[arch-dev-public] Mailing list migration (Luna->VPS)
Hi all The time has finally come to migrate lists.al.org away from Luna and to a Hetzner Cloud VPS. I will do the final testing today and if all goes well the migration will be handled tomorrow (23th of June) between 16-24UTC. A mail will be sent shortly before starting the migration and I don't expect more than 1-2 hours downtime (at worst). If you experience any issues after the migration, please reach out by mail or #archlinux-devops on Libera Chat. As part of the migration there are a few technical changes (draft MR here [1]): * The arc...@archlinux.org -> arc...@lists.archlinux.org aliasing[2] will be dropped * SpamAssassin and OpenDKIM are replaced by Rspamd * postfix_to_mailman.py[3] is replaced by Postfix aliasing [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/424 [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/a2b8682316e32ea956f6b6efedf4d7cff4f333b6/roles/postfix/files/mailman_compat [3] https://wiki.list.org/DOC/How%20do%20I%20configure%20postfix_to_mailman.py%3F Best regards Kristian Klausen - DevOps OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Mailing list migration (Luna->VPS)
On 22.06.2021 19.05, Kristian Klausen via arch-dev-public wrote: Hi all The time has finally come to migrate lists.al.org away from Luna and to a Hetzner Cloud VPS. I will do the final testing today and if all goes well the migration will be handled tomorrow (23th of June) between 16-24UTC. A mail will be sent shortly before starting the migration and I don't expect more than 1-2 hours downtime (at worst). If you experience any issues after the migration, please reach out by mail or #archlinux-devops on Libera Chat. Time to break arch! I will start the migration shortly. - Kristian
Re: [arch-dev-public] Mailing list migration (Luna->VPS)
On 23.06.2021 18.49, Kristian Klausen via arch-dev-public wrote: On 22.06.2021 19.05, Kristian Klausen via arch-dev-public wrote: Hi all The time has finally come to migrate lists.al.org away from Luna and to a Hetzner Cloud VPS. I will do the final testing today and if all goes well the migration will be handled tomorrow (23th of June) between 16-24UTC. A mail will be sent shortly before starting the migration and I don't expect more than 1-2 hours downtime (at worst). If you experience any issues after the migration, please reach out by mail or #archlinux-devops on Libera Chat. Time to break arch! I will start the migration shortly. The migration should now be done, if there are any issues please reach out by mail or #archlinux-devops on Libera Chat. - Kristian
Re: [arch-dev-public] deprecating git.archlinux.org
On 23.06.2021 22.01, Jelle van der Waa via arch-dev-public wrote:
If your project has not been migrated to Gitlab yet please contact
devops for help migrating it. A list of known to require migration is
listed in this ticket. [1]
As the invoice date comes up the 8th, it would be awesome if we can
cancel the box before that date.
[1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6
We (I and jelle) have already migrated a good chunk of the projects, so
I think it is time we can begin updating the packages to use their new
home as "source".
The following packages (found with[1]) use {git,projects}.archlinux.org
as source and should be updated (TODO here[2]):
archboot
arch-install-scripts
cgit-archweb
cgit-aurweb
devtools
mkinitcpio
namcap
netctl
pacman
pacman-contrib
Please reach out if the git repository hasn't been migrated and we will
fast track it. Some of the new homes are documented here[3].
[1] grep -lE 'git.archlinux.org|projects.archlinux.org' $(find
/srv/svntogit/repos -name PKGBUILD) | cut -f6 -d / | sort -u
[2] https://archlinux.org/todo/gitarchlinuxorg-deprecation/
[3] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6
Re: [arch-dev-public] deprecating git.archlinux.org
On 23.06.2021 22.01, Jelle van der Waa via arch-devops wrote: Hi All, Today mailman was moved to a dedicated vps, making git.archlinux.org the last service to run on luna which we intend to retire as it's an old expensive box and GitLab is our replacement for Git hosting. Luna is now wiped and it will be gone in a few hours. Most of the git.a.o projects have been moved to either our gitlab instance or github, most of the personal forks have been deleted after confirming with the relevant user and the remaining projects have been archived to Software Heritage[1]. [1] https://archive.softwareheritage.org/browse/search/?q=git.archlinux.org&with_visit=true&with_content=true
[arch-dev-public] 2FA credentials backup
Hi all In the past week two staff members have lost their phone and thereby their 2FA credential for accounts.archlinux.org. The DevOps team can remove 2FA if they are provided with a GPG signed mail, but we would prefer not spending time on that. So please consider backing up your 2FA credentials. On Android the following apps support backup: * https://github.com/andOTP/andOTP * https://getaegis.app/ Authy is also worth mentioning although it is proprietary: * https://authy.com/ Best regards Kristian Klausen - DevOps
Re: [arch-dev-public] namcap maintainership
On 28.08.2021 17.37, Caleb Maclennan via arch-dev-public wrote: On 2021-08-21 22:24, Jelle van der Waa via arch-dev-public wrote: I would love to see someone from our team pick up namcap maintainership, [...] Is there any progress on this decision? So far we have 4 of us that are interested in maintaining and/or contributing to the project. But, as I understand it, until somebody (?) makes an executive decision and we get some permissions on the project repo there is only so much any of us can do. I'm happy to work with any/all of Filipe, David, or Konstantin. I would suggest a relatively flexible workflow where one of us (whoever is going to manage delegating permissions and pull the trigger on releases) at least has maintainer accesses to the current repository on GitLab, and all the other parties that have volunteered to date (and possibly future ones) are given developer level permissions. Then we can setup the master branch protections such that 1 approval is required for merge requests. Any one of us could handle 3rd party contributions, and we can ourselves contribute with any one other party signing off on reviews. That way there isn't a huge bottleneck on one the development process if/when people are motivated to contribute. Only possibly the release tagging would be a single contact point (the maintainer). I added you all as developer and added a approval rule requiring one of you to approve every merge request. So coordinate and start hacking :) Please ping me or another from the DevOps team if you need more tweaking or perhaps we can make one of you a maintainer. Kristian I've scrubbed through the mailing list and found all the patches that have come in since the last commit to the repo and opened issues to review each of them. If this is going to move forward I can also collect said patches into MRs that can be reviewed from GitLab and possible scrounge up the existing feedback they got on the projects list. Dealing with those past contributions will at least be a first step. With a little motion on the project and a pathway for contributions to actually be processed I'm hopeful more devs/TUs will chip in over time — given this is something we are all exposed to. Caleb
Re: [arch-dev-public] RFC: Rename the Trusted User role
On Sat, Oct 09, 2021 at 22:03:55 +1000, Allan McRae via arch-dev-public wrote: > There is potential you already discussed this on the private mailing > list but I do not have access to the email archives that are linked in > the RFC. Nor do community members who are encouraged to comment on > RFCs. The fact changes like this are discussed in private is a > detriment to a community orientated distribution. Regarding your lack of access to the staff archive. AFAIU you removed the access yourself (correct me if I'm wrong), even though you could just have disabled "Mail delivery"[1] and maintained access to the archive. IMHO all staff should be subscribed to the staff list or at least have access to the archive, so if you want I can reinstate your access to the list with mail delivery disabled. [1] "Set this option to Enabled to receive messages posted to this mailing list. Set it to Disabled if you want to stay subscribed, but don't want mail delivered to you for a while [...]" Kristian
Re: [arch-dev-public] Upcoming PHP 8.1 update
On Sat, Jan 22, 2022 at 20:45:45 +0100, Pierre Schmitz via arch-dev-public wrote: > Hi David, > > sorry about the hassle. I did not expect much issues here. I would > consider this one of the smoother PHP updates. Unless people ignored > warnings by previous PHP versions. I guess that is what mostly happend > here. PHP 8 gets more and more strict each version. > > After reading the issues on Nextcloud's Github repository I guess we > can conclude that they will probably lack behind at least one PHP > minor version. This is quite incompatible with the Arch way. > > Anyway, let's talk about some options to solve such issues: > > 1) Let's no longer package software that requires older versions of > PHP. Personally I would run such complex software with very specific > needs in a Docker container. E.g. Nextcloud even provides an official > one. FYI: As stated earlier by Jelle[1], our bugtracker isn't currently compatible with PHP8. In case PHP7 is dropped from the repos and no one steps up fixing the flyspray code[1]. The DevOps team will likely just run the the bugtracker in a container of some sort. [1] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030571.html [2] https://gitlab.archlinux.org/archlinux/flyspray/ - Kristian > 2) Keep trying to patch upstream packages to keep them working. > 3) We provide two sets of PHP packages: "php" would always be the > latest stable version and be released no matter what. In addition to > this there would be e.g. "php-legacy" packages providing the oldest > supported version, currently 7.4. This would be updated to 8.0 in > November when 7 is EOL and php-8.2 get's released. The difference to > the currently available php7 package will be the lack of a version > number in package and binary names. So both packages will be a moving > target, but always two versions apart. > > I would give option 3 a try. I'd like to get rid of versioned > constraints then and reduce the amount of third party modules. While > we would end up with more packages we need less testing and will be > able to move faster. > > *) https://www.php.net/supported-versions.php > > On Sat, Jan 22, 2022 at 10:57 AM David Runge wrote: > > > > On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > I just released PHP 8.1 into [extra]. > > > > > > Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP > > > 7 can be dropped soon. > > > > > > have a nice weekend, > > > > Unfortunately, it likely won't be ;_; > > > > https://bugs.archlinux.org/task/73452 > > > > Another reminder for users to *please* join the Testing Team [1] and > > help test our packages! > > > > Best, > > David > > > > [1] https://wiki.archlinux.org/title/Arch_Testing_Team > > > > -- > > https://sleepmap.de > > > > -- > Pierre Schmitz, https://pierre-schmitz.com
[arch-dev-public] Signing enclave
Hi all The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling. A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today. The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing). Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed [1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure Best regards Kristian Klausen
Re: [arch-dev-public] Debug packages for Arch Linux
On 30.01.2022 12.08, Morten Linderud via arch-dev-public wrote:
I'm very happy to announce that debug packages in Arch Linux has been deployed
:)
This work began after FOSDEM 2020 and was announced in November 2020. However
because of time constraints it took quite a while before we managed to deploy
it.
Currently we have a debuginfod service which is capable of delivering source
listings and debug symbols to users with gdb, delve and other debuggers. This
can be enabled by installing the `debuginfod` package and setting the
environment variable `DEBUGINFOD_URLS="https://debuginfod.archlinux.org"`. The
`debuginfod` package is also going to be providing this variable :)
The debug package repositories themself are not publicly accessible nor
distributed to our mirrors. This is because there is a general concern around
the repository size increase. The goal is to take a look at distributing them
and/or making them accessible in the future.
We have three sponsored machines, which are used as package mirrors and
archive mirrors[1].
At the time of writing they have 14TB available storage each, so we
could mirror the debug packages to them.
[1] {america,asia,europe}.{archive,mirror}.pkgbuild.com
- Kristian
Re: [arch-dev-public] possible mkinitcpio-31-3 package
On 08.05.2022 21.52, Tobias Powalowski via arch-dev-public wrote: The next 3 weeks later ... any progress on the project release? greetings tpowa This is really not a topic for arch-dev-public, please discuss it directly with the maintainer, move the discussion to arch-projects or GitHub[1]. [1] https://github.com/archlinux/mkinitcpio Cheers, Kristian Klausen OpenPGP_signature Description: OpenPGP digital signature
