February 2022 - 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] 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] 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

[arch-dev-public] removed mariadb from testing
by Christian Hesse 10 Feb '22

10 Feb '22

Hello everybody, a problem has been found in MariaDB 10.6.6 and upstream decided to withdraw the release. We do the same, just removed mariadb (and galera) packages from testing. https://jira.mariadb.org/browse/MDEV-27789 -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

[arch-dev-public] On the toolchain current status
by Giancarlo Razzolini 09 Feb '22

09 Feb '22

Hi All, Most of you are aware that our toolchain is currently outdated. We always had very few people working on it through the years and I took over once Barth left, because it was needed. However, I have been having very little time to work on Arch related stuff lately and the toolchain is the most noticeable victim, given it is one of the most time consuming. In this meantime, a few things also happened that compounded to the issue, among them, we enabled LTO. Right now I'm working on bringing new glibc 2.35 and also waiting on binutils release so we can bring the toolchain up to date. I'm aware we also have a GCC release coming out soon, and the toolchain will need a new rebuild then. For the future, we are trying to bring more people to work with the whole toolchain, so it is not too much of a bus factor. We should have at least two toolchain maintainers, not just one. I hope this serves to assuage the concerns over the current status of our toolchain, both present and going future. Regards, Giancarlo Razzolini

2 1