[00:45] <jbicha> please reject that u-g-default-settings
[00:51] <jbicha> I'd like to see the gnome-shell & u-g-default-settings uploads in for raring
[04:22] <ScottK> Let's hope I rejected the right one.
[06:50] <stgraber> good morning
[07:13] <pgraner> morning stgraber
[07:23]  * infinity is questioning the wisdom of waking up today.
[08:19] <Laney> doko__: yes indeed (I get mailed about them). I'll upload something in a second.
[08:25] <cjwatson> I'm going to temporarily remove ubuntuone-couch in order to be able to copy it back (there was an override accident).
[08:26] <infinity> double-override explodey bug?
[08:26] <cjwatson> wgrant reckoned "overridden twice the same way"
[08:27] <wgrant> cjwatson: You shouldn't actually have to remove it
[08:27] <wgrant> Just copying it over itself should work
[08:27] <infinity> Yeah, just copying over itself works.
[08:28] <infinity> Jinx.
[08:28] <infinity> Either way, it's an irksome bug because no one notices the effects right away.
[08:28] <cjwatson> wgrant: It didn't earlier, but I only just noticed that that was because I forgot to use -b
[08:28] <cjwatson> But too late now
[08:28] <wgrant> Aha
[08:28] <wgrant> yes, that would do it :)
[08:28] <infinity> We now have shankbot double-checking my work on kernel SRUs to make sure things don't disappear.
[08:28] <cjwatson> Looks like it worked
[08:29] <cjwatson> (That's what I get for trying to do out-of-the-ordinary LP-related jobs at the weekend)
[08:29] <cjwatson> infinity: My new orphaned-sources script in u-a-t turns out to be good at spotting this
[08:30] <infinity> cjwatson: \o/
[08:30] <infinity> removed and blacklisted mozilla-gnome-keyring
[08:30] <cjwatson> Though it probably doesn't work right on stable releases
[08:30] <cjwatson> So shankbot's still helpful for SRUs
[08:31] <wgrant> cjwatson: That won't notice things with arch-dep stuff as well, will it?
[08:32] <cjwatson> It won't notice if a binary only disappears on a subset of architectures, if that's what you mean
[08:32] <cjwatson> Or if only a subset of binaries disappear
[08:32] <infinity> That nyquist/i386 FTBFS is messing with my head.
[08:32] <stgraber> cjwatson: hey, I just went through the ReleaseProcess wiki page, updating the bits about the ISO tracker. I was also surprised to see no mention of britney/proposed-migration on there. What's the plan? turn off britney before we start rolling final images (so we can decide what goes as SRU and what goes as last minute changes to raring)?
[08:33] <cjwatson> stgraber: Probably because it's the first release with it and we haven't made up a process yet :)
[08:33] <infinity> stgraber: Yeah, a global block and unblock things as we want them, methinks.
[08:33] <infinity> (ie: the same thing Debian does near release)
[08:33] <cjwatson> Indeed, global block makes more sense than commenting out the cron job
[08:33] <cjwatson> ("block-all source")
[08:34] <cjwatson> I'll edit ReleaseProcess now
[08:34] <stgraber> hmm, yeah, block-all indeed sounds better, that way we don't have to do all the checks ourselves before copying
[08:34]  * infinity nods.
[08:35] <cjwatson> It's not really a time-dependent thing though, it's "before publishing anything that's going to be a zero-day SRU"
[08:35] <infinity> Would be nice if we could extend britney to understand seeds and do something like "block-all seeded-source", but meh.
[08:35] <cjwatson> I think I'll put it at -3 days (i.e. now) and apply the hint
[08:35] <cjwatson> Unless anyone objects?
[08:36] <infinity> cjwatson: Go nuts.
[08:36] <infinity> We'll definitely have a few things to let through, but I prefer us putting thought into it at this point anyway.
[08:36] <cjwatson> Yeah
[08:36] <stgraber> fine with me
[08:36]  * cjwatson remembers to make a paired change to NewReleaseCycleProcess
[08:38] <cjwatson> OK, hint applied, let's see if it works
[08:38] <infinity> Such confidence.
[08:38] <cjwatson> We'll need to keep an eye on excuses
[08:39] <infinity> unblocks are just "unblock foo/ver"?
[08:39] <cjwatson> http://ftp-master.debian.org/testing/hints/README
[08:39] <cjwatson> But indeed
[08:39] <infinity> Yeah, I have to google that every time.  We should just have the README in the hints bzr.
[08:40] <infinity> Assuming britney will ignore it because the user "README" has no perms. :P
[08:45] <cjwatson> doko__: Should we remove avian/armhf, or do you expect to be able to fix that?
[08:45] <doko> cjwatson, hmm, can we remove it proposed instead?
[08:45] <doko> it in ...
[08:45] <cjwatson> How do you mean?
[08:46] <cjwatson> There isn't an armhf build of avian in -proposed; that's kind of the problem
[08:47] <doko> I mean, remove the source in binaries in -proposed
[08:47] <doko> s/in/and/
[08:48] <cjwatson> Oh.  Sure, if you want to withdraw the upload from -proposed you can, or if you'd prefer we can just put it on the list of uploads to carry over to s-proposed
[08:48] <cjwatson> The latter might be cleaner if it's an "I'll fix it up, but not this week" kind of thing
[08:49] <doko> yep, we can carry it over too
[08:49] <infinity> Eh.  No point in keeping it in s-proposed if the plan is for doko to upload a newer version at some point.
[08:49] <infinity> But either way.
[08:50] <doko> same for handbrake, that was a bad sync :(
[08:50] <infinity> doko: handbrake will be carried over, it builds fine against libav9, we just haven't migrated yet.
[08:50] <cjwatson> infinity: Might just make the history clearer
[08:51] <infinity> cjwatson: Did you have any clever ideas for git-annex's suckage?
[08:52] <Laney> i am trying to penetrate this makefile
[08:52] <Laney> to find out where to insert flags
[08:52] <cjwatson> Yeah, Laney's clearly ahead of me here :)
[08:53] <cjwatson> Laney: Or you could just build-dep on yesod on powerpc too - doesn't it work there now?
[08:53] <Laney> yes, but armhf
[08:53] <infinity> Someone sorting out pytables/ppc wouldn't hurt my feelings either.
[08:53] <cjwatson> armhf won't work anyway will it?  git-annex uses template haskell
[08:54] <cjwatson> Unless that's only in stuff that can be avoided ...
[08:54] <Laney> not sure; the current version at least builds there on debian
[08:54] <Laney> (in unstable)
[08:54] <Laney> anyway, I ought to do some normal work, so feel free to take over
[08:54] <Laney> I was trying to find out how to poke an -f-Webapp in for the non-yesod case in d/rules
[08:55] <cjwatson> Oh, it got more cabalised?
[08:55] <Laney> it kind of is, but I cannot tell at this point how much that gets used
[08:56] <cjwatson> I'm happy (ish) to have a look
[08:56] <cjwatson> infinity: Don't suppose you left leviathan on?
[08:57] <infinity> cjwatson: I did.
[08:57] <cjwatson> Orsome.
[08:57] <Laney> the new version in Debian is evne more so, so if you get ragey looking at that might be an option
[08:57] <xnox> infinity: i briefly looked at pytables/ppc but can only look at it against past EOD really as it quite a weird one =)
[08:57] <cjwatson> Laney: Yeah, I was considering that a while back but it had a load of extra features and stuff
[08:58] <Laney> la la la
[08:58] <cjwatson> We probably should have done that weeks ago
[08:58] <Laney> Well, hopefully we can find out how to do this, or decide that leaving armhf broken is alright
[09:00] <cjwatson> It doesn't matter for proposed-migration at this point, but I agree it'd be good to fix
[09:03] <cjwatson> Yeah, I think it's easier than you think.  -f-Webapp isn't the problem
[09:04] <Laney> oh, good
[09:07] <stgraber> infinity: hey, I just had a quick look at http://people.canonical.com/~ubuntu-archive/testing-ports/raring_probs.html and noticed it's not empty. For that hv-kvp-daemon-init entry, shouldn't it be safe to just make the package build only on i386 and amd64 (since AFAIK hyperV only supports those anyway)?
[09:09] <infinity> stgraber: That absolutely should be arch-restricted, yes.
[09:09] <infinity> stgraber: I'll do that right now.
[09:14] <doko> cjwatson, cinnamon now built on armhf, but is it blocked now manually?
[09:14] <infinity> I'll unblock in a sec.
[09:14] <infinity> We've blocked the world now.
[09:15] <xnox> stgraber: on the iso tracker, I'm failing to look up when was the last time the 3 MAAS testcases were fully tested on raring.
[09:16] <xnox> Also do we have anyone confirmed to test MAAS with candidate images? =) jamespage had his turn already with quantal release ;-) so maybe someone else this time around?
[09:18] <infinity> stgraber: New hv-kvp-daemon-init in the queue in 2 mins.
[09:18] <stgraber> xnox: I'll get the dates from the DB, one sec
[09:18] <stgraber> infinity: cool, I'll review once queuebot notices, should be an easy review ;)
[09:18] <xnox> stgraber: cuase a recent enough test, might be ok for that. Thanks!
[09:19] <stgraber> (will just need to remember to remove any leftover armhf and powerpc binaries afterwards)
[09:19] <infinity> stgraber: I'll remove those now, so britney doesn't have a sad.
[09:20] <infinity> stgraber: Done.
[09:21] <stgraber> xnox: 2013-02-13 and 2013-02-14 was the last time those were covered, so they definitely need re-testing
[09:22] <xnox> hm at Alpha2 time. stgraber do you know who did the test? Can we ping the same person? =)
[09:25] <stgraber>        1289 |   37582 |      1 | 2013-02-14 17:00:37 | hggdh2
[09:25] <stgraber>        1288 |   37582 |      1 | 2013-02-14 16:13:55 | hggdh2
[09:25] <stgraber>        1290 |   37582 |      1 | 2013-02-13 21:26:06 | hggdh2
[09:26] <stgraber> that was a day before he announced he was leaving Canonical, so that'd explain why we didn't get any result after that
[09:27] <pgraner> stgraber, I'll track someone down to do it
[09:27] <stgraber> pgraner: thanks
[09:28] <pgraner> stgraber, no prob
[09:29] <infinity> stgraber: OMG REVIEW FASTER RELEASE IS SOON EEEE!
[09:31] <stgraber> infinity: had to wait 5 minutes for LP to give me a two lines diff ;)
[09:31] <ogra_> there is a release ?
[09:31] <infinity> ogra_: That's the plan.
[09:32] <Laney> Oh crap, we aren't rolling?
[09:32] <xnox> Well, at such a last notice, I guess we'll scrap pressing CDs =)
[09:35] <cjwatson> stgraber: bug 1170120 :-)
[09:35] <ubot2> Launchpad bug 1170120 in Launchpad itself "Package diff generation is unnecessarily unresponsive" [Low,In progress] https://launchpad.net/bugs/1170120
[09:38] <stgraber> cjwatson: yay, thanks for fixing this!
[09:41] <cjwatson> well, pending review and unlikely to make it now in time to be useful for raring, but yeah
[09:41] <cjwatson> when I actually looked at it it became clear that the slowness was largely artificial
[10:29] <cjwatson> pytables> I started looking at that the other day, it's just an endian-related bug I think, just didn't quite finish ...
[10:49] <cjwatson> ^- that git-annex test-builds fine on armhf and powerpc
[10:51] <Laney> +-- utf-8 umbrella (utf-8 cloud looks too stormy)
[10:53] <infinity> cjwatson: Awesomesauce.
[10:53]  * Laney wonders why that works, since it still seems to use yesod
[10:53] <cjwatson> It's moved into a bit that's conditional on webapp
[10:53] <cjwatson> instead of on assistant
[10:53] <Laney> ah
[10:54] <Laney> I see, Assistant.hs:140
[10:54] <doko> dobey, u1db currently ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[10:54] <cjwatson> Hm.  I wonder why we don't have a similar non-multiarch tclConfig.sh hack in tcl8.5-dev as in tcl-dev
[10:54] <cjwatson> Quite tempted to add one
[10:54]  * Laney gets back to renaming variables in lightdm
[10:55] <infinity> Grr, missed accepting that by a few seconds. :P
[10:57] <xnox> cjwatson: good point. =) should be there.
[11:00] <cjwatson> Doing that now
[11:00] <doko> cjwatson, are there that many more?
[11:01] <cjwatson> Well, I found at least one, that's enough for me :-)
[11:02] <doko> I just fear if we add it, then all of daniel chen's patches maybe get reverted in the s-series ...
[11:02] <cjwatson> Doesn't seem like a big deal if they do
[11:02] <xnox> the less the changes to packages, the quicker we can multiarch tktcl in debian the better.....
[11:03] <xnox> as we do want to drop all patches and just be in sync with debian on most of those packages.
[11:03] <cjwatson> Yeah, I'd rather increase the chances of actually getting this transition landed in Debian, TBH
[11:03] <cjwatson> It's not as if it renders it any less M-A: same
[11:04] <cjwatson> And it'll probably help various third-party builds
[11:05] <xnox> and keep us more compatible with the rest of distributions out there....
[11:06]  * xnox doesn't like how interractive parted chokes on uefi-enabled cds dd'ed onto pen-drives.
[12:40] <ScottK> infinity: We have to britney unblock everything now?  Might be worth a mail to ubuntu-release to let everyone know.
[12:40] <cjwatson> I'll do it
[12:41] <ScottK> Thanks.
[12:42] <infinity> cjwatson: dpkg-architecture is in dpkg-dev, do you want to, I dunno, make tk8.5-dev depend on it?
[12:43] <cjwatson> infinity: Hmm.  tcl-dev and tk-dev don't
[12:44] <infinity> cjwatson: Right, that was sort of my point.
[12:44] <cjwatson> Well, I meant the existing ones in the archive (from tcltk-defaults) as opposed to tcl8.5-dev and tk8.5-dev
[12:44] <cjwatson> But you may be right ...
[12:44] <infinity> cjwatson: For package builds, this makes no difference, since dpkg-dev is build-essential, but for random people installing tcl8.5-dev and expecting the config script to work, it won't.
[12:45] <infinity> cjwatson: Oh, does tcl-dev do the same wrong thing?
[12:45] <cjwatson> Yeah
[12:45] <cjwatson> I'll go fix it all
[12:45] <infinity> Well, fixing that would be nice too.  Thanks. :)
[12:45] <infinity> (Is there a non-dpkg-arch way to get that string, I wonder?)
[12:46] <cjwatson> Don't think so
[12:46] <infinity> Actually, wait, tcl-dev isn't MA:same is it, so there's no reason you can't embed that string at build time instead of doing it at runtime.
[12:46] <infinity> Which seems more correct, since it should match the package arch, not the default dpkg arch.
[12:46] <xnox> infinity: it is.
[12:46] <infinity> Oh, it is.
[12:46] <infinity> I missed the header in my apt-cache.
[12:46] <infinity> Drat.
[12:46] <xnox> infinity: MA & Arch should match between foo-defaults and fooX.Y
[12:47] <cjwatson> Yeah, hence this hack.
[12:47] <xnox> otherwise it just doesn't work......
[12:47] <infinity> That hack will not work if your tcl8.5-dev is not the primary dpkg arch.
[12:47] <cjwatson> Correct
[12:47] <infinity> Oh well.
[12:48] <infinity> Cross that bridge when it annoys us for cross-building, I suppose. :P
[12:48] <cjwatson> But if you're doing that sort of thing I don't think it's excessive to convert to the right path for finding {tcl,tk}Config.sh
[12:48] <infinity> Anyhow, if you want to add run-time deps on dpkg-dev, that would be shiny.  If you don't care, I can also pretend not to.
[12:48] <xnox> I am slightly surprised that dpkg-architecture is in dpkg-dev and not dpkg, since I would have thought something like that would be desirable on e.g. all amd64 installs where we auto-enable multiarch out of the box.
[12:49] <infinity> xnox: I don't see how the first part of your sentence relates to the second.
[12:49] <cjwatson> It's irrelevant at run-time
[12:49] <infinity> dpkg-architecture has pretty much zero runtime utlity (except when people try to do hacks like this)
[12:49] <cjwatson> Even this isn't really run-time
[12:49] <infinity> True, it's runtime of a dev package.
[12:49] <cjwatson> The linker knows about the multiarch path, which is all that's needed
[12:50] <cjwatson> (And the odd string embedded in binaries and such)
[12:50] <cjwatson> infinity: All uploaded, should show up shortly
[12:50] <ogra_> infinity, FYI https://wiki.ubuntu.com/Touch/AndroidAutobuilds
[12:51] <xnox> infinity: ok. libdpkg-perl is only optional, despite being in many seeds. I somehow thought if dpkg-architecture scripts dependencies are all essential, there is no harm moving dpkg-architecture into dpkg. but turns out there is.
[13:00] <seb128> if I upload an updated ubuntu-docs package, can it still get in for the release? (we updated the translation template on thursday last week and quite some translation teams worked over the W.E to get the new strings translated)
[13:00] <cjwatson> I think so
[13:00] <seb128> great, upload on its way
[13:00] <seb128> thanks
[13:00] <doko> cjwatson, using dpkg-architecture, and not b-d on dpkg-dev? I mean, it won't file on the buildds ...
[13:00] <cjwatson> doko: Read scrollback :-)
[13:00] <cjwatson> That's fixed in latest uploads
[13:00] <doko> heh
[13:01] <cjwatson> And doesn't need a build-dep, only dep
[13:01] <cjwatson> infinity: When're we stopping image builds?
[13:30] <cjwatson> ScottK: your unblock syntax is wrong - needs to be "unblock SOURCE-NAME/SOURCE-VERSION" as in my mail
[13:31] <ScottK> cjwatson: Thanks.  I'll fix.
[13:32] <ScottK> Fixed.  In my defense, I did that before you sent the mail.
[13:32] <cjwatson> :)
[13:32] <cjwatson> Still wrong though
[13:33] <cjwatson> First / needs to be a space
[13:33] <ScottK> oh
[13:33] <ScottK> ok
[13:33] <ScottK> Maybe that ....
[13:34] <cjwatson> Yeah, looks better, thanks
[13:34] <ScottK> Thanks for setting me straight.
[13:34] <cjwatson> ScottK: oh, except you have the versions the wrong way round
[13:34] <ScottK> Heh.  Not my morning.
[13:34] <cjwatson> as in, the imageshack-uploader name with the ddtp-translations version and v.v.
[13:35] <cjwatson> not meaning to call you out in public or anything, sorry :)
[13:36] <ScottK> No problem.
[13:36] <ScottK> Fixed even more.
[13:37] <Laney> handily you can copy and paste from queue accept, afaics
[13:39] <cjwatson> ScottK: not pushed though ... maybe a clash with my most recent rev?
[13:39] <ScottK> Yep
[13:39] <ScottK> Fixing
[13:39] <infinity> cjwatson: After that openjdk-7 is done and migrated seems like a decent cutoff to do a respin and uncron.
[13:40] <ScottK> Figures.  The ONE time I don't pull "since it's just been a minute since my last change."
[13:41]  * Laney runs
[14:22] <jbicha> seb128: your ubuntu-docs upload doesn't matter if we don't regenerate the language packs, right?
[14:59] <seb128> jbicha, not sure, I tested a local build and some page are generated at build time
[14:59] <seb128> jbicha, but in any case we are ready for the next langpack update
[15:04] <Daviey> stgraber: I understand you reviewed juju.. and asked for some fixes.  It's in the queue now. Do you want to take that review or not?
[15:04] <stgraber> Daviey: ah, I didn't notice it getting back in the queue. Yep, I'll take a look
[15:05] <Daviey> stgraber: thanks!
[15:33] <stgraber> Daviey: there you go
[15:34] <Daviey> woot
[15:34] <Daviey> super stgraber
[15:37] <dobey> doko: can i get a retry for u1db? i just pulled it from bzr, built a source package, updated pbuilder, and built it in there, with no errors :-/
[15:40] <Daviey> stgraber: I assume you checked suitable break/replaces ^ ?
[15:42] <stgraber> Daviey: I think I did last week, anyway, I did a test build + test upgrade here today and it worked, so it should be good
[16:14] <infinity> cjwatson: nyquist sorted.  Was a particularly icky and silly bug.
[16:14] <infinity> cjwatson: Any traction on pytables?
[16:14] <cjwatson> nyquist> good stuff
[16:14] <cjwatson> pytables> Test-building a really crude fix now
[16:15] <infinity> \o/
[16:15] <cjwatson> overlapping strcpy> ah, yeah, that would cause mass confusiong
[16:15] <cjwatson> -g
[16:16] <ScottK> Is any of the non-partner stuff in New going to be accepted or should we just reject it all now?
[16:16] <infinity> cjwatson: Yeah, there was a lot of tag-team WTFery to get down there.
[16:16] <cjwatson> I was just looking at tegaki-omg-long-package-name
[16:16] <infinity> ScottK: I just did vala earlier, I might still poke one or two others.
[16:16] <ScottK> OK
[16:21] <doko> dobey, given back on amd64. but the last retry was on Sat ...
[16:29] <cjwatson> dobey: It fails in exactly the same way in a local sbuild instance.  Perhaps try that instead of pbuilder
[16:36]  * cjwatson does a little dance as we get rid of magellanic (old torrent.u.c)
[16:36] <infinity> !!
[16:36] <infinity> Really?
[16:37] <cjwatson> magellanic is dead, long live caranda
[16:38] <infinity> Fuck yeah.
[16:38] <infinity> I assume the new machine is all disky and RAMy and CPUy?
[16:38] <cjwatson> No idea but I'd have hoped so.  It can't be that much worse than mag
[16:39] <infinity> magellanic was a 486, I'm sure.
[16:48] <cjwatson> Well, tegaki-zinnia-traditional-chinese has a giant prebuilt model file in its source which it ships, but it does include a Makefile for rebuilding it from the XML file, and apparently the Debian ftpmasters were happy with tegaki-zinnia-simplified-chinese which is basically the same
[16:49] <cjwatson> So minded to accept if only because otherwise it's kind of unfairly inconsistent
[17:05] <utlemming> stgraber: around?
[17:05] <dobey> cjwatson: but the build depends isn't different for the package, so the same dependencies should be installed in both. why would it fail in sbuild but not pbuilder? that makes absolutely no sense to me.
[17:05] <infinity> dobey: Which package is this?
[17:06] <infinity> dobey: I missed the context.
[17:06] <dobey> infinity: u1db
[17:06] <dobey> infinity: the tests failed in doko's archive test rebuild
[17:06] <dobey> but they aren't failing under pbuilder
[17:07] <dobey> though i do get similar failures running tests for u1db trunk, on my actual raring system. but it's pretty hard to determine what actually broke and caused the failures, since u1db hasn't changed in the archive since december…
[17:07] <doko> dobey, did you check what cjwatson suggested (running in sbuild)?
[17:08] <infinity> Explodes here too.
[17:08] <dobey> doko: as soon as i figure out how to do that i guess
[17:08] <dobey> doko: but that doesn't really help, other than knowing that it does fail in sbuild (but not pbuilder)
[17:08] <dobey> doesn't tell me why it fails
[17:08] <infinity> Shouldn't need sbuild.  You can just grab the chroot tarball, unpack it, chroot in, install build-deps and build.
[17:09] <infinity> If you really can't make it fail in a pbuilder/raring setup, your chroot might be a bit dirty.  You could compare installed packages.
[17:09] <doko> dobey, failed in the december test rebuild too ... http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20121221-raring.html
[17:12] <dobey> i wonder what broke it
[17:20] <cjwatson> dobey: Might be some other minor difference in the environment.  I believe sbuild is a bit stricter about clearing it out.
[17:20] <cjwatson> dobey: In any case, reproducing it locally will let you investigate directly rather than guessing; it usually becomes clear once you find the cause.
[17:21] <xnox> to me it looks like a PYTHONHASHSEED issue, worth a try running tests with 1..10 and see if some of them pass while others fail.
[17:21] <cjwatson> dobey: (sbuild has options for "don't purge the chroot if a build fails", so you can schroot in and try finer-grained things.)
[17:21] <cjwatson> Plus, sbuild is just plain more relevant than pbuilder ...
[17:22] <dobey> xnox: right. though hash_randomized is set to 0 in sys.flags here…
[17:23] <dobey> cjwatson: sbuild is also just plain more pain that pbuilder (documentation tends to recommend pbuilder, and it's certainly much easeir to set up and get working, especially given that local sbuild and what is on launchpad also differ)
[17:23] <xnox> looking at the failure somethind does produce the results out of order, might as well test them once sorted.
[17:24] <doko> yes, hash rand. is turned off by default in 2.7
[17:24] <xnox> dobey: exacatly how "mk-sbuild raring" is harder than "pbuilder-dist raring create" with "sbuild -d raring foo*.dsc" and "pbuilder-dist raring build foo*.dsc" ??????
[17:24] <cjwatson> dobey: *shrug* I use sbuild for everything, I'm not failing to eat my own dog food here
[17:24] <seb128> quick release question
[17:24] <cjwatson> I don't find it difficult
[17:24] <dobey> anyway, i'm not trying to argue about sbuild vs. pbuilder or anything. i just want to be able to figure out what is going on here, because the tests work fine in quantal, but not in raring.
[17:25] <xnox> dobey: the distro-builders use sbuild for a reason ;-)
[17:25] <seb128> the gtk patch from https://launchpad.net/ubuntu/+source/gtk+3.0/3.6.4-0ubuntu7 (uploaded a week ago) created some scrolling jerkiness for some users, who are suggesting we revert the change for the release
[17:25] <cjwatson> And while it's true that local sbuild and LP sbuild differ, in practice they differ much less than any sbuild and pbuilder.
[17:25] <xnox> thus it's good enough arguments as to which one is "better" =))))
[17:25] <seb128> the issue is not a blocker either way
[17:25] <dobey> xnox: they also use a different sbuild setup than one can easily create locally
[17:25] <dobey> xnox: and i don't care which one is "better"
[17:26] <seb128> would you recommend to rather got for a SRU or upload to raring still?
[17:26] <cjwatson> Not significantly different in the majority of cases, and if you care about that then why on *earth* are you using pbuilder to try to reproduce sbuild problems?
[17:26] <cjwatson> At the very least try sbuild before asking other people ...
[17:26] <cjwatson> Since in this case it didn't differ, and it also doesn't differ in most others
[17:27] <ScottK> seb128: If you're confident you could SRU it, go ahead and upload and do the SRU template in the bug.  We just won't unblock it and then it'll be available if we decide to push it in.
[17:27] <seb128> ScottK, ok, thanks
[17:28] <Daviey> I've only ever seen the chroot difference between LP's and locally created matter once.  And in that instance, i downloaded the LP tarball and based my build on that, to debug
[17:29] <xnox> dobey: for me it fails utterly different from how it fails in the test rebuild. http://paste.ubuntu.com/5593211/
[17:30] <xnox> dobey: the test-suite failures in the rebuild, seem like one can address them due str != unicode (note comparison of "string" and u"string") and sorting actual before comparing with reference.
[17:31] <dobey> xnox: 'foo' == u'foo' in python 2
[17:31] <dobey> xnox: only if the encoding was actually different would it fail
[17:32] <xnox> dobey: true, then I don't understand the first failure here https://launchpadlibrarian.net/137872928/buildlog_ubuntu-raring-i386.u1db_0.1.4-0ubuntu2_FAILEDTOBUILD.txt.gz
[17:32] <xnox> whitespace?! wtf =)
[17:33] <dobey> no it's not the whitespace. it's that the values are different
[17:33] <jbicha> is it ok that I marked today's Ubuntu GNOME images as ready for final testing?
[17:33] <dobey> it's not just an ordering issue (though that is part of it)
[17:34] <xnox> right, yeah, there is an extra one. missed it.
[17:39] <xnox> dobey: I have just created a fresh pbuilder-dist raring create, and it fails in it as well, this time with failures as in the rebuild. Maybe your pbuilder chroot got something stray left in it? e.g. dropped essential packages and the like do not get autoremoved... or maybe it's out of date w.r.t. build dependencies.
[17:39] <xnox> with pbuilder-dist raring build u1*.dsc
[17:39] <xnox> dobey: so it's not even sbuild vs pbuilder problem.
[17:40] <dobey> so it's sqlite that broke
[17:42] <infinity> gtk?  Really?
[17:43] <ScottK> infinity: I told him to go ahead and upload for SRU and we'd just not unblock.
[17:43] <infinity> Ahh.
[17:43] <infinity> Well, we can unblock if there's a respin and we feel the urge.
[17:43] <infinity> (And we're respinning tonight anyway, so we'll see)
[17:44] <ScottK> Right.  It'll be there if it seems we want it.
[17:48] <infinity> ScottK: I need to escape this network for a bit, are you going to review and accept that gtk?
[17:48] <ScottK> It's unlikely I'll feel like I know enough to decide, but I'll look at it and accept if I'm comfortable.
[17:48] <infinity> Check.  If no one else gets to it, I will later.
[17:48] <ScottK> I can ask someone else to review if not.
[17:54] <seb128> infinity, ScottK: the gtk upload is basically "revert to what we had until one week ago"
[17:54] <seb128> if you debdiff 0ubuntu6 and 0ubuntu8 you will just get the changelog diff
[17:55] <seb128> the bug the patch tried to fix was already there in quantal so it's not a new bug or recent regression we tried to address
[18:03] <ScottK> Thanks seb128
[18:03] <seb128> ScottK, thanks to you guys for looking at it ;-)
[18:04] <ScottK> OK.  Done.
[18:30] <dobey> doko: ok, i've filed bug #1171568 for the regression in sqlite
[18:30] <ubot2> Launchpad bug 1171568 in sqlite3 (Ubuntu) "libsqlite3-0 3.7.15 breaks u1db tests" [Undecided,New] https://launchpad.net/bugs/1171568
[20:27] <phillw> is the cron off?
[20:28] <ScottK> There's a rebuild planned for tonight.  Dunno if it's via cron or not.  (trying to answer what is, I think, your actual question)
[20:29] <phillw> thanks ScottK, yeah, that was the question, lubuntu still shows 21st :)
[20:38] <slangasek> cron is off, yes
[20:38] <slangasek> so rebuilds are manual at this point
[20:38] <slangasek> I thought they were already run though, maybe I misunderstood?
[20:38]  * slangasek checks nusakan
[20:40] <phillw> slangasek: lubuntu shows 21st on my browser. Can someone else check.
[20:40] <slangasek> correct; the question on my part is whether that's because a build is pending, or because a build failed
[20:40] <infinity> cron is off, unless stgraber failed at that.  I'll kick off a bunch of rebuilds before bed, unless someone in a more sane timezone wants to do that for me.
[20:41] <slangasek> infinity: "before bed" - are we currently waiting for some publication before kicking them off?
[20:42] <ScottK> Since pitti doesn't seem to be around, is there anyone who has a minute to examine a possible fix for a jockey problem before I take a cleaver to it to fix something?
[20:42] <ScottK> If you can give me half an hour, I think I can have jockey working for wl again.  That may just affect Kubuntu though.
[20:42] <infinity> slangasek: gtk+3.0
[20:43] <slangasek> infinity: ok
[20:43] <infinity> slangasek: The armhf build is just finishing up, and I've unblocked it in britney.
[20:43] <slangasek> ScottK: where jockey is concerned, by instruments are no less blunt
[20:43] <slangasek> s/by/my/
[20:43] <ScottK> OK.
[20:43] <infinity> slangasek: If you're cool with a respin of The World, I can pretend not to care until the morning.
[20:44] <slangasek> infinity: I'm not sure what the current recommended method of respinning the world is - pointer?
[20:44] <infinity> slangasek: Colin and I have just been copying and pasting from crontab.
[20:44] <slangasek> ok
[20:44] <infinity> The old "pipeling" no workie since the python rewrite, and neither of us has bothered to do anything cooler just yet.
[20:44] <slangasek> any ordering constraints?
[20:44] <infinity> s/pipeling/pipeline/
[20:45] <infinity> slangasek: Just jamming it all in at once should more or less DTRT with locking.  But if you want to be clever, you can try to keep, say, the ARM and PPC builders full. *shrug*
[20:46] <infinity> slangasek: I found that, roughly, running two sessions, where you go top down in one, and bottom up in the other, and meet in the middle, seems to keep everything busy.
[20:48] <slangasek> I could just run everything in the background and trust the locking :)
[20:48] <slangasek> s/the background/parallel/
[20:48] <ScottK> Testing my jockey fix now.
[20:48] <infinity> slangasek: That should generally DTRT.
[20:59] <ScottK> Meh.  Trickier than I thought.  Getting a bigger hammer.
[22:00] <ScottK> Did we stop making the Kubuntu powerpc image on purpose?
[22:00] <ScottK> Someone's actually testing it, so it might be nice to have one less than three weeks old.
[22:00] <ScottK> (or point me to a failure log please)
[22:32] <doko> ScottK, infinity: the libfilesystem-ruby source should be removed, the new kid on the block is ruby-filesystem
[22:41] <phillw> ScottK: you can blame smartboyhw. He told me that your PPC tester had lost his charger for the laptop he had and asked if our lubuntu PPC testers would assist. If it is too late for a re-spin, i will cancel the request.
[22:41] <ScottK> No, I'm in favor of testing if we can get a current image.
[22:42] <ScottK> What he said was correct.
[22:43] <phillw> ScottK: and 'blame' is meant with a smile, he is a dedicated tester team lead and is quite entitled to ask other teams for help, you guys on kubuntu helped lubuntu out a lot in our early days... testers repsond to any SOS
[22:43] <ScottK> Ah.  OK.
[22:45] <ScottK> slangasek: Can you tell why Kubuntu PPC is out of date by several weeks?
[22:45] <phillw> ScottK: ppc installer is a pain, but if you get a respin, we may be able to test it to the level that lubuntu uses for a desktop system.
[22:45] <ScottK> Yeah
[22:46] <slangasek> ScottK: looking to see
[22:46] <ScottK> Thanks.
[22:47] <phillw> ScottK: Whilst I 'can' edit test suites, I'd ask you to to set it to the same as lubuntu uses. There is more chance of getting a passed by the skin of teeth, with release notes.
[22:48] <phillw> I'm not kubuntu team :)
[22:51] <slangasek> ScottK: no obvious cause; etc/default-arches appears to be correct, and there's no indication of a livefs build attempt
[22:52] <ScottK> slangasek: Someone may have stopped it due to a lack of testers.  Now we've got one.  Would you please give a respin a shot?
[22:52] <phillw> +1
[22:52] <slangasek> ScottK: I'm not seeing *where* it's disabled; something is preventing it from being built, I'd like to get to the bottom of that
[22:52] <ScottK> OK
[22:52] <ScottK> Thanks
[22:52] <slangasek> it's not a deliberate change, that would be done in etc/default-arches
[22:52] <slangasek> so there's a bug somewhere
[22:53] <ScottK> I think the jockey problem is release notes material unless pitti makes a magical appearance.
[22:53] <slangasek> ohwait, maybe my local branch is out of date; let's see
[22:54] <slangasek> mmm still no
[22:55] <infinity> slangasek: It's disabled in production.  Was done during the last milestone and not reverted.
[22:55] <slangasek> ah.
[22:56]  * slangasek reverts
[22:56] <slangasek> mmm, there's an edubuntu diff as well
[22:57] <slangasek> ok, firing a kubuntu powerpc build
[22:57] <infinity> The edubuntu diff should stay.
[22:58] <phillw> talk about re-spin the world? :)
[22:59] <ScottK> FSVO world
[23:01] <slangasek> so as it happens, royal seems to be doing a whole lot of nothing
[23:03] <slangasek> ah, no, it's really just that slow compared to the others :/