[00:00] <slangasek> stgraber, ScottK: ^^ should I turn off autobuilds, to let the stuff on http://iso.qa.ubuntu.com/qatracker/milestones/255/builds start being validated?
[00:00] <skaet> slangasek, checklist for milestones still has 3 days before,  so folks may not be thinking to tell you explicitly.   Can you send email out to ubuntu release?
[00:01] <slangasek> skaet: fair enough
[00:01] <slangasek> stgraber, ScottK: so, disabling per the above
[00:02] <skaet> highvoltage, Riddell (also)  ^ please let slangasek know when you want a rebuild.
[00:07] <Riddell> ack
[00:09] <stgraber> skaet: we're still discussing with highvoltage (in person) but there are good chances we'll do a last minute opt out from alpha-2 as the bits we wanted to land aren't quite there yet and we have 12.04.2 that's much more important to us
[00:42] <infinity> plars: How long does it take you to spin up a quick alternate test install?
[00:43] <infinity> plars: Comparing file lists, I think it's plausible that I've fixed https://bugs.launchpad.net/ubuntu-cdimage/+bug/1121179 in the latest precise dailies, but it needs an install test to be sure it all works.
[00:43] <ubot2> Ubuntu bug 1121179 in Ubuntu CD Images "Ubuntu 12.04.2 alternate AMD 64 ISO image Feb 10 installing mesa 8.0.4 not 9.0.0 - LTS quantal" [High,Triaged]
[01:22] <stgraber> infinity: so I have a fix for LTSP itself which I think will work, however I need to come up with some clever hack to test it as it could just be the bug hiding some more X-stack related problems
[01:23] <infinity> stgraber: Well, it wouldn't have been x-stack-related at all, it was tripping up trying to install a kernel that's not on the media.
[01:25] <stgraber> infinity: sure, but once it's past that step it'll try to install a bunch of packages which depend on the X stack and we can't see that going until the kernel problem is fixed
[01:26] <infinity> stgraber: True.  Though, as long as it's not explicitly installing individual X bits, but rather just installing ubuntu-desktop or something, it should work.
[01:26] <stgraber> it's installing individual X bits
[01:26] <infinity> Oh, that could be fun. :)
[01:26] <stgraber> that's why I'm worried ;)
[01:26] <infinity> They should all be provided in one way or another.
[01:26] <infinity> But we'll see.
[01:27] <stgraber> right, for now I'm not changing any of the dependencies and hoping the provides will be enough, otherwise I'll have to add a bunch of XYZ-lts | XYZ to ltsp and ldm
[01:29] <stgraber> infinity: is that the one I need for the X stack ^ or is 11.1 enough?
[01:31] <infinity> stgraber: .1 should be fine, this one just drops a langpack.
[01:31] <stgraber> ok
[01:31] <antarus> infinity: sigh, I see your kernel upload for 3.2 and I just think 'damn why do I roll my own kernel'
[01:31] <infinity> antarus: Yeah, why do you?
[01:32] <infinity> &^@!$ 708MB and 705MB... So close to 703.
[01:32] <infinity> Yet so very far.
[01:32] <infinity> We've officially run out of languages to remove (other than English), this could get interesting.
[01:35] <stgraber> who needs English, just ship with C.UTF-8 ;)
[01:36] <infinity> Dude, I've been making that argument for a while.
[01:36] <antarus> infinity: still trying to figure that part out ;)
[01:36] <infinity> antarus: Our kernel SRU release process has gotten remarkably slick over the last year or two, I'd say you can't really go wrong.
[01:38] <antarus> I'm fairly sure we have patches you won't take
[01:38] <infinity> Try us.
[01:38] <infinity> (Or, better yet, get them upstream)
[01:38] <antarus> I'm fairly sure we have patches we can't release, period ;)
[01:38] <antarus> certainly for new stuff
[01:38] <infinity> Oh, that's problematic. :P
[01:39] <antarus> I'm basically the guy that maintains the kernel
[01:39] <antarus> and I don't know anything about kernels
[01:39] <antarus> so...
[01:39] <antarus> I mostly tell them to get linus to apply it
[01:39] <antarus> and then I'll backpor tit
[01:39] <infinity> Though, if your patches are sanely self-contained, you could look at just tracking our kernels and rebasing on them, which is cake.
[01:39] <antarus> yeah
[01:39] <antarus> we do that for upstream right now
[01:40] <infinity> If you look at how Andy set up -lowlatency, tracking/rebasing as another flavour would be minimal effort.
[01:40] <antarus> It was not clear to me why we selected upstream instead of you as the base
[01:40] <antarus> but I was new to the team at the time
[01:40] <infinity> I have a desperate need to take a break and watch cartoons.  Back in a bit.
[02:07] <stgraber> infinity: got a successful install here. Will have the package uploaded in a few minutes once I confirmed the installed system is fine.
[02:07] <infinity> stgraber: Does that successful install also mean my change to the alternates was fine (ie: can I close that bug)?
[02:07] <stgraber> infinity: I think so, let me quickly check if my dpkg -l is full of -lts stuff
[02:08] <stgraber> infinity: yep, installed system is full of -lts-quantal packages
[02:08] <infinity> \o/
[02:08] <smoser> skaet, we can re-spin to pick up a kernel, it can't hurt. whe nis that due ?
[02:08] <smoser> utlemming, ^
[02:08] <smoser> we're planning on tagging something as "alpha-2", so we'd like that to have the newest kernel available at the time.
[02:17] <stgraber> infinity: there you go ^ it's only been tested on an hand-patched amd64 d-i install but I think the code is sane (unless you don't have any of those packages, but then, it should fail anyway)
[04:03] <plars> infinity: back now if you have something you want me to try
[05:08] <ScottK> slangasek: I just pushed up the same britney block we used for Alpha 1 (I was supposed to have improved it, but I haven't had time).
[05:08] <ScottK> skaet, Riddel, stgraber: ^^^
[05:08] <slangasek> ScottK: cheers
[05:10] <stgraber> slangasek: infinity doesn't seem to be around at the moment, if you have a sec can you review ltsp in precise-proposed?
[05:10] <slangasek> ooking
[05:10] <slangasek> looking, too
[05:11] <slangasek> stgraber: can you spell out a test case in the bug report quickly?
[05:12] <stgraber> slangasek: oh, I assumed we had a better description in that bug ;)
[05:13] <slangasek> the diff itself looks fine
[05:14] <stgraber> slangasek: bug updated
[05:14] <ScottK> It would be nice, if someone has a minute, to get the MRE updates for postfix into precise/quantal proposed while they are still an MR update of the version that's in raring (shortly they'll be the version that used to be in raring).
[05:15] <ScottK> Personally, I'm running it in production, that's how confident I am of it.
[05:16] <stgraber> slangasek: it's not really easy to test the new package without building the media with it though. The only way I could think of is to let it fail, undo what the first try did, use netcat to write the new script in place of the old version, then have d-i retry.
[05:16] <slangasek> stgraber: is the media currently being built without -proposeD?
[05:17] <stgraber> slangasek: indeed it's
[05:17] <slangasek> stgraber: I guess we (you) could do a test build with -proposed back on, for validation?
[05:17] <stgraber> slangasek: so my current plan is to md5sum the script in the new binary package against the one I used in my test VM, if they match, I'll just mark the bug verification-done because that'll be identical to me doing another install and will save me an hour
[05:20] <slangasek> ok
[05:21] <stgraber> right, just pulled from LP, md5sum of the script in the binary package matches the one on my working installed system
[05:24] <stgraber> slangasek: looks like it's built everywhere already, so once that's published I guess we're good to have this copied and unless we're waiting on something else, then respin the alternate images
[05:27] <smartboyhw> Hey Noskcaj
[05:27] <Noskcaj> hey smartboyhw
[05:27] <slangasek> stgraber: can you keep an eye on it and let me know when it's published so I can copy?  I'm only half here at the moment
[05:35] <smartboyhw> chilicui1, would you like to fix Bug 1122293 or I do it?
[05:35] <ubot2> Launchpad bug 1122293 in Ubuntu Manual Tests "Nautilus testcase needs clarified" [Undecided,New] https://launchpad.net/bugs/1122293
[05:37] <stgraber> slangasek: LP says it's published (which I think is good enough for a copy)
[05:37] <slangasek> stgraber: ack, copeied
[05:37] <chilicui1> I've already done it smartboyhw, I'm just waiting input, I can't reproduce the issue which had balloons
[05:38] <smartboyhw> chilicui1, I just realized: Wrong channel. Sorry release team?:P
[09:45] <infinity> cjwatson: ^-- Probably way too late, but the backport is straightforward and obvious.
[10:34] <didrocks> infinity: hey, do you know if some builders are stuck? on https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4293814, it's been at least 10 minutes that I spotted it doesn't move (and I doubt libappindicator is taking 8 hours to build as previous ones were ~26 minutes)
[10:36] <infinity> didrocks: That's going to be an angry build, not an angry builder, I bet.  I'll look into it.
[10:36] <infinity> didrocks: Does it have a testsuite that, say, backgrounds something (maybe dbus?) and then fails to clean up?
[10:39] <didrocks> infinity: it's using dbus-test-runner, so I assume that yes, can it be stuck randomly because of that? (previous builds worked IIRC)
[10:40] <didrocks> but dbus-test-runner has a 300s timeout though
[10:40] <infinity> didrocks: Is that the same thing that keeps breaking hud builds? >:(
[10:40] <didrocks> infinity: well, same upstream, so probably same issue :)
[10:40] <infinity> didrocks: It's clearly not fixed, and it's really pissing me off at this point.
[10:40] <didrocks> infinity: did you ping tedg about it?
[10:41] <infinity> Yes.  Several times.
[10:41] <infinity> And he put someone else on it, apparently.
[10:41] <didrocks> do you know who this is?
[10:41] <infinity> And then webops has had to clean up their builds every day.
[10:41] <infinity> So, yay.
[10:41] <infinity> No idea who.
[10:41] <didrocks> infinity: ok, I'll check with him, sorry for the stuck build
[10:41] <didrocks> and do both at the same time
[10:41] <didrocks> and ensure it's timely done
[10:42] <didrocks> infinity: what process is stuck? is it dbus-test-runner itself or a dbus-launch one?
[10:42] <infinity> buildd   14255 98.5  0.1   2396  1116 ?        R    02:31 480:16 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
[10:42] <infinity> buildd   14257  0.0  0.0      0     0 ?        Z    02:31   0:00  \_ [dbus-daemon] <defunct>
[10:42] <didrocks> (if you have a bug report, it would be easier to track/beat the hammer ;))
[10:42] <infinity> ^-- Those are the two we always have to kill.
[10:43] <infinity> didrocks: I don't tend to file bug reports against private PPAs...
[10:43] <infinity> (Which this has been, up until today)
[10:44] <didrocks> infinity: it's good to know the HUD is also affected, I was going to add it to the public release this week
[10:44] <infinity> didrocks: Also, we see it a LOT on quantal/i386, for some reason, though this was raring/armhf this time, so it's clearly not a Q-specific thing.  But that might make it easier to reproduce.
[10:44] <didrocks> infinity: yeah, here it's against raring, I think dbus-test-runner is just killing itself and not the dbus daemon that is spaws reliably
[10:46] <didrocks> infinity: FYI: bug #1122948
[10:46] <ubot2> Launchpad bug 1122948 in dbus-test-runner (Ubuntu) "dbus-test-runner is not killing dbus reliably" [Undecided,New] https://launchpad.net/bugs/1122948
[10:46] <infinity> didrocks: That would seem to be the gist of it, yes.
[10:47] <infinity> didrocks: I pointed ted at the telepathy-glib testsuite that gets this right, and got snarky responses about dbus-testrunner being "better" and "more modern" or something.
[10:47] <infinity> My argument is that it's clearly not better because it breaks. :P
[10:47] <didrocks> infinity: ahah, I experienced the same when talking about direct dbus-launch :p
[10:47] <didrocks> infinity: well, issues can happens when building something news, fixing timely though is required when it's a regression to what worked in the past
[10:49] <infinity> I'm all for people fixing their crap.  I'm just annoyed that we asked, what, two weeks ago to "disable these builds until the bug is fixed", and got nothing.
[10:50] <didrocks> infinity: I agree with you, I'll get that on their list for sure and tell we won't release it in ubuntu until it's done properly
[11:13] <ogra_> infinity, cadejo dead again ? i just got an empty omap4 failure mail
[11:14] <ogra_> and i cant reach its http server
[11:14] <ogra_> from nusakan
[11:25] <infinity> ogra_: Looks like.  Asking for a reboot 'n tidy.
[11:25] <ogra_> thx ... dont forget the lock :)
[11:26] <infinity> I didn't. :P
[11:26] <ogra_> well, i promised to think of itt the next time :)
[11:26] <ogra_> (so next time i can forget it again :P)
[11:27] <infinity> Looks like it's possible unstabbable, ticket filed.
[11:27] <infinity> The good news is that nexus7 builds are on celbalrai now, so that still works. :P
[11:27] <ogra_> sigh
[11:27] <cjwatson> infinity: How's .2 looking?  I guess we should hand off before you get on a plane
[11:27] <ogra_> oh, cool !
[11:28] <cjwatson> ogra_'s care factor for cadejo suddenly plummets
[11:28] <ogra_> haha
[11:28] <ogra_> well, we need to make a decision about panda desktop builds at some point
[11:28] <infinity> cjwatson: The alternate x-stack snafu appears to be good, images are barely oversizes and we've run out of languages to drop, so not sure what we want to do with that, and my apt backport is in the queue and should be harmless, if you want to review it, but it's probably too late regardless.
[11:29] <infinity> ogra_: cadejo seems up now.
[11:29] <ogra_> (TI dropped OMAP and we will likely not recieve drivers anmore ... in that light we likely need to re-consider building desktop images on pandas)
[11:30] <ogra_> but i also think we shouldnt drop desktop on arm completely ... since it will be base for things like U4A
[11:30] <ogra_> infinity, thx
[11:31] <cjwatson> infinity: I'll review the apt backport and probably let it into -proposed, but I don't think I'll take it for .2
[11:32] <cjwatson> Oversized - I'll have a look but we may just end up release-noting
[11:32] <cjwatson> I suspect today is mostly me going through release notes and working out what hasn't been written yet
[11:32] <infinity> ogra_: cadejo should work.  Maybe.
[11:33] <ogra_> k, we'll see what it spits out over the day ...
[11:33] <infinity> cjwatson: Yeah, not a huge loss if the apt thing makes post-.2... It just means the .2 install kernel will me marked manually installed.
[11:33] <infinity> cjwatson: But so are all the pre-.2 kernels, so...
[11:33] <cjwatson> Exactly
[11:35] <cjwatson> Autotests look good with the exception of one cloud test failure
[12:58] <mdeslaur> cjwatson: am I ok to publish security updates for precise now?
[13:03] <mdeslaur> ok, releasing updates now
[13:09] <cjwatson> mdeslaur: hmm
[13:09] <cjwatson> mdeslaur: I've disabled propagation to -updates just in case that comes in useful
[13:10] <mdeslaur> cjwatson: ok. I've released postgresql already. I still have qt4-x11 to release. Would you rather I wait?
[13:11] <cjwatson> Ideally
[13:11] <mdeslaur> until tomorrow?
[13:11] <cjwatson> Just till tomorrow so that I can be sure we're done?
[13:11] <mdeslaur> ok, I'll wait until tomorrow for qt4-x11
[13:11] <cjwatson> Great, thanks
[13:45] <jdstrand_> cjwatson: in related news, what about openjdk-6 for precise?
[13:45] <jdstrand> cjwatson: (and hello :)
[13:46] <cjwatson> Hmm
[13:47] <cjwatson> The only images I currently suspect I'll need to respin are the alternates, which don't have openjdk; but I'd still prefer you hold off as I haven't gone through iso.qa yet
[13:49] <jdstrand> cjwatson: do you think you would know by 21:00 UTC or your EOD, whichever comes first?
[13:50] <jdstrand> cjwatson: basically, I've got a nunch of stuff I can do til then, but I could plan on publishing then
[13:51] <jdstrand> cjwatson: I'm fine with us pinging each other, or we could wait one more day if it is necessary
[13:53] <cjwatson> jdstrand: If you can just wait one more day it would make life much easier
[13:53] <cjwatson> I don't expect to need to respin after then
[13:53] <jdstrand> ok
[16:41] <plars> stgraber: is there going to be a respin soon to fix https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1122525 ?
[16:41] <ubot2> Ubuntu bug 1122525 in ltsp (Ubuntu Precise) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,Fix released]
[16:42] <stgraber> plars: there should be, yes
[16:43] <plars> stgraber: I tried enabling proposed on my install and it seems I'm able to get past it now
[16:44] <stgraber> plars: yeah, I tried the fix and it's good, we just need a respin to get it. Though I suspect infinity is still working on finding ways to fix the oversizedness of alternate.
[16:44] <plars> right
[16:44] <plars> ok thanks
[16:44] <cjwatson> Uh, infinity's on a plane I think
[16:44] <stgraber> or about to get on a plane, yeah
[16:45] <cjwatson> I intend to release-note the oversizedness of alternate; it's only on amd64 and I don't see anything straightforward
[16:45] <antarus> sadly 'snakes' is already taken as a nick ;p
[16:45] <stgraber> ok, then we should respin alternate to get the LTSP fix
[16:45] <cjwatson> I hadn't realised we hadn't already done so
[16:45] <cjwatson> However, inclined to wait for mlankhorst's libpciaccess fix
[19:40] <slangasek> infinity, cjwatson, ScottK: bug #1123379 looks like Kubuntu alternates for .2 are rather broken... which way are Kubuntu images supposed to go?  Using the quantal backport stack or not?
[19:40] <ubot2> Launchpad bug 1123379 in Ubuntu CD Images "Kubuntu alternate install 12.04.2 2013_02_11 AMD 64 bit cannot find/load kernel modules" [Undecided,New] https://launchpad.net/bugs/1123379
[19:40] <antarus> can someone with an Ubuntu box just confirm that /root is 755 ?
[19:43] <antarus> hrm, examining base-files it looks like it should be 700
[19:52] <slangasek> antarus: 0700 on a new install, here
[19:52] <antarus> excellent
[19:52] <antarus> tis a bug in our puppet manifests
[19:52] <antarus> yay
[21:22] <Riddell> slangasek: not using backported stack
[21:22] <Riddell> slangasek: what's broken about them?
[21:22] <Riddell> I found some issues
[21:22] <slangasek> Riddell: the aforementioned bug shows the alternate CD failing to find kernel modules due to mismatched versions
[21:22] <Riddell> it moans about no wifi firmware on install for me
[21:22] <Riddell> sounds the same
[21:23] <slangasek> no, this is a lot more than wifi firmware
[21:23] <slangasek> "no kernel modules were found" - implies the udeb repo and the initramfs don't match
[21:24] <slangasek> Riddell: do you see a different message with current images?
[21:24] <Riddell> slangasek: yeah, something about can't find firmware for iw
[21:24] <slangasek> philwyett: see above; use of the 3.2 kernel on the Kubuntu CDs is by design
[21:25] <slangasek> hmm
[21:28] <philwyett> slangasek: OK. Was informed previously that Kubuntu matches Ubuntu. But decision to use old stack is fine.
[21:30]  * Riddell sleeps
[21:56] <antarus> do I see another flash patch?
[21:56] <antarus> heh
[22:45] <cjwatson> slangasek: I'll see about sorting out those Kubuntu images
[22:45] <cjwatson> (Had just seen the bug in mail - I was out for a bit, going to work for a few more hours now)
[22:45] <slangasek> cjwatson: cheers
[22:49] <cjwatson> ... as soon as my fingers work properly again.  damn it's cold out there.
[22:51]  * cjwatson starts off a custom build for this libpciaccess thing
[23:53] <cjwatson> Hmm, I'm going to have to do something desperately evil to disentangle Kubuntu udebs
[23:57] <slangasek> presumably unrelated to the name of the package that's just landed in the new queue :)
[23:58] <cjwatson> Indeed :)