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

[arch-dev-public] [RFC] Debug packages and debuginfod
by Morten Linderud 01 Dec '20

01 Dec '20

Give me cake, or give me debug symbols. - Some comedian, probably. Yo! For quite a few years people has wanted debug packages, but there has never really been any progress towards them. Pacman got support almost 10 years ago, and Allan wrote a POC for dbscripts in 2015[1]. In recent years this has largely been a discussion how large such a repository would become, and how to distribute it. But since we don't have any numbers things have more or less stalled with things being discussed, but never worked on. Dropping an imaginary 100 GB on some poor mirror hosts doesn't seem quite right. However, things has been been progressing for the better when it comes to the distribution of debug symbols that can hopefully make this entire process easier for us. debuginfod has been introduced into elfutils which allows a standardized API for fetching remote debug symbols [2]. Eli and I have have been chatting a little with upstream since February to ensure we could get our package format supported. This was fairly straight forward with an example package from us and things have been working nicely. Patches in elfutils: https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=499129e77aa88b947… https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=0245c6ed65a80bceb… https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=ad09e791320d13149… We have been distributing debuginfod since 0.178-1 and debuginfod support came to gdb with the 10.1 release, which is why I'm picking up on this now :) We did some testing with the debuginfod support with Stapelberg during the summer, and it works fairly well [3]. Eli has also started writing up the support for splitting out the debug packages into a separate pool [4]. I have since merged some of Elis dbscripts patches to the POC git migration server to test things. The idea is to allow uploads of debug packages to repos.a.o into a separate package pool, have a public reachable debuginfod and then consider if we want/need debug package distribution. We can then check the new mirror requirements, and give a clear heads up to any potential mirror admin while providing debug packages. I think this is a reasonable compromise for everyone. OpenSUSE already has one such server as an example [5]. There isn't any one way we have to progress on this, but my proposed timeline is as follows: - Add a debuginfod role to the infrastructure repository. - Test and deploy the dbscripts support for debug packages. - Add support to devtools for uploading debug packages. - Announce debuginfod support. - Discuss how to distribute the packages. I anticipate we can start a new discussion for the last point as I think there is some issues we should think about in terms of archiving debug packages and so on. Is there any questions, concerns or suggestions for this proposed implementation? If anyone is interested trying out debug packages and debuginfod, on the POC git migration server, please do poke me! -- Morten Linderud PGP: 9C02FF419FECBE16 [1]: https://lists.archlinux.org/pipermail/arch-projects/2015-August/004301.html [2]: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-el… [3]: https://twitter.com/zekjur/status/1268626664814247939 [4]: https://github.com/eli-schwartz/dbscripts/commits/wip/debug [5]: https://debuginfod.opensuse.org/

2 2

[arch-dev-public] Add active Python versions to the repos
by Filipe Laíns 26 Nov '20

26 Nov '20

Hi all, I want to propose adding all active Python versions to [community], not just the latest one. This would only entail adding the interpreter itself, no other packages. Having access to interpreters for older active versions is really helpful for Python developers. This allows them to easily run test suites against older versions. It is very common for developers to maintain software against a couple major releases. Tools like tox or nox are able to automate testing against multiple Python versions, just needing the interpreter. The current active Python releases are: - 3.9 - 3.8 - 3.7 - 3.6 - 2.7 The list can be found here[1]. So, I propose introducing 2 new packages: - python3.7 - python3.6 And when we update the python package to 3.9: - python3.8 Does anyone have any big issue with this? What are your thoughts? [1] https://www.python.org/downloads/ Cheers, Filipe Laíns

9 22

[arch-dev-public] Python 3.9 enters the testing repos
by Evangelos Foutras 26 Nov '20

26 Nov '20

We'll probably want to keep it in testing for a week or two. Please don't add new Python packages during this time. Many thanks to everyone who helped with the build failures. 🥰

1 0

[arch-dev-public] Split openssl package
by Pierre Schmitz 22 Nov '20

22 Nov '20

Hi all, there is a new set of openssl packages in testing that are split into openssl, openssl-doc and openssl-perl. See https://bugs.archlinux.org/task/54887 As most users just need the library the perl dependency can be dropped. Summing up: Before: openssl: depends on Perl; size: 3.6 MiB (7.31 MiB) After: openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB) openssl-perl: depends on Perl openssl-doc: size: 1.82 MiB We actually talked about this at ArchConf last year. Splitting the package was the easy part, but dropping the Perl dependency means that any package up the tree that depends on openssl needs to be checked if it actually needs Perl itself. Thanks to everybody who did the hard work here! PS: Do you think we should post a news item about this change? Most people won't need to worry about this, but those few who need the perl scripts need to install the separate package. Greetings, Pierre

2 3

Re: [arch-dev-public] Add active Python versions to the repos
by Filipe Laíns 21 Nov '20

21 Nov '20

On Sat, 2020-11-21 at 07:51 -0700, Zach Himsel wrote: > What would determine what the "default" python be? The latest? > > > -- > Zach Himsel > mailto://zach@himsel.net > http://zach.himsel.net Yep, that would stay exactly as it is right now. We would only additionally provide interpreters (and interpreters only!) for the older Python versions. Cheers, Filipe Laíns

1 0

[arch-dev-public] [xorg-server] from testing repo may need manual intervention
by Andreas Radke 19 Nov '20

19 Nov '20

We've started to build xorg-server packages form stable git branch again to pull pending bug fixes and an uncertain release date. A minor git package version numbering issue may prevent automatic future updates. In case you have already installed version 1.20.9+21+g5c400cae1-1 from testing repo today please run pacman -Syuu to receive a fixed version 1.20.9.r21.g5c400cae1-2. -Andy

1 0

[arch-dev-public] Python 3.9 rebuilds
by Evangelos Foutras 15 Nov '20

15 Nov '20

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.9. Please avoid adding new Python packages and starting other rebuilds during this time. Some PKGBUILDs were modified in /trunk to use the Python 3.9 site-packages path (among other tweaks). Building those against Python 3.8 might fail or produce incorrect packages. The affected packages are listed in the following two commits and care should be taken when updating them while the Python rebuild is ongoing. https://lists.archlinux.org/pipermail/arch-commits/2020-November/843783.html https://lists.archlinux.org/pipermail/arch-commits/2020-November/843784.html

2 2

[arch-dev-public] [signoff] [extra] postfix-3.5.8-1
by David Runge 11 Nov '20

11 Nov '20

Hi all! I recently upgraded the postfix package and made quite a few adjustments (e.g. using tmpfiles.d instead of a 1000 line POSIX shell script, splitting shared libraries and applying mild hardening on the postfix.service). As for many setups postfix is probably rather mission-critical it would be excellent to get some signoffs on it. Specifically it would be good to test setups in which postfix is not handling virtual mailbox setups, but is using unix user setups (due to the changes introduced to the service file). Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Pam lockout
by Tobias Powalowski 06 Nov '20

06 Nov '20

Hi guys, https://bugs.archlinux.org/task/67644 I second Levente's post of it's a configuration issue that needs to be addressed by user and not by the package itself. Typing 3 times wrong password is a sane default imho. Any other opinions out there? Thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 6

[arch-dev-public] Orion retirement
by Jelle van der Waa 02 Nov '20

02 Nov '20

Hi All, Our dedicated server orion (used to host repos.archlinux.org/mail.archlinux.org) has been cancelled which means it will be no longer accessible in 30 days. If you have anything of value in your home directory, please copy it before the 10th of November as then the server will be completely wiped. As the DNS entry is already gone you'll need to login into 88.198.91.70 We do have backups of this server, but do not wish to query them on demand if not required :) Greetings, Jelle

1 0