- Arch-general - lists.archlinux.org

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

Why after rebuild do I still get "warning: normalize: unknown key 'makepkgopt' in package description"?
by David C. Rankin 28 Mar '24

28 Mar '24

All, In whatever changed a week or so ago, pacman gave "... unknown key 'makepkgopt' in package description" for a slew of old packages left on my system from a decade of use. I've since gone back and removed all the packages and rebuilt the ones I need, but I still get a handful of errors for the 'normalize' package I've just built. What am I doing wrong? On cleaning the cache I get: 20:11 valkyrie:~> pms -c Packages to keep: All locally installed packages Cache directory: /var/cache/pacman/pkg/ :: Do you want to remove all other packages from cache? [Y/n] removing old packages from cache... warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description warning: normalize: unknown key 'makepkgopt' in package description Database directory: /var/lib/pacman/ :: Do you want to remove unused repositories? [Y/n] removing unused sync repositories... The normalize package is the one I just built and updated from AUR, e.g 20:12 valkyrie:~> pmqi normalize Name : normalize Version : 0.7.7-7 Description : A tool for adjusting the volume of WAV files to a standard level Architecture : x86_64 URL : http://normalize.nongnu.org Licenses : GPL Groups : None Provides : None Depends On : audiofile libmad vorbis-tools lame flac mpg123 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 118.49 KiB Packager : Unknown Packager Build Date : Tue 19 Mar 2024 08:07:32 PM CDT Install Date : Tue 19 Mar 2024 08:08:26 PM CDT Install Reason : Explicitly installed Install Script : No Validated By : None The PKGBUILD is: 20:13 valkyrie:~> cat arch/pkg/bld/normalize/PKGBUILD # $Id: PKGBUILD 266875 2017-11-15 14:29:11Z foutrelis $ # Maintainer: Giovanni Scafora <giovanni(a)archlinux.org> # Contributor: Tom Newsom <Jeepster(a)gmx.co.uk> pkgname=normalize pkgver=0.7.7 pkgrel=7 pkgdesc="A tool for adjusting the volume of WAV files to a standard level" arch=('x86_64') url="http://normalize.nongnu.org" license=('GPL') depends=('audiofile' 'libmad' 'vorbis-tools' 'lame' 'flac' 'mpg123') makedepends=('pkg-config' 'intltool') source=("http://download.savannah.gnu.org/releases/${pkgname}/${pkgname}-${pkgver}.t…" 'normalize-0.7.7-audiofile-pkgconfig.patch' 'normalize-0.7.7-m4.patch') md5sums=('1749b16fc7a08aa5d0cf9f76eeaa8436' '77d565e29bef11837e80347adfd42b58' '0b4bca7bf183275b9f939576ebad4233') prepare() { cd "${srcdir}/${pkgname}-${pkgver}" patch -Np1 -i "${srcdir}/normalize-0.7.7-audiofile-pkgconfig.patch" patch -Np0 -i "${srcdir}/normalize-0.7.7-m4.patch" touch AUTHORS NEWS ChangeLog #libtoolize --force --copy #aclocal -I m4 autoreconf -vi #automake --add-missing } build() { cd "${srcdir}/${pkgname}-${pkgver}" ./configure --prefix=/usr \ --mandir=/usr/share/man \ --with-audiofile \ --with-mad make } package() { cd "${srcdir}/${pkgname}-${pkgver}" make DESTDIR="${pkgdir}" install } Nowhere can I figure out where there is a "key 'makepkgopt' in package description". The package description is pkgdesc="A tool for adjusting the volume of WAV files to a standard level" Where is the "... key 'makepkgopt' ..." coming from? -- David C. Rankin, J.D.,P.E.

2 2