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

[arch-dev-public] Arch Linux in February 2022
by Levente Polyak 08 Mar '22

08 Mar '22

## Staff sudoforge has applied [0] to become a Trusted User and the vote is currently in progress. On top we would like to welcome freswa and Foxboron to their new additional duties as Arch Linux Developers. Furthermore we have onboarded the project maintainers Torxed (archinstall) and kevr (aurweb) as Arch Linux support staff. Last but not least we held our bi-yearly Arch Linux Project Leader election where Levente Polyák was re-elected [1]. Further details about future plans, priorities and discussed topics will be posted to our arch-dev-public mailinglist. ## Aurweb With the v6.0.0 release [2], aurweb now runs on Python using the Starlette/FastAPI framework. A complete list of changes from v6.0.0 up to the current patch (v6.0.6) can be viewed at gitlab [3]. Regarding there have been some modifications to the RPC API endpoints which have broken some clients in AUR helpers. ## Toolchain A new toolchain has been released to our stable repositories including gcc 11.2.0, binutils 2.38 and glibc 2.35. Frederik has joined forces with Giancarlo as an additional toolchain maintainer and helps to reduce the workload. ## archlinux-keyring Giancarlo Razzolini has been added as a new main key holder [4] and will provide trust to our packaging keys by verifying and signing them. [0] https://lists.archlinux.org/pipermail/aur-general/2022-January/036781.html [1] https://archlinux.org/news/arch-linux-leader-election-results/ [2] https://lists.archlinux.org/pipermail/aur-general/2022-February/036786.html [3] https://gitlab.archlinux.org/archlinux/aurweb/-/tags [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/commit/bae4859fd…

1 0

[arch-dev-public] News draft: Keycloak 17.0.0-3 update requires manual reconfiguration
by Leonidas Spyropoulos 07 Mar '22

07 Mar '22

The `keycloak` package prior to version 17.0.0-3 was running with WildFly server. Since upstream moved to Quarkus, Arch Linux follows this approach. This means current configurations need to be migrated. The new config location needs to be adjusted from the old `.xml` format to the new `.conf` ``` /etc/keycloak/keycloak.conf ``` The new $HOME of Keycloak is in `/usr/share/java/keycloak` See Keycloak [migration docs](https://www.keycloak.org/migration/migrating-to-quarkus) and Keycloak Quarkus [server docs](https://www.keycloak.org/server/configuration) -- Leonidas Spyropoulos PGP: 59E43E106B247368

1 1

[arch-dev-public] Moving base-devel dependencies to [core]
by Allan McRae 04 Mar '22

04 Mar '22

Hi all, I notice when using devtools, the following packages from [extra] get pulled into our clean build root: extra/gc extra/guile extra/libcroco extra/libsysprof-capture extra/libxml2 These are all dependencies of base-devel packages. I'd like to move them to [core] so they are captured by the signoff process. Thank you for your lack of objection. :) Allan

2 3

[arch-dev-public] Away for most of March
by David Runge 03 Mar '22

03 Mar '22

Hi all, I'll be away for most of March and beginning of April. I still have time sporadically over the next week but will likely not be available for packaging or other things afterwards until the beginning of April. Feel free to upgrade packages that are out-of-date while I'm away. Best, David -- https://sleepmap.de

1 0

[arch-dev-public] RFC: Store PGP keys for source file signatures in SVN
by Allan McRae 02 Mar '22

02 Mar '22

A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11 Please visit the above link for discussion. Summary: Store the PGP signing keys listed in a PKGBUILDs `validpgpkeys` array in the trunk directory of SVN. Motivation: The PGP keyserver infrastructure has become increasingly brittle over recent years. This can make helping with updates or rebuilds of packages difficult due to lack of access to the valid signing key. Having the signing key exported along side the PKGBUILD would allow for anybody to import the key into their keyring and verify the source.

1 0

[arch-dev-public] Urgent reminder about packager PGP keys and packages
by David Runge 24 Feb '22

24 Feb '22

Hi all, as mentioned mid January [1] we are currently en-route to deprecating Allan's main signing key [2]. For this purpose I have added 11 rebuild TODOs for packages signed by packager keys that have been superseded by newer ones (and should then also be removed). These packages need to be rebuilt using the new packager key (or any other valid packager key, that is not explicitly mentioned in any of the TODOs), as they block the removal of Allan's main signing key. You can do so with the help of rebuild-todo (which is part of archlinux-contrib). Have a look at its help output for all available options. Please also make sure to setup your current PGP key ID in your archweb profile, so that the information on the website [3] is correct and up-to-date. The following packagers have not yet created a new key and block the effort towards deprecating Allan's signing key as well: - bgyorgy (CE0BDE71A759A87F23F0F7D8B61DBCE10901C163) - archange (69DA34D78FE0EFD596AC6D049D893EC4DAAF9129) - arodseth (962855F072C7A01846405864FCF3C8CB5CF9C8D4) - kylekeen (48C3B1F30DDD0FE67E516D16396E3E25BAB142C1) - farseerfc (4B1DE545A801D4549BFD3FEF90CB3D62C13D4796) Please make sure to create new packager keys, have them signed by at least three main signing keys and rebuild all packages signed by the old packager key until the beginning of April. After that we will start mass-rebuilds of the remaining packages in question and commence with the revocation of Allan's key (which means that the above packager keys can not be used for packaging anymore) unless other blockers come up. If you have questions, please reach out via e-mail, or in #archlinux-staff on libera.chat. Best, David [1] https://lists.archlinux.org/pipermail/arch-dev-public/2022-January/030617.h… [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/148 [3] https://archlinux.org/master-keys/ -- https://sleepmap.de

1 0

[arch-dev-public] Looking for co-maintainers for AWS-related packages
by Chih-Hsuan Yen 20 Feb '22

20 Feb '22

Hi all, Recently I have less and less spare time, and keeping packages related to the AWS ecosystem becomes harder as AWS is a fast moving target. I'm looking forward to co-maintainers for the following packages: python-aiobotocore python-aws-sam-translator python-aws-xray-sdk python-cfn-lint python-moto python-pynamodb Below are my packages used by packages above. Feel free to also adopt them: python-aioitertools (dependency of python-aiobotocore) python-django-fake-model (dependency of python-aws-xray-sdk) python-jschema-to-python (dependency of python-cfn-lint) python-jsondiff (dependency of python-moto) python-junit-xml (dependency of python-cfn-lint) python-nose-random (dependency of python-jsondiff) python-pg8000 (dependency of python-testing.postgresql, python-aws-xray-sdk) python-pytest-env (dependency of python-aws-sam-translator and python-pynamodb) python-sarif-om (dependency of python-cfn-lint) python-scramp (dependency of python-pg8000) python-sshpubkeys (dependency of python-moto) python-sure (dependency of python-moto) python-testing.common.database (dependency of python-testing.postgresql) python-testing.postgresql (dependency of python-aws-xray-sdk) Please reply or ping me on IRC if you adopted something, thanks! Cheers, Chih-Hsuan Yen

1 0

[arch-dev-public] Python packaging future (PEP 517 & removal of setup.py calls)
by Filipe Laíns 19 Feb '22

19 Feb '22

Hi all, As some of you might know, the Python packaging ecosystem is changing. If you have noticed a lack of setup.py or its replacement with pyproject.toml then you already ran into issues I want to discuss today. I will a bit in-depth when explaining the motivation and current state of affairs, feel free to jump directly to the "What should we do?" and "Usage summary" sections if you do not care about that. What is happening? Up until now, the de-facto build system for Python has been setuptools. This forced setuptools to try and meet every single need from users. If you are unlucky enough to need something too different, well, you are out of luck. Your options are to try to hack around by adding custom handling to your setup.py or simply to create your own tooling. To prevent this, PEP 517[1] and PEP 518[2] were proposed. PEP 517 and 518 standardize the use of different backends. PEP 517 defines a standard interface for build tools to call the backends (AKA build hooks) and PEP 518 a way for users to declare which backend to use, in a new pyproject.toml file. TL;DR: PEP 518 introduces a pyproject.toml file where people can define the backend entrypoint and requirements [3] and PEP 517 defines the interface hooks for build tools to be able to interact with them [4]. Some extra info that might be relevant: PEP 517 suggests that build tools default to the setuptools.build_meta:__legacy__ backend if no backend is specified, making them compatible with projects that have not moved to pyproject.toml. setuptools.build_meta:__legacy__ will essentially call the same setuptools hooks as invoking setup.py directly. There are several resources available that explain this much better, please have a look at them if you need a better/more in-depth explanation. I am also available for questions if anyone is having trouble understanding how all this works, I understand it's very involved :P What are the current issues? The more pressing issue is that some project are already adopting this scheme, and our current `setup.py build && setup.py install` approach is simply not compatible. There is also the issue that `setup.py install` is deprecated, and will be removed soon. We have had very extensive conversations with the setuptools upstream about this. See [5] and [6]. The available tooling PEP 517 does not support direct installs, which is what we currently via `setup.py install`. Instead it allows us to build a wheel (a Python binary package file), which we can then install to the system. So the solution is to use PEP 517 to build a wheel file for the package, and then install that file to $pkgdir. For the building step, I have written python-build[7] which provides a Python API and a CLI tool to access the PEP 517 build hooks. The project is under the Python Packaging Authority (PyPA)[8] umbrella. For the install step, there is pradyunsg/installer[9] which provides a Python API to develop Python installers, and a CLI with a simple install tool. The project is currently in the process of being moved under the Python Packaging Authority (PyPA)[8] umbrella[10]. Our current approach For project that have adopted PEP 517, in most of the cases we use dephell. dephell is a tool that reads the metadata from pyproject.toml and generates a setup.py file. For setuptools this approach is okay, it's a direct translation, which is simple enough, but there are several other backends that are starting to being used (flit, poetry, etc.). When this different backends are used, dephell tries to translate their metadata to setuptools metadata to write to setup.py. I don't think this approach is sound, it's just a hack IMO. With things evolving, the backends will introduce quirks, or completely new features not available in setuptools. This is actually happening right now, we have at least one backend in the repos that is so simply not compatible with setuptools and the dephell approach is not an option, maturin[11]. In this case we rely on maturin providing a front end (CLI) to build the wheel file. What should we do? 1) Adopt python-build/python-installer for PEP 517 projects The Python packaging guidelines have already been updated to replace the dephell approach with the new standard tooling. I'd also like to see projects like maturin being built this way, instead of using their custom CLI tool, but that is not very pressing right now. 2) Drop setup.py install in favor of python-build and python-installer We should really move a way from setup.py calls. There are several reasons for this, the main one being that direct setup.py calls are deprecated. They don't issue a deprecation warning because of technical difficulties and lack of maintainer time. Other reason is that setup.py install will generate old-style basically undocumented, or implementation-driven, Python metadata, also known as "eggs". By moving to wheels, we will be installing proper standardized metadata (.dist- info) instead of egg metadata (.egg-info). I have filled RFC 10 [12] with a formal proposal for this, as it is a fairly big change. Feel free to give feedback there. Usage summary By default, python-build will build the package in a isolated environment, as recommended by PEP 517. We don't want this behavior in our packaging so we should disable it with the --no-isolation/-n flag. By default, it will also build a source distribution (sdist), basically a release tarball, and then use it to build a wheel file, which we probably want to avoid, thus we should pass the --wheel/-w flag too. $ python -m build --wheel --no-isolation or $ python -m build -wn This will generate a wheel in dist/. Build backends can also take arguments, they can be passed with --config-setting/-C arguments. You can find out more about the python-build CLI here[13]. After that, we will want to install the wheel file into $pkgdir. That can be done by running python-installer with the --destdir/-d argument. By default, it will compile the Python bytecode for the 0 and 1 levels, matching our old behavior, so we don't need to pass any extra flag. $ python -m installer --destdir="$pkgdir" dist/*.whl or $ python -m installer -d="$pkgdir" dist/*.whl Please also check the Python packaging guidelines[14], which should be up-to- date with the new workflow. Thank you for hanging out until the end! Feel free to ping me on IRC or by email if you have any questions. [1] https://www.python.org/dev/peps/pep-0517/ [2] https://www.python.org/dev/peps/pep-0518/ [3] https://www.python.org/dev/peps/pep-0517/#source-trees [4] https://www.python.org/dev/peps/pep-0517/#build-backend-interface [5] https://github.com/pypa/setuptools/pull/2080 [6] https://github.com/pypa/setuptools/issues/2088 [7] https://github.com/FFY00/python-build [8] https://github.com/pypa/ [9] https://github.com/pradyunsg/installer [10] https://discuss.python.org/t/moving-installer-under-the-pypa-umbrella/13778 [11] https://www.archlinux.org/packages/community/x86_64/maturin/ [12] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/10 [13] https://python-build.readthedocs.io/en/latest/ [14] https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_… Cheers, Filipe Laíns

2 1

[arch-dev-public] Bi-weekly arch-repo-management meeting
by David Runge 16 Feb '22

16 Feb '22

Hi all, as announced on arch-dev-public, we would like to do bi-weekly meetings for arch-repo-management [1]. I misjudged the (current) use-case for the arch-projects mailing list though and therefore am doing the meeting announcement here. I will send another mail to discuss the current/future scope of the arch-projects mailing list. The next meeting takes place on Jitsi on 2022-02-16 at 19:00 CET (UTC+01:00): https://meet.jit.si/20220216-arch-repo-management An ics file for calendar software is attached to this mail. Best, David [1] https://lists.archlinux.org/pipermail/arch-dev-public/2022-February/030711.… -- https://sleepmap.de

2 1

[arch-dev-public] Do not release packages built against [testing] to stable repos
by Allan McRae 11 Feb '22

11 Feb '22

Hi all, Just a reminder with the toolchain in [testing] that you need to be careful when building packages for the stable repos. If you build the package using the [testing] toolchain and release it to [extra] or [community] it will fail to run with errors like: /usr/lib/libc.so.6: version `GLIBC_2.34' not found Either build the package against [testing] and leave it in [testing] until the toolchain moves, or build against the stable repos. Allan

1 0