[07:06] <wrsuser> In theory, should it be possible for me to run (from within a 20.04 VM) the 'debian-installer build system' (which I've never used) and it'll create me an ISO similar to that mini.iso file (that Canonical/Ubuntu keeps saying shouldn't be used and isn't going to be built from now on)
[07:07] <wrsuser> presumably the 'debian-installer build system' would build an ISO that uses the nice old purple (or blue in Debian's case) text-mode installer... and uses debootstrap and APT I'm guessing to get everything done (rather than imaging?)
[07:36] <toabctl> bdmurray, hey. can can we proceed with lp:140136 ? it seems to be blocked by lp:1949116 and we (the CPC team) would like to SRU things for livecd-rootfs .
[07:36] <toabctl> bdmurray, I mean "proceed with lp:1940136" ...
[10:38] <LocutusOfBorg> bryceh, hello, can I ask you something w.r.t this change? https://launchpad.net/ubuntu/+source/php-apcu/5.1.20+4.0.11-0+deb11u1ubuntu1
[10:38] <LocutusOfBorg> its making this package FTBFS https://launchpad.net/ubuntu/+source/php-doctrine-cache/1.12.1-1
[10:38] <LocutusOfBorg> I don't know if I have to patch doctrine-cache to depend on the php-apcu-bc directly, or revert the php-apcu change
[10:41] <LocutusOfBorg> oh well, the apc.so is gone anyway
[10:44] <LocutusOfBorg> utkarsh2102, ^^ any idea?
[13:45] <jdstrand> mfo: hey, I did the sru testing for bionic and focal for bug #1933117 and marked those done. For bug #1946804 I commented on the testing I did but didn't mark as done since I didn't do iSCSI tests (though I'm not sure it is required, but I'll let others decide). I don't have a hirsute machine handy so didn't test that. if required, I could create a vm and do it
[13:47] <mfo> jdstrand, hey o/ thank you!  ok, cool. no worries, i'll also do some testing, and can cover hirsute. all good :)
[13:47] <jdstrand> mfo: thanks for that and doing the sru! :)
[13:48] <mfo> jdstrand, no problem! it's been great working w/ you.
[13:48] <jdstrand> you too :)
[14:00] <rbasak> mapreri: thank you for preparing bug 1832998. I'm not sure I agree with adding debian/patches/ in a 1.0 format package anyway as I think that's confusing, but I don't think it's worth being picky about that. But you've _also_ got a bunch of .pc noise in your upload. Maybe that's a bit too much?
[14:01] <rbasak> I'm also trying to ignore some of the non-functional indentation changes
[14:10] <rbasak> git-ubuntu is basically caught up now
[14:10] <rbasak> I'm retrying a handful of errored imports most of which were probably due to transient network/API availability issues.
[14:22] <mapreri> rbasak: if you think it's best I guess I can rm debian/patches and .pc
[14:23] <mapreri> what I did was to quilt init; quilt import; quilt push -a; done.
[14:24] <rbasak> mapreri: I'm open to being persuaded otherwise, but this is a pattern I've never seen before.
[14:24] <mapreri> I'd rather 1.0 died if you ask me :\
[14:24] <rbasak> Sure :)
[14:24] <rbasak> It feels really wrong to ship a .pc directory though?
[14:24] <rbasak> I get there is some benefit eg. dep3 headers in debian/patches/
[14:24] <dbungert> LocutusOfBorg: TJ-: LP:#1945596 mentions some pastes that have since expired, do you think that's useful information for the bug?
[14:25] <rbasak> I also get that shipping .pc means that quilt state is matched with the source tree
[14:25] <rbasak> It does make the diff really noisy though for what is actually a really small patch
[14:26] <mapreri> the point of the .pc is: if somebody dgets the source, a quilt pop would work, otherwise it wouldn't.
[14:26] <mapreri> but as I said, I don't care either way, it's unlikely I'll ever touch that thing again, so
[14:27] <rbasak> Yeah I see what you're achieving by doing what you did
[14:27] <mapreri> now I need to remember where in my file system I did that thing
[14:27] <mapreri> hopefully it wasn't /tmp :3
[14:28] <rbasak> I'm just skeptical that it will cause more confusion than benefit from the problem it solves
[14:28] <mapreri> oh, it *is* /tmp, but I didn't yet reboot! :D
[14:28] <mapreri> let me show you a different diff
[14:30] <mapreri> rbasak: https://paste.debian.net/1218067/ ? :)
[14:31] <rbasak> mapreri: I much prefer that, and appreciate the README. Thanks!
[14:31] <mapreri> rbasak: feel free to reject the current version then.  I'll build, try it out real quickly and upload again
[14:31] <mapreri> luckily it's a tiny package
[14:32] <rbasak> Done. Thanks!
[14:33] <mapreri> (also note how I dropped d/p/series to reduce potential confusions)
[14:37] <mapreri> ddstreet, teward: did you have a chance to read my changes to the wiki?  I think it's quite relevant for the upcoming meeting today.
[14:42] <teward> i've been a bit busy, reading shortly
[14:42] <teward> (FT job keeping me busy)
[14:42] <mapreri> rbasak: uploaded, if you want to look again right away
[14:43] <mapreri> (I already tested it)
[14:44] <rbasak> ack
[15:00] <TJ-> dbungert: the namespace reproducer would be but not sure I can reproduce it now, looks like I was doing some ad-hoc messing about based on looking at what the log shows the test doing
[15:11] <bdmurray> toabctl: we are fixing 1949116 now so you should be able to verify the fix for bug 1940136 real soon now
[15:31] <TJ-> dbungert: I've added the missing namespace reproducer and explanation as to the cause of the autopkgtest failure
[15:32] <dbungert> TJ-: nice, thanks.
[15:59] <toabctl> bdmurray, ack. thx!
[18:54] <LocutusOfBorg> dbungert, I don't think something useful un such pastes...
[18:55] <LocutusOfBorg> I'll have a look
[19:02] <TJ-> LocutusOfBorg: there was; I've added the info, and the bug cause, in a new comment
[19:05] <LocutusOfBorg> TJ-, what about joining #firewalld? :)
[19:06] <TJ-> LocutusOfBorg: why?
[19:06] <LocutusOfBorg> so you can talk directly with upstream
[19:06] <LocutusOfBorg> he is asking me stuff I don't really understand
[19:07] <TJ-> the autopackagetest failure isn't upstream issue; it's caused by Ubuntu packaging config of NetworkManager
[22:00] <mwhudson> is there some way i can make ubuntu-drivers list --gpgpu return something in a vm?
[22:07] <TJ-> mwhudson: see tests/test_ubuntu_drivers.py::gen_fakehw() ... maybe there's a clue there