[00:26] <NCommander> Seems armhf+highbank fell off the ISO tracker
[00:26] <NCommander> Can someone magic it back on?
[00:28] <skaet> NCommander,  will do.   same pattern as arm+armadaxp?
[00:28] <NCommander> Yeah
[00:28] <NCommander> I'll run through the tests tonight to make sure everything is peachy
[00:38] <infinity> NCommander: Everything's peachy except that it doesn't boot.
[00:38] <NCommander> infinity: eh?
[00:39] <infinity> NCommander: uboot bug, Rob Herring is on it.
[00:39] <skaet> NCommander,  its up on the tracker now.   Let me know if something needs tweaking.
[00:39] <NCommander> infinity: boots just fine as of last week, though you need to do a magic poke before invoking anything
[00:39] <infinity> NCommander: Okay, sure, if you're poking initrd_high.
[00:40] <infinity> NCommander: If that's your definition of success go to town. :)
[00:40] <NCommander> infinity: it was in the oficial instructoins from Calxeda (with a note that it would be fixed so it would unnecessaary)
[00:41] <infinity> NCommander: Evidently, not everyone got that memo.
[00:41]  * cjwatson grows old and dies waiting for dogfood.lp.net QA.  Wanna go to bed.
[00:41] <infinity> NCommander: Including Calxeda...
[00:41] <infinity> NCommander: Since Rob just ran into it with the latest d-i and has been grumpily hunting the bug all day.
[00:41] <NCommander> cjwatson: good things come to those who wait?
[00:42] <NCommander> infinity: possibly we're getting bug confusion then; there was a known one where you had to do mw.l 800000 0 10000 to get the nitrd to load else the kernel goes off to lala land
[00:42] <infinity> NCommander: Different bug.
[00:43] <NCommander> !@#$#!
[00:43] <cjwatson> NCommander: They'd better
[00:50] <NCommander> infinity: ugh, yeah, the kernel blew up trying to decompress the ramdisk
[00:51] <infinity> NCommander: Yup.
[00:51] <NCommander> infinity: I *just* tried this with a precise kernel/ramdisk and it worked
[00:51]  * NCommander grumbles
[00:51] <infinity> NCommander: setenv initrd_high 0xffffffff
[00:51] <infinity> NCommander: It's the size of the initrd.gz that triggers it.
[00:51] <NCommander> infinity: thanks
[00:52] <infinity> NCommander: End up with the stack overlapping the initrd.
[00:52] <infinity> NCommander: Which, it turns out, is bad.
[00:52] <NCommander> the kernel usually doesn't like that
[00:54] <NCommander> infinity: that did the trick
[00:54] <NCommander> thanks
[00:54] <infinity> NCommander: cheers.  Happy testing.
[01:10] <vanhoof> pgraner: Daviey, slangasek, ogra_, updated 1010009
[01:10] <vanhoof> if you need any more specifics I have the sdcard waiting :)
[01:11] <slangasek> vanhoof: could you note explicitly whether rebuilding boot.scr helped or didn't?  (I assume it didn't)
[01:12] <vanhoof> slangasek: is my comment misleading?
[01:12] <vanhoof> slangasek: no change in behaviour in all three scenarios
[01:12] <vanhoof> stock, 1280, 1920
[01:13] <slangasek> vanhoof: not so much misleading as hard for me to parse at a glance - feel free to chalk this up to a parser bug on my part and ignore :)
[01:13] <slangasek> regardless, thanks for testing
[01:13] <vanhoof> slangasek: no worries, will clarify, I can see where theres room for question
[01:15] <vanhoof> slangasek: updated
[01:17] <skaet> vanhoof,  can you update your results on the iso tracker too.
[01:17] <vanhoof> skaet: certainly
[01:17] <skaet> thanks!  :)
[01:17] <vanhoof> I also have an original panda I can try as well
[01:17] <vanhoof> but you'll lose me from IRC ;)
[01:18] <vanhoof> *cough* great znc proxy *cough*
[03:29] <astraljava> Hi gang, how much time do we have until release announcements?
[09:25]  * cjwatson cheerfully deletes stuff from ArchiveAdministration
[11:28] <ogra_> stgraber, oh, you did a successfull panda install ? could you comment on bug 1010009 ?
[11:28] <ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed] https://launchpad.net/bugs/1010009
[13:13] <stgraber> ogra_: commented
[13:29] <skaet> good morning
[13:30] <skaet> Daviey, jibel, ogra_, infinity -  do we have any results for the Netboot armhf+omap4?
[13:31] <stgraber> skaet: if not, I can probably get you some result
[13:31] <skaet> stgraber,  would appreciate knowing no surprises.   Thanks!
[13:32] <stgraber> ok, will start an install before the 12.04.1 meeting then
[13:34] <Daviey> super
[13:35] <jibel> skaet, I don't
[13:38] <jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseAlpha2TestReport
[13:38] <jibel> oh sorry
[13:39] <skaet> thanks for the report jibel.
[13:39] <jibel> skaet, I'm sure you're interested by Quantal too
[13:39] <jibel> https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport
[13:40]  * skaet laughs,  yup.
[13:40] <skaet> The Quantal one is more handy,  no question.    Although the precise one is interesting for comparison purposes ;)
[13:42] <skaet> jibel,  can you cross check the stats on the top of the report.   Not seeing Ubuntu Desktop there,  only highbank
[13:42] <skaet> ?
[13:43] <jibel> skaet, just saw that. checking
[13:44] <Daviey> jibel: I was trying to find that earlier today!
[13:50] <jibel> found the problem: build.status = 4
[13:51] <jibel> skaet, the coverage includes everything that is not ready to be released, which makes it less useful
[13:51] <jibel> I'm regenerating a new report
[13:51] <skaet> jibel,  thanks.
[13:53] <stgraber> cjwatson: so are we now properly building all our precise images with -proposed enabled? (I'm planning on mentioning it in the 12.04.1 meeting)
[13:57] <cjwatson> stgraber: Not quite, I need to fix livecd-rootfs
[13:57] <cjwatson> So livefses aren't yet being built with -proposed, unfortunately
[13:57] <cjwatson> But I'll fix that by the end of the week
[13:58] <jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport
[13:59] <jibel> I should probably split the list in ready/not ready
[13:59] <Daviey> jibel: yes please
[13:59] <jibel> -> A3
[13:59] <Daviey> jibel: Is the script which generates this somewhere
[13:59] <Daviey> ?
[14:00] <jibel> Daviey, my junk
[14:01] <Daviey> jibel: well, i wasn't commenting on the quality of your code.. just hoping you'd share it. :)
[14:03] <jibel> it is not even in my junk, I'll commit it to the tracker branch
[14:05] <ogra_> skaet, just fyi, seems paolo has a fix for the kernel that, even though it does get me a black screen instead of a splash when booting (which can take 5-10 min on arm for live images) ... i get the proper X resolution once the X server is up
[14:06] <skaet> ogra_ that will be an improvement.  :)  Will he be aiming for including it in the next set of dailies?
[14:07] <ogra_> well, i assume he will upload as soon as we have some more test results
[14:07] <ogra_> i wouldnt upload it right now, after all it worked for me with the resolution on cmdline while it didnt work at all for others with the same panda model
[14:08]  * skaet nods
[14:08] <ogra_> so we should see if it works for pgraner, apw and vanhoof too first
[14:10] <pgraner> ogra_, I'll check in about 30 min...
[14:11] <ogra_> pgraner, great, see my comment to apw on #ubuntu-kernel
[14:49] <stgraber> armhf+omap4 is taking quite a while to install as I don't have a local ports mirror (yet)
[14:50] <skaet> ok,  thanks.
[14:50] <stgraber> but the base system, partitioning, ... succeeded, just waiting for ubuntu desktop to install now ;)
[14:51] <skaet> vanhoof,  can someone from your team do a sanity check on netboot for armadaxp?   NCommander did highbank yesterday.
[14:52] <vanhoof> skaet: sure one sec
[14:56] <ogra_> stgraber, urgh, you should just have done a minimal install :P
[14:56] <stgraber> ogra_: so I thought after I pressed enter and saw the 30min ETA show up ;)
[14:57] <stgraber> ogra_: though I'm guessing most other netboot install will be just base system, so checking that the archive is actually consistent and lets you install a desktop is still a good test
[14:58] <ogra_> sure :)
[14:58] <ogra_> just takes ages :)
[15:04] <Daviey> astraljava, scott-work - updates for https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2 ?
[15:08] <skaet> Daviey,  I've marked the images that look like they should be sane to publish, can you double check they match up with the data you know as well.
[15:08] <skaet> balloons, jibel, ^
[15:09] <skaet> utlemming,  please go ahead and publish your set now.
[15:11] <skaet> jibel, does mvo still do https://wiki.ubuntu.com/UpgradeTestingProcess?  or do you do it now?   (if you do,  can you update the wiki page).
[15:11] <jibel> skaet, why is lubuntu amd64 ready and not amd64+mac ?
[15:12] <skaet> lubuntu amd64+mac had an additional crash,  and haven't gotten any data from that team to my pings, so seemed safest to leave it off.
[15:12] <jibel> skaet, updated. update-manager -d broken, cdromupgrade without network untested
[15:13] <skaet> thanks jibel
[15:13] <jibel> skaet, they are affected by the same problem of broken combo boxes
[15:14] <skaet> jibel,  so recommend is to leave both off?
[15:14] <jibel> skaet, I don't know, it's up to the product manager
[15:15] <skaet> jibel, yeah and the product manager hasn't provided input (or his delegate).   ok. leaving both off.
[15:15] <jibel> but a decision for one will affect all lubuntu desktop images
[15:16] <skaet> interesting,  i386 was looking solid.   oversite why that bug isn't on it?
[15:18] <jibel> skaet, it should affect it too. let me test
[15:20] <stgraber> ogra_: kernel blew up ;)
[15:20] <ogra_> stgraber, how ?
[15:21]  * apw reports that his broken panda is showing HDMI with ppisati's kernel
[15:21] <stgraber> I have a whole bunch of tcp_recvmsg related oops
[15:22] <cjwatson> skaet: Presumably either nobody tried manual partitioning, or they took a path through it that didn't hit that bug
[15:22] <cjwatson> (Maybe keyboard navigation avoids it or something?  I haven't much looked into it.)
[15:23] <skaet> cjwatson,  that would make sense.
[15:24] <skaet> I've gone ahead and unmarked that image for release.
[15:24] <skaet> so for Lubuntu,  just releasing the alternates.
[15:26] <utlemming> skaet: publishing in progress
[15:29] <jibel> keyboard navigation doesn't avoid it
[15:32] <stgraber> so that armhf fail got me a nice 1GB of log file, mostly kernel oops ;) that explains why the system died of an OOM :)
[15:32] <ogra_> hah
[15:35] <stgraber> would be good if someone could confirm I'm not the only one getting all these oops though
[15:35] <stgraber> because if it's a generic issue, then it's simply not possible to install desktop over netboot because of the running out of memory part of the problem :)
[15:35] <stgraber> minimal system might be able to succeed before you run out of memory
[15:40] <ogra_> stgraber, well, i dont get them here
[15:40] <ogra_> though i installed my desktop from a live image ... probably there are differences to netboot that we havent found yet
[15:40] <skaet> Daviey, I think the ones marked ready right now, are the ones we'll be going with for A2.   Can you start the publishing?
[15:41] <jibel> skaet, without surprise same problem on i386 and after installation combo boxes do not work. So it affects alternate too.
[15:41] <ogra_> stgraber, ddi you manually partition ?
[15:42] <ogra_> *did
[15:42] <skaet> jibel, understood,   undoing the publishing of them now as well.
[15:42] <skaet> Daviey, ^
[15:42] <ogra_> stgraber, by default i get a 386M swap partition on the live image, maybe yours is smaller ?
[15:46] <Daviey> skaet: wait, did you just publish them?
[15:47] <skaet> Daviey,  sorry,  meant to say marking them as ready to publish
[15:50] <utlemming> skaet: cloud images published
[15:52] <skaet> Thanks utlemming
[15:52] <skaet> Daviey, can you please publish the images marked (ready) now?
[15:53] <stgraber> ogra_: nope, it was automated partitioning, so it managed to dump a 950MB log file before dying :)
[15:53]  * skaet will go and update the pages to reflect lubuntu won't be going out.
[15:53] <Daviey> stgraber: what are these state changes?
[15:54] <Daviey> skaet: Why isnt't lubuntu going out?
[15:55] <skaet> Daviey, broken combo boxes problem and no guidance otherwise from lubuntu team.
[15:55] <stgraber> Daviey: typically "has been updated" means either a new version or a state change from ready back to testing
[15:56] <Daviey> stgraber: Well with yesterdays date, i assume it's back to testing
[15:58] <Daviey> skaet: Who is the owner of lubuntu again
[15:58] <Daviey> ?
[15:58] <skaet> Daviey,  gilir - who's not on IRC that I can find.
[15:59] <Daviey> skaet: I can't see what on https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport makes it unsuitable for A1
[16:00] <skaet> Daviey, ^ backscroll
[16:06] <bjf> SRU folks: there are a number of kernels that are in -proposed and ready for -updates
[16:07] <phillw> skaet: you have email :)
[16:09] <jibel> Daviey, bug 1018533 which was reported on lubuntu ppc  and mac but affects every architecture of lubuntu and installed desktop.
[16:09] <ubot2> Launchpad bug 1018533 in ubiquity "Cannot manually change partitions" [High,Triaged] https://launchpad.net/bugs/1018533
[16:10] <jibel> and it is not in ubiquity gtk3 and can be worked around in whatever theme they use.
[16:11] <jibel> s/ubiquity/ubiquity but
[16:11] <skaet> phillw,  ok wil look.   Basically looking for go/no go from lubuntu perspective...
[16:11] <phillw> skaet: I suspect, it is a bigger problem than just lubuntu :(
[16:12] <phillw> if you look at the similar bugs in xubuntu & ubuntu.
[16:13] <infinity> bjf: I'll have a poke.
[16:14] <phillw> If ubiquity won't allow the install & the putting of grub where required, it'll have to be a NO-GO from us.
[16:15] <bjf> infinity, danke
[16:15] <skaet> phillw,  thanks.
[16:17] <infinity> bjf: You weren't kidding about "a number".  Starting at hardy and working forward. ;)
[16:17] <bjf> infinity, i get paid by the number of kernels produced
[16:25] <Daviey> phillw: do you have an ETA?
[16:28] <skaet> Daivey,  I think they've got all the results they're going to have at this point.   Something else you're asking for?
[16:40] <infinity> bjf: Oh, hrm.  linux-ti-omap4 in oneiric doesn't have the Regression-testing task ticked off, but the comments seem to imply it should be.  Workflow oops, or is it not ready yet?
[16:40] <bjf> infinity, i'll check on it
[16:40] <infinity> bjf: bug #1012482
[16:40] <ubot2> Launchpad bug 1012482 in kernel-sru-workflow "linux-ti-omap4: 3.0.0-1212.24 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1012482
[16:41] <infinity> bjf: I'll reject my copy for now, and we can act on it later, when you're sure. ;)
[16:41] <bjf> infinity, it's just omap4, does anyone really care? :-)
[16:42] <infinity> bjf: I'm sure someone does. :P
[16:43] <Daviey> phillw: Hey!
[16:43] <Daviey> phillw: Can you add a entry to the TechnicalOverview
[16:43] <Daviey> phillw: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2
[16:44] <phillw> Daviey: I don't think there are any A2's for Lubuntu?
[16:44] <infinity> bjf: Same story on ti-omap4/precise (bug #1013464), and we definitely care about that one. :)
[16:44] <ubot2> Launchpad bug 1013464 in kernel-sru-workflow "linux-ti-omap4: 3.2.0-1415.20 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1013464
[16:44] <bjf> infinity: ack
[16:45] <Daviey> phillw: huh?
[16:45] <infinity> bjf: In both cases, there's a comment from John Johansen that says "looks good".  If that's meant to be a resounding "this kernel is awesome and provided me with free kittens", I imagine the tasks just need twiddling.
[16:45] <Daviey> phillw: to clarify, you don't want Lubuntu to be part of Alpha2?
[16:46] <bjf> infinity, LOL, that is the "security team signoff"
[16:46] <infinity> bjf: Ahh.  Check.
[16:47] <infinity> bjf: So, we really are still missing some sort of testing of those.  I'll leave them be, then.
[16:47] <bjf> infinity: right, i'm hasseling QA
[16:47] <infinity> bjf: Not sure who's meant to be doing ARM kernel testing, but they're clearly slacking. ;)
[16:47] <bjf> infinity, i blame pgraner
[16:47] <infinity> bjf: (There's an armadaxp in the pipe too that, while it's not aged enough yet anyway, could also use some testing).
[16:47] <phillw> Daviey: with the problem of Ubiquity preventing an install on a stated partition, until that is resolved I'm not convinced that releasing an A2 is wise.
[16:48] <bjf> infinity, yes QA is on the hook for that and have already been pinged about it
[16:48] <infinity> bjf: Ideally, I'd like to see these things fully verified before they hit the 7d window, so we can grease this machine a bit better.
[16:48] <infinity> bjf: (Though, it's sure a lot better than it used to be)
[16:48] <bjf> infinity: i can only flog so hard
[16:51] <phillw> Daviey: Julien is on the mailing list now. I await his decision.
[16:52] <infinity> bjf: Alright, all done.  Except for all of Tim's linux-firmware uploads which never seem to get reviewed in a timely fashion.  Maybe I'll look at some of those.
[16:52] <bjf> infinity: ack and thanks
[16:55] <Daviey> phillw: We really need to know now TBJ
[16:55] <Daviey> TBH
[16:56] <gilir> phillw, the bugs doesn't seems lubuntu specific, except the gtk one which was (only ?) workarounded on ubuntu theme
[16:56] <Daviey> phillw: I think we need to release A2 without Lubuntu based on the uncertainty, but can tag it on later as a post release update?
[16:57] <gilir> phillw, but as A2 is not too much important for lubuntu (no major change), we can probably drop A2 if you are not confident
[16:58] <phillw> gilir: I'm not confident. I think the ubiquity bug(s) affecting us, ubuntu & xubuntu need further looking into. 2 days for rc was not enough.
[16:58] <gilir> Daviey, I'm not sure the issues lubuntu have are specific to us, but you can just drop A2 for lubuntu if it delayed the release and you are sure about the others ISO :)
[16:58] <ScottK> phillw: It's just for manual partitioning, right?
[16:59] <ScottK> If it's just manual partitioning, I'd release note it and then do the release.
[16:59] <phillw> ScottK: AS I see, but I don't know if the xubuntu issue also affects lubuntu. We've not had time to check it. Nor the one affecting ubuntu.
[17:01] <phillw> Yes, it seems just manual partitioning.
[17:01] <ScottK> If it were me, I wouldn't let that stop the release.
[17:01] <ScottK> (It's an Alpha)
[17:01] <ScottK> As long as you document the limitation.
[17:02] <skaet> gilir,  phillw - if you can add the work arounds to the TechnicalOverview/Alpha2 notes,  I'm ok with them going out if you want.   They've been well tested,  but folks need to know about the issues.
[17:02] <ScottK> skaet: Looking at the testing report, Bug #1017172 seems somewhat scary.
[17:02] <ubot2> Launchpad bug 1017172 in ubiquity "Grub installs to wrong drive" [Undecided,New] https://launchpad.net/bugs/1017172
[17:03] <skaet> ScottK,  yes, that was one of the ones that gave me pause.   Counter is there's only one report, and a lot of other folks have tested
[17:03] <skaet> and not seen issues
[17:04] <phillw> for ubuntu also, I can't access the xubuntu one
[17:04] <skaet> its not confirmed.
[17:04] <gilir> skaet, I can add a workaround for the manual partitioner bug
[17:05] <phillw> gilir: So, a release note & launch?
[17:05] <ScottK> gilir: Excellent.
[17:05] <gilir> skaet, for the wrong install with grub, it seems to affect only when you have 2 drives, which we doesn't test a lot in a vm :/
[17:06] <phillw> after saturday, I can get back to testing, piglet has two hard drives :)
[17:07] <Daviey> skaet: ubuntustudio amd64?
[17:08] <skaet> gilir, yes, that should be mentioned,  as should recommedation in the overview section to stick with VMs possibly?
[17:08] <Daviey> skaet: it's had no testing.
[17:08] <skaet> Daviey,  no test results on it,  so don't know if there are surprises there or not.
[17:08] <skaet> so, no publish for now.
[17:09] <Daviey> skaet: ack
[17:09] <gilir> skaet, fine with me, it's an alpha after all :)
[17:09] <skaet> Daviey,  looks like we'll be publishing the lubuntu ones,  I'm going to "ready" them on the tracker now.
[17:10] <skaet> gilir,  :) looks like we've got 2 threads going.  just to be clear,  you want us to publish the lubuntu ones,  right?
[17:12]  * Daviey waits
[17:14] <xnox> ubuntu server i386 not going to be release, correct?
[17:14] <skaet> xnox,   yes,  we're not releasing i386 ubuntu server
[17:15] <Daviey> yah
[17:15] <gilir> skaet, yes please :) I'm finishing the note on the overview about the issues we mentionned
[17:17] <skaet> Thanks gilir
[17:17] <skaet> Daviey,  you should be good.
[17:18] <skaet> gilir,  only one I held back was alternate powerpc, which had been marked as install failed on all tests.
[17:19] <gilir> skaet, ok
[17:23] <Daviey> utlemming / smoser: Confirm that Alpha 2 cloud images are published?
[17:23] <utlemming> Daviey: confirmed
[17:24] <utlemming> Daviey: I confirmed to skaet at 09:52 -06:00
[17:24] <Daviey> utlemming: thanks
[17:24] <smoser> https://cloud-images.ubuntu.com/releases/quantal/alpha-2/
[17:29] <Daviey> skaet: Are you in contact with steve edwards?
[17:29] <astraljava> skaet: You wanted info on Studio? Technicals: Xfce updated to 4.10 (from Xubuntu), kernel (lowlatency) updated to 3.5. No other real major package updates. I wasn't really expecting to see Studio on Alpha-2, so I didn't prepare a proper release note this time. Also, amd64 images were not tested.
[17:29] <skaet> Daviey, yup.
[17:31] <skaet> astraljava, could you add that to the TechnicalOverview page?
[17:31] <astraljava> skaet: Xubuntu images can be released, no overly bad issues were found that would prevent them. I also saw that pleia2 handled the notes section, so do you need anything from us, still?
[17:31] <astraljava> skaet: Yeah, sure.
[17:32] <skaet> thanks astraljava,   for the confirmation on Xubuntu.
[17:33] <skaet> astraljava,  the bug that we were worried about is: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1017172
[17:33] <ubot2> Ubuntu bug 1017172 in ubiquity "Grub installs to wrong drive" [Undecided,New]
[17:37] <astraljava> skaet: Studio bits updated. I have no further data on that bug, so cannot say if it's an isolated incident or a recurring issue. It wasn't mentioned in other cases, though, so need to do more research.
[17:38] <skaet> Thanks astraljava  :)   let us know what you find.
[17:39] <astraljava> Will do. Sorry I was a little late of schedule, hopefully the delay was not too frustrating.
[18:42] <dobey> hey all. now that u1 has an MRE, is it best for me to make an "upgrade to X.Y.Z release" bug for all the packages we want to SRU to precise?
[18:44] <stgraber> dobey: yeah, the SRUs will need a tracker bug and that sounds like a good title for it. Obviously, for any fixes you have in there that already has a matching LP bug, please link to it (to make it easier on users who want to figure out what changed)
[18:46] <Daviey> also has the benefit of closing the bugs on publication :)
[18:48] <dobey> stgraber: right, thanks; yeah i try to list all the bugs that affect ubuntu in the changelog as well anyway. :)
[19:04]  * infinity begins to carefully copy stuff from -proposed to -release.
[19:05] <skaet> thanks infinity :)
[19:05] <skaet> please keep count.
[19:05] <skaet> :)
[19:13] <skaet> crontab has been turned back on for quantal dailies
[19:13] <skaet> image posting to iso tracker has been reset to dailies
[19:18] <skaet> iso tracker has had alpha 2 marked released, and daily moved back to testing.
[19:21] <vanhoof> skaet: dannf just tested armadaxp+netboot and posted results for a2
[19:21] <skaet> thanks vanhoof
[19:21] <skaet> (and dannf!  :) )
[19:40] <Daviey> skaet: all well in the world
[19:40] <Daviey> ?
[19:40] <skaet> Daviey,  alls well so far.  Thanks for all your help getting A2 out the door!  :)
[19:41] <Daviey> super
[20:25] <skaet> alpha 2 milestoned bugs now moved to alpha 3
[20:27] <xnox> congrats! thank you all =)
[20:29] <highvoltage> yay
[20:30] <highvoltage> ah thanks for moving the edubuntu ones, skaet. I should've done it already actually :)
[20:30] <xnox> infinity: are you copying everything, or are you using britney transitions?
[20:31] <infinity> xnox: The former.  britney's not ready yet (though, this would have been a good test)
[20:31] <infinity> xnox: But I'm doing it carefully and fixing build failures first. :P
[20:31] <xnox> infinity: two of my uploads to proposed did FTBFS
[20:32] <Laney> the horror
[20:32] <infinity> xnox: Which two?
[20:32] <xnox> infinity: avogadro & mongodb on arm-any
[20:32] <infinity> xnox: avogadro is fine, it's never built on ARM before.
[20:33] <infinity> xnox: (Though, fixing it would be nice, and I might do so "later")
[20:33] <infinity> xnox: monogodb, on the other hand...
[20:33] <xnox> mongodb - new upstream release introduces more non-arm pointer logic, so the smoke test segfaults. So our existing arm patch needs further fixing
[20:34] <xnox> ... if only it was forwarded to debian or upstream in the first place.....
[20:34] <infinity> If only.
[20:34] <infinity> xnox: So, you seem to know what's going on, feel free to fix it.  Since it's your upload.
[20:34] <infinity> xnox: *stare*
[20:34] <xnox> infinity: avogadro please keep it as it is, as it's a nice reminder for me to get into C++ / GLES crap =)
[20:35] <infinity> xnox: You'll probably find that fixing avogadro is pretty simple and doesn't actuallt require any C++, but sure.
[20:35] <xnox> infinity: I was thinking to do +really-old-version-X.Y.Z upload =)
[20:35] <xnox> for mongodb
[20:35] <infinity> xnox: (First step will be not build-depending on libglew-dev on arm*, the second step will be fixing CMake to look for GLES as well as GL)
[20:35] <infinity> xnox: I can just drop your mongodb from proposed, you don't need to do any ugly versioning.
[20:36] <xnox> infinity: ok. thanks. (/me copies to the todo)
[20:36] <infinity> xnox: Just upload a rebuild-only increment to release, if you want.
[20:36] <xnox> infinity: yes please drop mongodb from proposed. that's the best.
[20:37] <infinity> xnox: Done.
[20:38] <Daviey> AHHHHHHHHH.. xnox, i hate +really :)
[20:38] <xnox> infinity: player has implicit pointer conversion & the "let's parse our headers with a python script & regexp to generate swig bindings file, and rename all the functions and then compile swig binding" gave me a headacke
[20:39] <xnox> so it has FTBFS on amd64
[20:39] <Daviey> xnox: we had to do that for mysql a few releases ago.. made me cry
[20:39] <xnox> Daviey: it's ok. it was uploaded to proposed and infinity dropped from proposed. So we are back to the previous revision without +really ;-)
[20:39] <xnox> Daviey: it's ok. it was uploaded to proposed and infinity dropped *it* from proposed. So we are back to the previous revision without +really ;-)
[20:39] <Daviey> \o/
[20:40] <Laney> sucks to be the poor proposed users who got it :P
[20:40] <xnox> Laney: it's unsupported unsupported pocket anyway, so who cares =)
[20:41] <Daviey> Hmm, we do want to encourage proposed users.. not have them thinking they are running some dodgey PPA :)
[20:41] <Laney> actually, the dev release -proposed is something we do /not/ want people to be using
[20:42]  * Laney is trying to do something about this
[20:42] <xnox> Laney: while you are here ;-) could you please chase up / sheppard an upload of nux?
[20:43] <infinity> xnox: Eh?  What do you need a nux upload for?
[20:43] <infinity> xnox: Was the one in proposed not shiny enough for you?
[20:43] <xnox> the stuff in the bzr branch is fine. It's one of the last 10 packages holding boost1.46 in the archive & in main
[20:43] <xnox> infinity: ooh, maybe the proposed one is shiny enough =)
[20:43] <Laney> it just got uploaded
[20:43] <xnox> great!
[20:43] <Laney>  2.12.0-0ubuntu2 release, proposed (main) 10 minutes ago
[20:43] <Laney> do keep up
[20:43]  * xnox tracker is out of date ;-)
[20:44] <Laney> the tracker doesn't look at proposed
[20:44] <xnox> Laney: where is the new tracker? still on cjwatson overflow backlog?
[20:44] <Laney> yeah
[20:44] <xnox> ok.
[20:44] <xnox> so everything is looking good.
[20:45] <Laney> if you're bored…
[20:45] <Laney> …you can merge it up with trunk and see if it still works
[20:45]  * xnox off to have пельмени
[20:45] <xnox> dinner time ;-)
[20:45] <Laney> we're missing a number of commits
[20:46] <Laney> but I am aware there is at least one new dependency, so I'm avoiding it
[20:46] <xnox> which branches with what? +junk with lp:tracker?
[20:46] <xnox> lp:$project_name
[20:46] <Laney> https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/trunk
[20:46]  * slangasek learns about pelmeni
[20:46] <Laney> the upstream import
[20:46] <Laney> merging with the to-be-deployed branch
[20:47] <Laney> lp:ubuntu-transition-tracker, IIRC
[20:47] <xnox> slangasek: dumplings with mean, which russians believe did *not* come from ukraine
[20:47] <xnox> slangasek: dumplings with meat, which russians believe did *not* come from ukraine
[20:47] <slangasek> heh
[20:47] <xnox> slangasek: similar to perogies
[20:47] <xnox> Laney: ok thanks.
[20:47] <xnox> slangasek: what herritage is your last name?
[20:47]  * Laney had куриный салат
[20:48] <slangasek> xnox: český
[20:48] <xnox> Laney: Цезаря?
[20:48] <Laney> Было очень вкусно.
[20:48]  * Laney runs.
[20:48] <infinity> You people and your funny alphabets.
[20:49] <xnox> slangasek: ok. One of my friends from uni had a Czech father and a Slovak mother. It would wind her up if she heard "... so that makes you czechoslovak, right?!"
[20:49] <slangasek> hahahaha
[20:49] <slangasek> +1
[20:51] <xnox> also grilled bagels with turkey patte =) nom nom
[20:51] <cyphermox> slangasek, xnox: so, seems kind of similar to tortellinis?
[20:52] <cyphermox> provided the filling is right and the shape, I guess
[20:52] <xnox> cyphermox: kind of. they are bigger and the pastry is more bread like and less pasta like
[20:52] <slangasek> cyphermox: don't ask me, they don't make those in Czechia :)
[20:53] <cyphermox> xnox: very cool. /me takes a note to go out to find some east europian grocery store in Montreal sometime.
[20:53]  * xnox UDS in Moscow, Russia =)
[20:54] <infinity> Montreal probably has what you're looking for somewhere.  They do have a lot of delightful international cuisine.
[20:54] <cyphermox> yeah, pretty sure. I walk past a slovakian butcher when I go to the office
[20:54] <Laney> I was told that Russian visas for US and UK citizens mysteriously take a long time to get processed ...
[20:55] <xnox> didn't get to see Montreal. Been to Nova Scotia though
[20:55] <slangasek> Laney: yes, we're culturally inept at bribing officials ;)
[20:55] <xnox> Laney: my house mate got it in 2 weeks time. but he used an online 'bribe' website which submits invintation letter to the embassy.
[20:56] <xnox> the key is that for a russian visa is invitation letter from some company or person who (a) have a lot of income (b) will vouch and take responsibility for you
[20:57] <xnox> it's doable, but hassle
[20:57] <Laney> A French guy at uni is going to a summer school there, who were worried when they saw his UK email address
[20:57] <xnox> you'd be surprised but russia has a large immigration problem, far worse than US/UK
[20:57] <Laney> when they found out he was French it all became easier apparently :P
[20:57] <xnox> russians love french
[20:59] <xnox> half of our classical books are in half french - the language of aristocracy at the time.
[20:59]  * xnox half of a half is a quarter
[21:01] <xnox> infinity: can i copy stuff from -proposed to -release in the devel series or do I need magic AA cufflinks?
[21:04] <slangasek> AA
[21:06] <xnox> =(
[21:08] <xnox> slangasek: but I do have AA road-side recovery membership!
[21:08] <xnox> http://www.theaa.com/
[21:08] <slangasek> that's one A short, around here
[21:08] <infinity> Or a C short, here.
[21:09] <Daviey> err.. Are you sure you need to be AA for that?
[21:10] <infinity> I hope so.  Cause you can break things doing it.
[21:10] <infinity> Like, archive things.
[21:12] <xnox> oh, so *not* the British Automobile Association - the AA
[21:12]  * xnox gotcha ;-)
[21:14] <Daviey> infinity: what breakage are you expecting?
[21:14] <xnox> Daviey: the same as we did, when there was no -proposed for the devel release
[21:14] <infinity> Daviey: When things get copied before all arches are built and published, for instance, some things asplode.
[21:15] <infinity> xnox: No, I mean actual archive/soyuz "oh, I didn't expect that" breakage.
[21:15] <infinity> xnox: Not broken packages.
[21:15] <Daviey> infinity: include_binaries= ?
[21:15] <infinity> Daviey: include_binaries="stuffthathasn'tbuiltyet"?
[21:15] <infinity> Daviey: Well done.
[21:16] <Daviey> i highly suspect archive/soyuz expects this LP API behaviour, and i also suspect it works with not being an AA.
[21:16] <infinity> I can't speak to the permissions, but I can tell you that you're wrong on the former point.
[21:17] <infinity> Copying things around between pockets if the arches aren't in sync causes vaguely irreperable damage.
[21:17] <infinity> (It can be fixed with some awful hackery, but.  Not fun)
[21:18] <Daviey> infinity: if this is a real prospect, it needs to be better documented
[21:18] <slangasek> where is it documented that anyone other than AAs should be copying packages between pockets?
[21:19] <slangasek> or do you mean, documented for AAs?
[21:19] <Daviey> slangasek: I agree the fact that you can, doesn't mean that you /should/.. but having a supported API call that allows non-AA's... sort of implies it's ok in my mind.
[21:19] <Daviey> Therefore, if there is risk associated.. it should really be outlned
[21:20] <slangasek> no, we should instead fix the acl
[21:20] <slangasek> or fix the API to not allow buggy copying
[21:20] <slangasek> instead of documenting it
[21:20] <slangasek> but this is really cjwatson's turf :)
[21:20] <Daviey> Sure.. I am interested in more detail of the potential risks here.
[21:21] <xnox> fix the API is better, cause those who can upload into devel-release should also be able to copy from devel-proposed to devel-release
[21:21] <xnox> instead of doing fake uploads ;-)
[21:21] <Laney> I believe they can, and I believe that's what they are saying should not be possible
[21:21] <Daviey> if there is not a published bianry, it won't copy it.. right?  So the worst case is surely that it's as if -proposed wasn;t used to stage in the first place, no?
[21:22] <infinity> Daviey: No...
[21:22] <infinity> Daviey: Because if proposed wasn't used to stage, you still have a build record in release.
[21:22] <slangasek> xnox: I disagree; the whole point of having -proposed is to ensure archive installability, people should not be copying their own packages between pockets without coordination
[21:22] <infinity> Daviey: And the binary will eventually show up, if it's not FTBFS because the source is broken.
[21:22] <infinity> Daviey: Think dep-waits, slow buildd, etc.
[21:23] <xnox> slangasek: ok. makes sense.
[21:23] <Daviey> infinity: Well yes, but that really shouldn't be  vaguely irreperable damage.
[21:23] <infinity> Daviey: And yet, it is.
[21:23] <Laney> which binary upload wins?
[21:23] <Daviey> Laney: the newer one will fail to upload.
[21:23] <infinity> Daviey: Other than re-uploading a new source, or me copying the source BACK to the pocket it originated from.
[21:24] <infinity> Daviey: And it has nothing to do with "which binary upload".  There will only be one.
[21:24] <infinity> Daviey: And it won't work.
[21:24] <infinity> Daviey: Cause it won't have source associated with it.
[21:24] <Daviey> infinity: wait, why wouldn't it have a src?
[21:25] <slangasek> because the process is copy to -release -> remove from -proposed
[21:25] <infinity> Daviey: What he said.
[21:25] <Daviey> Ah, well.. syncSource i don't think supports removing from the original
[21:25] <Daviey> So.. it is clearly an issue
[21:40] <ScottK> xnox: Also LP can't let devs copy from -proposed to -release in the development series without also allowing the same for all releases, which we definitely don't want (and fixing that is non-trivial according to our local launchpad developer, cjwatson).
[21:41] <Laney> I understand the ACL of copyPackage to be the same as for normal uploading.
[21:41] <Laney> (and the behaviour around stuff landing in queues)
[21:42] <xnox> ScottK: Laney: ok thanks
[21:46] <micahg> ScottK: that's not true, the dev release has different ACLs
[21:46] <micahg> or rather a non-frozen release has different ACLs
[21:46] <ScottK> True.
[21:46] <ScottK> I guess I was thinking of distinguishing frozen from post-release.
[21:47] <micahg> so, I can copy something to precise-release, but it'll land in unapproved like anything else I copy, but if I copy to quantal-release it'll go straight through
[21:47] <Laney> Anyway it is the deleting part that makes this an AA-only task.
[21:47] <micahg> AIUI at least
[21:50] <slangasek> infinity: say, can I bother you to do NEW processing of sbsigntool?
[21:51] <xnox> infinity: will you move avogadro from quantal-proposed to quantal-release or are you doing them in reverse alphabetical order? =))))
[21:52]  * micahg would love some NEW/unapproved love for precise-backports when the AAs get a chance
[21:52] <infinity> slangasek: Looking.
[21:53] <slangasek> xnox: clearly avogadro's number hasn't come up yet
[21:55] <infinity> xnox: It'll move when it moves.
[21:55] <Daviey> Doesn't asking move it automatically to the bottom of the queue?
[21:57] <xnox> ;)
[22:01] <infinity> slangasek: Source and copyright look sane, fix the missing build-deps (pkg-config and openssl) and upload a new version, and I'm happy. :P
[22:02] <slangasek> infinity: wat
[22:02] <slangasek> openssl?
[22:02] <infinity> Yeah.
[22:02] <infinity> It calls it.
[22:02] <slangasek> hmm
[22:02] <slangasek> ok, let's fix
[22:02] <infinity> openssl genrsa -out private-key.rsa 2048
[22:02] <infinity> In the test suite.
[22:04] <slangasek> infinity: reuploaded, same version number
[22:04] <infinity> slangasek: Also fails with compilers that don't grok -m64
[22:04] <infinity> slangasek: But I'm guessing that's less interesting to you.
[22:04] <slangasek> infinity: it is currently less interesting to me, yes :)
[22:05] <infinity> slangasek: Only in the testsuite, so easily fixed later.
[22:09]  * infinity goes to find some lunch.
[22:14] <dobey> can someone copy ubuntuone-client from quantal-proposed to quantal please?
[22:14] <slangasek> hmmm, why did i386 build successfully?
[22:14] <infinity> slangasek: Because i386's toolchain speaks -m64.  It just fails if you try to link to something it can't find.
[22:15] <slangasek> dobey: infinity is working his way through the lot of them; I'd rather not jostle his elbow by getting in the middle now
[22:15] <infinity> dobey: Already done, I just missed it on the first pass, eyes crossed. ;)
[22:15] <slangasek> aha :)
[22:15] <dobey> ah ok
[22:15] <dobey> thanks
[22:16] <infinity> slangasek: And you'll note it doesn't actually link anything (nostdlib).
[22:16] <slangasek> infinity: right
[22:17] <infinity> slangasek: I imagine jk made sure it worked on i386 after I ridiculued him for the previous i386 build failure I found. :P
[22:18] <slangasek> I have no idea if he did or didn't
[22:18] <infinity> Anyhow.  Late lunch and bank.  Back in a bit.
[22:18] <slangasek> but it currently only handles signing of 64-bit PE files, so meh ;)
[22:18] <slangasek> (I have half a patch here to correct that)
[22:51] <cjwatson> So.  If you can upload to a suite, you can copy to it.  However, there are some restrictions on copying things like incompletely-built uploads.
[22:52] <cjwatson> The restrictions amount to avoiding conflicts.
[22:53] <infinity> Hahaha.  /usr/bin/ld: cannot represent machine `i386:x86-64'
[22:53] <infinity> I guess fixing the -m64 thing doesn't get you anywhere in the testsuite. ;)
[22:55] <cjwatson> One of the restrictions is that if there's already a needsbuild/building record in the archive you're copying to, or a built-but-not-published record, then you mayn't copy.
[22:55] <cjwatson> Hm, actually, I'm not so sure about that.
[22:56] <infinity> cjwatson: Sure, that doesn't fix the "copying something that isn't built on all arches yet" problem.
[22:56] <infinity> cjwatson: Which, at last check, can only be fixed by copying the source back to the originating pocket, so the build can happen.
[22:56] <cjwatson> Anyway, the answer is to improve the copy-conflict checker, not to forbid copies.
[22:56] <cjwatson> Forbidding copies gets us back to the bad old days when archive admins had to do syncs.
[22:56] <infinity> cjwatson: But we don't want to forbid copying incomplete sets, we want people to be forced to think about it.
[22:57] <cjwatson> There's incomplete because stuff has failed, and incomplete because it isn't done yet.
[22:57] <infinity> cjwatson: Failed isn't always failed.
[22:57] <cjwatson> And if it's needsbuild, the build records can (in principle, not sure if Soyuz does this) be recreated for the new suite.
[22:57] <infinity> cjwatson: (I just had to do two retries in proposed to fix two "failures")
[22:58] <cjwatson> Anyway, what I'm working on at the moment is essentially moving everything over to new-style packagecopyjobs so that I can rip out a huge chunk of old copy code.
[22:58] <infinity> Anyhow, when we move to using britney for this, it'll impose the "not built where it's built before" check anyway.
[22:58] <cjwatson> Then the copy code might be approximately comprehensible and it will be more or less possible to improve it.
[22:59] <cjwatson> (My current "remove delayed copies" branch removes well north of 1100 lines.)
[22:59] <infinity> Though this issue still exists for SRUs and security, where people are mostly careful, but not always.
[23:00] <cjwatson> Right.  But any situation where you can do something that breaks Soyuz (even if you're an AA) is a bug - the answer's usually to either fix it or forbid it selectively, not to lock down the operation
[23:00] <cjwatson> And I think most of these situations are fixable
[23:00] <infinity> Sure, that's the correct long-term answer, right now, I prefer asking people to be careful, which is easier with a smaller group of people.
[23:01] <cjwatson> I don't even think it's desperately long-term.  If you can describe a copy bug in sufficient detail, I can very probably fix it in days.
[23:01] <cjwatson> I'm pretty deep in the copy code right now.
[23:02] <infinity> Well, the simple fix for this would be that a pocket copy of an incomplete set (and the reason for the incomplete really doesn't matter) should create build records in the target.
[23:03] <cjwatson> Not quite that simple because you have to do something with existing builds too.
[23:03] <infinity> cjwatson: What happens in the built-but-not-published state?
[23:03] <cjwatson> You have to wait for publication.
[23:03] <infinity> cjwatson: Do those get correctly copied, or missed?
[23:03] <cjwatson> Forbidden.
[23:03] <infinity> Kay, so that situation should just flat-out be forbidden.
[23:03] <infinity> Which it isn't currently, I suspect.
[23:03] <cjwatson> Which situation?
[23:04] <infinity> proposed has builds ACCEPTED, and you try to copy source+binaries to another pocket.
[23:04] <cjwatson> I believe that is forbidden.
[23:05] <cjwatson>             if build_summary['status'] == BuildSetStatus.FULLYBUILT_PENDING:
[23:05] <cjwatson>                 raise CannotCopy(
[23:05] <cjwatson>                     "same version has unpublished binaries in the "
[23:05] <infinity> Kay.  I guess I've never tried that, cause I know it's bad. ;)
[23:05] <cjwatson>                     "destination archive for %s, please wait for them to be "
[23:05] <cjwatson>                     "published before copying" %
[23:05] <cjwatson>                     candidate.distroseries.displayname)
[23:05] <infinity> Err.
[23:05] <infinity> That error message sounds wrong.
[23:05] <infinity> I can't speak to the code.
[23:05] <cjwatson> This is lib/lp/soyuz/scripts/packagecopier.py:CopyChecker._checkArchiveConflicts, if you want to read through it.
[23:05] <cjwatson> What's wrong with it?
[23:06] <infinity> Unpublished binaries in the DESTINATION.  I'm talking about the source.
[23:06] <cjwatson> Destination *archive*.
[23:06] <infinity> Oh, right, I'm reading archive as pocket.
[23:06] <cjwatson> I.e. sharing the same pool.
[23:06] <infinity> Though, that then leads to the same issue for PPA->archive copies.
[23:06] <micahg> infinity: I've gotten that error before when trying to copy to devel from $stable-security
[23:07] <infinity> Which, I guess, is another kettle of... Whatever you put in kettles.
[23:07] <cjwatson> It doesn't matter so much if the same source gets built twice for a PPA and an archive.
[23:07] <cjwatson> In that case, you can have two .debs of the same name with different contents and who cares.
[23:07] <cjwatson> Since they're in different pools.
[23:07] <Daviey> cjwatson: The destination will have buildrecord for FTBFS/dep-wait scenarios, and satisfiable in -release to be given back if suitable, right?
[23:08] <cjwatson> I think it's late.  I'm having trouble parsing that.
[23:08] <infinity> Daviey: Currently, no, no new build records are automatically created.
[23:08] <Daviey> i think it's late.  I had trouble typing that.
[23:08] <infinity> (If that's what you were asking)
[23:08] <cjwatson> infinity: Missing build records should be created in the destination.
[23:08] <infinity> cjwatson: That's new then...
[23:08] <cjwatson> (In fact, too many of them sometimes, because it doesn't honour P-a-s ...)
[23:09] <infinity> cjwatson: Or, wait.  No, it might not be new, but it might not work.
[23:09]  * infinity tries to remember.
[23:09] <cjwatson> infinity: One of the confusions here is that missing builds are (I think) only created on the direct-copy path, not on the delayed-copy path.
[23:10] <cjwatson> The delayed-copy path is what is currently used when copying private uploads to a public archive.
[23:10] <Daviey> cjwatson: say, powerpc in -proposed are depwait or generally FTBFS.. But we are happy to copy to -release.. There is no reason that it wouldn't be treated as any other upload, 'rebuild button'.. right?
[23:10] <cjwatson> I am getting rid of delayed copies to try to reduce the amount of stuff we have to follow.
[23:10] <infinity> cjwatson: There was a case where some incomplete stuff was copied to updates, but tried to build against proposed, which failed miserably, cause the source wasn't in proposed anymore.
[23:10] <infinity> cjwatson: And the "fix" was the copy the source back to proposed, retry, and copy back again.
[23:10] <cjwatson> Daviey: It *should* get a new build record in release.
[23:11] <Daviey> cjwatson: So, as a non AA.. What should happen about removing the publication from -proposed?
[23:12] <infinity> Daviey: Anyhow.  Like I said above, when we move to doing the proposed->release stuff with britney for devel releases, you don't get to say "good enough" for new FTBFSes anyway. :P
[23:12] <cjwatson> infinity: OK.  It would be worth trying that out on dogfood to see if it's still current.
[23:12] <Daviey> infinity: we are moving to britney?
[23:12] <infinity> Daviey: That's the plan.  I've been looking into it this week.
[23:12] <cjwatson> Daviey: Non-AAs do nothing.  AAs periodically process pending-sru.html, which will list all such publications with cut-and-pasteable output for removal.
[23:13] <cjwatson> Daviey: (You probably haven't noticed since I routinely process that a couple of times a day, and I may not be the only one.)
[23:13] <infinity> You're not. :)
[23:13]  * infinity does another batch.
[23:18] <cjwatson> slangasek: installability/coordination> There's no point in forbidding copies when people can also simply upload directly.  The argument about coordination will make more sense when we get to the point where all uploads to quantal are automatically redirected to quantal-proposed.
[23:19]  * skaet pays attention.
[23:19] <slangasek> cjwatson: yes... though that's hopefully soon.  Anyway, fair point that this isn't policy that should live in the API then
[23:19] <cjwatson> I haven't quite worked out how the permission model for that should look, but I guess it should have one ...
[23:20] <cjwatson> I want delayed copies gone before we do that, otherwise my head really will explode. :-)
[23:20] <slangasek> mmk :)
[23:21] <cjwatson> Completely separate code path that does almost the same thing with subtly different semantics.  Honestly.
[23:21] <cjwatson> It took me weeks to divine that it was mainly irrelevant and should die.
[23:55]  * skaet has updated https://wiki.ubuntu.com/StableReleaseUpdates with the SRU team vanguards
[23:56] <micahg> skaet: I think you mean RAOF instead of ROAF
[23:57]  * skaet hugs micahg - thanks for catching that.
[23:57]  * micahg wonders if the channel should have the AA and SRU vanguards in /topic