[08:33] 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) [08:33] bug 1832457 in glib2.0 (Ubuntu Disco) "[SRU] 2.60.4" [Undecided,In progress] https://launchpad.net/bugs/1832457 [10:19] This KDE phabricator thing is crazy [10:31] When submitting it rewrites your last commit [10:31] It's like it's written for a single commit === cpaelzer__ is now known as cpaelzer === weedloser is now known as epicman === epicman is now known as weedloser === weedloser is now known as epicman === epicman is now known as eqeqe [13:00] 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] is that frowned upon? [13:01] 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) === ricab is now known as ricab|lunch [14:08] hey Laney :) [14:09] 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] correct [14:12] * Laney has tried to shift the paperwork onto acheronuk [14:17] 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] (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] fortunately, LMDB is tiny, depending only on libc [14:18] usually the main problem is if the MIR team decides to ask for a security review [14:18] then it can take a while [14:23] ximion: it's fine, we have this semi frequently, but it may delay any updates to appstream for a long while [14:24] so in general (if you want to care about this situation), making new runtime deps conditional is nice [14:26] 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] 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] I think suse has a similar procedure? [14:29] jup - SUSE already has LMDB in the trusted zone (at least for openSUSE) though due to KDE depending on it [14:29] (also RPM has a LMDB backend) [14:29] I couldn't find any info on what SLE does though, which is more relevant [14:36] 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] Laney: do you, by any chance, know this part of britney? [14:38] 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] those are in b1 [14:43] 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] (at least it provides 'some' powerpc binaries) [14:43] is that what changed around the time it started breaking? [14:44] 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] Laney: do you know if such britney crashes are sent somewhere when they happen? Like some notification [14:47] sil2100: probably the mailbox on snakefruit that nobody reads [14:47] We just find out when someone notices :( === ricab|lunch is now known as ricab [16:16] 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] I removed snapd from the FauxPackages because britney on xenial was crashing [16:17] And now it's just crashing totally [16:17] whee [16:17] checking [16:18] I feel strange because I thought I just reverted the snapd addition from some time ago ;p [16:19] sil2100: did you make your change locally or in the bzr branch? [16:19] because there's a conflict in the checkout [16:20] vorlon: ugh, I did a fresh bzr branch of lp:~ubuntu-release/britney/britney1-ubuntu, modified and bzr pushed [16:21] https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu [16:21] rather strange, the branch history looks like all the changes should've been commits, not cowboys [16:21] anyway, I've resolved it now [16:22] bet someone cowboyed and then committed the same thing [16:22] I only pushed this to the bzr branch [16:22] Can we kick britney for xenial somehow manually? Or should I find a xenial kernel to publish to -proposed ;p? [16:22] Since I wanted to see if this change makes xenial not-crash [16:27] 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] vorlon: I guess I could write something up quickly for our stable series [16:28] Since for devel it's easy to notice, but for stable we rarely look directly at excuses [16:28] 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] And it's the second time I see such a situation [16:28] Anyway, let me card it [16:54] 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] vorlon: I wonder though why it is failing now suddenly, but maybe there were some local changes cowboyed that now got removed? [16:55] vorlon: latest log: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-06-19/16:45:31.log [16:56] vorlon: what were the changes that were conflicting in the production branch? Was that something that could explain the issue here? [17:01] Laney: ^ you're probably EOD as well, right? [17:02] Do we have fauxpackages per-series? [17:12] 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] sil2100: is it possible it's crashing because gnome-shell/s390x exists as a real package in xenial? [17:15] sil2100: otoh gnome-shell has been in fauxpackages since april, without problems [17:34] 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] Section: faux [17:34] Version: 3.18.5-0ubuntu0.3 [17:34] Architecture: all [17:34] Package: gnome-shell [17:35] * Faux twitches again. [21:59] Faux: sorry for all the highlights! [22:00] 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] I think. [22:01] Memory is fuzzy. [22:01] ah [22:01] Laney: ^^ [22:01] makes sense [22:01] so let's commit removing that [22:01] 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] (but also, Debian seemed on the cusp of fixing gnome-shell on s390x at that point) [22:04] 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] 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] Laney: Did you want me to commit the revert, or was "let's" you saying you were doing so? [22:07] infinity: Go for it [22:08] Laney: Done. [22:08] Ta [23:43] bdmurray: Still there?