- Arch-general - lists.archlinux.org

An Intro from A Debian User
by Chime Hart 10 Apr '24

10 Apr '24

Well, 2nd try, as I must have posted to the subscription address instead. I am still running Debian SID on my main machine with a screen-reader, Speakup, as I am totally blind. Meanwhile, I wanted to try a newer screen-reader, called Fenrir on a laptop. So, we switched over to Arch. While at times I find the 2 package managers confusing, I like an aspect of a much newer kernel. An issue, I cannot find a smaller font which will provide many more lines. So far only 67, but when I was in Debian with this same laptop, I had 135. Can any1 please suggest a font which will do the trick? Storm, who maintains Fenrir says I would need a font which supports utf8, so Fenrir will read. I am having glowing support from Storm as well as Didier, an author of Slint, another accessable distro. Thanks so much in advance Chime

8 14

ipset enabled fails to restore /etc/ipset.conf
by David C. Rankin 10 Apr '24

10 Apr '24

All, I've setup a blocklist (hash:net) a whitelist (hash:ip) and a whitelistnet (hash:net) with ipset. It works quite well added to the stateful firewall. However ipset restore fails: 18:02 valkyrie:~> scs ipset × ipset.service - Loading IP Sets Loaded: loaded (/usr/lib/systemd/system/ipset.service; enabled; preset: disabled) Active: failed (Result: exit-code) since Wed 2024-04-10 17:06:05 CDT; 56min ago Process: 1399 ExecStart=/usr/bin/ipset -f /etc/ipset.conf restore (code=exited, status=2) Main PID: 1399 (code=exited, status=2) CPU: 3ms Apr 10 17:06:05 valkyrie systemd[1]: Starting Loading IP Sets... Apr 10 17:06:05 valkyrie ipset[1399]: ipset v7.20: No command specified: unknown argument Name: Apr 10 17:06:05 valkyrie ipset[1399]: Try `ipset help' for more information. Apr 10 17:06:05 valkyrie systemd[1]: ipset.service: Main process exited, code=exited, status=2/INVALIDARGUMENT Apr 10 17:06:05 valkyrie systemd[1]: ipset.service: Failed with result 'exit-code'. Apr 10 17:06:05 valkyrie systemd[1]: Failed to start Loading IP Sets. The sets cannot manually be restored with ipset restore (or ipset restore -file ipset.conf). It results in the same error: # ipset restore <ipset.conf ipset v7.20: No command specified: unknown argument Name: Try `ipset help' for more information. As does: # ipset restore -f ipset.conf ipset v7.20: No command specified: unknown argument Name: Try `ipset help' for more information. The content of the ipset save > ipset.conf file is the same as ipset list, and looks fine, e.g. # cat /etc/ipset.conf Name: blocklist Type: hash:net Revision: 7 Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xf3661058 Size in memory: 8856 References: 0 Number of entries: 194 Members: 167.94.138.0/24 199.45.154.0/23 43.130.0.0/18 43.129.192.0/18 43.157.32.0/24 <snip> Name: whitelist Type: hash:ip Revision: 6 Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xfa0e1f24 Size in memory: 1816 References: 0 Number of entries: 42 Members: 212.187.231.66 93.93.130.214 151.101.129.91 91.193.113.65 87.238.57.227 93.93.130.133 <snip> Name: whitelistnet Type: hash:net Revision: 7 Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xc9e0aa3d Size in memory: 504 References: 0 Number of entries: 1 Members: 151.101.129.0/24 The bug mentioned in the wiki https://wiki.archlinux.org/title/Ipset was not hit. Even though ipset failed to load the sets, iptables started normally. After manually re-creating the tables and restoring the iptables rules, iptables is again using the sets: # iptables -nvL --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set whitelistnet src 2 0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set whitelist src 3 0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set blocklist src 4 0 0 f2b-dovecot 6 -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 110,995,143,993,587,465,4190 <snip> I've followed the wiki and the man-page (and help) command to restore the files manually, but nothing seems to work. Any ideas what is going on? I'm brand new to ipset, so I don't have much experience to draw from. Anybody else seeing this or see a reason ipset isn't being restored on startup by ipset.service? -- David C. Rankin, J.D.,P.E.

1 0

Changing of archive packages to git tags
by Aaron Liu 10 Apr '24

10 Apr '24

Ey, Recently, a bunch of packages such as cowsay have switched to pulling from a git tag away from downloading from the /archive/ path of GitHub. Since downloading GitHub's archives are guaranteed to have the exact same contents as pulling from the tags, with the added benefit of not pulling the .git folder, is there any benefit to this? To my knowledge, the problematic xz tarballs were under the /release/ path as uploaded artifacts, while the /archive/ download remained clean. Aaron

2 1

Graphical session inside systemd-nspawn container
by FirstName LastName 09 Apr '24

09 Apr '24

Hello, I am trying to run X from within a systemd-nspawn container - this is something I had set up and was running successfully about three years ago, but something seems to have changed in the meantime and I am not able to recreate this. I created the container and installed X related packages following the wiki article, and was able to boot into my container and create an unprivileged user. The script I am using to boot is (modified from my container of three years ago): xhost +local: sudo systemd-nspawn -b -D /mnt/extra/nspawn-containers/test \ --bind-ro=/tmp/.X11-unix \ --bind=/dev/dri \ --bind=/dev/shm \ --bind=/dev/nvidia0 \ --bind=/dev/nvidiactl \ --bind=/dev/nvidia-modeset \ --setenv=DISPLAY=:0.0 \ xhost - When I try to `startx` from within the container, however, I get this: /usr/lib/Xorg.wrap: Only console users are allowed to run the X server xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error Couldn't get a file descriptor referring to the console. I am not entirely sure where to go from here. Is there something incomplete in my configuration? Looking up the Xorg.wrap error message, I only find that X will not run on pseudo terminals, but I do not know what to do about this or if this is even the problem. Best regards, e

3 4

Package java-environment-common-3-5 installs incorrect symlinks
by Wouffy The Dog 09 Apr '24

09 Apr '24

Hello, I was cleaning my machine, trying to find broken symlinks. I scanned my `/bin` directory with `find -L /bin/ -type l -ls`, and it found broken links installed by `java-environment-common` (`pacman -Qqo /bin/javah` for example). Is it the case for some of you?

4 3

Re: Arch Linux Rust packaging licensing problem
by Maarten de Vries 09 Apr '24

09 Apr '24

On 07-04-2024 13:10, Jan Alexander Steffens (heftig) wrote: > Hi Arvid, > > Thanks for bringing this issue to my attention and your detailed email > about it. I'm CCïng our public development mailing list in this > response so our other maintainers get informed, too. > > I agree that Arch needs a solution for this eventually. Unlike Fedora > we do not package Rust libraries so I think we need some help from > Cargo for this. Preferably from upstream, but a third-party tool would > work as well. > > Ideally, I think there we would create a SPDX license expression from > the entire crate tree and then simplify it, e.g. to turn `(MIT) AND > (MPL-2.0 OR MIT) AND (MIT AND BSD-2-Clause) AND (MPL-2.0 OR > BSD-3-Clause)` into `MIT AND BSD-2-Clause AND (MPL-2.0 OR > BSD-3-Clause)`. Or perhaps even simpler if the tool had knowledge > about which licenses are covered by others. > > We could call such a tool in the `package()` function to set the > `license` for the package. > > I'm not sure how feasible this would be. Are crates required to use > SPDX expressions? > > Greetings, > Jan > > Hey, Replying on the general mailing list since the dev list is staff only. The license field of the pacman package is actually only secondary concern. Many libraries have a license that requires shipping the copyright information along with binary distributions (such as MIT and BSD licenses). This is more than just the name or SPDX identifier of the license. Usually, it is included at the top of a license file and it would look like this: > Copyright (c) 2024, Maarten de Vries There are tools to help with this: https://crates.io/crates/cargo-bundle-licenses https://crates.io/crates/cargo-lichking Personally I think having incomplete SPDX identifier in the pacman package is not in itself a license violation as long as the individual license files are shipped with the package. Although it would certainly be nice for tooling if the package information is complete too. Kind regards, Maarten de Vries

8 9

pacman link
by james smith 09 Apr '24

09 Apr '24

the link[1] in the bugs part links to the old bugs it should link to the new one[2] [1]https://archlinux.org/pacman/ [2]https://gitlab.archlinux.org/archlinux/packaging/packages/pacman

1 0

postfix 3.9.0-1 - Worthy of "Latest News" note?? This will catch some people
by David C. Rankin 08 Apr '24

08 Apr '24

Arch devs, The update to postfix 3.9.0-1 appears worthy of a note in "Latest News" on archlinux.org as it will require manual user intervention. The upgrade note in pacman with the upgrade is much appreciated, but removal of hash: database types and replacement by lmdb will require regeneration of all user databases. This is something I'd expect a "Latest News" note on for those managing servers running arch. Just a suggestion. If you think the note on update is sufficient, that's fine too. The only reason I bring it up is this isn't a normal manual intervention that is required (like mariadb update or postgres collation version updates) where people are on the lookout for manual steps. Other than needing to rebuild the databases and skim through and blend the .pacnew changes to main.cf, all goes fine. -- David C. Rankin, J.D.,P.E.

1 0

Re: Proposal to increase the default vm.max_map_count value
by Genes Lists 02 Apr '24

02 Apr '24

On Tue, 2024-04-02 at 12:29 +0200, Robin Candau wrote: > On 4/2/24 11:59 AM, Robin Candau wrote: Couple of comments. * In lkml thread on same topic not everyone is on board with this [1] * Where to put this kind of thing Would it make sense to collect these kind of "system" settings, that dont clearly belong to a specific application, into a separate package (arch-system-settings or whatever). Admittedly at moment this would be very small package 🙂 [1] https://lkml.org/lkml/2024/4/2/404 -- Gene

1 0

Re: [arch-announce] The xz package has been backdoored
by Genes Lists 01 Apr '24

01 Apr '24

On Fri, 2024-03-29 at 18:55 +0000, Arch Linux: Recent news updates: David Runge wrote: > TL;DR: Upgrade your systems and container images **now**! > > Thanks for sharing. Truly an astounding revelation. This is a very, very sophisticated tool-chain attack along the lines of Ken Thompson's famous compiler trust example [1] Arch has been a strong advocate for reproducible builds [2] which can be part of a defense strategy [2]. I note that our xz package is marked as good in this regard [3]. I wonder what more we can reasonably do in the near term. Since git gives us decent tools to check what changed etc., I would imagine that can provide a stronger base on which to check things than working with tarballs or tarballs alone. This may have gone largely un-noticed for so long as people are probably more likely to check the source than the tarball itself. In this case, it seems, it was a primary developer doing the naughty - but they chose to leave the git repo alone and only infect the tarball. Question: -------- Would it make sense, therefore, to switch builds, where possible, away from tar files and instead pull directly from git source (signed tags where possible as usual etc)? Of course a git repo can also carry infections - perhaps taht's a little less likely. Or is this not worth the trouble? Gene [1] https://wiki.c2.com/?TheKenThompsonHack [2] https://reproducible-builds.org/ https://wiki.archlinux.org/title/DeveloperWiki:ReproducibleBuilds https://bootstrappable.org/ [3] https://reproducible.archlinux.org/ -- Gene

2 1