- Arch-devops - lists.archlinux.org

Christian Heusel is now a full DevOps!
by Kristian Klausen 11 Feb '24

11 Feb '24

Hi all, Christian has been a Junior DevOps for nearly 4 months but has been consistently contributing for way longer than that. He has proven himself to be hard-working and reliable, the DevOps team has therefore decided to promote him to full DevOps with all responsibilities and privileges that come with that. Welcome aboard, Christian! Cheers, Kristian

1 0

Rebasing other users' MRs for packages
by Brett Cornwall 11 Jan '24

11 Jan '24

Not sure if this is intentional but trying to rebase the branch in this MR is giving me a "something went wrong": https://gitlab.archlinux.org/archlinux/packaging/packages/sway/-/merge_requ… I would guess that the person just didn't check the "let the maintainer edit the commits" or something but I'd expect a less generic error message. Is this intentional behavior or broken behavior?

3 2

Automatic mailman onboarding
by Jelle van der Waa 08 Jan '24

08 Jan '24

Hey all, We have been wanting to onboard folks automatically via Keycloak to all our services. Mailman being one of them: Gluebuddy seems to be the best fit for this, as it a) knows keycloak and b) can also talk to mailman eventually (as it's just a REST API). For this I made an issue in Gluebuddy and a WiP branch for Gluebuddy which can do onboarding. [1] There are however several issues left to solve as we have many different usages of our mailing list. I for example on Keycloak use jelle(a)vdwaa.nl for my account and my arch email is jelle(a)archlinux.org (same as keycloak username). However this is not always the case, we have folks who have: - Different Keycloak email from Arch - Different Arch mail address from login name ie. svenstaro => sven(a)archlinux.org - May not use Arch email for mailing lists but their own. So in Keycloak I've used the beta feature of profile attributes, to add arch_email. And I think we should set this for all staff to be their archlinux email address. Even if it's the same as their username. With that solved we can onboard all arch email addresses. Would this also help for onboarding users into mail.archlinux.org? At least we can maybe replace the hardcoded mailmap? Now I know a lot of us subscribe with their personal email, how do we want to handle that from gluebuddy? Just mass subscribe and allow users to unsubscribe? Or at least allow sending? I haven't implemented onboarding, that likely has to request all users from mailman and match them against known keycloak staff's email/arch_email attributes. [1] https://gitlab.archlinux.org/archlinux/gluebuddy/-/issues/4 [2] https://gitlab.archlinux.org/archlinux/gluebuddy/-/merge_requests/17 P.S. the irony, I am not subscribed with my @archlinux.org address to this list.

2 1

Proposal about AUR affairs
by Evan Greenup 10 Dec '23

10 Dec '23

Hello, AUR is a unique feature for Arch Linux (include derived distros). It significantly expand the Arch ecosystem. However, for the current infrastructure and workflow for AUR, there are some drawbacks. 1. Difficult to feedback and difficult to contribute (to already existed package). If have any ideas or report, user need to send email to maintainer via email personally. This is not convenient for both maintainers and users. 2. Lack of Peer review, audience supervise. Some packages even if updated frequently by its maintainer, but it doesn't following good practice and not built from source (Not Java, native program), It retrieve from Debian or Ubuntu or Fedora packages, and extract or repackage it in Arch Linux package. And some packages may failed to build, or some of its dependencies are forgotten added by maintainer. 3. The entry with a specific name in AUR is always occupied by the Maintainer who firstly register the package. If there is another maintainer who has better practice than the previous one, This maintainer has to rename his/her package as `xxx-bin` or some sophisticated name else. This is unfair. It lack of refreshing mechanism. 4. upstream software author is difficult to directly contribute to the AUR packaging contribution. For a great number of upstream software author, they are willing to participate in downstream redistribution process. Especially for those young software. But the current AUR workflow block their way to contribute on downstream stuff. 5. Currently,to evaluate whether a AUR package is eligible to move in Arch Linux official packages (extra repo), It only depend on votes and popularity and whether there is a maintainer willing to pick it up. However, those factors is too lack of details. To evaluate the robustness of the eco-position of a package, It should evaulate the discussion, issue report, contribution, and ... And it should be evaluated case by case. I have some ideas to resolve or mitigate the problems above. 1. Create a git repo on gitlab.archlinux.org named aur-meta (Or whatever names which maker users understand easily). This git repo keep a list (table of content) which point to the git repo URI of the AUR packages. 2. For the AUR package, it can be placed on anywhere (github.com, gitlab.com, gitlab.archlinux.org, gitlab.gnome.org ...), the only things needed are these URIs are public accessible (can be git cloned by anyone who know this URI). And it need to keep its PKGBUILD on the top level of git repo. 3. The issue and affairs related to which upstream software is included and which PKGBUILD git repo is selected, goes to issues section of aur-meta. For packaging specific problems, it goes to the AUR package git repo. 4. If a package is orphaned or too broken/bad practice, the contributor who has access to aur-meta can simply change the pointer to a alternative PKGBUILD git repo which is better in practice and liveliness. 5. If user find there is package which need to be improved, it can firstly report it to PKGBUILD maintainer via the issue section of git repo. If the maintainer long time not response or insist to keep bad practice. The user can write a proposal in aur-meta to change the pointer to another alternative. This is what a community driven packaging method should be. 6. The name of entry in aur-meta is the package name, not the name of PKGBUILD git repo. (git repo can have different name). Many upstream software author would create a separate git repo along with their software repo which is dedicated for PKGBUILD. The design above, is just for demonstrate ideas, improvements can be made further. Evan

4 3

Handle recompilation of dependent packages, on breaking-changes
by Veldora 02 Nov '23

02 Nov '23

Hi there I'm having an issue with the ABS and how it's working. I've read, that the ABS is based on a similar concept such as *BSD's ports system. On e.g. FreeBSD, I can use poudriere to handle the ports and it's dependents recompilation. E.g. ffmpeg provides libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so Firefox depends on ffmpeg and poudriere handles like so: if a .so file get's changed, it recompiles ffmpeg to provide the .so and recompiles all dependent packages. (within also firefox). Has the official Arch build server anything similar to poudriere, so a rebuild of packages e.g. ffmpeg would trigger a recompilation of e.g. firefox, to match with the latest version again. The reason for this is, I would like to use a repo-snapshot of the Arch archive as main-repo and backport security-patches from the gitlab sources to a custom repo. While I could just do it manually, which would be a pain to manage and packages which depend on it hard to find, I'm asking, if there is anything comparable to poudriere on FreeBSD for Arch Linux, which I can selfhost? Thanks.

1 0

Junior DevOps application - Christian Heusel (gromit)
by Christian Heusel 20 Oct '23

20 Oct '23

Hello everyone, tl;dr: I would like to hereby apply as junior devops with jelle and klausenbusk sponsoring my application. I am using linux systems since around 2012, arch-based systems since 2016 and Arch Linux itself since 2018. Since a few years I am also an active contributor to open source software either by publishing own projects or modifying existing ones to fit my liking[0]. In Arch Linux I am currently mainly contributing as Package Maintainer[1], Tester, via contributions to various projects (devtools, AUR, archwiki etc)[2] and anywhere where I find contributing fun or figure someone needs to step up. I like things moving fast and improving over their status quo and feel like Arch Linux is a great fit to actually do that. Outside of Arch Linux I have so far already worked a few years as a part time linux systems administrator (2018-2021) and also still do on a volunteer basis for my student council (since 2018). I am therefore quite used to ansible, the mediawiki stack, hedgedoc, monitoring with the prometheus stack, backups via borg(matic) and in general just quickly getting any unknown systems to run when they are needed for the project or putting in the maintenance work to keep existing systems happily running. Past and current contributions to infrastructure projects in Arch Linux include helping a bit during the git packaging migration and when the gitlab was hit by spam and recently more meaningful contributions to the wiki setup[3][4] and in the light of the upcoming bugtracker migration[5][6]. To be able to further help out in the devops team I would like to become part of it as junior devops. I would initially be interested in the following areas, but will pick up whatever looks doable and progress from there: - Bugtracker, Gitlab and Bugbuddy (for the bugtracker migration) - Mediawiki (SSO, updates and fixes) - Hedgedoc Thanks for reading until here, I am excited to see your reactions/feedback! Cheers, gromit [0] https://github.com/christian-heusel [1] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [2] https://gitlab.archlinux.org/gromit [3] https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/747 [4] https://github.com/archlinux/archwiki/pull/67 [5] https://gitlab.archlinux.org/gromit/flyspray2gitlab/ [6] https://gitlab.archlinux.org/flyspray-migration/

3 3

CSS for the archlinux website could be more readable
by Jean Luc Picard 05 Sep '23

05 Sep '23

I've never noticed this until just right now, but I just viewed arclinux dot org slash news on a fairly competent laptop LCD (poor coverage, decent angles, good contrast) & was damn nearly blinded, even well after adjusting the relative font size w/ ctrl - +/-. I get that someone took the care to make the link colors to the official colorscheme, but I shouldn't feel like I should need an extension or toggle a browser flag as to not feel like I'm about to have a wall of text seizure. It's not the cyan link colorscheme so much as the combination with the table bg colorscheme complementing it, destroying whatever contrast was left. Something like 30% of the human population has some level of color-blindness & you might not want the overhead of whatever population might have photosensitive epilepsy. I know of good frens in the community who have been triggered by stupider problems. Some of which aren't around anymore for stupider problems. This is coming from someone that runs cdm in matrix mode & turns motd into an animation of ansi code. My recommendation: Find a color picker applet, reduce brightness a few notches (manual: keep subtracting from the subpixel values), & enable bold. Perhaps clicked on links go to arch cyan regular & unclicked go for a more Web 1.0 deepish blue bold. Change the table colorscheme to greyscale, or find an appropriate one that would complement in contrast rather than sameness. Something Something ADA Reasonable Accomodation Request Posting to devops cause I figure this is where the webmaster would be.

1 0

Self-managed Arch repo & build-server
by Pascal Bryner 28 Aug '23

28 Aug '23

Hello Arch-DevOps Community We'd like to ask you, if there's a possibilty to clone all core & extra packages from the ArchLinux GitLab Packages Group to one of our build-servers and build them for our self. I've found the pkgctl utility, but when trying to execute 'pkgctl repo clone --protocol https --universe', it creates the respective directories but is then stuck at the cloning-process. The reason for this request is: We're running 60+ Arch clients for our employees (tendency increasing), which all are managed through a central application, where we can execute OS-updates, software-installs, firmware-updates, etc. The main problem is, that if we execute a company-wide update, some people directly install them and some postpone them as far as possible, sometimes taking vacation without installing the updates first. This leads us to the problem that the clients don't have the same state, sometimes with a 2 week or more gap, which makes it difficult for us to troubleshoot any problems. We had in mind, cloning all package-sources and then making snapshots of the build-directory, for a "stable" release. When using the gitlab-api to get all the urls of the repos, after some time the request times out, because we made to many requests. We do understand, that it's not the idea of Arch Linux to be a "part-stable" distribution, since of it's rolling-release model, but for maintenance-reasons it's the best option, having a rolling-release distro with up-to-date software and the ability to control, which packages are getting installed and which not. I hope you understand our proposal. -- Best regards Pascal Bryner Junior System Administrator

4 4

DevOps Meeting Thursday 27 July
by Jelle van der Waa 24 Jul '23

24 Jul '23

Hi, Agenda: https://md.archlinux.org/devops-agenda-27-july Time: 20:00 CEST Greetings, Jelle van der Waa

1 0

DevOps Meeting 13-07-2023
by Jelle van der Waa 09 Jul '23

09 Jul '23

Hi all, This Thursday there should be another DevOps meeting, I can't attend as I'll be on vacation. Previous meeting: https://md.archlinux.org/obH9H0v1TYSsxiN0UTY1Kg Greetings, Jelle van der Waa

1 0