All right, I got curious enough try again, and found that this is apparently caused by the static build of ffmpeg that I’m using: I used yle-dl --verbose again, then interrupted the download immediately, ran the ffmpeg command (as reported by yle-dl) directly, and this resulted in a segmentation fault.

I then tried the same command in a VM with ffmpeg from Ubuntu repositories, and there the download finished successfully.

So the only remaining issue with yle-dl in this is the terminal being broken: that did not occur with directly-run ffmpeg despite the segfault.

I’m closing this issue though, so that it remains as documentation for the problem (and cause) as originally reported.

Trying to download this 7-hour long program only downloads (about) the first 6 hours and 40 minutes (~ 11 GB), after which the process just stops, and leaves Gnome terminal screwed up (typed characters are invisible until I run reset). In the web player the video seems to play past that point just fine.

This is on Ubuntu 20.04 with ffmpeg version N-58594-g715f63232f-static (static build from git master on 20210908).

jani@saegusa:Työpöytä$ /usr/local/bin/yle-dl 'https://areena.yle.fi/1-50934704'
yle-dl 20210808: Download media files from Yle Areena and Elävä Arkisto
Copyright (C) 2009-2021 Antti Ajanki <antti.ajanki@iki.fi>, license: GPLv3

Unsupported codec with id 98313 for input stream 2
Unsupported codec with id 98313 for input stream 5
Unsupported codec with id 98313 for input stream 8
Unsupported codec with id 98313 for input stream 11
Unsupported codec with id 98313 for input stream 14
Unsupported codec with id 98313 for input stream 17
Unsupported codec with id 98313 for input stream 20
Unsupported codec with id 98313 for input stream 23
Unsupported codec with id 98313 for input stream 26
Unsupported codec with id 98313 for input stream 29
Output file: YleX Esittää: Yle 95 - synttäribileet Linkkitornista: 2021-09-18T00:00.mkv
jani@saegusa:Työpöytä$  size=10814976kB time=06:39:40.68 bitrate=3694.5kbits/s speed=  44x

Note the prompt appearing on top of ffmpeg output on the last line. Typing echo $? reveals that the process exited with code 1.

Here’s the output when run with --verbose.

I’ve only tested this over the past couple of days so I don’t know if it’s a temporary error. Since the portion of the stream that I actually care about is all prior to the 6-hour mark, and the partial download is playable, I’m not too bothered to have the rest download. Reporting this just in case it’s a useful test of a corner case.

I can add that to options.rst, but the terse explanation still seems pretty meaningless; at least for me there’s no visible difference when I run nextcloud with --background compared to running without.

This could be due to #2333 though, if running without --background is supposed to open the main dialog (which has never worked on Focal). If so, I’d mention this too, something like: ”Launch the application in the background (without opening the main dialog).”

For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.

• VSCode Version: 1.53.0
• OS Version: Ubuntu Linux 20.04

Steps to Reproduce:

1. install .deb package
2. 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:

1. Open a card
2. 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.