[01:13] <stgraber> finally managed to get the lucid version of the patch working ^
[01:13] <stgraber> so if some SRU team member is around, it'd be great if I could have those two dhcp package reviewed and let through to -proposed (dhcp3 in lucid-proposed and isc-dhcp in precise-proposed)
[01:14] <stgraber> it's currently preventing containers of those two Ubuntu versions from getting an IP when running on a saucy machine. I'm told this is annoying for people doing LP dev on saucy ;)
[01:20] <infinity> stgraber: I'll have a look right nowish.  Just those two releases?
[01:22] <infinity> stgraber: The changelog history in precise is a bit goofy.
[01:27] <stgraber> infinity: yeah, I think we had an SRU that was pushed to proposed and removed, so I couldn't just +1 on the version number...
[01:28] <infinity> stgraber: Sure, I just assumed the 5.7 changelog would remain intact, instead of getting eaten in yours, but meh. :0
[01:28] <stgraber> yeah, I didn't feel like figuring out where to grab the removed 5.7 package to copy its changelog entry ;)
[01:28] <infinity> https://launchpad.net/ubuntu/+source/isc-dhcp/4.1.ESV-R4-0ubuntu5.7
[01:29] <stgraber> right, there ;)
[01:29] <infinity> No big deal.  This works.
[01:33] <infinity> Yay, po cruft in the lucid upload.
[01:33] <stgraber> was just about to mention that, I'm not sure where it's coming from, I certainly didn't touch any of it so I'm assuming that some magic debian/rules decided to shuffle the po headers around...
[01:34] <infinity> I assume something in clean is doing it, yeah.
[01:34] <infinity> I tend to call dpkg-buildpackage with -nc (making sure I'm in a clean copy first) by habit these days to avoid that sort of thing.
[01:35] <stgraber> yeah, I guess I should start doing that too. It always annoys me when I have a perfectly clean diff in bzr and I end up with a bunch more crap in the final debdiff...
[01:35] <infinity> It disturbs me that this is muscle memory: dpkg-buildpackage -i -I -rfakeroot -uc -us -S  -nc
[01:36] <stgraber> ;)
[01:36] <infinity> Pretty sure -rfakeroot has been the default for YEARS too, but I can't stop typing it.
[01:38] <stgraber> cjwatson: ^ once that's done building you can try updating your lucid container to the -proposed version of dhcp3 and then drop that mangle rule, if the binary package LP will spit out matches my locally built one, that should give you working dhcp in your container
[03:53] <wgrant> stgraber: Ah, thanks for fixing the dhcp checksum thing. I tried to get the patch working on lucid in Oakland but ended up deferring it.
[03:53] <wgrant> I've just been using an ethtool workaround
[04:07] <infinity> wgrant: Well, if you can make with the testing and verifying, that would be great then. ;)
[04:13] <wgrant> infinity: Sure, if you promise to not comment on bug #225 again :)
[04:13] <ubot2> Launchpad bug 225 in Launchpad itself "Search navigation and listing summary text are confusing." [Medium,Fix released] https://launchpad.net/bugs/225
[04:13] <infinity> wgrant: Haha.  I got spammed too, served me right.
[04:13] <infinity> wgrant: (Was due to a broken .changes in a -lowlatency SRU... *sigh*)
[04:13] <wgrant> Aha
[04:19] <wgrant> infinity: It works
[04:38] <infinity> ScottK: Since you seem to have most recent context on #1109283, I'm leaving it to you. :P
[04:52]  * ScottK wonders if he wants to know what that is.
[04:53] <ScottK> Oh.  That.
[04:54] <infinity> Probably not, but the bug log does invoke your name.
[04:54]  * ScottK is comfortable with it where it is.
[04:54] <ScottK> If their claims are accurate, they addressed my concern.
[09:45] <cjwatson> Laney: so, Joachim's preparing a mass push of Haskell to unstable at the moment
[09:45] <cjwatson> Laney: we're going to end up with that like it or not thanks to auto-sync; might we as well make sure to build a new ghc first?
[09:46] <cjwatson> Since we'll end up rebuilding the world anyway
[09:46] <Laney> I don't have a very good handle on how far ahead experimental is over saucy
[09:46] <cjwatson> Not much
[09:46] <Laney> we might get lucky with ABIs and not have to do much work
[09:46] <cjwatson> That was the mini-transition at the start of this cycle - I synced us up
[09:47] <cjwatson> I guess
[09:47] <cjwatson> So I could just leave auto-sync alone and see what happens
[09:47] <Laney> maybe let it happen and if it's huge then do a full one
[09:49] <cjwatson> The blurbs stuff is all in haskell-devscripts and there are tight build-deps, it seems
[09:50] <cjwatson> Joachim's reuploading every haskell package, it's not just copies, so we will end up with effectively a full rebuild although as you say we might get lucky and not have to *rebuild* stuff
[09:50] <cjwatson> *again
[09:50] <Laney> ah, wait, I see
[09:50] <Laney> if we get ghc into saucy-proposed early we might get the transition for less cost
[09:51] <Laney> if everything is going to be synced over anyway
[09:51] <cjwatson> Yeah, that's what I meant
[09:52] <cjwatson> I might have to temporarily stop auto-sync or something
[09:52] <Laney> works for me
[09:52] <Laney> of course we won't get as much help on build ordering as Debian does
[09:53] <Laney> you can see why Joachim was motivated to implement some of that stuff :-)
[09:53] <cjwatson> Yeah
[09:57] <infinity> +1 to merging the new GHC and seeing what happens.
[09:58] <cjwatson> It's a nine-hour build on armhf, so we'd definitely not be able to rely on it beating the next auto-sync.
[09:59] <Laney> disabling it seems reasonable
[09:59] <infinity> Shame about GHCi being disabled on armhf.
[10:00] <cjwatson> I spent weeks trying to fix it; it was just too hard
[10:00] <Laney> apparently the upcoming upstream series Fixes Everything™
[10:00] <cjwatson> Laney: ho ho ho
[10:00] <cjwatson> I'll believe it when I see it :)
[10:01] <infinity> Laney: You mean 8.x, 7.8, or 7.6.betterthanwhatwehave?
[10:01] <Laney> Milestone 7.8.1 according to http://hackage.haskell.org/trac/ghc/ticket/3658
[10:01] <Laney> Igloo's your man on that one
[10:02] <infinity> Yeah, he's a helpful sort.
[10:04]  * infinity thinks it might be time for a nap.
[11:23] <cjwatson> aha, texlive-doc was removed from unstable, that's why there was no upload transitioning it to new texlive
[11:23]  * cjwatson processes that
[11:30] <cjwatson> Hmm, I wonder if I just made texlive-base uninstallable
[11:30] <cjwatson> Oops
[11:31] <cjwatson> proposed-migration should sort it out in a cycle
[11:50] <ogra_> oh sigh sigh sigh ...
[11:50] <ogra_> http://paste.ubuntu.com/5696703/
[11:51]  * ogra_ tries to package the latest phablet.ubuntu/com tarballl
[11:51] <ogra_> 4.3M only for license data
[11:51] <ogra_> and i dont really know what to do for the tons of binaries included in the tree
[11:53] <ogra_> nobody will want to ever read the copyright file i'll assembel from these txt files
[11:54] <ogra_> *assemble
[11:56] <cjwatson> Foul
[11:56] <ogra_> well, i guess i can shrink the whole a bit based on subdirs using the same license
[11:56] <ogra_> but it will still be horrible to read
[11:57]  * cjwatson uploads ghc
[11:57]  * Laney fears
[11:58] <cjwatson> As soon as I can squeeze packets round the side of dput I'll stop auto-sync until it's built
[12:51] <cjwatson> wgrant: Are you able to extend http://qa.ubuntuwire.com/debcheck/ to cover saucy?
[12:53] <wgrant> cjwatson: I think it is extended, but crashing due to multiarch
[12:54] <wgrant> It's still running the pre-edos-debcheck codebase
[12:54] <wgrant> From like 2006
[12:54] <cjwatson> Ah, oops
[12:55] <cjwatson> I guess I can get britney to tell me
[12:58] <wgrant> Oh, and edos-debcheck itself is superseded now.
[13:02] <cjwatson> Only in name, I thought
[13:02] <wgrant> Indeed
[13:04] <wgrant> cjwatson: Are you particularly attached to the mildly hideous per-pub changeOverride?
[13:08] <cjwatson> wgrant: Well, I can guess why you're asking - what interface were you thinking of instead?
[13:08]  * Laney gets a weird haskell-platform rejection mail
[13:09] <cjwatson> Laney: my problem, dealing with it
[13:09] <cjwatson> I'm working on a demote-to-proposed script and running into some stupidities in the copier
[13:09] <cjwatson> You have to say include_binaries=True except when you mustn't
[13:10] <wgrant> cjwatson: Giving an API a set of names and override changes, I guess. Batchier and less prone to corruption due to races
[13:10] <wgrant> cjwatson: Oh?
[13:10] <wgrant> Intra-archive copies should always fail without it.
[13:10] <cjwatson> Unless there were never any binaries built for that source.
[13:10] <wgrant> Hah
[13:10] <cjwatson> In which case it fails with "source has no binaries to be copied" because OBVIOUSLY that's what I meant.
[13:11] <wgrant> There's no reason for that check other than that it's probably not what you want
[13:11] <wgrant> Except in cases like this
[13:11] <cjwatson> include_binaries=True should be "copy any binaries that exist", IMO
[13:11] <wgrant> I believe that check predates the current relatively pedantic build status checks
[13:11] <wgrant> So it's probably reasonable to ditch it
[13:14] <cjwatson> Wait, there's a strict_binaries param there ...
[13:14] <cjwatson> Except that is randomly strict about other things beyond what the docs say
[13:15] <cjwatson> Well, sort of
[13:15] <cjwatson> Probably a red herring
[13:16] <wgrant> Huh, is there?
[13:16] <wgrant> Oh, that might have been added for the rather inventive IDS stuff
[13:17] <wgrant> Yeah
[13:17] <cjwatson> Yeah.  I think it's not what I want here.
[13:19] <cjwatson> Just removing the check implies that it's possible to copy-with-binaries within the same series and archive even when everything's still building
[13:19] <cjwatson> But that's probably actually OK
[13:26] <cjwatson> ahahaha
[13:26] <cjwatson> include_binaries=False:
[13:26] <cjwatson> haskell-platform 2012.2.0.0ubuntu1 in saucy (same version already has published binaries in the destination archive)
[13:26] <cjwatson> include_binaries=True:
[13:26] <cjwatson> haskell-platform 2012.2.0.0ubuntu1 in saucy (source has no binaries to be copied)
[14:00] <cjwatson> Laney: FWIW we need to make sure to sync haskell-devscripts before the deluge starts, too.  Have to wait for the next gina run before I can do that
[14:03] <Laney> right, I was checking to see if it's been picked up
[14:03] <cjwatson> Two and a bit hours
[14:03] <cjwatson> It'll be well before ghc/armhf builds
[14:03] <wgrant> cjwatson: Are we out of sync with dak?
[14:03] <Laney> fair
[14:03] <Laney> I'll be on trains by then though
[14:03] <cjwatson> wgrant: I didn't think so
[14:04] <Laney> heading up to beautiful Humberside
[14:04]  * Laney nods towards xnox 
[14:04] <cjwatson> 52         1,7,13,19  *   *   *   /srv/ftp-master.debian.org/dak/config/debian/cron.dinstall
[14:05] <cjwatson> May 24 09:07:26 franck dinstall[15590]: Daily cron scripts successful, all done
[14:05] <wgrant> So it takes ~75 minutes?
[14:05] <cjwatson> Haha, two minutes after our mirror started
[14:05] <wgrant> + mirroring..
[14:05] <cjwatson> And yeah, ftp.uk needs time
[14:06] <cjwatson> So indeed - I think we should probably shuffle back an hour
[14:06] <wgrant> So we might do well to push it back like half an hour
[14:06] <wgrant> Or an hour
[14:06] <cjwatson> http://ftp.uk.debian.org/debian/project/trace/ says it synced at 09:22
[14:06] <xnox> Laney: ah..... =)))))
[14:06] <wgrant> It also probably wouldn't hurt to mirror every 30 minutes and run gina if the archive has changed
[14:06] <wgrant> But just pushing it back an hour works
[14:06] <cjwatson> Wait, but surely our cron times are UTC
[14:07] <wgrant> They should be nowadays
[14:07] <cjwatson> And we mirror at 10:05 and start gina at 10:10
[14:07] <wgrant> Ah
[14:07] <wgrant> So it's about right
[14:07] <cjwatson> So if franck is on UTC too it should be fine
[14:07] <cjwatson> Which at least the log file allegedly is
[14:08] <cjwatson> mirror every etc.> yeah, I've been suggesting that at six-monthly intervals for a while ;-)
[14:09] <cjwatson> e.g. https://bugs.launchpad.net/launchpad/+bug/798611/comments/5
[14:09] <ubot2> Ubuntu bug 798611 in Launchpad itself "Package Auto Sync seems to get ahead of +localdiff calculation" [High,Triaged]
[14:09] <wgrant> The extension of that is then to rewrite the runner bits of gina so that it can diff the LP and disk states in <30s like it should be able to..
[14:10] <cjwatson> Well, that too, but the thing that drives it could just check timestamps in project/trace/ or something
[14:10] <wgrant> Yeah
[14:11] <cjwatson> haskell-devscripts 0.8.16 was accepted at 09:33, so it's not a surprise that it would have to wait for the 13:52 dinstall
[14:11] <Laney> Could we not get a push mirror so that this stuff happens when triggered?
[16:03] <bdmurray> I'm looking at the SRU fixing bug 1056545 and it hasn't been positively verified, but there are no incidents of the crash with the version from -proposed on errors.  Does that seem like enough to mark it v-done?
[16:03] <ubot2> Launchpad bug 1056545 in Session Installer "session-installer crashed with AlreadyCalledDeferred in callback()" [Undecided,Incomplete] https://launchpad.net/bugs/1056545
[16:07] <bdmurray> infinity, slangasek: ^^ ?
[18:57] <infinity> bdmurray: Did you have a reproducer for it?  It would be nice to actually test it meaningfully.
[18:58] <infinity> bdmurray: For an "everyone uses it" desktop component, I'd be happy enough with the "silence is golden" idea that errors is giving us the whole story (like, say, a compiz crash no longer happening), but it's equally possible in this case that people running -proposed just aren't doing the thing(s) that trigger this bug.
[19:00] <phillw> Hi, sorry about this, as I am sure I have asked before.. is the usage of xdg-open no longer suggested for 'quick-links' such as those on "Easy Install" https://help.ubuntu.com/community/RestrictedFormats
[19:02] <bdmurray> infinity: I may have had a reproducer for it, I'll look again
[19:02] <infinity> phillw: That sounds more like a -devel question.
[19:04] <phillw> infinity: thanks :)
[20:03] <slangasek> bdmurray: so you did some scripting around notifying of unverified packages that are subject to removal... is there anything that I can use for selectively removing packages that failed verification?
[20:04] <slangasek> (clearly, running remove-package and commenting on the bug by hand is too many steps for me :)
[20:29] <bdmurray> slangasek: no, I don't have anything for that
[20:29] <slangasek> ok
[20:41] <ScottK> slangasek: Maybe bdmurray could whip up a script that tracks SRUs unverified after 30 days by uploader and decline further SRUs from such people until they verify an equal number of other people's SRUs.
[20:41] <slangasek> hmm!
[20:50] <ScottK> The moral of the story would be don't upload SRUs you don't have a plan to get verified.
[20:52] <slangasek> yep
[21:22] <infinity> ScottK: My plan usually involves "wait for a week or two for bug submitters to verify, and if they don't get around to it, do so myself".
[21:23] <infinity> ScottK: The latter part sometimes takes a gentle reminder from someone, though. :/
[21:23] <ScottK> Right, so the new rule would be motivation to be more organized.
[21:23]  * infinity has certainly been guilty of leaving his own SRUs in proposed too long.
[21:24] <infinity> Though, I don't feel too bad about leaving glibc in proposed for ages, cause it means it gets well-tested.
[21:24] <infinity> It just also means it gets superseded by security updates over and over again. :P
[21:25] <ScottK> There are some packages for which a longer wait is a good idea.
[22:39] <cjwatson> OK, ghc has built and published everywhere.  Unleashing the auto-sync hounds
[22:44] <infinity> OH GOD NOW.
[22:44] <infinity> s/W//
[22:44] <infinity> Thanks for inverting my meaning there, fingers.
[22:45] <infinity> Jerk fingers.
[22:48]  * infinity does some chroot updating.
[22:59] <cjwatson> Updated: 373.  *clang*
[22:59] <cjwatson> (Well, not clang.  But.)
[23:00] <infinity> scping new chroots now to cope. :P
[23:02] <infinity> And look, another acl2 that will inexplicably fail on Ubuntu and not Debian.
[23:02] <cjwatson> It's Lisp, what do you expect
[23:02] <infinity> I expect not to care, except that I keep seeing it at the top of the list, and it irks me.
[23:03] <infinity> If it was zcl2, I could blissfully ignore it.
[23:03] <cjwatson> I keep confusing it with acl.
[23:03] <cjwatson> I WONDER WHY.
[23:03] <slangasek> setfacl2confuse
[23:03] <infinity> cjwatson: More fun because the current version of ACL is 2.
[23:03] <infinity> (Though the SOVER is 1)
[23:04] <cjwatson> At least these uploads do seem to be aimed at disabling the tests that are failing for us ...
[23:04] <cjwatson> Dunno whether Camm's looking at Ubuntu build logs or whether they failed somewhere in Debian too
[23:05] <infinity> Dunno.  We'll find out in three days, I guess.
[23:05] <cjwatson> In fact, https://buildd.debian.org/status/fetch.php?pkg=acl2&arch=i386&ver=6.1-2&stamp=1369251882 doesn't look that dissimilar to our failure
[23:06] <infinity> I suspect some of my more nightmarish buildd confusions will just go away when I have ARM buildds with 4G of RAM and fast disks to swap to.
[23:06] <infinity> My current confusion is "why am I on hour 19 of a build that takes 6 hours in Debian on slower hardware?"
[23:07] <infinity> I'm not sure if I should blame g++-4.8's memory usage, or the fact that we're building with parallel=2, but either way, it's bad.
[23:09] <infinity> Why does Haskell get all the good package names?  I knew about "happy", this is the first time I've noticed "frown" too.
[23:09] <cjwatson> BTW I expect a bunch of these builds to fail; feel free to ignore them and I'll go through and retry them in dep order over the weekend
[23:09] <cjwatson> y-u-no-validate is pretty good
[23:09] <infinity> Hahaha.
[23:09] <infinity> I saw that on the last transition, I think.
[23:09] <cjwatson> Though sadly it's a XUL extension so presumably slated for removal somewhere
[23:11] <infinity> I guess it's proof that the developer community keeps getting fresh blood if we have packages with 4chan-meme naming schemes.
[23:12]  * infinity considers rewriting fail2ban in C and calling it something like "umadbro".
[23:12] <infinity> Can even claim I wrote it originally for Ubuntu, hence the "u" name.
[23:16] <cjwatson> Thanks for the chroot updates.  Bed, I think
[23:17] <infinity> 'Nighty night.