[13:42] <rcj> sil2100: Would you have time to look at the livecd-rootfs xenial SRU today?
[13:50] <sil2100> Sure o/
[13:57] <sil2100> bdmurray, juliank: hey! Could one of you upload a new python-apt with the mirror lists updated etc. for .2?
[14:08] <juliank> sil2100: yes
[14:10] <rcj> sil2100: Thank you!
[14:12] <rcj> vorlon: We have an interesting question regarding the 'unminimize' script in livecd-rootfs today in lp: #1912595.  The user take the minimal image, customizes the image, and then from that wants to master a production image (as-is) and a developer image by running unminimize.  Their customizations install things with -no-install-recommends.  They'd like a change to unminimize to allow that to be passed
[14:12] <rcj> through.  Thoughts?
[14:17] <vorlon> rcj: they can set that in /etc/apt/apt.conf.d instead; I don't think it should be part of the unminimize tool, when recommends are installed by default for a reason
[14:18] <rcj> Ah, that would work.  I'll make that recommendation.  I like that better than adding a flag to the unminimize script.
[15:23] <juliank> sil2100: python-apt uploaded
[15:48] <bdmurray> sil2100: my thought was there was a security update a couple of weeks ago so that should be good
[16:11] <juliank> bdmurray: that was early December when we updated the mirror list, the regression update only fixed the regression
[16:11] <juliank> Hence I pushed an update to proposed for the mirror list
[16:16] <sil2100> juliank, bdmurray: thanaks!
[16:16] <sil2100> *thanks
[16:17] <bdmurray> juliank: alright, I'll look closer next time!
[16:17] <bdmurray> sil2100: Are you going to review it?
[16:19] <sil2100> bdmurray: could you take a look at it? Since I'm doing an SRU publishing round first - and afterwards I might have another SRU review for you!
[16:23] <bdmurray> sil2100: I'll review python-apt and ubiquity for Focal.
[16:25] <sil2100> Thank you! Wait with the ubiquity review, I'll quickly release what's in -proposed
[16:26] <sil2100> Ok, ubiquity now released, you can proceed
[16:33] <juliank> bdmurray: I plan to rename apt apport hook file DpkgHistoryLog to AptHistoryLog so I can include actual dpkg.log as DpkgLog
[16:33] <juliank> Also I plan to add AptEIPPLog and AptEDSPLog
[16:33] <juliank> because that's the stuff that really matters
[16:33] <juliank> :D
[16:34] <juliank> Not sure if that needs work anywhere
[16:34] <juliank> but DpkgHistoryLog is so confusingly named, it's not helpful
[16:34] <juliank> EIPP log contains the log from the installation planner, allowing to reproduce installation ordering issues
[16:35] <juliank> EDSP log is the same for dependency solving
[16:35] <juliank> I want to get to the point where if stuff fails to resolve, we get an EDSP/EIPP log such that we can feed the tool with it and don't need apt-clone system states to reproduce
[16:35] <juliank> as apt can consume those problems directly and solve them
[16:36] <bdmurray> juliank: hmm, something might be looking at DpkgHistoryLog.
[16:36] <juliank> But I need to do some digging to figure out if I actually get the eipp/edsp logs i'm interested in from the hook or whether they were from a previous run :D
[16:37] <juliank> bdmurray: OK; it's not super urgent, just something on my mind for some time in the future
[22:03] <tjaalton> sergiodj: hi, 389 logs should show more, re: dogtag error
[22:22] <sergiodj> tjaalton: hi.  ok, I'll try to look into it when I have more time
[22:22] <sergiodj> thanks