| === ysnoi is now known as TheYsNoi | ||
| Riddell | what does "Run Once" mean for test cases on iso.qa.u.c? | 01:08 |
|---|---|---|
| slangasek | Riddell: that the test case needs to be done once for all images, instead of once per image | 01:35 |
| cjwatson | [5~/wg 44 | 01:44 |
| cjwatson | sigh | 01:44 |
| GrueMaster | One more image to test and I can hit the pub. | 02:35 |
| micahg | slangasek: I assume disabling the publisher for hours at a time before alpha2 is released would be a bad thing? | 06:11 |
| pitti | micahg: is "hours" more like two or 12? | 06:57 |
| pitti | micahg: two hours sohuld be bearable if it's urgent | 06:57 |
| pitti | but not much more | 06:57 |
| micahg | pitti: 2-3 per release (this is for the Firefox migration to -security) | 06:58 |
| micahg | releases == lucid,maverick | 06:58 |
| pitti | wow, copying packages takes that long? | 06:58 |
| micahg | yeah, I think it took 3 hrs per release from -proposed to -updates | 06:59 |
| pitti | I think that mostly was because jdstrand used copy-package.py for the gazillion langpacks, wasn't it? | 06:59 |
| micahg | is that not the right way? | 06:59 |
| pitti | it works, but is utterly slow | 06:59 |
| pitti | using our sru-release --pattern lucid --security language-pack script, it's a matter of 15 minutes or so | 07:00 |
| micahg | pitti: ah, could you please document that on the archive admin page, that's what we were trying to use | 07:00 |
| micahg | https://wiki.ubuntu.com/ArchiveAdministration#langpack_SRUs | 07:01 |
| * micahg probably won't be ready until after release in any event though | 07:01 | |
| pitti | urgh yes, that is a bit obsolete | 07:01 |
| pitti | also https://wiki.ubuntu.com/ArchiveAdministration#Standard_case | 07:02 |
| pitti | will update | 07:02 |
| micahg | thanks | 07:02 |
| micahg | ok, so, it should be <30 minutes per release then, perfect, if I'm ready before alpha2, I'll come ask in here | 07:03 |
| pitti | micahg: ArchiveAdmin page updated | 07:17 |
| micahg | pitti: thanks | 07:18 |
| === warp11 is now known as warp10 | ||
| === doko_ is now known as doko | ||
| mvo | is vmware-view-client waiting for approval in the precise-partner queue ? and if so, could someone have a look please :) | 08:27 |
| === jodh is now known as jhunt | ||
| pitti | mvo: I don't see it in new or unapproved | 09:01 |
| mvo | odd, I reupload | 09:02 |
| mvo | thanks | 09:03 |
| * cjwatson investigates lubuntu having ended up with unity-greeter | 13:24 | |
| ogra_ | wasnt there a bug about that that was fixed ? | 13:33 |
| cjwatson | not so you'd notice in the current images. | 13:34 |
| cjwatson | bug 918401 and bug 925358 | 13:35 |
| ubot4 | Launchpad bug 918401 in unity-greeter (Ubuntu) (and 1 other project) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 8) (dups: 1) (heat: 50)" [Undecided,Confirmed] https://launchpad.net/bugs/918401 | 13:35 |
| ubot4 | Launchpad bug 925358 in casper (Ubuntu) "Lubuntu Precise live CD boots to a Unity-like DE (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/925358 | 13:35 |
| cjwatson | but germinate output looks right; trying a local livecd-rootfs build | 13:37 |
| ogra_ | jibel, hey, when you get Bug 924993, do you actually get a keyboard selection dialog ? i wonder if these two issues i see are related (and if its probably only an oem-config vs ubiquity thing) | 13:38 |
| ubot4 | Launchpad bug 924993 in ubiquity (Ubuntu) "wireless password field disabled when user selects a protected network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924993 | 13:38 |
| ogra_ | i use oem-config here, see the same behavior but somehow the keyboard selection is supressed in that scenario ... while on systems without wlan the kbd selection shows up | 13:39 |
| jibel | ogra_, I do, everything works as expected apart from this password field that should be enabled. | 13:39 |
| ogra_ | ok | 13:39 |
| ogra_ | then it might be arm or oem-config specific | 13:39 |
| ogra_ | though arm is unlikel else kbd selection wouldnt be shown on the pandaboards | 13:40 |
| * ogra_ wonders wh his Y ke onl works ever 5th press | 13:40 | |
| jdstrand | pitti: re sru-release> the name implies it can only be used for -proposed to -updates. I see now there is a --security arg to go to -security. looking at the --help, I wonder about -updates to -security for the times that things might already be out of -proposed | 13:51 |
| pitti | jdstrand: I could add a --security-only for this occasion, it's easy to do | 13:51 |
| pitti | jdstrand: the packages are still in -proposed, so copying from -proposed to -security will be fine | 13:52 |
| pitti | jdstrand: you could use -s as-is, then it would copy to -updates again, plus -security | 13:52 |
| pitti | it's just a waste of half the time | 13:52 |
| pitti | but it might eventually come in handy for other occasions like firefox | 13:52 |
| jdstrand | well, since we run copy-report automatically, I don't really see why we would want --security-only at this time | 13:53 |
| jdstrand | it was more just the case of 'if the packages were deleted from -proposed already, but still in -updates' | 13:53 |
| jdstrand | I admit I don't know when things get deleted from -proposed | 13:54 |
| cjwatson | whenever we c/p the lines from the pending-sru page | 13:55 |
| cjwatson | which appear once they're in -updates | 13:55 |
| pitti | right, the report just doesn't cover langpacks, as it filters them out except for -en as a representative | 13:57 |
| pitti | as the validation process is different, and it would clutter up the page too uch | 13:57 |
| pitti | so in practice they stay in -proposed all the time | 13:57 |
| jdstrand | well, language-pack-en shows it is no longer in -proposed, but language-pack-es is | 13:58 |
| jdstrand | this was more curiosity anyway. I don't know if we will have another new set of langpacks for firefox 10 | 14:00 |
| pitti | jdstrand: right, -en might have been cleaned up already, so we need to copy that manually | 14:02 |
| pitti | but all the other n-hundred can be done with the script | 14:02 |
| pitti | jdstrand: no, we won't | 14:02 |
| pitti | jdstrand: this was an one-time change for 3.6->9 | 14:03 |
| jdstrand | pitti: ah great! thanks for your time :) | 14:04 |
| pitti | jdstrand: so, for this one time I'd just locally comment out the copying to -updates, that's easiest :) | 14:04 |
| * jdstrand makes a note | 14:04 | |
| pitti | wrt. alpha-2, I suppose there's still a potential lubuntu rebuild? | 14:04 |
| pitti | (as for freeze lifting) | 14:05 |
| Riddell | slangasek: for Kubuntu these images should be included in alpha 2: i386 and amd64 alternate, desktop and dvd | 14:07 |
| cjwatson | I think I've figured out the Lubuntu problem | 14:08 |
| cjwatson | it'll be a livecd-rootfs upload, build/publisher cycle, rebuild images | 14:09 |
| superm1 | skaet wanted me to mention we are planning a2 for mythbuntu | 14:09 |
| cjwatson | how are your tests looking? | 14:10 |
| superm1 | last tests were a week ago, so i'm going to try to drum up the team to test candidates today | 14:10 |
| cjwatson | right, this looks a few orders of magnitude more sensible. | 14:13 |
| skaet | cjwatson, go ahead and start on the upload and build for Lubuntu please. We'll wait until gilir's online to decide to retest/not. | 14:14 |
| skaet | Last I hear from him, was that he was ok with alternates going out, but not the livecd's. | 14:14 |
| cjwatson | the current desktop images are definitely unreleaseable by any reasonable metric. | 14:15 |
| cjwatson | (lubuntu I mean) | 14:15 |
| cjwatson | they simply aren't as specified | 14:15 |
| cjwatson | this should cut their size down a fair bit too ... | 14:17 |
| * skaet nods | 14:18 | |
| * skaet figures its time for all images to go on a bit of a diet as well... after A2 ;) | 14:19 | |
| cjwatson | feel free to make suggestions ;) | 14:19 |
| pitti | we have some overhead due to non-empty langpack updates | 14:19 |
| pitti | and ubuntuone bits need to be fixed to stop using gtk 2 and webkit (underway, AFAIUI) | 14:20 |
| pitti | then we can drop the old webkit gtk2 bits, some 8 MB | 14:20 |
| pitti | I did a size analysis recently, the biggest offenders were firefox/thunderbird (+2.6 MB each), new LibO (~ 1.5 MB), and of course python3 (~ +6 MB) | 14:20 |
| stgraber | skaet: I prepended the resolvconf issue to the list of known issues as I'm expecting quite a lot of users to hit that one | 14:22 |
| stgraber | skaet: looking at Edubuntu now | 14:22 |
| skaet | thanks pitti. :) | 14:23 |
| skaet | stgraber, thanks! Yes, anyone who knows of issues that are likely to be hit, please review the TechnicalOverview and add them. | 14:23 |
| cjwatson | hmm, but isn't the resulting Lubuntu system going to need to have recommends disabled too ... | 14:28 |
| cjwatson | grah, this is annoyingly complex | 14:28 |
| seb128 | pitti, webkit-gtk2 ... isn't that still used by ubuntuone-control-panel? | 14:28 |
| seb128 | pitti, and gwibber | 14:29 |
| pitti | seb128: yes, but I thought ubuntuone stuff would be moved to GTK3 (sso-client) and PyQt (control-panel) | 14:29 |
| pitti | seb128: ah, gwibber, too, I thought ken was working on it | 14:29 |
| seb128 | pitti, I'm not sure the pyqt stuff is going to happen this cycle | 14:29 |
| pitti | now that we have gnome-keyring GIR bindings | 14:29 |
| seb128 | but let's see | 14:29 |
| seb128 | pitti, he is, that didn't land yet either though ;-) | 14:30 |
| * slangasek waves morning-like | 14:30 | |
| pitti | anyway, it's the best thing we have right now wrt. size reduction | 14:30 |
| seb128 | slangasek, hey | 14:30 |
| pitti | slangasek: good morning | 14:30 |
| skaet | slangasek, good morning. grab the coffee. ;) | 14:31 |
| slangasek | Riddell: so you specifically don't want the amd64+mac and powerpc images published with the alpha? | 14:35 |
| cjwatson | I think the Lubuntu alternate CDs should be respun. Explanation in bug 918401 comment 32. | 14:35 |
| ubot4 | Launchpad bug 918401 in unity-greeter (Ubuntu) (and 2 other projects) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 9) (dups: 2) (heat: 58)" [Undecided,Confirmed] https://launchpad.net/bugs/918401 | 14:35 |
| stgraber | skaet: the Edubuntu technical overview is a bit long, unfortunately it looks like most of our changes happened between alpha-1 and alpha-2 ;) (alpha-1 was roughly identical to Oneiric) | 14:36 |
| stgraber | skaet: I'm now just waiting for highvoltage to do a final review so it may still grow or shrink a bit :) | 14:36 |
| cjwatson | I am fairly sure we'll need a new ubiquity if we want Lubuntu desktop to be suitable for Alpha 2. | 14:36 |
| skaet | stgraber, that's fine. Thanks! | 14:37 |
| Riddell | slangasek: they are untested, you can if users are clear of that | 14:37 |
| cjwatson | At which point I might as well include last night's marathon NTFS installation fix there as well. | 14:38 |
| skaet | slangasek, Riddell, if they are untested, they shouldn't go out. | 14:38 |
| Riddell | right | 14:39 |
| cjwatson | Any opinions on a new ubiquity just for Lubuntu? | 14:42 |
| cjwatson | I'm preparing it now anyway | 14:42 |
| cjwatson | IWBNI a Lubuntu developer were around here ... | 14:43 |
| skaet | cjwatson, given the complexity I suspect its unlikely we'll get a home run and it all work, however they're changes that are needed, so if they don't end up in A2, getting them in the dailies tomorrow is good. | 14:44 |
| cjwatson | Are all the other images golden at this point? | 14:44 |
| cjwatson | I agree it will be a slight fluke if they all work; however if everything else is good (at least for desktop) then going ahead with a ubiquity upload probably wouldn't hurt | 14:45 |
| skaet | cjwatson, I haven't heard any other show stoppers - so all the ones that are tested are likelies at this point. | 14:45 |
| cjwatson | The partman-auto change technically affects non-desktops although I seriously doubt anyone would notice | 14:46 |
| cjwatson | OK, so how about I go ahead and if it fails we just drop Lubuntu desktop from A2 (or attempt to release it tomorrow or something) | 14:47 |
| skaet | cjwatson, sounds good. | 14:47 |
| cjwatson | I don't see obvious drawbacks | 14:48 |
| cjwatson | OK | 14:48 |
| highvoltage | stgraber: looks good! | 14:50 |
| slangasek | ok, can someone tell me what ~/.isotracker.conf should look like? :) | 14:54 |
| cjwatson | you could grab nusakan's | 14:54 |
| cjwatson | though that'll have you pretending to be ubuntu-cdimage | 14:54 |
| slangasek | what password is it wanting? Hopefully not the SSO password? | 14:56 |
| slangasek | anyway, this is for publish-image-set, so pretending is probably fine | 14:56 |
| cjwatson | it's its own API key | 14:57 |
| slangasek | hum, getting an error: | 14:57 |
| slangasek | ERROR: Cannot handle product Ubuntu Server EC2 EBS (Asia-Pacific-NorthEast) amd64 | 14:57 |
| slangasek | ... but that should match the 'ignore' regexp that I see in here | 14:58 |
| slangasek | ignore_product_re = re.compile('Netboot |Upgrade |Server EC2|line-through') | 14:58 |
| cjwatson | looks like a space, quacks like a space, isn't actually a space, maybe? | 14:59 |
| cjwatson | ok, new ubiquity on its way | 14:59 |
| cjwatson | oh, it's using .match not .search | 15:00 |
| cjwatson | slangasek: update and try again | 15:01 |
| cjwatson | heh, now it dislikes uwbi | 15:01 |
| cjwatson | *wubi | 15:01 |
| slangasek | well, progress :) | 15:02 |
| cjwatson | which to be fair it probably can't actually handle - I don't know that there's any non-manual release handling for wubi yet | 15:02 |
| * slangasek nods | 15:02 | |
| cjwatson | I've added that to the ignore regex for now | 15:03 |
| slangasek | thanks | 15:03 |
| cjwatson | it produces sensible output now | 15:03 |
| cjwatson | well, output | 15:03 |
| slangasek | :-) | 15:03 |
| cjwatson | sense is your problem | 15:03 |
| cjwatson | surprising that I'm not seeing amd64+mac anywhere in the output | 15:04 |
| slangasek | possibly a missing $ on the amd64 variant | 15:06 |
| slangasek | testing | 15:06 |
| slangasek | yep | 15:06 |
| slangasek | fix pushed | 15:07 |
| cjwatson | yeah, I was just getting there :) | 15:07 |
| cjwatson | ta | 15:07 |
| slangasek | so to mark things as not-for-publishing, do we have a better mechanism than disabling them on the tracker? | 15:07 |
| cjwatson | ah yes, broken since r320 | 15:09 |
| * cjwatson satisfies curiosity | 15:09 | |
| cjwatson | r330 fixed it for armel+* but not amd64+* | 15:10 |
| cjwatson | slangasek: not AFAIK; I think I've just manually filtered them out of the publish-image-set output when I've done this | 15:10 |
| cjwatson | oh, we should do a source build | 15:11 |
| * cjwatson goes to poke that | 15:11 | |
| skaet | slangasek, I'm not seeing any of the amd64+mac images with testing on them, so they shouldn't be going out with A2. | 15:17 |
| skaet | (nor the powerpc ones) | 15:17 |
| cjwatson | I've been making some progress on scaring up powerpc testers and reminding them that they actually need to do it, but it was only a couple of days ago so they may not have got organised in time | 15:18 |
| skaet | do you want me to just go in and disable the definite "no go"s? | 15:18 |
| skaet | cjwatson, thanks. :) I've also been talking to IBM (Linux manager at LCA and he was receptive to the notion of getting some of his folks lined up to help) but it needs to be followed up on too. | 15:19 |
| slangasek | skaet: does disabling them prevent people from posting tests of them? | 15:29 |
| slangasek | I think disabling them on the tracker is probably still best if we're pretty sure we're not publishing them, but it does mean it'd be nice to have a better way for the tool to decide what to publish | 15:29 |
| skaet | slangasek, yes, but if there are no tests posted at this point, its unlikely we'll be getting any before we release. | 15:29 |
| skaet | slangasek, yes that would be good. Maybe we can brainstorm with stgraber about it after A2 is out. (publish ticky box?) | 15:31 |
| slangasek | or the tool could embed the policy directly about what's publishable or not based on testedness | 15:31 |
| stgraber | skaet: we could indeed create an extra build status for "ready" (trying to find a term that works for hardware testing and package testing too ;)) | 15:32 |
| stgraber | slangasek: the data actually is available in the API, so I could give a script using our criteria and returning the list | 15:32 |
| skaet | embedding the policy would be nice, but it needs to be transparent on the ship/not - maybe a color change when the testing results are satisfied to indicate its now possible to ship? | 15:36 |
| slangasek | well, that implies embedding the policy in *two* places, one of which the release engineer can't edit ;) | 15:38 |
| stgraber | right, if we want it visible on the website, we'd need a few extra tricks. Otherwise I'd simply make a python script using the API and put it in ubuntu-archive-tools (well, likely just update publish-image-set.py) | 15:41 |
| stgraber | so if someone wants to change the policy, it's just a matter of changing the script | 15:42 |
| stgraber | what I could do though is have the "ready" status visible on the website, have publish-image-set.py first apply the policy to the tracker and then show the list of what's ready to be published | 15:43 |
| skaet | just having the ready status visible on the website was what I was looking for. :) | 15:44 |
| stgraber | that'd allow for manual overrides on the tracker by manuall marking stuff as ready and still have the script apply the policy automatically for the rest | 15:44 |
| stgraber | then show the final list | 15:44 |
| * skaet nods | 15:44 | |
| skaet | slangasek, what are the key bugs right now preventing upgrading from 10.04 to 12.04? I'd like to add them to the release notes. | 15:46 |
| stgraber | skaet: so what's the current policy exactly? we clearly don't publish anything that wasn't tested at all but do we care about the actual test results? (like not publish anything that's not fully tested or not publish something that has all its results marked as failed, ...) | 15:46 |
| skaet | stgraber, we need to refine the policies and make them visible - some parts are grey right now, and it would be good to get the expectations nice and uniform. | 15:48 |
| cjwatson | skaet: bug 917173 and bug 922485 come to mind (fixed in precise but not yet successfully backported) | 15:48 |
| ubot4 | Launchpad bug 917173 in apt (Debian) (and 12 other projects) "lucid -> precise upgrade failed: Resolver failed to calculate the upgrade - dpkg-dev held back (affects: 1) (heat: 10)" [Unknown,New] https://launchpad.net/bugs/917173 | 15:48 |
| ubot4 | Launchpad bug 922485 in apt (Debian) (and 12 other projects) "Lucid Desktop i386 failed to calculate the upgrade to Precise (affects: 1) (dups: 1) (heat: 16)" [Unknown,New] https://launchpad.net/bugs/922485 | 15:48 |
| skaet | thanks cjwatson | 15:48 |
| * skaet adding them now. | 15:48 | |
| cjwatson | skaet: the bugs at this point are IMO sufficiently early in the process that we do not have a good overview of problems | 15:49 |
| cjwatson | I was trying to figure out why the backports failed to verify but was derailed by a2 stuff | 15:49 |
| skaet | cjwatson, fair enough. :) expect we'll be figuring out a lot of this over next month. | 15:50 |
| slangasek | skaet: right, the ones cjwatson listed. Although, does listing LTS upgrade bugs set an unreasonable expectation for people that a 10.04->12.04 upgrade is a reasonable thing for mortals to do? :) | 15:53 |
| skaet | slangasek, "Upgrading from 10.04 to 12.04 still has some known issues and is not recommended at this time." - just wanted to provide some examples ;) | 15:53 |
| slangasek | right-o :) | 15:53 |
| slangasek | skaet: as for policy on publishing... I guess I would say anything that's untested, or anything that's been tested but had only failures, should not be published, and anything else is a question of human judgement? | 15:55 |
| slangasek | i.e., if there's a reason we're choosing not to publish an image that *has* been successfully tested, we could still indicate that manually | 15:55 |
| skaet | slangasek, yes it does seem to boil down to that. How about I start a wiki page off after we get A2 out, and we'll get the rest of the release team's input. | 15:56 |
| skaet | then we can all have the same expectations on release day ;) | 15:57 |
| slangasek | sounds good | 16:00 |
| cjwatson | the good bit about testing upgrades is that you have plenty of opportunities for coffee breaks. | 16:00 |
| cjwatson | rebuilding Lubuntu desktop with fingers crossed | 16:13 |
| * skaet crosses fingers | 16:14 | |
| stgraber | skaet, slangasek: Using http://paste.ubuntu.com/826568/ gives me http://paste.ubuntu.com/826569/ (though iterating through everything takes almost a minute ... so custom status would be nice to avoid that, then just products.get_list and builds.get_list would be required) | 16:32 |
| stgraber | so that's everything that's currently active on the tracker (status = 0) and with at least one mandatory testcase marked as passed | 16:33 |
| skaet | stgraber, it should actually be all mandatory testcases marked as passed.... else they shouldn't be mandatory. | 16:35 |
| skaet | but its a judgement thing, depending where in the release cycle we are. | 16:36 |
| skaet | stgraber, http://paste.ubuntu.com/826569/ looks good though. :) | 16:37 |
| stgraber | skaet: indeed, we definitely want all the mandatory passed at least once for final, all the run-once also passed at least once and we can probably ignore the optionals (or only consider failures?) | 16:38 |
| stgraber | skaet: anyway, writting down the policy will help quite a bit ;) | 16:38 |
| slangasek | skaet: but late in the cycle, those also typically gate whether we're ready to publish, rather than just whether a particular image should be published | 16:38 |
| slangasek | so I think having the tool just block untested and completely-failed images gets us to the right place as far as automation | 16:39 |
| skaet | slangasek, stgraber - fair enough. Will work on writing it up tomorrow, and see if we can get it discussed next week. I'll try to add a dimension for Alpha, Beta, Final criteria - so we're clearer. | 16:40 |
| slangasek | hmm, are Ubuntu Studio considered publish-ready? | 18:06 |
| slangasek | apparently there are no successful ubiquity installs, just a bunch of failures | 18:07 |
| slangasek | skaet: ^^ I'm holding off on ubuntustudio for now given the above | 18:12 |
| skaet | slangasek, ack | 18:17 |
| skaet | scott-work, ^ any data that isn't in the tracker? | 18:17 |
| seb128 | slangasek, skaet: is there any plan to unfreeze today? | 18:21 |
| slangasek | I think we should be unfreezing at this point; skaet? | 18:21 |
| seb128 | just trying to schedule my end or day and friday | 18:21 |
| seb128 | or->of | 18:21 |
| scott-work | slangasek: skaet: i believe there were successful installs - there were cases of ubiquity failing but also lightdm not properly configured which may have been construed as "ubiquity failuers" | 18:21 |
| slangasek | scott-work: well, the only people who've posted test results on the tracker marked their tests as failed | 18:22 |
| cjwatson | Lubuntu desktop looks better to me now | 18:23 |
| cjwatson | at least gives me a working desktop, haven't tried an install | 18:23 |
| scott-work | slangasek: it may be better to not publish for A2 then | 18:24 |
| slangasek | scott-work: ok | 18:25 |
| skaet | thanks cjwatson, was wanting to hear how it looked before unfreezing. No results in from any of the lubuntu folk though yet, but at this point, not seeing much upside in keeping it frozen. | 18:25 |
| skaet | scott-work, I'll comment out the ubuntu-studio comments from the technical overview then as well. | 18:25 |
| slangasek | cjwatson: evidently the rules on #ubuntu-devel /topic handling have changed since last I needed to set one; can't set it directly, chanserv won't set it for me? | 18:31 |
| cjwatson | you have +t, you should be able to use /msg chanserv topic | 18:32 |
| * cjwatson tries to find what the channel mode used to be | 18:33 | |
| slangasek | yeah, chanserv didn't like me | 18:35 |
| slangasek | man | 18:36 |
| slangasek | can't set the channel here either | 18:36 |
| === slangasek changed the topic of #ubuntu-release to: Alpha 2 testing in progress: Archive:open | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis | ||
| davmor2 | slangasek: you just weren't hitting it hard enough :) | 18:36 |
| cjwatson | hm, you know, sod it, +t isn't mlocked on -devel afaics | 18:37 |
| scott-work | slangasek: skaet: sorry for dropping the ball on A2, i will be more prepared in the future | 18:49 |
| stgraber | slangasek: do we want to wait a bit longer for the resolvconf upload or should I go ahead and upload it nowish? (thanks for the postrm fix btw) | 18:55 |
| slangasek | scott-work: no skin off my nose... :) | 18:55 |
| slangasek | stgraber: I'm fine with you uploading it now | 18:55 |
| stgraber | slangasek: good. Will do a couple more tests on it and then upload, should definitely be in the archive in time for the Edubuntu daily (assuming they've been switched back on) | 18:56 |
| slangasek | they haven't been just yet | 18:59 |
| slangasek | who usually handles the cloud image publishing? | 19:01 |
| utlemming | slangesek: that's me | 19:01 |
| slangasek | utlemming: ah, hi :) | 19:01 |
| slangasek | utlemming: is there anything else pending from your POV before those can be published? | 19:01 |
| slangasek | looks like the testing is done | 19:01 |
| slangasek | and we're pushing out the ISOs, so I guess it's time for the cloud images to go out also? | 19:02 |
| utlemming | slangesek: no, we're good to go, just waiting for the go-ahead to publish them | 19:02 |
| Riddell | slangasek: announcing the release sometime soon? | 19:02 |
| slangasek | utlemming: go ahead then :) | 19:02 |
| utlemming | slangasek: publishing now | 19:03 |
| slangasek | Riddell: well, skaet will be | 19:03 |
| Riddell | I'm away for a few hours, I'll tell my kubuntu people to watch and put on the website when they see it | 19:03 |
| skaet | Riddell, sounds good. want me to post in the #kubuntu-devel channel, or will someone monitor here? | 19:04 |
| Riddell | skaet: that would be good yes | 19:04 |
| utlemming | cloud-images for Alpha2 are now public | 19:08 |
| skaet | utlemming, yup, able to see them now. :) | 19:17 |
| === skaet changed the topic of #ubuntu-release to: Alpha 2 released! Archive:open | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis | ||
| skaet | Looks like we're all nicely released now for A2. Thanks slangasek! | 21:03 |
| highvoltage | :) | 21:45 |
| balloons | gratz everyone! | 21:48 |
| === bladernr_ is now known as bladernr_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!