[08:27] <seb128> vorlon, can you badtest fpc/i386?
[08:29] <seb128> vorlon, doko, Saviq, mir/i386 autopkgtest fails on 'Depends: gcc:i386 but it is not going to be installed' ... is that depends wrong or is that an archive issue?
[13:45] <rbasak> Does "git ubuntu import-local" work for anyone currently (from the edge snap)? AFAICT, it's broken, so I'm struggling to not break it further when fixing an unrelated bug :-/
[13:45] <rbasak> If someone has a currently working use case for it, I'd like to know so as not to break it further.
[13:45] <rbasak> (it's a separate effort to fix and add tests for the broken bits of the CLI; I'm just trying to make some progress)
[14:06] <ahasenack> rbasak: has never worked for me (import-local)
[14:08] <rbasak> Thanks
[14:27] <seb128> vorlon, can you badtest upower/i386, it's failing because it tries to install python/gobject packages and that fails
[15:03] <gpiccoli> Hi rbasak and sil2100 , good morning/afternoon! Sorry to bother, I've updated LP #1847924 with the modified mdadm patch for SRU, I'd like to ask you to take a look if possible and...maybe sponsor it =))
[15:03] <gpiccoli> Thanks in advance!
[15:35] <rbalint> cpaelzer, how about forwarding this upstream? https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c05586d9da033bbfd6b6a74e10b87520843c7c48
[15:46] <cpaelzer> rbalint: did it work relialbly?
[15:46] <cpaelzer> back then we said we only want to suggest that if it works out to be helpful
[15:47] <cpaelzer> you look at those tests results more often I guess
[15:47] <cpaelzer> did this really help?
[15:47] <rbalint> cpaelzer, i think so, at least we carry this for some time so it is either harmless or working
[15:47] <rbalint> cpaelzer, i did not run tests without it :-)
[15:48] <cpaelzer> yeah, back then it was hitting ~50% or more
[15:48] <cpaelzer> I can submit it, but not today
[15:48] <cpaelzer> put it on my todo list
[15:48] <rbalint> thanks!
[16:11] <seb128> LocutusOfBorg, hey, do you know what's the dela with virtualbox's autopkgtest in focal? it's blocking libnotify but from the log it's pretty consistently failing
[16:21] <juliank> If anyone sees the new python-apt 1.9.1 in experimental and thinks oooh sync time: please don't, it will regress security. thx!
[16:21]  * juliank will have a fixed one later today or (probably) tomorrow
[16:32] <seb128> juliank, hey, could you have a look to bug #1849773 at some point? If not I think I will just drop the patch in a next upload because I've no document to trigger the problem/work on it and the segfault is worth than the weird char issue
[16:32] <juliank> seb128: oh yes, thanks for the reminder
[16:33] <seb128> juliank, thanks for having a look to it :)
[16:36] <juliank> seb128: But FWIW, if you want a PDF that triggers the rendering issue, you should be able to take any PDF, and just run ocrmypdf on it to reproduce the issue
[16:39] <juliank> Oh, I noticed that it's not the current patch I sent upstream, that one should not have the crash https://gitlab.freedesktop.org/poppler/poppler/merge_requests/280
[16:40] <juliank> Because it does not look at the font name
[16:42] <LocutusOfBorg> seb128, the 6.0.14-dfsg-4 should be good
[16:42] <LocutusOfBorg> but I don't know why it is not marked as such
[16:43] <LocutusOfBorg> oh... the kernel has bundled the very same version, so it doesn't get built
[16:44] <LocutusOfBorg> I suspect you can just add one hint
[16:57] <LocutusOfBorg> seb128, something to deal with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848788
[16:57] <LocutusOfBorg> cascardo, ^^
[16:57] <LocutusOfBorg> I suspect we should make dkms fail less badly
[16:57] <LocutusOfBorg> or hint the test
[17:01] <vorlon> seb128: hi, so for any package whose tests are currently failing on i386 we *should* badtest them in order to not block other packages, the question is whether we should be badtesting only the current version or badtesting it permanently; so if you could be explicit about whether you're asking for a temporary override or a permanent one, that would help streamline
[17:02] <vorlon> seb128: mir/i386: test dep on gcc is probably wrong, as opposed to 'build-essential' which we handle.  That test should be fixed and made cross-build-friendly
[17:04] <vorlon> seb128: upower/i386 hinted (because you gave rationale :)
[17:26] <seb128> vorlon, thx :)
[17:27] <seb128> vorlon, I think http://autopkgtest.ubuntu.com/packages/n/nghttp2/focal/i386 also goes down to want python and might be a candidate for badtest?
[17:27] <seb128> vorlon, unsure about http://autopkgtest.ubuntu.com/packages/libo/libomxil-bellagio/focal/i386 which is the other one blocking firefox
[17:30] <vorlon> ok looking
[17:30] <vorlon> seb128: meanwhile, if you happen to know why my latest gst-plugins-bad1.0 upload ftbfs on i386, I'm trying to get that landed to prune opencv, numpy, node, ... from the i386 set
[17:32] <vorlon> seb128: nghttp2 looks fixable to me, nghttp2-proxy could possibly depend on python3:any instead of python3; I'll add it under 'needs investigation'
[17:54] <vorlon> seb128: libomxil-bellagio: -doc packages being uninstallable is generally fixed by just marking those packages Multi-Arch: foreign
[18:00] <vorlon> Depends: [...] binutils, build-essential, [...]
[18:00] <vorlon> ok then
[18:41] <vorlon> seb128: had to dig into fpc a bit, but yeah, badtested now (I satisfied myself that a) the i386-specific packages are usable, and b) it's impossible to construct a correct test-dependency field for this package under the current autopkgtest implementation because its test deps conflict with build-essential :P)
[22:54] <wpk> Could I interest someone in  https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1810154 ? Bug is diagnosed, patch is attached, it just needs to go into the release. It's effects are quite annoying...
[22:56] <sarnold> wpk: oooh, would that let you use zfs native encryption for eg / or /boot or similar?
[23:00] <wpk> sarnold: I'm using native ZFS encryption for /
[23:01] <sarnold> nice; I'm using LUKS underneath zfs for that, and ... it works, but it feels brittle
[23:01] <wpk> sarnold: there were two bugs - one in zfs-initramfs (fixed, fix released), that's the second one - it's still possible to use native ZFS encryption but because of this bug I get dropped to initramfs because plymouth can't ask for password
[23:04] <wpk> rpool/ROOT/ubuntu on / type zfs (rw,relatime,xattr,posixacl)
[23:04] <wpk> NAME   PROPERTY    VALUE        SOURCE
[23:04] <wpk> rpool  encryption  aes-256-gcm  -
[23:05] <wpk> I've been using it for over a month now, no problems at all with the stability. Installation is annoying, but that's a one time effort
[23:06] <wpk> sarnold: anyway, it'd be nice for this one to be fixed :)
[23:27] <sarnold> wpk: heh, yeah, what I've got now has *worked* for a few months, but it wasn't fun to install :)
[23:29] <sarnold> wpk: did this patch come from upstream plymouth dev? debian? some other distro?
[23:29] <sarnold> wpk: some links about where it came from might help
[23:38] <wpk> sarnold: I made it
[23:39] <sarnold> wpk: cool cool :) getting it into the upstream releases would probably make it more likely to be included in ubuntu
[23:41] <wpk> sarnold: IIRC it's an ubuntu-only bug - it comes from one of the patches
[23:42] <wpk> $ cat misc-changes.patch
[23:42] <wpk> Description: Undocumented changes
[23:42] <wpk>  This patch contains undocumented changes accumulated during previous
[23:42] <wpk>  versions of the Ubuntu plymouth package, that have not yet been split up
[23:42] <wpk>  into individually-documented patches.  Please try not to add further things
[23:42] <wpk>  to this patch.  Using quilt for new changes is recommended, but if you
[23:42] <wpk>  don't, they'll end up in a separate debian-changes patch at the end of the
[23:42] <wpk>  patch series.
[23:42] <wpk> Last-Update: 2011-01-21
[23:42] <wpk> riiiight....
[23:43] <sarnold> oh my
[23:43] <sarnold> that's some real spelunking there
[23:57] <cjwatson> Heh, I thought that looked familiar, apparently I wrote that
[23:57] <sarnold> :)
[23:57] <cjwatson> Since they were the bits I couldn't understand
[23:58] <cjwatson> (Don't ask me about them, partly for that very reason, and partly because it was nearly nine years ago and I remember nothing)