- Arch-devops - lists.archlinux.org

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

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

Biweekly DevOps meeting
by Jelle van der Waa 03 Jul '23

03 Jul '23

Hey, This Thursday should be another bi-weekly DevOps meeting on 20:00 CEST. I won't be able to attend due to a work trip. Topics I can think of worth discussing are: - Uptimerobot - Flyspray migration - migration script status Greetings, Jelle

4 3

DevOps meeting Thursday
by Jelle van der Waa 30 May '23

30 May '23

Hey all, Let's re-start the bi-weekly meetings to sync up on the state of things, on Thursday 20:00 CEST. # Topics - Leftover migration ToDo's - Closing Flyspray - Gitlab package related topics Detailed agenda: https://md.archlinux.org/kF4a9cx2Sqe5ESusZw85zg?both Greetings,

1 0

GitLab's SSH moved to port 22 and sshd to port 2222
by Evangelos Foutras 19 May '23

19 May '23

GitLab's SSH clone URLs no longer require port 222. This matches the structure used by most GitLab instances. Previous clone URLs (which include port 222) will continue to work for the foreseeable future. The host's SSH port has been changed to 2222 and Ansible will use it automatically. Arch DevOps will also need to: ssh-keygen -R gitlab.archlinux.org Credits go to Kristian for suggesting and implementing this quality-of-life improvement: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/716

1 0