[00:02] <spiv> Good morning.
[00:02] <jelmer> hi spiv
[00:40] <poolie> hi spiv
[06:47] <thomi> poolie: you mentioned yesterday something about a config file related bug? Do you have a bug report I can take a look at?
[06:49] <thomi> I just proposed a merge that applies the patch from bug #250296 and fixes the unit tests for the new message text.
[07:05] <poolie> thanks thomi
[07:05] <poolie> let's see
[07:06] <thomi> poolie: BTW, I notice you've worked on loggerhead as well. Is there an IRC channel for that? #loggerhead is empty...
[07:07] <poolie> just talk here
[07:07] <poolie> https://bugs.launchpad.net/bzr/+bugs?field.tag=config
[07:07] <poolie> probably 419854 would be really nice and not too hard
[07:12] <thomi> ok, so I need to open the file somewhere, and then work out how to add it to bzrlib.config.Stack?
[07:12] <poolie> yep
[07:12] <poolie> you should be able to open it with something very similar to the per-user configuration file
[07:12] <thomi> hmmm, I'll certainly give it a go.
[07:12] <poolie> we might need to update some existing callers that currently open just that one file to use a stack instead
[07:13] <thomi> should I assign the bug to me while I'm hacking away at it?
[07:14] <poolie> if you want, it's up to you
[07:14] <poolie> you can just say on the bug you'll have a go at it
[07:15] <thomi> I think I'll try and make some headway first. I'm still trying to get my head around bzrlib
[07:20] <poolie> don't hesitate to ask
[07:26] <jam> hi all
[07:38] <thomi> poolie: so (correct me if I'm wrong), currently there's "global" config, location config, and branch config, represented by GlobalStack, LocationStack and BranchStack?
[07:41] <poolie> correct
[07:41] <poolie> hi jam
[08:12] <robert_ancell> bzr broken in oneiric?
[08:20] <thomi> is there an equivilent to bzrlib.win32utils.py for Mac OSX? *or* does anyone know what the correct system-wide config directory should be for a mac?
[08:21] <robert_ancell> spiv, can you help me with your workaround in https://bugs.launchpad.net/bzr/+bug/772935?  lp:lightdm can't get branched anymore
[08:31] <Riddell> poolie: https://bugs.launchpad.net/bzr-explorer/+bug/814408
[08:31] <poolie> Riddell: https://bugs.launchpad.net/bzr/+bug/680529
[08:39] <seb128> Riddell, could anyone help robert_ancell with his "ErrorFromSmartServer" issue?
[08:39] <poolie> jam, for me, os.fsync does take a fileno parameter
[08:39] <seb128> it's blocking a lightdm update in oneiric
[08:39] <poolie> and it seems to pass on winepython
[08:39] <jam> poolie: interesting. It definitely doesn't here
[08:39] <poolie> hi sed
[08:39] <seb128> which robert_ancell wants to get out before being on holidays
[08:39] <seb128> Riddell or somebody else
[08:39] <poolie> seb128: where?
[08:40] <seb128> robert_ancell, ^
[08:40] <jam> hmm...
[08:40] <seb128> poolie, try to checkout lp:lightdm
[08:40] <robert_ancell> in bug 816296
[08:40] <jam> it does take one here, so why was it failing?
[08:40] <robert_ancell> (private)
[08:40] <seb128> he gets something similar to bug #785029
[08:40] <Riddell> bzr branch ubuntu:lightdm  works fine for me
[08:41] <Riddell> robert_ancell: what version of bzr are you using?
[08:41] <poolie> jam, actually nm that, i'll investigate
[08:41] <jam> poolie: so disregard my statement, it does take "filedescriptor"
[08:41] <poolie> help robert if you can
[08:41] <seb128> Riddell, try lp:lightdm
[08:41] <robert_ancell> Riddell, 2.4b5
[08:41] <Riddell> mm, yes, boom
[08:41] <robert_ancell> Riddell, the branch is lp:lightdm that doesn't work
[08:43] <poolie> thomi: hi
[08:43] <thomi> Hi poolie
[08:43] <jam> I can replicate that here as well
[08:44] <jam> grabbing a copy from LP real quick
[08:44] <poolie> thomi, probably through distutils.sysconfig or something
[08:44] <jam> it fails with bzr.dev as well
[08:45] <thomi> poolie:  ahh of course, that would make sense.
[08:45] <thomi> poolie: I think I have something working, but it seems like there's lots of places in the code that call GlobalCOnfig() directly rather than GlobalStack
[08:45] <jam> ah, it is failing with "AbsentFactory"
[08:45] <jam> meaning it is missinga file text
[08:45] <poolie> excellent!
[08:46] <poolie> yes, they're going to need to be updated
[08:46] <jam> something pushed up a revision that referenced a file text that didn't get copied.
[08:46] <poolie> but i hope it will be pretty mechanical
[08:46] <jam> I don't specifically know why
[08:46] <poolie> you could do the update separately
[08:46] <jam> robert_ancell: there are potentially 2 fixes
[08:46] <thomi> I have it as separate branches, I'll decide whether to merge them before pushing or not later.
[08:46] <jam> 1) figure out what rev that is (not too hard), and then do surgery to remove that revision from the repository (trickier)
[08:47] <jam> 2) Use spiv's fetch-everything to try to fill in that missing text
[08:47] <robert_ancell> jam I don't know what the first branch is in spivs command
[08:47] <jam> robert_ancell: presumably you have another copy of the branch on your local machine, which likely has the content
[08:48] <robert_ancell> yes, with some other changes committed and pushed to another location
[08:49] <jam> ugh, the revision is quite old
[08:49] <jam> '...-20100710034239-8eysy1lpccerztec'
[08:49] <robert_ancell> So spiv's command is: bzr fetch-all-records lp:? lp:lightdm, but what do I put in ?
[08:49] <jam> 2010-07-10
[08:50] <jam> robert_ancell: "bzr fetch-all-records local-branch lp:lightdm" I believe.
[08:50] <robert_ancell> will that bring those extra commits I made?
[08:50] <jam> robert_ancell: it will put them in the repository, but it won't change the branch pointer
[08:51] <jam> so the history looks the same to someone doing "bzr branch lp:lightdm"
[08:51] <jam> but there happens to be some more content that they don't fetch
[08:52] <seb128> robert_ancell, does your vcs has what is in lp:lightdm with new commits or did they divert?
[08:52] <seb128> robert_ancell, because you can copy the your checkout to a new dir, bzr uncommit until the revision you want and bzr revert
[08:53] <seb128> robert_ancell, that should give you a checkout without the new commits
[09:01] <robert_ancell> ok, so I rewound my local branch, so I have ~/bzr/lightdm which is what should be on the server.  What's the next step to fix lp:lightdm?
[09:10] <poolie> night all
[09:16] <seb128> jam: ^ do you know about robert_ancell's question?
[10:39] <spiv> jam: another workaround is nosmart+
[10:39] <spiv> jam: and another may be to not fetch into a shared repo
[10:40] <spiv> jam: (or perhaps to fetch into a shared repo?  I forget.  There's definitely at least one case where one way triggers and the other doesn't)
[10:56] <jam> spiv: are you talking about the lightdm stuff? The branch itself is broken. After using hitchiker to copy it down, I can't "bzr branch lightdm other"
[10:56] <jam> I don't know how it lost a text which was a year old, though
[10:57] <jam> there are no "obsolete_packs" in it
[10:57] <jam> I wonder if someone repacked and deleted them
[11:04] <spiv> jam: oh, ok.
[11:04] <spiv> jam: I was just guessing from the symptoms, I must of guessed wrong!
[11:04] <jam> spiv: right, AbsentContentFactory in this case is because a text is referenced which is not present in the repository.
[11:04] <spiv> A year ago *might* be old enough to mean someone used a version of bzr with stacking bugs?
[11:05] <jam> spiv: certainly possible, though this is a development focus branch...
[11:05] <spiv> Odd.
[11:05] <jam> though maybe it wasn't in the past
[11:05] <spiv> And it's unstacked currently?
[11:05] <jam> $ cat .bzr/branch/branch.conf
[11:05] <jam> stacked_on_location = ""
[11:06] <jam> parent_location = ../../../~robert-ancell/lightdm/trunk/
[11:06] <spiv> Hmm, that suggests it was stacked in the past
[11:06] <jam> yeah
[11:06] <jam> and I have a clue where it was stacked on :)
[11:06] <spiv> So probably a stacking bug.
[11:06] <spiv> Yeah :)
[11:06] <spiv> jam: I find the repo-has-key command helpful for identifying which repo has the necessary record
[11:06] <spiv> Anyway, food time!
[11:06] <spiv> Happy bug squishing.
[11:09] <jam> spiv: and lo-and-behold, the text key is present in lp:~robert-ancell/lightdb/trunk
[11:09] <jam> (lightdm even)
[11:09] <jelmer> spiv: bon appetit
[11:09] <jelmer> spiv: it looks like dpkg-mergechangelog behaves slightly different on Debian sid :-/
[11:10] <spiv> jelmer: better? </optimism>
[11:10] <jelmer> spiv: The odd thing is that it's the same version as on oneiric
[11:11] <jelmer> spiv: it actually generates a conflict for the first test case in test_3way_conflicted
[11:14] <jam> spiv: looks like a bad unstacking job. If I manually re-add stacking, I can branch locally again.
[11:14] <jam> so I think someone decided to unstack by removing the config setting
[11:15] <fullermd> Less "unstacking" than "toppling" then  ;p
[11:17] <spiv> jam: I recall a scary XXX in Branch.unstack, but yes that sounds probable
[11:18] <jam> spiv: of course, I'm trying to post that to the bug and LP is timing out now...
[13:10] <exarkun> Can I convert one directory of an svn repository to a bzr branch?
[13:11] <exarkun> It looked like maybe I could point bzr svn-import at it with --layout=root, but apparently not
[13:11] <jam> exarkun: bzr branch svn:.../subdir
[13:11] <jam> I'm pretty sure "bzr branch path" always works
[13:11] <jam> svn-import doesn't because it tries to come up with multiple branches to import
[13:12] <exarkun> Meh http://codepad.org/f4MHt3FZ :(
[13:12] <jelmer> jam, exarkun: --layout=root means treat the root of the repository as a branch
[13:13] <jam> exarkun: my immediate thought is to just delete your svn cache and try again
[13:14] <maxb> My local copy of bzr-svn is modified to never use tdb even if it's installed, for various performance and fragility reasons
[13:15] <exarkun> maxb: Uh, so you use the SQLite backend?
[13:15] <maxb> yes
[13:15] <exarkun> which is full of concurrency bugs that I think I maybe heard no one was interested in fixing
[13:16] <maxb> It's not buggy, it just doesn't let you run two operations against the same svn repository at once
[13:16] <maxb> On a client workstation, you very rarely would want to do that anyway
[13:16] <exarkun> maxb: nah, it's buggy.
[13:17] <jelmer> maxb: what's fragile about tdb?
[13:17]  * exarkun trying with old caches moved aside now
[13:17] <maxb> As exarkun is experiencing, it can get itself into a state which bzr-svn cannot resume from
[13:18] <maxb> Granted this is bzr-svn's usage of it that's the problem, not tdb itself
[13:19] <maxb> $ bzr branch svn://svn.twistedmatrix.com/svn/Twisted/trunk/emacs
[13:19] <maxb> Branched 10 revision(s).
[13:19] <exarkun> Great, bzr branch worked
[13:19] <exarkun> maxb: :)
[13:19] <exarkun> Thanks.
[13:21] <maxb> My other problem was TDB is that it turned pathologically slow once my cache DB became sufficiently huge, to the point at which I was habitually cat-ing it to /dev/null to prime the disk cache
[13:21] <maxb> Since switching to sqlite, I've been happy
[13:22] <maxb> Even though my cache-v5 file is 1.1GB :-)
[13:24] <jelmer> maxb: I wonder if that particular problem is really the tdb backends fault or somethng else
[13:25] <jelmer> maxb: in SQLite "SELECT * from paths WHERE revnum = 42" just yields no results rather than an error if that entry was never filled in
[13:26] <maxb> IIRC from when I looked into this, the problem was with bzr-svn's storage of the minimum / maximum revno present in the cache, and them being updated inappropriately
[13:26] <maxb> Basically the maximum revno was being advanced before the data had actually been filled in
[13:28] <jelmer> maxb: would be nice to have that in a bug report :)
[13:28] <jelmer> I think there's one or more bug reports about that KeyError, but I haven't had time to look into them yet
[13:29] <maxb> Yes... I was intending to understand it some more first, but then I got distracted and switched to sqlite
[13:30] <jelmer> maxb: So my understanding of it would be that with sqlite you have an incomplete cache, which is even worse I think
[13:31] <maxb> I think sqlite just tended to roll back the transaction and leave you with wasted work, but a correct cache
[13:31] <maxb> It was a while ago, though
[13:36] <jelmer> maxb: hmm
[13:36] <jelmer> Riddell: did you see bug 812749 ?
[13:37] <Riddell> jelmer: no, I'll comment
[16:55] <zyga> hi
[16:55] <zyga> any way to have revision id from command line
[16:55] <zyga> bzr revno --with-revision-id or something?
[16:57] <james_w> bzr log --show-ids has it
[16:58] <jelmer> zyga: bzr version-info
[16:59] <zyga> jelmer, oh, wow, I have no idea how I have missed that! brilliant
[16:59] <jelmer> zyga: or 'bzr revision-info'
[17:00] <zyga> the other is even better
[17:00] <zyga> is there any reference for return values on commands
[17:00] <zyga> like bzr status and bzr pull
[17:00] <zyga> I'
[17:00] <zyga> I'm trying to implement a small wrapper around bzr
[17:00] <zyga> and I need methods such as is_dirty(), pull_without_merge()
[17:01] <zyga> I did this with bzrlib before but it was rather hard to read and not something I felt confident with
[17:05] <mgz> jelmer, did you have a paste accident in the comment you pasted to the selftest-xfail-msg mp?
[17:05] <mgz> I see the diff twice but not the output.
[23:47] <poolie> hi all
[23:48] <jelmer> hey polie
[23:49] <poolie> hi jelmer
[23:49] <jelmer> *poolie