[00:53] ogra_: fixed the issue with the diff generator (failing on relative hardlinks path in the tarball when the path is relative to the tarball root and not the fs root) and re-enabled the cronjob, so your image should publish in the next few minutes [04:34] hmm, https://merges.ubuntu.com/main.html appears to be updating, but the content doesn't seem to have [04:52] slangasek: note that its data source is trusty, not trusty+trusty-proposed [04:52] (which is arguably a bug ...) [04:53] cjwatson: ah, right, I had assumed rsyslog had already migrated and it hasn't [04:54] oh right, it hasn't migrated because it hasn't built because I'm still waiting for an MIR ack - ho hum [09:23] I've had to retry lucene++ twice on amd64 & i386. It's now built on amd64, but still not on i386. https://launchpad.net/ubuntu/+source/lucene++/3.0.4-0ubuntu3 [09:23] are there any tricks as to getting it built? disable parallel? keep retrying? === peterm-ubuntu is now known as Peter-wfh === yofel_ is now known as yofel [13:21] please could someone reject openvswitch from saucy-proposed [13:21] apparently I don't have my brain correctly wired today [13:23] Hello, is anyone from the SRU team around? [13:54] jamespage: done [13:55] stgraber, ta [14:04] can you reject msgpack-python and python-cliff for me? thanks [14:20] zul: done [14:21] stgraber: thanks [15:05] what release-teamish folks around? [15:06] lamont: what's up? [15:06] I'm about to possibly introduce a small disturbance into the syncproxy world. figured I should make sure it's a rational time and all that [15:07] syncproxy is moving to a new home is all [15:07] it _should_ be seamless [15:08] stgraber: any thoughts? [15:09] lamont: syncproxy is just for the ISO images right? [15:09] and archive [15:09] releases + archive [15:09] those IP addresses are dedicated, and moving to a new host [15:09] ok, how long do you expect it to be down? [15:09] which is a clone of the old host [15:09] moments only, though if I broke sync because of firewalls and such, there could be lagginess [15:10] steps: [15:10] 1) disable triggering of old [15:10] 2) one last sync [15:10] 1.5) quiesce old :D [15:10] 3) enable triggering on the new [15:10] 4) manually trigger an archive pulse [15:10] 5)watch [15:11] 6) profit [15:11] ok, well, go ahead whenever you want, just make sure to let us know here. releases I'm not concerned about since we won't be publishing anything new there for quite a while. archive is a bit more problematic but there aren't really any good time to get it out of sync with ftpmaster [15:11] right [15:11] it should remain synced. It may miss one sync pulse though [15:12] s/synced/consistent/ [15:14] lamont: looks like we use *.syncproxy.ubuntu.com for the trigger, so nothing to change on our side apparently [15:15] lamont: though I just noticed releases.syncproxy.ubuntu.com is currently unhappy. Is that because you started the switch? [15:15] stgraber: I disabled the triggering of syncproxy [15:15] ok, good, makes sense [15:15] (commented out the ssh keys for archvsync [15:15] * lamont is on step 1.5 [15:17] last sync is running [15:40] stgraber: feel like doing a manual trigger for me? [15:42] lamont: trying from nusakan now [15:42] lamont: seems to be hanging === brainwash_ is now known as brainwash [15:43] lamont: is 91.189.92.173 the correct IP for releases.syncproxy.ubuntu.com? [15:43] lamont: if so, port 22 times out, possibly due to a firewall somewhere [15:43] firewall. let me go smacking [15:44] interesting [15:47] * infinity wakes up and sees people talking about syncproxy... [15:47] lamont: Fill me in, is this a new ssh key and IP, or a cloned cutover? [15:47] Mon, 28 Oct 2013 15:44:39 +0000: Triggering archive.syncproxy.ubuntu.com: [15:48] ssh: connect to host archive.syncproxy.ubuntu.com port 22: Connection timed out [15:48] (From ftpmaster) [15:48] same ip same key, etc. [15:48] otoh, I'm figuring out why that IP isn't as live as it thinks it is [15:48] Ahh, check. [15:49] please de-new vowpal-wabbit for boost1.54 transition. https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text= [15:51] xnox: Looking. [15:58] infinity: it should be happy now. [15:58] stupid sticky arp caches [15:59] lamont: still unhappy from nusakan [15:59] hrmpf [16:01] more arp caches cleared [16:02] nusakan should be happy [16:02] yep, looks happy now [16:02] high hopes [16:02] lamont: ftpmaster's about done a publisher run, I'll let you know if it explodes. [16:02] * lamont is tailing logfiles [16:02] of course there's nothing to sync so I can't really check, but ssh to syncproxy definitely worked [16:03] stgraber: true that [16:06] lamont: Log looked good, at least. Assuming the trigger did something on the other side. ;) [16:07] I don't see that host attached to pepo:873, but maybe it was that quick? [16:08] Mon, 28 Oct 2013 16:07:29 +0000: Unifying file list with stay-of-execution list [16:08] it's chunking along on the archive bit [16:11] both a releases and an archive push are now in progress [16:18] infinity: I'm going to declare step 6 complete (profit) [16:18] /dev/sda1 1.7T 754G 807G 49% / [16:18] lamont: Good deal. [16:18] lamont, so on to step 7 [16:18] (beer) [16:18] ogra_: lamont doesn't drink. :P [16:18] * infinity sends root beer. [16:18] ogra_: 7) close ticket. [16:19] FIN [16:19] heh [16:20] infinity: could you merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updates-disregard-package/+merge/192741? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:55] infinity, bdmurray: hey, any chances you guys could review some saucy SRUs? (hud, libgpod, file-roller, indicator-* would be nice, would fix some of the top reported issues in saucy) [17:56] seb128: I'm suffering on seriously awful WiFi here, but I can have a look. [17:57] infinity: I can do it [17:57] Even better. [17:57] infinity, thanks, those are mostly small packages so should be easier to download [17:57] bdmurray, thanks [18:01] infinity: could you have a look at those procps uploads though since I sponsored them? [18:23] bdmurray: Sure. P/Q/R/S? [18:24] infinity: yes all four [18:26] bdmurray: Is this fixed in T? [18:26] Ahh, bug log says yes. [18:36] bdmurray, infinity: libindicator's saucy's SRU is green and 9 days old, can we move it to updates? [18:37] Yep. [18:38] seb128: Done. [18:38] infinity, thanks [18:39] infinity, do you guys pocket copy to t or should we do uploads there? [18:40] seb128: I can do the copy in this case, if there's no T upload planned. [18:40] infinity, that would be great ;-) [18:41] Done. [18:49] seb128: I'm confused about the indicator-datetime upload and bug 1233176 [18:49] Launchpad bug 1233176 in Ubuntu Clock App "Alarm notifications do not appear when an alarm is triggered" [Critical,Triaged] https://launchpad.net/bugs/1233176 [18:50] bdmurray, https://code.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10 [18:50] bdmurray, the change was reverted from the stable branch since it was not suitable for it, but the daily landing doesn't know how to delete changelog entries when that happens I guess [18:52] So then the janitor will close the saucy task although it hasn't been fixed. [18:53] bdmurray, we can re-open, or do you prefer another upload? [18:53] cyphermox, ^ [18:54] seb128: I think another upload would be the cleanest solution [18:56] bdmurray: agree [18:56] I'll do a manual upload that fixes this [18:56] bdmurray, what cyphermox said ;-) [18:56] that's going to be fun :) [18:56] cyphermox: thanks, let me know and I'll review it straight away [18:58] bdmurray: same version number, right? [18:58] it wasn't accepted into proposed yet? [18:58] cyphermox: no, it wasn't accepted [18:59] alright [19:04] bdmurray: ^ === iulian is now known as Guest86495 === sergiusens_ is now known as sergiusens === Guest86495 is now known as iulian === vila is now known as lt-columbo === lt-columbo is now known as vila [20:40] oh hai [20:40] infinity: (et al): how horrific are the windows if I just want to manually run the script that the publisher run triggers for the archive? [20:41] JFDI, it locks [20:41] \o/ [20:41] It tries to run every five minutes, 3 and 8 [20:41] ta [20:41] You can stop it for a bit in lp_publish's crontab if you like [20:41] atm, it's vweeping at me because awk runs for apparently forever [20:41] awk?! [20:42] 1001 21411 99.2 1.2 81244 74508 ? R 20:39 2:32 \_ awk { x[$1]=1} END { for (v in x) { print v }} filelists/2013-10-26-20-37-... [20:42] trust me.... after you shook your head and pondered, you'd say "yeah, that makes sense" [20:42] most of that whole thing is like that [20:43] Oh, this is your stuff not in the publisher [20:43] yep [20:43] k [20:59] I see what I did there [21:41] cjwatson: infinity I'm wondering just when we switched over to the publisher running every 5 instead of every 30 [21:43] lamont: It was this summer, around the time of the releng sprint, IIRC [21:43] Maybe a bit earlier? [21:43] I'd have said a couple weeks before the sprint [21:43] so early July ish [21:44] timestamp: Wed 2013-07-03 07:03:00 +0000 [21:44] message: [21:44] [adconrad,r=gnuoy] Attempt to run the publisher every five minutes instead of every thirty (lp:~adconrad/lp-production-crontabs/faster-publisher into lp:lp-production-crontabs) [21:44] lp-production-crontabs r792 [21:47] right. I'll work though the rest of what that means to the mirrormagic... [21:48] 6 times the files, and 1/6th the time to do it in ... amusing is one word for it [21:49] but anyway, it'll help make the evening more interesting [21:49] It won't actually run every five minutes [21:49] It just tries [21:50] I mean, it sometimes has a runtime under 5min, but only if it doesn't have any release pockets to publish [21:50] yeah, the stay of execution code is a touch more resilient [21:51] 71 cpu minutes, and we're almost 10% of the way through [21:51] lets just say there's room for improvement