[00:19] <cjwatson> * Chose apturl to satisfy xul-ext-ubufox
[00:19] <cjwatson> dear cdimage, what are you on, I'd like some
[00:20] <cjwatson> oh, never mind, that actually makes sense doesn't it
[00:21] <cjwatson> in that case I'm confused about why xul-ext-ubufox isn't on the lucid DVD
[00:24] <cjwatson> unless it's having trouble with the dependency changes between lucid and lucid-updates ...
[00:28] <cjwatson> oh, wow, germinate bug
[00:29]  * cjwatson tries to construct a unit test
[01:17] <cjwatson> Any chance of somebody on the MIR team looking at bug 922631?  I think it would clear precise_probs.
[01:17] <ubot4`> Launchpad bug 922631 in apache-pom (Ubuntu) "[MIR] apache-pom (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/922631
[07:49] <jibel> server images do not install this morning: no kernel module found
[07:52] <jibel> no kernels found sorry
[08:29] <pitti> hm, same for alternates
[08:30] <pitti> strange, d-i was rebuilt against -12
[08:30] <jibel> pitti, bug 924182
[08:30] <ubot4> Launchpad bug 924182 in debian-installer (Ubuntu Precise) (and 1 other project) "d-i images (server, alternate) failed to install: no kernels found (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/924182
[08:31] <jibel> it is not a problem with the version of the kernel
[08:32] <jibel> pitti, lines 15078 to 15116 in syslog
[08:34] <pitti> fallout from new apt?
[08:34] <pitti> jibel: on the bright side, nice to see that test_lts_upgrade_system.py succeeds now, and 3/4 _user.py
[08:36] <jibel> pitti, indeed. I must fix the upgrade tester to report unittest results correctly though.
[09:36] <cjwatson> jibel: looking
[09:44] <cjwatson> jibel: Where is your preseed file coming from?  You appear to be trying to use the amd64 preseed file on an i386 image.
[09:45] <cjwatson> jibel: They differ, in particular, on which kernel to use. :-)
[09:48] <cjwatson> That said I see that amd64 is failing too.
[09:56] <cjwatson> reproduced
[10:07] <cjwatson> Ah.  pitti is correct that it's fallout from the new apt.
[10:50] <Riddell> installing today's kubuntu ISO from USB disk it errors that it "could not set up local CD sources" or similar
[10:50] <Riddell> why is my debug log so short? http://starsky.19inch.net/~jr/tmp/installer/
[10:53]  * Riddell runs again with --debug
[10:56] <cjwatson> Riddell: look at syslog instead
[10:56] <cjwatson> (/var/log/syslog)
[10:57] <cjwatson> Riddell: I strongly suspect it's bug 924182 though
[10:57] <ubot4> Launchpad bug 924182 in apt (Ubuntu Precise) (and 1 other project) "d-i images (server, alternate) failed to install: no kernels found (affects: 1) (heat: 6)" [Critical,In progress] https://launchpad.net/bugs/924182
[11:09] <cjwatson> That's better.
[11:11] <Riddell> cjwatson: I don't think it is "an attempt to configure apt to install additional packages from the cd failed" http://starsky.19inch.net/~jr/tmp/installer/syslog
[11:11] <Riddell> E: Could not open file /cdrom/dists/precise/main/binary-i386/Packages - open (2: No such file or directory)
[11:12] <pitti> ^ sounds like that very bug, though
[11:12] <Riddell> pitti: really?  less scary error than "no kernel found"
[11:12] <Riddell> maybe this is USB vs CD install
[11:13] <pitti> Riddell: above but is apt falling over on a missing "Packages" file (as intended, it's Packages.gz)
[11:13] <pitti> s/but/bug/
[11:14] <cjwatson> Riddell: it's the same bug.
[11:14] <cjwatson> just different manifestation in d-i vs. ubiquity.
[11:14] <Riddell> pitti: yes, Packages.gz exists you're right
[11:15] <Riddell> cjwatson: ok thanks
[11:15] <cjwatson> I have a fix - just writing it up for the BTS.
[11:17] <Riddell> cool
[11:23] <cjwatson> uploaded - will rebuild all images once it's built and published, I guess
[13:15] <cjwatson> kicked off a number of rebuilds
[13:15] <cjwatson> not the full set, but the crontab is still enabled so I didn't think that was desperately important
[13:20] <cjwatson> jibel: could you try running the full set of upgrade tests on jenkins with release-upgrader-{apt,python-apt} from lucid-proposed?  ideally I'd like to see results from that published to jenkins
[14:17] <mvo> is a python-apt upload ok at this point or should I wait for after a2?
[14:23] <jibel> cjwatson, upgrade test with release-upgrader from -proposed seems to work, now the resolver resolves
[14:23] <jibel> but there is now this error "package dpkg is already installed and configured" on both arch while previous test on amd64 was ok.
[14:24] <jibel> I'm reverting to -updates and see if it pass
[14:28] <apw> are we aware the screen saver is not engaging on suspend/resume ... see rtg on #ubuntu-devel
[14:30] <cjwatson> mvo: what would it do?
[14:31] <cjwatson> jibel: hm, I suppose I did do a general update of release-upgrader-apt from precise so it could be something else in there ... sigh
[14:33] <mvo> cjwatson: some additional api (access to PkgPolicy.get_priority(), drops the need for python-debian and fixes .xz support for apt.debfile.DebFile()) (and another crash fix for multiarch debfiles)
[14:36] <stgraber> cjwatson: can you have nusakan push to the "Precise Alpha 2" milestone instead of "Precise Daily" (if not already done)?
[14:36] <cjwatson> stgraber: oops, yes, done no
[14:36] <cjwatson> w
[14:37] <cjwatson> mvo: do you think any of it is a2-critical?  I don't know how important the crash is, or what needs the new API
[14:37] <stgraber> cjwatson: thanks
[14:42] <mvo> cjwatson: not critical, no
[14:42] <mvo> I will wait for after a2 then, thanks
[14:47] <cjwatson> mm, I think that's probably best, thanks
[14:47] <cjwatson> enough stuff going wrong already and it's only Tuesday :)
[14:52] <pitti> precise is becoming much greener again, thanks cjwatson
[14:52] <pitti> (in jenkins)
[14:54] <cjwatson> phew
[14:54] <cjwatson> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html language pack badness again ...
[14:55] <pitti> yeah, just looking at this
[14:56] <pitti> I wonder what happened to language-pack-kde-ru
[14:56] <pitti> it's built, not in NEW, but also not in teh archive any more, WTH
[14:58] <pitti> cjwatson: kde-wae was built an hour ago, and is on cocoplum, that should resolve itself
[14:58] <pitti> cjwatson: I hope kde-ru is just somewhere in limbo in the publisher
[15:00] <cjwatson> 2012-01-31 11:35:32 ERROR   PoolFileOverwriteError: 92c921c793d4f95ec628f28ecb98cfdac50b61c7 != f6dd336dab9bd75d34ceefcb8bdfaf0348b51f2d for /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb, skipping. (OOPS-5a54afb4f69ef3bb6d25194cabc1af86)
[15:00] <ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=5a54afb4f69ef3bb6d25194cabc1af86
[15:01] <cjwatson> hm, there's also a corrupted file in /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb
[15:02] <cjwatson> that's non-trivially confusing
[15:02] <cjwatson> I've removed it from the pool since the publisher is clearly still trying and failing to publish it; hopefully the next run will wowrk
[15:03] <cjwatson> *wrk
[15:03] <cjwatson> damnit, YKWIM
[15:03] <cjwatson> it was 15668 bytes rather than the expected 899940
[15:04] <pitti> urgh, how could that happen? some bug in the langpack-o-matic upload script?
[15:04] <pitti> although that just calls dput, although 200 times in a row
[15:05] <cjwatson> no, it's clearly not on your side, it's fine in LP
[15:05] <cjwatson> there was a librarian deployment about that time ... I can only guess though
[15:10] <cjwatson> 2012-01-31 15:04:44 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/l/language-pack-kde-ru/language-pack-kde-ru_12.04+20120130_all.deb from library
[15:10] <cjwatson> looks better
[15:15] <cjwatson> pitti: what do you think of http://paste.ubuntu.com/823931/ ?  https://bugs.launchpad.net/ubuntu/+source/ruby-sinatra/+bug/843734 shows it working
[15:15] <ubot4> Launchpad bug 843734 in ruby-sinatra (Ubuntu Oneiric) (and 1 other project) "ruby-sinatra : Depends: ruby-rack but it is not installable (affects: 5) (dups: 2) (heat: 43)" [Undecided,Fix released]
[15:15] <cjwatson> it's a little cumbersome that you have to go to the queue web interface
[15:16] <pitti> cjwatson: I just hope approving them from the web ui is not subject to the very same timeouts
[15:16] <cjwatson> OTOH it's also cumbersome when you have to ssh to cocoplum and run copy-package.py
[15:16] <pitti> yes, it is
[15:16] <cjwatson> I shouldn't have thought so, it'll have done a bunch of the work by then
[15:16] <cjwatson> I can wait until there's an opportunity to copy something huge if you prefer, and we can stress-test that
[15:16] <pitti> and at least it can then also be done by the whole SRU team
[15:17] <pitti> cjwatson: I'm sure the next kernel update isn't that far out; we just copied unity yesterday, that was also a good one
[15:17] <pitti> cjwatson: but anyway, I'd say go ahead with it
[15:17] <pitti> and we'll see how it goes
[15:17] <pitti> bzr is good at remembering the old code, if we have to :)
[15:18]  * cjwatson tidies the output slightly
[15:18] <cjwatson> yeah :)
[15:19] <ogasawara> skaet: bug 923512, we're still trying to isolate the regression.  I would like to upload a fix if we are able to find it in time.  If the window to upload has passed, I'll release note it.
[15:19] <ubot4> Launchpad bug 923512 in linux (Ubuntu) "ath9k wireless stopped working after kernel upgrade to 3.2.0-12 (affects: 2) (dups: 1) (heat: 18)" [High,Confirmed] https://launchpad.net/bugs/923512
[15:20] <skaet> ogasawara, ping when you find the regression and we'll see where we are with the other issues.
[15:20] <cjwatson> pitti: done
[15:20] <ogasawara> skaet: a test kernel which reverts what we believe is the offending patch is being built right now, then we're gating on feedback from reporters.
[15:21] <ogasawara> skaet: am trying to find someone with hw that uses ath9k to see if we might be able to speed up the testing process.
[15:21] <skaet> ogasawara, thanks
[15:27] <stgraber> ogasawara: I have a USB ath9k device if that helps
[15:28] <ogasawara> stgraber: I just found out serge can reproduce.  I'm assuming we can get a quick test confirmation from him, if not I'll come find you.
[15:29] <ogasawara> stgraber: thanks
[15:45] <skaet> slangasek, could you update #uubntu-devel to indicate we're soft frozen now?   I lack ability to be op in that channel.
[15:48] <cjwatson> You do?  I thought we fixed that ages ago.
[15:48] <cjwatson> 15:48 -ChanServ(ChanServ@services.)- 7     skaet                  +tA [modified 1 year, 16 weeks, 3 days, 03:40:52 ago]
[15:50] <skaet> cjwatson,  it appears not.  I just tried to get operator status to update the header, like I did for ubuntu-release, and got back: * #ubuntu-devel :You're not a channel operator
[15:50] <skaet> PBKAC?
[15:50]  * skaet doesn't rule it out anyway... ;)
[15:51] <cjwatson> Yes, but you can use the topic command to chanserv.
[15:51] <cjwatson> /msg chanserv topic #ubuntu-devel new topic blah blah blah
[15:52] <cjwatson> (Which should work here too.)
[15:53]  * skaet trying
[15:53] <Riddell> http://iso.qa.ubuntu.com/qatracker/milestones/206/builds lists 20120131 when it should be 20120131.2 n'est pas?
[15:53] <cjwatson> Possibly I didn't change .isotracker.conf in time.
[15:54] <cjwatson> If you want to get me a list of new builds to post then I can post them
[15:55] <skaet> cjwatson,  chanserv new topic worked. \o/
[15:55] <cjwatson> good, except the "new topic" bit was meant to be a placeholder :)
[15:55] <skaet> thank you.
[15:55] <cjwatson> 15:54 -!- Irssi: Topic: -: Archive: open
[15:55] <cjwatson> 15:54 -!- Irssi: Topic: +: new topic Archive: soft freeze for Alpha 2
[15:55] <skaet> lol
[15:55] <skaet> fixing now
[15:57] <skaet> done.
[15:57]  * skaet goes to get more coffee,  it appears needed today.
[15:59] <jibel> skaet, stgraber all builds published to the tracker excepted ubuntu-studio
[16:00] <jibel> for ubuntu-studio there's no alternate since last week, DVD is available but not listed on the releaseimagecontacts page
[16:00] <jibel> does DVD replaces alternate ?
[16:01] <cjwatson> yes
[16:01] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/other-p-ubuntustudio-livedvd
[16:02] <jibel> thanks
[16:15] <skaet> thanks fro updating the manifest jibel. :)
[16:15] <skaet> (or rather the image contacts ;) )
[16:16] <Riddell> yay kubuntu ISO installs good
[16:17] <skaet> :)
[16:17] <jibel> cjwatson, I built a fresh lucid desktop amd64. without proposed, upgrade succeeds. with -proposed enabled it fails.
[16:18] <pitti> cjwatson: could you perhaps apply your magic trick for language-pack-kde-wae again?
[16:18] <pitti> cjwatson: -ru is gone from precise_probs, -wae is still there
[16:18] <pitti> the others are just armel buildd skew
[16:19] <cjwatson> I'm not seeing a similar problem there
[16:21]  * pitti checks again
[16:22] <pitti> oh crud, I know; sorry, cjwatson
[16:22]  * pitti makes a mental note to actually update the branch on macquarie when pushing fixes to bzr
[16:22] <doko> with the soft freeze in place ... I'm starting the test rebuild now ...
[16:25] <skaet> doko, we scheduled it for tomorrow...   I'm expecting we'll be doing some rebuilds of the images later today (mdeslaur's change, possible kernel update)
[16:26] <skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[16:32] <doko> skaet: you're over-optmistic that it will be done in one day ;-)
[16:32] <doko> it was meant to use the empty buildds during the freeze
[16:34] <skaet> doko,  slangasek is wrestling the bits this time around.   I leave the decision to him.  :)
[16:43] <pitti> hm, universe stuff is usually not covered by the freeze
[16:43] <micahg> pitti: some stuff is, anything shipped on an image
[16:44] <micahg> skaet: did the freeze start late for alpha2 or at the normal time?
[16:44] <pitti> I meant for expecting empty buildds
[16:44] <skaet> micahg,  it started late.   slangasek announced it for tuesday last week in release meeting,  so I held to that.
[16:45] <micahg> ah, yeah, and there are always security uploads, but usually the buildds are emptier during the freeze
[16:45] <micahg> skaet: ah, ok, so I won't go around slapping people with a fish then :)
[16:46] <pitti> wow, even powerpc got down to 14 minutes
[16:46] <skaet> pitti - really?   cool!
[16:47] <skaet> micahg,  you and doko probably should coordinate a bit to use the buildds - he has intentions there too. ;)
[16:48] <micahg> skaet: most of mine are surprisingly done, what's left is short and shouldn't impact anything, if I end up respinning for any reason, I'll let him know
[16:49] <skaet> micahg, great.  Thanks. :)
[17:00] <astraljava> Hey guys, Ubuntu Studio doesn't have test cases for Alpha-2. Anyone able to help us with that?
[17:04] <astraljava> Nevermind, jibel on -testing is taking care of this. Thanks!
[17:10] <mvo> cjwatson: I just merged your fix for apt back, sorry that its currently such a bumpy ride
[17:28] <mvo> skaet: I only just now uploaded the updated app-install-data, sorry, there was a bug in .xz code that I had to find/fix first
[17:32] <hallyn> i'd like to push a fix for lxc for bug 924281.  Any objections?
[17:32] <ubot4> Launchpad bug 924281 in cgroup-lite (Ubuntu) "cgroup-lite not installable inside 'lxc create -t ubuntu' container (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/924281
[17:34] <skaet> hallyn,  go ahead,  we're waiting for some other things to land before rebuilds occur.
[17:34] <skaet> slangasek, ^
[17:34] <slangasek> ack
[17:34] <slangasek> doko: feel free to go ahead with the test rebuild if you haven't already
[17:34] <slangasek> doko: provided you've reserved us a builder for each arch for emergencies
[17:35] <infinity> doko: Which arches are you test-rebuilding on?
[18:03] <slangasek> ScottK: I notice that there are kubuntu-mobile images still in the cdimage crontab, but they're not in the release manifest; should those be dropped?
[18:14] <ogasawara> slangasek, skaet: Fix for bug 923512 has been confirmed.  I'd like to upload if I may?
[18:14] <ubot4> Launchpad bug 923512 in linux (Ubuntu) "ath9k wireless stopped working after kernel upgrade to 3.2.0-12 (affects: 3) (dups: 2) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/923512
[18:18] <ogasawara> slangasek, skaet: the regression was introduced in upstream stable v3.2.2 so I've just reverted the offending patch.  it's already been reported upstream, so we'll follow up there.
[18:29] <skaet> ogasawara,  go ahead.
[18:29] <ogasawara> skaet: thanks
[18:37] <doko> slangasek, infinity, armhf, i386, amd64. herb did want to look for additional machines once the rebuild is started. reserving would be setting a buildd on manual ... I'll score down the big packages instead, so that wait times are short
[18:37] <doko> afk for diner now
[18:48] <infinity> doko: Kay, was mostly interested in which arm you were doing (armhf was my preference, so yay), and I'll re-balance the buildds a bit to compensate.
[18:50] <slangasek> doko: the plan out of the rally was that we *would* have a buildd set on manual
[18:57] <infinity> slangasek: Would it be good enough to reserve one of each of the old/first-gen buildds (crested, yellow, vernadsky, rothera)?
[18:57] <infinity> slangasek: If so, I can't see that hurting a rebuild much, since faster mashines like allspice and roseapple will tear through the process anyway.
[18:58] <infinity> machines, too.  Typing hard.
[18:59] <slangasek> infinity: yes; I don't expect any huge builds needed for respins (and if they are we can shoot builds in the head manually to free up resources)
[19:04] <utlemming> stgraber: can I have you add http://cloud-images.ubuntu.com/precise/20120131/ to the iso tracker?
[19:10] <stgraber> utlemming: pushed a bunch but the script then failed, looking at it now
[19:10] <utlemming> stgraber: thank you kindly
[19:16] <stgraber> utlemming: ok, added all these that exist on the tracker. We're apparently missing sa-east-* and us-west-*
[19:16] <stgraber> well, sa-east-1-* and us-west-2-* actually
[19:16] <utlemming> stgraber: missing them from the tracker or from the url?
[19:17] <doko> slangasek, ok, will do that. infinity: which one is the slowest i386?
[19:17] <stgraber> utlemming: either missing on the tracker or missing in our mapping table in the script. Everything looks good on your side AFAICT
[19:18] <stgraber> jibel: do you have a few minutes to add sa-east-1-amd64-ebs, sa-east-1-amd64-instance, sa-east-1-i386-ebs, sa-east-1-i386-instance, us-west-2-amd64-ebs, us-west-2-amd64-instance, us-west-2-i386-ebs and us-west-2-i386-instance to the tracker?
[19:18] <utlemming> stgraber: intersting...yeah, I see in the tracker it is scrapping off the -#, so US-West-2 and US-West-1 are mangled.
[19:19] <stgraber> jibel: (as in, adding the products and test cases for these, I'll update the script to push them once done)
[19:19] <utlemming> stgraber: also, I'm working on a query2 format that will deliver this information in JSON format...is that interesting for you guys?
[19:20] <stgraber> utlemming: published-ec2-daily.txt seems easy enough to parse for now, but json would work too indeed
[19:21] <stgraber> utlemming: we probably should look into running our script everytime the new AMIs are published so they automatically appear either as part of daily testing or as part of the current milestone testing
[19:24] <utlemming> stgraber: jamespage is looking integrating the test results automagically into isotracker. The problem that I see with running your script is on a schedule is that we promote a daily to a release-candidate. Since we don't want the released AMI's public till the release date, and we publish new AMI's for the current dev cycle daily, tracking them automatically could be bad.
[19:25] <utlemming> what I could do, is to work out something so that I can flag release-candidates so that you know if the tracker needs to be updated and then you could check that instead
[19:27] <stgraber> utlemming: what do you mean by "Since we don't want the released AMI's public till the release date"? does that mean you don't want daily testing of the AMIs? (in case that wasn't clear yet, I know close to nothing about EC2 ;))
[19:27] <utlemming> erm....we do want daily testing
[19:28] <utlemming> but the problem with EC2 is that there is a new AMI ID every time you build
[19:28] <utlemming> when we promote a daily to a release, alpha, whatever, it is re-registered
[19:29] <utlemming> so the AMI IDs that are on the tracker are the daily images that we've chosen as the candidate
[19:29] <utlemming> once we release the images, those AMI ID's are invalid
[19:30] <utlemming> basically, the easiest way to think of it is that we don't know the AMI ID's of the released images until after they are made public
[19:32] <stgraber> utlemming: ok, but there wouldn't be any problem with publishing all your dailies as part of the "Precise Daily" milestone on the tracker as we do for ISO images, have them published as "Precise Alpha 2" when doing milestone testing. What you're saying only seems to impact what goes in the release announcement (where the final IDs need to be put I guess)
[19:33] <utlemming> okay, I think I'm on the same page now
[19:33] <utlemming> yes, publishing all the dailies is fine, as long as they are flagged as dailies
[19:36] <stgraber> cool, might look into that when I have some time. Trying to get as much as possible to show up on the daily testing page :)
[19:40] <cjwatson> sigh, my germinate sync failed to build - I wish we would get mailed about that case
[19:40] <cjwatson> (I know, known bug)
[19:56] <GrueMaster> stgraber: Can you change Netboot armel+omap to Netboot armhf+omap (or add  Netboot armhf+omap).  We care more about armhf than armel.
[19:56] <GrueMaster> On iso.qa.ubuntu.com
[19:57] <stgraber> GrueMaster: oops, seems like we're missing Netboot armhf+omap in the DB indeed. Fixing that now
[19:58] <GrueMaster> thx
[19:59] <GrueMaster> Although I am not sure how long before I get to it.  8 images to test on omap and only 1 board.
[19:59] <slangasek> GrueMaster: "We care more about armhf than armel" - does that mean the armel/armhf decision has been made?
[20:00] <slangasek> last I heard it was still up in the air
[20:00] <stgraber> GrueMaster: done
[20:00] <infinity> doko: rothera, vernadsky, yellow, and crested are all basically the same vintage.
[20:00] <GrueMaster> No, not until before FF.
[20:00]  * slangasek nods
[20:00] <GrueMaster> However, we are leaning towards armhf.
[20:00] <infinity> slangasek: It's still up in the air, but we're trying to focus on armhf to influence the decision in the direction we all want it to go. :P
[20:00] <slangasek> ack
[20:10] <infinity> slangasek: The other reasonably fair point is that, other than archive skew, anything that works on armhf should work on armel, while the inverse isn't necessarily true.
[20:11] <slangasek> I don't follow that at all
[20:11] <infinity> slangasek: Since anything I do for armhf, I also do for armel, but there could be plenty of armel-specific hacks still kicking around causing armhf problems.  So, testing armhf seems the saner route to catch problems with both, if you're time-constrained and can't do both.
[20:11] <slangasek> unless we're talking about latent bugs due to the newness of armhf itself?
[20:11] <slangasek> oh, no, I'm upside down
[20:12] <infinity> Newness of the armhf toolchain, plus packages that might have armel hacks that haven't been duplicated on armhf.
[20:12] <infinity> Where can I find a lintian lab to do an rgrep of armel in debian/* BTW? :P
[20:12] <infinity> Sifting through that will suck, but I think it needs to be done.
[20:13]  * GrueMaster sees new desktop armel images finally showed up for today, sighs after testing most of the previous ones.
[20:13] <GrueMaster> s/armel/arm
[20:30] <slangasek> GrueMaster: in fact, there will be further builds today since there were several package uploads landing; the current daily images would certainly be fine for smoke testing in any case
[20:30] <GrueMaster> slangasek: Problem is I have limited resources (me) and a lot of images.
[20:31] <GrueMaster> I really don't want to be testing at 10pm again.
[20:32] <skaet> slangasek, have to step away for a bit - will be back on later.
[20:32] <slangasek> skaet: ack
[20:35] <jibel> stgraber, will do. test cases are the same than other instances ?
[20:36] <stgraber> jibel: yep
[20:36] <GrueMaster> slangasek: What packages have changed?
[20:36] <stgraber> jibel: I have the script updated here ready to post the new builds
[20:37] <stgraber> jibel: I went with "(South America)" and "(US-West-2)" in the script but feel free to use whatever you want on the tracker
[20:38] <slangasek> GrueMaster: nautilus, app-install-data, lxc, sudo; also the kernel, for an x86-specific fix
[20:38] <jibel> stgraber, I'll use the same naming convention.
[20:38] <slangasek> GrueMaster: a smattering of other packages - I don't have an exact list because the weather report doesn't have the preinstall images on it
[20:39] <GrueMaster> So essentially I am done for the day as far as real milestone testing goes.
[20:39] <jibel> stgraber, ec2 will need a dedicated tracker soon
[20:39] <slangasek> GrueMaster: I don't know what you mean by "real" milestone testing
[20:39] <GrueMaster> Since it will take several hours to build new images, and a few hours to pull them down locally.
[20:40] <GrueMaster> I.e. reporting into qa.iso.ubuntu.com.  Anything I test and report there will need to be retested/posted with the new images.
[20:40] <slangasek> yes, which is how this always works
[20:41] <GrueMaster> Well, last cycle I didn't have 2x the number of images (armel only).
[20:42] <GrueMaster> And I can't automate any of the preinstalled image tests.
[20:50] <slangasek> Riddell, ScottK: do you want libqapt1 rebuilt against current libapt for a2?
[20:52] <Riddell> slangasek: hmm not unless it needs to be
[20:52] <Riddell> do we know of any problems with old libapt?
[20:53] <slangasek> there are a number of bugs
[20:53] <slangasek> nothing that's going to be milestone-critical in that context however
[20:54] <slangasek> Riddell: probably the biggest win is it means you don't have to have two copies of libapt on the CD? :)
[20:55] <jibel> stgraber, http://paste.ubuntu.com/824402/
[20:55] <Riddell> slangasek: ach we're well oversized anyway, it won't help
[20:55] <stgraber> jibel: looks good, I'll push the builds now
[20:55] <jibel> stgraber, k
[20:56] <stgraber> yay, no error message this time!
[20:56] <stgraber> jibel, utlemming: should all be on the tracker now
[20:56] <astraljava> stgraber: skaet: What's the ETA for Ubuntu Studio image?
[20:57] <slangasek> astraljava: no eta yet, still waiting for an updated kernel package
[20:57] <astraljava> slangasek: Thanks!
[20:57] <slangasek> astraljava: you can assume it'll be at least 4h out
[20:58] <astraljava> That's fine. Thanks again!
[21:11] <slangasek> skaet: step 3 on -2days isn't anything I've seen / done before, is this mail something I should be sending?  (Or is this inherited from somewhere?)
[21:25] <stgraber> jibel: no testcase for Ubuntu Server EC2 instance (US-West-2) i386
[21:26] <jibel> stgraber, it's true
[21:26] <jibel> stgraber, fixed
[21:40] <Riddell> what is the capital X for in new queue info? http://paste.kde.org/197528/
[21:40] <slangasek> interesting question; I don't think I've ever seen that before
[21:41] <slangasek> I thought the allowed values were 'S-' for source, and '-B' for binary
[21:41] <Riddell> random bug? http://paste.kde.org/197534/
[21:41] <Riddell> fetch fails
[21:41] <slangasek> bug of some kind; whether it's random or not I don't know :)
[22:01] <Riddell> slangasek: sladen filed bug 924537 and wgrant says it's not a priority because new packages can be waved through
[22:01] <ubot4> Launchpad bug 924537 in launchpad ""queue fetch" requires a changes file which copies sometimes lack (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/924537
[22:02] <wgrant> It should be trivial, though.
[22:02] <wgrant> slangasek, Riddell: X is copy/sync
[22:02] <slangasek> ah
[22:03] <slangasek> "waved through" - we do want to make sure syncs are landing in the right component (universe vs. multiverse)
[22:27] <slangasek> hmm, apparently the typical time for a kernel build is a bit higher than I remembered.  I think I shall be pushing builds out without waiting, for smoketesting purposes
[23:32] <infinity> slangasek: For the record, the flash-kernel upload I just did only affects a subarch we don't ship, so shouldn't trigger rebuild mania.  But harmless if we do more respins later and incidentally pick itup.
[23:32] <slangasek> ack
[23:33] <slangasek> heh, new linux published on armhf, still waiting for the other archs
[23:35] <infinity> *flex*
[23:35] <infinity> (It sort of helps that armhf only builds one flavour...)
[23:39] <cjwatson> slangasek: syncs do land appropriately in universe/multiverse IME
[23:39] <cjwatson> slangasek: do I need to rebuild d-i for the new kernel?
[23:40] <slangasek> cjwatson: oh, then perhaps waving them through is the correct answer after all :)
[23:40] <slangasek> cjwatson: it's a non-ABI-changing upload
[23:40] <cjwatson> Riddell,wgrant: I thought about fixing that queue fetch bug, but TBH I hadn't been bothering because I was intending to supersede it soon enough :-)
[23:41] <cjwatson> slangasek: yeah, but do we need the changes to be reflected in the d-i initrds?
[23:41] <wgrant> cjwatson: Yep
[23:41] <wgrant> cjwatson: It's pretty trivial if someone does want to fix it, though.
[23:42] <cjwatson> Aye
[23:42] <slangasek> cjwatson: well, it contains a single fix for a wifi driver; any reason to rev the initrds for that?
[23:43] <cjwatson> Depends if it's in the initrds ... which driver?
[23:43] <slangasek> ath9k
[23:44] <cjwatson> well, it is in the netboot initrd, at least
[23:45] <cjwatson> not cdrom, so it's not critical path
[23:47] <cjwatson> ideally I'll be heading to bed unless there are any emergencies, so maybe somebody could do an upload there :)
[23:49] <infinity> I have ath9k on several of my systems here.
[23:49] <infinity> Not sure if that's an argument for rebuilding d-i, but yeah.  It's not uncommon, at any rate.