[01:12] <stgraber> cjwatson: so, while doing some kernel debugging today I noticed that my secureboot setup may have been a bit wrong for a while and it's not completely impossible that my succesful test was with my firmware in setup mode (after having somehow managed to wipe most keys while playing with the keyring), so I'm downloading today's image and will re-test to be sure
[01:41] <stgraber> cjwatson: ok, reinstalled, triple checked that SecureBoot is properly enabled and only contains the MS keys and install worked and system worked afterwards
[01:41] <stgraber> I did spot one of those efi disk error from grub at boot time though, but it didn't prevent it from loading all the needed files
[02:24] <micahg> Laney: thanks
[04:45] <RAOF> I wonder if we want to reword the accepted-into-proposed Launchpad bug text to emphasise *writing a comment* (and then setting the appropriate tag).
[04:45] <RAOF> I find it awkward to process SRUs that have the verification-done tag as the only activity after acceptance :)
[04:46] <ScottK> I agree it's awkward.
[04:47] <ScottK> I think that's a good idea.
[05:06] <infinity> RAOF: Patches welcome.
[05:06] <RAOF> infinity: https://code.launchpad.net/~raof/ubuntu-archive-tools/sru-accept-message-bikeshed/+merge/139384 :P
[05:36] <ScottK> infinity: Any idea where https://launchpad.net/ubuntu/quantal/+source/networkmanagement/0.9.0.5-0ubuntu1.1 went?
[05:36] <ScottK> I have the "waiting for approval" mail, but it seems vanished.
[05:38]  * ScottK uploads it again and waits to see what happens.
[05:39] <ScottK> Because it would be really nice to get that accepted for precise/quantal since we have another one about ready.
[05:45] <infinity> ScottK: The 404 implies it went nowhere...
[05:45] <ScottK> And it just did it again.
[05:45] <ScottK> Despite the queuebot, it seems to have gone into the ether again.
[05:46] <infinity> I see it in unapproved.
[05:46] <infinity> Twice.
[05:46] <infinity> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=network
[05:46] <ScottK> Facepalm.
[05:46] <infinity> Should we pass around a jar for new glasses?
[05:47]  * ScottK somehow ended up looking in New, not Unapproved.
[05:47] <ScottK> I rejected the extra one.
[05:48] <ScottK> It would be nice to get that one in and done as it's presence is (I think) cyphermox excuse for waiting to do the next one ...
[05:51] <infinity> After I finish my next round of glibc uploads, I think my "I'm on vacation, but a workaholic" mode will be mostly queue reviews.
[06:03] <ScottK> Excellent.
[06:09]  * ScottK wonders what to do about sivp and the opencv transition.  The sivp armhf binary (that jamespage already tried to fix) is the only thing standing between raring-proposed  and raring for opencv and a stack of other packages.
[06:09]  * ScottK could see either forcing the whole mess through and leaving sivp armhf out of date for now or doing a binary removal.
[06:20] <infinity> ScottK: I'd rather not do either.  If it's FTBFS without the source changing, it points to something elsewhere that really needs fixing, not ignoring.
[06:20] <ScottK> So just leave the whole transition waiting?
[06:21] <infinity> For now, anyway.  Not indefinitely, obviously.
[06:21] <infinity> I'll see if I can get someone to look a bit deeper.
[08:05] <doko> infinity, still awake?
[10:29] <doko> please don't accept the -defaults packages until powerpc is built
[11:10] <Laney> is ross a higher-specced machine than adare?
[11:13] <cjwatson> Laney: IIRC they're nominally identical
[11:13] <Laney> I ask because I got a timeout on webkit/adare and I checked the last few builds and they all went to ross or sulfur and were successful
[11:32] <doko> the linux-ppc build was faster on adare too
[15:34] <stgraber> again? :)
[15:44] <ScottK> stgraber: Yes.  Getting debian/copyright done right is SOOOO much fun.
[15:44]  * ScottK did 14 uploads yesterday to fix ones that got by him.
[17:30] <ScottK> infinity or cjwatson: Any thoughts on why this migrated before it was built on all archs? https://launchpad.net/ubuntu/raring/+source/kapman/4:4.9.90-0ubuntu1
[17:32] <plars> I did a bit of looking at https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1081721 yesterday and it seems that ubuntu-vm-builder doesn't use grub2 by default. It looks like in the past, grub-pc is an extra package that the auto-upgrade-testing scripts install at some point, but it doesn't seem that they automatically force the conversion to grub2 when they run.
[17:32] <ubot2`> Launchpad bug 1081721 in update-manager (Ubuntu) "quantal to raring upgrade: do-release-upgrade fails to install the new kernel" [Undecided,New]
[17:32] <cjwatson> ScottK: Because it was new
[17:32] <plars> I'm curious if anyone has thoughts on why it ever worked in precise, quantal... but not now
[17:32] <cjwatson> plars: vm-builder has awful amounts of release name hardcoding
[17:33] <infinity> ScottK: Migration only checks if it's out-of-date.
[17:33] <ScottK> Oh.
[17:33] <infinity> ScottK: If it didn't previously exist on $arch, it can't be out of date.
[17:33] <plars> cjohnston: indeed it does, but I don't think anything related to that changed
[17:33] <cjwatson> plars: the release name is now "raring"? :-)
[17:33] <plars> err... cjwatson rather, sorry cjohnston
[17:34] <cjwatson> or, well, I don't know, but when I looked at this last the vm-builder code was sufficiently obviously wrong (I think it had been last updated around natty, so was defaulting to ancient-mode for anything current) that I stopped looking
[17:34] <cjwatson> On the principle that once you've found a giant glaring problem it isn't worth looking for more
[17:34] <ScottK> It's new source, but not new binaries.
[17:35] <ScottK> The binary is out of date on powerpc now.
[17:35] <plars> cjwatson: the diff in the plugins between quantal, precise, oneiric... is pretty much just the name though
[17:35] <cjwatson> Huh.  Probably a bug in britney2 then.
[17:35] <cjwatson> plars: Honestly I don't know that it's worth investigating beyond the obvious thing.
[17:35] <infinity> ScottK: Oh, that's a bit unfortunate.
[17:36] <ScottK> That's why I was surprised.
[17:36] <cjwatson> Update it to do sensible things for current release names.
[17:36] <cjwatson> If it still goes wrong, then it might be worth investigating.  But as it is it's just hopelessly incorrect.
[17:36] <infinity> ScottK: Was that the only such fallout from the kdegames (I assume?) split?
[17:36] <infinity> ScottK: If so, I scored it up, and it'll solve itself shortly.
[17:36] <ScottK> infinity: It's the only one I noticed.
[17:36] <plars> cjwatson: true, I'm looking to work around it, just wanting to make sure that we don't miss something legitimate in the process
[17:37] <cjwatson> Why work around rather than fix?
[17:37] <ScottK> infinity: Given the number of KDE users on powerpc, I'm not overly concerned about the games packages.  I'm mostly worried do our tools DTRT.
[17:37] <infinity> ScottK: Yeah, agreed.
[17:38] <ScottK> OK.  There's my bug report ...
[17:38] <cjwatson> There's no point in auto-upgrade-testing testing upgrades from this artificially created scenario that doesn't correspond to anything installed since, er, 9.10 or thereabouts
[17:48] <jibel> plars, vm-builder is deprecated and auto-upgrade-testing must migrate to a solution that is maintained . A local cloud image + cloud-init for the initial setup is a viable solution.
[17:48] <jibel> That's something I never had time to do last cycle but must definitely be done.
[17:48] <jibel> the server team has a BP about it https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-vmbuilder
[17:49] <plars> jibel: does anyone else use auto-upgrade-testing though? I think our current plans are to move the upgrade testing to utah once utah can support things like snapshotting
[17:49] <jibel> plars, with vmbulder the only workaround is to fix the vm manually
[17:49] <jibel> plars, stgraber uses it for the flavor, but he uses the lxc backend IIRC
[17:49] <jibel> *flavors
[17:50] <ScottK> infinity: Now we get to find out what happens with a build for -proposed when the source is already copied to release and deleted ...
[17:50] <cjwatson> That happens lots.  It's fine.
[17:50] <plars> jibel: ok, I'll plan on just editing the template images for the time being then, it's a one-time thing in any case
[17:51] <cjwatson> Well, I think there's a bit of raciness if the copy fails, but other than that it's known to work.
[17:52] <ScottK> OK.  Good to know.
[17:58] <xnox> jibel: plars: utah can install systems from an ISO and reboot them, all that needs doing is ask utah to use old image, provision, and execute $ ssh do-release-upgrade in the runlist.
[17:59] <plars> xnox: yeah, I think it's mostly just missing the ability to recycle an old image at the moment, and a small amount of scripting around that. I'm not up on the current plans and whether they are much beyond that, but that's probably about all that's needed
[17:59] <xnox> plars: what do you mean by "recycle"?
[17:59]  * xnox thinks reboot & continue work is in progress.
[17:59] <plars> xnox: one that it didn't just install from a preseed
[18:00] <plars> xnox: we don't want it building the base image every time, because some of those base images take a *very* long time to build
[18:00] <xnox> interesting. I see.
[18:01] <jibel> xnox, we also want to create images with a specific set of packages, or upgrade with -proposed enabled, or the release-upgrader from bzr, ...
[18:02] <xnox> jibel: why would you want -proposed?
[18:02] <jibel> xnox, for LTS or SRUs
[18:03] <jibel> s/or/and
[18:03] <xnox> jibel: sounds like you want piuparts & loads of disk-space =)
[18:03] <xnox> ack.
[18:04] <jibel> xnox, it is not only about "installability" but also verify that upgrade paths are correct. We used it to verify apt fixes for example.
[18:58] <doko> ... and everything is blocked on powerpc
[22:43] <ScottK> It would be ever so nice if some kind AA could hit accept on the opendmarc sync in New (it's my sync).  I'd like to backport it, but it needs to be in raring first ...
[22:52] <slangasek> accepted (hope you weren't expecting me to look at it first)
[23:04] <ScottK> slangasek: Thanks.
[23:04] <ScottK> No.  I was not.
[23:05] <ScottK> It's a Debian sync, so I think it got as much looking as it needs.
[23:05] <slangasek> I would argue a self-accept is equally appropriate, then :)
[23:06] <ScottK> OK.  Noted.
[23:07] <ScottK> Thanks.
[23:10] <slangasek> n/p
[23:27] <infinity> ScottK: Debian syncs in NEW don't need any serious review, except maybe to note that it's not someone trying to fool the blacklist.
[23:27] <infinity> ScottK: (basically, the same cursory non-review we do for autosyncs)
[23:34] <ScottK> Right.  That's all I would do, but I was, I guess, being too much of a stickler about the no-self accepts.
[23:34] <ScottK> JFTR, the list of rejects is shorter this time.  We are making progress.
[23:43]  * infinity frowns as the ongoing kdegames queue saga.