=== AuroraBorealis is now known as aurora|sleep
[05:38] <jam> vila: no issues building the installers, I just haven't tried yet
[05:43] <vila> jam: do you plan to try soon or should I announce 2.4.0 without them ?
[06:32] <vila> hi all !
[06:34] <vila> poolie: regarding HTTPErrors on jubany, here is an interesting one: http://paste.ubuntu.com/677730
[06:34] <poolie> hi vila, jam
[06:35] <poolie> hi vila
[06:35] <jam> hi poolie
[06:36] <jam> so... interesting news about fdatasync
[06:36] <vila> poolie: hey
[06:36] <poolie> i think i know what's happening there, which is that it's getting None for one of the branches so lp rejects the attempt to file an mp
[06:36] <jam> test suite w/fdatasync 3h35min, hacking it out, 1h35min
[06:36] <jam> still not as fast as bzr-2.3's 45min
[06:36] <poolie> locally? or on pqm?
[06:36] <jam> poolie: on pqm
[06:36] <jam> so there is more going on than just fdatasync
[06:36] <poolie> that's about what i would expect
[06:36] <poolie> right
[06:36] <jam> but it is clearly part of it
[06:36] <poolie> i wonder if it's failing to load some extensions?
[06:37] <jam> poolie: doesn't that issue warnings, and we use -Werror ?
[06:38] <poolie> it's just kind of a shot in the dark about what could cause such a large slowdown
[06:38] <poolie> do we know anything about the relative timing of particular tests?
[06:38] <jam> poolie: yeah, the difference w/ 2.3 was where I was going to focus
[06:38] <jam> poolie: we could do a failing pqm run that doesn't filter out successes, and we would get back a subunit stream containing all the timings
[06:42] <jam> 2.4 has a few more tests, 26.3k vs 24.7k than 2.3
[06:42] <jam> I doubt that accounts for doubling the time, though
[06:44] <jam> poolie: I'll try to find another quiescent time for PQM and put another couple of test runs through
[06:44] <poolie> you can also just ask the sysadmins to run something on that box
[06:45] <poolie> i saw Sidnei wrote about having a tarmac-on-openstack set up for tarmac so i might try to convert that some time
[06:45] <poolie> vila, that bug you mentioned with httperror i was going to keep tracking under the same number
[06:45] <poolie> i fixed some of them but that's still a problem
[06:46] <poolie> it's related to the Branch.getByURL call (that might not be the exact name)
[06:48] <vila> poolie: not a bug, just something I caught while monitoring jubany after deploying bzr-builddeb yesterday
[06:48] <poolie> it is a bug
[06:48] <vila> right
[06:49] <vila> what I mean is that I've seen different outputs usually, this one was mentioning something different (the missing branch)
[06:51] <vila> ... and I didn't file a new bug before mentioning it to you, should I ?
[06:52] <vila> so s/not a bug/not *yet* a bug/
[06:59] <vila> jam: do you plan to try building the windows installers soon or should I announce 2.4.0 without them ?
[06:59] <jam> vila: I'm working on them as we chat
[07:00] <vila> jam: great, waiting for your feedback to do the announcement
[07:00] <jam> anyone know if qbzr-0.21 is still the right version to build with?
[07:02] <jam> there seems to be an 0.21.1, I'll go with that
[07:02] <jam> though I think there was supposed to be a 0.21.2 coming soon
[07:25] <vila> maxb: do you plan to upload bzr-svn-1.1.0 to the stable ppa ?
[07:49] <poolie> are you ready to mumble?
[07:50] <fullermd> Speaking of qbzr, is it just me or does it still completely hork the test suite on .dev?
[07:51] <fullermd> ...  and of course, it figures I say that right before firing off a pull that gets the rev that fixes it...
[07:51] <jam> poolie: I believe that has to be spelled "muuuummmbbbbbbbbllllllee" ?
[07:51]  * fullermd sighs.
[07:53] <jam> poolie: http://www.youtube.com/watch?v=WvufFwdqMzg&feature=player_detailpage#t=53s
[07:53] <jam> but yes, I'm logged in
[07:54] <poolie> yep
[07:54] <jam> Or maybe "LETS GET READY TO *mumble*"
[07:59] <jam> vila: it says it will be 20min for it to copy down to me, and then 5-10 min for me to upload them to launchpad
[07:59] <jam> but -1 is built
[08:42] <jam> vila: windows installers have been uploaded and announced
[08:43] <vila> jam: thanks
[08:45] <poolie> Riddell, so can people actually get into translating bzr now?
[08:46] <poolie> i thought perhaps you should send an update on the state of i18n - perhaps it's better to wait until it's live though
[08:54] <Riddell> you go to https://translations.launchpad.net/bzr and do the translation
[08:55] <Riddell> it's set to restricted so you have to be an approved translator
[08:55] <Riddell> I can e-mail the translators list and bazaar list to announce that
[08:56] <jam> poolie: https://code.launchpad.net/~hid-iwata/bzr/fix-827721/+merge/73125 I don't know if you saw that I already made the fix, but accidentally submitted it to trunk instead of 2.4
[08:56] <jam> I'm guessing you did the same fix?
[08:56] <poolie> i saw a comment about that
[08:56] <poolie> i sent just a correction of his patch to 2.4
[08:56] <poolie> did you fix it in a substantially different way?
[09:06] <jam> poolie: I just indented by 1 space
[09:07] <poolie> that's what i did too
[09:07] <poolie> it's running on jubany now
[09:07] <poolie> *bellany
[09:13] <jam> poolie: well, jubany does have better hardware, maybe we could install PQM and.... :)
[09:17] <jelmer> jam: I'm looking at my bzr/move-hashcache branch; is it correct that just WT2 and WT3 use the hashcache?
[09:18] <jam> yes
[09:18] <jam> the cache is in the Dirstate for WT4+
[09:28] <poolie> ok i'm going to sign off
[09:29] <poolie> vila, if you commit that fix to trunk it should automatically get onto docs.b.c.c
[09:29] <vila> poolie: yup, I know, submitting to pqm
[09:30] <vila> poolie: grepping 2\.4 I found some references to python-2.4 that we don't support anymore, I'll file a bug for that as several docs needs a deeper fix
[09:30] <jam> jelmer: rather than resubmit, I think just marking your submission back to NeedsReview
[09:30] <jam> at least for me, it means that email threads get put on the right submission, etc.
[09:30] <jam> like I *just* commented on the last one
[09:30] <jelmer> ah, hmm
[09:30] <jelmer> with some projects I find that reviewers ignore MPs that already have votes on them
[09:31] <jam> jelmer: well, I just ignore everything you submit regardless :)
[09:32] <fullermd> jam: Ignore who?  ;p
[09:32] <jam> jelmer: I supposed it is project dependent. I do a lot of processing merge requests via email vs the web ui
[09:32] <jam> and often keep "unread" things that are in queue to reviewe
[09:32] <jam> unfortunately, LP does *not* link emails across resubmissions
[09:33] <jam> so it starts a new email thread
[09:33] <jam> and doesn't have a "this proposal has been superseded" email
[09:33] <jam> in this particular case, it looks like we raced
[09:33] <jam> where I was in the web app commenting, and you were resubmitting.
[09:34] <jelmer> jam: Clearly the workflow isn't optimal yet :) I'm happy to just change the MP status for bzr though
[09:35] <jam> for bzr, I would probably resubmit if there has been a long discussion that is now only partly relevant due to large changes
[09:36] <vila> jam: additionally when you review via mail CC'ing the submitter, the submitter gets two mails, one of them without the lp links and headers which also break threading
[09:36] <jelmer> jam: also, we don't always change the MP status when we vote so there's no way to indicate a MP is ready for another review
[09:37] <jelmer> e.g. https://code.launchpad.net/~jelmer/bzr/move-hashcache/+merge/73299
[09:37] <jam> sure, but you can also just *say* "ready for re-review"
[09:37] <vila> jelmer: you can request an additional review from the web ui, which should send emails
[09:38] <vila> jelmer: I did that yesterday for https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/72451 and got an email with the updated diff AFAICS
[09:38] <jam> vila: yeah, but then jelmer resubmitted it as well :)
[09:38] <jelmer> jam, vila: neither of those makes it easy to see what needs another review on the +activereviews page
[09:39] <vila> jelmer: true :-/
[09:39] <jelmer> anyway, I wasn't trying to be a pedant..
[09:39] <jam> jelmer: *everything* needs review if it is still on that page
[09:39] <jam> that page should always be pushed to 0
[09:39] <jam> IMO
[09:39] <jam> though yes, some with more or less priority
[09:39] <jam> which isn't particularly easy to see
[09:39] <jam> though, even when used "correctly" it isn't very easy to see
[09:39] <vila> jelmer: I don't think you were
[10:14] <jelmer> vila: several of the recent problems building against 2.4 seem fail because of the safety net
[10:14] <jelmer> grmbl
[10:14] <jelmer> vila: several of the recent problems building against 2.4 seem be because of the safety net
[10:14] <jelmer> vila: e.g. https://launchpadlibrarian.net/78535248/buildlog_ubuntu-oneiric-i386.trac-bzr_0.4.2%2Bbzr117~ppa34~oneiric1_FAILEDTOBUILD.txt.gz
[10:15] <jelmer> do you have any idea what might be causing that? It seems to be some weird interaction with fakeroot (which LD_PRELOADs and pretends the currents uid is 0)
[10:16] <vila> jelmer: failing to call setUp for the parent class ?
[10:16] <jelmer> it succeeds when not run under nosetests
[10:17] <jelmer> argh, when not run under fakeroot
[10:17] <jelmer> and as far as I can tell setUp() gets called where necessary
[10:18] <vila> hmm, doesn't explain the attributeerror...
[10:18] <vila> _SAFETY_NET_PRISTINE_DIRSTATE was introduced recently, let me check
[10:19] <vila> created in _check_safety_net, called by _make_test_root
[10:20] <vila> there is a comment there about tricky test dir on OSX,
[10:20] <vila> the issue there was that /tmp is redirected to /private/tmp
[10:21] <vila> jelmer: could it be that fakeroot is doing some trick too about /tmp ?
[10:21] <vila> not that it would explain the AttributeError either...
[10:21] <jelmer> vila: well, it pretends the owner of all files is root.root, for /tmp too.
[10:22] <vila> brain dumping,
[10:23] <vila> we had issues related to tests run as root, we had issues related to a very early failure with the test root not being properly created or something
[10:24] <jelmer> fwiw the debian packages have always been using fakeroot, but this issue has only come up recently
[10:25] <vila> jelmer: recently << 2011-07-11 ?
[10:25] <jelmer> vila: I'm also surprised it's trying to access /root/.bazaar/locations.conf
[10:26] <vila> jelmer: $HOME == /root ?
[10:26] <jelmer> vila: nope, HOME=/home/jelmer
[10:26] <vila> wow, test isolation
[10:26] <jelmer> although getpwuid(0).pwd_home is /root
[10:27] <vila> HOME is not set I presume, fallback to python whatever
[10:27] <jelmer> in fact, it seems that if I change the home directory of root in /etc/passwd the tests all pass..
[10:27] <vila> yup, python is getting there to get the home if nothing else is available
[10:28] <jelmer> so the _SAFETY_NET_PRISTINE_DIRSTATE issue is a red herring
[10:28] <vila> known issue
[10:28] <vila> not sure they are related
[10:30] <jelmer> vila: it looks like it's now reading the config because it wants to know if it should fdatasync, perhaps it wasn't doing that previously
[10:30] <jelmer> vila: is the safety net perhaps created before BZR_HOME is overridden?
[10:30] <vila> for the config stuff, yes, it wasn't and it's related to finding HOME from /etc/passwd and is a test isolation issue
[10:30] <jelmer> because creating the safety net involves creating a tree, and that involves reading the config
[10:30] <vila> yup
[10:31] <vila> oh, and some exception is lost ?
[10:31] <vila> so we miss the safety net not being created ?
[10:33] <jelmer> vila: if creating the safety net fails then the exception is masked by the fact that the teardown fails, because we haven't set _SAFETY_NET_PRISTINE_DIRSTATE yet at that point
[10:33] <vila> urgh, http://paste.ubuntu.com/677867 , indeed the safety net is created before overriding the env for tests
[10:37] <vila> jelmer: in the short term, can you try a way to run selftest in a context where bzr *can* read its config files ?
[10:38] <vila> s/try/find/
[10:38] <vila> jelmer: like... BZR_HOME=<valid home> may be ?
[10:39] <vila> jelmer: valid here doesn't imply there is a .bazaar dir, just that we get File not found instead of permission denied
[10:41] <vila> alternatively we should catch permission denied and handle it as meaning we can't read the config files
[10:42] <jelmer> vila: overriding the environment variables doesn't seem to work :(
[10:43] <vila> may be fakeroot filters it ?
[10:44] <jelmer> vila: nope
[10:45] <vila> jelmer: hmm, does os.path.isfile(infile) raises permission denied ?
[10:45] <vila> s/s//
[10:46] <jelmer> it returns False
[10:46] <jelmer> vila: still, that seems like the wrong thing to do. We shouldn't be reading the users' config
[10:46] <vila> jelmer: configobj uses this to decide if the file exists
[10:46] <vila> jelmer: why ?
[10:47] <vila> jelmer: we're not *in* the test at this point, we are still in the user context setting up the test environment
[10:47] <jelmer> vila: this is for the test setup, we shouldn't be using the users preferences for the repository we're going to use for testing
[10:47] <vila> jelmer: we obey TMP
[10:48] <vila> which is part of the user env
[10:48] <jelmer> vila: sure, but this means you could get varying test results based on what the user has in ~/.bazaar/bazaar.conf
[10:48] <vila> no, because we take care of that just after
[10:48] <vila> but I think I've found the hole
[10:48] <vila> TestCase.setUp has been called and there we clear BZR_HOME
[10:50] <vila> jelmer: try moving _make_test_root *before* the upcall to setUp() ? (May not be enough)
[10:51] <jelmer> AttributeError: 'TestRepository' object has no attribute '_bzr_selftest_roots'
[10:52] <jelmer> vila: where do we reset the standalone working tree so it isn't affected by the users settings?
[10:52] <vila> I don't follow
[10:53] <vila> the safety net is supposed to be created... above the test dirs
[10:54] <vila> the tests have no idea it exists
[10:54] <jelmer> vila: ah, nevermind.. I see we just use bzrdir.BzrDir.create_standalone_workingtree() to get at the dirstate bytes
[10:54] <vila> jelmer: try commenting out the calls to _create_safety_net and _check_safety_net
[10:54] <jelmer> vila: that does mean we try to read ~/.bazaar/bazaar.conf for every test though, doesn't it?
[10:55] <vila> yes, that's the main issue related to config in the fdatasync patch
[10:56] <jam> vila, jelmer: We only create the safety net once per test suite run, right?
[10:56] <jelmer> does remembering the raw bytes of the dirstate file really gain us all that much speed?
[10:56] <jam> we just check it on every test
[10:56] <jam> jelmer: spiv commented it was about 15% of the run speed for the whole test suite
[10:56] <jam> so... yes
[10:57] <jelmer> jam: yeah, I guess I'm just seeing it being executed multiple times because its setup fails
[10:57] <jam> jelmer: the point of that code was we *used* to have a real problem with a test case not isolating itself from the environment
[10:57] <jam> hence you can do "bzr log -r revid:A"
[10:57] <jam> in bzr.dev
[10:58] <jam> It honestly hasn't been a problem for a while, but perhaps that is because it gets caught easily. I would venture it is because TestCaseInTempDir/MemoryTransport et al make it easy to just inherit a base that is env safe
[10:58] <jam> I think vila already submitted a bug that if _create_safety_net fails, it should just abort the test suite
[10:58] <jam> rather than fail 20k times
[10:59] <vila> https://bugs.launchpad.net/bzr/+bug/825027
[10:59] <ubot5> Ubuntu bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed]
[10:59] <jam> vila, jelmer, Riddell: I'd like to do some more PQM timing runs, but I want to make sure not to block anything. Is there a reasonable time for me to do it?
[10:59] <vila> jam: thanks !
[11:00] <vila> jelmer: doh, but you *did* comment on this one !
[11:00] <spiv> jam, jelmer: IIRC by reading the raw bytes we skipped open_workingtree and that in turn skipped reading all bazaar.conf and locations.conf
[11:01] <vila> spiv: right, but the issue here is when *creating* the wt
[11:01] <jelmer> jam: as long as you don't approve any MPs you should be good ;)
[11:01] <jam> jelmer: k, I'll make sure to reject all patches. :)
[11:01] <jam> jelmer: it is more "is there stuff you want to see land soon that hasn't been approved so I'll wait"
[11:01] <vila> jam: fine with me, I'm finishing the announcement for 2.4
[11:01] <spiv> (Because it is the safety net, not some wt inside it, that means reading the users real ~/.bazaar/locations.conf, etc)
[11:01] <jam> we already have a Q depth of 4
[11:02] <jelmer> jam: I figured :) Nothing from me.
[11:02] <jam> hi spiv! good to see you around, btw
[11:03] <jam> jelmer: is it "_create_safety_net" or "_check_safety_net" that is cousing problems for bzr-cia?
[11:03] <vila> jam: i.e. nothing urgent from me, the one waiting can even be canceled (but let me know as it was a pqm-submit one)
[11:04] <spiv> jam: thanks :)
[11:04] <jam> vila: I have a strong suspicion that our current Q is going to overflow for at least today.
[11:04] <vila> jam, jelmer: I suspect it's create_safety_net and the exception is caught
[11:04] <jam> 4*2.5 is already 10 hours
[11:04] <spiv> jam: If the Q overflows, I guess that makes it an R
[11:04] <jam> spiv: I'm pretty sure it becomes QQ
[11:05] <vila> jam: yeah, debugging a live pqm is not fun
[11:05] <vila> jam: which is why I postponed it :)
[11:05] <jam> spiv: from: http://www.urbandictionary.com/define.php?term=less%20qq%20more%20pew%20pew
[11:05] <spiv> jam: two Qs?  Too cute :P
[11:05] <jelmer> vila,jam: it's _create_safety_net (but that gets called by _check_safety_net)
[11:05] <jam> spiv: It symbolizes tears coming out of eyes
[11:06] <vila> jelmer: I don't think we reach that call
[11:06] <jam> vila: we do if it is failing
[11:06] <vila> jam: we get an AttributeError on _SAFETY_NET_PRISTINE_DIRSTATE so we don't reach it
[11:07] <jam> ah
[11:07] <jelmer> yeah, that's true
[11:07] <jelmer> because _create_safety_net raised an exception
[11:07]  * jelmer 's head spins
[11:07] <vila> jelmer: try commenting out create/check safety_net
[11:07] <vila> calls
[11:09] <vila> safety net and permit_url kind of overlap in both their implementations and intents, in your case, if you don't get failures with safety net outside of fakeroot, then it's probably safe to disable it
[11:09] <jelmer> yeah, that's fine (apart from a test isolation error because BzrDir browses up too far in the fs)
[11:09] <spiv> jam: QQ makes me think of pearl tea (http://en.wikipedia.org/wiki/Bubble_tea), there's a tea place I used to go to that lists the tapioca balls on the menu as QQ.
[11:09] <vila> "browses up too far in the fs" is a hard one
[11:10] <jelmer> vila: could we just temporarily monkey patch config_dir in _create_safety_net ?
[11:10] <jam> jelmer: http://paste.ubuntu.com/677891/
[11:10] <vila> pfew, to which value ?
[11:11] <vila> jam: that would make the test suite fails for jelmer, he is trying to get a successful run (or it could just not run it all otherwise)
[11:11] <vila> s/it could/he could/
[11:11] <jam> vila: well fix #1, if we can't set up, stop running the rest of the tests
[11:11] <jam> fix #2, make it so we can run
[11:12] <jelmer> jam: thanks, that would at least make it fail sensibly
[11:12] <vila> jam: right, that's what bug #825027 is about
[11:12] <ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed] https://launchpad.net/bugs/825027
[11:12] <jam> jelmer: I think there should be a better way, integrating it with our test suite runner, etc.
[11:12] <jelmer> vila: set BZR_HOME to e.g. TestCaseWithMemoryTransport.TEST_ROOT while we run create_standalone_workingtree
[11:13] <jelmer> vila: we don't care if that location doesn't exist
[11:13] <vila> jelmer: yup, should work
[11:13] <jam> jelmer: can you paste the actual traceback somewhere?
[11:16] <jelmer> jam: http://pastebin.ubuntu.com/677896/
[11:16] <jelmer> that's with a slight change to _check_safety_net to use getattr to get at _SAFETY_NET_PRISTINE_DIRSTATE
[11:16] <jam> jelmer: well, I would say that if config gets PermissionDenied, it should just accept it and treat it as though the file doesn't exist
[11:17] <jam> jelmer: by the time we get to _check* we should always have _SAFETY_NET set
[11:17]  * jelmer looks at vila
[11:17] <vila> <vila> alternatively we should catch permission denied and handle it as meaning we can't read the config files
[11:17] <jelmer> jam: Perhaps we should just warn ?
[11:17] <jam> jelmer: looking at the traceback you posted, it is clearly during "_make_test_root" not during "_check_safety_net"
[11:17] <jelmer> that works for me I guess
[11:18] <jam> jelmer: I could consider warning.
[11:18] <jelmer> jam: If I don't make that slight change to _check_safety_net then I get an attributeerror from _check_safety_net.
[11:18] <jam> jelmer: I'm thinking you're getting that after the previous failure, during tear-down time
[11:18] <jelmer> jam: yes, I am
[11:18] <jam> so setUp() fails, then we always run tearDown() and *it* fails
[11:19] <jelmer> jam: that attributeerror is a red herring, but that's why I mentioned _check_safety_net in that bug report
[11:19] <jam> sure
[11:19] <jelmer> cool
[11:34] <jam> jelmer: is bug #835183 actually fixeD?
[11:34] <ubot5> Launchpad bug 835183 in Bazaar "bzr-svn 1.1.0 from daily PPA does not install with bzr 2.5.0 from same repository" [Undecided,New] https://launchpad.net/bugs/835183
[11:34] <jelmer> jam: not yet - the right packages are available from the daily PPA but not from the regular PPA
[11:34] <jam> jelmer: the bug at least claims to be the daily
[11:35] <jam> "bzr-svn from bzr-daily repo doesn't install with bzr  from the same repo"
[11:35] <jelmer> jam: in that case it might be a different one than I was thinking about
[11:35] <jam> which is why I'm confused that you saying "use the daily repo" and he claimed it was fixed
[11:36] <jelmer> jam: marked fixed, thanks for the pointer
[11:41] <jelmer> vila: https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361
[11:57] <vila> jelmer: cough, configobj based configs doesn't have the issue and TransportConfig is not involved either in your case
[12:01] <vila> jelmer: the bug is that configobj uses os.path.isfile and doesn't see the permission denied while config.IniFileStore traps only NoSuchFile and should also catch permission denied
[12:08] <jelmer> vila: updated
[12:08] <jelmer> (and confirmed working against tracbzr)
[12:09] <grumbel> I have here a bzr repository (based on a svn repo) with some user created changes, I (the one with write access to the SVN) want to merge those changes back into the main svn repository. How would I do that?
[12:09] <jelmer> grumbel: if you have a checkout, it should just be a matter of running "bzr commit"
[12:10] <jelmer> grumbel: if you have a standalone branch that's derived from the svn branch, commit and push back
[12:19] <grumbel> jelmer: confusing part for me right now is that the bzr repository (not mine) is against anon-svn, while I would need to commit to the non-anon svn, which has a different URL
[12:20] <jelmer> grumbel: if the bzr branch is standalone it should just be a matter of pushing
[12:20] <jelmer> and specifying the non-anon URL to "bzr push"
[12:44] <vila> jelmer: BB:tweak, can you check that my tweak still works for tracbzr ?
[12:45] <vila> jelmer: finally, don't we want that for 2.4 ?
=== med_out is now known as medberry
[12:55] <jelmer> vila: either works for me; I'll have to ship it as a Debian patch anyway. I'm not sure if it's big enough of an issue for other users.
[12:56] <vila> jelmer: wfm
[12:57] <vila> jelmer: and sorry for the trouble, I should have thought about bug #825027 earlier :-/
[12:57] <ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed] https://launchpad.net/bugs/825027
[12:58] <jelmer> vila: thanks for the review, I'll submit to PQM after John is done
[13:04] <jelmer> vila: no worries, it's pretty hard to recognize what it breaks without knowing the exact cause
[13:05] <vila> jelmer: where is fakeroot used in the whole bzr ecosystem ?
[13:06] <jelmer> vila: it's used by pretty much all debian packages when building
[13:06] <vila> jelmer: including ubuntu packages you mean ?
[13:06] <jelmer> vila: yep
[13:07] <vila> weird that we didn't encountered sooner...
[13:08] <jelmer> vila: it only happens if there actually is a /root directory - on most build hosts there isn't
[13:08] <vila> oh my...
[13:08] <vila> jelmer: and 'fakeroot -u' is not applicable ?
[13:09] <jelmer> nope
[13:09] <jelmer> vila: the idea is that when installing binaries they don't end up being owned by some random uid
[13:09] <vila> ok
[13:12] <vila> it's still weird to pretend to be root while not allowing to read config files though, but well, I can't see how to fix that anyway
[13:15] <vila> jelmer: ha, no, you mentioned the right fix earlier I think: force BZR_HOME to an existing place while creating the safety net, I'll add that to the brittle safety net bug
[13:25] <jelmer> vila: thanks!
[13:33] <jelmer> Speaking of weird FTBFS errors..
[13:33] <jelmer>   File "/usr/lib/python2.7/dist-packages/bzrlib/osutils.py", line 822, in compact_date
[13:33] <jelmer>     return time.strftime('%Y%m%d%H%M%S', time.gmtime(when))
[13:33] <jelmer> ValueError: timestamp out of range for platform time_t
[13:34] <vila> 8-(
[13:34] <jelmer> my thoughts exactly
[13:34] <jam> jelmer: clearly 'when' is negative?
[13:34] <jam> or a BIGINT
[13:34] <jam> I wonder if you need (time.gmtime(int(when))) or something
[13:35] <jelmer> jam: yeah, it's probably something like that
[13:35] <jam> the fact that it says out-of-range seems very strange
[13:36] <jelmer> it's also something that only occurs on the buildds
[13:36] <jelmer> anyway, I'll dig deeper
[13:37] <jelmer> it just seems like *somebody* forgot to tell me that today is weird FTBFS day.
[13:37] <jam> jelmer: didn't they just do an oneiric "rebuild" which causes everything to break?
[13:38] <jelmer> jam: yeah, but usually that just results in one or two plugin packages that happen to still call a method that has been removed from bzrlib
[13:38] <jam> jelmer: https://code.launchpad.net/~jelmer/bzr/move-hashcache/+merge/73299
[13:39] <jam> appears to be duplicating _write_hashcache_if_dirty
[13:39] <vila> jelmer: today is weird FTBFS day.
[13:39] <jam> anyway, not to distract you from what you're up to
[13:40] <jelmer> jam: it is - rather than using hashcache in the base class it makes WT2 and WT3 use it explicitly
[13:40] <jelmer> I could've made that clearer in the comments.
[13:41]  * jelmer adds a comment
[13:45] <jam> jelmer: is it possible to unify them, such as by just having a non-class attribute, or an extra base class. It is a real pain to track down and fix a bug in duplicated code.
[13:46] <jam> like NonDirstateWorkingTree or something
[13:46] <jelmer> jam: yeah, it's always a tradeoff I guess. I'd be happy to add a base class
[13:47] <jam> jelmer: I know it is old code that doesn't get touched much, but that's also why I'd like to not make it harder to support
[13:50] <vila> jam: that's what I was trying to convey when I asked you that follow-up about get_parent_map :)
[13:50] <jam> vila: except in my case there isn't code duplication, which is what I told you
[13:50] <jam> it isn't copy and paste code, it is take data from a different format and extract it for the api
[13:51] <vila> doesn't make the maintenance easier
[13:51] <jam> It is a "give me data" interface, but there isn't a simple corresponding "insert data" interface
[13:52] <vila> that's true
[13:53] <vila> but that can be addressed for the tests
[13:55] <vila> jelmer: do you have an easy way to test the build failure (without your patch for permission denied) ?
[13:55] <jelmer> vila: yeah
[13:56] <vila> jelmer: http://paste.ubuntu.com/677992/
[14:00] <vila> jelmer: bah, waitasec
[14:00] <jelmer> NoSuchFile: No such file: u'/tmp/testbzr-BmUC0T.tmp/.bzr/checkout/dirstate': [Errno 2] No such file or directory: u'/tmp/testbzr-BmUC0T.tmp/.bzr/checkout/dirstate'
[14:01] <vila> jelmer: http://paste.ubuntu.com/677995/ the previous one was blatently bogus
[14:01] <vila> or did you fix it yourself ?
[14:02] <jelmer> vila: "1". Really?
[14:02] <vila> for os.exit ? you prefer -1 ?
[14:03] <jelmer> vila: see that pastebin :)
[14:03] <vila> LOL
[14:03] <vila> pastebinit epic failure :)
[14:03] <vila> jelmer: http://paste.ubuntu.com/677998
[14:06] <jelmer> vila: that works
[14:07] <vila> ha, gooood, now, can I add tests for that...
[14:08] <vila> jelmer: just checking by "works" you mean the test pass not that we abort at the first one right ?
[14:15] <jelmer> vila: yep
=== aurora|sleep is now known as aurora|school
[15:04] <vila> jelmer: speaking of weird cases, something happens in a try: tree.lock_write() /finally: tree.unlock() that leaves a broken lock, what can 'something' be ?
[15:09] <vila> jelmer: some failed imports can't be requeued without breaking these locks manually which is.. disruptive ;)
[15:09] <jelmer> vila: hmm, not sure either :/
[15:10] <vila> an unmatched lock/unlock ?
[15:10] <vila> unlikely
[15:11] <jelmer> could be, I guess
[15:11] <vila> and we get a traceback... so the finally clause should be obeyed...
=== deryck is now known as deryck[lunch]
[16:30] <lamalex> hi, so bzr status only showed 2 unknown files, so i can bzr add. and it added a fucking ton of other files. is there a sane way to remove them without losing all of the changes i had in my tree?
[16:34] <LeoNerd> bzr rm --keep path/to/file   will forget an 'add'
=== Meths_ is now known as Meths
[16:45] <jelmer> lamalex: what kind of files did it add that "bzr status" didn't show?
[16:46] <lamalex> jelmer, build files
[16:46] <lamalex> can i bzr ignore build/ and have it disregard the add?
[16:47] <lamalex> ha oh LeoNerd bzr rm --keep worked great
[16:47] <jelmer> lamalex: yes, "bzr add" (without arguments) will ignore files that are in .bzrignore
[16:47] <jelmer> lamalex: if you explicitly specify files it will add them regardless of whether they are in .bzrignore
[16:48] <lamalex> yah
[16:48] <lamalex> thanks
=== kedare is now known as kedare_work
=== deryck[lunch] is now known as deryck
[17:11] <lamalex> does anyone know of a good tutorial on bzr pipelines and bzr colo
[17:11] <lamalex> i keep finding myself in space where i think i would really benefit from the workflow
[17:11] <lamalex> but i can't find good docs about really how people use it
[17:12] <lamalex> thumper, ^ don't you use these things?
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
[19:16] <AuroraBorealis> is launchpadlibrarian slow as hell to anyone?
[19:16] <AuroraBorealis> im downloading at 2 kb/s
[19:24] <Quintasan> jelmer: http://paste.kde.org/116311 <-- any idea about that? recipe file: http://paste.kde.org/116317
=== zyga is now known as zyga-food
=== CardinalFang_ is now known as CardinalFang
[20:26] <thumper> lamalex: yes, I use pipelines
=== nyuszika7h` is now known as nyuszika7h
=== zyga-food is now known as zyga
[21:54] <jelmer> Quintasan: sorry, was out. I'll have a look now
[22:17] <Quintasan> jelmer: Thanks
[22:21] <jelmer> Quintasan: can you run this: python -c 'from bzrlib.plugins.builder.cmds import get_maintainer; print get_maintainer()'
[22:21] <Quintasan> ('Micha\xc5\x82 Zaj\xc4\x85c', 'quintasan@kubuntu.org')
[22:22] <jelmer> Quintasan: bzr-builder needs to be calling .decode on that since python-debian (now?) uses unicode for changelogs
[22:22] <jelmer> Quintasan: can you file a bug?
[22:24] <Quintasan> jelmer: against bzr?
[22:24] <jelmer> Quintasan: against bzr-builder
[22:28] <Quintasan> jelmer: https://bugs.launchpad.net/bzr-builder/+bug/837741
[22:28] <ubot5> Ubuntu bug 837741 in bzr-builder "bzr-builder has to call .decode on get_maintainer() output" [Undecided,New]
[22:28] <jelmer> Quintasan: thanks
[22:28]  * jelmer wished he could triage bugs from IRC
[22:29] <jelmer> Quintasan: setting DEBFULLNAME to something that only includes ascii characters should work around it for hte moment
=== medberry is now known as med_out
=== aurora|school is now known as AuroraBorealis
[23:53] <poolie> hi all