[00:03] <xnox> lamont: my connection to archive.ubuntu.com has turned from ~20-40 MBs to a 198 kBs cripple ware =/ unless virgin media UK is having issues.
[00:04] <lamont> xnox: interesting
[00:06] <lamont> xnox: I'll have to dig more - the big change is s/146GB/300GB/ drives, *8
[00:07] <xnox> lamont: well, i see a little packet loss with mtr (on ae1-core0.gsld2.uk.as6908.net & canonical-gw.datahop.net) but that might be just usual filtering / dropping ping packets.
[00:08] <infinity> lamont: Hrm?  You fiddled with archive frontends?  I thought you just replaced syncproxy.
[00:08] <xnox> http://paste.ubuntu.com/6321324/
[00:08] <lamont> infinity: new box, larger drives
[00:08] <lamont> on account of trusty won't fit
[00:09] <infinity> lamont: Err, yes, but that was syncproxy, right?
[00:09] <lamont> oh. right
[00:09] <lamont> xnox: I did nothing to archive.u.c
[00:09] <xnox> lamont: must be ISP hick-ups.
[00:09] <lamont> I suspect so
[00:10] <xnox> downloading to /dev/null a large package is back to at least 9MBs now.
[00:10]  * xnox ponders if I should start having a full unsplit local mirror for all arches.
[00:11] <infinity> It's a bit of a pain to unsplit them, sadly.
[00:11] <xnox> infinity: i'm already running unsplitter =)
[00:11] <lamont> infinity: it's not horriic
[00:11] <lamont> it's just "non-trivial"
[00:11] <infinity> lamont: I'd rather just have a proper mirror to rsync from. :P
[00:11] <xnox> https://github.com/xnox/apt-mirror
[00:11] <infinity> (Well, I have one, but you'd hunt me down if I was rsyncing from pepo)
[00:12] <xnox> infinity: rsync one & another, verify the archive Release.gpg, if doesn't match don't commit, if it does Horay!
[00:12] <lamont> heh
[00:12] <stgraber> infinity: was just about to say, rsync over ssh works fine ;)
[00:12] <xnox> infinity: so boils down to completing the second rsync before a push =)
[00:13] <lamont> xnox: my approach is more evil - I just rsync dists/ and use a 404 handler to fetch as needed.  then morguify as needed
[00:13] <infinity> xnox: The smarter way to go would be to grab all the dists trees first (repeat until you get a match), then mirror both pools.
[00:13] <lamont> I really don't recommend that approach - it kinda grew from some strange intermediate states
[00:13]  * xnox is meant to spin up the instance of https://github.com/xnox/apt-mirror on canonistack, but last time around had some troubles with https launchpad librarian.
[00:13] <xnox> lamont: https://github.com/xnox/apt-mirror/blob/master/nginx.snapshot =) the apt-mirror above also only syncs dists ;-)
[00:13] <lamont> xnox: you do have the advantage that files don't disappear from pool/ until 24 (or was that 48) hours after they disappear from all packages files
[00:14] <infinity> lamont: Right, hence my approach above.  Mirror archive/ports dists (until Release match found), then mirror pool, then copy dists.new to dists, win.
[00:14] <xnox> lamont: i'm just sad that apt-get goes all berserk upon http -> https redirects and fails to verify them. Which imho it shouldn't care about as long as .gpg is correct.
[00:14] <infinity> But that first bit is stupid fiddly.
[00:16] <infinity> I guess the easier way to go, actually, is just to symlink ubuntu-ports/pool to ubuntu/pool, and let ubuntu-ports/dists and ubuntu/dists live as separate entities.
[00:16] <infinity> That also has the advantage of being the layout the installer wants.
[00:17] <lamont> nice
[00:17] <lamont> actually, that's what I ahve, now that I think about it
[00:17] <lamont> ubuntu-ports and ubuntu are separate trees, and arch-all and source are, uh, rewrites.
[00:18] <lamont> or at least look in the main tree before fetching
[00:18]  * lamont doesn't care enough to go look
[00:21] <infinity> lamont: Well, you'd rsync pool twice with --delete but --exlude ports arches on the non-ports run and --exclude main arches on the ports run.
[00:21] <infinity> lamont: That way, you'd only get all.deb and source once.
[00:21] <lamont> except I don't sync pool at all
[00:21] <infinity> (Except for the source dists tree, but that's not a big deal)
[00:22] <infinity> Oh, you squid pool?
[00:22] <lamont> sometimes, it sucks to live with impoverished bandwidth
[00:22] <lamont> wors
[00:22] <lamont> I 404-handler it
[00:22] <lamont> so it's all right there where it belongs, but only if someone fetches it
[00:22] <lamont> and then there's the part where I hijack dns
[00:23] <lamont> my way is not very sportsmanslike
[00:23] <infinity> Yeah, I hijack DNS too, so I don't have to tell d-i about my mirror.
[00:23] <infinity> Perfectly reasonable solution, IMO.
[00:23] <lamont>                 allow from all
[00:23] <lamont>                 # Go fetch the file
[00:23] <lamont>                 ErrorDocument 404 /cgi-bin/missing-file
[00:24] <lamont>  140  369 4448 /srv/mmj.archive.ubuntu.com/cgi-bin/missing-file
[00:24] <stgraber> I used to do that, but now moved to having my transparent squid hijack the traffic to any of the archive servers and send it to my mirror, unless the traffic comes from the mirror, has the advantage of supporting regexps to catch all the .archive.u.c and .ports.u.c at once
[08:29] <jibel> cjwatson, does britney submits test requests as soon as an architecture is built or does it wait for all the binaries to be built?
[08:32] <jibel> cjwatson, for example with mongodb, 1:2.4.6-0ubuntu6 FTBFS on i386 but is available on amd64, a test request has been submitted but reconciliation is not possible on i386 because autopkgtest installed 1:2.4.6-0ubuntu5
[08:33] <jibel> if I wait on the interface side, it will wait until a new binary is available and state will remain 'running' during that time
[10:42] <jamespage> please could SRU bug 1236462  be pushed through to -updates; I just finished testing the standard OpenStack topologies in the lab
[10:42] <ubot2> Launchpad bug 1236462 in swift (Ubuntu Saucy) "[SRU] update openstack packages to 2013.2 release tarballs" [Medium,Fix committed] https://launchpad.net/bugs/1236462
[10:42] <jamespage> maybe Daviey if he's around?
[10:42] <jamespage> :-)
[12:25] <Daviey> jamespage: looks good, released. Thanks :)
[12:59] <jamespage> Daviey, ta
[13:15] <cjwatson> jibel: It's *supposed* to wait until the package has been built on all ADT_ARCHES (i.e. amd64 i386)
[13:16] <cjwatson> Or rather, is not out of date on all such architectures
[13:16] <cjwatson> (So it's possible you'd get strange behaviour for new packages, but that shouldn't be the situation here)
[14:53] <bdmurray> cjwatson: could you merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updates-disregard-package/+merge/192741 ?
[14:53] <cjwatson> looking
[14:55] <cjwatson> bdmurray: done
[14:55] <bdmurray> thanks
[16:15] <stgraber> so what do I need to do to get dch to default to trusty (on a trusty machine)?
[16:16] <stgraber> the upload above is unfortunately not the first one where I push to saucy by accident as I'm trusting dch to DTRT
[16:16] <cjwatson> This is not a terribly graceful answer but I just edit the script :-)
[16:17] <stgraber> oh, it's acutally hardcoded in there... was vaguely hoping it'd use distro-info or something...
[16:17] <stgraber> I guess I'll do a devscripts upload then
[16:18] <cjwatson> aye
[16:19] <stgraber> ah, looks like it build-depends on distro-data, so it's not hardcoded anywhere in the source but needs a no change rebuild to pick it up
[16:34] <infinity> stgraber: I'd love it dch on any release defaulted to the devel release (which distro-info could do for you), but the last time I did that, I got shot down by people who told me that my filthy developer needs were less important than the billions of people who upload to PPAs. :P
[16:34] <infinity> s/love it/love if/
[16:35] <stgraber> infinity: yeah, I remember that. I just wish it'd just default to whatever base-files says you're running
[16:35] <ogra_> infinity, just tell them to use click packages
[16:36] <ogra_> PPAs are so yesterday
[16:36] <stgraber> that'd be making me mostly happy and wouldn't affect stable releases
[16:36] <infinity> stgraber: Yeah, that could be sort of doable.  Or, we could just remember to rev it when we open.
[16:36] <stgraber> yeah, I'd have to check whether devscripts is on the long list of stuff to upload at open time, but I vaguely remember it being on some of those wiki pages
[16:36] <infinity> stgraber: Just like I always open with a vim merge, you could always open with a devscripts merge, and we're good.  Right? :)
[16:37] <stgraber> yeah, I just need to remember it ;) I think I've been the one doing the no change rebuild the past 2-3 cycles but for some reason I always forget about it, get frustrated a few days later and then have to figure out what to do again :)
[16:37] <infinity> (This barely affects me, because I almost never run 'dch -r', but just manually s/UNRELEASED/trusty/ when I'm ready to go)
[16:38] <infinity> For whatever muscle-memory reasons.
[16:38] <cjwatson> There's always dch -rD trusty
[16:38] <cjwatson> But yeah
[16:39] <infinity> Training my fingers to use dch -r could take years, if not decades. :P
[16:39] <infinity> Heck, I still type dpkg-buildpackage -rfakeroot -uc -us -S
[16:40] <infinity> Even though I know it's redundant.  And has a friendly wrapper.
[16:40] <rbasak> It feels wrong to me if the timestamp in the changelog is wrong. So I use -r to bump that (and have to use -D)
[16:40] <stgraber> I mostly use it with bzr branches with my usual: bzr diff, dch -r, debcommit -r, bzr push :parent
[16:48] <Laney> Any problem if I copy g-s-d from s-proposed to t-proposed?
[16:48] <infinity> Nope, as long as it's to proposed.
[16:48] <Laney> sure is
[16:48] <seb128> we should just copy all the SRUs pending in there ;-)
[16:48] <infinity> Perhaps, but we also should stop that Very Soon.
[16:50]  * seb128 likes those copies, it allows him to be lazy
[16:55] <jibel> cjwatson, does http://paste.ubuntu.com/6324974/ make sense? It removes packages from the request file that have been identified by britney as invalid for testing.
[16:56] <jibel> a case is a package upload that triggers a test of an uninstallable package
[16:57] <jibel> or not all the binaries have been published
[17:02] <cjwatson> jibel: thanks.  could you MP that for me and I'll look?  sitting in the CI meeting right now and it's hard to concentrate on this
[17:02] <cjwatson> (client sprint)
[17:03] <jibel> cjwatson, sure.
[17:42] <seb128> infinity, bdmurray: hey, is there any chance that one of you could accept "hud" to saucy? it has the top issues in e.u.c constantly for a week and the fixes are waiting in the queue since friday ... would be good to get that in
[17:48] <bdmurray> seb128: okay, I'll have a look
[17:48] <seb128> bdmurray, thanks!
[17:58] <cjwatson> Laney: FYI I'm having a go at merging ben and creating a proper Ubuntu template - once that's done maybe we can get IS to create us a trusty-transitions chroot and then we can just use that
[17:58] <cjwatson> Need to switch to the new version ASAP for dose-debcheck support
[17:59] <cjwatson> Since edos-debcheck can't handle Depends: foo:any
[18:04] <Laney> cjwatson: Oh, cool
[18:05] <Laney> cjwatson: I had at the back of my mind a note to try using fakechroot/fakeroot
[18:07] <Laney> also there's some old-ish-but-newer-than-deployed branches at lp:ubuntu-transition-tracker & friends
[18:07] <Laney> Maybe you meant that already
[18:08] <cjwatson> Yeah, I'm working on that
[18:08] <cjwatson> I'd like to get to where we just run with the packaged ben
[18:09] <cjwatson> Maybe once the DC is on trusty we can work with backports instead and ditch the chroot
[18:09] <Laney> Yeah, that was the goal. I even did some backports of OCaml libraries and things but never got a newer environment to deploy into
[18:09] <Laney> I think there's an ancient RT
[18:10] <cjwatson> Well, if we use a trusty chroot we don't need backports
[18:10] <Laney> indeed
[18:10] <cjwatson> I don't think it's worth backporting to lucid/precise
[18:10] <Laney> that wasn't the case at the time :-)
[18:10] <cjwatson> Yep
[21:48] <kirkland> infinity: could you please reject an errant upload?  https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=run-one
[21:49] <stgraber> kirkland: rejected
[21:49] <kirkland> stgraber: thanks!
[22:12] <seb128> bdmurray, could you review system-config-printer's saucy SRU as well? it's a one liner
[22:16] <bdmurray> seb128: momentarily
[22:57] <seb128> bdmurray, thanks