Arch-devops November 2018

arch-devops@lists.archlinux.org

4 participants
3 discussions

[arch-devops] Reproducible Build nodes
by Jelle van der Waa 14 Jan '19

14 Jan '19

Hi all, We promised two PIA boxes to be used for reproducible build rebuilding nodes. [1] The boxes are already defined in ansible's hosts and don't have to be converted to Debian if we can get them working with Arch. [2] [3] The boxes should be added to their Jenkins server via ssh. We should setup a user with sudo rights and ssh key access to set the box up as slave. My plan if no one objects is: 1) Update the boxes and hope they come back up (~ 200 updates). 2) Add DNS entries for the two boxes {repro1,2}.pkgbuild.com. 3) add holger to this box with sudo rights (an ansible role probably). [4] 4) Add them to monitoring I suppose. Some background about reproducible builds and the usage of the boxes. The boxes will detect package updates, rebuild these packages twice and check if they are reproducible. These rebuilds have already found failing to build from source packages, 404 urls and other issues which improves are packages! [1] https://tests.reproducible-builds.org/archlinux/archlinux.html [2] https://git.archlinux.org/infrastructure.git/tree/hosts [3] https://salsa.debian.org/qa/jenkins.debian.net/blob/master/bin/reproducible… [4] https://salsa.debian.org/qa/jenkins.debian.net/blob/master/authorized_keys/… -- Jelle van der Waa

2 2

[arch-devops] Switch wiki git repo from tarball based updates to git merges?
by Florian Pritz 05 Nov '18

05 Nov '18

Hi, AFAICT, our wiki repo has been created with an extracted tarball and updated by just extracting the new tarballs on top of it and committing the result. Due to that we've once lost a change (a2bbd243c85ea0e425ee3e8c380aba9f254cee61) when an update had been commited (7c2a4c95e1d96bc56d00fd133fa537acc1346f5b). I've noticed that we have this open pull request[1] and since the Vector skin is part of the upstream tarball I'm worried that if I were to apply the change, it would again be lost with the next update. [1] https://github.com/archlinux/archwiki/pull/18 I've thus prepared a local branch where I merged our repo with the upstream repo. That means that we can update by merging the upstream tags and thus git can track our changes we get merge conflicts when necessary. The only issue I see with this setup is that we also pull in upstream tags, but those obviously refer to the upstream versions which do not include our changes and thus won't work. We could disable tag fetching, but this has to be done each time someone configures the upstream repo in their local clone and it can't be done automatically. We could either ship a small script that configures the remote correctly, but it has to be executed manually by the user, or we just live with the tags and prefix our own tags with 'archwiki-' or similar in the future. We could also stay with the tarball update method, but I think that's unnecessarily complicated and error prone. Thoughts? Florian

2 2

[arch-devops] Build tools and repo management
by Dumont, Joey 01 Nov '18

01 Nov '18

Hi everyone! Our group is thinking of maintaining a subset of the msys2 repo to be used internally. I am wondering if there is documentation on the Arch Linux side on what tools you are currently using to automatically build the packages in the officially supported repos. I believe there must be some kind of dependency management as well, since official repos are never cursed by soname bump issues. Is there documentation on this as well? Specifically, is there a tool similar to apt-mirror? Thank you, and please don't hesistate to ask questions if I didn't make myself clear. Joey Dumont Scientific Computing Technical Advisor National Research Council Canada joey.dumont(a)nrc-cnrc.gc.ca<mailto:joey.dumont@nrc-cnrc.gc.ca>

3 3

2023

2022

2021

2020

2019

2018

2017

2016

2015

Arch-devops November 2018