Tuesday, 2022-05-03

opendevreviewMerged openstack/diskimage-builder master: Revert "Fallback to persistent netifs names with systemd"  https://review.opendev.org/c/openstack/diskimage-builder/+/83886300:26
ianwclarkb: if you have a sec for https://review.opendev.org/c/openstack/diskimage-builder/+/839307 as well, it's just a little bash thing that i noticed in a test once.  it feels racy, i'm surprised we haven't hit it before.  or maybe we do and just put it down to gate instability and recheck06:48
rpittauianw, clarkb, I rebased the bifrost test to check after the merge, but it was green before, so I do not expect surprises07:02
ianwrpittau: thanks for that.  opendev has a need for a release to fix the centos 7 builds, if no objections probably will do tomorrow .au time07:03
opendevreviewJeremy Stanley proposed openstack/diskimage-builder master: yum-minimal: workaround missing $releasedir variable  https://review.opendev.org/c/openstack/diskimage-builder/+/83984015:48
opendevreviewJeremy Stanley proposed openstack/diskimage-builder master: Temporarily stop running OpenSUSE functtests  https://review.opendev.org/c/openstack/diskimage-builder/+/84032815:48
opendevreviewJeremy Stanley proposed openstack/diskimage-builder master: Revert "Temporarily stop running OpenSUSE functtests"  https://review.opendev.org/c/openstack/diskimage-builder/+/84032915:48
opendevreviewNeil Hanlon proposed openstack/diskimage-builder master: Ensure passwd is installed on RH and derivatives  https://review.opendev.org/c/openstack/diskimage-builder/+/84035216:06
opendevreviewMerged openstack/diskimage-builder master: Temporarily stop running OpenSUSE functtests  https://review.opendev.org/c/openstack/diskimage-builder/+/84032818:57
clarkbianw: I went ahead and approved https://review.opendev.org/c/openstack/diskimage-builder/+/83930719:37
ianwthanks19:38
opendevreviewMerged openstack/diskimage-builder master: yum-minimal: workaround missing $releasedir variable  https://review.opendev.org/c/openstack/diskimage-builder/+/83984019:52
ianwi'm thinking about how we could push this openafs update to the ppa from zuul, rather than manual updates19:55
ianwi could put the debian/* directory in openstack-zuul-jobs (near where we have the rpm build jobs) or system-config, or a new project?19:55
ianwit would then "just" need to run a debuild -S -sa and upload the results via dput, the trick will be getting a key on there that the ppa trusts to sign it19:57
ianwactually first grab defined upstream source, make orig.tar.gz, then put our /debian in it, then run debuild19:58
fungiyou could use the same mechanism we use to put a signing key on release job nodes19:58
ianwthat's approximately what i do manually19:58
fungii mean as far as automating it via zuul19:58
ianwyeah, that's handy, it will have figured out the magic of getting a key from secret->gpg19:59
fungiright, the short answer is that we export (just) the signing subkey as a keyring file and then encode that as a zuul secret to supply to the job19:59
fungithen when the job runs, a task splats that back onto the filesystem where gnupg expects to find it20:00
ianwpresumably that's just the default key, and ergo if it has no password debuild would just happily sign the changes file?20:01
fungiyes20:01
fungithough you can also override it with a specific key id, keyring path, et cetera if you like, it shouldn't really be necessary in a ci job20:01
ianwdo you think it's worth starting a new repo, or just put it in openstack-zuul-jobs somehow?20:02
fungiby "it" you mean the secrey? (we store the openstack release signing key in openstack/project-config)20:04
fungier, secret20:04
ianwi mean the whole /debian/* tree to build from really20:04
ianwand the job content, and i guess the secret20:04
fungiit could be a files subtree under a role20:04
fungiansible can copy a directory, right?20:05
ianwyeah it probably makes sense20:05
ianwdo you know off-hand how to regenerate *just* a changes file?20:05
fungii mean, if you want to go the debian's debian route, it would be to create a separate git repository for the debian subtree and then use git-buildpackage to import the upstream source...20:06
fungithe changes file is part of the build output, so i'm not sure how you would generate just the changes file without building20:06
fungibuilding the source package, i mean20:06
fungipresumably this is for source-only uploading to the ppa builder20:06
ianwyeah, i'm wondering if we can just re-sign it 20:07
ianwso the gate builds it, and then we pull the artifact in a promote job, and sign it with the "real" key and upload20:07
fungioh, if there's an existing changes file and you want to change or add a signature, you could just use gpg to do that directly i think20:07
ianwit would have to replace the signature, i guess20:10
fungii think multi-signature is possible, but i can't think of a benefit that would provide us in this context20:11
ianwif you run a .changes file through "gpg --decrypt --output <file>" i guess that gives us the original, then we can resign it20:14
clarkbianw: what would be the original source pacakge in that context? The one from debian ( Ithink that is what we had been using previously)20:15
ianwclarkb: it could be, but i'd probably have the script download and repackage the upstream source 20:16
clarkbah20:16
clarkbwould there be a changes file in that case?20:16
ianwthat way it's fairly clear what we're building20:16
ianwthe changes i mean the thing that debuild spits out, that has the list of files to build and their checksums 20:17
ianwdput then grabs the source files and that .changes file and uploads to launchpad, that then checks everything matches up with a trusted signature and builds20:18
clarkbright I guess I'm just confused why would would need to decrypt/unsign that file if you are generating it with the key you want? But also I'm probably missing something obvious20:19
fungisounds like the idea is to not use the upload key in the source package build job, but then have a separate job (re)sign and upload the resulting artifact20:20
clarkbah20:21
ianwyeah i think it makes most sense to have a promote step?  i'm open to ideas20:22
clarkbthat was the part I was missing and ya that would make it similar to some of the other artifact publishign we do20:23
ianwif we're building the source, we're only a very small way away from just using pbuilder or something to make our own binary packages20:23
ianwalthough launchpad still gives us easier multi-arch builds which we need20:24
ianwoh i thought we were in #opendev, heh, this isn't really dib related20:25
fungii was starting to wonder20:26
fungithat also changes the tone, if we're signing something for opendev instead of for openstack20:26
opendevreviewMerged openstack/diskimage-builder master: centos: avoid head pipe failure  https://review.opendev.org/c/openstack/diskimage-builder/+/83930721:04
ianwa055b59f8da71cf59d903e25de7fd2b6441026f3 is what i'm thinking for 3.21.022:10
clarkbianw: ya that lgtm22:44
clarkbianw: side note I think fungi thought 3.20.2 may have been tagged not on a merge commit so was actually further back in history than intended? godo to double check we'vegot a tip commit22:44
opendevreviewClark Boylan proposed openstack/diskimage-builder master: Add Jammy functesting to dib  https://review.opendev.org/c/openstack/diskimage-builder/+/84039122:55
clarkbianw: ^ something like that for jammy functesting?22:55
opendevreviewMerged openstack/diskimage-builder master: containerfile: update test to jammy  https://review.opendev.org/c/openstack/diskimage-builder/+/83898122:56
clarkboh heh I was updating to do that in my change and didn't ralize there was already a change for it :) I'll rebase22:57
opendevreviewClark Boylan proposed openstack/diskimage-builder master: Add Jammy functesting to dib  https://review.opendev.org/c/openstack/diskimage-builder/+/84039122:58

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!