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

[arch-dev-public] Orphaned packages from arcanis
by Morten Linderud 20 Dec '20

20 Dec '20

Yo! As a followup from the recent TU removal, I have composed a list of orphaned packages from arcanis. Please write back if you adopt anything else I'll drop packages into the AUR after some time has passed. As of now there are no package resigning that needs to be done. $ pkgsearch -m arcanis -l 1 | cleanup-list.py - Orphans required by maintained packages: - eric: arcanis: eric-i18n-en, eric-i18n-es, eric-i18n-de - g15daemon: idevolder: lcdproc - mftrace: arcanis: lilypond dvzrv: lilypond Unneeded orphans: canorus eric-i18n julius libasl libg15 libg15render libmatio libmmtf pdfsam pychecker pymol python-biopython python-pmw scala voxforge-am-julius Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

5 5

[arch-dev-public] Archweb migration
by Giancarlo Razzolini 18 Dec '20

18 Dec '20

Hi All, Continuing with the efforts to migrate each service to their own, separate VPS, we are now going to migrate archweb (our site). The tentative date for migration is tomorrow, 17, with a backup date this Friday, 18, around 6PM UTC. The site will be in maintenance mode and the service that updates the packages on archweb's database will be stopped on gemini. I expect the migration to last around 2 hours, but it might be faster than that. Also, we're changing the current redirection, which is to redirect anything to www.archlinux.org, to instead redirect anything to just archlinux.org. There's no rush to update any links, since we'll keep the redirections indefinitely. Regards, Giancarlo Razzolini

2 3

[arch-dev-public] New Archive Mirrors available
by Jelle van der Waa 18 Dec '20

18 Dec '20

Hi All, I am happy to announce that thanks to Kake/PIA sponsoring us dedicated servers, we now have three new Arch Linux Archive servers available at: https://america.archive.pkgbuild.com/ https://europe.archive.pkgbuild.com/ https://asia.archive.pkgbuild.com/ The servers have 3 x 9.1 TiB disks and have similar capacity to our canonical archive. Greetings, Jelle van der Waa

2 1

[arch-dev-public] away until next year
by David Runge 14 Dec '20

14 Dec '20

Hi all, from tomorrow on I'll be on holidays until early next year. While I will check my mails I won't necessarily be in places with good network connection. If anything comes up, feel free to bump my packages. I hope you all have a relaxing rest of the year. Stay healthy! Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Boost 1.74 Rebuilds
by Jelle van der Waa 07 Dec '20

07 Dec '20

Hi all, We've started the Boost rebuilds with automated builds in [staging], if required a todolist will be created for the failing builds. Please don't schedule any rebuilds which conflict with boost. Hopefully packages will arrive in [testing] before the end of the week :) Greetings, Jelle

2 2

[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