- Arch-devops - lists.archlinux.org

A Mumble server for Arch Linux
by Sven-Hendrik Haase 28 Oct '24

28 Oct '24

Hello everyone, I would like to suggest we set up a Mumble server for Arch Linux staff. Time and time again, it's been useful for Arch people to come together for a longer time to hack on various projects or to plan stuff like Arch Summit. Often times, people use Jitsi for such things. However, I think Mumble is a more suitable alternative for people hanging out for a longer time as it: - allows you to have multiple channels for dedicated topics and you can see who's currently meeting where - is more stable than Jitsi in my experience - has better desktop integration for muting - has better quality - can more easily be used over slow networks The idea is to use mumble-server, put it on the smallest Hetzner VPS and call it a day. I've been operating Mumble servers for years and it requires maintenance basically never. We cannot connect it to SSO so we'll run it like we run the IRC channels: have a password and ask people to not tell people outside of staff. We'll have a bunch of moderators (not necessarily devops, just whoever wants to do create some channels now and then) that can set up channels and such but apart from that I think we can just run it. Thoughts? Sven

5 5

Cannot register new security keys on accounts.archlinux.org
by Frederick Zhang 29 Sep '24

29 Sep '24

Hi all, I was trying to replace my security keys on accounts.archlinux.org however the page [1] seemed to be broken due to a missing base64url.js script [2]. Here's the Copy as cURL command I got from Firefox dev tools and its output: $ curl 'https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url…' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0' -H 'Accept: */*' -H 'Accept-Language: en-GB,en-US;q=0.8,en;q=0.5,ja;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: script' -H 'Sec-Fetch-Mode: no-cors' -H 'Sec-Fetch-Site: same-origin' -H 'TE: trailers' -D- HTTP/2 404 server: nginx date: Tue, 10 Sep 2024 11:47:04 GMT content-length: 0 referrer-policy: no-referrer strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff x-xss-protection: 1; mode=block strict-transport-security: max-age=31536000; includeSubdomains; preload Could someone who has access please look into this issue? And of course let me know if this is the wrong list. Thank you! [1] https://accounts.archlinux.org/realms/archlinux/login-actions/required-acti… [2] https://accounts.archlinux.org/resources/l7rth/login/archlinux/js/base64url… -- Frederick Zhang PGP: 8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D

2 2

becoming member of the infrastructure team
by khaliid caliy 18 Sep '24

18 Sep '24

I am a sysadmin and i would like to participate in Arch Linux infrastructure team with my skills and expertise and i willing and eager to learn more. Thanks all and apologies for inconvienance

3 4

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 07 Jan '24

07 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 19 Oct '23

19 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