Sure. There shouldn’t be anything confidential here
installer.tar.xz Edit (396.6 KiB, application/x-tar)
@Olivier: Sure. This VM was just for testing purposes, so there shouldn’t be anything confidential here.
installer.tar.xz Edit (396.6 KiB, application/x-tar)
@Olivier: Sure. This VM was just for testing purposes, so there shouldn’t be anything confidential here.
Screenshot from 2022-09-26 21-01-16.png Edit (159.6 KiB, image/png)
Looks like the deb line for updates is missing entirely from sources.list in this install; only the deb-src is there.
Screenshot from 2022-09-26 19-36-11.png Edit (149.8 KiB, image/png)
@Simon Here goes, although now it just shows both at 9.7, and 9.9 not yet available. Before I downgraded libc6 it obviously showed libc6 at 9.9.
I also tried to reproduce the issue in a fresh VM, but those kept getting 9.9 for all the packages, so installing build-essential caused no issues.
I don’t have in-depth knowledge about phased updates, but this looked like as if downloading the updates during installation was not yet affected by phased updates (and hence got libc 9.9), but, after the installation was completed, the system got cast into a ”still at 9.7” group of phased updates, and so libc6-dev (et al) could not be installed.
Just got hit by the same issue in a VM after a fresh install of 20.04.5. I chose ”Minimal installation”, ticked ”Download updates while installing”, and installed the remaining updates post-install.
After that the first thing I tried to do was to install build-essential, which failed, because the version of libc6 was out of sync with the rest of the libc6* packages: libc6 was already at 2.31-0ubuntu9.9, while e.g. libc6-dev was still only available as 2.31-0ubuntu9.7.
I tried switching from my local archive (fi.archive.ubuntu.com) to the main one (archive.ubuntu.com), but that made no difference. I had to downgrade libc6 to 2.31-0ubuntu9.7 to be able to install build-essential.
Hi @claucambra, I tested the appimage and the issue still reproduces.
Using a path with umlauts as logDir
causes an incorrectly encoded directory to be created and used as log directory, instead of the specified directory.
nextcloud.cfg
. Set logDir=/home/jani/Tänne
(applying appropriately to your home directory)ls /home/jani/Tänne
A listing of new log files residing in /home/jani/Tänne
.
This question is unclear. The log files are the ones affected.
Linux
Ubuntu 20.04
Distro package manager
24.0.4
3.5.4-20220806.084713.fea986309-1.0~focal1
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Encryption is Disabled
No response
This bizarre and otherwise exhaustingly long issue form is lacking a ”What happens instead of my expected outcome” question, so I’m entering it here instead: there are no logs in the specified target directory (it doesn’t even exist if you’ve not created it beforehand). Instead, like in the ye olden days, there is now a directory called Tänne
containing the logs. In nextcloud.cfg
the path has been re-encoded as logDir=/home/jani/T\xc3\xa4nne/
which is apparently how it should be, since a similarly re-encoded value for a ...localPath
with umlauts in the [accounts]
section has been working just fine for as long as I can remember using it.
I’m affected by this. Storied from PBS appears the only one of my followed channels to exhibit this, though it may very well just be the only one with audio description tracks provided. For instance, this video has the first description at t=71 (”A huge orange eye opens”). As with Yuseldin’s example, the descriptive track is available, but not selected by default when I open the video in a browser.
I’m getting these unrequested emails from my self-hosted instance, with no apparent way to disable them. This is bad, bad behavior.
Host an instance running Mattermost 6.6.1. Leave it ”collecting a bit of dust”.
Not to get spammed with unwanted emails.
Keybase key for verifying the tar archive’s signature is missing.
Get a public key to verify the tar archive’s signature.
404 not found