February 2020 - Arch-general - lists.archlinux.org

[arch-general] Packages "jami-gnome" and "libjamiclient" out of date
by Friedrich Strohmaier 24 Oct '20

24 Oct '20

Hi archers, Packages "jami-gnome" and "libjamiclient" are flagged out of date since 2019-11-16 / 2019-11-20. There are two new releases in place. I tried to contact the maintainer twice but nothing happened. I retrieved the maintainers (Bruno Pagani) mail adress from this mailinglist. I suspect the mails didn't ever get there. Any hints how to proceed? -- Friedrich

3 5

[arch-general] Hibernation Failure
by Paul Dann 23 Apr '20

23 Apr '20

I'm having trouble getting hibernation to work on my new Dell Inspiron 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), but resume fails, with the following left in the kernel logs: --- PM: Image signature found, resuming PM: resume from hibernation Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. PM: Marking nosave pages: [mem 0x00000000-0x00000fff] PM: Marking nosave pages: [mem 0x0009e000-0x0009efff] PM: Marking nosave pages: [mem 0x000a0000-0x000fffff] PM: Marking nosave pages: [mem 0x40000000-0x403fffff] PM: Marking nosave pages: [mem 0x66797000-0x66798fff] PM: Marking nosave pages: [mem 0x761f7000-0x791fefff] PM: Marking nosave pages: [mem 0x79200000-0xffffffff] PM: Basic memory bitmaps created PM: Using 3 thread(s) for decompression PM: Loading and decompressing image data (1343374 pages)... PM: Image loading progress: 0% PM: Image loading progress: 10% PM: Image loading progress: 20% PM: Image loading progress: 30% PM: Image loading progress: 40% PM: Image loading progress: 50% PM: Image loading progress: 60% PM: Image loading progress: 70% PM: Image loading progress: 80% PM: Image loading progress: 90% PM: Invalid LZO compressed length PM: Read 5373496 kbytes in 6.35 seconds (846.21 MB/s) PM: Error -1 resuming PM: Failed to load hibernation image, recovering. PM: Basic memory bitmaps freed OOM killer enabled. Restarting tasks ... done. PM: resume from hibernation failed (-1) --- And then the system boots fresh. An internet search revealed absolutely nothing about the "Invalid LZO compressed length", and I've no idea why the image would be corrupt. I'd appreciate any ideas. Paul

3 8

[arch-general] Pacman Database Signatures
by Christopher W. 25 Mar '20

25 Mar '20

Hi. The wiki states that database signatures for pacman are currently a work in progress. It's been that way for a long time, so I assume there is no "progress" happening. What is currently in the way of this much-needed security feature to be fully implemented? Right now, pacman is taking untrusted input from the internet as root. That's very bad. Most of the comments I've seen say that an attacker could hold back vulnerable packages, but this is assuming the attacker does not have bigger plans. The pacman tool is not immune to bugs in the way it parses the database files. It has no privilege separation in the download/parsing code as far as I can see (apt and others have had this for a long time) so it's really an even more dire situation. Pacman should not perform any operations as root until it has verified the signature of all files being used to install/upgrade the packages, but it currently does everything (downloading, verifying, etc) as root. I'd like to get a discussion going about how and when these two issues could be resolved so that all Arch users can be safer. Thanks.

4 7

[arch-general] 5.5 kernel - Latest virtualbox testcase build for 5.2.37 fails to start Arch guest on Arch host
by David C. Rankin 06 Mar '20

06 Mar '20

lAll, After update to 5.5 kernel and rebuild of virtualbox from the 5.2.36 and the latest testcase build for 5.2.37 (all kernel modules build and load fine) https://www.virtualbox.org/download/testcase/VirtualBox-5.2.37-135942-Linux… Arch guests fail to run on Arch host. network device enp0s3 not found, udev kernel rules fail, and the boot never complete. All fine with the 5.4 kernel. I've posted to the vbox-users list, but if anyone here has additional information I would appreciate it. -- David C. Rankin, J.D.,P.E.

3 8

Re: [arch-general] [arch-dev-public] Potential removal of Chromium in ~2 months
by Geo Kozey 27 Feb '20

27 Feb '20

On Saturday, February 22, 2020 5:50 AM, Evangelos Foutras via arch-dev-public <arch-dev-public(a)archlinux.org> wrote: > Just a quick heads up that I am considering dropping Chromium from > [extra] a week or two before the Chromium 82 stable release (~April 28). > The reason for this is that our API keys no longer work for geolocation > requests and there is no clear upstream guidance on how to resolve this > issue. [1] > > When I created these API keys back in 2013, there was a semi-official > effort by the Chrome Team to support distro builds of Chromium in regard > to accessing Google APIs; a few minor hiccups along the way were quickly > resolved. I feel this arrangement is starting to fall apart (in spite of > some upstream Chrome developers' best efforts). > > To make a long story short, I consider broken geolocation sufficient > reason for removal. I don't mind it being broken for my own use, but > shipping a package with broken functionality due to lack of upstream > support does not sit well with me. > > To protect against systems with outdated Chromium (following the stable > release of version 82), at the beginning of April I intend to post a > news item about the need to switch to another browser. That is assuming > no solution is found and nobody objects to the removal or wishes to > continue maintenance of the package with reduced functionality. > > [1] > https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/Z… Hi, First of all let me thank you for high quality maintainership of chromium package in Arch. This post was really surprising for me and sad but also quite confusing because I don't understand how lack of some minor feature can involve nuclear option of removing dominant and most tech-advanced browser on the market from Arch repos. I bet most users won't even notice lack of it and some may even welcome removal of so called "spyware". Those who treat geolocation as critical feature may choose different browser but forcing everyone out of they beloved one for this particular reason seems like overreaction to me. Yours sincerely G. K.

4 4

[arch-general] Package Jami is out of date
by Simon Brand 27 Feb '20

27 Feb '20

Hello, the package Jami is out of date: https://www.archlinux.org/packages/community/x86_64/jami-gnome/ The last packager seams to be not active anymore. Can anybody please take over the package? Best, Simon

2 4

[arch-general] animate.sty in texlive-latexextra needs update
by Marco 24 Feb '20

24 Feb '20

Dear list, I run into the problem of outdated package "animate" contained in texlive-latexextra. With the current version of the package, xelatex is not able to embed animations at least when using png frames. At the contrary, pdflatex works fine. Replacing the /usr/share/texmf-dist/tex/latex/animate/animate.sty with the version "2019/12/03" available upstream, that is, from CTAN [1], fixes the issue. I am now confused as what it's the best way to proceed, since I am not familiar with Arch's release cycle of texlive. Should I flag texlive-latexextra as out-of-date? Or is it better to file a bugreport? Suggestions welcomed. Cheers, Domanov [1] https://www.ctan.org/tex-archive/macros/latex/contrib/animate

2 2

[arch-general] Chromium in a systemd-nspawn container?
by Mark Raynsford 22 Feb '20

22 Feb '20

Hello! It seems that a recent update (unfortunately, I'm not sure exactly which) broke my ability to run Chromium in a systemd-nspawn container. Specifically, the symptom is that the Chromium window opens, but remains blank and evidently doesn't respond to keyboard/mouse input. Firefox in the same container runs without issue. Is there something I can do to debug this issue? I'm using the standard trick to allow containers to access X: https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_an_X_environment The only possibly relevant error message I see on Chromium's stderr is: 67:67:0221/100217.520256:ERROR:gpu_channel_manager.cc(459)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. I've tried the --disable-gpu flag, but that makes no difference. Any ideas? -- Mark Raynsford | http://www.io7m.com

4 4

[arch-general] Mate 1.24.0 status?
by fredbezies 22 Feb '20

22 Feb '20

Hello. I noticed that all mate packages are flagged as outdated for nearly two weeks now. I built Mate 1.24.0 using official PKGBUILDs and it ran great besides a rebuild of mate applets related to new cpupower version. Any ETA for Mate 1.24? Thanks. -- Frederic Bezies fredbezies(a)gmail.com

1 0

[arch-general] post-install dependencies check
by Jude DaShiell 22 Feb '20

22 Feb '20

Can pacman be used to find which packages are missing which optional dependencies after an install? --

5 13