[02:19] <rbasak> Can we blacklist src:mysql-defaults from autosync from Debian please? With feature freeze coming up, I'd like to hold this for Yakkety+1 if possible, as it'll make no difference for Yakkety and could be confusing for users.
[02:19] <rbasak> infinity: ^
[02:19] <rbasak> It's already been uploaded to unstable.
[02:20] <rbasak> Though I don't see it in LP yet.
[03:23] <mwhudson> can someone process golang-github-coreos-pkg pretty pls :-) (slangasek? infinity?)
[04:09] <infinity> rbasak: Err, why?
[04:09] <infinity> rbasak: If it'll "make no difference for yakkety"?
[04:10] <infinity> rbasak: Seems like a reasonable thing to get in, so our packaging can keep tracking for the rest of yakkety, no?
[04:10] <infinity> rbasak: Otherwise, you're forking mysql from here.
[04:10] <infinity> (because of mysql-common)
[04:14] <rbasak> infinity: because it creates default-mysql-* packages, which make it look like we "default" to MariaDB, but that won't be the case (in Yakkety) because no packages actually will use those metapackages.
[04:14] <rbasak> I should double check, but mysql-common hasn't actually changed yet.
[04:14] <infinity> rbasak: And if we don't intend to default to mariadb ever, we should change the defaults.
[04:14] <infinity> rbasak: That's the point of "defaults" packages.  Makes it easier for derivatives.
[04:14] <rbasak> Debian is only starting the switch to src:mysql-defaults. I don't think it makes sense to take it now, since we're about to feature freeze.
[04:15] <rbasak> We can take it next cycle and add a delta or whatever.
[04:15] <infinity> rbasak: I'm really less inclined to agree, I guess.  universe syncs might start depending on the default stuff, and needing deltas, etc.  Just taking mysql-defaults and fixing it is saner.
[04:16] <infinity> rbasak: Feature freeze is pretty lax (and/or nonexistent) for unseeded stuff.
[04:16] <infinity> I think any attempt to avoid work here is likely to create more work than just uploading mysql-defaults with s/maria/mysql/ and be done with it.
[04:17] <rbasak> I just think that it'd be confusing for Yakkety and doesn't actually give us anything. In the case of a universe package getting synced and having a new dependency on default-* in Debian, it's be trivial to delta that out.
[04:18] <infinity> Err, yes.  But we can fix one package, or fix potentially many.
[04:18] <rbasak> src:mysql-defaults will also take over mysql-common, currently generated by src:mysql-5.7 in Ubuntu (and src:mysql-5.6 in Debian, which we will update to src:mysql-5.7 without mysql-common soon)
[04:18] <infinity> I don't get the "confusing" argument.  At all.  If nothing depends on it, it's not confusing, if something does, it's helpful.
[04:19] <rbasak> I guess it's not confusing if we do delta it.
[04:19] <infinity> Right.
[04:19] <infinity> As we do for default-mta, etc.
[04:19] <infinity> This is a Good Thing(tm).
[04:27] <rbasak> I don't disagree. Only with the timing. I'm not convinced it's useful to introduce this right now. But I don't feel strongly about it.
[04:59] <tedg> Hello, I need an archive admin to delete two binaries in yakkety. url-dispatcher and indicator-datetime for s390
[05:00] <tedg> They depend on libubuntu-app-launch which depends on Upstart which isn't building on s390.
[05:04] <slangasek> tedg: binaries removed (and ftr it's not two binaries, it's all the binaries built from url-dispatcher source on s390x)
[05:04] <tedg> slangasek: Thank you, yes.
[05:04] <tedg> Sorry to be confusing.
[05:05] <slangasek> tedg: I'm not sure what that does to other packages that depend on liburl-dispatcher1... looks like there are other indicator packages that will need to be removed from s390x in the next round
[05:06] <tedg> slangasek: A couple, the biggest one is platform-api, but I think that already doesn't build on s390.
[05:06] <slangasek> yeah, it's only built on x86 and arm
[05:08] <tedg> Huh, surprised how big that rdepends list is...
[05:50] <Mirv> ah so there's another bunch of new packages requiring --all-proposed rerun
[05:50] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir
[05:59] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-settings-components
[05:59] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-notifications
[06:07] <slangasek> Mirv: triggered; but why are these packages finding their way into -proposed while the transition is in progress?
[06:07] <slangasek> some of these, at least, would seem to be silo landings
[06:09] <slangasek> if people are forcing in landings on top of other landings, they should maybe not do that considering it will further slow down the transition
[06:13] <infinity> tedg: The goal being to remove upstart, can we tackle that from the other direction?
[06:13] <infinity> tedg: Removing all the s390x binaries that are in the rdep chain for a package we want to stop depending on seems counter-productive.
[06:22] <Mirv> slangasek: those are silo landings yes, OTA-13 is being finalized this week
[06:22] <Mirv> there would be an option to not release to yakkety for a little while if wanted, only publish to overlay PPA
[06:24] <Mirv> the transition has been going on for three weeks now
[06:40] <flocculant> infinity: images (all I looked at) aren't building - looking I assume they're having trouble with dependencies
[07:28] <handsome_feng> cjwatson, infinity: Good morning!  The Ubuntu Kylin daily iso is not created successfully. The question is about python3-aptdaemon.pkcompat package. Kubuntu and Xubuntu have the same question. But Ubuntu and lubuntu daily iso is created susccessfully.Do you know how to sovle this problem? The URL is https://launchpadlibrarian.net/278816938buildlog_ubuntu_yakkety_amd64_ubuntukylin_BUILDING.txt.gz and https://launchpadlibrarian.net/278982117/build
[07:28] <handsome_feng> log_ubuntu_yakkety_amd64_xubuntu_BUILDING.txt.gz  Thank you !
[07:33] <seb128> handsome_feng, python3-aptdaemon.pkcompat has been removed, stop trying to install it
[07:33] <seb128> see https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1+bzr982-0ubuntu15
[07:33] <seb128> just use packagekit
[07:39] <handsome_feng> seb128, I see the ubuntu-desktop package still recommend python3-aptdaemon.pkcompat,but python3-aptdaemon.pkcompat is not installed.
[07:39] <seb128> right, recommends don't fail build, they just go missing if they can't be insalled
[07:39] <seb128> but that one should probably be removed indeed
[07:39] <seb128> thanks for pointing it out
[07:42] <handsome_feng> seb128,  ubuntukylin-desktop also only recommed python3-aptdaemon.pkcompat package, but build failed
[07:43] <seb128> handsome_feng, you are sure that you don't have something else that has a depends on it?
[07:45] <seb128> otherwise I don't know but maybe infinity has some idea when he's around
[07:48] <handsome_feng> I use command "apt-cache rdepends" only find ubuntukylin-desktop which related us.
[07:50] <handsome_feng> By the way, ubuntu mate,ubuntu gnome, xubuntu, kubuntu have the same issue.
[07:50] <infinity> ubuntu.yakkety/desktop: * (python3-aptdaemon.pkcompat) # needed to keep packagekit off the images
[07:51] <infinity> seb128: So, if the intent was to keep packagekit off images, "just install packagekit" seems like a poor fix.
[07:53] <seb128> infinity, that comment is years old, from a time where packagekit didn't have a decent apt backend, my understanding with that package1.0 transition is that the packagekit backend is considered better maintained and that we want to use it
[07:54] <seb128> which is why the pkgcompat layer got dropped from aptdaemon
[07:56] <infinity> seb128: Mmkay.  Will tear it out of all the seeds, then.
[07:56] <seb128> thanks
[07:57] <infinity> seb128: Care to do me a favour and look at all the rdeps for pkcompat on http://people.canonical.com/~ubuntu-archive/nbs.html and make sure they're other OR deps or deps on the virtual package?
[07:57] <infinity> seb128: So we can remove the binary...
[07:58] <seb128> infinity, k, let me have a look
[07:59] <infinity> No, some are definitely real deps.
[07:59] <infinity> ubuntu-drivers-common and packagekit-tools at least.
[08:00] <infinity> gnome-packagekit-session and gstreamer1.0-packagekit
[08:00] <infinity> cyphermox: When you remove a package, it would be nice to check the rdeps. :P
[08:01] <infinity> Oh, gnome-packagekit-session is itself NBS.
[08:01] <infinity> But also not removable. :P
[08:31] <tjaalton> anyone fancy reviewing x-x-v-intel from xenial queue? adds some pciids and apparently fixes #1568604
[08:31] <tjaalton> bug #156860
[08:31] <ubot5> bug 156860 in f-spot (Ubuntu) "f-spot crashes on tif file import" [Undecided,Invalid] https://launchpad.net/bugs/156860
[08:31] <tjaalton> uh
[08:31] <tjaalton> bug #1568604
[08:31] <ubot5> bug 1568604 in xserver-xorg-video-intel (Ubuntu Xenial) "Mouse cursor lost when unlocking with Intel graphics" [High,Confirmed] https://launchpad.net/bugs/1568604
[08:36] <infinity> tjaalton: I can haz matching lts-xenial upload?
[08:39] <Mirv> Laney: i386 unity8 also passed
[08:39] <tjaalton> infinity: you will
[08:40] <tjaalton> infinity: if this works?
[08:40] <tjaalton> I can't repro the bug
[08:40] <Mirv> so on next update excuses page should look better
[08:40] <Mirv> (amd64 Pass already visible there)
[08:41] <Laney> Mirv: cool
[08:41] <Laney> that wasn't run with all-proposed, but it worked :-o
[08:41] <Laney> Hopefully then we just need to get the kernel
[08:42] <Mirv> Laney: it was, s_langasek did a bunch of them when I asked
[08:42] <Laney> it wasn't, you can see at the top of the log
[08:42] <Laney> he picked some packages instead
[08:42] <infinity> tjaalton: Not being able to reproduce is a bit annoying.
[08:42] <tjaalton> yep
[08:42] <Mirv> Laney: aren't those full -proposed archives? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/u/unity8/20160816_083258@/log.gz
[08:43] <Mirv> Laney: but it still just takes the listed ones I guess?
[08:43] <Laney> --apt-pocket=proposed=src:systemd,src:gsettings-ubuntu-touch-schemas,src:unity8,src:qtmir,src:ubuntu-settings-components,src:unity-notifications,src:libhybris
[08:43] <Laney> it uses apt pinning to only use those ones
[08:43] <Mirv> right, then some luck too
[09:01] <Laney> Mirv: Just kernel stuff left now, AFAICS
[09:07] <willcooke> Hi gang - could someone take a look at the NM SRU please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=network-manager
[09:23] <Mirv> update_output indeed seems clearer than ever
[09:24] <Mirv> "just" the kernel is a bit worrying though
[09:26] <Laney> why?
[09:27] <Mirv> well I can imagine releasing a new kernel is not always a matter of hours
[09:27] <Mirv> and herding these cats to not publish anything new might be challenging :)
[09:28] <Mirv> most of touch stack fortunately doesn't even affect the migrations, and unity8 and friends were just published last night so it's not going to happen soon again
[09:46] <Saviq> seb128, willcooke, hey, how do I find out about the state of unity8 dependencies WRT MIR? is there some way I could query the archive or maybe we've already a list of projects + MIR bug#s?
[09:56] <willcooke> Saviq, well, there's this:  https://trello.com/b/mab4G8UQ/unity-8-in-16-10
[09:56] <willcooke> Saviq, but that's pretty much manual
[09:57] <willcooke> and bregma has a script which walked the dependancy tree - that might help
[09:58] <Saviq> I think I'll wait for that...
[10:14] <bregma> Saviq, ~bregma/+junk/MIR-tools
[10:19] <Saviq> bregma, ack
[10:22] <Saviq> bregma, how do I use that? generate-package-list unity8 just shows me unity8, the other shows all binaries from src:unity8
[10:24] <bregma> add -k to keep the graphviz file and use xdot to view or sotty to convert to svg or some other format
[10:24] <Saviq> ack
[10:26] <Saviq> bregma, still, that only shows me the list of binaries from src:unity8, that correct?
[10:26] <bregma> nope
[10:26] <bregma> ewww, I mean dotty, not sotty
[10:27] <bregma> example of unity8-desktop-session from the week before last: http://i.imgur.com/3e4Yq0f.jpg
[10:28] <bregma> it shows the recursive depends and recommends not in main for all binaries generated by the source packages
[11:01] <Saviq> bregma, ok, seems my sources.list caused it, got a graph now, do we have a central place listing the MIR bug#s yet?
[11:01] <bregma> Saviq, just https://trello.com/b/mab4G8UQ/unity-8-in-16-10
[11:02] <bregma> I was working on a script to connect trello to the packages, but got sidetracked
[11:03] <bregma> also https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs?orderby=-datecreated&start=0
[11:03] <Saviq> bregma, in the MIR bug, I suppose I should only list direct deps?
[11:03] <Saviq> oh that looks helpful
[11:04] <bregma> Saviq, that's what I did (ie. only dependencies, not recommends) because Seb says that's all that's really needed despite what the Wiki page says
[11:04] <Saviq> ack
[11:04] <bregma> we'll see what beatings the MIR team give us over not including the recommends
[11:08] <Saviq> bregma, ah, and green is OK because it's in main?
[11:08] <Saviq> in the chart I mean?
[11:09] <bregma> Saviq, yeah, green means the source package is already in main so the binary can just be (auto) promoted
[11:42] <seb128> Saviq, bregma, recommends in universe are going to show on component mismatch but shouldn't block iso builds/create issue, they are going to need to be eventually to be dealt with but that can come after we start installing the session and we can probably demote things to Suggests if needed
[11:42] <Saviq> ack
[11:44] <bregma> unless the MIR team rejects the MIR because all recommends must be in main first, in which case we need to land all the package changes necessary to move the recommends to suggests, and all that will take time to move through the pipeline, and there are looming deadlines for 16.10
[11:45] <seb128> that's only text
[11:45] <seb128> we can change the recommends to suggests if that's what they want
[11:45] <seb128> and I doubt they are going to block on that
[11:45] <bregma> it's still a change that has to land though ci-train, and that can currently take *weeks*
[11:46] <seb128> it's everybody's interest to get the feature in so it can get tested earlier
[11:46] <seb128> it doesn't have to
[11:46] <seb128> dput still works
[11:46] <didrocks> as long as the change is in the pipe (please link it/write it in the MIR bug report), that's fine, not a blocker
[11:46] <seb128> didrocks, thanks for confirming ;-)
[11:46] <didrocks> yw ;) (that's how *I* deal with it, others might have different opinions)
[11:47] <bregma> at least it's not as bad a Debian in that regard
[11:48] <didrocks> Saviq: you can use check-mir btw as a helper to list them if that helps
[11:48] <Saviq> ack
[12:43] <Mirv> Laney: any word from the kernel team? is there someone we could ping directly?
[13:04] <tedg> infinity: The answer is "kinda" the problem is that most of these packages triple land all the way back to vivid.
[13:04] <tedg> infinity: I think that once UAL supports systemd we can make Upstart an optional build dep there. Which will block off some of the issues.
[13:04] <tedg> infinity: But today that is its only backend, so we kinda need it as a real build dep.
[13:08] <infinity> tedg: Right, but with the push to move yakkety to all-systemd-all-the-time, I do hope this is something being worked on.  If I have my way, we'll remove libnih/upstart/mountall from the archive entirely before release.
[13:09] <tedg> infinity: It is on my todo list, but I don't think that's a goal. AFAIK no one is porting the rest of the U8 session to systemd. It's not a goal.
[13:10] <infinity> It very much is a goal.  People sprinted for this and everything.
[13:10] <infinity> If we move U7 entirely to systemd but not U8, that's a bit lolz.
[13:10] <tedg> *I* sprinted on it, but that was U7 not U8
[13:11] <infinity> pitti: ^-- tedg's been telling me that while unity7 systemdness was a goal, unity8 (and u-a-l?) isn't a priority for yakkety.
[13:12] <pitti> none of the touch things have been ported yet indeed
[13:12] <pitti> we do have WIs for it, but indeed less urgent than for u7
[13:12] <infinity> pitti: I'd really like to remove nih/upstart/mountall entirely by release if we can manage.  But...
[13:13] <infinity> Though, most of my pain would also be averted by someone fixing bugs in them.
[13:13] <infinity> Given that the bugs in upstart in yakkety are entirely valid in xenial too, where we're not removing it.
[13:13] <infinity> I need to talk to Steve about allocating time for that somehow.
[13:14] <infinity> And chaining xnox to a desk.
[13:34] <Laney> Mirv: infinity stabbed some people with a rusty fork and it is being progressed
[14:14] <caribou> Any reason why LP: #1587988 is held in trusty-proposed ?
[14:14] <ubot5> Launchpad bug 1587988 in sssd (Ubuntu Trusty) "LDAP ping doesn't prefers site-local DCS" [High,Fix committed] https://launchpad.net/bugs/1587988
[14:25] <flocculant> infinity: thanks for the intel sru bug comment etc - have asked 'our' people to test that
[14:29] <infinity> flocculant: You're thanking a script, I don't write those comments by hand. :)
[14:29] <infinity> flocculant: If I did, they'd be more sarcastic.
[14:31] <flocculant> :)
[14:31] <flocculant> I'll thank anyone if it helps :p
[15:59] <xnox> infinity, there are a couple phone specific things that rely on upstart: click apps launching, android container -> text socket io bridge -> system upstart events -> user session upstart events (for e.g. sms notifications)
[15:59] <xnox> click apps launching -> tedg's help / guidance is needed to port that to systemd
[16:00] <xnox> porting socket bridge to systemd is doable, but will need a bit of engineering to start/stop targets properties on systemd side and change things to listen/bindsto those and some such.
[16:00] <infinity> xnox: The whole upstart-versus-newer-kernels thing should probably be fixed in xenial anyway. :/
[16:00] <xnox> first one is portable without a working phone.
[16:00] <xnox> the later one needs a phone to test things on.
[16:01] <xnox> because i can't run an andorid lxc container on a regular desktop and goldfish emulator is b0rked
[16:01] <xnox> but do we really want to port clicks to run under systemd? and/or will the phone move to have apps as snaps? Or is .click -> .snap conversion scheduled for some time later on the current generation phones?
[16:06] <bdmurray> slangasek: update-manager, update-notifier, and xserver-xorg-video-ati-lts-xenial are all verified and ready for an early SRU release.
[16:23] <flocculant> jbicha: I was just a bit confused how the murrine thing actually happened - and not sure of your tz :)
[16:24] <jbicha> flocculant: I'm US Eastern
[16:24] <flocculant> aah ok - not 'too' bad then for me :)
[16:33]  * infinity wonders why packagekit-plugin-click doesn't show up on the NBS report...
[16:33] <cjwatson> Because it's still listed in debian/control, but conditionally not built
[16:33] <infinity> Well, that's derpy.
[16:33] <cjwatson> Needed to keep it existing in vivid/xenial
[16:33] <infinity> Kay.
[16:36] <infinity> cjwatson: rdeps look clean, I'll just remove it blindly.
[16:36] <cjwatson> kay
[16:36] <infinity> I wonder how often that happens. :/
[16:37] <infinity> cjwatson: Wow.  A local build of click in sbuild fails the testsuite miserably.  Am I missing a trick of some sort?
[16:37] <cjwatson> er, dunno.  any details?
[16:38] <infinity> test_fields (click.tests.test_framework.TestClickFramework) ... ERROR
[16:38] <infinity> /usr/lib/python3.5/unittest/case.py:628: ResourceWarning: unclosed file <_io.BufferedReader name=3>
[16:38] <infinity>   outcome.errors.clear()
[16:38] <infinity> A lot of stuff like that.
[16:38] <cjwatson> haven't the foggiest.  it's been a while
[16:38] <infinity> Kay.  Don't care.  The test build was unnecessary anyway, once I realised the thing I was rebuilding for was NBS. :P
[17:02] <slangasek> flocculant, jbicha: hi, so what's the path forward on gtk2-engines-murrine?  Is this going to be fixed timely in the dependent theme package, or do we need a revert?
[17:03] <flocculant> slangasek: I'm not sure tbh tbh, ochosi is the guy to talk with
[17:03] <slangasek> ok
[17:04] <ochosi> slangasek: it's only "fixable" in the theme package by not using the text-shadow feature anymore in the theme
[17:04] <slangasek> for reference, the policy on SRUs is "no regressions allowed"; so whoever uploaded this SRU should take some responsibility for following through
[17:04] <ochosi> as far as i can see the bug isn't fixed
[17:04] <flocculant> ochosi: thanks for seeing the ping here :)
[17:04] <ochosi> (the fixes proposed for other themes simply switched to a different way of drawing text shadows which only works in some specific application contexts)
[17:05] <ochosi> so basically we either need to 1) bisect murrine to see what went wrong where and fix it or 2) roll back
[17:05] <ochosi> at least that's my view
[17:05] <jbicha> is it actually a xfdesktop bug or just a murrine bug?
[17:05] <ochosi> (in theory there are hundreds of other murrine-based themes out there which use text-shadow and now have breakage)
[17:05] <slangasek> bdmurray: releasing, thanks!
[17:06] <ochosi> jbicha: it's murrine. xfdesktop has a built-in function for text-shadow (stemming from the times where themes couldn't do it yet)
[17:06] <ochosi> that's the workaround
[17:06] <ochosi> but it only works for the desktop, not in other contexts
[17:06] <ochosi> also see https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-murrine/+bug/1598316/comments/8 for reference
[17:06] <ubot5> Launchpad bug 1598316 in gtk2-engines-murrine (Ubuntu) "gtk2-engines-murrine desktop text shadow problem" [High,Triaged]
[17:06] <flocculant> jbicha: shoulD *that* matter?
[17:06] <ochosi> sry, gotta go, bbl :/
[17:07] <flocculant> ochosi: understood that :)
[17:08] <jbicha> flocculant: I think it matters when deciding which bug is more important, the bug that was fixed or the bug that was triggered
[17:08] <flocculant> I guess
[17:09] <flocculant> what we have is brokne desktops
[17:09] <ochosi> final note: as murrine is longtime unmaintained it shouldn't be terribly hard to find the offending commit
[17:09] <ochosi> i'm even surprised anyone commits to it at all
[17:09]  * ochosi would look at cimi with sad puppy eyes if he were in this channel right now
[17:10] <jbicha> ochosi: the bug was triggered by https://launchpad.net/ubuntu/+source/gtk2-engines-murrine/0.98.2-0ubuntu2.1
[17:10] <jbicha> which was accepted into multiple other distros
[17:10] <flocculant> jbicha slangasek I don't code at all - I just try to get testing done, when something breaks when it *was* ok - hands up in surrender
[17:10] <flocculant> jbicha: so can it not be reverted?
[17:10] <jbicha> ochosi: I think we're delegating the decision on what to do here to you then
[17:12] <jbicha> sure, it can be reverted; I guess people using 3rd party themes is more common than people using a bitmap font as their system font
[17:13] <flocculant> mmm
[17:13] <flocculant> jbicha: I don't know enough to comment more atm, I'll leave that to others
[17:14] <flocculant> all I'll say is *we* have to test with foo, if it then changes and a flavour ends up broken - that's not good for anyone :)
[17:17] <flocculant> what I know is that the update broke things for us
[17:48] <gb_mks> Hi, I´m looking for some help to fix this bug in Ubuntu 14.04. https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1398569   is this the right place for it?
[17:48] <ubot5> Launchpad bug 1398569 in schroot (Ubuntu) "overlayfs: handle v3.18 overlay union type" [Medium,Fix released]
[17:57] <ochosi> jbicha, flocculant: i'll take a look at that commit and see whether i can fix the fix...
[17:58] <ochosi> (don't hold your breath though)
[18:03] <tsimonq2> gb_mks: probably #ubuntu-devel
[18:03] <gb_mks> tsimonq2: thanks  :) I will try there
[18:08] <tsimonq2> slangasek, infinity: so lubuntu-next is just not building at all, very weird http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/yakkety/
[18:09]  * tsimonq2 double-checks cron
[18:09] <tsimonq2> (I *thought* it was like 11:something AM my time that it spun up and it's 1:09 PM)
[19:32] <slangasek> tsimonq2: I see the lubuntu cronjob still running, and the crontab edit you made causes lubuntu-next to be serialized behind lubuntu which is probably still running
[19:33] <tsimonq2> slangasek: ohh good point
[19:33] <tsimonq2> slangasek: thanks
[19:35] <tsimonq2> slangasek: wait a minute... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu should be done? look at the log for powerpc
[19:35] <tsimonq2> I'm no expert but doesn't the PPC log look done already?
[19:37] <wxl> well desktop hasn't built yet
[19:52] <tsimonq2> wxl: really?
[19:52] <tsimonq2> hmmm
[19:52] <tsimonq2> wait, but I think it's waiting on PPC
[19:53] <tsimonq2> oh nvm
[19:55] <tsimonq2> so if the live image is built, why isn't it continuing? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/yakkety/daily-live-20160816.log
[19:56] <cjwatson> tsimonq2: cd-build-logs is only synced periodically, it's not a live log
[19:57] <tsimonq2> good to know, thanks cjwatson
[19:57] <cjwatson> */15 * * * *    mirror-image-build-logs
[19:58] <cjwatson> just finished
[19:58] <tsimonq2> so in a minute and a half it'll sync?
[19:59] <cjwatson> tsimonq2: ish
[19:59] <cjwatson> I don't recall how long the rsync takes
[20:02] <tsimonq2> there it is! \o/
[20:03] <tsimonq2> slangasek: what's the deal? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/yakkety/daily-live-20160816.log
[20:04] <wxl> same error from yesterday
[20:05] <wxl> didn't you guys merge the fix yesterday?
[20:05] <cjwatson> looks like no livefs-launchpad change, again
[20:05] <slangasek> infinity: ^^ did you forget to push your livefs-launchpad change?
[20:08] <wxl> also is "Could not resolve hostname royal.buildd" to be concerned about?
[20:10] <slangasek> that's because of trying to do a non-launchpad build, which is probably a knock-on effect of the missing merge
[20:11] <cjwatson> yes
[20:11] <cjwatson> we should probably kill the fallback to be less confusing, but it would just fail differently :)
[20:12] <cjwatson> (or at least kill the fallback configuration; the code is still conceivably useful for people doing stuff locally)
[21:01] <infinity> slangasek: I didn't make a livefs-launchpad change.
[21:01] <infinity> slangasek: I pointed out to you where to make it. :P
[21:01] <infinity> slangasek: I guess a slight miscommunication there.
[21:02]  * infinity goes and makes the change now.
[21:03] <slangasek> infinity: ah, sorry
[21:03] <slangasek> and thanks :)
[21:03] <wxl> infinity: when that's merged, is it possible to trigger the rebuild?
[21:03] <infinity> wxl: Sure.
[21:03] <wxl> infinity: thank you kindly, sir.
[21:06] <infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu-next
[21:06] <infinity> livefses are building, at least.
[21:06] <infinity> Progress.
[21:06] <wxl> yay you rock!
[21:06] <infinity> Err, oh.  Crap.
[21:07] <tsimonq2> ooh what's that mean?
[21:07] <tsimonq2> what happened? :O
[21:08] <infinity> I goofed something.  Cancelling and trying again.
[21:08] <tsimonq2> ok 👌
[21:10] <Ukikie> infinity: Speaking of which, you guys bothered to review the MATE/Xubuntu ones?
[21:28] <mwhudson> slangasek: can you process golang-github-coreos-go-systemd ^ through NEW?
[21:28] <mwhudson> slangasek: then i can upload lxd!
[21:32] <wxl> tsimonq2: bah https://launchpadlibrarian.net/279311792/buildlog_ubuntu_yakkety_powerpc_lubuntu-next_BUILDING.txt.gz
[21:32] <wxl> lubuntu-default-seetings is the problem
[21:38] <tsimonq2> oh gawd
[21:42] <slangasek> mwhudson: done
[21:42] <mwhudson> slangasek: thanks
[21:45] <infinity> mwhudson: Will this lxd pass its testsuite? :)
[21:45] <mwhudson> infinity: i certainly hope so!
[21:45] <mwhudson> there's not really an easy way to find out apart from uploading to -proposed is there?
[21:49] <infinity> mwhudson: You can run autopkgtests locally, but every time I need to do so, I find myself forgetting where that's documented. :/
[21:54] <infinity> doko: Your addition of python3-talloc{,-dev} got removed in a later Debian upload.  Do you want to reintroduce that as an Ubuntu delta, or fix the one rdep (ldb) to not care?
[21:58] <jbicha> mwhudson: it's also possible to run autopkgtest.u.c from a ppa but it's not a very intuitive process