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

[arch-dev-public] Elastic stack packages have been replaced by OpenSearch
by Justin Kromlinger 08 Jan '22

08 Jan '22

Due to the licence change of Elasticsearch and Kibana from Apache 2.0 to SSPL [0] both packages have been stuck on the last Apache 2.0 version for a while. For this reason both have now been moved to the AUR and are replaced by OpenSearch and OpenSearch Dashboards in community [1]. Please refer to the official migration guide [2] and consider providing any insights on the ArchWiki page [3]. While the beats agents [4] are still on Apache 2.0 newer versions suffer compatibility issues [5] with ElasticSearch OSS and OpenSearch. Thus those have been moved to the AUR as well. Please note that the AUR packages are now orphans, feel free to adopt them. [0] https://www.elastic.co/pricing/faq/licensing [1] https://archlinux.org/packages/?sort=&q=opensearch [2] https://opensearch.org/docs/latest/upgrade-to/upgrade-to/ [3] https://wiki.archlinux.org/title/OpenSearch#Upgrading_from_Elasticsearch_OSS [4] https://github.com/elastic/beats [5] https://wiki.archlinux.org/title/OpenSearch#Compatibility_with_Beats_OSS -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

1 0

[arch-dev-public] RFC Final Comment Period: Rename the Trusted User role
by Konstantin Gizdov 05 Jan '22

05 Jan '22

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/7 Please visit the above link for discussion. Summary: It is shown in some cases that the Trusted User role naming leads to some confusion and misunderstanding in broader contexts outside Arch Linux. This RFC aims to remedy that with a better suited term to reflect more accurately upon TUs' roles and responsibilities as well as their position in the Arch Linux Organisation. -- Regards, Konstantin

1 0

[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

[arch-dev-public] Debug package support in dbscripts
by Jelle van der Waa 16 Dec '21

16 Dec '21

Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The original proposal from November last year can be found here: https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.… Cheers, Foxboron & Jelle

2 3