Arch-dev-public December 2020

arch-dev-public@lists.archlinux.org

8 participants
14 discussions

[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 15 Dec '20

15 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

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public December 2020