Avainsanana Ubuntu

JSON files attached to a card (with .json filename extension) are empty when downloaded

28. tammikuuta 2022 klo 14.01
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Apache, Brave, Firefox, Snap, Ubuntu, Wekan, Wikipedia


JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

  • Did you test in newest Wekan?: 5.90
  • Did you configure root-url correctly so Wekan cards open correctly? yes
  • Operating System: Ubuntu 20.04
  • Deployment Method: snap
  • Http frontend if any: Apache
  • What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

  1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
  2. Open a card in Wekan.
  3. Select + from the Attachments section.
  4. Select ”Computer” from the popup.
  5. Select example.json.
  6. With the JSON file now attached to the card, select to ”Download” it.
  7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.


Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

  • Deleting the attachment seems to work.
  • The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Vastaa viestiin sen kontekstissa (Github)

Checksum mismatch in .gitlab_kas_secret post-install & gitlab-ctl reconfigure

4. joulukuuta 2021 klo 12.57
Sijainti: Vianhallintajärjestelmät: Gitlab
Avainsanat: Debian, Gitlab, Ubuntu


I’m running debsums -c daily, hoping to catch file corruption and/or other abnormalities early. (The Debian package even provides a pre-made cronjob for this task.)

debsums -c gitlab-ce reports .gitlab_kas_secret as deviating from the provided md5sum.

Steps to reproduce

  1. apt install gitlab-ce
  2. vi /etc/gitlab/gitlab.rb # set external URL
  3. gitlab-ctl reconfigure
  4. debsums -c gitlab-ce

What is the current bug behavior?

# debsums -c gitlab-ce

What is the expected correct behavior?

# debsums -c gitlab-ce

Details of package version

Provide the package version installation details
ii  gitlab-ce      14.5.1-ce.0  amd64        GitLab Community Edition (including NGINX, Postgres, Redis)

Environment details

  • Operating System: Ubuntu 20.04
  • Installation Target, remove incorrect values:
    • VM
  • Installation Type, remove incorrect values:
    • New Installation
  • Is there any other software running on the machine: plenty
  • Is this a single or multiple node installation? single

Configuration details

Provide the relevant sections of `/etc/gitlab/gitlab.rb`
external_url 'http://localhost'

Related issues

#2635 is basically the same, but I’ve never seen debsums complain about schema.rb.

Vastaa viestiin sen kontekstissa (Gitlab)

4.4.0: snapshots broken when netcam_high_url used with recommended width and height values

3. joulukuuta 2021 klo 16.45
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Motion, Ubuntu

  1. Reviewed guide and contributing documents? Yes
  2. version 4.4.0
  3. installed as a package or compiled from sources: deb
  4. standalone or part of third party: standalone
  5. video stream source: net cam
  6. hardware: x86 (amd64)
  7. operating system: Ubuntu 20.04

Short description

In Motion 4.4.0, using recommended values of width and height results in broken snapshots, when netcam_high_url is used. Either the warning about using a different resolution is incorrect, or the creation of snapshots breaks when width and height are set so as to not cause a warning on startup.


I have a 1080p camera (a TP-Link Tapo C100) with a 360p substream, so I’ve specied both URLs as follows:

netcam_url "rtsp://"                                        
netcam_high_url "rtsp://"

I’ve set up snapshots to occur with snapshot_interval = 60.

If I set width and height based on the main stream (1920×1080), Motion starts up with a warning:

netcam_rtsp_ntc: The network camera is sending pictures in a different
netcam_rtsp_ntc: size than specified in the configuration file.
netcam_rtsp_ntc: The picture is being transcoded into the size 
netcam_rtsp_ntc: requested in the configuration.  If possible change
netcam_rtsp_ntc: netcam or configuration to indicate the same size
netcam_rtsp_ntc: to possibly lower CPU usage.
netcam_rtsp_ntc: Netcam: 640 x 360 => Config: 1920 x 1080

This implies I should set width and height based on the lower resolution stream, so I’ve done that, and the warning goes away.

With Motion 4.3.2, the snapshots were saved as I would expect, albeit of course now in the lower resolution (360p), whereas I’d prefer them in the full 1080p.

After upgrading to 4.4.0, the snapshots are still 360p, but now their content is garbled and green:


I haven’t looked at the code, but what this looks like to me is as if Motion is now using the high resolution URL for the image data, but the lower resolution dimensions, and the resulting file is a (broken) crop of the full resolution image. Indeed, if I set width and height based on the full stream (i.e. back to 1920×1080), the snapshots now appear the full resolution and without corruption.

Pictures from detected motion (picture_output) do not appear to be affected, i.e. they are saved in the correct 1080p resolution and look fine, regardless of the values of width and height. Video output likewise appears in the higher resolution, as I would expect.

Here’s a minimal configuration that reproduces this issue for me, minus netcam_userpass.

log_level 8

target_dir "/home/jani/tmp"

netcam_url "rtsp://"
netcam_high_url "rtsp://"

netcam_params rtsp_transport=tcp
netcam_high_params rtsp_transport=tcp

width 640
height 360

snapshot_interval 10

Vastaa viestiin sen kontekstissa (Github)

This is apparently caused by the static build of ffmpeg

24. syyskuuta 2021 klo 20.26
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Ubuntu

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.

Vastaa viestiin sen kontekstissa (Github)

7-hour long program not downloaded completely

21. syyskuuta 2021 klo 12.25
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Gnome, Ubuntu, Yle Areena

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.

Vastaa viestiin sen kontekstissa (Github)

The terse explanation still seems pretty meaningless

28. toukokuuta 2021 klo 13.13
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Nextcloud, Ubuntu

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).”

Vastaa viestiin sen kontekstissa (Github)

I haven’t seen this since Ubuntu-distributed Firefox was updated to 84

20. joulukuuta 2020 klo 12.12
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

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.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Twitter tabs don’t load in Firefox when set as home

13. joulukuuta 2020 klo 16.37
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

I’m affected by this too, in Ubuntu 20.04 with Firefox 83.0+build2-0ubuntu0.20.04.1.

Tested nightly (85.0a1.en-US.linux-x86_64) with a clean profile, and the issue remains.

Steps to reproduce

  1. Start nightly with ./firefox -no-remote -profilemanager
  2. Create a new profile, select it and click Start Nightly
  3. Open these three tabs (replacing the first-run tabs currently open):
  1. Open preferences, set Home to Custom URLs…, select ”Use current pages”
  2. Close the window
  3. Start nightly again with ./firefox -no-remote -profilemanager, select the previously created profile

What happens

None of the three tabs load any content. The firefox process also doesn’t end after closing this window with the non-working tabs, I have to Ctrl-C out of it.

Further info

Upon subsequent starts, Nightly does appear to correctly load the tabs, whereas for my main Twitter profile and FF 83.0 no amount of restarts seems to help; instead I have to open another tab and open m.twitter.com in it, then click on the home button to have the home tabs load (and close the first, still stuck set of home tabs).

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Checksum mismatch in deb package for .desktop files

11. joulukuuta 2020 klo 19.45
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Debian, Ubuntu, VSCode

  • 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
 # Update mimetype database to pickup workspace mimetype
 if hash update-mime-database 2>/dev/null; then
        update-mime-database /usr/share/mime

Vastaa viestiin sen kontekstissa (Github)

There’s also LP #1876157: Memtest86+ in Ubuntu 20.04 doesn’t work

26. marraskuuta 2020 klo 14.29
Sijainti: Muut: Ask Ubuntu
Avainsanat: Ubuntu

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.

Vastaa viestiin sen kontekstissa (Ask Ubuntu)

Vanhempia »