[07:36] <slyon> Hey! Could somebody with the powers please re-trigger the netplan/focal test on ppc64el, arm64 & amd64 https://autopkgtest.ubuntu.com/packages/netplan.io/focal/ppc64el ? It failed for flaky tests... was successful before in bileto.
[11:22] <Laney> slyon: pretty much all of the autopkgtests are failing for me now when trying a test run locally in qemu... do you know why?
[11:23] <slyon> Laney: not sure... let me re-try that locally as well. I verified that all were working before the upload.
[11:24] <Laney> I'll try to re-run one arch on focal
[11:26] <slyon> thank you
[11:53] <Laney> seems to be working, so I did the others
[11:53] <Laney> no idea why qemu isn't working properly :(
[12:11] <cpaelzer> slyon: what is your commandline to get qemu autopkgtest runners?
[12:11] <cpaelzer> ... -- qemu --qemu-options='-cpu host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-groovy-amd64.img
[12:11] <cpaelzer> would be my tail that I use for these most of the time
[12:13] <slyon> Laney: cpaelzer: qemu is doing good for me so far, it's still in the middle of the test, but all tests passed up to now. I do not have any special commandline, just using "-- qemu ./autopkgtest-focal-amd64.img"
[12:15] <Laney> like that but without --cpus 2
[12:15] <Laney> autopkgtest --timeout-copy=6000 --apt-pocket=proposed=src:netplan.io netplan.io -- qemu --ram-size=1592 autopkgtest-focal-amd64.img
[12:16] <Laney> pretty much everything broke, way more than did in the runs that failed on autopkgtest.u.c so I don't even
[12:17] <Laney> https://paste.ubuntu.com/p/8hQwp8wk8G/ for example
[12:17] <Laney> but running that without the --apt-pocket=proposed=src:netplan.io was mostly good https://paste.ubuntu.com/p/Ym5QhHHsJ9/
[12:23] <slyon> That's interesting... I can reproduce it if I use --apt-pocket=proposed=src:netplan.io (instead of using the source dsc). I need to look into that
[12:24] <slashd> rbasak: could you please reject my 'sosreport' upload in bionic ? I need to arrange a few things and will re-upload later.
[12:25] <slashd> re: LP: #1892275 ^
[12:37] <rbasak> slashd: sure
[12:37] <slashd> rbasak: thanks
[13:51] <xnox> dpkg-genchanges: error: cannot fstat file ../linux-firmware-raspi2_1.20200902-0ubuntu2_amd64.buildinfo: No such file or directory
[13:51] <xnox> dpkg-buildpackage: error: dpkg-genchanges subprocess returned exit status 25
[13:52] <xnox> anybody had this before, whilst building source build of the package only?
[14:00] <jchittum> LocustusOfBorg: i updated lp:1895862 with more information. I took the path of using the pre-installed virtualbox-guest-utils module. However, attempting an upgrade or install will fail. This will end up breaking anyone using the vagrant-vboxguest plugin or that installs an update via automation (such as Ansible)
[15:24] <cousteau> Hi, I had to rebuild and install package `git`.  Now `apt policy git` shows two candidates: 1:2.25.1-1ubuntu3 500 (the one from repos) and 1:2.25.1-1ubuntu3 100 (the one I installed).  Now, if I `apt-get install git`, for some reason it thinks the one from repos is more modern than the custom one I built and installed, and reinstalls the one from repos
[15:24] <cousteau> I have no idea what those 500 and 100 mean
[15:25] <cousteau> (on an unrelated note, git with GnuTLS doesn't work on my company network)
[15:35] <cjwatson> You should change the version if you rebuild it locally
[15:35] <cjwatson> Increase it very slightly, e.g. 1:2.25.1-1ubuntu3+local1
[15:47] <cousteau> cjwatson: I suspected that.  After some research, apparently the 500 is a pin priority established by apt_preferences(5)
[15:47] <cjwatson> It's possible to adjust pinning, but much easier to change the version
[15:47] <cousteau> Now let's see how easy it is to change the version number.  Guess it's a matter of touching the DEBIAN file
[15:47] <cjwatson> Just requires sticking a new entry at the top of debian/changelog
[15:47] <cjwatson> Do not ever touch DEBIAN (all-caps) manually
[15:48] <cjwatson> You modify packaging metadata by editing things under debian/ (all lower case) in the source package
[15:48] <cousteau> Or the... whatever file that later generates the DEBIAN
[15:48]  * cousteau followed a tutorial mostly blindly and didn't have much idea what he was doing 
[15:49] <cjwatson> Any tutorial that advises touching DEBIAN/ (all-caps) should be cast into the sea and replaced with some other tutorial :)
[15:49] <cjwatson> It's a good filtering mechanism
[15:50] <cousteau> Yeah sorry.  I just remembered there was a DEBIAN file or folder so I mentioned that
[15:50] <cjwatson> Yeah, it's an internal detail used by dpkg when assembling the control.tar part of the binary package
[15:51] <cousteau> In fact this tutorial said to edit debian/control and never mentioned the all caps version
[15:51] <cjwatson> Oh good
[15:51] <cjwatson> But debian/changelog for changing the version
[15:51] <cjwatson> There's a fairly precise format.  The "dch" tool will help
[15:53] <realtime-neil> If Ubiquity doesn't support preseed keys for the `base-installer` component (https://wiki.ubuntu.com/UbiquityAutomation), then how do I tell it which kernel to install? Equivalently, what is the Ubiquity way to do `base-installer/kernel/image`?
[15:53] <cousteau> cjwatson: https://devopscube.com/gnutls-handshake-failed-aws-codecommit/ the tutorial, in case you're curious :)
[15:56] <cjwatson> Yeah, I would generally recommend sbuild instead to keep your main system clean, but that's not wrong
[15:56] <cjwatson> Mostly
[15:57] <cjwatson> But it indeed omits changing the version, which is wrong :)
[16:00] <cjwatson> realtime-neil: I'm several years out of date, but generally speaking ubiquity doesn't have configuration for this sort of thing because it's designed to copy a squashfs instead - you give it a different kernel by preparing a replacement squashfs that contains that kernel
[16:00] <realtime-neil> cjwatson: that's incredibly helpful. How can I edit the documentation to this effect?
[16:03] <paride> hi Laney, did you have a chance to look at the broken xenial migrations? Is there a LP project where it's sensible to file a bug against for this?
[16:05] <Laney> paride: A bit, but I didn't get to the end yet with the sprint and stuff, sorry about that
[16:07] <Laney> you can file it on the 'britney' project
[16:32] <paride> Laney, https://bugs.launchpad.net/britney/+bug/1898907
[16:32] <Laney> merci
[16:40] <cjwatson> realtime-neil: Sorry, I'm too far out of the loop to know where would be best to edit - I used to work on this stuff but not for >5y
[16:41] <realtime-neil> cjwatson: no worries; I'll keep looking around
[19:43] <mwhudson> fwiw subiquity's squashfs doesn't have a kernel in it, but it doesn't really have a sensible hook for letting you change which kernel to install