[00:00] skaet: I know the bugs were logged. but as the respins go on, they get dropped off. Where are they all kept? [00:00] where it says /builds on the iso tracker put in /history [00:00] then you should see them all. [00:02] 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] can you give me a clean link for them? [00:02] stgraber, ^ [00:02] phillw, will do. [00:04] http://iso.qa.ubuntu.com/qatracker/milestones/210/history [00:06] 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] skaet: Mars cleared the ppc error, I'm guessing it was a dodgy download that snook through the lower level error checking. [00:08] ok. what about the intel macs? [00:09] 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] skaet: may I speak freely? [00:10] skaet: or should this be done in PM? [00:11] PM if its sensitive people wise, otherwise speak freely. [00:11] If "speaking freely" won't violate the code of conduct, go to town. [00:12] skaet: we do not have a log bot. I always adhere to CoC [00:12] :) [00:13] skaet: I am, after all a ubuntu member, I just do not use that cloak. [00:13] phillw, comment on CoC was from infinity ;) [00:14] Long story, cut short .... xubuntu was the best option for ppc, then it got bloated & needed lots of work arounds. [00:15] when it was mentioned that lubuntu "may" do a ppc release, the ppc people were all over us [00:15] phillw: xubuntu would add PPC back if there were committed testers [00:15] we said that to so required testers. [00:16] micahg: you seem to forget Charlie handing in his resignatation? [00:16] phillw: charlie never tested PPC [00:17] micahg: I am not currently chatting about xubuntu? I am chatting about ppc / mac testers? [00:18] please do let me finish before you start. [00:19] skaet: I am finished. I am an admin, catch me on PM anytime [00:20] 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] 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] 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] stgraber, :) [00:26] phillw, yes, that does look complicated for ppc macs. Who is testing intel macs and are they using the same proceedure? [00:27] phillw, or are they working on bare metal. [00:29] you're not going to get a useful test of amd64+mac under qemu. [00:30] (qemu doesn't implement uefi, as far as I'm aware) [00:33] 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] slangasek: They have bare metal testers for PPC as well. [00:34] in which case I have no objection [00:34] slangasek: Those instructions are more of a "for other who want to add more test results", AIUI. [00:35] s/other/others/ [00:35] slangasek: But the guy filing lubuntu/ppc bugs is doing so on real hardware. [00:35] ok, good :) [00:35] 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] 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] 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] 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] 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] how do we get ahold of Lars if ribs need poked? [01:18] slangasek: https://launchpad.net/~lubuntu-qa [01:19] let me just dig up his email [01:21] slangasek: P okay? [01:21] PM [01:21] sure [01:25] slangasek: from zero to where we are, does IMHO, inforce the lubuntu commitment to lower spec machines. [01:27] 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] Gah, who just let all that stuff into -release? [01:34] Or were those all rejects? [01:35] slangasek, skaet: ? [01:35] infinity: my e-mails says they were accepted [01:35] infinity, not me [01:36] stgraber, is it possible to change removed in the bot message to accept or reject? [01:36] skaet: Not easily. [01:36] ok. just an idea. [01:36] skaet: Requires scanning DONE and REJECTED which is hugely time-consuming and vile. [01:37] skaet: what he said :) hopefully the API for the audit changes will make that easier [01:37] (I suppose one could also blindly hit the package/version record, and if it doesn't exist, assume reject) [01:37] stgraber: ^ [01:38] 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] I guess I can implement that and we'll see how well that works [01:39] Well, if the source exists at all in a !new state, it's accepted (or better). [01:39] Since unapproved sources don't have source records yet. [01:39] Actually, I guess new doesn't either. [01:40] Only new binaries do. [01:40] 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] 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] But for unapproved, if there's a source record at all, that should mean "accepted". I think. [01:42] Anyhow. Whoever did the above just leaked in some gnome transition bits and other stuff. *sigh* [01:42] please wait on that bcfg2 upload [01:42] I'll use it to test the bot ;) [01:42] Though, maybe it was all universe. [01:43] hmm... hasn't solved the mystery of who just let all that code into -release. [01:44] * phillw not guilty... [01:44] infinity: can you reject bcfg2? it's one of my uploads, I'll re-upload after that so we can test "approved" :) [01:44] stgraber: I can just pull it out of rejected after I do, no need to reupload. [01:45] infinity: ah right, forgot you could do that [01:45] Oh, except then we won't be able to test the unapproved->accepted route. [01:45] So, reupload. :P [01:45] yay! [01:45] uploading now [01:46] the current code is: if not "Rejected" => "accepted" [01:46] so as the above worked, accepting should work too [01:46] stgraber: As in, if source record exists -> accepted; else -> rejected? [01:47] Something like that should be close enough to the truth for most cases we care about anyway. [01:47] 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] "build record"? [01:47] that object happens to have a status property [01:47] There are no build records for unaccpted source... [01:48] s/build record/package upload/ [01:48] https://launchpad.net/+apidoc/1.0.html#package_upload <-- that stuff [01:48] Ah-ha. [01:48] Much more elegant. [01:48] looks like that worked. ;) [01:49] thanks skaet :) [01:49] > [01:49] * skaet did those ^ on request from vanhoof. [01:49] > [01:49] vanhoof: You poked me? [01:49] skaet: we haven't seen any "accepted" yet :) [01:49] infinity: same question [01:49] infinity: last minute drama, and a decision was made to yank them [01:49] vanhoof: Oh, was that all of them, not just the older ones? [01:49] infinity: that all of em [01:49] vanhoof: I guess it's a good thing I didn't get around to reviewing them for jani yet. :P [01:52] queuebot: Wake up and poll already. [01:52] \o/ [01:53] wow, that worked! [01:53] stgraber: Magic. [01:53] now looking into what happened with mosh [01:55] that's if LP stops timing out when trying to look at the records in the Done queue :) [01:56] right, so the problem is indeed that they are binary packages but not detected as such... [01:58] stgraber: Was that perhaps fallout from trying to handle the binary+translations case? [01:59] 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] and instead simply check if pkg.arch == "source" which should be a bit more reliable [01:59] * infinity nods. [02:00] 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] ok, looks like all source packages in New have "source" as their architecture, good [02:05] infinity: accepts> wasn't me [02:05] slangasek: Great. We have a mystery queue manipulator. [02:06] 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] stgraber: Thanks in advance. [02:08] infinity: hehe, should actually be easy to do ;) [02:08] 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] 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] 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] stgraber: we'll also see a sudden spate of retirements from ubuntu-archive, I trust :P [02:09] stgraber: Perfect! [02:09] slangasek: :) [02:09] slangasek: That might not be a bad thing either. Probably should thin the herd a bit. [02:10] I'd rather not [02:10] the NEW queue is long enough without reducing manpower :) [02:11] ^ that's with this morning's bug fixed and some better handling of syncs in the New queue too [02:11] (as LP also considers 'sync' as a valid architecture apparently) [02:11] stgraber: is there a bzr branch for the queue bot yet? [02:11] slangasek: lp:~stgraber/+junk/queuebot [02:11] ok :) [02:12] 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] I think ubuntu-core-dev would be fine anyway [02:13] not like being able to edit the bot confers any superpowers that should be tied to release :) [02:13] 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] stgraber: You're not in -release? [02:14] But yeah, -core-dev seems fine. [02:16] infinity: nope, might poke skaet about it at some point though :) [02:16] infinity: I'm the team owner though (through coredev) ;) [02:16] s/coredev/TB/g [02:16] Yeah, I'm jealous of your horsey. [02:17] 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] Can we make him our mascot? [02:23] so, to reflect our private discussion: yeah, I'd be happy to join the release team [02:24] slangasek: queuebot moved to https://code.launchpad.net/~ubuntu-core-dev/+junk/queuebot [02:24] stgraber: Probably doesn't need the junk... [02:25] don't we have to link a branch to a project? [02:25] We could create a project for it. [02:25] Then I could file bugs instead of pestering you on IRC! [02:25] Progress. [02:26] :) [02:26] not sure, sounds like a slower process causing more interruptions for me (unless you don't say anything on IRC ;)) [02:27] 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] 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] at this rate we'll soon have more bots than human in the channel [02:29] There's probably a critical mass of bots we can reach where we obsolete ourselves. [02:29] Please don't write sarcasmbot, I'll be out of a job. [02:30] ;) [02:30] * stgraber adds to the TODO [02:30] the blueprint approval for that one should be fun [02:38] * skaet giggles [03:34] 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] 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] 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] 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] including what looks like a fix for the missing "chvt 1" that was mentioned earlier today [03:35] stgraber: I'm planning a plymouth upload, yes, though probably only once the chvt thing is *properly* fixed [03:35] the 'chvt 1' is almost certainly wrong and should NOT be uploaded [03:38] 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] slangasek: If you're touching plymouth, can I bring https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/939283 to your attention? [03:39] Launchpad bug 939283 in plymouth "[hybrid-gfx] Blank screen on boot due to failure to follow primary framebuffer" [High,New] [03:39] I think I have the crux of it, but I need to make sure we're entirely race-free [03:40] RAOF: I'm aware of the bug, but I have no good solution for it [03:42] 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] 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] slangasek: actually "initctl show-config | grep login-session-start" should work [03:46] 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] or more specifically explictly say they might emit it [03:47] 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] 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] 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] 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] stgraber: but if I don't pull it off, that does sound like a viable fallback, thanks [04:01] RAOF: there's no monitoring of udev events, no [04:02] That shouldn't be too hard to add? I'm blissfully unfamiliar with the plymouth code, though. [04:04] I don't think this would be a safe area to make changes to post-beta, sorry :/ [04:04] regression-testing plymouth is effectively impossible at this point [04:05] release folks, I'm not sure, but this seems like a rather bad behavior for the LTS openssl: bug 965371 [04:05] Launchpad bug 965371 in openssl "HTTPS requests fail on some sites on Ubuntu 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/965371 [04:08] kees: do you know why TLSv1 is disabled by default? I would assume that's because it's insecure? [04:09] 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] slangasek: That's a good question; I'll try it next time it triggersl. [04:18] slangasek: TLSv1 is slightly less secure than 1.3, but none of the browsers are using it yet. [04:18] which is why no one has noticed that paypal can't talk to a 1.3 tool [04:18] the changelog for openssl 1.0.1 seems to indicate that they fixed autodetection, but it's clearly a lie. :P [04:19] they turned on 1.3-by-default in the 1.0.0 release at some point [04:22] ok [04:22] triaged and assigned for follow-up [04:49] stgraber: Hrm. queuebot just helpfully told us about 18-hour-old uploads... [04:50] stgraber: Oh, no. Nevermind. It really is in the queue twice. [04:50] * infinity double-takes. [04:50] How... Is that in the queue twice? [04:50] you can upload multiple times to unapproved [04:51] micahg: With the same version? [04:51] yep [04:51] That seems broken. [04:51] The only queue without constraints should be rejected. [04:52] would make it easier to detect collisions :) [04:54] Oh well, I'll reject the older one. [04:56] * skaet --> zzz [05:11] Good morning [05:12] pitti: We made some improvements to the bot today. Enjoy. [05:15] looking forward to trying them out :) I have some -proposed stuff to accept [05:16] 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] hm, at this point we certainly don't consider respinning server again? [05:16] pitti: Oh, and announces images being posted to the tracker. [05:16] reject vs accept> yay! [05:16] very helpful indeed [05:16] saves the "^ don't panic, it was a reject" followups [05:17] * infinity nods. [05:18] 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] Soon, the bot will do our jobs for us. [05:19] can it point out bugs in debdiffs yet? [05:20] Soon. [05:22] I'll do the pre-publishing now, so that it has some time to mirror around the world [05:22] cjwatson, skaet ^ [05:23] ah, we don't put Kubuntu on release.u.c. any more [05:27] cjwatson, skaet: pre-publishing done [05:55] cjwatson, slangasek: FYI: [05:55] bzr commit -m 'sru-release: Add --release/-r option for copying to release pocket, for staging uploads in development release' [06:02] pitti: \o/ [06:02] pitti: Both to the pre-publishing and the sru-release change. [06:02] working on making the SRU report show non-DONE builds, to see what can't e copied yet [06:03] e -> be [06:03] LibO will be a fine test for this for the next two days [06:04] Heh, yeah. [06:05] Someone really needs to talk to them about splitting it out into modular bits. [06:05] (Which, ironically, it mostly is in the source anyway, they just need to release it that way) [06:05] in fact they just merged their individual component gits back into one [06:05] Meh [06:05] It's insanity, even on x86. [06:06] 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] infinity: it's almost as large as the kernel (~12M lines of code) [06:08] micahg: Yeah, but the difference is that no kernel build uses all of the source. [06:09] Also, the kernel workd. [06:09] s/workd/works/ [06:10] pitti: I kinda wonder who I'd need to talk to about doing componentised distribution and releases without being laughed at. [06:10] that's a question for Sweetshark [06:10] 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] (I'm sure my parents would love it if Office suite updates were 5MB instead of 150... [06:10] ) [06:55] slangasek: you mentioned an unconfirmed report that amd64+mac corrupts partition tables; do you have a bug number or anything for that? [07:08] 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] cjwatson, I'm wiping the disk and will redo the installation [07:20] curious, I don't know what their constraints are exactly [07:39] what time are we expecting to release today? [07:39] "Thu Mar 1 22:21:43" says the beta 1 announce, no rush then :) [07:39] 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] it may be a hardware issue, there are fsck errors on every boot. [07:42] "unrecognized file system" is another error but the filesystem type is JHFS+ [07:43] I probably won't be able to investigate that; sounds like the sort of thing you really need to be in front of ... === doko_ is now known as doko [12:45] 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] oh, 3 mins before [12:45] * bdrung was faster than tumbleweed. :) [12:45] tumbleweed: that was a sync [12:46] tumbleweed: oh, you mean you did an upload just now? [12:46] I just did a second sync [12:46] right, rejected === bladernr_afk is now known as bladernr_ [13:08] skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseBeta2TestReport === bladernr_ is now known as bladernr_afk [13:54] hi [13:54] 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] 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] good morning [14:01] good morning skaet [14:01] :) [14:03] pitti, cjwatson - based on the test report, am thinking Ubuntu amd64+mac and ppc probably shouldn't ship this time around. [14:04] thoughts? [14:04] skaet: good morning [14:04] :) [14:05] 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] skaet: no strong opinion on that, but amd64+mac seems to at least work [14:05] skaet: and it's by and large identical to teh amd64 one, so "it boots, it works" comes pretty close IMHO [14:05] heh, yes, what cjwatson says [14:06] pitti, worry point is that jibel can't get behaviour post install on his hardware (partition map table) [14:07] 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] skaet: as we have only one test on ppc, and it's failed, ok with not releasing [14:12] jibel, ubuntu core (armel + armhf) - who's testing? any results? [14:13] 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] Did you have the same problem (or know whether you did) with previous versions? [14:14] i.e. is this a regression? [14:16] hmm, wondering if "disabled" would be better than "marked for re-build" === bladernr_afk is now known as bladernr_ [14:17] superm1 - not seeing any testing on the Mythbuntu images, any testing going to happen in next couple of hours? [14:17] utlemming, how do the cloud images look? [14:17] * skaet not seeing them on the tracker. [14:18] ogra_, infinity, any testing of the ac100 or mx5 images? [14:19] i tested yesterday [14:19] ogra_, sorry - misread a line. [14:19] appologies. [14:19] and noted it on the tracker [14:19] ah, k [14:19] infinity wanted to do mx5 [14:20] thanks ogra_ [14:20] skaet: the wallpapers have finally turned up. Should I play with the compression and rush them up for tonight, or hang back? [14:20] sladen, play with compression and aim for tonight's build. [14:21] skaet: (and yes, still waiting on Otto to upload the default wallpaper, but it has now been decided) [14:21] skaet: okay-dokey [14:23] 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] skaet: the cloud images look fine [14:24] skaet: I did ask last night to have them added to the tracker [14:24] so....can I have http://cloud-images.ubuntu.com/precise/20120328/ added to the tracker? [14:25] utlemming: yep, doing that now [14:25] stgraber: thank you kindly :) [14:26] cjwatson, I don't know, it is a new machine and 1rst time ubuntu is installed on it [14:26] utlemming: done [14:27] stgraber: much obligded [14:28] thanks utlemming [14:30] 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] cjwatson, ok, will do. [14:32] 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] Riddell, ScottK - not seeing much testing on your images in the history or current. Are they safe to release? [14:42] s/your/Kubuntu/ [14:42] skaet: yes I'm behind in updating the iso tracker [14:42] but no problems so far [14:43] skaet: any relase time in mind? [14:43] Riddell, ok, please update the tracker. [14:43] Riddell, soon as all the data is gathered, so we know what's safe to ship. :) [14:43] (yes, you're on critical path right now ;) ) [14:43] 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] ok I need to get back to a real computer to update the tracker this one is too fiddly for that [14:45] 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] 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] 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] skaet: ack'd [14:50] 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] scott-work, :) that should work. [14:50] 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] 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] skaet: as cjwatson says, this may be a definition of "corruption" that only applies to the OS X partitioning tools [14:52] i.e., no runtime impact and no risk of data loss [14:53] 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] 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] am seriously on the fence on this one. waiting more data. [15:07] Daviey, TechnicalOverview - server's still looking a bit bare on content, ETA for additions? [15:17] skaet: That was all i was going to ship TBH, but i can elaborate [15:23] skaet: cloud images are good to go [15:25] thanks utlemming [15:28] 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] skaet: do you want to wait with the publishing of the images still, or should we go ahead with this now? [15:28] skaet: also, WDYT about lifting the freeze now? [15:28] cjwatson: did you already run cron.src? if not, I can start it now [15:30] then I wiped Ubuntu partitions with MacOS tools and everything seems to be working correctly [15:30] jibel: identical parameters for the partitioning at every stage? [15:31] (bearing in mind that if there /is/ a bug, it might be related to precise partition sizes / offsets...) [15:31] 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] pitti: oh, no, I didn't, please do [15:32] kubuntu is just short of wubi testers [15:32] pitti, so am fine about lifting freeze. Just don't know which image we'll ship. [15:32] skaet: "which image"? [15:33] cjwatson: running [15:33] ubuntu core armhf and armel - no results on tracker (current or history) [15:33] skaet: I pre-published the current ubuntu desktop/alternates/servers this morning [15:33] ah [15:33] these don't get pre-published, so *phew* [15:33] * ogra_ votes for an image of a kitten [15:33] they always get good reception [15:33] :P [15:34] 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] ogra_, hmm, don't want to be refered to as a kitten killers please. ;) [15:36] hmm, any of my recent changes ought to have been entirely deterministic [15:38] jibel, was that on oneiric then? so we have a regression? or on precise (and hence good to ship). [15:39] skaet, on Precise [15:39] cjwatson: any reservations about lifting freeze now? [15:40] pitti, OEM has taken their snapshot as well, so they're fine with opening it. [15:40] pitti: I'm fine with it [15:40] ok, doing then [15:40] so -proposed will shut again for a bit ;-) [15:40] :) [15:40] however my branch to open it all the time is approved === Ursinha_ is now known as Guest92471 [15:41] skaet: checking with team what's up with the testing situation [15:43] thanks superm1 [15:46] 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] skaet: err, too late, I'm afraid; that's what I just asked about? [15:47] pitti, I though you were asking about letting the packages that had built up get added in. [15:47] sorry [15:47] skaet: well, both really [15:47] skaet: we can certainly ask IS to freeze it again, but do we really want to review everythign for a whole month? [15:48] pitti, given its an LTS, and there's some area of high churn, it seems prudent. [15:48] I'll also copy the installable bits from -proposed [15:48] we used to freeze for release at RC freeze [15:49] Laney, in Oneiric we just left it freeze. [15:49] after Beta 2 [15:49] ScottK, ^ thoughts? [15:50] i.e. two weeks before release [15:50] I also copy the installable bits from -proposed to release [15:50] two weeks seems a sensible time for final freeze, but isn't that scheduled? [15:51]