=== pieq__ is now known as pieq
=== _hc[m] is now known as _hc
=== ebarretto_ is now known as ebarretto
[08:41] <sil2100> bdmurray, xnox: ok, just to double confirm - the phasing machinery for secureboot-db is deployed and it will all work automagically, yes?
[08:41] <sil2100> I don't need to do anything special to special-case it?
[09:30] <LocutusOfBorg> Laney, FYI we forgot on bad package the libgstcamerabin.so, so now they are not installable together (good and bad) meh, removing and reuploaded
[09:30] <LocutusOfBorg> seb128, ^^
[09:33] <Laney> LocutusOfBorg: You didn't test?!?!?!!
[09:33] <seb128> LocutusOfBorg, quality
[09:33] <LocutusOfBorg> I did
[09:33] <LocutusOfBorg> and I don't know why it got installed in my chroot
[09:33] <LocutusOfBorg> I also debdiffed the resulting binaries
[09:35] <LocutusOfBorg> of course I tested the locally built packages, not the one in the archive (because they were in new queue), so I used dpkg -i on them
[09:35] <LocutusOfBorg> the only package who was asking to be autoremoved was an old dbg package, because of the new dbgsym one
[09:35] <LocutusOfBorg> I still have the debs, let me try to figure out what happened
[09:36] <Laney> I see, that's partly why I wanted to have the PPA :-)
[09:36] <LocutusOfBorg> I even tested the upgrade path from 1.16 to 1.18
[09:39] <LocutusOfBorg> damn, I tested them again, and they still install
[09:40] <LocutusOfBorg> ok got it
[09:41] <LocutusOfBorg> libgstreamer1.0-plugins-good-dev doesn't install gstreamer1.0-plugins-good
[09:41] <LocutusOfBorg> seems counter intuitive, but correct :(
[09:42] <Laney> oh well, you caught it, no big harm this time
[09:46] <LocutusOfBorg> once, a while ago I setup piuparts to automagically do this instead of doing it manually (because with such big number of binaries and new binaries, manual testing is PITA), but I forgot the setup
[09:46] <LocutusOfBorg> meh
[09:48] <LocutusOfBorg> btw I would have loved to use the ones in the ppa, but the dh_gstscan dh call was not preloading the libraries (and silently failing), so I opted for a faster local build...
[09:49] <LocutusOfBorg> (not sure what the gstscanplugins call does, but I wanted to be safe)
[09:55] <Laney> It's used to generate the fields you see in the archive, Gstreamer-Encoders and friends
[09:55] <Laney> so that packagekit and stuff can find the right package to install on demand
[10:10] <xnox> sil2100:  correct
[10:11] <xnox> sil2100:  it has hardcoded constant to slow phase if package name is secureboot-db
[11:57] <Laney> LocutusOfBorg: The -dev package is borked on i386, the -opencv dep needs to be excluded there
[11:58] <Laney> if you've got time, fixing that would be welcomed, otherwise I'll do it later
[11:58] <Laney> and please pull git, I fixed up the branches a bit
[11:59] <Laney> they were a bit weirdly messed up
[12:05] <mvo> juliank: hey, not sure if you are the best person (who is doing grub these days?) to ask I just filed 1896608 about a grub-shim-amd64-signed failure, I have an open debug shell to the machine if that is useful, I can provide interactive help if needed
[12:06] <juliank> mvo: i did read the bug a few minutes ago, and that seems to be fallout from xnox's latest changes to error out with exit 1 instead of continuing on
[12:10] <juliank> mvo: I can't really context switch to it right now, I'm inside PackageKit :(
[12:18] <mvo> juliank: no worries! not urgent from my POV, just tried to help :)
[12:19] <LocutusOfBorg> Laney, done thanks
[12:19] <juliank> mvo: We've seen about 3 such bugs and marked them incomplete because there was no error message in the log :)
[12:20] <mvo> juliank: yeah, this wa a bit tricky to debug, it highlights that shell and debconf has some shortcomings when it comes to APIs :)
[12:21] <xnox> mvo:  how did you upgrade?
[12:21] <xnox> mvo:  non-interactive?
[12:22] <xnox> juliank:  also now i'm not sure if install_devices are expected to be empty for efi?!
[12:23] <xnox> mvo:  yeah i would want to see the debconf-get-selections | grep grub or some such.
[12:24] <juliank> xnox: grub-efi/install_devices should not be empty, it will be populated from mounted ESP (migrated setting)
[12:26] <xnox> ack
[12:26] <xnox> mvo:  were you upgrading non-interactive?
[12:26] <mvo> xnox: this was not set to non-interactive, the code comment is not accurate
[12:26] <mvo> xnox: it was an apt upgrade
[12:27] <xnox> but return code 30 would mean SKIP / not-shown
[12:27] <xnox> is our debconf handling all wrong then?!
[12:27] <mvo> xnox: it looks like this is an exit code
[12:27] <mvo> xnox: so the if is non-zero
[12:27] <mvo> xnox: at least that is what sh -x is indicating
[12:28] <xnox> mvo:  can you pastebin the sh -x log?
[12:28] <mvo> xnox: sure, one sec
[12:29] <mvo> xnox: I added debug lines to each "exit 1" so don't be surprised by that: https://paste.ubuntu.com/p/9CBGGvJjz9/
[12:30] <mvo> xnox: I think the crux is that "if db_input critical grub-efi/install_devices_empty" gets a return code 30 because the question is skipped
[12:30] <mvo> xnox: and that triggeres the "non-interactive" branch which is not quite right, it's skipped because it was asked before
[12:31] <mvo> xnox: does that make sense?
[12:31] <LocutusOfBorg> Laney, I think you got it from ehre "libgstreamer-plugins-bad1.0-dev/i386 has unsatisfiable dependency"
[12:31] <LocutusOfBorg> what about also telling "which" dependency is unsatisfiable? isn't this a good feature?
[12:33] <mvo> xnox: grep -A4 grub  /var/cache/debconf/config.dat|pastebinit -> https://paste.ubuntu.com/p/j2DwtQHzSb/ but I think the crux is just the "install_devices_empty" and the fact that it has the seen flag
[12:34] <mvo> xnox: anyway, I have the debug shell here if needed, I would love to have the two "exit 1" to print something before they exit so that at least it's slightly more clear what is going on (I was totally lost when I saw this initially)
[12:47] <sil2100> xnox: ok, done, hopefully it's phasing now
[12:47] <sil2100> xnox: btw. is phasing also implemented for -security too?
[13:09] <xnox> sil2100:  no, there is no phasing for -security, it gets auto-installed within 24h via unattended updates.
[13:21] <LocutusOfBorg> jamespage, hello, do you care about temptest? removing python3-neutron-tempest-plugin/0.2.0-1/amd64 from testing makes python3-tempest/1:23.0.0-0ubuntu2/amd64 uninstallable
[13:25] <LocutusOfBorg> I syncd it
[13:27] <LocutusOfBorg> looks like it was syncable, and no features
=== didrocks999 is now known as didrocks
[13:36] <Laney> LocutusOfBorg: it is, but the code doesn't make it simple so that's why it's not been done straight away
[13:36] <Laney> feel free to take a look
[13:40] <LocutusOfBorg> ack, I was wondering something more difficult to implement
[13:41] <LocutusOfBorg> btw, will you open an RC bug for gst-omx in Debian too?
[13:41] <LocutusOfBorg> I asked to trigger an autopkgtest
[13:41] <LocutusOfBorg> the full gst-stack in Ubuntu might be close to migration in one britney run
[13:42] <LocutusOfBorg> I mean, you opened a bug already, but I would raise it to RC
[13:42]  * LocutusOfBorg does it
[14:08] <LocutusOfBorg> looks like the Debian gst-omx is not failing, so probably also the Ubuntu one was good with the correct gst* triggers
[14:12] <seb128> LocutusOfBorg, l_aney said he fixed that one already
[14:12] <seb128> LocutusOfBorg, https://lists.ubuntu.com/archives/groovy-changes/2020-September/011185.html
[14:17] <Laney> LocutusOfBorg: I guess if you can prove it's broken in Debian, feel free to make it RC
[14:17]  * Laney likes tasty RC bugs
=== alan_g is now known as alan_g_
[14:49] <LocutusOfBorg> Laney, what I'm saying is that it wasn't broken at all in Ubuntu
[14:49] <LocutusOfBorg> https://ci.debian.net/packages/g/gst-omx/unstable/ppc64el/
[14:49] <LocutusOfBorg> it just needed the right gst trigger to pass... so I can't RC it :)
[14:57] <Laney> sad
[14:59] <xnox> juliank:  so apperantly it is hetzner machine, and it has grub-efi-amd64-signed installed, despite not being an EFI machine......
[15:00] <xnox> juliank:  it seems like grub-efi-amd64-signed is installed, yet the machine is non-efi one
[15:00] <LocutusOfBorg> I triggered the test with the right triggers, lets see
[16:08] <juliank> xnox: I shall upgrade my hetzner
[16:09] <juliank> xnox: i have a hetzner vps and I don't have efi grub
[16:10] <juliank> xnox: but yes, that's a valid configuration
[16:10] <juliank> xnox: that's why grub-* only upgrade grub, and don't install new grubs
[16:13] <LocutusOfBorg> waveform, hello, can you please forward rpi.gpio patches to debian next time?
[16:14] <LocutusOfBorg> I fixed your package, but please next time make it syncable, specially when packaging bugs comes from Debian...
[16:15] <LocutusOfBorg> oh well, there is a merge request with that change, nevermind
[16:15] <waveform> LocutusOfBorg, which patch is that (I don't recall touching rpi.gpio in aaages?)
[16:15] <waveform> (though it's on my list for the next cycle as we're way out of date on that and need to get gpiozero in too)
[16:16] <LocutusOfBorg> the readme file being wrong
[16:16] <LocutusOfBorg> <BTS> Opened #970728 in src:rpi.gpio 0.7.0-0.1 by Gianfranco Costamagna (locutusofborg) «rpi.gpio: bad debian/doc file». https://bugs.debian.org/970728
[16:16] <ubottu> Debian bug 970728 in src:rpi.gpio "rpi.gpio: bad debian/doc file" [Normal,Open]
[16:16] <LocutusOfBorg> <BTS> Opened #970726 (serious) in src:rpi.gpio 0.7.0-0.1 by Gianfranco Costamagna (locutusofborg) «rpi.gpio: FTBFS in sid (gcc-10)». https://bugs.debian.org/970726
[16:16] <ubottu> Debian bug 970726 in src:rpi.gpio "rpi.gpio: FTBFS in sid (gcc-10)" [Serious,Open]
[16:17] <LocutusOfBorg> and also the gcc-10 build failure in proposed
[16:17] <LocutusOfBorg> I'm NMUing the package in Debian so we can sync it again
[16:21] <LocutusOfBorg> waveform, well 0.7.0 looks like the latest stable to me
[16:21] <LocutusOfBorg> but in any case, I can do the "debian" uploads if you want
[16:21] <LocutusOfBorg> so the package doesn't get forgotten in Ubuntu, and is auto syncd
[16:24] <waveform> LocutusOfBorg, thanks - that would be good (it's on my list, along with the other gpio-related packages, to look at next cycle - and I need to look at moving the udev rules in rpi.gpio out of that package and somewhere in the base image)
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
=== dreaded_ is now known as dreaded