- VSCode Version: 1.53.0
- OS Version: Ubuntu Linux 20.04
Steps to Reproduce:
- install .deb package
- run
debsums -s
Does this issue occur when all extensions are disabled?: Yes
I’d like to resurrect #37762: the checksums for .desktop files included in the .deb archive fail to pass post-install.
$ debsums -s code
debsums: changed file /usr/share/applications/code.desktop (from code package)
debsums: changed file /usr/share/applications/code-url-handler.desktop (from code package)
This happens because the postinst script calls desktop-file-install
for the .desktop files, which adds an X-Desktop-File-Install-Version
entry to them, and hence the checksums change.
I don’t know why the desktop-file-install
call is there, as including the .desktop files in the deb archive is sufficient to have them installed (in their proper place under /usr/share/applications/), with the checksum intact.
I built the package with just those desktop-file-install
calls removed (see below), after which the checksums pass post-install (with no other changes that I can see).
diff --git a/resources/linux/debian/postinst.template b/resources/linux/debian/postinst.template
index c72fe5f9f5..dcc147de93 100755
--- a/resources/linux/debian/postinst.template
+++ b/resources/linux/debian/postinst.template
@@ -12,12 +12,6 @@ ln -s /usr/share/@@NAME@@/bin/@@NAME@@ /usr/bin/@@NAME@@
# developers would prefer a terminal editor as the default.
update-alternatives --install /usr/bin/editor editor /usr/bin/@@NAME@@ 0
-# Install the desktop entry
-if hash desktop-file-install 2>/dev/null; then
- desktop-file-install /usr/share/applications/@@NAME@@.desktop
- desktop-file-install /usr/share/applications/@@NAME@@-url-handler.desktop
-fi
-
# Update mimetype database to pickup workspace mimetype
if hash update-mime-database 2>/dev/null; then
update-mime-database /usr/share/mime
While hardware fault and memtest bugs are possible, there’s also LP #1876157: Memtest86+ in Ubuntu 20.04 doesn’t work. So if the memtest you ran was from Ubuntu 20.04 images, try running memtest from Ubuntu 18.04 images.
1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:
ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android
> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk
./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log
The top of that file, build.sh
, refers to /bin/sh
, but on Ubuntu and Debian, /bin/sh
has been Dash for quite a while, whereas build.sh
seems to written for Bash (where function is a valid keyword):
ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh
#!/bin/sh
function execute() {
cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}
I suggest switching the shebang to #/bin/bash
, or better yet, #!/usr/bin/env bash
(for path-agnosticity). In my environment, using either one fixes the build.
Since recently, editing the description takes two clicks instead of just one. The first click turns the content into a textbox, but it remains unfocused until I click it again.
Issue
Server Setup Information:
- Did you test in newest Wekan?: yes
- For new Wekan install, did you configure root-url correctly so Wekan cards open correctly? yes
- Wekan version: 4.49
- Meteor version: 2.0-beta.4
- Node version: 12.19.0
- MongoDB version: 3.2.22
- Operating System: Ubuntu 20.04
- Deployment Method: snap
- Http frontend if any: Apache
- What webbrowser version are you using? Both Firefox 82.0.2 and Chrome 86.0.4240.183 equally affected.
- If using Snap, what does show command
sudo snap logs wekan.wekan
? nothing
Problem description:
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.
Steps to reproduce:
- Open a card
- Click on the description once
What I expect to happen:
For the description to have focus (i.e. cursor, to be able to type)
What happens instead:
The description textbox remains unfocused and I can not type into it
Console log contents
site.webmanifest:1 GET https://my-domain.com/site.webmanifest 404 (Not Found)
site.webmanifest:1 Manifest: Line: 1, column: 1, Syntax error.
A bad HTTP response code (404) was received when fetching the script.
mZLgcqMWYXM4o7dmL:1 Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://my-domain.com/') with script ('https://my-domain.com/pwa-service-worker.js'): A bad HTTP response code (404) was received when fetching the script.
It seems to refer to to paths in the domain root, whereas my root-url has the path https://my-domain.com/kan. Not sure if that’s related to the issue or not.
Currently experiencing this. `lsof /var/lib/dpkg/lock` shows only ”focal” as holding the lock. The same ”focal” process is also eating up all of the CPU. No dpkg or apt processes are listed by `ps` either.
A fix has recently been committed upstream: https://salsa.debian.org/debian/ddclient/-/commit/82d99d1dfb0fb002a15e081fdc7ccf8f96215dc6
My guess is this is due to bug #1785354: ”/etc/fstab: fs_passno is 0 for all file systems”. So yes, you should probably correct it.
I removed all but Desktop Icons, Ubuntu AppIndicators and Ubuntu Dock, rebooted and then reproduced the issue. Luckily I’ve found one way to reproduce this, albeit somewhat convoluted and still a bit unreliable, involving Synaptic and window tiling. And as it doesn’t seem to trigger the issue when using another account, I’m now working through settings differences between the two in hopes of finding something crucial.
While doing so, I did discover that dconf-editor is similarly affected:
touko 12 16:09:32 saegusa gnome-shell[8208]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
touko 12 16:09:32 saegusa gnome-shell[8208]: WL: error in client communication (pid 12364)
touko 12 16:09:32 saegusa dconf-editor[12364]: Error reading events from display: Katkennut putki
touko 12 16:09:32 saegusa boinc[2098]: No protocol specified
touko 12 16:09:32 saegusa boinc[2098]: No protocol specified
touko 12 16:09:33 saegusa boinc[2098]: No protocol specified
touko 12 16:09:33 saegusa boinc[2098]: No protocol specified
touko 12 16:09:34 saegusa gnome-shell[8208]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
touko 12 16:09:34 saegusa boinc[2098]: No protocol specified
touko 12 16:09:34 saegusa boinc[2098]: No protocol specified
touko 12 16:09:34 saegusa gnome-shell[8208]: WL: error in client communication (pid 12796)
touko 12 16:09:34 saegusa gnome-terminal-[12796]: Error reading events from display: Katkennut putki
touko 12 16:09:34 saegusa systemd[3569]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
touko 12 16:09:34 saegusa systemd[3569]: gnome-terminal-server.service: Failed with result 'exit-code'.
touko 12 16:09:34 saegusa systemd[3569]: vte-spawn-da1941e8-60e5-48e5-868b-7348dd1158c7.scope: Succeeded.
touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
Looks like dconf-editor did not exit with FAILURE, but the dconf-editor window did disappear just as Gnome terminal’s did.
For future reference, this was probably Ubuntu bug #1875558 (”libproxy1-plugin-gsettings triggers a lot of warnings”).
Still present in 20.04 (Focal) with vlc 3.0.9.2-1, though here at least it seems to only affect some URLs, not all. When I view a stream from my local webcam, vlc -vvv in the terminal shows
main playlist debug: incoming request – stopping current input
as the final message, and does not exit (after closing the window; Ctrl-Q still works). But when streaming from Wowza’s RTSP test stream [1], vlc exits just fine after closing the window.
Debian bug 916595 [2] and related VLC ticket [3] mention disabling hardware acceleration as a workaround, but even so I was unable to make it work (i.e. exit properly).
Possibly related: Ubuntu bug #1847162. There’s also been discussion about the issue over on Manjaro forums [4].
* [1] rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov
* [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916595
* [3] https://trac.videolan.org/vlc/ticket/20627
* [4] https://forum.manjaro.org/t/vlc-not-closing/69965/2