[00:04] <slangasek> cjwatson: have you confirmed these are the only two udebs with the problem and things won't fail further down the line?  I guess we don't have udebs in Contents
[00:04] <slangasek> libxcb fix committed, building to verify
[00:06] <doko> populate-archive now running for 1h, not sure if I will wait ...
[00:07] <slangasek> how long does it usually take?
[00:07] <cjwatson> slangasek: Debian does, we don't, unfortunately
[00:07] <cjwatson> I might be able to cruft together a brute-force scan
[00:08] <cjwatson> we don't have that many udebs ...
[00:08]  * slangasek nods
[00:08] <slangasek> libxcb uploaded, after I stopped typoing it as 'xkcb'
[00:09] <slangasek> did your bzr checkout clear?  if not, I have a local checkout
[00:09] <cjwatson> it did, I'm test-building now
[00:09] <slangasek> ok
[00:09] <slangasek> sorry for the hassle :/
[00:10] <cjwatson> -rw-r--r-- root/root     15544 2011-03-25 04:47 ./usr/lib/i386-linux-gnu/avahi/service-types.db
[00:10] <cjwatson> pool/main/a/avahi/libavahi-common3-udeb_0.6.29-0ubuntu2_i386.udeb
[00:10] <cjwatson> is the other one - apparently not actually a library though
[00:10] <slangasek> yep
[00:10] <slangasek> just arch-dep gdbm database file
[00:10] <cjwatson> the library itself is in /usr/lib
[00:10] <cjwatson> so that won't break mklibs
[00:10]  * slangasek nods
[00:10] <cjwatson> everything else on i386 is clean
[00:11] <doko> I remember taking it about 1h the last time
[00:11] <cjwatson> ... and amd64 armel powerpc
[00:21] <cjwatson> slangasek: does http://paste.ubuntu.com/586660/ look OK?  slightly clunky ...
[00:22] <slangasek> I thought about just changing the install path in the .install.in file for the library and leaving the modules in the multiarch path; mklibs doesn't need to poke at the modules, does it?
[00:23] <slangasek> your way looks correct to me as well, but it is clunky as you say
[00:23] <cjwatson> it seems as though it ought to consider symbols in them for reduction
[00:23] <slangasek> ok
[00:23] <cjwatson> if a pango module is the only thing that uses some symbol ...
[00:23] <cjwatson> (I'm not certain whether it does right now, but it ought to if it doesn't :-) )
[00:24] <cjwatson> ah, it does, they show up in mklibs output
[00:24] <slangasek> ok
[00:24] <slangasek> I'll accept this if you upload it :
[00:24] <slangasek> )
[00:30] <cjwatson> slangasek: done.  I used your changelog entry from libxcb though, since it was better-worded ... :-)
[00:30] <slangasek> heh, ok :)
[00:30] <cjwatson> slangasek: would you mind giving d-i back once those two have been published?  I'll be asleep by then, I hope
[00:31] <slangasek> can do
[00:53] <cjwatson> could somebody look at gfxboot-theme-ubuntu 0.11.3, please?
[01:02]  * cjwatson -> bed
[01:18] <hyperair> hi
[01:18] <hyperair> is it too late to upload something for beta1?
[01:23] <hyperair> slangasek: ping
[01:23] <slangasek> hyperair: hi there
[01:24] <hyperair> slangasek: hi. i'd like to upload banshee 1.9.6 for natty. is it too late for that?
[01:24] <slangasek> "Too late to upload something for beta1" - technically no, but it hopefully has a good reason :)
[01:24] <hyperair> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/736631
[01:24] <hyperair> this bug.
[01:24] <ubot4`> Launchpad bug 736631 in banshee (Ubuntu) "External devices not recognised at all (affects: 10) (dups: 2) (heat: 60)" [High,Fix committed]
[01:24] <slangasek> what else is in the new upstream version?
[01:24] <hyperair> i accidentally broke the build of the gio hardware backend, so nothing gets detected
[01:25] <slangasek> "new upstream version" usually implies "feature freeze exception needed"
[01:25] <hyperair> http://pastebin.com/9x4YUJws
[01:25] <hyperair> that's the relevant changelog entry
[01:26] <hyperair> in banshee's case, i'm planning to get 2.0 into natty, but that'll be after beta.
[01:26] <hyperair> banshee's following the GNOME release schedule, and 1.9.6 is the current unstable version -- 2.0 is the next stable
[01:27] <slangasek> 9 entries listed under "enhancements" - sorry, I'm not willing to accept a freeze exception like this the week of beta; if you think 736631 should be fixed for beta1, please backport
[01:27] <hyperair> alright, thanks
[01:27] <slangasek> (unless skaet has a different opinion on this)
[01:27]  * skaet looking
[01:32] <skaet> hyperair, I agree with slangasek,  file it in as a FFE and target it to beta-2.    Its a bit late for beta-1 now.
[01:33] <hyperair> skaet: alrigt.
[01:34] <hyperair> skaet: there's also the 2.0 release coming up in april
[01:34] <skaet> hyperair,  do you know when?
[01:34] <hyperair> tarball due on 4th
[01:35] <hyperair> should have relatively minor changes, so the package should be ready for upload within the next day or so
[01:35] <skaet> hyperair, that will fit into the beta-2 window nicely.
[01:35] <hyperair> alright. thanks.
[01:36] <hyperair> skaet: so should i file two FFEs, or will one suffice?
[01:37] <skaet> hyperair, file one FFE for the 2.0 version.  Unless there's a very good reason to take the other one before.
[01:37] <hyperair> alright.
[01:39] <hyperair> well, i'll be going. slangasek, skaet, thanks for the help!
[01:40] <skaet> hyperair, thanks for bringing it forward.  :)
[01:43]  * skaet toddles back to editing release notes....
[02:08] <slangasek> cjwatson: hmm, strange new failure with the new libpango, "Depends: libthai0 (>= 0.1.12) but it is not installable" - digging in
[02:17] <slangasek> got it, moving the files back to /usr/lib caused binary-install/$(UDEB_PKG) to fail to remove pango-thai-lang.so
[02:24] <slangasek> if anyone wants to review pango1.0 in the queue in about 5 minutes, be my guest; otherwise I'll self-accept to make sure it gets in before the no-publisher window
[02:24] <kirkland> slangasek: i can, if you like
[02:25] <kirkland> slangasek: elseways, go for it
[02:26] <slangasek> up to you
[02:31] <slangasek> kirkland: ^^ you reviewing, or shall I accept directly?
[02:32] <kirkland> slangasek: i'm already on it, looks good
[02:32] <kirkland> slangasek: component/section/priority?
[02:32] <kirkland> slangasek: i'll leave as is
[02:33] <kirkland> slangasek: OK: pango1.0
[02:33] <slangasek> nothing should be changed, this isn't a NEW package...
[02:33] <kirkland> slangasek: done
[02:34] <slangasek> thanks
[02:35] <slangasek> should build in plenty of time to get into the next publisher cycle, good
[03:02] <skaet> :)
[07:57] <pitti> Good morning
[08:30] <mvo> the python-apt is a nice-to-have but its perfectly fine if its not on the cd
[08:34] <pitti> mvo: it does cause a ton of jockey crashes, though
[08:34] <pitti> mvo: thanks for fixing that (and kudos to barry for debugging)
[08:36] <mvo> yeah, all credit goes to barry
[08:36]  * mvo hugs barry
[08:40]  * pitti accepts the slideshow as well
[08:40] <pitti> as we didn't get the split cairo in, I'll chop off a small langpack from i386 to fix oversizedness
[08:40] <pitti> (cairo will land after b1)
[09:34] <cjwatson> slangasek: thanks for cleaning up pango1.0
[09:35] <cjwatson> damn, I should have caught that in debc :-/
[09:36] <cjwatson> if that bind9 upload is what I think it is, it has to be in the server images we ship, IMO (http://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record)
[09:36] <cjwatson> reviewing
[09:36] <cjwatson> oh, no, different bug
[09:37] <cjwatson> OK, that's low-priority, I think I'll leave it
[09:37] <pitti> the dnssec one is much more urgent for lucid/maverick at this point
[09:37] <pitti> still figuring out the SRUs
[09:39] <cjwatson> that dnssec bug is already fixed in natty, good
[09:39] <pitti> cjwatson: do you think we'll need to fix bug 717404  for b1?
[09:39] <ubot4`> Launchpad bug 717404 in ubiquity (Ubuntu) "ubiquity-dm crashed with IOError in command(): [Errno 32] Broken pipe (affects: 2) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/717404
[09:39] <cjwatson> pitti: see my comments at the end of that bug
[09:39] <cjwatson> that's Fabio Marconi being scattershot in his bug handling
[09:40] <cjwatson> I suspect that the original bug is no longer relevant
[09:40] <pitti> ah
[09:40] <pitti> I saw them, but I didn't know yet how urgent the original one was
[09:41] <pitti> cjwatson: I dropped the bn langpack from i386 live seed to work around the oversizedness, FYI
[09:41] <pitti> still needs to trickle through soyuz, I guess
[09:42] <pitti> slideshow and python-apt are currently being published
[09:55] <cjwatson> it was processed by the cron.germinate run that just happened, and there's stuff to be published, so it'll hit the archive in <1hr
[09:58] <seb128> is the current iso worth testing or are respins coming in the next hours?
[09:58] <pitti> I'd say "both"
[09:58] <seb128> ok
[09:58] <pitti> seb128: the new iso is by and large "newer slideshow, fixed python-apt for jockey crash, not oversized any more on i386"
[09:59] <Daviey> Hi, what was the reasoning for server spin 20110329 ?
[10:01] <cjwatson> cron
[10:02] <cjwatson> and whatever packages were accepted between the previous build and that one; at minimum it includes a refreshed installer with the current kernel
[10:02] <Daviey> ah ok.. has the uninstallable packages in powerpc been noticed?  It's new in the report.html from the previous spin.
[10:02] <Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/20110329/report.html
[10:03] <cjwatson> nope, I'll check on that
[10:04] <cjwatson> hm, ubiquity build failures on armel and powerpc
[10:04] <Daviey> oh joy.
[10:05] <cjwatson> Evan mentioned something which I now see was related to that
[10:06]  * cjwatson has a poke
[10:08] <Daviey> groovy.
[10:09] <cjwatson> 01:28 <ev> *grumbles about having hardcoded an efi question despite having constructed the facilities to find the correct platform-specific ones*
[10:09] <cjwatson> 01:28 <ev> tomorrow though
[10:09] <Daviey> heh
[10:10] <Daviey> cjwatson, At which point should we be considering a serious candidate for B1?  Are we switching to manual spins soon?
[10:11]  * ev waves
[10:11] <ev> yes, the build failure is due to a poorly constructed test
[10:18] <Daviey> ev, do you have access to power and armel hardware to test this on?
[10:19] <cjwatson> ev: testing a fix now
[10:19] <cjwatson> Daviey: all platform team members do
[10:19] <ev> cjwatson: brilliant
[10:19] <cjwatson> Daviey: sometime today
[10:19] <ev> we do? Is this on the wiki somewhere?
[10:19] <Daviey> cjwatson, the porter boxes?  for installing?
[10:19] <cjwatson> https://wiki.canonical.com/MachineOverview
[10:20] <cjwatson> actually nowadays it's porter-$arch.canonical.com
[10:20] <cjwatson> (except that $arch is ppc rather than powerpc, but ...)
[10:20] <cjwatson> Daviey: sufficient to run the ubiquity test suite
[10:20] <ev> oh nice
[10:21] <pitti> ev: note that in the chroots you can do sudo apt-get install <package>
[10:21] <ev> noted; thanks
[10:21] <Daviey> cjwatson, ah.. ok..  The concern i have is that our team will not be testing the ISO's for power and arm... and i don't think the QA team are in a better situation.
[10:22] <cjwatson> sure, separate problem from this.
[10:22] <Daviey> ack
[10:53] <cjwatson> can somebody review ubiquity?  the sooner the better so that we can get architectures back in sync
[11:16] <Riddell> cjwatson: looking
[11:18] <Riddell> accepting
[11:19] <cjwatson> thanks
[11:22] <iulian> Good morning.
[11:22] <iulian> Could someone please also accept at-spi2-core?
[11:25] <Riddell> iulian: accepted
[11:25] <iulian> Ta.
[11:25] <Riddell> iulian: I take it at-spi2 isn't going to be default in natty?
[11:26] <iulian> Riddell: No, it's not, as far as I know.
[11:26] <pitti> cjwatson: hm, http://cdimage.ubuntu.com/daily-live/20110329/ is still oversized, seems this was built before the -bn langpack drop was published?
[11:27] <Riddell> I've dropped a language pack from the kubuntu live seed to get kubuntu undersized
[11:28] <cjwatson> pitti: it would have been
[11:28] <cjwatson> ought to wait for new ubiquity, though
[11:29] <cjwatson> iulian: blah, sorry, I reviewed it and thought I'd accepted it along with -atk
[11:29] <cjwatson> pitti: the builds were just from cron today
[11:29] <pitti> ah; I got a tracker notification
[11:29] <cjwatson> that wasn't me
[11:31] <iulian> cjwatson: No worries. :)
[11:40] <Riddell> I got a personal notification from a Jean-Baptiste asking for testing
[11:48] <cjwatson> Riddell: that's jibel
[12:12] <NCommander> morning all
[12:32] <jibel> where are the images for u-headless, k-desktop and x-desktop on armel/imx51 ? I cant find them on cdimages
[12:43] <ogra_> jibel, nobody implemented support for mx51 yet
[12:46] <ogra_> (on the image builders or in livecd-rootfs)
[13:10] <jibel> ogra_, oh well, skaet https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts should be updated accordingly
[13:14] <bdrung> can you please reject this upload?
[13:23] <cjwatson> bdrung: is it yours?
[13:23] <bdrung> cjwatson: yes
[13:24] <cjwatson> bdrung: done
[13:24] <cjwatson> ah, ubiquity 2.5.32 has published now
[13:24] <cjwatson> does anyone have anything else that needs to go into a respin?
[13:24] <Daviey> bdrung, Just out of curiosity, what was wrong with it?
[13:25] <cjwatson> (publisher is still running, so you have a few minutes to answer)
[13:25] <bdrung> the debian changlog entry was missing
[13:25] <Daviey> cjwatson, Just two moments, want to check if a package is seeded or not.
[13:28] <Daviey> cjwatson, I'm happy.
[13:28] <cjwatson> Daviey: which package?
[13:29] <Daviey> cjwatson, keepalived .. rdepends of ipvsadm
[13:29] <Daviey> Really not essential, to hold back a beta.. therefore not for a spin IMO.
[13:30] <cjwatson> well, should I respin server or not?
[13:31] <Daviey> cjwatson, yes please.
[13:31] <cjwatson> server running now, since the Ubuntu DVDs are currently building from cron so live images have to wait for that to free up
[13:32] <Daviey> super
[13:34] <bdrung> ^ that's the correct one
[13:43] <ScottK> jibel: I didn't get mx.51 sorted yet, but I'm hoping for permission to do it next week, so please don't delete them from the wiki page yet.
[13:44] <ScottK> bdrung: Since it's on the Mythbuntu ISO, it should wait until after Beta 1 unless it's got a critical fix.
[13:45] <ScottK> bdrung: If it does, please coordinate with the Mythbuntu folks and see if they want it for Beta 1.
[13:45] <jibel> ScottK, deleting it was not my intention, just adding a note on the wiki to indicate the status of the image.
[13:45] <cjwatson> ScottK,bdrung: it only changes versions of build-dependencies
[13:45] <ScottK> jibel: OK. That's fine.
[13:46] <ScottK> cjwatson: Right, I see that now.  I certainly can wait.
[13:46] <cjwatson> (so doesn't seem like it can be critical)
[13:46] <ScottK> Agreed.
[13:46] <bdrung> ScottK, cjwatson: yes, this upload can be hold until after the beta. i wasn't aware that it's on the mythbuntu iso
[14:24] <Riddell> ScottK: update for kubuntu mobile if you fancy reviewing ^^
[14:24] <ScottK> Riddell: Waiting for the diff.
[14:43] <Riddell> cjwatson: shall I remove desktop images from the ISO tracker?
[14:44] <cjwatson> no particular need to remove them, but I'm rebuilding them
[14:54] <skaet> cjwatson, ALL images being rebuilt now? (ie. should all on the iso tracker get marked as disabled for now)
[14:54] <skaet> or just the desktop ones
[14:54] <skaet> ?
[14:55] <cjwatson> server wanted a respin anyway, so I guess the lot
[14:55] <ScottK> cjwatson: Due to ^^^ if you can do Kubuntu last we might have that in by then.
[14:55] <cjwatson> there weren't many tests completed on the tracker so I wasn't worrying about it
[14:55] <cjwatson> ScottK: ok
[14:55] <ScottK> It's only essential for Kubuntu Mobile, but if we can get it on the others, so much the better.
[14:57] <cjwatson> Most images have Jockey, so that python-apt crash fix is a good thing to get in across the board, even aside from getting the installer in sync everywhere.
[15:00] <skaet> cjwatson, ok,  have marked all actual images on the iso tracker as disabled for now.
[15:00] <cjwatson> skaet: note that I'd already posted server
[15:00] <cjwatson> (20110329.1)
[15:01] <skaet> urk
[15:01] <skaet> undoing.
[15:02] <skaet> cjwatson, ok, server's back.   one question, would any of the changes made affect the upgrade tests?   Am wondering if the results are ok there, or if they need to be redone too.
[15:06] <cjwatson> skaet: can never be certain, but I think a substantive effect on upgrade tests is unlikely
[15:08] <skaet> cjwatson, thanks,  will suggest to jibel redoing them then with latest images can be deprioritized until after the rest of the testing.
[15:11]  * pitti pats http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- I don't think we've ever been that good for beta-1
[15:21] <cjwatson> mvo: update-manager saying beta - does that need to be in images, or is it in the server-side component?
[15:25] <mvo> cjwatson: server side is good enough
[15:25] <mvo> cjwatson: I do that now
[15:25] <cjwatson> oh good
[15:26] <cjwatson> Daviey: the server image is going to need a quick respin because I forgot to update the volume label to say Beta 1 rather than Alpha
[15:26] <cjwatson> doing that right now
[15:27] <skaet> Daviey, cjwatson - have marked 20110329.1 server as disabled
[15:29] <ScottK> stgraber or highvoltage: Is ^^^ needed for beta 1?
[15:29] <highvoltage> ScottK: ideally, yes, since it affects a UI change and should rather be done sooner than later
[15:29] <highvoltage> ScottK, skaet: https://bugs.launchpad.net/ubuntu/+source/edubuntu-live/+bug/745000
[15:29] <ubot4`> Launchpad bug 745000 in edubuntu-live (Ubuntu) "UIFe: Edubuntu installer Ubiquity Description (affects: 1) (heat: 6)" [Low,In progress]
[15:30] <ScottK> I guess it depends a bit on where we are on respins.
[15:30] <stgraber> It could be accepted and if we end up respinning, then we'll have it. I don't think it's worth a respin just for that.
[15:30] <highvoltage> ScottK: ok. it's low priority so if if would cause any inconvenience, then it can certainly wait until after beta
[15:31] <cjwatson> edubuntu is several hours off by way of respins
[15:31] <cjwatson> accepting this won't cause an image building problem
[15:31] <ScottK> I'll review it then.
[15:32] <stgraber> thanks
[15:32] <ScottK> Once LP makes the diff ...
[15:32] <skaet> ScottK,  thanks - I thought it was just text change.
[15:32] <Daviey> cjwatson / skaet, thanks
[15:32] <ScottK> I'll find out once there's a diff.
[15:33] <skaet> ScottK,  I put approved in there, but if its more than that and there's risk, please judge appropriately.
[15:33] <ogra_> ScottK, i have some skeleton stuff for mx51 already btw, but will need more info about the HW and some testing on your side, lets sit down next week and take a look
[15:33] <stgraber> it's supposed to just be a text change in debian/templates. If there's something else, feel free to reject as that'd be a mistake :)
[15:33] <cjwatson> cdimage cron jobs disabled
[15:33] <ScottK> ogra_: I'll be glad to.
[15:34] <highvoltage> thanks ScottK
[15:37] <stgraber> ScottK: http://launchpadlibrarian.net/67595025/edubuntu-live_11.03.3_11.03.4.diff.gz
[15:37] <ScottK> Yep.  Got it.
[15:38] <ScottK> Looks good.  Accepted.
[15:39] <skaet> cool  :)
[15:40] <stgraber> yeah! thanks
[15:46] <slangasek> cjwatson: n/p (pango1.0)
[15:57] <cjwatson> Ubuntu server, alternate, desktop posted
[15:59]  * ScottK consideres that perhaps any test result that doesn't reference at least one new or existing bug should be considered invalid.  No upgrade is perfect.
[15:59] <ScottK> (upgrade or install - the case I just did was an upgrade)
[16:19] <doko> slangasek: that's what I'm uploading, doesn't have to be on the images. http://paste.ubuntu.com/586916/
[16:21] <slangasek> doko: "$(dir $(libdir))" grabs the parent directory of $(libdir)?
[16:21] <doko> yes
[16:21] <slangasek> ok
[16:21] <slangasek> looks like what we want, then
[16:21] <doko> checked with a test build
[16:25] <slangasek> module-init-tools (pre-)reviewed, looks good to me; where are we on image building?  This probably isn't critical enough to force a respin but it's definitely good to have if there's time
[16:26] <cjwatson> somewhat into building
[16:26] <tgardner> slangasek, huh, I was just about to drop a note to skaet about that very thing.
[16:26] <cjwatson> (Ubuntu server, alternate, desktop done; Xubuntu alternate done; Xubuntu desktop building; others to come)
[16:27] <slangasek> cjwatson: do you want to add m-i-t to your "if there's a chance" queue?
[16:27] <slangasek> tgardner: we have a bot that notifies us of pending packages :-)
[16:27] <cjwatson> sure
[16:28] <ogra_> cjwatson, headless too please, once you get to armel
[16:29] <cjwatson> everything is on the list
[16:29] <ogra_> great, thanks
[16:35]  * pitti wonders what the "free software only" option means these days -- is it just about adding restricted/multiverse apt sources? I don't think we actually install any non-free stuff by default any more, not drivers, not linux-firmware-nonfree
[16:35] <pitti> (unless you tick the checkbox in the installer)
[16:38] <doko> skaet, slangasek: rebuild tests started for armel, i386, amd64
[16:38] <cjwatson> it controls the apt sources, yes
[16:38] <cjwatson> it also suppresses the appearance of that installer checkbox
[16:38] <cjwatson> so it's easy to build an installer image that doesn't offer non-free software
[16:39] <slangasek> doko: great :)
[16:39] <pitti> cjwatson: ah, thanks; but unless you tick anything in particular, a default install only has free stuff now, right?
[16:43] <slangasek> doko: what's the link for the amd64/i386 archive rebuild?
[16:44] <doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20110329
[16:44] <doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20110329-arm
[16:44] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-arm-natty.html
[16:45] <doko> the other overview page isn't there yet until wgrant wakes up, or we wake him up =)
[16:48] <slangasek> no problem :)
[16:53] <slangasek> doko: and lp:svammel should be ready now-ish, so we'll be able to use that for autofiling bug reports about build failures
[16:55] <doko> does it catch duplicates?
[16:57] <slangasek> doko: https://wiki.linaro.org/MattiasBackman/Sandbox/SvammelUsage,
[16:57] <slangasek> , https://wiki.linaro.org/Platform/Infrastructure/Specs/BuildFailureBugFiling
[16:58] <slangasek> the infrastructure team has said "yes" - I haven't tested it in a live fire situation yet :)
[17:02] <cjwatson> pitti: I believe so
[17:05] <jibel> cjwatson, can we reopen ubuntu dvds for testing ?
[17:13] <cjwatson> no, but I can build them asap
[17:40] <lamont> skaet: (et al): new launchpad-buildd that has natty-toolchain compatible detection of 64-bit pointers converted to ints rolling out sometime todayish
[17:40]  * lamont tosses louvi back where it belongs
[17:41] <skaet> lamont, can we wait until after this set of images for the release finishes building?
[17:41] <skaet> cjwatson, ^^?
[17:41]  * skaet feeling a bit worried about possible variable changes at this stage.
[17:42] <lamont> skaet: the total change is to the regex where we look at the log and say "no, you didn't actually succeed like you think you did, you really failed"  I can certainly wait until beta is out before I push it out if you want
[17:43] <lamont> the exposure is that things think they fail, and then die on users' machines with SIGSEGV/SIGBUS due to bad compiles that the compiler decides should be warnings, when they really are failures
[17:44] <lamont> to make matters more amusing, they only sometimes fail on amd64, since the upper 32 bits of pointers are most frequently all zeros.  just not always
[17:44]  * skaet feels a bit better after that explanation.
[17:46] <cjwatson> I don't have a problem with that rollout - it won't affect CD image builds, anyway
[17:46] <cjwatson> although I'd like any current builds not to be restarted in the process :-)
[17:47] <skaet> cjwaton,  cool.   lamont can you wait until the current set is finished, and then we'll let you know when the coast is clear?
[17:47] <lamont>   [ various ]
[17:47] <lamont>   * ProjectGroup.products sort order and remove Author: comments.
[17:47] <lamont>   * Fix some tests to not print stuff
[17:47] <lamont>   * Make buildd pointer check regexes work on natty
[17:47] <lamont>   * merge before rollout + text conflict patch by wgrant
[17:47] <lamont> https://bugs.launchpad.net/launchpad-buildd/+bug/719162
[17:47] <ubot4`> Launchpad bug 719162 in launchpad-buildd "[Natty] check-implicit-pointer-functions fails on natty, resulting possibly broken packages (affects: 1) (heat: 6)" [Critical,Fix committed]
[17:48] <lamont> cjwatson: yeah - I'll wait for your all-clear, or beta
[17:48] <lamont> because yeah, totally gonna just romp it all over the build farm when it rolls.
[18:12] <skaet> ScottK, pitti, cjwatson, (and all interested) - have updated https://wiki.ubuntu.com/NattyReleaseSchedule  will broadcast out to u-d later today so would appreciate a quick review.
[18:13] <slangasek> doko: I remembered that bug #741949 should also be fixed in eglibc; I'll cook a patch and send another upload to the queue and reject yours
[18:13] <ubot4`> Launchpad bug 741949 in eglibc (Ubuntu Natty) (and 1 other project) "libc6-i386 co-installed with libc6:i386 breaks ia32-libs (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/741949
[18:21] <doko> slangasek: ok, thanks
[18:32] <cjwatson> I've queued up everything else for build apart from Kubuntu/armel (which is waiting for kdebase-workspace/armel to build)
[18:33] <cjwatson> dinner
[18:45] <ogra_> skaet, beta freeze on 11th now ?
[18:46] <ScottK> skaet: I think it's fine.
[18:47] <skaet> ogra_, yes that was the best compromise point
[18:47] <ogra_> skaet, heh, k, i'm sure the unity-2d guys wont like that, they just confirmed the 13th with me today as final upload date for bugfixes
[18:48] <ogra_> i'll forward the 11th
[18:54] <skaet> thanks ogra_
[18:55] <smoser> cjwatson, or slangasek or skaet could someone load the iso tracker with http://uec-images.ubuntu.com/server/natty/20110329/published-ec2-daily.txt
[19:00] <skaet> smoser, to confirm - you're not expecting the links to work from the iso tracker, just using it to record the results?
[19:02] <smoser> we need the amis populated into the table. (post-amis-to-iso-tracker)
[19:02] <smoser> lp:~ubuntu-archive/ubuntu-archive-tools/trunk/
[19:02] <slangasek> ScottK: ^^ should fix the armel problem
[19:03] <skaet> smoser, ack.
[19:03]  * skaet sees if she can get that script working again
[19:06] <ScottK> slangasek: Cool.  At this point we should probably wait until after Beta 1 don't you think?
[19:06] <ScottK> Riddell: ^^^
[19:06] <slangasek> ScottK, Riddell: your call entirely
[19:06] <ScottK> I guess it depends on how much we care about having some out of date packages on the images.
[19:06] <ScottK> Riddell: ^^^?
[19:17] <zul> is the nertboot images still being respun?
[19:18] <cjwatson> netboot?  no
[19:18] <cjwatson> that shouldn't have been marked as rebuilding
[19:18]  * cjwatson goes to fix
[19:19] <doko> doesn't start too good ... https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+builds?build_text=&build_state=failed
[19:22] <slangasek> eh, binutils?
[19:22] <slangasek> is that the same transient build failure as before?
[19:23] <slangasek> bind9 is a multiarch failure, sigh
[19:23] <slangasek> stupid manual build-time probing
[19:23] <doko> we either need to link it statically, or change the soname
[19:23] <doko> for every upload
[19:23] <slangasek> so this is a general binutils problem?
[19:24] <slangasek> apturl is weird; I swear I didn't break /usr/share/omf ;P
[19:25] <doko> heh ...
[19:51] <skaet> smoser, jibel,  there are some images in http://uec-images.ubuntu.com/server/natty/20110329/published-ec2-daily.txt that are not registered in the iso tracker.   Specifically looks like ap has split to northeast and southeast.
[19:54] <skaet> jibel, can you make the changes to the isotracker to add the new ones ( northeast ) and clarify the others (add southeast)
[19:54] <skaet> jibel_, ^^
[20:03] <smoser> skaet, 'southeast' is "Asia Pacific"
[20:03] <skaet> slangsek, cjwatson, smoser - am going to need to wait on jibel to get some numbers to use in the iso tracker (tablenumbers) before I can get the script working to pick up the new northeast images.
[20:04] <skaet> smoser,  yup,  that's what's there now, so appears to be what isotracker is mapping to now.
[20:04] <skaet> smoser, do you want me to edit out the northeast and publish the rest right now?
[20:04] <skaet> then come back to them later when we hear from jibel?
[20:05] <smoser> sure.
[20:08] <ScottK> slangasek: Any thoughts on what we can do about Bug #744944?
[20:08] <ubot4`> Launchpad bug 744944 in kdebase-workspace (Ubuntu Natty) (and 1 other project) "kdm is restarted during the upgrade to Natty . The user is disconnected from the session (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/744944
[20:08] <ScottK> It's the PAM service restart that's doing it.
[20:08] <slangasek> hum. has kdm regressed?
[20:08] <ScottK> Something has regressed.
[20:08] <slangasek> or maybe it doesn't play nicely after the switch to upstart
[20:09] <ScottK> There's no debconf prompt for the restart.  Just happens.
[20:09] <ScottK> I'm guessing if I'd done a command line upgrade I'd have been asked like I was for my server upgrade I did earlier today.
[20:09] <slangasek> yes, that's per previous feedback that when doing upgrades with the default GUI upgrader, and the default set of services are running, there should be no prompting... but that was predicated on the assumption that the restart wouldn't break the GUI itself
[20:10] <slangasek> so there are two possible solutions here
[20:10] <slangasek> one is that kdm may have evolved to the point where a pam upgrade doesn't break it because the authentication is done by a helper process that's launched at authentication time; if someone can confirm that this is the case, we can drop kdm from the list of services to restart
[20:11] <cjwatson> Kubuntu alternate, Kubuntu desktop, and Kubuntu mobile i386 posted
[20:11] <slangasek> another is that we find a different "restart" option for kdm that's graceful and lets kdm reload libpam from disk, without restarting the current session
[20:11] <slangasek> (the third option is to have to prompt on upgrade, but that's unsatisfactory; "is it ok to kill your session now?" is not a very elegant question)
[20:12] <skaet> smoser,  can you check all except the northeast are accessible now?
[20:13] <ScottK> slangasek: Is there some "It's an upgrade, don't restart KDM because they have to reboot at the end anyway" option?
[20:13]  * skaet --> grab some lunch,  biab
[20:14] <slangasek> ScottK: unless kdm implements 1), that carries the risk that if anything goes wrong during the upgrade and they're logged out, they won't be able to log back in to finish the upgrade and the system may not be in a bootable state at that point (because who knows what state the packages are in)
[20:14] <slangasek> so I'd really prefer not to do that, from a robustness standpoint
[20:14] <ScottK> Could that get us through beta 1?
[20:14] <ScottK> Because currently getting logged out is a sure thing.
[20:15] <ScottK> Riddell: ^^^?
[20:15] <slangasek> yes, though at least you're guaranteed to be able to log back in to cleanly shut the system down
[20:15] <slangasek> we can do that as a stopgap
[20:15] <ScottK> Worst case you can switch to a VT and login that way.
[20:16] <ScottK> Obviously not suitable for final, but for beta should be ~OK.
[20:16] <slangasek> if someone who has kubuntu running could tell me if the main/parent kdm process has libpam loaded into memory, maybe we can short-circuit and just go with fix #1
[20:16] <ScottK> I have it running.  How do I find that out?
[20:16] <slangasek> lsof -p $pid | grep pam
[20:17] <ScottK> Where $pid is kdm's pid?
[20:18] <slangasek> yes
[20:19] <ScottK> Returns nothing.
[20:19] <slangasek> ok, then we should be able to drop it from the service restart list altogether
[20:19] <slangasek> (not just as a temporary fix for beta)
[20:19] <slangasek> are you looking to get this on images, or just in the archive for upgrades?
[20:19] <slangasek> (if I have a little time, I have another multiarch-related upgrade fix I'd like to include)
[20:19] <ScottK> I'd say just in the archive fo upgrades.
[20:19] <ScottK> fo/for
[20:21] <slangasek> ok; will get that together later today
[20:21] <slangasek> ok for me to reassign the bug to libpam, or do you need a task open on kdebase-workspace to collect dupes?
[20:23] <ScottK> slangasek: I think it's fine to reassing.
[20:23] <ScottK> gn/ng
[20:24] <ScottK> stgraber or highvoltage: I'd really like to get ia32-libs updated before beta, but it's in the Edubuntu package set ...
[20:27] <stgraber> hmm, what ? :)
[20:27] <stgraber> ia32-libs in the edubuntu package set ? fun
[20:28] <highvoltage> ScottK: what's the update, btw?
[20:28] <ScottK> http://launchpadlibrarian.net/67613251/ia32-libs_20090808ubuntu10_source.changes
[20:29] <ScottK> Getting the newer drm in will allegedly help a lot with crashes from using an old drm in ia32-libs with flash.
[20:29] <ScottK> Plus the more multiarch the better.
[20:29] <ScottK> stgraber: I've assumed it's on your amd64 dvd.  Is that not the case?
[20:29] <stgraber> ScottK: I just checked and we don't ship it :)
[20:29] <ScottK> OK.
[20:30] <stgraber> it's not in any of our .manifest or .list, so I'm not really sure how it ended up being in our package set
[20:30] <ScottK> Then I'll treat it like unseeded Universe then.
[20:30] <stgraber> ScottK: sure, go ahead !
[20:30] <stgraber> cjwatson: ^ any idea ?
[20:31] <ScottK> Done.
[20:31] <cjwatson> desktop-gnome.build-depends_edubuntu_natty_amd64:ia32-libs                                 | ia32-libs                         | wine1.2 (Build-Depend)                     | Ubuntu Developers<EMAIL_ADDRESS>    |        33345206 |          143224
[20:31] <cjwatson> looks like it's only there for build-depends
[20:33] <stgraber> ok, I think I got it
[20:33] <stgraber> we ship ttf-symbol-replacement which is a binary package of wine1.2 which itself build-dep on ia32-libs :)
[20:34] <stgraber> so even if ScottK breaks ia32-libs it'd only be an issue if we rebuild wine1.2 and that'd only affect Edubuntu if ttf-symbol-replacement actually uses ia32-libs (which is very very unlikely for a font package)
[20:35] <ScottK> Which is good since I already accepted it.
[20:35] <slangasek> :D
[20:35] <highvoltage> ScottK: in other words, please go ahead :)
[20:37] <ScottK> slangasek: ^^^ Riddell and I decided to go ahead on avogadro.  Thanks again.
[20:37] <slangasek> no prob
[20:37] <cjwatson> does avogadro require a rebuild of anything?
[20:38] <ScottK> If there's time re armel we'll want to get kdeedu and kdeplasm-addons in, but if we don't do them, we're no worse off.
[20:39] <ScottK> It's more than a rebuild though.  Riddell has a kdeedu on the way.
[20:39] <cjwatson> I haven't started any Kubuntu armel builds yet, since when I started this build sequence we were still waiting for stuff
[20:39] <cjwatson> left to do: ubuntu-netbook (in progress), ubuntu-headless, mythbuntu, ubuntustudio, kubuntu dvd, edubuntu dvd
[20:39] <cjwatson> that's at least three or four hours' worth
[20:41] <Riddell> slangasek: do I need to check that pam issue with kdm upstream or are we happy that it's fine not to restart?
[20:42] <slangasek> Riddell: if the kdm process doesn't have libpam loaded except when it's doing an authentication, then there's no risk unless we've missed that it's loaded persistently in some other process
[20:43] <Riddell> groovy
[20:50] <ScottK> lamont: Any chance of getting one or more of the dead armel builders brought back to life?
[20:51] <slangasek> bamf uploaded, fixing multiarch-induced FTBFS; I expect this is fine to keep until after beta1
[21:08] <kirkland> howdy release team ... I'm uploading cdebconf_0.154ubuntu2 to natty now;  this can be held until beta2, but I wanted to make sure it was in the queue asap
[21:08] <kirkland> note that this change won't take affect until cjwatson rebuilds debian-installer after beta1 releases
[21:08] <cjwatson> yep
[21:08] <cjwatson> dear ubuntu-netbook, why are you taking >2h to build
[21:09] <cjwatson> lamont: are acorn and sycamore actually doing anything useful?
[21:10] <cjwatson> they aren't answering HTTP from chinstrap
[21:17] <stgraber> cjwatson: I removed the release note item about LTSP not working. That's been fixed and tested on both alternate and Edubuntu by highvoltage.
[21:17] <skaet> stgraber,  cool.  thanks
[21:17] <ScottK> slangasek: No such luck on avogadro: https://launchpadlibrarian.net/67618143/buildlog_ubuntu-natty-armel.avogadro_1.0.1-3.2ubuntu1_FAILEDTOBUILD.txt.gz
[21:17] <slangasek> yeah, just saw the mail
[21:18] <slangasek> hrm, how did that happen
[21:18] <slangasek> I'll see if adding libqt4-opengl-dev back is enough to fix this
[21:19] <slangasek> (sorry, up to now it has only been build-tested on i386.. I figured I'd get a chance to do an armel build test before queue accept, but the panda is taking its sweet time)
[21:19] <slangasek> maybe I have one of these by-faster-we-mean-slower SD cards of GrueMaster's
[21:24] <ScottK> We're no worse of than we were before.
[21:28] <highvoltage> I'm in the wiki page making some changes to the edubuntu parts... I'll be out again in a minute or so
[21:36] <slangasek> if I get through two consecutive eglibc builds on amd64 in the time it takes me to get the avogadro *build deps* installed on my panda, I'm going to be sad
[21:36] <slangasek> GrueMaster: what do you use for profiling SD card performance?
[21:37] <slangasek> ScottK, Riddell: ^^ there's the pam fix for kdm; just the one change after all, apparently the other one I thought I needed was one I already included
[21:38] <Riddell> slangasek: looking
[21:39] <slangasek> kdm is still listed in the libc6.preinst for restarting - that's harder to confirm that we don't need to restart for
[21:40] <ScottK> What's going to happen if it doesn't get restarted that's worse than it getting restarted in the middle of the upgrade?
[21:40] <slangasek> hmm, this code seems to have bit rotted; only kdm, postgresql, and xdm listed for restart, and a bunch of code to handle other services not listed at all
[21:41] <slangasek> ScottK: as long as the user knows how to get to a VT, nothing - I'm musing out loud about how to fix this overall, we can certainly apply a stopgap for beta
[21:41] <ScottK> OK.
[21:41] <skaet> smoser,  jibel's added the test cases.   please join us in #ubuntu-testing if there are still issues.
[21:42] <smoser> ok. i'll be filling the results out tomorrow when jamespage is around.
[21:44] <Riddell> slangasek: accepted
[21:45] <slangasek> cheers
[21:45] <GrueMaster> slangasek: Mainly time.  I see how long it takes to flash an image to my SD from my desktop, and also how long it takes to boot or other tasks.
[21:45] <slangasek> ok
[21:45] <GrueMaster> Not a very efficient method, but definitely visible between different SD cards.
[21:46] <GrueMaster> For builds, you should at a minimum use a USB based chroot.
[21:47] <GrueMaster> I haven't timed an NFS root yet.  Maybe next week.
[21:47] <slangasek> I don't have a USB disk hooked up, this was intended to be a quick one-off :)
[21:48] <GrueMaster> What is the timeframe for new armel images?
[21:50] <cjwatson> netbook just finished
[21:51] <cjwatson> headless is running
[21:51] <cjwatson> netbook took two hours or so ...
[21:52] <cjwatson> I've posted netbook (omap3/omap4)
[21:53] <cjwatson> away for an hour or two
[21:59] <skaet> slangasek, cjwatson,  new version of post-amis-to-iso-tracker.py uploaded (rev 235) has northeast images in testcases now.
[22:00] <slangasek> great :)
[22:35] <stgraber> /w/win 33
[22:35] <stgraber> oops :)
[22:44] <pitti> good night
[22:44]  * slangasek waves to pitti
[22:52] <cjwatson> ubuntu-headless posted
[22:52] <cjwatson> (omap3/omap4)
[23:01] <lamont> cjwatson: sycamore/acorn both answer to ssh - seeing what they're up to
[23:02] <lamont> ScottK: yeah, it's been 8 hours since I did it last, it may well be time to smack them agvain
[23:03] <lamont> cjwatson: both are happily idle
[23:07] <lamont> ScottK: in theory, the 4 are back.  (being quick on the recovery is not rewarded, since then I have to actually kill the build that is STILL RUNNING)
[23:07] <doko> lamont definitely needs a smack bitch
[23:08] <lamont> doko: if only there were some way that we could encapsulate the process in a programming language.
[23:08] <lamont> ...
[23:09] <GrueMaster> cjwatson: Can you (or someone) make some adjustments ot the iso tracker for the headless and netbook armel images?
[23:10] <GrueMaster> The Netbook images really should be Ubuntu Arm Preinstalled [omap3|omap4]
[23:11] <skaet> GrueMaster, is it just the labeling?  or something with the mapping?
[23:11] <GrueMaster> Both.
[23:12] <skaet> GrueMaster, jibel is the one who can help here, and if he's offline bdmurray
[23:12] <GrueMaster> I think the Netbook images are from Lucid and earlier, so they don't map correctly.
[23:12] <skaet> start the discussion off in #ubuntu-testing
[23:12] <GrueMaster> Ok.  Moving on.
[23:12] <skaet> joining you....
[23:24] <hggdh> slangasek: I just ran a server-amd64 minimal install, and got a d-i loop. Right now this is just a heads-up, I am re-running it t confirm
[23:25] <hggdh> (the loop is due to a segfault in a d-i lib)
[23:25] <slangasek> hggdh: are you meaning to flag skaet rather than me, or is there specific action you think I should take here?
[23:26] <slangasek> hopefully it's not a multiarch-induced segfault, though I guess that's not impossible :)
[23:26] <hggdh> slangasek: I did flag skaet, and she asked me to flag you :-)
[23:26] <slangasek> ok :)
[23:26] <hggdh> slangasek: all other server installs seem to be kosher
[23:28]  * skaet just wanted it on slangasek's radar in case it was a multiarch-induced segfault... ;)
[23:28] <slangasek> man, I hope not :)
[23:28] <skaet> me too
[23:31] <hggdh> slangasek: skaet: I think I know what caused it -- installing a minimum system (real) on a VM, instead of installing a minimum VIRTUAL system on a VM
[23:32] <hggdh> I will repeat it later, but this will be a normal bug, not an ISO test one
[23:32]  * skaet feels better...
[23:32] <skaet> thanks hggdh
[23:32]  * hggdh is starting to redeem self with skaet ;-)
[23:33] <skaet> lol
[23:40] <doko> it's good to be able to blame anything on multiarch ;-P
[23:43] <slangasek> :-)
[23:43] <cjwatson> lamont: thanks, see #is though, it sorted itself out not that long after I asked
[23:44] <cjwatson> GrueMaster: yeah, I don't have that level of iso tracker access, sorry
[23:44] <GrueMaster> Neither do I.
[23:44] <cjwatson> GrueMaster: please can you specifically *not* make them "Ubuntu Arm Preinstalled [omap3|omap4]", though
[23:44] <GrueMaster> Ughh.
[23:44] <cjwatson> GrueMaster: that naming is a horrendous pain in publish-image-set.py
[23:45] <cjwatson> the closer it corresponds to how cdimage names things, the smoother the release publication process can be
[23:45] <GrueMaster> Then someone needs to delete them from the testcases and fix the netbook ones to map properly.
[23:45] <lamont> cjwatson: figures
[23:45] <cjwatson> publish-image-set.py scrapes iso.qa with a big pile of regexes and uses that to output publish-release commands that we use when we're ready to release
[23:46] <GrueMaster> We run into this every release since early maverick.
[23:46] <cjwatson> the "Ubuntu Arm" stuff was completely out of sync with everything else there, and a massive headache
[23:46] <GrueMaster> That's what we do best.  :P
[23:46] <cjwatson> fixing up the testcase mappings seems to make more sense than changing the names
[23:47] <GrueMaster> Agreed.  Just no one seems to care about the tracker except during release week.
[23:47] <cjwatson> hggdh: having trouble seeing how that could make a difference ...
[23:48] <cjwatson> hggdh: there are differences in how those two preseed files set up the target system, but no segfault in d-i can be explained away by that
[23:48] <cjwatson> hggdh: do you have more details on the segfault?
[23:48] <hggdh> cjwatson: I do not understand either, but now it is working; I will get back to it when I end the ISO tests
[23:49] <cjwatson> what I mean is that installing a minimum system (real) on a VM is a valid test
[23:49] <hggdh> cjwatson: not right now, no details, except it looped
[23:49] <cjwatson> I guess that's a better way to put it
[23:49] <hggdh> hum
[23:49] <cjwatson> the virtual option is optimised for VMs, rather than being the only valid thing to choose on VM
[23:49] <hggdh> then this would be a failure
[23:49] <cjwatson> s
[23:49]  * lamont EOD afk
[23:49] <hggdh> OK, I will repeat it nwo
[23:49] <hggdh> now
[23:51] <cjwatson> mythbuntu and ubuntustudio posted
[23:51] <jibel> GrueMaster, I cant do this instantly because the name/path resolution is hardcoded in the tracker.  please file a bug against ubuntu-qa-website and I'll see what can be done for next milestone.
[23:53] <cjwatson> skaet: do you know why Edubuntu upgrade tests are disabled?
[23:53] <cjwatson> looks like just those plus Kubuntu DVD, Edubuntu DVD, and a bunch of Kubuntu armel builds to go
[23:54] <cjwatson> Kubuntu DVD is in progress, will take a while though