[00:05] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.2-4-g05926e48-0ubuntu1~16.04.1 => 18.2-4-g05926e48-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[08:40] <slangasek> Laney: do you have any idea why python-netaddr is installed on the autopkgtest web node? I was curious to see why ieee-data is installed on the node (and throwing cron errors), seems that's the revdep, and I don't see why it would be needed
[08:46] <Laney> slangasek: nope, sorry, but it's "manually" installed on the rabbitmq-sever/0 node too, which we don't really touch - so maybe something juju did
[08:48] <Laney> I like that you get these cron mails and I don't :-)
[09:27] <slangasek> Laney: oh, you're not getting these mails? lol
[10:32] <Laney> slangasek: I definitely have had emails from that instance in the past though :(
[10:32] <Laney> it's great how this is totally non shonky
[11:06] -queuebot:#ubuntu-release- Unapproved: vlan (bionic-proposed/main) [1.9-3.2ubuntu5 => 1.9-3.2ubuntu6] (core)
[11:41] -queuebot:#ubuntu-release- Unapproved: ifupdown (bionic-proposed/main) [0.8.17ubuntu1 => 0.8.17ubuntu2] (ubuntu-desktop, ubuntu-server)
[13:28] <juliank> Laney: https://code.launchpad.net/~juliank/autopkgtest/+git/development/+merge/344889
[14:28] <juliank> slangasek: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=94bffad136c7e12210ec4900881809a11a00067a broke the britney2 testsuite :(
[14:28] <juliank> and all the data in the excuses key is not available elsewhere
[14:29] <juliank> like for test_hint_force_skiptest, it says 'Should wait for tests relating to green 2, but forced by pitti'
[14:30] <juliank> (the test_autopkgtest.py)
[14:30] -queuebot:#ubuntu-release- Unapproved: heat (artful-proposed/main) [1:9.0.3-0ubuntu1 => 1:9.0.4-0ubuntu1] (openstack, ubuntu-server)
[14:34] <slangasek> juliank: ah.  well, if it needs to be reverted we can revert it, although in principle I'd still like this done because it substantially bloats the yaml and makes retry-autopkgtest-regressions much slower
[14:34] <slangasek> juliank: but in principle I think it's a change we should move forward with, even if we revert it in the near term
[14:37] -queuebot:#ubuntu-release- Unapproved: neutron-lbaas (artful-proposed/universe) [2:11.0.2-0ubuntu1 => 2:11.0.3-0ubuntu1] (openstack)
[14:43] -queuebot:#ubuntu-release- Unapproved: nova (artful-proposed/main) [2:16.1.0-0ubuntu1 => 2:16.1.2-0ubuntu1] (openstack, ubuntu-server)
[15:36] <cascardo> bdmurray: can you look into s390-tools for xenial-proposed?
[15:39] <bdmurray> cascardo: While the test case seems pretty straight forward the bug is missing the SRU template stuff.
[15:40] <cascardo> let me fix that
[15:54] <cascardo> bdmurray: I added the template
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (xenial-proposed) [1.34.0-0ubuntu8.6]
[16:22] <juliank> Laney: https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/344902
[17:09] <tsimonq2> Cosmic Canimal.
[17:09] <tsimonq2> Interesting one.
[17:11] <infinity> tsimonq2: That's CANIMAL, as in a placeholder for "Animal starting with C that Mark hasn't told me yet."
[17:12] <infinity> tsimonq2: You're watching git commits on your seeds, I guess? :P
[17:13] <tsimonq2> infinity: I have. :P
[17:14] <jbicha> infinity: can you set it to derive from buster (or maybe unstable)?
[17:16] <infinity> jbicha: buster doesn't exist in LP, it seems.  Maybe we only add them when they go stable.
[17:17] <infinity> Oh, yes it does.  But it's marked FUTURE, so doesn't really exist.  Only sort of.
[17:17] <infinity> It won't have packages in it.
[17:18] <infinity> Hrm, I say that, but it seems to have 27k sources.
[17:18] <infinity> Well, we'll see if it gives me the option.
[17:18] <tsimonq2> infinity: How did the Git branching part of the branch cycle script work out in prod? Did you have to tweak at all?
[17:19] <infinity> tsimonq2: branch-seeds worked fine, the one change I might make it changing the rename to a copy.  I know it doesn't make sense git-wise to have a copy of the checkout for each branch, but all the tools expect foo.series to exist (and have the right branch checked out), so...
[17:20] <infinity> tsimonq2: So, I'd probably change the pull/reset/rename/branch to pull/reset/copy/branch
[17:20] <tsimonq2> OK, cool.
[17:20] <infinity> tsimonq2: Otherwise, seemed fine.
[17:21] <infinity> tsimonq2: I mean, the move is non-fatal, since all seed updating stuff takes "directory doesn't exist" as a prompt to do a fresh checkout, just a bit weird to have foo.bionic disappear briefly. :)
[17:22] -queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [18.2-4-g05926e48-0ubuntu1~17.10.1 => 18.2-4-g05926e48-0ubuntu1~17.10.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[17:35] <wxl> infinity: you might want to change "canimal" to "some-unknown-animal-that-starts-with-c" if you wish to avoid confusion :)
[17:36] <infinity> wxl: I'm not deeply concerned about confusion.
[17:36] <infinity> wxl: Also, hi!  You're on the CC, right?
[17:36] <wxl> infinity: yep
[17:37] <infinity> wxl: Can you go to https://launchpad.net/~techboard/+members and extend us all by a month or so?  It's pretty clear we're not going to hold an election in the next two days.
[17:39] <infinity> wxl: I realize that extending terms without an election is how democracy dies, you can let the Washington Post know about it afterward.
[17:40] <tsimonq2> infinity: Ah, so I think I remember doing it that way just in case it broke something historical.
[17:41] <tsimonq2> If you're 100% sure it won't break jack, an MP (to the tooling that's still in Bazaar, feels ironic, let me know if there's anything I can do to help with that :P) will follow later.
[17:42] <infinity> tsimonq2: So, I think the safest would actually be to just go a fresh clone to foo.newseries, checkout oldseries, branch newseries.  If you're paranoid about there maybe being cruft in the working dir.
[17:43] <infinity> tsimonq2: (assuming the hard reset was due to the cruft paranoia)
[17:43] <infinity> tsimonq2: But a local cp would certainly be faster.
[17:43] <tsimonq2> infinity: OK.
[17:44] <infinity> tsimonq2: Not really picky either way.  And I recovered fine from the os.rename, obviously, just that it's not quite right.
[17:45] <infinity> tsimonq2: I guess keeping the existing code, but moving the cp above the hard reset would also have the desired effect.
[17:45] <infinity> tsimonq2: ie: cp -a olddir newdir / hard reset in newdir / branch newseries in newdir
[17:46] <infinity> But I think I've taken longer typing pseudocode than we would have taken just committing a fix. ;)
[17:47] <tsimonq2> infinity: ack
[17:49] <tsimonq2> infinity: And while we're at it, as much as I like Lubuntu's seed being in Git, is there a compelling reason not to JFD the conversion for all of them?
[17:49] <tsimonq2> I wrote a script that's on the wiki... :P
[17:50] <infinity> My fingers really don't like typing cosmic.
[17:50] <infinity> Keeps coming out at cosmis.
[17:50] <wxl> done, infinity
[17:50] <infinity> tsimonq2: We should convert them all, but obviously the flavours need to be involved to avoid surprises.  But yes, I think it's a solid goal to make sure that happens for everyone early this cycle.
[17:51] <infinity> wxl: Ta.
[17:51] <tsimonq2> infinity: I can do the email thing if ACK is your official answer.
[17:52] <infinity> tsimonq2: If you want to send out an email describing what the change will mean and getting sign-off, that'd be great.  I can do the actual conversions if everyone ACKs it, since I have commit to all the seees (obviously).
[17:52] <infinity> s/seees/seeds/
[17:52] <acheronuk> tsimonq2 has been bugging me for ages to do Kubuntu's. not going to do it today (as he would like) but quite soon I hope
[17:52] <infinity> So comforting to see that I can't type at all on a day where all my typos could be fatal.
[17:53] <tsimonq2> infinity: If I got branch access, I could save you the time... But I doubt that will happen. :P
[17:53] <tsimonq2> And yes, I will admit that I have begun "nagging" people mildly to convert the stuff.
[17:53] <tsimonq2> I'll send the email tonightish.
[17:54] <acheronuk> oh. if infinity wishes to do it whenever, fine by me
[17:55] <infinity> Yeah, I mean, no huge rush, but it's the sort of thing we should probably do in the first month, so you have 5 months to get used to it. :P
[17:55] <acheronuk> agreed!
[17:56] <infinity> This might be heresy, but I think my large coffee might have been too large.
[17:56] <flocculant> infinity: not heresy to me lol
[17:56]  * infinity resonates at an unfamiliar frequency.
[17:57] <tsimonq2> infinity: While we're at it, are there other branches that could be converted? I have a cool converter script and I've been converter happy... :P
[17:57] <infinity> tsimonq2: I'm sure there's a ton of stuff to convert.  But nothing I'm in desperate need of converting this instant.
[17:57] <tsimonq2> (*AHEM* hints) infinity: There's no such thing as a coffee that's too large. :P
[17:58] <infinity> tsimonq2: ubiquity comes to mind as an obvious candidate.  Except that if some of you are planning on being black sheep and swapping installers, maybe you don't care. :P
[17:58] <tsimonq2> I'm totally lagging here with IRC messages. Don't mind me.
[17:58] <infinity> (I'm honestly concerned about the swapping installers thing, given that one of the things that makes you an Ubuntu flavour is common infrastructure like that...)
[17:59] <infinity> If you think our response time is bad dealing with your installer bugs, being at the mercy of an upstream that doesn't really care about Ubuntu (and certainly not our release schedule) isn't going to make that better.
[17:59] <acheronuk> won't be happing for Kubuntu unless it is very solid AND has a real benefit to us
[18:00] <wxl> ubiquity comes to mind as a good candidate for overwriting with zeroes :/
[18:00] <acheronuk> translations is an issue as well
[18:00]  * flocculant can't see Xubuntu disagreeing with infinity
[18:00] <infinity> acheronuk: I'm entirely on board with the idea that another installer could have some benefits, but the release schedule carefactor goes a long way.  If they have cool features (or lack of certain bugs) that we need, we might be better served by embracing and extending. :P
[18:01] <acheronuk> certainly
[18:13] <tsimonq2> infinity: True, but I think it's worth trying.
[18:13] <tsimonq2> I also think that the Ubiquity codebase is a bit ... dated.
[18:14] <tsimonq2> There's pros and cons to it.
[18:14] <infinity> tsimonq2: Newer isn't inherently better.
[18:14] <wxl> i think the biggest problem with it is how disorganized it appears. it's fairly frankensteinish.
[18:14] <tsimonq2> I'm certainly not volunteering to un-KDE the Qt frontend.
[18:15] <tsimonq2> infinity: Right. But it's worth trying.
[18:15] <infinity> Maybe.
[18:16] <tsimonq2> And with us doing the LXQt switch for 18.10, that'll work out.
[18:16] <infinity> I think the ability to come screaming to your upstream a week before release is a hard advantage to quantify.
[18:16] <infinity> (Well, and to expect results from said screaming)
[18:16] <infinity> Unfortunately, un-KDEing the Qt frontend would have happened with a switch to unity8, but that didn't happen.
[18:17] <infinity> It really doesn't look like that much work to make it a bit more generic, though.
[18:18] <infinity> I'd probably start by forking the Qt frontend into a KDE frontend and Qt-generic, scrub the Qt-generic clean, then see if it can be merged back with some iffery to avoid code duplication.
[18:18] <tsimonq2> I want to try it for 18.10. If it doesn't break terribly, we'll continue. If it does, back to Ubiquity.
[18:19] <tsimonq2> Oh, and by the way, the LXQt switch is an official, public thing now. :)
[18:20] <tsimonq2> infinity: I might want a second set of eyes on the whole seed unmangling thing.
[18:20] <tsimonq2> We're also getting rid of alternates.
[18:21] <infinity> \o/
[18:21] <tsimonq2> And no-follow-recommends I think.
[18:21] <infinity> \o/!
[18:22] <tsimonq2> Speak now if I'm missing anything else.
[18:22] <cjwatson> I think the best thing to do with ubiquity would be to start putting together a dbus backend for all the rootly things it does
[18:22] -queuebot:#ubuntu-release- Packageset: 6652 entries have been added or removed
[18:23] <infinity> cjwatson: Wayland, here we come?
[18:23] <cjwatson> Once that exists usefully, it'd be a lot easier to make the frontends saner
[18:23] <cjwatson> For that and other reasons, yes
[18:23] <infinity> cjwatson: (well, and also, get thee hence, pkexec)
[18:23] <cjwatson> Yeah, the release day panic this time round wouldn't have happened with that architecture
[18:23] <infinity> cjwatson: I agree entirely, but the harder part is being able to scope the work and block it off in someone's schedule.
[18:24] <infinity> cjwatson: PS: Welcome back to Foundations?
[18:24] <infinity> *cough*
[18:24] <cjwatson> Sure, I'm just advocating for it.  And nope, not doing it :)
[18:24] <tsimonq2> My thoughts.
[18:24] <tsimonq2> Calamares is the easy way out. :P
[18:25] <infinity> You're putting a lot of faith in a relatively untested codebase.
[18:25] <tsimonq2> Then let's test it. :P
[18:25] <flocculant> you go ahead :p
[18:26] <infinity> Also, installers are one of the areas where distros historically differentiate.  You won't be able to sell Mark on us using a generic installer upstream.
[18:26] <infinity> Which means Ubuntu will always have a different one.
[18:26] <infinity> WHich means no help from us when yours breaks.
[18:27] <tsimonq2> OK.
[18:30] <infinity> Now, with that said, the move from unity/lightdm back to gnome-shell/gdm certainly does infer that we're attempting to keep our desktop offering slightly less scarily different, so if Calamares could be heavily themed, hacked, cut down, and made to be Ubuntuish (ask fewer questions, proper debconf integration for final system configuration, blah blah), it's not entirely implausible that we could use it.  But we also have our own ideas about ...
[18:30] <infinity> ... how to ship things that might just be fundamentally incompatible with their design.
[18:30] <tsimonq2> Well, it's a QML frontend.
[18:30] <infinity> Like stacked squashes (which we should probably do this cycle in ubiquity), or more silly little things like upstream telling you that we're "wrong" for saving tens of MBs of disk space by not shipping two identical kernels and initrds.
[18:30] <tsimonq2> So that might not be a thing.
[18:31] <tsimonq2> But it's all YAML-based and modular, so it makes it super easy.
[18:31] <infinity> After all, why would you want your installer ISO download to be smaller?  We're clearly crazy people.
[18:32] <tsimonq2> And irt the kernel thing, we're working with Neon (who has paid employees) for a more permanent patch.
[18:32] <tsimonq2> But yeah.
[18:32] <tsimonq2> That's a thing.
[18:35] <tsimonq2> infinity: One thing about that though. I'm not exactly sure where to find the code for e.g. "Install Lubuntu" on the boot menu. Caspar?
[18:36] <tsimonq2> Steve told me at one point but I'd have to search for those logs.
[18:36] <infinity> tsimonq2: debian-cd
[18:36] <tsimonq2> Ah.
[18:37] <tsimonq2> That sounds right. Thanks.
[18:37] <infinity> It sounds right because it is right.
[18:37] <tumbleweed> sound plausible? 19.10,Cosmic Canimal,cosmic,2018-04-26,2018-10-18,2019-07-18
[18:37] <infinity> tumbleweed: Except that "CANIMAL" is a placeholder. :P
[18:37] <infinity> tumbleweed: I wouldn't do any official d-i-d release yet.
[18:37] <tumbleweed> is *that* why there's no blog post
[18:38] <wxl> yep
[18:38] <wxl> and apparently adam is trying to culture confusion by keeping the darn canimal there :)
[18:38] <tsimonq2> Wait, 19.10?
[18:38] <infinity> tumbleweed: I'll do an ubuntuX revision to cosmic with the placeholder, but hold off on the upstream update until Mark animals us, IMO.
[18:38] <tumbleweed> 18.10 even :P
[18:38] <infinity> I'm mildly amused at the non-zero number of people who think CANIMAL is an animal.
[18:39] <tsimonq2> wxl: So "animaling" is a verb now. :P
[18:39] <tsimonq2> infinity: I thought it was at first.
[18:39] <tsimonq2> ¯\_(ツ)_/¯
[18:39] <tumbleweed> infinity: it wasn't that, I was just trusting LP
[18:39] <jbicha> it's because Mark tends to make up animal names. The delay in getting official names is because he has to get it inserted into the dictionary first!
[18:40] <tsimonq2> Hah.
[18:40] <infinity> We've only had three fake animals so far, and he didn't make any of them up!
[18:40] <infinity> Three?  I think three.
[18:40] <infinity> Jackalope, Unicorn, Werewolf?
[18:40] <jbicha> jackalopes are real! I totally saw artifacts of them in the American West
[18:41] <infinity> Heh.
[18:44] <tsimonq2> infinity: So when can I do my Qt transition? :P
[18:44]  * tsimonq2 runs
[18:46] <wxl> infinity: speaking of ubiquity tsimonq2 is telling me we can't change the window titles from kubuntu to lubuntu because it's hardcoded. is that for real?
[18:46]  * xnox is not sure if Canimal is a placeholder, or an actual reference to Canimals the animated series..... https://www.google.co.uk/search?q=canimals&tbm=isch
[18:47] <xnox> infinity, if this one is Canimal, i want next NN release be Neopet then.
[18:47] <wxl> xnox: i tried to warn adam about that but he's not concerned. therefore, i beileve we should culture the notion that it's actually NOT a placeholder
[18:47] <tsimonq2> YES XD
[18:48] <infinity> wxl: Probably, but it's just code.
[18:49] <wxl> infinity: can you point me at where in the code that is?
[18:49] <tsimonq2> In the KDE frontend.
[18:50] <tsimonq2> The *ahem* /KDE/ frontend.
[18:50] <infinity> wxl: Checkout ubiquity, 'rgrep -i kubuntu'
[18:50] <infinity> Looks like there are some hardcoded translation strings too, but that's easily fixed.
[18:52] <wxl> ok so it seems like https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/kde_ui.py#L80
[18:54] <wxl> so it seems like we should be able to fix this, @tsimonq2. it'll just take some work to pass distro as an argument, as gtk supports
[18:55] <tsimonq2> Knock yourself out.
[18:55] <tsimonq2> Not ir.
[18:55] <tsimonq2> *it
[18:55] <tsimonq2> There's also theming.
[18:56] <xnox> the gtk frontend is slightly better in that sense, and reads the .disk-info stuff to get the appropriate $BUNTU name
[18:56] <wxl> maybe the nice kubuntu folks would be nice to generalize their qt frontend
[18:56] <xnox> i guess this pre-dates that being available on disk.
[18:56] <xnox> cause back in the date qt == kubuntu; gtk == ubuntu.
[18:56] <xnox> cause back in the day qt == kubuntu; gtk == ubuntu.
[18:57] <tsimonq2> Yeah.
[18:57] <tsimonq2> wxl: They've said "no" to that.
[18:57] <tsimonq2> And I don't blame them.
[18:58] <wxl> why? it opens it up to other flavours to go qt
[18:58] <tsimonq2> I don't think this was designed in a way where any other desktop would be Qt within Ubuntu.
[18:58] <tsimonq2> It's going to be painful.
[19:23] <tsimonq2> infinity: I'm assuming the cosmic-changes mailing list is not set up correctly on purpose?
[19:24] <tsimonq2> In that case, you might have to manually approve my subscription, even after it's opened up.
[19:36] <acheronuk> awaiting moderator approval....
[19:37] <acheronuk> to be fair, it's not showing on lists.ubuntu.com yet :P
[19:54] <blackboxsw> RAOF: we have a couple of cherry pick SRU's for cloud-init into xenial and artful with a bug fix for customers. if there is time to queue them today or tomorrow morning to get the pending-sru counter started that'd be great.
[19:55] <blackboxsw> cloud-init 18.2-4-g05926e48-0ubuntu1~(16.04.2|17.10.2)
[21:12] -queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42+18.04.1 => 2.42+18.04.2] (no packageset)
[21:13] -queuebot:#ubuntu-release- Unapproved: boinc (bionic-proposed/universe) [7.9.3+dfsg-5 => 7.9.3+dfsg-5ubuntu1] (no packageset)
[21:59] <bdmurray> infinity: I'm not seeing any upgrade issues from A to B worth continuing to not have that upgrade path enabled.
[22:00] <infinity> bdmurray: The trigger loop thing still concerns me a tiny bit, but I haven't had a chance to attempt to dissect it.  Have you?
[22:00] <infinity> bdmurray: I think fixing the ones we know changed post-xenial is still the Right Thing, but you noted that didn't fix the test case you had.
[22:01] <bdmurray> infinity: Installing libc6 from bionic fixes it. Also that is an issue from the upgrade from X to B, so enabling A to B wouldn't matter.
[22:01] <infinity> bdmurray: Mostly, that concerns me because it's a hard failure from dpkg, which only reasonably savvy users can recover from.
[22:02] <infinity> bdmurray: Oh, A to B.  Derp.  Yeah, if you see no issues with A to B, go for it.
[22:02] <bdmurray> infinity: I updated the bug 1766890 with my findings
[22:03] <infinity> bdmurray: Curious that upgrading libc6 would fix it.  I didn't change the libc-bin trigger config, did I?
[22:03] <bdmurray> infinity: There was one change there yes, but doing it on disk in the trigger in /var/lib/dpkg/info didn't fix it. Although that might be a crazy test.
[22:04] <infinity> bdmurray: Hrm.  Well, we have a couple of months to try to unwind that.  Put it on the standup nag list until we're sure it's solid.
[22:05] <infinity> bdmurray: I'd argue that do-release-upgrade should probably be forcing apt and dpkg to upgrade first anyway, though that wouldn't fix apt-get dist-upgrade.
[22:05] <infinity> bdmurray: OTOH, apt-get might force that order anyway, and it could be a d-r-u specific bug cause we drive python-apt in a silly way.
[22:07] <infinity> bdmurray: Anyhow, TLDR: A->B, go nuts; X->B, let's keep an eye on it.
[22:08] <tsimonq2> infinity: How willing are you to help Lubuntu decruft the stuff we explicitly grab from that no-install-recommends bug?
[22:09] <infinity> tsimonq2: Do you mean implicitly?
[22:09] <infinity> tsimonq2: And I can offer advice here and there, but I'm not prepared to commit to anything.
[22:09] <tsimonq2> infinity: OK.
[22:10] <tsimonq2> infinity: I'm working on it now and I'll commit something (then send that email) soonish.
[22:10] <infinity> tsimonq2: jbicha and darkxst have the most experience in this area after years of trying to make Ubuntu and Ubuntu GNOME not hate each other, but I'm not going to volunteer either of them either. :P
[22:11] <tsimonq2> infinity: Alright. :P
[22:11] <tsimonq2> infinity: A quick sanity check once it's all committed would be cool.
[22:11] <infinity> A lot of prior art in GNOME packages back in xenial, though, to attempt to make sure both desktop got what they wanted without pulling the other in.
[22:11] <tsimonq2> infinity: Plus, I have to revert/refactor some tooling changes we made for this hackery.
[22:11] <tsimonq2> Ah.
[22:12] <infinity> If your concern is less about accidentally pulling in half of KDE and more just making sure that your recommends aren't needlessly bloated, evaluating questionable recommends for suitability to downgrade to suggests isn't too much effort.
[22:13] <tsimonq2> Right.
[22:13] <infinity> At the end of the day, though, I'd say the classic Lubuntu seeds with no-follow pulled in far too little stuff.
[22:13] <tsimonq2> I just don't want to make sure I don't mess this up. ;)
[22:13] <infinity> Most recommends are there for solid reasons.
[22:13] <infinity> Just not all of them.
[22:13] <tsimonq2> I'd agree.
[22:14] <mwhudson> clearly we need new fields
[22:15] <infinity> tsimonq2: The simplest view, IMO, is just to commit the no-follow-removal change locally, aim your meta ./update at it, and debdiff the results.  Then go hunting for the added bits that look super wrong.
[22:15] <mwhudson> suggests/recommends/likes/would-recommend-but-security-laughed-at-the-mir/
[22:16] <tsimonq2> hahahahahahahahahaha
[22:18] <Ukikie_> I dunno, trying out calamares kind of sounds nice with the strange bugs ubiquity tends to get.
[22:18] <wxl> ^^^ and the difficulty in trying to figure them out, regardless of how close the codebase is
[22:19] <tsimonq2> Yeah.
[22:20] <tsimonq2> It's why I think the benefits might outweigh the downsides.
[22:20] <wxl> tbh it's not like one has problems and the other one doesn't. they both have problems. but, if calamares works out for us, then maybe it's something ubuntu can consider for everyone, in which case the downsides to it are far less
[22:21] <tsimonq2> Right.
[22:21] <Ukikie> Ubiquity broke pretty much right before release for me, and I'm not even sure what specifically is broken.
[22:22] <tsimonq2> Me neither. I don't know what weird permissions pkexec dbus something or other broke.
[22:33] <bdmurray> infinity: Thinking back you said fixing the triggers was the Right Thing, do you think we should still do that regardless?
[22:35] <infinity> bdmurray: Yeah.
[22:36] <bdmurray> infinity: Any suggestions on SRU template info for those?
[22:36] <infinity> bdmurray: The libc-bin trigger change shouldn't change anything, it went from interest to interest-await, which is pretty much the same thing.
[22:37] <infinity> So I'd say that upgrading libc6 early is just perturbing the upgrade order enough to paper over the real loop.
[22:38] <bdmurray> Yeah, its weird that a standard Ubuntu install doesn't encounter it either.
[22:38] <infinity> bdmurray: Not sure what to do for bugs for those.  Maybe just manually check (with diff) that the installed triggers in the SRUed packages match the state of things in bionic?  I can't really think of a good test.
[22:39] <infinity> bdmurray: They also need one-by-one investigation to make sure that the trigger changes didn't also come with packaging changes that allowed deferred triggers to be okay.