[08:33] <seb128> bdmurray, hey, I'm unsure how you keep up with SRU bugs comment, so please have another look to bug #1832457 (also would be nice to not block SRUs in such cases when it's clear that the new serie isn't going to miss the update/fix)
[10:19] <juliank> This KDE phabricator thing is crazy
[10:31] <juliank> When submitting it rewrites your last commit
[10:31] <juliank> It's like it's written for a single commit
[13:00] <ahasenack> hi, is there precedent in transforming a native ubuntu package into a non-native in ubuntu? Both in a devel release, and in srus?
[13:00] <ahasenack> is that frowned upon?
[13:01] <ahasenack> by sru, I mean a package that is native currently in a stable release, becoming non-native via an sru (there are other changes in the sru though, not just this)
[14:08] <ximion> hey Laney :)
[14:09] <ximion> I was just made aware that the LMDB dependency of AppStream is actually an issue for Ubuntu, as LMDB isn't in main (yet?)
[14:10] <Laney> correct
[14:12]  * Laney has tried to shift the paperwork onto acheronuk 
[14:17] <ximion> Laney: of course in my opinion LMDB should be in main (you could enable it for bind9, postfix etc. as well then), but if there's anything I can help with, let me know
[14:17] <ximion> (in the very worst case, AS could also run without cache, but that would be significant effort to make it work for terrible performance and memory usage)
[14:18] <ximion> fortunately, LMDB is tiny, depending only on libc
[14:18] <Laney> usually the main problem is if the MIR team decides to ask for a security review
[14:18] <Laney> then it can take a while
[14:23] <Laney> ximion: it's fine, we have this semi frequently, but it may delay any updates to appstream for a long while
[14:24] <Laney> so in general (if you want to care about this situation), making new runtime deps conditional is nice
[14:26] <ximion> Laney: I don't forsee any additional dependencies for AppStream - the library should really be quite small, all the annoying stuff (like font rendering and image scaling) should end up in asgen anyway
[14:26] <ximion> a security review is sensible - I was just looking on whether RHEL has it yet, but it's only in EPEL there, at least for the current version
[14:27] <Laney> I think suse has a similar procedure?
[14:29] <ximion> jup - SUSE already has LMDB in the trusted zone (at least for openSUSE) though due to KDE depending on it
[14:29] <ximion> (also RPM has a LMDB backend)
[14:29] <ximion> I couldn't find any info on what SLE does though, which is more relevant
[14:36] <sil2100> Laney: hmmm, it looks like britney dies for xenial since over a week: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/13:46:56.log
[14:37] <sil2100> Laney: do you, by any chance, know this part of britney?
[14:38] <Laney> sil2100: not off the top of my head, but I think we have a FauxPackage for snapd if the message just before the traceback is relevant
[14:38] <Laney> those are in b1
[14:43] <sil2100> Laney: ah, indeed! You think removing the faux package might help? I guess I can try that, since snapd now builds on powerpc
[14:43] <sil2100> (at least it provides 'some' powerpc binaries)
[14:43] <Laney> is that what changed around the time it started breaking?
[14:44] <sil2100> Laney: yeah, that would fit, since the new snapd landed on the 11th, which was when the last time britney ran without crashing on xenial
[14:44]  * sil2100 reverts and hopes for the best
[14:46] <sil2100> Laney: do you know if such britney crashes are sent somewhere when they happen? Like some notification
[14:47] <Laney> sil2100: probably the mailbox on snakefruit that nobody reads
[14:47] <Laney> We just find out when someone notices :(
[16:16] <sil2100> vorlon: hey! Do you know what could be the reason for this? https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/16:09:59.log
[16:16] <sil2100> I removed snapd from the FauxPackages because britney on xenial was crashing
[16:17] <sil2100> And now it's just crashing totally
[16:17] <vorlon> whee
[16:17] <vorlon> checking
[16:18] <sil2100> I feel strange because I thought I just reverted the snapd addition from some time ago ;p
[16:19] <vorlon> sil2100: did you make your change locally or in the bzr branch?
[16:19] <vorlon> because there's a conflict in the checkout
[16:20] <sil2100> vorlon: ugh, I did a fresh bzr branch of lp:~ubuntu-release/britney/britney1-ubuntu, modified and bzr pushed
[16:21] <sil2100> https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu
[16:21] <vorlon> rather strange, the branch history looks like all the changes should've been commits, not cowboys
[16:21] <vorlon> anyway, I've resolved it now
[16:22] <Laney> bet someone cowboyed and then committed the same thing
[16:22] <sil2100> I only pushed this to the bzr branch
[16:22] <sil2100> Can we kick britney for xenial somehow manually? Or should I find a xenial kernel to publish to -proposed ;p?
[16:22] <sil2100> Since I wanted to see if this change makes xenial not-crash
[16:27] <sil2100> vorlon: I already poked La_ney about that, but I guess it would be nice for us to get some kind of a notification whenever britney crashes, or maybe even something more sublime like 'no successful britney run after x days' or something
[16:27] <sil2100> vorlon: I guess I could write something up quickly for our stable series
[16:28] <sil2100> Since for devel it's easy to notice, but for stable we rarely look directly at excuses
[16:28] <sil2100> Right now for instance, because of this we could have published some xenial updates that didn't have their autopkgtests ran and might have regressed
[16:28] <sil2100> And it's the second time I see such a situation
[16:28] <sil2100> Anyway, let me card it
[16:54] <sil2100> vorlon: hmmm, so britney now is crashing for gnome-shell apparently - I wonder if maybe the gnome-shell fauxpkg entry should also be checked?
[16:55] <sil2100> vorlon: I wonder though why it is failing now suddenly, but maybe there were some local changes cowboyed that now got removed?
[16:55] <sil2100> vorlon: latest log: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/16:45:31.log
[16:56] <sil2100> vorlon: what were the changes that were conflicting in the production branch? Was that something that could explain the issue here?
[17:01] <sil2100> Laney: ^ you're probably EOD as well, right?
[17:02] <sil2100> Do we have fauxpackages per-series?
[17:12] <vorlon> sil2100: the conflicts were between snapd being shown as locally added and gnome-shell being added to the merge source, which didn't make any sense in the end
[17:13] <vorlon> sil2100: is it possible it's crashing because gnome-shell/s390x exists as a real package in xenial?
[17:15] <vorlon> sil2100: otoh gnome-shell has been in fauxpackages since april, without problems
[17:34] <vorlon> sil2100: this is what ends up in xenial-proposed/Packages_s390x; I don't understand why the architecture string is what it is, I don't recall this detail of fauxpackages
[17:34] <vorlon> Section: faux
[17:34] <vorlon> Version: 3.18.5-0ubuntu0.3
[17:34] <vorlon> Architecture: all
[17:34] <vorlon> Package: gnome-shell
[17:35]  * Faux twitches again.
[21:59] <xnox> Faux:  sorry for all the highlights!
[22:00] <infinity> vorlon: Oh, I just noticed the backscroll WRT fauxpackages.  I did indeed cowboy removal of the gnome-shell one when eoan opened and we realised it was breaking xenial.  I should have committed that, but I was hoping to dig deeper and figure out why.
[22:01] <infinity> I think.
[22:01] <infinity> Memory is fuzzy.
[22:01] <vorlon> ah
[22:01] <vorlon> Laney: ^^
[22:01] <Laney> makes sense
[22:01] <Laney> so let's commit removing that
[22:01] <infinity> I think I may have cowboyed instead of comitted because I feared I'd need to flip it back in and out if it was needed for a larger migration.
[22:02] <infinity> (but also, Debian seemed on the cusp of fixing gnome-shell on s390x at that point)
[22:04] <infinity> Anyhow, removing it should just render a couple of things uninstallable on s390x-only, which is fine.  If it causes migration issues for newer versions of those same things, I'll reevaluate.
[22:06] <infinity> The real problem here comes from our clever use of one britney base and multiple config files to handle N releases.  Maybe we could extend FauxPackages to have a series filter, if we cared, but we use it so infrequently...
[22:07] <infinity> Laney: Did you want me to commit the revert, or was "let's" you saying you were doing so?
[22:07] <Laney> infinity: Go for it
[22:08] <infinity> Laney: Done.
[22:08] <Laney> Ta
[23:43] <GunnarHj> bdmurray: Still there?