[09:36] <flexiondotorg> Laney, would it be possible to sync ubuntu-mate-artwork 0.4.3ubuntu1 from proposed so it can be used to spin Beta1?
[09:37] <Laney> flexiondotorg: OK (FWIW the request is for an 'unblock', it's being held because of the beta 1 freeze)
[09:37] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-mate-artwork
[09:39] <Laney> Done - once rmadison shows the new version is in vivid you can start your rebuild
[10:11] <flexiondotorg> Laney, Thanks.
[10:22] <oSoMoN> what’s the freeze currently in application that prevents packages from migrating from proposed to release?
[10:26] <cjwatson> oSoMoN: beta 1
[10:28] <oSoMoN> cjwatson, pardon my ignorance, when will it be lifted?
[10:28] <cjwatson> oSoMoN: after beta 1 is released.  see the release schedule
[10:28] <cjwatson> https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
[10:29] <oSoMoN> tomorrow if I read correctly then. thanks
[13:51] <cjwatson> flexiondotorg: ^- powerpc appears to have succeeded too, it's just only on the tracker for daily and not beta 1 at the moment
[13:51] <cjwatson> Laney: ^- doesn't appear to have download information set up on the tracker
[13:52] <cjwatson> http://iso.qa.ubuntu.com/qatracker/milestones/326/builds/89692/downloads
[13:52] <flexiondotorg> cjwatson, OK. Is that something I can fix?
[13:54] <cjwatson> flexiondotorg: I think it needs ubuntu-release, which is why I asked Laney
[13:54] <cjwatson> oh, sorry, you mean beta 1
[13:55] <cjwatson> I don't remember, maybe Laney can
[13:56] <flexiondotorg> cjwatson, What is most important is it produce a powerpc iso I can get the ppc guys playing with.
[13:58] <cjwatson> flexiondotorg: Well, you have that
[13:59] <cjwatson> flexiondotorg: http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/
[13:59] <cjwatson> Don't commit the error of thinking that the tracker is everything :)
[13:59] <flexiondotorg> cjwatson, 😃
[14:22] <Laney> flexiondotorg: cjwatson: Done, added to Beta 1 milestone also
[14:28] <flexiondotorg> Laney, Thanks!
[14:41] <cjwatson> Laney: ta
[14:59] <flexiondotorg> Laney, I rebuild the Ubuntu MATE isos a little while ago.
[14:59] <flexiondotorg> Laney, This spin is looking good for Beta 1.
[14:59] <flexiondotorg> Laney, Do I have to do anything to mark it as Beta 1 candidate or will it just automatically get ellected?
[15:00] <Laney> flexiondotorg: Use "Mark as ready" on the tracker to indicate so
[15:01] <flexiondotorg> Laney, does that mean "i've tested it and it is ready"?
[15:01] <Laney> It means that it's ready to be released with the milestone
[15:02] <flexiondotorg> OK
[15:02] <Laney> Whether it's tested or not is a matter for the person pressing the button. :P
[15:10] <bdmurray> cjwatson: the autopackage stuff is ready for review https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/autopkg-excuses/+merge/250795
[15:12] <bdmurray> and there is another ubuntu-archive-tools mp - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-deleted/+merge/250811
[15:13] <cjwatson> oh, right, yeah, those were on my to-do for today, let me look now
[15:19] <cjwatson> bdmurray: both merged, thanks!
[15:21] <bdmurray> cjwatson: great, thank you
[15:24] <infinity> bdmurray: Say, if you're fiddling in sru-report, I have a bug for you that I was just looking at how best to fix.
[15:25] <infinity> bdmurray: In get_srus, we skip packages we don't want showing up in the lists due to noise (langpacks, kernels, etc), but that's the wrong place to skip them, as it means they also don't show up on the removals list.
[15:26] <infinity> bdmurray: Which has never been a problem until we did britney integration, now we really do want the proposed versions deleted if they're hanging around.
[15:26] <infinity> cjwatson: Though, maybe this is a self-solving problem if the ultimate goal is for migration to be unblocks, and britney does an atomic copy/delete for me, like it does in the devel series?
[15:27] <infinity> Would still be nice to have the report tell me about removals when that screws up, though.
[15:31] <bdmurray> infinity: noted
[15:34] <infinity> bdmurray: The naive fix would have just been to move the filter into the HTML output section instead, but if we're not displaying all the info for those, it's pretty inefficient (especially for kernels) to go bug-scraping, etc.  So, perhaps something more clever like having them still be in the srus list, but skip scraping for extra info, and add a display=bool property set to false?  I dunno.
[15:34] <cjwatson> infinity: Yeah, I think this is ultimately why I just had to do a big pile of binary removals from -proposed for old kernels.  I was thinking about the same thing today.
[15:35] <infinity> cjwatson: Yeah, it's definitely the cause of your pain.  We used to remove old kernels from proposed, and then I started filtering them out of the list, which meant they hung around forever.
[15:35] <infinity> cjwatson: I never cared, since it has zero impact on the size of /pool/ and minimal impact on proposed/Packages, but it suddenly matters.
[15:36] <cjwatson> infinity: If I get round to finishing my copyPackage(move=True) patch, then you could just use that in sru-release, of course, and the removals section no longer matters.
[15:36] <cjwatson> (Or movePackage.  Whatever.)
[15:37] <cjwatson> proposed-migration would use that too under the hood, of course, but it could equally be used directly.
[15:37] <infinity> And, of course, my filtering was just a cargo-cult of the existing langpack filtering, but langpacks don't suffer the same issue, since they don't introduce NEW binaries on every upload.
[15:37] <cjwatson> Or, even now, sru-release could do the same thing that promote-to-release does and do the delete.
[15:38] <infinity> cjwatson: Yeah, sru-release could do the copy-and-delete together, but we still know that (very rarely) fails to delete sometimes, hence the removal list is still helpful.
[15:38] <infinity> We still catch the odd manual removal needed in vivid here and there.
[15:38] <infinity> Unless that was finally hunted down and stamped out?
[15:38] <cjwatson> Right.  This is ultimately why I want an atomic move operation.
[15:38] <cjwatson> It's entirely bogus to have to do those separately.
[15:38] <infinity> Yep.
[15:38] <infinity> An actual atomic move would be lovely.
[15:39] <cjwatson> The case where copyPackage succeeds, the actual copy job fails, and the delete succeeds is much worse, and does happen once in a blue moon.
[15:39] <infinity> I'd also like some atomic batch operations... I wonder if I ever files bugs.
[15:39] <cjwatson> Batching can be harder due to timeouts, but atomic move of a single package is quite easy.
[15:40] <infinity> (ie: change-override should be using an atomic batch interface, and an atomic batch for a set of moves would also be awesome, so I don't get hit by a random delay making linux-meta release before linux)
[15:40] <cjwatson> I had most of the patch for that but I keep getting distracted ...
[15:42] <infinity> cjwatson: I assume the API is flexible enough to be able to crank up timeouts for specific operations?
[15:42] <infinity> cjwatson: Seems a waste to back this whole thing on a database with transactional support and not leverage it more.
[15:43] <cjwatson> That's controllable by feature flags per-operation if necessary, yes.
[15:43] <infinity> And, actually, a batch change-overrides would probably be much faster than what we currently do, too.  So long as it doesn't lock an entire table when it happens. :P
[15:43] <infinity> Or worse, several.
[15:43] <cjwatson> That's probably the issue.  I don't understand the data model quite well enough for that.
[15:44] <cjwatson> Also we'd need to put the operation on some other base object.
[15:45] <infinity> cjwatson: Well, I can hold off on these fancy requests, since I know that both overrides and copies are on wgrant's hitlist for his feature redesign.
[15:45] <cjwatson> And I suspect we'd end up encoding a bit more policy into the Launchpad side, because it would need to have things like checking for which architectures still have active publications, that are currently checked on the change-override side.
[15:45] <cjwatson> Yeah.
[15:45] <infinity> cjwatson: So, a fresh data model might make these things easier.  Though, "will this allow for sane batching and locking" should probably be a design goal.
[15:46] <cjwatson> I need to go off and understand the current bits of that redesign at some point.
[15:46] <cjwatson> But slightly full right now. :)
[18:26] <elfy> I suspect that I've missed Laney by a country mile ...
[18:57] <Laney> elfy: suspect no more
[18:58] <elfy> :)
[18:58] <elfy> so  - it looks like everyone (except us) are all looking good where testing
[18:59] <elfy> I'll chase studio up shortly
[18:59] <elfy> xubuntu has a contingency plan - doesn't look like we'll get our issue sorted in time to test
[18:59] <elfy> not sure what other things you need from me tbh
[19:00] <elfy> atm anyway
[19:00] <elfy> I'll sort out the release announcment tomorrow
[19:00] <Laney> just herd the cats into being ready in time, and send the announcement tomorrow
[19:00] <elfy> yea
[19:01] <elfy> loads of fun, I'm not internet friendly at work :)
[19:51] <wxl> hey infinity you ever figure out what's wrong with our alternate? it looks like the issue may extend beyond just that last point release :( http://pastebin.com/VKECPUCK
[19:53] <wxl> infinity: nevermind. bad tester.
[19:53] <infinity> wxl: I'm not sure what you mean?  You mean trusty dailies still show it?  Of course they do, nothing has changed to fix it since 14.04.2 was released.
[19:54] <wxl> i meant in vivid infinity but i see that this is based off of 14.04.2 :/
[20:53] <elfy> infinity: someone a lot cleverer than me has worked out why the install windows are off -> somewhere :)
[23:08] <infinity> elfy: Oh?  Have a pointer to the analysis/fix?  I'm curious.