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:11 |
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:12 |
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:13 |
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:14 |
mikal | NP | 00:15 |
=== bladernr_afk is now known as bladernr_ | ||
=== bladernr_ is now known as bladernr_afk | ||
tumbleweed | Laney, skaet: I'm not expecting to be around for todays meeting (not that MOTU generally has much to say) | 11:42 |
Laney | i likely will not be either, but don't think there is anything to report | 11:46 |
=== bladernr_afk is now known as bladernr_ | ||
=== bladernr_ is now known as bladernr_afk | ||
skaet | tumbleweed, Laney - ack. Thanks for letting me know. :) | 15:10 |
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:24 |
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:25 |
cjwatson | ok, good | 16:26 |
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 | 16:27 |
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:01 |
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:02 |
cjwatson | otherwise what mostly matters is the last-generation time of reports, which should generally be on the report itself | 17:03 |
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:04 |
cjwatson | wgrant: it might be worth making the FTBFS pages on qa.ubuntuwire.com update twice an hour now, if that's feasible | 17:06 |
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:07 |
cjwatson | so the precise timing there isn't desperately important | 17:08 |
* cjwatson fixes it so that *-mismatches will run again, though | 17:11 | |
cjwatson | (was broken by this morning's deployment) | 17:16 |
skaet | Thanks for the overview cjwatson, appreciated. :) | 17:25 |
cjwatson | sent a mail to -devel now about the increased frequency | 17:33 |
cjwatson | might miss the next publisher run; there were a lot of binaries from the mass sync | 17:59 |
cjwatson | OK, so mostly half-hourly. Still a bit to improve. | 18:00 |
* 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:11 |
* slangasek oohs at the cocoplum crontab - yay | 18:24 | |
infinity | cjwatson: I assume that if the publisher bumps into a lock, it just gives up, then? | 19:12 |
slangasek | yep | 19:12 |
* infinity thinks it's high time we fix lp_queue's crontab as well... | 19:14 | |
infinity | We haven't needed that gap at :55 for years. | 19:15 |
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:48 |
mvo | no archive-admins around anymore at this time of day/night :) ? | 19:52 |
infinity | mvo: Which release? | 20:06 |
infinity | mvo: Ahh, oneiric. | 20:06 |
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:07 |
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:08 |
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:09 |
infinity | mvo: debian/copyright seems somewhat inaccurate... | 20:12 |
infinity | mvo: At least, I assume all these binary blobs aren't actually LGPL? | 20:12 |
mvo | infinity: I have no idea :/ but I guess it should be LGPL-2.1 and properiteary instead? | 20:15 |
infinity | Yeah. I just found usr/share/doc/vmware-view-client/VMware-view-client-EULA-en.txt | 20:16 |
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:17 |
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:18 |
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:19 |
mvo | infinity: thanks again! I will clarify this | 20:23 |
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:54 |
SpamapS | mvo: will look at it later today | 21:57 |
mvo | thanks! | 21:58 |
SpamapS | mvo: done | 22:04 |
mvo | thanks again! | 22:08 |
infinity | mvo: Accepting your vmware thingee as-is for now, but I've raised the license clarification concerns with the powers that be. | 22:09 |
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:10 |
mvo | infinity: yeah, much appreciated! | 22:14 |
* mvo finally calls it a day | 22:14 | |
wgrant | cjwatson: Excellent! | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!