December 2021 - Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] openssl 3.0
by Pierre Schmitz 15 Dec '22

15 Dec '22

Hi Jelle, (also forwarding to dev-public) definitely yes, OpenSSL 3.0 is on my wish list! :-) I did not want to jump on it at day one though. Even the last minor updates were quite painful and we still have packages requiring version 1.0 and are still not compatible with 1.1. While they claim that most packages should work with a recompile, it would be nice to actually know which packages are not compatible. This should help whether we need another compatibility package are would be able to just replace openssl 1.1 with version 3. I know about foutrelis' awesome rebuilder script, but I wonder if we have something similar that I just could run for half a day to get an idea which package would break and which wont? Like a dry run that wont commit anything. If no such thing exists yet, I might have a look myself. Greetings, Pierre On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote: > > Hi Pierre, > > Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens > to have already started. > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > Greetings, > > Jelle -- Pierre Schmitz, https://pierre-schmitz.com

10 19

[arch-dev-public] Upcoming PHP 8.1 update
by Pierre Schmitz 25 Apr '22

25 Apr '22

Hi all, a little heads up as it takes longer than expected. I'll start the PHP 8.1 update and the required rebuilds soon. I noticed some unexpected incompatibilities and I'd like to look into these first. I'll also evaluate if we could drop the php7 packages at the same time. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

7 28

[arch-dev-public] packager key revokation
by Andrzej Giniewicz 27 Jan '22

27 Jan '22

Hi all, my away time got longer than I expected (announced October 2020). Due to pandemic I still have no access to my Arch machine. I will get back access to it mid July, so this is not a resignation from my TU role! This notice is due to revocation of Bartłomiej Piotrowski's main key. Together with David Runge we decided, that best approach would be to remove my current key, and add a new one when I have access to my Arch machine. We will transfer the trust to a new key then. Hope to get back to packaging stuff soon, I have a lot of ideas I want to try and being stuck with Windows laptop from work is getting on my nerves. See you soon! Cheers, Andrzej Giniewicz (giniu).

4 3

[arch-dev-public] OpenSearch released to Community
by Justin Kromlinger 05 Jan '22

05 Jan '22

Hello everyone, As mentioned in a previous mail [0] I've taken some time to bring the ElasticSearch fork OpenSearch to Community [1]. I've also added twelve plugin packages, a package for the Kibana fork OpenSearch Dashboards and eight plugin packages for that. Additionally I packaged the opensearch-cli Go binary which currently conflicts with the opensearch package. More plugins will follow, but most of them can be installed manually as well (f.e. ingest-attachment). I've tested both opensearch and opensearch-dashboards with my old node data, but some plugins are untested because I have no experience with them (primarily the security plugin), so I would be happy if someone could test them out. Please note that opensearch doesn't use the upstream-included JRE and opensearch-dashboards doesn't use the upstream-included NodeJS but the ones provided by our repositories. Please keep that in mind for any bug reports towards upstream. This brings up the elastic-question: What should we do with the elasticsearch and kibana packages? If we keep them, someone would need to adopt them - I will orphan them since I won't be using them anymore. Do we want to update them to their newest version with the new Elastic license? Or drop them to the AUR? If we update them to a newer version the beats packages versions are complicated as well. The 7.X versions already need additional configuration in opensearch and versions >=7.13 won't work at all [2]. I would recommend new packages for the beats-oss version 7.12.1 or even 7.10.2 as recommended by opensearch. Euch einen guten Rutsch ins neue Jahr or a Happy New Year, hashworks [0] https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.ht… [1] https://archlinux.org/packages/?sort=&q=opensearch [2] https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/ -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

2 2

[arch-dev-public] RFC Final Comment Period: add an official mediation program to our organization
by Levente Polyak 27 Dec '21

27 Dec '21

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/9 Please visit the above link for discussion. Summary: Add an official mediation program to our organization consisting of elected mediators to help settle disputes and provide a clear escalation path. Best, Levente

1 0

[arch-dev-public] Fun with LTO and stripping
by Allan McRae 25 Dec '21

25 Dec '21

With the latest devtools, LTO is enabled by default. This causes an issue with .a and .o archived when stripping. Look out for output like: strip: ./usr/lib/st4RPjCb/libsyslog_ng_native_connector_a-native-grammar.o: plugin needed to handle lto object That file is now nicely mangled! Turns out this is a very well known issue in other distros, and has not been fixed in binutils since reported in 2017. There are a couple of workarounds: 1) disable LTO for that package 2) add -ffat-lto-objects to the C{,XX}FLAGS for those packages I can see how to fix this in makepkg, but that will take a few days to push out. In the meantime, pay attention to your build output! Cheers, Allan

6 7

[arch-dev-public] News draft: libxml2>=2.9.12-6 update may require manual intervention
by Jan Alexander Steffens (heftig) 24 Dec '21

24 Dec '21

The libxml2 package prior to version 2.9.12-6 was missing the compiled python modules. This has been fixed in 2.9.12-6, so the upgrade may need to overwrite any untracked pyc files created. If you get errors like these libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc exists in filesystem when updating, use pacman -Suy --overwrite /usr/lib/python3.10/site-packages/__pycache__/\* to perform the upgrade.

2 1

[arch-dev-public] community.files pacman database corrupt
by Pierre Schmitz 21 Dec '21

21 Dec '21

Hi all, Since Aug 30 07:17:11 CEST the "community.files" database (repos.archlinux.org/community/os/x86_64/community.files) seems to be corrupted. The package "ipguard-1.04-6" has an empty "desc" file. The "files" file has content though. Also the regular "community.db" file does seem fine. I also do not see that package being updated or moved. I did not try to regenerate the file yet to not make it harder to find the issue. Greetings, Pierre

4 5

[arch-dev-public] Arch monthly report December 2021
by Levente Polyak 21 Dec '21

21 Dec '21

## Report The pad for the next January 2022 report is available at [0]. ## Staff We are happy to welcome artafinde [1] among the Trusted Users. Additionally Segaja has applied [2] to become a Trusted User and the vote is currently in progress. ## mkinitcpio A new mkinitcpio version v31 has been released [3]. Besides various nice improvements the biggest highligh of this release is support for efi stub generation [4]. There is also a new wiki page for Unified kernel images [5]. ## Keyring The new keyringctl tooling has been finalized and merged. The next steps are to convert the keyring data using the new tooling to a curated source of truth. Additionally we have started to replace packager keys that were not meeting our latest strength requirements [6] and to ensure that each key has a dedicated @archlinux.org UID. The goal is that for packaging purpose we only sign @archlinux.org UIDs with the main keys but still allow web-of-trust cross-sigs issued from packager keys. ## Devtools A new devtools version 20211129 has been released [7]. The new devtools package is waiting in [staging] for the python 3.10 rebuild to finish in order to avoid additional hassle with an already cumbersome rebuild. LTO has additionally been enabled is this release as the issues should be easy to spot and extremely simple to work around by just setting an `options` knob inside the PKGBUILD. Once devtools has been moved out of [testing], a wide ranged rebuild is planned to make use of the new flags on a broad scale. ## Python The process to upgrade to Python 3.10 has started and we are currently rebuilding [8] all Python packages. Packagers are also actively working on removing Python 2 from the repositories. Packages used for development, like python2-virtualenv and python2-pip, was recently removed [9] and there is work under way to clear out rest of the python2 packages. ## archinstall A new archinstall version 2.3.0 has been released [10] with a lot of new functionality and improvements. Most notably it contains: * GRUB and Disk Encryption now properly works and supports multiple encrypted volumes. * BTRFS subvolumes *(beta only supports a nested structure [11] and has some known issues [12])* * A rudimentary plugin-support [13], allowing users to create their own plugins. * swap [14] has been added into the mix using zram [15] and zram-generator [16]. ## Reproducible Builds A new rebuilderd version has been released that supports build groups, meaning it's now possible to have one build reproduce multiple artifacts at once. This aids being able to check split packages more efficiently instead of building the whole group multiple times for every single split artifact. archlinux-repro has also had a new bugfix release [17]. [0] https://md.archlinux.org/Hu6IMKXCTLa9bv0yh-WCrg [1] https://lists.archlinux.org/pipermail/aur-general/2021-October/036617.html [2] https://lists.archlinux.org/pipermail/aur-general/2021-November/036672.html [3] https://github.com/archlinux/mkinitcpio/releases/tag/v31 [4] https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/ [5] https://wiki.archlinux.org/title/Unified_kernel_image [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/best-pract… [7] https://github.com/archlinux/devtools/releases/tag/20211129 [8] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030564.… [9] https://lists.archlinux.org/pipermail/arch-dev-public/2021-November/030555.… [10] https://gitlab.archlinux.org/archlinux/archinstall/-/tags/v2.3.0 [11] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Nested [12] https://github.com/archlinux/archinstall/issues/718 [13] https://github.com/archlinux/archinstall/blob/master/archinstall/lib/plugin… [14] https://wiki.archlinux.org/title/Swap [15] https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html [16] https://wiki.archlinux.org/title/Swap#zram-generator [17] https://github.com/archlinux/archlinux-repro/releases/tag/20211205

3 2

[arch-dev-public] Library dependencies
by Allan McRae 17 Dec '21

17 Dec '21

Hi all, I submitted a patchset to pacman that I would like some packager feed-back on. [1] Essentially this replaces the old libdepends/libprovides system into something akin to that used by APK. In short, makepkg.conf will have a variable like: LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32') At the end of package building, makepkg will look in the library directories and add a provide. E.g. for pacman: provide = lib:libalpm.so.13 Note the prefix matches the prefix given to the relevant directory in LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g. pacman may have: depends = lib:libgpgme.so.11 Note, to help with bootstrapping this system, or if packages just do not want to add libprovides, the depends entries are only added if a package actually provides them. This is different to the APK system for libraries which uses "so" as the prefix and is not configurable. But Alpine used musl, which has no concept of multilib, so we need to be a bit more flexible. Note the "lib" and "lib32" prefixes are just for discussion. Arch can configure how they want. The dependency/provides additions can all be disabled in pacman.conf with the '!autodeps' option. Note that APK has similar things for binaries and pkg-config files. e.g. provides = cmd:pacman provides = pc:libalpm These can now be readily be added as dropins to libmakepkg. Any opinions on this would be greatly appreciated. Is this a better system than the current one? Is adding automatic dependencies against the spirit of makepkg where everything is in the PKGBUILD? Thanks, Allan [1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps

3 6