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

[arch-dev-public] News draft: Bug wrangling day
by Frederik Schwan 06 Sep '20

06 Sep '20

Hi people, given the large amount of open bugs, I'd like to invite all users to help out with an official announcement. ----> Kill Arch Bugs: Help us on the 13th of September! We would like to hold a bug wrangling day on the 13th of September to reduce the large amount of open tickets. If you cannot take part in the bug wrangling day, then feel free to help us any time before that event. How? Please review all bugs that were reported by you and check if they are still valid. Please request a task closure on the bug tracker if the task may be closed. Otherwise please provide further information so that we can continue to work on the bug. We cannot fix bugs without your feedback. Questions? Join us at #archlinux-bugs channel on irc.freenode.net during 13th of September. As we life in different timezones not all devs and bug wranglers will be available at the same time, but feel free to report your issues to any dev available. Also please check your mailboxes that may contain notifications about comments made on your tickets <---- Parts of this news are derived from this post: https://bbs.archlinux.org/viewtopic.php?id=31568 Cheers, Frederik

2 1

[arch-dev-public] Bug tracker migration
by Frederik Schwan 30 Aug '20

30 Aug '20

Hi folks, I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab instance. TLDR: - Bug wrangling day on the 13th of September; see 1) - Flyspray will be read-only after we rewrite the Archweb URLs - new bug tracker -> Gitlab 1) I'd like to hold a bug wrangling day, where our goal is to close as many bugs as possible. Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately I can't offer any cookies that day :/ Rules: a) Bug with no reply for at least 6 months which has been submitted for a different version than the current one in the repos shall be closed with a message that a reopen request may be filled if this issue is still present. b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps. 2) Afterwards we will point the bug tracker links in the Archweb to the new location and opening new tickets in Flyspray will be disabled. The project structure of the future Gitlab bug tracker will be discussed in a seperate mail and is not part of this mail(thread). 3) When enough tickets are closed or when $DevOps is tired enough of Flyspray, we'll migrate the rest of the tickets to Gitlab. We seek to keep Flyspray as a static homepage to allow the reference in the new bug tracker to old tickets and to keep the integrity of search engine results. Please make sure you all have a working account at our Gitlab instance. Cheers, Frederik

5 7

[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
by Evangelos Foutras 25 Aug '20

25 Aug '20

I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after significant refactoring. What are your thoughts on dropping all these seemingly unnecessary lines from our official PKGBUILDs? Anyone feel strongly about keeping them (and why)?

5 5

[arch-dev-public] Ciao
by Gaetan Bisson 20 Aug '20

20 Aug '20

Dear all, I've joined the Arch team in 2010 and spent a decade as a developer; it's been a great privilege to be a part of such an awesome community and also a lot of fun. However I felt the ten-year mark was a good opportunity for me to move on since I recognize the majority's views on the future of the distro have of late steadily been diverging from mine. And thus I hereby resign my position of Arch Linux Developer. All the best in your future endeavors! -- Gaetan

3 3

[arch-dev-public] Holidays 2020-08-20 -- 2020-09-01
by David Runge 18 Aug '20

18 Aug '20

Hey all, I will be on holidays between 2020-08-20 and 2020-09-01 and very likely not be able to do packaging. Feel free to bump my packages. Note, that audacity would require a lot of work.. so only get on to that one if you're really up for it :-P Juce is another such candidate (but also because it currently makes the build for iempluginsuite fail). Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Mail server migration
by Giancarlo Razzolini 14 Aug '20

14 Aug '20

Hi Guys, Continuing with our migration efforts, we're now going to migrate the last running service on orion which is the mail server and all the software related to it. This is also getting migrated to a VPS [0]. We plan on making this as transparent as possible, so all the mailboxes, sieve filters and .forward files and anything else mail related will be copied from the home directions each user has on orion. We also plan on syncing /etc/shadow, to make sure all the passwords remain the same. However, the SSH Host keys will also be changed on the process. These keys will be documented beforehand on [1] as well as sent to this thread. SSH access will only be used for password changing and for putting/editing .forward files and/or sieve filters. Eventually the mail server will not support SSH access anymore, as we plan on transitioning authentication to keycloak in the future. But for foreseeable future, things won't change. Also, with this change, since mail is the last thing on orion, that machine will be decommissioned. So, please, everyone make sure that you don't have anything on your home directory that you wish to keep. We'll take a backup, but the only things getting moved to the new mail server are mail related files. There's no date yet for both the migration and for orion's decommissioning, but the mail migration will happen next week, and orion's decommission following that and provided the mail migration is successful. There will be a period of time where the pop and imap services will be unavailable, as well as sending emails. We plan on not disrupting the incoming of emails, and I'll sync the queue between the machines, to avoid any lost email, while the DNS records are changing. Regards, Giancarlo Razzolini [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/92 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ss…

1 0

[arch-dev-public] Anatol is inactive due to situation in Belarus
by Anatol Pomozov 14 Aug '20

14 Aug '20

Hello folks My name is Anatol Pomozov and I am an Arch Linux developer. I've been quiet for a couple of weeks now and will probably stay away from my Arch Linux/pacman (+bcc:pacman-dev@) duties for a bit more. Please feel free to take care of my packages if it's needed. The reason for this decision is a situation that happens in my home country. I am a belarusian. My home country, my beautiful Belarus is essentially taken hostage by a usurpator Lukashenko. He has been "ruling" the country for 26 years already. Lukashenko cancelled results of the last election (where he took ~10% of votes) and declared that he is going to stay in power for another 5 years. All his political opponents were put into a jail or hiding from him abroad. Anyone who demands fair elections is terrorized by his personal army. Many people are tortured in jail. You can see what happens in Belarus in these clips https://www.youtube.com/watch?v=XG3D6881AXY https://www.youtube.com/watch?v=-6tCGnM0xiQ https://www.youtube.com/watch?v=E0VLjQvCxcc I live abroad and I am safe now. But my parents and relatives are in Belarus and they were essentially taken hostage by the Lukashenko's government. The last few weeks were stressful for me and I want to focus on my extended family as much as possible. I understand that Arch maillist might not be the place for political statements but this is something personal and something important for me. There is no place for such violence and there is no place for dictators in Europe of the 21st century. Please support Belarusian people in their fight against the usurpator. Talk to your governor/mayor/deputy/..., ask them to contact Belarusian government to stop the violence. Talk to the press, explain to them what is going on in Belarus right now. Anything that brings peace to Belarus will be helpful. Thank you. Жыве Беларусь!

2 1

[arch-dev-public] Online Arch Linux Conference
by Morten Linderud 11 Aug '20

11 Aug '20

Yo! Because of COVID-19 I assume most people have had some conference plans cancelled this year. FroSCon has had an Arch Linux devroom the past years, but as we are not meeting physically I guess that isn't happening either. Thus I want to try rally some people and have an online Arch Linux conference/devroom. There are not any major ambitions really. This can be a few hours an evening, or a weekend event. We will see what we figure out :) # Ideas Some of the ideas I have had so far is as roughly: * Team Q&A * Talks/presentations * team member and the wider community * Interactive streams * See how packagers do their work? * Arch Linux installation speedruns(?) * Workshops? Feel free to email me offlist, or poke me on other platforms, if you have other great ideas that could work! # Organization To organize we would need some help and might need some roles filled. This is a shortlist of the ones I can come up with. But I'm sure there are more tasks and roles needed: * Art-work/graphics * Help figuring out streaming * Planning and handling CFP There is no requirement to be on the Arch team to contribute. If you think you have anything to contribute, please do come talk with me! Need every help one can get :) # Meeting Below is a suggested meeting date for interested parties to attend. I'm unsure if it's going to be mumble or purely text based. Date of meeting: 4th of August 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 IRC: #archlinux-conf @ freenode Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16

1 3

[arch-dev-public] Use detached package signatures by default
by Anatol Pomozov 10 Aug '20

10 Aug '20

TLDR; let’s start using detached package signatures to make system updates faster. Hi folks, Some time ago there was a discussion at IRC where someone (Allan maybe?) proposed to stop using embedded PGP signatures in favor of detached signature files. I would like to bring this idea here and quantify it with some numbers. Here is a bit of technical details on this topic. Pacman has the ability to verify authenticity of package files with PGP signatures. PGP signatures add protection against undesired package modifications by a third-party and it improves security aspects of the package management. This feature can be configured per repository and the official Arch Linux repos have it enabled. Package signatures have been used by Arch Linux successfully for a couple of years now. Package signatures are stored as a part of a pacman database file (it is called “embedded signatures”). One issue with embedded signatures is that they represent a quite large chunk of database file. What is worse, a PGP signature is high-entropy data and does not compress well. I was mildly shocked to learn how much of the *.db files signatures consume. I ran experiments and repackaged extra, community databases without PGP data. For uncompressed “extra” repository size drops to 83% of its original size (though uncompressed size is not that interesting). Arch uses GZIP compressed database and in this case removing signatures reduces the “extra” database to 36.8% of its original size. To emphasize it one more time - removing PGP signatures makes this repo only 1/3 of its original size. The change is even more dramatic in case of “zstd -19” compression where the final database file is only 31% of its original size. For community.db the numbers are: uncompressed file gets 79.8% of its original size, “gzip -9” gets 33.4%, and with “zstd -19” it gets 27.51% of its original size. A database gets modified with every package update. Users need to re-download the databases where 2/3 of it are package signatures that are used only when a specific package is installed. An alternative to embedded signatures are detached signatures. These are signatures stored in a separate file next to the package itself (in a <pkg>.sig file to be specific). Instead of downloading *all* signatures every time a database is updated, detached signatures are downloaded only when a specific package is installed/updated. If Arch could switch to this model then database files become 3 times smaller that saves users bandwidth and system update time. I looked through pacman code and most components have detached signatures support already. Most of the places have a logic like this: if(pkg->embedded_sig) { use(pkg->embedded_sig) } else { sig = load_detached_sig(pkg) use(sig) } I found only 2 places where pacman does not fallback to a detached signature: 1) Keyring key check. Pacman was using embedded signatures only. This has been fixed in pacman’s commit b01bcc7d3d680 and it will be available in pacman version 6.x 2) dump_pkg_full() that dump package information. If a package uses detached signatures only then it prints “None”. I think this is fine as this function displays database entries and it does not affect the package verification process. I disabled the embedded signatures at my testing machine to use detached signatures only and things look great so far. ‘pacman --debug’ confirms that detached signatures are correctly downloaded and used to verify the package content. Given this information I would like to propose to stop using embedded signatures and move to detached signatures by default. This will require pacman 6.x or as alternative backport the fix(es) to 5.x branch. It will help to make system updates even faster, something that me and many other Arch users really love.

5 7

[arch-dev-public] Stepping down from DevOps
by Florian Pritz 01 Aug '20

01 Aug '20

Hi, As you have probably noticed, my involvement in DevOps tasks has dwindled in recent months. I have given away a few tasks to others already, but since I hardly use my root access any more, I think it is finally time to officially open up the spot and let someone else take over. Back when we started the DevOps team nearly 5 years ago (good god, time flies), Allan asked me if I wanted to lead the "infrastructure team" (old name). I am glad that I have never needed to use the team leader hat since we could discuss pretty much every problem and reach an agreement. Given that things have worked so well in the past, I'm inclined to simply discontinue the (unused) team leader hat. Considering how little, well, actually not at all, I have used the hat, most people are probably not even aware of it, so this feel like the most logical choice. I think having a core team of active people that discuss the issues and then come to an agreement has worked well in the past and it is something worth keeping. I'm still amazed by what you guys accomplished over the last year and I hope that making space and letting others join will only allow the team to be even more awesome! All that said, please disable my root access and remove me from the various infrastructure/devops/root related email aliases and services (kanboard and gitlab come to mind). Please do keep me on the mirrors(a)archlinux.org alias for now though since I still handle mirror related requests. I also see that I am the only one on the dmarc-reports@ alias. If nobody is interested in the reports, please remove the relevant line from the DMARC DNS entry in the archlinux.org zone. Also, please remove my email address from the explicit hetzner contact list. If you think of anything else that I forgot, please disable it or, if in doubt, feel free to ask on IRC if I still need it. Thanks for the journey! Florian

1 0