[00:11] <mikal> Hi. Is there someone who can chat to me about the precise china daily images in the archive? Specifically, I want to know if its safe to clean some of the older ones up yet.
[00:11] <cjwatson> oh, I can go do that.
[00:12] <cjwatson> I'd prefer if that were always left to one of the cdimage team
[00:12] <mikal> Ok, no problems.
[00:12] <mikal> So you'd rather that it was left manual as well?
[00:12] <cjwatson> (Must implement auto-purging of the Qin images)
[00:12] <cjwatson> It's my fault that that isn't automatic yet
[00:12] <cjwatson> It's automatic for most other images
[00:12] <mikal> Ok... you're happy doing that work and don't want me to give you a hand?
[00:13] <cjwatson> Yes, it should be done as part of our existing scripts
[00:13] <cjwatson> Would be bad for the two of us to have competing systems for that kind of thing :)
[00:13] <mikal> Heh
[00:13] <mikal> Sure
[00:13] <mikal> Ok, well if you could do a quick clean when you get a chance that would be awesome
[00:14] <cjwatson> I've cleaned up all but the last four days now
[00:14] <cjwatson> Should be syncing to scandium at the moment
[00:14] <mikal> Thanks man
[00:14] <cjwatson> Actually could you file a bug on the ubuntu-cdimage project in LP about the manualness?  Otherwise I'll forget
[00:14] <mikal> For sure
[00:14] <cjwatson> Ta
[00:15] <mikal> NP
[11:42] <tumbleweed> Laney, skaet: I'm not expecting to be around for todays meeting (not that MOTU generally has much to say)
[11:46] <Laney> i likely will not be either, but don't think there is anything to report
[15:10] <skaet> tumbleweed, Laney - ack.    Thanks for letting me know.  :)
[16:24] <cjwatson> so the new publisher crontab entry is:
[16:24] <cjwatson> 03,33 * * * * /srv/launchpad.net/codelines/current/cronscripts/publish-ftpmaster.py -v -d ubuntu >> /srv/launchpad.net/production-logs/lp_publish/publish-ftpmaster.log 2>&1
[16:24] <cjwatson> do bear it in mind if you're doing anything under the assumption that the publisher won't be running ...
[16:24] <cjwatson> I think I've adjusted most related jobs on cocoplum and lillypilly too
[16:25] <cjwatson> pitti, I tweaked your sru-report job to run twice-hourly; I hope it's fast enough for that, haven't checked
[16:25] <pitti> cjwatson: yeah, should; it usually takes around 5 mins
[16:25] <pitti> traversing through all the bugs
[16:26] <cjwatson> ok, good
[16:27] <cjwatson> I should be able to switch to API-based mass syncs fairly soon as well, now that copyPackage has sponsoring support
[16:27] <cjwatson> I'll probably work on that next week
[17:01] <skaet> cjwatson,  is there a good overview some where of all the related jobs, and how they interact from the cron perspective?
[17:01] <cjwatson> not AFAIK
[17:02] <cjwatson> it usually only matters if you're working on them, in which case 'crontab -l'
[17:02] <skaet> heh,  was afraid you'd say that.  thanks.
[17:03] <cjwatson> otherwise what mostly matters is the last-generation time of reports, which should generally be on the report itself
[17:04] <cjwatson> the relevant user/host combinations if you're working on them directly are lp_publish@cocoplum, lp_archive@cocoplum (gradually going away), and ubuntu-archive@lillypilly
[17:06] <cjwatson> wgrant: it might be worth making the FTBFS pages on qa.ubuntuwire.com update twice an hour now, if that's feasible
[17:07] <cjwatson> skaet: the jobs run as ubuntu-archive@lillypilly are set up to be fairly loosely coupled with the publisher cycle; they try to run every ten minutes and only do anything if the archive changed
[17:08] <cjwatson> so the precise timing there isn't desperately important
[17:11]  * cjwatson fixes it so that *-mismatches will run again, though
[17:16] <cjwatson> (was broken by this morning's deployment)
[17:25] <skaet> Thanks for the overview cjwatson,  appreciated.  :)
[17:33] <cjwatson> sent a mail to -devel now about the increased frequency
[17:59] <cjwatson> might miss the next publisher run; there were a lot of binaries from the mass sync
[18:00] <cjwatson> OK, so mostly half-hourly.  Still a bit to improve.
[18:11]  * cjwatson takes great pleasure in closing bug 36535
[18:11] <ubot4> Launchpad bug 36535 in launchpad "cron.daily should complete quick enough to allow 30 minute days again (affects: 1) (heat: 16)" [High,Fix released] https://launchpad.net/bugs/36535
[18:24]  * slangasek oohs at the cocoplum crontab - yay
[19:12] <infinity> cjwatson: I assume that if the publisher bumps into a lock, it just gives up, then?
[19:12] <slangasek> yep
[19:14]  * infinity thinks it's high time we fix lp_queue's crontab as well...
[19:15] <infinity> We haven't needed that gap at :55 for years.
[19:48] <mvo> could a archive admin check if "vmware-view-client" in archive.canonical.com needs NEW processing? I just uploaded it to archive.canonical.com
[19:52] <mvo> no archive-admins around anymore at this time of day/night :) ?
[20:06] <infinity> mvo: Which release?
[20:06] <infinity> mvo: Ahh, oneiric.
[20:07] <mvo> infinity: oneiric and the partner archive
[20:07] <infinity> Do we have a quality policy for partner yet, or should I just close my eyes and accept? :P
[20:08] <mvo> infinity: feedback is welcome
[20:08]  * infinity grabs the source for a quick license check, at least.
[20:08] <mvo> infinity: but there are limits what we can do
[20:08] <infinity> mvo: Yeah, I know.
[20:08] <infinity> mvo: partner scares me. :P
[20:09] <cjwatson> infinity: yeah, you just get:
[20:09] <cjwatson> 2011-12-16 18:03:03 INFO    Creating lockfile: /var/lock/launchpad-publisher.lock
[20:09] <cjwatson> 2011-12-16 18:03:03 DEBUG   Lockfile /var/lock/launchpad-publisher.lock in use
[20:12] <infinity> mvo: debian/copyright seems somewhat inaccurate...
[20:12] <infinity> mvo: At least, I assume all these binary blobs aren't actually LGPL?
[20:15] <mvo> infinity: I have no idea :/ but I guess it should be LGPL-2.1 and properiteary instead?
[20:16] <infinity> Yeah.  I just found usr/share/doc/vmware-view-client/VMware-view-client-EULA-en.txt
[20:17] <infinity> And I wish I hadn't.
[20:17] <infinity> I assume that Canonical has a license that overrides this and allows us to distribute. :P
[20:17] <infinity> Cause this is hilariously strict.
[20:18] <infinity> It would be nice if the Canonical-specific licenses we negotiate could land in debian/copyright. :/
[20:18] <mvo> infinity: thanks, I will raise this with the relevant people
[20:19] <infinity> As it reads (with what info is included in the package), we don't have a license to distribute, and since the EULA is non-transferrable, we're not giving our users the right to either download or use the product.
[20:19] <infinity> I assume neither of those statements is actually true, but there should be some text in the package denoting what the truth actually is.
[20:23] <mvo> infinity: thanks again! I will clarify this
[21:54] <mvo> SpamapS, pitti: if someone could look at the SRU for app-install-data-partner at some point, that would be great! its for vmare-view
[21:57] <SpamapS> mvo: will look at it later today
[21:58] <mvo> thanks!
[22:04] <SpamapS> mvo: done
[22:08] <mvo> thanks again!
[22:09] <infinity> mvo: Accepting your vmware thingee as-is for now, but I've raised the license clarification concerns with the powers that be.
[22:10] <infinity> mvo: (Like I said, I suspect lots of partner has similar issues, so perhaps this will just lead to better processes on that front)
[22:14] <mvo> infinity: yeah, much appreciated!
[22:14]  * mvo finally calls it a day
[22:54] <wgrant> cjwatson: Excellent!