[00:11] 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] oh, I can go do that. [00:12] I'd prefer if that were always left to one of the cdimage team [00:12] Ok, no problems. [00:12] So you'd rather that it was left manual as well? [00:12] (Must implement auto-purging of the Qin images) [00:12] It's my fault that that isn't automatic yet [00:12] It's automatic for most other images [00:12] Ok... you're happy doing that work and don't want me to give you a hand? [00:13] Yes, it should be done as part of our existing scripts [00:13] Would be bad for the two of us to have competing systems for that kind of thing :) [00:13] Heh [00:13] Sure [00:13] Ok, well if you could do a quick clean when you get a chance that would be awesome [00:14] I've cleaned up all but the last four days now [00:14] Should be syncing to scandium at the moment [00:14] Thanks man [00:14] Actually could you file a bug on the ubuntu-cdimage project in LP about the manualness? Otherwise I'll forget [00:14] For sure [00:14] Ta [00:15] NP === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk [11:42] Laney, skaet: I'm not expecting to be around for todays meeting (not that MOTU generally has much to say) [11:46] i likely will not be either, but don't think there is anything to report === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk [15:10] tumbleweed, Laney - ack. Thanks for letting me know. :) [16:24] so the new publisher crontab entry is: [16:24] 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] do bear it in mind if you're doing anything under the assumption that the publisher won't be running ... [16:24] I think I've adjusted most related jobs on cocoplum and lillypilly too [16:25] pitti, I tweaked your sru-report job to run twice-hourly; I hope it's fast enough for that, haven't checked [16:25] cjwatson: yeah, should; it usually takes around 5 mins [16:25] traversing through all the bugs [16:26] ok, good [16:27] I should be able to switch to API-based mass syncs fairly soon as well, now that copyPackage has sponsoring support [16:27] I'll probably work on that next week [17:01] cjwatson, is there a good overview some where of all the related jobs, and how they interact from the cron perspective? [17:01] not AFAIK [17:02] it usually only matters if you're working on them, in which case 'crontab -l' [17:02] heh, was afraid you'd say that. thanks. [17:03] otherwise what mostly matters is the last-generation time of reports, which should generally be on the report itself [17:04] 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] wgrant: it might be worth making the FTBFS pages on qa.ubuntuwire.com update twice an hour now, if that's feasible [17:07] 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] so the precise timing there isn't desperately important [17:11] * cjwatson fixes it so that *-mismatches will run again, though [17:16] (was broken by this morning's deployment) [17:25] Thanks for the overview cjwatson, appreciated. :) [17:33] sent a mail to -devel now about the increased frequency [17:59] might miss the next publisher run; there were a lot of binaries from the mass sync [18:00] OK, so mostly half-hourly. Still a bit to improve. [18:11] * cjwatson takes great pleasure in closing bug 36535 [18:11] 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] cjwatson: I assume that if the publisher bumps into a lock, it just gives up, then? [19:12] yep [19:14] * infinity thinks it's high time we fix lp_queue's crontab as well... [19:15] We haven't needed that gap at :55 for years. [19:48] 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] no archive-admins around anymore at this time of day/night :) ? [20:06] mvo: Which release? [20:06] mvo: Ahh, oneiric. [20:07] infinity: oneiric and the partner archive [20:07] Do we have a quality policy for partner yet, or should I just close my eyes and accept? :P [20:08] infinity: feedback is welcome [20:08] * infinity grabs the source for a quick license check, at least. [20:08] infinity: but there are limits what we can do [20:08] mvo: Yeah, I know. [20:08] mvo: partner scares me. :P [20:09] infinity: yeah, you just get: [20:09] 2011-12-16 18:03:03 INFO Creating lockfile: /var/lock/launchpad-publisher.lock [20:09] 2011-12-16 18:03:03 DEBUG Lockfile /var/lock/launchpad-publisher.lock in use [20:12] mvo: debian/copyright seems somewhat inaccurate... [20:12] mvo: At least, I assume all these binary blobs aren't actually LGPL? [20:15] infinity: I have no idea :/ but I guess it should be LGPL-2.1 and properiteary instead? [20:16] Yeah. I just found usr/share/doc/vmware-view-client/VMware-view-client-EULA-en.txt [20:17] And I wish I hadn't. [20:17] I assume that Canonical has a license that overrides this and allows us to distribute. :P [20:17] Cause this is hilariously strict. [20:18] It would be nice if the Canonical-specific licenses we negotiate could land in debian/copyright. :/ [20:18] infinity: thanks, I will raise this with the relevant people [20:19] 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] 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] infinity: thanks again! I will clarify this [21:54] 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] mvo: will look at it later today [21:58] thanks! [22:04] mvo: done [22:08] thanks again! [22:09] mvo: Accepting your vmware thingee as-is for now, but I've raised the license clarification concerns with the powers that be. [22:10] 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] infinity: yeah, much appreciated! [22:14] * mvo finally calls it a day [22:54] cjwatson: Excellent!