- Arch-general - lists.archlinux.org

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

Which Emacs package?
by Abraham S.A.H. 31 Mar '24

31 Mar '24

Hey fellows; There are many Emacs packages available across Arch repositories and AUR. I list some of them here, in no specific order: From Extra repository: * emacs * emacs-wayland * emacs-nativecomp * emacs-nox From AUR and some third party repositories: * emacs-lucid-nativecomp * emacs-git * chaotic-aur/emacs-pgtk-native-comp-git I do not explain any of them for details. My audience is the one who already tried them, so can give me some advice. I already have tried all of them and also read archwiki's Emacs article. The Lucid one seems like the most stable with the least bugs, but with an archaic UI and without dnd support, but I do not use those scroll/menu/toolbars. Please, if you have any experience, share it with me. -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

5 6

man.archlinux.org/man/xzmore.1.uk is not in English
by u34＠net9.cf 30 Mar '24

30 Mar '24

https://man.archlinux.org/man/xzmore.1.uk manual page is not in English. Visually, I would say my local copy, man -l /usr/share/man/uk/man1/xzmore.1.gz , and xzmore.1.uk at man.archlinux.org have the same text. I also have many warnings, for a lot of packages, from pacman -Qkk. One of these warnings is about /usr/share/man/uk/man1/xzmore.1.gz. The warning is despite the fact the actaul data for /usr/share/man/uk/man1/xzmore.1.gz seems to agree with zgreping /var/lib/pacman/local/xz-5.6.1-2/mtree for that file. Local pacman version is 6.0.2-9. -- u34

3 4

Mensaje de ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ
by ꪗꪮ𝘳ᦔꪖꪀ𝓽ꫀ 29 Mar '24

29 Mar '24

hello

1 0