[00:04] <infinity> wxl: Getting there.
[00:05] <knome> i guess i'm the only one around who could push the xubuntu announcement to our website, and i'm about to hit the bed
[00:06] <wxl> infinity: no worries, just checking
[00:06] <knome> so our announcement will most probably be a tad late :)
[00:06] <wxl> hehe
[00:06] <infinity> knome: Announcements matching reality is probably not critical. ;)
[00:06] <knome> not really, but just FYI, if somebody wonders what's going on
[00:07] <wxl> knome: just stay out of ubuntu+1 :)
[00:09] <infinity> wxl: So, skipping ppc entirely, despite the tests that claim to have been done?
[00:09] <infinity> Oh, done but all failed because it didn't boot. :P
[00:09] <infinity> Nevermind.
[00:09] <wxl> infinity: i know they're only 32 bit
[00:09] <infinity> Skipping away.
[00:09]  * wxl nods
[01:40] <mdeslaur> can someone please reject 4.3-9ubuntu3 from the queue, please
[01:40] <mdeslaur> sorry, bash 4.3-9ubuntu3
[01:46] <infinity> mdeslaur: With pleasure.
[01:47] <mdeslaur> infinity: thanks
[01:47] <infinity> mdeslaur: Yet another fix needed?
[01:48] <mdeslaur> infinity: build issue, bison isn't regenerating the file from the patched source because of a timestamp issue
[01:48] <infinity> mdeslaur: Whoops.
[01:49] <mdeslaur> infinity: what's the filesystem used on the builders?
[01:50] <infinity> mdeslaur: ext3/ext4, depending (so, yes, some might not have micro-second timestamps, if that's your issue)
[01:52] <mdeslaur> yeah, I've hit that a couple times
[01:54] <infinity> mdeslaur: The vast majority are ext4 at this point, but that's not something one should rely on (and I consider it a bug if a build system needs precision timestamps anyway, since it rules out building on a lot of filesystems)
[01:55]  * mdeslaur nods
[04:12] <wxl> yay we're released
[08:23] <lool> would a RT member mind reviewing and releasing network-manager from unapproved? it brings wifi scan fixes that we need in RTM for the wifi based positioning
[08:31] <Laney> I assumed we'd unfreeze
[08:31] <Laney> Not?
[08:36] <apw> Laney, we have nominally remained in hard freeze from beta to final so that things in main get extra review (iirc)
[08:36] <apw> (final beta)
[08:38] <Laney> Maybe, I forgot what we did last time
[08:39] <apw> that is my memory, i don
[08:39] <apw> don't think it is intended to imply a higher bar, just more care being applied
[08:39] <Laney> I know
[08:43] <Laney> lool: no patch headers, bug reference or description of the problem being solved :( - forwarded upstream?
[08:59] <infinity> Laney: Can you hunt down the uploader of that gtk+3.0 and investigate if it breaks ABI?
[09:00] <infinity> Laney: At a glance, it looks like it's altering argument counts for at least one non-static function (but that might just be hard to read right in the diff context), which would need at best a symbol version bump, at worst, a new SOVER.
[09:00] <infinity> Laney: (I'd do the hunting myself, but I should be asleep, and need to be up again in ~4h)
[09:03] <infinity> Laney: Actually, I'm going to reject it, pending further investigation, just in case.  But please do hunt down said person and see about investigating properly.
[09:04] <lool> Laney: yes, this was discussed with upstream
[09:05] <lool> cyphermox: ^ do you have upstream references for the NM changes?
[09:05] <cyphermox> ha?
[09:05] <cyphermox> it was on IRC, really
[09:05] <cyphermox> we came up with a solution that was proposed to dcbw, and we all mutually agreed this was what was required
[09:06] <cyphermox> I'm not sure tvoss posted the patch yet
[09:06] <cyphermox> perhaps I'll just go ahead and ship it to the mailing list now
[09:06] <Laney> I picture it disappearing into the void
[09:06] <cyphermox> Laney: ?
[09:06] <Laney> If not forwarded upstream
[09:06] <lool> cyphermox: can we open a bugzilla ticket with the patch?
[09:07] <cyphermox> sure can
[09:07] <lool> thanks
[09:07] <Laney> would it be bad to reupload with the reference?
[09:07] <Laney> or, I guess there's a VCS?
[09:08] <Laney> infinity: Okay, I'll see in a minute
[09:08] <cyphermox> it will be in ~network-manager/network-manager/ubuntu shortly
[09:08] <Laney> seb128: ^? did you upload gtk by any chance?
[09:08] <lool> Laney: this is fairly urgent I'm afraid
[09:11] <Laney> Isn't it always :)
[09:12] <lool> eh
[09:12] <Laney> I accepted it - please update the VCS with the appropriate headers
[09:13] <lool> thanks
[09:13] <lool> cyphermox: ^ if you dont mind
[09:14] <seb128> Laney, yes I did for printing/cred, why?
[09:14] <seb128> shouldn't be an abi change, it's in the printing code which is used only by gtk itself
[09:15] <seb128> that's a backport from gtk 3.13
[09:15] <infinity> seb128: Can you double-check it doesn't affect any exported functions?
[09:15] <Laney> It seems from first glance to change the signature of exported symbols
[09:15] <infinity> seb128: The diff sure made it look like it might.
[09:15] <seb128> k
[09:15] <seb128> sorry I have to go, I can do that this afternoon
[09:15] <seb128> I just sponsored a backport of an upstream commit
[09:15] <seb128> that change is in debian unstable btw and they didn't change anything afaik
[09:15] <seb128> but I can check later
[09:16] <infinity> seb128: At first glance, it only looks like added args, so wouldn't be an ABI break, just an ABI progression (ie: need symbols min versions updated), but I could also just not be getting enough context.
[09:16] <seb128> that's not an external symbol afaik
[09:16] <seb128> the print module is just used by gtk itself
[09:17] <infinity> seb128: "just used by gtk itself" is a statement, not necessarily a reality.  If the symbols are public symbols in an object we ship, and that object has an ABI, it has a contract.
[09:17] <infinity> Unless it's a plugin that literally only GTK *can* load.
[09:17] <seb128> ok, discard it, I don't care
[09:17] <infinity> Anyhow, just have a check sometime.  If my glance was wrong, cool, we can accept from rejected.
[09:18] <seb128> well, I fail to see what outside gtk would load the gtk print dialog
[09:18] <seb128> but I don't have the slots to do work on that, I though it would be a no issue change
[09:18] <seb128> so if it's not let's drop it
[09:19] <ogra_> could someone unembargo the hud package from unaccepted ?
[09:19] <ogra_> (i need it for a pending fix)
[09:22] <infinity> (base)adconrad@cthulhu:~$ nm -D /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1200.2 | grep gtk_print_backend_set_password
[09:22] <infinity> 0000000000318bd0 T gtk_print_backend_set_password
[09:22] <infinity> seelaman: FWIW, definitely not in a plugin.
[09:22] <infinity> Err.
[09:22] <infinity> seb left.  Bah.
[09:39] <cjwatson> infinity: Any reason I shouldn't start working my way through the queue?
[09:40] <rbasak> bcache-tools has in the Utopic NEW queue for a while now, if you have time to look at that.
[09:40] <rbasak> (please)
[09:40] <cjwatson> oh I was talking about unapproved, new is a different headspace ...
[09:41] <infinity> cjwatson: Work away.
[09:41] <infinity> cjwatson: Fairly sure you can ignore half of it (all the KDE stuff), which I expect Riddell/ScottK to get to soon.
[09:41] <infinity> cjwatson: But all the pending syncs probably want love.
[09:41] <infinity> (and oh, how we all love reviewing syncs)
[09:42] <infinity> cjwatson: Though, if you're, y'know, bored for a few minutes, getting to the bottom of the grub2/ppc64el breakage (or reverting to the cross-build hack for now) would be nice.
[09:43] <infinity> Not that I ever verified that it didn't work, I just took your word for it and didn't release that ISO.
[09:43] <cjwatson> infinity: There were patches on grub-devel this morning which I'm going to apply
[09:44] <cjwatson> Well, not for the nvram bit
[09:44] <infinity> cjwatson: I haven't looked at how it works now.  It's still building a 32eb binary, right, just using the native toolchain?
[09:44] <cjwatson> But at least for the VSX chaos
[09:44] <cjwatson> RIght
[09:45] <infinity> cjwatson: Kay.  When you think it's all fixed, I should try it on my old PowerStation, to make sure it's happy on old very big-endian-only kit.
[09:45] <infinity> Though testing on a POWER3/4/5 would be ideal, since that also rules out accidental AltiVec leakage too.  But what are the odds?
[09:49] <infinity> Oh, except testing it on my machine would mean manually extracting the binary from the ppc64el package.  That's a bit of a pain.
[09:54] <infinity> Alright, I'm giving up on the fiction that I'll be able to sleep between now and when the exterminators come to tear apart my apartment.
[09:59]  * cjwatson raises eyebrows at queuebot
[10:04] <cjwatson> infinity: I've reviewed all the syncs in the queue with the exception of libav, which I requested.
[10:40] <lool> hey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows network-manager has been waiting for autopkgtests "in progress", but it's been 3 britney passes that they are finished and green in jenkins
[10:40] <lool> it looks like britney is not getting the right status from the tests
[10:40] <cjwatson> film at 11
[10:41] <rbasak> Could this be anything to do with the recent maintenance?
[10:41] <cjwatson> unlikely
[10:41] <cjwatson> it's just broken sometimes
[10:42] <cjwatson> that said
[10:42] <cjwatson> when I go to the "private" link for friends, the job is apparently still running
[10:42] <lool> the public one has a recent date and is finished
[10:42] <cjwatson> though not the n-m one
[10:42] <lool> ah friends
[10:42] <cjwatson> the public one is basically just informational
[10:43] <cjwatson> the relevant status file on snakefruit is dated a bit over an hour ago ...
[10:43] <cjwatson> but screw it, I'll just force it
[10:43] <cjwatson> don't have time for subtlety
[10:44] <cjwatson> hint committed
[10:45] <lool> in other news, I intend to do a source + binary copy of qtubuntu-sensors ubuntu2 from ubuntu-rtm to ubuntu as ubuntu as an ubuntu1 source with the same contents, but that's a lower version
[10:45] <lool> it might end up in unapproved
[10:45] <cjwatson> don't need to tell us in advance, we'll be notified
[10:46] <davmor2> cjwatson 's been committed man we need a plan to break him like they did with murdoch......I love it when a plan comes together.
[11:03] <cjwatson> infinity: I just realised - the dubious ppc64el changes in grub2 never made it into utopic, because I forgot to do grub2-signed
[11:03] <cjwatson> infinity: so final beta might be bootable on ppc64el after all ...
[11:03] <oSoMoN> hey release team, if I can do anything to help approve webbrowser-app quickly, let me know (this landing only has unintrusive bug fixes, and needless to say, has been thoroughly tested)
[11:04] <cjwatson> oSoMoN: it's ok, we're reasonably on top of the queue at the moment
[11:05] <oSoMoN> cool :)
[11:05] <infinity> cjwatson: Oh.  I guess I should have actually looked into it and tested instead of taking you at your word.  I guess I could still test that image and release it before it gets culled.
[11:06] <cjwatson> infinity: might be a plan, yeah
[11:06] <cjwatson> sorry for misinormation
[11:06] <cjwatson> +f
[11:06] <oSoMoN> that was fast indeed, thanks :)
[11:06] <infinity> cjwatson: In that case, please don't re-enable dailies, I'll get to testing today/tomorrow.
[11:06] <cjwatson> ok
[11:07] <infinity> I guess I could chattr that daily so it can't go away. :P
[11:07] <infinity> Probably a bit unfriendly.
[11:07] <cjwatson> or just hack cdimage/etc/purge-days
[11:08] <cjwatson> cowboy "ubuntu-server 10" in there for a while or something
[11:08] <infinity> cjwatson: Oh, yeah, I've done that in the past.
[11:09] <infinity> Done.
[11:52] <cjwatson> infinity: doesn't appear to be bootable on snyder.  Of course, the latest debian-installer was built against the broken grub-ieee1275-bin
[12:06] <infinity> cjwatson: Oh, of course it was, cause it was built in proposed.
[12:06] <infinity> cjwatson: So, the migration status is meaningless.
[12:07] <infinity> Also, this is an argument for me adding exact (= ) deps to d-i's output.
[12:07] <infinity> Have britney enforce a rebuild any time anything it was built with changes.
[12:07] <infinity> Or implement Built-Using, fill it in properly, and make Britney enforce that.
[12:07] <infinity> The former is much less effort, though. :)
[12:08] <infinity> I suppose we can't avoid properly implementing Built-Using forever though, so we should probably do it.
[14:54] <cjwatson> infinity: ^- could you review that?  I'm aware the pre-existing code is horrible, and I'm flying blind; but I don't think it can make things worse, and apparently the bug reporter is working to a deadline
[14:54] <cjwatson> infinity: also, can we turn dailies back on now that we know ppc64el was hosed?
[14:59] <infinity> Laney: Did you triple check that that was the only public symbol that was affected by that patch?
[15:00] <infinity> cjwatson: Yes to the latter.  Maybe to the former, I'm waiting on exterminators to knock on the door, I can make no promises once they do.
[15:00] <Laney> Pretty sure. I gave up trying to fiddle with acc to check though
[15:01] <cjwatson> infinity: ok, I'll go ahead and do the latter.  I'll keep your purge-days cowboy for a bit though
[15:01] <infinity> cjwatson: Huh.  People partition /dev/mdX?  Weirdoes.
[15:01] <cjwatson> dmraid apparently
[15:02] <cjwatson> and yeah that's much what I thought
[15:02] <cjwatson> maybe a consequence of the new dmraid looking like mdadm thing
[15:02] <infinity> Oh yeah, it would do.
[15:03] <infinity> That pattern just gets prettier on every iteration, doesn't it?
[15:03] <cjwatson> it sure does
[15:03] <cjwatson> one of these days ...
[15:04] <infinity> cjwatson: s/hs/hms/ -> lexical order, or subconscious desire to join the navy?
[15:05] <cjwatson> lexical
[15:05] <cjwatson> (âllo c'est l'heure)
[15:05] <cjwatson> (oh wait I've mangled that, it was "a l'eau, c'est l'heure")
[15:06] <infinity> cjwatson: And maybe context would be enlightening, but why does the second block hand vdX, but the first not?
[15:06] <cjwatson> I would love to know that
[15:06] <cjwatson> this is in the category of "too scared to fix without extensive testing")
[15:06] <infinity> Lovely.
[15:07] <cjwatson> the whole thing needs refactoring
[15:07] <infinity> With a shotgun behind the shed, yes.
[15:07] <cjwatson> but to do that safely I have to test it on every device type
[15:07]  * didrocks learnt today a new way how English people mock French, thanks cjwatson :p
[15:08] <cjwatson> didrocks: apologies, feel free to mock English
[15:08] <cjwatson> to be fair I think that was more mocking the navy, but point taken :)
[15:08] <didrocks> cjwatson: I think I'm doing that everyday butchering the language with all those typos ;)
[15:09] <didrocks> cjwatson: no worry, was just interesting… Took me some googling to understand the reference though
[15:09] <infinity> The English are too easy a target.  It's like kicking a toddler in the face.
[15:09] <infinity> Except that the toddler's only going to look that way *after* you've kicked him.
[15:29] <apw> cheek
[15:45] <jamespage> ^^ point release needed for openstack horizon
[16:26] <jdstrand> fyi, libvirt has a few libvirt-lxc apparmor policy refinements
[16:27] <ogra_> that dbus and ubuntu.touch-session need to go in together ^^^^
[16:40] <Laney> ogra_: you've found everything that expects this old path?
[16:42] <wxl> are those updates for the bash fix???
[16:43] <cjwatson> er that's just the dailies
[16:44] <cjwatson> I don't know why they're showing up as Beta 2
[16:44] <wxl> i didn't think beta 2 implied dailies
[16:44] <wxl> ah ok
[16:44] <cjwatson> I think it's because Beta 2 hasn't been marked as Released in the tracker
[16:44] <ogra_> Laney, that path was dropped from desktop about one release ago ... thats touch only nowadays
[16:44] <cjwatson> infinity: ^-
[16:45] <ogra_> Laney, desktop even used to use it from a different location in home when it still used it
[16:45] <Laney> what is 'desktop'?
[16:45] <ogra_> Laney, ubuntu desktop ... that was the original consumer
[16:45] <ogra_> from years ago
[16:45] <Laney> I'm not making any distinction like that
[16:46] <ogra_> Laney, anyway, it is touch only
[16:47] <jdstrand> that contains ^ apparmor policy updates that were reviewed by upstream and tested by me and the server team
[16:49] <infinity> cjwatson: Oh, I didn't mark Beta2 as released on the tracker, that's why.
[16:49]  * infinity tries to remember how to do that.
[16:50] <infinity> Done.
[16:50] <cjwatson> ta
[16:51] <wxl> infinity: your g5 uses dvi?
[16:56] <infinity> wxl: PowerStation, not G5, but close enough, and yeah, dual DVI.
[16:57] <wxl> infinity: did you manage to get to the splash screen or did you just check yaboot success/fail the other day?
[16:59] <infinity> wxl: Hrm?  I didn't test any PPC images (except server on a VM)
[16:59] <wxl> infinity: ah, ok, nevermind.
[17:04] <ogra_> Laney, was that Q+A just out of interest or did you plan to unleash dbus ?
[17:08] <ogra_> hmm, seems he said good night in another channel ...
[17:09] <ogra_> could someone else please let dbus thought then (else AP/smoke testing on touch will break now that ubuntu-touch-session landed)
[17:14] <infinity> ogra_: Does it really still need the mkdir there?
[17:15] <ogra_> hmm, i guess not ... unless it doesnt trust upstart to create it (all apps log there under touch anyway)
[17:16] <ogra_> its a no-op i guess
[17:16] <infinity> Kay.
[17:17]  * ogra_ hugs infinity 
[17:17] <ogra_> i'll drop that line in a subsequent upload
[17:17] <ogra_> (for cleanness)
[17:19] <infinity> ogra_: Well, assuming something else creates it.  Maybe others are relying on it. :P
[17:20] <ogra_> i'm pretty sure init creates it when it starts the session .. but yeah, i dont mind either way
[17:48] <Laney> ogra_: I was actually interested in the answer
[17:48] <Laney> but I just got "it's touch only"
[17:48] <ogra_> Laney, well, the only other consumer was the hud ... that dropped using it
[18:42] <stgraber> can somebody pretty please review and accept ^ that's fixing ubuntu touch
[19:22] <infinity> stgraber: Looking.
[19:23] <infinity> stgraber: Ew?
[19:23] <infinity> stgraber: Why aren't packages doing this on install?
[19:24] <ogra_> infinity, they do ... thats the prob :)
[19:24] <stgraber> infinity: they assume adduser/useradd will do it for them
[19:24] <infinity> ... and why isn't it?
[19:24] <stgraber> infinity: but they don't call adduser/useradd when we already created all the users for them
[19:24] <infinity> Okay, and why are we creating the users instead of letting the postinsts do it?
[19:24] <ogra_> infinity, with readonly images (and readonly /etc/passwd) but dynamically assigned UIDs you get a mess
[19:25] <stgraber> infinity: and we create all of the users and groups ahead of time to avoid misordering on the image which breaks the world when uids and gids suddenly change between images
[19:25] <ogra_> if your readonly image ships a different UID all your RW bind-mounted dirs owned by that user get messed up
[19:25] <infinity> Oh, gross.  Okay.
[19:25] <infinity> Yeah, I get the problem.
[19:25] <stgraber> infinity: yeah, not too pleased I had to come up with that hack, but the alternative was even worse :)
[19:26] <stgraber> infinity: (alternative was to detect changes on the device and do some chown all over the place from initrd)
[19:26] <infinity> stgraber: Yeah, that's not at all viable.
[19:26] <ogra_> well, androoid just ships a header file with hard mapping of user and group IDs ... you can only change them at compile time
[19:26] <stgraber> at least now we've got a static list of uid/gid and a second hook which detects additions and fails the build, so we're guaranteed some consistency
[19:27] <ogra_> (as replacement of any password mechanism)
[19:28] <infinity> stgraber: Well, I'm not happy with the explanation, but I guess it's the one I'm going to get. :P
[19:43] <infinity> stgraber: Want to review jdstrand's lxc upload?
[19:44] <jdstrand> stgraber: (it includes what we agreed to earlier and reviewed by hallyn)
[19:45] <infinity> I guess this libvirt upload goes with it?  Seems like it relates.
[19:45] <jdstrand> infinity: it doesn't actually. it is just similar changes for libvirt-lxc
[19:45] <jdstrand> (they're wholly separate)
[19:46] <infinity> jdstrand: Not dependencies, but worth reviewing together to make sure the changes seem to match functionality.
[19:46] <jdstrand> sure
[19:46] <slangasek> infinity: could you have a look at FFe bug #1374609?
[19:46] <ubot2> bug 1374609 in perftest (Ubuntu) "[FFe] update perftest to 2.3+0.12.gcb5b746-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/1374609
[19:47] <jdstrand> stgraber: fyi, the libvirt-lxc changes don't use the more lenient unix (receive) and signal (receive) because these a) each container has its own profile and b) there is no preexisting policy for libvirt-lxc prior to utopic
[19:49] <jdstrand> stgraber: also, libvirt's control file was updated previously for apparmor
[19:49] <infinity> 1.2-OFED-1.4.2-2 -> 2.2.0.19-1 -> 2.3+0.12.gcb5b746-1 ... This package sure has some creative versioning.
[19:51] <infinity> slangasek: No open bugs since it was uploaded (or at all, for that matter, I wonder if it has users?), built everywhere, complete leaf.  Go for it.
[19:54] <stgraber> jdstrand: yeah, I don't care about libvirt, that's fine to use the more restrictive one there :)
[19:54] <stgraber> I'll do the review for both
[19:58] <slangasek> infinity: thanks