[12:04] <lapthrick> hrmpf
[12:04] <lapthrick> it seems that a push didn't, in fact, include the nested tree :(
[12:05] <lifeless> had you committed?
[12:05] <lapthrick> yes
[12:05] <lifeless> does 'bzr branch mytree mynewtree' include the upstream subtree ?
[12:05] <lifeless> and did you use bzr push, or bzr svn-push?
[12:05] <lapthrick> lifeless: when I do svn log on that branch, there's a missing revno corresponding to when I merged
[12:06] <lapthrick> lifeless: svn-push
[12:06] <lapthrick> actually, it might be due to another thing
[12:06] <lifeless> jelmer_: good timing
[12:06] <lifeless> assuming you are here :)
[12:06] <lapthrick> that SVN repo uses a two-level branch structure
[12:06] <lapthrick> so branches/owner/branchname
[12:07] <jelmer> hey lifeless
[12:07] <lifeless> 08:04 < lapthrick> hrmpf
[12:07] <lifeless> 08:04 < lapthrick> it seems that a push didn't, in fact, include the nested tree :(
[12:07] <lifeless> 08:05 < lifeless> had you committed?
[12:07] <lifeless> 08:05 < lapthrick> yes
[12:07] <lifeless> 08:05 < lifeless> does 'bzr branch mytree mynewtree' include the upstream subtree ?
[12:07] <jelmer> it's actually evening here (-:
[12:07] <lifeless> 08:05 < lifeless> and did you use bzr push, or bzr svn-push?
[12:07] <lifeless> 08:05 < lapthrick> lifeless: when I do svn log on that branch, there's a missing revno corresponding to when I merged
[12:07] <lifeless> 08:06 -!- jelmer [n=jelmer@157pc196.sshunet.nl]  has quit [Remote closed the connection] 
[12:07] <lifeless> 08:06 < lapthrick> lifeless: svn-push
[12:07] <lapthrick> and it did bail out with "not a valid SVN branch" during that push
[12:07] <lapthrick> so I assume it was trying to push that sub-tree after pushing the parent tree and then it died
[12:08] <lapthrick> jelmer: so, I need support for two-level branch scheme for the repo I'm using
[12:09] <lapthrick> though it's actually optional, some branches we have are directly unders branches/, some live in branches/owner/
[12:09] <jelmer> lifeless: Thanks
[12:10] <lapthrick> jelmer: I also submitted a bug report and have a scenario where merge-into manages to kill bzr-svn for you :)
[12:10] <jelmer> lapthrick: 'bzr svn-branching-scheme' should be able to tell you what branching scheme is being used for a repository atm
[12:11] <lapthrick> bzr pokerolymp:2090/> svn-branching-scheme svn+https://beta.aimido.de/svn/src2/
[12:11] <lapthrick> trunk
[12:11] <lapthrick> branches/*
[12:11] <lapthrick> tags/*
[12:12] <jelmer> you'd probably want to add 'branches/*/*' there as well
[12:12] <lapthrick> jelmer: how can I do that?
[12:13] <jelmer> bzr.dev svn-branching-scheme --set
[12:13] <lapthrick> jelmer: so just svn-branching-scheme --set branches/*/* ?
[12:15] <jelmer> lapthrick: just bzr svn-branching-scheme --set <url>
[12:15] <jelmer> that should put you into an editor allowing you to edit that list
[12:15] <lapthrick> ahh
[12:15] <jelmer> the branches/*/* should probably be the first line
[12:17] <lapthrick> bzr pokerolymp:2090/> svn-push svn+https://beta.aimido.de/svn/src2/branches/mathrick/pokersource/
[12:17] <lapthrick> Unhandled error:
[12:17] <lapthrick> hmm
[12:17] <lapthrick> I suspect that branch might be broken by the previous botched push
[12:18] <lapthrick> no, actually it happens for every branch I try to push to
[12:18] <lapthrick> jelmer: any idea where I should poke it?
[12:19] <jelmer> lapthrick: what unhandled error exactly?
[12:19] <lapthrick> jelmer: that's exactly what it says. Unhandled error and then nothing
[12:20] <jelmer> can you try running with BZR_PDB=1 set and seeing what line it bails out on?
[12:21] <lapthrick> jelmer: http://pastebin.com/m68ba42d8
[12:23] <lifeless> igc: I have all tests passing in packs
[12:23] <jelmer> ah, looks like ListBranchingScheme still needs a is_parent_branch() implementation
[12:23] <igc> that's great lifeless
[12:24] <lifeless> igc: about to send a patch that cleans up weave stuff - and makes the tests pass ;)
[12:24] <igc> ok - I'll have a look
[12:25] <lapthrick> jelmer: is there an easy fix for that?
[12:26] <jelmer> lapthrick: looking at it atm
[12:29] <jelmer> lapthrick: btw, I don't think I've seen any bugreport on the merge-into/bzr-svn problem
[12:32] <lifeless> igc: mail sent
[12:32] <igc> cool
[12:33] <igc> btw, up early because it's school holidays here now - best to get as much done as early as possible :-)
[12:34] <lifeless> heh
[12:34] <lifeless> I got 7 hours solid sleep.... and then woke up at 0430
[12:35] <lapthrick> jelmer: no, I didn't submit a bugreport, as it wasn't entirely clear what's happening
[12:37] <jelmer> lapthrick: If you can still reproduce it, a bug report would be very useful. merge-into and bzr-svn should be able to work ok together
[12:39] <lapthrick> jelmer: sure
[12:45] <lapthrick> jelmer: actually it seems I'm able to trigger two separate errors
[12:45] <lapthrick> mathrick@hatsumi:/tmp/merge$ bzr merge-into file://$PWD/../test/trunk test
[12:45] <lapthrick> bzr: ERROR: Repository KnitRepository('file:///tmp/merge/.bzr/') is not compatible with repository SvnRepository('file:///tmp/merge/../test')
[12:45] <lapthrick> jelmer: that's on a local test repo
[12:46] <lapthrick> jelmer: http://pastebin.com/m63022805
[12:46] <lapthrick> this one is on the actual repos I wanted to merge-into
[12:47] <jelmer> lapthrick: that first error should be fixable by upgrading the bzr repository
[12:47] <jelmer> lapthrick: see the FAQ in bzr-svn's 0.4 branch
[12:48] <jelmer> lapthrick: I'll fix the other one
[12:48] <lapthrick> jelmer: great, thanks
[01:11] <lifeless> igc: repository branch that passes all tests pushed
[01:11] <igc> cool. Did you want me to run any tests here?
[01:13] <lifeless> not as such
[01:13] <lifeless> just letting you know
[01:14] <igc> sure - thanks
[01:34] <Peng> Pulling from the repository branch: bzr: ERROR: Revision {robertc@robertcollins.net-20070923224332-qy28l0g345rcyein} not present in "rev_storage.py-20051111201905-119e9401e46257e3".
[01:35] <Peng> Is it in the middle of a push or something?
[01:39] <lifeless> no
[01:39] <lifeless> revert back a couple of revisions
[01:39] <lifeless> then pull again
[01:39] <lifeless> termporary bokrage
[01:43] <Peng> What, uncommit back a few revisions?
[01:44] <lifeless> yes
[01:44] <lifeless> bbiab
[01:44] <lifeless> before the 'fix test X' one, that broke it
[01:45] <lifeless> uncommit + revert
[01:45] <lifeless> ok, ciao, -> poolies
[01:45] <Peng> Oh, revert too.
[01:48] <Peng> Yeah, that worked.
[01:48] <Peng> Thanks.
[02:11] <abentley> lifeless: The branch: and ancestor: revision specs do a fetch.
[02:15] <poolie> hi
[02:16] <poolie> abentley, i think lifeless is on a train
[02:16] <abentley> poolie: Okay.  No big rush.
[02:16] <poolie> (rebooting)
[03:42] <lifeless> Peng: cool
[03:47] <Peng> So what was wrong with it?
[03:56] <lifeless> I broke it
[03:56] <lifeless> then I unbroke it
[03:56] <lifeless> you had the broken copy
[04:00] <Peng> Okay.
[04:19] <lifeless> Peng: the details are pretty boring really; there was a failing test that was more important than I realised; and two variables being tested for equality that were of different types
[04:19] <lifeless> Peng: but all tests pass now; so should all be good
[04:26] <fullermd> Underrating the importance of a failing test??  Who are you, and what have you done with lifeless?
[04:28] <lifeless> its an experimental branch
[04:29] <lifeless> I don't have a zero-tests failing policy for things that I'm doing open heart surgery on; I try for zero but its not always feasible.
[04:29] <fullermd> Hrmph.  Excuses, excuses.  Getting soft in your old age...
[04:39] <Peng> lifeless: Oh, okay.
[05:47] <lifeless> igc: ping
[05:47] <igc> hi lifeless
[05:48] <lifeless> want a quick call ?
[05:48] <igc> sure
[05:48] <igc> you at poolies?
[05:48] <lifeless> up
[05:48] <igc> or you can call me
[05:48] <lifeless> yup
[05:48] <lifeless> nah, call poolies
[05:48] <igc> np
[05:49] <igc> 2 minutes
[06:15] <ubotu> New bug: #144352 in bzr "tag should refuse to tag null:" [Undecided,New]  https://launchpad.net/bugs/144352
[06:52] <jelmer> lapthrick: ok, the bug you posted to pastebin should be fixed now
[07:18] <poolie> jelmer: hi?
[07:19] <jelmer> poolie, hi
[07:29] <lapthrick> jelmer: the one with merge-into svn://, or the one with push svn:// ?
[07:29] <jelmer> lapthrick: merge-into
[07:29] <jelmer> poolie: ping?
[07:29] <lapthrick> okay, lemme try
[07:29] <jelmer> btw, I've only fixed the issue you reported, not actually tested merge-into with bzr-svn..
[07:32] <lapthrick> jelmer: it seems to work fine
[07:32] <jelmer> cool, great :-)
[07:33] <lapthrick> jelmer: do you have that push bug recorded somewhere, or should I put it in launchpad?
[07:34] <jelmer> lapthrick: I just filed a bug report on launchpad, with you subscribed
[07:34] <lapthrick> good, thanks
[07:34] <fullermd> poolie: Hi dere.
[07:35] <fullermd> poolie: Is 0.91 blocked on something?
[08:02] <poolie> fullermd: no, just other work keeps getting ahead of it
[08:02] <poolie> liw, hi
[08:03] <liw> poolie, greetingses
[08:03] <fullermd> Coolies.  Just making sure I didn't miss something on the list   :)
[09:24] <lapthrick> I have a branch in which I removed some files present in upstream, now it turns out I need them. What's the best way to restore them?
[09:27] <GaryvdM> lapthrick: revert
[09:27] <GaryvdM> I think
[09:29] <AfC> lapthrick: revert is correct if it's simply current uncommitted work.
[09:29] <AfC> lapthrick: if numerous revisions have gone by since then, you'll have to do something more elaborate
[09:30] <lapthrick> the latter
[09:30] <liw> would a reverse merge work? "bzr merge -r 42..41"
[09:30] <lapthrick> it suggests merge -r foo
[09:30] <AfC> ... a kludgy way to do it would be to just copy the files [back]  in, and `bzr add` them [again]  [potentially using  --file-ids or whatever to make sure it knows what you're up to] 
[09:31] <AfC> liw: [that would assume the file removal was the only thing in that revision, although you could do that and then revert the parts you didn't want to, er, revert :)] 
[09:33] <lapthrick> it seems that revert takes revision argument, but it also seems that I didn't, in fact , remove the dir I needed, I was just looking in the wrong place :)
[09:36] <lapthrick> aye, revert -r foo bar restores bar just fine
[09:36] <lifeless> ciao for now, be back in a bit
[09:37] <lapthrick> AfC: we need to beat some sense into desrt
[09:37] <lapthrick> what with his silly delusions about git
[09:37] <lifeless> lapthrick: are you a gnomer ?
[09:37] <lapthrick> lifeless: indeed
[09:37] <lifeless> cool
[09:37] <lapthrick> indeed :)
[09:37] <lifeless> AfC: btw, did I mention I have local initial commit faster than hg now ?
[09:38] <lifeless> AfC: (not that hg are *my* benchmark, but they seem to be some folks' benchmark)
[09:38] <lifeless> heading home, be back in a bit
[09:38] <lapthrick> see ya
[09:39] <vila> hi all
[09:39] <lapthrick> hi vila
[09:40] <lapthrick> vila: looked into that curl bug perhaps?
[09:40] <vila> lapthrick: 1) not yet, 2) I thought you found it was more on the bzr-svn front ?
[09:41] <lapthrick> vila: no, quite the opposite, I found it's a general libcurl-gnutls compat issue
[09:41] <vila> lapthrick: more precisely ? Is that a problem in curl or a problem in the way we interact with it ?
[09:42] <vila> lifeless: regarding my corrupted repo, I found that gutsy have changed the way nfs interacts with OSX
[09:42] <lapthrick> vila: I dunno, but last time you said it looked like an API compat bug and you need to look into it, since there was no error 77 as far as you knew
[09:43] <vila> lapthrick: That point I didn't have time to check yet
[09:43] <lapthrick> ok
[09:43] <lapthrick> I'm not in a big hurry, I can use https+urllib for now, that repo isn't very likely to haxx me for not checking the cert properly
[09:44] <vila> lapthrick: ok
[09:46] <vila> lifeless: as I update gutsy as soon as the update-manager warn me, I can't know exactly if/what/when something went wrong, *but* this morning, the nfs mount from OSX failed at boot (but worked from command line...) until I add proto=tcp in /etc/fstab (using mount-v revealed that the mount succeeded with proto=udp)
[09:48] <vila> as I can't reproduce the corruption by committing in the same conditions (to the best of my knowledge), I will consider that NFS was the cause (I don't really like leaving a possible corruption bug lying around, but I really can't see what to do to get a better diagnosis)
[09:50] <vila> lifeless: I am currently reorganizing around a new repo and will keep the corrupted one for some weeks anyway as it looks as a perfect candidate to better understand many details (why 'bzr send -o -' needs to refer to a revision outside of the branches it should care of, for one :)
[10:18] <lifeless> vila: ok
[10:18] <lifeless> oh, and I'm back :)
[10:19] <vila> lifeless: :) I still feel bad about that corruption though... What is *your* feeling ?
[10:20] <lifeless> vila: One of the lp developers has had similar corruption twice now; they use nfs.
[10:20] <vila> lifeless: haaaa, what a relief, same symptoms ? zeroed revision ?
[10:21] <lifeless> dunno exactly
[10:23] <vila> lifeless: ok, will keep an open eye then (but I rarely commit from OSX these days anyway)
[10:24] <vila> lifeless: is there same way to check against this corruption from another data path or do we rely on the gzip crc ?
[10:25] <lifeless> file sha will find it
[10:26] <vila> ok, I'll try to look into that (if only to understand if bzr may have been tricked by nfs telling him, yes, the content have been written to disk, when in fact it has not)
[10:27] <vila> that's one of the reason I didn't want to touch that repo if I was able to rebuild everything (which I'm close to have achieved)
[10:29] <vila> lifeless: errr, scratch that, the commit was from the NFS server
[11:05] <ubotu> New bug: #144388 in bzr "Cannot do svn checkouts in a repository" [Undecided,New]  https://launchpad.net/bugs/144388
[11:55] <ubotu> New bug: #144394 in bzr "stderr from a bzr+ssh smart server process should not be sent to the client" [Undecided,New]  https://launchpad.net/bugs/144394
[02:50] <ubotu> New bug: #144421 in bzr "Using branch: revspec in stat blows up" [Undecided,New]  https://launchpad.net/bugs/144421
[05:56] <abadger1999> Does launchpad support the smart server?
[05:56] <Peng> Yes.
[05:56] <Peng> It's even recommended now1
[05:56] <Peng> !
[05:56] <Peng> Not sure about bzr+http.
[05:56] <abadger1999> Cool.
[05:56] <abadger1999> Oh.
[05:56] <abadger1999> Does that mean I would need an account of some sort to have ssh?
[05:57] <Peng> Yes.
[05:57] <fullermd> I didn't think it did, only the +ssh variant.
[05:57] <Peng> I tried to set up a bzr+http server once. It didn't work. Someone else had the same experience too.
[05:57] <abadger1999> I'm making some speed tests for a blog post and wanted to include smart server times to lp.
[05:58] <abadger1999> Guess I'll just include times to a server I have ssh on and note any discrepancy between doing a plain branch operation and smart server branch operation compared to lp.
[05:58] <fullermd> I don't think bzr+http is in general significantly faster than http.  It'll gain a little, and the special case of initial mirror may be a good bit faster from the tarball sending thing, but that's pretty fringe...
[05:59] <abadger1999> Good to know.  Is http in general faster than bzr+ssh?
[05:59] <abadger1999> err.. as fast as.
[06:00] <fullermd> Well, theoretically (mod protocol setup overhead), bzr+ssh should be the same speed as bzr+http
[06:00] <fullermd> Somewhat axiomatically, http should be slower than bzr+http by some non-zero factor; I think that factor is pretty small outside of very specific cases, though.
[06:01] <abadger1999> Okay.  Sometime when I'm less busy I'll have to run some more in-depth tests.
[06:01] <fullermd> Now, bzr+ssh is noticeably faster than sftp.  But that's mostly on writes (and the specific limitations of sftp in that realm), not reads, so that doesn't translate over to http.
[06:02] <abadger1999> Okay.  And the initial checkout? (because of the tarball sending)
[06:03] <fullermd> Too, there are the currently in-progress (and vaguely hoped for in 0.92) smart server improvements that should make a drastic improvement there, by making the smart server actually smart.  It's pretty dumb overall...
[06:04] <fullermd> Well, when it kicks in, that should make the transfer bandwidth limited at the size of the repository.
[06:04] <abadger1999> heh, my quick blog post is just to address someone who claimed that bzr branch awn (a project on lp) took 10 minutes.  So the smart server will definitely add another interesting number to the mix.
[06:18] <abadger1999> Does anyone know what the scope of this warning in http_smart_server.txt is?
[06:18] <abadger1999> **This feature is EXPERIMENTAL and is NOT SECURE.  It will allow access to
[06:18] <abadger1999> arbitrary files on your server.**
[06:19] <abadger1999> Does it refer to the particular configuration in the file or to limitations of running bzr+http at all?
[06:28] <Peng> abadger1999: It's out-of-date.
[06:29] <abadger1999> Even better :-)
[06:30] <Peng> abadger1999: Personally, I'd like to know one of the developers went through the bzr+http code, but I'd be willing to use it.
[06:30] <Peng> abadger1999: Tell me if you get it to work!
[06:31] <abadger1999> Peng: Cool.  I'll be sure to mention it if I get it running!
[07:19] <sabdfl> fullermd, abadger1999: there's also the history-horizon stuff, which should make "bzr branch" take about the same time as a tarball download of source snapshot without history
[07:19] <sabdfl> i think that's post-1.0, though, so December+
[07:20] <abadger1999> Nifty.  I didn't realize history horizon would improve performance.
[07:20] <abadger1999> Does that mean that it doesn't download history unless it's necessary?
[07:20] <fullermd> Well, in the degenerate case, it drops you to a equivalent 'checkout --lightweight' time.  Which doesn't really crank up spiffiness until the smart server gets rather smart.
[07:25] <sabdfl> abadger1999: the idea is to make it do "asm much as it can" with the history it has availble
[07:25] <sabdfl> so, bzr log would show the revisions it has
[07:25] <sabdfl> you could fetch more revisions to do more
[07:26] <sabdfl> merge would bring in just the revisions needed to do the merge
[07:36] <abadger1999> Thanks for the explanation.
[08:04] <schierbeck> phanatic: hi
[08:05] <phanatic> hey schierbeck
[08:05] <phanatic> i've just rolled out 0.91.0
[08:05] <schierbeck> cool
[08:06] <schierbeck> have you taken a look at the remove-date-column branch?
[08:08] <dato> phanatic: cool, thanks
[08:10] <phanatic> schierbeck: yep, but i think we should go with what GaryvdM suggested (allowing the user the select which columns s/he wants to see)
[08:11] <phanatic> dato: yw :)
[08:12] <schierbeck> phanatic: okay, is someone working on that atm?
[08:12] <phanatic> i don't know if GaryvdM does, i hope he can answer that when he returns
[08:15] <schierbeck> okay, i was just hoping we could've merged my branch first, and then worked on a more advanced solution later on
[08:16] <jelmer> phanatic, congrats on your first release (-:
[08:17] <schierbeck> phanatic: should i create a separate branch for the removal of the email part of the committer column?
[08:17] <phanatic> jelmer: thanks :) i hope i haven't f'd up anything...
[08:17] <Lo-lan-do> Aha!
[08:17] <phanatic> schierbeck: it's up to you
[08:18] <jelmer> hey Lo-lan-do
[08:18] <Lo-lan-do> jelmer: I'm sorry I was not online during the weekend, hope you weren't waiting for me
[08:18] <schierbeck> phanatic: okay, i'll do that -- you'll merge it to trunk?
[08:19] <jelmer> hey Lo-lan-do
[08:19] <phanatic> schierbeck: sure, just send a mail about that to the list, so we can track them. and don't forget the NEWS entry. i had to hunt down at least 5 missing items before the release :)
[08:19] <jelmer> bad timing for a client crash :-)
[08:19] <Lo-lan-do> As I was saying: <Lo-lan-do> jelmer: I'm sorry I was not online during the weekend, hope you weren't waiting for me
[08:20] <Lo-lan-do> (Hope you're not fleeing away from me :-)
[08:21] <ubotu> New bug: #144522 in bzr "test suite fails" [Undecided,Fix committed]  https://launchpad.net/bugs/144522
[08:21] <jelmer> Nah, was travelling
[08:23] <Lo-lan-do> 'kay.  Did you have time to have a look at my pushing problem?
[08:23] <schierbeck> phanatic: btw, do you want me to sign the commits?
[08:27] <jelmer> Lo-lan-do: working on it atm
[08:27] <Lo-lan-do> That's great!
[08:31] <phanatic> schierbeck: it's not neccessary
[08:32] <schierbeck> phanatic: screw it, i already did it
[08:32] <schierbeck> :)
[08:32] <phanatic> hehe :)
[08:32] <phanatic> no problem
[08:32] <phanatic> i hope it won't break anything
[08:32] <phanatic> jelmer: could you update gnomefiles and freshmeat? i don't have access to those bzr-gtk pages
[08:33] <schierbeck> phanatic: i'm thinking of adding some ui for displaying whether a commit has been signed, so i'm planting some data
[08:33] <jelmer> phanatic, I'll add you to the list of maintainers of both
[08:33] <phanatic> jelmer: thanks!
[08:33] <phanatic> schierbeck: sounds cool :)
[08:33] <schierbeck> okay, i've got to get something to eat now, see you guys later
[08:35] <abadger1999> abentley: When you're around I have some trac-bzr patches.
[08:37] <GaryvdM> phanatic, schierbeck: Hi
[08:37] <GaryvdM> I'm not working on the columns selector currently.
[08:37] <phanatic> GaryvdM: hey, thanks for the update
[08:37] <jelmer> phanatic: I've added you on freshmeat
[08:37] <GaryvdM> How is the release going?
[08:39] <jelmer> phanatic, and you're now owner of bzr-gtk on gnomefiles.org
[08:40] <phanatic> GaryvdM: 0.91.0 is out :)
[08:40] <phanatic> jelmer: thank, updating those sites now...
[08:40] <phanatic> thanks
[08:40] <GaryvdM> Cool!
[08:48] <phanatic> jelmer: freshmeat and gnomefiles updated
[08:48] <lapthrick> oooh, jelmer, my favourite bzr-svn maintainer
[08:49] <phanatic> schierbeck: subscribe to the list :P
[08:56] <jelmer> hey lapthrick
[08:56] <jelmer> phanatic, thanks!
[08:57] <lapthrick> jelmer: did you have the time for bugfixing love perhaps?
[09:00] <jelmer> lapthrick, I'm working on bzr-svn atm though on a different bug..
[09:00] <lapthrick> I see
[09:08] <jelmer> Lo-lan-do: can you try the pushing again
[09:08] <jelmer> ?
[09:09] <Lo-lan-do> Sure
[09:13] <Lo-lan-do> http://paste.debian.net/37896
[09:27] <lifeless> abadger1999: the warning is out of date, I believe it is less scary in bzr.dev
[09:28] <abadger1999> lifeless: Great.
[09:28] <corporate_cookie> dose anyone have a bzr RPM for RHEL4 ?
[09:30] <lifeless> corporate_cookie: I'm not sure, however its really easy to run from source - just unpack it somewhere and add the dir to your path
[09:30] <lifeless> corporate_cookie: as long as you have pythn2.4 or newer, the very core will simply work
[09:30] <corporate_cookie> lifeless: I need an entry in my RPM database for some dependancy checking
[09:31] <corporate_cookie> I've tried to roll my own ..but i'm getting some fun errors ...and I have no clue what they mean
[09:31] <lifeless> corporate_cookie: oh
[09:31] <abadger1999> corporate_cookie: Which python version is in RHEL4?
[09:31] <lifeless> corporate_cookie: what sort of errors, ones from rpm ?
[09:33] <abadger1999> corporate_cookie: python -c 'import sys; print sys.version'
[09:34] <abadger1999> I was pretty sure it was 2.3 :-(
[09:34] <jelmer> Lo-lan-do: thanks
[09:34] <corporate_cookie> abadger1999: its 2.3
[09:34] <corporate_cookie> however ..i have a parallel install of 2.4
[09:36] <abadger1999> corporate_cookie: Ah.  Then I might be able to help (I build the Fedora and EPEL-5 bzr rpms)
[09:36] <abadger1999> corporate_cookie: if you pastebin your errors and spec file I can take a look.
[09:41] <schierbeck> phanatic: i thought i already was :) i've done it now
[09:41] <phanatic> schierbeck: thanks. your previous mail will appear on the list as soon as we get moderation fixed :)
[09:42] <schierbeck> phanatic: cool
[09:44] <corporate_cookie> abadger1999: (managers always pick the best times to stop by and check in; pardon my slow responce)
[09:46] <corporate_cookie> abadger1999:  im generating the spec ..and rpm with python2.4 setup.py bdist_rpm
[09:48] <abadger1999> corporate_cookie: k.
[09:48] <corporate_cookie> im pasting the full output
[09:48] <corporate_cookie> http://pastebin.com/d37383707
[09:51] <abadger1999> Hmm... it's unable to find generate_docs.py even though it's in the toplevel directory.
[09:55] <corporate_cookie> abadger1999: is this a problem with the python install ?
[09:56] <abadger1999> corporate_cookie: I don't think so.  I'm able to replicate it here with the vendor py2.5 install.
[09:59] <Lo-lan-do> I'll probably blink for a while, but I'll definitely be back :-)
[10:00] <abadger1999> corporate_cookie: Looks like it's a problem with distutils.
[10:00] <lifeless> Lo-lan-do: good luck :)
[10:01] <abadger1999> corporate_cookie: Let me see if I can get an old enough version of the bzr spec from Fedora that might work for you.
[10:01] <corporate_cookie> thanks : )
[10:02] <ubotu> New bug: #144300 in bzr "bzr log dies on more fancy revisionspecs with bzr-svn branches" [Medium,Triaged]  https://launchpad.net/bugs/144300
[10:09] <Lo-lan-do> Back (yay for TCP timeouts being longer than the reboot time of a Soekris box)
[10:09] <abadger1999> corporate_cookie: http://toshio.fedorapeople.org/bzr.spec
[10:09] <corporate_cookie> woo hoo
[10:09] <corporate_cookie> thanks abadger1999
[10:09] <lifeless> bubg 144300
[10:09] <abadger1999> corporate_cookie: Have you built an rpm from scratch before?
[10:09] <lifeless> bug 144300
[10:09] <ubotu> Launchpad bug 144300 in bzr-svn "bzr log dies on more fancy revisionspecs with bzr-svn branches" [Medium,Triaged]  https://launchpad.net/bugs/144300
[10:10] <jelmer> looks like the ancestor: one is a bzr-svn related bug
[10:10] <corporate_cookie> abadger1999:  I have ...but i must admit i've only done it aa few times
[10:10] <jelmer> lifeless: but the branch: one is valid for bzr itself too
[10:10] <lifeless> yah noticing that
[10:11] <abadger1999> corporate_cookie: Okay.  If you have troubles using rpmbuild with that spec let me know and I'll try to work out what's going wrong.
[10:11] <abadger1999> corporate_cookie: I don't have a rhel 4 box with python2.4 so I can't test it easily :-(
[10:11] <fullermd> That kinda ties in with but 144421 I filed earlier.
[10:11] <jelmer> lifeless: There's no "split" option for bugs in lp yet, right? I'll make a copy
[10:12] <lifeless> bug 144300
[10:12] <ubotu> Launchpad bug 144300 in bzr "bzr log -r branch|ancestor attempt to fetch data in a read only transaction" [High,Triaged]  https://launchpad.net/bugs/144300
[10:13] <fullermd> Note that my testing was on stat, which fails with branch:.  Using 'diff' instead works, though.
[10:15] <lifeless> another patch up :)
[10:16] <lifeless> so jelmer, I'm curious why the new list
[10:17] <AnMaster> http://pastebin.ca/709607
[10:17] <AnMaster> shouldn't both report no such command?
[10:18] <AnMaster> bzr should handle utf8 everywhere IMO
[10:18] <jelmer> lifeless: doesn't require contributors to be on the high-volume bzr list, makes it easier to set up separate bundlebuggy, doesn't clutter the main list with bzr-gtk merge requests
[10:18] <fullermd> AnMaster: Are you using a UTF-8 locale?
[10:18] <AnMaster> fullermd, I am
[10:19] <lifeless> jelmer: OTOH if most of our users use bzr-gtk as well, then until they get used to the other list your contributors won't see their questions
[10:19] <AnMaster> sv_SE.UTF8
[10:19] <lifeless> also slack folk like me with $ too many lists, will be lazy about joining the new list
[10:19] <AnMaster> sv_SE.UTF-8 even
[10:19] <fullermd> AnMaster: It DTRT's for me.  en_US.UTF-8.
[10:20] <AnMaster> bzr 0.90
[10:20] <jelmer> lifeless: There'll still be bzr-gtk folks like Szilveszter and me around to help with the occasional question on the main bzr list
[10:20] <fullermd> bzr.dev and 0.91rc2.  I don't have 0.90 handy at the mom...  wait, maybe I do.
[10:20] <fullermd> Yeah, works on 0.90 too.
[10:20] <AnMaster> fullermd, system is freebsd
[10:21] <fullermd> So're all mine.  I've got taste, after all   ;>
[10:21] <AnMaster> it also fails on gentoo
[10:21] <AnMaster> hm
[10:21] <AnMaster> it fails on my 64-bit gentoo but not my 32-bit gentoo
[10:21] <AnMaster> as for freebsd, it is 32-bit
[10:21] <AnMaster> weird
[10:22] <fullermd> Are you setting LANG, or some of the LC_*'s individually?
[10:22] <AnMaster> fullermd, I'm setting LC_ALL
[10:22] <AnMaster> LANG is set to C
[10:22] <AnMaster> but, it is same on each
[10:22] <AnMaster> fullermd, actually no it isn't
[10:23] <jelmer> lifeless: also, two bundlebuggy's on one list doesn't work - at least not with the standard bundlebuggy and standard 'bzr send'
[10:23] <AnMaster> fullermd, but well both gentoo got LC_COLLATE set to C as well
[10:23] <AnMaster> and one of those worked
[10:23] <AnMaster> so makes no sense
[10:23] <fullermd> I've never tried mixing and matching.  I just have LANG=en_US.UTF-8 on my systems, LC_ALL stays blank, and the other LC_*'s follow it.
[10:24] <fullermd> I get a headache every time I try to figure out more intricate setups and precedence   :|
[10:24] <AnMaster> fullermd heh
[10:26] <fullermd> But that's where I'd guess the problem is; it ends up seeing a 7-b ASCII encoding rather than a UTF-8 because of whatever vagary of interpretation of the mixing, on those systems.
[10:26] <AnMaster> btw who should I complain to about trac-bzr?
[10:26] <AnMaster> the trac ppl or you here?
[10:27] <fullermd> Probably someone here.  Not sure who, though...   I think abentley did some work on it, but I don't know if he's currently looking at it.
[10:27] <AnMaster> http://kuonet.org/~anmaster/envbot/trac/timeline <-- see two weird changesets at top
[10:27] <lifeless> jelmer: re BB thats really just a bug :)
[10:27] <AnMaster> also I get messages like:
[10:27] <AnMaster> /usr/local/lib/python2.5/site-packages/TracBzr-0.2-py2.5.egg/tracbzr/backend.py:674: DeprecationWarning: bzrlib.revisiontree.RevisionTree.get_weave was deprecated in version 0.90.
[10:27] <AnMaster>   weave = self.tree.get_weave(self.entry.file_id)
[10:27] <lifeless> I don't like the idea that folk have to have a list to use BB properly.
[10:27] <AnMaster> :/
[10:28] <AnMaster> fullermd, ^
[10:28] <AnMaster> bzr is 0.90
[10:28] <AnMaster> trac and trac-bzr are last from ports on freebsd
[10:28] <fullermd> Yeah, that would be a 'bzr API moving ahead, trac not keeping up' thing.
[10:28] <AnMaster> fullermd, same for the broken changesets ?
[10:29] <fullermd> Oh, I don't know trac or trac-bzr well enough to say, but it could be a suspicious coincidence.
[10:29] <AnMaster> fullermd, also did bzr do a version jump, it seemd to be around 0.15 just some months ago then I turned my back for a few months and it is suddenly at 0.90
[10:29] <AnMaster> ?
[10:29] <lifeless> jelmer: for instance, one could give BB a submission address, rather than the list. Then BB mails the list as things come into it
[10:29] <jelmer> lifeless: Yup, I agree. I don't think it's likely that support for determining whether a revision is relevant for a particular project is going to be added soon though and working with a separate list is much easier than adding such support.
[10:29] <fullermd> bzr port is up to date.  trac-bzr is from March, though, so I dunno.  I don't have any involvement with the trac side...
[10:29] <fullermd> AnMaster: Yes, it jumped from 0.18 to 0.90.
[10:29] <AnMaster> fullermd, reason?
[10:30] <lifeless> jelmer: This would be trivial, all you need is BB to forward the message rather than just linking to it.
[10:30] <lifeless> much simpler than what you're talking about
[10:30] <fullermd> AnMaster: Well, _I_ stick by the belief that it's a bit error in memory somewhere...     :p
[10:30] <jelmer> lifeless: so you have to send merge requests to both the list /and/ bundlebuggy?
[10:30] <lifeless> jelmer: no
[10:30] <AnMaster> fullermd, and the official reason?
[10:30] <jelmer> lifeless, that sounds more complicated than joining an additional mailing list
[10:31] <fullermd> AnMaster: The theory behind it was to express some sense of progress toward 1.0.
[10:31] <AnMaster> fullermd, anyway, I need to know who to complain to really about trac-bzr
[10:31] <lifeless> jelmer: rather than --mail-to bazaar-at-blah, its --mail-to bundle-buggy
[10:31] <jelmer> lifeless: that means the development process for bazaar would have to change as well
[10:31] <jelmer> lifeless: otherwise bzr's bundlebuggy would pick up the bzr-gtk merge requests
[10:32] <lifeless> jelmer: its a trivial change
[10:32] <lifeless> and its not like we're static, we change what, monthly?
[10:32] <fullermd> AnMaster: Well, you may have to bug Radim about it.  I'm not sure there are any 'official' releases; it looks like a snapshot that he rolled and hosts himself for the port.
[10:32] <jelmer> lifeless, it requires all contributers to change how they work, docs on submitting merge requests to change, etc
[10:32] <AnMaster> fullermd, who? *confused, just a user*
[10:32] <fullermd> AnMaster: I'm not sure where the 'official' upstream is, to check if there are catchup changes.
[10:32] <fullermd> AnMaster: The port maintainer.
[10:32] <AnMaster> ah
[10:32] <lifeless> jelmer: yes, I understand that.
[10:33] <lifeless> AnMaster: we jumped to 0.90 because some people judge 'progress' by 'how close to MAJOR.0'
[10:33] <AnMaster> fullermd, /usr/ports/www/trac-bzr/pkg-descr says http://bazaar-vcs.org/TracBzr
[10:34] <lifeless> AnMaster: and while we were happy moving point release by point release, it wasn't clear to folk casually perusing, how mature a project this is.
[10:34] <AnMaster> lifeless, ah
[10:34] <lifeless> AnMaster: (we think its pretty mature)
[10:34] <AnMaster> I always find a project that jumps versions like this suspect
[10:34] <jelmer> lifeless: I think getting that changed would take a lot more time than setting up an additional list
[10:35] <jelmer> lifeless: if you really feel having an additional list is a problem, please bring it up on the bazaar list
[10:35] <lifeless> jelmer: I wasn't claiming it was a problem, I was asking why.
[10:35] <fullermd> AnMaster: Well, there aren't any fixed for that sort of problem on Aaron's branch; there's hardly anything recently.  I'm not sure if someone else's is the "main" branch now.  You could try asking on the list.
[10:35] <lifeless> it surprised me is all, and it makes more work for me
[10:35] <fullermd> (fixes)
[10:35] <AnMaster> fullermd, what list? not mailing list I hope, I hate mailing lists
[10:36] <lifeless> jelmer: so enough said, nothing to see here, moving right along
[10:36] <fullermd> AnMaster: Oh.  Well, forget I said anything, and poke Radim them   :] 
[10:36] <AnMaster> fullermd, and where do I get hold of him?
[10:36] <fullermd> cd /usr/ports/www/trac-bzr/ && make -V MAINTAINER
[10:37] <AnMaster> ah
[10:39] <lifeless> phanatic: good to see you around again ;)
[10:40] <abadger1999> AnMaster: I have patches to make those changesets slightly less wierd.
[10:40] <AnMaster> abadger1999, oh?
[10:40] <abadger1999> AnMaster: Let me dig up the launchpad bug
[10:40] <AnMaster> :)
[10:41] <fullermd> Oh good!
[10:41] <abadger1999> AnMaster: https://bugs.launchpad.net/trac-bzr/+bug/116659
[10:41] <ubotu> Launchpad bug 116659 in trac-bzr "Phantom changesets in timeline" [Undecided,Confirmed] 
[10:41] <abadger1999> I've been working on the assumption that abentley's branch is canonical.
[10:41] <AnMaster> abadger1999, hm
[10:41] <phanatic> lifeless: thanks, but actually reviewing patches and managing a release takes more time than just hacking :)
[10:42] <AnMaster> I think I will mail ports maintainer either way
[10:42] <AnMaster> so everyone can make use of it
[10:42] <abadger1999> yeah.  It would be good.
[10:42] <fullermd> Hm.
[10:42] <fullermd> hsn_: Around?
[10:42] <lifeless> phanatic: indeed it does
[10:43] <hsn_> fullermd: yes
[10:43] <fullermd> hsn_: Oh good.  See above discussion about trac-bzr port compatibility with current bzr.
[10:44] <fullermd> Quicker than email   :] 
[10:45] <jelmer> lifeless: Sorry, you said it takes more time for you, that's why I figured you considered it a problem. Anyhow, I'll let it rest.
[10:48] <AnMaster> abadger1999, sent mail to trac-bzr maintainer
[10:49] <abadger1999> AnMaster: Cool -- I think hsn_ is that maintainer :-)
[10:49] <AnMaster> abadger1999, sent it to output of that command fullermd gave me
[10:49] <AnMaster> but yes hsn was in the mail
[10:50] <hsn_> abadger1999: you think right
[10:50] <AnMaster> hsn_, got my mail right?
[10:50] <lifeless> jelmer: it does, but I patch bzr-gtk what, once a month? If that? So I'll ignore it until my next patch, if its more convenient for the folk doing the coding that is the important thing.
[10:50] <AnMaster> yet*
[10:51] <AnMaster> btw, does source forge support bzr? I don't really like launchpad, it is slower than sourceforge even (and that is pretty slow) and it looks ubuntu-ish, and is confusing
[10:52] <fullermd> In theory, you could just host the bzr files in project webspace.  I suspect it's probably at least moderately frowned on, though.
[10:52] <dato> AnMaster: bzr can be served over a normal http server, so there you go
[10:52] <abadger1999> hsn_: Cool. I'm packaging trac-bzr for fedora so if we need to work on standardizing on someone's branch as canonical or cooperating on getting bugs fixed feel free to ping me.
[10:52] <AnMaster> dato, hm true
[10:53] <AnMaster> dato, but does pycurl fail at bzr branch http://kuonet.org/~anmaster/bzr/envbot for anyone but me
[10:53] <AnMaster> some users reported problems
[10:53] <AnMaster> lighttpd on freebsd
[10:53] <fullermd> SF is probably better connected (depending on where you are).  A lot of the slowness may be just bzr, though...
[10:53] <AnMaster> it works with urllib
[10:54] <AnMaster> fullermd, yes pushing almost half a minute to my current web server
[10:54] <jelmer> lifeless: But why is it more work? subscribing takes less than a minute
[10:54] <AnMaster> but anyway, why is pycurl broken for that site
[10:55] <lifeless> jelmer: subscribing, managing the mail to a new folder, remembering to check that folder, remembering to send to a different list, moving discussion cross-list as needed
[10:56] <fullermd> AnMaster: Hard to say, probably.  pycurl will probably have somewhat different characteristics (request rate and accel, number pipelined, number keepalive'd, blah blah) than urllib.  What about it is significant, though..
[10:57] <AnMaster> fullermd, a user who did some debugging said it somehow borked with certain range requests
[10:58] <lifeless> hmm
[10:58] <lifeless> perhaps we should make disabling pycurl easy without uninstalling it
[10:59] <lifeless> vila: ^ ?
[10:59] <fullermd> I thought we had a discussion just last month-ish about turning off default-enable-if-found on it, and just saving it for explicit http+pycurl
[10:59] <lifeless> AnMaster: we've had a bunch of issues with lighthttpd IIRC
[10:59] <lifeless> fullermd: sounds vaguely familiar
[11:00] <lifeless> AnMaster: or some http server, sending bad range responses
[11:00] <lifeless> failing to serve our requests ok
[11:00] <lifeless> and this forces us to fallback to slower means
[11:00] <lifeless> or error
[11:00] <lifeless> bbiab
[11:01] <AnMaster> lifeless, ah
[11:01] <AnMaster> lifeless, for now I tell my users to use http+urllib://...
[11:02] <fullermd> I think in the current state, urllib is generally preferable anyway, so you don't lose much that way.
[11:02] <AnMaster> hsn_, so, how long can it take to get a fixed version into ports? :)
[11:03] <hsn_> AnMaster: if you submit patch, it can be quite fast
[11:04] <AnMaster> hsn_, I sent a link to the patch yes in my mail to the maintainer
[11:04] <AnMaster> :)
[11:04] <AnMaster> and that was you
[11:04] <hsn_> did you tested patch?
[11:05] <AnMaster> hsn_, not yet I sent a link to the bug report to be exact
[11:05] <AnMaster> but I will test in a bit
[11:05] <AnMaster> once I find out how to patch this in the correct way to test it
[11:05] <hsn_> ok. test it and report it back to me
[11:05] <AnMaster> I don't know, should I edit the port?
[11:06] <hsn_> yes, edit port
[11:06] <AnMaster> hsn_, or how to do it without making package manager loose track?
[11:06] <AnMaster> hsn_, um, and what with portsnap do then?
[11:06] <hsn_> put patch in files/ directory
[11:06] <fullermd> AnMaster: Copy the port dir somewhere else (in /tmp, say) and work on it there.  It doesn't have to be under /usr/ports to work.
[11:06] <hsn_> recompile port, test, install porttools and do port submit
[11:06] <AnMaster> fullermd, oh? cool
[11:06] <fullermd> Then you can diff against the 'main' one to gen the patch.
[11:06] <AnMaster> hsn_, hm
[11:07] <fullermd> 's how I do it (actually, I cvs co from my local CVS mirror in /tmp, but 6 of one, half a dozen of the other...  either way)
[11:08] <AnMaster> hsn_, um, I got to sleep now, it is late here
[11:08] <AnMaster> I will do it tomorrow
[11:37] <mgedmin> I can't use bzr diff to look at my changes while I'm editing the commit message for bzr ci?
[11:38] <jelmer> phanastic: ok, pqm is up at http://145.97.196.157:8089/
[11:57] <james_w> mgedmin: no you can't I'm afraid. With 0.91 you can use bzr ci --show-diff to get the diff in the message editor.