[01:07] <vipzrx> hello
[01:29] <stokachu> doko_: do you have plans on merging puppet 3.2.1 into saucy?
[02:29] <RAOF> @pilot out
[04:18] <pitti> Good morning
[06:14] <didrocks> doko_: hey! did you get any time to have a look at bug #1192567? Seems mterry did for one, but the iso will still be blocked by it
[06:25] <m4n1sh> pitti: when you are free, please check your @debian or @ubuntu mail
[06:27] <pitti> m4n1sh: in general I'm happy to help out with Debian sponsoring; but my new GPG key still isn't updated in Debian, so I can't actually upload :/
[06:28] <pitti> m4n1sh: so, what I can do is look over the package and see whether I spot anything weird
[06:28] <m4n1sh> pitti: it is a dead simple package, a bunch of python scripts and a desktop file. Can you review it and refer it to someone else whom you know can help me upload it to debian?
[06:28] <m4n1sh> yeah. that would be better. referring it to someone whom you know is willing to help would be appreciated
[06:40] <pitti> m4n1sh: replied
[06:44] <didrocks> cjwatson: trying to fix the dep (invalid .pc file included) pointed by mterry, but we got no feedback on other ^
[06:44] <didrocks> cjwatson: not sure about the tests, will ask Mirv to get them run during build once he's back from holidays
[06:45] <didrocks> cjwatson: if doko can't review the others today, I would propose that my +1 takes action once qtwebkit-dev fixed and promote it, but your pick :)
[07:22] <dholbach> good morning
[07:46] <pitti> apw: hey Andy
[07:46] <apw> pitti, yo
[07:46] <pitti> apw: I did some investigations for bug 1108082 and I think I found the option which we disable
[07:46] <pitti> apw: so this is now a mere matter of resetting our config value to the default one
[07:47] <pitti> apw: is there some way to mark the bug so that it gets in the kernel team's queue?
[07:49] <apw> pitti, where is affected, is this devel or everywhere
[07:49] <pitti> apw: all releases, but it's not something we want to change in stables; so saucy only
[07:54] <tseliot> apw: the kernel available here doesn't have drm (the latest from the mainline ppa does though): https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[07:56] <apw> pitti, ok put that on my plate and i'll do it now, mostly get it to me or jsaulisbury is the normal way, he has a tag he uses, but i forget -- i don't have one :(
[07:57] <pitti> apw: ah, I thought about assinging it to someone appropriate, or set a milestone, or whatever you use in the kernel team to manage the bug queue
[07:57] <pitti> apw: but if "bother you on IRC" is the accepted way, that WFM :)
[07:58] <apw> pitti, for me, probabally the safest :)
[08:01] <tseliot> apw: so I don't think that kernel will work with any graphics driver
[08:05] <apw> tseliot, yep i'll look next
[08:07] <tseliot> apw: ok, just please don't upload it or hell will break loose ;)
[08:07] <apw> tseliot, the previous build worked as i am running it, so that is odd
[08:08] <tseliot> apw: maybe drm was accidentally disabled in the config
[08:10] <apw> tseliot, given how they are made i would be supprised, but will look shortly
[08:12] <tseliot> apw: yes, the config looks fine here. It's just that the package is missing the actual modules
[08:28] <didrocks> cjwatson: FYI: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/5
[08:28] <didrocks> cjwatson: so, just tell me how you want to proceed for the other deps
[08:40] <apw> tseliot, which packages did you install specificially
[08:40] <apw> tseliot, did you install linux-image and linux-image-extra ?
[08:40] <tvoss> I'm having problems creating a saucy chroot on Hardy, the process bails out when trying to extract libglib-2.0. Is there something known about the issue?
[08:41] <apw> tseliot, as the drm modules seem to be in there:
[08:41] <apw> -rw-r--r-- root/root    476924 2013-06-17 13:48 ./lib/modules/3.10.0-0-generic/kernel/drivers/gpu/drm/drm.ko
[08:41] <tseliot> apw: linux-headers-3.10.0-0-generic_3.10.0-0.5_amd64.deb linux-headers-3.10.0-0_3.10.0-0.5_all.deb linux-image-3.10.0-0-generic_3.10.0-0.5_amd64.deb
[08:42] <tseliot> are the modules in the -extra package?
[08:42] <apw> tseliot, ok so you only installed '-virtual' basically, the thin part.  a full -generic pulls -extras as well
[08:46] <tseliot> apw: so the modules are in -extra?
[08:51] <apw> tseliot, no, some of the kernel is in linux, some is in -extras,  drm happens to be in extras but not because it is a module because you don't need it on a server VM
[08:52] <apw> tvoss, hardy?  really ?
[08:56] <tseliot> apw: ok, I had no idea
[09:14] <RAOF> apw: tvoss_ is in the enviable position of trying to work out why a build wedges on the buildds.
[09:14] <doko> jbicha: nothing to do with the cross build, gcc-4.8 fails too
[09:23] <cjwatson> didrocks: OK ... I'm not an MIR reviewer so my word doesn't mean much, but FWIW I guess I'd be happy to proceed temporarily without tests as long as we get a cross-my-heart-and-hope-to-die promise that it'll be sorted out once Mirv is back.  However I do think we need the other deps reviewed
[09:24] <cjwatson> doko: ^- we need to get this sorted out today, FWIW, since image builds being blocked for days is a big deal, so can you either make time for this or make sure somebody else on the MIR team does?
[10:07] <Daviey> doko: ipxe seems to think that gcc 4.8 has a bug (as shown in the rebuild) - https://github.com/ipxe/ipxe/commit/238050dfd46e3c4a87329da1d48b4d8dde5af8a1 .. If it is indeed a gcc bug, i assume it will not be fixed this cycle?
[10:32] <ev> mpt: http://www.engadget.com/2013/06/21/apple-publicly-charts-ios-fragmentation/
[10:36] <davmor2> ev: is that because apple push the updates, in comparison to google where the phone manufactures do, and they want you to buy new hardware not upgrade your existing?
[10:37] <mpt> Ah, the pie chart, William Playfair's biggest mistake
[10:37] <ev> I have no idea, but I'm surprised there are that few first generation iPads out there
[10:37] <ev> heh!
[10:37] <doko> cjwatson, didrocks, yes, looking at it now
[10:37] <doko> Daviey, is there a test case somewhere?
[10:37] <ev> all hail the doughnut chart!
[10:38] <mpt> ev, so when do we see the area chart for Ubuntu? :-)
[10:38] <cjwatson> Now I'm hungry
[10:38] <Daviey> doko: Not as far as i know.  the rebuild you did exposed it to me, and referring upstream who believe it to be a bug.
[10:39] <Daviey> (in gcc)
[10:39] <ev> mpt: I had a conversation about this, but I cannot for the life of me remember why we decided against it for now.
[10:39] <ev> I should stop talking to people in the kitchen and exclusively use email
[10:39] <ev> or maybe just email them in the kitchen
[10:40] <mpt> That's why we need Ubuntu on fridges!
[10:40] <ev> LOL
[10:40] <ev> mpt: quick, lets find a venture capitalist
[10:41] <mpt> Huh, fridge.ubuntu.com still exists
[10:44] <ev> icebox.ubuntu.com? :)
[10:46] <doko> Daviey, believing in a gcc bug is the easiest thing ;p
[10:49] <Daviey> doko: Yeah, lets switch to LLVM - it's bug free.
[10:51] <doko> Daviey, sure, as long as we don't use clang
[10:53]  * cjwatson mutters something about bad workmen and tools :)
[10:54] <Daviey> doko: What i am trying to find out is if you think it is a gcc bug, and if we work around it now.. should we be aware to undo this workaround later in the cycle.
[10:55] <xnox> ev: they measured last two weeks of accessing "apple store", guess what, one no longer can access latest apple store on the first gen / older devices!
[10:55] <doko> Daviey, understood, it's asm syntax, so I have to look into it too
[10:55] <xnox> ev: maybe we should generate ubuntu version fragmentation based on errors.ubuntu.com and point out that everyone is on precise and up =)
[10:56] <ev> xnox: I'm not sure I understand what you mean. I have a first-generation iPad and can access the App Store fine.
[10:56] <ev> xnox: :)
[10:56] <xnox> ev: really?! /me clearly remembers error messages 'you must buy newer apples to continue'
[10:57] <xnox> ev: and is there much to install on a first-gen iPad still?
[10:57] <xnox> what's the highest iOS it can get?
[10:58] <ev> 5.1.1
[10:58] <ev> there are still updates to things like Chrome
[10:58] <ev> Google Currents cannot be updated
[10:59] <xnox> google are generally good, e.g. chrome only recently dropped lucid support.
[11:02] <Laney> oops
[11:02] <Laney> @pilot out
[12:36] <cjwatson> doko,Daviey,jamespage: The /builders 403 bug is now bug 1193057.  I have a test which is appropriately failing, so it shouldn't be too difficult to fix from here.
[12:42] <jdstrand> jodh: hi!
[12:43] <jdstrand> jodh: while you were away, we discussed getting a new upstart with the apparmor patchset into Ubuntu
[12:43] <jdstrand> jodh: and it was decided that we would wait on your return, because there was something else you wanted to have included
[12:44] <jdstrand> jodh: we want to have the apparmor patches in as part of the application lifecycle (a multi-team effort), and as soon as is reasonable for you
[12:44] <jodh> jdstrand: sure. we're in the process of putting a new Upstart release together that will include the Apparmor feature.
[12:44] <jdstrand> jodh: what are your plans with uploading a new upstart?
[12:45] <mdeslaur> jodh: I have a distro patch for the new upstart that needs to go in the distro upload
[12:45] <jdstrand> jodh: awesome. can you coordinate with mdeslaur? he has a distro patch that will need to go with your upload, aiui
[12:45] <jodh> jdstrand: I was imagining early-mid next week.
[12:45] <jodh> jdstrand: ack.
[12:45] <mdeslaur> hehe
[12:45] <jdstrand> jodh: thanks! :)
[12:45] <xnox> mdeslaur: please propose them against lp:ubuntu/upstart it's a "'fully mergeble with lp:upstart" branch.
[12:46] <jdstrand> ricmm: fyi ^
[12:46] <Riddell> doko: ICE in GCC on arm in kde4libs? any thoughts?
[12:46] <Riddell> ../../khtml/svg/SVGStyledLocatableElement.h:45:27: internal compiler error: in extract_insn, at recog.c:2154
[12:46] <Riddell> https://launchpadlibrarian.net/143010200/buildlog_ubuntu-saucy-armhf.kde4libs_4%3A4.10.80-0ubuntu1_FAILEDTOBUILD.txt.gz
[12:46] <mdeslaur> xnox: ok
[12:47] <mdeslaur> xnox: it doesn't have the new upstart now though, right?
[12:47] <doko> Riddell, please open an issue, *including* the preprocessed source
[12:48] <doko> Riddell, can this already be cross-built?
[12:49] <mitya57> Riddell: hi, I've uploaded some fresh Qt 5 merges to saucy, can you please add me to ~kubuntu-packagers so that I can commit it?
[12:49] <Riddell> doko: an issue in gcc bug tracker?
[12:49] <xnox> mdeslaur: not yet, but soonish. What are the distro patches?
[12:50] <Riddell> mitya57: oh cool, sure
[12:50] <mitya57> (namely qttools, qtgraphicaleffects and qtmultimedia)
[12:50] <Riddell> doko: I've never tried any cross building so I don't know
[12:51] <doko> Riddell, yes, a reproducible ICE always is a gcc issue
[12:51] <mitya57> Riddell: thanks
[12:51] <mdeslaur> xnox: a couple of added distro-specific stuff in the apparmor_available() function, and a fail-open when apparmor fails in job_process.c to emulate current ubuntu behaviour
[12:52] <mdeslaur> xnox: let me know when all the apparmor stuff hits lp:ubuntu/upstart, and I'll propose a merge
[12:52] <xnox> i see.
[12:53] <mdeslaur> jjohansen: are your /sys/module/apparmor/parameters/enabled permissions relaxed yet in saucy's kernel?
[12:54] <jjohansen> mdeslaur: no I haven't given the kt a pull request that fix yet
[12:54] <mdeslaur> jjohansen: soon? like, before the new upstart hits? :P
[12:54] <jjohansen> mdeslaur: the dbus ppa kernel should have that fix
[12:55] <jjohansen> mdeslaur: when will the new upstart hit?
[12:55] <xnox> jjohansen: "<jodh> jdstrand: I was imagining early-mid next week."
[12:55] <hallyn> bdmurray: gah
[12:55] <jjohansen> xnox: okay, I'll pull together a kernel pull request
[12:55] <mdeslaur> actually, it doesn't matter as long as we don't use the new stanzas
[12:56] <xnox> by default that is.
[12:56] <xnox> still would be interesting to play with this feautre.
[12:56] <jdstrand> mdeslaur: things are landing fast-- upstart-app-launch is in the archive already. the unity team is working to get those bits too
[12:57] <mdeslaur> yep
[12:57] <jdstrand> mdeslaur: that said, upstart-app-launch doesn't have the stanza yet
[12:57] <hallyn> bdmurray: I don't actually have upload rights to that, so if you reject i'll need to bug someone else over it...  so i'm tempted to say approve it.
[12:57] <jdstrand> but the goal is to have it all together soon. cherrypicking the one patch for the pull request seems reasonable
[12:57] <mdeslaur> jdstrand: what are you referring to?
[12:57] <jdstrand> jjohansen: the pull request jjohansen mentioned
[12:58] <mdeslaur> oh, yes, definitely
[12:58] <jdstrand> iirc, it was just a teeny little patch
[12:58] <mdeslaur> it needs to happen asap when the new upstart is available
[12:58] <jdstrand> ok
[12:58]  * jdstrand nods
[12:58] <mdeslaur> I just meant stuff won't explode if upstart gets uploaded a day before that patch goes in
[12:58] <jdstrand> ok, yes, agreed
[12:59] <jdstrand> we won't add the stanza to upstart-app-launch until the other bits are in place
[12:59] <xnox> jdstrand: mdeslaur: sounds like we'd want a versioned depends anyway...... but then again there is no way to define one for _all_ kernels......
[13:00] <mdeslaur> xnox: it's not important enough for a versioned depends...I don't want to prevent someone from testing older kernels
[13:00] <xnox> also considering the case where we are booted into old kernel, yet upstart is upgraded and statefully re-execed, how badly things greak?
[13:00] <jdstrand> well, we'll need to handle that gracefully, cause people use test kernels without apparmor,e tc
[13:00] <mdeslaur> it just won't allow user session apparmor switches
[13:00] <jdstrand> (or disable, etc, etc)
[13:01] <jdstrand> mdeslaur: yeah, your patchset already handles all that, right? that is your distro patches, correct?
[13:01] <mdeslaur> xnox: it will fail gracefully, no issue
[13:02] <xnox> mdeslaur: fair enough.
[13:02] <mdeslaur> jdstrand: not the distro patches, the upstream upstart will simply not start user jobs that require an apparmor switch
[13:02] <jdstrand> ok-- I thought I remembered it was all handled, couldn't remember where
[13:02] <mdeslaur> sorry, it will start them, just without the switch
[13:03] <jdstrand> we probably want upstart-app-launch to have a versioned depends on the upstart that has the apparmor patches when we add the apparmor stanza
[13:03] <jdstrand> but that is different
[13:07] <mdeslaur> doko: are you going to merge puppet, or can I go ahead?
[13:07] <doko> mdeslaur, please go ahead
[13:07] <mdeslaur> doko: ok, thanks
[13:14] <tedg> jodh, hello, it seems that we're ending up in a situation where the unity job isn't starting.  It actually seems to be hanging.
[13:14] <tedg> jodh, Any ideas for debugging that?
[13:15] <jodh> tedg: anything in ~/.cache/upstart/unity.log ?
[13:15] <tedg> jodh, No, it isn't even created
[13:15] <tedg> jodh, xsession is blocking on initctl emit xsession
[13:16] <xnox> tedg: racing against gnome-session? e.g. it has been started outside of upstart and hence now the upstart's unity dies whilst re-spawning?
[13:16] <xnox> tedg: are there any unities running?
[13:17] <xnox> in like $ ps output
[13:17] <tedg> xnox, No, no instances of compiz.  And I'm not getting any flicker of the compositor turning on and off.
[13:18] <tedg> I took out the waiting on the xsession event.  And the pre-start script that we had, but it seems to be roughly the same (except that xsession-init doesn't block)
[13:19] <tedg> Basically the job never leaves "start/starting"
[13:22] <jodh> tedg: can we see the updated .conf somewhere?
[13:22] <tedg> The one I stripped down to debug is here: http://paste.ubuntu.com/5786760/
[13:22] <tedg> But then one you have on your system does the same.
[13:23] <tedg> I was just trying to remove variables
[13:28] <jodh> tedg: does that compiz build run from the command-line ok? also why have we lost the post-start and pre-stop?
[13:28] <tedg> jodh, Yes, it runs from the command line.  And I was cleaning things up a bit thinking they might be the issue.
[13:29] <jodh> tedg: also, on my hardware, respawn is absolutely essential :)
[13:29] <tedg> Heh, sure.
[13:29] <tedg> I need to set it up to put some limits on that.
[13:30] <tedg> I ended up with a bug a couple weeks ago where compiz was restarting so fast I thought my CPU was going to melt :-)
[13:39] <infinity> tedg: Say, you're a desktop guru.
[13:39] <tedg> It'll never catch on.
[13:39] <infinity> tedg: What bit hinders my ability to reboot from the gear menu if I've logged in on another console?
[13:39] <infinity> tedg: And, more pressingly, why does that bit continue to hate me even if I've logged in *and out* on another console?
[13:41] <tedg> infinity, Well, we get that info at different points, so it might be broken in either indicator-session or the gnome bits.  But we get the info from ConsoleKit/LoginD.
[13:41] <tedg> infinity, Are you not getting the prompt or is it not working once you're rebooting?
[13:41] <xnox> infinity: logind?!
[13:42] <xnox> infinity: for me logind usually proactively kicks it and kills everything for me. Btw. open a terminal and execute "$ stop" =) it's left as an exercise to the reader to work out what that does.
[13:43] <jodh> tedg: I've disabled unity.conf on my system, yet something (the panel service?) is starting it anyway.
[13:44] <tedg> jodh, It's gnome-session.  You need to edit: /usr/share/gnome-session/sessions/ubuntu.session
[13:45] <tedg> jodh, Make it look like: http://paste.ubuntu.com/5786806/
[13:46] <infinity> tedg: When you ask it to reboot, it logs you out instead.  Which is arguably correct behaviour if I really am logged in on another console (though it would be swell if you could somehow pass a message to lightdm that would print a "Reboot prohibited due to active sessions on another console" message or something)
[13:47] <infinity> tedg: But yeah, I've noticed the same behaviour if I logged in on another console and logged out again.  Not a race condition, as that login could have been days ago, so perhaps a refcounting issue in something.
[13:47] <didrocks> doko: any progress on the review for qtwebkit?
[13:48] <tedg> infinity, That sounds like a gnome-session issue as I think we pass the command directly to them.
[13:48] <seb128> infinity, did you try today?
[13:48] <seb128> I just go a "another user is logged in, enter your admin password to reboot anyway"
[13:48] <infinity> seb128: Nope, although I did just do an upgrade on a text console today, so we're about to find out when I try to reboot. :P
[13:48] <seb128> I'm wondering if the gnome-session 3.8 update from yesterday fixed that
[13:48] <seb128> you need to start a new session to get that gnome-session running though
[13:48] <infinity> Maybe this is a fixed problem as of this week.  We'll see.
[13:49] <seb128> but yeah
[13:49] <infinity> Well, we'll see when I'm in a position to reboot and test.
[13:49] <seb128> infinity, but yeah, known issue other: https://bugs.launchpad.net/indicator-session/+bug/861171
[13:50] <seb128> infinity, we almost got a fix, robert_ancell had a vcs branch: https://code.launchpad.net/~robert-ancell/indicator-session/lp-861171/+merge/137085
[13:50] <seb128> infinity, http://imgur.com/K3CzMrV
[13:50] <infinity> tedg: While I'm whining about desktop things, has anyone reported and/or fixed a bug about unity-panel-service spinning out of control, stealing focus, and making their desktop useless for seconds/minutes?  Is that another bug I should expect is fixed as of today and I just need a reboot? :P
[13:50] <seb128> but then the unity guys replaced the indicator-session dialogs by unity ones
[13:51] <tedg> infinity, There were some issues there with people who have indicator-network installed, is that you?
[13:51] <seb128> infinity, I didn't read any bug like that one you just described
[13:51] <infinity> tedg: Nope.  The only non-standard indicatory thing I have installed is pidgin.
[13:51] <infinity> tedg: Which may well be the problem, dunno.
[13:52] <tedg> infinity, Seems unlikely.
[13:52] <tedg> infinity, Hmm, so no, haven't seen anything like that.  Not sure how the panel service could steal focus though....
[13:52] <infinity> Alright, I'll finish up this upgrade, reboot to make sure I'm in clean and upgraded sessions, then see if I can reproduce and file a bug.
[13:53] <infinity> tedg: I'm not sure how it steals focus either, but it does.  Hangs on to both mouse and keyboard while it's spinning a core to oblivion, and sometimes for several minutes.
[13:53] <seb128> tedg, charles: btw it could still be useful to get https://code.launchpad.net/~robert-ancell/indicator-session/lp-861171/+merge/137085 merged in
[13:53] <doko> didrocks, I'm looking at it currently, but not exclusively, started an hour or two ago
[13:53] <seb128> those dialogs are still used in e.g the greeter
[13:54] <infinity> tedg: If I can come up with a useful reproduction recipe, I'll aim a bug at you.
[13:54] <infinity> tedg: The part where you've never heard about it before is a bit disconcerting, I wonder if I've done something terrible locally.
[13:55]  * cjwatson pushes up https://code.launchpad.net/~cjwatson/launchpad/builders-visibility/+merge/170818 - hopefully that'll sort out all the remaining /builders 403 bugs
[13:56] <seb128> infinity, the flickering is usually a segfault, did you try to attach gdb to it?
[13:56] <infinity> cjwatson: Oh, shiny.  I'd asked wgrant to look at that and tell you not to waste your time on it, but I'll happily accept your fix anyway. :P
[13:57] <infinity> seb128: I've not attempted any debugging yet, first step was to ask people if it was already known/in-progress.
[13:57] <cjwatson> Yeah, too slow, and I was interested anyway :)
[13:57] <infinity> seb128: I'll try to reproduce after my next reboot and see if I can get anything useful out of it.
[13:57] <seb128> infinity, no, but if that's a segfault of the service any indicator could cause it, stacktrace would help to say if that's known
[13:57] <seb128> infinity, thanks
[13:57] <infinity> cjwatson: Does that fix both the copy-from-public-to-private bug and the private-recipe bug?
[13:59] <infinity> cjwatson: (The private recipe one being lower priority, since it's only for a few seconds at a time instead of potentially hours, but I figured the fix would probably be similar)
[13:59] <cjwatson> infinity: I believe so.  It wasn't actually private-recipe as such, it was a recipe built from public branches for an archive owned by a private team
[13:59] <infinity> cjwatson: Oh, I note you have both bugs linked from the branch.
[13:59] <cjwatson> Ever since wgrant's fix for bug 728673, those two cases have gone through identical formatter code
[14:00] <cjwatson> So in both cases it's "ooh, shiny, the PackageBuild is visible, let me try to render archive.owner.name"
[14:00] <cjwatson> *splat*
[14:00]  * infinity nods.
[14:01] <cjwatson> At least as far as I could work out
[14:19] <Daviey> cjwatson: super, thanks!
[14:30] <bdmurray> hallyn: okay
[14:36] <seb128> shrug
[14:37] <seb128> doko, something in the gcc-4.8 4.8.1-2ubuntu1 -> 4.8.1-3ubuntu1 or binutils 2.23.2-2ubuntu3 -> 2.23.52.20130612-1ubuntu1 broke gtk on armhf
[14:37] <seb128> doko, is there any known issue in those updates?
[14:37] <seb128> Laney, pitti, didrocks: ^ fyi
[14:37] <Laney> you tested with the old versions?
[14:37] <seb128> the failing test doesn't fail if I rebuild with those downgrades
[14:37] <seb128> Laney, I downgraded both and tested on my n7
[14:38] <Laney> are they tied together such that you can't isolate which one it is?
[14:38] <seb128> will update binutils and try again
[14:38] <Laney> cool
[14:38] <seb128> Laney, no, it's just that it takes 3 hours to build gtk on this thing
[14:38] <Laney> thanks for investigating
[14:38] <seb128> so I went for "let's see if that's the toolchain"
[14:38] <Laney> is porter-armhf faster? ...
[14:38] <didrocks> seb128: thx
[14:38] <seb128> Laney, I can't downgrade packages on porter-armhf
[14:38] <Laney> oh yeah
[14:38] <seb128> Laney, sudo give you apt but not dpkg or edit of sources.list
[14:39] <Laney> I forgot about that restricted apt business
[14:39] <ScottK> seb128: kde4libs broke too.
[14:40] <infinity> seb128: binutils seems like the more likely culprit, given all that's changed in that snapshot.
[14:41] <seb128> ScottK, thanks, that's useful information ... did anyone figure out what exactly change/broke? do you have a bug about it?
[14:42] <ScottK> seb128: No, there was an ICE in the build overnight.
[14:43] <ScottK> Since ~none of the involved people have working arm hardware that's anything other than really, really slow, we didn't get far with it.
[14:43] <seb128> yeah, I'm fighting that was well
[14:43] <seb128> the porter box I've access to doesn't give me enough rights to downgrade packages or install custom debs
[14:43] <seb128> the nexus is sloooow
[14:44] <Laney> I could give you ssh to my panda if you want it
[14:44] <infinity> The Nexus7 is faster than a Panda.
[14:44] <ScottK> xnox has some really fast hardware apparently, but no time to operate it.
[14:44] <infinity> (except possibly for storage I/O)
[14:45] <Laney> It's got a USB disk attached for better IO
[14:45] <Laney> so only takes 1h46 to FTBFS gtk
[14:45] <infinity> ScottK: He does?
[14:45] <infinity> xnox: You have fast ARM hardware?
[14:45] <ogra_> highspeed pandas :)
[14:45] <ScottK> He claimed to.
[14:45] <seb128> Laney, thanks but that's ok, I can "just" make clean in the gtk/ subdir and rebuild that part, which should take less than 1h
[14:45] <ScottK> But then he said something about Friday and going to the beach.
[14:46] <Laney> k
[14:46] <seb128> infinity, the issue is I/O indeed
[14:47] <infinity> seb128: Don't forget to -j4 for your N7's cores. :P
[14:48] <seb128> yeah
[14:55] <Riddell> looks like qtwebkit-source has a similar arm gcc internal error
[14:56] <Laney> always with the minimal reproducers :P
[14:56] <xnox> infinity: not what you think.
[14:58] <xnox> infinity: i have nexus7 (currently in flux testing cross-compiled flipped images), panda, and in-ram qemu across 8 ivy-bridge cores (which apparently cannot build kde*).
[14:58] <xnox> infinity: have you got the actually fast ARM hardware for us in launchpad yet? =)))))
[15:04] <charles> seb128: right, I'm going through i-session's merge requests today
[15:05] <seb128> charles, thanks
[15:05] <charles> seb128: actually there are also a couple of patches already merged that I need to retrofit for the GMenu code
[15:05] <infinity> xnox: We're still burn-testing our Calxeda kit.
[15:05]  * xnox ponders why pull-debian-source e2fsprogs unstable pulls something old, instead of what launchpad thinks it should be for about 4 hours now. Does pull-debian-source talks to something else to query latest/greatest version numbers for debian?
[15:05] <charles> seb128: after that, I can finally mark those merge conflicts as resolved on the gmenu branch, and finally let CI run it... :)
[15:05] <xnox> infinity: ack.
[15:06] <seb128> charles, \o/
[15:08] <didrocks> jdstrand: seems mterry wants a quick security audit for qtscript-opensource-src
[15:08] <didrocks> cjwatson: FYI ^
[15:38]  * ScottK LOLs at "quick security audit" and Qt in the same sentence.
[15:39] <jdstrand> didrocks: ack, but I can't today. added to todo for monday
[15:40] <didrocks> cjwatson: ^ not sure how this is going to end for the ISO :/
[15:42] <mdeslaur> gah! another unmaintained javascript engine, how awesome
[15:44] <jdstrand> mdeslaur: that is supposed to only be temporary-- ie related to qt5webkit
[15:44] <xnox> didrocks: something did build today... http://cdimages.ubuntu.com/daily-live/20130621/
[15:44] <didrocks> mterry: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/11
[15:44] <didrocks> xnox: interesting…
[15:45] <didrocks> mterry: looking at qt3d now, the fix should be the same
[15:45] <mdeslaur> jdstrand: nothing else uses qscript yet?
[15:45] <mterry> didrocks, cool
[15:45] <infinity> jdstrand: Do we have a long-term plan for webkit that actually makes sense?  I saw you mention it in passing, but I'm curious if whatever we do will end up being reusable by all the flavours that need a webkit, or if it'll end up being vaguely UbuntuDesktop/Touch-specific.
[15:45] <jdstrand> mdeslaur: it is being pulled in because of the signon changes needing qt5webkit, and qt5webkit needing it, so no
[15:46] <jdstrand> infinity: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-webkit-maintenance
[15:46]  * infinity is pretty non-plussed with the trend of embedding webkit and v8 all over the world.
[15:47] <jdstrand> infinity: the plan is being formed. we think we have come up with something reasonable, so 'yes'
[15:48] <infinity> "Package Chromium Content library and develop Ubuntu SDK bindings for the Chromium Content library."
[15:48] <jdstrand> but the plan does not include maintaining all the various bindings (webkit-gtk, qt4webkti and qt5webkit)
[15:49] <jdstrand> the plan is create our own bindings that others can use
[15:49] <infinity> jdstrand: So, this means we'll be tied to v8 (while Qt was planning to move to a new JS engine that might actually work on more than 2.5 platforms)
[15:49] <jdstrand> if you are referring to QML, that is different
[15:50] <jdstrand> we'll follow upstream Qt on that
[15:50] <jdstrand> the javascript that is in the webview and the javascript used for interpreting QML are different now and will continue to be
[15:50] <ScottK> infinity: The Ubuntu webkit stuff will be Ubuntu specific.  It won't help us any.
[15:51] <infinity> ScottK: Yeah, I just got through the proposal and came to the same unfortunate conclusion.
[15:51] <jdstrand> ScottK: that is a rather pessimistic view. we will be making our bindings available to upstream
[15:51] <infinity> Sadly, I'm not sure I see a better option other than "make all the upstreams get along"... This certainly isn't a situation of our making. :(
[15:51] <jdstrand> if upstream upstream qt wants to take that and help, great, if not, they can continue to do as they've always done
[15:51] <infinity> jdstrand: Given that we could never get people to merge and collaborate on webkit codebases before, I doubt offering them a third option will get anywhere.
[15:52] <ScottK> jdstrand: When the proposal was announced we talked to rekonq upstream about supporting it and got told they weren't going to do distro specific webkit variants.
[15:52] <infinity> (Or a fourth option, now that Google has forked too)
[15:52] <ScottK> So I'm not guessing.
[15:52] <jdstrand> that is a valid point. toolkit upstreams have different requirements than we do
[15:52] <jdstrand> ScottK: I am not talking about rekonq. I am talking about qt upstream
[15:53] <ScottK> If you can sync up with them, then yes, that helps us a lot.
[15:53] <ScottK> (and it's no longer distro specific)
[15:53] <ScottK> The plan I saw was for an Ubuntu specific stabilized/maintained version.
[15:53] <mdeslaur> just to be clear, we're not doing webkit, we're doing blink
[15:54] <jdstrand> well, we're doing the chromium content api, which includes blick underneath
[15:54]  * xnox .... which was discussed before blink
[15:54] <jdstrand> blink*
[15:54] <xnox> right.
[15:55] <jdstrand> the webkit landscape is unfortunate and depressing in general. we can't solve that (google and apple couldn't solve it either)
[15:55] <jdstrand> so we are working with the available options
[15:58] <infinity> jdstrand: Yeah, I'm not sure the plan qualifies as "sane", but I'm equally unsure that there's a better option that we can drive.
[15:58] <mdeslaur> it's not a sane plan, it's the less insane plan we could come up with
[15:58] <infinity> And given everyone's reluctance to stabilise a One True Webkit upstream, there's not much we can do.
[15:58] <mdeslaur> webkit's future is in flux
[15:58] <infinity> mdeslaur: That statement's been true for years.
[15:59] <mdeslaur> with google gone, apple's been removing all the platform specific stuff
[15:59] <mdeslaur> it's gotten worse
[15:59] <infinity> If Apple and Google would just hand over the reigns to a third party (Collabora comes to mind?), this could all be cleaned up, but they don't like giving up their toys.
[15:59] <infinity> s/reigns/reins/
[16:00] <didrocks> mterry: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/12. So I guess only qtscript is the remaining blocker one.
[16:00] <mdeslaur> whoever controls the web controls the ad revenue, so I doubt they will give up their livelyhood for the sake of the greater good
[16:00] <didrocks> doko: I think mterry has beat you :)
[16:01] <infinity> mdeslaur: But if there's anything the Linux kernel has taught people, it's that the greater good is also the individual good, with a well-managed and non-biased upstream.
[16:01] <jdstrand> didrocks: if it helps, I'll give the ok to pre-promote (in this case it doesn't make a lot of sense to block on a security audit that is temporary-- I'll make the same comment on it too)
[16:02] <infinity> mdeslaur: But, yeah, a hard sell, when it's the sort of thing that needs to go all the way to the top of the management chains at the US's two most powerful tech companies, nevermind the two large open source stakeholders than also can't get along.
[16:02] <didrocks> jdstrand: yeah, I'm not sure what we built as an image, but at least, that would be awesome to do that, do you want me to keep the bug status for qtscript as opened?
[16:02] <mdeslaur> infinity: I'm not sure...the kernel is pretty much a commodity...it's not the differentiating factor that makes your product better than the competitors
[16:02] <didrocks> jdstrand: oh btw, you did see that it's similar for libhybris, right?
[16:02] <didrocks> jdstrand: you were on holidays when it happened, I assigned it to you IIRC
[16:03] <didrocks> (but had to prepromote, and it's only used in the touch image which was already installing it)
[16:03] <didrocks> jdstrand: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1188213 FYI
[16:03] <mdeslaur> but yeah, in an ideal world we'd get a single browser engine that everyone would use
[16:03] <infinity> mdeslaur: That's not true at all in the case of Android, for instance.
[16:03] <infinity> mdeslaur: Where Google's finally been upstreaming all their fancy for the greater good (and, more importantly to them, reduced maintenance burden).
[16:04] <mdeslaur> infinity: I don't purchase my phone based on kernel capabilities
[16:04] <infinity> mdeslaur: And the webkit landscape is an absolute mess for maintenance burden.  The merging between the (now four) major forks is insane.
[16:04] <infinity> mdeslaur: You don't purchase your phone based on how shiny the web browser is either. :P
[16:05] <infinity> mdeslaur: And only the nerdiest of the nerdy choose their desktop browser based on killer features too.  Normal people really don't.
[16:05] <jdstrand> didrocks: I didn't, thanks
[16:05] <mdeslaur> infinity: normal people choose whatever seems to work best
[16:05] <didrocks> jdstrand: seems you already have a fun schedule for next week :p
[16:05]  * jdstrand always has a fun schedule :P
[16:06] <didrocks> heh
[16:06] <infinity> mdeslaur: Right, which has little to do with shiny new features, but rather stability and some combination of standards and quirking.
[16:06] <mdeslaur> infinity: but google wants chrome to get the shiny new features first
[16:07] <mdeslaur> which work with the coolest websites
[16:07] <mdeslaur> which makes people want chrome
[16:07] <mdeslaur> etc.
[16:07] <infinity> mdeslaur: A blessed upstream and downstreams maintaining feature branches would solve that need.
[16:07] <mdeslaur> perhaps
[16:08] <infinity> mdeslaur: (Much like Linux distributions will often land features before committing upstream, just to have that tiny head start).
[16:13] <didrocks> jdstrand: mterry: kenvandine: seb128: cjwatson: ok, promoted all components as per discussion and fixes and prepromoted qtscripts. I set the qtscripts task to NEW and all other to fix committed. We should be back to normal iso building
[16:26] <cjwatson> xnox: The ISO parts built today, but the livefs parts didn't.  Look at the timestamps on *.manifest
[16:27] <cjwatson> didrocks: Thanks
[16:28] <didrocks> cjwatson: thanks to mterry for the MIR reviews (and jdstrand for the future security review ;))
[16:28] <xnox> cjwatson: ah.
[16:28] <mterry> :)
[16:29] <cjwatson> didrocks,mterry: looks like the two of you raced setting the status of the qt3d-opensource-src task on that bug?
[16:30] <mterry> cjwatson, aye, fixed
[16:30] <didrocks> cjwatson: indeed! mterry you are too slow! :p
[16:30] <didrocks> thanks
[16:32] <didrocks> cjwatson: even if qtwebkit-opensource-src entered -proposed as 5.0.1-0ubuntu3 in universe, it will get into main once copied to the release pocket (as 5.0.1-0ubuntu2 is)?
[16:35] <cjwatson> There are some bugs around override handling with copies
[16:35] <cjwatson> Keep an eye on it; it's possible you may need to repeat the override
[17:02] <seb128> infinity, doko: seems it's on of the changes in gcc-4.8 4.8.1-2ubuntu1 -> 4.8.1-3ubuntu1  that broke gtk on armhf, any idea which one could create issues?
[17:05] <infinity> seb128: Have you tried with -4ubuntu1?
[17:06] <infinity> seb128: (And no, I'm afraid I'd have no idea, but doko might)
[17:07] <seb128> infinity, no, let me try that ... I started those builds yesterday
[17:07] <seb128> shrug and there is new svn version in 4ubuntu2
[17:07] <seb128> can try directly I guess
[17:07] <infinity> seb128: -4ubuntu2 would be more interesting, but it's still building. :P
[17:08] <seb128> will take another 9 hours or so to have it available it seems
[17:08] <seb128> that's a job for monday then
[17:08] <seb128> let me try ubuntu1 still
[17:09] <infinity> Oh, hey, all the things I was waiting for are done, I can reboot now and see if unity-panel-service still hates me.
[17:10] <doko> there shouldn't be that many changes
[17:10] <doko> seb128, what did break?
[17:11] <seb128> doko, I'm not sure to understand what's happening, css parsing in gtk return an assert when building with that gcc version
[17:12] <seb128> like if the datas were corrupted
[17:12] <seb128> the css is embedded in the binary as a resource
[17:12] <ScottK> doko: There's an ICE on armhf with kde4libs, not sure what it's about.
[17:12] <seb128> but extracting it with gresource (the command line utility to deal with those) gives a valid file
[17:13] <ScottK> It's the first attempt on a major new version, so I don't know if it's a new issue on gcc 4.8 or newly exposed due to upstream code failing.
[17:13] <doko> ScottK, preprocessed source needed. Riddell told me
[17:13] <doko> seb128, -3 had the linaro toolchain update, so yes, it could be ...
[17:13] <ScottK> ENOHARDWARE
[17:17] <seb128> doko, is there any kind of testing I can do that would make figuring out what change is creating the problem easier?
[17:17] <doko> seb128, maybe open an issue for gcc and gtk, to collect more information?
[17:17] <seb128> doko, yeah, I will do, it took me a day to figure out it was gcc that changed for the issue to start
[17:18] <seb128> doko, I'm just going to test with your new uploads from today first
[17:18] <doko> seb128, well, try to lower the optimization level in the gtk build, then try to combine object files from a O1 and O2 build until you find something odd
[17:18] <seb128> doko, ok; thanks
[17:18] <doko> but I'm afk now
[17:18] <seb128> that can wait next week
[17:18] <seb128> doko, have a good w.e
[18:02] <saiarcot895> If I need to fix a build failure on Ubuntu, do I create a branch and merge it into the saucy-proposed version of the branch?
[18:03] <cjwatson> I usually just use saucy even though that's technically arguably a bit incorrect
[18:05] <cjwatson> It'll usually be correct soon enough
[18:05] <saiarcot895> Thanks cjwatson
[19:26] <hallyn> infinity: would you mind taking a look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?  the .10 is a better fix by/for arges than the .9 which is pecolating in precise-proposed right now.
[19:26] <hallyn> (then i need to get to work on a 1.0 stable upstream tree based on the patches in our package)
[21:28] <ricmm> jdstrand: ping
[21:28] <ricmm> jjohansen: any update on the patches?
[21:29] <jjohansen> ricmm: sorry, yeah I am currently reworking my audit shim, and then I will rebuild and test again.
[21:29] <ricmm> great, thanks
[21:30] <ricmm> did you get to reach maguro?
[21:30] <jjohansen> ricmm: The backport for all 4 are done, besides the reworking the shim and any other errors I might yet find
[21:30] <ricmm> awesome! great work
[21:30] <jjohansen> ricmm: I am will send out pull requests for all of them today
[21:31] <ricmm> jjohansen: great :) can you cc me in any email? to be in the loop
[21:31] <jjohansen> ricmm: sure
[21:31] <ricmm> ricmm@c.c
[23:51] <wgrant> cjwatson, infinity: Right, recipes themselves can't be private, and recipes can't use private branches, so "private recipe build" just means "recipe build in a private archive"
[23:51] <wgrant> cjwatson: Thanks for fixing that. Had it planned for Monday, but this is easier :)