[04:27] <pitti> Good morning
[07:08] <dholbach> good morning
[07:38] <jibel> pitti, about gvfs, I found that a test has been requested for gvfs_1.17.2-0ubuntu3 when libgphoto2 2.4.14-2.1 has been synced
[07:38] <jibel> pitti, but no trace of a test when gvfs itself has been uploaded, i'll continue to investigate
[07:40] <pitti> jibel: well, don't waste too much time on it
[07:41] <pitti> jibel: I was just curious as this is pretty much exactly the kind of regression that we want to keep out
[07:41] <jibel> pitti, I suspect it is not limited to gvfs
[07:42] <pitti> jibel: infinity seemed to have a case yesterday where a new eglibc only triggered 19 rdepends, that also seemed a bit low
[07:42] <pitti> not sure whether this is related somehow
[07:42] <pitti> but if you say that a test had been requested on the libgphoto2 sync, then it's something else
[07:45] <pitti> infinity: hm, what does that want to tell me? https://launchpadlibrarian.net/146278424/buildlog_ubuntu-saucy-amd64.sane-backends_1.0.23-0ubuntu3_FAILEDTOBUILD.txt.gz
[07:45] <pitti> infinity: some error in the PPA chroot's .sbuildrc?
[07:45] <doko> Laney, any idea why gtk+3.0 is built sequentially?
[07:48] <JackYu> dholbach, morning, we updated a new tarball at bug #1203958, would you please take a look?
[07:52] <dholbach> JackYu, taking a look
[07:56] <dholbach> JackYu, I commented on the bug report
[08:16] <pitti> jibel: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ back to green \o/
[08:22] <Laney> pitti: I wonder if unblock implies forcing the tests
[08:23] <Laney> gvfs was unblocked during the freeze
[08:23] <pitti> jibel: ^
[08:23] <Laney> more a cjwatson question I'd guess
[08:23] <pitti> Laney: they indeed did coincide, perhaps that's it
[08:23] <pitti> but I thought unblocking would just mean "remove the block in the ~u-release branch", not actively pushing stuff
[08:24] <Laney> unblocks override blocks, so we tend to add them specifically
[08:28] <Noskcaj> roaksoax, PING
[08:29] <pitti> Laney: oh, I misinterpreted that as "got unblocked after the freeze", sorry
[08:29] <Laney> ah
[08:30] <Laney> I mean the 'unblock' hint type - I wouldn't be surprised if that overrode test failures
[08:30] <Laney> p.s. good work on fixing that
[08:30] <pitti> Laney: very plausibly, yes
[08:30] <pitti> jibel: ^ so, don't waste time on investigating this (yet)
[08:54] <JackYu> dholbach, updated:).
[08:54] <pitti> tkamppeter: ah, it seems you are somewhat attached to flphoto?
[08:55] <pitti> tkamppeter: do you know if there is a patch anywhere to build it against libgphoto 2.5? I looked around (fedora, suse, etc.), but fedora never had it, suse dropped it, and upstream disappeared
[08:56] <pitti> tkamppeter: otherwise, would you be very sorry if we removed it? shotwell should by and large replace it
[08:58] <dholbach> JackYu, uploading
[08:58] <JackYu> dholbach, great, thanks a lot:)
[08:58] <dholbach> anytime :)
[09:00] <doko> pitti, jibel: looking at the python2.7 test failures on i386 ...
[09:01] <doko> the test_curses test did fail to start early this week, however we had no python related changes. wasn't this the time when the new autopkgtest was enabled?
[09:03] <cjwatson> Laney: unblock doesn't force tests
[09:06] <pitti> doko: it's around the same time, yes, but that doesn't change how std{in,out,err} or the VMs look like; these were mostly fixes around error handling and wrong dependencies
[09:07] <doko> pitti, no change in the redirection handling?
[09:07] <pitti> no
[09:07] <doko> but why did it start failing?
[09:08] <pitti> doko: my first bet would be on https://launchpad.net/ubuntu/+source/ncurses/5.9+20130608-1ubuntu1
[09:09] <pitti> that's quite a large change
[09:09] <pitti> doko: and presumably that python2.7 run was triggered due to the new ncurses, as it landed at that very time?
[09:10] <pitti> I guess it wasn't held back because someone marked python2.7's autopkgtest as 'known broken', as it had failed for a while
[09:10]  * pitti looks into the override branch
[09:11] <didrocks> doko: hey, (not related) do you think that some part of boost needs to be rebuilt/there is a mismatch? I got https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz during the day and still get it
[09:11] <didrocks> sil2100: if you have time and finished the daily release activity, can you look about that (Mir related) please ^?
[09:12] <pitti> might be a victim of the same problem that allowed the new libgphoto2 sync to get in despite it breaking reverse dependencies
[09:12] <doko> didrocks, ahh, the mpi split package ... but isn't mir in main?
[09:12] <didrocks> doko: not yet, there is MIR for Mir, but not in main for now
[09:12] <sil2100> didrocks: will do!
[09:13] <didrocks> thanks sil2100 ;)
[09:14] <didrocks> sil2100: if you find changes in the rdepends (as apparently doko did some), maybe the MIR for Mir needs to be updated as well
[09:16] <seb128> JackYu, hey, did you see my NEW review comments bug?
[09:16] <Laney> cjwatson: OK then, not sure why gvfs passed here - http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2013-07-23/03:57:03.log
[09:16] <Laney> the timing matches up with ScottK's unblock, AFAICS
[09:17] <JackYu> seb128, not yet. Where can I got it?
[09:17] <didrocks> doko: so, what's up? how can you fix it? mind giving a little bit more info? ;)
[09:17] <seb128> JackYu, https://bugs.launchpad.net/bugs/1206613
[09:18] <seb128> JackYu, it would be nice if you subscribed to the packages you work on, so you get email for bugs filed on those
[09:20] <JackYu> seb128, I see, thanks:). It seems that I overlooked the bug email...
[09:21] <seb128> JackYu, you're welcome, and no worry, I'm just pointing it, in case
[09:23] <JackYu> seb128, got it, we will improve it in the next release:).
[09:23] <seb128> thanks
[09:26] <tkamppeter> pitti, no problem to drop it, it was one of Mike Sweet's hobby projects. He did not do anything on it for years. The highlight of it was nice printing functionality, especially for more than 1 photo on a sheet and it was the only program which did automatic crop-to-fit to make a photo filling the whole page (or a given rectangle with an aspect ration not necessarily equal to the photo's).
[09:27] <pitti> tkamppeter: http://www.easysw.com/~mike/flphoto/ doesn't even exist any more, it just times out ..
[09:27] <tkamppeter> pitti, perhaps we simply drop it.
[09:27] <pitti> tkamppeter: ok, thanks for confirming
[09:28] <tkamppeter> pitti, easysw.com is history. Mike has no private servers any more. CUPS is coming from Apple now. Anything needed for CUPS but dropped by Apple is coming from me (OpenPrinting).
[09:29] <pitti> tkamppeter: ok, that explains why other distros dropped the package
[09:31] <pete-woods> pitti: resuming over here then
[09:31] <pete-woods> pitti: I only modify the source - and it's a new patch - I'll just check if it's fixed in 2.37
[09:31] <pitti> pete-woods: I think it'd be better to update glibmm2.4 to 2.37.4 to match our glib version
[09:31] <pitti> pete-woods: if it's fixed there, of course
[09:31] <cjwatson> Laney: Hard to tell from this point, unfortunately :-(
[09:32] <cjwatson> Laney: But I did look over the unblock code and AFAICS it only does anything to blocks
[09:32] <pitti> pete-woods: if not, let's update anyway (as other API certainly changed) and apply your patch on top
[09:32] <pete-woods> pitti: that sounds reasonable to me! :)
[09:33] <cjwatson> Laney: That is, block is "set update_candidate to False unless we find a matching unblock", rather than unblock going through and setting update_candidate to True which might indeed do more than intended if that were the way it worked
[09:34] <doko> pitti, but the autopkgtest did run before ncurses was in the archive
[09:35] <cjwatson> pitti: sane-backends> that's a known problem where Xen builders occasionally lose their mind and scribble over bits of the filesystem.  It's pretty scary but we don't know what causes it ...  For now the fix is generally to get ops to reset the slave
[09:40] <infinity> pitti: Which host was that on?
[09:41] <infinity> pitti: (Linking to builds is much friendlier than build logs)
[09:41] <doko> pitti, looking at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/ I have a hard time to see why this is marked as failed. all tests succeed ...
[09:43] <pete-woods> pitti: from looking at the git repo now, it seems like I patched a generated file, so the patch works on the source tarball, but it's not going to apply upstream
[09:44] <pete-woods> lots of macro magic about _WRAP_CTOR
[09:45] <cjwatson> doko: I think you're being confused by Jenkins' terribly confusing UI
[09:45] <cjwatson> doko: Don't look at the log under "Last Successful Artifacts"
[09:46] <infinity> cjwatson: s/reset the slave/rebuild the slave/
[09:46] <cjwatson> doko: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/27/artifact/results/log is the last failure log
[09:46] <cjwatson> infinity: *nod*
[09:46] <infinity> cjwatson: Did anyone hunt down which guest it was and have it rebuilt?
[09:46] <cjwatson> 1 test failed:
[09:46] <cjwatson>     test_curses
[09:46] <cjwatson> infinity: No, I tried but by the time I got to pitti's PPA he'd already retried it on another host
[09:47] <doko> cjwatson, I did look at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastSuccessfulBuild/artifact/results/log
[09:47] <cjwatson> doko: The key in that URL is "lastSuccessfulBuild" :-)
[09:47] <cjwatson> doko: Like I say, Jenkins' UI tends to lead you to the wrong place
[09:47] <doko> argh
[09:47] <cjwatson> doko: You need to follow the "Last build" link
[09:47] <cjwatson> i.e. https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastBuild/
[09:47] <doko> got it
[09:48] <infinity> cjwatson: Looks like chindi05.  *disables*
[09:48] <cjwatson> infinity: Ta
[09:48] <doko> slangasek, how did you get samba uploaded? I get an error unpacking the unmodified source ...
[09:50] <seb128> JackYu, dholbach: unity-china-photo-scope accepted to saucy
[09:50] <dholbach> yeehaw!
[09:50] <seb128> ;-)
[09:52] <JackYu> seb128, wow, great!
[09:56] <pitti> infinity: I've encountered it on several, but I retried them; they worked the second time
[09:56] <infinity> pitti: Yeah, cause they hit a different host.  I had to go hunt down the broken one.
[09:56] <pitti> doko: I think that's just time zone confusion
[09:57] <pitti> pete-woods: it's not fixed in 2.7.4?
[09:57] <pitti> infinity: the builder name isn't in the log anywhere? sorry then, I'll tell you the next time it happens
[09:58] <infinity> pitti: The builder name is in the log when sbuild starts.  Which it couldn't because of this bug. :P
[09:58] <pitti> infinity: argh :)
[09:58] <infinity> pitti: Arguably, I should slap it at the top of the log too.  Would be handy.
[10:00] <cjwatson> infinity: Totally
[10:00] <cjwatson> infinity: Do we have the build URL at that stage
[10:00] <cjwatson> ?
[10:02] <pitti> seb128: so https://launchpad.net/~pitti/+archive/ppa/+packages is complete (we'll remove flphoto), I tested upgrades, and that gphoto2, gphotofs, and shotwell still work fine
[10:02] <seb128> pitti, great, do you want to give it a try as well?
[10:03] <seb128> want *me* to*
[10:03] <pitti> seb128: si tu veux, bien sûr :)
[10:03] <infinity> cjwatson: I'm not sure that we ever do, that's not something the slave needs to know.
[10:03] <seb128> pitti, ok, je le fais
[10:03] <pete-woods> pitti: nope, same problem there - the problem is that the ctor methods are auto-generated, and don't delegate to the C-based ctor methods
[10:03] <pete-woods> pitti: so they miss out on the initialisation from there
[10:03] <cjwatson> infinity: Thought not
[10:04] <pete-woods> pitti: the same problem has been worked around in the class dbusmessage
[10:04] <pitti> pete-woods: ok; probably best to discuss that with Murray (upstream), he should be online and he knows better how this is (auto)generated
[10:05] <pitti> seb128: FYI, I forgot to add a ~ppa suffix, so while the PPA has libgphoto2 - 2.5.2-0ubuntu1.1 I'll actually upload libgphoto2 - 2.5.2-0ubuntu1
[10:05] <seb128> pitti, ok
[10:06] <pitti> seb128: dist-upgrade should remove libgphoto2-2 libgphoto2-port0 and install libgphoto2-6 libgphoto2-port10
[10:08] <pitti> seb128: hm, upgrade worked fine in a schroot, but not on my desktop; investigating
[10:09] <seb128> pitti, http://paste.ubuntu.com/5932256/ for me
[10:09] <seb128> pitti, seems fine, out of the libsane-dev to be removed
[10:09] <pitti> seb128: hm, seems I missed the libsane-dev dep
[10:09] <seb128> well I don't need it but it seems buggy
[10:10] <pitti> hm, in my uploaded source it is correct
[10:10] <pitti> seb128: I wonder why it doesn't just upgrade it; might be the same problem that I'm seeing
[10:11] <pitti> seb128: probably the unversioned Breaks: is too strong and it confuses apt
[10:11] <seb128> could be
[10:11] <pitti> seb128: the libgphoto2 packaging is a mess, but I don't want to divert too far from Debian
[10:12] <seb128> pitti, also it removed libgphoto2-2-dev and didn't install libgphoto2-6-dev instead
[10:12] <seb128> is that wanted?
[10:12] <pitti> seb128: that's kind of expected; we could add a transitional package for -dev, not sure whether we should bother
[10:14] <pitti> seb128: ok, hold on for a bit, I'll try a new version
[10:14] <infinity> pitti: Does an unversioned Breaks even make sense?  It's effectively a Conflict at that point.
[10:14] <pitti> infinity: yes, but I thought Breaks: were slightly friendlier to apt as it can remove the package after the broken one gets unpacked
[10:15] <seb128> pitti, oh, I upgraded to do runtime testing ... those -dev issues seem fine to me
[10:15] <pitti> infinity: but I'll drop the breaks and just keep the Replaces:, that ought to be enough (testing now)
[10:16] <infinity> pitti: Well, if the goal is to force the other package off the system, Replaces alone won't do it, it'll just overwrite some files. :P
[10:16] <pitti> it shouldn't actually break the old library, it just overwrites some READMEs
[10:16] <pitti> infinity: yes, that's the goal
[10:16] <sil2100> doko: hi! I'd like to do a re-poke about the libboost-mpi issue we got during Mir building
[10:16] <infinity> pitti: But for overwrites, you *should* use Breaks/Replaces, to guarantee correct ordering, so files don't get lost.  But, they should be versioned.
[10:16] <sil2100> doko: could you give us some info about what could be wrong that it's not installable?
[10:17] <pitti> I installed gvfs, shotwell, and gphoto2 into a schroot and dist-upgraded to the PPA without a problem, but on my real desktop apt wants to hold back gphoto2 rather
[10:17] <infinity> pitti: Unless both packages will always ship those files, in which case, someone's doing something wrong.
[10:17] <sil2100> doko: (along with libboost-mpi-python-dev and libboost-graph-parallel-dev)
[10:17] <pitti> infinity: so that means I'll keep the old names as transitional packages and keep them empty
[10:18] <pitti> I was hoping to avoid that, but *shrug*
[10:18] <infinity> sil2100: boost-mpi/boost just got uploaded/built, were you just running into arch skew?  Which build?
[10:20] <sil2100> infinity: hi! Ok, so I'm running amd64 and I'm encountering the same issue as in the logs - so, after doing update, apt-get install libboost-all-dev cannot install libboost-graph-parallel-dev libboost-mpi-dev and libboost-mpi-python-dev - we got the same here:
[10:20] <sil2100> infinity: https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[10:20] <sil2100> infinity: so it's i386
[10:21] <sil2100> infinity: does it mean libboost-all-dev has invalid deps now?
[10:21] <sil2100> Due to the switch?
[10:22] <infinity> What "switch"?
[10:23] <pete-woods> pitti: I have managed to make a patch that will apply upstream now - do you know what room / server I will find Murray in?
[10:23] <infinity> sil2100: If you retry that build, it should be fine.
[10:24] <infinity> sil2100: At least on i386/amd64.  ppc and arm are still building the new boost.
[10:24] <pitti> pete-woods: he's "murrayc" in #gnome-hackers on irc.gnome.rog
[10:24] <pitti> pete-woods: .org
[10:24] <sil2100> infinity: hm, it will? Since I just did update and apt-get install --simulate libboost-all-dev on my system and get the same error - but maybe my mirror is outdated?
[10:24] <infinity> sil2100: I just tried it here and it was fine.  *shrug*
[10:25] <sil2100> Well, I'm using the polish mirror, so I guess it could be this
[10:25] <sil2100> Let me try a re-run
[10:26] <pitti> seb128: ok, got a clean upgrade now
[10:27] <pete-woods> pitti: thanks!
[10:27] <sil2100> didrocks: ok, so anyway we'll have to wait for armhf mir at least until boost finished building there
[10:28] <didrocks> infinity: I retried it this morning, but maybe too early?
[10:29] <didrocks> sil2100: keep me posted ;)
[10:29] <sil2100> didrocks: it's building now \o/
[10:29] <pitti> seb128: tried again with gvfs (file-like browsing), gphoto2, and shotwell, WFM
[10:29] <sil2100> didrocks: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4839926
[10:29] <sil2100> didrocks: so I'll re-try i386 as well
[10:29] <didrocks> sil2100: sweetnesssssss! :)
[10:30] <seb128> pitti, works fine for me as well
[10:30] <pitti> seb128: gvfs' GPhoto test will need an update for the new ioctls, I'll do that
[10:30] <seb128> thanks
[10:30] <cjwatson> sil2100: The builds use the hidden master archive; everything, including archive.ubuntu.com, is potentially outdated relative to that :-)
[10:30] <pitti> seb128: ok, so ready for saucy?
[10:31] <seb128> pitti, seems so! UPLOAD ;-)
[10:31] <pitti> seb128: (-proposed)
[10:31] <seb128> it's transitions' week
[10:31] <seb128> (new poppler, new libgphoto, ...)
[10:31] <sil2100> ;D
[10:31] <Laney> mmm transitions
[10:34] <slangasek> doko: that's a behavior change in patch; the new version of samba in Debian unstable is fixed
[10:36] <doko> slangasek, when you sync/merge it, could you update the config.* files too?
[10:39] <slangasek> doko: I don't expect to have time to do that merge any time soon, fwiw - so maybe it's better to file a bug
[10:39] <didrocks> sil2100: so, from the MIR for Mir standpoint, no additional package is needed? (if boost was splitted?)
[10:40] <doko> slangasek, ahh, still in NEW
[10:42] <slangasek> doko: hmm, what's in new?
[10:42] <doko> slangasek, 4. but I see there is -2 in debian. will check it ...
[10:43] <slangasek> right, I meant 3.6.16-2 only
[10:53] <sil2100> didrocks: hm, doesn't look like it, I'm looking at the diffs but I don't even see any splitting going on
[10:53] <didrocks> sil2100: ok, not sure what doko meant by "the mpi split package"
[10:54] <xnox> sil2100: didrocks: we only split the default boot version. Do you want to use a newer boost?
[10:54] <sil2100> didrocks: no idea as well, but boost 1.53.0-4ubuntu1  was released long ago an ubuntu2 and ubuntu3 only added --disable-long-double --without-context
[10:55] <didrocks> xnox: mir is using default boost and tries to install libboost-all-dev
[10:55] <didrocks> (and the -dev deps on libboost-program-options-dev)
[10:56] <xnox> didrocks: libbost-all-dev is in universe, as that depends on mpi portion. Depend on individual libboost-foo-dev that your package actually needs.
[10:56] <infinity> I'm failing to see how any of those things are problems...
[10:56] <infinity> Except for the -all-dev, yes, which no one should build-dep on.
[10:56] <sil2100> Interesting
[10:56] <didrocks> infinity: do you think what the mir-team should deps on?
[10:56] <infinity> That's like a build-dep on "lib*-dev" because you don't know what you actually use. :P
[10:56] <infinity> didrocks: I think they should build-dep on what they link with.
[10:57] <sil2100> didrocks: I guess that we need to consider talking to the mir team about that
[10:57] <didrocks> sil2100: yeah, see my pings on #ubuntu-mir ;)
[10:58] <sil2100> oh!
[10:59] <infinity> xnox: I suppose if you wanted to be nice to the lazy, you could provide a libboost-all-main-dev, but I tend to agree people should actually figure out what they need and only use that anyway.
[11:00] <didrocks> infinity: that's obvious, I would just hope I wouldn't have to be the one again figuring that out for them and being taken in hostage because of that transition
[11:00] <xnox> infinity: meh, that would diverge from debian.... plus we may or may not move some boost portions to universe even if they are build  from the main package, if nothing depends on them.....
[11:00] <didrocks> so let's try to figure that out with them
[11:01] <infinity> didrocks: There is no transition here... boost has always been split like this.
[11:01] <infinity> didrocks: The transition is that they've moved from building in universe to main. :P
[11:01] <infinity> xnox: Fair point.
[11:05] <doko> infinity, let's introduce pattern dependencies for the mir team =)
[11:10] <infinity> doko: Depends: stripes\nSuggests: polkadots\nConflicts: plaid?
[11:15] <Laney> siretart: do you have plans for libav 9 in saucy?
[11:17] <xnox> sil2100: didrocks: doko: infinity: so mir will bring in boost chrono & regex, but both of those are build from the main src-package already, so it's just binary move. https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804
[11:25] <infinity> Laney: Yeah, we're going to start the transition Very Soon.
[11:26] <infinity> xnox: Sure, binary moves are no big deal, we deal with them all the time.
[11:27] <Laney> infinity: Neat.
[11:28] <slangasek> xnox: MIRs only care about source packages, not binaries... as long as the source is in main, the binaries will be in main as long as something else in main needs them to be
[11:28] <xnox> slangasek: ok.
[11:28] <slangasek> but mpi is obviously still a problem
[11:30] <xnox> slangasek: in progress being solved https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804
[11:31] <slangasek> xnox: excellent :)
[12:13] <ev> anyone know a good example of a project using dbus-test-runner offhand? apt-cache rdepends is of no help, and I imagine build-rdepends isn't needed often enough to warrant the implementation
[12:14] <jbicha> ev: did you try  reverse-depends -b dbus-test-runner
[12:15] <ev> dammit. Thanks jbicha.
[12:18] <jbicha> ev: in whoopsie-preferences, is the "Send a report automatically for login problems" box still supposed to be insensitive?
[12:19] <ev> jbicha: yes - we haven't implemented that yet. I thought we started hiding it though?
[12:19]  * ev digs
[12:20] <jbicha> ev: when it was in a-l-m, I had to hide it "harder" https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/activity-log-manager/saucy/view/head:/debian/patches/01_really_hide_automatic_reports.patch
[12:20] <ev> jbicha: it still is in a-l-m
[12:22] <ev> whoopsie-preferences is a dbus service and library for communicating with said dbus service that controls /etc/default/whoopsie, /etc/apport/autoreport, and the whoopsie upstart job
[12:29] <xnox> slangasek: if and when you have time to review =) https://code.launchpad.net/~xnox/ubuntu/saucy/mountall/btrfs/+merge/177822
[12:34] <pete-woods> pitti: hi again, so now that bug has been fixed upstream, I've backported the patch to the version we have in saucy
[12:34] <pitti> pete-woods: nice, that was fast
[12:34] <pete-woods> pitti: should I still submit a bug / patch for that off the current version we have?
[12:34] <pitti> pete-woods: I think it'd be better to update it to 2.37.4 and apply it on top of it
[12:35] <pitti> to match our glib
[12:35] <pitti> pete-woods: so no need for you to backport
[12:35] <pitti> pete-woods: (in terms of changing the code to apply to the older version)
[12:35] <pete-woods> pitti: I don't think that it'll be 2.37.4 - looking in the git tree that has already been tagged
[12:35] <pitti> pete-woods: we still need to add the patch to the package, of course
[12:36] <pitti> pete-woods: so a bug "please update" with a pointer to the patch (gnome git) is fine
[12:36] <pitti> pete-woods: unless you want to do the update yourself, of course
[12:36] <seb128> pitti, pete-woods: I can do the glibmm update today if you want ... what's the patch to include?
[12:36] <pete-woods> pitti: oh, that's cool - I thought we'd be waiting on "full" releases
[12:36] <pitti> seb128: I guess https://git.gnome.org/browse/glibmm/commit/?id=23823fdf3a54ed3851b8
[12:37] <pete-woods> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=705199
[12:37] <pitti> pete-woods: depends on how urgent it is, but if you block on it we can cherry-pick the patch
[12:37] <robert_ancell> slangasek, bug 1206897
[12:38] <seb128> pitti, pete-woods: if I do the update I can as well include the patch with it
[12:38] <pete-woods> pitti: well, the world won't end, but it is blocking me atm :)
[12:39] <seb128> pete-woods, pitti: I'm going to backport it, no worry
[12:39] <pete-woods> seb128: that would be awesome! :)
[12:54] <slangasek> xnox: why should we special-case btrfs in mountall?  Why should we not demand that the btrfs-tools provides the standard interfaces, like fsck.btrfs?
[12:55] <slangasek> xnox: also, why is "major zero" a correct means of detecting "this is a filesystem we should skip checking"?
[12:58] <xnox> slangasek: because due to (a) intrisic features of btrfs, it does not need fsck on each mount (b) deficiencies of fsck.btrfs of not able to run on read-only mounts.
[12:59] <xnox> slangasek: i didn't find a definite explanation of what "major zero" mean and which fs have "major zero", but that's the check used now in chroot.sh (debian sysvinit) and there are references of similar used on fedora.
[12:59] <slangasek> xnox: which is to say: btrfs devs are playing silly buggers with the standard fsck interfaces and people are letting them get away with it
[13:00] <xnox> slangasek: imho, ideally i'd want all btrfs filesystems specify fs_passno 0 in fstab. But nobody seems to be doing that at the moment.
[13:01] <slangasek> right, but why wouldn't we fix *that* bug in Ubuntu?  (installer + update handling)
[13:01] <xnox> slangasek: do we ever modify /etc/fstab post install?
[13:01] <slangasek> sure
[13:02] <slangasek> we did for migration to UUID-based mounting
[13:02] <xnox> cause, I still have ntrfs-3g patch to accept obsolete aliased option name for wubi, unless that's because we can't access/modify fstab....
[13:03] <slangasek> we certainly can modify fstab
[13:03] <slangasek> it needs to be done carefully
[13:06] <slangasek> seb128, pitti: have you guys noticed that this week, lid close events are not being handled correctly?  It's a frequently-reported problem here at the sprint, that only just regressed
[13:06] <seb128> slangasek, was that the "upower hangs in libusbx code"?
[13:06] <seb128> or is that something different?
[13:06] <slangasek> I see there was a upower update, but I can't make that line up with when I started seeing the bug
[13:06] <slangasek> seb128: I don't know
[13:06] <slangasek> is there a bug report about this?
[13:07] <seb128> slangasek, I synced the libusbx fix from aurel32 this morning, would be good to see if that's still happening with the update/an upower restart
[13:07] <slangasek> upower doesn't seem to be hung for me
[13:07] <seb128> slangasek, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988
[13:07] <infinity> slangasek: My lid close was failing and then after an upgrade, stopped failing again.
[13:07] <infinity> slangasek: So, either it was fixed, or it's wildly intermittent and hard to reproduce.
[13:08] <seb128> slangasek, gdb to upowerd and "t a a bt"?
[13:09] <slangasek> seb128: upgrading libusb-1.0-0 now to check
[13:09] <seb128> slangasek, you can easily reproduce? if you are in buggy state, having the bt before killing upowerd would be useful still
[13:10] <slangasek> bah, why is update-manager broken again?
[13:10] <slangasek> seb128: sure, trivial to reproduce; I'll pastebin the gdb bt
[13:11] <slangasek> seb128: http://paste.ubuntu.com/5932741/
[13:11] <seb128> slangasek, yep, locked in libusb code
[13:11] <slangasek> why does apt-get dist-upgrade against saucy want to remove ubuntu-desktop? :P
[13:11] <slangasek> did someone force something inappropriate through proposed-migration?
[13:11] <seb128> slangasek, don't use saucy-proposed?
[13:11] <slangasek> I don't
[13:11] <seb128> hum
[13:11] <seb128> can you pastebin that as well? ;-)
[13:12] <slangasek> http://paste.ubuntu.com/5932747/
[13:12] <seb128> slangasek, your upower issue is almost for sure the one fixed by the new libusbx I synced earlier, let me know if the update works for you
[13:13] <slangasek> yes, will do
[13:13] <seb128> slangasek, https://launchpad.net/ubuntu/+source/libgphoto2
[13:13] <seb128> slangasek, apt-cache policy libgphoto2-2 ?
[13:15] <seb128> slangasek, or shotwell
[13:15] <seb128> slangasek, you are sure you don't use pitti's ppa or something?
[13:16] <seb128> slangasek, the new gphoto/gvfs/shotwell are still in proposed (and in pitti's ppa)
[13:22] <stokachu> seb128: ive got a branch going to port sosreport over to python3 but it is still a ways away
[13:24] <slangasek> seb128: so, upower was definitely hung; I had 0% battery life and didn't know it, so the laptop shut down in the middle of the upgrade ;P
[13:24] <slangasek> libgphoto2-2:
[13:24] <slangasek> libgphoto2-2:
[13:24] <slangasek>   Installed: 2.4.14-2.3ubuntu2
[13:24] <slangasek>   Candidate: 2.4.14-2.3ubuntu2
[13:24] <slangasek> seb128: ^^ that's in saucy, not in a ppa or proposed
[13:25] <seb128> slangasek, which is your pastebin listing it as "to update"?
[13:25] <seb128> slangasek, you confirmed the dist-upgrade?
[13:25] <slangasek> seb128: right, I apparently do have a ppa of pitti's enabled though
[13:25] <seb128> slangasek, having shotwell in that dist-upgrade doesn't make sense
[13:26] <slangasek> seb128: I did an apt-get upgrade instead
[13:26] <slangasek> shotwell was "to be removed"
[13:26] <seb128> slangasek, right, but shotwell-common to update
[13:26] <slangasek> well, I don't know why I have pitti's ppa enabled /anyway/, so disabled now
[13:26] <seb128> slangasek, which doesn't make sense, https://launchpad.net/distros/ubuntu/+source/shotwell ... the current version is in saucy since july 12
[13:27] <seb128> slangasek, pitti prepared the gphoto transition in his ppa, I'm pretty sure that's the issue you hit
[13:27]  * StevenK beats seb128 with the deprecated URL stick
[13:27] <seb128> slangasek, you probably had it from logind testing back then
[13:28] <seb128> StevenK, seems so, I never bothered changing my firefox alias it seems
[13:29] <StevenK> seb128: I can't see us removing it because it's mostly cheap, but still ... :-)
[13:30] <seb128> StevenK, well, I didn't notice, I just do "lpurl <source>"  in my firefox and end up on the new url through the redirect
[13:30]  * xnox seems to be back online.
[13:32] <pitti> slangasek, seb128: re; was in meeting, reading scrollback
[13:33] <pitti> slangasek: upower is almost certainly bug 1203655 which is supposed to be fixed with latest usbx
[13:33] <seb128> pitti, yeah, that was it, slangasek got a stacktrace
[13:34] <pitti> slangasek: yes, libgphoto in my PPA is slightly broken, the version I uploaded to -proposed fixes the Breaks: and the upgrade
[13:34] <pitti> seb128, slangasek: logind testing was a different PPA though
[13:35] <seb128> ok, maybe he had it for another reason
[13:36] <pitti> would anyone know why libgphoto2 doesn't appear on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
[13:36] <pitti> it should still cause some uninstallability
[13:36] <stokachu> seb128: or would it be possible to just have sosreport seeded on the cloud-image?
[13:36] <pitti> (some NBS packages)
[13:36] <Laney> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libgphoto2
[13:36] <slangasek> seb128: post-reboot, pre-upgrade, the no-action-on-lid-close problem is not reproducible for me; but I'll restart upower and watch for the problem to resurface
[13:36] <Laney> Not considered -> not on _output yet
[13:37] <pitti> Laney: ah, it's first (build+tests) -> excuses, and then installability -> output?
[13:37] <pitti> Laney: (besides, the jenkins test finished over an hour ago0
[13:37] <seb128> slangasek, great, let me know how it goes
[13:37] <pitti> Laney: I'm just anxious that it doesn't propagate now
[13:37] <Laney> something like that, yeah
[13:38] <pitti> Laney: thanks
[13:38] <seb128> stokachu, sorry, I skipped your first message in the backlog ... cloud-image: it's not my call, but as said I would prefer not other python2 users on the desktop image, since we are aiming at dropping python2 from the image
[13:38] <stokachu> seb128: ok thats cool
[13:39] <seb128> pitti, "autopkgtest for gvfs 1.17.2-0ubuntu3: RUNNING (Jenkins: public, private) " ... you better check with cjwatson/jibel if there is an issue there
[13:39] <seb128> pitti, it might be that the test hit an issue and is stucked as RUNNING on that side
[13:39] <Laney> Not sure about the path results take from jenkins back to proposed-migration
[13:39] <seb128> wouldn't be the first time
[13:39] <stokachu> seb128: the previous msg was i have a branch for python3 its just a ways away
[13:39] <Laney> it'll go to FAIL anyway, won't it? :-)
[13:39] <pitti> seb128: it's not stuck, I checked https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ and http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/
[13:40] <pitti> but maybe it just didn't hit another britney run yet
[13:40] <stokachu> does anyone know who manages the cloud-image seed?
[13:40] <pitti> anyway, for now it needs to stay in -proposed until I sort out the failing gvfs test
[13:41] <seb128> pitti, well, it seems that sometime the status doesn't go back to britney correctly, that's what I meant by "stucked"
[13:41] <seb128> pitti, e.g excuse keeps showing things are RUNNING when they are not
[13:41] <kenvandine> @pilot in
[13:41] <ogra_> stokachu, i'd guess smoser (not sure though)
[13:42] <stokachu> ogra_: ok thanks ill try him and see
[13:44] <pitti> seb128: right
[13:44] <doko> Riddell, ScottK: do you know if there are any architecture specific things in qt4-x11? and if yes, where?
[13:46] <mbiebl> slangasek: a hung upower sounds very familiar
[13:47] <xnox> slangasek: btrfs returns invalid major number (zero) since a single pair is not enough for btrfs, due to possible multiple drives/subvolumes. But yeah, sounds like a fragile interface.
[13:47] <mbiebl> I've been experiencing that quite a few times in the last weeks
[13:47] <pitti> mbiebl: yes, the libusbx one, already sorted out
[13:47] <mbiebl> pitti: ah, perfect
[13:48] <mbiebl> pitti: what was the problems (do you have a bug number?)
[13:48] <pitti> mbiebl: http://packages.qa.debian.org/libu/libusbx/news/20130730T171814Z.html
[13:48] <seb128> mbiebl, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988
[13:48] <pitti> mbiebl: bug 1203655
[13:49] <seb128> pitti, pete-woods: https://launchpad.net/ubuntu/+source/glibmm2.4/2.37.4-0ubuntu1
[13:49] <mbiebl> pitti: thanks
[13:59] <pete-woods> seb128: seriously, this is really really appreciated, thanks! :D
[14:00] <seb128> pete-woods, yw ;-)
[14:01] <seb128> shrug, build failed
[14:01] <seb128> "Gio::Resolver::lookup_by_name() threw exception: Error resolving 'www.google.com': Name or service not known"
[14:02] <pitti> in the test?
[14:02] <seb128> pitti, https://launchpadlibrarian.net/146315371/buildlog_ubuntu-saucy-i386.glibmm2.4_2.37.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:02] <seb128> pitti, yes, in the tests
[14:04] <seb128> pitti, I guess I can just drop 	giomm_tls_client/test			from check_PROGRAMS in tests/Makefile.am
[14:04] <seb128> pitti, or do you have a better suggestion?
[14:05] <pitti> seb128: no, sounds good to me; we don't have network access in buildds
[14:09] <slangasek> seb128: bug reproduced again; up-to-date libusb-1.0-0 on disk and in memory
[14:09] <seb128> :-(
[14:09] <seb128> slangasek, can you get a bt of upowerd and pastebin it?
[14:10] <Riddell> doko: there's various bits for arm in debian/rules
[14:10] <seb128> slangasek, dpkg -l | grep libusb-1.0-0
[14:10] <slangasek> http://paste.ubuntu.com/5932893/
[14:10] <Riddell> doko: and some bits for arm and powerpc in debian/control
[14:10] <slangasek> version 2:1.0.16-2
[14:11] <Riddell> doko: there's a few .asm assembler files
[14:11] <pitti> hm, that's still the same pthread_join thingy
[14:12] <seb128> slangasek, :-(
[14:12] <seb128> slangasek, you are confident you restarted upowerd with the new libusb?
[14:12] <seb128> I guess aurel32's fix isn't enough then :-(
[14:12] <slangasek> seb128: lsof | grep DEL, etc. etc
[14:12] <slangasek> (so yes, I checked)
[14:13] <seb128> slangasek, can you follow up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988 saying you still have the issue,
[14:13] <seb128> ?
[14:19] <slangasek> seb128: ok - you want it on the Debian bug, not in LP?
[14:19] <seb128> slangasek, well, you can update the lp bug as well, but it's a direct sync from Debian and nobody on our side has experience on that lib afaik
[14:19] <seb128> slangasek, aurel32 is responsive and tried to fix the issue one, we should at least let him know it's not fixed
[14:19] <seb128> once*
[14:23] <tseliot> slangasek: can you have a look at bug 1198942 when you have the time, please?
[15:14] <jdstrand> mterry: hey. fyi https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1203589/comments/7
[15:21] <mterry> jdstrand, ah, OK.  Missed that
[15:22] <jdstrand> np
[15:23] <dobey> pitti, jibel: with autopkgtest, does build-needed also result in any tests in override_dh_auto_test: in debian/rules for example, being run?
[15:35] <cjwatson> dobey: If and only if an ordinary package build would run them
[15:38] <dobey> cjwatson: is there any way a normal package build wouldn't run them (outside of failing to build before it got to that point)?
[15:40] <cjwatson> dobey: Some packages choose not to run dh_auto_test in all cases; it's within the control of debian/rules.  It would normally be fairly obvious in debian/rules if it were avoiding running tests though.
[15:40] <cjwatson> If it's just using dh in the ordinary way then it'd run them
[15:41] <xnox> dobey: if DEB_BUILD_OPTIONS=nocheck is set, then unit-tests are prevented from running.
[15:41]  * xnox is not sure if autopkgtest enables that or not.
[15:43] <cjwatson> It does not
[15:44] <pete-woods> seb128: it looks like the tls_client test tries to connect to https://www.google.com, and I'm guessing our build servers intentionally can't connect to the internet (https://launchpadlibrarian.net/146315233/buildlog_ubuntu-saucy-amd64.glibmm2.4_2.37.4-0ubuntu1_FAILEDTOBUILD.txt.gz)
[15:45] <dobey> indeed. thanks
[15:46] <slangasek> pete-woods: correct; internet access is not allowed as part of a package build
[15:47] <infinity> (Nor external DNS resolution, as one can see from that build log)
[15:47] <seb128> pete-woods, https://launchpad.net/ubuntu/+source/glibmm2.4/2.37.4-0ubuntu2
[15:47] <slangasek> tseliot: so I'm sprinting this week, it might be better to hand that off to another SRU team member
[15:47] <pete-woods> seb128: way ahead of me! :p
[15:47] <seb128> pete-woods, ;-)
[15:47] <tseliot> slangasek: oh, ok no problem
[15:59] <javierl> hello, does anyone have a link to instructions to debug netinstaller?, it stops at the repo index download with no apparent reason, using linuz/initrd.gz from precise-updates
[16:02] <cjwatson> javierl: Actually stops (with an error), or is just very slow?
[16:02] <cjwatson> javierl: There's a change going through QA at the moment to speed it up drastically ...
[16:05] <javierl> cjwatson: it could probably is slow, I've not waited more that 5 min on that stage, I abort the installation process.., however it shouldn't wait more that 5 minutes to get repos index, I wanted to boot in debug mode to see what was happening
[16:10] <cjwatson> javierl: It's probably bug 1067934.
[16:11] <cjwatson> javierl: There's a precise-proposed image linked from there.
[16:11] <javierl>  cjwatson I'm gonna try the proposed update and comment there, thanks!
[16:12] <cjwatson> javierl: There's DEBCONF_DEBUG=developer, but it's unlikely to be of any use in this case since there's no debugging emitted in the relevant code
[16:12] <cjwatson> javierl: The best debugging available here is simply to switch to tty4 (Alt-F4) and see what's at the end of the log
[16:12] <cjwatson> But you might as well just try the precise-proposed image first, rather than repeating debugging that's been done :)
[16:54] <seiflotfy_> seb128: around?
[17:02] <seb128> seiflotfy_, yes but otp...
[18:16] <doko> tkamppeter, pitti: https://launchpadlibrarian.net/146228947/buildlog_ubuntu-saucy-i386.cups-filters_1.0.34-3build1_FAILEDTOBUILD.txt.gz
[18:47] <kenvandine> @pilot out
[19:31] <tkamppeter> doko, this is already known: https://bugs.linuxfoundation.org/show_bug.cgi?id=1144
[19:32] <doko> tkamppeter, you misunderstand. this is about the cyclic b-d
[20:00] <stokachu> could I get someone to approve a series nomination for bug 1069570 for maas package
[20:00] <stokachu> also to remove the nomination for isc-dhcp
[20:05] <infinity> stokachu: Which series?
[20:06] <stokachu> infinity: so my fix only applies to the dhcp within maas, but i created nominations for both isc-dhcp and maas
[20:06] <infinity> stokachu: You don't have to nominate for saucy, it's the current devel release...
[20:06] <stokachu> infinity: oh
[20:06] <stokachu> infinity: then i guess both of them :D
[20:06] <infinity> That wasn't very clear.
[20:07] <stokachu> yea, sorry, if you could clear the saucy nominations for isc-dhcp and maas that'd be great
[20:09] <stokachu> infinity: actually, you know what, im going to mark this invalid and create a new issue for this fix
[20:09] <stokachu> so not to confuse whats already fixed in isc-dhcp
[20:09] <infinity> stokachu: *smirk*... Kay.
[20:09] <stokachu> infinity: thanks :)
[20:09]  * infinity presses some buttons just to get the nominations out of searches.
[20:09] <stokachu> infinity: haha thanks
[20:10] <infinity> stokachu: For future reference, there's 0 point in creating tasks for devel releases, since an upload to devel will close the non-targetted "master" task.
[20:11] <stokachu> infinity: ah ok, wasn't sure how that worked
[20:11] <infinity> stokachu: Furthermore, due to launchpad being a bit silly, if you target something to saucy, it defers the master task to the saucy task instead and, on new series opening, you get no t-series task.  Which sucks if you never got around to fixing it in saucy. ;)
[20:12] <infinity> stokachu: So, just say no to devel series tasks.
[20:12] <stokachu> infinity: hah i will remember to do that from now on
[20:12] <infinity> We probably should just disallow nominating to active series'.
[21:43] <Noskcaj> roaksoax, kirkland: can you link me your PyPi accounts so i can add you as owners of testdrive?
[21:46] <kirkland> Noskcaj: 'kirkland'
[21:46] <roaksoax> Noskcaj: i'll create one and let you know
[21:48] <Noskcaj> kirkland, added as owner.
[21:48] <kirkland> Noskcaj: cheers mate
[21:50] <Noskcaj> kirkland, can you add to your release script a function to update the version in setup.py?
[21:51] <kirkland> Noskcaj: sure
[21:51] <kirkland> Noskcaj: let me check, I thought I did...
[21:51] <kirkland> if [ -f setup.py ]; then
[21:51] <kirkland>         sed -i "s/version='$MAJOR.$MINOR'/version='$MAJOR.$nextminor'/" setup.py
[21:51] <kirkland> fi
[21:51] <kirkland> Noskcaj: it's in there
[21:51] <Noskcaj> kirkland, It must have broke then. I had to manually change it from 3.10 to 3.22
[21:52] <kirkland> Noskcaj: ah, right, I bet it didn't match 3.10
[21:52] <kirkland> Noskcaj: because that was too out of date;  it'll work on the next run, I bet
[21:52] <Noskcaj> ok, cool
[21:58] <stokachu> roaksoax: you around?
[22:09] <roaksoax> stokachu: not really... :-)  whats up?
[22:10] <stokachu> roaksoax: hey, was just curious when you get some time to have a look at a maas bug with a fix
[22:10] <stokachu> bug 1207102
[22:11] <roaksoax> stokachu: is this for precise?
[22:11] <stokachu> saucy
[22:12] <roaksoax> stokachu: ok can ypou assign me or subscribe me to the bug. though is this related to multiple duplicated entries of a node? or many leases for a node?
[22:12] <stokachu> roaksoax: i believe its related to duplication or the nodes not being ready when adding to dns
[22:13] <roaksoax> stokachu that was fixed on isc-dhcp side though...
[22:13] <stokachu> roaksoax: that didnt actually fix this issue
[22:14] <stokachu> something about the leases not being expired quick enough when adding multiple nods
[22:14] <stokachu> nodes*
[22:14] <roaksoax> uhmm ok. ill have a look tomorrpw cause im EOD already. Just assign it to me please :-)
[22:15] <stokachu> roaksoax: ok will do.. i have the fix attached just need it uploaded/verified
[22:16] <roaksoax> ok cool thanks!
[22:18] <Noskcaj> kirkland, one other thing, why doesn't the testdrive bzr branch or the .orig include the translations?
[22:22] <kirkland> Noskcaj: no idea -- I have always sucked at getting po and debian packages and Launchpad translations integrated
[22:22] <kirkland> Noskcaj: it would be great if y'all figure that out
[22:23] <Noskcaj> kirkland, I'll look into it when i get home from school
[23:07] <stokachu> shouldnt https://wiki.ubuntu.com/SimpleSbuild#Local_packages for chroot-setup-commands be /repo/prep.sh since its running within the chroot?
[23:08] <stokachu> barry: ^
[23:09] <barry> stokachu: what can i tell ya.  if it ain't broke, don't fix it. ;)
[23:09] <stokachu> barry: it breaks for me
[23:09] <stokachu> :)
[23:10] <cjwatson> barry: It might happen to work for you because your schroot profile bind-mounts your home directory
[23:10] <barry> stokachu: oh!  well, tbh, i don't think i've done local packages since at least raring.  it's possible that something's changed since then
[23:10] <barry> cjwatson: yep, that's it
[23:10] <cjwatson> But that isn't guaranteed and isn't true for all profiles
[23:11] <cjwatson> So I'd agree with stokachu's suggested change if it tests out
[23:11] <barry> stokachu: cjwatson is right, i'm sure.  it's a wiki - fix it! :)
[23:11] <stokachu> so after i added the line to sbuild/fstab i had to change the chroot-setup-commands to use /repo/prep.sh
[23:11] <stokachu> barry: i just wanted to make sure im not crazy before editing it
[23:11] <barry> stokachu: no time to test it here, but cjwatson's comment makes sense.  if it works for you, go for it
[23:12] <cjwatson> chroot-setup-commands is indeed executed chrooted, so I think it makes sense to use guaranteed-to-be-inside-chroot paths
[23:12] <stokachu> ok cool ill update the wiki cjwatson/barry
[23:13] <barry> stokachu, cjwatson thanks.  i've made the change locally so i'll double check the next time i do a build
[23:13] <stokachu> barry: sounds good man, thanks!