[00:01] <jbicha> cortina and meta-gnome3 are the only 2 I see that will need new uploads now then for that
[00:01] <jbicha> so I'll do that now
[00:01] <infinity> Well, ostree clearly does, or it wouldn't have s390x binaries.
[00:01] <infinity> Not sure I want to hunt through the rest of the bug to see if others are in such a state.
[00:01] <jbicha> yes but as long as we can get the newer ostree to migrate that will be fixed
[00:02] <infinity> jbicha: Eh?
[00:02] <slangasek> infinity: when people are retrying builds for things that ftbfs on random archs that have never built, and I get email for those, I absolutely reserve the right to not like the emails and not commit to fixing the builds
[00:02] <infinity> jbicha: The new ostree has s390x binaries.
[00:02] <infinity> slangasek: Okay, it's fair that we could do with some regression history, so we could maybe tag FTBFS mails in a filterable way.
[00:02] <jbicha> infinity: no, it's in depwait (and my diff is unnecessary) https://launchpad.net/ubuntu/+source/ostree/2017.11-1ubuntu1
[00:03] <infinity> jbicha: Oh, there's a VERY new one. :)
[00:03] <infinity> jbicha: I was looking at rmadison, silly me.
[00:03] <jbicha> ok
[00:03] <infinity> jbicha: Alright, removing away.
[00:03] <infinity> jbicha: Thanks for weathering my rant with rational responses. :P
[00:05] <jbicha> infinity: since you're opinionated, do you prefer I have cortina build-depend on gjs (so depwait) or specify a list of architecture to build for?
[00:05] <slangasek> infinity: to your rant though, I want to double-check I'm not doing something wrong - my usual response to "please remove these binaries" is "please give me a new version in -proposed that isn't just going to bring those binaries back."  so I'm in the clear, right?
[00:06] <infinity> slangasek: Right.  Binary removal should only happen if the binary is NBS.
[00:07] <jbicha> cortina/s390x has an unsatisfiable depends on gnome-shell, which confuses britney I believe
[00:07] <slangasek> ok
[00:07] <infinity> slangasek: I mean, there should also be due diligence to make sure that version in proposed will actually migrate, but basically the right track there.
[00:07] <infinity> jbicha: That doesn't confuse britney, britney's correct.
[00:08] <infinity> jbicha: ostree cleaned up.
[00:08] <infinity> (And so noted in the bug)
[00:10] <infinity> jbicha: As for the question, I prefer the unnecessary build-dep method (though, really, it should build-dep on gnome-shell, since that's what it depends on) because, while it's a bit heavy-handed and gross, it has the advantage of "fixing itself" if the stack suddenly becomes buildable again.
[00:10] <infinity> jbicha: And also doesn't need adjusting for new arches.
[00:11] <jbicha> ok
[00:11] <doko> slangasek, infinity: I gave back all packages last week, because it wasn't done since April
[00:11] <infinity> The amount of the archive that isn't built on Random Arch X purely because the maintainer chose an Architecture line 13 years ago that no one has since reviewed for accuracy is larger than you'd think.
[00:11] <jbicha> there's a chance someone in Debian will figure out gettings mozjs52 to work on other arches…
[00:11] <infinity> doko: Thanks.
[00:12] <doko> and yes, it built a handful more packages sucessfully
[00:12] <infinity> jbicha: Well, afaik, newer mozjs is entirely dependent on rustc being non-crap, which arch maintainers are working on, so it might just kinda fix itself over the next 6-12 months on a few arches.
[00:13] <doko> well, working on rust is wishful thinking
[00:13] <infinity> doko: I don't mean downstream arch maintainers, I mean IBM has people working on it.
[00:14] <infinity> I certainly am dedicating exactly as much time to rustc as I did to golang.
[00:14] <jbicha> I think mozjs52 is pre-rust but yeah, the future will be fun
[00:15] <infinity> jbicha: Ahh, if it's pre-rust, it may just be a legit silly endian bug or something and, indeed, Debian might fix it.
[00:16] <infinity> jbicha: The future actually looks pretty good for mozilla after the switch to rust, IMO.  And that's coming from someone who's sick of "oh look, a new compiler that needs porting."
[00:16] <jbicha> https://buildd.debian.org/status/package.php?p=mozjs52 ( you can probably ignore mips64el but the other test failures are really bad)
[00:16] <infinity> jbicha: Cause at least this compiler WILL be ported (over time).
[00:17] <infinity> jbicha: The most complex part of firefox that ALWAYS broke on non-primary arches was mozjs, so switching to a highly-portable thing that needs less babysitting by port maintainer might make firefox Just Work a lot more often than it used to.
[00:18] <infinity> (Again, in a wonderful future of a year or three when rust's ports are all solid)
[00:19] <jbicha> it's nice that GNOME is now on the latest mozjs (ESR) instead of mozjs24 like we were a year ago too
[00:21] <infinity> Of course, if you take my above analysis to extremes, I may have just accidentally advocated writing a javascript interpreter in Perl.
[00:21] <infinity> Which I don't recommend.
[00:22] <infinity> (Though it wouldn't be any worse than jbailey's pet project to write a libc in js)
[00:23] <jbicha> if you're in a removing mood, want to remove some or all of the packages at LP: #1710318? we might leave a few webkitgtk rdeps in artful but it doesn't need to be so many
[00:23] <ubottu> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
[00:24] <infinity> jbicha: I have to run out to the hospital shortly, but I have a browser tab open to look at it.
[00:24] <infinity> karstensrage: Oh, ditto to you.  I got sidetracked a bit here.  But when I get back, I'll have a poke at your stuff.  What timezone are you in?
[00:25] <karstensrage> Pacific
[00:25] <jbicha> infinity: what time zone are you in? lol
[00:25] <infinity> karstensrage: Ahh, kay.  I'm Mountain.  So if we need some real-time back-and-forth on this (and your NSS module), let's talk tomorrow.
[00:25] <karstensrage> hope all is well infinity and thank you for your patience with me
[00:25] <karstensrage> will do
[00:25] <infinity> jbicha: I'm in both all of them and none of them.  And even moreso the last week or two with the above mentioned hospital issue. :/
[00:26] <jbicha> best wishes
[00:26] <infinity> There are many crossed fingers.
[00:26] <infinity> Mom's scheduled for all the open heart surgery ever next week.
[00:26] <infinity> Which is a bit scary.
[00:27] <infinity> A lot scary.
[00:47] <gaughen> infinity, slangasek - would you, or someone else with a release team hat, have a look at - https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706248
[00:47] <ubottu> Launchpad bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed]
[00:55] <infinity> gaughen: I'm conceptually okay with a new SLOF from an HWE perspective, but I think I'd like to give it a once-over/test-drive, and chat with Aurelien about doing it in Debian too.
[00:55] <infinity> gaughen: So putting that open browser tab on my "will look a bit later".
[00:55] <gaughen> fair enough
[00:56] <infinity> Also super curious about this "new boot menu" thing, since firmware presenting boot menus is usually a bad thing, in my experience, not a good one. :P
[00:56] <gaughen> cpaelzer, ^^ fyi re: ffe on slof
[00:57] <gaughen> infinity, from the perspective of users select options they shouldn't?
[00:59] <infinity> gaughen: I want to see what they mean by "boot menu".  If it's "hit a key combination to enter forth prompt", fair enough, if it's some nasty attempt to present what grub should be presenting, ick.
[00:59] <gaughen> yeah that is ick
[00:59] <infinity> gaughen: Anyhow, the motivation for the bug report (the dhcp thing) feels like something we'd want to cherry pick back to (at least) xenial, so worth someone looking at that while I also evaluable the wholesale version bump.
[00:59] <infinity> evaluate, too.
[01:00] <infinity> evaluable?  Really, fingers?  THAT'S NOT EVEN A WORD.
[01:01] <slangasek> UEFI has a boot menu, it must be a good idea
[01:01] <infinity> slangasek: Yeah, and it's STELLAR.
[01:01] <infinity> Except the other thing.
[01:02] <infinity> Also, see petitboot as exhibit suck.
[01:02] <slangasek> yes, I was just seeing petitboot this afternoon
[01:02] <infinity> My condolences.
[01:02] <slangasek> for half a second, before its 10 second boot timeout triggered after I had waited a half hour for it to load
[01:32] <cjwatson> Evaluable is totally a word.  Just not the word you wanted.
[01:33] <infinity> Err, yes it is.  But not in the way I was thinking.
[01:33] <infinity> e-valuable is how my brain broke it apart.
[05:35] <cpaelzer> good morning
[05:35] <Unit193> Heya.
=== Guest19724 is now known as RAOF
[09:12] <jamespage> o/
[09:47] <doko> stgraber: autopkg test failures triggered by lxc
[09:47] <doko> jamespage: cinder autopkg test failure on s390x
[09:48] <jamespage> doko: looking now
[10:54] <LocutusOfBorg> hello chrisccoulson, doesn't rust need a sync from debian? because of firefox?
[10:56] <LocutusOfBorg> (actually a merge probably)
[11:01] <chrisccoulson> unless you're also going to do cargo, please do not sync or merge rust
[11:40] <ricotz> LocutusOfBorg, chrisccoulson, notice/remember libgit2
[11:40] <ricotz> chrisccoulson, please see PM
[12:00] <LocutusOfBorg> chrisccoulson, I was asking about what firefox requires, I don't plan to do it :)
[12:01] <LocutusOfBorg> ricotz, what is the libgit2 problem?
[12:01] <LocutusOfBorg> is somebody requesting a ffe?
[12:02] <ricotz> LocutusOfBorg, debian is not shipping it internally and relies on it as system-dep which won't work on ubuntu
[12:02] <ricotz> since backport down to trusty are required
[12:02] <ricotz> LocutusOfBorg, so don't plainly take it from debian
[12:03] <ricotz> basically the toolchain for firefox 56 is already done
[12:03] <ricotz> the version of rustc/cargo which are in debian currently will be required beginning with firefox 57
[12:12] <LocutusOfBorg> ok, anyway, I don't plan to do cargo/libgit2/rust work
[12:13] <LocutusOfBorg> I was just asking in case you want to prepare for FF57
[12:16] <LocutusOfBorg> libgit2 will be autosyncd btw when 18.04 opens
[12:19] <ricotz> LocutusOfBorg, I think rustc/cargo should not be synced, e.g. even likely that ff56 won't build with rustc 1.20
[12:45] <rbasak> xnox: any progress on bug 1691096 please? AFAICT, it's a bug in systemd and I'd like to start considering it release-critical for server.
[12:46] <ubottu> bug 1691096 in systemd (Ubuntu Artful) "mysql in lxd fails to start with systemd 233, 234: failed at step KEYRING" [High,Triaged] https://launchpad.net/bugs/1691096
[12:46] <rbasak> ahasenack: ^
[12:46] <ahasenack> thx
=== giraffe is now known as Guest431
[14:22] <sil2100> hm, we seem to be having some issues with our autopkgtests in our ubuntu-image CI
[14:22] <sil2100> Looks like it has problems installing haveged?
[14:22] <sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-foundations-ubuntu-image/artful/amd64/u/ubuntu-image/20170918_021026_e3fc6@/log.gz
[14:24]  * sil2100 tries re-running
[14:26] <xnox> sil2100, universe is not enabled?
[14:27] <sil2100> Did it get disabled from the infra?
[14:28] <sil2100> Since I don't think this is anything we control
[14:47] <stgraber> doko: I know, I've been watching :)
=== dupondje_ is now known as dupondje
[15:54] <nacc> jbicha: infinity: ok, setup a mate VM of 16.04.3. In the 'boutique', if i search for virtualbox, both virt-manager and oracle's virtualbox show up (confusingly not the one from multiverse). No repository is setup for virtualbox initially (that I can see in boutique). If I click on install oracle virtualbox, it queues it and then if i click on apply changes, the third party virtualbox repo has been
[15:55] <nacc> added and a non-ubuntu package has been installed. Now, it does say the source is oracle's repo (by URL), but I'm not sure a regular user would konw it's unsupported software (by Ubuntu)
[15:57] <nacc> infinity: not sure if that still constitutes a policy violation or not; it's opt-in, but not at all obvious to an end-user what they are opting in to, imo
[16:14] <rbasak> ddstreet: sorry, I didn't realise you had a new patch for me there. I don't think forcing use of gcc-6 is a suitable fix for the development release though. I suspect doko wouldn't be happy about that.
[16:14] <rbasak> ddstreet: I think I'd already made suggestions on this channel?
[16:15] <ddstreet> rbasak it's being worked by niedbalski who is actually out today, but i'll pass that on to him, so he may ping you tomorrow
=== tkamppeter_ is now known as tkamppeter
[20:53] <pitti> wgrant: trouble with lgw again? most builders seem to be stuck in "cleaning" again (some spot checks like https://launchpad.net/builders/lgw01-amd64-041/+history says 6 hours)
[23:52] <karstensrage> infinity, very sorry to bother you, no worries if you have more pressing issues, any preliminary comments? Id like to get started on the new NSS packaging
[23:53] <karstensrage> i assume since thats new it will be an ITP and then a RFS so it goes through the normal process