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

[arch-dev-public] Update to asciidoc 10.x
by Caleb Maclennan 17 Jan '22

17 Jan '22

The update from asciidoc 9.x to 10.x has been a long standing fiasco. The initial release had quite a few bugs that completely blocked our usage and (as is the case for many Python projects) packaging has gotten harder as upstream tooling is less distro friendly. After an upstream minor release and several patch releases most of the major issues are resolved and I've cobbled together packaging that works. It has been in the [community-testing] repository for a while now and has a couple signoffs. I've also mentioned some of the differences in IRC, but I thought I would give a warning here — I'm about to move it to [community]. Many Arch packages have asciidoc as a makedepends=(). Most of these do not require it as a library and thus the API changes in 10.x will not be relevant, but they do use the CLI script for converting documentation to man pages. One of the major changes in 10.x relevant to other Arch packages is that these CLI scripts /usr/bin/{a2x,asciidoc}.py are no longer distributed with the .py extension, they are just plain /usr/bin/{a2x,asciidoc}. Many upstream projects have adopted this already, but there may be some that have not and will need patching. If you do run into trouble building anything, that is the most likely culprit and the first thing to search for and patch out of upstream code. Caleb

1 0

[arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
by David Runge 15 Jan '22

15 Jan '22

Hi all, in the past days there have been a few releases of our archlinux-keyring package, which contains the root trust of our distribution. We have successfully switched to using keyringctl [1] to manage the keyring. From now on all changes to the keyring are done via merge requests towards the archlinux-keyring repository, as it now serves as the source of truth, whereas in the past we have been relying on the dying SKS infrastructure or the Ubuntu keyserver (which may or may not support all key types in use). I have contacted all of you over the past months and either requested the addition of an @archlinux.org UID, the creation of a new PGP keypair or the verification of your PGP key by means of a clearsigned token. To all that have added a new @archlinux.org UID or have created a new key, please make sure that all signatures you have received from main signing keys are also present in the current keyring (`pacman-key --list-sigs <nick>@archlinux.org`) or in the current HEAD of archlinux-keyring (`./keyringctl inspect <nick>` in a clone of the archlinux-keyring repository). If you have signatures that are not yet in the keyring, you can add them yourself [2] and do not have to wait on a main signing key holder to do it. To all that have created a new key, please make sure to setup the correct PGP key ID in your archweb profile so that the website displays the signatures correctly [3]. If you have gained more than or equal to three main key signatures for your new PGP key and the key as well as those signatures are already available in the keyring in [core] please rebuild all of your packages using your new key and start the process of having your old key removed [4]. For the purpose of mass package rebuilding you may create a TODO [5] and use `rebuild-todo` (in the archlinux-contrib package) which makes use of our build server infrastructure. I have not yet gotten a response from or have not yet been able to resolve my request with the following packagers (nickname in the archlinux-keyring repository): - bgyorgy - archange - arodseth - kylekeen - daurnimator - pierre - farseerfc Please make some time to create a new key/ UID/ or get signed, as Allan would like to revoke his signing key in the near future (which may mean the inability to sign packages and mass rebuild of packages in question) as soon as the above packager signature situation has stabilized. In case you have questions, feel free to reach out in #archlinux-staff on libera.chat or via mail. If you are interested in helping further develop keyringctl, have a look at the relevant open tickets [6]. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/#usage [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [3] https://archlinux.org/master-keys/#master-sigs [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/… [5] https://archlinux.org/todo/add/ [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues?scope=all… -- https://sleepmap.de

4 5

[arch-dev-public] Arch Linux in December 2021
by Levente Polyak 09 Jan '22

09 Jan '22

## Staff We are happy to welcome Segaja among the Trusted Users [0]. ## Monthly Report We have switched the format of the monthly report to specifically report the progress of the whole previous month. ## Debug packages The dbscripts repository handling for debug packages has successfully been merged [1] and deployed. Successive integration has been submitted to devtools [2] as well as pacman improvements related to PKGINFO [3] and debugedit [4][5]. ## Keyring As the last step of migrating our keyring to a new tooling and a local source of truth we have re-boostrapped the trust with an initial import of the old trust data into the new curated data structure [6]. We are still inviting people to look at the current trust data and cross verify the results. ## pacman A new library dependency feature has been submitted to makepkg [7]. At the end of package building, makepkg will look in the library directories and auto add a library provide that packages can auto depend on. Patches were submitted to alternatively choose asignify for package signatures [8] while keeping gnupg as default in place. ## LTO With the availability of the latest devtools release a lot of freshly updated packages were built with LTO. We have encountered different set of issues that needed to be tackled. Some language specific problems have popped up including but not limited to Go and Rust that require some documentation and adjustments. ## ArchWiki After being broken for almost four months, ArchWiki is once again readable on small screens. [0] https://www.mail-archive.com/aur-general@lists.archlinux.org/msg00635.html [1] https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 [2] https://github.com/archlinux/devtools/pull/78 [3] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025464.html [4] https://sourceware.org/debugedit/ [5] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025471.html [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring [7] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030582.… [8] https://lists.archlinux.org/pipermail/pacman-dev/2022-January/025439.html

1 0

[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