[00:00] <phillw> skaet: I know the bugs were logged. but as the respins go on, they get dropped off. Where are they all kept?
[00:00] <skaet> where it says /builds on the iso tracker put in /history
[00:00] <skaet> then you should see them all.
[00:02] <phillw> skaet: an oops ... PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: "history" LINE 4: WHERE (qatracker_build.id = 'history') ^: SELECT qatracker_build.note AS value FROM {qatracker_build} qatracker_build WHERE (qatracker_build.id = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => history ) in qatracker_block_noticeboard() (line 81 of /srv/drupal-qa-tracker/www/bzr/new/modul
[00:02] <phillw> can you give me a clean link for them?
[00:02] <skaet> stgraber, ^
[00:02] <skaet> phillw,  will do.
[00:04] <skaet> http://iso.qa.ubuntu.com/qatracker/milestones/210/history
[00:06] <skaet> phillw,  who's been doing the amd64+mac tests?   jibel may want to contact them in the morning to see if they're seeing a problem he is on his ubuntu tests.
[00:07] <phillw> skaet: Mars cleared the ppc error, I'm guessing it was a dodgy download that snook through the lower level error checking.
[00:08] <skaet> ok.  what about the intel macs?
[00:09] <phillw> skaet: do feel free to call him, but while he is really 100% on lubuntu release.... the offer of cookies, chocolate may help :)
[00:10] <phillw> skaet: may I speak freely?
[00:10] <phillw> skaet: or should this be done in PM?
[00:11] <skaet> PM if its sensitive people wise,  otherwise speak freely.
[00:11] <infinity> If "speaking freely" won't violate the code of conduct, go to town.
[00:12] <phillw> skaet: we do not have a log bot. I always adhere to CoC
[00:12] <skaet> :)
[00:13] <phillw> skaet: I am, after all a ubuntu member, I just do not use that cloak.
[00:13] <skaet> phillw,  comment on CoC was from infinity ;)
[00:14] <phillw> Long story, cut short .... xubuntu was the best option for ppc, then it got bloated & needed lots of work arounds.
[00:15] <phillw> when it was mentioned that lubuntu "may" do a ppc release, the ppc people were all over us
[00:15] <micahg> phillw: xubuntu would add PPC back if there were committed testers
[00:15] <phillw> we said that to so required testers.
[00:16] <phillw> micahg: you seem to forget Charlie handing in his resignatation?
[00:16] <micahg> phillw: charlie never tested PPC
[00:17] <phillw> micahg: I am not currently chatting about xubuntu? I am chatting about ppc / mac testers?
[00:18] <phillw> please do let me finish before you start.
[00:19] <phillw> skaet: I am finished. I am an admin, catch me on PM anytime
[00:20] <skaet> phillw,  very much appreciate getting the ppc testing happening this release.    Was curious who was doing the intel mac testing right now,  since jibel has seen an issue with ubuntu on intel mac, and would like someone to compare notes with.
[00:21]  * skaet looked at your bugs on those ports and didn't see anything like he was worrying about,  so just trying to figure out if its an ubuntu specific problem or wider problem.
[00:24] <phillw> skaet: Life is real complicated for me, Julien gave a way to test for us lubuntu people at https://wiki.ubuntu.com/Lubuntu/Testing/PPC#How_to_test_on_any_architectures_.28using_qemu.29
[00:25] <stgraber> skaet: the error message above is actually right 'history' isn't an integer ;) I guess it wouldn't hurt to check the input before running the select against the DB though :)
[00:25] <skaet> stgraber,  :)
[00:26] <skaet> phillw,  yes,  that does look complicated for ppc macs.   Who is testing intel macs and are they using the same proceedure?
[00:27] <skaet> phillw, or are they working on bare metal.
[00:29] <slangasek> you're not going to get a useful test of amd64+mac under qemu.
[00:30] <slangasek> (qemu doesn't implement uefi, as far as I'm aware)
[00:33] <slangasek> I would also question whether it's wise to use qemu for validation of ports images, since the entire point of validating the ports images separately is to pick up on hardware-specific issues not caught in the x86 testing, and qemu gives you a very narrow view of "hardware"
[00:34] <infinity> slangasek: They have bare metal testers for PPC as well.
[00:34] <slangasek> in which case I have no objection
[00:34] <infinity> slangasek: Those instructions are more of a "for other who want to add more test results", AIUI.
[00:35] <infinity> s/other/others/
[00:35] <infinity> slangasek: But the guy filing lubuntu/ppc bugs is doing so on real hardware.
[00:35] <slangasek> ok, good :)
[00:35] <infinity> Even burning actual coasters to do so.  *shiver*
[01:11]  * phillw are the http://iso.qa.ubuntu.com/qatracker/milestones/210/builds for lubuntu 'good to go' ? As in can I announce them as our beta 2 officially instead of the likes of 'certain' threads announcing while we are still testing?
[01:13] <slangasek> phillw: it's inadvisable to announce until the testing is all done and the images are published as a beta - which has not been done yet
[01:14] <slangasek> phillw: and by "all done", I mean done for all images, not just lubuntu ones; testing on another flavor could yet turn up a showstopper issue that lubuntu would want to consider respinning for even if it wasn't caught in your own testing
[01:15] <slangasek> and there's still the question of whether amd64+mac is actually releasable despite having been signed off for lubuntu, since there's an as-yet-unconfirmed report that it corrupts partition tables
[01:16] <phillw> slangasek: if you need Lars to test on another system, do feel free to give him a poke in the ribs. Vocal he may be, but he has access to kit to test things on.
[01:17] <slangasek> how do we get ahold of Lars if ribs need poked?
[01:18] <phillw> slangasek: https://launchpad.net/~lubuntu-qa
[01:19] <phillw> let me just dig up his email
[01:21] <phillw> slangasek: P okay?
[01:21] <phillw> PM
[01:21] <slangasek> sure
[01:25] <phillw> slangasek: from zero to where we are, does IMHO, inforce the lubuntu commitment to lower spec machines.
[01:27] <phillw> our reports back just generally, is that ubuntu have made a massive difference to those guys. We have testers, you are the guys who make it happen. for that, I know I can speak on behalf of them all..... THANK YOU.
[01:34] <infinity> Gah, who just let all that stuff into -release?
[01:34] <infinity> Or were those all rejects?
[01:35] <infinity> slangasek, skaet: ?
[01:35] <stgraber> infinity: my e-mails says they were accepted
[01:35] <skaet> infinity,  not me
[01:36] <skaet> stgraber,  is it possible to change removed in the bot message to accept or reject?
[01:36] <infinity> skaet: Not easily.
[01:36] <skaet> ok.  just an idea.
[01:36] <infinity> skaet: Requires scanning DONE and REJECTED which is hugely time-consuming and vile.
[01:37] <stgraber> skaet: what he said :) hopefully the API for the audit changes will make that easier
[01:37] <infinity> (I suppose one could also blindly hit the package/version record, and if it doesn't exist, assume reject)
[01:37] <infinity> stgraber: ^
[01:38] <stgraber> infinity: true, I was just thinking about that actually ;) if the source is "published" (as far as LP knows at least) and the package was removed from the queue, that should mean it's been accepted
[01:38] <stgraber> I guess I can implement that and we'll see how well that works
[01:39] <infinity> Well, if the source exists at all in a !new state, it's accepted (or better).
[01:39] <infinity> Since unapproved sources don't have source records yet.
[01:39] <infinity> Actually, I guess new doesn't either.
[01:40] <infinity> Only new binaries do.
[01:40] <stgraber> actually, it looks like I can keep the URL of a build record then query for its status when it's removed, that should tell me if it was rejected or not without scanning the queue
[01:41] <infinity> stgraber: I suspect "published" won't catch the "just accepted" state (which can last up to 30m), but I haven't looked at the API for SPRs.
[01:41] <infinity> But for unapproved, if there's a source record at all, that should mean "accepted".  I think.
[01:42] <infinity> Anyhow.  Whoever did the above just leaked in some gnome transition bits and other stuff.  *sigh*
[01:42] <stgraber> please wait on that bcfg2 upload
[01:42] <stgraber> I'll use it to test the bot ;)
[01:42] <infinity> Though, maybe it was all universe.
[01:43] <skaet> hmm... hasn't solved the mystery of who just let all that code into -release.
[01:44]  * phillw not guilty... 
[01:44] <stgraber> infinity: can you reject bcfg2? it's one of my uploads, I'll re-upload after that so we can test "approved" :)
[01:44] <infinity> stgraber: I can just pull it out of rejected after I do, no need to reupload.
[01:45] <stgraber> infinity: ah right, forgot you could do that
[01:45] <infinity> Oh, except then we won't be able to test the unapproved->accepted route.
[01:45] <infinity> So, reupload. :P
[01:45] <stgraber> yay!
[01:45] <stgraber> uploading now
[01:46] <stgraber> the current code is: if not "Rejected" => "accepted"
[01:46] <stgraber> so as the above worked, accepting should work too
[01:46] <infinity> stgraber: As in, if source record exists -> accepted; else -> rejected?
[01:47] <infinity> Something like that should be close enough to the truth for most cases we care about anyway.
[01:47] <stgraber> nope, I'm actually storing the URL of the build record, then pulling an updated version of the object when I noticed it dropped out of the queue
[01:47] <infinity> "build record"?
[01:47] <stgraber> that object happens to have a status property
[01:47] <infinity> There are no build records for unaccpted source...
[01:48] <stgraber> s/build record/package upload/
[01:48] <stgraber> https://launchpad.net/+apidoc/1.0.html#package_upload <-- that stuff
[01:48] <infinity> Ah-ha.
[01:48] <infinity> Much more elegant.
[01:48] <skaet> looks like that worked.   ;)
[01:49] <vanhoof> thanks skaet :)
[01:49] <vanhoof> >
[01:49]  * skaet did those ^ on request from vanhoof.
[01:49] <vanhoof> >
[01:49] <infinity> vanhoof: You poked me?
[01:49] <stgraber> skaet: we haven't seen any "accepted" yet :)
[01:49] <vanhoof> infinity: same question
[01:49] <vanhoof> infinity: last minute drama, and a decision was made to yank them
[01:49] <infinity> vanhoof: Oh, was that all of them, not just the older ones?
[01:49] <vanhoof> infinity: that all of em
[01:49] <infinity> vanhoof: I guess it's a good thing I didn't get around to reviewing them for jani yet. :P
[01:52] <infinity> queuebot: Wake up and poll already.
[01:52] <infinity> \o/
[01:53] <stgraber> wow, that worked!
[01:53] <infinity> stgraber: Magic.
[01:53] <stgraber> now looking into what happened with mosh
[01:55] <stgraber> that's if LP stops timing out when trying to look at the records in the Done queue :)
[01:56] <stgraber> right, so the problem is indeed that they are binary packages but not detected as such...
[01:58] <infinity> stgraber: Was that perhaps fallout from trying to handle the binary+translations case?
[01:59] <stgraber> could be, the check for binary/source was written before I actually add access to pkg.arch ;) I'm doing a test run now where I won't do silly hacks to detect source vs binary
[01:59] <stgraber> and instead simply check if pkg.arch == "source" which should be a bit more reliable
[01:59]  * infinity nods.
[02:00] <stgraber> infinity: well, what you currently see in #stgraber-release is actually a "debug" version where the versio number in "New: source" packages is replaced by the architecture
[02:01] <stgraber> ok, looks like all source packages in New have "source" as their architecture, good
[02:05] <slangasek> infinity: accepts> wasn't me
[02:05] <infinity> slangasek: Great.  We have a mystery queue manipulator.
[02:06] <infinity> stgraber: Also, when a package is accepted, can the bot /msg every member of ~ubuntu-archive and ask "was that you, fess up, was it you?!"
[02:06] <infinity> stgraber: Thanks in advance.
[02:08] <stgraber> infinity: hehe, should actually be easy to do ;)
[02:08] <slangasek> infinity: though AFAICS, the only one that was in main was mousetweaks, which went to -proposed; so whoever's doing it hasn't actually broken anything
[02:09] <stgraber> infinity: I can query the list of team members on LP, then their IRC nick and ask each of them, then we'll have an "audit trail" (assuming nobody lies and everyone replies ;))
[02:09] <infinity> slangasek: Yeah, I came to a similar conclusion later, but it still would have been nice to have someone annotate the accept spam.
[02:09] <slangasek> stgraber: we'll also see a sudden spate of retirements from ubuntu-archive, I trust :P
[02:09] <infinity> stgraber: Perfect!
[02:09] <stgraber> slangasek: :)
[02:09] <infinity> slangasek: That might not be a bad thing either.  Probably should thin the herd a bit.
[02:10] <slangasek> I'd rather not
[02:10] <slangasek> the NEW queue is long enough without reducing manpower :)
[02:11] <stgraber> ^ that's with this morning's bug fixed and some better handling of syncs in the New queue too
[02:11] <stgraber> (as LP also considers 'sync' as a valid architecture apparently)
[02:11] <slangasek> stgraber: is there a bzr branch for the queue bot yet?
[02:11] <stgraber> slangasek: lp:~stgraber/+junk/queuebot
[02:11] <slangasek> ok :)
[02:12] <stgraber> slangasek: might move to ~ubuntu-core-dev or similar, I guess ~ubuntu-release or ~ubuntu-archive would technically be better but I don't have access to these
[02:12] <slangasek> I think ubuntu-core-dev would be fine anyway
[02:13] <slangasek> not like being able to edit the bot confers any superpowers that should be tied to release :)
[02:13] <stgraber> well, you can confuse the archive admins and release admins quite a bit by messing in the code, but nothing worse than that ;)
[02:14] <infinity> stgraber: You're not in -release?
[02:14] <infinity> But yeah, -core-dev seems fine.
[02:16] <stgraber> infinity: nope, might poke skaet about it at some point though :)
[02:16] <stgraber> infinity: I'm the team owner though (through coredev) ;)
[02:16] <stgraber> s/coredev/TB/g
[02:16] <infinity> Yeah, I'm jealous of your horsey.
[02:17] <skaet> stgraber,  if you want to be in -release,  am happy to put it forward.   You've done alot to make our lives easier between the ISO tracker and this queue bot.   Anytime.
[02:19] <infinity> Can we make him our mascot?
[02:23] <stgraber> so, to reflect our private discussion: yeah, I'd be happy to join the release team
[02:24] <stgraber> slangasek: queuebot moved to https://code.launchpad.net/~ubuntu-core-dev/+junk/queuebot
[02:24] <infinity> stgraber: Probably doesn't need the junk...
[02:25] <stgraber> don't we have to link a branch to a project?
[02:25] <infinity> We could create a project for it.
[02:25] <infinity> Then I could file bugs instead of pestering you on IRC!
[02:25] <infinity> Progress.
[02:26] <skaet> :)
[02:26] <stgraber> not sure, sounds like a slower process causing more interruptions for me (unless you don't say anything on IRC ;))
[02:27] <infinity> stgraber: No, no.  I'd write a second bot that polls lp/queuebot/bugs and pings you on IRC when they're filed.  Duh.
[02:28] <stgraber> right so queuebot would crash, crashbot would see it, file a bug, then nagbot would post the bug number here for ubot2 to post the LP description?
[02:28] <stgraber> at this rate we'll soon have more bots than human in the channel
[02:29] <infinity> There's probably a critical mass of bots we can reach where we obsolete ourselves.
[02:29] <infinity> Please don't write sarcasmbot, I'll be out of a job.
[02:30] <stgraber> ;)
[02:30]  * stgraber adds to the TODO
[02:30] <slangasek> the blueprint approval for that one should be fun
[02:38]  * skaet giggles
[03:34] <stgraber> slangasek: are you planning a plymouth upload shortly after freeze? I just noticed bug 904622 (the original, not sure why it was marked as duplicate) on one of my servers using the text theme
[03:34] <ubot2> Launchpad bug 904622 in unity-greeter "Still says 11.10 on precise on boot (dup-of: 892394)" [Low,Fix committed] https://launchpad.net/bugs/904622
[03:34] <ubot2> Launchpad bug 892394 in unity-greeter "Greeter logo needs to be updated for 12.04" [Medium,Fix released] https://launchpad.net/bugs/892394
[03:35] <stgraber> I started looking to fix it and noticed you already figured it out and there are changes pending in the branch for a while now
[03:35] <stgraber> including what looks like a fix for the missing "chvt 1" that was mentioned earlier today
[03:35] <slangasek> stgraber: I'm planning a plymouth upload, yes, though probably only once the chvt thing is *properly* fixed
[03:35] <slangasek> the 'chvt 1' is almost certainly wrong and should NOT be uploaded
[03:38] <stgraber> yeah, that's definitely wrong. We only want the chvt if nothing will show up on vt7, which definitely sounds a lot easier than it really is to implement
[03:39] <RAOF> slangasek: If you're touching plymouth, can I bring https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/939283 to your attention?
[03:39] <ubot2> Launchpad bug 939283 in plymouth "[hybrid-gfx] Blank screen on boot due to failure to follow primary framebuffer" [High,New]
[03:39] <slangasek> I think I have the crux of it, but I need to make sure we're entirely race-free
[03:40] <slangasek> RAOF: I'm aware of the bug, but I have no good solution for it
[03:42] <slangasek> the difficulty is that plymouth starts before we even know we're on a hybrid system, and has no good way to either wait, or switch cards when it turns out there's a better one
[03:44] <stgraber> slangasek: ideally we'd ask upstart if any job said it could emit "login-session-start" if we don't get any back, we'd emit "no-login-manager" and have that used to stop plymouth, sadly even though upstart knows what events each jobs can emit I don't think it exposes it yet
[03:45] <stgraber> slangasek: actually "initctl show-config | grep login-session-start" should work
[03:46] <stgraber> initctl show-config | grep -q login-session-start || echo "chvt 1"    <= that should do it, assuming all login managers actually emit that (I just looked at lightdm)
[03:47] <stgraber> or more specifically explictly say they might emit it
[03:47] <stgraber> I know that the above won't work with LTSP but if you go with something like that, it's trivial to fix in our existing upstart job
[03:48] <RAOF> slangasek: Does/can plymouth monitor udev events?  You could watch for fb device creation, correlate that with the associated DRM device, and switch fbs iff the new fb is associated with a drm device with attached outputs and is currently on a fb associated with a drm device with no attached outputs.
[03:58] <RAOF> Or, now that I think of it, you could just bring it up on each and every output, like the drm backend already does.
[04:00] <slangasek> stgraber: I think that would be papering over the real issue; I'd like to take a little more time to get it right in the plymouth code
[04:00] <slangasek> stgraber: but if I don't pull it off, that does sound like a viable fallback, thanks
[04:01] <slangasek> RAOF: there's no monitoring of udev events, no
[04:02] <RAOF> That shouldn't be too hard to add?  I'm blissfully unfamiliar with the plymouth code, though.
[04:04] <slangasek> I don't think this would be a safe area to make changes to post-beta, sorry :/
[04:04] <slangasek> regression-testing plymouth is effectively impossible at this point
[04:05] <kees> release folks, I'm not sure, but this seems like a rather bad behavior for the LTS openssl: bug 965371
[04:05] <ubot2> Launchpad bug 965371 in openssl "HTTPS requests fail on some sites on Ubuntu 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/965371
[04:08] <slangasek> kees: do you know why TLSv1 is disabled by default?  I would assume that's because it's insecure?
[04:09] <slangasek> RAOF: not that it's a fix for your bug, but I just saw your followup and I wonder if double-tapping 'Esc' brings the splash screen up for you?
[04:10] <RAOF> slangasek: That's a good question; I'll try it next time it triggersl.
[04:18] <kees> slangasek: TLSv1 is slightly less secure than 1.3, but none of the browsers are using it yet.
[04:18] <kees> which is why no one has noticed that paypal can't talk to a 1.3 tool
[04:18] <kees> the changelog for openssl 1.0.1 seems to indicate that they fixed autodetection, but it's clearly a lie. :P
[04:19] <kees> they turned on 1.3-by-default in the 1.0.0 release at some point
[04:22] <slangasek> ok
[04:22] <slangasek> triaged and assigned for follow-up
[04:49] <infinity> stgraber: Hrm.  queuebot just helpfully told us about 18-hour-old uploads...
[04:50] <infinity> stgraber: Oh, no.  Nevermind.  It really is in the queue twice.
[04:50]  * infinity double-takes.
[04:50] <infinity> How... Is that in the queue twice?
[04:50] <micahg> you can upload multiple times to unapproved
[04:51] <infinity> micahg: With the same version?
[04:51] <micahg> yep
[04:51] <infinity> That seems broken.
[04:51] <infinity> The only queue without constraints should be rejected.
[04:52] <micahg> would make it easier to detect collisions :)
[04:54] <infinity> Oh well, I'll reject the older one.
[04:56]  * skaet --> zzz
[05:11] <pitti> Good morning
[05:12] <infinity> pitti: We made some improvements to the bot today.  Enjoy.
[05:15] <pitti> looking forward to trying them out :) I have some -proposed stuff to accept
[05:16] <infinity> pitti: Well, not sure what was landed yesterday and what was today, but it now knows unapproved versus new, displays dists and pocket, knows source versus binary, and the most important part, now understand how something was removed (reject or accept).
[05:16] <pitti> hm, at this point we certainly don't consider respinning server again?
[05:16] <infinity> pitti: Oh, and announces images being posted to the tracker.
[05:16] <pitti> reject vs accept> yay!
[05:16] <pitti> very helpful indeed
[05:16] <pitti> saves the "^ don't panic, it was a reject" followups
[05:17]  * infinity nods.
[05:18] <infinity> Oh, and stgraber dumped it in lp:~ubuntu-core-dev/+junk/queuebot, if you feel the urge to peruse and suggest other improvements.
[05:18] <infinity> Soon, the bot will do our jobs for us.
[05:19] <pitti> can it point out bugs in debdiffs yet?
[05:20] <infinity> Soon.
[05:22] <pitti> I'll do the pre-publishing now, so that it has some time to mirror around the world
[05:22] <pitti> cjwatson, skaet ^
[05:23] <pitti> ah, we don't put Kubuntu on release.u.c. any more
[05:27] <pitti> cjwatson, skaet: pre-publishing done
[05:55] <pitti> cjwatson, slangasek: FYI:
[05:55] <pitti> bzr commit -m 'sru-release: Add --release/-r option for copying to release pocket, for staging uploads in development release'
[06:02] <infinity> pitti: \o/
[06:02] <infinity> pitti: Both to the pre-publishing and the sru-release change.
[06:02] <pitti> working on making the SRU report show non-DONE builds, to see what can't e copied yet
[06:03] <pitti> e -> be
[06:03] <pitti> LibO will be a fine test for this for the next two days
[06:04] <infinity> Heh, yeah.
[06:05] <infinity> Someone really needs to talk to them about splitting it out into modular bits.
[06:05] <infinity> (Which, ironically, it mostly is in the source anyway, they just need to release it that way)
[06:05] <pitti> in fact they just merged their individual component gits back into one
[06:05] <infinity> Meh
[06:05] <infinity> It's insanity, even on x86.
[06:06] <infinity> Fixing a small bug should be a short build and a small download away, not a day of build time and pushing 150MB to users.
[06:07] <micahg> infinity: it's almost as large as the kernel (~12M lines of code)
[06:08] <infinity> micahg: Yeah, but the difference is that no kernel build uses all of the source.
[06:09] <infinity> Also, the kernel workd.
[06:09] <infinity> s/workd/works/
[06:10] <infinity> pitti: I kinda wonder who I'd need to talk to about doing componentised distribution and releases without being laughed at.
[06:10] <pitti> that's a question for Sweetshark
[06:10] <infinity> pitti: Cause if the argument is just "but, but, Windows...", I'd seriously commit to spending a weekend or two writing them a nice package installer / manager / updater for Win32.
[06:10] <infinity> (I'm sure my parents would love it if Office suite updates were 5MB instead of 150...
[06:10] <infinity> )
[06:55] <cjwatson> slangasek: you mentioned an unconfirmed report that amd64+mac corrupts partition tables; do you have a bug number or anything for that?
[07:08] <jibel> cjwatson, not a corrupted partition table but after installing ubuntu on a Mac, none of the MacOS disk tools can manage the partitions. They cannot erase, resize, ...
[07:08] <jibel> cjwatson, I'm wiping the disk and will redo the installation
[07:20] <cjwatson> curious, I don't know what their constraints are exactly
[07:39] <Riddell> what time are we expecting to release today?
[07:39] <Riddell> "Thu Mar 1 22:21:43" says the beta 1 announce, no rush then :)
[07:39] <jibel> for example, resize (to a smaller) or erase partition reports: "Error -5344 Mediakit reports not enough space on device for requested operation" or "cannot update partition map"
[07:40] <jibel> it may be a hardware issue, there are fsck errors on every boot.
[07:42] <jibel> "unrecognized file system" is another error but the filesystem type is JHFS+
[07:43] <cjwatson> I probably won't be able to investigate that; sounds like the sort of thing you really need to be in front of ...
[12:45] <tumbleweed> err whoops, that ubuntu-dev-tools upload can be rejected. It appears bdrung already synced it, but the publisher hasn't run since then
[12:45] <tumbleweed> oh, 3 mins before
[12:45]  * bdrung was faster than tumbleweed. :)
[12:45] <pitti> tumbleweed: that was a sync
[12:46] <pitti> tumbleweed: oh, you mean you did an upload just now?
[12:46] <tumbleweed> I just did a second sync
[12:46] <pitti> right, rejected
[13:08] <jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseBeta2TestReport
[13:54] <jelmer> hi
[13:54] <jelmer> I'm going to update the tevent package from upstream release 0.9.14 to 0.9.15 by syncing 0.9.15-2 from unstable
[13:54] <jelmer> 0.9.15 is a bugfix only release, though it's got a fair amount of noise because it unpacks waf upstream and has some changes to bundled libraries that aren't used by the package.
[13:56] <skaet> good morning
[14:01] <stgraber> good morning skaet
[14:01] <skaet> :)
[14:03] <skaet> pitti,  cjwatson - based on the test report,  am thinking Ubuntu amd64+mac and ppc probably shouldn't ship this time around.
[14:04] <skaet> thoughts?
[14:04] <pitti> skaet: good morning
[14:04] <skaet> :)
[14:05] <cjwatson> The notion of coverage for amd64+mac is pretty bogus.  Most of the amd64 tests apply equally to it; making sure that it builds and installs should be enough to carry over the rest of the coverage.
[14:05] <pitti> skaet: no strong opinion on that, but amd64+mac seems to at least work
[14:05] <pitti> skaet: and it's by and large identical to teh amd64 one, so "it boots, it works" comes pretty close IMHO
[14:05] <pitti> heh, yes, what cjwatson says
[14:06] <skaet> pitti,  worry point is that jibel can't get behaviour post install on his hardware (partition map table)
[14:07] <skaet> cjwatson,   tests should probably be edited then for amd64+mac to be just those for that configuration, so they aren't so bogus.
[14:08] <pitti> skaet: as we have only one test on ppc, and it's failed, ok with not releasing
[14:12] <skaet> jibel,  ubuntu core (armel + armhf) - who's testing?  any results?
[14:13] <jibel> pitti, on Mac I did I installation, after this installation I couldn't do any operation with MacOS disk utils and had to reformat the machine (which took a while from the Net) I'm restesting it to check if it's a problem with the hardware.
[14:14] <cjwatson> Did you have the same problem (or know whether you did) with previous versions?
[14:14] <cjwatson> i.e. is this a regression?
[14:16] <stgraber> hmm, wondering if "disabled" would be better than "marked for re-build"
[14:17] <skaet> superm1 - not seeing any testing on the Mythbuntu images,  any testing going to happen in next couple of hours?
[14:17] <skaet> utlemming,   how do the cloud images look?
[14:17]  * skaet not seeing them on the tracker.
[14:18] <skaet> ogra_, infinity,  any testing of the ac100 or mx5 images?
[14:19] <ogra_> i tested yesterday
[14:19] <skaet> ogra_,  sorry - misread a line.
[14:19] <skaet> appologies.
[14:19] <ogra_> and noted it on the tracker
[14:19] <ogra_> ah, k
[14:19] <ogra_> infinity wanted to do mx5
[14:20] <skaet> thanks ogra_
[14:20] <sladen> skaet: the wallpapers have finally turned up.  Should I play with the compression and rush them up for tonight, or hang back?
[14:20] <skaet> sladen,  play with compression and aim for tonight's build.
[14:21] <sladen> skaet: (and yes, still waiting on Otto to upload the default wallpaper, but it has now been decided)
[14:21] <sladen> skaet: okay-dokey
[14:23] <skaet> stgraber,  yeah, at this stage a separate button maybe to indicate "don't ship"  might be appropriate - and then mark it disabled.   Usually it is rebuilding.
[14:24] <utlemming> skaet: the cloud images look fine
[14:24] <utlemming> skaet: I did ask last night to have them added to the tracker
[14:24] <utlemming> so....can I have http://cloud-images.ubuntu.com/precise/20120328/ added to the tracker?
[14:25] <stgraber> utlemming: yep, doing that now
[14:25] <utlemming> stgraber: thank you kindly :)
[14:26] <jibel> cjwatson, I don't know, it is a new machine and 1rst time ubuntu is installed on it
[14:26] <stgraber> utlemming: done
[14:27] <utlemming> stgraber: much obligded
[14:28] <skaet> thanks utlemming
[14:30] <cjwatson> jibel: There have been some partitioning changes recently-ish (parted 2.3-8ubuntu4).  But it's also quite possible that this has always been broken.  If you have time, I think it would be worth trying e.g. oneiric for comparison.
[14:32] <jibel> cjwatson, ok, will do.
[14:32] <skaet> scott-work,  ubuntu-studio looks like it had pretty good testing earlier in the week.   you comfortable no regressions with the current images and they should go out?
[14:42] <skaet> Riddell,  ScottK - not seeing much testing on your images in the history or current.   Are they safe to release?
[14:42] <skaet> s/your/Kubuntu/
[14:42] <Riddell> skaet: yes I'm behind in updating the iso tracker
[14:42] <Riddell> but no problems so far
[14:43] <Riddell> skaet: any relase time in mind?
[14:43] <skaet> Riddell,  ok,   please update the tracker.
[14:43] <skaet> Riddell,   soon as all the data is gathered,  so we know what's safe to ship.  :)
[14:43] <skaet> (yes, you're on critical path right now ;) )
[14:43] <slangasek> skaet: if jibel's testing shows that this mac partitioning tool issue is a pre-existing bug, are you happy to release amd64+mac with beta-2?
[14:44] <Riddell> ok I need to get back to a real computer to update the tracker this one is too fiddly for that
[14:45] <scott-work> skaet: i'll be honest, i'm not sure currently, the last image didn't get much testing and i believe we were getting a new kernel (plus luke and alessio were making some adjustments as well)
[14:45] <scott-work> skaet: can we have at least until this evening to make one (or several) last tests?
[14:45]  * scott-work does acknowlege the past testing were very favourable, but is mainly worried about the new kernel
[14:48] <skaet> scott-work,  understood.   we'll likely release before this evening,   but get the results you can, and I'll ping you later.   Problem is coordinating with other time zones.
[14:48] <scott-work> skaet: ack'd
[14:50] <scott-work> skaet:  one team member is progressing with very particular tests on the kernel, i would expect to have answers within a few hours
[14:50] <skaet> scott-work,  :)  that should work.
[14:50] <astraljava> skaet: That one team member would be me, and with that said, I'd want to hear how much time I have on Xubuntu tests, still, too. :)
[14:51] <skaet> slangasek.  not sure.    lubuntu did quite a bit of testing of amd64+mac configs on their image and didn't report issues,  but don't want to muck with disk corruption issues for users with a beta either.
[14:52] <slangasek> skaet: as cjwatson says, this may be a definition of "corruption" that only applies to the OS X partitioning tools
[14:52] <slangasek> i.e., no runtime impact and no risk of data loss
[14:53] <cjwatson> skaet: This is why I want to know if it's a regression from oneiric; if we released 11.10 with the same thing, then ...
[14:54] <skaet> slangasek, cjwatson, understood, and yes that does remove risk.   Other challenge is that they also just don't have much testing on the Ubuntu side, but there is the overlap with amd64 images, so....
[14:54] <skaet> am seriously on the fence on this one.   waiting more data.
[15:07] <skaet> Daviey,  TechnicalOverview - server's still looking a bit bare on content,   ETA for additions?
[15:17] <Daviey> skaet: That was all i was going to ship TBH, but i can elaborate
[15:23] <utlemming> skaet: cloud images are good to go
[15:25] <skaet> thanks utlemming
[15:28] <jibel> another installation of Precise is successful, and MacOS can still manage its partitions. I reformatted the disk, reinstalled MacOS and installed Ubuntu alongside.
[15:28] <pitti> skaet: do you want to wait with the publishing of the images still, or should we go ahead with this now?
[15:28] <pitti> skaet: also, WDYT about lifting the freeze now?
[15:28] <pitti> cjwatson: did you already run cron.src? if not, I can start it now
[15:30] <jibel> then I wiped Ubuntu partitions with MacOS tools and everything seems to be working correctly
[15:30] <slangasek> jibel: identical parameters for the partitioning at every stage?
[15:31] <slangasek> (bearing in mind that if there /is/ a bug, it might be related to precise partition sizes / offsets...)
[15:31] <skaet> pitti,  now that we've heard from the cloud side,  we'll be going with the images we have.   Challenge is which to publish and not.
[15:31] <cjwatson> pitti: oh, no, I didn't, please do
[15:32] <Riddell> kubuntu is just short of wubi testers
[15:32] <skaet> pitti,  so am fine about lifting freeze.   Just don't know which image we'll ship.
[15:32] <pitti> skaet: "which image"?
[15:33] <pitti> cjwatson: running
[15:33] <skaet> ubuntu core armhf and armel - no results on tracker (current or history)
[15:33] <pitti> skaet: I pre-published the current ubuntu desktop/alternates/servers this morning
[15:33] <pitti> ah
[15:33] <pitti> these don't get pre-published, so *phew*
[15:33]  * ogra_ votes for an image of a kitten 
[15:33] <ogra_> they always get good reception
[15:33] <ogra_> :P
[15:34] <jibel> slangasek, yes, I resized the hfs partition to 250GB leaving 500G free space + an EFI and a recovery partition and selected 'Install alongside' in Ubiquity
[15:34] <skaet> ogra_, hmm,  don't want to be refered to as a kitten killers please.  ;)
[15:36] <cjwatson> hmm, any of my recent changes ought to have been entirely deterministic
[15:38] <skaet> jibel, was that on oneiric then?   so we have a regression?   or on precise (and hence good to ship).
[15:39] <jibel> skaet, on Precise
[15:39] <pitti> cjwatson: any reservations about lifting freeze now?
[15:40] <skaet> pitti,   OEM has taken their snapshot as well, so they're fine with opening it.
[15:40] <cjwatson> pitti: I'm fine with it
[15:40] <pitti> ok, doing then
[15:40] <cjwatson> so -proposed will shut again for a bit ;-)
[15:40] <skaet> :)
[15:40] <cjwatson> however my branch to open it all the time is approved
[15:41] <superm1> skaet: checking with team what's up with the testing situation
[15:43] <skaet> thanks superm1
[15:46] <skaet> pitti,  cjwatson,   would like to keep the actual archive in pre-release freeze though (like we did in Oneiric).
[15:46]  * skaet likes the queue bot.
[15:46] <pitti> skaet: err, too late, I'm afraid; that's what I just asked about?
[15:47] <skaet> pitti,  I though you were asking about letting the packages that had built up get added in.
[15:47] <skaet> sorry
[15:47] <pitti> skaet: well, both really
[15:47] <pitti> skaet: we can certainly ask IS to freeze it again, but do we really want to review everythign for a whole month?
[15:48] <skaet> pitti,  given its an LTS,  and there's some area of high churn,   it seems prudent.
[15:48] <pitti> I'll also copy the installable bits from -proposed
[15:48] <Laney> we used to freeze for release at RC freeze
[15:49] <skaet> Laney,  in Oneiric we just left it freeze.
[15:49] <skaet> after Beta 2
[15:49] <skaet> ScottK,  ^  thoughts?
[15:50] <Laney> i.e. two weeks before release
[15:50] <pitti> I also copy the installable bits from -proposed to release
[15:50] <Riddell> two weeks seems a sensible time for final freeze, but isn't that scheduled?
[15:51] <skaet> Laney,  Riddell,  that's too late,  I'd like the release Candidate to actually have a realistic chance of shipping this time.
[15:51] <Riddell> yes April 12th
[15:51] <Riddell> we don't have a release candidate scheduled
[15:53] <skaet> Riddell,  we'll be putting out the image the Thursday before.   (candidate week concept we discussed at UDS).
[15:53] <Riddell> so that's April 19th  ?
[15:54] <skaet> yes,  final Freeze is April 12,  then only bugs requested by release team.
[15:54] <Laney> what do you want between now and then?
[15:54] <skaet> before that we certainly want bug fixes,  but don't want regressions
[15:54] <Laney> in terms of uploads/accepts
[15:54] <pitti> well, we never want regressions :)
[15:54] <skaet> and bad system interactions....
[15:55] <skaet> some fixes may be too risky,  libraries, kernel as things get closer to final freeze.
[15:56] <Riddell> I expect to upload qt 4.8.1 and kde sc 4.8.1
[15:56] <Riddell> no kde sc 4.8.2
[15:56] <skaet> Riddell,  when?
[15:57] <Riddell> toot sweet
[15:57] <Riddell> qt is out now, kde sc on monday
[16:00] <skaet> Riddell, no issues with it going in if Kubuntu and Edubuntu both want it.
[16:01] <Riddell> stgraber: what say you?
[16:01]  * skaet figures it still has time shake out at system level.
[16:03] <stgraber> Riddell: shouldn't be a problem for us, we really only use kdeedu
[16:04] <pitti> GrueMaster, ogra_, skaet: should we publish the armhf+omap4 images? They look like all fail in the iso tracker
[16:04] <GrueMaster> Ask the person that marked them as fail.  I'm no longer testing images.
[16:04] <pitti> ah, ok
[16:04] <pitti> pgraner and Riddell did apparently
[16:05] <skaet> pgraner, ^ comments on if armhf+omap4 safe to publish,   looks like not per the tracker.
[16:05] <stgraber> knome: did you push your changes to lp:ubiquity-slideshow-ubuntu? I'm ready for the upload now
[16:05] <Riddell> pitti: kubuntu works for me bug with a bug in the graphics driver, ubuntu desktop doesn't but only because the bug means I get it at 640x480 and ubiquity gtk doesn't work at that
[16:05] <pitti> skaet: I'm not sure whether we ever published mx5
[16:05] <Riddell> I don't know what pgraner's beastie iss
[16:09] <pgraner> skaet, yes it is, its harmless and dosen't affect much
[16:10] <skaet> pitti,  we did publish mx5 before.
[16:10] <skaet> pgraner,  thanks.   pitti,  which specific one armhf+omap4 are you refering to Ubuntu,  Ubuntu Core or Ubuntu Server?
[16:11] <pitti> skaet: desktop
[16:11] <pgraner> pitti, desktop is fine to ship
[16:11] <pitti> core armel and armhf weren't tested at all
[16:11] <pitti> and server looks fine
[16:11] <skaet> pgraner,  ubuntu core.
[16:11] <skaet> ?
[16:11] <pgraner> skaet, we don't have anyone testing them
[16:12] <ScottK> skaet: I've been offline most of the last 24 hours, so I'm OK with whatever.
[16:13] <skaet> pgraner, we won't ship them then since they haven't been tested.
[16:14] <skaet> pitti, ubuntu core armel, armhf won't go out with beta 2,  please disable.
[16:14] <pitti> done
[16:15] <skaet> thanks pitti
[16:15] <pitti> skaet, Riddell: kubuntu desktop powerpc -> disable, too?
[16:15] <pitti> i. e. not ship?
[16:16] <Riddell> pitti: right don't ship it
[16:16] <pitti> mythbuntu also hasn't been tested, at least not the current images
[16:16] <Riddell> my powerpc died years ago
[16:16] <pitti> Riddell: nice to see the Kubuntu Active passes!
[16:16] <Riddell> we like to be an active bunch :)
[16:18] <jibel> skaet, 3rd install of desktop amd64+mac in a row without problem.
[16:19] <skaet> jibel,  :D   ok, pitti,  let it out.
[16:19] <pitti> skaet: ok, waling through http://iso.qa.ubuntu.com/qatracker/milestones/210/builds again
[16:20] <pitti> walking
[16:20] <skaet> :)   I'll do a pass too.
[16:20] <pitti> Mythbuntu <- not tested
[16:21] <pitti> ubuntu desktop mx5 and omap <- not tested
[16:21] <pitti> ubuntu studio i386 <- not tested, but amd64 ok
[16:21] <pitti> except of those three, we are good
[16:24] <skaet> pitti,  Mythbuntu,  Ubuntu Studio are running tests now.
[16:26] <skaet> ubuntu desktop mx5 and omap,  not ship.
[16:26] <pitti> disabled those two
[16:26] <skaet> thanks pitti.
[16:27] <skaet> superm1,  scott-work, astraljava  ^ any updates on the tests and whether the images are safe?
[16:28] <Riddell> pitti: do you know if kubuntu active will end up at http://cdimage.ubuntu.com/kubuntu-active/releases/precise/beta-2/ ?
[16:28] <pitti> Riddell: not for sure, we haven't published it yet
[16:33] <skaet> Riddell,  can you take a pass through the Kubuntu images and make sure the ones not safe to ship are marked out as well.
[16:33] <Riddell> skaet: on where?
[16:33] <astraljava> skaet: I'm still running the tests, sorry.
[16:37] <skaet> Riddell, on iso tracker please.
[16:37] <skaet> astraljava,  thanks.   any preliminary feel?
[16:38] <Riddell> skaet: Kubuntu Alternate amd64+mac  and Kubuntu Desktop amd64+mac can be marked out
[16:39] <skaet> Riddell,  ok,  please do.
[16:39] <Riddell> mm, I don't think I know how
[16:39] <pitti> Riddell: just check them and click "disable selection"
[16:39] <astraljava> skaet: Studio seemed to have the up-to-date low-latency kernel, and I didn't notice any hiccups. Xubuntu has had most of the mandatory tests run, so I have great confidence in it already.
[16:39] <pitti> Riddell: can do for you if you wish, of course
[16:40] <pitti> astraljava: so studio i386 installs?
[16:40] <Riddell> ooh it works
[16:40] <astraljava> pitti: I'm testing the amd64 currently, I'll start a test install of i386 in a matter of minutes.
[16:41] <pitti> astraljava: thanks muchly
[16:41] <pitti> superm1: any idea about the state of the current mythbuntu images?
[16:41] <astraljava> pitti: Thank you! :)
[16:44] <pitti> oh, mythbuntu i386 is fully tested now \o/
[16:45] <skaet> \o/
[16:46] <pitti> skaet, cjwatson: as it's very likely that mythbuntu amd64 and ustudio i386 work (as their amd64/i386 counterparts work), I propose I start the publishing work, as this takes a couple of hours to complete (syncs, etc.)
[16:46] <pitti> if these really fail, we can still pull them again
[16:46] <pitti> thoughts?
[16:46] <cjwatson> sounds sane to me
[16:46] <skaet> pitti,  +1 from me.
[16:46] <pitti> I'd like to do it before starting dinner, so that it can sync over dinner
[16:47] <skaet> we may have some pulls, as the data comes in.  but as you say,  we can pull.
[16:47] <pitti> and it seems all other images are golden
[16:47] <pitti> ERROR: Cannot handle type active for kubuntu
[16:47] <pitti> Riddell: ^ hmm, at least publish-release doesn't know about it yet
[16:48] <pitti> Riddell: can you figure out the right publish-release incantation for it?
[16:48]  * pitti makes a backup of www/ now, so that we can experiment a bit
[16:48] <pitti> not sure whether cdimage even knows about it yet :/
[16:52] <cjwatson> Riddell did do some work on that
[16:53] <Riddell> I don't know if I've done anything speifically publish-release for it
[16:53] <cjwatson> Err.  I can't see that error message anywhere
[16:53] <Riddell> it should be type desktop
[16:53] <cjwatson> $ grep -r Cannot bin
[16:53] <cjwatson> bin/semaphore:  echo "Cannot acquire lock on semaphore $SEMAPHORE!" >&2
[16:53] <pitti> cjwatson: from publish-image-set
[16:54] <cjwatson> There's no such script
[16:54] <cjwatson> oh, ubuntu-archive-tools
[16:54] <pitti> right
[16:54] <pitti> last time I tried it, I wasn't able to come up with the right publish-release incantation
[16:55] <pitti> but if Riddell added that now, we just need to plug that into publish-image-set
[16:55] <cjwatson> one moment
[16:55] <Riddell> mm I'm not sure I have
[16:55] <infinity> pitti: It shouldn't be kubuntu, type active, it should be kubuntu-active, type desktop.
[16:56] <infinity> pitti: Unless we really want to rename it and jam it in the same directory.
[16:56] <cjwatson> I'm working it out now
[16:56] <pitti> infinity: sounds fine to me to keep it as a separate project
[16:56] <cjwatson> http://paste.ubuntu.com/905906/ seems plausible
[16:56] <cjwatson> just do all the same things that were done for kubuntu-mobile
[16:57] <pitti> ack
[17:01] <Riddell> kubuntu-mobile was type mobile as I remember
[17:02] <pitti> $ ARCHES='i386' for-project kubuntu-active publish-release daily-live 20120328 active named beta-2
[17:02] <pitti> No daily for precise i386 on 20120328!
[17:02] <pitti> err, sorry
[17:02] <pitti> $ ARCHES='i386' for-project kubuntu-active publish-release daily-live 20120328 desktop named beta-2
[17:02] <pitti> works fine
[17:02] <pitti> fixing publish-image-set accordingly
[17:02] <skaet> pitti,  Netboot armel+omap and armhf_omap isn't tested,  marking it don't ship.
[17:03] <infinity> skaet: Good luck not shipping it.
[17:04] <infinity> (We don't "publish" netboot beyond the archive, where it's already published anyway)
[17:04] <pitti> cjwatson, Riddell: publish-image-set.py change committed for active; based on cjwatson's patch with the additional "type = desktop" fix
[17:05] <skaet> infinity, yup indeed.   marking it explicity for tracking purspose then.
[17:05] <skaet> (and to ask questions about later... ie.  do we need to produce it for the final image set, etc.)
[17:07] <infinity> I'm not sure how we suddenly seem to have dropped omap support/testing, but there seems to be a serious miscommunication somewhere. :/
[17:08]  * skaet nods
[17:09] <Riddell> thanks pitti
[17:14] <slangasek> skaet, stgraber: why is Ubuntu core armhf marked for rebuilding?
[17:17] <skaet> slangasek,  its marked for not shipping, because it wasn't tested.
[17:18] <infinity> Err, I can test core in 2 seconds.
[17:18] <infinity> Which other cores are marked not shipping?
[17:18] <slangasek> infinity: armel + armhf
[17:19] <infinity> Right, I'll poke them both.
[17:19] <skaet> infinity,  cool.  We can re-enable them and ship if they're ok.
[17:19] <slangasek> skaet: armhf is rather er, core to Core; if testing is (ever) needed, feel free to ping me
[17:19] <skaet> slangasek,  will do.
[17:19] <skaet> (and thanks)
[17:20] <utlemming> is there a bug with the armhf core?
[17:20] <utlemming> s/bub/bug number/
[17:20] <infinity> There are no bugs, it just didn't get tested.  Doing now.
[17:21] <utlemming> infinity: ah, okay.
[17:22] <pitti> erk, I was apparently typing into the void and got disconnected
[17:23]  * pitti replays
[17:23] <pitti> cjwatson: oh, did you fix publish-release to put the corrent "Beta-2" into the HEADER.html files?
[17:23] <infinity> skaet: core/armel and core/armhf are both fine.
[17:23] <pitti> I don't see any having "Daily Build" any more
[17:23] <pitti> anyway, looks like publish-release is DTRT now, sweet
[17:23]  * skaet welcomes pitti back.   infinity is testing out the Ubuntu Core armel and armhf images so we'll be likely to ship
[17:23] <pitti> skaet, cjwatson: "rel -15 mins" steps 1 to 3 done
[17:23] <pitti> skaet, cjwatson: i. e. all images published, .manifest and .htaccess mangled, etc.
[17:23] <infinity> pitti: ^
[17:23] <pitti> mirrors are syncing now, which will keep them busy for an hour or two
[17:23] <pitti> skaet, cjwatson: if it's alright with you, I'd leave for dinner now; I'll take my mobile phone with me for emergencies?
[17:23] <pitti> infinity: yep, publishing these two along then
[17:23] <skaet> :)
[17:24] <skaet> If they're added,  enjoy dinner.   :)  Will call if urgent.
[17:24] <skaet> thanks pitti.
[17:24] <pitti> reenabled
[17:24] <pitti> (in the tarcker)
[17:25] <utlemming> skaet: whats our current ETA on making things public?
[17:25] <skaet> pitti,  don't disable Beta 2  in the tracker.   Results still coming in on those other projects.
[17:25] <pitti> utlemming: you can start publishign the EC2 images
[17:25]  * skaet nods
[17:25] <cjwatson> pitti: HEADER.html> hmm, I don't recall
[17:25] <pitti> skaet: nope, wasn't planning to
[17:26] <pitti> cjwatson, skaet: I don't remember, should or shouldn't I remove beta-1 from releases/cdimage at this point?
[17:26] <skaet> pitti,  thanks.   I'll do it after we get those last data points,  before the dailies kick off again.
[17:26] <cjwatson> pitti: it probably wants to go to old-images
[17:26] <pitti> I can move them to old-images
[17:26] <pitti> ack, will do
[17:27] <skaet> thanks.
[17:27] <skaet> utlemming,  still a couple of hours off for the announce, but getting things ready with the images is good (what pitti says)
[17:28] <fabsh> when's the eta for the release
[17:28] <pitti> oh, and moving alpha-2 to old-images as well
[17:30] <SpamapS> Daviey: around?
[17:32] <pitti> cjwatson, skaet: alpha-2 and beta-1 removed; should free quite a lot of space on cdimage mirrors then
[17:32]  * pitti off for dinner then, please call my mobile on fires
[17:34] <skaet> cjwatson,  am wondering if I should update the links in  to point to old-images for the Alpha2 and Beta1 TechnicalOverview,  so folks know where to find them.   (after Beta 2 goes out).   useful?
[17:35] <arosales> skaet: will there be an ubuntu-release meeting tomorrow?
[17:35] <knome> stgraber, nope, we didn't have anything now
[17:36] <cjwatson> skaet: old-images is not publicly accessible
[17:36] <cjwatson> so no, not useful :)
[17:36] <skaet> arosales,  no meeting planned right now - this release is causing some late nights.    Please have detailed status in and we'll handle by email.   Call one on monday if somethings need wider discussion.
[17:36] <skaet> cjwatson,  fair enough.  :)  thanks.
[17:36] <cjwatson> perhaps you're thinking of old-releases, but we only do that for actual final releases, not alphas/betas.  old-images is a staging area before old milestone releases get backed up to tape.
[17:36] <stgraber> knome: when are you expecting your changes to land?
[17:36] <cjwatson> we can recover them via IS if we have to for archaeology, although not necessarily quickly.
[17:37] <skaet> fabsh,  lots of things to sort still,  couple of hours out at a minimum.
[17:38] <skaet> fabsh,  announce email will signal we've stopped making changes ;)
[17:38] <arosales> skaet: ok, thanks.
[17:39] <knome> stgraber, well i don't know, we're not planning anything... ;)
[17:39] <utlemming> skaet: cloud-images are published
[17:39] <knome> stgraber, i was just asking for the future, and for ubuntu studio too
[17:39] <skaet> thanks utlemming,  I'll start checking links and let you know if I spot glitches.
[17:40] <stgraber> knome: oh, good, I thought you had some stuff to update already, I certainly won't complain that you don't have to do last minute translation template update ;)
[17:40] <knome> ahh, nope ;)
[17:40] <skaet> jbicha,  how are we looking on ubuntu-doc freeze?
[17:41] <Laney> has the default wallpaper materialised yet?
[17:42] <jbicha> skaet: umm...
[17:43] <jbicha> I only got half the screenshots done, I don't expect to be able to finish the rest until this weekend
[17:44] <skaet> Laney,  default wallpaper change isn't supposed to affect screen shots based on earlier discussion.
[17:44] <skaet> jbicha,  are all the strings ok,  for the translators to start?
[17:46] <jbicha> skaet: I'm going to give it a final lookover and ping you & dpm when I'm done
[17:49] <skaet> jbicha,  sounds good.
[17:49] <skaet> thanks
[17:51] <SpamapS> Can I get an ACK on this juju FFE? https://bugs.launchpad.net/ubuntu/+source/juju/+bug/962507 .. Daviey ACK'd it last week, but there have been a few additional changes and I want to make sure its ok before upload.
[17:51] <ubot2> Launchpad bug 962507 in juju "[FFE] Latest juju snapshot enables maas provider" [High,New]
[18:29] <superm1> pitti: Daviey is going to test amd64 shortly, but not too much worry as i386 is looking good
[18:31] <skaet> superm1,  ok.  :)
[18:34] <pitti> syncs are making progress, but will still take a while
[18:34] <jbicha> skaet: I believe we'll be good to freeze ubuntu-docs, technically that happens at 2100 UTC, right?
[18:34] <skaet> jbicha,  yes.   and thanks.   that's good news.
[18:35] <jbicha> skaet: except for the other half of the screenshots like I mentioned
[18:35] <skaet> astraljava,  all still looking ok on Ubuntu Studio.
[18:35] <skaet> jbicha,  noted.  :)
[18:37] <astraljava> skaet: Yes, I've been running some exhaustion tests on the kernel, and it's looking quite good. Still need some more time on the i386, but looking good thus far.
[18:37] <astraljava> (...there was a set-back with the test machine I use for i386 tests, hence it's been delayed a bit...)
[18:38] <skaet> astraljava, sounds good we'll keep on the path of assuming they'll be releasing then.
[18:39] <astraljava> skaet: Absolutely, no reason not to.
[18:40] <pitti> skaet: hm, I see that ubuntu amd64+mac got disabled, but it was tested; why wouldn't we release this?
[18:40] <pitti> once the big sync is done, I'd like to publish it as well
[18:40] <skaet> pitti was disabled before jibel, gave us the +1 its ok.
[18:40] <pitti> ok, re-enabling and publishing
[18:40] <skaet> since we know its ok,  reenable.
[18:40] <skaet> :)
[18:42] <pitti> 'k, done
[18:42] <pitti> will wait with another sync-mirrors push until the current one is done, though
[18:42] <skaet> pitti,  there's some community arm ports being tested and may get results for later today.   If they don't make your big push,  handle tomorrow?
[18:43] <pitti> skaet: I can queue them up now
[18:43] <pitti> or later, yes
[18:43] <skaet> pitti,  not sure yet which ones will make it.  so later is probably better.
[18:43] <pitti> skaet: so far my plan was to take a break for an hour or so, as there's not much I can do to speed up the rsync now
[18:43] <pitti> skaet: I'll check back in maybe 1.5 hours, check sync status, and publish the rest
[18:43] <pitti> sounds ok?
[18:44] <skaet> pitti.  that works for me.  Am on editing of the announce.  Would like you to take a pass at it in about an hour or so if possible?
[18:44] <pitti> sure
[18:44] <skaet> Thanks.  :)
[19:53] <pitti> re
[19:53] <pitti> ah, sync seems to be mostly done, xubuntu is there
[19:54]  * pitti pushes the next sync run
[19:54] <skaet> pitti, amd64+mac images not showing up under ubuntu yet.  can you check?
[19:54] <pitti> skaet: covered in this run
[19:54] <pitti> also the removal of alpha-2/beta-1
[19:54] <pitti> ahh, these are now gone from http://cdimage.ubuntu.com/edubuntu/releases/12.04/
[19:55]  * pitti watches cdimage.u.c. take a deep breath from freeing some GBs
[19:55] <pitti> skaet: any new image verifications since then?
[19:59] <pitti> skaet: http://cdimage.ubuntu.com/releases/12.04/beta-2/ has amd64+mac now, and the rest should be there now, too
[20:04] <infinity> pitti: Where was that proposed build status page you whipped up?
[20:04] <pitti> infinity: http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html
[20:04] <pitti> right next to all the others
[20:04] <infinity> Oh, that's just uninstallibility reports.
[20:04] <infinity> I though you had something detailing out-of-date/unbuilt.
[20:05] <pitti> infinity: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[20:05] <pitti> argh, but now that precise is thawed it doesn't actually show that any more
[20:05] <pitti> I'll fix that
[20:05] <pitti> ... tomorrrow
[20:05] <pitti> infinity: do you know what's up with https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.1-1ubuntu3/+build/3367726 ?
[20:05] <pitti> that looks strange
[20:05] <pitti> and the previous version did build on amd64
[20:06] <pitti> and the delta to this is just a typo fix in Depends:
[20:06] <infinity> That looks like someone asked webops to "cancel" it instead of killing it.
[20:06] <infinity> Build records in that state can't be fixed without DB surgery.
[20:07]  * infinity wonders why that was done, and by whom.
[20:07] <astraljava> pitti: skaet: I've been running the tests on both amd64 and i386 for Studio, and I believe I can now say in confidence that they are working just fine.
[20:07] <astraljava> with confidence*
[20:07] <pitti> infinity: right, I guess we'll need another upload to rescue this? (sigh)
[20:08] <pitti> astraljava: splendid, thanks!
[20:08] <SpamapS> FYI, i need to do an upload of mysql soon, there's a new upstream w/ security fixes
[20:08] <astraljava> Thanks to you guys!
[20:08] <SpamapS> just giving release team a heads up :)
[20:08] <infinity> pitti: Or sort out the DB surgery with wgrant and have it hotfixed by webops.
[20:09] <infinity> pitti: It's just a single update to a row.
[20:09] <infinity> pitti: Given that ARM has been building it for a good while, it might be nice to fix the build record.
[20:10] <pitti> yes, absolutely
[20:17] <skaet> astraljava,  great!   and thank you.
[20:18] <skaet> Riddell,  where should the Kubuntu Active image being showing up?   am not seeing it in the Kubuntu page.
[20:18] <pitti> skaet: http://cdimage.ubuntu.com/kubuntu-active/releases/12.04/beta-2/
[20:19] <pitti> skaet: sorry, DSL dropout; I /msged that to you, but I guess it got lost
[20:19] <skaet> pitti, thanks.   Will go add the link.
[20:20] <pitti> skaet: so DSL + the late hour might want to tell me to go to bed :)
[20:20] <skaet> pitti,  thanks for your help.   understand.   I think we're pretty close.
[20:20] <skaet> I'll impose on infinity or slangasek if there are remaining issues spotted.
[20:21] <pitti> cheers, so good night, and good luck with the remaining bigs!
[20:21] <pitti> bits
[20:21] <skaet> Good night pitti,  sleep weel.
[20:21] <skaet> well even.  lol
[20:21]  * skaet doesn't have the excuse its late,   just lots of typing today.
[20:22]  * knome sends skaet some replacement fingers
[20:23] <skaet> :)
[20:29] <Daviey> \o/
[20:29] <scott-work_> skaet:  did you get an answer from astrlajava about the studio images?
[20:30] <skaet> scott-work,  astraljava just gave them a +1 in the backscroll.   we're good.
[20:30] <skaet> (about 23 minutes ago)
[21:02] <skaet> web site up - check
[21:02] <skaet> links to mirrors working - check
[21:02] <skaet> links on annouce email working - check
[21:02] <skaet> yup, guess its that time....
[21:03] <skaet> Beta 2 is released.
[21:03] <fabsh> nice
[21:03] <fabsh> i can publish my news article now :)
[21:03] <mdeslaur> congrats!
[21:03] <skaet> thanks for waiting fabsh - very much appreciate it!!!
[21:03] <fabsh> its my job :)
[21:05] <ScottK> Sigh.
[21:05] <skaet> Riddell,  scott-work,  knome,  stgraber,  highvoltage, astraljava, gilir - we're live now.
[21:05] <ScottK> Announcement still refers to an Ubuntu kernel.
[21:06] <knome> skaet, yup, our beta2 announcement is up since "<skaet> Beta 2 is released" + 15 secs:)
[21:06] <stgraber> yay!
[21:06] <skaet> ScottK - in announce we say its clearly based off upstream Linux kernel.   Not trying to hide where it comes from.
[21:06]  * knome rejoices with some good rum
[21:06] <ScottK> That's true.
[21:07] <Riddell> awooga
[21:07]  * fabsh has Talisker
[21:08]  * knome prefers ron zacapa 23yo
[21:08] <skaet> thanks pitti, cjwatson, infinity, Riddell,  slangasek for getting those bits all nice and sorted.  :)
[21:08] <ScottK> skaet: Fair enough.  It seems reasonable.
[21:08] <fabsh> knome: it was a gift, i won't complain
[21:09] <knome> fabsh, heheh, yeah, i wouldn't either... :)
[21:10] <astraljava> A huge thanks for the whole release team!
[21:11] <skaet> :)
[21:19] <fabsh> ok, peeps. my news item is submitted and pending editorial review. i'm off to bed. good luck with the beta! :)
[22:01] <wgrant> infinity: The button was added to fulfill the long-standing request for a button to permanently kill a build so the user couldn't retry it.
[22:02] <wgrant> infinity: eg. if it's a buildd-killing build.
[22:02] <wgrant> infinity: (except that the button doesn't work for non-virt builds, so I guess a WebOps manually did this one with SQL)
[22:03] <skaet> Daily builds have been turned on.
[22:04] <skaet> default milestone has been pointed back to Precise Daily.
[22:17] <infinity> wgrant: I can't see why anyone would have manually done it, since we want that build to happen.
[22:17] <wgrant> infinity: pitti requested some LO builds killed last night.
[22:17] <infinity> wgrant: Anyhow.  I think we might need a duckie-accessible way to undue the pain that button brings, if we insist on keeping it.
[22:17] <wgrant> I'm not sure if that was one of them.
[22:17] <infinity> wgrant: The ones he requested were a previous version.
[22:18] <infinity> wgrant: But someone may have oopsed.
[22:18] <infinity> wgrant: Anyhow, would it be doable to resurrect that build record?  Don't really want to reupload and reset the whole process on other arches.
[22:18] <wgrant> aaaaaaa
[22:19] <wgrant> infinity: Best is probably to convince a webops to reset the status to FAILEDTOBUILD
[22:19] <wgrant> infinity: Then you can retry normally.
[22:19] <infinity> Sure, is that all it takes?  It's just in a broken status?
[22:20] <infinity> (do they know the SQL for this by rote, or do I need you to give them a query?)
[22:21] <wgrant> infinity: You'll need to ask them.
[22:21] <wgrant> I don't know all their secret repositories.
[22:27] <stgraber> skaet: did the matching changes on the tracker
[22:28]  * stgraber killed the bot to avoid the flood
[22:28] <stgraber> that's an interesting side effect of marking a milestone as released ;)
[22:29] <stgraber> will need to fix that...
[22:29] <knome> khihi
[22:30] <skaet> stgraber,  :)  looks good.
[22:32] <phillw> will http://iso.qa.ubuntu.com/qatracker/milestones/210/builds tidy itself up, or do one of you good people need to that manually?
[22:34] <stgraber> phillw: what do you mean? it's now archived as it's and shouldn't ever change anymore
[22:34] <phillw> stgraber: it shows the aborted mac builds as rebuilding?
[22:35] <knome> awwwh
[22:35] <stgraber> sorry for that
[22:36] <stgraber> phillw: yeah, we mark them for re-build when we know they won't be released
[22:36] <stgraber> so I at least confirmed that moving a milestone from release to testing makes the bot spam everyone which is the intended behaviour :)
[22:36] <phillw> okies, just I know someone will ask me 'when will they finish rebuilding?' :D
[22:36] <stgraber> now let's say if archiving no longer spams us :)
[22:37] <stgraber> *see
[22:39] <stgraber> so far so good
[22:39] <stgraber> still good, now let's see if we get spammed
[22:40] <stgraber> apparently not, so looks like the fix worked
[22:54] <GrueMaster> Ok, looks like Beta 2 is now archived.  I can say that I have run through all arm images and everything passes (with bugs).  I have a list of bugs as well.  Just can't enter them in the tracker.
[23:00] <stgraber> ... who re-enabled the milestone? :)
[23:00]  * skaet reopened the Beta 2 release to get some more results added to the tracker.
[23:00] <skaet> stgraber,  I'll set it back again as soon as those results are added.
[23:01] <stgraber> skaet: ok :) I'll find a clever way to prevent the bot from flooding both channels when moving a milestone back to testing
[23:02] <skaet> stgraber,  sounds good.
[23:02] <knome> hrmm?? stgraber
[23:02] <stgraber> at least we confirmed that the bot no longer gets killed for flooding LP :)
[23:02] <stgraber> knome: what? the bot is doing what it's supposed to ;)
[23:02] <knome> oh, right
[23:02] <knome> ...
[23:03] <knome> a very good FLOODBOT then
[23:03] <knome> :)
[23:04] <skaet> knome,  sorry,  few last results came in we wanted to add to release.
[23:05] <knome> np :)
[23:05] <skaet> stgraber,  I'll give you some warning when we're done, and you can switch back to test out your new non-flood version... ;)
[23:06] <skaet> when you're ready.
[23:06] <skaet> or I'll just do it,  either way is fine.
[23:09] <stgraber> skaet: switching back won't flood, I added code for that
[23:09] <stgraber> as testing => release is expected milestone status change
[23:09] <stgraber> released => testing isn't :)
[23:13] <stgraber> skaet: just looked at the code again, it's going to be pretty difficult to differentiate someone moving a milestone from released to testing vs someone adding the first set of images to a new milestone
[23:13] <stgraber> besides checking how many entries and not doing anything above a given threshold
[23:15] <skaet> stgraber,  ok,  I'll switch it back now.   New results have been added.
[23:20] <stgraber> skaet: added flood protection, if there are more than 25 images added at once it'll just print a single message ;)
[23:21] <stgraber> let's see if that works :)
[23:21] <skaet> heh,  notice you just did
[23:21] <skaet> :)
[23:21] <infinity> 25 seems like a pretty high threshold.
[23:22] <stgraber> infinity: yeah, but I still want notifications when we add all the upgrades
[23:23] <skaet> hmm... did I just cause that quit, by doing the switch back to release?
[23:23] <stgraber> skaet: nope, I'm fixing a bug
[23:23] <skaet> :)
[23:23] <skaet> stgraber,  I've done what I need to.   Will let you test as needed now.   ;)
[23:24] <stgraber> skaet: thanks :)
[23:24] <infinity> stgraber: Well, what's the theoretical largest number you can get in one go?
[23:24] <infinity> All arches for any given CD build is only 4 at the moment.  All subarchaes for d-i is a bit more, if they all published at once.
[23:25] <infinity> subarches, even...
[23:25] <stgraber> qatracker=> SELECT count(*) FROM qatracker_product WHERE siteid=1 AND status=0;
[23:25] <stgraber>  count
[23:25] <stgraber> -------
[23:25] <stgraber>    117
[23:25] <stgraber> (1 row)
[23:25] <stgraber> total number of products with status active on iso.qa.ubuntu.com
[23:26] <infinity> Well, yes.  I didn't mean how many are there, I meant how many would post simultaenously.
[23:26] <infinity> I'd guess that anything over 10 is an "oops, we touched everything" flood.
[23:26] <stgraber> ok, almost working ;)
[23:27]  * infinity likes the %s.
[23:27] <infinity> printf is hard.
[23:27] <stgraber> infinity: currently, the maximum number of products we've been adding at once is 16
[23:27] <stgraber> infinity: that's when we add all the upgrades
[23:27] <infinity> Seriously?  16?
[23:28] <stgraber> infinity: yep
[23:28] <infinity> I guess I'm thinking from a cdimage autopost perspective, where it's technically impossible right now to post more than 4 things at once.
[23:29] <stgraber> yeah, upgrades are added either by a script that pushes them all at once with the current date as the version or by someone in the admin UI selecting them all and clicking "add build"
[23:29] <stgraber> both of them result in all of them appearing in the DB in a single transaction
[23:29] <infinity> Check.
[23:30] <infinity> I'd almost argue for a lower flood protection, but special-case upgrades.
[23:31] <infinity> "Upgrades were added for %d products: product arch, product arch, product arch"
[23:31] <stgraber> ok, %s fixed ;)
[23:32] <infinity> Cause I don't want to see 16 lines of output, even if it's legit. ;)
[23:32] <stgraber> yeah, I guess that'd be an idea. For now the limit of 25 prevents the "oh, here's everything showing up again". The other cases (website failure, ...) are already dealt with in the code (and it's been hitting that bit a few times over the past 2 hours)
[23:44] <phillw> who maintains the page http://releases.ubuntu.com/ ?
[23:49] <slangasek> the release team / cdimage team does
[23:50] <infinity> phillw: Why do you ask?
[23:51] <infinity> Oh, cause it doesn't list all the flavours.
[23:52] <slangasek> infinity: if you're fixing, should probably pull Gobuntu off there while you're at it since it's EOL
[23:52] <phillw> I've had mutterings from the ranks that lubuntu isn't on there!
[23:52] <slangasek> (was desktop, last released with hardy)
[23:53] <infinity> And change some wording.
[23:53] <infinity> And it should probably also point out that cdimage/releases hosts unsupported Ubuntu images too.
[23:53] <infinity> Or even supported ones that we just don't put on releases. :P
[23:54] <infinity> lubuntu's a less ambitious and easier fix, though.
[23:54] <phillw> thanks :)
[23:55] <infinity> Err, if that text actually showed up anywhere in the source...
[23:55] <infinity> Oh, it's not generated.
[23:55] <infinity> Just a static header.
[23:55] <infinity> Derp.
[23:58]  * infinity rearranges alphabetically to avoid people complaining about Kubuntu being special.
[23:58] <phillw> we're all a bit tired, me thinks! I was going to bed 3 hours ago!