[00:17] <slangasek> skaet: I'm out for a few hours now; won't be in a position to get online, but you need anything feel free to ring me
[00:21] <skaet> slangasek,  Thanks.
[00:32] <skaet> NCommander, GrueMaster,  can you give me a summary of how we look on the ARM side?   anything needing rebuilds?
[00:33] <skaet> infinity,  ^^ if you have some perspective,  feel free to chime in ;)
[00:37] <skaet> ScottK, kubuntu desktop (20110831) and kubuntu alternate(20110830.1) posted
[00:39] <skaet> ScottK, on the desktop,  amd64, amd64+mac, i386 are oversized.
[00:48] <infinity> skaet: We need all our alternates rebuilt (if that didn't already happen) for that latest d-i.
[00:48] <infinity> skaet: For desktop, we have "issues" anyway, so I'm not sure we care deeply tonight.
[00:49] <skaet> infinity, has the d-i been published yet?
[00:49]  * skaet looking
[00:55] <skaet> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu60
[00:55] <skaet> infinity, looks like we're waiting for the arm images to be published.
[00:56] <highvoltage> how are things, skaet? I'm sorry for being so absent during this cycle, work just got into the way too much.
[00:57] <skaet> heya highvoltage,  good to see you.  :)  we're just sorting out which images need rebuilds to pick up today's fixes.
[00:58] <highvoltage> ah great
[00:58] <skaet> highvoltage, http://pad.ubuntu-uk.org/ubuntu-release;   basically as soon as the firefox fixes get published to the archive, I plan to spin a new set of edubuntu DVDs.   That look ok to you?
[01:00] <highvoltage> no complaints from me, I noticed today that I get build notifications agin
[01:00] <highvoltage> *again
[01:00] <highvoltage> I guess stgraber fixed the mail list for that
[01:00] <highvoltage> (which is great)
[01:05] <skaet> :)
[01:07] <skaet> highvoltage, if you have the time now, while we're waiting for the builds to start off,  would be great if you could add the Edubuntu overview into the release notes.  https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
[01:16] <highvoltage> ah yes there is some new information I can add there
[01:18] <skaet>  :) thanks!
[01:18] <skaet> ScottK,  kubuntu DVD (20110831) images posted
[01:19] <GrueMaster> skaet: sorry, I had stepped out and missed your ping.  Desktop armel looks messy, but nothing rebuild worthy.  I am kind of concerned with omap as I don't have networking now, but It may be due to an older board.
[01:19] <GrueMaster> And I am working to discover if it is a u-boot or kernel issue.
[01:19] <GrueMaster> I'll get the server testing done tomorrow.
[01:20] <GrueMaster> (desktop is more complex).
[01:21] <skaet> GrueMaster, okie.   based on infinity's comments,  which specific images do you want picking up the debian-installer changes?
[01:21] <GrueMaster> Just the netboot images.
[01:21] <GrueMaster> Everything else is preinstalled and not affected.
[01:22] <skaet> Thanks GrueMaster :)
[01:23]  * skaet appreciates not having to do the grep exercise. ;)
[01:30] <infinity> GrueMaster: Oh, thanks for that, somehow I keep forgetting ARM doesn't actually have d-i images.
[01:30] <infinity> GrueMaster: (Well, other than netboot, which is built by d-i itself)
[01:34] <skaet> infinity, can you paste the netboot building command - I'm scanning the crontab and not seeing it.
[01:34]  * skaet may be getting tired.
[01:34] <skaet> GrueMaster, infinity - do we need rebuilds of ubuntu core?
[01:36] <superm1> skaet, can you accept mythbuntu-default-settings for the ubiquity text rendering fix?
[01:37] <GrueMaster> I haven't tested it yet, but it is far less complex than the desktop or server, so highly doubtful.
[01:37] <superm1> hopefully that should be the last of the bugs i think to be fixed for b1
[01:37] <GrueMaster> It doesn't have boot capabilities on its own.
[01:38] <skaet> superm1,  am fine with us pulling them in, but would prefer infinity (or one of the other more knowledgeable folk ;) ) do the review. :)
[01:38] <GrueMaster> skaet: One issue with ubuntu-core that doesn't appear to have been resolved yet is that http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current points to an older version and not the latest daily.
[01:38] <superm1> Mkay
[01:39] <skaet> GrueMaster, ack,  probably an oversite at some point.  Will correct now.
[01:47] <infinity> skaet: I'll be doing core stuff later anyway.
[01:47] <infinity> skaet: It builds with pretty much zero effort, so I'll get on it in a bit.
[01:47] <infinity> GrueMaster: That's being fixed.
[01:47] <infinity> skaet: Fixing that means me committing some fixes to publishing.
[01:50] <skaet> GrueMaster, latest Ubuntu Core I know about is 20110829.1,  probably best to pull it down manually until jibel and infinity can get things working again.
[02:15] <skaet> firefox finally published to the mirrors,  am starting off the sequence of builds now.
[02:18] <micahg> thanks skaet
[02:18] <skaet> thanks micahg, chrisccoulson   :)
[02:37] <skaet> builds humming along now,   status of what is going on where, and in which order is on http://pad.ubuntu-uk.org/ubuntu-release if anyone is interested.
[02:38] <skaet> I'm going to step away for a bit for some dinner, but if someone notices an image has emerged, feel free to post.
[02:39] <skaet> highlight my nick if issues spotted,  biab.
[02:39]  * charlie-tca going to sleep soon, will return in about 11 hours
[02:39] <skaet> charlie-tca - xubuntu builds in that set,  should be up by the time you wake.  (fingers crossed).
[02:40] <charlie-tca> Thanks. my fingers are crossed too.
[02:40]  * skaet --> dinner, biab.
[03:43] <skaet> ubuntu alternate, desktop (20110831) posted
[03:43] <skaet> xubuntu alternate (30110831) posted
[03:44] <skaet> ubuntustudio alternate (20110831) posted
[03:44]  * skaet notes on xubuntu that should have been 20110831
[03:47] <skaet> astraljava, ^^
[03:48]  * micahg would have been more interested in xubuntu alternate from the year 3011 :)
[03:50] <skaet> lol
[04:11] <skaet> ubuntu dvd (20110831) posted
[04:11] <nigelb> I didn't know skaet had a time machine :D
[04:13] <skaet> nigelb,  ...I just wish I could apply it to our mirrors and the build publishers.  ;)
[04:13] <nigelb> heh
[04:14] <skaet> pitti,  jibel - I'm calling it a night now.   Edubuntu DVD,  and Xubuntu CD still to come off the builders,  please post to the iso tracker when they emerge.
[04:15] <skaet> pitti,  http://pad.ubuntu-uk.org/ubuntu-release is up to date with what I know.  :)
[04:15]  * skaet --> zzz
[04:19] <pitti> Good morning
[04:20] <pitti> micahg: I set crested back on auto
[04:21] <micahg> pitti: thanks, I"ll have more builds later :)
[04:22] <pitti> ah, I hope the "currently planned rebuilds" in the pad are out of date now, I'll updateit
[04:37] <pitti> eek, seems kubuntu desktop wasn't rebuilt, doing that now
[04:38] <pitti> oh, I guess no lightdm -> no autologin fix
[04:41] <slangasek> ok, who broke the livefs autobuilders? :)
[04:41] <slangasek> /usr/bin/ubuntu-defaults-image: 130: sudo: not found
[04:42] <infinity> slangasek: ?
[04:42] <slangasek> ah, seems to have un-broken itself in a subsequent run
[04:42] <slangasek> infinity: reading my error mailz
[04:42] <infinity> Reading is unhealthy.
[04:43] <skaet> slangasek,  that was cjwatson's zh_CN build.
[04:43] <slangasek> looks like that's fixed now, but ubuntu/powerpc failed to build because libreoffice is uninstallable there (missing lib)
[04:43] <slangasek> skaet: ah
[04:47] <pitti> slangasek: right, ubuntu-defaults-image is only for the localized builds, i. e. Chinese Edition; this is still being set up
[04:47] <pitti> slangasek: mythbuntu doesn't use firefox, but does use lightdm, I think we should rebuild that, too; I'll trigger thhat
[05:08] <superm1> pitti, can you accept mythbuntu-default-settings before triggering it?
[05:08] <superm1> fixes the ubiquity rendering bug
[05:15] <pitti> superm1: sure
[05:15] <superm1> thanks
[05:15]  * superm1 -> bed
[05:15] <pitti> edubuntu/xubuntu will still build for a while anyway
[05:33] <pitti> Daviey: is bug 791607 still actually an RC issue? I thought euca is unsupported  now? Or is that still an issue for supporting upgrades?
[06:01] <infinity> Is this antimony's way of saying I should go to bed?
[06:01] <infinity> Received disconnect from 91.189.90.135: 2: Packet corrupt
[06:01] <infinity> Write failed: Broken pipe
[06:05] <micahg> pitti: feel free to kill a thunderbird 3.1.x build if you need a builder (won't go out until EOD UTC tomorrow)
[06:05] <micahg> err, EOD UTC today :)
[06:05] <micahg> it's only ~1hr on everything except armel though
[06:05] <infinity> slangasek / skaet: ubuntu-core publishing is sane now.  Or, should be.  Have a poke at it and see if it works for you.  All it needs now is someone to write a decent header blurb for it, but that can happen a bit later.
[06:05] <pitti> micahg: no, should be fine
[06:06] <pitti> infinity: what does "publishing" mean here? we can start another build?
[06:06] <micahg> ah, I see I won't be able to grab all the buildds, oh well...it's fine anyways
[06:10] <infinity> pitti: As in, how they're published. :P
[06:10] <infinity> pitti: (I'm not in the way of any builds, nor does core need any currently, if either of those was what you were driving at)
[06:11] <pitti> i. e. http://cdimage.ubuntu.com/ubuntu-core/daily/20110831.1/ ?
[06:11] <pitti> oh, I see - shiny header.html
[06:11] <pitti> and the previous ones only had armel builds
[06:11] <pitti> thanks!
[06:11] <infinity> pitti: Oh, that can be added to the tracker if anyone has a clue how to test them.  But I was mostly just sanitizing the icky hackjob I had there before for build/publish.
[06:12] <infinity> pitti: (We are nominally testing/validating core, I guess, but it's basically just "chroot in and see if your shell doesn't segfault, win")
[06:12] <infinity> Cause, really, how do you test a minimal chroot? :)
[06:12] <pitti> something like "bash and apt-get install work"?
[06:13] <pitti> i. e. package management is set up properly
[06:13] <infinity> pitti: Even the latter won't, unless you set up a resolv.conf.
[06:13] <pitti> that'd be my expectation, anyway
[06:13] <infinity> pitti: But sure, that would be an easy testing step.
[06:13] <pitti> edubuntu DVDs posted
[06:14] <infinity> Anyhow.  I think it's nap time here.
[06:14]  * infinity tosses pitti what's left of his cowboy hat.
[06:14] <infinity> See you in 8 hours. ;)
[06:14] <pitti> sleep well
[06:14] <micahg> infinity: +1 :)
[06:15] <pitti> latest ubuntu core posted
[06:15] <pitti> not that anyone cares.. "0 notification e-mails have been sent."
[06:24] <infinity> Oh, one last thing..
[06:25] <infinity> cjwatson: Should \*gz be added to bin/site-manifest?  Not sure precisely how or what it's used for, but various img.gz and tar.gz images missing from it seems off.
[06:25]  * infinity sleeps now.
[06:32] <pitti> xubuntu desktop posted
[07:30] <jibel> good morning
[08:19] <pitti> bonjour jibel
[08:56] <cjwatson> skaet: for the record - netboot images are built by the debian-installer source package.  they're not a cdimage function, and thus you won't find anything pertaining to them in the cdimage crontab.
[08:56] <cjwatson> infinity: err, maybe - I'll have a look
[08:57] <astraljava> skaet: Thank you!
[09:25] <cjwatson> pitti: could you review that ubuntu-defaults-builder upload?  It should fix the overnight failure.
[09:26] <pitti> mythbuntu posted
[09:26] <pitti> that was the last image, should all be current and working now
[09:26] <pitti> cjwatson: sure, doing
[09:26] <pitti> cjwatson: good morning
[09:27] <pitti> cjwatson: oh, I guess it shouldn't use sudo if it's already root?
[09:27] <pitti> right, should have thought about that
[09:27] <pitti> cjwatson: accepted, thanks for fixing
[09:28] <cjwatson> in this case sudo isn't installed :)
[09:28] <cjwatson> (arguably we should depend on it?)
[09:29] <pitti> cjwatson: I'm happy to add a recommends, but for installing it on the builders it would perhaps better to exit with a meaningful error if you aren't root and sudo is not installed?
[09:29] <cjwatson> mm, perhaps - at any rate the above change should deal with it for now
[09:30] <cjwatson> since BuildLiveCD just kicks the whole thing off as root
[09:53] <cjwatson> infinity: site-manifest now looks at *.img.gz and *.tar.gz too; thanks
[10:39] <pitti> jibel, cjwatson: do you see anythign which requires urgent attention?
[10:39] <pitti> if not, I'd reinstall my workstation with the current image, and have lunch in the meantime
[10:41] <jibel> pitti, testing goes well. major issues on desktop are  bug 837681 and OEM install broken on DVDs
[10:42] <jibel> 837681	ubiquity (Ubuntu)	New	Critical	Automatic partitioning corrupts GUID partition table (GPT)
[10:42] <pitti> jibel: OEM install broken on CDs as well?
[10:42] <jibel> pitti, no only on DVD
[10:42] <pitti> uh, weird
[10:42] <pitti> oh, no clickable bug links any more?
[10:43] <jibel> 837503	ubiquity (Ubuntu)	Triaged	High	'Prepare for shipping' not available on DVDs
[10:44] <jibel> oem-config is not installed
[10:44] <cjwatson> 837681> hmm.  that'll be a nightmare to investigate without logs.
[10:44]  * cjwatson wonders if he can mock up a suitable test VM
[10:44] <pitti> ok, I think we can release-note oem-config on DVDs
[10:46] <cjwatson> I know how to fix 837503 but I think you're right that it's release-note fodder for b1
[10:47] <cjwatson> (commented on the bug)
[10:48] <jibel> other issue: migration-assistant is broken
[10:48] <jibel> 829987	migration-assistant (Ubuntu)	Confirmed	High	ubiquity crashed with TypeError: cell_data_func() takes exactly 4 arguments (5 given)
[10:48] <pitti> ok, back in about an hour; please ring my cellphone if something urgent pops up
[10:49] <cjwatson> ev: ^- can you look at 829987?
[10:49] <ev> will do
[10:51] <cjwatson> confirmed that EFI installations have /sys/firmware/efi again
[10:53] <jibel> apart from that I'll test ltsp and cjk install this afternoon. ibus was in bad shape last milestone.
[10:54] <cjwatson> I ported lots of ibus modules to the new libibus, which perhaps may have helped
[11:16] <ogra_> hmmmm
[11:17]  * ogra_ cant seem to find out why preinstalled images end up without slideshow
[11:57] <pitti> re
[12:09] <ogra_> m
[12:09] <Daviey> pitti: sorry, just saw your question on scrollback.  The milestone was set really to help encourage those that are working on it.  It is not a release crticial issue.
[12:10] <pitti> Daviey: ok, so we'll just move it over to b2 I guess
[12:12] <Daviey> pitti: I plan to move all the milestoned bugs i care about later today.
[12:13] <Daviey> or rather, s/care/moniotring/
[12:13] <pitti> Daviey: we have a script for that
[12:13] <pitti> so we can do it wholesale after release
[12:13] <pitti> unfortunately it breaks right now, as LP claims to have zero "development releases" of Ubuntu
[12:13] <pitti> it's trivial to workaround
[12:13] <pitti> but either way, moving them after the release is more correct, I htink
[12:14] <cjwatson> grr
[12:14] <cjwatson> I hate it when I discover new shell quirks during release work
[12:14] <ogra_> before the friday release meeting would surely be preferred though :)
[12:14] <cjwatson> 'DISPLAY= $SUDO PROJECT="$FLAVOUR" ARCH="$ARCH" lb build' does not behave the way I expect it to when SUDO is empty
[12:14] <pitti> ogra_: I can do it right after we unfreeze, i. e. tomorrow
[12:15] <ogra_> indeed
[12:15] <cjwatson> I guess parsing of variable assignments happens before parameter expansion
[12:15] <pitti> eek; that says PROJECT=foo: command not found
[12:16] <cjwatson> yes
[12:16] <pitti> cjwatson: shall we just slide an "env" between $SUDO and PROJECT?
[12:16] <Daviey> pitti: incidently, so do i (have a script) :)
[12:16] <pitti> that's a real program
[12:16] <cjwatson> actually I was going to suggest SUDO=env
[12:16]  * ogra_ was about to say that 
[12:17] <pitti> cjwatson: or that
[12:17] <pitti> cjwatson: want me to fix in bzr, or are you on it?
[12:18] <cjwatson> I'm on it
[12:19] <cjwatson> uploaded
[12:20]  * pitti reviews diff from bzr, accepted
[12:21] <pitti> need to run to the post office, back in 20
[12:22] <cjwatson> ta
[12:35] <smoser> cjwatson, could you populate the ISO tracker with https://cloud-images.ubuntu.com/server/oneiric/20110831/
[12:37] <cjwatson> smoser: I've run the script.  Does it look OK?
[12:38] <cjwatson> seems to have at least one of the correct ami-* IDs.
[12:39] <smoser> cjwatson, i think so.
[12:39] <smoser> checking
[12:40] <smoser> cjwatson, good. thank you
[12:45] <pitti> hey smoser
[12:45] <pitti> smoser: ah, we discussed that yesterday, and Daviey meant that it's not too much value having them there, as they are being tested automatically only anyway?
[12:45] <pitti> but thanks
[12:50] <smoser> i wish i would have been consulted.
[12:51] <smoser> why do we not feel that having a central location at which bugs are recorded and test cases tracked ?
[12:51] <smoser> s/ ?/is valuable?/
[12:55] <pitti> well, if it's useful to you, then let's add it
[13:01] <stgraber> morning
[13:02] <charlie-tca> Good morning
[13:21] <Daviey> smoser: hold fire, on the phone
[13:29] <Daviey> smoser: Yes, it was really a continuation of a prior discussion in here.  I did wonder what the value is in having it on that site, considering the testing is all automated - and copying the pass/fail from one website to another is a little crap.
[13:29] <Daviey> I totally agree having a central release tracking place is a good thing.
[13:30] <Daviey> (which is why i was suggesting we look to automate that part)
[14:11] <cjwatson> sigh, I wish I could test ubuntu-defaults-image more than one commit at a time
[14:11]  * skaet waves
[14:12]  * skaet and starts into the backscroll.... 
[14:15] <cjwatson> pitti: review of ubuntu-defaults-builder 0.18 (just uploaded) welcome :-/
[14:15] <pitti> hey skaet
[14:17] <pitti> cjwatson: this just demotes memtest86+ from depends to recommends AFAICS?
[14:17] <pitti> ah, nevermind, bzr diff -c -3 is the real one
[14:17] <cjwatson> yeah, promotes it from nothing to recommends
[14:17]  * pitti waits for it to hit the queue
[14:17] <cjwatson> I'm hoping that the livefs chroot is set up to install recommends by default
[14:18] <cjwatson> if it isn't, this will fail anyway due to lack of syslinux-theme-ubuntu, and I shall have to curse and file an RT to get BuildLiveCD amended again
[14:23] <pitti> cjwatson: calling a local script isn't possible for testing?
[14:25] <skaet> pitti,  jibel, - so other than bug ev's looking at (bug 829987), all is calm?
[14:25] <cjwatson> it's less effort to lob it through the autobuild process a few times than to try to replicate a sufficiently faithful local environment
[14:26] <pitti> cjwatson: I meant, having BuildLiveCD call the script from ~cjwatson or so; I suppose it's not, I was just curious
[14:26] <cjwatson> that would involve an RT
[14:26] <cjwatson> and I don't have access to the relevant system anyway
[14:26] <pitti> skaet: yes, I didn't see other major things pop up except the ones in the pad
[14:26] <doko_> cjwatson, slangasek: jamespage sees a test failure in lucene2, which goes away when adding/installing fontconfig. were there any changes after the 24th?
[14:26] <cjwatson> my least-effort access to it is via uploads
[14:27] <cjwatson> doko_: no idea ...
[14:27] <pitti> skaet: i. e. oem-config broken on DVDs, EFI (deliberately) broken on server, migration-assitant broken
[14:27] <cjwatson> well, not deliberately broken, deliberately not respinning to fix
[14:27] <jamespage> doko_: thats not in lucene2 - that was in jenkins - think out conversation got a little crossed over
[14:29] <pitti> right, sorry; I meant "deliberately unfixed"
[14:30] <pitti> "not fixed"
[14:30] <doko_> jamespage, well, maybe just add it as dependency for now, if we do not find the real reason. can you see, if fontconfig was installed in your succeeding build, maybe pulled in by another dependency?
[14:30] <jamespage> doko_: ack
[14:32]  * skaet really likes time scrollback on the pad!  :)
[14:36] <charlie-tca> skaet: just failed lvm encrypted install on Xubuntu 386 alternate
[14:39] <pitti> cjwatson: I don't remember, did we use to pre-publish amd64+mac images? publish-image-set doesn't seem to do that
[14:40] <pitti> we didn't for the final, anyway
[14:40] <pitti> so I guess it's intended, just want to make sure that this didn't change
[14:41] <jibel> skaet, and this bug: 837681 ubiquity (Ubuntu) New Critical Automatic partitioning corrupts GUID partition table (GPT)
[14:42] <pitti> skaet, jibel: the ISO tracker gives me sufficient confidence for ubuntu desktop/alternate to pre-publish, but kubuntu alternate is not tested at all yet, and kubuntu desktop only lightly; so I propose I'll do the pre-publishing later tonight?
[14:42] <pitti> (we need to do it today for mirrors to catch up)
[14:42] <cjwatson> pitti: no, they're not on releases
[14:43] <cjwatson> (for better or worse)
[14:43] <skaet> pitti, why can't we run them first thing tomorrow?  how long a mirror catch up are we talking about?
[14:43] <cjwatson> skaet: we can do repeated prepublications, so you can have botrh
[14:43] <cjwatson> *both
[14:43] <cjwatson> but the earlier the better really
[14:44] <pitti> tomorrow is too late, it takes some time to rsync around the world
[14:44] <pitti> but if we rebuild, another rsync should be a lot faster
[14:44] <pitti> I need to leave at 19:30 today for Taekwondo, so I could start the pre-publishing at 19:00, which is 2:15 hours from now
[14:44] <pitti> maybe we'll get some testing on Kubuntu until then
[14:45] <pitti> I can also pre-publish ubuntu now and kubuntu later, that's even better
[14:45] <charlie-tca> Both Xubuntu alternate images fail encrypted installs; probably caused by packages needing rebuilds due to changes yesterday
[14:45] <cjwatson> hm, what would need rebuilds in a way that would affect encrypted installs?
[14:45] <pitti> charlie-tca: hm, xubuntu got rebuilt last night
[14:45] <charlie-tca> Can we back them up
[14:45] <cjwatson> back what up?
[14:46] <charlie-tca> and today they fail. Yesterdays images worked
[14:46] <charlie-tca> Can we have them back
[14:46] <cjwatson> any chance of diagnosing the problem first?
[14:46] <charlie-tca> bug 838136
[14:46] <pitti> charlie-tca: you mean releaseing http://cdimage.ubuntu.com/xubuntu/daily/20110830/ instead? in theory yes
[14:46] <charlie-tca> yes
[14:46] <charlie-tca> unless we can fix this bug quickly
[14:47] <pitti> http://paste.ubuntu.com/678937/ is the package version diff between the images
[14:48] <cjwatson> it would have been quicker to check report.html before starting the tests :)
[14:49] <pitti> it dropped libwv, tango-icon-theme, libnet-dbus-perl, and indicator-application
[14:49] <pitti> libwv probably causes the abiword uninstallability
[14:51] <charlie-tca> Does it only affect encrypted installs?
[14:51] <charlie-tca> desktop 64 whole disk partitioning worked
[14:51] <pitti> charlie-tca: should affect all alternate installs
[14:51] <charlie-tca> oh
[14:52] <cjwatson> yes, everything.  I advise checking report.html before starting any tests (for images where it exists)
[14:52] <cjwatson> well, all alternates
[14:53] <cjwatson> a simple rebuild might fix it; xubuntu-desktop is installable in my chdist environment
[14:53] <charlie-tca> yes, xubuntu-desktop 64 worked okay
[14:53] <pitti> I'll try a rebuild; not sure what made these drop off the CD
[14:53] <cjwatson> charlie-tca: different xubuntu-desktop :-)
[14:53] <charlie-tca> heh
[14:53] <pitti> eek, did the DC just fell off the planet?
[14:54] <pitti> ah no, just LP
[14:54] <charlie-tca> lol
[14:56] <charlie-tca> okay, back to testing the desktop images then
[15:05] <skaet> cjwatson - so decision is to definitely release note 837681 (since limited to amd64+mac?).  Also, what's outlook on  829987?  fix likely?
[15:07] <cjwatson> 829987 no idea, ask ev
[15:07] <skaet> ack, will do
[15:07] <smoser> Daviey, regarding having the results there... i agree they're not all that much value, but the one thing that is there that is no where else is the links to bugs that were found.
[15:07] <cjwatson> 837681 no proof that it's limited to amd64+mac
[15:07] <ev> on 829987 now
[15:07] <smoser> in the jenkins there is no way to say "this failure was this bug".
[15:07] <ev> was busy fixing oem-config stuff
[15:07] <cjwatson> it could well be all systems requiring GPT
[15:08] <ev> which I'm still doing, but I'll put that down for a moment
[15:08] <cjwatson> i.e. anything EFI or with >2TB disk
[15:08] <smoser> although, i dont know how i can see historical results on ISO testing so that is not really all that valuable.
[15:08] <Daviey> smoser: I do agree.. This was why i raised the suggestion of automating copying of the results in the meeting yesterday.
[15:10] <Daviey> Release team, can i have some advice on bug #836668 ?
[15:10] <Daviey> It doesn't seem that we have any archive dependencies that require mongodb support for kombu, and it does build ok without this build dep.  However, introducing a delta in kombu to keep pymogo out of main would seem to be more work involved, than maintaining pymongo which currently seems to be maintenance free; and it's only been tested with this build dep so far in the cycle.
[15:10] <smoser> Daviey, but you'd still need human intervention to mark the bug.
[15:11] <smoser> and, really, i think iso tracker is severely lacking if you can't see historical results (which i've never been able to see).
[15:11] <Daviey> smoser: Yeah, that is true.. but it's less time itesive to go and make fails with a bug #, than marking all the ones which passed
[15:11] <ev> right, 829987 is fixed (it was just the wrong function prototype for GTK3 - passing the data argument is now required)
[15:13] <skaet> ev,  Thanks!
[15:13] <ev> sure thign
[15:13] <ev> thing even
[15:20] <pitti> charlie-tca: ok, that's better: http://cdimage.ubuntu.com/xubuntu/daily/20110831.1/report.html
[15:20] <pitti> charlie-tca: posted to tracker
[15:21] <charlie-tca> Okay, I will try again
[15:21] <charlie-tca> Thank you very much, both pitti and cjwatson
[15:21] <pitti> charlie-tca: that should never have made it to the tracker in the first place, sorry about that
[15:22] <charlie-tca> Well, as long as things are fixable. I get nervous this late when things fail that bad
[15:23] <pitti> rightfully so :)
[15:28] <pitti> hmm
[15:28] <pitti> the tracker says we tested server 20110829.1, but we only ahve 20110830
[15:29] <ScottK> I've gotten some good installs on Kubuntu live, so if history is a guide we'll likely be ~good to go.
[15:30] <pitti> hggdh, jibel: seems you tested the server images; can you please check .info/ about the build stamp?
[15:30] <pitti> I wonder whether it was just added to the tracker with the wrong version, or if we did a rebuild yesterday and lost the old image
[15:31] <Daviey> pitti: .1 was for the powerpc respin, it was only limited to the single arch.
[15:31] <jibel> pitti, the tracker is wrong. we tested "Ubuntu-Server 11.10 "Oneiric Ocelot" - Beta amd64 (20110830)"
[15:31] <Daviey> 20110829.1 was never created for normal arches.
[15:31] <pitti> jibel: *phew*, thanks
[15:31] <hggdh> :-)
[15:31] <pitti> I guess if I bump the tracker, we lose all testing results, though
[15:32] <pitti> so I'll just fix up the version when publishing
[15:32] <hggdh> thank you ;-)
[15:34] <jibel> pitti, I'll update the buildnumber
[15:34] <pitti> jibel: ah, DB hackery? thanks
[15:35] <jibel> pitti, new bug for your team. Launching pgadmin3 crashes metacity
[15:35] <pitti> eek
[15:39] <jibel> done
[15:40] <pitti> ScottK: right, and Kubuntu desktop has some successful test cases
[15:41] <ScottK> The hardware I have available for testing is 32bit, so if someone could work on amd64, it'd be really helpful.
[15:41] <pitti> ScottK: do you have power again?
[15:41] <ScottK> pitti: Yes.  Got it back last night.
[15:41] <pitti> yay
[15:42] <ScottK> Equally important from a productivity perspective is that school for our 8 year old got power back so today was the first day of school (was supposed to be Monday).
[15:42] <pitti> skaet: FTR, I pre-published ubuntu desktop/alternate/server and kubuntu desktop
[15:42] <pitti> I'll do kubuntu alternate once we get a successful test
[15:43] <skaet> pitti, thanks.
[15:43] <pitti> skaet: if we re-spin, the update will at least be faster
[15:43]  * skaet nods
[15:43] <pitti> hush, mirrors out there, go sync
[15:43] <ScottK> I've got the Kubuntu i386 dvd downloaded for after I finish Kubuntu desktop testing.
[15:43] <jibel> LTSP is ok on alternates, next on the list is CJK installation
[15:45] <stgraber> jibel: you didn't happen to try LTSP in french did you? would have been interested to know if when logging in on the thin client you get the session in the right language (it's not the case for edubuntu).
[15:47] <pitti> skaet: I think at this point all bugs on https://launchpad.net/ubuntu/oneiric/+bugs?orderby=-importance&field.milestone%3Alist=39143 are OK to move to b2
[15:47]  * skaet looking
[15:48] <pitti> skaet: that would clear the list for real b1 showstoppers which come in
[15:48] <jibel> stgraber, I didn't but I do it again in franch
[15:48] <jibel> *french
[15:48] <stgraber> jibel: cool
[15:48] <pitti> skaet: if you concur, I can run the script to move them wholesale
[15:49] <skaet> pitti,  scanned them, and concur.  Thanks.
[16:08] <pitti> so, if a b1 blocker turns up, we'll see it more clearly on https://launchpad.net/ubuntu/oneiric/+bugs?orderby=-importance&field.milestone%3Alist=39143 now
[16:09] <pitti> skaet: not sure whether you want to target bug 837681 there for the time being?
[16:09] <pitti> (and move it over if we don't get to it)
[16:10] <skaet> pitti,  would like bug 837681 moved back to b1 until we hear from cjwatson.
[16:11] <pitti> skaet: please go ahead
[16:11] <pitti> seems appropriate to me
[16:12] <pitti> dinner, bbl
[16:15] <skaet> pitti, done.
[16:30] <jibel> stgraber, login screen and session on the thin client are in french
[16:39] <charlie-tca> Xubuntu 64bit alternate install worked.
[16:39] <pitti> skaet: targetted it to oneiric, too
[16:39] <pitti> charlie-tca: good
[16:39] <charlie-tca> Thank you again
[16:41] <skaet> :)
[17:04] <cjwatson> lamont: can you tell me whether the innermost livefs build chroot is configured to disable installation of Recommends by default?  It appears that this is so, but I'd like to chec
[17:04] <cjwatson> *check
[17:25] <pitti> jibel: do you guys test the kubuntu alternates, or is that a community effort?
[17:27] <stgraber> skaet, pitti: Edubuntu looks good but LTSP doesn't work on it... I'm looking at fixing that now (two separate bugs), if I can get something within the next 1-2 hours I'll probably ask for a respin. Edubuntu isn't on releases.u.c (only on cdimage) so we're not affected by mirroring and I'll have time to re-test both images tonight.
[17:28] <skaet> stgraber,  ok.  Will be standing by.   Are there bug numbers?
[17:29] <pitti> stgraber: understood
[17:29] <stgraber> skaet: I don't think so, not sure what the problem exactly is yet. One if LTSP not showing up translated on LTSP live (need to look at upstream code) and the other is LTSP just not booting at all post-install.
[17:29] <stgraber> the first I'm fine release-noting but the second I want it fixed (and as it's likely to be the same package, I'd fix both at once)
[17:30] <skaet> stgraber,  thanks for the explanation.  Noted.
[17:36] <pitti> skaet: need to leave for Taekwondo now
[17:36] <skaet> ev,  can you upload ubiquity (with migration assistant bug fix), would like to get it build and standing by for rebuilds.
[17:37] <pitti> skaet: can you take over the con?
[17:37] <skaet> pitti,  thanks for the head's up,  yup.   please check in when you get back though ;)
[17:37] <pitti> skaet: I just updated the pad wrt. kubuntu pre-publishing
[17:38] <pitti> skaet: back in about 2.5 hours, I'll check back in then before going to sleep
[17:38] <skaet> pitti,  thanks!
[17:38] <pitti> skaet: at that point I'll pre-publish kubuntu alternate, regardless of the testing result
[17:38] <pitti> if it still doesn't have any tomorrow afternoon, we can still skip it
[17:38] <pitti> but I guess it should have some tests by then
[17:39] <skaet> ok
[17:39] <pitti> so, cu
[17:40] <stgraber> skaet: found the problem with LTSP for Edubuntu. Now to find a fix :)
[17:41] <skaet> stgraber: :)
[17:44] <stgraber> skaet: and fixed. I'll upload a new edubuntu-live and ltsp in the next 5 minutes or so.
[17:45] <skaet> even better.   :D
[17:54] <stgraber> skaet: that's bug 838265 and bug 838268. Both packages are now uploaded and should show up in the queue soon.
[17:57] <skaet> stgraber, sounds good.  Thanks.
[17:57] <skaet> slangasek, ^^ can you review?
[18:22] <slangasek> skaet: yep, reviewing
[18:23] <skaet> slangasek, Thanks! :)
[18:27] <slangasek> stgraber: ev doesn't seem to be around; could you prepare an upload of the ubiquity trunk so we can get those fixes in?
[18:27] <slangasek> ev: ^^ unless there's something still in progress here that we need to hold off for?
[18:28] <stgraber> slangasek: I'm currently testing one last fix. Colin said he'd upload when he gets back from dinner.
[18:28] <slangasek> ok
[18:57] <slangasek> I suppose there's no sense in edubuntu respins until ubiquity is also in?
[18:58]  * skaet nods
[19:35] <charlie-tca> looks like ubuntustudio 64 will need a respin -
[19:35] <charlie-tca> http://paste.ubuntu.com/679164/
[19:43] <charlie-tca> Can someone kick a respin for ubuntustudio or should I file a bug report on the fail to install?
[19:43] <slangasek> charlie-tca: are those issues fixed in the source package?
[19:43] <slangasek> a respin without a source fix shouldn't do any good there
[19:44] <charlie-tca> Xubuntu had almost the same fails; respin worked
[19:44] <charlie-tca> Xubuntu also had abiword failing to build though
[19:46] <slangasek> well, I don't see why a rebuild would fix this but I also don't see why the image missed picking up those packages; trying a respin
[19:47] <charlie-tca> I know the first two packages should have worked; we have them in the xubuntu images that are now working
[19:47] <slangasek> this was the error in the logs: Link from /srv/cdimage.ubuntu.com/ftp-universe/pool/universe/t/ttf-sil-andika/ttf-sil-andika_1.0.basic-4_all.deb to /srv/cdimage.ubuntu.com/scratch/ubuntustudio/daily/tmp/oneiric-i386/CD1/pool/universe/t/ttf-sil-andika/ttf-sil-andika_1.0.basic-4_all.deb failed: No such file or directory
[19:47] <slangasek> some kind of archive skew during the build, then
[19:47] <slangasek> cjwatson: ^^ is this a new problem?  I don't remember it having shown up before
[19:51] <cjwatson> tools/hardlink is relatively new code, but why's it getting ENOENT
[19:52] <cjwatson> and the archive's meant to be locked
[19:52] <cjwatson> sorry, no cycles to look at this
[19:52] <cjwatson> just lost an hour's work on the parted bug due to USB cable slippage
[19:52] <cjwatson> so kind of stressed
[19:58] <skaet> release team members,  parted needs to be figured out and we need to understand it enough to know if its safe to release tomorrow or not.   Please assist cjwatson if he asks for any help.
[19:59] <cjwatson> thanks, for now it's a one-person-at-a-time job though
[20:00] <cjwatson> ubiquity uploaded
[20:01] <skaet> thanks cjwason.   slangasek, ^^
[20:02] <slangasek> reviewing
[20:06] <slangasek> strange set of whitespace changes in bin/oem-config-remove-gtk, bin/ubiquity which are otherwise untouched
[20:06] <slangasek> cjwatson: ^^ can you tell me if that's deliberate/harmless/uh-oh?
[20:06] <cjwatson> deliberate and harmless, though I probably should have waited 'til later before committing that
[20:07] <cjwatson> (pyflakes was whining in red at me)
[20:07] <slangasek> ok
[20:10] <bjf> pgraner, skaet What I can tell you at this point is that out of 5941 bugs open against linux, 106 had drives 2 TB or larger
[20:10] <bjf> pgraner, skaet I'm not checking if any of those are the same system with multiple bugs, i can do that, if you'd like
[20:12] <skaet> bjf,  thanks!
[20:12] <slangasek> ev, cjwatson: I see the change in ubi-language.py that addresses not trying to connect signals in oem-config, but there's a very large delta due to dropping a wrapping try/except... that doesn't seem related to this change?
[20:13] <bjf> pgraner, skaet, is that enough info or do you want me to determine how many of those 105 were the same system?
[20:13] <cjwatson> I'm afraid I just uploaded it and haven't extensively reviewed it
[20:13] <skaet> bjf, as long as the 106 weren't all from the same system.   We have the evidence we need that this is a use case that is important.    If its a 5 minute task do it,  otherwise, we have enough for now.
[20:13] <cjwatson> I don't mind putting back the try/except if you'd rather, since that's easy and it's harmless
[20:14] <slangasek> cjwatson: ok.  in practice this shows up as the language page failing to be instantiated either way I think, so I'll not worry unless you tell me to
[20:14] <cjwatson> skaet: is this related to the parted bug I'm working on?
[20:14] <bjf> skaet, i'll work on it
[20:14] <skaet> cjwatson, yes,  trying to figure out how many >2T systems might be out there.
[20:14] <cjwatson> skaet: neither you nor I know exactly what the trigger for this bug is
[20:14] <cjwatson> I really recommend not going on long hunts until we have more infor
[20:14] <cjwatson> information
[20:15] <cjwatson> I can't even tell you yet whether non-Mac >2T systems are affected
[20:15] <slangasek> ubiquity accepted
[20:16] <cjwatson> it's quite possible that it's isolated to Macs; it's also quite possible that it isn't
[20:16] <skaet> cjwatson, understood.   It was asked earlier if we even had some >2T filesystems out there now, and bjf has answered that.
[20:17] <cjwatson> yep, I was getting bugs related to that a year or two ago
[20:17] <cjwatson> >2T is one of the big drivers for GPT and hence EFI
[20:18] <cjwatson> (the "hence" isn't as much of a requirement as the manufacturers would like you to think, but anyway)
[20:19] <pitti> hello again
[20:19] <skaet> thanks for the backgound.
[20:19] <skaet> hiya pitti,  welcome back
[20:19] <cjwatson> I wish resize2fs weren't so slow ...
[20:19] <pitti> ah, so ltsp/edubuntu-live were uploaded
[20:20] <slangasek> superm1: I see there's a mythbuntu-log-grabber ftbfs fix in the queue; would you want that in beta-1?  (It doesn't look critical, but we have a window right now)
[20:20] <skaet> pitti,  yup, and migration assistant fix just went up.   Will start off edubuntu rebuilds when it lands.
[20:20] <pitti> skaet: ah, good
[20:20] <slangasek> skaet: only edubuntu?
[20:20] <skaet> ubuntu rebuilds are still ??? though.
[20:21] <pitti> skaet: I don't think we should rebuild the other images for that, though
[20:21] <skaet> slangasek,  will do any others that want it.
[20:21] <pitti> if we get a GPT fix, then yes
[20:21] <slangasek> I would say push the lot to the queue if we care about these ubiquity fixes
[20:21] <slangasek> the migration-assistant crash wasn't edubuntu-specific?
[20:22] <pitti> slangasek: right, it wasn't
[20:22] <slangasek> I assumed it was being pushed because we wanted it for ubuntu
[20:22] <skaet> slangasek,   I'll trigger ubuntu rebuilds once we understand if we're going to need to wait for parted or not.
[20:23] <slangasek> skaet: we could always respin again if we find out we need parted, no?  better to make the buildds useful in the meantime
[20:23] <slangasek> so that if we *don't* need parted, we haven't waited for nothing
[20:23] <skaet> slangasek,  ok,  will launch them one by one,  so can interrupt.
[20:23] <slangasek> right, sounds like a plan
[20:23] <skaet> after ubiquity is published in the archives :)
[20:24] <ScottK> What's the ubiquity fix?
[20:24] <skaet> migration assistant
[20:24] <ScottK> OK, doesn't affect Kubuntu.
[20:24] <pitti> skaet, slangasek: can you also re-pre-publish the ubuntu images if/when you respin them, please?
[20:25] <cjwatson> hmm, still can't reproduce ...
[20:25] <slangasek> can do
[20:25] <cjwatson> oh, BLAST, parted does its own subarch detection doesn't it
[20:26] <cjwatson> so I need to hack libparted as well as just archdetect
[20:26] <pitti> skaet, slangasek: do you have the situation under control, or need me to do anything right now?
[20:26] <skaet> slangasek,pitti  I've got the pad scored for the rebuilds and triggers.
[20:26] <skaet> pitti,  I'll be adding the publish/not status at the bottom of it,  started now.
[20:27] <skaet> will flesh it out through the day.
[20:27] <cjwatson> ScottK: there are a couple of other changes too, but I don't think they're vital for the KDE frontend.  Bug 770320 would affect you but is hardly respin-worthy on its own.
[20:28] <skaet> pitti, if you've got any data add it to the pad,  otherwise,  situation is as under control as its going to be ;)
[20:28] <pitti> skaet: no further data from me, as I just returned
[20:29] <pitti> skaet: ok, then I'll go to sleep, and come back in 8 hours
[20:29] <skaet> Thanks pitti.
[20:29] <pitti> good luck!
[20:31] <superm1> slangasek, no rush for it right now, just let it  through after b1
[20:33] <pitti> skaet: oh, forgot: kubuntu alternates still have no tests, but I'll pre-publish it now
[20:34] <pitti> at worst we re-pre-publish it
[20:34] <skaet> pitti,  ok,  but if they don't get tested,  we're not going to release them.
[20:34] <pitti> skaet: right
[20:34] <pitti> but if they are good, we have them ready
[20:34]  * skaet nods
[20:40] <ScottK> cjwatson: Thanks.
[20:45] <pitti> skaet: done
[20:45] <pitti> good night everyone
[20:45] <skaet> thanks pitti,  sleep well.
[20:47] <skaet> superm1,  you ok with the mythbuntu images that are available being shipped tomorrow?
[20:48] <superm1> skaet, yeah they're cool with me.  won't solve the oversize issue on amd64 by b1
[20:49] <ScottK> jibel: Do you have anyone that could test http://iso.qa.ubuntu.com/qatracker/result/6391/55 - I'd feel a lot better with releasing if I knew that was a "sometimes" problem and not an "always" problem.
[20:59] <bjf> pgraner, skaet, the number of bugs filed against unique systems with 2TB drives appears to be 90
[21:00] <skaet> Thanks bjf!
[21:01] <bjf> pgraner, skaet if you have any further requests, let me know, for now I'll consider this done
[21:02] <skaet> bjf,  consider it done.  :)  much appreciated.
[21:13] <jibel> ScottK, confirmed.
[21:14] <ScottK> jibel: Thanks.
[21:15] <ScottK> jibel: Confirmed it happens all the time or confirmed it's a sometimes problem?
[21:16] <jibel> ScottK, it happens all the time. create more than 2 partitions and change one, the installer crashes.
[21:16] <stgraber> ScottK: I'll have a look. I have another kubuntu-only ubiquity bug I'm looking at so I can have a quick look at this one.
[21:16] <ScottK> stgraber: Thanks.
[21:17] <ScottK> skaet: We could probably release note for Bug #838273 ^^^ if we have to, but it does concern me.
[21:17] <stgraber> jibel: did you get a trace in /var/log/installer/debug?
[21:17] <ScottK> jibel: Thanks again.
[21:17] <cjwatson> there wasn't anything obvious in the logs in the bug, that I saw
[21:18] <skaet> ScottK,  let me know if there's any chance of a respin, or if you want to hold off on the images.
[21:19] <ScottK> skaet: Let's plan on release noting, but if stgraber can find something soon/low risk we can think about it.
[21:33] <stgraber> jibel: can you give me more detail on your setup? I tried with a disk that already had 3 partitions and it worked fine here.
[21:33] <stgraber> jibel: did you start with a blank disk, then created 3 partitions?
[21:33] <jibel> stgraber, on kubuntu ?
[21:33] <stgraber> jibel: yep
[21:33] <jibel> charlie-tca, ^
[21:33] <charlie-tca> two hard drives, one is 200GB, one is 40GB
[21:34] <charlie-tca> four existing partitions on 200GB, two of which are /swap
[21:34] <charlie-tca> two partitions on 40GB, / and /swap
[21:34] <stgraber> oh, I found what's wrong with my setup. My image is 32bit. downloading 64bit now
[21:34] <charlie-tca> tried to change / on 40gb, no problem.
[21:35] <charlie-tca> clicked on the first partition on 200GB, clicked change, got thrown out of the installer
[21:37] <charlie-tca> will run it again and grab the logs if you need them?
[21:38] <cjwatson> aha, reproduced the parted bug, finally
[21:39] <cjwatson> (archdetect stubbed to print i386/mac; PARTED_GPT_APPLE=1 inserted in /lib/partman/init.d/30parted; otherwise followed directions in bug
[21:39] <cjwatson> )
[21:39]  * skaet very happy to hear reproduced.  :)
[21:42] <skaet> jibel, any problems if I go in and remove from the iso tracker, the images its clear we're not going to be releasing?
[21:42] <skaet> or should I just mark them as invalid?
[21:42] <jibel> skaet, go and remove.
[21:43] <cjwatson> I can at least say that the parted bug is definitely Mac-only
[21:43] <skaet> jibel, thanks, will do.
[21:44] <skaet> cjwatson,  *whew*   That makes me feel a lot better.
[21:44] <cjwatson> I'm not sure it does me.  There may well be more Macs than systems with >2TB disks.
[21:45] <skaet> cjwatson, yeah, but we can hold back the amd64+mac images.
[21:45] <skaet> nice identifiable affected subset.
[21:45] <skaet> not great, but better than the big ??
[21:47] <cjwatson> skaet: the amd64 images brick at least some Macs
[21:47] <cjwatson> do you really want to do that?
[21:47] <cjwatson> also, the i386 images are affected
[21:47] <ScottK> skaet: Kubuntu alternates look good.
[21:48] <skaet> cjwatson,  hmm... I misunderstood then I thought it was only Macs - are there i386 Macs?
[21:48] <cjwatson> almost any amd64 system can install using i386
[21:48] <cjwatson> (the exception being pure UEFI, but that doesn't cover Macs)
[21:49] <cjwatson> and given that historically we've tended to recommend i386 rather than amd64 for desktop systems ... (though that should be changing with multiarch)
[21:51] <skaet> Can we not say prominently in the release notes;  "These images are not intended for installation on Mac's, do not do so unless you're a developer and willing to help us debug if there are problems" ?
[21:51] <cjwatson> we could, but I think that's a pretty bad last resort
[21:51] <skaet> understand.  will let you get back to figuring it out.
[21:54] <GrueMaster> skaet: All armel testing is now complete.  Some big issues with netboot, but they can be worked around.
[21:54] <skaet> GrueMaster,  re: netboot,  will we release omap and omap4  - or just omap?
[21:54] <GrueMaster> both
[21:55] <skaet> GrueMaster,  ok, thanks.   Can you add the workaround information to the issue in the release notes?
[21:56] <GrueMaster> Already adding to the tracker.  Will add to the release notes wiki.
[21:56] <skaet> Perfect.  Thank you. :)
[21:59]  * cjwatson tests a fix
[22:00] <charlie-tca> slangasek: I don't know why or how, but ubuntustudio re-spin installs good now
[22:01] <charlie-tca> Thank you for doing the re-spin
[22:01] <cjwatson> if anyone wants to preview, the patch I'm working with is http://paste.ubuntu.com/679243/
[22:01] <cjwatson> on the grounds that Linux refuses to treat a partition table as GPT unless it has a 0xEE protective partition *starting at LBA 1*
[22:01] <cjwatson> we were failing to enforce the latter condition
[22:02] <cjwatson> so I think this only affects systems where the BIOS GRUB partition doesn't start at LBA 1; but who knows how many systems that might be, I suspect quite a few
[22:12] <cjwatson> hmm, maybe not quite right, trying http://paste.ubuntu.com/679246/ instead
[22:13] <cjwatson> brick> incidentally I'm awaiting results of a test fix for that, since obviously it's pretty bad too, but we released natty with that bug so ... :-/
[22:17] <cjwatson> ... and we need *slightly* more than that to guarantee that GRUB stays happy with the GPTness as well as Linux
[22:28] <skaet> stgraber,  https://launchpad.net/ubuntu/+source/edubuntu-live/11.08.7,  is only building i386.  Is this expected?
[22:31] <stgraber> skaet: yep, it's an arch:all package
[22:31] <skaet> stgraber,  thanks.
[22:37] <stgraber> ScottK: ok, got a crash including a stacktrace. Going to grab some dinner and I'll debug that when I'm back.
[22:37] <GrueMaster> skaet: Did you want me to document the workarounds for netboot-omap/omap4 on the pad document?  Might be easier than me trying to find the wiki page ogra usually works on.
[22:38] <skaet> GrueMaster, https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
[22:38] <GrueMaster> ok
[22:38] <skaet> If you can add it directly will save someone (ie. me) transcribing it later ;)
[22:38] <slangasek> cjwatson: so this affects all mac systems because gpt is required there, rather than just being an issue for >2TB disks?
[22:39] <cjwatson> yes, exactly
[22:39] <cjwatson> it's not an issue on non-Mac systems because it's a bug in the legacy MBR code path, which is Apple-only because we love standards and want more of them
[22:41] <cjwatson> uploaded a fix, which is http://paste.ubuntu.com/679260/
[22:41] <cjwatson> full test (insofar as I can) is still running, but I've checked that sfdisk output now looks a lot more plausible
[22:42] <cjwatson> i.e. 0xee partition first, only one of it
[22:43] <cjwatson> we'll need testing on a real Mac though, so hopefully Chad can provide that
[22:46]  * skaet nod
[22:46] <skaet> (Chad was recovering his system, not sure if its operational or not yet)
[22:46] <cjwatson> I mentioned on #ubuntu-testing that gptsync from a live CD should fix it
[22:47] <skaet> yup,  missed that post.  just saw it.
[22:48] <skaet> slangasek,  ubiquity just published to the archives,  I'll do a build with it so we have it in hand,  while waiting for parted to build/publish.   Will do respin tonight.
[22:49] <skaet> stgraber, ltsp is published, but edubuntu-live appears to have missed this cycle.   Do you want me to wait for the parted fix and respin then?  or respin when edubuntu-live publishes?
[22:49] <slangasek> skaet: ok.  anything you need from me?
[22:50] <slangasek> aside from parted review, which I'm doing now
[22:50] <skaet> slangasek,  thanks!
[22:50] <cjwatson> hm, I think given parted uploaded now, it might be more efficient to just wait for it?
[22:50] <cjwatson> well, it'll take two hours from now
[22:50] <cjwatson> (probably)
[22:50] <cjwatson> I suppose you might get two or three builds in in that time
[22:51] <skaet> cjwatson, yeah I figure I can gt the images in about an hour.
[22:51] <skaet> yeah
[22:51] <cjwatson> just don't want to burn out testers
[22:51] <skaet> I wont publish the results of the just ubiquity build, unless things go south with the parted+ubiquity one.
[22:51]  * skaet gets some insurance ready.
[22:52] <cjwatson> makes sense
[22:53] <slangasek> does parted take > 9 min to build?
[22:53] <cjwatson> about 11 mins last time on i386
[22:53] <slangasek> ok
[22:53] <slangasek> should I hold the publisher for it?
[22:53] <cjwatson> 4 mins or so on amd64
[22:53] <cjwatson> 50-odd mins on armel, 14 mins on powerpc
[22:54] <cjwatson> that might be worthwhile
[22:54] <slangasek> so worth holding the publisher for a couple mins to get it in this hour IMHO
[22:54] <cjwatson> maybe on everything !armel
[22:54]  * slangasek nods
[22:54] <cjwatson> since armel is in different antimony build passes anyway
[22:55] <skaet> slangasek if you can speed up the publisher part you have my sincere thanks.
[22:56] <skaet> slangasek,  feel free to nudge edubuntu-live along while you'r at it for parted
[22:56] <slangasek> nudge along?
[22:56] <skaet> publish
[22:56] <slangasek> it already is, unless there's another version pending?
[22:57] <skaet> hmm.. wasn't showing up on the mirror when I just checked.
[22:57] <slangasek> antimony's mirror, or another?
[22:57] <cjwatson> the mirror doesn't show anything until the publisher runs, and the publisher will publish everything that's pending (no way to make it not do so)
[22:57] <skaet> main one.
[22:57] <skaet> http://archive.ubuntu.com/ubuntu/pool/universe/e/edubuntu-live/?C=M;O=D
[22:57] <cjwatson> that's not the one antimony usses
[22:57] <cjwatson> *uses
[22:58] <slangasek> right, that's just propagation lag; it's published on cocoplum, antimony gets it from a more direct source than archive.u.c
[22:58] <cjwatson> I've heard reports of problems with archive.u.c syncing; I would not recommend relying on archive.u.c as your data source
[22:58] <slangasek> the best way to confirm antimony can see it is to tell antimony to update its mirror
[22:58] <slangasek> (hence the wait-for-package tool()
[22:58] <skaet> gotcha.
[22:59] <cjwatson> oh, wow, wait-for-package is going to do fun things if there's something else building
[22:59] <cjwatson> it doesn't respect the "build-image-set is running" semaphore
[22:59] <cjwatson> must fix that ...
[22:59] <skaet> infinity was educating me a bit about it last night, but I still have a bit to learn and some things to write.
[23:00] <infinity> cjwatson: Sadly, the issues with archive.u.c seem to go all the way back to syowa, meaning that antimony syncing from syncproxy has similar issues. :/
[23:01] <cjwatson> the way I tend to predict whether a package will be available to antimony is (a) see if LP says it's published (and not "yet to be published in the repository" or whatever it says) and (b) check 'ps -u lp_publish f' on cocoplum to make sure the publisher has actually completed, as there's a window between LP thinking it's done and it actually being on disk such that antimony can see it
[23:01] <infinity> cjwatson: I have no idea why our internal mirror world seems to have pooped itself lately, but...
[23:01] <cjwatson> infinity: jpds pointed me at https://rt.admin.canonical.com/Ticket/Display.html?id=46572 - apparently there are some hardware problems around there
[23:01] <slangasek> infinity: all the more reason to test by actually pulling the mirror down
[23:01] <slangasek> rather than using any sort of proxy metric
[23:01] <infinity> slangasek: Yeah, I've been testing by just syncing the mirrors.
[23:02] <slangasek> can someone bump the build score for parted? i386 is already built and accepted, amd64 is listed as starting in 1h
[23:02] <cjwatson> the problem with just syncing on antimony is that if a build is in progress you may cause it to have inconsistent Packages/Release files
[23:02] <infinity> slangasek: Sure.
[23:02] <slangasek> well, assuming bumping the build score will do any good and the buildds aren't just plain saturated
[23:03] <cjwatson> urgh, they're saturated
[23:03] <cjwatson> I think
[23:03] <infinity> They sure are.
[23:03] <infinity> Bumping the score brought it from > 1 hour wait to... 42 minutes.
[23:03] <slangasek> pff
[23:04] <infinity> cjwatson: I only sync when there aren't builds, since I'm syncing to see if I want to start builds.  But point taken.
[23:06] <infinity> cjwatson: Sadly, syncing from syncproxy still is leading to inconsistencies.  Were there technical reasons (or just concerns about ftpmaster's precious CPU time?) why we don't sync from cocoplum?  It's the only source that's actually guaranteed sane.
[23:06] <slangasek> should we invoke lamont --kill-build paraview/amd64?
[23:06] <skaet> ok, if we're going to be waiting on those buildds, am tempted to start building that insurance - unless it will make some things worse.
[23:07] <cjwatson> infinity: I don't remember, elmo told me to do it this way about seven years ago
[23:07] <cjwatson> slangasek: yes
[23:07] <cjwatson> if you can get hold of lamont, I haven't heard from him today IIRC
[23:07] <slangasek> lamont: ohai
[23:08] <slangasek> skaet: I don't think it will make anything worse if you're just doing a smoketest build - it will certainly finish before we need to get other builds going
[23:08] <slangasek> infinity: interpret for me - https://launchpad.net/builders/ says 3 amd64 builders, I only see 1 of them currently building a package in archive?
[23:08] <infinity> slangasek: I see 3...
[23:08] <infinity> elmo freed up crested for us.
[23:09] <slangasek> infinity: which ones?
[23:09] <cjwatson> two of them are building non-virt PPAs
[23:09] <infinity> ^
[23:09] <slangasek> ok
[23:09] <slangasek> so the ubuntu-security-proposed ones, right
[23:09] <slangasek> elmo: thanks :)
[23:09] <infinity> And canonical-kernel-team.
[23:10] <infinity> Are we going to need more emergency builds tonight?  I can toss crested on manual to avoid blocking it again.
[23:11] <infinity> (Okay, silly question, "are we going to have more unforseen issues", but whatever)
[23:13] <cjwatson> might be a good plan.
[23:13] <cjwatson> though any such uploads aren't going to come from me, unless leaning on the z key is likely to improve some unfortunate package
[23:14] <infinity> It's possible.
[23:14] <stgraber> skaet: I'm fine waiting for parted
[23:15] <infinity> For the love of... It takes longer to purge paraview's build-deps than it takes to build parted.
[23:15] <infinity> *taps foot*
[23:15] <elmo> I particularly love how we still purge the build-deps on the virtualized buildders
[23:15] <elmo> which are cow snapshots that are goiong to get thrown away anyway
[23:16] <infinity> At UDS-P, someone corner me, force beer down my throat, and get me to make abort() work.
[23:16] <infinity> elmo: I think there was once an argument that people wanted to have the "do build-deps correct remove/purge" data.  Which, of course, no one got around to exporting.
[23:16] <infinity> elmo: So, that's kinda special.
[23:16] <slangasek> in the meantime, someone want to get us a powerpc builder to go with the amd64 one (and score up parted appropriately)?  that's not as urgent though.
[23:16] <cjwatson> OK, my VM test with the updated parted passed
[23:16] <infinity> elmo: 1-line fix to just make sbuild stop doing the removal step.
[23:16] <cjwatson> for whatever that's worth
[23:17] <slangasek> i.e., if powerpc isn't going to be ready soon, I'll pull the trigger with i386+amd64
[23:17] <cjwatson> so I'm crashing now.  one of these days I want a beta where I'm not critical-path. :-P
[23:17] <infinity> cjwatson: Stop doing critical things.
[23:18] <infinity> slangasek: PPC will build in a minute or so.
[23:18] <slangasek> cjwatson: cross-train doko on parted? :) 'night :)
[23:18] <cjwatson> SMS me if the world falls over again, and I'll probably hear it
[23:18] <slangasek> infinity: ok
[23:18] <slangasek> if the world falls over, wouldn't you hear that without us needing to use SMS
[23:18] <cjwatson> not if it all does so at once, principle of relativity and all that
[23:18] <infinity> Depends on how he lands.
[23:21] <infinity> slangasek: It's possible that LP is lying to me about when I get PPC CPU time. :P
[23:21] <slangasek> that's not very sporting of it
[23:21] <cjwatson> skaet: oh FWIW, I think we should rebuild alternate for parted 2.3-6ubuntu2
[23:21] <infinity> It's a bit of a jerk that way.
[23:22] <cjwatson> I suspect we can get away without server for that
[23:22] <cjwatson> somebody should update the pad with things like which other desktops are to be rebuilt for parted 2.3-6ubuntu2
[23:22] <cjwatson> I've updated it with the version information
[23:22] <cjwatson> anyway, really gone
[23:22] <infinity> slangasek: I imagine it makes as much sense to just turn the publisher crank once parted_amd64 is uploaded, do some x86 builds, and ppc will get there later.
[23:23] <infinity> FSVO "later".
[23:23] <slangasek> infinity: except the ppc builds now trigger as part of the same job, so if it's not too long of a wait we're better off getting powerpc in at the same time
[23:24] <infinity> ARCHES="amd64 i386"; buildstuff && for-project do-stuff?
[23:24] <infinity> But we can summon elmo to buy us a PPC buildd too.
[23:25] <slangasek> the syntax is not an issue, the human time spent doing it twice is
[23:26] <infinity> *nod*
[23:26] <slangasek> however, this minute is longer than the ones I tell my wife it'll take me before I get off the computer and am ready to leave the house, so let's go with that for now
[23:26] <infinity> Getting elmo to tackle a wandering Xserve.
[23:27] <infinity> If he hasn't gone to sleep. ;)
[23:28] <infinity> Okay, adare incomine.
[23:28] <infinity> incoming, too.
[23:28] <infinity> After 7 minutes of build-dep removal...
[23:28] <infinity> Seriously.  beer.  abort().  Remind me.
[23:32] <infinity> slangasek: There.  parted/ppc building, and adare also on manual in case we need it.
[23:32] <slangasek> thanks :)
[23:33] <infinity> I sometimes wonder if we should turn davis into another PPC buildd.  How often do people actually use the porter machines?
[23:33] <infinity> Mostly, people seem to just throw stuff at the archive and pray anyway. :/
[23:33] <slangasek> I use it
[23:34] <infinity> Well, yes.  I figure a few of us do.
[23:34] <infinity> Well, I'm not in that list only because my house is littered with PPC hardware.
[23:34] <elmo> if we want to turn something into a buildd, it should be sulfur, not davis
[23:34] <infinity> elmo: Oh, we have another PPC machine hiding in the DC?
[23:34] <elmo> yeah, an openpower one
[23:35] <infinity> Oh, shiny.
[23:35] <ScottK> stgraber: Great.
[23:38] <micahg> I have more mozilla builds, do you need me to hold off on long stuff?
[23:39] <slangasek> well, we don't have an i386 buildd held in reserve yet
[23:42] <micahg> slangasek: I can wait a couple hours for the firefox/xulrunner ones, I might have some other builds though, will ask if any of them are > 20 min
[23:43] <slangasek> alternatively if we can get an i386 buildd marked manual, you wouldn't need to wait
[23:44] <infinity> I can steal one, sure.
[23:44] <infinity> There, roseapple is ours.
[23:45] <infinity> micahg: Just upload whatever.  If we screw ourselves, it's not your fault. ;)
[23:45] <micahg> infinity: heh, ok, thanks, I have to wait a bit on those builds anyways as there might be a respin of the respin :-/
[23:47] <infinity> Of the respin of the respin of the respi...
[23:47] <infinity> *head explodes*
[23:47] <slangasek> mmk, parted builds all done, so we can run the publisher again right after this finishes
[23:47] <slangasek> micahg: hmmm?  Point is we have buildds reserved now, so we won't trip over any builds you queue
[23:47] <infinity> ^
[23:48] <micahg> slangasek: no point for you :), just mumbling...
[23:48] <slangasek> micahg: I don't understand your "I have to wait a bit on those builds anyways"
[23:48] <micahg> slangasek: wait to upload
[23:48] <slangasek> yes, why do you?
[23:48] <micahg> slangasek: I don't want to upload then repackage and upload build2 :)
[23:49] <slangasek> do you mean that they're builds for oneiric?
[23:49] <slangasek> oh, you mean respins of the source
[23:49] <slangasek> not of images
[23:49] <micahg> slangasek: yes
[23:49] <slangasek> I didn't know packages spun, only CDs :)
[23:49] <micahg> Mozilla's good at spinning :)
[23:49]  * slangasek coughs
[23:51] <infinity> I propose we change the verb used for creating CD images from "spin" to "twirl" for the next release week.
[23:51] <infinity> "Can you twirl me a new xubuntu-desktop?" just sounds like it would add levity.
[23:57] <slangasek> skaet: parted publishing for i386/amd64 done; powerpc pending publication