=== maxb_ is now known as maxb === jodh is now known as jhunt === doko_ is now known as doko [11:56] cjwatson: I've submitted a sync-request for autotools-dev (https://bugs.launchpad.net/ubuntu/+source/autotools-dev/+bug/932668), as it would be really great for people to be able to build packages and software for ARMv8 in Precise. I'm not sure what turnaround time on sponsorship usually is, but given the proximity to the FeatureFreeze I thought I'd check that there isn't anything else I should do... [11:58] for syncs, we take into account the date of filing [12:00] but sure, I'll sort this out, thanks [12:08] cjwatson: awesome, thanks :) [12:17] jaustin: done [12:20] cjwatson: thanks again :) === Ursinha_ is now known as Guest37786 === Guest37786 is now known as Ursula === bladernr_ is now known as bladernr_afk [14:29] Daviey, skaet: 10.04.4 mumbling now? === bladernr_afk is now known as bladernr_ [14:31] skaet: https://jenkins.qa.ubuntu.com/view/Lucid%20ISO%20Testing%20Dashboard/ [14:31] pitti, yup. Daviey - we're in desktop. [14:35] http://iso.qa.ubuntu.com/qatracker/milestones/207/builds [14:35] pitti, Daveiy ^ [15:02] Daviey: so, this is cdimage/www/simple/.manifest [15:02] and apparently someone forgot to restore .manifest.full last time [15:02] * pitti does now [15:04] at least I think that's right [15:04] cjwatson: ^ please confirm? [15:05] cjwatson: .manifest only has oneiric, .manifest.full has everything; I think at this point .manifest should have everything, right? [15:05] and we'll prune it for 10.04.4 [15:05] pitti: thanks [15:05] Daviey: ^ anyway, that's the file you need to prune [15:05] Daviey: but don't do it right now, as .manifest is already trimmed; please keep .manifest.full around [15:05] * pitti isn't 100% sure how this works either [15:05] it's black magic :) [15:07] the point of trimming down .manifest is so that the mirror prober can run more quickly and tell us about only the release currently under consideration [15:08] cjwatson: right; but it shouldn't stay trimmed permanently, should it? [15:08] outside release mirroring periods, .manifest should generally have everything, yes [15:09] Daviey: ok, .manifest restored; now the instructions will work [15:09] cjwatson: thanks for confirming [15:13] np [15:30] skaet, FF tomorrow 9pm UTC as usual? [15:40] ara, yes. [15:44] skaet, ta [16:50] rbasak, was brian going to check whether calxenda needed the entire distro switch to openmpi 1.5 or do they just need GA of that package? [16:51] doh! wrong channel [17:41] hey [17:41] skaet, slangasek, others: when does the feature freeze start? [17:42] was there any email sent reminding of that? [17:42] cjwatson said 2100 tomorrow, but I don't know where that number came from [17:42] we are unsure if it's tomorrow 0utc or 21utc, different people know differently [17:42] that's very confusing ;-) [17:42] seb128, 2100 UTC [17:42] slangasek, I though you told me previous cycle that freezes were always at 0utc, my bad [17:43] well, previously they were... new RM, new rules, I think :) [17:43] skaet, thanks, would still be useful to send a remainder email with the hour to ubuntu-devel-announce maybe? [17:45] slangasek: it's what https://wiki.ubuntu.com/PrecisePangolin/FeatureLanding sayd [17:45] *says [17:46] oh :-) [17:53] it's also what the release schedule says although hidden at the top [18:03] seb128, I'll send one out at 2100 UTC today ;) saying less than 24 hours. We kept on not holding to the 0000 UTC, and 2100 seemed to work fairly well, so are standardizing on that. [18:04] skaet, great, I got bitten in the past the other way around, thinking it was thursday end of day and slangasek who told me it was 0utc ;-) [18:04] but good to know we still have a day [18:05] if folks have something that is landing late, that might impact other teams, would be good if they could put it on https://wiki.ubuntu.com/PrecisePangolin/FeatureLanding [18:06] I may be asking some teams to explicitly hold off for a day or two, and stagger some of the high interacting ones in, so we can try to keep the images work. [18:06] new process this time around, trying it out. [18:06] I'll mention this in the email to ubuntu-devel-announce, as well. [18:09] skaet: added LTSP 5.3 to that list, it'll most likely release upstream a few hours before FF and be uploaded a few minutes before FF [18:10] skaet: it's still undergoing work upstream and is being tested by quite a lot of people using PPA builds on Edubuntu, Ubuntu and Debian systems. (5.3 is a major LTSP release, we've been on 5.2 since 10.04) [18:12] stgraber, Thanks! I may request you hold off on the FF upload for a day or two of that so it doesn't get caught up with the churn from other packages. Would you be ok with that? [18:14] skaet: timing question for you.... if I want to take about a 2-3 hour maint window about noon tomorrow that will reduce your arm builder count significantly while I bring up the replacement pandas. [18:15] noon london, that is [18:15] skaet: yeah, that'd work, though I'm not sure what we'd be avoiding doing it. LTSP is a fairly self contained feature, so our worst case scenario is either "LTSP won't install" or "LTSP won't boot", I don't see any way where LTSP could break anything in a default install or in the archive. [18:16] skaet: the only dependency changes we'll be doing (that could be problematic as LTSP is in main) is switching from some older font packages to the new ones (following changes in Ubuntu desktop) and switching from rdesktop to freerdp-x11 (same as done on the desktop so we can get rid of rdesktop eventually) [18:17] stgraber, ok, then please hold to FF. :) [18:17] skaet: ok :) [18:18] lamont, should not affect 10.04.4 since its not an arm release; however we've got feature freeze tomorrow - so the builders are being pounded on. [18:18] (I know, one shouldn't complain about getting a few extra days for feature work, but I'm planning on being done with all the feature stuff for 12.04 on Friday ;)) [18:18] skaet: atm, arm* seem to be all precise rebuild test [18:19] lamont, yeah, FF is tomorrow [18:19] specifically armhf/precise. armel is where you'll lose the builders - kitalpha and satinash will remain, and are fast. we can shuffle some from armhf to armel if there's a need for more width [18:19] lamont, can you delay for 24 hours, I suspect loosing the builders before the FF will get some folks grumpy. [18:20] they'll come back roughly 3x faster [18:20] hence the tradeoff [18:20] ogra_, infinity, ^^ I'm ok if you are? [18:20] infinity: you want your pandas while you sleep tomorrow morning? [18:22] skaet: I'll touch base with infinity today sometime - he's the one that's been pushing to get these done NAO NAO NAO this past week, so I expect he's +1 [18:22] and tghanks [18:22] s/g// [18:22] lamont, thanks for letting me know about it too. :) [18:51] * ogra_ reads backlog ... [18:52] lamont, go for it, i dont think we have anything specifically urgent to build atm [18:53] skaet, ^^ [18:56] ta [18:58] skaet: lamont: loosing armel builders isn't a great loss since we're not doing anything sensitive with that archive ATM [18:59] NCommand1r, ots about arm* not just armel [18:59] eek [18:59] when didI become 1r [19:00] the only thing major coming down the pipe thats time sensitive is a d-i upload, and I can dorescore magic tokeep things running === NCommand1r is now known as NCommander [19:03] ogra_: well... if nothing is queued on armel, it's not much about armhf at all [19:03] k [19:03] armhf/non-virt has no bbg3s atm === apachelogger_ is now known as apachelogger [19:14] cjwatson: i wasn't aware that syncs filed before FF were still good to go through without FFe, and i suspect plenty of other people aren't too. is there a list somewhere of what does/doesn't have to be done before FF to be ok? [19:14] it might be nice to send that out before someone goes and marks everything in the sponsorship queue as needing FFes [19:17] not sure; generally we just try to apply common sense, though I know that's a fuzzy concept [19:18] I think what I may have meant is that if it hits the archive queue by FF then that's good enough; but of course we don't have much of an archive queue for syncs any more [19:21] oh also, is there another SRU for lucid's apt coming, or has all of that already happened? https://code.launchpad.net/~l3on/ubuntu/lucid/apt/fix-917845/+merge/90890 seems like a good candidate for incorporation [19:21] I don't have any right now [19:22] are there point release implications for sponsoring that at this point? [19:23] it wouldn't be accepted until after .4 is out [19:23] no problem uploading it though [19:23] as long as the upload's based on that in lucid-updates, obviously [19:23] right. i think it will likely need some adjustment [21:07] lamont: Losing armel builders for a few hours is a no-brainer, do it. [21:07] lamont: Any time lost will be made up for in, like, half an hour. :P [21:07] lamont: (Has anyone designed and built a babbage catapult yet?) [21:18] Daviey, turns out the DVD image I posted was last year's, got the dates confused. :P Have started the Kubuntu DVD builds off now. [21:21] not a babbage ballista? [21:28] pitti, cjwatson, Daviey - had to restore the cdimage's crontab from the file version (with thanks for slangasek's help); have disabled the LUCID daily builds in the new one. [21:28] buildlive kubuntu-dvd dvd lucid && DIST=lucid for-project kubuntu cron.dvd [21:29] Daviey ^ this is what I've kicked off the DVD build with, if you spot an issue. Please flag it. [21:30] skaet: okaym looks good - thanks [21:30] skaet: Have kubuntu been notified? [21:32] Daviey, they were the ones who notice it was last year's posted, not this years. #ubuntu-testing [21:33] ahh [21:33] * skaet goes off to compose the FF warning anounce, and wonders what other finger fumbles she'll come up with... :P [21:36] skaet: why not defer it till next week? We'll all thank you. :) [21:38] Daviey, hmmm ... late night planned eh? [21:48] skaet: What is a late night? [21:50] Daviey, anything 12 hours later than your normal time to go to sleep. :) [21:59] skaet: sleep? What is this? :) [22:03] * skaet figures that explains some things.... [22:04] Lucid 10.04.4 Kubuntu DVD's posted to the iso tracker. [22:25] Daviey, pitti - given the issues with getting the Kubuntu DVD posted, can you please double check the publishing scripts have it right for them, if they get tested in time? [22:27] skaet: have an md5sum handy for what you are expecting? [22:28] Daviey, 4e648b2fdbfbb41e6e8eb8576936e0b9 *lucid-dvd-amd64.iso [22:28] 12111bc7ba90e50532dbca95dc5b33d1 *lucid-dvd-i386.iso [22:28] skaet: http://cdimage.ubuntu.com/kubuntu/dvd/current/report.html , concerning ? [22:28] (from Monday?) [22:28] lucid [22:29] duh [22:29] http://cdimage.ubuntu.com/kubuntu/lucid/dvd/current/ [22:30] right, http://cdimage.ubuntu.com/kubuntu/lucid/dvd/current/report.html [22:30] yup. [22:33] hmm.... Daviey - lucid-desktop-amd64.OVERSIZED [22:34] you and pitti discuss ^? [22:45] skaet: the PS3 version? [22:45] err, mac [22:46] no, amd64 desktop CD [22:46] http://cdimage.ubuntu.com/kubuntu/lucid/daily-live/current/ [22:47] skaet: it's 701MB, and will still fit a cd-r [22:47] skaet: ah, we should probably ask them to look for something to trim [22:47] charlie-tca: good point [22:48] charlie-tca, :) thanks we'll leave it alone then. *whew* [22:48] You are welcome [22:48] i burned it to one without realizing it was oversize [22:50] super! [22:50] slangasek, ^ FYI. :) [22:51] * skaet wonders if some heuristics for CD images size need to be updated, remembering some discussions at UDS on the subject and not sure where things ended up. [22:58] yeah, I've failed to follow through on that [22:58] the thing is, we know that the limits are unnecessarily small for *most* cases [22:58] and we haven't been able to pin down the details on where it's been a problem in the past [23:00] * skaet nods [23:55] slangasek, any thoughts as to why we could be seeing: http://cdimage.ubuntu.com/lucid/dvd/20120214/report.html [23:55] linux-meta 2.6.32.28.32 produces uninstallable binaries: [23:55] linux-backports-modules-wireless-lucid-generic-pae (amd64) [23:55] linux-backports-modules-wireless-lucid-server (i386) [23:56] looking [23:57] skaet: because -generic-pae makes no sense on amd64 [23:58] and it depends on an i386-only package (linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-generic-pae) [23:58] so this is a bug in linux-meta [23:58] still looking at the second one [23:59] the second one is the reverse - linux-backports-modules-wireless-lucid-server depends on linux-backports-modules-compat-wireless-2.6.34-2.6.32-28-server, which only exists on amd64 [23:59] ah - but that one is NBS