[00:01] <skaet> will coordinate with infinity on the subject first thing in the morning then as well.
[00:01] <cjwatson> stgraber mentioned bug 986806 which might be a regression from the work on encrypted home; will investigate tomorrow
[00:01] <ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [Undecided,New] https://launchpad.net/bugs/986806
[00:02] <cjwatson> (probably specific to encrypted home)
[00:03]  * skaet nods
[00:06] <cjwatson> also, I now have an LP test that reproduces bug 887185, so I'm working on fixing that
[00:07] <ubot2> Launchpad bug 887185 in launchpad "ArchivePermission allows duplicated rows" [Critical,Triaged] https://launchpad.net/bugs/887185
[00:07] <cjwatson> since that ideally ought to be rolled out by the time we initialise Q
[00:09] <skaet> good luck with figuring out the fix.
[00:10] <skaet> ok,  no respins for now,  we'll discuss tomorrow morning the timing of the next set of respins
[00:10] <kees_> g
[00:30] <hggdh> ugh. kernel oops
[00:55] <skaet> hggdh,  get the details in a bug immediatley please.   apw should be coming on line soon, and will be here with us in London, to help figure it out.
[01:15] <cjwatson> Fix for 887185 (well, at least the urgent bits of it) is making its way through EC2 now, so with any luck should be able to get it deployed on Wednesday
[01:15] <cjwatson> maybe Tuesday with a strong following wind
[01:18] <hggdh> skaet: bug 987052
[01:18] <ubot2> Launchpad bug 987052 in linux "WARNING: at /build/buildd/linux-3.2.0/kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0()" [Undecided,Confirmed] https://launchpad.net/bugs/987052
[01:18] <cjwatson> That was worth a late night, since the extra eight hours or so will matter :-)
[01:18] <hggdh> skaet: end result is system became completely unresponsive
[01:19] <skaet> Thanks cjwatson.  :)
[01:19]  * cjwatson spies jetlag
[01:19] <skaet> hggdh,  not good.
[01:19]  * skaet notes that cjwatson is right
[01:20] <skaet> apw, bjf, ogasawara ^ could you please look at this as soon as one of you comes online.
[04:10] <pitti> Good morning
[04:10] <pitti> skaet: the rebuilds you pinged about already happened on the weekend AFAICS, right?
[04:30] <pitti> at least http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html says that all packages are current
[04:30] <pitti> err, images
[04:36] <ScottK> pitti: AFAIK there's no immediately pending rebuilds, although we do know we'll need to respin everything at some point because Nobody remembered to set OFFICIAL="Release" in debian-cd until now.
[04:37] <ScottK> cjwatson mentioned it earlier.
[04:37] <pitti> indeed
[04:38] <pitti> I wonder if there is anything in precise-proposed which ought to get wrapped into the rebuild then
[04:38] <pitti> like compiz, dkms, maas-provision
[04:49] <ScottK> server will need a respin once mass gets accepted regardless (so mass-provision is no rush)
[04:50] <ScottK> The current maas package in the archives has dependencies that the security team said were no-go for Main.
[04:50] <ScottK> (mass-provision will go on the server CD and cobbler will go off to Universe)
[05:18] <skaet> pitti,  lets plan on discussing in the channel in 3 hours (when more folks are on line,  which of the opportunity targets we feel comfortable including in the respin.
[05:20]  * skaet notes that the weather report, probably needs updating to reflect that Ubuntu Studio transitioned from an Alternate to a DVD this cycle...
[05:20] <pitti> skaet: agreed
[05:23] <ogasawara> skaet: have posted a comment to 987052
[05:24] <skaet> Thanks ogasawara.  :)
[05:25] <skaet> ogasawara,  who maintains the weather report these days?
[05:25] <ogasawara> skaet: I do, was just about to look at the ubuntu studio bit
[05:26] <skaet> ogasawara,  coolio.  Thank you.    Its late though,  that is certainly not urgent.   We can work around.
[05:28] <ogasawara> skaet: it's a quick fix to point to the new manifest location.
[05:28] <skaet> ogasawara,  coolio.  what ever
[05:28] <skaet> is easiest
[05:28]  * skaet hates keeping reminders if its fastest to just do it rather than write a reminder.   ;)
[05:32] <skaet> pitti,  if things are calm right now,  could you fit in a pass on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop?   Want to make sure we've got the right features highlighted for the release, and get started on adding in the key bugs.
[05:33] <skaet> if you're working on bugs though,   the ReleaseNotes can certainly wait.
[05:36] <pitti> skaet: oh, can do; I already brushed it up last week, but I'll have another pass
[05:37] <skaet> great!  thanks pitti.  :)   Its likely to be a WIP until release day... ;)
[05:38]  * skaet --> gets breakfast,  l8r
[06:03] <pitti> skaet: I'm fixing a few spelling/grammar/wording issues, and I remove the update-manager -d instructions (as at the time of release the -d won't be necessary any more)
[07:16] <stgraber> good morning
[07:16]  * stgraber gets everything setup here for g+, back in a few minutes
[07:27] <pitti> do we have an official hangout place? I grabbed an USB webcam now (as my laptop is closed under my desk, and the integrated camera won't do much good)
[07:27] <pitti> but I have some trouble telling g+ about which cam to use
[07:28] <stgraber> pitti: skaet said we'd, I'm going to create one if I don't have a reference to it in my e-mails
[07:30] <skaet> pitti, stgraber - go ahead and create a site for now,  we may consolidate later, once we get the hardware set up.    Choose a good name for it ;).
[07:31] <skaet> I need to figure out with Pete if we should consolidate qa-meeting in with it,  or leave them as separate G+ sessions.
[07:31] <skaet> Will be heading in to office in 30 minutes or so, and setting up then.
[07:31] <stgraber> skaet: remember that we have a 10 participants limit in g+ hangouts
[07:32] <skaet> stgraber,  good point.  ok, separate it is.
[07:48]  * skaet -->office,  biab
[08:08] <micahg> could someone do another round of removals from precise stuff that was removed from unstable?  That way I can just file bugs if I see anything left
[08:09] <cjwatson> Yes, I was about to start that
[08:09] <micahg> cjwatson: thank you :)
[08:09] <cjwatson> Oh, a general p-r run you mean
[08:09] <cjwatson> OK, I guess so, though I'd tend to be pretty conservative
[08:09] <micahg> cjwatson: is there output of what has Ubuntu diffs and has been removed?
[08:10] <pitti> hello cjwatson
[08:10] <micahg> cjwatson: nm, I know the answer to that :)
[08:12] <cjwatson> micahg: Er, you could run p-r yourself in dry-run mode I guess
[08:12] <cjwatson> I forget how upset it gets if you don't have ftpmaster shell access
[08:13] <micahg> I was thinking of ubuntuwire
[08:13] <cjwatson> Ah
[08:14] <micahg> after the p-r run, I can go through an see if there's anything that needs an update to remove old stuff
[08:36] <cjwatson> micahg: In progress now.  A lot of things relate to other package reorganisations that haven't happened yet in Ubuntu, so I'm being pretty cautious.
[08:37] <micahg> cjwatson: I can appreciate that, thanks, I'm hopefully going to sleep shortly, will try to pick off a few at a time over the course of the day from what's left
[09:20] <sil2100> Hi!
[09:23] <sil2100> I have a small request... there is a compiz patch in -proposed that has been pushed in recently
[09:24] <sil2100> It works, everything is fine - but it's a workaround for a problem we noticed, since we didn't yet have a good fix
[09:24] <sil2100> But on Friday, we actually found the root cause of the problem and fixed it the right way
[09:25] <sil2100> So I wanted to know if it would be possible to exchange the workaround for compiz that's already in -proposed for the 'final' fix
[09:26] <infinity> sil2100: We kinda like things being fixed correctly.
[09:28] <pitti> sil2100: this -proposed version will not go into the final release anyway
[09:28] <sil2100> pitti: ah, so it's anyway target for SRU-0?
[09:29] <sil2100> infinity: this final, non-workaround fix is much better, since it has no performance implications
[09:29] <sil2100> infinity: since it fixes a typo someone made long long time ago ;)
[09:29] <pitti> sil2100: so yes, it's perfectly reasonable to replace the upload with a better one
[09:30] <sil2100> pitti: excellent, I'll ping ogra_ to port the gles patch if possible to the new distro version
[09:30] <sil2100> pitti: thanks!
[09:39] <rickspencer3> skaet, I'm looking at the ISO tracker, for the rows that are green, does it mean those ISOs are good to release?
[09:39] <rickspencer3> for exable Ubuntu amd64 has a green 6/6
[09:39] <rickspencer3> ?
[09:39] <stgraber> wow, Ubuntu is installling so much faster now that I closed g+ :)
[09:40] <stgraber> rickspencer3: they'll all need a rebuild to be tagged as final images
[09:40] <skaet> rickspencer,  not quite,  it means that all the tests have passed, and we could if there were no other issues known.   Its part of the story, but not all of it.
[09:40] <rickspencer3> how can I tell which ones are good to go?
[09:40] <rickspencer3> stgraber, skaet ^ ?
[09:40] <skaet> rickspencer3, http://pad.ubuntu.com/ubuntu-release
[09:41] <stgraber> AFAIK none of them have the official tag set, so they all need at least a cd rebuild if not livefs rebuild
[09:41] <skaet> gives the issues we're monitoring for respin.
[09:41] <skaet> [18] is the "Release" respin stgraber is referring to.
[09:42] <Laney> I see two 18s there :P
[09:43] <rickspencer3> so they all need to be respun and then retested via the ISO tracker?
[09:43] <skaet> rickspencer3, yes.
[09:44] <stgraber> skaet: might be worth adding a note in the tracker header again if not disable them all.
[09:46] <skaet> stgraber,  yes.
[09:46] <Daviey> pitti: Can maas be accepted please, and maas-provision be pocket copied from -proposed please?
[09:47] <pitti> Daviey: sure
[09:47] <Daviey> thanks
[09:47] <pitti> Daviey: want to do the releasing yourself, for practicing, or not now?
[09:48] <Daviey> pitti: the hat now?
[09:48] <Daviey> what*?
[09:48] <pitti> Daviey: pad updated for maas, re-labeled to "20" (as "18" already existed)
[09:48] <pitti> Daviey: sru-release -r precise maas-provision
[09:48] <Daviey> pitti: I'm not in ~ubuntu-archive, frustratingly.
[09:48] <pitti> Daviey: can run it for you, I just wondered if you wanted to
[09:48] <pitti> Daviey: ah, ok
[09:49] <Daviey> I would like to do it myself, yes :).
[09:49] <Daviey> skaet: didrocks is kindly looking over tge MIR's for horizon.  NOT SPIN RELATED.
[09:50]  * didrocks emphases in "kindly" :p
[09:50] <pitti> cjwatson: reviewing gfxboot, this just changes *.po files? I don't see an actual string change in any code there?
[09:51] <Laney> can we do something with esteid-browser-plugin one way or the other please?
[09:51] <didrocks> wait for python-coverage, maybe additional changes are needed ^
[09:51] <didrocks> pitti: surely, there will be needed for another upload, can you reject it for now?
[09:51] <pitti> didrocks: coverage?
[09:51] <cjwatson> pitti: there's a *.pot file there too.  The actual string is in debian-cd
[09:51] <pitti> didrocks: seems Daviey just uploaded it to change the version for the ubuntu delta
[09:51] <ogra_> pitti, infinity, note that updating the gles patch on top of the compiz change will take another day for linaro and me to update everything again
[09:52] <didrocks> pitti: yeah, there is no LICENSE/COPYING file
[09:52] <didrocks> oh sorry
[09:52] <didrocks> that's fine, BSD-2
[09:52] <pitti> cjwatson: ah, so it takes the strings from there; thanks
[09:52]  * didrocks tries to see where it's specified that it's BSD-2 on the package
[09:53] <skaet> Daviey, didrocks.   Thanks.  (and appreciate the clarification ;) )
[09:55] <stgraber> skaet, cjwatson: Unable to reproduce bug 986806 here
[09:55] <ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [High,New] https://launchpad.net/bugs/986806
[09:56] <skaet> stgraber, ok.   we'll aim to release note.   Its recoverable.   Would you please add a release note project to the bug?
[09:56] <skaet> (so we don't loose it.)  Important to tell folks how to recover.
[09:58] <stgraber> skaet: well, I don't know what the problem is post-install so I don't know how to fix it ;)
[09:58] <skaet> stgraber,  fair enough.  Some of the folks in the room were just discussing it.
[09:58] <stgraber> skaet: can be any of missing swap in /etc/fstab, non-encrypted swap trying to be mounted as encrypted swap or just non initialized swap partition
[09:59] <stgraber> skaet: having another look at the log provided by the user to try and see if there's a clue I didn't see initialiy
[10:02] <stgraber> skaet: oh, I think I found a clue, will do another test install now. Seems to be related to low-memory environment
[10:03] <stgraber> install was done with < 512MB of ram, which created a zram device that might have caused the encrypted swap script some troubles
[10:04] <stgraber> cjwatson: sounds possible? ^
[10:04] <stgraber> cjwatson: relevant part of the log being: http://paste.ubuntu.com/942285/
[10:08] <cjwatson> stgraber: possible, but I thought I fixed ecryptfs-setup-swap to ignore zram
[10:08] <cjwatson> right, so that should just have been ignored?
[10:08] <cjwatson> I did explicitly test that
[10:08] <stgraber> yeah, I remember seeing that code... test install running here with 480MB to see exactly wha happens
[10:08] <stgraber> *what
[10:09] <stgraber> zram seems indeed to be ignored, but then we get that extra log entry:
[10:09] <stgraber> Apr 22 08:38:12 ubuntu ubiquity: WARNING: Commented out your unencrypted swap from /etc/fstab
[10:09] <stgraber> that I don't get on a > 512MB install
[10:10] <cjwatson> Odd, you should, I think
[10:10] <didrocks> pitti: skaet: python-coverage looks good to me with this upload, acking the MIR. If you accepted it to -proposed an then move it to the release pocket, I'll do the promotion to main
[10:10] <didrocks> or maybe you want to override directly when copying from proposed to the release pocket?
[10:10] <cjwatson> That should be commenting out the swap entry on the hard disk, not zram
[10:11] <pitti> didrocks: accepted to -proposed
[10:11] <pitti> didrocks: yes, I can do that
[10:12] <didrocks> pitti: ok, just set the bug report as fix committed, please change the status to released once… released ;)
[10:12] <pitti> didrocks: yep, will do; thanks
[10:13] <stgraber> skaet: lunch time here, I'll be back for the hangout. I have a test install running for the encrypted swap install so I'll know more at the meeting
[10:13] <skaet> Thanks stgraber
[10:14]  * cjwatson slogs through all the removals from the Cambridge Debian BSP in March
[10:21]  * cjwatson laughs at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662179
[10:21] <ubot2> Debian bug 662179 in ftp.debian.org "RM: pouetchess -- RoQA; unmaintained, RC buggy" [Normal,Open]
[10:21] <cjwatson> "5 years after the maintainer promised to fix a chess program
[10:21] <cjwatson> which ends the game on check, it's time to stop pretending
[10:21] <cjwatson> that it can be described as a chess program."
[10:23] <cjwatson> (Why does ubot2 think that bug's open?  Silly thing)
[10:26] <Laney> ppc build fix
[10:31] <cjwatson> fine by me
[10:32] <Laney> cheers
[10:35] <doko> slangasek, I did check -lucid and -oneiric updates with your upload, and they both do work for me
[10:51] <cjwatson> So are we good to respin now?
[10:53] <cjwatson> Oh, maas needs to go to release, copying that now
[10:54] <stgraber> cjwatson: so I got an Ubuntu install with the same log as the reporter but I still have a working swap. Doing another install on top of that to see if that triggers it then
[10:54] <cjwatson> ok
[10:54] <stgraber> (I don't see why it'd but well, that's what the reporter described)
[10:58] <cjwatson> So IMO it's ETA ~30mins until we can start respins
[11:04] <cjwatson> OK, I basically can't hear anything at all on G+
[11:04] <cjwatson> It's very jumpy sound
[11:04] <cjwatson> I think if we want to have a productive sync with remote participants we'd be better off with IRC
[11:07] <pitti> IRC ++
[11:07] <skaet>   cjwatson, stgraber - anything left to wait for from your perspective, or are we good to go?
[11:07] <skaet> pitti- anything from your radar?
[11:07] <cjwatson> maas needs to publish to release
[11:07]  * skaet has gone to IRC
[11:07] <stgraber> skaet: I just finished another test install for the ecryptfs issue
[11:07] <pitti> I can't hear a word from the office, and the video is just a slideshow
[11:07] <stgraber> skaet: I'm looking at the result now
[11:08] <cjwatson> After that I don't have anything at the moment
[11:08] <Daviey> It's amazing really.. We can produce an operating system, but a phone call is too much of a challenge :)
[11:08] <skaet> ok stgraber,  you're my trigger then.  :)
[11:08] <apw> Daviey, we can produce an operating system, G cannnot produce a phone call
[11:08] <stgraber> skaet: VM booting now :)
[11:09] <skaet> utlemming,  you'll need to respin the cloud images to pick up the "Release" setting (it was omitted by accident on last Thursday's interesting)
[11:09] <ScottK> What are the issue numbers on the pad referring to?
[11:09] <cjwatson> skaet: um
[11:09] <skaet> [18]
[11:09] <skaet> CONF.sh
[11:09] <cjwatson> skaet: utlemming's cloud image generation code doesn't use debian-cd, so I don't see why that would matter to him
[11:09] <cjwatson> He may have something independent
[11:10]  * Daviey checks
[11:10] <stgraber> skaet, cjwatson: right, can't reproduce the issue even on low memory doing two installs on top of each other
[11:10]  * Daviey stops checking for the moment.
[11:10] <cjwatson> OK, let's chalk it up to cosmic rays for now?
[11:11] <stgraber> skaet, cjwatson: so if that thing is reproducable, it's difficult enough that it likely won't affect a lot of systems and so shouldn't be RC
[11:11] <skaet> cjwatson,  Daviey thanks!
[11:11] <skaet> stgraber,  ack.  ok,  will start queueing up the rebuilds.
[11:13] <stgraber> skaet: commented in the bug asking for everything that'd help to debug this and marked incomplete, so I think we're done with that one for now
[11:15] <skaet> thanks stgraber,   ok,  going ahead with the desktop rebuilds
[11:16] <skaet> Daviey,  I'll start the alternates and server as soon as we're sure publishing is clean
[11:16] <skaet> infinity,  as soon as you've added the timestamps, ping me and we'll start the arm ones off.
[11:17] <cjwatson> phone> FWIW we found in the foundations installer sprint that mumble was in practice more usable for leaving on all day
[11:18] <pitti> yeah, video is not all that important here
[11:19] <stgraber> yeah and doesn't use half of your CPU. Though I think Millbank would still need a decent microphone
[11:19]  * cjwatson reaches April in this removals sync-up
[11:19] <cjwatson> keeping up with the Debian FTP team <- hard
[11:20] <stgraber> cjwatson: can you ensure you don't end up removing qtnx? I know that last time pitti did the removal sync with Debian that dropped it from the archive even though I use it and fix it when it break.
[11:23] <cjwatson> I don't recall it coming up, but I'm running from the start of the year so if it was removed from Debian before that it won't come up
[11:24] <Daviey> cjwatson: maas seems published in release pocket now?
[11:24]  * skaet is marking iso tracker that respins comming...
[11:24] <cjwatson> Daviey: publisher is still running
[11:24] <cjwatson> I'm watching the log
[11:24] <Daviey> ok
[11:25] <cjwatson> LP tells you it's published at the start of the relevant publisher run
[11:25] <stgraber> cjwatson: last time it was removed from the ubuntu archive was on the 6th of February, according to the Debian bug, it was removed in Debian on the 17th of December, so should be good then
[11:25] <cjwatson> stgraber: yep, won't be a problem
[11:27] <skaet> hmm...   we're double checking WUBI right now...
[11:27] <cjwatson> maas is done
[11:27] <Daviey> cjwatson: thanks
[11:27] <cjwatson> skaet: what about it?
[11:29] <skaet> cjwatson,  trying to figure out GPL issue resolved with ev
[11:29] <skaet> seems to be some doubt
[11:29] <cjwatson> skaet: Steve and I agreed that it should not be a showstopper
[11:30] <cjwatson> skaet: (a) It's not clear that we've ever got it particularly right for Wubi so it's not really a regression, (b) we can fix it with non-image changes
[11:30] <ev> we're fine on wubi
[11:30] <ev> the wubi revision we have signed and in place is the most recent bzr revision
[11:31] <cjwatson> I raised it here because I only noticed it recently and because it came up in the context of another bug, not because it was a release showstopper
[11:31] <ev> as colin confirmed, he and steve don't consider the gpl issue a release blocker
[11:31] <ev> so there's no need to respin wubi images
[11:31] <skaet> thanks ev, cjwatson. :)
[11:31] <ev> skaet asked me to write all that here
[11:31] <skaet> :)  yup
[11:32]  * skaet trying to get this virtual thing effective,  and make sure room conversations are echo'd here.  ;)
[11:40] <stgraber> skaet: I moved the Edubuntu page from https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/EdubuntuDesktop to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Edubuntu so that the name is similar to that of the other flavours and fixes some broken links in the process
[11:42] <fabo> heya, can we still have linaro-image-tools package updated in universe?
[11:44] <stgraber> fabo: yes
[11:45] <stgraber> fabo: unseeded universe isn't frozen yet though UI and feature freeze apply
[11:46] <stgraber> fabo: 	
[11:46] <stgraber> fabo: UnseededUniverseFinalFreeze is tomorrow at 21:00 UTC
[11:47] <fabo> stgraber: ok, thanks
[11:50] <skaet> thanks stgraber!   thought I'd caught them all, but it appears not.  :)
[11:51] <skaet> ^ full rebuild has started,  should be emerging on the iso tracker from now on.
[11:51] <stgraber> skaet: there also was a broken link to the kernel config /Spec/ instead of /Specs/, spotted by one of the Edubuntu guys, fixed too :)
[11:51] <skaet> awesome.   Please thank the guy that spotted it from me.  :)
[11:52] <stgraber> skaet: any reason why Upgrade is disabled? I'm not aware of anything being broken there
[11:52] <skaet> good point
[11:53]  * stgraber is always sad to get an e-mail from the auto-upgrader telling him 8 hours of testing couldn't be reported because the builds are disabled ;)
[11:55] <cjwatson> micahg: OK, first pass at that finally done, so feel free to report anything else that bothers you
[11:56] <cjwatson> Also, phew, that was a lot of removals
[11:56] <cjwatson> Not many with FTBFS bugs attached though
[11:56] <Laney> were you doing removals from unstable or testing?
[11:56] <Laney> s/doing/tracking/
[11:58] <skaet> and by accident I ended up including WUBI in the builds - will be reverting back to the already tested one.
[12:00] <cjwatson> ack, I don't *think* any of the rebuild triggers affect Wubi preinstalled images?
[12:01] <stgraber> cjwatson: I think dkms does but that's just a dependency fix so we don't NEED it
[12:02] <cjwatson> <cjwatson@sarantium ~>$ GET http://cdimage.ubuntu.com/wubi/current/i386.manifest | grep dkms
[12:02] <cjwatson> <cjwatson@sarantium ~>$ GET http://cdimage.ubuntu.com/wubi/current/amd64.manifest | grep dkms
[12:02] <cjwatson> <cjwatson@sarantium ~>$
[12:03] <stgraber> oh, ok :)
[12:03] <stgraber> ah, I guess dkms is usually in /pool so on the desktop media but not on the preinstalled images
[12:28] <cjwatson> infinity: any word on what to do with gnat-4.6 outdates?
[12:31] <infinity> cjwatson: doko claimed he'd look at it.
[12:32] <cjwatson> OK
[12:35] <infinity> doko: Did you get anywhere with gnat-4.6 (turning off multilib on armel)?
[12:35] <infinity> cjwatson: We *could* remove all of armel's gnat-4.6 rdeps, but given that we didn't get it ported to armhf in time, that's kinda one of the few potential use-cases for multiarch on armel/armhf. :P
[12:37] <infinity> Daiey / cjwatson: Erm, was maas-provision meant to be in main?
[12:37] <cjwatson> I didn't touch that
[12:37] <infinity> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[12:38] <ScottK> It was.
[12:38] <infinity> I assume this invalidates the current server spins being done. :P
[12:39] <cjwatson> Might want a fix-committed MIR then.
[12:39] <cjwatson> It would do.
[12:39] <ScottK> The only question is about the apparmor profile.
[12:39] <ScottK> That needs fixed first.
[12:39] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/950193/comments/6
[12:39] <ubot2> Launchpad bug 950193 in maas-provision "[FFe] [MIR] maas-provision" [High,In progress]
[12:39] <ScottK> (see the mir bug)
[12:39] <cjwatson> So that's now critical path.
[12:40] <cjwatson> forked-daapd FTBFS on armel/armhf because libdispatch misbuilds with a sufficiently new dpkg-dev, and on top of that it fails to build in three different way.
[12:40] <jdstrand> I am trying to raise Daviey on this issue. I don't know why it was shipped disabled by default. I guess I could've been more clear...
[12:40] <cjwatson> *ways
[12:40] <cjwatson> But I think I've got it disentangled now.
[12:41] <cjwatson> Oh, sorry, two different ways. :-P
[12:41] <infinity> Daviey: Can you sort out the maas-provision issue with jdstrand ASAP?
[12:45] <cjwatson> added a note to the pad about this
[12:46] <cjwatson> speculatively made Ubuntu ARM Server trigger on a fix for this as well as Ubuntu Server; please correct me if I'm wrong
[12:47] <infinity> cjwatson: Seems right.
[12:47] <infinity> cjwatson: Did you remove gnat-4.6/armel binaries already?  outdate seems to not list them...
[12:47] <cjwatson> No
[12:47] <infinity> Oh, outdate probably doesn't list armel.
[12:47] <infinity> La la la.
[12:47] <cjwatson> Try testing-ports/...
[12:47] <ScottK> All of cobbler can be demoted.
[12:47]  * infinity nods.
[12:48] <infinity> I really wish we didn't split main/ports for britney.
[12:48] <cjwatson> ScottK: I was sort of loosely waiting until maas-provision could be promoted
[12:48] <ScottK> maas already doesn't depend on cobbler and the only reason maas-provision exists is because cobbler isn't suitable for main.
[12:49] <ScottK> We've got plenty of time, I guess.
[12:49] <cjwatson> ew @ libkqueue
[12:49] <cjwatson> fails to build with a hang in the test suite, only on amd64/i386
[12:50] <ScottK> Is the stack of mismatches related to horizon meant to impact the server CD?  Does anyone know?
[12:50] <cjwatson> Oh, and apparently only on buildds, not locally.
[12:50] <cjwatson> ScottK: No, it's in supported-misc-servers so not on the CD.
[12:50] <ScottK> OK.
[12:51] <ScottK> So we don't need to wait for that.
[12:51] <cjwatson> And libkqueue has the same maintainer as libdispatch.  Bless me, Father, for I have sinned.
[12:52] <cjwatson> (At least, I assume I must have done.)
[12:53] <apw> cjwatson, it inevitable, the list of possible sins is so very large
[12:54] <infinity> Oh, bleh, tulip is GLES + QT issues.
[12:55] <cjwatson> I might just disable the test suite on sufficiently old kernels.
[12:56] <infinity> cjwatson: Just build it on one of the new buildds.
[12:56] <cjwatson> Maybe if I disable it on <<2.6.32, and then we'll find out later if a buildd upgrade to lucid fixes it.
[12:56] <infinity> cjwatson: They're precise.
[12:56] <cjwatson> Oho
[12:56] <cjwatson> OK, I'll try that
[12:59] <infinity> cjwatson: And that appears to have worked.  \o/
[13:00] <cjwatson> infinity: I've been gradually removing OODs from GLES/Qt issues (there are still lots).  tulip has an Architecture: all build-dep, but hey, that's uninstallable on armhf anyway.  Shall I just kill it on armel?
[13:00] <cjwatson> Hooray for brute force and ignorance
[13:00] <infinity> cjwatson: Yeah, I was going to remove it.
[13:00] <infinity> cjwatson: Go for it.
[13:01] <cjwatson> Done
[13:02] <infinity> (It should have been removed in oneiric, it was out-of-date there too)
[13:02] <infinity> Oh well.
[13:02] <cjwatson> Now if anyone understands maven, I could use help with the wagon build failure
[13:02] <cjwatson> infinity: I've deduced that OOD hasn't been clear since before lucid
[13:02] <infinity> cjwatson: srsly?
[13:02] <cjwatson> Since I've been removing binaries that should have been superseded in lucid
[13:02] <infinity> Ugh.
[13:02] <cjwatson> I think karmic was the last time
[13:02] <infinity> Right, this needs to be a more proactive thing, methinks.
[13:03] <infinity> Would be less effort if we did it more than once every 2 years. :P
[13:03] <cjwatson> Yes.  One reason I want to kill it dead for precise.
[13:03] <cjwatson> It should be part of +1 maint.
[13:03] <infinity> Ooo, axiom's build failure on PPC is special.
[13:04] <cjwatson> Dear http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.txt, I don't believe you
[13:05] <infinity> cjwatson: You don't?
[13:05] <cjwatson> Oh, _all
[13:05] <cjwatson> Duh
[13:05] <infinity> cjwatson: Yeah, that's only main. :P
[13:05] <cjwatson> Sorry, wrong direction in my browser's back/forward queue ...
[13:05] <infinity> ;)
[13:07] <smoser> Adri2000, i've updated the README.files.
[13:07] <infinity> cjwatson: FFe for an axiom sync, the newer version builds everywhere on Debian (well, except mips...)
[13:07] <infinity> cjwatson: ?
[13:08] <infinity> cjwatson: No rdeps, except for some science-* metapackages.
[13:09] <cjwatson> Do you have the upstream changelog handy?
[13:10]  * infinity looks.
[13:10] <cjwatson> libdispatch, why do you mock me
[13:11] <cjwatson> https://launchpadlibrarian.net/102903313/buildlog_ubuntu-precise-armhf.libdispatch_0~svn197-3ubuntu1_FAILEDTOBUILD.txt.gz clang isn't just stuffed on armhf, is it?
[13:11] <cjwatson> I don't like the look of those BFD assertions
[13:13] <cjwatson> Also, libdispatch/powerpc builds iff it *isn't* built on sulfur.
[13:13] <infinity> cjwatson: In theory, clang works on armhf.  I'm not sure how heavily it's been tested...
[13:14] <cjwatson> (Log's gone, I'm afraid, but it was SIGILLing.)
[13:14] <infinity> cjwatson: If it's sigilling on sulfur, then it's incorrectly building in altivec.
[13:15] <infinity> cjwatson: Which would fail on my PPC machines at home too.
[13:15] <cjwatson> Wouldn't surprise me.  What's the right flag to fix it?
[13:15] <infinity> cjwatson: (adare/ross are Apple G5s, sulfur is a POWER5)
[13:15] <cjwatson> -mno-altivec?
[13:15] <infinity> Could be.
[13:15] <infinity> Not sure. :/
[13:15] <cjwatson> There's no mention of altivec in the source.
[13:16] <cjwatson> I suppose llvm/clang itself could be doing it.
[13:16] <infinity> Well, altivec being a guess, but I think that's generally where a G5 and POWER5 differ, ISA-wise.
[13:16] <infinity> But it would also mean those bianries would fail on G4, G3, etc.
[13:17] <cjwatson> Not really sure I can be bothered to fix it now.  armhf is getting in the way though.
[13:17] <cjwatson> Pretty sure at least some G4s had altivec.
[13:17] <infinity> Some did.
[13:17] <infinity> Differing generatoins, though.
[13:17] <infinity> Like SSE.
[13:18] <infinity> Anyhow, nothing in the PPC archive should have altivec.  Maybe an instruction scanner at some point would be nice.
[13:18] <cjwatson> http://llvm.org/bugs/show_bug.cgi?id=11924
[13:18] <ubot2> llvm.org bug 11924 in Frontend "clang makefile assumes all powerpc systems have altivec" [Normal,New: ]
[13:19] <cjwatson> At a guess
[13:21] <infinity> cjwatson: oo, sounds likely.
[13:21] <infinity> I'll make a note of that for an SRU.
[13:21] <cjwatson> So it's clang itself, not libdispatch
[13:22] <infinity> Check.
[13:22] <infinity> I'll fix llvm on PPC later.
[13:22] <infinity> But the armhf thing, hrm.
[13:22] <infinity> (Well, if we end up needing to upload for armhf, we could do PPC at the same time)
[13:23] <cjwatson>                   BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0);
[13:23] <cjwatson> The assertion is that if Tag_FP_arch is set to 0 then Tag_ABI_HardFP_use must also be set to 0
[13:24] <infinity> Which means that something here is producing an SF binary.
[13:24] <cjwatson> This is all in configure tests with fairly basic compiler options.
[13:25] <cjwatson> configure:2632: clang -g -O2 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c  >&5
[13:25] <infinity> cjwatson: Right, so either clang is wrong, or something it's linking to is...
[13:25] <cjwatson> (precise-armhf)cjwatson@scheat:~$ cat t.c
[13:25] <cjwatson> int main(int argc, char **argv) { return 0; }
[13:25] <cjwatson> (precise-armhf)cjwatson@scheat:~$ clang t.c -o t
[13:25] <cjwatson> /usr/bin/ld.bfd.real: BFD (GNU Binutils for Ubuntu) 2.22 assertion fail ../../bfd/elf32-arm.c:11477
[13:25] <cjwatson> I'm going to vote for clang
[13:26] <infinity> Poop.
[13:26]  * infinity has a look.
[13:26] <cjwatson> Gotta love compiler test cases you can fit into IRC.
[13:29]  * infinity wonders how/why this worked a few months ago...
[13:31] <cjwatson> You didn't change the triplet or something did you?
[13:31] <infinity> No.
[13:31] <infinity> Just the linker path, which shouldn't relate.
[13:31]  * cjwatson -> out for a bit
[13:35] <doko> cjwatson, infinity: will have to wait until tonight. didn't setup dyndns, working from mwhudson's place today with dholbachj
[14:33] <jdstrand> Daviey: uploaded maas-provision to precise-proposed
[14:36] <infinity> jdstrand: Is this one good enough to promote?
[14:37] <cjwatson> infinity: How do I reliably tell whether an object file is SF or HF?
[14:38] <cjwatson> infinity: 'clang -c t.c -o t.o && clang t.o -o t' produces a working binary, so I'm suspicious.
[14:38] <infinity> cjwatson: readelf -A | grep Tag_ABI_VFP_args
[14:38] <infinity> cjwatson: The binary it produces *is* hardfp.
[14:38] <infinity> cjwatson: The complaint from ld is about something it's linking to... Some static bits, maybe?  I dunno.
[14:38] <infinity> cjwatson: I was just trying to hunt that down.
[14:38] <Daviey> infinity: please don't promote it just yet.. would like to test and find reasoning for why the profile was disabled before progressing.
[14:39] <Daviey> jdstrand: thanks
[14:39] <infinity> cjwatson: Or maybe Sledge's assertion is just not quite right.
[14:39] <cjwatson> I'm confused about why compiling and linking separately works, then.
[14:39] <jdstrand> infinity: it meets the requirements for the MIR, yes. you'll need to talk to Daviey on whether it is suitable as is
[14:40] <infinity> cjwatson: The assertion should be (essentially) checking exactly the same thing as the above readelf bit.
[14:40] <infinity> cjwatson: That said, it's possible to produce ELF object with broken/incomplete headers (remember libicu?)
[14:41] <cjwatson> The link lines look identical.
[14:41] <infinity> cjwatson: So maybe llvm/clang is doing something sketchy with interim objects.
[14:41] <cjwatson> Modulo input file name.
[14:41] <cjwatson> "/usr/bin/ld" -z relro -X --hash-style=gnu --as-needed --build-id --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-linux-armhf.so.3 -o t /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf ...
[14:41] <cjwatson> ... -L/lib/arm-linux-gnueabihf -L/usr/lib/arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib/arm-linux-gnueabihf -L/lib -L/usr/lib/arm-linux-gnueabihf -L/usr/lib t.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ...
[14:41] <cnd> skaet, infinity: we've had multiple positive test reports of xorg-server in -proposed on the ubuntu-desktop and ubuntu-x mailing lists, and the bug reported has confirmed that the package resolves his issue
[14:41] <cnd> just fyi in case you want to respin with it
[14:41] <cjwatson> ... /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crtn.o
[14:41] <infinity> cjwatson: Oh, wait.  When you do them serially, it doesn't bitch?
[14:41] <cjwatson> infinity: Correct
[14:42] <cjwatson> Wait
[14:42] <cjwatson> Sorry, I must have done something wrong, it does complain now
[14:43] <gema> skaet: server images created with usb-creator end up in an endless loop and are not properly verified
[14:43] <gema> skaet: with dd, everything seems to be good
[14:43] <Daviey> !
[14:43] <gema> skaet: so the problem is with usb-creator
[14:43] <skaet> gema,  thanks for finding this.  urk.
[14:43] <Daviey> gema: This is a recent thing, as the problem WAS the other way around
[14:43] <cjwatson> Ah, OK, I don't think it's the linker step.  'clang -c t.c -o t.o && clang t.o -o t' asserts; 'gcc -c t.c -o t.o && clang -v t.o -o t' fails.
[14:43] <cjwatson> ev: ^- could you look into that usb-creator bug?
[14:43] <gema> Daviey: maybe, this was my first day with server, so I hadn't really been verifying a lot of images on desktop
[14:44] <Daviey> gema: can you confirm what options you selected in usb-creator?  persistence ?
[14:44] <ev> gema: what do you mean by an endless loop?
[14:45] <cjwatson> infinity: In both the above two cases, 'readelf -A t.o | grep Tag_ABI_VFP_args' output is identical.
[14:45] <gema> ev: if you burn a usb stick with usb-creator, one of the server images either i386 or amd64, and when you start the install you go to "Check disk for defects", you end up in an endless loop
[14:45] <gema> ev: if you dd the image, on the other hand, it verifies ok
[14:45] <cjwatson> Endless loop displaying a memory check UI?
[14:45] <cjwatson> Oh, sorry, defects not memtest
[14:45] <cjwatson> Never mind me
[14:45] <gema> ok
[14:46] <gema> memtest is fine as far as I am concerned
[14:46] <cjwatson> What's it doing while in the endless loop?
[14:46] <skaet> thanks for letting us know cnd.    At this point its best to plan on this for a later SRU - too much churn elsewhere.
[14:46] <cjwatson> I mean, what's on the screen?
[14:46] <gema> cjwatson: let me pull it again and I will tell you the message
[14:46] <Daviey> gema: Oh, i suspect you are the first person all cycle to select "Check disk for defects"
[14:47] <gema> Daviey: I am afraid so, even though it is the first step on every server install xD
[14:47] <Daviey> gema: s/step/option/
[14:47] <gema> Daviey: step, as in test case step
[14:48] <gema> Daviey: all the test cases have that at the beginning
[14:48] <Daviey> ahh
[14:50] <hallyn> ev: hey, created a bootable usb yesterday from live desktop precise image, crashed during install.  (It said it would reboot and let me file a bug, but doesn't seem to have saved anything to the usb writeable partition and isn't doing that, i'm afraid)
[14:50] <gema> cjwatson: it scans the CD ROM and it says [!] Configuring d-i/ No valid Ubuntu CD-ROM, The CD-ROM you have inserted is not a valid Ubuntu CD-ROM. Please change the disk
[14:50] <gema> cjwatson: and you are stuck there, there is only a "continue" option that doesn't do anything but showing the same dialog again
[14:51] <ev> hallyn: if there aren't any logs, there's really nothing we can do to fix it
[14:51] <ev> whatever it was
[14:51] <hallyn> ev: of course not, just a heads-up
[14:51] <hallyn> meanwhile, re-trying
[14:51] <infinity> cjwatson: Eh?  'gcc -c t.c -o t.o && clang -v t.o -o t' doesn't fail here.
[14:52] <cjwatson> infinity: Sorry, too many negatives.
[14:52] <cjwatson> infinity: clang -c asserts, gcc -c succeeds.
[14:52] <infinity> clang -c t.c -o t.o && readelf -A t.o
[14:52] <cjwatson> So it's the .o clang's producing that's at fault, not its link step.
[14:52] <infinity> It's either not a hardfp binary, or it's getting broken ELF headers, as I suspected.
[14:53] <cjwatson> gema: Could you mount the produced USB stick and pastebin 'ls -l' of its top-level directory?
[14:53] <ev> gema: what does syslinux/syslinux.cfg contain?
[14:53] <ev> ah, that too
[14:53] <gema> indeed
[14:53] <gema> jsut a sec
[14:54] <cjwatson> That error message indicates that (following symlinks) either (a) .disk is not a directory (b) ubuntu is not a directory (c) md5sum.txt is not a regular file
[14:54] <infinity> cjwatson: Actually, it is a hardfp binary, according to the headers, but it's also nonsense (and probably a lie)...
[14:54] <infinity> cjwatson: v4t, thumb-1...
[14:54] <infinity> If this isn't a lie, it should be. :P
[14:55] <cjwatson> I note "-triple armv4t-unknown-linux-gnueabihf"
[14:55] <cjwatson> (in 'clang -v t.c -o t')
[14:55] <ogra_> awww
[14:55] <gema> cjwatson, ev: http://paste.ubuntu.com/942601/
[14:56] <ev> gema: ls -la :)
[14:57] <cjwatson> Shouldn't need -a
[14:57] <cjwatson> Oh, we should
[14:57]  * cjwatson on bad form today
[14:57] <cjwatson> Anyway, no ubuntu directory or symlink there
[14:57] <cjwatson> I guess vfat doesn't do symlinks, hmm
[14:57] <gema> ev: http://paste.ubuntu.com/942603/
[14:58] <cjwatson> Not sure what to do most correctly.  We could nobble cdrom-checker to check for dists instead of ubuntu.
[14:59] <ev> that sounds sensible, given that there are other tools out there beyond usb-creator that do equally stupid things in this case
[14:59] <cjwatson> But we'll have to rebuild d-i for that.
[14:59] <cjwatson> skaet: ^-
[14:59] <ev> (unetbootin creates 0 byte files when it encounters a symlink)
[14:59] <cjwatson> So that'll be netboots, alternates, servers
[14:59] <infinity> cjwatson: Oh, as to the "upstream changelog" for axiom, it's basically unreadable. :P
[15:00] <cjwatson> infinity: I guess with no rdeps I basically don't care.  Have your FFe and let's get it build.
[15:01] <cjwatson> built.
[15:06]  * infinity grabs cdrom-cheker to review.
[15:06] <cjwatson> The diff is pretty obvious; I was going to wait for agreement on whether we want that respin.
[15:07] <cjwatson> It's a fairly contained set of images.
[15:07] <gema> so, where do you guys want me to put the bug, on usb-creator, on the cdrom-checker?
[15:08] <infinity> cjwatson: We seemed to have already agreed here.
[15:08] <cjwatson> cdrom-checker, but I already uploaded a fix without any bug number in the changelog
[15:08] <skaet> cjwatson,  given its fairly confined, and testing hasn't progressed too far.
[15:08] <Daviey> cjwatson: i'd really appreciate if d-i went via -proposed if we are doing it.. i think that most people seem to use USB these days makes it a worthwhile fix for release
[15:08] <cjwatson> So no need for a bug really
[15:08] <infinity> cjwatson: And accepted, after I looked at wider context. :P
[15:08] <cjwatson> Daviey: the two halves of that sentence seem contradictory?
[15:09] <ScottK> Daviey: Did you find an archive admin to binary New the quantum FFe you approved?
[15:09] <gema> cjwatson: ok, then I won't put a bug there
[15:09] <ScottK> In the meantime it probably shouldn't be accepted.
[15:10] <cjwatson> ScottK: o/
[15:10] <ScottK> OK.  Thanks.
[15:10] <ScottK> Done then.
[15:11] <infinity> Daviey: There's no point in doing it in -proposed... We want it in release.
[15:11] <infinity> Daviey: (d-i, that is)
[15:11] <slangasek> doko: good-o
[15:11] <cjwatson> Yeah, d-i doesn't have arch skew problems.
[15:12] <Daviey> cjwatson: I mean, having an inconsistent d-i really breaks us.. so it would be nice to smooth the road, no?
[15:12] <cjwatson> Daviey: How so?
[15:13] <cjwatson> Daviey: I can't think of any problems caused by d-i building at different times on different architectures, in the absence of a kernel ABI bump.
[15:13] <cjwatson> Which there isn't here.
[15:14] <infinity> That's pretty much uniquely an issue with ABI bumps, isn't it?
[15:14] <cjwatson> Yes.
[15:14] <cjwatson> Daviey,zul: Er.  This quantum upload moves files between packages without Breaks/Replaces.
[15:14] <cjwatson> Daviey,zul: Please fix.  I won't accept this without that.
[15:14] <zul> cjwatson: ack
[15:15] <cjwatson> zul: Also, "debian/quantum-server.quantum-sever.upstart" typo
[15:16] <cjwatson> This results in your upstart job not being shipped.  Clearly not build-tested.
[15:22] <cjwatson> zul: I think you only need Breaks: quantum-server (<< 2012.1-0ubuntu3) and Replaces: quantum-server (<< 2012.1-0ubuntu3) in quantum-ryu-agent, not in the other quantum-*-agent, since that's the only file that moves.
[15:22] <cjwatson> (Is the lack of dependencies on *-agent intentional?  I don't know the packaging structure here.)
[15:22] <zul> cjwatson: yeah im testing it now
[15:22] <zul> cjwatson: it is
[15:23] <cjwatson> OK
[15:23] <cjwatson> Rejecting the current binaries; I'll be happy to review an update.
[15:28] <infinity> cjwatson: Oh, derp.  Thise assert is while iterating Tag_FP_arch, which isn't being written by clang/llvm.
[15:28]  * infinity needs to did into voodoo.
[15:31] <cjwatson> https://launchpad.net/ubuntu/+source/cdrom-checker/1.21ubuntu2/+build/3426318
[15:31] <cjwatson> Um, maybe we should get some of these armel builders recovereed?
[15:31] <cjwatson> -e
[15:35] <infinity> When was meissa disabled?
[15:36] <cjwatson> Dunno, but it blew up on the previous cdrom-checker build.
[15:36] <cjwatson> (I didn't disable it, I just thought about it)
[15:37] <infinity> I really want these machines running precise.
[15:37] <cjwatson> Well, something is critical-path, because I don't want to upload d-i with cdrom-checker out of sync
[15:39] <infinity> It's built now.
[15:39] <infinity> Sadly, 6 minutes later than you wanted.
[15:40] <zul> cjwatson: http://paste.ubuntu.com/942687/
[15:41] <cjwatson> zul: Why the chdir, and the removal of respawn?
[15:41] <cjwatson> zul: Also, this still doesn't fix the typo in the *file name* of the Upstart job
[15:42] <cjwatson> The one that means it doesn't get installed at all in your binary packages
[15:42] <zul> cjwatson: because if quantum-server it just keeps on respawning until someone notices
[15:42] <cjwatson> zul: The Breaks/Replaces is in the wrong place.  You need it on quantum-plugin-ryu-agent, not quantum-plugin-ryu
[15:42] <zul> gotcha
[15:43] <cjwatson> And 'bzr mv debian/quantum-server.quantum-sever.upstart debian/quantum-server.quantum-server.upstart' :-)
[15:43] <cjwatson> Or even just debian/quantum-server.upstart, probably.
[15:44] <apw> jbicha, just looking at the 'Ubuntu Desktop Guide' it says 'Welcome to Ubuntu 12.04' without the LTS
[15:45] <cjwatson> Actually that should have resulted in "/etc/init/quantum-sever.conf", I think, so you may want to test-build to find out why it went missing entirely rather than merely having a typoed name.
[15:49] <pitti> is someone already reviewing maas-provision, or want me to?
[15:49] <pitti> Daviey: ^
[15:49] <zul> cjwatson: works fine if i just rename it debian/quantum-server.upstart
[15:50] <zul> cjwatson: http://paste.ubuntu.com/942703/
[15:50] <Daviey> pitti: it's blocked on something, please wait.
[15:50] <pitti> ack
[15:52] <jbicha> apw: you could file a bug or submit a merge proposal for that if you like :)
[15:52] <cjwatson> zul: yep, that looks better now, thanks
[15:52] <infinity> jbicha: Submit a merge proposal for a 4-character fix? :P
[15:53]  * cjwatson creates the obvious basic wiki pages for quantal
[15:53] <jbicha> infinity: you trust my memory?
[15:54] <cjwatson> and might as well rename the LP series now too
[15:54] <pitti> cjwatson: can you? or does that require an RT?
[15:54] <pitti> I just had a look, but don't find a button for it
[15:54] <jbicha> I'm not sure yet when we're opening the ubuntu-docs branch for the SRU updates, if it's today, it's not hard to remember
[15:54] <cjwatson> pitti: I should be able to
[15:54] <cjwatson> Oh, maybe I can only change the displayname.  Let's see
[15:57] <cjwatson> OK, RT time I guess
[15:58] <NCommander> morning world
[15:59] <cjwatson> RTed
[15:59] <skaet> morning NCommander :)
[16:00] <skaet> thanks for renaming the series cjwatson.
[16:00] <jdstrand> Daviey: fyi, bug #987374. I suggest someone fix that before maas-provision is accepted, but please base the work on what is in unapproved now
[16:00] <ubot2> Launchpad bug 987374 in maas-provision "apparmor denials when using 'maas-import-isos'" [Undecided,New] https://launchpad.net/bugs/987374
[16:06] <infinity> cjwatson: I can change the series name.
[16:07] <cjwatson> Huh.  Where?
[16:07] <cjwatson> You surely don't still have a ducky
[16:07] <infinity> cjwatson: You could change your RT to be a request for quantal-changes.
[16:07] <infinity> cjwatson: (I just fixed the name in LP)
[16:08] <cjwatson> You're in ~launchpad, I guess that might help?
[16:08] <infinity> Yeah, that's what does it for me.
[16:22] <apw> jbicha, bug #987385
[16:22] <ubot2> Launchpad bug 987385 in ubuntu-docs "the Help/Ubuntu Help page lists the release name as 12.04 without the LTS" [Undecided,New] https://launchpad.net/bugs/987385
[16:30] <ev> cjwatson: do you happen to know why the alternates, specifically the server alternate, has vga=788 set? Do we not want to defer to the kernel on that?
[16:30] <ev> apw noticed that the Dell system he's testing on really doesn't like that mode
[16:31] <cjwatson> ev: It's loads faster on most systems
[16:31] <cjwatson> see the changelog
[16:31] <ev> ah, okay
[16:31] <cjwatson> debian-installer (20100211ubuntu11) maverick; urgency=low
[16:31] <cjwatson>   * vga=788 seems to work now that vesafb and fbcon are built into the
[16:31] <cjwatson>     kernel, and it's very much faster in kvm, so resync with Debian and use
[16:31] <cjwatson>     it.
[16:31] <cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Mon, 28 Jun 2010 17:44:51 +0100
[16:32] <cjwatson> Also, we aren't using full KMS in d-i, IIRC, and so the kernel would ordinarily just give us a really basic text mode
[16:32] <cjwatson> This is nicer to use
[16:33] <apw> cjwatson, ok it is occuring on a dell mini 10v, not on my hp mini so i assume it is not everywhere at least
[16:34] <Daviey> Please can maas-provision be accepted into -proposed only (current target pocket)
[16:36] <infinity> Done.
[16:47] <infinity> cjwatson: So, yeah.  Not sure if this is llvm's fault or clang's.  But one or both of them need to be hit with a hammer to map GNUEABIHF to armv7-a, and then to stop assuming that armv7-a means neon. :P
[16:49] <NCommander> infinity: ew
[16:49] <cjwatson> infinity: Are you going to keep working on it?
[16:51] <infinity> cjwatson: Yeah, I can probably just fix it in clang for now, and worry about llvm in a more careful SRU later.
[16:51] <cjwatson> OK, cool
[16:51] <infinity> It irks me that all this arch detection stuff seems to happen in two places.
[16:51] <infinity> If clang is meant to be an llvm frontend, why duplicate it all (and get it differently wrong?)
[16:53]  * NCommander shivers at menthion of clang
[16:55]  * skaet sees WUBI update, and goes to revert it manually.
[16:56] <tumbleweed> ^ anyone feel like uploading the precise-proposed version of that? I can't. bug 987390
[16:56] <ubot2> Launchpad bug 987390 in distro-info "[SRU] Add Quantal to distro-info-data in oneiric" [Medium,Fix committed] https://launchpad.net/bugs/987390
[16:57] <slangasek> does kubuntu use network-manager?  I don't see network-manager-kde seeded on the ISOs
[16:57] <slangasek> I'm actually trying to figure out if the dnsmasq release note is relevant to kubuntu or if it's only relevant to ubuntu desktop
[16:57] <slangasek> (currently it's being included in the release notes for all the products)
[17:03] <skaet> slangasek,  we're heading off for dinner here now,  when the maas-provision lands,  can you kick off the respins when [22][23] show up, if I'm not online.
[17:03] <skaet> ?
[17:05]  * cjwatson -> evening.  May not be around much tonight; up early tomorrow to head for London.
[17:07]  * skaet will check in again after food.
[17:09] <slangasek> skaet: yep, will watch for
[17:12] <micahg> cjwatson: ~130 removals, nice :)
[17:15] <jdstrand> ok, I promoted maas-provision
[17:15] <jdstrand> and demoted cobbler
[17:19] <pitti> good night!
[17:30] <Daviey> jdstrand: thanks!
[18:25] <slangasek> cjwatson: based on feedback from the CD people who rightly point out that using all the sectors for data is a violation of Red Book format, I've lowered our CD size limit back down a smidge, after confirming that none of the precise images currently exceed it
[18:26] <slangasek> but just in case the images get bigger between now and Thursday, better safe than sorry
[18:32] <cjwatson> slangasek: OK, thanks
[18:33] <slangasek> cjwatson: was there going to be a d-i upload for cdrom-checker?
[18:33] <slangasek> I see cdrom-checker itself updated and in
[18:33] <cjwatson> Oh, yes, I forgot
[18:34] <slangasek> ok
[18:34] <cjwatson> Can't do it right now, either I can do it in an hour or so, else feel free
[18:34]  * slangasek cancels the alternate CD respins, since we probably want that update in for consistency
[18:34] <cjwatson> Yes, sorry
[18:34] <slangasek> just a no-change upload of d-i?
[18:35] <cjwatson> Yes
[18:35] <slangasek> ok, will do
[18:36] <cjwatson> to precise, not -proposed
[18:36] <slangasek> understood
[18:38] <ScottK> slangasek: Kubuntu does use NM.  The front end is plasma-widget-networkmanagement.
[18:38] <slangasek> ok
[18:39]  * slangasek drops this into the Kubuntu release notes as well then
[18:40] <slangasek> ScottK: well... except there doesn't seem to be a section for it.  Do you want the dnsmasq release note integrated somewhere on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu ?
[18:40] <slangasek> on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop I stuck it under "Desktop Interface"... I guess I could redo the Common Infrastructure include to allow sticking things under the heading that aren't actually common :P
[18:41] <ScottK> Just a sec.  Let me get the guy that's doing the release notes.
[18:42] <slangasek> ok :)
[18:42] <slangasek> oh grr, the command on the pad backgrounds the job, wth
[18:42] <ScottK> slangasek: claydoh is doing the Kubuntu release notes.
[18:43] <ScottK> claydoh: slangasek had a question about where to include the dnsmasq changes that are common to Kubuntu and Ubuntu in the Kubuntu release notes.
[18:43] <slangasek> claydoh: hey there - I was telling ScottK that I've pulled the release note for dnsmasq out of our "Common Infrastructure" page because it's not common except to desktops, and wondering if you wanted this pulled back into https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Kubuntu in some fashion
[18:43] <slangasek> (https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop shows the note in question)
[18:43]  * ScottK thinks it ought to be in the Kubuntu notes somewhere.
[18:44] <slangasek> claydoh: I basically agree with ScottK, but don't know where to put it :)
[18:45] <claydoh> slangasek:  I will look
[18:47] <slangasek> ok, apparently trying to do a fresh bzr checkout of d-i for this upload was a mistake
[18:47] <slangasek> I'll just apt-get source and commit after
[18:47] <slangasek> much after
[18:47] <claydoh> slangasek: I don't see why it can't be kept where it was
[18:47] <slangasek> claydoh: because that include file was being pulled into the release notes for all images, including server and core, where it's false
[18:48] <claydoh> slangasek: oh, ok
[18:53] <slangasek> self-accepting d-i
[18:55] <ScottK> python-scipy reject was discussed with the uploader.  It'll come back in a few minutes.
[18:55] <claydoh> slangasek: I could format Kubuntu's page to reflect the layout for UbuntuDesktop and then place it in a similar area
[18:56] <slangasek> claydoh: if you wish; my other idea was to munge the way we're doing the include, so that we can shove almost-common stuff in between the header and the include
[18:57] <ScottK> Common and Desktop Common (matches the seeds)
[18:59] <ScottK> Should I be concerned about "CD image kubuntu/precise/daily failed to build on 20120423.1"?
[18:59] <claydoh> slangasek: whichever is better for  you. Desktop Common would seem to be an appropriate place
[18:59] <slangasek> ScottK: no, that's me properly ^Cing the alternates that I started before noticing d-i needed an update
[19:00] <ScottK> OK.  Thanks.
[19:04] <slangasek> ScottK, claydoh: stuck in a 'Desktop Infrastructure' section on the page, is that what you want?  Feel free to edit to taste here
[19:04] <ScottK> Thanks.
[19:04]  * ScottK looks at claydoh
[19:06] <claydoh> ScottK: slangasek I like it
[19:12] <ScottK> Kubuntu Desktop powerpc test results!  That's a pleasant surprise.
[19:18] <Riddell> good evening
[19:56] <gema> there seems to be a problem with the indicator in desktop arm, when there is no wired connection and you are installing and giving it a wireless password, it shows a non-existent wired connection going on and off
[19:57] <gema> and it takes forever for it to actually show the indicator of wireless connected, even though the network is authenticated
[19:57] <ogra_> on what platform is that ?
[19:57] <gema> pandaboard desktop arm
[19:57] <gema> I am installing without wire
[19:57] <ogra_> can you file a bug please ...
[19:58]  * ogra_ hasnt tested wlan for a while, wired works fine usually
[19:58] <gema> yes, I am waiting for it to finish installing, I have taken pictures and I will attach
[19:58] <ogra_> thanks
[19:58] <gema> will give you bug no whenever I have it
[19:58] <ogra_> please subscribe (not assign) ubuntu-arm to it
[19:58] <gema> ok
[19:58] <ogra_> then it will show up on the arm list
[19:58] <gema> I cannot assign anyway :)
[19:59] <ogra_> ah, right :)
[20:00] <gema> it is very annoying, it keeps saying Wired Network disconnected
[20:20] <gema> ogra_: bug 987511
[20:20] <ubot2> Launchpad bug 987511 in network-manager "network manager not handling properly wireless only on pandaboard" [Undecided,New] https://launchpad.net/bugs/987511
[20:20] <gema> I subscribed your team
[20:36] <jbicha> heh, quantal's not even in the auto-correct dictionaries :( I guess that's a good SRU candidate
[20:36] <knome> jbicha, "xubuntu" isn't either... oops!!
[20:36] <ScottK> knome: That's on purpose.

[20:36] <knome> :P
[20:37] <knome> anybody familiar with the dictionaries?
[20:37] <ScottK> Yes.  I make my kids use one every time they ask me how to spell a word.
[20:38] <knome> ScottK, bad jokes day?
[20:38] <ScottK> Awwh.  Come one.  Those were great jokes.
[20:38] <ScottK> The second one is just being ironic since I do that.
[20:38] <knome> why not come two.
[20:38] <ScottK> one/on anyway.
[20:38] <knome> btw, is ScottL a better version of you?
[20:39] <knome> even lts.
[20:39] <ScottK> No.  He's always claiming to be at work.
[20:39] <knome> isn't that a good work?
[20:40] <ScottK> Whereas I work from home, so I am in fact at work even when I'm at home.
[20:40] <knome> err, s/work/thing/
[20:40] <ScottK> No idea.
[20:40] <knome> same here.
[21:07] <ScottK> What package ships the "Prepare for shipping ..." bits in oem mode?
[21:09] <ogra_> ScottK, should all be ubiquity nowadays
[21:09] <ScottK> ogra_: Thanks.
[21:13] <ScottK> OK.  With the Kubuntu alternate doing an OEM install doesn't result in oem-config-kde getting installed.  Suggestions on where to look for that problem?
[21:19] <slangasek> cjwatson: I see various changes to the pipeline command for arm on the pad that I don't understand.  What are these sleep 10's for?
[21:22] <slangasek> I'm also confused that the entire sequence is now being backgrounded, instead of just the cron.daily part
[22:07]  * Daviey checks in
[22:10]  * ScottK tut tuts about asterisk.
[22:13] <cjwatson> slangasek: It was sleep 1 last I checked, and it was just to make sure that the starting message for each sequence were disjoint.  The entire sequence is now backgrounded because every ARM build type is now being dispatched to its own livefs builder.
[22:14] <cjwatson> So we don't need to block on one set of livefses before starting on the next.
[23:02] <slangasek> cjwatson: ah right
[23:10] <stgraber> ScottK: just saw your message from earlier. Assuming oem-config-kde is on your media, the place to look for it is in ubiquity as that's where the oem udebs come from
[23:11] <stgraber> ScottK: I fixed an issue there recently with the ubuntu slideshow not being installed. Keep in mind that even though it's the same branch, the desktop and alternate code paths are different, so you'd likely need to update both.
[23:12]  * stgraber goes to bed now, talk to you all tomorrow
[23:44] <ScottK> It works fine on the Kubuntu desktop CD and is present on the alternate, just not installed.
[23:46] <cjwatson> Check the installer syslog for an attempt to install it
[23:46] <cjwatson> It's meant to work as follows:
[23:47] <cjwatson>  * oem-config-udeb/frontend is preseeded to "kde" on Kubuntu images (/preseed/kubuntu.seed on the image)
[23:47] <cjwatson>  * ubiquity/finish-install.d/01oem-config-udeb (/usr/lib/finish-install.d/01oem-config-udeb in the installer environment) fetches that and feeds it to apt-install
[23:48] <cjwatson> Not meant to be *that* many moving parts here
[23:50] <ScottK> E: Unable to locate package oem-config-slideshow-ubuntu
[23:50] <ScottK> It seems to bail at that point.
[23:55] <cjwatson> Hmm.  Whoops.
[23:57] <cjwatson> Did you already file a bug for this?  (If not, don't worry, it's just for the bug number.)
[23:58] <cjwatson> The quick fix is to jam oem-config-slideshow-ubuntu into your seeds and respin.  The slow but correct fix is to change ubiquity to install oem-config-slideshow-ubuntu separately and not worry if it fails.