#bzr 2008-07-07
 * Foskasse JÃ¡ tenho (sqrt(350)-0.7082869*cos(20)-0.4192478) ANOS!
 * Foskasse Happy birthday to me guys!!
<lifeless> hi
<mwhudson> hi lifeless
<mwhudson> lifeless: isn't it like 3am for you now?
<lifeless> 4
<bob2> ep?
<lifeless> GYADEV
<mwhudson> lifeless: eurg
<Odd_Bloke> lifeless: Ah, are you at GUADEC?
<Odd_Bloke> I'll take 'GYADEV' as a 'yes'. :p
<lifeless> yes
<lifeless> Currently jetlagging; and waking up jamesh
<mwhudson> lifeless: just woke up, or still awake?
<lifeless> just woke \
<lifeless> poolie: on NEWS (420MB corpus), bit of a pathological case perhaps:
<lifeless> gaip it all: 136MB
<lifeless> bzip it : 36MB
<poolie> hello lifeless
<lifeless> our knit hunks in bzr.dev: 4.5MB
<poolie> did you mean gzip?
<lifeless> 7zip(lzma) the 420MB as one file ccatted together - 215KB
<lifeless> poolie: yes
<lifeless> git repacking at 200,200 638KB
<bob2> how about rzip?
<lifeless> my first attempt with my new compressor: 600KB
<lifeless> bob2: dunno
<lifeless> and its outputting some really badly chosen sequences thanks to sequence matcher
<lifeless> lp:~lifeless/+junk/bzr-groupcompress
<Odd_Bloke> A gnome-terminal extension that made those clickable would be awesome.
<poolie> lifeless: nice
<poolie> or an irc bot that expands them to http url
<mwhudson> can i rename a thread in a loom?
<lifeless> mwhudson: there is a bug, I would love a ptch
<lifeless> mwhudson: it includs the workaround
<lifeless> call to prayer has just starter
<mwhudson> lifeless: i can't find the bug, although https://bugs.edge.launchpad.net/bzr-loom/+bug/203287 and https://bugs.edge.launchpad.net/bzr-loom/+bug/203203 are relevant to what i'm trying to do
<ubottu> Launchpad bug 203287 in bzr-loom "unable to create a new bottom thread" [High,Triaged]
<lifeless> mwhudson: basically make a new thread called newname and delete oldname
<mwhudson> lifeless: but i want to create a new bottom thread
<lifeless> mwhudson: you want to rename the bottom thread?
<mwhudson> lifeless: yeah
<lifeless> so do what I said
<mwhudson> well, i just started again, the loom was about 10s old
<lifeless> mwhudson: switch bottom && create-thread foo && swtich bottom && combine-thread
<mwhudson> lifeless: ah right
<lifeless> wooo
<lifeless> new version;
<lifeless> 360181
<lifeless> and 0.5 seconds to get it back
<lifeless> which is 0.03 seconds slower than bzr.dev
<lifeless> pushing now, trying to sleep again
<Odd_Bloke> lifeless: Sleep well!
<alecwh> I'm trying to push to a repository, and I'm getting this error: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ephpns-team/phpns/head/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<alecwh> the command I used: "bzr push lp:phpns"
<mwhudson> bzr launchpad-login
<alecwh> No Launchpad user ID configured.
<alecwh> How do I fix this?
<bob2> bzr launchpad-login yourlaunchpadusername
<alecwh> mwhudson: bob2: Thanks a bunch, that worked!
 * arjenAU prods igc
<lifeless> poolie: how is stacking landing going?
<stewart> i'm having an issue. bzr serve using recent 1.6 tree on linux, trying to "bzr branch" from the server on a Windows XP install of 1.5 and getting "Could not understand response from smart server: ('error', ",module' object has no attribute 'SmartServerRepositoryStreamRevisionsChunked'')
<spiv> stewart: hmm, sounds like a bug.  1.5 is the version on the server?
<poolie> hello lifeless, i'm debugging the anotate failures atm
<poolie> arjenAU: he's sick today i think
<stewart> spiv: no, 1.5 is client.
<poolie> or away anyhow
<arjenAU> poolie: he's awake and talking to me anyway ;-)
<spiv> stewart: ah, hmm.  I'll just take a look
<arjenAU> poolie: but tnx
<stewart> spiv: i'm pulling latest dev tree for server now, i'll see if that helps.
<spiv> stewart: I see the bug, and it's still in bzr.dev
<spiv> stewart: I'll just send a patch to fix it, thanks for the report!
<stewart> spiv: cool. easy fix by any chance?
<stewart> spiv: can you cc me on the patch? stewart @ mysql dot com
<spiv> Yeah, just deleting some lines from bzrlib/smart/request.py
<spiv> (We unimplemented some RPCs in 1.6 as part of the fallout from the VersionedFiles reworking Robert did.  Performance impact should be minimal for pack format repositories.)
<spiv> stewart: I'll do that.
<stewart> spiv: thanks!
<stewart> will try patch as soon as i receive it.
<spiv> stewart: sent
<arjenAU> stewart: can you be on im?
<stewart> arjenAU: yepp... am now
<arjenAU> good lad
<stewart> spiv: now i'm getting (on client) "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this)". Is that intentional?
<spiv> stewart: heh.  Yes, although that is a bit confusing it's unavoidable I think.
<stewart> spiv: well, at least it's doing something now. i'll see how long the branch takes
<spiv> stewart: thanks.  Let us know if it takes noticeably longer than having 1.5 on the server.
<stewart> spiv: no disk space has been used on client yet :(
<spiv> stewart: is that worse than before?  Damn.
<stewart> spiv: haven't tried explicitly with 1.5 server... but would have expected quicker.
<spiv> You could try "bzr -Dhpss ..." instead of "bzr ..." and looking at the ~/.bzr.log to see what it's doing.
<spiv> Hmm...
<stewart> spiv: it's a mysql tree, generally, over the internet branching it should take about 20mins. the majority of that being at about full speed of the network link. Now it's transferring something though... but only at up to about 200k/sec
<stewart> sometimes bursts...
<spiv> If it is dropping back to the <1.2 RPCs, it's probably going to take longer fetch graph data.
<spiv> Part of the reason for the protocol changes in 1.6 is so we don't need unnecessary reconnections with mismatched client/server versions in future.
<stewart> spiv: at least it's going... but not fast. at least, i'd expect faster considering on local network.
<spiv> stewart: yeah, that doesn't sound good.  I think 1.5 is figuring that if the server doesn't support streaming pull, it also doesn't support get_parent_map
<stewart> spiv: it's getting data now... but only 82.3MB so far
<spiv> Streaming pull shouldn't matter too much with a pack repo, but get_parent_map still does.
<spiv> (Especially if the repo hasn't been packed recently)
<stewart> spiv: there's 15 pack,s one of which is 550MB
<spiv> Some friction is unavoidable when client and server are different versions :/
<stewart> spiv: yeah, no doubt. perhaps when 1.6 windows installers are up it'll be better...
 * spiv nods
<stewart> hopefully branching subsequent branches into the repository is a lot faster
<spiv> I think mhammond posted a test 1.6b3 installer to the list.
<spiv> Yeah, it should be.
<stewart> 113MB now
<spiv> Upgrading the client will definitely help, when that becomes possible for you.
<stewart> spiv: is this what you meant: http://www.nabble.com/Experimental-1.6b3-windows-binaries-available-td18168374.html
<spiv> Right.
<AfC> Oh, for the love of...
<AfC> Launchpad: The URI scheme "bzr" is not allowed.  Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp ... This is the external location where the Bazaar branch is hosted.
<AfC> (when trying to add a remote branch)
<andrea-bs> AfC: you have to use bzr+ssh:// or lp: , not bzr://
<AfC> Ridiculous.
<stewart> spiv: tried with new version. instead getting "socket.error: (10055, 'No buffer space available')". so this time it doesn't work at all :)
 * stewart will try rebooting the windows client vm... it did say to do that in the installer...
<spiv> stewart: woah!
<stewart> darn non-operating operating systems
<spiv> stewart: That's surprising.  I thought we'd squished all those.
<spiv> And I wouldn't have expected the changes in 1.6 to cause that.
<spiv> stewart: please file a bug with a traceback for that
<stewart> spiv: will do.
<spiv> stewart: past experience with that error suggests we know what to do about it once we get a traceback :)
<stewart> will just double check
<stewart> spiv: filed at https://bugs.launchpad.net/bzr/+bug/246180
<ubottu> Launchpad bug 246180 in bzr "no buffer space available" [Undecided,New]
<spiv> stewart: Thanks!
 * spiv heads to the shops
<stewart> now to go back to 1.5 so i can actually get the source tree there
<arjenAU> stewart: funny how your bug ended up here and mine did not. it's #246178 also for bzr
<stewart> joy... i just have to swear at windows a lot now...
<stewart> gah
<mathrick> so, what is the proper way of accessing bzr from non-python languages
<beuno> mathrick, one way is using the xmloutput plugin
<lifeless> beuno: hiya
<beuno> lifeless, evening!
<AfC> Ah, Launchpad, crashing my browser. I love it.
<siretart> is there an easy (scriptable) way to report the latest revision of the current branch?
<siretart> with revid, that is
<spiv> bzr revision-info
<RAOF> siretart: There was also a recent blog post about incorporating bzr into the build process; there was a bzr command to substitude various branch info in a string.
<RAOF> Ah, right.  bzr version-info is what I'm thinking of.
<siretart> aah, that's cool. thanks
<mathrick> beuno: mhm, and is there some more systematic approach to calling into python from outside
<mathrick> ?
<beuno> mathrick, well, I suppose that depends on the language, it's bindings, etc
<mathrick> beuno: yeah, but how do you bind from, say, C to python?
<beuno> mathrick, I wouldn't know  :)
<mathrick> particularly I'm interested in common lisp -> python, but C is good enough, I can manage from there
<mathrick> beuno: oh
<mathrick> so you were just saying without any actual background?
<mathrick> I mean, the bindings etc. need to work somehow
<mathrick> I guess it's #python time
<beuno> mathrick, sounds like something outside of bzr's scope, yes
<Odd_Bloke> poolie: We could do with having a chat.  I'm currently pretty much on GMT+7 sleeping patterns, so sometime tomorrow morning for you would be best (as I'm pretty tired and about to head bedwards).
<poolie> heh me too :)
<poolie> well, not sleep, but go offline
<lifeless> spiv: ping
<Laibsch> How do I merge two bzr branches?  "bzr branch $branch1;cd $branch1;bzr merge $branch2" tells me that revision $XY is not present in object $YZ
<Laibsch> The two branches are unrelated as far as bzr is concerned, there is no common ancestor or something like that
<markh> Let's say I made a branch of bzr.dev, made local commits and pushed it to a *new* branch.  What is the fastest way to get a diff against the original branch?
<AfC> bzr diff -r ancestor:../path/to/branch
<AfC> Can be quite useful
<AfC> bzr diff -r branch:../path/to/branch
<AfC> on other occasions
<markh> ah, cool, thx.  'ancestor' is a special 'keyword'?
<AfC> markh: whether that applies to you in your situation I couldn't say
<markh> it gives me a clue I didn't have, so gives me something to read up on - thx!
<AfC> markh: it's a namespace, yes. Like tag: and the others at
<AfC> bzr help revisionspec
<Stavros> hmm, bzr 1.5 crashes rather frequently :/
<Stavros> is this a known issue?
<fredo> Hello!
<Peng> Stavros: Um, details?
<Peng> Stavros: And, you mean that it exits with a traceback, right?
<fredo> Just one question: Is it possible to integrate bzr into a python application? Let's say I want to write a version controlled wiki, can I interface bzr from within my app without calling it on the command line?
<Stavros> Peng, yes, it crashed with various errors at least three times in the past two days
<Stavros> i'm reporting one of them right now
<Peng> Stavros: Good. You should report the others too. :)
<Stavros> it just crashes too frequently for comfort, even during commits :/
<Stavros> the others were reported already
<Peng> fredo: import bzrlib
<fredo> Peng: Thanks!
<fredo> Where do I find the docs for bzrlib?
<Peng> fredo: bzrlib is the entirety of Bazaar. The bzr script is just a simple wrapper that calls into bzrlib.
<fredo> Ah, ok. Thanks!
<Peng> fredo: Um, there are API docs somewhere. There's also other stuff in doc/ in the source and the website.
<fredo> I'll have a look into this.
<fredo> Yes, I think I found the API doc.
<semslie> quick question about bzr-svn: I have some branches that were checked into subversion via bzr-svn (for the purposes of working with the other members of our team). I've noticed that when those branches are checked out into a new repository then "bzr visualise" doesn't show the branch history, but rather one flat line of history. However it obviously does know about its branch-point, because merging that branch into another will produce the correct history. 
<jelmer> semslie: It doesn't push the right hand side revisions, though it does know about them
<AfC> jelmer: do you have a minute? (pm)
<jelmer> AfC, yeah
<AfC> k
<LarstiQ> stewart: out of interest, which bugs are those?
<Peng> Oh, look. I've been having a problem with bzr-svn for a couple days, and I was just abotu to report it, but it works correctly now. :)
<LarstiQ> ehm
<semslie> jelmer: okay, I think that makes sense with that I'm seeing
<LarstiQ> s/stewart/Stavros/
<jelmer> semslie: if you pull in the changes from elsewhere (the original bzr branch for example) it will show them
<LarstiQ> jelmer: when are you at guadec?
<jelmer> LarstiQ: didn't make it
<semslie> jelmer: the situation is that a work mate is getting interested in all the bazaar activity and gave it a try. The visualisation tool gives a tangible sense of the activity that has been taking place on the bazaar side, so he was a bit disappointed not to see it straight away.
<LarstiQ> jelmer: hokay
<LarstiQ> jelmer: I have a free bed here at EP ;)
<Peng> Cool, bzr-svn is importing tags now too. :)
<jelmer> semslie: see also bug 158883
<ubottu> Launchpad bug 158883 in bzr-svn "ability to push non-lhs revisions" [Wishlist,Triaged] https://launchpad.net/bugs/158883
<jelmer> LarstiQ: :-)
<semslie> jelmer: nice to see its on the list. what are the challenges in pushing non-lhs revisions?
<jelmer> semslie: They can't be pushed to the same location as the lhs revisions
<jelmer> semslie: Since they don't have the same ancestry
<jelmer> semslie: So they have to be pushed to /branches/foo
<semslie> jelmer: so is it not just a case of storing metadata about the non-lhs revisions? I've noticed that if I made the branch in my bazaar repo, then push to svn, then check out again into the same repo then I see all the threads of activity.
<jelmer> semslie: metadata about what the non-lhs revisions are is already stored
<jelmer> semslie: the revisions themselves are just not stored
<jelmer> semslie: You'll see that if you run "bzr log --show-ids" the non-lhs revisions are mentioned
<semslie> jelmer: oh right, that makes sense and would explain why you then see those revisions as soon as they become available
<jelmer> beuno, ping
<jelmer> semslie: Yep
<beuno> jelmer, pong
<jelmer> beuno: bzr-upload was rejected due to faulty upload
<beuno> jelmer, hrm, so the DD uploaded wrong?  or was it an issue with the packaging?
<jelmer> beuno: It was uploaded incorrectly
<beuno> jelmer, ugh, I'll ping the DD and nag then, sorry
<jelmer> beuno: No worries, the sponsoring is much appreciated :-)
<lifeless> Jc2k: ping
<Jc2k> lifeless: pong
<lifeless> Jc2k: so, JFDI huh? thought thats what we were doing :).
<Jc2k> lifeless: they dont know that yet
<Jc2k> i mean, we still need to jfdi for the supporting stack
<Jc2k> wrong words
<Jc2k> we need to fix bkors stuff :)
<lifeless> Jc2k: totally; thought I get the impression hes given it a go and it just worked :)
<lifeless> Jc2k: e.g. bonsai -> bzr-search :)
<Jc2k> eh
<lifeless> s/thought/though
 * Jc2k looks forward to "Bazaar JFDI" post :)
<lifeless> we need the precommit hooks trasnscribed
<Jc2k> where are you guys at?
<Jc2k> have retreated to hotel to hack for a bit
<lifeless> I'm in the vcafeteria getting power
<lifeless> the evolution talk was interesting
<Jc2k> ahh i think i'd already left
<Jc2k> DVCS DVCS Swag taxi hacking :)
<lifeless> Jc2k: :)
<lifeless> Jc2k: you're at the golden horn ?
<Jc2k> lifeless: about 5 minutes away at hotel aslan
<lifeless> in sultanahmet
<siretart> is there a shortcut for 'bzr revert file -r"the branch I'm merging from"'?
<siretart> in case of conflicts, that is
<Peng> siretart: You can use the .OTHER file.
<james_w> siretart: "mv file.OTHER file" ?
<james_w> siretart: but other than that I don't think so (e.g. if you have resolved the file, or there weren't conflicts in the first place)
<lifeless> Jc2k: cool
<siretart> james_w: Peng: that doesn't resolve the 'conflited' state
<Peng> siretart: Yeah, then you need to run bzr resolved $file.
<siretart> Peng: bzr revert doesn't require that. but it is rather clumsy to loop up 'the other' revision id
<quicksilver> maybe there shuld be
<quicksilver> bzr resolve-other FILE
<quicksilver> bzr resolve-this FILE
<quicksilver> would be a trivial plugin.
<siretart> bzr resolve --other would do it, I think
<jelmer> Laibsch, ping
<mathrick> jelmer: bzr: ERROR: Repository KnitPackRepository('file:///home/mathrick/Dev/python/.bzr/repository/') is not compatible with repository SvnRepository('svn+ssh://maciek@svn.gnome.org/svn/epiphany-extensions')
<mathrick> which one is compatible?
<jelmer> mathrick: bzr upgrade --rich-root-pack
<mathrick> aha, thanks
<mathrick> jelmer: humm, how do I make the shared svn / bzr checkout?
<jelmer> mathrick: How do you mean?
<mathrick> jelmer: I want a dir that's both a valid svn working tree and a bzr branch
<jelmer> mathrick: You mean something that has both a .bzr and .svn subdirectory ?
<jelmer> you need to pass --no-plugins to bypass bzr-svn to do that
<mathrick> jelmer: or alternatively, if I bzr commit to an svn working tree, will it do what I want?
<jelmer> mathrick: Yes, committing in a svn working tree should work
<mathrick> jelmer: good, and what happens if I svn up it behind bzr's back?
<jelmer> that will work as well
<mathrick> cool
<jelmer> the only two things that don't work are merge and revert
<mathrick> so bzr ci will be local, and svn will still work?
<jelmer> bzr ci won't be local
<jelmer> it will upload the changes to subversion
<jelmer> (since there is no local branch)
<mathrick> oh
<jelmer> if you would like to use offline commits, use a bzr branch locally
<jelmer> commit to that, and once you're done, "bzr push" into Subversion
<mathrick> jelmer: the thing is that I wanted to work on stuff I manage with jhbuild, and which is in an upstream svn repo. So I wanted jhbuild to be able to do its stuff (ie. update the checkout and compile and install things), but have it also backed up by a local branch
<mathrick> does it make sense?
<mathrick> it would be no problem to have the local bzr branch if it wasn't for the fact that it's the svn working dir the source gets installed from
<jelmer> mathrick: How hard would it be to add bzr support to jhbuild?
<mathrick> dunno, I think it already does it
<mathrick> right, I can just create a local moduleset
<mathrick> jelmer: thanks for making me think straigtht :)
<jelmer> (-:
<Laibsch> jelmer: pong
<lifeless> Jc2k: thumper would like to clone your svn update logic
<lifeless> Jc2k: can you spare some time to tell him, or jamesh about this?
<jelmer> Laibsch, Were you Rolf?
<fredp> mathrick: Jc2k has his work on bzr-mirror support for jhbuild; but it is already possible to set bzr as the program to do svn checkout
<lifeless> mathrick: also, http://bzr-mirror.gnome.org:8080/jhbuild/trunk/changes
<lifeless> mathrick: (you can just pull jhbuild from there using bzr  :)) - hmm, actally remove the :8080, thats only the web viewer
<fredp> also don't hesitate to report enhancement requests to jhbuild bugzilla
<Laibsch> jelmer: Yes
<mathrick> fredp, lifeless: ah, thanks, will look into it
<jelmer> Laibsch: I was wondering whether there would be any chance you can try reproducing bug 245763 with a later bzr-svn
<ubottu> Launchpad bug 245763 in bzr-svn "svn import fails" [Undecided,Incomplete] https://launchpad.net/bugs/245763
<Jc2k> lifeless: sure
<Laibsch> jelmer: later than 0.4.9-1?  Where to get it for hardy?
<Laibsch> well, actually debian sid
<Laibsch> this was on a remote machine
<jelmer> Laibsch: Debian sid has 0.4.10-2 now
<Laibsch> OK, I can try that
<Laibsch> once I get a connection ;-)
<Laibsch> right now the machine seems to be down
<lifeless> Jc2k: we're heading to hotel now; but perhaps you could mail the scripts etc to them?
<fredp> is there any tool like cvs2cl or svn2cl, to produce a ChangeLog from bzr history?
<fredp> bzr log --log-format=changelog would sure be nice.
<jelmer> fredp: there is a plugin that does that I think
<jelmer> It's probably listed on the plugin page (http://bazaar-vcs.org/BzrPlugins)
<fredp> GNU changelog formatter for bzr log
<fredp> nice
<fredp> google had a lot of noise
<jelmer> Laibsch: no hurry :-)
<Laibsch> I'm afraid you might need to remind me
<Laibsch> The machine is still down
<jelmer> k, will do
<CyberSnooP> Hi everyone. Am I supposed to be able to create tags in an bzr svn checkout?
<jelmer> CyberSnooP: only when using the 0.4 branch, not in any released version
<CyberSnooP> Ah, okay. Spend some time in the wiki, but couldn't find it as a limitation
<jelmer> there is an open bug report about it
<kdehoff> Hi.  I need to run an odd setup and I'm not sure if it's even possible.
<leo2007> is there any convention how to write a log entry when checking in using BZR
<jelmer> kdehoff: ?
<kdehoff> I'm attempting to set up a set of repositories on an old sun server
<CardinalFang> leo2007, for what project?
<kdehoff> They need to be accessed from within and outside of a firewall, with HTTP/S being the only transport optin
<kdehoff> But the users want to control who can and cannot read and/or write to their files
<leo2007> just for general guideline, CardinalFang
<kdehoff> From the documentation, it doesn't look promising, but access control isn't really touched on much
<CardinalFang> leo2007, generally, make sure your log audience understands what you're doing.
<james_w> leo2007: there isn't a general one, but keeping a short first line summary makes for better output with the line log formatter.
<jelmer> kdehoff: I think there's indeed not an awful lot at the moment
<jelmer> you may be able to use apache access control to some extend but I don't have experience with that
<kdehoff> So for the HTTP server, the files are generally served as any other web page?
<leo2007> james_w: thanks
<jelmer> kdehoff: there are several methods
<jelmer> kdehoff: you can use webdav to upload to .bzr/ using the webdav plugin for Bazaar
<jelmer> kdehoff: or you can use the smart server which I think relies on mod_python
<jelmer> kdehoff: with the webdav plugin you should be able to control who can read/write to a particular branch
<jelmer> kdehoff: it wouldn't allow access control within the branch
<jelmer> I'm not sure whether something like that is also possible with the smart server, it may well be
<jelmer> the smart server will most likely be faster than the webdav plugin
<jelmer> also, the smart server works out of the box for all clients whereas webdav would require the clients to install the webdav plugin first
<kdehoff> would the apache "user" need write access for the smart server?
<jelmer> I think so
<Pieter> Jc2k: was the meeting bad?
<james_w> hey rockstar. You were after me the other day, sorry I missed you. Was it anything I can still help with?
<alf> Hello
<alf> I was wondering what is the recommended way of handling trivial changes to a project
<alf> eg is it better to have a 'trivial' branch instead of creating a feature branch for each small change
<alf> or perhaps commit directly on the trunk?
<beuno> alf, a trivial branch sounds fine
<beuno> but it's so cheap making branches in a shared repo, I usually just do a branch
<alf> beuno, thanks, what about changing the (local branch of) trunk directly (svn style)
<beuno> alf, well, that's cheaper I suppose, although for the workflow I have, that doesn't work
<beuno> I have a branch of trunk locally
<beuno> and pull regularly
<beuno> and I don't change it so I don't have to merge
<alf> beuno, you mean you don't have to merge with the remote trunk, just push?
<beuno> alf, right, I pull a copy locally
<beuno> and merge that into other branches
<alf> beuno, and when you wang to publish changes you merge them directly to the remote trunk or through the local copy?
<beuno> alf, I merge trunk into my feature branch, and push that branch into the mainline
<beuno> I basically keep a mirror of trunk locally
<alf> beuno, thanks, there are so many ways of using bzr and finding your own way can be a challenge :-)
<beuno> alf, yeah, you may even find more then one that fits you well
<alf> beuno, perhaps it would be useful if some of the experienced users/developers published their own ways (eg in the bzr wiki) so that newer users can see some alternatives
<beuno> alf, there was a thread on the mailing list recently...
<beuno> let me dig that up for you
<beuno> hrm, can't find it
<jelmer> beuno: if you have some time, any chance you can do more bzr-gtk reviewing?
<beuno> jelmer, sure, I'll try and do some later tonight
<alf> beuno, it's ok, i'll take a look myself and perhaps send an email to the list
<jelmer> beuno: Thanks :-) I'll see if I can do that release at the end of the week
<alf> beuno, you have been very helpful, thanks
<beuno> jelmer, sounds great. I'll still be distracted this week, but hopefully I'll get some time in the hotel
<beuno> alf, my pleasure
<Verterok> beuno, jelmer: hi
<jelmer> Verterok, hi!
<beuno> hey Verterok!
<Verterok> jelmer: thanks for bb:approve ;)
<jelmer> Verterok: You're welcome :-) bzr-svn already uses that functionality if it's present
<Verterok> nice! :)
<mwhudson> hello
<jelmer> mwhudson!
<mwhudson> this seems a bit ominous
<jelmer> oh noes, that's a dictionary word
<jelmer> mwhudson: not to worry, I only filed a few more launchpad-bazaar bugs...
<mwhudson> jelmer: oh, ok, i'm sure i'll get round to reading my bugmail folder at some point
<mwhudson> jelmer: the most recent one is a duplicate in fact
<jelmer> mwhudson: oh, ok. sorry
<mwhudson> np
#bzr 2008-07-08
<jml> poolie: hi
<poolie> jml, hi
<Odd_Bloke> Moin.
<jml> poolie: I was thinking about branches last night.
<jml> Odd_Bloke: g'day
<poolie> jml, btw i'm on leave today
<jml> poolie: oh.
<poolie> i will be around a bit
<jml> poolie: in that case I'll talk to you about branches tomorrow :)
<poolie> :)
<poolie> i am going to check on my stacking merge for a bit though
<poolie> there are still some test failures in the top of robert's loom
 * jml nods sagely
<poolie> unless he somehow fixed them
<poolie> mm
<poolie> i wish it was done
<Odd_Bloke> jml: Hey. :)  How's it going?
<jml> Odd_Bloke: well, actually.
<jml> Odd_Bloke: I'm experimenting to see if rememberthemilk is better than emacs for my nefarious purposes.
<Odd_Bloke> poolie: When you're next free, I'd like to have a chat. :)
<poolie> Odd_Bloke: how about this time tomorrow?
<Odd_Bloke> poolie: Sure, that should be fine.
<tro> with bzr-loom, is it possible to merge the changes in the upper thread down? when i use combine-thread it just tosses my changes
<spiv> tro: you could do "bzr merge -rthread:THREAD-NAME"
<tro> ah
<tro> i'll try that. what does bzr record do?
<spiv> It saves the state of the loom (i.e. the current threads and what revisions they are at).
<tro> when would i use it? after commits? or only when i move from one thread to another?
<tro> bzr merge -rthread:initial
<tro> bzr: ERROR: No location specified or remembered
<spiv> Just before pushing, basically.
<tro> ah ok
<tro> the same error occurs when i do just "bzr merge -r thread:"
<spiv> Oh,
<spiv> "bzr merge -rthread:initial ."
<spiv> Merge needs a location, not just a revisionspec.
<spiv> I just tested, and that does work.
<tro> indeed. thanks
<tro> loom comes in useful, when working with source inside an environment, which is tedious to set up
<spiv> The idea with record is that eventually it'll facilitate merging looms; i.e. if someone branches off your loom, and makes changes including adding/combining threads, you'll be able to merge their loom state back into yours nicely.
<tro> o neat
<spiv> I don't think that's fully ready yet, but looms are already very useful :)
<tro> is there a reason why creating a new thread and then merging it back into the original results in the revision number having not one but two more decimal points?
<tro> ie. rev 1 -> rev 2 -> rev 2.1.1 > rev 3
<tro> 2 is the branch point
<spiv> tro: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers
<tro> ok thanks
<spiv> It's not specific to looms, that's how bzr revision numbering works in general.
<ozzloy> please help http://pastebin.org/49528 what am i doing wrong?
<RAOF> ozzloy: You're merging from the wrong directory.
<ozzloy> so i am
<RAOF> bzr push sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/avk/itms ... Merging from remembered location sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/itms/
<spiv> ozzloy: as RAOF says, there's a missing "avk/" in the remembered location.  Do "bzr merge --remember sftp://ozzloy.lifeafterking.org/~/public_html/avk/itms"
<ozzloy> hooray!
<ozzloy> that was a tad slow, but yay!
<ozzloy> something to work on tomorrow.  thank you!
<hypatia_> Probably tedious licencing question: does Bazaar really regard its logo as GPL? There have been uploads to Wikimedia on that basis: http://commons.wikimedia.org/wiki/Image:Bzr.jpg http://commons.wikimedia.org/wiki/Image:Bzr_icon_64.png
<hypatia_> The logo files no longer seem to be in the source tarballs and the bazaar-vcs.org website seems to be all rights reserved.
<Odd_Bloke> hypatia: Why do you ask?
<hypatia> Odd_Bloke: A couple of reasons, all related to Wikimedia Commons. If those files aren't Free, they can't be on Commons, that's one reason. The other is that if the logo is GPLed, Commons should use the SVG version.
<hypatia> The current justification for them being on Commons is that, apparently, as of the beginning of 2008 they were included in the tarball of Bazaar itself, which has a LICENCE file saying it's GPL. The logo files are no longer in the repo that I can see.
<hypatia> If they ever were, I have not searched the history yet.
<spiv> hypatia: FWIW, I don't see a logo in the bzr-1.1 tarball, which was released mid-Jan 2008.
<jelmer> hmm, would be nice to have some clarification about that
<hypatia> spiv: I am currently running bzr log on your laptop, so we'll see.
<jelmer> bzr-gtk still ships them
<spiv> Heh.
<spiv> Unfortunately poolie isn't around today.
<Odd_Bloke> If they aren't free, they should be.
<spiv> Odd_Bloke: yeah
<hypatia> They are not in Ubuntu's .deb of bzr.
<Odd_Bloke> Else Debian'll have to package bzr as IceMarket.
<jelmer> any nested tree gurus around?
<spiv> Odd_Bloke: heh
<jelmer> The serializer appears to forbid reference_revision to be None, but other parts of the code seem to assume that's a valid value
<jelmer> LarstiQ_: pingz0rz?
<Odd_Bloke> Is packages.ubuntu.com being unresponsive for anyone else?
<bob2> yes
<Odd_Bloke> OK, I just found an Ubuntu mirror and looked at the diff.gz, which saved time. :p
<lifeless> moin
<Verterok> hi lifeless
<hypatia> Looks like the bzr repo has never contained the logo.
<chandlerc> how can you do a non-destructive revert after adding a file you don't want versioned?
<spiv> bzr rm --keep FILE
<chandlerc> --keep might be a nice flag for bzr revert
<chandlerc> but thanks, that worked like a charm
<spiv> Although bzr rm will not delete the file if bzr thinks there might be uncommitted changes to it.
<mwhudson> hi lifeless
<chandlerc> will bzr revert?
<chandlerc> that would be unfortunate default behavior, but it was what the help indicated would happen
<chandlerc> =/
<spiv> bzr revert won't delete an uncommitted file either (You can test for yourself with "bzr init foo; cd foo; echo hello > hello.txt; bzr add; bzr revert")
<chandlerc> ahh
<chandlerc> the basic "bzr help revert" didn't indicate that behavior clearly to me
<chandlerc> but good to know! =] that's what i wanted it to do, and I had done it once, and the output seemed to indicate it was deleting files, so I was concerned
<spiv> The help text talks a bit about how it will make a backup of the file "if appropriate", which sort of hints that it's careful not to destroy your work.
<spiv> But yeah, it could be clearer.
<chandlerc> yea, i read the creating a backup to mean it *would* destructively modify the file, which is why it needed a backup
<chandlerc> and in this case, i added a *very* large directory, so going through and renaming stuff would have been... messy... ;]
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> you're about to get mail ;)
<ozzloy> spiv: RAOF:  thanks, btw
<lifeless> spiv: its queued
<Odd_Bloke> abentley: Am I right in thinking that you had some work on merge directive support in PQM somewhere?
<spiv> ozzloy: not a problem
<lifeless> spiv: mail should have reached you:)
<Odd_Bloke> If someone could add me to the list of people allowed to post to bazaar-commits, it'd be appreciated.
<lifeless> poolie: ping
<chandlerc> what provides bzrlib.knit.* stuff?
<lifeless> chandlerc: how do you mean 'provides' ?
<chandlerc> i'm getting an ImportError
<chandlerc> i have bzr 1.6b2 installed.. wondering if i need some additional libraries
<lifeless> chandlerc: you probably have a 1.6b3 version of some plugin
<chandlerc> hrm
<chandlerc> annoying... trying to follow a release branch of bzr-svn, but don't really want to be quite so bleeding edge with bzr itself
<chandlerc> highly annoying as the released version doesn't work with 1.6b2 and contains a couple of bugs fixed in the release branch
<ToyKeeper> That reminds me...  I've been meaning to fix my dual bzr/bzr.dev install setup so it doesn't try to use the wrong version of plugins.
<ToyKeeper> IIRC there was an article on an easy way to do that, if I can find it.  :)
<lifeless> jelmer: ^ see chandlerc's comment :P
<lifeless> ToyKeeper: basically, don't use ~/.bazar/pluings for ones that hace trouble, instad link them to bzrlib/plugins/ in the version you want them for
<lifeless> ToyKeeper: our export a bZR_PLUGINS_PATH
<LarstiQ_> jelmer: pongzorz
<lifeless> Odd_Bloke: ping
<lifeless> poolie: piong
<Odd_Bloke> lifeless: Pong.
<Odd_Bloke> poolie is on leave today, so probably isn't around.
<beuno> mwhudson, check out bug #237914
<ubottu> Launchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed] https://launchpad.net/bugs/237914
<beuno> :)
<AfC> Odd_Bloke: how'd you go with that PHP snippet?
<Odd_Bloke> AfC: I looked at it, thought "I'll do this later" and haven't got around to doing it yet. :p
<lifeless> Odd_Bloke: your review requests titled 'The Diff' are context-free. I'm told if you don't set a title a sensible one is chosen
<AfC> Odd_Bloke: most of it is actually about creating a listing of repositories, branches, and/or empty directories as you'd expect in a normal server generated index page. The "There's a branch here" part was pretty easy".
<Odd_Bloke> lifeless: I've been adding "The diff" via "Add a comment/review" just before using the "Request a review" button.  I'll use the "Request a review" whiteboard for the diff in future.
<Odd_Bloke> lifeless: Apologies.
<lifeless> Odd_Bloke: the problem is the tmail topic
<lifeless> Odd_Bloke: thumper says not to use the whiteboard
<lifeless> thumper says you are setting a subject; don't do that.
<lifeless> its a bug that there isa  field there IMO
<Odd_Bloke> I took my prompting for adding the diff from https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/296
<Odd_Bloke> But in future I'll leave the subject empty.
<AfC> Odd_Bloke: oh, I just realized that without the Apache config the .php I sent you is probably totally lacking in context. So, http://rafb.net/p/WihwmF64.html
<lifeless> Odd_Bloke: thumper agrees that it is all his fault, and he sucks
<abentley> Odd_Bloke: Here's my last work: http://code.aaronbentley.com/bzr/pqm
<ChristopheT> Hi!  What is considered to be a good web interface for bzr repositories?  I found "bzrweb" (http://mccormick.cx/dev/bzrweb/index.py/repositories) and webserve (https://launchpad.net/bzr-webserve).
<beuno> ChristopheT, Loggerhead is probably the most complete one
<beuno> https://launchpad.net/loggerhead
<bob2> or launchpad itself!
<james_w> hey beuno
<beuno> morning james_w
<james_w> are you in the office?
<beuno> james_w, yeap, got here a while ago
<beuno> are you here too?
<james_w> yeah, I'm hiding away in the back corner.
<beuno> ah, you sneaked in!  I got here 9am-ish, and I'm right by the door
<Odd_Bloke> lifeless: Hurrah!
<Odd_Bloke> abentley: Thanks. :)
<lifeless> Odd_Bloke: ?
<Odd_Bloke> 08:31:19 < lifeless> Odd_Bloke: thumper agrees that it is all his fault, and he sucks
<lifeless> right
<mtaylor> hey all - quick question... given a revision id, is there a _sensilble_ way to find out the tags applied to the tree _after_ that revision?
<lifeless> jelmer: ping
<mtaylor> like, if we tag releases and want to be able to determine if a particular patch went in to a particular release...
<lifeless> mthaddon: log can show tags I believe
<lifeless> meh mtaylor I mean
<mtaylor> lifeless: yes... it can
<mtaylor> lifeless: but that makes the process ... bzr log | less ... find commit, scroll back in output looking for tags...
<lifeless> mtaylor: I suggest you fle a bug wishlist wise :)
<mtaylor> hehe
<mtaylor> ok
<mtaylor> :)
<james_w> mtaylor: would 'bzr log -rrevid:foo.. | grep "tags: " | cut -d" " -f2' be considered sensible?
<james_w> mtaylor: but I agree that it would be a good thing to have
<james_w> hi lifeless
<mtaylor> james_w: well, I've just come across another snag...
<mtaylor> james_w: if I later merge from a different tree (in this case, say I'm in the 6.2 release branch and I occasionally merge up changes from the 6.1 branch)
<mtaylor> then I see those 6.1 tags in my bzr log output in the 6.2 ... which would lead me to believe that the fix is "in" 6.1.11
<mtaylor> this is silly
<james_w> mtaylor: true
<james_w> are you mainly interested in a single tag when you do this, or are you looking for all tags?
<james_w> doing it for one tag (or a list of them) is easy enough.
<mtaylor> I think if I could pass a revspec to bzr tags, this would be cake
<mtaylor> like
<mtaylor> bzr tags -r2512.78.7..
<james_w> asking "what tags is this revision an ancestor of?" is probably straightforward as well, I'm not familiar enough with the branch.tags interface though.
<james_w> I'm not sure about adding that to tags, as it would seem to be to be "list all tags that are in this revision range", not "list all tags that have the start of this range as an ancestor", which means I would expect it to return the same as the grep expression.
<james_w> mtaylor: http://pastebin.com/f3b0c221d
<james_w> try putting that as ~/.bazaar/plugins/which_tags.py and then run "bzr which-tags -rrevid:foo"
<traduffe> hello, is there any example of post_change_branch_tip for doing anything on the repository server when a new commit arrives through a push?
<traduffe> it works when i commit locally, but when i push nothing happens. i have also tried using bzr serve to no avail
<traduffe> (commit locally on the server that is)
<mtaylor> james_w: awesome... trying now
<traduffe> perhaps it is related to the message "This transport does not update the working tree of" - i get that with both bzr+ssh://, sftp:// and bzr:// (what transport am i supposed to use?)
<mtaylor> traduffe: your repository on the server should probably be created with --no-trees
<james_w> traduffe: remote transports won't do that for you.
<james_w> traduffe: your hook doesn't do what you want, or it isn't exectued at all?
<traduffe> james_w: it is not executed at all
<james_w> mtaylor: I still think a wishlist bug would be valuable, as I think this should be done right, and done in the core.
<mtaylor> james_w: cool. I'll file one if I get a chance today
<james_w> traduffe: I'm not familiar with hooks, so I'm not sure what to look at, sorry.
<james_w> traduffe: what version are you using?
<james_w> traduffe: server and client?
<james_w> mtaylor: great, thanks
<traduffe> james_w: version 1.5
<traduffe> at both sides (from the ppa launchpad repo)
<james_w> traduffe: I don't know what to say, sorry. Hopefully someone with a clue will pipe up.
<traduffe> ok!
<lifeless> Jc2k: ping
<Jc2k> lifeless: pong
<lifeless> Jc2k: wondering if we can et your procmail recipe
<Jc2k> eh, its not procmail
<lifeless> or whatever it is :)
<Jc2k> wget http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/download/6/mirror.py-20080624200612-su5368kmi8ua94bd-5/mirror.py?file_id=mirror.py-20080624200612-su5368kmi8ua94bd-5
 * Jc2k blinks at the url :)
<Jc2k> see the actions/ folder for how the {svn,bzr,git} mirrors are created/updated
<lifeless> Jc2k: thanks!
<mwhudson> yuck
<lifeless> Jc2k: we're looking at making an in-conference mirror
<lifeless> Jc2k: what do you think?
<pygi> lifeless, ping
<mwhudson> (at the url, it's too late to be clicking things)
<lifeless> pygi: hi
<pygi> lifeless, tell gnome people to stop being ignorant, and mentioning gitorious only in git context
<lifeless> pygi: right, clearly its portable to bzr :)
<pygi> lifeless, also tell them that if needed, gitorious can fully support bzr in a two-weeks timeframe
<pygi> and it will, as I mentioned in my blog post, through rvcs
<pygi> somebody just gotta get me the reason to do it
<pygi> lifeless, what me and Jc2k mentioned is far more important ... coming up with the plan on how to do all things needed for the migration
<lifeless> pygi: well, I'm doing the things
<Jc2k> lifeless: an onsite mirror? if we can get the bandwidth for an initial pull
<Jc2k> onsite branching, with bzr-avahi
<Jc2k> shit the bed.
<lifeless> Jc2k: shipping a firewire drive from london
<lifeless> Jc2k: just need a machine to plug the thing into
<Jc2k> lifeless: i'm bouncing up and down like a giddy goat
<lifeless> Jc2k: ok, cool
<pygi> lifeless, anyway, just wanted to mention that =)
<pygi> if they have any problems, direct them to me xD
<lifeless> pygi: thanks! will do
 * pygi goes back to hacking...
<beuno> james_w, let me know when you're hungry  :)
<lifeless> beuno: are you still in england?
<beuno> lifeless, yeah, I got sidetracked into working on other stuff  :)
<beuno> so I'm here til saturday
<lifeless> dang
<lifeless> I arive sunday
<beuno> yeah, all the fun starts when I leave
<beuno> that *always* happens  :p
<james_w> beuno: I was just thinking the same thing. What is there to do for food around here?
<beuno> james_w, there's pizza express, the cafe that's mostly for takeaways, or other pubs that I'm always unable to find
<beuno> lifeless, how's Guadec?
<lifeless> good; intense
<beuno> are you giving any bzr talks?
<lifeless> yes, in 40 minutes
<beuno> lifeless, good luck
<beuno> I'm off to lunch!
<lifeless> thanks!
<lifeless> Jc2k: hi
<lifeless> Jc2k: you moved a module to svn recently, for use with i10n right ?
<Jc2k> did i?
 * Jc2k blinks
<lifeless> or maybe it was someone else..
<lifeless> Jc2k: it was gnome-specimen
<lifeless> uws: ping
<lifeless> http://uwstopia.nl/blog/2008/06/gnome-specimen-now-in-gnome-svn
<lifeless> ^ - so , danilo is looking at making this work straight out of i10n
<sven> hi! i get a traceback when running 'bzr annotate file.OTHER' while merging, if file is removed locally and modified in the other branch
<sven> i can reproduce it with this: http://pastebin.com/m3837d47e
<sven> using bzr 1.5
<sven> and also 1.6b3
<_paneb> i created a branch locally, added some code, and pushed it to a remote repository. when i ssh into the remote machine, the remote branch has no working tree - is this normal?
<lifeless> sven: please file a bug
<sven> lifeless, ok
<lifeless> _paneb: yes,  totally normaly - other people can branch from this
<_paneb> ok
<_paneb> ok now i have my local mirror of the remote (trunk). i want to create a new branch for a new feature. i do bzr branch trunk feature-X locally against my mirror branch. when i do bzr log in feature-X, the branch nick is still 'trunk'
<jelmer> yes, because the commits were created in that branch
<bob2> the nick affects future commits
<bob2> 'bzr nick' will show you what it will be recorded as
<_paneb> ah
<_paneb> ok, thanks
<MvG> I just wondered, is there a way to have a single working tree switch between different branches?
<LarstiQ_> MvG: bzr switch
<MvG> Use case: large compiled project and I'm working on multiple features.
<bob2> yes, with the 'bzr switch' command
<LarstiQ_> MvG: which is useful in exactly that usecase, yes :)
 * MvG is reading switch help
<MvG> Ah, so I create a lightweight checkot initially, and then use switch to change the branch. Nice. Thanks!
<guilhembi> abentley: hello! could you please post an update in support issue 2413? A colleague hit a criss-cross merge where the merge3-per-file bzr version gives seemingly bad content conflicts, as we had already observed, and which is a problem you were working on.
<sven> lifeless, ok, i filed https://bugs.launchpad.net/bzr/+bug/246573
<ubottu> Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Undecided,New]
<MvG> jelmer: Are there any news in bzr-svn regarding fetching history explicitely for the given branch, as opposed to implicitely for each history request not contained in the cache?
<guilhembi> abentley: the colleague is Sven who is on this channel, by the way.
<lifeless> sven: tanks!
<guilhembi> abentley: he used the "bzr merge --mysql" plugin to kill those conflicts,
<_paneb> and finally, how do i create a release (export) from the remote trunk, given that it has no working tree?
<jelmer> MvG: not particularly
<guilhembi> abentley: but this feels a bit anxious, as one cannot be sure that all of them were incorrect. So we're looking forward to the full solution.
<jelmer> MvG, I've kept my svn-1.5 branch up to date with the 0.4 branch and started looking into the logic behind all this and then got distracted
<sven> hi guilhembi and lifeless! yes, would be very nice to have a solution to this! the merge --mysql thing is good, but i have to go through all the content conflict files and check the result...
<MvG> jelmer: Understandable. As long as it isn't forgotten completely, that should be all right.
<MvG> jelmer: Especially as current 0.4 branch seems to work with svn-1.5 as well, there is not that much of a hurry.
<bob2> _paneb: normally you'd use your local version of it, but bzr export takes a branch argument
<_paneb> bob2, ok, i'll use the local branch, but i did pass the branch to export
<bob2> _paneb: and what happened?
<_paneb> bob2, i inverted the branch name and archive names :P
<LarstiQ_> jelmer: you pinged me for something?
<jelmer> LarstiQ_, yeah, nested tree support
<jelmer> LarstiQ_, What's the status ? :-)
<LarstiQ_> jelmer: the same as in London afaik
<jelmer> LarstiQ_, Also, do you know whether it's possible to nest another branch
<jelmer> without specifying a revision in that branch
<jelmer> or, to word it differently, is it possible to nest the tip of another branch rather than a specific revision
<LarstiQ> jelmer: as in, always pull the latest version?
<jelmer> yeah
<LarstiQ> jelmer: I don't think so
<jelmer> crap, that makes nested trees unusable for svn:externals :-/
<LarstiQ> you think?
<LarstiQ> jelmer: ime svn:externals are mostly pinned at a specific revision.
<jelmer> It is possible to pin them, but almost nobody uses the pinning
<LarstiQ> still would like to update once in a while of course
<LarstiQ> jelmer: hmmm, our experiences conflict :)
<jelmer> in particular because the revision an external is pinned to is annoying to update
<jelmer> you have to update the external
<LarstiQ> propedit it?
<jelmer> yeah
<jelmer> well, at least that makes it easy to decide whether to wait for nested trees before I introduce that new mapping format...
<LarstiQ> ok, let met dig through the code a bit.
<awilkins> jelmer: Hello, was that log informative at all for the bindings?
<jelmer> awilkins, yeah, I just haven't had much time to look into them yet :-/
<jelmer> though some may be fixed now because of the move away from fs access
<jelmer> awilkins, Yeah, any chance you can run it again?
<jelmer> the number  of errors should've gone done quite a bit
<LarstiQ> jelmer: fs access?
<jelmer> LarstiQ: Rather than using a working copy to create revisions for testing
<jelmer> we now talk directly to the database
<LarstiQ> jelmer: ok, I'm severely lacking context
<jelmer> LarstiQ: this is in bzr-svn
<LarstiQ> jelmer: that I understood :)
<jelmer> LarstiQ: using a working copy to build revisions is quite slow
<jelmer> (an actual directory in the file system we modify and then commit in)
<jelmer> mainly because svn sleeps in between operations to avoid funny timestamp business
<jelmer> instead, we now just talk to the Subversion repository directly without using a working copy
<LarstiQ> jelmer: an svn working copy?
<jelmer> LarstiQ: yes
<jelmer> Bazaar doesn't have working copies, only working trees :-P
<awilkins> jelmer: I'll run it later, this isn't my build machine
<LarstiQ> jelmer: oh feh terminology ;P
<MvG> jelmer: Current bzr.dev and bzr-svn 0.4 repeatedly fail to branch the inkscape repo for me: ï»¿http://rafb.net/p/fvOeJD27.html
<MvG> Looks like the server became impatient and dropped the connection, but I would expect bzr-svn to reestablish connection at least once before giving up.
<jelmer> MvG: Reconnecting would be a job of the svn client library imho
<jelmer> MvG: The problem is that we don't have a good way to determine why an operation fails
<jelmer> the same error code is returned for everything that fails when using the webdav transport
<MvG> jelmer: We could examine the error message, serach for "connection.*closed" or some such.
<MvG> Ugly, I know.
<jelmer> The error message is useless since that can be localized
<MvG> :-(
<MvG> Still a dropped connection would differ from most other errors in that retrying the exactly same operation again would succeed.
<jelmer> Yeah, but that would mean adding fallback code everywhere and that seems too much for a workaround like this
<MvG> So how would you suggest I proceed? Try to implement reconnects, fall back to using svn without bzr, or bug the subversion lib devs trying to get reconnects and/or sensible error messages there?
<jelmer> well, simplest solution would just be to run the command again and let bzr-svn continue where it stopped
<jelmer> but in the end the subversion lib should be fixed first
<chandlerc> jelmer: any clue on using the 0.4 bzr-svn branch with bzr 1.6b2?
<MvG> Which I did before I wrote about "repeatedly failing" up there.
<jelmer> chandlerc: You need a newer version of bzr than 1.6b2
<chandlerc> =/
<jelmer> MvG: Try the command again as a user I mean
<chandlerc> jelmer: where would i get it from? i'd rather not run bzr right off the tip of development
<chandlerc> (if i can even do that)
<MvG> jelmer: I already deleted the branch directory and restarted the branch command from the command line. As the shared repository was still in place I had hoped it would continue there, but it seems that wasn't enough.
<jelmer> chandlerc: You would need bzr.dev for the 0.4 branch at the moment
<jelmer> MvG: If the shared repo is still there, it should be continuing
<jelmer> MvG: Does "bzr info" in the repo say those revisions are there?
<MvG> jelmer: 0 revisions. The last message from bzr-svn was "determining changes". No status message afterwards yet, seems to be still working. Not much network traffic either.
<jelmer> MvG: it may've saved the cache though
<MvG> jelmer: Yes, the cache should be complete. Command just died again. Next time around I guess I'll wireshark things.
<Odd_Bloke> Woo, I have merge-directives working in PQM.
<Odd_Bloke> In a 'has worked once for me' type of way, before anyone gets too excited. :p
<jelmer> Odd_Bloke: W00t! Congrats :-)
<Odd_Bloke> Almost entirely Aaron's work.
<chandlerc> jelmer: is running bzr.dev viable? ie, is it stable enough to use day to day?
<chandlerc> jelmer: i would gladly run the released bzr-svn and avoid all of this, but there are bugs fixed since then that I depend on. ;]
<jelmer> chandlerc: yeah, I've been doing so for the last two and a half years without any problems whatsoever
<jelmer> Odd_Bloke: Still, this is nice to finally have
<Odd_Bloke> jelmer: Yeah. :)
<MvG> jelmer: OK, the network is busy all the time with PROPFIND requests. Not much of throughput, so it didn't show up on my network usage docklet. I got a gdb stack trace somewhere in between, and it lists ra_get_dir as the function called from python, but as the error message indicates _fetch_switch instead, I'd rather assume the issue to occur in the switching code. Can you reproduce the issue?
<jelmer> MvG, what's the url exactly?
<MvG> jelmer: http://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk is the branch, http://rafb.net/p/fvOeJD27.html my error command line and error message.
<jelmer> MvG: You know about -Dtransport?
<MvG> jelmer: In theory yes. Should I try to get a log for this?
<jelmer> MvG: I suspect this is just the server being a pain
<jelmer> so far everything is working smoothly here though
<MvG> jelmer: Do you have any idea what bzr-svn is doing all the time here? It prints a progress bar about determining what revisions to fetch, that bar vanishes about halfway through, and afterwards I see nothing and the code calls those get_dir things and issues PROFIND requests for various dirs. SHouldn't all that information be available form the log?
<jelmer> MvG: It's figuring out what revisions are present in Subversion and which ones are missing in bzr
<jelmer> MvG, it needs to look at the file properties of a path to figure out what its revision id is
<MvG> So basically it's asking the server for each and every dir in the tree to tell it what files are present and what revisions IDs they have? I thought revision IDs were a bzr thing.
<jelmer> MvG: It's only looking at the file properties of the branch itself
<jelmer> so /trunk usually
<jelmer> MvG: But revision ids have to be preserved when pushing revisions into Subversion
<MvG> jelmer: My wireshark capture says otherwise.
<jelmer> and they're stored in file ids
<jelmer> s/file ids/file properties/
<MvG> I see. Still looks like something was going wrong here.
<jelmer> MvG: It's doing requests for get_dir() on things other than branch paths?
<Odd_Bloke> Was just debugging why PQM wasn't accessing remote source locations when using merge directives.  I hadn't actually created the remote branch. >.<
<MvG> It's difficult to match network traffic to function calls, or trace the lib calls in some sensible way, but I think so.
<MvG> As it was running get_dir at some arbitrary point during all those PREOFIND requests, I'd assume get_dir to be the source of at least most of those. And as I'd assume get_dir to only issue a handful of such requests, I think there is either a bug in get_dir or it's being called repeatedly.
<jelmer> MvG: get_dir() is being called repeatedly
<jelmer> MvG: It's probably called awfully often but hopefully only doing a single request each time
<MvG> jelmer: I have the -Dtransport log ready. Opening RA connection to repo root, then a long break, then a list of unsupported properties immediately followed by the traceback.
<LarstiQ> isn't that worse than doing more requests less often?
<jelmer> LarstiQ: There is no way you can get multiple results out of get_dir()
<MvG> jelmer: Why is it called awfully and there are PROPFINDs for different dirs when you are only interested in the file properties of the branch itself? Or do you mean all files within the branch as well?
<jelmer> MvG: It's called for each revision in which the branch path changed
<MvG> more requests less often would seem like less overhead.
<jelmer> MvG: I'm pretty sure it's not called for the files inside of the branch
<jelmer> MvG: Though they are returned by get_dir()
<Odd_Bloke> Right, I'm done for the day.
<Odd_Bloke> I'll send the merge directives patch in tomorrow, I want to make sure I'm not too tired when checking through it.
<Odd_Bloke> Also I think I'm beginning to become one with this chair.
<MvG> jelmer: Your branch still progressing smootly? I've reproduced the problem several timjes here in that time, so if it survived up to now, it's likely to continue to its completion.
<jelmer> MvG: yeah, it works fine here
<jelmer> I'm actually updating an existing branch
<jelmer> I'll try a fresh one
<jelmer> MvG: Can you pastebin that .bzr.log file somewhere?
<MvG> jelmer: Strange. You're on svn 1.5?
<jelmer> yeah, Subversion 1.5 (not the svn 1.5 branch)
<MvG> jelmer: No difference there. Which makes the different behaviour even stranger.
<MvG> jelmer: http://rafb.net/p/H2WMRd54.html
<Pieter> lifeless: bzr.dev is ~25MB in git, which might be a better comparison than the NEWS file, so if the 0.4:0.6 ratio then keeps up, you're looking at ~18MB for bzr.dev
<lifeless> Pieter: yes, I did a test run with more data and got 16MB for the texts
<lifeless> totally untuned yet though, I think I can probably get higher and make some different tradeoffs with better compressor heuristics
<lifeless> been doing talks and stuff since
<abentley> guilhembi: jam would be the best person for that, since he's working on the issue right now.
<jam> lifeless: as an aside (i'm *really* trying to get the merge stuff done right now :). How long of a delta chain are you allowing, and how does that impact decompression speed
<lifeless> jam: well, decompresion is decompress(); parse-delta; copy-bytes-from-basis
<lifeless> jam: so the IO and decompression size emittied is really the cactor, *not* the length of the chain
<lifeless> currently 60% of reconstruction is in cStringIO.readlines
<lifeless> so I'm going to eliminate that call altogether for the basis
<MvG> jelmer: I've managed to extract the HTTP requests from my network capture: http://rafb.net/p/Mc5IIX11.html
<jelmer> MvG: they're not very useful without the calls that call them
<jelmer> s/call/cause/
<jam> lifeless: another aside... we may want to consider a pyrex extension to split a string on '\n', since we can't use string.splitlines()
<lifeless> jam: right; or just not do splitting :P
<jam> split('\n') strips the final '\n' out, so we can't strictly use that eihre
<jam> lifeless: well, once we rewrite the apis to allow that
<tro> i'm using bzr-loom 1.3 with bzr 1.5 on python 2.5 on windows. when i merge changes from a thread immediately above the current using merge -rthread:above it merges fine, but then when i up-thread i have to merge again for some reason.
<tro> this results in some strange looking merge graphs in bzr vis
<tro> the merge doesn't change any files, because i just transfered all the changes from the upper thread into the lower one, so shouldn't moving back up not change anything?
<lifeless> tro: well, once you've merged the thread above, you don't need that thread anymore, right ?
<tro> lifeless: but i do. i have more stuff to change. the merged stuff is just the immediate changes needed by the lower thread
<lifeless> tro: there is an open bug about this actually, its mainly UI love, to 'fast forward' the thread for you
<lifeless> tro: oh, so you're not merging everything from the thread above?
<tro> lifeless: i'm merging everything, but i'd like to continue working on that thread after i've merged. the upper thread is potentially a big feature that i'd like to merge incrementally into the stable thread (lower) as i get work done on the upper
<tro> i guess i have to create a new thread for every such merge?
<lifeless> tro: as a workaround yes
<tro> ok, thanks. i'll search and subscribe to the bug
<lifeless> just merge; commit; create-thread thing; switch old-thread' bzr combine-thread
<tro> speaking of combine-thread, i think it's a little misleading. i would expect that operation to merge my changes into the lower thread, but instead if just tosses them. it's a good thing i tried it out on a test branch first before using it for real :)
<tro> maybe it should just be renamed to delete-thread?
<tro> i can't seem to find the bug. maybe my search-fu isn't up to launchpad's par. what should i be looking for? bzr-loom returns nothing
<tro> oh. i should be looking in the bzr-loom launchpad, of course, not bzr
<MvG> jelmer: I'm running the command through gdb and pdb to find out more about the causes. "determining revisions to fetch" has 19219 to go, but is done after 8576. strange.
<jelmer> MvG, new clone breaks here as well
<jelmer> MvG: that may make sense, if the branch was created in that revision for example
<MvG> Is there any decent way to figure out what python function invoked a given native C function? Like who called ra_get_dir? The gdb stack trace isn't much help, and my pdb breakpoints seem to have missed the invocation.
<MvG> jelmer: Unlikely for trunk, but possible.
<jelmer> MvG: There are gdb macros that allow you to print the python stack from within gdb
<jelmer> MvG, another possibility is that you already had the revisions up to 8576
<jelmer> MvG, alternatively you can just add more mutters
<MvG> I somehow doubt that the gdb macros will be much use, as most function call parameters seem to be optimized out.
<jelmer> they work fine here
<jelmer> hmm, the knits files don't appear to be written to disk anymore
<MvG> jelmer: I've got a high-priority issue here. I guess I'll be looking at the inkscape issue later on again. If you can find more about it by then, I'd of course be more than happy.
<jelmer> MvG, k
<lifeless> MvG: I know that ted succeeded with inkscape
<lifeless> MvG: And that it was _slow_ due to sf.net
<lifeless> MvG: perhaps you could branch his converted branch as starting point
<MvG> lifeless: With current bzr-svn and bzr.dev starting from scratch? Might well be that the slowness is mostly due to sf.net, but still its annoying that bzr-svn is so much slower than svn itself. Prevents people from switching to bzr.
<MvG> lifeless: I guess I could, but I coluld also start from my svn checkout, or from the lp mirror, as I don't intend to push any changes.
<lifeless> MvG: we traced it - sf.net was taking many seconds per request
<MvG> Still, I'm usually more interested in fixing issues that I encounter than in working around them.
<lifeless> MvG: they have some scaling issues
<lifeless> MvG: I agree; using --stacked will help somewhat, when al lthe pieces have landed
<jelmer> MvG: a large part of slowness in bzr-svn is due to bzr itself
<mtaylor> bzr: ERROR: bzrlib.errors.ReadingCompleted: The MediumRequest '<bzrlib.smart.medium.SmartClientStreamMediumRequest object at 0xb787a68c>' has already had finish_reading called upon it - the request has been completed and no more data may be read
<mtaylor> that ring any bells with anyone?
<lifeless> mtaylor: thats usually a second-order error
<lifeless> mtaylor: I believe spiv has posted some stuf about debugging that
<jelmer> MvG: Found the error
<jelmer> for some reason we're trying to update between 10643<->10643
<jelmer> and the sf.net server doesn't like that :-P
<MvG> jelmer: Will you write a fix?
<jelmer> I'm looking into how hard it is
<jelmer> It appears to be caused by tricky changes
<jelmer>    A /inkscape/trunk (von /trunk/inkscape:10642)
<jelmer>    D /trunk/inkscape
<MvG> Sounds like one would want a test case for such tricky situations, and ensure that test fails unless the fix is in place.
<jelmer> yeah, I always do that for regressions
<mtaylor> lifeless: I'm getting an error from search...
<jelmer> jam, lifeless: What's the plan for 1.6?
<mtaylor> lifeless: http://pastebin.com/m6bd9746e
<jelmer> MvG, Hmm, I spoke too soon
<jelmer> MvG: it has to do a fresh checkout in that case so it's correct behaviour
<MvG> jelmer: Requesting update for the same revision is correct behaviour?
<jelmer> MvG: Yes, iff you specify start_empty=True
<jelmer> that basically means "send me all the data in this revision"
<jelmer> jam: ping?
<jam> jelmer: ?? If it is about 1.6, I don't really know what the plan is. I'll try to bring it up at the next standup meeting. My best guess is that we are waiting for Stack to land, and Martin is working on that ATM
<jelmer> jam: Ah, thanks
<jelmer> jam: The other question was about my ignore patch
<jam> sure
<jam> I think the functionality *belongs* as a 'tree.add_ignore'
<jam> That doesn't meanit has to happen now
<jelmer> jam: You voted tweak - what tweak would you like to see exactly?
<jam> bzrlib.ignores.XXX is much better than wallowing i ncmd_ignore
<Odd_Bloke> That was my first thought when I glanced at the patch.
<jam> jelmer: I would *like* to see it moved to Tree
<jam> if you feel that is too much, than I probably would just approve
<jelmer> jam: Ah, ok - thanks
<jelmer> I agree MutableTree is a better place
<jam> Odd_Bloke: then you should be participating in the code reviews more :)
<jelmer> Odd_Bloke, Do you have voting rights yet?
<jam> jelmer: anyone can send a 'bb:approve' even if bb doesn't track it :)
<Odd_Bloke> jelmer: Nope.
<jam> jelmer: also, just to be sure, you should check the rules as far as adding a .bzrignore if it doesn't exist, etc. I think you did, but it was something that just popped into my head
<jelmer> jam: There isn't anything else as far as I can tell
<jam> And the tree should be write locked while all of this is happening
<jelmer> jam: there are existing functions for parsing the ignore file but they ignore the order
<jelmer> jam: since they use set()
<jam> jelmer: sure, but there *is* a WT._get_ignore_list or something similar
<jam> which uses ignores.XXX to do its work for it
<jam> I'm not 100% sure why I chose a set back then, but probably to remove duplicates
<jelmer> jam: It does make sense when using the ignores file
<jam> jelmer: I have a favor to ask. Can you try submitting a branch for me?
<jam> I've had this patch since 1.4, and when I try to submit it
<jelmer> jam: Sure
<jam> I see it show up in the PQM queue, but then it disappears without a success/failure
<jam> http://bzr.arbash-meinel.com/branches/bzr/1.4-dev/non_utf8_77657
<jam> I suppose I should try pinging lifeless to have him check if I'm segfaulting PQM or something weird
<jelmer> Maybe weird interaction with redirects?
<jam> that branch shouldn't redirect
<jam> it is just a plain apache share of the directory
<jelmer> jam: It's a look branch
<jelmer> s/look/loom
<jam> ??
<jam> ah, I guess I need to get rid of that
<jelmer> I don't have looms installed and I get:
<jelmer> bzr: ERROR: Unknown branch format: 'Bazaar-NG Loom branch format 6\n'
<jam> kk
<jelmer> Does pqm have looms?
<jam> It seems that locally it is not
<jam> I'll try nuking it and re-pushing
 * jelmer files a bug on PQM
<jam> ok, I just resubmitted it as a normal branch
<jelmer> jam: if you have time, any chance you can look at bug 244306 ?
<ubottu> Launchpad bug 244306 in bzr "push hook not executed for new branches" [Undecided,New] https://launchpad.net/bugs/244306
<jelmer> I'm considering whether push hooks *should* be executed for new branches
<jam> jelmer: ATM, time is not something I have much of, I would probably say that post-changed-branch-tip should probably fire, I'm not sure if 'push' should
<jam> I suppose if you created it via "bzr push ..../new-branch"
<jam> it would seem a bit odd if the hook didn't fire
<jam> but would it fire for
<jam> bzr branch . .../new-branch
<jam> L
<jam> ?
<jam> jelmer: is there a specific use-case you have in mind?
<jelmer> jam: I have a push hook that sets public_branch in ~/.bazaar/locations.conf when I push a branch
<jelmer> It's a bit annoying to always have to push twice to get that to work
<jelmer> I'll just use post-changed-branch-tip for now
<jam> jelmer: I would probably say that running "bzr push .../new-branch" should fire the trigger
<jam> And not firing would thus be a bug
<jam> jelmer: so... I agree it is a bug, I don't have any time to fix it myself :)
<jelmer> jam: Thanks
<jelmer> jam: I wasn't asking for a fix :-) I was unsure about how to fix this so your comments are much appreciated
<jelmer> jam: I just realized this would also help eliminate svn-push
<jelmer> jam: Would it make sense to add a "BzrDir.import_branch()" function ?
<jam> jelmer: This eliminates svn-push because it allows you to tell the local branch to 'pull --overwrite' ?
<jam> And I'm not sure what you are trying to do with 'import_branch'
<jelmer> jam: At the moment cmd_push() has its own logic for creating a new branch
<jam> now, if this was a *pre* push hook
<jam> that would make sense for svn-push
<jelmer> jam: So creating a BzrDir.import_branch() would allow the implementation of BzrDir to override the way the branch was created
<jam> jelmer: I don't think I would call it 'import_branch'...
<jam> And the logic in cmd_push is because of a dispute between lifeless and I
<jam> basically, if the repository exists, create a branch and fetch
<jam> if not, push works a bit differently
<jelmer> and it would allow it to take care of running the push hook, rather than putting the logic of running the push hook in cmd_push(which would be ugly)
<jam> (I wanted to change sprout()/clone() to always create the target branch and fetch, his argument was it creates a branch temporarily that is not the final valid value.)
<jam> (So instead, it only does that when the target repo already exists.)
<jelmer> ah
<jam> the idea was to support resuming in a limited way
<jam> though with packs it all goes away anyway
<jelmer> so what about something like BzrDir.clone_new_branch() rather than BzrDir.import_branch() ?
<jam> (packs have an all-or-nothing approach.)
<jam> jelmer: I would love to have cmd_push cleaned up and split into nice helper functions
<jam> I think what you are asking would only change the "elif br_to is None" logic
<jam> which is the case when there is a BzrDir and a Repository, but no branch
<siretart> I need to branch from an repository via http with an broken repository. However bzr fails because pycurl fails to verify it
<siretart> is there some way to ignore this error?
<jam> siretart: urlib+http://
<jam> is the workaround for now
<jam> well, urlib+https://
<siretart> bzr: ERROR: Unsupported protocol for url "urlib+https://svn.aspectc.org/repos/Puma/trunk"
<jelmer> jam: yeah, I agree
<jelmer> jam: I'll give this some more thought, thanks for the comments
<jam> siretart: well there youhave to ask jelmer, since it seems to be an interactiong with svn and https
<siretart> jelmer: does bzr-svn work at all with urlib?
<jelmer> siretart: try svn+https://svn.aspectc.org/repos/Puma/trunk
<siretart> aah, much better!
<siretart> thanks
<jelmer> vila, ping
<tolstoy> Is there any way to "tag" a branch remotely, or is there a super fast way to do it outside of that?
<jam> tolstoy: 'bzr tag -d path/to/branch' ?
<tolstoy> I want to create release branches over a lot of projects all at the same time, but need to tag the branch point.  If I didn't need to tag, I'd just bzr branch sftp://blah/head/project sftp://blah/branch/prject.
<tolstoy> jam: I think that requires running on the same machine as the repo you're branching.
<tolstoy> (We're using a source-of-truth model.)
<tolstoy> (Baby-steps....)
<tolstoy> If I run on the actual server, branch will generate "working trees" which I don't want.
<jam> tolstoy: I just tested it with bzr+ssh and it worked
<jam> I would expect -d to be fine with sftp:// as well
<jam> tolstoy: is the 'no-working-trees' flag set on the server?
<jam> touch .bzr/repository/no-working-trees
<jam> if it isn't
<jam> that should prevent working trees via 'bzr branch' (bzr co still creates them)
<tolstoy> Hm. Okay. There's a LOT of projects up there. I'll see if I can get bzr+ssh working instead of sftp.
<jam> tolstoy: it worked via sftp as well
<jam> I don't know why it wouldn't be working for you
<tolstoy> jam: Hm. Okay, I'll try it again.
<tolstoy> It might be that I did this before, then did a bzr pull, and got the "no revisions to pull" message, and just assumed the tags didn't come back.
<tolstoy> Or a permissions issue. Oy.
<jam> tolstoy: you can also try "bzr tags -d XXX"
<jam> which shows you what tags are on the branch
<tolstoy> Yep. The command succeeded, now to double-check.
<jam> tolstoy: and I would create the 'no-working-trees' file on the "blah" server, btw
<tolstoy> Okay. I'll add that to my list.  It seems like a good idea.
<jam> I'm /away for a bit
<tolstoy> Thanks for your time! I'm super happy my company is using BZR. I feel like we've leapfrogged a bunch of other companies.
<tolstoy> Yep. Remote tagging is working.
<tro> how come bzr-loom isn't listed as one of the plugins on the bzrplugins wiki page?
<ozzloy> http://pastebin.org/49698 how do i getrid of this?
<luks> ozzloy: get rid of what?
<luks> if you mean the working tree thing - http://bazaar-vcs.org/FAQ#head-927e36ce76d7ee3a9ef59baaf6aa839fc46c36aa
<ozzloy> luks: every time i push, bzr says i need to upgrade.  when i upgrade, it tells me the branch format is already the most recent.
<luks> ozzloy: I'm afraid you can't ugprade working trees over network
<luks> but you probably shouldn't have the working tree on server anyway
<ozzloy> luks: http://pastebin.org/49700
<ozzloy> this is on the server
<luks> ozzloy: bzr --version?
<ozzloy> http://pastebin.org/49701
<ozzloy> 0.11.0
<ozzloy> maybe i need a backport
<luks> and the format sais it needs at least 0.15
<luks> *says
<luks> but 0.11 is really ancient, you should upgrade anyway :)
<luks> or, since you don't use the working tree remotely, just remove it
<ozzloy> luks: i use the server to share between my laptop and work computer
<luks> ozzloy: but do you share the working tree or only the branch?
<ozzloy> luks: i'm new to distributed version control.  i'm unclear on the distinction
<luks> ozzloy: branch are the data inside .bzr, working tree are the actual files you can see
<luks> having the working tree on servers is usually useless, because you don't _work_ on the server
<luks> you only push/pull data from the .bzr dir
<ozzloy> ah
<ozzloy> but isn't that what i did?  push?
<luks> ozzloy: yes, but you have files outside of the .bzr dir you don't use
<ozzloy> so i should just delete them?
<luks> if you are sure you don't have any local changes on the server, I'd so `bzr remove-tree`
<luks> but you will need to upgrade bzr to do that
<ozzloy> i'll have to go to #debian for that
<ozzloy> hooray stable!
<luks> I'm sure debian backports have recent bzr
<ozzloy> (crusty)  thanks for the suggestion.
<luks> as there is a lot of debian people here
<ozzloy> and for the help
<ozzloy> although it actually seems to be working fine.  i've already pushed and merged changed between the computers
<ozzloy> i just get that message every time
<luks> ozzloy: exactly :)
<luks> bzr will not the remote working tree, so it's outdated and then it complains
<luks> er, will not touch
<ozzloy> icic
<ozzloy> would upgrading help with the speed of the pushes and merges?
<ozzloy> because those are kinda slow
<luks> you _could_ fix it with one simple trick even without upgrading bzr, but I 'm not going to tell you that
<luks> ozzloy: that depends on your local bzr version
<ozzloy> heh, thanks for teasing me then.
<luks> ozzloy: ideally you should upgrade bzr to 1.x and upgrade the branch
<luks> there was a new format introduced in 0.92 (I think) which speeds up pushes/pulls especially over sftp
<ozzloy> luks: back-ports has version 1.5
<ozzloy> and the upgrade finished
<Qhestion> hi. how can i make bazaar add all files in the current directory/subdirectories, without ignoring any files?
<jam> Qhestion: 'find dir -print0 | xargs -0 bzr add' ?
<jam> Qhestion: if you explicitly list a file, bzr will add it regardless of the ignore list
<jam> so you could also do "bzr add foo foo/*"
<jam> just depends what is easier for you
<Qhestion> no that seems not to work
<Qhestion> once make finishes is will try the first version
<jam> Qhestion: the 'find'  or the 'bzr add foo/*'? Also, can you give platform, etc?
<Qhestion> "bzr add foo/*" seems not to work
<jam> Qhestion: note that the second one doesn't recurse into subdirs of foo
<jam> you have to explicitly list all the files
<Qhestion> Python 2.5.dunno, Ubuntu 8.04
<Qhestion> explicitly listing all files is... not possible, because i have LOTS of files (it took me half an hour to compile this thingy and now i want to back it up)
<jam> If you are using zsh, you should also be able to do "bzr add foo/**/*"
<jam> If it is just .o files, you could also edit ~/.bazaar/ignore and remove the .o from your global ignore
<Qhestion> O_o this time it worked
<jam> Though I honestly would recommend not adding compiled output.
<Qhestion> dunno what went wrong the last time (hours ag), but "bzr add ./*" did it
<jam> As conflicts in .o files would be a pain
<Qhestion> jam: its just temporary
<ChristopheT> Hi.  We are a small group of developers and push our branches (via sftp) to a directory with the sgid set (so everybody in the group can write to the repository).  However, bzr does not properly propagates the sgid on its directories.  What can we do?
<fullermd> bzr does.  sshd doesn't.
<fullermd> If you use the smart server via bzr+ssh or something, it'll work.
<tolstoy> ChristopheT: What we did was make sure everyone's default group in the server was "bzr", and that our umasks were at least 002.
<ChristopheT> tolstoy: Unfortunately, this is a machine used by many other people with several projects on it...
<tolstoy> Yeah, we have a dedicated machine for the repos and all associated tasks.
<ChristopheT> That also means I can't install myself the bzr smart-server on it :(
<jam> ChristopheT: well, I could write a simple plugin that would disable bzr trying to set the mode on files over sftp, but that would only effect people who had the plugin installed
<ChristopheT> jam: thanks but I do not see how that will solve my problem.  The sgid bit is set on the server and not respected when .bzr is pushed.  My problem is _not_ that the sgid bit is not propagated (as https://bugs.launchpad.net/bzr/+bug/50568).
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]
<ChristopheT> If I create a dir from sftp, it is created with the right sgid bit.
<jam> ChristopheT: what happens is bzr does "chmod xxx" on all files after it creates them
<jam> this bit gets *removed* by sftp
<jam> my plugin would basically disable the chmod
<jam> so as long as the files get created with the right umask,
<jam> they will respect the sgid bit
<jam> or, I should say, directories will still have the sgid
<jam> bit
<jam> and thus files underneath will have the appropriate group
<jam> ChristopheT: put another way. When you do 'bzr push' we do "mkdir XXX; chmod 2775 XXX", which gets interpreted by sftp as mkdir XXX; chmod 775 XXX
<jam> and strips the sgid bit
<jam> then when we create a file underneath XXX/ , the containing dir doesn't have the sgid bit set, so the files created use the user's default group
<jam> ChristopheT: I could be wrong, but i'm pretty sure your problem *is* bug #50568
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568
<ChristopheT> jam: you are correct, I just tried and indeed chmod strips the sgid bit :(
<jam> yep, good ol' openssh
<ChristopheT> Maybe we should add our voice to http://marc.info/?l=openssh-unix-dev&m=117745562123264&w=4
<jam> I don't know *why*, I think it is a protection mechanism
<jam> so you can't sgid things you shouldn't
<jam> unfortunately, it strips it from things that you *should*
<ChristopheT> not propagating is a protection, not not leaving the ones that are set on the server side...
<ChristopheT> BTW, why does bzr use chmod?
<jam> ChristopheT: to try to get around users with a bad umask set
<jam> Sort of a damned if you do, damned if you don't
<jam> By default creating a directory will use the user's umask
<jam> so if they have 022
<jam> then directories won't be group writable
<jam> so we chmod
<jam> but then they lose the sgid bits
<jam> So *one* answer is to force users to set there umask (which they may want 022 for normal work, and only 002 for bzr work in certain directories), and not chmod.
<jam> An *easier* solution is to use bzr+ssh and something like bzr_access to set your umask for bzr connections
<jam> but that doesn't seem to help *you* as you don't have appropriate admin rights on this machine
<ChristopheT> I'll try to convince the admin to install the smart-server (but he is put off by the fact that no debian package exists)
<jam> ChristopheT: sudo apt-get install bzr
<jam> I don't see how hard that is
<jam> bzr+ssh just requires *bzr* to exist on the server
<jam> (and for you to have the ability to run "ssh host bzr serve --inet"
<jam> I certainly hope that jelmer has been keeping up with the debian packaging :)
<pygi> sooooo folks, who here has time to talk with me about topics that should be included in hopeful bzr book? :)
<jam> ChristopheT: http://packages.debian.org/search?keywords=bzr
 * jelmer needs sponsors
 * jam hides :)
<ChristopheT> For chmod, isn't the better to try: if a created dir has >= the right permissions or has a suid or sgid bit, do not touch it; otherwise chmod?
<jelmer> hi pygi
<jam> ChristopheT: there are a lot of possible heuristics which could be attempted, but if the g+w bit isn't set, sgid doesn't help much
<pygi> hi jelmer :)
<jam> you get the right group
<jam> but the group still can't write
<jam> I thought we had a "stat + if bits not right chmod"
<jam> ChristopheT: ah, we don't do that for sftp, because of adding an extra round trip issues. We probably could, and patches for that would certainly be reviewed
<jam> Especially if it only effected mkdir, since we do that infrequently, versus for all file creation, which we do somewhat more often
<jam> (ie, effecting 1 time in 1000 means you can do a bit more work each time)
<jam> (without impacting the overall work done much)
<ChristopheT> Yes but one can then warn the user and use a default decision (either no chmod -- the sanest IMHO since if the sgid bit is set, this is for a reason, but tell tu use umaks id the bit g+w is not set -- or do chmod anyway and use an option --no-chmod to override that -- but forgetting this will screw up things).
<jam> If the user has the wrong umask... if chmod you  get files with the wrong group, though probably read permissions on the files (aka, you can still use it), or if you don't chmod you get no 'w' for the directory, so other people can't put new files there (aka, you can't use it at all)
<jam> ChristopheT: again, if you care deeply, I'm happy to review a patch to the sftp code. It is all contained in bzrlib/transport/sftp.py
<jam> And you want to look at the "def _mkdir()" function specifically
<jam> You probably should also discuss it on the mailing list
<jam> to ensure that people generally agree.
<jam> One man's 'just work's heuristic is often another's "it is very broken"
<pygi> lifeless, how did the bzr talk went?
<ChristopheT> jam: if the administrator agrees to install bzr, if he does not agree then I'll try to change the mkdir logic (hopefully the bug will be fixed in sftp itself)
<jam> ChristopheT: well, it has existed for... 3+ years now, I don't know that the openssh guys are really going to change anything
<ChristopheT> BTW, the part of the server we have access to is in a chroot environment.  Any hint about what I have to tell him to do?
<jam> ChristopheT: well, python2.5 and bzr need to be available in the chroot
<jam> but no, I don't have a lot of personal experience with getting software working under a chroot
<jam> I know you can run bzr from source or from your personal home directory
<jam> as long as python etc are available
<ChristopheT> Does bzr creates new _directories_ after the initial push?
<jam> ChristopheT: for new-format (pack) repositories, it only creates lock directories which should be cleaned up during unlock
<jam> older ones used multiple levels for storage, but that is no longer the case.
<jam> anyway, bbiab, restarting my machine
<ChristopheT> I guess moreover that bzr does not chmod any existing directories after their creation, right?  (For the short run, then I can change the sgid by hand -- we are using righ-root-pack.)
<poolie> jam, hi
<mwhudson> <insert question about branch7 landing here>
<poolie> mwhudson: see my mail "update on stack merging"
<mwhudson> poolie: ahah, thanks
<jelmer> poolie: what are the plans for 1.6 ?
<jelmer> days, weeks, months ? :-)
<poolie> jelmer, days, immediately the stacking branch is landed, which will be as soon as all the tests pass
<jelmer> poolie: Thanks!
<jml> good morning Bazaar.
<jam> poolie: hi
<poolie> hi jam, shall we talk?
<jam> just a sec, talking with #bzrlp guys
<jam> also, I'm on linux right now, so by-phone is probably better than by-skype
<poolie> sure, just ping me when you're ready
<jam> poolie: I'm probably available for a call now
<poolie> ok
#bzr 2008-07-09
<igc> morning
<jelmer> hmm, 43 % of all bzr-svn bugs will be fixed in 0.4.11. I wonder if we'll be able to make that 50...
<spiv> Heh.
<spiv> jelmer: hmm, current 'stable' branch is extremely slow for me when pulling my twisted import
<jelmer> spiv: What step is slow?
<spiv> jelmer: the progress bar keeps jumping back.  http://rafb.net/p/SPzipu87.html
<jelmer> looks like it's finding tags
<jelmer> does twisted have an awful lot of them perhaps?
<spiv> I guess it might.
<spiv> $ svn ls svn+ssh://cvs.twistedmatrix.com/svn/Twisted/tags | wc -l
<spiv> 152
<spiv> Approximately one for each release (including rc and alpha releases) until Twisted 2.2 or so, when the release process changed, I think.
<spiv> I suspect Twisted isn't going to be unusual in doing that :)
<ChristopheT> jam: Are you sure chmod is to set g+w?  I tried without setting the proper umask on the server and g+w was not set.
<ChristopheT> Anyway, I have a small patch available.  Do I send it to the ML or do you want to see it first?
<Odd_Bloke> Moin.
<jelmer> hi Odd_Bloke
<jelmer> Odd_Bloke: You're not in the UK?
<Odd_Bloke> jelmer: Yeah, but have weird sleeping patterns. :D
<jelmer> ah :-)
<spiv> jelmer: I filed a bzr-svn bug for you, I got an error when I left that bzr pull run to completion.
<jelmer> spiv: Thanks
 * Odd_Bloke --> breakfast
<jelmer> ok, that's even more weird than my sleeping patterns
 * igc lunch
<libwilliam> I've got a question/comment. I was wondering why bzr modified isn't in the user reference list. Also it seems like bzr ls should have a --modified option.
<Odd_Bloke> jelmer: :D
<libwilliam> Also is there a way to get a list of removed files. That would be another option I think bzr ls should have.
<libwilliam> i know i can get them with status, but I meant the removed files alone
<Odd_Bloke> I decided to be on Australian time for a while, and am now adjusting back for something I'm doing this weekend.
<Odd_Bloke> Also, I work best at night.
<bob2> bzr status -S | awk '/^R/ {print $2}' or something
<libwilliam> bob2: ill mess around with that, thanks, didnt think about that
<Odd_Bloke> poolie: When you're free, a chat would be good. :)
<meteoroid> poolie rawks :-P
<meteoroid> i'd like to expose my bzr branches over http and i'm unclear from the documentation on how to do so
<meteoroid> any help would be much appreciated :)
<Peng> meteoroid: You can just put them in some location served by Apache or whatever. You don't need to do anything else.
<meteoroid> i have heard that, but had trouble with it in the past
<Peng> You *can* set up an HTTP smart server if you want to, but it's not necessary.
<meteoroid> are there any docs?
<meteoroid> i'd like to set up for http commit
<Peng> meteoroid: Well, you shouldn't have.
<Peng> ??
<meteoroid> so people don't need ssh
<meteoroid> i know i shouldn't have, that's why i ask about docs..
<Peng> Oh.
<meteoroid> i must have missed something..
<Peng> Err, I'm not sure you can.
<meteoroid> and yeh, a lot of my collaborators are ubuntu users, so getting bzr is no big.
<Peng> Writing over HTTP requires WebDAV, right?
<meteoroid> not sure i can what?
<Odd_Bloke> meteoroid: vila has recently published the webdav plugin.
<meteoroid> Odd_Bloke: url?
 * meteoroid would welcome half-working experimental code
<Odd_Bloke> meteoroid: https://code.launchpad.net/~bzr/bzr.webdav/webdav
<meteoroid> is it in pypi?
<Odd_Bloke> It's marked as only working for bzr 1.6, but will probably work before that, it just hasn't been tested.
<meteoroid> hm, i seem to have 1.3.1
<meteoroid> i should be compiling from source..
<meteoroid> but, yeh, i'd like this setup to work with what ubuntu is shipping..
<bob2> sftp or bzr+ssh will be less hassle
<poolie> Odd_Bloke: oh hi
<Odd_Bloke> poolie: Hey.
<poolie> hello
<poolie> did you want to talk here, on private irc, or on the phone
<Odd_Bloke> poolie: PM?
<Odd_Bloke> I have two different Test classes, both of which have a setUp method.  I also have one test which requires the setUps of both Test class.  How should I go about combining them?  Is there something better than copy-paste?
<bob2> C inherits from both of them, it's setUp consists of A.setUp(self);B.setUp(self)
<Odd_Bloke> I tried that, I think C then ends up with all of the tests from A and B being run twice.
<Odd_Bloke> I'll double-check though.
<Odd_Bloke> It does run all the tests from A and B twice.
<Odd_Bloke> However, it has also allowed me to debug the test which shares the setUps, so it's not a total loss.
<Odd_Bloke> Perhaps extract the setUp for A and B to A' and B'.  A and B then each subclass A' and B' and C subclasses both A' and B'?
<spiv> Odd_Bloke: yeah, separating the setUps from the classes with the test methods sounds like a good start
<spiv> Depending on what those setUps do, you might even be able to extract them into a non-TestCase object entirely.
<spiv> Like how some bzrlib tests do things like "smart_server = bzrlib.smart.server.SmartTCPServer_for_testing(); smart_server.setUp(backing_transport=blah); self.addCleanup(smart_server.tearDown); ..." in test bodies.
<spiv> But your arrangement with A' and B' sounds ok too.
<Odd_Bloke> Soo, bzr-email and the PQM test suite shouldn't be mixed. >.<
<Odd_Bloke> If I want to exclude a specific directory under a more general directory (in this case ~/devel/pqm/work/_trial_temp underneath ~/devel/pqm) from using bzr-email, do I do it in ~/.bazaar/locations.conf?
<spiv> Odd_Bloke: If the PQM test suite used bzrlib.tests.TestCase, it ought to be insulated from your ~/.bazaar configuration.
<Odd_Bloke> Hmm, thumper has a patch for exactly this.
<Odd_Bloke> PQM merge-directives patch just sent to the ML.
<lifeless> pygi: quite well recieved, but a self selected audience
<lifeless> pygi: 20 or so people, all but 4 already love bzr :)
<lifeless> jam: I will check when I get to the uni
<poolie> lifeless: it looks like branch --stacked still copies all the data from the source repository
<poolie> this is in the top of your baz2.0/shallow-branch
<poolie> am i just using out of date code, or do i need to fix this?
<Odd_Bloke> jml: What was the name of the todo-list website you were looking at?
<mwhudson> rememberthemild
<mwhudson> rememberthemilk
<mwhudson> remember the mild sounds like a good idea of a different sort...
<Odd_Bloke> mwhudson: Thanks. :)
<Peng> mwhudson: Can I bother you about Loggerhead?
<mwhudson> Peng: not really, it's end of day time here
<mwhudson> Peng: but if you're quick...
<Peng> mwhudson: Oh. Yeah, not very quick..
<mwhudson> Peng: bugs and or email then please
<Peng> mwhudson: Email to? Bazaar-list?
<mwhudson> Peng: yeah, sounds good
<liw> "And man, major WTF at using Bazaar. :)" (in the comment section, fairly close to the end, of http://community.livejournal.com/evan_tech/248736.html)
<liw> I know bzr isn't as popular as git, but... "major WTF" for using it? tsk.
<lifeless> poolie: I was fairly sure there were tests to catch this;  its possible there are not though
<tim__> nick thumper
<tim__> damnit
<lifeless> :)
<lifeless> poolie: abentley's policy work may help too
<poolie> lifeless: what branch would those tests be in?
<poolie> can you check you've pushed all your work on it?
<poolie> afaics aaron's work doesn't change it
<poolie> it might though
<poolie> maybe i should try the merge anyhow
<poolie> at least in a separate workspace
<lifeless> poolie: I have
<lifeless> poolie: got a machine to setup sorry
<poolie> lifeless: i don't mind fixing it, i just want to avoid rewriting code that exists on your laptop or something
<poolie> "I have" -- checked you've pushed it?
<poolie> ok, thanks
<poolie> i tried the stacking-policy branch; it still copies the contetn
<lifeless> poolie: urgh. I suspect a race condition in clone()/sprout()
<poolie> i should have tried this a few days ago
<poolie> i've been chasing the wrong geese
<lifeless> poolie: group compress is looking nice btw - I can compress bzr.dev's texts down to 16MB
<bob2> wow
<thumper> lifeless: what is it normally?
<thumper> poolie: hi
<poolie> hi thumper
<lifeless> du -sh test-repos/bzr.dev.-100/.bzr/repository/packs/
<lifeless> 74M     test-repos/bzr.dev.-100/.bzr/repository/packs/
<lifeless> thumper: which includes inventories and revisions too though
<thumper> lifeless: that is very impressive
<bob2> btree indices save more than 50%, too
<lifeless> ok, strict bzr.dev gets down to 12M
<bob2> is groupcompress hooked up the ui at all?
<lifeless> its a VF object at the moment
<lifeless> thumper: ping
<lifeless> thumper: the local playground is up at 10.2.13.75
<lifeless> thumper: I need you to find olav, and send him my way on IRC or real-world
<beuno> lifeless, hey there. I've been hearing great things about you in Guadec!  Having fun?
<lifeless> beuno: yes indeed
<lifeless> being eaten alive by mosquitos
<Odd_Bloke> (NOM NOM NOM)
<beuno> ok, off to work, bbiab
<lifeless> poolie: ping
<poolie> lifeless: pong
<lifeless> whats the mailman padmindb password these days
<lifeless> jamesh: ping, can you come over
<lifeless> thumper: jamesh: pikng
<thumper> lifeless: here
<thumper> lifeless: I don't have popups with irssi
<lifeless> can you and jamesh pop over, I can't really come to you
<Odd_Bloke> thumper: lifeless: poolie: Is it OK if I go ahead and create the pqm-dev team?
<jamesh> lifeless: sorry.  was away.  Where are you?
<lifeless> student computer lab
<lifeless> Odd_Bloke: I've created it
<Odd_Bloke> lifeless: Cool, thanks.  I've just applied.
<lifeless> Odd_Bloke: I'm a bit confused about what the team is meant to imlpy though
<lifeless> if its commit access to trunnk, which I labeled it as, then clearly its just me today.
<lifeless> if its not commit access to trunk, then what is it
<Odd_Bloke> lifeless: I think it's probably for people who are expected to have commit access at some point.
<Odd_Bloke> At the very least, it'd be good to have a team that can manage the bugs.
<lifeless> do you not have the needed permissions todayt?
<Odd_Bloke> I can't change Importance of bugs.
<lifeless> ok, lets fix that
<beuno> mwhudson, merged trunk into loggerhead-searched and pushed revo 273
<beuno> lifeless, thanks for pushing the merge  :)
<lifeless> beuno: my pleasure
<lifeless> beuno: ping
<lifeless> beuno: does the loggerhead gnome theme branch have bzr-search merged?
<beuno> lifeless, yeap
<Peng> Does Loggerhead trunk or bzr-search_integration work with bzr.dev?
<beuno> Peng, both do
<Peng> Heck, I'll switch to bzr-search_integration, then.
<beuno> 1.5+ AFAIK
<beuno> :)
<beuno> hopefully trunk will become lh-search soon
<Peng> Yeah, I was expecting that to happen faster..
<Odd_Bloke> lifeless: I'm a little confused by what pqm.ui.twistd.QueueResource.render is doing (http://tinyurl.com/5jptpr for reference).  Should both of the "len(request.postpath) > n" be "len(request.postpath) >= n"?
<lifeless> Odd_Bloke: no :)
<lifeless> Odd_Bloke: have a look at what the data is, it may help
<Peng> beuno: Like, how soon? Do you have a specific plan? If I switch now, will you suddenly merge it into trunk tomorrow?
<lifeless> poolie: deends on mwhudson
<lifeless> Peng: ^
<lifeless> poolie: soorry\
<Peng> Well.
<beuno> Peng, "in the next few days"
<Peng> Oh, nice.
<Peng> beuno: Is the search branch considered reasonably stable?
<beuno> Peng, gnome has been using it, and I haven't heard any complaints
<beuno> I think it's stable enough to be used in most enviroments, yes
<Peng> Will search indexes be created automatically?
<beuno> no, that's one of the remaining issues
<beuno> they do get updated automatically, but that's due to bzr-search's magic, not LH
<Odd_Bloke> lifeless: I would expect "localhost:8000/project" to go to project's page.  ATM, however, it would go to the main page.
<lifeless> Odd_Bloke: it doesn't seem to is what I'm saying
<Peng> beuno: So, if there is no index, what happens? it's eternally slow?
<lifeless> Odd_Bloke: as in, projects are in use at the moment, and it works last I heard
<beuno> Peng, nope, it ignores everything, and search doesn't return any results
<Peng> Haha.
<Peng> Since I don't want to bother to index anything, I guess I won't do it, then.
<lifeless> Peng: 'bzr index' once on the things you want to index
<Peng> lifeless: Yeah, but I don't know what should be indexed. I'm not an upstream developer; I don't have any trunk branches.
<lifeless> Peng: well, you're running loggerhead on some branches you want to look at
<Peng> So apparently knit repos can't be indexed?
<Peng> Actually, no, even a pack repo tracebacks about weave_store.
<Peng> Ooh.
<Odd_Bloke> lifeless: Ah, I was being confused by a lack of a '/' at the end of the URL.
<Peng> I'm sorry, false alarm. One copy of bzr-search was out-of-date.
<lifeless> Peng: :)
<Peng> Also, when "bzr index" uses 220 MB of RAM, and my VPS has 360 MB of RAM, that becomes a bit of a problem..
<Peng> Also also, I still got a weave_store traceback.
<Peng> Screw this. I'm reverting.
<lifeless> Peng: your loggerhead?
<lifeless> Peng: or the index creation ?
<lifeless> Peng: uhm, ratchet down the group size in index.py will reduce memory use
<LarstiQ> hatchet it down? :)
<Peng> lifeless: The original weave_store tracebacks were from index, but upgrading bzr-search fixed them. The new ones were from Loggerhead.
<lifeless> Peng: sounds like an old loggerhead too then
<Peng> lifeless: I had just merged bzr-search_integration, which just merged the trunk.
<lifeless> bue^
<lifeless> beuno: ^
<beuno> hm
<beuno> yes, lh-search has the latest and greatest
<beuno> Peng, LH is using the memory, or creating the search indexes?
<Peng> beuno: Sorry, index was using the memory.
<Peng> Um, actually, that traceback was from a branch that either had no index or a broken one.
<Peng> lifeless: What all does index creation modify? Just .bzr/bzr-search. Or in other words, what do I delete to make it go away? :)
 * beuno throws the ball back to lifeless 
<Peng> Haha.
<lifeless> Peng: .bzr/bzr-search
<Peng> lifeless: Thanks.
<lifeless> beuno: I was saying LH was erroring, bzr-search is using the memory
<lifeless> Peng: like I say though, edit index.py, look for group_size
<lifeless> set that to 1 for minimal memory use
<beuno> Peng, can you paste the traceback?
<Peng> beuno: http://paste.pocoo.org/show/78956/ (it's the same traceback all 4 times)
<Peng> lifeless: Thanks, but I'll just live without those branches being indexed for the moment.
<Peng> lifeless: Does searching suck much RAM?
<beuno> Peng, are you running bzr.dev with the latest bzr-search?
<Peng> beuno: I should've been.
<lifeless> Peng: searching should not suck much
<lifeless> beuno: can you advise on something
<Peng> lifeless: That's good. Thanks.
<lifeless> beuno: if you go to http://bzr-playground.gnome.org/gnome/CWordHelper/trunk/changes, and do a search
<lifeless> beuno: a) why does it end up on bzr-gnome.canonoical.com
<Peng> beuno: I had just switched Loggerhead from using the system bzr 1.5 to my copy of bzr.dev with bzr-search, and I never confirmed it actually worked.
<lifeless> beuno: and
<beuno> Peng, that seems like a bzr-search <> bzr problem with lifeless's VersionedFiles thingie
<lifeless> b) why doesn't the search box popup show
<beuno> lifeless, hm, that's odd
<Peng> Canonical host's Gnome's Bazaar?
<Peng> Err, hosts*
<lifeless> Peng: we host svn.gnome.org I think too :)
<Peng> lifeless: You're right. That's nice.
<beuno> lifeless, it seems LH is finding the *.canonical URL instead of the *.gnome one, and setting that
<beuno> find as you type should work though
<lifeless> beuno: where does it look though?
<beuno> it probably doesn't due to cross-site-scripting protection
<lool> Hey folks
<lool> When bzr branching casper under hardy and Debian sid I get:
<lool> KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
<beuno> lifeless, it seems paste is resolving to that host
<lool> I'm suggested to run bzr check or reconcile, but is there any risk for the lp repo?
<lool> I wouldn't want to break the casper bzr repo on lp
<lifeless> lool: I suspect you have a bug in your bzr that we fixed
<lifeless> lool: what version do you have?
<lool> lifeless: hardy's and sid's versions
<lool> That'd be 1.5-1 and 1.3.1-1
<lool> Well the opposite
<lifeless> lool: please try 1.6b2
<lool> Is this in some ppa?
<lool> I don't see it in intrepid
<lifeless> lool: but its possible that there is some problem
<lifeless> lool: yes
<lifeless> 'bzzr' ppa
<lool> That guy exists but doesn't have a ppa :)
<Peng> lifeless: ~bzr's ppa only has 1.5.
<lifeless> oh, the bzr-beta one then
<lool> I see no bzr-beta ppa
<lool> And indeed ~bzr only has 1.5
<mattions> hey guys
<mattions> hello
<lool> ~bzr-beta-ppa
<lifeless> https://launchpad.net/~bzr-beta-ppa/+archive
<lifeless> hi matt
<lifeless> ions
<Peng> Bye matt ions.
<lifeless> beuno: I see no search requests in th eloggerhead logs
<lifeless> beuno: could the jscript not be loading in the client?
<beuno> lifeless, it probably isn't, yes, because it's on a different host, and browsers have cross-site-scripting protection
<mattions> hi lifeless, sorry xchat wuit
<lifeless> beuno: so, why is it detecting this other host, how do I fix that
<Peng> Why does LH insert the full URL into links so often?
<beuno> that means, to some extent, the browser is also confused on what the hosts are
<mattions> can anybody have a quick look to this stacktrace http://paste.ubuntu.com/26174/ ?
<lool> lifeless: It isn't fixed in 1.6
<lifeless> lool: ok; can you chat to colin watson?
<lool> 1.6~beta2-1~bazaar1 is the hardy version I tried
<lool> lifeless: Colin suggested me to come here :)
<lifeless> oh
<beuno> lifeless, I'm trying to find where paste generates that, and why it would be detecting something else
<lool> lifeless: As he has been experiencing the same
<lifeless> uhm, try grabbing the current source, then pulling the old source into your branch with pull --overwrite
<lool> The current source?  you mean the source package?
<lifeless> lool: the current bzr tree
<lool> Or only check out the latest revision?
<beuno> lifeless, did you kill LH?
<lool> I'm doing bzr checkout --lightweight lp:~ubuntu-core-dev/casper/trunk
<lool> Interestingly, when I bzr pull --overwrite it says: Using saved location: http://people.ubuntu.com/~tfheen/bzr/casper/trunk/
<lool> it shouldn't use this saved location
<Peng> lool: "bzr pull --remember lp:~ubuntu-core-dev/casper/trunk" to change it.
<lool> Peng: Thanks
<Peng> (You can pass --overwrite too if you want to.)
<lifeless> beuno: back
<lool> All pulls returned "No revisions to pull" and bzr vis complained that my branch didn't support tags
<lifeless> lool: with --overwrite ?
<beuno> lifeless, not for me  :)
<lool> lifeless: With overwrite
<lool> Let me try again starting from the lightweight checkout and using unbind first
<lool> bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://lool@bazaar.launchpad.net/%7Eubuntu-core-dev/casper/trunk/.
<lool> So I'll skip unbind
<lifeless> lool: just bzr branch the current trunk of casper, then pull --overwrite the old version you want
<lool> I checked it out because I didn't know I could lightweight branch, but I'll try that
<lool> lifeless: I don't see how I can branch the current trunk
<lool> Hmm perhaps with revision
<lool> No doesn't work
<lool> bzr branch --revision 516 or bzr branch alone fails with the KnitCorrupt error
<lool> KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
<lool> I can't unbind without upgrading
<lool> I could try to upgrade locally, unbind and pull --overwrite
 * lool lightweight checkout + upgrade => stuck: \ [============================================] checking repository format 1/1
 * Peng leaves.
<lool> No progress anymore
<beuno> lifeless, are you running serve-branches or start-loggerhead?   can you try running the other one on a random branch?
<beuno> I suspect it's the way serve-branches sets the URL
<lifeless> beuno: server-foo
<lifeless> lool: sorry, I can't devote as much time to you as I'd like, my cycles are overcommitted
<lool> lifeless: I understand; how do we go forward with the problem?
<lool> Should I file it against bzr?
<lool> It's effectively preventing Colin and I to work on the casper bzr tree which is used for the casper package
<lifeless> beuno: it was the ServerName in apache
<beuno> lifeless, self._url_base = environ['SCRIPT_NAME']
<beuno> yeah
<beuno> found it  :)
<lifeless> lool: its proably user data that has had something bong done to it; perhaps sftp interaction bug or something in the past
<lool> lifeless: Interestingly, I could branch from an older bzr version
<lool> alioth's
<lifeless> lool: so now pull --overwrite the newer one into there
<lool> I have nothing to pull in particular
<Dany> Hi! I'm developer on a project opened on "http://forge.ocamlcore.org/". I have generated a key with "PuTTYgen" and I put it in my profil on ocamlforge. With this, I can connect me to the shell with the command "putty shell.forge.ocamlcore.org". I use bzr to make a branch of the project, it works fine. But the command "bzr push sftp://bzr.ocamlcore.org//bzrroot/pa-do/pa-do/trunk" gives an error.
<Dany> The error is : bzr: ERROR: Unable to connect to SSH host bzr.ocamlcore.org; EOF during negotiation
<lifeless> lool: grab the alioth branch; cd to it; pull the launchpad branch
<Dany> any suggestion?
<lool> lifeless: Ah I think I wasn't clear
<lool> lifeless: I could bzr branch the lp branch /from/ alioth
<lool> Using alioth's bzr
<lool> There's no branch hosted on alioth
<lool> It's just bzr 1.3-1~bpo40+1
<lifeless> Dany: no idea sorry
<lifeless> lool: can you run rsync that somewhere and then run check on it
<lool>    112 inconsistent parents
<lool>      5 revisions missing parents in ancestry
<lool> I ran bzr reconcile and bzr checked again; I still have      5 revisions missing parents in ancestry
<lool> and 5 ghost revisions in all cases
<lifeless> try cloning that with modern bzr?
<lool> -- I did the checks and reconciles with modern bzr btw
<lool> bzr: ERROR: Revision {Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-9} not present in "KnitVersionedFile(file:///home/lool/b/trunk2/.bzr/repository/knits/9c/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.36)".
<lool> NB: The error is this only line now
<lool> (this is the error from branching the reconciled branch with modern bzr)
<lifeless> same thing
<lifeless> file a bug please
<lifeless> don't alter the lp branch
<lool> I'll attach this IRC log
 * lool thanks and waves
<mtaylor> lifeless: if I have two revisions, is there a "good" way to just get the list of revisions between them? (like a magic method to call somewhere?)
<lifeless> mtaylor: graph.difference os some wuch
<mtaylor> ah...
<lool> Sorry, forgot to say I filed #246880
<lifeless> mtaylor: g = repository.get_graph();
<lifeless> lool: thanks
<lool> lifeless: thank /you/
 * lool goes for some lunch soonish now &
<lifeless> ok. we're syncing again
<davidf1> Hi all, I have a question to which I can't find an answer (but maybe I'm not looking good enough...). It is this: someone has started a project and committed lots of files to our repository. Most of it isn't used anymore, but some of it is. I started new projects with a clean structure. Is it possible to lift just a few files out of the old project with version history included? So, something like a merge, but without pulling in all unused stuff, revisions
<davidf1> Sorry for the long read...
<Peng> davidf1: That ended with "but without pulling in all unused stuff, revision" and one more byte.
<davidf1> Ai...
<davidf1> So, something like a merge, but without pulling in all unused stuff, revisions and histories. I can merge the entire project and then delete all unused stuff, but that pulls in lots of history I don't use. Can I just merge a few files?
<davidf1> Peng: thank you
<Peng> Sprry, but I don't have an answer. Hopefully someone else knows.
<davidf1> Peng: thank you for pointing out the missing text.
<Peng> :)
<davidf1> I'll wait for someone else to answer this (hopefully...)
<Peng> Also, I was just about to go to bed. Good night (or, morning, or whatever).
<davidf1> Peng: good night for you, then. Here, it's just after lunch, ;-)
<Peng> Here it's 07:05, but I have no sleep schedule. :D
<Peng> Bye.
<davidf1> Peng: you stayed up all night???
<luks> the problem is mainly in getting positions of the text line
<luks> sorry, wrong channel
<lifeless> davidf1: the history for the files you want is mingled with the history you don't want; its possible to write ode to generate new history with matching dates etc for only the file syou want, but it won't be mergable after that; and we haven't got a canned solution too this
<davidf1> lifeless: ok, thanks. I'll merge the whole project then and remove all unnecessary parts. A bzr log <file> should still only give the relevant history, right?
<lifeless> davidf1: yes
<davidf1> lifeless: thanks!
<Odd_Bloke> lifeless: I've just checked and I still can't edit PQM bugs.  I think you need to set PQM's bug supervisor to the pqm-dev team...
<lifeless> Odd_Bloke: ok
<lifeless> Odd_Bloke: done
<jelmer> hi lifeless, Odd_Bloke
<thumper> lifeless: I've just applied to join the pqm-dev team too
<lifeless> k
<Odd_Bloke> All the cool kids are doing it.
<jelmer> Odd_Bloke, you appear to've spammed the commits list :-)
<Odd_Bloke> jelmer: Was this with multiple 'Revision 1' messages, or more recently?
<jelmer> yeah, multiple rev 1
<jelmer> the others appear to be fine
<Odd_Bloke> Yeah, that's because PQM's test suite uses your standard bzr settings, which I'd forgotten about.  So every commit in a test got emailed out.
<jelmer> ahh :-)
<mwhudson> bzrlib.tests.TestCase ftw
<lifeless> thumper: try that groups thing now
<jam> lifeless: I'd like to chat a bit about how 'bzr pull' has to grab 100% or it throws out everything.
<jam> It's being a real problem with mirroring 200 branches from my home repository
<jam> => launchpad
<lifeless> jam: ok; well it doesn't really have to, what it has to do is ensure that the ones it grabs are topologically oldest
<jam> lifeless: so I was looking at the fetch code.
<jam> And for "old" formats
<jam> you could simply grab the sorted list of revision ids
<jam> and then say grab 1000 at a time
<jam> the problem with the new code
<jam> is that you use "get_stream_from_search"
<jam> which is nice and efficient
<jam> from a "bytes transmitted on the wire" perspective
<jam> but means there isn't a way to say "give me only some of these"
<jam> I mentioned to Andrew that it would be nice to have a "sync" node in the data stream
<jam> so that the server could give you revisions in a given group, and then let the client know that it has a "complete" set
<jam> thus it can be committed to the repo
<jam> and start a new write group.
<lifeless> jam: sure, or you could just drive it from the client, by taking some subset of the search
<jam> well, the client has to do a lot more querying of the server to find out the subset from the search
<jam> since all it has are the graph edges
<lifeless> jam: not really
<lifeless> jam: its traversed the intermediate nodes, you can just pick one, and use the existing graph edges
<jam> maybe I misunderstand what the 'for search' does
<jam> lifeless: my specific example is 'first pull', how should it need to traverse anything but the branch tip?
<lifeless> jam: ah that case is fair enough
<jam> I would *like* to have it driven by the client, but the whole point was to avoid having the client have to determine the whole graph
<jam> being driven client side makes it easier to support
<lifeless> jam: ack; anyhow I agreew it the the need
<jam> ok, I know you and I have full plates, so I'll see about pushing spiv to do it :)
<kinkie> Hi all... I have a problem with pushing some changes to launchpad. I have a private copy of squid-trunk off which I branched. I pulled from trunk, merged into my copy and then tried to push my copy to launchpad. But the push complains that "These branches have diverged.  Try using "merge" and then "push".". Tried to, but all actions show that trees are actually in sync. Hints on how to solve?
<kinkie> Thanks in advance
<lifeless> kinkie: hi
<kinkie> hi lifeless :)
<lifeless> kinkie: are you pushing to your own branch in launchpad?
<kinkie> yes
<lifeless> kinkie: what url is that ?
<lifeless> (and what url does bzr think you are pushing to)
<kinkie> after lp: expansion, it's bzr+ssh://kinkie@bazaar.launchpad.net/~kinkie/squid/cachemgr-refactor/
<lifeless> can you paste the bzr output?
<kinkie> kinkie@longhorn:~/src/cachemgr-refactor$bzr push
<kinkie> Using saved location: bzr+ssh://kinkie@bazaar.launchpad.net/~kinkie/squid/cachemgr-refactor/
<kinkie> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<lifeless> kinkie: what does 'bzr info' show?
<kinkie> kinkie@longhorn:~/src/cachemgr-refactor$bzr info
<kinkie> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<kinkie> Location:
<kinkie>   light checkout root: .
<kinkie>    checkout of branch: /home/kinkie/src/repo/squid-cachemgr-refactor
<kinkie>     shared repository: /home/kinkie/src/repo
<kinkie> Related branches:
<kinkie>     push branch: bzr+ssh://kinkie@bazaar.launchpad.net/%7Ekinkie/squid/cachemgr-refactor/
<kinkie>   parent branch: /home/kinkie/src/repo/squid-trunk
<kinkie>   submit branch: ../repo/squid-trunk
<lifeless> ok
<lifeless> what does bzr missing bzr+ssh://kinkie@bazaar.launchpad.net/%7Ekinkie/squid/cachemgr-refactor/ show ?
<kinkie> You have 6 extra revision(s): XXX omitted XXX
<kinkie> You are missing 1 revision(s): XXX omitted XXX
<lifeless> right, clearly you are diverged :)
<kinkie> (hm.. is omitted even english?)
<kinkie> Oookay. the 6 extra revisions are what I am trying to push.
<lifeless> kinkie: you have either uncommitted, or pushed a different branch to that url at some point
<lifeless> if you have whaqt you want, you can just push ---overwrite
<kinkie> I have what I want, what I'm missing is a merge from trunk which I performed anyways
<lifeless> so, push --overwrite
<kinkie> should I find myself in the same situation, what could be a resolution path? merge from the offending branch then push?
<lifeless> kinkie: look at whats missing, decide if you want to sync - merge & push, or replaace - push --overwrite
<kinkie> ok.
<kinkie> Thanks!
 * kinkie has to go now.
<kinkie> See you later / tomorrow!
<lifeless> kinkie: for a release branch, like trunk, you'd normally check that branch out, cd to it, merge your branch and push
<lifeless> ciao
<kinkie> ok
<kinkie> thank you very much.
<lifeless> beuno: ping
<beuno> lifeless, pong
<lifeless> hey
<lifeless> so thumper and I have some mino trouble
<lifeless> with rewrites
<beuno> hm?
<lifeless> so, we have a server with /gnome/project/trunk and /user/project/trunk
<lifeless> we want to present this as /project/trunk and /~user/project/trunk,
<beuno> hrm, the way we use URLs is far from ideal...
<beuno> you're using an htaccess?
<lifeless> rouhgly, yes
<lifeless> so we tried adding the gnome in a rewrite rulle, which works
<lifeless> and stripping the ~, which doesn't work
<lifeless> because loggerhead sees /user/ and does a 301 to /user/ causing epic fail
<beuno> hmm...
<beuno> I need to finish something, and I'll try and see how we can work around that
<lifeless> so I'd like the paste magic to say  '/gnome/' -> '/gnome/' and '/other' -> '/~other'
<MvG> Hi! I'm again trying to get a bzr branch for inkscape, and again I encounter errors. This time I'm using the branch at launchpad as a source.
<MvG> First I tried a simple "bzr branch lp:inkscape", then a "bzr branch http://bazaar.launchpad.net/~vcs-imports/inkscape/main". Both take ages and seem to freeze at some point.
<MvG> wireshark lists an awful lot of partial requests from the branch repository, which seems to be quite inefficient.
<MvG> To solve that aspect, I used wget to download the pranch with repository in a dumb but fast way. The fact that this is several times faster than a bzr branch should cause some worries, I think.
<MvG> So with that I had a local copy of the inkscape main branch on launchpad. I tried to branch from that, and again it froze at the same point the other access methods did. So it's not a server issue, and now I can reproduce it quite fast.
<lifeless> MvG: ok, can you file a bug then ?
<lifeless> MvG: it may not be a bug, and I'll be delighted to dig into it in detail, but I'm a little fenetic right now
<MvG> lifeless: I guess I could, but I'm not sure how much of this depends on current state of the branch, so debugging as much as possible today might be helpful.
<MvG> So what would you suggest in order to get more info for this. Is there some -D switch liekly to help?
<lifeless> well, if you hit ctrl-\ at the hung bzr,
<lifeless> you can get a debugger
<lifeless> and hit bt to get a back trace
<MvG> That's just what I wanted, thanks! I'll try locate the loop, and tell you my findings.
<lifeless> beuno: so, do you know how to ook into the url -> disk mapping layer easily?
<radix> hey guys, is there a prerelease with stacked branches yet?
<beuno> lifeless, not off the top of my head, sorry
<beuno> I may be able to poke at it in a few hours, but I'm in a tight schedule right now
<lifeless> beuno: I understand
<james_w> hey radix, I don't think so.
<james_w> radix: should be an rc1 with them in the next day or two I believe.
<radix> oh, nice
<rivo> hi
<rivo> I converted a part of a subversion repository to bazaar using bzr branch <svn repo url>
<jam> lifeless, abentley: If you want to see why the ha_ndbcluster.cc merge is tricky, here is its file revision graph (note, you want to wget it and view it locally, not in a browser):
<jam> http://bzr.arbash-meinel.com/mesh.png
<jam> The brown node is the unique lca
<rivo> is there any downsides to that, compared to properly doing  bzr svn-import ...?
<jam> the green nodes are the intermediate lcas
<jam> the red nodes are the revisions being merged
<jam> and all revisions that are ancestors of the unique lca have been pruned
<jam> rivo: Just that svn-import will do multiple branches for you at once
<jam> The results should be the same
<rivo> jam: ok, that's great
<rivo> jam: I couldn't get svn-import working, maybe because of the weird layout of my repo, but then it doesn't matter
<MvG> OK, I have some more information from my slow branch of the main inkscape branch from launchpad.
<MvG> It seems not to be an infinite loop, but rather incredibly slow processing.
<lifeless> MvG: puttting the backtrace in a bug will be useful
<lifeless> MvG: most incredibly slow processing cases are due to data-conversion paths
<MvG> It's busy in fetch.py in Inter1and2Helper._find_root_ids, iterating over some 4000+ id's, with each batch of 100 taking several minutes.
<MvG> And it only has this kind of problem when I branch into a pre-initialized rich-root-pack repo. A branch without shared repo workes fast enough to wait for it, although I still wouldn't call it "fast".
<james_w> MvG: what does "bzr info" on the branch you are pulling from report as it's repository type?
<MvG> james_w: pack-0.92
<james_w> so this is slowness from not-rich-root->rich-root
<lifeless> MvG: you're pulling into a rich root format from a non-rich root; I'm guessing the lp branch yyou're pulling is not the bzr-svn import
<MvG> What would you like to do about it? Have a bug report? Wishlist item? Some kind of benchmarking testcase? Or declare it as somebody elses problem?
<lifeless> MvG: its our problem; what we really want is to have everyone using rich-root, but there is a bug remaining to do the conversion
<MvG> lifeless: No, I don't think it is either.
<MvG> lifeless: I had tried to branch drictly from svn yesterday, but that failed due to a bug in bzr-svn, and I have seen no commit from jelmer since which would addressing that.
<lifeless> MvG: is it https://code.edge.launchpad.net/~ted-gould/inkscape/trunk that you are pulling ?
<MvG> lifeless: No, it's http://bazaar.launchpad.net/~vcs-imports/inkscape/main
<lifeless> MvG: please grab http://bazaar.launchpad.net/%7Eted-gould/inkscape/trunk/ it should be nce and fast
<lifeless> I'll tell ted to update the series
<MvG> lifeless: Thanks, I'll do that to work on inkscape. Classified "workaround", as the slowness issue still remains, though.
<jam> Odd_Bloke: I'm getting a bunch of test commits from you
<jam> Odd_Bloke: Rev 1: start branch. in	http://bzr.daniel-watkins.co.uk/pqm/work/_trial_temp/bzrbranch
<MvG> I've got a breakpoint in l347 of fetch.py, so I would get notified every 100 revisions. Last time I hit that is more than 10 minutes ago, so throiughput is less than 10 revisions per minute.
<MvG> As the inkscape branch has 6052, that would mean about 10h to convert everything.
<lifeless> MvG: the branch I have pointed you at will not do this conversion
<MvG> lifeless: I know, I just wanted to illustrate the scope of the slowness for situations where no workaround is feasible.
<jam> MvG: I believe if you branched locally into a non rich-root repository, and *then* branched into the rich root repository, it would likely be faster
<MvG> jam: Why would it be faster? I was working from a downloaded (wget) copy of the branch, so network traffic didn't play a role any more. Over the net, it was slower still, I think.
<jam> MvG: ok, I didn't realize you were using the local copy
<MvG> I guess that was way up there in the backlog, when I first told about this and lifeless introduced me to the breakin debugger.
<lifeless> MvG: so there is always a workaround - don't cross-grade the data
<MvG> As long as I don't need any of the features provided by rich root packs. As I couldn't name any such feature right now, I think it usually should work.
<Odd_Bloke> SimpleTAL makes my eyes hurt. :(
 * beuno hands eye drops to Odd_Bloke 
<beuno> :)
 * Odd_Bloke hands Mako to beuno.
<Odd_Bloke> ;)
<beuno> haha
<beuno> well, we looked into it
<beuno> it's faster, just not structured like we want it to
<beuno> *be
<Odd_Bloke> Structure within templates, or higher-level structure than that?
<beuno> within templates
<Odd_Bloke> I just don't like templating engines that put their structure inside the HTML elements.  It means I'll have to write a comment saying, essentially, what I could just write as code in one that uses a Mako/Django style.
<Odd_Bloke> Hmm, BB is down.
<Odd_Bloke> Ominously soon after I submitted the first patch testing the new functionality.
<Odd_Bloke> s/testing/utilising/
<radix> Odd_Bloke: there's a bzr buildbot?
<Odd_Bloke> radix: BB is BundleBuggy in bzr parlance.
<radix> oh, woops
<Odd_Bloke> :D
<MvG> Anyone here familiar with the gentoo overlay managed by malept? It caused bzr 1.5 to break here: http://rafb.net/p/xyIkQ870.html
<Verterok> MvG: I was getting the same error, then I changed to this branch of the overlay lp:~mocksoul/bzr-gentoo-overlay/bzr-gentoo-overlay
<MvG> jelmer: Starting from the bzr-svn branch of inkscape from http://bazaar.launchpad.net/%7Eted-gould/inkscape/trunk/ as mentioned above, I tried to pull the remaining revisions using bzr-svn directly from the svn repository. bzr-svn then crashed on me in find_tags: http://rafb.net/p/LdJtdP94.html
<MvG> Verterok: Thanks, I'll try that.
<emilis_info> I have heard there will be a bzr development sprint in EuroPython conference in Vilnius tomorrow
<MvG> The issue with the http://bzr.malept.com/bazaar-overlay/ branch can be reproduced on the command line with bzr 1.5, but current bzr.dev works fine. Do you intend bug-fixing maintainance backports to the 1.5 branch? SHould I report this somewhere?
<emilis_info> Couldn't find the guy who anounced it though
<emilis_info> anyone know anything about this?
<Verterok> beuno: hi
<beuno> howdy Verterok
<Verterok> beuno: still around Europe?
<beuno> Verterok, yeap, still working too.  I should be back on sunday
<beuno> how's your holiday?
<Verterok> beuno: quite nice, it's good to wake up late. also working, but in bzr-java-lib and xmlrpc service ;-)
<beuno> Verterok, I've been getting up at 7am, please don't tell me about waking up late  :)
<Verterok> beuno: ouch, I fully understands your suffering
<jam> beuno: bah, my son is waking me up at ~5:45 the last two days
<jam> kids seem to really sleep by the sun, which seems to be forgotten in our general society
<beuno> jam, well, I suppose you can nap when he does, babies sleep a lot
<jam> or at least, our son did, it is kind of hard to push them to stay awake or go to sleep earlier
<beuno> I don't think it'll look good if I fall asleep at a desk in Canonical
<jam> beuno: except he naps during work hours :)
<beuno> heh, right
<beuno> smart guy
<jam> the real trick is to not work until 1am
<jam> that helps a lot
<beuno> that is, if you can still manage the deadlines without doing so
<jam> I didn't know you were working at Canonical HQ.
<Odd_Bloke> I find that getting up to start work at 1am increases my productivity a great deal.
<jam> beuno: well, if you are having deadline problems, either they are unrealistic, or you have poor time management skills :)
<beuno> jam, been here last week, and will be here til the end of this one.  My trip was a bit... unexpected  :)
<beuno> jam, or both!
<jam> beuno: yeah, poolie mentioned your work rotation might get a bit interesting
<beuno> jam, hopefuly it will. I'll know the details in the next few weeks
<jam> beuno: I should also mention that he woke up about 4 times last night... at least it was always for a short time
<jam> sometimes he'll wake up at 3, and then not sleep for ~1 hr
<jam> silly babies
<emilis_info> jam, how old is he?
<emilis_info> :)
<beuno> jam, sounds fun
<jam> 10 months
<emilis_info> mine is 5 months today
<jam> grats emilis_info
<Odd_Bloke> I suppose one advantage of working for Canonical is that there'll almost always be someone up to work with.
<emilis_info> thanks :)
<jam> Odd_Bloke: except bzr is mostly US & AU, we need to get more Europe people hired
<Odd_Bloke> *COUGH*
<jam> Odd_Bloke: then what are you doing working if you started at 1am :)
<jam> by my count, it is ~7pm there
<Odd_Bloke> It was about 4am this morning.
<jam> ah, ok, keep working then
<jam> I wouldn't want you to slack off
<Odd_Bloke> I'm having to adjust from Australian to British time by Friday.
<jam> Odd_Bloke: what were you doing in AU?
<Odd_Bloke> I wasn't, I was just keeping AU time.
<Odd_Bloke> Until the last couple of days I haven't really been sure of what I was doing PQM-wise.
<radix> we try to keep consistent schedules in canonical, at least :)
<Odd_Bloke> And being on British time tends to mean I dump stuff at the end of the day and wake up to reviews being there.
<Odd_Bloke> Which isn't particularly helpful if I need to chat to someone about what I'm doing.
<beuno> Odd_Bloke, do what I did. Just sleep australia time.
<Odd_Bloke> beuno: Yeah, I was. :)
<beuno> and leave reviews for jam   :p
<jam> radix: 4-10 on mondays, 8-6 on tuesday-thurs, 8-4am on fridays ?
<jam> Odd_Bloke: well, I've been used to dumping stuff at the end of the day, and then *maybe* waking up to reviews for a while now :)
<jam> AU time starts when I get done
<jam> which has the small benefit that I *can* drop by in the evening and see poolie/lifeless
<jam> And I probably do that far too often :)
<Odd_Bloke> Heh.
<Odd_Bloke> I had noticed. :p
<jam> Anyone here know zsh very well?
<jam> I'm trying to configure my prompt by inserting the output of a script
<jam> and it doesn't seem to want to run ti
<jam> it
<jam> In bash, I just put $(command) into the PS1
<jam> Doing that in zsh just runs the command right away, and not each time
<jam> using \$(command) ends up only printing the string $(command)
<james_w> emilis_info: LarstiQ is at EuroPython I believe
<emilis_info> james_w, hmm... thanks. I'll need to find him tomorrow :)
<statik> anyone got a good example of how to use bzr-builddeb?
<james_w> hey statik
<james_w> if you are in a branch with ./debian/ then "bzr-builddeb" should build it
<james_w> are you trying to build something, or are you setting up a package in a branch?
<james_w> http://jameswestby.net/bzr/builddeb/user_manual/
<statik> hi james_w! i'm looking to create a new package, and i want to keep in in bzr
<statik> it's a really simple metapackage, which i'm adapting from another package, but the package I am copying from doesn't use version control
<james_w> cool, so is it a native package?
<statik> yes
<statik> this doc you pointed me to is good, I had not found that yet
<james_w> ok, native packages are easy :-)
<statik> james_w: that doc says I need to create the branch with --dirstate-trees, is that still true?
<james_w> the important bit is:
<james_w> $ mkdir .bzr-builddeb/
<james_w> $ echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
<james_w> $ bzr add .bzr-builddeb/default.conf
<james_w> statik: it's both wrong and false and outdated and stupid
<statik> heh, ok :)
<james_w> I need to push the updated docs there sometime.
<awilkins> jelmer: ?
<awilkins> Hmmph, these test reports need better instance-comparability
<GaryvdM> Hi - In qbzr you can run "bzr qlog FILENAME" to see the history of that file.
<GaryvdM> When you do that, unfortunately the ui locks up.
<GaryvdM> This happen during the call to branch.repository.texts.get_parent_map
<GaryvdM> see http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/279?file_id=liblogmodel.py-20080624153442-csesbwmxg0s8db2x-1#L121
<GaryvdM> Is there a way to do the incrementally?
<james_w> an --lsprof output might be helpful to know what's eating the time
<james_w> I'm not familiar with the .texts interface to know if it is likely to be slow
<james_w> I know that "bzr log filename" is very slow, but I think that is implemented in a different way.
<GaryvdM> I've been reading the code. If I could get to branch.repository.texts._index._graph_index.iter_entries - that is incremental
<GaryvdM> It's similar to "bzr log filename"
<GaryvdM> I'm not so worried about the speed. I would just like to be able to update our ui while it is happening.
<james_w> ah, I've looked above now, maybe not using a list comprehension for text_keys would allow you to make it incremental
<james_w> so, loop over self.merge_sorted_revisions calling get_parent_map each time
<GaryvdM> Oh - ok - let me try that.
<james_w> there shouldn't be too much of a performance hit
<james_w> if that works then you could experiment with batching
<james_w> the show_log code batches some of its operations, which makes a big difference.
<awilkins> Offtopic : who's good with XSLT?
<awilkins> CAn you pass a {$variable} as part of your input document and have the XSLT expand it?
<GaryvdM> Thanks james_w - That worked.
<james_w> really?
<GaryvdM> Yip - now it need to try get it to load on screen incrementaly
<GaryvdM> *now I need
<james_w> well, even a stopped clock is right twice a day :-)
<pygi> hi ho
<GaryvdM> lol
<james_w> hey pygi
<james_w> you get around :-)
<GaryvdM> Huh
<GaryvdM> bzr qlog bzrlib\tree.py
<GaryvdM> is now about 4x faster (wall clock time)
<GaryvdM> than bzr log bzrlib\tree.py >/dev/null
<james_w> GaryvdM: nice work
<james_w> have you looked to see if log itself could be sped up here?
<GaryvdM> Thats what I'm thinking.
<GaryvdM> james_w: Making the same change to bzr log makes it much faster.... :-)
<GaryvdM> Patch on the way.
<james_w> GaryvdM: great!
<mwhudson> is it log <FILE> specific?
<GaryvdM> Yes
<mwhudson> ah well
<mwhudson> :)
<james_w> I found that the limiting factor in plain log was revision extraction.
<jam> mwhudson, GaryvdM: I also will guess it will break our test suite
<jam> It is slow not because we can't get the graph of just the changes to a file
<jam> but because we want to see the revisions which merged those changes
<jam> So in:
<jam> A
<jam> |\
<jam> | C
<jam> |/
<jam> B
<jam> We want to see both 'C' and 'B'
<jam> even though the file was only changed in C
<jam> (This was back when we discussed per-file merge logic.)
<jam> GaryvdM: I would be happy to be proven wrong, though. :)
<mwhudson> jam: but if you  have the merge sorted revision graph (which log does) finding B from C really isn't so hard
<GaryvdM> jam: how do I check?
<mwhudson> GaryvdM: 'bzr selftest log' i would imagine
<GaryvdM> ok
<jam> mwhudson: I would guess you are right (though *getting* that merge sorted graph is also quite slow)
<jam> There are also issues with doubly nested merges, etc.
<mwhudson> jam: oh sure
<mwhudson> jam: but you need to do that anyway to be able to number the revisions (today, anyway)
<GaryvdM> Hmm - does break test :-(
<jam> GaryvdM: so if you have the per file graph, and you have the merge_sorted graph
<jam> I *think* you can start iterating over the merge sorted graph
<jam> when you find a revision that is in the per-file graph
<jam> you just need to include all merge sorted revisions with a depth < the current depth
<jam> until you reach mainline
<GaryvdM> ok
<jam> I can't promise that, but I think it would work
<mwhudson> there is code in loggerhead to do this :)
<mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head:/loggerhead/history.py#220
<mwhudson> that's perhaps not quite what you want
<mwhudson> but it has the flavour
<tolstoy> Hi Folks, I'm getting an error: ValueError: failed to deserialize tag dictionary ....
<tolstoy> Is there anything I can do about that?
<tolstoy> I can't "branch" the branch because of it.
<james_w> tolstoy: that sounds like file corruption to me
<james_w> of .bzr/branch/tags
<tolstoy> Hm. Just erase it and maybe to a pull or something from another branch?
<tolstoy> I think it has later tags, though.
<james_w> can you see what state it is in before doing anything?
<james_w> is there obvious corruption
<james_w> I'm not even sure that it's not a binary file though
<tolstoy> It's just a long string, but I don't know the format in order to tell what's corrupted.
<james_w> I think it might be rio, but I'm not familiar with it either
<tolstoy> The difference between it and the "HEAD" that it was branched from is a weird \n appended to it.
<james_w> I assume you haven't edited it at any point
<tolstoy> Nope.
<james_w> there was a problem recently where someone's dirstate had a \n appended as well, I don't think they share a codepath though
<james_w> it would be odd for disk corruption to just append \n to a file
<tolstoy> Very odd.
<tolstoy> Ah, okay. The "corrupt" one has a line feed, not the characters "\n" on the end of it, which I thought it did at first.
<james_w> so it ended \r\n?
#bzr 2008-07-10
<tolstoy> Hm. Not sure.
<tolstoy> I "fixed" it, but it's still bad. Time for some radical action here.
<GaryvdM> james_w, mwhudson, jam: I got it working. Tests show a 44% improvement. Patch in the mail :-)
<james_w> woo!
<poolie> hello
<mwhudson> hi poolie
<GaryvdM> If you do bzr log FILE, it does graph.iter_ancestry twice. In get_view_revisions and in _filter_revisions_touching_file_id
<GaryvdM> If you could reuse the parent_map from get_view_revisions in _filter_revisions_touching_file_id, it would be a huge saveing
<GaryvdM> I'm not sure how one would do that without changing the api?
<tolstoy> If you do a merge, but don't want it (because you didn't know about preview), is there a way to "unmerge" to get rid of all the changes you just pasted in?
<tolstoy> Ah. bzr revert.
<tolstoy> Well, there you go.
<pygi> :)
 * Foskasse <Red_Khmer_> FUI UM DOS PRIMEIROS A TESTAR O IRC BETA
 * Foskasse <Red_Khmer_> e tinha 212 irc cops a trabalharem para mim
<ferrum> Hey guys, I'm trying to check out the Gnash trunk to work on it. The guys who usually help us aren't present at the moment..
<ferrum> It's hosted by Savannah; I'm using the commands on https://savannah.gnu.org/bzr/?group=gnash , but they all exit immediately with "ERROR: Not a branch"
<ferrum> any help would be appreciated
<bob2> they somewhat lie - you need to append the branch name
<bob2> e.g. 'trunk'
<ferrum> bob2: ah, works. thanks
<pygi> funny thing ... bzr viewer is broken because of that too xD
<mwhudson> beuno: are you here?
<libwilliam> I am having trouble with C/Python with the BugTracker class I hope someone can help me with. Here is my current code
<libwilliam> This is more a problem with me having a hard time understand the C/Python part
<libwilliam> I can get the class but I don't know how to get an instance of that BugTracker class to call the methods on.
<Verterok> libwilliam: BugTracker() ?
<libwilliam> i am both happy and pissed it is that easy ;)
<Verterok> libwilliam: sorry, just looking at the code
<Verterok> libwilliam: the "right" way to do it, is using the registry
<Verterok> 'tracker_registry'
 * igc lunch
<libwilliam> Verterok, thanks, I will try that out
<Verterok> libwilliam: somethign like: tracker_registry.get(key='gnome')
<Verterok> np, glad to help :)
<lifeless> hi
<arjenAU> yeye
<ToyKeeper> Hmm, having trouble getting 'bzr.dev selftest -v blackbox' to finish.
<ToyKeeper> It just gets stuck forever on ...test_outside_wt.TestOutsideWT.test_url_log
<mwhudson> hi libwilliam
<mwhudson> no
<mwhudson> hi lifeless
<libwilliam> hey
<mwhudson> libwilliam: sorry :)
<libwilliam> haha, no prob
<ToyKeeper> D'oh, sent a message before my list subscription was finished, so now it wants moderator approval.
<ToyKeeper> (just a quick fix for bug 247150)
<ubottu> Launchpad bug 247150 in bzr "'bzr init-repo' requires LOCATION; should default to '.'" [Undecided,In progress] https://launchpad.net/bugs/247150
<sm> evening all
<Odd_Bloke> Moin.
<Odd_Bloke> Waking up with light outside feels weird...
<lifeless> moin
 * ToyKeeper finally gets back to the bzrk-with-diffs thing
<ToyKeeper> I got most of the issues fixed, but haven't yet taken care of DiffWidget not wanting to update.
<ToyKeeper> For now, it's worked around by destroying and creating a DiffWidget every time its contents need to change.  Yuck.
<beuno> mwhudson, I am now  :)
<beuno> thanks for the search review, I'll try and address the concerns today
<mwhudson> beuno: ok, cool
<mwhudson> (that's what the ping was about unsurprisingly)
<beuno> :)
<beuno> I'm off to get breakfeast
<lifeless> ook
<lifeless> my machine just oopsed
<lifeless> bbiab I hope
<salubrium> I have a php project (vtiger) that was developed using Unix line breaks, then some developers have added quite a bit of modifications and many files are using Windows line breaks. Bazaar is detecting all these files as modified even though their content is the same
<lifeless> salubrium: hi, you want the EOL conversion feature; this hasn't quite landed yet but you can probably get the pieces and test yourself. Hhowever - running a script before commit to force the line endinds to unix should ba  goo dwork aorund
<lifeless> I would say that 1.7 will have what you need without workarounds
<salubrium> I am new to Bazaar, by the way. I am trying to use it to perform a code-comparison to see what the previous developers have hacked. I tried using dos2unix to convert back to Unix.. but it seems that base Vtiger must use some windows line breaks in some libraries
<lifeless> salubrium: ah, that would be annoying
<salubrium> thanks lifeless.. do you know if Git or Mercurial have a "ignore line break" option?
<lifeless> they do; I can't comment on how easy to use etc
<lifeless> salubrium: well, to be more precise, they have a feature for during commits
<lifeless> salubrium: I don't think thye have an arbitrary ignore-after-the-fact, but I may be wrong
<Odd_Bloke> ToyKeeper: On the "init-repo ." bug report you mentioned sending a merge request.  Is my mail server being dodgy, or has it not quite been sent yet?
<salubrium> Thanks for your help lifeless
<lifeless> salubrium: no problem; sorry I couldn't help more -
<ToyKeeper> Odd_Bloke: I sent it to the bazaar list, but it was sent a few minutes before my list subscription was completed...  so it's probably waiting in the moderator's queue.
<ToyKeeper> Odd_Bloke: I could re-send if desired.
<Odd_Bloke> ToyKeeper: Don't worry about it, I was just wondering what had happened. :)
<ToyKeeper> It's a tiny patch for an unimportant bug, so I figured it could wait.  :)
<Odd_Bloke> lifeless: If you have time to merge one branch into pqm.dev, the fix-tests branch which you've already reviewed would be good.  ATM I'm having to merge it into just about every branch I create myself, and I don't think I can submit branches which depend on it to BB without confusion ensuing.
<lifeless> Odd_Bloke: you can submit branches with it - just use cherrypicks from it to your tip :)
<lifeless> Odd_Bloke: that said, whats the url for fix-tests; I'll see what I can do
<Odd_Bloke> lifeless: http://bzr.daniel-watkins.co.uk/pqm/fix-tests/
<lifeless> Odd_Bloke: tests fail
<lifeless> bzrlib.errors.FileExists: File exists: u'/tmp/testbzr-Tm95nh.tmp/tmp2Rh46g/work/bzrbranch/.bzr': [Errno 17] File exists: '/tmp/testbzr-Tm95nh.tmp/tmp2Rh46g/work/bzrbranch/.bzr'
<Odd_Bloke> lifeless: I can't replicate here.
<lifeless> 'make check' ?
<Odd_Bloke> lifeless: I'm still not seeing it.  I get "exceptions.IOError: [Errno 13] Permission denied: '/usr/lib/python2.4/site-packages/twisted/plugins/dropin.cache.new'" from trial itself, but the tests then go on to pass.
<lifeless> Odd_Bloke: ok, was a bzr version skew thing I think
<Odd_Bloke> lifeless: OK.  I'm using 1.5 here.
<ToyKeeper> Okay, got the most annoying bugs fixed in the new 'bzr vis' diff panel.
 * ToyKeeper ponders whether to submit a merge request now, or wait until after he's added something to remember panel/window sizes
<lifeless> ToyKeeper: now!
<ToyKeeper> 'k, I'll send it.
<ToyKeeper> D'oh, forgot to commit NEWS first.
<Odd_Bloke> Hmm, unit testing HTML is annoying.
<Odd_Bloke> I want to make sure that the SimpleTAL template that I'm about to write produces equivalent HTML to the Mako template I already have, but don't care about irrelevant whitespace being the same.
<neobug> Odd_Bloke: you could use BeautifulSoup to parse generated HTML
<neobug> and compare the tree with the one from Mako template
<Odd_Bloke> neobug: Yeah, that's in the back of my mind.
<lifeless> Odd_Bloke: I would prefer simpletal please
<Odd_Bloke> lifeless: Yup, I'm working on that this morning.
<mgedmin> where could I find a version of bzr-svn that works with the current stable bzr (i.e. 1.5)?
<LarstiQ> mgedmin: bzr-svn 0.4.10 I believe
<mgedmin> bzr-svn in hardy is too old, http://people.samba.org/bzr/jelmer/bzr-svn/stable wants bzr 1.6
<LarstiQ> mgedmin: http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions 0.4.10 works with 1.4 and 1.5
<mgedmin> thanks
<mgedmin> now I only have to find it somewhere...
<mgedmin> found the tarball on launchpad
<Odd_Bloke> I'm really struggling to get my head around SimpleTAL.
<beuno> Odd_Bloke, let me know if I can help. I went through that phase recentely
 * mgedmin can't wait for history horizons to become available...
<Odd_Bloke> I think this all boils down to my basic hatred of SGML-based markup languages.
<Odd_Bloke> Perhaps I was abused my Tim Berners-Lee as a child.
<Odd_Bloke> More seriously, the issue seems to be that Mako's macros are much more expressive than SimpleTAL's.
<Odd_Bloke> And I can't work out how to deal with that.
<nandersson> Sorry if this is a bit off topic, but I would like to know if OpenSUSE Build Service would be of any use to Ubuntu, or if it's a competing platform with Launchpad.
<nandersson> I'm curious as I write for Swedish tech-mag TechWorld Open Source
<mgedmin> what was the name of that bzr plugin that lets you publish branches using avahi?
<james_w> nandersson: #launchpad might be a better place for you to ask that
<james_w> mgedmin: bzr-avahi?
<mgedmin> right
<james_w> mgedmin: bzr-dbus and bzr-gtk are also useful to have if you are using it
<mgedmin> my mistake was searching on bazaar-vcs.org rather than on google
<nandersson> james_w, ok. I'll check!
 * mgedmin wishes the bazaar ppa had these useful plugins in it
<Odd_Bloke> beuno: So ATM I'm passing in a list of dictionaries representing messages.  Is there any way I can get the length of that list, or do I need to pass that in separately?
<beuno> Odd_Bloke, you can do inline python with:    python: len(list)
<beuno> withing an attrbute
<beuno> you want to show the amount of results/list length?
<mgedmin> okay, I'm beginning to think the pain involved in installing bzr-avahi (and then trying to get someone else how to do that, but this time on Mac OS X) is more than the potential gain...
 * mgedmin is at a sprint for a project that uses svn and would have liked to try DVCS for sharing prototypes
<mgedmin>  oh, the latest bzr-avahi doesn't work with the latest bzr-dbus anyway
<mgedmin>  from bzrlib.plugins.dbus.server_mainloop import MainloopThread
<mgedmin>  ImportError: No module named server_mainloop
<james_w> mgedmin: it looks like it may require https://code.edge.launchpad.net/~jamesh/bzr-dbus/kill-broadcast-daemon then
<jamesh> yeah.  I've got to go over a few changes lifeless suggested and get it merged ...
<mgedmin> hm...
<mgedmin> I managed to get the plugin to work after rm -rf avahi; bzr co -r 32 lp:bzr-avahi avahi
<mgedmin> what is the bzr-speak for "svn up -r 32" when I have a bzr checkout?
<mgedmin> i.e. getting the working tree to match an older revision?
<mgedmin> anyway, bzr serve claims to work now, although bzr browse finds nothing when I run it on the same machine
<mgedmin> should it?
<mwhudson> mgedmin: svn up -r == bzr revert -r
 * mgedmin will try to remember
<mwhudson> mgedmin: also 'bzr share' not 'bzr serve' ?
 * mwhudson is not here
<mgedmin> bzr: ERROR: unknown command "share"
<mgedmin> bzr help avahi says I'm supposed to use bzr serve
<mgedmin> and all I needed to do was bzr advertise!
<jamesh> mgedmin: I'd suggest running the above bzr-dbus branch and up-to-date bzr-avahi instead
<mgedmin> yey!
<jamesh> mwhudson: current bzr-avahi uses hooks to run out of standard "bzr serve"
<mgedmin> jamesh: do I really have to?
<mgedmin> now that I got the older ones working?
<mgedmin> also, is it hard to get bzr-avahi running on Mac OS X?
<mgedmin> or even possible at all?
<jamesh> mgedmin: well, if the old version does what you want, go for it.
<jamesh> mgedmin: but if you have problems I'd suggest upgrading
<mgedmin> okay
<mgedmin> what I want is to share the branch easily with someone sitting right next to me, who has a Mac laptop
<Odd_Bloke> beuno: Thanks, that's helped a lot.
<poolie> lifeless: ok so the problem is that the RepositoryPackCollection also knows about fallback repositories, but add_fallback_repository doesn't tell it when one is added
<beuno> Odd_Bloke, you're welcome. Although, abusing that defeats the purpose of separating code from presentation, so use wisely  :)
<poolie> lifeless: ping?
<james_w> hi poolie
<LarstiQ> ok, online again
<james_w> hi LarstiQ
<james_w> are you sprinting today?
<poolie> hello james_w, LarstiQ
<Odd_Bloke> beuno: I'm using <div>s in most places which require content to be replaced, but this causes linebreaks around it.  Is there a better element to use, or do I need to add 'tal:omit-tag=""' to all of them?
<LarstiQ> james_w: yeah
<LarstiQ> james_w: neobug, emilis_info, cyberix and mhammond are also here right now.
<LarstiQ> james_w: The two Italians (I don't know their names unfortunately) are having lunch.
<emilis_info> :)
<beuno> Odd_Bloke, well, span elements won't add line breaks
<mgedmin> Odd_Bloke: use <div tal:replace="new content" />
<mgedmin> instead of tal:content=...
<LarstiQ> neobug, emilis_info: so how are you doing? :)
<neobug> LarstiQ: I fixed that bug with spaces in editor path, now writing the test
<LarstiQ> neobug: cool
<lifeless> poolie: hi; I'll ring you in a minute
<LarstiQ> emilis_info: to summarize, you're looking at bug 109115, you're looking at code to see what the codepaths are that call bytes_to_gzip()?
<ubottu> Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115
<emilis_info> LarstiQ, yep
<emilis_info> I'm trying to find the correct place to show the error
<LarstiQ> right
<emilis_info> now int repository.py ... record_entry_contents()
<emilis_info> s/int/in/
<james_w> emilis_info, LarstiQ: rockstar was looking at that bug the other day. I think he was working out how to test it.
<emilis_info> james_w, I have some shell code that reproduces it
<LarstiQ> rockstar: ayt?
<lifeless> Jc2k: ping
<ChristopheT> Hi.  What is the best way to put a local bzr branch into a new branch on a pristine svn repository (no branches yet).  I tried push but got "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<jelmer> ChristopheT: bzr svn-push
<jelmer> ChristopheT, There's an open bug about this
<ChristopheT> jelmer: indeed, I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ('Delta does not fill the target window', 185003)"
<jelmer> ChristopheT: Hmm, that bit is not expected actually
<jelmer> ChristopheT, What version are you running?
<SteveA_> LarstiQ: hi
<ChristopheT> bzr 1.6b3, bzr svn 0.4.11exp0.  I will pull the lastest version of bzr-svn
<jelmer> ChristopheT: This is most likely a regression in 0.4.11
<ChristopheT> jelmer: I still eget the same exception
<jelmer> ChristopheT, is this a public branch you're trying to push?
<jelmer> ChristopheT: With 0.4.10?
<SteveA> hi jelmer :-
<SteveA> )
<ChristopheT> jelmer: I am trying to push to svn+ssh://svn.forge.ocamlcore.org/svnroot/pa-do/trunk
<jelmer> SteveA: Hoi Steve
<ChristopheT> I have the rights to do so
<jelmer> ChristopheT: What branch are you trying to push?
<olleolleolle> jelmer: Hi, interested in bzr2svn here. SteveA said it'd be... useful.
<jelmer> olleolleolle: Hi
<olleolleolle> Thinking of using its API to avoid lotsa munging and collecting SVN metadata. bzr2svn could be a friend in that case, I hope.
<jelmer> olleolleolle: What sort of metadata would you ike to gather?
<jelmer> ChristopheT: What branch are you trying to push?
<olleolleolle> "Gimme all the diffs from rev 0 to now," so I can visualize it nicely. I had started with "svnadmin dump" output.
<jelmer> ChristopheT: Can you run with BZR_PDB=1 set?
<olleolleolle> is bzr2svn a Tailor script?
<ChristopheT> jelmer: I did a "svn co https://pa-do.svn.sourceforge.net/svnroot/pa-do" and a "bzr branch my-branch trunk"; can I just add, commit and push?
<jelmer> olleolleolle: bzr-svn is a bzr plugin, there's also svn2bzr which is a python script
<jelmer> ChristopheT, yeah, you should be able to
<ChristopheT> jelmer: BZR_PDB=1: I am in the debugger.  Now what do I do?
<olleolleolle> Thanks, jelmer.
<jelmer> olleolleolle: Are you interested in the unified diffs as text or rather the semantical information?
<SteveA> jelmer: my thought was, if they're working on visualizing revision history, then using bzr's API is going to be a good thing to use.
<olleolleolle> (unified diffs as text, I think. I am kinda making a "terrain map of my code")
<jelmer> SteveA: Ah, that makes sense
<SteveA> jelmer: and, as it's reasonably easy to either convert a SVN repo to bzr format, or to interact with it using bzr-svn, then that makes it a good plan.
<ChristopheT> jelmer: It starts with
<ChristopheT> **** entering debugger
<ChristopheT> > /home/trch/.bazaar.dev/plugins/svn/commit.py(539)commit()
<ChristopheT> -> lock.unlock()
<jelmer> olleolleolle,SteveA: Just running "bzr viz" on a Subversion repository should work
<jelmer> ChristopheT, Can you pastebin the backtrace ("bt") somewhere?
<SteveA> jelmer: I'm flying back to amsterdam shortly.  see you later.  olleolleolle's going to keep hacking on this here :-)
<jelmer> SteveA: Ah, you're at EuroPython? Have a good flight
<jelmer> olleolleolle: Are you looking to just browse the history of your project or actually generate a report with all the diffs, etc?
<olleolleolle> generating a report, painting a picture, using that information, yep.
<olleolleolle> Dumb q: When I install the bzr-svn plugin, is it enough to do "sudo python setup.py install"? Or is there a step I am missing?
<ChristopheT> jelmer: .bzr.log: http://pastebin.com/d2a21fd36
<jelmer> olleolleolle: No, that should be sufficient if you've also got bzr itself installed
<olleolleolle> I installed bzr 1.5 using the Installeer for OS X 10.5.
<jelmer> olleolleolle: You will also need to have the Python Subversion bindings (with several patches) installed if you're using a released version of bzr-svn
<jelmer> This is a bit of a pain at the moment, but necessary because there are several bugs in the bindings that bzr-svn otherwise hits
<olleolleolle> Oh, thanks. The reason I tried to avoid MacPorts was that... I have a functioning Python that I don't want to break. I'll go look for the bindings now.
<jelmer> Alternatively, you can use the development version of bzr-svn which only requires the (vanilla) Subversion development headers are present
<olleolleolle> Sounds good to me.
<jelmer> ChristopheT, thanks
<jelmer> blegh, annoying netsplits...
<jelmer> ChristopheT, Hmm, doesn't help much determining what's wrong  :-/
<uws> jelmer!!
<uws> jelmer: je werd genoemd!
<jelmer> uws!!1!!!!1!1!!ONEONE!
<uws> jelmer: ging over bzr-svn en bzr mirror van gnome
<poolie> hello uws
<uws> hi poolie
<jelmer> ah, cool
<jelmer> hey poolie
<uws> you're at europython?
<jelmer> uws, is de beslissing al gevallen?
<jelmer> uws, no, I'm in dublin
<jelmer> uws, @ wilmers
<jelmer> dinner
 * uws at guadec
<poolie> night
<olleolleolle> http://people.samba.org/bzr/jelmer/bzr-svn/ Is the development version "trunk" or "bzr.dev" ?
<olleolleolle> (Am looking for bzr-svn, still.)
<a_c_m> support?
<a_c_m> humm no bot then.
<a_c_m> :)
<kgoetz> sorry, i just filed a bug (which may be a dupe). if its a dupe hope one of you lot can pick it :)
<kgoetz> 247270 (fwiw). ineternet connection just let the bug through :|
<ChristopheT> jelmer: "doesn't help ...": anything else I can send you?
<Odd_Bloke> a_c_m: Hi. :)
<a_c_m> Odd_Bloke: hey, just formulating a massive message asking my question ;)
<Odd_Bloke> a_c_m: Cool.
<a_c_m> ï»¿I have what i hope is a common situation that i'm looking for a nice solution for - which i hope bzr is. We are a small, but growing drupal development shop, So we depend on CVS updates from drupal.org. We also want to have our own mini versions of the core drupal.org CVS which our projects looks to as thier source e.g.    drupal.org --[updates]-->our drupal version--[updates]--
<a_c_m> >our projects
<a_c_m> is such a thing possible / easy to do?
<james_w> hi a_c_m
<a_c_m> hi james_w
<james_w> at https://code.edge.launchpad.net/drupal launchpad provides an import of drupal CVS you could base your work on
<james_w> you can also see branches other people have made based on that
<james_w> what you could do is branch the main copy and make your changes, and then distribute that for your shop to base their work on
<LarstiQ> poolie: I think there should be two mails to the list that need approval, could you approve them?
<james_w> then every day or few days you can grab the latest from drupal CVS with "bzr merge lp:drupal"
<a_c_m> james_w: exactly! so that when a new version comes out, we update our branch and test it, before pushing it out to the sub projects
<james_w> that should work nicely
<a_c_m> james_w: i think we will only ever take releases from the drupal.org upstream (is upstream the right term?), as otherwise it could become a lot of work
<james_w> in that case you can just run "bzr merge" when upstream releases.
<james_w> I don't know drupal's release strategy, do they release from trunk, or do they make branches?
<a_c_m> james_w: branches... i think as trunk is waaaay ahead of where the stable release are
<james_w> hmm, not sure how cscvs deals with branches
<james_w> you may want to enquire about launchpad mirroring the stable branches as well for you, as that may suit you more
<a_c_m> james_w: humm... wouldnt it be simpler just to import the drupal.org branch myself?
<a_c_m> james_w: locally?
<LarstiQ> olleolleolle: I'm currently a bit wound up, but if you want to grab me later to discuss things here at EP, you're welcome :)
<james_w> a_c_m: possibly, I have no experience with importing CVS to bzr, and how painful or not it may be, so I thought that if launchpad could do it for you it may save you some work.
<a_c_m> james_w: heh, fair enough - seems like somthing people might use too, drupal is quite popular ;) do you know who i would need to talk to?
<olleolleolle> LarstiQ: sure
<a_c_m> james_w: but also do you know any good tutorials on setting up that kind of staged upstream system?
<jelmer> olleolleolle, http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<james_w> a_c_m: there are a couple of people that hang around here, but they are at the wrong end of the world for you at the moment I expect
<a_c_m> k well i will hang about in here for a while, guessing the are US based right?
<james_w> a_c_m: there is #launchpad, but I think one of the best ways might be a question on launchpad on the launchpad-bazaar project.
<james_w> a_c_m: the best person to ask is actually antipodean, but one of the US guys might know
<a_c_m> james_w: going to do some more reading and a bit of playing now - sink a few hours into it;)
<james_w> kgoetz: hi, are you using a proxy by any chance?
<kgoetz> james_w: i *shouldnt* be
<lamont> bzr log foo/ --> shows me the initial import of the directory.  bzr log $(find foo/) gives me an error.
<kgoetz> james_w: i dont seem to be ($http_proxy and $HTTP_PROXY are both empty)
<lamont> so... how do I get a log of all the changes to all the files in a directory?
<lamont> "iteration" is not the answer I want to hear
<LarstiQ> lamont: I'd think bzr log foo/ would do that. Hmm.
 * beuno has seen this discussion before, but can't remember the outcome
<lamont> LarstiQ: that was also my foolish notion
<markh> lamont: so what does it show for you?  Just a single log entry that reflects the initial import?
<james_w> lamont: there is a long open bug about that
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/97715
<ubottu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed]
<lamont> markh: yep
<a_c_m> james_w: seems like bzr-fastimport might be of use to me...
<james_w> a_c_m: yup
<ChristopheT> jelmer: I have this error "bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'lstrip'" when I do "bzr log --line" on a svn co (http://pastebin.com/d7e817d3c)
<Odd_Bloke> beuno: Thanks for the speedy suggestions. :)
<stewart>  anybody got an idea on why it takes 4 or 5 hours to push a mysql branch to launchpad? (even when it's my 2nd branch). Does launchpad not use a shared repo ?
<pax> hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos...
<pax> ?
<thekorn> hi, I've once again a 'is it a bug or a feature'-question:
<thekorn> when I do   bzr log -r -2..  i get the text of the last two changes
<thekorn> when I run  bzr diff -r -2.. I get the diff from the last commit until now
<beuno> Odd_Bloke, glad to help  :)
<thekorn> for me it looks like inconsistency
<uws> jelmer: No decision yet
<awilkins> Could someone try pulling http://www.datadictionary.nhs.uk/software/dd-publish for me?
<thekorn> so it looks more like a bug, any opinions?
<hmeland> thekorn: Not sure I understand what you think is inconsistent, but log is a repository-querying command, while diff can peruse both repository and working tree.
<james_w> stewart: no, it does not, there is development right now to make this much quicker
<stewart> james_w: that'd be nice. as right now it's unusable for collaboration, 5+hrs is a long time.
<james_w> hi thekorn, there is reasoning for this I believe, I'm just trying to dig it out of the depths of my brain.
<thekorn> hmeland, ok, but this is something I as a user do not know, I expect '-r -2..' to return not confusing results
<thekorn> james_w, hey, ok, thanks :)
<james_w> hmeland: it's not due to the working tree, the effect is visible even with no uncommitted changes
<hmeland> Ah, I didn't spot that you said "the last" on "diff -r -2..".
<pax> hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos...?
<james_w> hmeland: make it -r-2..-1 and you get the same discrepancy
<james_w> pax: not currently, no
<thekorn> my usecase is: a contributor tells me he changed something in his last two commits, so I run  bzr log -r -2..  to see his messages,
<thekorn> and after this I would like what he changed, so I intuitively run bzr diff -r -2..
<hmeland> I still think the repository-only/repository-and-tree difference is relevant, though.
<james_w> thekorn: yeah, I can't remember the reason, sorry. I imagine that if you change this you get some weirdness showing up elsewhere
<hmeland> Say you commit a change, push it, then decide you want to revert it.  You bzr revert, but want to verify that your tree now really doesn't have any differences wrt. how it looke before the erroneous commit.  What options should you give to bzr diff?
<james_w> though I do think having log not show the start of the range would be reasonable.
<james_w> hmeland: "bzr diff -r-2.." isn't it?
<hmeland> james_w: So "bzr log 1.." shouldn't show the first commit message?
<james_w> hmeland: correct
<james_w> that's one thing that would be weird at least
<james_w> thekorn: you could file a bug, I have a hunch it would be closed, but at least you would get a reason :-)
<thekorn> :)
<thekorn> ok, will do
<thekorn> thanks hmeland and james_w
<hmeland> james_w: Yes, exactly -- "diff -r -2.." gives you the diff from *just before* the most recent commit until the current tree state.
<thekorn> atleast it is maybe a documentation issue: both help (bzr help diff and bzr help log) are refering to "help revisionspec"
<thekorn> and a difference is not mentioned there
<james_w> yeah, mention that in the bug
<james_w> revisionspec mentions nothing about ranges as far as I can see, and the individual command should probably mention how they interpret the range
<awilkins> Anyone serve Bazaar repos from IIS?
<hmeland> revisionspec says that "-2 is the second-to-last commit", and bzr help diff says that "bzr diff -r1..2" is the difference between rev 2 and rev 1.  Doesnt that infer that "diff -r-2..1" is the difference between the second-to-last commit and the current tree, i.e. for an unmodified tree the changes introduced by revision -1?
<hmeland> I think there's something I'm not getting here... :-)
<hmeland> Sorry, s/-r-2..1/-r-2../
<radix> hmeland: when you leave off the second revision, it means "the state of the working tree"
<hmeland> Yeah, hence my "for an unmodified tree" reservation.
<radix> but if you use -1, it means "the most recent revision", so the distinction is whether it includes uncommitted changes
<radix> hmeland: what you said sounds right
<ToyKeeper> hmeland: If you want the diffs from the past two revisions, try -r-3..-1 instead.  (it's off by one)
<radix> yeah, "the difference between the second-to-last revision and now" won't include the change that *caused* the second-to-last revision
<hmeland> I'm just trying to understand why people think the difference in the amount of revisions included in the reports "bzr log -r -2.." vs "bzr diff -r -2.." is a bug.
<hmeland> They both appear sane to me.
<awilkins> I like the way .pack files are named for their md5sum
<awilkins> Ok ; I'm trying to dumb-serve a repo from IIS ; why am I getting "Expected a boundary" errors
<awilkins> Expected (q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl) line, got '--<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>
<awilkins> It looks really close, anyone know what the problem is?
<james_w> awilkins: is there a proxy involved?
<stewart> question: how come i'm getting moved files reported as removed and added?
<awilkins> james_w: If you wget the file, it matches it's MD5
<stewart> more importantly, how will this affect merges
<james_w> stewart: did you move them with "bzr mv"?
<stewart> james_w: i think so... but may have accidently run "bzr add" on them...
<ToyKeeper> hmeland: Since log shows 3 revs worth of changes and diff shows 2, it could be considered confusing.
<awilkins> james_w: There is a proxy, probably
<stewart> james_w: (after having bzr mv)
<awilkins> james_w: I am not privy to the secret machinations of the NHS network provisioning team
<stewart> james_w: any way to retro-actively bzr mv (i haven't committed yet)
<james_w> stewart: if you used "bzr mv" first then "bzr add" wouldn't have done anything
<james_w> stewart: try "bzr mv --after"
<james_w> stewart: if that doesn't work then "bzr rm --keep" the new name and then "bzr mv --after"
<james_w> awilkins: I'm thinking of https://bugs.edge.launchpad.net/bzr/+bug/198646
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released]
<james_w> awilkins: bzr is used in the NHS? :-)
<awilkins> james_w: Well, the project isn't finished yet, but yeah, I guess it is.
<awilkins> james_w: I'm going to add it to the Hall of Fame when I get a sign-off on this project
<stewart> james_w: seems to be working, thanks!
<james_w> awilkins: cool
<awilkins> james_w: bzr AND bzr-eclipse :-)
<james_w> stewart: did you have to "rm"/
<stewart> james_w: yes, did have to "rm --keep" and then mv --after for each one
<james_w> stewart: good to know, thanks.
<awilkins> james_w: Plus bzr-gtk (local branch thereof)
<awilkins> james_w: We're using my home-built 1.6b2 ATM because it's so much faster than 1.5
<awilkins> james_w: But I've been tracking the tip of many things ....
 * CardinalFang waves to guilhembi.
<guilhembi> Hi CardinalFang , but what's a Fang?
<CardinalFang> guilhembi, The name is a Monty Python reference.  It seemed fitting in #python a few years ago.
<hmeland> ToyKeeper: I see your point, but I don't think it holds up; for example, I find it entirely reasonable that "bzr log -r1..1" reports one revision, while "bzr diff -r1..1" reports no changes.
<rockstar> LarstiQ, I am now.
<jam> a_c_m: By the way, if you are trying to use Bazaar + Drupal, they do have conversions available: http://drupal.org/node/45368
<a_c_m> jam: thanks... but thats just head, which is version 7 atm... were working with version 5, so its not so helpful. But i think bzr does hold the key - i just created a test local repro, added one of our sites and then updated it to a new version of drupal, by hand - without bzr missing a beat (unlike SVN which just wont do it).
<a_c_m> james_w: just asked in #launchpad :)
<awilkins> Gah, this is SOO annoying
<awilkins> I'm trying to dumb-serve a bzr repo out of IIS. Through a debugging proxy, chained to our main proxy, it works fine
<awilkins> Heh, ISA works, FreeProxy doesn't
<awilkins> MS finally does something right
<ToyKeeper> hmeland: Yeah, I don't claim the diff/log behavior is wrong, but I can see why someone might find it confusing.
<mtaylor> if I do bzr log --gnu ... and I get "no such option gnu" for some people, but it works for me.
<mtaylor> where is the --gnu coming from?
<awilkins> mtaylor: A plugin that overrides the log options?
<mtaylor> hrm.
<awilkins> mtaylor: The help should list the option and which plugin it comes from
<mtaylor> :)
<mtaylor> howabout the gnulog plugin
<ChristopheT> Something is strange.  When I do  bzr.dev merge https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/
<ChristopheT> I get: "Nothing to do."
<ChristopheT> But when I try: "bzr push https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/"
<ChristopheT> it replies with the error: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
<luks> umm, push over https?
<luks> oh, it's svn
<james_w> what does "bzr missing https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" tell you?
<kiorky> yo guys, does bazaar supports something like in-working-copy-branches from git or namedbanched "ala" mercurial?
<luks> no, but it does support branches without working trees, and a way to switch a working tree to a different branch
<ChristopheT> james_w: "bzr missing" tells me that I have 3 extra revisions (basically merges from that repo).  So I guess I branch from https://pa-do..., merge in my revisions and pull, right?
<kiorky> lazy1: so if i have a/ as a bazaar repo, it has two branches 1/ and 2/ , a/ can be switch on 1 and 2, so why isnt that different from  "in-working-copy-branches"?
<kiorky> s/lazy1/luks/
<ChristopheT> s/pull/push/
<kiorky> luks: the prolem i got is that mercurial deceived me with the namedbranches :p, i cant delete them, i cant rename them
<james_w> ChristopheT: if you have 3 extra revisions then push should not say that have nothing to do
<james_w> maybe there's some interaction with svn that I'm not getting though
<james_w> kiorky: it looks pretty similar to working-copy-branches, but you do have external branches
<ChristopheT> james_w: it is "merge" that says "nothing to do".
<james_w> the distinction matters to some people, not others
<james_w> ChristopheT: ah, sorry.
<james_w> ChristopheT: ok, so you shouldn't be told that they have no common ancestor, again unless there is some bzr-svn subtelty I am missing
<kiorky> james_w: the use case is integration with svn, i want to have in my repo the svn branch, and features branches
<james_w> ChristopheT: but your solution should work
<kiorky> james_w: can the rbranches be local, i mean: can the branches not be pushed on a central repo ?
<james_w> kiorky: absolutely.
<kiorky> whow !=
<kiorky> features i miss on mercucrial :)
<kiorky> james_w: now, for the integration with the existing stuff i have. Is there something to do as the mercurial forest extension to organize a bunch of repos
<james_w> I'm not familiar with forest
<kiorky> ok
<kiorky> let me a moment
<kiorky> james_w: Overview
<kiorky> The Forest extension allows operations on trees with nested Mercurial repositories, called forests. Those to some degree correspond to multi-project CVS/Svn/... repositories.
<neobug> kiorky: I don't see why you should push branches to the central place in mercurial
<kiorky> james_w: you have a tree with sub mercurial repos, that you can serve, this solve the partial checl out problem for example
<james_w> ah, I got it
<james_w> no, bzr doesn't have that yet
<neobug> doesn't it depend on the style the developers are using the mercurial?
<kiorky> neobug: if you make named branches, they are pushed
<neobug> oh
<ChristopheT> james_w: Ack! "bzr.dev branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" starts downloading the revision bu then tells "bzr: ERROR: The branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/ has no revision None."
<neobug> I probably missed this detail
<james_w> ouch
<ChristopheT> james_w: .bzr.log: http://pastebin.com/d5fbaed93
<kiorky> neobug: :), frustrating isnt it ?
<kiorky> neobug: do not try the localbranch extension it is quite unusable
<james_w> ChristopheT: not sure what's causing that. It's an odd level to get that message from though
<neobug> well, I haven't used named branches so it's hard to say :-)
<kiorky> james_w: so how can you organize large repo?
<kiorky> james_w: my structure is there for example : http://hg.minitage.org/
<ChristopheT> james_w: Worth to file a bug?
<james_w> ChristopheT: probably
<james_w> kiorky: you mean how should it be organised without an equivalent to the forest extension?
<kiorky> james_w: yep
<kiorky> james_w: i m used to have tree based organization
<kiorky> james_w: so i dont know how to make in an other way
<james_w> kiorky: I'm not sure, unfortunately if you require the forest-like behaviour you are pretty stuck
<james_w> you can make each of those in to branches fine, there is just no way to grab the top level and get them all, say.
<kiorky> james_w: ok, tahts not a problem
<kiorky> james_w: i just want to organize/have partial checout
<kiorky> james_w: but then, how can i make a branch of a sub branch?
<james_w> you can make separate branches in the same way as you have separate repos in hg, you just can't define the structure like you can with forest
<james_w> it has to be done up front though, there's no partial checkout facility either
<semslie> I've managed to leave bazaar in a locked state by killing the gcommit process before actually committing. Is there a way to unlock it?
<gour> semslie: bzr break-lock?
<semslie> gour: thanks!
<kiorky> james_w: i will try to get a tree structure this evening
<Jc2k> lifeless: ping
<ToyKeeper> Oh, that reminds me...  I was having gcommit issues I should take a closer look at.
<ToyKeeper> ... or not.  Works fine after pulling updates.
<cyberix> Is there a transport neutral way to find out whether some path is pointing to a directory or just an ordinary file?
<cyberix> local transport has _check_mode_and_size, but that's just the local transport
<alecwh> One of our team members pushed to our repository, in Launchpad, but he didn't have the latest changes to begin with. When he attempted to push (after he commited his changes, he had 3 commits), the branch warned him that he needed to "merge", so he did this: "ï»¿bzr merge lp:phpns". Now I want to undo what he did. How?
<james_w> alecwh: he pushed after?
<alecwh> Sorry, he didn't push, he just did a "merge"
<james_w> and commit?
<alecwh> He TRIED pushing
<alecwh> yes
<alecwh> 3 commits.
<alecwh> here is the repo: https://code.launchpad.net/~phpns-team/phpns/head
<james_w> hmm, I'm not sure I understand, you're trying to fix that branch, or just the one on this developer's machine?
<alecwh> we're trying to fix the branch. It looks like we lost several commits from me.
<alecwh> We just want to "revert" to before he merged.
<alecwh> so everything will be normal again.
<james_w> so he did push after?
<alecwh> let me check.
<james_w> is "	kyle's EE in. Ready for packaging (if no more fixes)" the revision that you had as the tip beforehand?
<alecwh> Yes, I believe so!
<james_w> cool, if you have a branch locally you can do this:
<james_w> if you run "bzr log -r -1" then you will see your revisions merged in, the number of the top one of these (the indented ones) should be 26.1.4
<alecwh> I have a copy of the branch (the one with the merge) on my desktop
<james_w> so, if you run "bzr pull --overwrite -r 26.1.4 ." then it will put your copy of the branch back on that revision.
<james_w> If you then run "bzr log" you should see it as it was before.
<james_w> you can then push that back to lp:phpns. However, it won't let you do that as you have changed history, so you need to pass --overwrite there as well.
<james_w> You should check that you have what you want locally before you push though. The situation wouldn't be unfixable, but it's better to catch it early
<james_w> once your happy with that I can help you get the other developer's changes merged properly
<olleolleolle> LarstiQ: Eh, are you still in the... room?
<olleolleolle> No.
<alecwh> james_w: okay, I just pushed the changes with --overwrite, but it isn't showing up on Launchpad. This is just lag, right?
<alecwh> it did say "Pushed up to revision 30."
<james_w> yeah, I think so
<alecwh> that worked great then!
<james_w> do you understand how the other developer should have merged to avoid this?
<alecwh> Okay, now, that developer (Kyle) still has those 3 commits we want to put in
<alecwh> james_w: no, how?
<james_w> ok, so with this style of development each developer should keep a mirror of trunk on their machine that they only run "bzr pull" in normally (using a shared repository will make this very cheap for them).
<james_w> they then have at least one other branch that they do their work in. You can have loads, or you can just have one, it works the same.
<james_w> when you are at a stage where you want to push your work to launchpad you "cd ../trunk; bzr merge ../my-branch"
<james_w> this merges in all your changes, you fix up any conflicts and then commit
<alecwh> okay.
<james_w> you can then push directly to launchpad
<james_w> the chances of colliding with someone else when doing this are very small, but if it keeps happening then there are ways to avoid it, but it's probably better to keep it simple for nwo
<james_w> this means that you only ever have merge commits on the trunk, and my work doesn't "swallow up" your work like just happened
<james_w> I can help you to do this for the three commits if you like, as you won't be able to see them in your branch at the moment
<alecwh> so, assuming the branch is now fixed (merge was removed), I think I'll have HIM clone the branch, and just copy over his "changed" files (because he still has a copy of that merged branch that we fixed), and just commit/push
<alecwh> there is no need to branch, because it's all tested and fine.
<james_w> that would work, but we can preserve history if you would like
<alecwh> okay, but those 3 commits he made are gone from the LP repo, correct?
<james_w> they'll still be in the repo, but won't be visible, and won't be copied in when grabbing the code
<james_w> bzr doesn't delete revisions, even if you do something like we just did. It's a small cost.
<james_w> I mean it's a small cost that they are there even though they are not needed to have some safety about not losing them.
<alecwh> okay, can we get those "visible" as concurrent revisions? So, his would be revs 31, 32, 33?
<james_w> yes, that's a "rebase" operation. You would need a plugin to do that.
<james_w> I can easily tell you how to resurrect them and then merge them so they would just be rev 31, but would show as merged revisions still
<alecwh> Hm, I think it would be easier with what I said above
<alecwh> james_w: okay
<james_w> ok, so first we need to pull his commits out in to an old branch.
<alecwh> so, I need to grab the last commit before he made his?
<james_w> For this we will need the revision id of the tip when the branch was messed up. we need the revision id as the revisions are no longer present in the history of your branch, and so won't be given revision numbers.
<james_w> I just so happen to have the relevant id here: k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8
<james_w> so if you run "bzr branch -rrevid:k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8 your-branch/ new-branch/
<alecwh> okay, great. This will give me the branch before we fixed it?
<james_w> then run "bzr log" in "new-branch/" you will see the branch being back to it's broken state
<james_w> yes, exactly.
<james_w> now you can "cd ../your-branch; bzr merge ../new-branch"
<alecwh> Branched 29 revision(s).
<james_w> once you commit you can examine "bzr log" to see what this looks like
<james_w> when you are happy you can again push, and you won't need the --overwrite here, as you didn't modify history, just appended to it.
<alecwh> what does:  M* inc/config.php
<alecwh> mean?
<alecwh> the *
<james_w> permission change I believe
<james_w> a "bzr diff" should say
<james_w> "bzr help status-flags" mentions it
<alecwh> alecwh@alecwh-laptop:/var/www/websites/phpns_2.2.3$ bzr push lp:phpns
<alecwh> Pushed up to revision 31.
<alecwh> james_w: you are a life saver! Thanks so much, seriously, this fixes everything
<james_w> great, glad to be of help
<sm> I'm so confused.. might there be a page describing PQM and Bundle Buggy ? who develops them, who uses them and how they relate to each other ?
<Klaas111> hi all
<jasper> When I send patches to bzr-gtk@lists.canonical.com the right target_branch is not set (see bzr-gtk mailing list today). Maybe someone knows how to improve the given answer of setting ~/.bazaar/locations.conf?
<Klaas111> hoping that dummy questions are ok here
<jam> jasper: I think you want to not set "...:policy=appendpath"
<Klaas111> I'm using bzr with bzr-svn because I'm tied to a svn repo
<jam> I hope you can see that through the smiley
<jasper> what smiley :)
<jasper> Ok, I'll try
<Klaas111> there's a couple of config files that are part of the project (checked in)
<Klaas111> but I'd like to have local modifications without checking them in and annoying my colleagues.
<Klaas111> what's the proper way to do this? that is, without having to manually exclude them each time, or move them away
<MvG> jelmer: Yet again I'm trying to pull from the inkscape repo using bzr-svn, and every day there is something new. As the delete item bug has been fixed now I get a loop in "finding branches 2/3". The progress bar stays fixed most of the time, but occasuonally it jups back 7 chars and fills those up to the previous position. Seems like there was no progress. Can I provide any useful debug information here?
<jasper> Jay!, had to work around some local testing cruft, but I now have ' target_branch: https://code.launchpad.net/~bzr-gtk/bzr-gtk/trunk'. Is this ok, or should I loose the trunk bit?
<jam> I'm curious why that is the recommend URL, versus http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk or https:/code.launchpad.net/bzr-gtk, or any of the multitude of ways of referring to that branch.
<jam> But that is between BB, abentley, and the bzr-gtk group :0
<jasper> True.. but with the locations.conf file I don't have to worry about it anymore. I can just use 'bzr send -o bla.patch' again
<jasper> jam: thanks for the help! I have written a mail with the (I hope) proper workflow to the list
<jasper> So, what are the chances for a bzr-gtk release in the near future?
<beuno> jasper, I believe jelmer plans to release this week
<beuno> and, also, I believe I promised I'd review patches
<beuno> which I haven't been able to yet  :/
<jasper> time or access rights?
<beuno> time, unfortunetly
<beuno> access rights is much easier to fix  :)
<radix> oh, sweet, rc2!
<radix> ahhh, I need to switch to a new PPA
<jasper> beuno: only the queued ones on BB or the whole bunch recently merged?
<beuno> jasper, just the queued ones, the other are, well, already merged  :)
<jasper> well.. I know of 4 easy one liners in the queue :)
<beuno> jasper, yeah, hopefully I'll have some time tonight
<Odd_Bloke> sm: I dunno if you're still around, but if you have a more specific question about BB/PQM, I could try answering it.
<sm> thanks Odd_Bloke
<sm> are these two parts of one system, or two competing/complementary systems ?
<sm> both come from within canonical I assume
<sm> or maybe one came from canonical/launchpad, and one from bzr ?
<Odd_Bloke> sm: They're complementary.
<Odd_Bloke> sm: Neither come from Canonical, originally.  BB is Aaron Bentley's creation, so that a bzr background.
<Odd_Bloke> sm: PQM comes from Arch/Baz, so does have some Canonical involvement.
<Odd_Bloke> That's about as much of the history as I know.
<sm> that helps reduce my confusion, thanks
<james_w> hey Odd_Bloke
<sm> I think currently both are used by basically two teams - launchpad and bzr
<james_w> they don't have any direct interaction currently, but they could, it would be good to have, and it might well happen.
<james_w> I'm not sure that launchpad use BB for their development
<Odd_Bloke> sm: bzr certainly use both.
<Odd_Bloke> james_w: Hi. :)
<jam> james_w: They don't use BB, afaik
<james_w> hey jam
<jam> They *do* use PQM
<jam> they actually use a coordination point of a wiki
<james_w> Odd_Bloke: nice patch flood :-)
<jam> I don't know if they are dogfooding the Launchpad review queue
<jam> stuff
<jam> I know they want to get away from a wiki where they post changes to be reviewed, etc.
<sm> and basically PQM handles background pre-commit testing, and BB provides a web/email interface for patch review & voting, would that be right ?
<jam> sm: There are several Bazaar projects (bzr-gtk, bzr, pqm, etc) that are using Bundle Buggy. But it was pretty much just developed because we were getting too many patches to have a simple mailing list keep us from dropping stuff.
<jam> So Aaron basically codified our working practice around the mailing list
<jam> presenting a nicer UI, etc.
<jam> sm: correct
<sm> and both are available for other projects to use ?
<Odd_Bloke> james_w: Thanks. :)
<Odd_Bloke> sm: Yes, both are GPL, I believe.
<sm> great.. much clearer, thanks for the answers
<sm> one more I guess, have y'all found them to help a lot ?
<jasper> from a 'user' perspective, BB looks like a great system
<Odd_Bloke> BB is great.
<Odd_Bloke> I'm spending the summer working on getting PQM somewhere up to that standard.
<james_w> sm: BB has definitely helped with the process I would say
<james_w> I don't have PQM rights to know if it's a pain at the moment, but it does give something to the project, similar to what you get if you start using continuous integration in a project.
<hmeland> Hmmm.  In my bzr.dev mirror branch, when I do "bzr log dir-or-file", the output always includes a few revisions, no matter which directory or file I supply.  Are anyone else seeing anything similar?
<james_w> extra revisions? the same revisions every time?
<hmeland> Yup, apparently... I'll pastebin, hold on.
<Odd_Bloke> It's hard to imagine how the bzr project would function without BundleBuggy.  Without PQM, we'd just have to have a human patch queue manager.
<sm> Odd_Bloke: why not just post/discuss/vote on patches on the mail list, and merge by one or more human gatekeepers when appropriate ?
<sm> like eg the linux folk ?
<sm> just curious
<sm> that's what I do in my smaller project, but I'm wondering how to make the process more robust
<sm> I guess so that you can handle a greater volume of patches without confusion
<luks> sm: it's easy to miss patches that way
<Odd_Bloke> sm: Well, BundleBuggy helps to make sure things don't get lost.
<Odd_Bloke> Heh.
<hmeland> james_w: http://pastebin.ca/1068483
<james_w> hmeland: sorry, pastebin.ca doesn't work for me, can you use another?
<hmeland> I first tried pastebin.com, but my output tripped their spam filter... any others you'd recommend?
<Odd_Bloke> ubottu: paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<Odd_Bloke> hmeland: ^
<hmeland> http://paste.ubuntu.com/26528/
<james_w> so there's a problem with directories that it normally only shows the revision in which the directory itself was created
<james_w> I guess here they may be some funky stuff going on in early history that mean that you get multiple entries
<james_w> though some of it isn't that old
<hmeland> I know about the non-recursive directory log thing.
<hmeland> I'm more worried about the revisions that get printed for both contrib/ (line 1-55) and bzrlib/ (line 56-109).
<MvG> jelmer: I added some mutters to repository.py and now found out what inkscape was doing here. I got it to print, among others, the value of bp in the loop in SvnRepository.find_tags. While I pull from inkscape/trunk (relative to the root of the repo), it seems to examine not only inkscape/tags/* but */tags/* for possible tags. And as that is a lot of unrelated history, this operation seems to take quite a while. Wouldn't it make sense to try determine
<hmeland> But, is this only something that I'm seeing here, or are others getting similar output?
<MvG> jelmer: Sorry, of course that's bzr-svn doing that, while pulling inkscape, not the other way round.
<hmeland> I've tried with --no-plugins, btw -- and saw no difference from what's on the pastebin.
<jasper> I just upgraded bzr to 1.6b2, and just as in 1.5 I get SmartTCPServerHooks deprecation warning when checking out from lp. Do I have to remove some conf foo somewhere?
<james_w> jasper: do you get it with --no-plugins
<jasper> no, but the lp: functionality is gone too in that case
<jasper> old bzrtools version?
<Odd_Bloke> jasper: What does 'bzr plugins' show?
<jasper> avahi 0.3.0dev0, bzrtools 1.5.0, gtk 0.95.0dev1 launchpad
<jasper> hmm.
<jasper> must be the launchpad plugin
<Odd_Bloke> jasper: It'll be avahi.
<jasper> doh :P
<Odd_Bloke> I think the latest trunk has the fix.
<jasper> you are right
<jasper> hmm.. 'bzr checkout lp:bzr-avahi avahi' in ~/.bazaar/plugins/ now gives me 'Unable to load plugin 'avahi' from (..)' messages
<james_w> -Derror will tell you why
<james_w> perhaps that you need bzr-dbus
<jasper> seems there is a server_mainloop missing from dbus according to avahi
<jasper> more importantly, the MainloopThread from server_mainloop
<james_w> jasper: yup, you need a different branch of bzr-dbus for latest -avahi
<james_w> apparently revision 32 of -avahi will work with the trunk of -dbus
<jasper> Ok.. thanks. But since I don't think I'll use both I'll just move them out of the way for now
<jasper> on a different note, I made bzr 1.6b2 bork with MemoryError >:) (bzr checkout lp:mysql-server/6.0 on a P4 2.4 GHz, 512mb ram)
<poolie> good morning
<poolie> jasper: if that was pulling over bzr+ssh you should try using sftp instead
<jasper> I'll try with sftp another time. Time to go now. Bye all.
<RAOF> It seems the gstreamer project will be moving from cvs to $DVCS.  Currently the sole contender is git, because there are a couple of people who will actually do the migration/support work for git.  Is this interesting to anyone here? :)
<jam> poolie: guess what... I get more conflicts if I don't sort the merges by their ancestry order when inserting into the weave
<jam> poolie: So it seems that the dependency ordering into the weave file really does matter
<jam> poolie: of course, my test case keeps breaking when I fix other things because suddenly topo_sort emits the revisions in a different order
<jam> (It will return the right parent first, if the right parent has no more ancestry, otherwise it returns the left parent first)
<AfC> RAOF: you might send that in a brief email to the mailing list. There are a lot of people travelling right now. "Possible opportunity to advocate Bazaar to GStreamer" or something like that.
<pygi> RAOF, we can help with the bzr questions, sure
<AfC> pygi: it doesn't sound like there are going to BE any bzr questions. :(
<pygi> RAOF, does anyone from Gst community uses bzr?
<LarstiQ> pygi: some people at Fluendo afaik, although not Thomas himself
<pygi> LarstiQ, we can't really push for bzr outside
<pygi> it has to be done inside, we can only be a helping force
<LarstiQ> pygi: they're pretty much in the Gst community
<pygi> well, I know, thus make them push for bzr, and we can eventually help them :P
<LarstiQ> we actually talked about that today
<RAOF> There are certainly people on the gstreamer list who express a preference for bzr, and more who are concerned about git's poor windows support
<RAOF> The stated preference for git is because someone has volunteered to actually do the migration/answer questions, and a desire to move away from cvs _now_.
<LarstiQ> RAOF: I'm pretty sure we can help with migrations.
<pygi> and we can answer the questionss
<RAOF> That's what I was thinking, reading the discussion.
<LarstiQ> RAOF: considering other migration help with mysql and gnome in the recentish past.
<Peng> beuno: Ping?
<beuno> Peng, at your service
<Peng> beuno: Just a random Loggerhead idea that I wanted to throw out there.
<beuno> shoot
<Peng> It isn't necessarily a good idea, but anyway... Currently, when you visit /some/branch/, you get redirected to /some/branch/changes. It might be neat if Loggerhead showed a regular directory listing just like the web server would, with a link to the changes view.
<beuno> Peng, right, the Files view
<beuno> there has been some discussion around what's the best default
<Peng> Ah, I forgot about that. I meant an actual directory listing of the directory, not the Bazaar data.
<Peng> My use case is that I serve my branches at /bzr/some/branch/, and have Loggerhead at /loggerhead/some/branch/. I occasionally throw up a file or two in the branch directories (usually a 'bzr send' patch), and am wondering...I dunno.
<beuno> ah, I see
<beuno> well, I personally don't have a use case for it, but I can see why you would want that
<beuno> I don't think it would be too hard
<beuno> and since I want to be able to serve branches from LH, directory listings will be needed on the logic
<beuno> so, feel free to file a bug requesting it
<poolie> jam, hi
<poolie> interesting
<jam> poolie: and that's not all.... :(
<jam> It seems the ordering I "happened" upon in my earlier patch is the most optimal
<jam> but it isn't quite anything as far as I can tell
<jam> I'm still investigating
<jam> I had a bug in one of my functions
<jam> so it wasn't returning things in the order I thought it was
<jam> and then I was using tsort
<jam> and combined, that gives the fewest conflicts
 * jam is quite sad that non-deterministic ordering was winning
#bzr 2008-07-11
<izm99> I have a branch stored on my webserver, and I did a checkout on it.  but I can't commit.  I get bzr: ERROR: Cannot commit to branch BzrBranch6('file://local-path'). It is bound to BzrBranch6(sftp.....') which is bound to sftp:same-path.
<izm99> so BzrBranch6(sftp-path) is bound to sftp-path sounds circular... but I have no idea....
<LarstiQ> izm99: that sounds as if the branch on your server is a checkout.
<izm99> LarstiQ: so how can I commit to it?
<LarstiQ> izm99: what does `bzr info` return for sftp:remote-path?
<izm99> checkout root: .
<izm99> oh sorry.. of remote path.. one sec
<izm99> branch root: http://stevenbrown.ca/src/AttrDict/
<izm99> bound to branch: sftp://blah@blah/src/AttrDict/
<izm99> related branches: push branch: sftp://blah@blah/src/AttrDict/
<LarstiQ> and the bound branch is the same as that branch itself?
<LarstiQ> 'bound to branch'
<izm99> i kinda fudged when I put it up there....  Â¬_Â¬
<LarstiQ> izm99: if so, that's rather silly. Issue a `bzr unbind` on the remote branch.
<LarstiQ> izm99: after that, you should be able to commit in the local one.
<izm99> oooh.. ok, i'll try
<izm99> wait, do i have to ssh into the remote host to do that?
<LarstiQ> izm99: yeah, fraid so.
<izm99> dang
<izm99> bzr isn't actually installed on that.
<LarstiQ> if you're not afraid to touch .bzr we can do it without bzr installed.
<izm99> i'm in
<izm99> :D
<izm99> (i have a local copy anyways, this is a learning exercise)
<LarstiQ> ok
<LarstiQ> izm99: see .bzr/branch/branch.conf
<LarstiQ> izm99: it should have a bound_location and a boolean 'bound' option.
<LarstiQ> izm99: toggle the latter to false, and you should be good to go.
<izm99> hmm....  it let me commit
<LarstiQ> izm99: so your problem is fixed now?
<izm99> not really... it didn't actually change the files
 * LarstiQ needs a bit more context
<LarstiQ> where did you commit, and where didn't files change?
<izm99> yeah, sorry, I'm trying to poke around...
<izm99> Committing to: sftp://stiibu@stevenbrown.ca/home/stiibu/stevenbrown.ca/src/AttrDict/
<izm99> added COPYING
<izm99> modified attrdict.py
<izm99> modified test_attrdict.py
<izm99> Committed revision 2.
<izm99> (woops username.. oh well)
<LarstiQ> that looks like it worked to me.
<izm99> ya..
<LarstiQ> izm99: I'm guessing you're expecting the checkout on stevenbrown.ca to also have updated?
<izm99>  bzr status http://stevenbrown.ca/src/AttrDict -> bzr: ERROR: Path(s) do not exist: http:/stevenbrown.ca/src/AttrDict
<izm99> yes i am
<LarstiQ> that doesn't actually happen.
<izm99> oh.
<izm99> i have to push?
<LarstiQ> izm99: no no, the .bzr file got updated fine.
<izm99> (unless I'm bound)?
<LarstiQ> izm99: so the question is, what are you trying to accomplish?
<izm99> i wanted to update the remote branch with my commit
<LarstiQ> izm99: if you just want to publish your branch, you don't have to do anything extra, since all bzr cares about is .bzr, and that's updated.
<LarstiQ> izm99: is your use case something like website deployment?
<LarstiQ> izm99: or do you want to be able browse the content of the branch?
<izm99> yeah, i want the source to browsable, as well
<LarstiQ> izm99: ok, for the latter I'd probably recommend running loggerhead to do that.
 * izm99 googles
<LarstiQ> izm99: That's an actual webfrontend akin to things like viewcvs if you are familiar with that.
<izm99> yes, I'm familiar
<izm99> so the changes have been committed, but the actual files are not updated?  The changes are stored in the .bzr somewhere?
<LarstiQ> izm99: The changes have been commited, yes. The files outside of .bzr are not touched, I wouldn't call them 'actual files' though :)
<LarstiQ> izm99: so, if you wanted to updated the files there, you could do 'bzr update'
<izm99> ooooh....
<LarstiQ> izm99: there is a plugin to ssh into the remote machine and run update after a push if you want something like that.
<izm99> so I should pretty much at least install bzr on the remote machine...
<izm99> I was trying to avoid any server stuff...
<LarstiQ> izm99: if you want to do code browsing there, yes.
<LarstiQ> izm99: the alternative is having to transfer all the files in the working tree every time, that's rather expensive though.
<LarstiQ> izm99: at this point I would step back and consider if browsing on the server is really what I want to do then.
<izm99> hah.. ok, I believe you.. i just tried another checkout. :P
 * izm99 checks local bzr version
<izm99> so, there's likely incompatibilities between bzr versions, right?
<izm99> my local is : bzr 1.3.1, python 2.5.2;;  remote is : python 2.3
<LarstiQ> izm99: depending on versions, yes. But you're not combining 0.11 with 1.5 are you?
<LarstiQ> izm99: ah see, we kinda depend on python2.4 or higher.
<izm99> i'm just curious ... ya, that was my next question.
<izm99> i figured the python would be too old.
<izm99> >.<
<izm99> is it a bzr option to transfer the working tree?
<poolie> izm99: check out bzr-upload plugin
<LarstiQ> izm99: yes
<izm99> hmm.. ok, should i take the debian or trunk branch of bzr-upload?
<LarstiQ> izm99: the debian branch is specifically for Debian packaging, it doesn't bring you other benefits.
<izm99> oh ok.
<LarstiQ> izm99: it might mean that you can just apt-get install bzr-upload depending on what suite of Debian you are running. But bzr 1.3.1 looks older than what is in sid.
<LarstiQ> and I doubt it's in anything else at this point.
<izm99> i'm using hardy
<izm99> just searched, not there
<izm99> i'll follow the directions to branch into .bazaar/plugins/ directory.
<LarstiQ> right
<izm99> i'm guessing a lot of plugins have a hypen in the name...  it'd be nice if bzr had some install_plugin command that renamed the plugin branch appropriately when grabbing it.
<LarstiQ> yes
<izm99> whoo! it worked.  Thanks for all the help!
<LarstiQ> izm99: so, _now_ everything you want to do works? :)
<izm99> yes!  LarstiQ: Thank you very much.  :D
<LarstiQ> good, good.
 * LarstiQ continues poking at python-nautilus.
<izm99> ^.^
<LarstiQ> for some reason the nautilus-bzr stuff doesn't work when I think it should.
<LarstiQ> But phatch has a nautilus extension that does work, so it _is_ possible.
<pygi> it's so amazingly funny
<pygi> you know Novell folks also work/will work on nautilus-bzr, right? xD
<pygi> what happened with the collaboration I though exists in FOSS world? :-/
<pygi> oh well
<LarstiQ> pygi: huh what?
<LarstiQ> how should I know this?
<pygi> at least I think that's correct, If I understood right
<pygi> I'll have to investigate
<pygi> LarstiQ, no idea, I'm just talking in general xD
<LarstiQ> pygi: the problem was that nautilus doesn't pick the script up from ~/.nautilus/python/, but it does look at /usr/lib/nautilus/extensions-1.0/python/
 * LarstiQ insers an extensions-1.0 in his home dir variant
<LarstiQ> pygi: I'd like to know more about that. Have you been at GUADEC this year?
<pygi> LarstiQ, I haven't, no ...
<pygi> LarstiQ, I'll investigate that more for you in the coming days, to see if I got it right
<pygi> but I think I have, and there'll also be nautilus-hg, nautilus-git and similar
<LarstiQ> strace ftw, .nautilus/python-extensions
<LarstiQ> pygi: riight.
 * pygi has to make them collaborate with you then =)
<LarstiQ> pygi: I admit to not having followed bzr lately.
<pygi> but I'm sleeping now, it's 2:35AM, and I gotta get up in 3 hours and 25 minutes :P
<LarstiQ> pygi: so Mark Hammond and I discussed TortoiseBazaar today, and our idea was to use the same code at one side of the pipe, and/but write a small nautilus thingy that does the equivalent of windows shell.
<pygi> enjoy folks :)
<LarstiQ> pygi: have fun
<pygi> LarstiQ, we'll talk about that tomorrow, ok?
<LarstiQ> pygi: yes/no
<LarstiQ> pygi: please do talk to me
<LarstiQ> pygi: but I'll be away untill Sunday/Monday
<pygi> LarstiQ, ah, ok, then Monday it is :)
<LarstiQ> pygi: you can paste links at me and I'll read my backlog when I get back.
<pygi> sure, that works too perhaps :)
 * pygi is officially in sleep-mode
<LarstiQ> sigh, I'm reminded of why I didn't use nautilus in the first place.
<izm99> LarstiQ: why not?
<LarstiQ> izm99: I recall there being some option to turn it off, but the main thing that is annoying me right now is it's autospawning.
<izm99> LarstiQ: oooh... yeah, that bothers me sometimes too, actually.  never bothered looking for how to turn it off.
<izm99> LarstiQ: but i'm interested to try the new tab interface...  :)
<LarstiQ> also, I don't appreciate it chaning my root window.
<LarstiQ> ah, -n is helpful
<LarstiQ> emilis_info: Just installed taglist (finally!), quick test looks great!
<LarstiQ> emilis_info: so thanks :)
<arjenAU> hmm, branch lp:,mysql-server going since yesterday arvo... still going...
<igc> poolie: i have some user doc on stacked branches in progress. Will put a patch up later today.
<igc> explaining 'policies' is the main thing left to do
<poolie> igc, hi
<dan1> does bazaar support encrypted repositories? i searched and found only one plugin that released no code and has not been touched in a year. anyone know of anything else?
<poolie> i think there's just that
<poolie> so no, they're not supported
<dan1> ok, thanks. i sent an email to the author asking about it.
<arjenAU> I was going to ask, why... you can have it on an encrypted fs anyway
<poolie> arjenAU: well it would be kind of nice to host it on an untrusted server
<arjenAU> it's distributed, allover the place, bzr needs to know the pwd anyway... and so on. messy. and slow
<poolie> it is a bit of an edge case
<arjenAU> poolie: well that's true I suppose. but would you really... that's tricky for other reasons
<poolie> imo it's more of a cool feature than a useful one
<arjenAU> poolie: yup. nice for later. right now, aim for speed. the mysql-server branching is upsetting me a bit, fortunately its a one off but it's heading towards a 24hr thing
<poolie> could you be maybe pulling into or from a knit repository?
<poolie> jml, i think i have a fix now
<poolie> happy to say
<jml> poolie: sweet
<jml> poolie: I am happy to hear it.
<libwilliam> I was wondering what the default merge algorithm was. in the user reference it shows 4 options, diff3, lca, merge3 and weave but doesn't show what the default it.
<libwilliam> is*
<mwhudson> libwilliam: merge3
<libwilliam> mwhudson, thanks
 * igc lunch
<poolie> arjenAU: so i can branch mysql-6.0 from launchpad in about 20 minutes
<poolie> and my adsl link is busy with other stuff
<poolie> it should be roughly comparable for you?
<arjenAU> poolie: i' grabbing mysql-server (that is all branches)
<poolie> but if you put them in a repo most of the data should be shared?
<arjenAU> and I have ADSL2+.. it's not eating the bandwidth. it's just slow as. no idea what it's doing
<poolie> check using bzr info they have the same format
<arjenAU> hmm
<arjenAU> remote? on lp?
<arjenAU> poolie: perhaps i'm confused somewhere. on my box I just do bzr init-repo mysql, cd mysql, bzr branch lp:mysql-server
<arjenAU> flawed logic that that should be ok?
<arjenAU> I think the repo-init was done with an old bzr, I've just restarted the whole thing and we'll see....
<arjenAU> that might've been the issue.
<arjenAU> poolie: would be godo to have bzr complain about version stuff between repo and the branch you're trying to get. also, perhaps have lp refuse ancient bzr clients to protect them against what I had the other day, namely bzr pulling about 20G of data and putting it nowhere. ate my iiNet allowance ;-)
<stewart> poolie: it'd be great if you could bug the launchpad ppl to have init-repo there, takes 7+hrs to push a mysql branch :(
<mwhudson> stewart: stacked branches coming soon!
<stewart> mwhudson: yay :)
<mwhudson> in a couple of weeks i guess
<Peng> How big is the repo for one branch of mysql-server?
<Peng> stewart: FWIW, I push things to shared repos on my own server, and have Launchpad mirror from there. It still uses lots of my server's bandwidth, but pushing is quick.
<stewart> Peng: 500mb or so i think....
<stewart> $ du -sh ~/mysql/.bzr
<stewart> 619M	/home/stewart/mysql/.bzr
<stewart> that's shared repo... but i'm pushing 6.0 branches, which is latest, so includes about all history.
<Peng> Nice. I tried to branch it once on a VPS with very little memory and it almost died. :D
<stewart> Peng: yeah... branching into shared repo is quite quick (2minutes for a new mysql branch being pulled from europe over bzr+ssh over ADSL1). wish it was that quick for pushing to lp
<mwhudson> i guess it
<mwhudson> 's not worth it with stacked branches looming, but otherwise i'd suggest getting a machine in the uk you could host a shared repo on and have lp mirror those branches, like Peng said
<Peng> Yeah, exactly.
<stewart> mwhudson, Peng: there's machines and stuff within Sun that i could do that with, although it involves going through people, not as direct as "bzr push lp:...."
<mwhudson> stewart: you can probably make it pretty easy actually (have you seen register-branch?) but well yeah
<mwhudson> stewart: hence why stacked branches are priority 1
<Peng> stewart: If you have to go through people, they probably won't appreciate you using that much disk space and bandwidth.. :P
<poolie> arjenAU: yes, those commands are correct; yes, we should make it give a warning when doing a transfer or conversion that will be slow
<poolie> or possibly on any access to a really old format
<poolie> and as mwhudson says stacking should fix this on lp soon
<arjenAU> poolie: I think the latter was the prob. and there's no indication for it so blocking it would be fine
<arjenAU> I mean the old format foo
<arjenAU> itt's doing better now on the progress bar. sanity is prevaling
<poolie> yay
<poolie> little things like a warning would make a big difference
<poolie> i'll try to add one soon
<arjenAU> yep. tnx.
<arjenAU> poolie: I'd say just block old stuff. say to upgrade.
<poolie> jml, i think i'm on the home stretch now
<poolie> or at least another stretch :)
<mwhudson> poolie: yay
<jml> poolie: yay
<poolie> i have an change i should separate out that puts you into the debugger when a test fails
<poolie> it's super useful
<poolie> can't believe i haven't done it before
<Peng> Wait, yay what?
<poolie> yay stacking is nearly landed
<Peng> Oh, yay. :)
<stewart> i have a suggestion, it'd be cool to have "bzr conflicts" print out a list of files directly, so you could: emacs `bzr conflicts`
<stewart> oh... --text does that
<arjenAU> poolie: mysql-server 50 minutes. all done
<poolie> stewart: yes, but it kind of annoys me it's not the default
<poolie> also it would be nice if we could run the editor for you
<Peng> How exactly does stacking work? Does it cache X revisions locally? Does it cache all revisions starting at X?
<poolie> though emacs users might not prefer it
<poolie> Peng: basically the second
<poolie> it's not really a cache though
<Peng> Yeah, I know.
<Peng> Can you (automatically) remove older revisions from the local repo?
<Peng> Should we always use stacked branches, or only when it's necessary?
<mwhudson> stewart: $ grep -c 'vim $(bzr conflicts --text)' /home/mwh/.bash_long_history
<mwhudson> 23
<mwhudson> :)
<poolie> peng, if you're familiar with a union filesystem mount it's kinda like that
<poolie> jml, mwhudson, i have only 3 more failures, all repetitions of the same test and i think i know why
<jml> \o/
<mwhudson> \o/
<mwhudson> poolie: what exactly is in this branch btw?
<poolie> integration of stacking into trunk
<mwhudson> poolie: branch7 etc but not the stacking policy?
<poolie> not the policy patch but that's pretyt small
<poolie> i know it does need to be merged too
<mwhudson> cool
<mwhudson> if it lands, i'll run a launchpad make check tonight against bzr.dev
<chandlerc> jelmer: known issue about apr-config and rst2html binaries being arbitrarily used by "make" in bzr-svn? (i have apr-1-config and rst2html.py here...)
<poolie> chandlerc: what do you mean by 'arbitrarily'?
<chandlerc> it doesn't seem to do any detection of the path, or variable substitution
<chandlerc> but i haven't looked directly at the makefile -- could be dead wrong
<chandlerc> poolie: ahh, it seems RST2HTML is a variable, apr-config comes out of setup.py, but it actually keeps testing till it finds (correctly) apr-1-config, so the "error message" is just not swallowed
<chandlerc> poolie: setting RST2HTML=rst2html.py fixed it right up, although it didn't fail fatally before, just didn't bulid the HTML docs, which is fine
<Peng> Random: bzrlib/tests/ is 106k lines of code, including whitespace and everything.
<Peng> All of bzrlib is 211k.
<Odd_Bloke> Moin.
<Peng> Hmm, I have an appointment in 6.5 hours. I should sleep or something.
<lifeless> Jc2k: pong
<lifeless> poolie: hi, can't skype from here, can use phone
<poolie> hi lifeless
<poolie> that could be good
<poolie> i can call you if you want
<lifeless> just starting a talk now, is 55 minutes ok for you? I'll ring - cheaper
<poolie> ok
<Odd_Bloke> Do we have any test coverage figures for bzr?
<poolie> no
<poolie> there may be some support for making it, i'm not sure
<vila> poolie, Odd_Bloke: I'm not aware of any figures, spiv may (he implemented the --coverage global option and used it at least for parts of bzr). I'm interested in such figures too.
<vila> and hi all :)
<poolie> hello vila
<poolie> i should mail you
<markh> is there a particular reason the gtk plugin doesn't offer a 'glog' command?  Is it considered that gannotate is all you really need?
<markh> (I'm hoping to directly reuse almost all of the 'g' commands for tbzr)
<fullermd> I think 'viz' usually fills that role in -gtk...
<AfC> markh: `bzr viz` fills that role
<markh> ahh, thanks.  I missed that as it doesn't start with 'g' :)
<Peng> Maybe someone should add an alias?
<AfC> Peng: if you do `bzr help commands` everything says where it comes from. You can always just ` | grep gtk`
<AfC> Peng: but perhaps an alias would be good - unless someone is planning on writing a glog that does something else.
<markh> but you do get "tricked" into thinking that gtk adds a new version of most common commands, but with a 'g' prefix
<fullermd> Which unfortunately fails when descriptions go to more than one line   :|
 * fullermd wishes for "bzr plugin-commands $FOO"
<markh> but I admit it was there for me to find :)
<AfC> fullermd: aren't the descriptions single lines? If not, "oh"
<fullermd> Not all.
<Peng> fullermd: Maybe "bzr help plugins/foo" should list them.
<fullermd> cvsps-upgrade-conversion Convert the old layout of branches to the new one.
<fullermd>                          [cvsps]
<fullermd> fetch-ghosts             Attempt to retrieve ghosts from another branch.
<fullermd>                          [bzrtools]
<fullermd> [etc]
<AfC> You'd think a project which refuses to feed its output to $PAGER would refuse to wrap its lines.
<fullermd> I guess the gtk ones are all shor...   no, there's test-gtk, running onto a second line for the [gtk]
<AfC> But as to markh's query, all that we are discussing only applies if you've conceived of the problem as "there GUI commands I am looking for are in a plugin called '[bzr-]gtk' and so I should search down from that"
<Peng> bug 220331 (in reference to a mailing list post, not what's going on here)
<ubottu> Launchpad bug 220331 in bzr "editor paths containing spaces are not parsed correctly" [Medium,In progress] https://launchpad.net/bugs/220331
<Peng> Thank you, ubottu.
<Peng> bug 109115 (same)
<ubottu> Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115
<lifeless> poolie: is your phone on ?
<poolie> lifeless: yes, i was on teh phone to amanda
<poolie> lifeless: try again?
<lifeless> Jc2k: http://bzr-playground.gnome.org/gnome/.mirror-log/changes <- the log
<Kinnison> lifeless: how goes guadec?
<markh> it seems 'bzr viz' always shows a visualization of the entire branch - which is different than 'log'
<fullermd> Well, I didn't say it was the same   :)
 * Odd_Bloke --> breakfast
<steltho>  With bzr, is there any way I can pull a specific commit from another branch, kind of like git cherry-pick?
<gour> git has cherry picking?
<lifeless> gour: it records a single revid
<lifeless> steltho: yes you can, bzr merge -r x..y BRANCH
<gour> lifeless: but that's still not like darcs' ?
<lifeless> gour: not at all
<gour> (due to different design)
<markh> fullermd: you think there is scope to add a 'glog' command which is just a graphical version of 'log'?  Or maybe it is considered unnecessary?
<markh> (I'm not asking anyone to do it - just if it makes sense!)
<lifeless> markh: I think it does
<lifeless> markh: though for full log it should look like viz :)
<markh> lifeless: by "full log", you mean "log of entire branch"?
<markh> I'm not sure what a log of multiple files should do.  Maybe it makes more sense for 'vis' to accept a filename?
<markh> s/a filename/list of filenames/
<lifeless> markh: sure; st
<poolie> hello markh
<poolie> jml, stacking passes all tests
<jml> poolie: rock the cazbah
<poolie> and patch is sent
<lifeless> poolie: woo!
<poolie> lifeless: if you could read it that would be great
<poolie> there is some more that can be done but at least it passes
<poolie> it's in the 'stacking status update' thread
<poolie> have a good weekend
<poolie> now i should really log off
<poolie> night
<a_c_m> anyone know of any good introduction videos for bzr, im trying to sell the development team/management on the idea, videos seems to get watched from start to finish, were as text gets skimmed or not read at all :)
<AfC> If there isn't, perhaps we should get a good one produced. That would be fun to be a part of, actually.
<markh> poolie: hi.  I'm at the bzr sprint at europython, which is quite cool!
<markh> I wish I could work out how to get a group of talented people to work like dogs for free for a few days ;)
<steltho> \leave
<james_w> a_c_m: would you be after screencasts, or more presentational videos?
<Odd_Bloke> neobug: Hey, just replied to your email.
<neobug> ok, thanks
<Odd_Bloke> neobug: How did you send your changes to the mailing list previously?
<neobug> Odd_Bloke: LarstiQ helped me
<neobug> I just sent a mail with Mutt
<neobug> and attached a bundle
<Odd_Bloke> neobug: OK, you should be able to do exactly the same again, having committed your changes to the same branch.
<lifeless> markh: hey there
<lifeless> markh: who is sprinting?
<markh> Wouter was here yesterday, but there are a few new people who have never used or seen bzr too - which is quite amazing really
<markh> A couple of [RFC] mails to the list are from such people
<lifeless> most excellent
<gour> markh: save'em all ;)
<a_c_m> james_w: dont mind... just something text light, ideally with moving bits and sound ;)
<a_c_m> james_w: i just sent out one of the pdf presentations as a stop gap... but i doubt they would make it past all 50 odd pages
<Odd_Bloke> markh: On a side note, if you could encourage them to use '[MERGE/RFC]' rather than just '[RFC]', that makes not losing them much easier.
<james_w> a_c_m: I've been working on some instructional screencasts. We haven't set up hosting for them yet, and there are only a few, but once I've got my current deadline out the way I hope to make some more.
<a_c_m> james_w: sounds good to me, ones on the different workflow situations and how to set them up / use them would be what my guys would be most interested in
<james_w> a_c_m: I hadn't got that far yet, but that's the sort of thing that I would like to do. Unfortunately they are not quick to produce.
<markh> Odd_Bloke: that is a convention that is news to me.  Wouter was actually mentoring those guys yesterday, but I'll try and make that happen for today.
<markh> I think that none of the patches was really considered ready for merging though (IIRC, one of the new error messages suggested buying more RAM ;)
<uws> markh: which Wouter?
<markh> I suggested adding "you idiot" to the end of the message ;)
<uws> V?
<uws> vH
<markh> umm - not sure :)  The dutch one
<uws> you're highlighting me :)
<uws> markh: i'm "the other dutch wouter"
<markh> oh :)
<uws> but I'm at guadec, so it's not me ;)
<markh> um - the one with the Q at the end of his IRC nick
<uws> thogh we do have a bunch of bzr people around here as well
<uws> larstiq that is
<a_c_m> james_w: cool, are you on identi.ca ?
<markh> yeah!
<james_w> a_c_m: nope
<a_c_m> james_w: shame
<james_w> heh :-)
<lifeless> uws: larstiq
<lifeless> beuno:
<lifeless> Traceback (most recent call last):
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/controllers/changelog_ui.py", line 45, in get_values
<lifeless>     revid, start_revid, filter_file_id, query)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
<lifeless>     return unbound(self, *args, **kw)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 458, in get_view
<lifeless>     revid_list = self.get_file_view(start_revid, file_id)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
<lifeless>     return unbound(self, *args, **kw)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 423, in get_file_view
<lifeless>     revlist = list(self.get_short_revision_history_by_fileid(file_id))
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/util.py", line 407, in locked
<lifeless>     return unbound(self, *args, **kw)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 330, in get_short_revision_history_by_fileid
<lifeless>     w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
<lifeless> breaks http://bzr-playground.gnome.org/robsta/gtk-css-engine/changes?start_revid=20&filter_file_id=gtk2.0-20080708104047-cvt44z7pck8smu4n-3
<beuno> ew
<beuno> hm
<beuno> lifeless, that's using the latest lh-search?
<lifeless> beuno: I hope so :) - but its in history.py in loggerhead :)
<lifeless> beuno: its using the latest loggerhead-gnome-theme
<lifeless> beuno: http://bazaar.launchpad.net/%7Ebeuno/loggerhead/gnome_theme/
<beuno> that file is empty
<beuno> I wonder if that's what triggers the traceback
<lifeless> beuno: using weave_store triggers it
<lifeless> beuno: its running 1.6b3 bzr
<beuno> lifeless, where can I get a branch for that repo?
<lifeless> http://bzr-playground.gnome.org/robsta/gtk-css-engine
<lifeless> bbs
<beuno> lifeless, it doesn't blow up in trunk
<beuno> looking at what may have caused it
<beuno> lifeless, pushed a revision that fixes it
<lifeless> beuno:
<lifeless> Traceback (most recent call last):
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/controllers/changelog_ui.py", line 45, in get_values
<lifeless>     revid, start_revid, filter_file_id, query)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 376, in get_view
<lifeless>     revid_list = self.get_file_view(start_revid, file_id)
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 342, in get_file_view
<lifeless>     revlist = list(self.get_short_revision_history_by_fileid(file_id))
<lifeless>   File "/srv/gnome-loggerhead/loggerhead/history.py", line 252, in get_short_revision_history_by_fileid
<lifeless>     w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
<lifeless> AttributeError: 'KnitPackRepository' object has no attribute 'weave_store'
<beuno> that's odd, I don't get that traceback locally
<beuno> running bzr.dev
<lifeless> beuno: you're probably not actually using bzr.dev :)
<lifeless> beuno: check your python path
<beuno> mn
<beuno> damn
<beuno> how can I force bzr.dev in my python path?
<lifeless> PYTHONPATH=path_to_bzr.dev ./serve-branches.py
<beuno> and on a more permanent basis?
<lifeless> install bzr.dev ? :)
<beuno> you and your complicated ways...
<beuno> hm, I still don
<beuno> 't get the traceback
 * beuno installs bzr.dev
<lifeless> beuno: its simple really - weave_store does not exist anyomore
<beuno> yeah, I'll have to update that
<beuno> I'd just like to reproduce it
<beuno> there
<beuno> ok
<beuno> I'll file a bug
<beuno> thanks lifeless
<lifeless> beuno: so, can I suggest:
<lifeless> put a import pdb;pdb.set_trace() statement at that line
<lifeless> run serve-branches, hit the page
<lifeless> if the line triggers you'll be in pdb
<lifeless> beuno: then, import bzrlib; print bzrlib.__file__
<lifeless> that will tel you what bzrlib its finding
<beuno> oh, that's interesting
<beuno> lifeless, I'll try and get that fixed this evening
<lifeless> beuno: I'll fix it now I think then
<lifeless> beuno: users :)
<beuno> lifeless, argh, sorry. It's my last day here, and, again, tight schedule  :/
<awilkins> Hi there, I think I may have found a bug in the HTTP response handling ; anyone know about that bit and want to talk about it?
<lifeless> awilkins: vila is good to talk to
<awilkins> vila: Ping?
<awilkins> I'm going to put a bug up for this, I think, anyway.
<vila> awilkins: not interruptible right now, file the bug, I'll comment, associated tests are in test_http_response.py, if you encounter it in RL, please add relevant .bzr.log while -Dhttp is active
<awilkins> Righto
<lifeless> beuno: fixed, branch coming up
<lifeless> ok, fixed - http://bzr-playground.gnome.org/robsta/gtk-css-engine/changes?start_revid=20&filter_file_id=gtk2.0-20080708104047-cvt44z7pck8smu4n-3
<markh> so, any other competing GUI toolkits apart from gtk and qt? ;)
<markh> hrmph - maybe I misunderstood - is there a QT UI toolkit for bzr at the moment?
<markh> ah - just needed the correct google-foo - QBzr
<lifeless> beuno: http://bazaar.launchpad.net/~lifeless/loggerhead/gnome
<beuno> lifeless, very cool, thanks. I'll merge that into trunk in a while
<lifeless> beuno: also, .keys()/.versions() are bad apis, don't use them :)
<beuno> lifeless, noted. There are still large parts of the code which are, well, inherited  :)
<Odd_Bloke> I'm going to be away over the weekend, probably without Internet and certainly without time to spend on PQM/bzr stuff.
<Odd_Bloke> So if anyone wants anything, you have about 10 minutes. :p
<james_w> anyone know an easy way in python to grab a file from http only if not modified compared to the local one
<james_w> i.e. to set If-Modified-Since or similar?
<james_w> bonus points if I can do it with the bzrlib transport.
<Odd_Bloke> Right, I'm off.
<Odd_Bloke> See you all Sunday/Monday. :)
<james_w> see you
<markh> james_w: um - set the if-modified-since header? ;)
<markh> Or If-None-Match is you have remembered the etag
<james_w> markh: yeah, I'm looking in to it. I firstly need to translate from the modified time of the local file to the correct format
<markh> (actually, you will have had to remember the date too)
<markh> Actually, that might not be good enough
<markh> a cached response will have a date in the past, for example, and the RFC says you should just treat the date header as a string, not as a date for this purpose
<markh> so you probably need to remember a couple of headers at least
<markh> (your requirements may be a little simpler, but in the general case, the above is true)
<james_w> ok, thanks, I'll look to see if these servers provide etags
<markh> well - etgas and date are the same problem for you
<markh> you need to remember *either* (or both, but either will do)
<markh> so etags really isn't simpler than date, nor vice-versa
<markh> I guess if you were suport luck, the etag may be in the HTML as a "http-equiv" tag (or however that is spelt)
<markh> s/suport/super/
<james_w> this 'aint html, so that won't help unfortunately.
<markh> but I doubt it
<markh> right
<james_w> so you would recommend just saving the date and repeating it back.
<markh> in an if-modified-since header, yeah.  Then you expect either a 304 or 200
<markh> 304 means not changed and no body will come, 200 means it has changed and the new version will come
<james_w> thanks. Now I see why there isn't a simple bit of code I can steal.
<markh> :)
<markh> james_w: ack - its not the "date" header you remember, its the "last-modified"
<markh> but the rest remains the same
<james_w> thanks, I'm stubbornly not opening the RFC, so I'm sure to get some things response
<lifeless> james_w: you want to read the rfc
<lifeless> james_w: otherwise I will laugh at you :)
<james_w> heh :-)
<markh> yeah, sadly the RFC can't be avoided ;)
<markh> its pretty approachable though
<lifeless> james_w: its a complex bitch to deal with, but doing it wrong will just fail
<lifeless> abentley: http://advogato.org/person/robertc/diary/92.html
 * awilkins is also in _persnickity-RFC-implementation-land_
<awilkins> vila: Ping?
<vila> awilkins: pong
 * vila is interrupted but not available for too long :)
<awilkins> vila: Hi there ; just where this bug is is a matter of opinion ... but I think I've fixed it
<vila> bug number ?
<awilkins> https://bugs.launchpad.net/bzr/+bug/247585
<ubottu> Launchpad bug 247585 in bzr "Angle bracketed boundary lines from IIS cause failure" [Undecided,New]
<awilkins> Angle brackets are not permissible under RFC 2046, but Python also behaves badly by considering angle brackets to be quotes for the purposes of RFC 822 quoting (as far as I can tell)
<awilkins> So I've resorted to passing all the boundary lines in reponse.py through rfc822.unquote() before they are checked
<awilkins> Which fixes it
<awilkins> I think that's fair given the parameters (including boundary) all get the same treatment when the headers are parsed
<vila> awilkins: hmm, sounds reasonable, could you add tests to reproduce it (make it fail before your patch, succeed after) and send that to the list ?
<awilkins> vila: I knew that bit would be the most work :-P
<vila> since this will be very localized (with a comment explaining it :-) I think there is no point in refusing to work for IIS
<vila> awilkins: I think it's a matter of subclassing TestRangeFileMultipleRanges and redefining _boundary_line :-)
<awilkins> vila: Ah, well at least that'll be nice and quick
<awilkins> TestRangeFileMultipleRangesLikeIIS here we come
<awilkins> It seems to use the same boundary string (qhich is someone hopscotching on their keyboard) all the time
<awilkins> q1w2e3r4t5 etc
<vila> who ? IIS ?
<awilkins> Yes
<vila> pfff, no further comment
<awilkins> I have half a mind to try some content with it's boundary string inside it and see if it copes
<vila> well, it shouldn't, we don't scan each part searching for the boundary line, we *know* where they should occur
<awilkins> Yeah, but the RFC says it shouldn't happen - boundary strings should not occur in content
<vila> the boundary line mechanism is more a robustness encoding
<awilkins> BUt I have a feeling that this may be a kludge everyone uses
<awilkins> Can you imagine guaranteeing the non-occurence of a given string in a 4GB file on a busy webserver?
<vila> The best would be if you can find another implementation known to work with apache2 and IIS needing multi-part and check how they did it
<vila> awilkins: You don't have to guarantee that, we *don't* search inside the part itself since we know its size
<awilkins> vila: True, it's just the RFC-driven pedant inside me :-)
<vila> Content-Range is *required*
<vila> ok :)
<awilkins> quoth "The boundary delimiter MUST NOT appear inside any of the encapsulated parts
<awilkins> ANyhow, thanks for the pointer on the test, that would have taken me a qhile to figure out
<vila> awilkins: argh, then IIS is utterly broken of they always use the same one :-/
<vila> s/of/if/
<vila> np, helping people provides tests helps bzr having more tests :-D
<awilkins> vila: It may use a different one if it detects it in the content, but since testing that isn't going to change IIS... I'm rather inclined not to bother
<vila> I'll check that when I'll review your patch (if I can find the time) but I'm pretty sure *we* dont't search for the boundary inside the part, so whether or not the multipart is RFC-compliant (for that particular point) should not be a problem
<awilkins> I don't see that anywhere either
<vila> on the other hand unquote may not be the best solution since after all, you *guessed* their RFC interpretation, may be they always put <> and in that case deleting only that may avoid false positives
<vila> awilkins: I suppose you can't check the sources for all available versions of IIS ? No ? Too bad :D
<cyberix> is get_transport supposed to work when base isn't a directory?
<awilkins> vila: Only verified it on 6.0 and .70
<vila> awilkins: in the sources ??? :D
<vila> cyberix: It' not supposed to be used with anything but directories...
<vila> what is your use case ?
<awilkins> vila: Nope, but it doesn't vary on different content and it's always the same plinky-plonked string that some bored developer thought was an unlikely char stream....
<vila> awilkins: you can verify that by creating a file with many occurrences of it and querying multiple ranges of it
<cyberix> vila: I'm tracking back a problem with someone trying to do a push on a bundle
<cyberix> vila: That is not (yet) supported
<cyberix> so I'd like to add an exception when someone tries to do get_transport on a file
<vila> You can't
<cyberix> oh bugger
<vila> get_transport do not even connect
<cyberix> ?
<vila> the first operation on the transport that requires access will automatically connect
<cyberix> oh
<cyberix> Where can I find the code that connects?
<vila> you may want to have a look at bzrlib.bundle.read_bundle_from_url and below to see how to deal with such cases
<vila> cyberix: gee, in all transport implementations under bzrlib/transport/
<cyberix> ofcourse
<cyberix> sorry I'm a newbie and a bit slow because I'm tired
<vila> but look at bzrlib.bundle.read_bundle_from_url first
<cyberix> But currently I'm not even detecting whether or not the file is a bundle
<cyberix> You try to push on a file -> I warn you and exit
<cyberix> The problem is detecting whether or not the target is a file
<vila> try pushing, trap exceptions
<vila> put pushing to a bundle sounds really like a strange idea
<vila> bundles are not supposed to be updated
<cyberix> I can see that
<vila> replaced, yes, updated, I fail to see how
<cyberix> The next step would be to tell the user he should do merge and send -o instead
<awilkins> vila: Confirmed, it does it even when serving a file packed with "--<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>\r\n" and "<q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl>\r\n" .. (but I bet apache makes a similar compromise)
<cyberix> But I want to get the checking to work first
<vila> awilkins: ok
<cyberix> vila
<cyberix> : does that sound more correct to you
<vila> cyberix: That's called 'Look Before You Leap) and we try hard to avoid that
<cyberix> The problem is that some users might take the advice and go for it without thinking what it actually does?
<vila> :-) It applies to code, not to humans
<vila> What is your idea big picture ?
<cyberix> I don't think it is a lot bigger than what I already told you
<cyberix> 1) tried pushing to a bundle
<cyberix> 2) bzr complained about directories
<cyberix> There are no directories involved, so it is a bug
<cyberix> Then I was told that instead of pushing to a bundle you are supposed to do pull/merge and send -o
<cyberix> So might as well tell that to the user who is trying to push into a bundle
<cyberix> It does not necessarily make sense to do that for him, because he might not expect the bundle getting mered into his tree when does push
<cyberix> telling him about the possibility might still help him
<markh> cyberix is also at the europython sprint.  For background, we have been telling people that a bundle is basically a self-contained branch - so an enquiring person then tried to *push* to a bundle (its a branch, right? ;)
<markh> so we understand and agree that's not supported - but we want to fix the error message in that case
<vila> hmmm
<vila> it's a self contained *read-only* branch
<vila> does that fix it ? :-D
<vila> but... bzr should already says 'not a branch' no ?
<vila> I don't think you need to go deep to the transport level to trap that
<cyberix> I'm currently planning to go for something like...
<cyberix> 'Pushing to a file is not supported at the time.'
<vila> But I don't think it will ever be supported since you will need to re-recreate the bundle anyway
<cyberix> Yep, might take out 'at the time'
<cyberix> Then, if I managed to detect that the file is a bundle I might go with something like...
<cyberix> 'Bzr doesn't support direct push into a branch contained within a single file. Use merge to import the changes into your local branch, then use send with switch -o to publish a new single file branch.'
<vila> haaaa
<vila> hmm
<vila> then you should do that in push itself and stay far above the transport level
<LarstiQ> vila: the current code tries to mkdir('.') on to_transport, which raises a FileExists, and then it assumes it was a directory
<LarstiQ> vila: the error message is rather confusing in that case.
<markh> LarstiQ: aren't you supposed to be sleeping to prepare for your music festival? ;)
<LarstiQ> markh: I've caught up on sleep, showered and am waiting to be picked up :)
<vila> LarstiQ: hi :D
<vila> are you referring to ensure_base implementation ?
<LarstiQ> vila: cmd_push code
<LarstiQ> vila: lines 796
<vila> wow line 787 here, I lag :-/
<vila> Anyway, 1) You're in the right spot, 2) You just found an old XXX => You won !
<LarstiQ> :)
<LarstiQ> heya emilis_info
<emilis_info> heya LarstiQ, how was your flight?
<emilis_info> :)
<LarstiQ> vila: when I looked at transport, I didn't see a way to distinguish wether we're dealing with a file or a directory, so choosing which message to return is slightly tricky
<LarstiQ> but maybe the error carries some information
<LarstiQ> emilis_info: scary :)
<emilis_info> LarstiQ, airline madness? :)
<LarstiQ> emilis_info: that is, the airport had a general (checkin) system failure, so nothing happened for half an hour
<LarstiQ> we managed to leave on time, but the Moscow flight in front of me had people get checked in 5 minutes prior to scheduled takeoff
<emilis_info> hmmm...
<emilis_info> maybe they were upgradins stuff
<emilis_info> :)
<vila> LarstiQ: This will be inherently tricky, the best I can think of, once the FileExists has been raised, is to issue a stat() call (incurring roundtrip, but since it's error handling it could be acceptable)
<vila> then you can use st.st_mode to check if it's file or directory
<LarstiQ> emilis_info: seeing how stressed out the staff was, I don't think so ;)
<LarstiQ> vila: can we stat?
<vila> *but* stat() is implemented on writable transports only
<LarstiQ> right
 * vila loves when answer cross question on the wire :)
<vila> but in your case, push requires a writable transport
<LarstiQ> vila: are we guaranteed to have a writable transport at that point?
 * LarstiQ hates dying phones 
<vila> LarstiQ: no, but a different exception will be thrown in that case when you try to nkdir()
<cyberix> LarstiQ: So don't dye them.
<vila> And you get the get famous "http doesn't implement mkdir" error which confuse so many people :)
 * vila goes back to gdb for good...
<LarstiQ> cyberix: correct, good sir :P
<LarstiQ> vila: have fun
<cyberix> LarstiQ: You too. I'm soon going to call it a day.
<cyberix> But I'm not planning to give up the holy task.
 * ToyKeeper finally figures out what's making the labels in bzr vis overflow their parent widgets
<awilkins> CAn anyone tell me a smart bzr+http:// I can point a session at so I can see what it's supposed to look like in a debug proxy?
<Foskasse> sup
<awilkins> I'm about halfway to getting IIS to serve bzr over ISAPI
<james_w> awilkins: I don't actually know anywhere that serves over bzr+http://, maybe someone has something set up.
<ricardokirkner> hi. I have been struggling with that setup.. what is the problem?
<awilkins> ricardokirkner: I have it returning "bzr message 3", and then the client just queries the parent folder ; repeat until 404
<awilkins> I think something is missing from my query
<awilkins> It might be my WSGI shim though
<ricardokirkner> mhh.. sorry, that doesn't ring a bell...
<ricardokirkner> my problems where related to not finding the repository, and to authentication
<awilkins> ricardokirkner: I can tell bzr is running from the response ; I don't think it's finding the repository either
<awilkins> But I think it's my WSGI calling script
<ricardokirkner> I had it running with wsgi, and the script is extremely simple (it just bypasses everything on an url to bzr)
<awilkins> I;m not sure it's passing the RIGHT stuff
<ricardokirkner> here you can see my script: http://pastebin.com/d1d612421
<ricardokirkner> that, plus a few lines in http.conf, which I will shortly paste
<ricardokirkner> http://pastebin.com/m7ec0f366
<ricardokirkner> I am using mod_wsgi
<awilkins> I'm using IIS 7 and PyISAPIe
<awilkins> Not through choice, I hasten to add :-)
<ricardokirkner> ok.. then I dont think that will help you out... maybe it's a windows issue... I am sorry, I cant help you out there
<awilkins> I think I'm getting closer, it's accessing a bunch of files in the repo folder now
<chandlerc[g]> hrm, I'm getting an odd error on "make" in bzr-svn
<chandlerc[g]>   File "./setup.py", line 13, in __init__
<chandlerc[g]>     super(CommandException, self).__init__(self.message)
<chandlerc[g]> TypeError: super() argument 1 must be type, not classobj
<chandlerc[g]> is my Python version too old?
<awilkins> What is your Python version?
<chandlerc[g]> 2.4.3
<awilkins> I saw a comment in the commit log about remving a Python 2.5 -ism recently, could be
<chandlerc[g]> hmm i'm working off of 0.4, so i would think i would have anything...
<chandlerc[g]> and its in setup.py, which seems especially odd
<awilkins> jelmer: ^^
 * awilkins is successfully serving his repo from IIS using WGSI
<chandlerc[g]> wow
<schoni> http://www.pennergame.de/change_please/3238442/
<awilkins> vila: On top of fixing that response bug, for good measure I got IIS running as an HPSS
<james_w> nice work
<awilkins> james_w: Well, I have a "poke hole in firewall" request for SSH going with my IT services crew.... I have this onimous feeling they are going to deny it, so this is insurance.
<awilkins> This way I can just exploit a port that's already open to run an interactive application :-)
<chandlerc[g]> Any idea why a KnitPackRepository would not be compatible with a KnitPackRepository??
<awilkins> chandlerc[g]: Are you pushing over http:// ?
<chandlerc[g]> branch over sftp://
<awilkins> chandlerc[g]: Is one rich-root-pack and the other not?
<chandlerc[g]> maybe?
<chandlerc[g]> one is bzr-svn created, the other is a fresh "init-repo"
<awilkins> bzr-svn is by necessity rich-root-pack
<chandlerc[g]> yea, rich-root-pack
<awilkins> pass --rich-root-pack to your init-repo command
<chandlerc[g]> just got shelled into tho remote machine
<chandlerc[g]> ahhh
<chandlerc[g]> thx
<awilkins> You're welcome
<awilkins> I jsut got the exact same error for a totally different reason :-)
<chandlerc[g]> hehehe
<chandlerc[g]> its a bit... confusing. ;]
<awilkins> Rich roots are set to become the default somewhen
<awilkins> But I agree that the error is confusing
<vila> awilkins: Great !
<Mecha25> hey, anybody know what bzr: ERROR: Transport operation not possible: http does not support mkdir() means?
<mtaylor> Mecha25: it means that http does not support mkdir()
 * mtaylor ducks
<jam> Mecha25: it is usually a sign that you tried to either 'bzr commit' or 'bzr push' to an HTTP url
<jam> Generally caused by something like "bzr co lp:project" without doing 'bzr launchpad-login' first. So it checks out the files from the anonymous read-only side.
<jam> Alternatively, by doing "bzr push http://URL"
<Mecha25> sorry, just got it working, I did need to add my login
<jam> which is easier to fix, since you can just do "bzr push sftp/bzr+ssh/etc"
<Mecha25> however, now I've pushed it, it has a branch format, but the code isn't there
<Mecha25> what happened to the codE?
<libwilliam> maybe bzr update?
<Mecha25> I'll try that
<Mecha25> says No Working Tree exists
<libwilliam> or if you are pushing to launchpad wait about 5 minutes
<Mecha25> oh
<Mecha25> ok, it takes a while for it to get the code?
<libwilliam> it always takes a while before the results show up
<Mecha25> I just did it 3 seconds ago
<Mecha25> cool then, I'll wait
<mmmultiworks> does bzr have an external api or swg bindings at all?  I have a need for ruby integration
<mmmultiworks> swig bindings, sorry
<libwilliam> http://bazaar-vcs.org/Integrating_with_Bazaar
<james_w> mmmultiworks: no, sorry, though I think there is a ruby version control API that supports bzr somewhere
<mmmultiworks> thanks, I'll keep digging some more
<mmmultiworks> james_w: there is this one which I can use as a base probably
<mmmultiworks> http://www.redmine.org/repositories/entry/redmine/trunk/lib/redmine/scm/adapters/bazaar_adapter.rb
<newz2000> hi, wondering if something like this is possible or even a good idea...
<james_w> mmmultiworks: http://rvcs.rubyforge.org/svn/trunk/README
<newz2000> I have a config file for project that has a path in it. when I create a branch, is it possible for variable substitution to occur and update the path in the config file?
<james_w> newz2000: short answer: no.
<james_w> newz2000: long answer: no, but...
<newz2000> ok. there's probably a better way then... if it were a good idea it would probably be easy and you all would be using it.
<james_w> you might be able to do that with Ian's tree filter stuff that will be in 1.6/1.7
<colbrac> hmm.. seems my tweaking of locations.conf yesterday worked. I now produce 2 BB responses on the bzr-gtk list with a patch
<gdoubleu> I just did a merge, but then backed out with bzr revert.  Is there a command or option to clean up the unversioned files that stuck around?
<Peng> bzrtools adds a clean-tree command that can do this (but read the help; by default it deletes a lot more).
<awilkins> bzr ignored | xargs rm   ?
<awilkins> Maybe not....
<awilkins> bzr ignored | grep -e ~\\d~ | xargs rm   ?
<awilkins> best stick with bzr clean-tree --detritus I think
<gdoubleu> thanks, I'll check that out
<[cliff]> hi all
<[cliff]> the guy I work with sent me a bundle via email, I'm trying to merge but I get this message: "bzr: ERROR: Not a branch:" followed by my branch path concatenated with the bundle's path.
<[cliff]> how can I merge the bundle?
<Peng> Oh, bug 247550 is why Loggerhead broke. Sorry for not getting around to reporting it..
<ubottu> Launchpad bug 247550 in loggerhead "Loggerhead uses deprecated weave_store in bzr 1.6" [Critical,Fix committed] https://launchpad.net/bugs/247550
<Peng> beuno: With the fix for bug 247550, is Loggerhead still compatible with older versions of bzr? Is it slower, or less memory-efficient or anything?
<beuno> Peng, all those are really good questions, for which I don't have a educated answer for right now  :)
<beuno> I need to get some sleep
<beuno> fly for 16 hours tomorrow
<Peng> beuno: Heh, okay. I might find out. Or not.
<beuno> and I'll probably be myself again next week
<Peng> beuno: Yikes. Moving to the Googlunaplex?
<beuno> Peng, let me know what your findings are  :)
<Peng> beuno: If you see lots of expletives and whining, you'll know. :)
<beuno> Peng, it's called "user feedback"  :p
<LaserJock> quick, semi-blasphemous question. Is it possible to *not* have "branches-as-directories"?
<Peng> LaserJock: Not at the moment.
<Peng> LaserJock: Well, you can use "bzr switch" a lot. And looms sort of do it.
<[cliff]> how can I trace bzr execution? is there a switch?
#bzr 2008-07-12
<Peng> beuno: bzr-search_integration + bzr.dev are working. :)
<beuno> Peng, yay!
<beuno> now, really off to bed
<beuno> g'night
<Peng> beuno: (Well, trunk + bzr-search_integration + my serve-branches.py changes.)
<Peng> beuno: G'night. :)
<james_w> [cliff]: you can merge it with "bzr merge /path/to/bundle", is that what you did?
<LaserJock> Peng: hmm, are there any suggestions for good ways to keep branches out of the way?
<[cliff]> james_w, not an absolute path, no. let me try that
<LaserJock> bzr tends to make me not want to branch much
<james_w> [cliff]: relative will work as well.
<[cliff]> james_w, right... same result
<Peng> LaserJock: No, I'm just crushed under a pile of separate branches. Sorry.
 * Peng wanders off.
<[cliff]> the NotBranchError doesn't appear to be used a lot. I was trying to figure out if there is a way of tracing it
<james_w> [cliff]: see "bzr help debug-flags" for one thing that can help. There's also plenty of information in ~/.bzr.log
<james_w> LaserJock: you can simulate it with one checkout and switch
<james_w> LaserJock: there is loom, which is like quilt
<[cliff]> james_w, says no help could be found for debug-flags... maybe I'm missing a package
<LaserJock> james_w: hmm, I'll have a look at those
<james_w> LaserJock: and it's possible that a plugin for multiple branches in a dir will turn up next week
<LaserJock> I just feel like I'm losing the power of a DVCS if I'm not doing any branching
<james_w> [cliff]: sounds like you have an old bzr, which would explain the error. What version are you using?
<[cliff]> but .bzr.log does the trick! nice one. checking it out
<[cliff]> james_w, 1.3.1, ubuntu's standard I think
<james_w> [cliff]: I'd check with --version
<[cliff]> james_w, right, 1.3.1
<james_w> [cliff]: ah, sorry, "bzr help global-options" has a debugging flags section.
<[cliff]> just out of curiosity, how do you manage to output those nice traces?
<james_w> the traceback module
<[cliff]> nice one, cheers
<[cliff]> it appears the error is raised on "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1426, in find_format
<james_w> traceback.format_exc() will print the last one, there are other functions for being more specific
<james_w> [cliff]: can you pastebin the relevant stanza from ~/.bzr.log please, I'll see if I can spot anything
<[cliff]> certainly
<[cliff]> james_w, http://pastebin.com/d65b306ce
<james_w> ah, I meant the whole section, but the traceback is a start, let me look
<james_w> hmm, it does know that it is a bundle apparently
<[cliff]> I've updated the pastebin
<james_w> [cliff]: ah, got it I think, can you read the top of the bundle and see what submit_branch is?
<[cliff]> none, I only have a target_branch
<james_w> is that a URL?
<[cliff]> nope, a relative path
<[cliff]> that doesn't exist on my filesystem
<james_w> ah yeah, target branch
<[cliff]> don't know if it's relevant but I managed to successfully merge another bundle on a different branch
<james_w> I was reading it wrong
<james_w> yeah, the bundle has been created wrong
<james_w> if you could ask the person that sent it to tell you how they created it it would be useful
<james_w> this should probably be caught
<[cliff]> how should we do it? I'm going to smack the other guy on the head hehe
<[cliff]> I can ask him, but not now, he's off for the weekend
<james_w> so, a merge directive has a submit branch, which is the branch that you intend it to be merged in to.
<[cliff]> I'll try to reach him still
<james_w> ah, I see something else as well
<james_w> you can specify this as the first argument to "bzr send"
<[cliff]> james_w, hmmmm although I understand (or at least I think so :-) ) how come the target_branch can't be ignored when merging the bundle to the current workbranch?
<james_w> if you don't then it uses the branch's parent
<[cliff]> so for example the submit branch should be .
<[cliff]> ?
<james_w> it stores the branch location in the merge directive as you saw, but if the target branch has a "public_url" set then that will stored instead.
<james_w> running "bzr send" creates a bundle (the base64 encoded bit at the bottom) that has all of the revisions that are in your current branch, and not in the submit branch.
<james_w> so "." is pretty much always wrong, as this will be the empty set, which isn't what you wnat
<james_w> he should have a mirror of your branch (or just use the location of it if it is public) and point to that
<james_w> now, I see this in the code:
<james_w>                 except errors.RevisionNotPresent:
<james_w>                     # At least one dependency isn't present.  Try installing
<james_w>                     # missing revisions from the submit branch
<james_w>                     submit_branch = _mod_branch.Branch.open(self.target_branch)
<james_w> which is where it fails
<[cliff]> I see. let me shed some light on this matter. the way we're working is like this: a master-branch is stored on a server and all devs have a local branch off it. when someone wants to work on something, they branch their copy of the master-branch into a new branch
<[cliff]> so the way the dev created the bundle was by bundling the differences between his work branch and his local copy of the master-branch
<[cliff]> so the target_branch reflects his own fs directory layout
<james_w> yep, that should work correctly.
<james_w> you should set "public_url" on the local copy to be the url of the master branch.
<james_w> is your copy of the branch out of date compared to master?
<[cliff]> hehe which one? :-) the local or the remote?
<[cliff]> yup
<james_w> ok, so what should happen here is that it would fetch these missing revisions from the master branch, but as the location of that was set to a local path in the merge directive it cant get to it
<[cliff]> hhhhmmmmmm
<james_w> I'm working up an example
<[cliff]> got the guy out of the bed :-) I've asked his revno of the master
<james_w> heh
<james_w> unfortunately I can't find documentation on public_url
<james_w> so, if you have http://server/master
<james_w> and a local ~/dev/master
<james_w> and your feature branch to submit ~/dev/feature
<[cliff]> james_w, that's it. my master is at a different revno of this master
<[cliff]> james_w, that's it. my master is at a different revno of his master
<james_w> and you set "public_url = http://server/master" in ~/.bazaar/locations.conf for ~/dev/master
<james_w> then "bzr send ~/dev/master" should do the right thing from ~/dev/feature
<james_w> and if the parent of the feature branch is master then "bzr send" should work
<james_w> [cliff]: does that match your set up?
<[cliff]> we don't set the public_url actually
<james_w> yeah, that's why I think this fell over.
<james_w> I'm going to see if I can write a test for this so that we can provide a better error
<[cliff]> hmmmm maybe insert a note in the documentation, that should be sufficient (and easier to do I think)
<[cliff]> I reckon the bundle parts of the documentation could use some love
<james_w> yeah, it does seem to confuse people sometimes.
<james_w> it works really well when it works
<james_w> We can spot this problem quite easily I think, so providing an informative error would be good, even with improved documentation
<[cliff]> true
<james_w> I think I see a similar problem just below as well, so we can catch that as well.
<[cliff]> he sent me a proper bundle now (branched off the same revno I have and created the bundle based on that). I'm checking out, it's close to 1am :-) thanks a lot for your help james_w
<chandlerc[g]> jelmer: you about? i'm hitting weird errors with bzr-svn
<chandlerc[g]> jelmer: http://pastebin.com/d1e4f1b42
<chandlerc[g]> happy to help any way I can w/ debugging.
<james_w> chandlerc[g]: https://bugs.edge.launchpad.net/bzr/+bug/246635
<ubottu> Launchpad bug 246635 in bzr "svn+ syntax may be deprecated but it is still essential" [Undecided,New]
<chandlerc[g]> james_w: yep, that explains the first one. thanks, i'll add myself to the CC of that one
<chandlerc[g]> still no clue about the second one...
<chandlerc[g]> its just a segfault, w/o any traceback or anything
<chandlerc[g]> maybe i'll try and to a gdb on it
<chandlerc[g]> jelmer: I did some gdb poking: http://pastebin.com/d6e9e66cf  I'll rebuild ra.so with debugging symbols tonight, and let you know what I find.
<lifeless> jelmer: Bug 247787
<ubottu> Launchpad bug 247787 in bzr-svn "assert len(tview) == tview_len" [Undecided,New] https://launchpad.net/bugs/247787
 * ToyKeeper hopes his vis changes get approved and merged
<beuno> ToyKeeper, approved  :)
<beuno> now you just need jelmer to pitch in
<ToyKeeper> I'm just sending a summary + merge directive, to make things clearer.
<ToyKeeper> I'm not too familiar with bundle buggy.  Does it take the first merge directive in a thread, or the last?
<beuno> ToyKeeper, always the latest one
<beuno> each time you send a new one, it overrides the previous one
<ToyKeeper> Okay, good.
<beuno> ToyKeeper, http://bundlebuggy.vernstok.nl/bzr-gtk/request/%3C20080712094212.GA15283@mutt.xyzz.org%3E
<ToyKeeper> I had the wrong public branch the first time too, thinking it was supposed to be my public branch, not trunk.
<ToyKeeper> Jasper's message in the olive bookmarks thread cleared that up for me.
<beuno> ToyKeeper, patch looks great, really, thanks for working on it
<beuno> ah, we have 2 bundlebuggys now
<beuno> jelmer, which are we using?
<ToyKeeper> I feel dirty about building labels in an unrolled loop, but didn't see an obviously better approach.
<ToyKeeper> Anyway, vis, gci, and mdiff (diff with meld) are the only GUI bits I really use.
<ToyKeeper> Hmm, maybe gblame, once in a while.
 * beuno is trying to pack before check-out time
<apol> where can I find the bzr python api?
<apol> i've been looking for it for a while and I can't find it
<beuno> apol, you mean, documentation for it?
<beuno> http://starship.python.net/crew/mwh/bzrlibapi/
<apol> beuno: yes, yesterday i found a page that showed how to add files, remove files and so using python
<beuno> apol, http://doc.bazaar-vcs.org/latest/developers/integration.html
<apol> (i'm a the kdev+bzr test thingie)
<apol> yes that's what I meant
<apol> thanks a lot
<beuno> apol, ah, Aleix, yes, hi!
<apol> ;)
<beuno> how's that going?
<apol> I should be able to have something working today
<beuno> oh, yay!
<beuno> please send to the list
<beuno> everybody loves screenshots
<apol> still working on the multilanguage plugin integration though
<apol> beuno: I'll consider that ;)
<beuno> apol, and, also, bzr-gtk may be a good place to find out how to get some things from bzr
<apol> beuno: nice, I'll get it then...
<beuno> alright, I'm off to a 16 hour flight
<beuno> apol, I look forward to your screenshots  ;)
<Stavros> hello
<Stavros> how can i have bzr run pylint on files and aborting the commit if the score is too low?
<awilkins> Pre-commit hook?
<Stavros> awilkins: this is interesting
<Stavros> is there anything ready-made?
<awilkins> I don't know. You know, the docs don't even make it clear if hooks can abort steps.
<awilkins> But you can probably get them to stop by throwing an error...
<james_w> yeah, pre-commit can abort the commit I believe
<Stavros> ah, good, thanks
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/247847
<ubottu> Launchpad bug 247847 in bzr "hooks documentation doesn't clearly state which hooks can modify or abort the operation" [Undecided,New]
<james_w> just filed that for you
<lifeless> james_w: read more closely please; you're describing bugs incorrectly
<james_w> sorry, which ones?
<lifeless> 244310 was wrong
<lifeless> I'm checking the other recent updates now
<lifeless> separately, I'm not sure the platform is relevant for many of the bugs
<james_w> oh yeah, I don't know why I put that
<lifeless> no prob
<james_w> I'm not sure it is for all of them either
<james_w> I just got fed up of hunting through each time to dupe them.
<james_w> I can pull it out of the ones that probably aren't if you like
<lifeless> well
<lifeless> not really worth the time I guess
<lifeless> just note it for future :)
<james_w> sure
<james_w> p.s. I have an archive import running at the moment, about 14 hours on main and it's up to kdebase
<james_w> debian+ubuntu
<lifeless> cool
<lifeless> we'll want that to play with Monday :)
<james_w> yep, Colin asked me to make sure we had some branches for others to play with next week. There's a bunch of failures, but I think two things account for 90% of them.
<james_w> are you still in Istanbul?
<lifeless> yup
<lifeless> till sunday 4pm
<lifeless> (as in 4pm I hit london)
<james_w> how was GUADEC?
<lifeless> pretty good
<lifeless> have you seen the playground?
<lifeless> bzr-playground.gnome.org
<james_w> no, I haven't looked yet
<lifeless> uhm battery; bbiab
<lifeless> back
<lifeless> hi markh, how went the sprint ?
<markh> lifeless: not too bad - I'm still here - but I'm all alone in the bzr world
<lifeless> :)
<lifeless> james_w: do look at the playground
<markh> a couple of people have promised to send a couple of patches - hopefully they will turn into contributors
<lifeless> awesome
<markh> how is the middle-east (whereever it is you are!)?
<markh> successful?
<lifeless> istanbul :)
<lifeless> pretty intense
<lifeless> lots of passionate users of both bzr and git
<markh> with the gnome guys, right?
<lifeless> yes
<james_w> lifeless: it doesn't seem to work too well for me. I just get the project lists, but they don't seem to go anywhere for the people ones, and the trunk ones give a proxy error
<markh> you winning their hearts and minds? ;)
<lifeless> james_w: the people ones have not created branches of their own yet
<lifeless> james_w: the proxy error - needs looking at; its LH again:(. but just refresh and it should come good
<mark1> stooopid wireless networks...
<lifeless> :)
<awilkins> Woo, lots of bzr-svn branches
<apol> why doesnt WorkingTree.has_filename() work? it is always returning True to me... :S
<lifeless> apol: really?
<apol> lifeless: yes, it is the first time i use it so maybe I'm doing something wrong... :S
<lifeless> apol: it only tells you if the _path is versioned_, not if its on disk
<lifeless> apol: er, hang on - was looking at wrong code
<lifeless> apol: it does a lexists
<apol> i just want to know if a path is on a working tree
<lifeless> apol: in what manner, do you mean 'is versioned', or 'is present on disk', or 'is versioned and present on disk'
<apol> lifeless: is versioned
<apol> lifeless: i'm working on the kdev4 support
<lifeless> apol: for that, use path2id
<apol> lifeless: i just want to know if the user still has to add it or he can work with it (eg check the log or commit)
<lifeless> apol: tree.path2id('README.txt') != None
<apol> cool
<apol> let me check
<apol> thanks a lot lifeless
<lifeless> no problem :)
<lovebug356> Is it possible to merge with another branch but only with one command? ( like git merge --squash)
<lovebug356> s/command/commit
<lifeless> lovebug356: yes
<lifeless> lovebug356: merge FOO && bzr revert --forget-merges && bzr commit -m 'squashed!'
<andrea-bs> how about a cherrypick?
<lovebug356> lifeless, thanks, will try that.
<lifeless> andrea-bs: bzr merge -r x..y FOO && bzr commit -m 'This is a cherrypick'
<andrea-bs> oh, thanks lifeless
<lifeless> np
<lovebug356> And does somebody know how to work with a git branch? tried bzr-git but that crashed
<lifeless> lovebug356: your best bet to day is git-fast-export ++ bzr fast-import
<lifeless> https://launchpad.net/bzr-fastimport
<lovebug356> lifeless, thanks, but can you give a real-life example of that? the recipe is not clear to me
<lifeless> lovebug356: I can't, but I am quite sure there are details on the list :).
<lifeless> http://bazaar-vcs.org/BzrFastImport
<lifeless> that wiki page has a howto
<lifeless> bzr init-repo .
<lifeless> front-end | bzr fast-import -
<lifeless> where front-end is the exporter from git
<lovebug356> lifeless, ok, thanks it works
<lifeless> lovebug356: cool
<lifeless> I'm going offline for a while; hope someone else can help on an further questions :)
<lovebug356> lifeless, ;-)
<antoranz> Hi guys! I had problem with 1.5 with filenames with non-ascii characters
<antoranz> A fix has been issued for this... but I found another kind of problem related to non-ascii characters in 1.6b2
<antoranz> I posted a report in the same bug in launchpad... should I file a new bug for it?
<antoranz> take a look: https://bugs.launchpad.net/bzr/+bug/135320/comments/27
<ubottu> Launchpad bug 135320 in bzr "dirstate updating fails if there are symlinks and non-ascii filenames" [Medium,Fix committed]
<antoranz> yes... that's it
<antoranz> so? File a new bug or leave it like that?
<james_w> antoranz: yeah, yours seems to be a different issue, so different bug report please.
<antoranz> k
<james_w> though is it https://bugs.edge.launchpad.net/bzr/+bug/244360 ?
<ubottu> Launchpad bug 244360 in bzr "UnicodeError running "bzr st"" [Undecided,New]
<james_w> it looks like it to me, so you could just subscribe to that one
<Necoro> hmm ... I need to run bzr under windows ... but using the cmdline seems not to work... or am I missing something?
<enobrev> Necoro, have to make sure bzr is in your path
<Necoro> how do I do this? have never really used windows
<enobrev> Necoro, on my system, I had to add "C:\Program Files\Python25\Scripts" to my system path
<enobrev> Right click on "My Computer", go to Properties, Advanced Tab, Environment Variables (button), Look on hte bottom where it says "System Variables", Click on "PATH", then "Edit", and add a semi-colon and the path to your Python Scripts folder to the end of that line.
<Necoro> ok - worked... thanks :)
<enobrev> sure :)
<apol> could somebody tell me why this doesn't work? http://rafb.net/p/bNXtm645.html
<apol> or how to add something to a workingtree... 8-)
<antoranz> I just added my stuff to that bug.
<foobydoo> What's the appropriate URL to file a bug-report for bzr-svn clobbering commits if multiple users are editing their commit messages simultaneously?
<luks> apol: smart_add takes a list of paths
<luks> what you did is basically wt.smart_add("/home/kde-devel/testbzr/aaa")
<luks> er
<luks> wt.smart_add(["/", "h", ...])
<apol> aaah
<apol> luks: thanks a lot
<matthewlmcclure> does bazaar have a "copy file" command?
 * Foskasse http://failblog.files.wordpress.com/2008/06/fail-duck-writing1.jpg LOL!
<apol_> how can I initialize a directory from python?
<james_w> matthewlmcclure: no, it doesn't
<james_w> apol_: checkout "bzrlib/builtins.py" for "class cmd_init"
<james_w> apol_: that handles a few cases, so you may be able to strip it down depending on what you need
<apol_> james_w: cool, thanks
<james_w> it's not a simple one-liner though, as you have to deal with formats
<apol_> really? :/
<apol_> well, I'll check it out
<apol_> thanks a lot
<james_w> it's not one line, but it is about three I think, if don't need to handle all cases of existing dir, no parent dirs, etc.
<matthewlmcclure> james_w: thanks
<libwilliam> I have a question... With bzr send... Is the --message option only used with the email option of send?
<libwilliam> Nevermind, I guess it works with the --output also... I thought it didn't but I wanted to ask first, but the test I did that made me think I didn't was wrong.
<libwilliam> So ignore these message :)
<libwilliam> messages*
#bzr 2008-07-13
<Peng> "Rendering RevisionUI: 51.553565979003906 secs, 35388458 bytes, 15192308 (42.9%) bytes saved" <-- Oops.
<Peng> I accidentally loaded it again, and this time it took 73 seconds. :)
<sstangl> Does bzr have a way to auto-generate a patch?
<sstangl> I want to generate a patch from local branch "development" against local branch "trunk" to be emailed.
<sstangl> ah, send.
<mib_zv5ff9> I use bazaar to track version changes with my python application...  you know that __version__ attribute seen in most python programs?  I was wondering if those are typically automatically given a value after doing a version commit (and how to do that), or if the developer puts in a number manually?
 * rockstar looks around for james_w
<lifeless> rockstar: james_w is on utc time
<rockstar> lifeless, yea, I knew that, but thought I'd try anyway.
<lifeless> 1am - hoopeful :)
<abentley> lifeless: morning.
<lifeless> hi abentley
<abentley> lifeless: When are you flying?
<lifeless> leaving hotel at 1100
<abentley> I was thinking 11:45
<lifeless> that would be too late for my flight, have to be at airport by 1200
<lifeless> so I'm catching a lift with davyd
<abentley> Okay.  I'm packing right now, but ping me if you want to pair on something, or just hang out.
<lifeless> k
<lifeless> I'm eating now
<lifeless> the 333MB index has under 1MB left to parse
<abentley> Teh Rock!
<LaserJock> jelmer: around?
<Peng> lifeless: With your mailing list message about adding bzr-svn to the PPA, do you mean 0.4.10? Because it's gotten significantly better since then..
<lifeless> Peng: 0.4.aything >> None
<Peng> 0.4.11exp0? :D
<lifeless> well
<LaserJock> I updated my bzr-svn branch (0.4) and now it fails to load
<lifeless> concretely I'd like something that matches the bzr in each ppa
<lifeless> LaserJock: run make
<Peng> lifeless: The 0.4 branch matches bzr.dev. :P
<lifeless> Peng: if you use the ppa today you end up not having bzr-svn
<lifeless> Peng: this is a bug
<LaserJock> hmmpf, it needs apr-config
<Peng> Are you implying that the PPA works?
<Peng> Wow, it's been almost 2 months since 1.5 was released.
<Peng> 1 month since 1.6b2.
<LaserJock> ok, phew, got it working again :-)
<lifeless> time to finish packing
<Peng> You people with your lives and traveling and contributions to society... Pssh.
<lifeless> :)
<LaserJock> oh darn, I'm in a bit of a pickle :/
<LaserJock> are there any bzr-tools packages compatible with the bzr 1.6 betas?
<lifeless> yes
<lifeless> 1.6 bzrtools should be in the beta ppa
<LaserJock> ... it's not
<lifeless> oh
<LaserJock> https://edge.launchpad.net/~bzr-beta-ppa/+archive only has bzr
<lifeless> well its at lp:bzrtools I think
<LaserJock> *sigh* OK
<LaserJock> this well this spagetti of packages is getting messy
<lifeless> yes
<LaserJock> I can't remove bzr-tools because of bzr-builddeb
<lifeless> I'd love some more csript support for the folk doing ppa maintenance
<LaserJock> although I suppose I can keep it but use the bzr branch of bzr-tools
<LaserJock> but I only need bzr 1.6 because I updated bzr-svn
 * Peng doesn't use the packages at all.
<LaserJock> Peng: well, I'm a simple user and I'd rather spend time using the VCS than tracking down all the versions
<luks> LaserJock: the thing is that it's easier to do `bzr branch lp:bzrtools ~/.bazaar/plugins` than to find the right package
<LaserJock> luks: yeah, but then you update and things are screwed
<luks> LaserJock: why do you think so?
<LaserJock> because that's what I just did
<luks> LaserJock: in me experience, things are screwed more if some debian packages refuse to update
<luks> *my
<LaserJock> I wondered if new stuff was in bzr-svn, and now I'm running after dependencies
<Peng> New stuff is most definitely in bzr-svn.
<LaserJock> well, I figured being on the 0.4 branch wouldn't be too bad
<Peng> It's not bad.
<Peng> But it has new C bits, so you have to run make.
<LaserJock> except it require a beta bzr
<Peng> Oh.
<Peng> I run bzr.dev anyway, so I hadn't noticed.
<LaserJock> which gives me problems with bzr-tools
<LaserJock> hmm, I can't find what reversion the bzr-dep was bumped :/
<LaserJock> ok, so I can't branch bzrtools because my current bzr won't work
<LaserJock> hmm, so I think I need to start from scratch
<Peng> LaserJock: Why won't it work?
<LaserJock> Peng: gives me some traceback
<Peng> LaserJock: Details?
<LaserJock> Peng: so I went back and removed everything bzr
<Peng> LaserJock: If it's from a plugin, you can run bzr without plugins temporarily.
<LaserJock> reinstalled 1.5
<LaserJock> now I'm trying to see if I can get a bzr-svn that works
<LaserJock> bah! it want's python2.4
<Peng> Bazaar has required Python 2.4 or greater for ages.
<LaserJock> no, I mean I have 2.5
<Peng> You mean bzr-svn specifically wants python2.4 rather than 'python -- yeah./
<Peng> Um, I use bzr-svn's 0.4 branch, and I don't have python2.4.
<LaserJock> yeah, I can't use that branch right now
<Peng> Why not?
<LaserJock> because it requires a newer bzr!
<LaserJock> this is the cycle I've been going through
<Peng> Oh.
<LaserJock> somewhere the bzr dependency got bumped
<Peng> There's no cycle for me, but I use the dev branches of everything.
<Peng> And don't build packages or anything.
<LaserJock> right, which is not great for me
<LaserJock> I'm not trying to be necessarily at the tip of development, I just want a set that works
<Peng> The tip of development works. :P
<LaserJock> if I can find where in the 0.4 branch the bzr dep was bumped I can go back to that revision, but I can't find it
<GaryvdM> Hi - I'm having a problem with ext-merge on windows. The file name has / separators and it should have \ .
<LaserJock> Peng: I guess, but I'd end up updating a lot of branches to keep up
<LaserJock> if I have to do bzr, bzrtools, bzr-svn, and the other plugins
<GaryvdM> Is there a api method to get a windows path from a unix path or should is just replace / with \ if on windows?
<LaserJock> and if they don't work with the current bzr.dev branch then they break
<LaserJock> anyway, I've got to go to bed, I'll trying to think of something tomorrow
<Peng> LaserJock: Yeah. I do keep up with them, and it's not too much effort. I update bzr.dev and bzr-svn whenever I'm bored (which is every 2 hours), and update the others whenever I think of it (every week or two?), and things usually work.
<Peng> LaserJock: Anyway, good night. :)
<Peng> GaryvdM: os.path?
 * Peng stares at Freenode.
<GaryvdM> This is where it gets the filenames:
<GaryvdM> http://bazaar.launchpad.net/~zindar/bzr-extmerge/trunk/annotate/10?file_id=__init__.py-20060218133530-ac9ae4e505cbcfa9#L70
<GaryvdM> I'm browsing bzrlib/osutils.py atm
<GaryvdM> I think might be able to find something there.
<GaryvdM> Is there a way to specify --fixes= after you have commited?
<lifeless> Guest12932: you are thashing your name; please stop, its filling the page up with noice
<Peng> lifeless: Do you have the ability to ban him?
<lifeless> yes, though I think Lnidas is somewhat regular and that seems harsh
<Peng> I agree, but temporarily banning people with misconfigured clients isn't an uncommon practice.
<Peng> Heck, it's not like anything is going on here anyway.
<lifeless> Leonidas: ping
<lifeless> Peng: OTOH I'm about to hop on a plane; I won't be around to unban
<Peng> lifeless: Oh.
<lifeless> which is more of a problem  I feel
<Peng> lifeless: Before you go, what's the status of bzr-search? Is it, like, done? Do you think it should be merged into the core?
<lifeless> Peng: well, there are some bugs open indicating future work
<lifeless> Peng: I consider it alpha status
<Peng> That would've been great if he had auto-rejoin off.
 * Peng blinks.
<lifeless> ok, so its entertaining but useless
<lifeless> bah
<lifeless> I don't want to kick the username, because I won't be around
<lifeless> sorry, but perhaps /ignore Guest* ?
<oleavr> or *@chronon.pointtec.de
<Toksyuryel> he's not changing his name to guest, nickserv is
<Toksyuryel> because he's not entering the password for the nick
<lifeless> oleavr: yeah, I want him/her to be able to join the channel; I will be offline very soon
<lifeless> Toksyuryel: oh, interesting
<Toksyuryel> given the number of attempts I'd wager that's not the real owner of that nick
<lifeless> I'm pretty sure it is
<oleavr> lifeless: ah I see
<lifeless> oleavr: so if they could msg me and say 'fixed unban me' I would ban them, but as I have to go - bad idea
<oleavr> lifeless: yep, understandable :)
<lifeless> Toksyuryel: I reckon they are not in front of the pc/not notcing nickserv complaining
<Toksyuryel> lifeless: then why does the nick keep changing back?
<lifeless> Toksyuryel: client
<lifeless> Toksyuryel: or they don't understand why its happening
<Toksyuryel> lifeless: what client auto-changes one's nick back?
<Toksyuryel> if they don't understand why it's happening it means they don't own the nick
<lifeless> 20:15 [freenode] -!-  away     : Auto Away at Thu Jul  3 16:41:12 2008
<Toksyuryel> a better script might be an auto-identify script :P
<Peng> -Guest2534- VERSION ZNC by prozac - http://znc.sourceforge.net <-- Apparently that client.
<Peng> Oh, it's a bouncer.
<Toksyuryel> *!*leonidas@chronon.*
<lifeless> clearly, after 10 days idle this is unlikely to go away in the next 5 hours :)
<Toksyuryel> heh heh
<lifeless> Peng: so search
<lifeless> Peng: I think its alpha - it works but there are some important things to do to make it as slick and smooth as the rest of bzr
<lifeless> Peng: getting indices shared between branches; stemming; date ranges; for starters
<lifeless> and there is the boarding call; I must go
<lifeless> back in 6 or so
<Peng> lifeless: D'oh, I was jsut about to say something. Anyway, have a nice flight. :)
<lifeless> Peng: oh, I think search is reliable now, just not complete; if that helps with clarity
<lifeless> bye
<Peng> lifeless: Thanks, it does.
<GaryvdM> ping luks
<Peng> GaryvdM: FWIW, my IRC client says his last message was 186 minutes ago.
<GaryvdM> ok - thanks
<luks> GaryvdM: pong
<GaryvdM> I wanted to chat about qdiff
<GaryvdM> I was thinking for background loading
<GaryvdM> The different views each have a append_diff method
<GaryvdM> The background loading calls thoughs methods when it has finished a diff.
<luks> have you seen my changes to the code from yesterday?
<GaryvdM> That will split populate_diff_documents.
<GaryvdM> Yes
<GaryvdM> Thats why I wanted to chat
<GaryvdM> So far - I actually have not written any code. Just reading and planing.
<luks> personally, the only thing I'd do is moving sequence matching from the initialization code to populate_diff_documents
<luks> and make populate_diff_documents only work on one file at a time
<luks> which would be repeatedly called by an idle timer, until all files are diffed
<GaryvdM> ok
<luks> GaryvdM: I mean, I don't mind any other solution if you think it's better, but this seemed the easiest to me
<luks> you are going to write the code, after all, you decide :)
<GaryvdM> DiffSourceView.setChanges and DiffViewHandle.setChanges  need the be changed to extendChanges
<luks> yep
<GaryvdM> Yes - but you know then code better than I so you might be able to give me advice...
<GaryvdM>  Ok - time to dive in....
<strk> $ bzr update
<strk> You tried to execute: bzr serve --inet --directory=/ --allow-writes
<strk> Sorry, you are not allowed to execute that command.
<strk> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<strk> gnash project, repository on savannah
<bob2> lp?
<bob2> does 'unset BZR_REMOTE_PATH ; bzr up' work?
<strk> no such env
<luks> misconfigured server on savannah?
<strk> same error with the unset anyway
<spiv> strk: sounds like a misconfigured server
<strk> they must have changed something within the last 12 hours then
<vimes656> hi there
<vimes656> I'm using bzr bzr1.5 installed from fink in mac os x
<vimes656> I'm always getting a locale error
<vimes656> bzr: warning: unknown encoding . Continuing with ascii encoding.
<mathrick> hiya
<mathrick> I hit a bug in bzr cat
<mathrick> http://pastebin.com/f78cd4840
<mathrick> I don't know what to make of it
<spiv> mathrick: That's https://bugs.launchpad.net/bzr/+bug/175570, I think.
<ubottu> Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Undecided,New]
<mathrick> spiv: ah, bummer
<colbrac> I just posted a patch on the bzr-gtk mailinglist with some dialog cleanup.. any comments?
<ToyKeeper> Yeah, but I'm replying on-list.
<Leonidas> lifeless: you can unban me already, I've got it working again
<Leonidas> my bouncer started to play ping-pong with the services
<Leonidas> (sorry for these problems, I'll take a look at the configuration of the bouncer)
<Peng> Did the bouncer finally give up or what?
<clemente> Hi; I plan to turn my web site into a branch repository to hold different simultaneous developments. But is there an easy way to check out a whole repository with all branches?
<liw> clemente, I don't know of such a way; I've occasionally wanted a "bzr branches http://foo/repository" kind of command, which would let one script things
<liw> (there might be one, I have not really looked for one throughly)
<colbrac> About the olive.glade file: The window_merge is used in MergeDialog in olive. But, unlike the other window_* dialogs, MergeDialog is not in the olive subfolder but in the main folder in merge.py. Is it thus used outside of olive?
<clemente> liw: that would be good; otherwise you need to know the exact name of each branch; is it like that?
<liw> clemente, as far as I know, you need to know the exact name of each branch to check them all out
<mathrick> I'm enhancing Bugs Everywhere to support operations on arbitrary branch URLs, not just working trees in the current directory, and I'm not sure how best to go about re-structuring the bzr backend of it
<mathrick> namely, the current implementation happily invokes bzr as a subprocess (ie. plain old popen()), and assumes there is a working tree available. So it can do things like add several files, then commit them all in a batch
<Peng> bzrtools adds a "bzr branches" command that recursively finds all branches in the current directory.
<mathrick> what is the best way to implement that from python using bzrlib?
<mathrick> that is, I want to be able to accept several ops, construct a revision from them, and then push it to a branch
<mathrick> having temp files is A-OK, but requiring working trees is not
<clemente> Peng: but not on a remote server, I think
<clemente> (trying)
<clemente> Mmmm :-(
<clemente> bzr: ERROR: Could not understand response from smart server: ('UnicodeDecodeError', 'ascii', 's:w7p0aWxlcw==')
 * mathrick still looks for someone to help him with navigating bzr's innards
<mathrick> to rephrase my question, is it possible to build up a commit without having a (physical) working tree?
<clemente> mathrick: I have no idea... Maybe you can construct a pack directly? Or maybe using bzr fast-import... fast-import accepts just a stream of data and does not require files
<mathrick> oh, that's certainly a hint, thanks
<clemente> It is the same data format that âgit fast-exportâ creates
<lifeless> mathrick: yes
<lifeless> mathrick: there are tests that do this using InMemoryWorkingTree
<lifeless> or MemoryTree or whatever I called it
<mathrick> oh!
<mathrick> cool, so reading those tests should tell me everything I need to know?
<lifeless> its only as sophisticated as I needed it to be at the time; but further improvements would be welcomed:)
<lifeless> mathrick: yah
<mathrick> I don't expect my needs to be terribly sophisticated, I follow a rigid protocol and mostly communicate with myself
<mathrick> well, somewhat rigid
<lifeless> mathrick: well, give it a shot; let me know how it goes
<mathrick> yup, doing that now
<lifeless> Leonidas: unbanned, thanks
<Leonidas> lifeless: thank you. I changed the settings and will change the bouncer to prevent this from happending in the future
<lifeless> Leonidas: no probs
 * Odd_Bloke returns.
<liw> http://www.yosefk.com/blog/dvcs-and-its-most-vexing-merge.html -- that has probably been discussed to death, yes?
<mathrick> does put_file_bytes_non_atomic replace the previous contents?
<mathrick> liw: the answer is "depends on your merge algorithm"
<mathrick> in particular, diff3 fails this test miserably
<colbrac> funfact: bzr-gtk trunk is 1000 days old today
<colbrac> at least.. according to my olive information dialog :)
<lifeless> mathrick: yes it replaces
<lifeless> colbrac: cool
<clemente> In a repository, I did (knowingly...) ârm -rf branch/â. But since the contents were stored in repo/.bzr and not in the branch, repo/.bzr has still a lot of things I don't want. How can I really remove the remainings of the branch?
<lifeless> clemente: you mean a gc?
<clemente> yes
<lifeless> I should really write that :). Anyhow, the manual way is to make a new repo; branch the branches you want to keep into it and then replace the old repo's .bzr/repository with the new one's.
<clemente> but there's no âgcâ command
<lifeless> thats what bzr gc will do when I get around to writing it
<lifeless> (well, it will optimise away some of the copying, but it will be conceptually the same)
<clemente> Thanks, I'll try it. By the way, I had to remove the branch by force because I had interrupted a âbranchâ with C-c and then no command I tried could delete it
<ToyKeeper> That reminds me... is there a way to see which abandoned branches are in the repo, and maybe get them back?
<lifeless> clemente: did you try zr break-lock ?
<lifeless> ToyKeeper: bzr hads
<lifeless> *heads*
<colbrac> bzr heads only shows 2 for me
<colbrac> and I have a few more
<ToyKeeper> Hmm, must be in some plugin I don't have right now.  I think I've seen it somewhere, though.
<colbrac> bzr help heads to the rescue
<colbrac> bzr heads --all
<colbrac> or even better
<colbrac> bzr heads --dead-only
<clemente> lifeless: No... In fact I don't know how to remove the branch. Is it remove-tree?
<clemente> lifeless: By the way, I thought that command âreconcileâ would be similar to what you said about âgcâ. Maybe they share features
<lifeless> clemente: to remove a branch its normally just rm -rrf branch
<lifeless> erm, -rf I mean :)
<lifeless> ToyKeeper: its in bzrtools
<lifeless> clemente: remove-tree removes the working tree, so you just have the branch on its own.
<clemente> But it's still needed a command to remove a branch which exists in a repository
<clemente> Althought rm -rf  + bzr gc   would work, too...
<ToyKeeper> Ah, I just hadn't set up a version compatible with bzr.dev yet.
<lifeless> clemente: well, yes. generally though a branch is a tiny fraction of a repo
<lifeless> clemente: so there has been little user pressure to make this part of the system streamlined (though it will happen) :). In particular, rming the directory leaves the head behind which is beneficial
<lifeless> (if you want to recover later :))
<Peng> Hmm, I occasionally mess up with bzr-svn and pollute a repo. A gc command would be nice there.
<lifeless> Peng: well a first implementation for packs would be refs = last-revision + tags for b in repo.find_branches(); create-pack_from_packs(revs = refs); remove packs matching refs;
<Peng> Would it wind up packing everything into one pack?
<lifeless> nah, only the ones it has to read to grab shit from
<lifeless> theres a little more glue etc in there, that was clearly just a sketch :)
<apol> how can I update to a revision from a workingtree?
<lifeless> apol: udpate will take you to tip, revert can take you back
<apol> mmm
<apol> fine
<apol> but... update only updates
<lifeless> yes, need to add -r to it
<apol> lifeless: i need to update it to a certain revision (say as svn up -r213)
<lifeless> apol: revert -r 213
<lifeless> apol: if you have local edits, shelve them first
<apol> lifeless: and with the python interface? is it the old_tree parameter?
<lifeless> apol: not sure offhand, builtins.cmd_revert and follow your nose probably
<apol> lifeless: cool
<apol> thx
<lifeless> np
<Peng> Huh, Loggerhead's RAM usage has dropped slightly twice today.
 * Foskasse http://graphjam.files.wordpress.com/2008/06/gj32.gif LOL!
<mathrick> ok, so I can hit https://bugs.launchpad.net/bzr/+bug/175570 with memorytree as well against bzr://
<ubottu> Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed]
<mathrick> it seems that branch.lock_read() does NOT lock the repo
<mathrick> even though branch.is_locked() returns true
<mathrick> could anyone assist me with debugging that?
<mwhudson> mathrick: do you have a testcase ?
<mathrick> mwhudson: I will in a second, but I wanted to poke around more in PDB
<mwhudson> hm, the traceback in the bug report is out of date
<mwhudson> mathrick: it seems to work for me now
<mathrick> it doesn't for me
<mathrick> I'm running 1.5 btw
<mwhudson> mathrick: i'm running 1.6b2 i think
<mathrick> mostly because 1.6 breaks loggerhead and it hasn't been updated last I checked
<mwhudson> mathrick: this seems like this sort of thing that might have been fixed by accident in the versionedfiles refactoring
<mwhudson> mathrick: i'm pretty sure loggerhead works with 1.6...
<mathrick> it didn't when I tried
<mwhudson> try again :)
<mathrick> if it does, then I see no reason to stick with 1.6 :)
<mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181 looks relevant
<mathrick> yep, thanks
<mathrick> isn't there a PPA for bzrtools?
<mathrick> mwhudson: still happens for me on 1.6b2
<mwhudson> mathrick: hmm
<mathrick> oh, maybe it's because the server is still running 1.5
<mwhudson> ah
<mathrick> nope
<mathrick> reran it as 1.6b2, still happens
<mathrick> mwhudson: https://bugs.launchpad.net/bzr/+bug/175570
<ubottu> Launchpad bug 175570 in bzr "bzr cat over bzr protocol fails" [Medium,Confirmed]
<mwhudson> mathrick: can you pastebin the traceback?
<mathrick> mwhudson: I did
<mwhudson> if i run bzr serve in one window
<mathrick> as a python comment
<mwhudson> oh ok
<mwhudson> i can run "bzr cat bzr://localhost:4155/README" in another
<mathrick> mwhudson: hmm, can you try subdir/README?
<mathrick> nah, that happens here for files in the main dir as well
<mathrick> mwhudson: what is the format of the repo?
<mwhudson> very odd
<mathrick> mine is pack-0.92
<mwhudson> same
<mwhudson> hm, if i run your python code it fails in a different way
<mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181
<mwhudson> no
<mwhudson> NotImplementedError: <bound method MemoryTree._populate_from_branch of <bzrlib.memorytree.MemoryTree object at 0x7f284c38f8d0>>
<mathrick> oh
<mathrick> mwhudson: definitely something is not in sync at your place
<mathrick> it's implemented and supposed to work
<mwhudson> oh
<mwhudson> that's because i have symlinks in the tree i'm testing with, it seems
<mwhudson> ok, now it fails the same way as for you
<mwhudson> mathrick: http://pastebin.ubuntu.com/27148/ seems to summarize the problem
 * mwhudson pulls in latest bzr.dev
<cyberix> I'm working on a bzr branch and it uses the bzrlib from my Ubuntu installation instead the one from that branch ( without my permission ;-)
<cyberix> How do I force it to use the one that comes with it
<cyberix> s/bzr branch/bzr bzr branch/
<Verterok> cyberix: /path/to/branch/bzr selftest ;)
<Verterok> cyberix: s/selftest/<any_command>/
<cyberix> That is what I'm doing
<Verterok> hm, cyberix: try with: PYTHONPATH=/path/to/branch:$PYTHONPATH /path/to/branch/bzr
#bzr 2009-07-06
<mwhudson> jelmer: did i tell you before about bzr-svn tests segfaulting with python 2.4 ?
<jelmer> mwhudson: no
<jelmer> mwhudson: please file a bug with gdb backtrace if possible
<mwhudson> ok
<mwhudson> doesn't happen with 2.5
<mwhudson> trying on hardy w/ec2 now
<mwhudson> oh waht
<mwhudson> jelmer: any ideas? http://pastebin.ubuntu.com/210808/
<mwhudson> (haven't dug at all, maybe i'm doing something dumb)
<poolie> hello
<Peng_> Hi
<jelmer> mwhudson: that one should be fixed now
<mwhudson> jelmer: in bzr-svn?
<mwhudson> (i was testing the release-0.6.3 tag)
<Pilky> poolie: did you get my email about the bzr licence?
<poolie> hi
<poolie> i did get it on friday
<Pilky> cool
<poolie> i'll reply today
<Pilky> thanks
<Pilky> just wanted to make sure, been having a few problems sending emails recently
<Pilky> anyway time for bed for me, night
<spiv> Hello.
<poolie> hello spiv
<mwhudson> oh hm, does happen on hardy too
<mrooney> lifeless: checking out grisbi, eh? saw your bug reports :)
<lifeless> mrooney: yah
<lifeless> mrooney: for 'easy to use' it seems harder than gnucash
<lifeless> ><
<poolie> hello lifeless
<lifeless> hi poolie
<poolie> is it better in some other way?
<poolie> i think i tried it...
<lifeless> poolie: I think it may have saner defaults, but in my limited experiment it wasn't really better/worse
<poolie> gnucash doesn't seem to be changing very fast
<lifeless> I was hoping for something like MS Money, which I used inthe late 90's, that was at least polished, for all its defects
<mrooney> lifeless: I popped in to ask if you had a minute to evaluate the personal finance software I am working on, wxBanker, and let me know what you think coming from grisib/gnucash. I am currently working on a newer version for Karmic
<RAOF> I've quite liked Homebank's interface, but I'm may well be looking for something a little bit different to you.
<poolie> mrooney: what do you think is better than gnucash in wxbanker?
<lifeless> mrooney: karmic package is the thing to try?
<mrooney> there are some screenshots at wiki.ubuntu.com/wxBanker I do believe :)
<mrooney> nope bzr branch lp:wxbanker is the thing to try, it just needs python-wxgtk2.8 and python-numpy
<mrooney> poolie: gnucash is more featureful and advanced, I tried it and initially was overwhelmed and just wanted something simple to keep track of basic transactions in arbitrary accounts
<lifeless> RAOF: could be; I need to manage (today) a mortgage, bills that are paid by proxy, income in multiple currencies (pay + investments), and an utterly useless export facility from my bank
<mrooney> lifeless: oh no multiple currencies yet, although you can csv import
<poolie> ah
<poolie> yay Vanguard :)
<RAOF> Homebank manages the last criterion with reasonable applomb, and the rest are use-cases I've never tried.
<lifeless> vanguard?
<poolie> the RMS of finance :)
<poolie> s/^/John Bogle is/
<lifeless> $ apt-cache search vanguard
<lifeless> $
<lifeless> poolie: did you play with https://edge.launchpad.net/bzr-guess/trunk ?
<poolie> http://en.wikipedia.org/wiki/The_Vanguard_Group
<jelmer> mwhudson: yeah, in bzr-svn
<poolie> featured in his screenshots
<jelmer> mwhudson: it can be worked around by installing python-apt
<jelmer> s/python-apt/python-tdb/
<poolie> lifeless: nup, i only saw the mail so far
<mwhudson> jelmer: oh
<mwhudson> jelmer: ok, have gdb on a python2.4 segfault
<mrooney> anyway I was just poking around looking for UI / intuitiveness opinions / reviews so I can improve it for karmic, let me know if you have any :)
<poolie> mrooney: i might try it too
<poolie> i use gnucash quite a lot
<mrooney> hmm, I suspect you will find it lacking but, let me know what is most lacking
<poolie> and can see many ways in which it could be improved up
<poolie> upon
<mwhudson> jelmer: this is the start of the traceback http://pastebin.ubuntu.com/210848/
<poolie> can it do the 'total for this financial period'? i use that a lot
<mrooney> poolie: my target audience is people overwhelmed by gnucash or people who want to start tracking finances, so people happy with gnucash will probably find features missing in wxbanker
<lifeless> I can tell you what I find most frustrating about most of these tools
<lifeless> and thats polish
<lifeless> I mean, I can run a double entry system on cards if I want to
<lifeless> Simple reports and data entry for that are *not a win*
<mrooney> poolie: hm, you can search by date regex, I could also add a start and end date control to the graph
<mrooney> I should just add a start and end option in the search, let me do that now :)
<poolie> mrooney: to do my tax, i need to answer things like "how much did depreciation of the work-related fraction of my computer equipment cost between 1 jul 08 and 30 jun 09"
<mrooney> yeah, that isn't really possible to do in an automated way currently :)
<mrooney> it will be soon with recurring transactions, and then searching on those based on description / account
<mrooney> but these are already good things to write down :)
<poolie> so, for me too, like lifeless
<poolie> i am not at all overwhelmed by the double entry concept
<poolie> i just wish there was more polish
<poolie> oh maybe more speed wbn too
<poolie> it takes about a minute to start
<poolie> at this rate it would take years to
<poolie> at this rate it would take weeks* to boot for Mark :)
<garyvdm> I got a question about trees.
<poolie> would probably be rewarding to try MYOB or some windows program
<poolie> hello gary
<garyvdm> Background: for qcommit, the user can select files to be added.
<garyvdm> Hi poolie
<garyvdm> This only happens when the ok is press, and is achived by running bzr add
<garyvdm> We also have a diff button which show a diff of all selected changes.
<garyvdm> But due to the design, it does not include the files that the user has selected to be added
<garyvdm> Is there a way that I can temporally add files to the working tree without anything being written to disk?
<lifeless> no
<lifeless> trees don't have a transactional model
<lifeless> you could use a preview tree
<garyvdm> lifeless: Hi
<lifeless> or you could just add the files, and unversion afterwards
 * garyvdm looks at preview trees
<lifeless> mrooney: I want two key things: planning features: what-if on mortgage, debt management, investment management. And country specific glue - a chart of accounts that dumps everything into the right buckets for AU tax returns
<mrooney> lifeless: interesting, I have some budgeting stuff planned so you can add your own lines to the graph, like saying, I want my savings account to grow by 7% plus 10K a year, and see that in comparison to the actual balance
<mrooney> so that could work to set debt paying guides as well. the tax stuff sounds more complicated :)
<poolie> budgets would be nice
<poolie> you could do a lot there
<poolie> like if i've budgeted to spend say $x on ugg boots per year
<poolie> well, actually for a simpler example
<poolie> $x on groceries
<poolie> it could show if i'm running a bit high for this month
<poolie> but some things are very lumpy, if they're only paid for once per year
<poolie> and it could help take that into account too
<poolie> for quoted investments i'd like to see the current value compared to what i spent on it
<poolie> gnucash could do that, but doesn't
<poolie> oh and then you could calculate the irr
 * SamB wishes the daily PPA builds would now have versions of form bzr 1.16.1+XXXX
<lifeless> SamB: why not 1.17~
<SamB> lifeless: well, right now it's 1.16+XXXX
<SamB> whereas the latest is "1.16.1"
<poolie> i wonder what the trunk currently
<poolie> say
<poolie> says*
<poolie> i noticed that the other day too
<SamB> I mean, that's what aptitude thinks is the latest ;-)
<lifeless> what is it about GUI help that they all a) want to run a browser and b) want to *not run my default browser*
<SamB> lifeless: it's because you aren't using Windows, maybe ;-P
<SamB> where they probably have a simple API to run the default browser
<mwhudson> jelmer: the subverpy tests pass for me, of course :)
<lifeless> kfogel: please put backtraces in bug reports
<lifeless> ok deepish hacking mode on; SMS me if you want my attention
<lifeless> poolie: install bzr-guess, would like to see what you think
<kfogel> lifeless: I did (or so I thought...?)
<lifeless> no, you linked to a pastebin site
<lifeless> totally useless for reviewing bugmail
<lifeless> what I mean is, it adds a lot of latency to the task of figuring out what the bug is
<lifeless> because I have to fire up a web page
<lifeless> this turns a 5-10 second operation into more like a minute
<lifeless> unless its an lp web page
<lifeless> in which case its a couple of minutes
<kfogel> lifeless: uh, did you see the attachment on the bug?
<kfogel> the one that my initial comment said I was attaching, and that I did attach? :-)
<lifeless> kfogel: launchpad doesn't forward attachments
<kfogel> lifeless: I would happily paste a backtrace directly into the bug desc/comment form *if* that form would give me any clue about what its formatting rules are.
<lifeless> kfogel: just paste them, it preserves CR
<kfogel> lifeless: CR only?
<lifeless> if you paste it will work
<kfogel> lifeless: I will try to remember that, but shouldn't have to :-).
<lifeless> kfogel: agreed
<lifeless> lp should have attached the attachment to the bug mail
<lifeless> but what it does is send a separate mail out with the url
<lifeless> its very frustrating
<kfogel> lifeless: also, not sure how, but your comment comes after a conversation between James and me in which we find out exactly what you said in your comment.
<kfogel> Is that because of the "lp bugs don't implement mid-air collision" thing?
<lifeless> kfogel: I do bugs via email
<lifeless> kfogel: I was replying to your 4:06 comment "This could be related to bug #120930, though I tend to think not, as no"...
<ubottu> Launchpad bug 120930 in bzr "commit of files with unicode names fails in 0.17rc1" [Critical,Fix released] https://launchpad.net/bugs/120930
<kfogel> lifeless: While I appreciate the convenience of an email interface, I do think that makes you more likely to enter into a conversation without having heard what was most recently said.
<lifeless> kfogel: be generous in what you accept :)
<lifeless> kfogel: for all that you had both decided on bzr-search, I still needed to make the backtrace more visible for me, as i"ll need it when investigating the cause.
<lifeless> I had seen all the discussion when I replied
<kfogel> lifeless: I think you know all the things I might say at this point in the conversation, so I won't say them :-).
<kfogel> Thank you for looking into it, anyway.
<lifeless> I haven't yet, but I will
<lifeless> oh
<lifeless> what bzr-search revno do you have?
<lifeless> kfogel: ^
<kfogel> lifeless: 70
<lifeless> update
<kfogel> lifeless: I haven't fetched in a while
<kfogel> should I?
<kfogel> ok
<kfogel> lifeless: commit seems to work now
<kfogel> lifeless: closed bug as invalid, therefore
<lifeless> kfogel: fixreleased actually
<lifeless> kfogel: I've already done it
<kfogel> heh!
<kfogel> now, even though I'm using the web interface, I did the same thing you did -- I didn't see a previous comment, and therefore had a non-reported mid-air collision.
<kfogel> lifeless: ^^
<lifeless> one of the things that makes the email interface frustrating actually, is latency
<lifeless> theres no good technical reason that smtp events should be any higher latency than http, for in or out.
<lifeless> kfogel: well, I closed it by email
<kfogel> lifeless: I think the method by which you closed it doesn't matter here -- even if you had done it via web, that problem still would have happened, b/c the bug tracker doesn't do conflict detection.
<poolie> hm
<lifeless> (time to close, 3 seconds - 1/5th the time to close the web page)
<lifeless> kfogel: yes, and it doesn't do real-time update on open views either
<poolie> i suspect, without strong evidence, that midair collisions actually do _worse_ than just taking the latest values
<kfogel> lifeless: as I said, no argument about the convenience (to that user) of email.
<lifeless> kfogel: I filed a couple of bugs last week about the webui in this regard
<poolie> let alone taking the latest values of changed fields i
<poolie> it's hard to see how that could be true
<kfogel> poolie: I've worked with both, and this way is worse.
<kfogel> poolie: mid-air collision just means notice the conflict, inform the user, and let them figure out what to do.
<poolie> kfogel: both which?
<kfogel> the way I just described, and the current way
<poolie> oh you mean you'd prefer it gives you an error
<kfogel> lifeless: I thought that was an old bug, though?
<poolie> like um bugzilla does?
<kfogel> poolie: VASTLY
<lifeless> kfogel: which-was ? :)
<kfogel> poolie: or like every other tracker I've worked with, as far as I know? :-)
<lifeless> kfogel: debbugs doesn't.
<kfogel> lifeless: that the bug tracker not doing conflict detection is a bug
<kfogel> lifeless: ah, good example.  okay, except debbugs (which could, though -- email interface vs web interface has nothing to do with this)
<poolie> ok
<lifeless> kfogel: I didn't file bugs about c-d, rather about stale-pages.
<lifeless> kfogel: if you have a view on e.g. a list of bugs
<lifeless> and poolie closes one
<lifeless> it would be nice if the list updated
<kfogel> lifeless: oh, I see -- yes, great idea
<poolie> yes
<poolie> a real pony of an idea :)
<poolie> btw Black Sheep A+
<mwhudson> i watched black sheep on the way back from allhands/uds
<lifeless> glad you like it
<mwhudson> at one point i had half the cabin crew watching it over my shoulder, which was a bit of an odd experience
<lifeless> LOL
<kfogel> is this some movie?
<thumper> poolie: black sheep isn't that funny
<thumper> poolie: certainly a good b-grade movie, but A+? B+ maybe
<lifeless> http://en.wikipedia.org/wiki/Black_Sheep_(2007_film)
<mwhudson> jelmer: still awake?
<lifeless> http://en.wikipedia.org/wiki/Wilhelm_scream wow.
<mwhudson> (i hope not)
<kfogel> anyone know the bzr flag to ignore ~/.bazaar ?
<kfogel> bzr help hasn't turned it up yet, though I'm sure it's there somewhere
<thumper> kfogel: are you versioning ~/ ?
<thumper> kfogel: bzr ignore .bazaar
<kfogel> thumper: Yes.  In Subversion :-).
<kfogel> thumper: no, not to ignore for vc
<kfogel> thumper: to ignore for running a command
<thumper> kfogel: huh?
<kfogel>     bzr --behave-as-if-i-had-no-.bazaar-dir
<thumper> kfogel: ah
<thumper> kfogel: something to do with $HOME or $BZR_DIR
 * thumper thinks
<spiv> kfogel: perhaps "BZR_HOME=/dev/null bzr ..." ?
<lifeless> spiv: will error
<spiv> It generates a bit of "No handlers ..." noise on stderr probably due to being unable to initialise the .bzr.log trace file, though.
<lifeless> (I think this is a bug) - bzr writes a default ~/.bazaar/ignore on first use.
<spiv> Ah, drat, so it does.
<spiv> I tried 'bzr whoami', and that worked.
<spiv> But actual working tree ops die as you say.
<lifeless> kfogel: why
<spiv> I guess there's always "tmpdir=$(mktemp -d); BZR_HOME=$tmpdir bzr ... ; rm -r $tmpdir", although you'd need more complexity to preserve the exit code...
<lifeless> and still. why?
<kfogel> lifeless: I wanted to test some pulls over http and know for sure that my launchpad identity was not affecting them.  I just moved the dir out of the way temporarily, it's no problem.
<spiv> Oops, streaming is still generating more root records than IDS.  I guess I need to more ruthlessly reuse more of the IDS logic...
<lifeless> spiv: did the test suite catch it?
<spiv> lifeless: not directly, I found when digging into a inventory-parents/stacking related failure.
<spiv> I'll certainly add a direct test.
<lifeless> could you add tests then ?
<lifeless> thanks
<spiv> :)
<lifeless> spiv: direct-interface level would be my preference
<spiv> lifeless: I was thinking interrepo test for any non-rr -> rr, with rev1:[] and rev2:[rev1], do a fetch, rev2's inv should have (root-id, rev1) (and corresponding text record).
<lifeless> spiv: there's one like that already
<spiv> Yeah, I expect so.
<lifeless> spiv: rev2's inv should have (root-id, rev2)
<itistoday> i have a lightweight checkout that's bound to a bzr:// address, but that address has changed, how do I point the checkout to the new location?
<spiv> Hmm.  Really?
<fullermd> itistoday: switch
<lifeless> spiv: yes, the algorithm is meant to be identical in the presence of ghosts
<mwhudson> itistoday: i think you have to edit the .bzr/branch/location file by hand :(
<mwhudson> unless that bug has been fixed
<lifeless> mwhudson: --force
<mwhudson> ah good
<lifeless> mwhudson: fixed about a year ago
<fullermd> Heck, who has time to keep THAT up to date?
<itistoday> fullermd: yeah, doesn't work :-(
<itistoday> mwhudson: hmmm... thanks i'll try that... odd that there isn't a command to do this
<lifeless> itistoday: there is a command
<lifeless> itistoday: bzr switch --force NEWURL
<itistoday> lifeless: it doesn't seem to work, i get a connection refused error for the  old location
<spiv> lifeless: ah, I see.  So it's actually IDS that's wrong then, not the streaming.  Hmm.
<lifeless> itistoday: oh, thats odd.
<lifeless> itistoday: what bzr version do you have?
<lifeless> spiv: look in log for a commit from me about this
<lifeless> spiv: and you'll find the test I wrote for it
<itistoday> lifeless: 1.16
<spiv> lifeless: will do
<itistoday> mwhudson: thanks, that seemed to have worked, although very odd, it will give an error if that file ends in a newline.
<lifeless> itistoday: what does 'bzr plugins' report?
<mwhudson> itistoday: ah, could have warned you about that
<lifeless> we have a test that this works
<mwhudson> itistoday: bzr switch --force worked for me though
<lifeless> so its being cause by something outside of bzr core, or something unusual
<lifeless> bzrlib.tests.blackbox.test_switch, test_switch_lightweight_after_branch_moved
<itistoday> lifeless: bzr_push_and_update (0.2dev), bzrtools 1.16, launchpad 1.16, netrc_credential_store 1.16
<itistoday> perhaps it's a bug to do with switching from a URL that looks like this: bzr://foo/  => bzr://foo:9990/repo/trunk ?
<mwhudson> itistoday: i guess it's too late now (maybe you could copy the tree and mangle the location file in the copy?) but if you can reproduce the problem, could you run with -Derror and pastebin the traceback?
<itistoday> mwhudson: it might be easy to turn things back... just by editing that file again, i'll try, one sec
<mwhudson> looking at the code i can't see how --force isn't working
<mwhudson> unless as lifeless says, switch is being entirely replaced somehow
<lifeless> itistoday: also if you can reproduce it, please try 'bzr switch --no-plugins --force NEWURL'
<itistoday> lifeless: ok
<itistoday> where does the -Derror go?
<itistoday> immediately after bzr?
<itistoday> or after the command?
<mwhudson> anywhere
<lifeless> between bzr and the command normally
<itistoday> k, able to reproduce, 1 sec
<itistoday> what's a good pastie site?
<lifeless> rafb.net
<lifeless> or paste.ubuntu.com
<lifeless> or whatever
<mwhudson> spiv: can reproduce the pyflakes problem btw
<itistoday> http://pastie.org/535315
<itistoday> hope that's helpful
<mwhudson> spiv: and fixed it
<lifeless> itistoday: it is thanks
<lifeless> itistoday: i'll turn it into a bug
<itistoday> lifeless: k cool
<mwhudson> aaah
<spiv> mwhudson: oh, great.  Thanks!
<mwhudson> spiv: r29 of my branch
<mwhudson> itistoday: the code was expecting "not branch", not "connection refused"
<itistoday> mwhudson: sorry, don't really follow, but does that mean you know what the problem was?
<mwhudson> itistoday: yes
<itistoday> mwhudson: cool :-)
<itistoday> btw, is 'cool' still in use today?
<itistoday> i come from the past you see...
<mwhudson> so do i, in internet terms :)
<fullermd> I like living in the past.  I know when to cringe.
<thumper> mwhudson: aren't you still under 30?
<mwhudson> thumper: no
<thumper> well... at least I never used punch cards :)
<fullermd> My FORTRAN book instructs me to use punch cards in the exercises...
<fullermd> ...  OK, now I have to go see if Google knows who makes a USB card reader...
<lifeless> good luck with that search term
<mwhudson> haha
<fullermd> Whoah.  I should know that doing a search like that is likely to give me even weirder results than what I'm looking for...
<fullermd> "Proposed solution: Construct an adapter that interfaces a standard PC USB port to the tape drive interface of the 1401."
<fullermd> http://ed-thelen.org/1401Project/IBM_1401_to_PC_Interface_Adapter.html
<fullermd> So, just follow those instructions, feed your cards into the 1401, and write them to the tape [PC].
<fullermd> All you need is a 1401...
<vila> hi all
<vila> go away vila , damn ghost mouse events ! I swear I didn't click...
<fullermd> Are ghost mice more or less frightening to elephants?
<vila> fullermd: far more ! Imagine mouse clicks occurring not even where your pointer is...
<vila> elephants just can't support that...
<lifeless> night all
<vila> night lifeless
<poolie> lifeless: are you still here?
<poolie> can i now lazily register commands?
<poolie> i can certainly be lazy by asking rather than digging more :)
<poolie> vila, your comment "Turn test_non_ascii.py test_mv errors into failures." is interesting to me
<vila> poolie: hehe, command lazy registering is certainly a continuum :)
<poolie> i wonder if at least getting to actual failures rather than other types of exception is a good intermediate step
<vila> good, the idea was to either start discussion during review or leave a starting point for a better diagnostic or bug filing
<vila> oops, message crossing
<poolie> so you did find it useful?
<vila> we have the actual failures, but keeping them undiagnosed is counter-productive for the test farm
<vila> given that the failures date back to 1.6 ....
<poolie> oh, you meant into known failures
<poolie> i agree about that
<vila> yes, thinking more about it I should just turn the TestSkipped into a KnownFailure
<vila> I was thinking about doing that as a tweak during the week-end
<poolie> i was thinking about something else which is whether a TestFailure (or whatever it's called) is better than say a TypeErorr
<poolie> probably not enough better to be worth making a separate step for it
<poolie> um
<poolie> regarding TestSkipped etc
<poolie> i'd like to overhaul that too
<poolie> i think we're missing a couple of useful classes
<vila> I don't get it. What TypeError are you talking about ?
<poolie> also, marc tardif(?) recently posted about the taxonomy of test failures used by different frameworks
<poolie> it might be worth looking at that
<poolie> um
<poolie> it's just an abstract example-
<poolie> i'm talking about the difference between tests that crash when run
<poolie> and those that fail with in a specific test assertion
<vila> Oh ERROR instead of FAIL
<poolie> some people think that failures of the first type are worse than the second type
<poolie> right
<poolie> i don't think that's that ERROR is worse, or even very different, in our case
<lifeless> (program over :P)
<lifeless> so I think there is a good concrete difference
<lifeless> say you break something
<vila> I view ERRORs as compilation issues as opposed to FAIL as run-time issues. The former should indeed occurs only during dev
<lifeless> things /testing/ the thing broken are more likely (one hopes) to FAIL, and all the ERRORS are fallout that one can ignore until the FAILures are fixed
<lifeless> and probably once the FAILures are fixed the errors will go away
<vila> lifeless: interesting counter-example :) I should try that next time, but I'm pretty sure I always try to address the ERRORs first...
<poolie> this is kind of a beer question :)
<lifeless> poolie: so, re lazy - I don't think its good to have to manually maintain a cache
<poolie> so i'm going back to your review then to my code
<lifeless> poolie: other than that its all open ;)
<poolie> lifeless: i agree, once and only once is better
<lifeless> and, try bzr-guess :):)
<poolie> ok
<poolie> i'd rather have better zsh completion :)
<lifeless> fortunately its not an exclusive choice
<lifeless> anyhoo - see you all tomorrow
<poolie> lifeless: ok, very cute
<poolie> vila, +1
<poolie> to your osx patch
<lifeless> poolie: this might be something to put in core
<poolie> which?
<lifeless> bzr-guess
<poolie> :? maybe
<poolie> um
<poolie> it's an interesting test case
<poolie> i don't know how many people will specifically go out and get it separately
<poolie> and it's presumably small
<lifeless> distributors could
<poolie> otoh people may want it off by default?
<lifeless> git has something similar - type 'git inti'
<vila> lifeless, poolie : I'd like bzr-guess to be put in core *as a plugin* so that it gives one more plugin example and leave the core code simple
<poolie> interesting
<poolie> mm
<poolie> as i posted a while ago
<poolie> i think shipped plugins are probably a bad idea
<poolie> merge or merge not
 * poolie attempts to get his nose down
<lifeless> poolie: I still disagree with you. We have lots of plugin structured code - repo formats, merge handlers etc.
<vila> poolie: and thanks for the review
<poolie> um
<poolie> we might be talking about somewhat different variables
<lifeless> not an urgent discussion
<lifeless> put your nose down.
<poolie> i completely support having it cleanly separated
<poolie> through registries or whatever
<poolie> actually maybe i mainly care about 'selftest --no-plugins' etc
 * lifeless waves
<lifeless> lets chat about this later
<poolie> vila: would you agree in principle with a patch for bug 391411?
<ubottu> Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411
<vila> poolie: I agree that it should be part of reconfigure, it would be nice if it works with remote branches too... ha! Yes, bug #391405 already linked
<ubottu> Launchpad bug 391405 in bzr "want an option to force stacking or not when creating a branch" [High,Confirmed] https://launchpad.net/bugs/391405
<vila> poolie: that will require a bunch of tests though...
<poolie> vila, i was hoping to tackle that later
<poolie> i think they can be fixed separately
<poolie> i was hoping for fairly small smoke tests at the ui layer
<poolie> at least for this one it should be mostly a matter of using apis that are already there
<vila> poolie: can't you raise NotLocalUrl until your address the problem ?
<Youssef> Hi guys!!!
<Youssef> I come to report a litte bug!!!!
<Youssef> Who want to liste to me...?
<vila> Youssef: https://bugs.launchpad.net/bzr/+filebug !!! :-)
<Youssef> lol
<Youssef> im already there
<Youssef> lol
<Youssef> :D
<vila> Youssef: otherwise: ask, don't ask to ask !!!
<vila> Until you ask, nobody knows if he/she can answer
<Youssef> :P
<vila> poolie: the LockNotHeld in a stacking env reminds me of jam encountering the same kind of problem...
<vila> poolie: I vaguely remember him sending a patch even... not sure it landed though
<poolie> hm
<poolie> well, if you can find it that would be nice
<poolie> i'm not sure what you mean about NotLocalURL
<poolie> that i could make it work only locally at first?
<poolie> i guess so
<vila> poolie: yes, make it work locally first
<poolie> any idea about that patch for the unlock error?
<vila> poolie: from jam you mean ?
<poolie> yeah, for the problem jam reported
<poolie> just if you happen to have it
 * vila doing a quick search
<vila> poolie: [MERGE] Cleanups for fallback repos and stacking is what I had in mind
<vila> poolie: so I think this has landed, but you may still find it inspiring
<vila> poolie: part of 1.16
<vila> poolie: hmm, just see your comment, you may be right about the branch not having a stacking-on branch anymore
<poolie> hm, i'm working off today's trunk
<Pilky> poolie: hey, just read your reply
<Pilky> I've tried --xml before but the big issues I've had is that going through the main UI makes working with push, pull, branch etc awkward as getting the progress and giving the authentication credentials is very hacky
<Pilky> it also seems like bzr-eclipse have the same issue
<poolie> vila, i'm running out of concentration, i think i'll leave it there for today
<poolie> i think that fix won't be very hard
<poolie> Pilky: ok, so how about just keeping a compatible licence and then dealing with what arises?
<Pilky> could work, I mean would it be a huge problem with the API being LGPL. I'm not planning on modifying bzr itself, the API will be designed to work with the standard bzr implementation
<Pilky> I just want something that would allow others to use the API in any sort of app, open or closed source
<vila> poolie: ok, lunch time for me anyway, cu
<Pilky> as I think it could really help get bzr support into many tools on the Mac
<poolie> i guess it just seems a bit speculative to me
<poolie> changing licence is a big deal and basically irrevocable
<Pilky> yeah
<poolie> and the question of lgpl vs gpl is hard to understand for python code
<poolie> i'd definitely like to see good support in xcode and other mac apps, certainly
<Pilky> well the idea is for me to write the API in PyObjC and bundle it in a framework
<poolie> well
<Pilky> of course the issue is I'll be looking at bzrlib.builtins to learn how to use bzrlib
<poolie> i'll talk to other people here about it
<Pilky> ok cool
<poolie> um
<Pilky> yeah
<poolie> i think this is going to be a lot more convincing if there's already a good mac ui and people are then saying "we'd like to integrate with $app but we need $thing"
<poolie> than just 'will you change your licence?' right from the word go
<Pilky> yeah
<poolie> i think if there's an objc api that provides a similar level of functionality but that can be called as a component
<poolie> in principle that should be fine
<Pilky> ok
<poolie> but, maybe there's some good mechanism like the os x Services rpc (the details are rusty) that actually turn out to be a better way to integrate
<Pilky> well one way that is in the back of my mind is to make the Obj-C API into a separate binary and then use distributed objects to communicate between the two processes
<Pilky> much more complicated that I'd like but it satisfies the GPL
<poolie> ok
<poolie> well,
<poolie> work on the objc library and we'll see how it comes out
<poolie> good night
<Pilky> ok, ttyl
<bialix> lifeless: https://bugs.launchpad.net/bzr/+bug/285055/
<ubottu> Ubuntu bug 285055 in bzr "switch --force on lightweight checkout connects to original remote branch" [Medium,Confirmed]
<jam> morning vila
<vila> morning jam !
<LarstiQ> lifeless: could it be that I no longer have PQM access? I'm not seeing any rejection mails, but it did show up on http://pqm.bazaar-vcs.org/
<vila> LarstiQ: what are your public and parent branches (precise URLs as shown by bzr info) ?
<LarstiQ> lp:~larstiq/bzr/reinvoke-2.6 and /home something, but I specified --submit-branch=http://bazaar-vcs.org/bzr/bzr.dev
<mozmck_work> question: if I have used bzr init to put a project under bzr, can I later change it to a shared repository?
<Peng_> mozmck_work: Yes, using "bzr reconfigure".
<Peng_> I think. Even if not, you could still do it; it'd just take a little more work.
<vila> LarstiQ: don't use lp branches
<vila> LarstiQ: convert them to their http equivalent, there seems to be one bug related to lp that keeps coming and going ...
<mozmck_work> Peng_: thanks
<LarstiQ> vila: k, will try that
<LarstiQ> vila: it seems to be running
<vila> LarstiQ: ping spiv, I think he's the last who encounter that kind of problem
<vila> LarstiQ: by the way, do you know how to automatically start ssh tunnels ?
<LarstiQ> vila: automatically? /me feels he is missing context
<LarstiQ> vila: I've got a jumphost setup though
<LarstiQ> vila: http://blog.ganneff.de/blog/2007/12/15/using-a-ssh-jumphost.html
<vila> LarstiQ: from my laptop I use local forwarding to my desktop for smtp, but that requires me to manually initiate an ssh connection or starting the tunnel manually,
<spiv> LarstiQ: last time I tried lp: URLs weren't working with PQM, I need to pester spm about that again.
<vila> wow, good night spiv :-)
<spiv> LarstiQ: try setting the public_location for your branch to http://...
<spiv> vila: yeah, I know... I'm about to sleep :)
<LarstiQ> spiv: I did, PQM is rrunning the tests now :)
<spiv> LarstiQ: ok, good, it's still that problem then :)
 * spiv -> land of zzz
<vila> LarstiQ: now I'd like these tunnel to be up when I need it so I'd like to put it in a @reboot cron entry, but ssh ask for my password at that time instead of waiting for a connection on the local port
<LarstiQ> vila: ah, right
<LarstiQ> vila: I believe mutt has some support for setting up ssh tunnels
<LarstiQ> personally I deliver over tlsed port 587
<vila> LarstiQ: ok, more context :-) I said mail but I want to do that other uses so I'd like a ssh-only solution if possible :-)
<vila> s/other uses/for other uses/
<LarstiQ> vila: you could use an openpgp card with an auth key and then pinentry-qt for the passphrase, to deal with the password prompting?
<vila> no
<vila> my two problems are: 1) starting without password or reliably delay until the ssh agent is up, 2) restart if the connection is lost
<vila> I wonder I should wrap the process in python script myself or if there is already some solution I can't think about :-/
<vila> jam: didn't you use ssh tunnels yourself ?
<rocky> is there anyway to specific file ignores for stuff on your own local workstation such that they don't have to get committed with .bzrignore ? (ie inside bazaar.conf)
<vila> rocky: there is a global ignore file alongside bazaar.conf
<rocky> heh
<rocky> too obvious =P
<vila> rocky: sometimes it helps to think: "If I were programming that tool, I'd put that feature here" and just go checking :)
<vila> sometimes it doesn't though, like my ssh tunnels :-D
<jam> vila: Sometimes
<jam> I didn't quite see what was going wrong (network went flakey)
<vila> jam: don't tell me you use an ssh tunnel for chatting :
<vila> :) Ooops, typo in smileys now :)
<jam> *I* don't
<jam> I believe Robert uses a remote IRSSI correction
<vila> jam: Do you use ssh tunnels for anything ?
<jam> Mostly for sending mail when I'm away from home
<vila> jam: do you start manually or automatically ?
<jam> manually
<vila> I'd like to automate that (I now have three of them smtp/ssh/buildbot)
<vila> I used to start the smtp one manually by issuing an ssh connection and declaring the local forwarding in ssh/config, I've seen that I can do: "ssh -L port:host:port -N&",
<vila> but I still need to issue that manually and the process errors out under some conditions
<vila> so,
<vila> my two problems are: 1) starting without password or reliably delay until the ssh agent is up, 2) restart if the connection is lost
<vila> jam: thoughts ?
 * awilkins uses an SSH tunnel for chat, what's wrong with that?
 * awilkins uses SSH tunnels for many things
<vila> awilkins: do you know how to start them while addressing my 2 points above ?
<awilkins> I have 2 mins until train, I shall look briefly but may speak later
<vila> ok
<awilkins> vila: Yes you can define port forwarding in .ssh/config
<awilkins> hMM
<vila> awilkins: been there, done that, want more :)
<awilkins> Not sure this is issue but now must run
<jam> vila: I've seen people do stuff like "ssh-add -l" to determine if keys have been added to the agent.
<jam> As for "wait until agent starts", isn't it enough to just put your script as starting after the ssh-agent script starts?
<jam> you could also use a script like
<jam> ps -efww | grep "ssh.*-L..."
<jam> to check if your process is running
<jam> and then add something into cron that checks
<jam> if [ssh-add -l] and not [ps -efww | grep "ssh.*-L..."]; then ssh ... -L
<jam> Though I might wrap the complex logic into a python script
<vila> jam: I need to use that from various OSes, so the ssh agent... is not well standardized :-/ But thanks for the hints (ssh-add -l may works everywhere)
<jam> vila: ssh-add is present under Cygwin...
<jam> and -l works here
<jam> and fails with an error if the ssh-agent isn't available, etc.
<vila> As for cron checking, I'm always a bit uncomfortable with scripts that starts again even if *I* stop them :-)
<vila> ssh-add -l works well on OSX too
<jam> vila: well, you just asked for it to restart if you drop a connection
<jam> cron works well for that
<jam> you can write your *own* cron replacement as a python script...
<jam> but blah
<jam> just create something like a "proc.no-autorun" or "proc.stop" file
<jam> and have that checked as well.
<vila> but cron is hard to stop or easy to forget to stop, I ran into the issue with my croned fetchmail (restarted every hour)
<vila> jam: thanks for your answer, I'm searching for something easier to setup (I can handle hacks but I want it to be easy for others), so all your advices are good but make me think there is no known and supported packaged solution :-/
<vila> jam: I think I'm more into #3 at http://www.debian-administration.org/article/SMTP_via_a_SSH_tunnel
<vila> aka special ssh private/public key without password and start at connection
<jam> vila: interesting thought. Though starting an ssh connection for each time you want to send an email seems a bit heavyweight
<jam> I suppose if you have a local MTA it would probably work quite well
<jam> since it would likely send things in batches.
<vila> jam: I have indeed a local MTA and for the other uses I don't mind establishing an ssh connection
<vila> but I want that connection to be established automatically :-)
<LarstiQ> vila, spiv: pqm success, so yeah the lp: url seemed to be the culprit
<nbauernf> Can anyone explain to me what might be going on with this:? $ bzr branch http://mc.pp.se/bzr/ps3sdk
<nbauernf> bzr: ERROR: Invalid http response for http://mc.pp.se/bzr/ps3sdk/: Unable to handle http code 501: Not Implemented
<mzz> nbauernf: works for me. Which bzr?
<nbauernf> mac osx
<Tak> I get the same result as nbauernf
<mzz> nbauernf: more interested in the version number :)
<nbauernf> v 1.16.1
 * Tak bzr 1.16.1
<mzz> huh, 1.16.1 here too. Got pycurl?
<mzz> (I think I don't, checking...)
<nbauernf> mzz: what can I do to reasonable check for pycurl?
<mzz> sec
<nbauernf> reasonably*
<Tak> same result after installing pycurl
<nbauernf> I'm able to checkout the http bzr repository of bzr
<nbauernf> i.e. this works:  bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
<mzz> ~/.bzr.log (or wherever that lives on your os) may be interesting
<Tak> http://paste2.org/p/307245
 * LarstiQ gets the 501 with bzr.dev
<LarstiQ> it almost sounds like that is intermittent
<nbauernf> I have the same problem as in Tak's paste
<Tak> is this an svn repo or a bzr repo?
<nbauernf> LartsiQ: I get it consistently with httphttp://mc.pp.se/bzr/ps3sdk/
<LarstiQ> Tak, nbauernf: do you have bzr-svn?
<Tak> yes
<nbauernf> I don't think I do
<LarstiQ> --no-plugins and it works
<Tak> interesting - I tried bzr+http and got a 404
<LarstiQ> nbauernf: `bzr plugins` will tell you
<nbauernf> yeah --no-plugins works
<nbauernf> Thanks!!
 * Tak also @ --no-plugins
<LarstiQ> nbauernf: mind filing a bug against bzr-svn?
<nbauernf> hmm this is the first time I've ever used bzr, but I don't mind if I can find the bug tracking system
<RenatoSilva> how do I run tests?
<mzz> RenatoSilva: bzr help selftest
<RenatoSilva> mzz: it's a plugin
<LarstiQ> nbauernf: http://bugs.launchpad.net/bzr-svn
<LarstiQ> RenatoSilva: same thing
<mzz> RenatoSilva: I am insufficiently bored to figure out how to run the tests specific to your plugin, sorry
<mzz> RenatoSilva: (also, I'd have to assume I'm correctly guessing this is still about xmloutput)
<LarstiQ> bzr plugins usually (and should, imnsho) have their testsuite run via bzr selftest
<LarstiQ> RenatoSilva: see -s and bp.xmloutput
<LarstiQ> if that is indeed the plugin you have in mind
<mzz> I think I just wildly guessed "bzr selftest xmloutput" would do something reasonable, and it did
<LarstiQ> mzz: it does
<RenatoSilva> mzz: I figured out that the plugin registers itself, I can run them with selftest <registered_name>
<mzz> this is often the case with bzr :)
<LarstiQ> mzz: -s bp.<pluginname> will restrict the tests to be loaded to that plugin
<RenatoSilva> mzz: yes, xmloutput, Guillermo asked me to write tests for my branch proposal, I'm trying to achieve this
<LarstiQ> so it's a bit quicker cycle if you're developing a plugin
<Pilky> anyone know if the developer(s) of bzr-eclipse come in here?
<RenatoSilva> LarstiQ: I'm sorry I'm new to bzr tests, I don't get what you said about -s and bp.*
<RenatoSilva> LarstiQ: I run the tests with bzr selftest <test_name>
<verterok> RenatoSilva: hi!
<RenatoSilva> there are some test failures
<RenatoSilva> verterok: hi, who are you :) ?
<verterok> RenatoSilva: Guillermo
<RenatoSilva> verterok: oh!
<RenatoSilva> verterok: nice to meet you
<verterok> RenatoSilva: nice to meet you too
<verterok> Pilky: shoot, I'll be around a bit
<LarstiQ> Pilky: verterok?
<Pilky> ah cool
<LarstiQ> RenatoSilva: `bzr selftest -s bp.xmloutput`
<RenatoSilva> verterok: as I said, I'm new to bzr tests...
<verterok> LarstiQ: heya! how are you?
<LarstiQ> Pilky: there are two Eclips projects though, the other is Nick Allen, who doesn't irc (much)
<RenatoSilva> LarstiQ: what does that command do?
<LarstiQ> RenatoSilva: so when you say `bzr selftest <pattern>` bzr loads _all_ tests, filters down to ones matching <pattern> and runs those
<Pilky> verterok: I'm just wondering how you guys get around the problems with authentication and getting progress information from push/pull/branch actions without using bzrlib
<verterok> RenatoSilva: I ussually do: BZR_PLUGINS_PATH=/path/to/branch/parent bzr selftest xmloutput
<LarstiQ> RenatoSilva: when instead you say `bzr selftest -s bp.<plugin>` it will only load the tests for that plugin.
<LarstiQ> RenatoSilva: on my hardware, that saves a couple of minutes
<LarstiQ> verterok: good, thanks :) Just been to EuroPython, adjusting again now
<Pilky> verterok: because I think I've got an idea that can let me use bzrlib and get around the GPL but it seems a tiny bit hackish so I was wondering if you guys had come up with anything
<LarstiQ> Pilky: have you talked with Martin Pool yet?
<verterok> Pilky: I basically lie a bit a about progress :)
<RenatoSilva> LarstiQ: I see, it could check if it's a plugin name and internally run the -s bp.
<Pilky> LarstiQ: yep, he basically said it is better to having something to show before they could consider anything about licences, but since I talked to him this morning I think I've come up with a way to get around licensing issues
<LarstiQ> RenatoSilva: eh, no
<verterok> Pilky: regarding auth there is a bug since the start, but bzr-eclipse only supports bzr+ssh if the user previously added the ssh key to an agent
<LarstiQ> Pilky: ah ok, good
<Pilky> verterok: right
<verterok> Pilky: what are you working on? :)
<Pilky> an Objective-C API for bzr
<RenatoSilva> LarstiQ: that -s xxx is hard to remember
<LarstiQ> RenatoSilva: the pattern is very useful for finer or wider grained matching
<Pilky> but I want it to be MIT licensed so non GPL projects can use it
<Pilky> as ultimately I want to write an MIT licensed GUI for bzr on the Mac
<verterok> Pilky: I'ld suggest using xmloutput, but it sucks compared to pure python :)
<Pilky> well, I have come up with a plan to allow me to use both
<Pilky> xmloutput is fine for stuff like logs, annotations etc
<Pilky> but pure python is better for push, pull etc
<Pilky> the only problem is the pesky GPL ;)
<verterok> Pilky: what about splitting the project into library and UI, once you have the library bits solved, you can try to fix the licensing issues
<verterok> Pilky: oh, linking... forget what I said :)
<Pilky> well I'm planning on doing the library first and then building the UI on top of it
<Pilky> but yeah, my idea might possibly help you as well
<Pilky> we can do the xmloutput thing and not have to GPL our code because you can talk to a separate binary that is GPLd without having to GPL your code
<Pilky> so my idea is, where I have to talk to bzrlib directly through python, create a separate binary
<Pilky> then use distributed objects from my main API to talk to that binary
<Pilky> the separate binary is GPL licensed
<Pilky> the main API is MIT licensed
<verterok> Pilky: I already found a very non-xml solution, you could use xmlrpc to pass python objects around, bypasing all the manual xml generation
<verterok> s/very/very nice/
<Pilky> hmm
<verterok> and you keep python on both sides
<RenatoSilva> verterok: about bug 393010: the message comes from server as python-like str encoded as utf-8, it is being parsed by KXML lib and returned to bzr-java-lib's log parser as latin-1, something like new String(msg_bytes, getWorkspaceEncoding()), instead of getXMLEncoding().
<ubottu> Launchpad bug 393010 in bzr-eclipse "Encoding problem in log view" [Medium,Triaged] https://launchpad.net/bugs/393010
<Pilky> verterok: well I'm planning on using PyObjC when I need to talk to python so I can convert the Python object to Objective-C fairly easily and vice versa
<LarstiQ> Pilky: did I already ask why you don't want to GPL your code?
<verterok> Pilky: the downside is the need to almost rewrite every commands
<Tak> it seems as though xmlrpc is still "linking"
<Pilky> LarstiQ: because GPL is a horrible licence for APIs
<LarstiQ> Pilky: I see what you mean, what API are you writing?
<verterok> RenatoSilva: uh, I think to remember a workaround I did some time ago, about wrapping all the xml in a xmlrpclib.Binary object
<Pilky> LarstiQ: an Objective-C "wrapper" for talking to bzr
<verterok> RenatoSilva: to work around the java-python encoding mismatch
<Pilky> so Mac developers can add support for bzr to apps such as text editors and such much more easily
<verterok> RenatoSilva: with the latest changes we worked in the last days, that might not be neccesary any more
<LarstiQ> Pilky: you think for this specific case the GPL is actually a hurdle?
<RenatoSilva> verterok: a possible workaround while KXML is not fixed is to get the message bytes again, and create a new String using utf-8 (or whatever macthes the commit message returned by the server)
<Pilky> LarstiQ: well, yes as if a library is licensed under the GPL then linking to it requires the linking application to also be GPL
<Pilky> if it was LGPL it wouldn't be too much of an issue
<LarstiQ> Pilky: yes, that is theory though
<verterok> RenatoSilva: all the xml is sent inside a Binary, so it's hidden from kxml
<Pilky> theory and also what the license says ;)
<LarstiQ> Pilky: yes :P
<Pilky> plus the minute I put "GPL" on the licence for the product lots of developers run for the hills ;)
<LarstiQ> Pilky: but so far there are very little people wanting to integrate bzr in their application
<verterok> RenatoSilva: I think the missing  bit is the conversion to the correct encoding in the Java side
<LarstiQ> Pilky: anyway
<Pilky> LarstiQ: true, but that is partly due to the fact that bzr isn't quite as popular as git on the Mac
<Pilky> and the fact that svn is currently the easiest to integrate into an app
<goundy> Hi.
<LarstiQ> Pilky: no, I mean, overall, anywhere
<goundy> How to remove a file from source control ? thank you.
<LarstiQ> Pilky: right
<LarstiQ> goundy: `bzr rm`
<goundy> LarstiQ, bzr rm deletes the file from the hard drive :/
<goundy> I just want to kick it from source control
<verterok> goundy: bzr rm --keep
<goundy> verterok, thank you very much
<LarstiQ> Pilky: anyway, if your current plan doesn't pan out, you could write your wrapper, license it under the GPL, and lobby to get bzr relicensed, and relicense when that goes trhough.
<goundy> LarstiQ, thank you too
<RenatoSilva> verterok: maybe KXML is just returning a new String(msg_utf8_bytes). As they probably use Linux, they didn't get any error. However in my case, Java preferred encoding is not UTF-8 but latin-1 (cp1252), so that it tries to decode the bytes as latin-1 and then I see the wrong chars. KXML should explicitly specify the encoding for the string.
<LarstiQ> Pilky: as from my pov it will be useful even if not MIT licensed
<LarstiQ> goundy: also see `bzr help rm`
<goundy> thanks ! :)
<goundy> See you
<Pilky> LarstiQ: well hopefully my plan will pan out, though it'll take a while as I'll only be working on it a day or two a week, got the day job to work on the rest of the week ;)
<LarstiQ> RenatoSilva: eh? If not otherwise specified isn't the xml encoding always utf8?
<LarstiQ> Pilky: aight
<Pilky> I'm hoping to have the API in a fairly usable state by the end of summer
<verterok> RenatoSilva: do you have the bzr-java-lib sourcecode?
<RenatoSilva> verterok: do you mean it's not KXML who is parsing the server CDATA and creating the corresponding bytes?
<RenatoSilva> verterok: not in hand
<verterok> RenatoSilva: yes, little and dirty hack :p
<verterok> RenatoSilva: let me find you the url, but the file is: src/main/java/org/vcs/bazaar/client/xmlrpc/internal/XMLRPCCommandRunner.java line 161
<verterok> RenatoSilva: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/head%3A/src/main/java/org/vcs/bazaar/client/xmlrpc/internal/XMLRPCCommandRunner.java
<verterok> RenatoSilva: by default it's doing new String(result.getBinary(1))
<verterok> RenatoSilva: but that method should be deprecated for the one in line 161
<RenatoSilva> verterok: public String getStandardOutput(final String charsetName)?
<RenatoSilva> verterok: it was not running in my debug session
<RenatoSilva> verterok: And I was running it very times
 * RenatoSilva was disconnected
<verterok> RenatoSilva: the base COmmand class use public String getStandardOutput() by default
<Peng_> RenatoSilva: You didn't miss anything.
<verterok> RenatoSilva: I think that we should change that to: public String getStandardOutput(final String charsetName)
<RenatoSilva> verterok: I was talking about this line: http://bazaar.launchpad.net/%7Everterok/bzr-java-lib/bzr-java-lib/annotate/head%3A/src/main/java/org/vcs/bazaar/client/commandline/parser/XMLLogParser.java#L123
<RenatoSilva> verterok: parser.nextText() is KXML
<RenatoSilva> verterok: it is returning a String (in python it's like an u'')
<RenatoSilva> verterok: with wrong chars...
<verterok> RenatoSilva: yes, I think it's because the string parsed by kxml is the one returned by Command.getStandardOutput
<verterok> RenatoSilva: and Command.getStandardOutput don't specify any charset, so I think Java is using the default one
<verterok> RenatoSilva: this line: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/195.2.11/src/main/java/org/vcs/bazaar/client/commandline/CommandLineClient.java#L317
<verterok> RenatoSilva: My guess is that the xml log parser is receiving a bad string, and so the nextText() call is returning that
<RenatoSilva> verterok: I checked it out, the message in server response is something like <![CDATA[Ma\xc3\xa7\xc3\xa3]]> encoded as base64, but parser.nextText is not decoding from UTF-8. As I said, KXML (or something in the call hierarchy) should be doing something like new String(bytes) (which decodes from UTF-8 for the developers) instead of new String(bytes, "UTF-8") (which explicitly decodes from UTF-8 all the time)
<verterok> RenatoSilva: that should be in the line I just pointed out, just before passing the stdout string to the XMLLogParser
<verterok> RenatoSilva: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/195.2.11/src/main/java/org/vcs/bazaar/client/commandline/CommandLineClient.java#L317
<RenatoSilva> verterok: comparing to python... imagine you received the utf-8 bytes from server: 'Ma\xc3\xa7\xc3\xa3'
<verterok> RenatoSilva: I'm missing something?
<RenatoSilva> verterok: it's like nextText() is returning a 'Ma\xc3\xa7\xc3\xa3'.decode('latin-1') or .decode() (from prefered encoding)
<verterok> RenatoSilva: hmm, weird, I must debug it, but I believe you :)
<verterok> RenatoSilva: kxml is doing: new String(bytes)
<RenatoSilva> verterok: put a breakpoint in the line I mentioned, you'll see that the string is already wrong in that point, check also the server response. It was a bit hard to me as it comes into an InputStream. I had to hunt the buffer (is isnisde is inside is...), then I put the bytes in a Java test file and decoded. As it is base64, then I run python and decoded the response, Then I got the XML with the mentioned CDATA.
<RenatoSilva> verterok: do you have kxml source? ok, just like I imagined...
<verterok> RenatoSilva: yes, maven do all kind of neat tricks ;)
<verterok> RenatoSilva: I'm fireing up eclipse, to start the debug session, give me a few minutes :)
<RenatoSilva> verterok: ok, just to point it out for a possible fix in KXML: I don't know how can it guess the CDATA encoding, as it is pure ascii...
<verterok> RenatoSilva: I don't think it's kxml job to do that, bzr-java-lib should know what to do with those bytes
<RenatoSilva> verterok: ok I just think it's a bit weird to decode, then encode, then decode again, but ok...
<verterok> RenatoSilva: agreed!
<RenatoSilva> verterok: in this case bzr-java-lib should somehow know what is the encoding of such CDATA
<verterok> RenatoSilva: what do you suggest?, not encoding at all in the xmloutput side?
<verterok> RenatoSilva: as you mentioned in one of the bugs
<verterok> RenatoSilva: we could send all utf-8 encoded data over "the wire"
<RenatoSilva> verterok: I think that static encoding may be better. In this case, you can trust that the CDATA is always UTF-8
<LarstiQ> who is producing the CDATA?
<verterok> RenatoSilva: that's the way it should be working today, at least in 0.8.4 utf-8 is hardcoded in the xmlrpc server
<verterok> LarstiQ: bzr-xmloutput
<verterok> LarstiQ: actually, the xmlrpc server in bzr-xmloutput
<RenatoSilva> verterok: you mean just the preamble right?
<LarstiQ> verterok: ok, from what source? bzr historical data, or also files on disk?
<verterok> RenatoSilva: the stdout encoding is changed to utf-8
<verterok> LarstiQ: both
<NfNitLoop> *siiiiiiigh*  reading all the caveats to svn 1.5 merging makes me miss bzr. :)
<LarstiQ> verterok: ah, that complicates matters a bit
<LarstiQ> NfNitLoop: you don't have to ;)
<RenatoSilva> verterok: because it's always utf-8, but the actual data is the terminal encoding. This way when I run bzr xmlstatus I get a header <?xml ... encoding="utf8"?> but the data itself is cp850...
<RenatoSilva> LarstiQ: btw, does bzr stores its metadata always as UTF-8?
<NfNitLoop> LarstiQ: Unfortunately I do.  I don't think bzr-svn handles some of the SVN features we're relying on.
<verterok> RenatoSilva: that was a bug, when running xmlstatus from the terminal, I pushed a branch to fix that (utf-8 was hardcoded in the preamble)
<verterok> RenatoSilva: the xmlrpc service is a different story :)
<verterok> RenatoSilva: take a look to the decorator defined in line 87 of service.py,
<LarstiQ> RenatoSilva: yes.
<LarstiQ> NfNitLoop: ah, which would that be?
<RenatoSilva> verterok: so when you said it was always using utf-8, it was just the header right?
<verterok> RenatoSilva: the commands executed via xmlrpc are executed, with  utf-8 as the user encoding, and stored in a StringIO instead of redirecting the stdout output
<verterok> RenatoSilva: the idea is to always use utf-8 in the xmlrpc calls
<RenatoSilva> verterok: oh I didn't understand that part, I'm sorry. I just noticed that the final result I receive is variable encoding...
<verterok> RenatoSilva: the utf-8 is set as the user encoding when the xmlrpc server starts, in the serve_forever() method, service.py line 74
<RenatoSilva> verterok: you mean to decode client commands?
<verterok> RenatoSilva: for all other operations that use osutils.get_user_encoding()
<verterok> RenatoSilva: the osutils._cached_user_encoding and bzrlib.user_encoding are updated
<RenatoSilva> verterok: and how the response gets its encoding changed? (as I said, I receive cp850 data)
<verterok> RenatoSilva: that's the weird part, looks like a bug in service.py
<RenatoSilva> verterok: if it's always using utf-8, I should receive utf-8, but I receive cp850
<RenatoSilva> verterok: oh...
<verterok> RenatoSilva: you could easily test this wihtout putting bzr-java-lib in the middle, there is a client.py file in the xmloutput tree to call the xmlrpc service via python
<verterok> RenatoSilva: a lot easier to debug ;)
<RenatoSilva> verterok: well, somewhere it is getting the terminal encoding ont the one you had set when starting the server...
<verterok> RenatoSilva: you could check what's the encoding of the data inside the Binary Blob using a slightly modified client.py
<RenatoSilva> verterok: humm wait a minute, I receive variable encoding in terminal!
<verterok> RenatoSilva: looks like that might be the cause
<RenatoSilva> verterok: I'm sorry, in terminal no xmlrpc call is involved
<verterok> RenatoSilva: right
<verterok> RenatoSilva: the xmlrpc service is a different world
<RenatoSilva> verterok: so in the server you make xmloutput think that it has an utf-8 terminal, and so you receive data as utf-8....
<verterok> RenatoSilva: that's the idea, and I replace sys.stdout in order to catch all the output
<LarstiQ> that is a bit iffy
<RenatoSilva> verterok: well, if the server certaintly is always returning utf-8, you could safely do new String(parser.nextText(), "UTF-8")
<LarstiQ> verterok: is this because you're calling cmd_ classes?
<verterok> LarstiQ: I know.. it's a hack
<verterok> LarstiQ: exactly
<verterok> LarstiQ: the idea is to stop calling bzr commands, and call exposed methods via xmlrpc
 * LarstiQ nods at verterok 
<verterok> LarstiQ: the xmlrpc service is in the middle of a transition, it's just a band aid to workaround the slow startup
<LarstiQ> verterok: aye :/
<verterok> RenatoSilva: now I need to make sure that's true...but for that I need my windows vm...sadly I can take a loook to it tomorrow, as I;m not in my home (the VM is in my desktop :p )
<RenatoSilva> verterok: or instead of hard-coded "UTF-8", the server response itself could have some element or attribute to tell the right encoding of the python-like strings inside the CDATAs (something like python_str_encoding="UTF-8" or "XML" (indicating that it's the same as the xml itself))
<verterok> RenatoSilva: that's a good idea :)
<verterok> RenatoSilva: first I want to make sure the xmlrpc service is actually sending all the info in one encoding...to be sure from where I should get the encoding it's using
<LarstiQ> verterok: couldn't you change your terminal encoding in !win32 to test?
<verterok> LarstiQ: I'ld love to know how to do that in linux :)
<verterok> LarstiQ: what'do you know what's the *nix equivalent of cp??? encodings?
<verterok> s/what'//
<LarstiQ> verterok: export LC_ALL=C will probably already trip things up
<LarstiQ> verterok: if not, you can pick a non-utf8 locale
<verterok> LarstiQ: ack, thanks!
<LarstiQ> verterok: say nl_NL@euro
<LarstiQ> verterok: (LC_ALL should be enough, but if not, be a bit more brute with the variables from `locale`)
<RenatoSilva> verterok: I will update the log view bug later...
<verterok> RenatoSilva: ok, thanks!
<RenatoSilva> verterok: what about the tests for teh emrge proposal? I'm not familiar with writing them :(
<verterok> RenatoSilva: ok, don't worry I'll try to write a test for it
<RenatoSilva> verterok: ok I'll try too, if it's not good you reject it...for services it may be easy, but for xml info it's a big file...I'll take a look anyway
<RenatoSilva> verterok: thanks for helping!
<verterok> RenatoSilva: it should be a simple test, about passing url with unicode names, etc. not a test for each command :)
<verterok> RenatoSilva: thanks you, for digging into this and help me out!
<RenatoSilva> thank you too
<blueyed> What's the best way to check (from a shell script), if a file is under bzr control?
<Peng_> blueyed: "bzr st" on it, maybe?
<verterok> blueyed: take a look to: bzr ls --versioned
<blueyed> Peng_: yes, makes sense. unfortunately the return code does not indicate an error.
<blueyed> verterok: well, I have a given file and want to check if bzr knows about it.
<blueyed> bzr ls only lists current directory.
<Peng_> "bzr inventory" lists everything, but it's a bit evil to do it that way.
<verterok> blueyed: there is a --recursive but as Peng_ said, it's a bit evil
<blueyed> bzr st, with grepping for error might work.
<verterok> blueyed: there is the 'bzr file-id' hidden command
<Peng_> I just ran a quick test. For a file that wasn't versioned, "bzr st" exited with 3. For one that was versioned an unchanged, it was 0.
<Peng_> Oh, that's a good idea.
<blueyed> Peng_: bzr st exits with 0 for an non existant file.. (1.16.1)
<blueyed> verterok: bzr file-id exits with error 3. great.
<Peng_> blueyed: I'm on bzr.dev. Huh!
<mwhudson> good morning
<mwhudson> jelmer: ping
<jelmer> mwhudson: pong
<mwhudson> jelmer: did you look at that python2.4 crash bug at all?
<RenatoSilva> how do I assertNoExceptionIsRaised?
<Peng_> Isn't that what tests do by default?
<Peng_> That's like doing "try: ...; except: raise".
<RenatoSilva> how to avoid output?
<RenatoSilva> I don't want the commands I'm running to print to stdout...
<Peng_> Eh? What commands? Where?
<RenatoSilva> Peng_: http://pastie.org/536241
<RenatoSilva> Peng_: last command
<Peng_> Ehh, I don't know anything.
<RenatoSilva> Peng_: is it the pratice to let them write out to output?
<Peng_> < Peng_> Ehh, I don't know anything.
<RenatoSilva> Peng_: I 'd want just to see 'passed'
<RenatoSilva> Can anyone suggest me a dummy command containing a non-ascii string?
<jelmer> mwhudson: not really yet, sorry
<mwhudson> jelmer: ok
<mwhudson> jelmer: any ideas on where it's likely to be?
<jelmer> mwhudson: I'm in .ie on vacation atm so my response times may be a bit slow the next couple of days
<mwhudson> jelmer: ok
<RenatoSilva> someting like bzr branch lp:xxx MaÃ§Ã£, but easy to set up inside a test
<jelmer> mwhudson: no idea when I'll have a look exactly, depends on whether I can find a spare moment when I get back at the airport, etc
<mwhudson> jelmer: it's a race between you and whoever is working on getting launchpad running on python 2.5 then :)
<RenatoSilva> oh, bzr init :)
<jelmer> mwhudson: :-)
<jelmer> mwhudson: I'm quite sure it's a bug in subvertpy btw, since that's the only part of the code that actually has C extensions and could reasonably crash
<RenatoSilva> but I need to delete the folder...no no... bad option....I want something simpler
<mwhudson> jelmer: fair enough
<LarstiQ> RenatoSilva: hmm?
<verterok> RenatoSilva: take a look to the xmllog tests, I think there are encoding related tests
<NfNitLoop> LarstiQ: re: SVN use cases -- we're making lots of use of svn:externals
<NfNitLoop> (sorry, was AFK at a meeting)
<RenatoSilva> verterok: currently I'm trying the custom_commands_main ...
<verterok> RenatoSilva: I think that passing the raw str should be enough to test your fix, right?
<LarstiQ> NfNitLoop: right, that is a bit of a sore spot. Have you looked at lp:bzr-scmproj?
<verterok> RenatoSilva: like, 't\xc3\xba' that's tÃº in UTF-8
<verterok> RenatoSilva: but in whatever encoding you want to check
<NfNitLoop> LarstiQ: Haven't even heard of it till just now, I'll take a look.
<jelmer> mwhudson: btw, do you happen to know what eventually was decided about nested trees?
<mwhudson> jelmer: no, not really
<LarstiQ> jelmer: not being hindered by knowledge of the facts, afaik no decision has been reached
<jelmer> LarstiQ: so I guess that implies it's all going to be 3.0+
<jelmer> ?
<LarstiQ> jelmer: I'd really have to actually read something before trying to answer that
<NfNitLoop> LarstiQ: Aah, scmproj sounds cool.  Unfortunately, what I need to manage is merging svn:external properties.  (Fun, right?) :p
<jelmer> LarstiQ: last I heard (at UDS) spiv and abentley were working on dealing with the concerns raised
<LarstiQ> NfNitLoop: *blink*
<RenatoSilva> verterok: http://pastie.org/536241 (f.type is wrong, I'm trying to get the right attribute for the id)
<jelmer> NfNitLoop: scmproj doesn't help in that regard unfortunately
<LarstiQ> NfNitLoop: you people do _what_? ;P
<NfNitLoop> LarstiQ: It sounds crazier than it is...
<NfNitLoop> and it's a hell of a lot better than the system it replaced.
<verterok> RenatoSilva: are you trying to catch an xmlrpc exception? or a bzr specific error?
<NfNitLoop> We use a SVN repo full of svn:externals to deploy our (PHP) code to our servers in EC2.
<NfNitLoop> we're going to have a branch of that for our staging environment.
<NfNitLoop> when we are ready to launch staging to prod, we'll merge the changes to the externals into our prod repo.
<NfNitLoop> It's... very meta. :p
<NfNitLoop> (i.e. NOT something I would expect any other tools to support.)
<LarstiQ> right. imnsho that is abusing vcs for deployment
<RenatoSilva> verterok: catch the custom_command_main exceptions, it raises a Fault for UnicodeEncodeError
<NfNitLoop> LarstiQ: It is.
<NfNitLoop> But, did I mention that it's still *waay* better than our previous system? :)
<LarstiQ> NfNitLoop: yes, you did :)
 * LarstiQ goes to bed
<NfNitLoop> The upshot is that it's always trivial to make sure that our production environment(s) haven't diverged from a known code state.  Which, unfortunately... happens.
<RenatoSilva> verterok: I think I'll need to change the code itself a bit to raise the unicode error...
<RenatoSilva> verterok: can I put any code into the fault code?
<verterok> RenatoSilva: try doing a print dir(t)
<RenatoSilva> verterok: ?
<verterok> RenatoSilva: 42 is bzr specific error code
<RenatoSilva> verterok: and 32?
<verterok> RenatoSilva: all other non-bzr errors
<RenatoSilva> verterok: what about not wrapping the error with fault? If it is UEE, then I just raise it
<RenatoSilva> verterok: If I should use the Fault, then what code do I fill for UEE?
<davidstrauss> What's the difference between a "bound branch" and a normal, heavyweight "checkout"?
<verterok> RenatoSilva: it will be wrapped in a Fault, as it's a client/server talk
<dash> davidstrauss: one difference
<dash> oh wait
<dash> no, those are the same thing.
<davidstrauss> dash: That's why I thought.
<verterok> RenatoSilva: I think 32, but this is just a way to note the error is from the bzr command or a bug/server side error
<davidstrauss> But why does bzr explorer show a tab for each?
<davidstrauss> dash: This suggests they're not the same thing: http://bazaar-vcs.org/DraftSpecs/SimpleCheckouts
<dash> davidstrauss: Oh hmm
<dash> i'm not gonna think about that lest it complicate my understanding of the world
<verterok> RenatoSilva: you can get the code with: t.faultCode
<verterok> RenatoSilva: you can get the code with: f.faultCode
<RenatoSilva> verterok: yeah I've found it, but I did with raising a raw exception, see: http://pastie.org/536241. How about it?
<verterok> RenatoSilva: using the code you pasted prviously, and using f.faultString I get the xml with the error: <?xml version="1.0" encoding="UTF-8"?><error><class>UnicodeEncodeError</class><dict></dict><message>'ascii' codec can't encode characters in position 2-3: ordinal not in range(128)</message></error>
<verterok> RenatoSilva: and how is the UnicodeError handled?
<verterok> RenatoSilva: e.g: a client send bad encoded args, what should the client expect in order to hanlde the error?
<RenatoSilva> verterok: in main code?
<verterok> RenatoSilva: in the client side
<RenatoSilva> verterok: you mean we must send a Fault?
<lamalex> Has anyone here given a talk on bzr at a lug or something similar? I'm giving on in two weeks, was wondering what other people talked about in theirs
<RenatoSilva> verterok: I'm sorry could you explain better
<RenatoSilva> verterok: humm maybe something's wrong with my test
<verterok> RenatoSilva: look how the error are wrapped in XMLError(e), when client get a xmlrpc Fault with f.faultString containing the xml version of the exception
<RenatoSilva> verterok: does Fault objects contain the exception object involved?
<verterok> RenatoSilva: an xml version of the exception
<RenatoSilva> verterok: only?
<RenatoSilva> verterok: that's hard, I'd have to parse it...
<verterok> RenatoSilva: yes, if you look at the definition of XMLError, it's just a way to serialize an exception to xml
<RenatoSilva> verterok: I'm thinking of a better way to describe the test...
<RenatoSilva> verterok: how about http://pastie.org/536241
<verterok> RenatoSilva: looks good!, also you can check for an specific regexp in f.faultString
<RenatoSilva> verterok: self.assertEquals...
<RenatoSilva> verterok: yeah, regex...
<verterok> RenatoSilva: e.g: self.assertContainsRe(f.faultString, 'UnicodeEncodeError')
<RenatoSilva> verterok: when I remove the if isinstance(a, str) test in main code, the test fails, when not it passes ok
<verterok> RenatoSilva: yay! :)
<RenatoSilva> verterok: a minute please...
<RenatoSilva> verterok: what now: http://pastie.org/536241
<verterok> RenatoSilva: looks good, but the test should fail if you get a Fault...that means something else is completely broked
<verterok> RenatoSilva: so, the previous self.assertEquals(21, f.faultCode) was ok
<RenatoSilva> verterok: it does not test the whole method, just the encoding handling :)
<RenatoSilva> verterok: test_custom_commands_main_unicode_handling
<verterok> RenatoSilva: agreed, but "fail early" is good ;)
<jam> poolie: if you wake up and want to chat, please call my cell phone
<RenatoSilva> verterok: not always teh test should fail if you get a Fault
<verterok> RenatoSilva: in this case, if you are calling an existing command it should fail :)
<RenatoSilva> verterok: if you give it a wrong value, you expect a Fault, and therefore everything is ok and the test must pass
<verterok> RenatoSilva: but it's good for me
<RenatoSilva> verterok: this test runs a bzr log MaÃ§Ã£, where MaÃ§Ã£ is not a branch, whcih will raise a Bzr error, that's why we can't use assert to fault code
<verterok> RenatoSilva: so, if you like the later, I'm ok with it
<verterok> RenatoSilva: ok, good point :)
<RenatoSilva> verterok: I'll let you write the other tests custom_commands_main ok? :)
<verterok> RenatoSilva: sure thing, thanks a lot!
<RenatoSilva> verterok: ok I need to eat something, I can't push stuff to lp at work, I'll save this test and push later at home, I'll try to take a look for the other issue (non-ascii URLs) too...
<verterok> RenatoSilva: ok, thanks again! Bom apetite!
<RenatoSilva> verterok: thank you too, see you
<jml> spiv, ping
<lifeless> hai
#bzr 2009-07-07
<jml> lifeless, hello :)
<spiv> jml: pong
<spiv> jml: how was EuroPython?
<jml> spiv, it was great :)
<jml> spiv, I just sent my trip report to warthogs & am about to send my Bazaar sprint report
<jml> spiv, regarding the --allow-writes patch. I'm thinking of marking the bug as wontfix, you filed the original bug IIRC -- what do you think?
<jelmer> 'evening spiv, jml
<jelmer> spiv: Do you perhaps know what the state/plans for nested trees is?
<jml> jelmer, g'day.
<spiv> jml: I did?  I vaguely thought it was poolie...
<jml> spiv, you are right.
<jml> and I am daft.
<spiv> jelmer: morning :)
<spiv> jelmer: abentley's was working on addressing the various concerns people had, the details of that are in his devnotes branch I think.  It certainly won't make 2.0, but given that abentley has a fair bit of code already and the design questions are largely worked out it's hopefully not too far into the future.
<spiv> It probably depends on abentley's other priorties more than anything else...
<jelmer> spiv: ah, ok - thanks
<spiv> spm: ping; where did we get to with lp: URLs and bzr's PQM?
<spiv> spm: (it's still not working)
<poolie> hello
<poolie> hello jml, welcome back
<poolie> i think regarding --allow-writes there is still an issue there that should be addressed
<poolie> but
<poolie> perhaps not in the way recommended by the bug
<poolie> how about just giving a warning if it's used in --serve mode/
<poolie> i mean, in non-inetd mode
<jml> poolie, yeah. I've reverted the bug back to 'Triaged'.
<jml> poolie, that sounds fine to me. Simple & to the point.
<poolie> did you pick this because it looked easy, or was there some stronger motivation?
<SpamapS> I want to make a copy of my current working copy and then revert so I can build the old version.. can I just 'cp -arf working working2' and then 'bzr revert' in working, and still keep my local changes in working2?
<poolie> yes
<lifeless> you can also branch and then use 'bzr merge --uncommitted'
<lifeless> jml: bug 307166
<ubottu> Launchpad bug 307166 in bzr "bzr fails when attempting to fetch branch using lp:" [Undecided,New] https://launchpad.net/bugs/307166
<lifeless> jml: I'm curious why you removed the launchpad tag?
<jml> lifeless, because I didn't read the stack trace.
<jml> lifeless, and reading only the error, I assumed that the OP mistook a general network error for a Launchpad-specific thing.
<jml> In any case, it's a dupe of a bug I just fixed.
<lifeless> cool
<lifeless> what about bug 216924
<ubottu> Launchpad bug 216924 in bzr ""bzr push lp:" on windows leads to socket.sslerror traceback." [Undecided,New] https://launchpad.net/bugs/216924
<jml> wow, untriaged bugs starting with 2
<jml> lifeless, do you think it's a bug in the lp plugin?
<lifeless> yes
<lifeless> the backtrace shows its the lp plugin calling xmlrpclib
<lifeless> its got nothing to do with ssh
<jml> you think the plugin should catch that error and... ?
<lifeless> I think we should determine the root cause
<lifeless> my gut says its a dup of the 'lp plugin does not honour proxy settings'
<lifeless> bug
<lifeless> what does the 'launchpad' tag mean to you?
<jml> bug in the launchpad plugin
<lifeless> to me it means 'fixing this bug will make life easier/nicer for users of bzr with launchpad
<jml> I see.
<poolie> to me just 'related to launchpad'
<lifeless> the lp plugin is just 'code that is unique to working with lp'
<lifeless> not the entire set of related to lp
<lifeless> jml: I'm tagging that launchpad again
<jml> lifeless, ok
<lifeless> jml: because you can only get that error using lp:
<lifeless> as only lp: uses xmlrpc
<jml> lifeless, fair enough.
<jml> lifeless, re: "the lp plugin is just 'code that is unique to working with lp' not the entire set of related to lp" -- yes that goes without saying, what's your point?
<lifeless> jml: my point is that the tag, and experience is broader than the plugin
<jml> lifeless, I'd kind of like a way of saying "this bug affects the launchpad plugin".
<lifeless> jml: why?
<jml> lifeless, but I guess that the space of bugs related to launchpad more generally isn't big enough for that to help
<poolie> jml, i've read your trip report, if you want to chat just give me a call
<mwhudson> hey guess what
<mwhudson> lrucache isn't thread safe
<jml> lifeless, because it matches my mental model of the world :)
 * mwhudson really really should not have made that mistake :/
<poolie> :/
<poolie> mwhudson: there's not really any promise that any bzr class is thread safe
<mwhudson> poolie: yes, i know
<poolie> and in general making single classes threadsafe can be an antipattern
<poolie> k
<mwhudson> a failure to think straight on my part
<lifeless> jml: you'd need to explain your model then.
<lifeless> we're threadsafe like the C++ STL is
<lifeless> which is to say, we're safe for a single thread :)
<fullermd> Threadsafe, not threadSsafe   :p
<mwhudson> "not conspicuously stupid about it"
<jml> abentley, bundlebuggy appears to be down
<abentley> jml: restarted
<jml> abentley, thanks.
<poolie> jml, i filed bug 396335
<ubottu> Launchpad bug 396335 in bzr "want a deb that adds the bzr ppa and keys" [Low,Confirmed] https://launchpad.net/bugs/396335
<lifeless> poolie: uhm
<lifeless> poolie: I don't know if you are aware but there are a bunch of other approaches for that
<lifeless> that don't need maintenance in the same way
<poolie> i know there's various efforts to have a systematic way to add/remove ppas
<poolie> this bug is kindof a workaround for the lack of them
<poolie> what kind of maintenance are you talking about though?
<lifeless> two things mainly
<lifeless> one is that the deb is introducing static data, so it has to be at least a little careful because users may remove the data without removin the deb
<lifeless> and the other is that the keys it adds are static
<lifeless> but archive keys are often rotated
<poolie> really?
<lifeless> and even if lp isn't rotating ppa keys today, I fully expect it will have to at some point
<lifeless> (it being whatever deb is created)
<poolie> for values of often = never :)
<poolie> well,
<lifeless> ubuntu and debian archive keys are rotated
<poolie> if they start doing that, they'll have to work out some some solution for the thousands of people who've manually added the keys now
<jml> wow.
<jml> just came across the first time I've ever wanted to sort bugs by id
<lifeless> jml: thanks for the slides; looks like you created a really good narrative
<jml> lifeless, my pleasure.
<jml> btw, I just came across this bug: https://bugs.edge.launchpad.net/bzr/+bug/183831
<ubottu> Ubuntu bug 183831 in bzr "bzr add <softlink> follows the link" [Undecided,Confirmed]
<jml> it has a patch that hasn't been responded to.
<jml> the author of the patch asked me about it at EuroPython, I think.
<RenatoSilva> How do I unpush?
<lifeless> push --overwrite -r -2
<lifeless> or whatever is the right revision
<RenatoSilva> I pushed a new revision, I want to uncommit and push the revision again to lp
<RenatoSilva> lifeless: thank you!
<lifeless> or if you have a new revision locally, just push --overwrite
<RenatoSilva> lifeless: ?
<RenatoSilva> lifeless: pushed revision was 130...
<RenatoSilva> lifeless: I uncommited, commited again (a new 130)
<RenatoSilva> lifeless: if worked without specifying the rev number
<RenatoSilva> *it
<lifeless> yes
<lifeless> the rev number is when you want to specify a rev other than  tip
<lifeless> --overwrite is all that is needed to force the push
<RenatoSilva> lifeless: thank you
 * spiv -> lunch
<RenatoSilva> When a bug is invalid for a project, but there's a watch in the project for a external bug, what does this mean?
<lifeless> it means the bug is recorded in  two places
<RenatoSilva> I mean it's like the bug itself is invalid
<lifeless> I'm not sure what you mean
<lifeless> but perhaps an example would help
<RenatoSilva> lifeless: in bug 388300, Eclipse was checked as invalid, however I reported it initially as general error "bzr-eclipse does not work with accented paths"
<ubottu> Launchpad bug 388300 in bzr-xmloutput "Encoding problems in xmloutput: non-ascii URLs and unchecked string decodings" [High,Confirmed] https://launchpad.net/bugs/388300
<RenatoSilva> lifeless: now we know it's an xmloutput issue, but the external bug may also be affecting bzr-eclipse
<RenatoSilva> lifeless: eclipse was marked as invalid, because the title changed...that's ok, I just wonder if I should generalize the title again (and change eclipse's invalid status), or either open a new bug pointing to that bug
<RenatoSilva> to the eclipse external bug
<lifeless> RenatoSilva: if changes are needed to eclipse to close the bug
<lifeless> RenatoSilva: then it would be appropriate for a task to be open (not invalid) on eclipse
<lifeless> however the external bug is marked resolved
<lifeless> perhaps the external link needs to be updated
<poolie> jml, any reason you're using BB rather than lp reviews?
<poolie> i hear they're rather good :)
<jml> poolie, well, I'm not really.
<poolie> oh, i just thought i saw one from you
<poolie> also, maybe you shoud send your report somewhere else too
<jml> poolie, yeah, that was an RFC patch
<poolie> like a europython list?
<jml> poolie, I guess I could have used a merge proposals
<jml> but I hoped I'd get responses more quickly on the ML
<jml> I guess I was wrong
<poolie> mm
<jml> good idea re forwarding
<RenatoSilva> lifeless: it's just about organizing the issues, maybe it's better to create a new bug
<lifeless> RenatoSilva: I don't know
<RenatoSilva> lifeless: is is resolved as duplicate of another bug (also watched in lp bug)
<poolie> jeez i'm sick of launchpad repeating the bug description in the first bugmail
<RenatoSilva> lifeless: most of bug content is about xmloutput, eclipse's bug is a little part
<jml> poolie, yeah.
<lifeless> I don't mind it being included
<lifeless> it helps when you are added to an already inflight bug
<poolie> it's provably stupid when it's including *the exact same text* twice
<poolie> ffs
<poolie> seriously
<lifeless> oh, I haven't noticed that
<poolie> sending you the description when you're added to a bug would be useful i agree
<poolie> and even when i have 'include bug descriptions' turned off
<poolie> </grump>
<poolie> going back to reconfigure
<poolie> lifeless: in the context of unstacking
<poolie> at the moment unstacking fails with revisionnotfound if you have any tags pointing to not-present revisions
<poolie> this should probably not happen...
<lifeless> I think fetch is still broken wrt that case
<poolie> at any rate it should be consistent with branch, which seems to only copy things referenced in the branch
<poolie> it looks like fetch makes no effort to copy the revs referenced by tags?
<lifeless> thats right; there is a bug open on that
<lifeless> ciao
<spiv> Woah, "repo.add_inventory(...)" on a stacked gc repo is adding the inventory to repo's fallback, not repo.
<spiv> Hmm, something is weird here.
<vila> spiv: isn't the fallback read-only ?
<vila> err, Hi all ! :)
<spiv> Hmm, or it's just the way I'm introspecting the vf that's the issue.
<poolie> hello spiv
<poolie> hello vila, spiv
<poolie> spiv, how's stuff?
<jml> is https://bugs.edge.launchpad.net/bzr/+bug/393349 a dupe of something deeper?
<ubottu> Ubuntu bug 393349 in bzr "exceptions.AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'" [High,Triaged]
<poolie> probably
<jml> poolie, spiv, vila: could one of you please review https://lists.ubuntu.com/archives/bazaar/2009q3/060202.html
<jml> it's one of the patches from the sprint.
<vila> I think spiv is the usual suspect here :)
<spiv> poolie: alright, that stacking cross-format test is passing finally.  I'm just trying to figure out why more mundane (pack-0.92 to pack-0.92, for instance) tests are failing, which I only just noticed after fixing the stacking bug.
<spiv> jml: heh, coincidentally I updated my bzr-ping plugin to report that just a few days ago.
<spiv> Aah, ghosts.  I see the bug.
 * spiv fixes
<spiv> Ok, just one failing test left.
<spiv> Well, 1 x every format :)
<spiv> Weird, only one format fails when I run just those tests.
<lifeless> spiv: global state
<spiv> lifeless: you'd think so, but it turns out be pebkac (well, that and test names that are very similar to the eye, particuarly in the rather noisy output of multiple test failures) :)
 * spiv exhales and pushes the branch with all interrepo and fetch tests passing, finally.
 * vila cries, one more bug in python http server...
<awilkins> vila: Heh, and the bugs in the RFC implementations bump into the bugs in IIS's implementations :-)
<vila> awilkins: err, any specific in mind ? I just fixed one where the http server weren't inserting a Content-Length header (which I more or less think is kind of mandatory in 1.1 which presumably is needed for https)
 * vila sounds very confident isn't it ? :-D
<awilkins> vila: It's the one I worked around somewhere...
 * awilkins looks up the revision
<vila> awilkins: really ? The only case where it seems to cause a problem is pycurl+https client hanging, all other combinations are fine
<awilkins> r 3539
<awilkins> It's a problem with it serving ranges in IIS
<awilkins> RFC822 in Python is wrong, as is RFC2046 in IIS
<awilkins> It's essentially about the way it quotes multipart content boundary lines
<vila> awilkins: Oh, I remember that one
<awilkins> But it has a workaround ; and really, you're not going to get it fixed in IIS
<vila> Sure, but the one I just fixed is in the python's http server
<vila> And *that* means that our http clients are tolerant about that, except pycurl for https :-)
<fullermd> Funny how every time I hear 'pycurl' here or on the list or anywhere, it's followed by "is screwing up XYZ for me"...
<awilkins> Off the top of my head the only thing I can think of for your automatic make-a-tunnel problem is that you may want to have a private key with no passphrase ; the part where it's automatically starts the tunnel is escaping me
<vila> fullermd: that's called rumors and I suspect someone is trying to get pycurl deprecated
<awilkins> pycurl screws things up for me on Windows
<vila> awilkins: Oh, good, I end up to that conclusion too (no pass-phrase) as for the automatic start, I found 2 possible solutions: 1) use inetd, 2) a perl script called autotunnel (a bit hackish though and not because it's written in perl ;-)
<vila> on the other hand, the automatic part is really needed only for my laptop usage and less important
<vila> awilkins: what is pycurl screwing ?
<awilkins> I'm content with manually establishing tunnels tvbh
<awilkins> vila: I don't recally, I abandoned using it about a year ago
<vila> tvbh ?
<vila> tbvh I can translate to 'to be very honest' with my crystal ball but... tvbh...
<awilkins> vila: Was meant to be tbh but I'm suffer from fat fingers. Too many sausage sandwiches I think.
<fullermd> Through Verbose Barnyard Hovels?
<vila> :)
<awilkins> And pycurl must have annoyed me, the folder is now called "curl_off"
<bialix> vila: bonjour
<vila> Hello bialix !
<bialix> I have a question about review process on LP
<vila> Are you asking if you can ask ?
<bialix> what should be done to mark patch as approved
<bialix> ?
<vila> :-)
<bialix> e.g. https://code.launchpad.net/~bialix/bzr/lp-bzr.exe/+merge/8259
<bialix> 2 approve votes is not enough now?
<spiv> vila: I don't think Content-Length is mandatory; e.g. if the transfer-encoding is chunked you don't need it to reliably determine end-of-body.
<vila> bialix: the second rapprover should land the patch :)
<Peng_> (testing my IRC client, sorry) bzr+ssh://example.com/
<vila> spiv: yeah, chunked and Content-Length are exclusive
 * fullermd fails Peng_'s client.
<Peng_> fullermd: :D
<bialix> vila: wait, there is 2 queues now: https://code.launchpad.net/bzr/+activereviews and https://code.launchpad.net/bzr/+approvedmerges
<bialix> my patch in the former
<bialix> what should be done to take it into the latter?>
<bialix> and what is "Review type" when I'm adding manually additional reviewers?
<knielsen> Hi, I'm a bit worried about this bug: https://bugs.launchpad.net/bzr/+bug/375898 ... it has been sitting there for a couple of month now, and it's basically a showstopper, crash on merge into tree with no known work-around :-(
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged]
<vila> bialix: ha, yes, the proposal status should be update, that's not the same as the review status
<bialix_> rats, my new patch for unicode locks affected by difference between lp:bzr and http//bzr.dev
<knielsen> There is a reproducible test case ... it's been blocking our merge of PBXT into MariaDB for two months now :-( ... so any help would be much appreciated
<bialix_> what should I do now?
<vila> bialix: ha, yes, the proposal status should be update, that's not the same as the review status
<bialix_> vila: sorry, I have been disconnected for some time
<vila> as for "Review type", I have no idea :) Try searching lp help :D
<bialix_> vila: so, I'm not bzr-core member, so I have no rights to change proposal status, it seems
<spiv> bialix_: for bzr just leave the review-type blank; some projects (e.g. launchpad) have separate UI review and database schema review on top of basic code review.
<spiv> But for bzr we just have reviews, no special differentiation.
<bialix_> ok, my new patch https://code.launchpad.net/~bialix/bzr/lock-unicode-win32/+merge/8297 affected by divergence between bzr.dev and lp:bzr. Should I resubmit it later?
<vila> generally yes
<knielsen> importance for  https://bugs.launchpad.net/bzr/+bug/375898 is "medium" which seems too low, as it basically makes your tree corrupt and unusable ... sounds more like critical to me ... ?
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged]
<bialix_> vila: ok, will do later today
<bialix_> jam is working these days?
<vila> knielsen: it would be best to check with jam and abentley in a couple of hours US TZs
<knielsen> vila: ok, will do, thanks
<poolie> hello vila
<vila> poolie: hi again :)
<poolie> if you have a chance, robert would appreciate you doing his check review
<poolie> it's kind of big
<poolie> he got an initial review from ian, but ian is away this week
<vila> poolie: I'm already reviewing it :-)
<fullermd> Hopefully that doesn't mean reviewing it drives people away  :p
<poolie> on the other hand it cures cancer :)
<vila> fullermd: in fact it does... I'll be in vacations the week after next week :)
<poolie> :)
<fullermd> Hm.  I'll review it then; I could use an escape week...
 * LarstiQ fumbles about with the launchpad review ui
<maxb> I have bzr-gtk installed to be able to use "bzr visualize", but I don't want the popup notifications when I bzr pull - where can I stop those? Thanks.
<Wellark^1> hi! I'm planning to start a project which uses bazaar for version control. I'm interested about the current state of GPG integration. This page http://bazaar-vcs.org/BzrGpgSigning seems to be outdated and I would like to know what's the current status. Particularly I'm interested whether or not is it possible to demand and force every commit which land to shared repositories on remote server to be signed. Thanks.
<poolie> Wellark^1: it's probably possible by writing a hook on the server
<poolie> i think there may be one already
<Wellark^1> ok. cool!
<Wellark^1> I'm sure I can work that out when I begin deployment
<poolie> you could send mail...
<Wellark^1> I was just worried if GPG side is completely broken or something like that :)
<lifeless> maxb: disable the applet
<maxb> what applet?
<maxb> removing the bzr-dbus package seems to have stopped them
<lifeless> theres a bzr gtk process being started by your session
<lifeless> bzr-dbus is just the transport
<maxb> Oh, so there is. Too much magic :-)
<lifeless> bzr-dbus has glue to do notifications on cross process, or LAN etc
<lifeless> and I plan to hook in jabber when I get some time
<NEBAP|work> is it possible to checkout a shared repository?
<mzz> NEBAP|work: it's definitely possible to checkout branches living inside a shared repository.
<mzz> NEBAP|work: checking out an entire shared repository doesn't make sense, but there may be a command that automates checking out all the branches inside one.
<NEBAP|work> mzz: but then I have to create a shared repository myself in the local location, too. Is there a way to checkout the hole "structure" of a project?
<mzz> NEBAP|work: see above.
<NEBAP|work> hmm
<mzz> NEBAP|work: it's not at all required for your local shared repository layout to match the remote one
<NEBAP|work> I introduce the layout I want to have for the project, maybe IÂ´m wrong with building it in bazaar
<mzz> NEBAP|work: for example if the remote repository has /path/to/repo/trunk, /path/to/repo/branches/foo-feature, etc, it'd make perfect sense to put them in local/repo/remote/trunk, local/repo/remote/branches/foo-feature, etc
<mzz> NEBAP|work: compared to (say) svn: a svn repository is much more like a bzr branch than a bzr repository. bzr repositories are normally purely an optimization
<NEBAP|work> hmm
<bob2> multi-pull plugin
<NEBAP|work> Can you checkout my preferred layout and tell me what each folder should be (e. g. branch or shared repository)?? http://pastebin.com/d496f0521
<NEBAP|work> IÂ´ve started using bazaar for some private projects which worked very well
<NEBAP|work> now I want to setup a bigger project in our company with bazaar
<mzz> NEBAP|work: the bazaar manual documents the pros and cons of a handful of repository layouts. Have you read that bit?
<NEBAP|work> yes
<NEBAP|work> but there is no hint how to setup those layouts
<NEBAP|work> the question is
<vila> NEBAP|work: Both (MyProject) and (Module1, Module2) are good candidates for shared repos
<mzz> NEBAP|work: unless your projects are pretty large you shouldn't worry too much about repository layout imoh
<mzz> imho, even
<NEBAP|work> is it useful for a developer to just use a branch (e. g. bzr branch .../MyProject/Module1/Branches/FeatureX; make changes and commit)
<vila> the choice mostly depends on the expected volume, the safe bet is to use Module1, Module2
 * vila agrees with mzz
<NEBAP|work> so itÂ´s ok to use some shared repos in a shared repo?
<vila> NEBAP|work: you can, but be sure everybody understand the consequences
<NEBAP|work> ^^
<NEBAP|work> what are the consequences?
<NEBAP|work> I think IÂ´ve understand the usage of a shared repository with some branches
<vila> Unexpected use of 'MyProject' repository ?
<vila> Or did you imply some other repos *below* ModuleN
<NEBAP|work> yes
<vila> NEBAP|work: let's forget about repos for a minute,
<NEBAP|work> ok let me tell you about the functionality I want to have
<vila> imagine that each branch stores the whole history of a project, each time you create a branch you copy that whole history to start with, and then each branch update its history, pull/push/merge occur, the histories are now different
<NEBAP|work> using the layout IÂ´ve posted before
<NEBAP|work> I want to have a overall place where the hole project (all modules) are stored
<NEBAP|work> to let a developer checkout all stuff in a single call (e. g. bzr checkout .../myproject)
<vila> NEBAP|work: you can't right now
<NEBAP|work> for each module I want to have a trunk storing the mainline of the project and a container for the branches to let a developer checkout a the trunk, create a feature branch under branches, commit to it and then merge it back to the mainline branch
<NEBAP|work> hmm
<NEBAP|work> is it possible to use a shared repository in a branch?
<vila> NEBAP|work: A standalone branch use its own private repository
<NEBAP|work> hmm
<NEBAP|work> a shared repository is useful for the feature branches to use a common place to store the history and prevent the branches to keep a history themselfes, right?
<vila> right
<NEBAP|work> so the moduleX folder should be a shared repo
<vila> I think so
<NEBAP|work> ok
<NEBAP|work> what is if I use a branch for the ProjectX folder?
<NEBAP|work> which contains the shared repositories?
<vila> :-)
<NEBAP|work> the ProjectX folder doesnÂ´t have to share the history
<vila> NEBAP|work: you mean http://bazaar-vcs.org/NestedTreesDesign/
<NEBAP|work> because there is no code in the container folder :)
<vila> NEBAP|work: define ProjectX
<NEBAP|work> ProjectX is just a container for the ModuleX folders (shared repos)
<NEBAP|work> but shouldnÂ´t hold a common history
<NEBAP|work> because Module1 and Module2 have nothing to do with each other
<NEBAP|work> the only thing I canÂ´t do in this layout is "bzr commit" in the ProjectX folder to commit each modules changes
<NEBAP|work> right?
<vila> right
<NEBAP|work> here is my updated example http://pastebin.com/d63396cf8
<vila> NEBAP|work: that sounds a lot like a server layout though, developers don't have to fully mirror it
<NEBAP|work> yes
<NEBAP|work> but they can if they want :)
<NEBAP|work> does this layout make sense?
<vila> MyProject is not a branch, it's just a directory
<vila> of course they can if they want
<NEBAP|work> but does it make sense to set MyProject up as branch?
<vila> but I suspect they don't want a copy of all feature branches even if they want all trunks
<vila> not really, what will you put into it ?
<NEBAP|work> to let developers do the following: "bzr branch .../MyProject" ?
<NEBAP|work> to load the hole project
<NEBAP|work> or doesnÂ´t it work?
<vila> no, that will not work
<NEBAP|work> k
<vila> but the developers can use the multi-pull plugin
<vila> which address, I think, your need
<NEBAP|work> my current layout looks similar to the posted but "MyProject" is just a folder and "Branches" is just a folder is that fine?
<NEBAP|work> k
<NEBAP|work> maybe they wonÂ´t need
<NEBAP|work> but thank you for the hint :)
<NEBAP|work> but now this is the layout on my server
<NEBAP|work> what has a developer to do if he / she wants to start a new feature branch?
<NEBAP|work> building up a local shared repository
<vila> err, "similar..but...is that fine?" is quite a tricky question :)
<NEBAP|work> ^^
<NEBAP|work> sorry, IÂ´m not the best english speaker ;)
<NEBAP|work> I just wanted you to ask if you think this layout is ok: http://pastebin.com/d3bed7893
<vila> mkdir MyProject ; cd My project ; bzr init-repo Module1 ; bzr branch <server_url>/MyProject/Module1/Trunk Module1/Trunk
<NEBAP|work> ok
<vila> yup, layout ok
<NEBAP|work> so the developer has to setup a local branch :)
<NEBAP|work> thank you
<NEBAP|work> if IÂ´m right, the developer shouldnÂ´t use the --no-tree option as this doesnÂ´t show the folders ..
<vila> has to setup a local shared repo, yes, that's better if he intend to use several branches, but that's not required
<NEBAP|work> k
<vila> exact, the developer is *supposed* to work with the trees :-0)
<NEBAP|work> but holding the trunk as a mirror and using some branches is "better" in a shared repository, because the history is just hold one time in the shared repo
<NEBAP|work> ?
<vila> It is more important when working disconnected from a central server but still not mandatory (ok, I will stop to mention the non-mandatory part from now :)
<NEBAP|work> k :)
<NEBAP|work> thank you alot
<NEBAP|work> very helpful
<vila> On a LAN, you care less about having a local mirror
<vila> because your network bandwidth/latency may be better than your disk's :-)
<NEBAP|work> itÂ´s very hard to understand all the useful functions of bazaar in a short time ;)
<NEBAP|work> hehe
<NEBAP|work> yeah
<vila> That's why we try to start from the workflow before chosing the layout, but it's not, oops
<NEBAP|work> ^^
<NEBAP|work> I just want to setup the server layout at first to avoid problems later
<NEBAP|work> loosing a history can be a very big problem ..
<mzz> imho as long as you get what goes into what branch right you'll be mostly ok
<mzz> that is: as long as you figure out if you want separate branches per project or need one branch containing multiple projects for some reason
<NEBAP|work> hmm
 * vila agrees with mzz
<mzz> you can reorganize at what level repositories live transparently, and to some extent move branches around on the filesystem too
<mzz> splitting up or joining branches is much more of a headache
<NEBAP|work> IÂ´ve just seen the cool log entries if you using the feature branch layout
<mzz> oh, yes, you definitely want feature branches
<NEBAP|work> :)
<mzz> but where on the fs those branches live is much less important
<NEBAP|work> itÂ´s just a few times more readable using this feature
<NEBAP|work> ah k
<mzz> it's just that any checkouts that are currently bound to them get upset if they move around
<NEBAP|work> weÂ´ve just used subversion before, bazaar gives us a bunch of new possibilities :)
<mzz> (I forgot just how badly confused a non-lightweight checkout gets)
<mzz> a heavyweight checkout can probably just be unbound if the branch it is bound to goes away, and an unbound branch doesn't care
<mzz> so those filesystem paths don't matter that much, they don't make it into history (the branch nick does, but the full branch location shouldn't)
<mzz> so if you change your mind on how you organize branches you'll have to deal with some temporary pain as people currently using them switch to the new location, but it won't show up in history
<mzz> makes sense?
<NEBAP|work> yes, I just hope I got you right :), as I said, IÂ´m not the best english speaker ..
<NEBAP|work> you mean that checkouts have problems if the corresponding server location changes?
<mzz> I don't recall if heavyweight ones do. Let me try.
<NEBAP|work> donÂ´t think, because you can use the unbind function to let them stay standalone (imho)
<vila> NEBAP|work: I you use plain branches, you won't run into the problems mzz mentioned
<NEBAP|work> k
<NEBAP|work> which type of branches does mzz use?
<vila> lightweigth or heavyweigth checkouts I presume which allow an indirection between the working tree and the branch itself
<mzz> a heavyweight branch will just unbind and rebind if the underlying branch moves
<mzz> so that's not an issue (no more of one than when using regular branches, and you have to respecify the push/pull location)
<mzz> lightweight branches get a bit upset
<mzz> that's probably a bug, and there might be a workaround for it
<NEBAP|work> hmm
<mzz> my local setup is slightly odd (I store code in working-tree-less branches on a fileserver on my lan, and hack in lightweight checkouts on the local drive)
<NEBAP|work> but all those problems are just present if I change the server location, right?
<mzz> you might want to not duplicate that setup :)
<NEBAP|work> ^^
<mzz> it's really a nonissue unless you use lightweight checkouts, and I should file a bug on those actually
<mzz> if you use heavyweight checkouts or regular branches you can just tell bzr where the parent branch went if it moves
<NEBAP|work> hmm I just want to use the a lightweight checkout to mirror the trunk in each module
<NEBAP|work> k
<NEBAP|work> ok, but server location shouldnÂ´t change
<NEBAP|work> so there should be no problem with my setup :)
<mzz> lightweight branches you'd have to recreate, unless you're feeling adventurous and change the location in .bzr/branch/location (but that's pretty horrible)
<NEBAP|work> ^^
<mzz> but I'm pretty sure that's just a bug and I should file it
<NEBAP|work> yeah, should be possible to reroute the lightweight checkout like the heavyweight one
<NEBAP|work> just one last question, should the developers in my layout store there branches on the server?
<NEBAP|work> I think they should for backup reasons
<vila> s/should/can/ they want to do that either for backup or because they are ready to share or because they want it to be reviewed before merging, etc
<NEBAP|work> k
<NEBAP|work> thank you both for your very good help
<NEBAP|work> safed me a lot of time and probably a lot of trouble :)
<vila> NEBAP|work: always happy yo help (tm)
<NEBAP|work> :D
<vila> s/yo/to/
<mzz> ah, interesting
<mzz> NEBAP|work: https://bugs.launchpad.net/bzr/+bug/105192/comments/7 if you do want to use lightweight checkouts and end up rearranging
<ubottu> Ubuntu bug 105192 in bzr "bzr bind should work for lightweight checkouts" [Undecided,Confirmed]
<NEBAP|work> mzz thanks
<NEBAP|work> I think most commercial projects / softwares can learn from the great support some open source projects offer ..
<NEBAP|work> or better the communities behind those projects
<NEBAP|work> one last question
<NEBAP|work> if I want to create a branch of the trunk
<NEBAP|work> should I create this branch from the server location of the trunk
<NEBAP|work> or from my local trunk mirror?
<NEBAP|work> the trunk mirror is a lightweight checkout from the server
<vila> a lightweight checkout is *not* a mirror (at least, that's not what is generally called a mirror whose purpose is to avoid accessing the mirrored server)
<vila> since in both cases you are accessing the server, it doesn't matter
<NEBAP|work> ^^
<NEBAP|work> so I shouldnÂ´t use the lightweight checkout for the mirror?
<NEBAP|work> what should I use instead?
<vila> a standalone branch
<vila> and pull regularly
<NEBAP|work> IÂ´m trying to use the feature branch layout
<NEBAP|work> ok
<NEBAP|work> so make a branch from the server trunk
<NEBAP|work> make the feature branch
<vila> that's what *I* do
<NEBAP|work> commit
<NEBAP|work> merge the feature branch into the trunk mirror
<NEBAP|work> and push the trunk mirror back on the server?
<vila> haaaa, now you're exposing your workflow :)
<NEBAP|work> ^^
<NEBAP|work> so you see, your help isnÂ´t just wasted time ;)
<vila> in that case you'b better keep your trunk as a lightweight checkout :)
<NEBAP|work> k
<NEBAP|work> so after commiting to the feature branch is just
<vila> but don't call it a mirror and think about 'bzr update'ing it on a regular basis and especially before merging
<NEBAP|work> s/is/I
<NEBAP|work> just merge the feature branch in the trunk checkout
<vila> right
<NEBAP|work> and then commit the trunk checkout to send changes to the server
<vila> yes
<NEBAP|work> ah cool :)
<NEBAP|work> but using push in a brunch doesnÂ´t just overwrite the target, it does more like a commit, right?
<vila> at worst you will run into diverged branches if someone else committed between your last update/pull and your commit
<vila> push *add* revisions to the target putting both branches (local and remote) back in sync
<NEBAP|work> hmm
<NEBAP|work> so maybe is push more safe then using a lightweight checkout?
<NEBAP|work> to use the send command (using a readonly branch on the server), have I to use a branch or a checkout?
<mzz> a checkout of a readonly branch is itself pretty readonly
<mzz> well, I guess there's --local, but if you want to commit I'd just use a plain old branch
<NEBAP|work> ah ok, sound logically ^^
<NEBAP|work> ok
<mzz> in fact generally when in doubt just use a plain old branch
<NEBAP|work> thank you guys
<NEBAP|work> ^^
<NEBAP|work> I just tried to use the cool send feature and run into some troubles
<NEBAP|work> s/run/ran
<vila> What do you want to use 'send' for ?
<mzz> and yeah, who or what are you sending to?
<NEBAP|work> to avoid problems when more people commit to the trunk, my idea was to make the trunk readonly and force the developers to send the changes to the "committer" which then, can also do some code review
<vila> NEBAP|work: send needs a public branch and a submit branch
<NEBAP|work> but in contrast it becames a very complex layout then, if I donÂ´t want to lose the possibilty to backup the feature branches ..
<vila> the submit branch is where your want the merge proposal to be applied, the public branch is where you will find revisions not included in the bundle if you need them
<NEBAP|work> public branch -> read only on the server, submit branch?
<NEBAP|work> ah ok
<NEBAP|work> seems to be a bit hard with my layout ^^
<NEBAP|work> just an idea :)
<NEBAP|work> thank you
<bialix> hello jam
<Tak> jelmer: ping
<bialix> jam: thank you.
<Tak> ok, so `bzr pull` from a branch of an svn repo fails with an unknown branch id
<Tak> but `bzr rebase` gives "Base branch is descendant of current branch. Pulling instead" and succeeds
<vila> jam: += 1 in pyx ? What pyrex version are you using :-D
<jam> vila: 0.9.8.5
<jam> I'll certainly fix those for landing
<jam> anyway, I'm in-and-out, (mostly out) this morning because my son is sick again
<jam> If you want, you can call my cell phone right now
<vila> :-/
<jam> I'll have 30min or so to talk
<vila> jam: I'm reviewing your rework-annotate proposal
<jam> sure
<jam> I thought you might want to talk directly about it
<flutherben> Hi all--I have a question: Is there a way to make the output of "bzr revno" not show the progress bar and all the download statistics?
<beuno> flutherben, maybe if you add -q?
<flutherben> Thanks, beuno, I tried --quiet, didn't seem to do it
<flutherben> I think it's some kind of global bzr setting
<beuno> flutherben, then you will likely have to do it through python to avoid getting a progress bar
<mzz> iirc there's some magical env var to disable progress bars
<mzz> sec
 * beuno does not know the encantation
<beuno> vila, hi  :)
<mzz> BZR_PROGRESS_BAR=something, I think, sec
<mzz> of course I'm not getting any progress bar on "bzr revno" anyway. Hmm, what gets me a progress bar
<flutherben> it's only since I moved to 1.16
<flutherben> now I'm seeing a bug about "not respecting BZR_PROGRESS_BAR", though it's not clear what the options are yet
<mzz> hmm, yes.
<mzz> the one function looking at BZR_PROGRESS_BAR is marked deprecated
<mzz> err, or maybe not. sec.
<mzz> "bzr help configuration" still documents BZR_PROGRESS_BAR
<flutherben> hmmm, what's strange it is only seems to be happy on my server, though it's the same version of bzr
<awilkins> Holy dungbeetle, verterok, bzr-hudson makes Maven download lots of stuff
<vila> hi beuno :)
<verterok> awilkins: yes, hudson plugins download a lot of stuff :)
<awilkins> Bah, no bzr-java-lib
 * awilkins sets up a Hudson job for that too
<verterok> awilkins: bzr-java-lib? btw, some changes landed in bzr-java-lib trunk, now it's using commons-logging
<flutherben> I can't find any way to turn it off (the BZR_PROGRESS_BAR)
<vila> flutherben: 'BZR_PROGRESS_BAR=none bzr revno' should work
<flutherben> doesn't work
<vila> which bzr version ?
<flutherben> 1.16.1
<flutherben> http://dpaste.com/64136/
<vila> flutherben: fixed in bzr.dev, will be part of bzr 1.17
<flutherben> ah, that explains it
<flutherben> thanks
<vila> there was bug #321935 and bug #339385 at least, both are fixed
<ubottu> Launchpad bug 321935 in bzr "[master] Progress bar leaves artifacts in output" [High,Fix released] https://launchpad.net/bugs/321935
<ubottu> Launchpad bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385
<flutherben> alright, I guess it's time I move to the dev version
<CalicoJck> hello, i was hoping someone might be able to point me in the right direction here...i'm trying to integrate to a subversion server that doesn't have a consistent repository layout.  Depending on which subtree of the repository you are in, branches and tags exist in different locations (or sometimes not at all).  Is there a way to specify the repository layout in subversion.conf for different subtrees of the same subversion repository?
<flutherben> Great, using the dev version, now it works
<flutherben> thanks
<flutherben> also, is bzr co --lightweight the fastest way to get a copy of a branch?
<exarkun> Can I specify a custom Python function implementing a merge algorithm to be applied to files which match a particular pattern?
<beuno> flutherben, you just want a working tree?
<flutherben> yeah
<beuno> if so, maybe "bzr branch BRANCH --stacked" is faster. Not sure
<flutherben> cool, thx
<huf> hi. what's the best way to backup a bzr repo?
<huf> just copy the files as they are?
<huf> or is there some command i can use that converts to a more future-proof format?
<beuno> huf, I just rsync .bzr
<beuno> bzr isn's very nice to rsync, but it works
<knielsen> abentley: someone suggested I ask you about https://bugs.launchpad.net/bzr/+bug/375898 ... any ideas? It's been sitting for about two months, it is a case where repo gets basically corrupt/unusable due to bzr merge crashing, there is a reproducible test case ...
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged]
<knielsen> I'm asking, as it is somehow blocking our merging of PBXT into MariaDB ...
<knielsen> jam: ^^^ your name was also suggeste :)
<abentley> knielsen: Problems like that are quite subtle, so I have no idea how easy or hard it would be to fix.
<knielsen> abentley: hm, really?
<knielsen> abentley: well, I agree the test case is far from minimal :-( probably >50k commits
<knielsen> and not at all clear how to reduce it
<abentley> knielsen: I'm not sure how to respond.
<knielsen> abentley: no worries, I think you responded fine, the issue has been looked at, but the root cause is not known ....
<knielsen> that means probably that we should look into an alternative way to solve the problem, as a fix is not likely to appear soon. Maybe we will have to track merging manually, which ought to avoid the problem
<alecwh> Hi, I want to branch my code to work on a site redesign. In git, all I do is "git branch feature_x" (where feature_x would be the experimental feature) in the working directory, and then "git branch" to see which one I'm currently "on".  Then I want to merge my branch back in when I'm done with the site redesign. how do I do this in bzr?
<knielsen> abentley: It does worry me somewhat so see repository corruptions like this, was quite fortunate that I happened to test that particular merge before pushing into our main repository and potentially having to roll back lots of commits
<Peng_> alecwh: "bzr branch" and "bzr merge". It's just that it's more equivalent to "git clone".
<abentley> knielsen: This is not a repository corruption.  It's all to do with merge and the working tree.
<knielsen> abentley: hm... are you saying you can see from the bug that the branch is ok, and once the bug in bzr is fixed, the merge could complete?
<alecwh> Peng_: when I do this in bzr, inside my working directory, it says, "bzr: ERROR: Not a branch: "/var/www/redesign/"." (from this command: bzr branch redesign)
<Peng_> alecwh: bzr help branch :P
<alecwh> Peng_: good point, thanks. =)
<abentley> knielsen: I am saying there's no reason to suspect this is anything other than a bug in merge.
<Peng_> alecwh: cd .. && bzr branch $OLDPWD redesign && cd redesign
<Peng_> alecwh: :D
<knielsen> abentley: ok, thanks for your help!
<alecwh> Peng_: Thanks, I'll be sure to check the docs next time.
<alecwh> Does bazaar support topic branching (like git's "branch feature_x")?
<dash> alecwh: sure. 'bzr branch oldbranch/ newbranch'
<SamB> git doesn't support topic branching in particular -- it just supports branching
<SamB> more-or-less correctly
<Peng_> alecwh: Bazaar just doesn't support having multiple branches in the same directory.
<alecwh> dash: no, I don't want bzr to create another physical branch. With git, I can do a "git branch" and it will show me what branch I am currently on, and then I can switch to one very easily without navigating directories.
<SamB> how you use it is your bussiness
<alecwh> Peng_: ah, dang.
<Peng_> (Well, you can sort of do it with a lightweight checkout and "bzr switch", but...)
<SamB> alecwh: I usually use a repo dir full of treeless branch directories in parallell with a lightweight checkout of one of them
<dash> weird
<Peng_> I'm lazy. I just have lots of trees sucking disk space. :D
<dash> same here
<Peng_> I usually "bzr remove-tree" them when I'm done, at least on the larger projexts.
<RenatoSilva> join #launchpad
<RenatoSilva> verterok: hi
<RenatoSilva> clear
<verterok> RenatoSilva: hi
<RenatoSilva> verterok: I've written the other test...
<RenatoSilva> verterok: they're running ok for me
<verterok> RenatoSilva: thanks!, I have the email in my TODO queue, just that I wasn't hable top take a look yet, I think in a few hours (after my "work day")
<RenatoSilva> verterok: ok
<flutherben> I was moving hard drives, and I copied over a bzr directory, and now when I commit I'm seeing "aborting commit write group: NoSuchId"
<flutherben> any simple way to fix this?
<LarstiQ> flutherben: could you paste the traceback?
<flutherben> http://dpaste.com/64303/
<LarstiQ> interesting
<LarstiQ> flutherben: the ~/.bzr.log should have a fuller traceback
<LarstiQ> flutherben: what does `bzr info` say?
<flutherben> ah
 * LarstiQ wild guess would be that it's a branch without its repository
<flutherben> bzr info is pointing to a renamed home repository
<flutherben> can I re-brand this brand to a new repo?
<LarstiQ> depends on what is going on
<flutherben> ok, I'll paste the output
<LarstiQ> if I'm right, then no, because the branch's revisions are not in the repo it is finding
<flutherben> this is the output from bzr-info:
<flutherben> http://dpaste.com/64306/
<flutherben> (and panda-mirror has been renamed to panda-trunk
<flutherben> but it's a new hard drive
<flutherben> so it's not the exact same tree
<flutherben> and here's my bzr.log
<LarstiQ> right, so it is using a shared repository
<LarstiQ> flutherben: do you know which repository it was using on the old harddrive?
<flutherben> yeah, and I still have access to it
<flutherben> panda_mirror
<flutherben> er, panda-mirror
<LarstiQ> so if you cp -a this branch there, does it give the same error?
<flutherben> lemme see
<flutherben> I'd prefer to use this new repository, but that would actually be fine
<flutherben> hold on
<LarstiQ> just trying to confirm my suspicions
<LarstiQ> flutherben: how did you copy this branch over from the old to the new one?
<flutherben> I just copied it (using os x finder) from the old repo into the new repo
<flutherben> seems kinda foolish when I think about it now
<flutherben> but the repos are both checkouts of the same branch
<LarstiQ> flutherben: yeah, I thought that might be the case.
<LarstiQ> flutherben: repo != branch
<flutherben> yeah, that makes sense
<LarstiQ> flutherben: the repository is what contains the actual revisions, a branch just references them
<LarstiQ> flutherben: so if you copy a reference to a place that doesn't have the actual data, boom
<LarstiQ> flutherben: using `bzr branch` instead of os cp would prevent that from happening
<flutherben> got it
<flutherben> lemme try and move it back to the old repo
<flutherben> check in there
<flutherben> and then bzr branch it in
<flutherben> ok, moving it and committing worked
<flutherben> I'm getting confused about the bzr branch command
<flutherben> is it bzr branch old_dir new_dir?
<flutherben> and it will just know to switch repos?
<flutherben> wow, it all just worked
<flutherben> thanks a lot, LarstiQ
<flutherben> I was about to start manually changing things
<flutherben> great!
<LarstiQ> flutherben: yes, it will know about which repos to use
<LarstiQ> flutherben: pleased to be of help
<LarstiQ> flutherben: in the future, please don't cp/mv branches out of their repositories, but either copy the repository too or use `bzr branch` :)
<flutherben> yeah, for sure
<lifeless> bbs
<poolie> good morning
<LarstiQ> moin poolie
<poolie> i'm hoping to fix the rest of bug 391411 and other stacking issues today
<ubottu> Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411
<poolie> hi LarstiQ
#bzr 2009-07-08
<poolie> it's quiet today...
<lifeless> and how does that make you feel?
<lifeless> :)
<jelmer> moin poolie, lifeless
 * mwhudson grumbles
<mwhudson> other things that turn out not to be thread safe in bzrlib: lazy imports
<lifeless> mwhudson: for that one, you might want to file a bug
<james_w> things not being thread safe that have bitten me today: LP API
<poolie> jml, did you send a metronome mail?
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/396819
<ubottu> Ubuntu bug 396819 in bzr "lazy imports are not threadsafe" [Undecided,New]
<mwhudson> contrary to what i thought yesterday, lrucache doesn't seem to be that thread un-safe
<mwhudson> (although if a cleanup function raises, that seems to break the cache pretty badly)
<poolie> lifeless: is there a command to dump the pack-names file (re bug 396308)
<ubottu> Launchpad bug 396308 in bzr "bzrlib.errors.ShortReadvError: readv() read 0 bytes rather than X bytes for pack" [Undecided,New] https://launchpad.net/bugs/396308
<lifeless> poolie: bzr dump-btree .bzr/repository/pack-names
<lifeless> poolie: (for 1.9 and above formats)
<jml> poolie, no, it got crowded out.
<thumper> poolie: for  bug 391411 can the reconfigure --stacked-on give a relative remote path for the branch?
<ubottu> Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411
<thumper> poolie: I think that is what we really want for LP stacking
<poolie> thumper: my current idea (indeed current code) is that you give a cwd-relative or absolute url, but it stores it relative to the branch
<thumper> poolie: we use absolute paths from /, like /~bzr/bzr/devel
<thumper> poolie: so it works over whatever transport
<poolie> ok
<poolie> hm maybe we need a transport-relative path
<poolie> btw, staging is a bit hard to test this against because it recommends new branches be stacked on staging/~bzr/bzr/trunk (for example)
<poolie> but that branch doesn't exist :)
<poolie> on staging
<thumper> poolie: bzrtools is on staging
<thumper> poolie: but I think it is the only project we copy across for testing
<poolie> ok
<poolie> i'll test on that then
<thumper> let me know if you have any problems
<thumper> although with spm not around, I'm not sure there will be much I could do :)
<jml> lifeless, Just confirming, is the full fix for bug 390563 in bzr.dev?
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<poolie> jml, it may be that there are other bugs that look similar
<poolie> not sure
<RenatoSilva> anyone using maven?
<RAOF> The only thing I've heard about maven has not been complementary.
<RenatoSilva> I want to download source for a lib
<doctormo> I'm trying to help someone who is new to bzr, I asked him the bzr checkout a branch that we can both commit to on launchpad but when he goes to commit he gets: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-learning-board/ubuntu-learning-moodle/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<doctormo> I think I may have advised him wrong, any help getting out of this position?
<beuno> doctormo, he hasn't set his launchpad id
<beuno> bzr launchpad-login USERNAME
<doctormo> beuno: Ah right
<jml> poolie, done!
<doctormo> beuno: running the launchpad-login caused the same error: Transport operation not possible: http does not support mkdir()
<beuno> doctormo, that's... odd
<jml> doctormo, does he have write permission for the branch?
<jml> that is, is he a member of ~ubuntu-learning-board?
<doctormo> beuno: Ah no sorry the login didn't error, a new commit command failed the same way,.
<doctormo> bad communication
<beuno> doctormo, as jml asked
<beuno> is he part of the team?
<lifeless> jml: checking (sorry, laptop powered off, came back and the kms thing had me wedged for a bit)
<lifeless> and now X has locked up.
<lifeless> <sigh>
<doctormo> beuno: yes team: https://code.launchpad.net/~ubuntu-learning-board code: https://code.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk and user: (launchpad wouldn't load)
<lifeless> doctormo: now you need him to do 'bzr bind lp:<...>'
<doctormo> matthew.lye
<lifeless> doctormo: to change the URL that bzr has recorded locally
<lifeless> or bzr switch lp:...
<doctormo> lifeless: I see
<doctormo> I think I remember this problem from before
<doctormo> https://code.edge.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk <- on here, we got his commit working, but he shows us as an odd name /email, config problem?
<doctormo> thanks lifeless, beuno for your help with the commit problem
<lifeless> doctormo: bzr help whoami
<doctormo> thanks lifeless
<jml> hey
<jml> I was just talking with Twisted folk about NEWS files.
<jml> apparently when they had a NEWS file that was edited on each mainline commit, they got conflicts on every landing
<jml> this doesn't seem to happen with the Bazaar project: why?
<lifeless> jml: two things
<lifeless> a) it does
<lifeless> we often have to merge down trunk and fix conflicts with news
<lifeless> just run log -n0 (man that should be the default) and you can see those commits.
<lifeless> b) we alphabetically order the news items under each header.
<lifeless> this reduces concurrent editing of the same locations
<jml> lifeless, ok. thanks.
<lifeless> chronological ordering will generate many successive edits to the same place
<RenatoSilva> the args are given to a plugin command by bazaar, right?
<lifeless> yes
<RenatoSilva> I mean, I have a source code here, and the command class has a run method with the *args argument
<RenatoSilva> these args are full objects, right? e.g the rev
<RenatoSilva> I'd like to know who fills in the data for the rev object...
<RenatoSilva> it seems that the fields are utf-8 str objects, not unicode
<lifeless> plugins are no different than any other command
<RenatoSilva> but I need a documentation
<lifeless> look at something like cmd_pull
<lifeless> there are api docs, but there isn't a narrative about this part of bzrlib
<RenatoSilva> ok, bazaar gives the cmd an arg called rev, it's an object
<RenatoSilva> I want to know what bazaar has to tell me about the rev strings
<RenatoSilva> are they always utf-8? may change the encoding? may become unicode someday?
<lifeless> show me your code
<RenatoSilva> lifeless: what code exactly?
<RenatoSilva> lifeless: what I'm trying to achieve is...
<RenatoSilva> bzr-eclipse gets branch's log by running an xml-rpc call, which in turn runs xmloutput plugin, which returns the XML version of the log. I looked at the source, the xmllog command just runs the builtins.cmd_log passing an XML formatter for the log. This formatter handles the revision object given by bazaar...
<RenatoSilva> and puts the commit message inside a CDATA for example
<lifeless> inside bzrlib revisionids are utf8 bytestrings
<RenatoSilva> I'm not sure if it's using a custom writer or if the data comes from bzr already as utf-8 str
<lifeless> the commit message is unicode
<RenatoSilva> the fact is that the data is utf-8
<RenatoSilva> lifeless: only message or all data in rev object?
<lifeless> "only message or all data in rev object?" - what?
<RenatoSilva> lifeless: what's the compromise of bazaar rgarding rev data format?
<lifeless> I'm sorry, I'm really not following you. You're talking about objects, not data formats.
<lifeless> the Revision class has a number of fields, and they are all different types.
<RenatoSilva> s/data format/string format (aka str+encoding or unicode)
<lifeless> if you're talking about how something is serialising stuff, it depends on what the serialiser is doing
<RenatoSilva> lifeless: I need to check if the plugin is using a self writer
<lifeless> this may help:
<lifeless> there are three sets of strings that bzr deals with:
<lifeless>  - internal disk data (stuff under .bzr). These we have specific formats for that have varied over time. Commonly they are xml within compressed archives
<lifeless>    and more specifically, the xml tends to be utf8 encoded
<RenatoSilva> I just want to find the reason I'm receiving utf-8, if it's bzr or the plugin
<lifeless>  - local environment strings: command line parameters, working directory, file system encoding, console encoding
<lifeless>    for these strings bzr usually decodes them to unicode objects, so the core bzr code doesn't have to know what encodings are in use
<lifeless>  - internal strings. These are strings like revision ids, index keys, file ids. For these bzr strives to have them in utf8 all the time, decoding to unicode and encoding to the external encoding only when required
<lifeless>    we do this for speed
<lifeless> RenatoSilva: You want to know if you're getting utf8 *in python code* ? Or on stdout ?
<RenatoSilva> lifeless: I want to know what happens from e.g. commit message inside .bzr to it being read by the java plugin. I want to know if the plugin is re-encoding stuff as utf-8 or if it was already encoded by bzr
<RenatoSilva> anyway I want to know
<RenatoSilva> sorry
<lifeless> it will be reencoding
<lifeless> because the repository is not required to use xml
<lifeless> as to where it is reencoding, I haven't looked at the xmloutput plugin, so I don't know what code paths its using
<lifeless> I'm still not clear what you mean 'it being read by the java plugin'. You might  be meaning 'when the eclipse process reads teh xml'. Or you might mean 'when a revision object is given to bzr-xmloutput'
<lifeless> or you might mean 'when xmloutput receives an xml revision string'
<lifeless> or something else
<RenatoSilva> I'm checking bzrlib.revision.py, there are just 2 refs for message field, one in __eq__ and the other in get_summary
<RenatoSilva> ok let me start again...
<RenatoSilva> the problem is:
<RenatoSilva> wrong chars in bzr-eclipse log view
<RenatoSilva> that is, when you want to see the log through ui using bzr-eclipse, you see wrong chars because of an ecoding issue
<RenatoSilva> this issue can be fixed by just re-decoding the xml-rpc response as UTF-8
<RenatoSilva> the problem here is that...
<lifeless> so the xmlrpc response has to start out as octets
<lifeless> because its a network protocol
<RenatoSilva> I don't want to put "UTF-8" hard-coded in the fix
<RenatoSilva> I want...
<lifeless> XML defines how encodings are represented
<RenatoSilva> I want to who is ensuring the data is UTF-8, and if it will always be this way, etc.
<RenatoSilva> lifeless: ok you could guess by XML preamble but...
<lifeless> so, you're looking at lass XMLLineLogFormatter(log.LineLogFormatter):
<lifeless> yes?
<RenatoSilva> lifeless: unfortunately just printing out a charset in the XML header won't ensure that the XML itself matches such encoding...
<lifeless> so, bzr-xmlloutput is responsible for this
<lifeless> it recieves Revision objects
<lifeless> and it should serialise them
<lifeless> the revision_id and parent_ids attributes have utf8 bytestrings; the other fields are variously dicts, ints, floats, and unicode
<RenatoSilva> lifeless: and the data I'm particularly interested in is not generated by the plugin, it's given by bzr.... the question is: is bzr giving unicode and the plugin encoding as utf-8? or is bzr giving utf-8 str, and in this case is the plugin doing any conversion still? or still, is bzr giving non-utf-8 str and the plugin is re-encoding as utf-8?
<lifeless> RenatoSilva: I think I've answered this
<RenatoSilva> lifeless: I'm reading the code to find the answer... you're giving me me info about rev object, but in bzrlib.revision.py for example, I can't find the message field. Am I looking at the wrong file?
<lifeless> Revision is poorly documented, and a bit of a 'data holder' class
<lifeless> deserialisation is per-repository, you can look at repository.py, and repofmts/*.py to see the different serialisers
<lifeless> and bzrlib/xml* and bzrlib/*serial*
<lifeless> as I said above though. revision.message is *unicode*
<RenatoSilva> you just know this or are you looking at some source code?
<RenatoSilva> As I said I can't find the definition of the message field :(
<RenatoSilva> logxml.XMLLogFormatter has a to_file field, but I can't find where it comes from
<lifeless> the log infrastructure
<RenatoSilva> I'm trying to know if it is being overwritten by the plugin (codecs.getwriter)
<RenatoSilva> well I think I don't need to
<lifeless> I have no idea :)
<RenatoSilva> if the message is given as unicode by bzr, and it gets in the client as utf-8, that's because bzrl-xmloutput is doing it, no matter how :)
<RenatoSilva> lifeless: so I can trust that rev object strings will be either unicode or utf-8 str, right?
<lifeless> in the log formatter yes
<lifeless> I can't make any assertions about what the log formatter outputs
<RenatoSilva> anyway I think the plugin should handle the data properly, ensuring its policy will be applied (for example, print always utf-8)
<RenatoSilva> lifeless: conclusion the answer about what is the encoding should be given by the plugin
<RenatoSilva> so simple o.O
<vila> hi all
<vila> lifeless: I agree with your feelings about pycurl hanging bug, *but* digging to the root cause requires crossing the python/C barrier and that could be really time consuming, keep in mind though, that if real servers can produce such behavior, I will, sooner or later knows it via local_test_server (once I restart my efforts there)
<vila> s/I agree/I *share*/
<lifeless> vila: so a few thoughts
<lifeless> vila: have you checked that the socket is actually being closed?
<vila> lifeless: just asnwering to your mail
<vila> lifeless: I've seen the close() calls
<lifeless> in strace?
<vila> in pdb
<poolie> hi vila
<vila> hi poolie !
<poolie> spiv, istr you had a patch a while ago, that might have been abandoned, to do with better reporting of exceptions masked by unlock failures...
<lifeless> so _socketobject.close seems to rely on gc()
<lifeless> vila: ^
<spiv> Huh, I wasn't expecting to find a hpss hang here.
<vila> lifeless: >-/
<spiv> poolie: I did, I think it was essentially abandoned.
<lifeless> vila: I'd really like a little more investigation. Not a lot.
<lifeless> vila: just - add a gc.collect() call after the server calls close()
<vila> lifeless: like a call to gc from the server after the close ?
<vila> :)
<spiv> I think the bug report(s) are probably fairly up to date about where that's at.
<lifeless> and when it hangs, poke with lsof
<lifeless> perhaps run under strace quickly, which should show the data being written, and read, and the socket closed
<poolie> spiv, where?
<poolie> i mean, where is the hpss hang?
<lifeless> if thats all inconclusive, keep it as it is...
<vila> lifeless: works for me
<spiv> poolie: there's a race condition(!) in the v3 decoder, if it receives multiple calls to accept_bytes after parsing the end of the message it overwrites, not accumulates, the excess bytes.
<spiv> The fix is trivial (+= rather than = in the relevant function), but it certainly was confusing for a while, especially before I didn't realise it wasn't necessarily deterministic once sockets get involved... so I was getting random test failures.
<poolie> oh ok
<spiv> And of course when you don't realise there's randomness then you start going crazy as you change minor things to debug the failure and get different results...
<spiv> Just finishing up the network backwards-compat part of this inventory delta patch and then it's ready for review.
<lifeless> jml: ping
<jml> lifeless, pong
<jml> lifeless, just got back from an urgent hair cutting appointment.
<lifeless> heh
<lifeless> I wanted youropinion on my last post on https://bugs.edge.launchpad.net/testresources/+bug/284125
<ubottu> Ubuntu bug 284125 in testresources "Provide an option for easy instrumenting of resource setup and teardown" [Medium,Triaged]
<jml> oh right. I saw that go through my email last night..
<lifeless> I could ring you?
<jml> yeah.
<jml> although skype is better for me
<lifeless> I'm just heading for a walk
<vila> lifeless: summary: I need to call gc.collect() *after* the server thread ends to get some difference :-/
<vila> which seems to validate poolie's theory..
<Spabby> hi there, the location of my bound branch has moved (ip has changed), is there any way to tell bzr this pleasE?
<bob2> edit .bzr/branch/branch.conf or 'bzr bind nelocation'
<Spabby> sorry closed my irc by mistake, thank you bob2
<jml> jelmer, can you please set the development focus branch of https://launchpad.net/git to the vcs-imports branch?
<Mez> jml, still around?
<Mez> or any of the devvies :D
<jml> Mez, I am.
<Mez> jml: I'm thinking of a feature request - don't know whether it's viable.
<Mez> Well, 2 feature requests.
<Mez> 1) When you commit, an option to set the "whoami" data for just that commit
<Mez> 2) the option to force you to have to set that per commit (so you have to specify who you are)
<Mez> It's cause we've got a dev environment where we all seem to login to and commit, and it doesnt show in the log WHO actually made the commit
<jml> Mez, ok.
<jml> Mez, so you can set the author of a commit already
<jml> Mez, note that 'author' is distinct from 'committer'
<Mez> hows that then ?
<jml> Mez, 'bzr commit --author 'Jonathan Lange <jml@mumak.net>'
<Mez> jml: does that show up in the log ?
<jml> Mez, I don't know off the top of my head. It should be easy enough to do the experiment though.
<jml> he said, hintingly.
<Mez> I'm already doing an experiment, just thought you might know off the top of your head
<jml> :)
<Mez> revno: 459
<Mez> author: Martin Meredith <martin@sourceguru.net>
<Mez> committer: root <root@webutils>
<jml> Mez, as for forcing you to set the author...
<poolie> lifeless: ok, bzr-guess just helped me :)
<poolie> or it tried
<poolie> i ^cd it by instinct first
<jml> Mez, I guess it's a valid feature, but you might well be the only person who wants it :)
<Mez> probs
<jml> Mez, as a crappy hack, you could do this:
<jml> bzr alias commit='commit --author'
<poolie> or you can set BZR_EMAIL
<jml> (but that's a really crappy hack.)
<Mez> or I can write some sort of plugin
<jml> yeah.
<jml> I've talked with lifeless before about a feature for setting the author(s), for use in pair programming sessions.
<mwhudson> jelmer: does bzr-git import the kernel yet? :)
<poolie> it might be nice if the config system also looked in the environment
<poolie> for cases like this
<vila> lifeless, poolie: I've got a cleaner fix calling shutdown(socket.SHUT_RDWR) and catching EBADF and ENOTCONN when the server connection is closed
<Mez> well, it's also the fact we all use the same user (near enough) when we're on there
<poolie> nice
<poolie> Mez, that's why i was suggesting an env var
<poolie> so it's not on disk or shared
<poolie> vila, nice - i agree with you in questioning whether this is worth it, but if you've fixed it, yay
<poolie> lifeless: are you still here?
<poolie> jml, nice metronome
<jml> ta
<Mez> poolie, then they have to work out how to set that env var
<jml> poolie, lifeless is gone, methinks.
<vila> poolie: I feel better having it fixed that way, lifeless rightly pointed the grey area
<poolie> vila, just to talk over the reconfigure stuff
<poolie> apparently it fails if there's new history in the stacked branch on top of the fallback repository
<poolie> 'it' meaning set_stacked_on_url
<poolie> in other words, if the tip of the stacked branch is new, it fails with revision not present
<poolie> this is a pretty typical scenario if you think about it
<poolie> i suspect this covers some number of existing bugs
<poolie> now i need to work out if i can get fetch() to backfill history the right way
<vila> poolie: new history ? Between which dates ?
<poolie> new history in the sense of revisions that aren't in the fallback repository
<vila> so it can be called only at creation time ?
<poolie> yeah apparently so
<poolie> or rather, before committing to the stacked branch
<poolie> it looks like it tries to handle the other one but it doesn't seem to work
<vila> hmm, worth fixing :)
<vila> lifeless: in passing: using --parallel=fork in the test farm gives a very obscure failure: the execution is killed after the timeout without output has triggered but there is no clue about why. I think I'll keep using it though at least until I stabilize the whole setup
<poolie> vila: you know socket shutdown may (on some OSs?) discard any data sent to the socket and not read by the other party?
<vila> poolie: pffff, even flushed data ?
<vila> poolie: because here, both read and write makefiles are flushed, closed, and yet, pycurl got nothing while polling...
<vila> where is that data then ???? :-D
<fullermd> I ate it.  I'm sorry.
<poolie> vila, it can discard the socket buffers inside the os kernel
<poolie> i'm not sure if this is relevant to your patch
<poolie> vila, do you know if there's a way to do a fetch that allows for this situation i described above?
<poolie> ie the tip revision we want to fetch is not in the source, but some of its ancestry is?
<poolie> maybe i should just change it to fetch everything...
<vila> poolie: the more bugs of that kind I see, the more I'm convinced there is a bug in the python socket stack...
<vila> poolie: err, I'm not familiar with fetch internals, sorry :-/
<poolie> well
<poolie> doing that makes it pass :)
<poolie> i think i'll leave it there for tonight and talk to jam or lifeless tomorrow
<vila> but I feel strange that you request a tip that is not in the source instead of fetching what you're missing
<poolie> it may be possible to make a fetch spec for it
<poolie> i agree it sounds strange
<Fauli> Hi everyone.
<Fauli> Any bzr-gtk developers available?
<vila> Fauli: depending on your question you may have different answers, so please just ask
<Fauli> Is it possible to make release?  The current 0.95.0 is broken with Bazaar 1.16, but fixed in trunk.
<Fauli> I help maintain the Gentoo Bazaar overlay where we have an ebuild available (and I am the Bazaar maintainer in Gentoo anyway).
<Pilky> poolie: you around?
<vila> Fauli: ping jelmer and phanatic, I thought jelmer was about to make a release though...
<Fauli> jelmer: What's the status on a new bzr-gtk release?
<Fauli> vila: Thanks for the information.
<awilkins> verterok: Hi there ; is there anything more to installing a Hudson plugin than uploading the hpi to the web interface? I can't seem to get the Bazaar plugin to install
<awilkins> verterok: Never mind, it installs it rather than just putting it in the list of available plugins
<jelmer> jml: done
<jelmer> mwhudson: it should support importing the kernel if you're importing to a 2a repo
<jelmer> Fauli: I'm not sure - I won't have time for it any time soon, maybe one of the other bzr-gtk folks will
<Fauli> jelmer: Could you convince them or should I file a bug for that?
<lifeless> poolie: guess - good.
<lifeless> poolie: you can ring if you need to chat but I'm not at the laptop after these lines
<lifeless> vila: yes, I suspected shutdown would be useful
<jelmer> Fauli: can you perhaps mail to bzr-gtk@lists.canonical.com ?
<lifeless> vila: this starts to smell less like a pycurl bug with that data
 * lifeless goes again
<Fauli> jelmer: Done.
<jelmer> Fauli: thanks
<mwhudson> jelmer: what goes wrong in 1.9-rr?
<mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/git/trunk:)
<mwhudson> jelmer: also https://code.edge.launchpad.net/~vcs-imports/wine/git-trunk :(
<jelmer> mwhudson: in 1.9-rr xml-invalid characters are squashed
<jelmer> mwhudson: meaning that you need the cache for proper incremental imports
<vila> jelmer: I'd be happy to *help* release bzr-gtk but I don't know what need to be done to make a release
<jml> jelmer, thanks
<Tak> jelmer: good $timeofday
<jelmer> vila: there's a tasklist here: http://bazaar-vcs.org/bzr-gtk/releasing
<jelmer> Tak: hey
<Tak> I had the same bzr-svn error again yesterday :-/
<Tak> I couldn't find any cache dir to remove this time, but a rebase seems to have "fixed" it for now
<jelmer> Tak: please file a bug next time you hit it
<Tak> ok - I can't seem to reproduce it consistently - just a couple times I've gone to pull, and bam
<vila> jelmer: from http://bazaar-vcs.org/bzr-gtk/releasing, I can push a branch where 1-6 are done, I can then do 15-18, can you do 6-14 ? (12 and 13 being... optional it seems, see updated wiki)
<Pilky> did bzr get a new progress bar in 1.16?
<vila> Pilky: changes where made in that area yes
<Pilky> cool, it's a hell of a lot more useful than it was before :)
<vila> Pilky: compared with what ?
<Pilky> well I've got 1.10 on my main machine and it doesn't show as much info and seems to be kinda buggy, but 1.16 on my laptop seems more informative and not buggy
<Pilky> though I didn't realise I was that far behidn on my main machine
<vila> Pilky: oh, so, you just discovered the traffic blinken lights :)
<ramaral> Hello, I'm new to Bazaar. I was going through the tutorial (mini version) and tried to publish to my ftp website and got this error message "FTP temporary error 451:......." I noticed some of the files and directories were created on the ftp server but my version files were not copied. Can anyone help me resolve this?
<vila> ramaral: it would help if you say what is after the 451, if it's about appending, you're likely out of luck with a server that doesnt' support a feature bzr need
<ramaral> The stuff after the 451 error is "/Projects/myproject/.bzr/repository/upload/iqbx62....ftech: Append/Restart not permitted, try again. retrying."
<bialix> vila: bonjour
<vila> ramaral: exactly
<vila> bialix: hi !
<ramaral> vila: do you mean exactly I'm out of luck because my ftp server does not support append or you want the rest of the GUI that I truncated in the last message?
<vila> ramaral: your ftp server doesn't support append
<ramaral> OK, thanks for your help!
<bialix> vila: http://pastebin.com/m7f3976a3
<bialix> vila: any ideas why explicit URL gives this warning every time?
<bialix> it affects qpull (in qbzr)
<bialix> can I file a bug?
<vila> bialix: <shudder> because some code is stripping the the final '/' you carefully added :-/
<bialix> qpull reads saved URL and then run bzr pull with exact string
<bialix> and I've got this every time
<bialix> it makes bad impression (even for me)
<vila> then, the http server, being Apache, insists that you really should put a final '/' if you're talking about a directory, even if it knows damn well that the path is a directory
<vila> bialix: it's either a trivial patch or a tricky one, depending on how you look at it (I haven't in the last months, but lifeless and abentley discussed it and I seem to remember they ended up with a trivial, I don't remember why it was never submitted...)
<bialix> so, I'm file the bug. I hope it's possible to fix it in trivial way rather than tricky one
<bialix> https://bugs.launchpad.net/bzr/+bug/397046
<ubottu> Ubuntu bug 397046 in bzr "explicit URL for pull command: bzr eats trailing slash from URL and then complains about permanent redirection" [Undecided,New]
<abentley> vila: I don't remember.
<vila> abentley: what ? The fix or why it wasn't submitted ?
<abentley> vila: All I remember was agreeing that it should be fixed.
<vila> :)
<bialix> I don't find a similar bug report to mine
<jam> morning vila, bialix
<jam> btw vila, it seems "Review: approve" doesn't work anymore
<jam> you need to do "vote: approve"
<jam> (I've run into this a couple times where I approved something and LP didn't notice)
<bialix> jam: good day
<vila> I did it yesterday and it did work
<jam> vila: it didn't work here: https://code.edge.launchpad.net/~jameinel/bzr/1.17-rework-annotate/+merge/8281
<jam> not sure why
<vila> but the mail should be signed
<vila> rats, I forgot to sign that one too ???
<vila> I thought you got an error mail in that case but may be that changed :-.
<vila> jam: I'm reviewing your lru-cleanup, let's see
<vila> hmm, reading the help again: Note that you must start the command line with a space or your command will not be recognized.
<jam> vila: sure, I thought you had
<jam> I *think* vote is for the vote of the specific patch
<jam> and Review is the overall status of the merge request
<jam> so doing *both* is actually reasonable
<vila> vote (deprecated: use review)
<jam> vila: where is the help?
<vila> https://help.launchpad.net/Code/Review
<vila> and needs_fixing *really* sounds like tweak to me
<vila> approve: go ahead, merge, needs_fixing: merge with the little changes asked for, resubmit: too many changes asked for, I'd like to view the result
<vila> oh nice: reviewwer
<vila> oh nice: reviewer
<vila> or maybe tweak is really: review needs_fixing, merge approved
<jam> so it seems that "merge" is now the overall status
<jam> and "review" is the status of my personall review
<jam> also interesting
<jam> the "review" commands are actions
<jam> (approve, disapprove)
<jam> but the "merge" commands are *states*
<jam> (approved, rejected)
<jam> probably not the best design
<vila> review approve, merge rejected :-/
<vila> jam: it worked
<jam> bug #397049
<ubottu> Launchpad bug 397049 in launchpad-code "code review email interface inconsistent command types" [Undecided,New] https://launchpad.net/bugs/397049
<bialix> jam: I have no chance to test/review your patches for bzr-explorer in next few days, because I'm in the process of finishing urgent tasks before my vacation. I hope igc will be able to review them
<jam> bialix: no problem, I hope you have a nice vacation
<bialix> I hope too
<jam> a couple are pretty trivial, though
<bialix> it's a bit short -- only one week
 * bialix waves, need to go
<mgedmin> what was the name of that plugin that showed notification bubbles when people committed changes in your local LAN?
<mgedmin> something to do with bzr-avahi, no?
 * mgedmin plays with bzr help and find bzr lan-notify
<mgedmin> bzr commit-notify doesn't exist in my version of bzr-gtk :(
<jam> vila: I have to duplicate the line to get it into the finally block
<jam> what would you rather see?
<vila> wow, a new brain ?
<vila> if misread the else as being aligned with the try :-/
 * SamB wonders what happens when you use bzr-svn to commit a non-linear revision graph
<vila> I know, doesn't make sense
 * SamB supposes there's one way to find out ...
<vila> jam: then just a comment in the finally block that you want to ensure the node is warm enough
<jam> vila: yeah, I added finally comments
<jam> about why we are using them
<vila> ok
<SamB> warm? like, won't go out of cache?
<jam> SamB: moved to the front of the LRU in an LRUCache :)
<jam> vila: btw, I did end up inheriting from _py.Annotator in _pyx.Annotator, and it does simplify things a bit
<jam> so cheers for the idea
<vila> yeah !
<jam> It also meant I didn't need to create _NeededTextsIterator
<jam> to compensate for the fact that pyrex doesn't support yield
<jam> which is a fairly big win for complexity
<vila> regarding pyrex, I browse the archives a little bit but I wasn't convinced there was a lot of activity there... and I see a lot of references to cython, did you research cython yourself ?
<jam> vila: cython is a fork of pyrex that sounds "better", I believe bialix uses it and like its
<jam> that said
<jam> it wasn't as widely available
<jam> (as in, no packages for Ubuntu)
<jam> pyrex is basically maintained by 1 person that wants fairly strict control over it
<jam> as he wants to understand everything that goes into the codebase
<jam> cython is (AIUI) maintained by many people
<jam> so if we were to go to the effort of packaging our own thing
<jam> we should certainly consider switching to cython
<jam> vila: certainly the 0.9.8 stuff (supporting "cdef list foo" was brought into pyrex from cython)
<vila> ouch
<jam> vila: http://wiki.cython.org/FAQ#WhatistherelationbetweenCythonandPyrex.3FArethebarriersbetweenthetwobasedontechnicaldirection.3FDifferinggoals.3F
<jam> though I think the "for x in blah" was also brought into pyrex
<vila> ok, I'm printing the Cython manual and willl read it at night
<vila> jam: blah that url is unreadable :)
<jam> vila: first item on:
<jam> http://wiki.cython.org/FAQ
<vila> jam: kidding, the page *is* readable :)
<jam> autogenerated urls... yummy
 * SamB curses Debian and/or GNU for the lack of bash.info, even in non-free ...
<vila> jam: If we go to the point where we archive the .c files, we'll get also lower the constraints on the tool we chose...
<jam> vila: as long as you can make versioning auto-generated files palatable
<jam> which seems to be the bigger issue
<vila> jam: I agree. But does cython suffers from the same problem ?
 * mgedmin finds bzr-notify
<jam> vila: cython shares enough history with pyrex that I'm 75% sure it does
<jam> on the plus side, cython uses Launchpad's bug tracker :)
<jam> though the user mercurial as the VCS
* garyvdm changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jam> hmm.. looks like they might be packaged in Jaunty
<jam> given that they have some [jaunty] bugs :)
<vila> 0.10.3 in jaunty, bug they seem to use trac not launchpad...
<jam> vila: well their wiki points you to answers.launchpad.net
<vila> jam: yeah, weird
<jam> oh, it also seems that pyrex is pure python, while cython bootstraps itself
<jam> vila: so I still see absolute paths in the "cython.py foo.pyx" output
<jam> so yes, they suffer the same issue
<vila> hmm
 * vila EDOing
<jam> sure
<jam> going a bit further, they even include the code snippets in the output
<jam> which means it is a bit bigger, and changing line 10 causes noise in the diff for line 11's comment
<garyvdm> Hi bialix
<garyvdm> Hi amanica
<amanica> garyvdm hi!
<amanica> garyvdm: nice new photo..
 * bialix bbl
<ramaral> User question: I'm test driving bazaar following the mini tutorial. I've created a local repository and pushed it onto an ftp server. I'm having trouble getting those files from the server. The files were pushed to ftp://<server name>.com/Projects/myproject, I'm trying to get them into a different local directory (simulating a different user) like this "bzr branch http://<server name>.com/Projects
<ramaral> /myproject. I get the error "ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for http://<server name>.com/Projects/myproject". Help?
<amanica> ramaral: I assume you didn't use svn at all for this, and that you have the bzr-svn plugin installed?
<ramaral> amanica: Yes, no SVN. I can only assume I have a bzr-svn pluggin. I installed the Windows version of Bazaar. I was surprised to see references to SVN.
<amanica> ah, ok yes it is bundled with that afaik
<amanica> this sounds like a bug I saw
<amanica> you can try: "bzr --no-plugins branch http://<server name>.com/Projects/myproject. "
<amanica> (space before the last .)
<ramaral> OK, let me try that, one min...
<ramaral> amanica: Now I get "ERROR: Not a branch : http://<server name>.com/Projects/myproject". For server name should I be using "www.<server name>.com" or "ftp.<server name>.com"
<amanica> can you browse the http site you are trying to branch from/
<amanica> is it shared over ftp and http?
<ramaral> I'll try that too a little later, have a meeting now...thanks amanica
<amanica> ok ramaral, np
<bialix> garyvdm: hi
<schmichael> somehow i've got my branch set with a "submit branch: ."
<schmichael> sp now merge is using "." by default instead of my parent branch
<schmichael> s/sp/so
<schmichael> i'm not even sure what a submit branch is or (more importantly) how to get rid of it
<schmichael> it appeared when i was playing around with "bzr merge --preview"
<bialix> schmichael: use merge PATH --remember to override it
<schmichael> bialix: any clue how i caused it?  or what a submit branch is?
<bialix> ÑÑ
<bialix> no
<bialix> schmichael: maybe you playing with `send` command?
<schmichael> nope, just merge...
<schmichael> weird huh?
<bialix> weird? sometimes it makes sense to look at commands history
<dgoulet> hello people, is it possible to create a branch but with a revision history reset ? (not getting the revision history)
<bialix> bzr init?
<dgoulet> without*
<dgoulet> oups sorry, from an existing repo
<dgoulet> bzr branch from an existing repo but without the history
<dash> dgoulet: why create it in an existing repo if you don't need the history in that repo?
<dash> a repo is just a collection of revisions :)
<dash> (mostly)
<dash> 'bzr init' sounds right to me
<dgoulet> the point is that I have some standard file in a bzr repo. I want to create a branch from that to get these "default file" but without getting the 18673 revision history
<dgoulet> because some file previously deleted or uncommit might be confidential
<dgoulet> are you following me?
<dash> hmm, do you perhaps want 'bzr export'?
<dgoulet> yep but then I can't make anymore diff with the parent repo  right..?
<dash> right
<dash> wait
<dgoulet> that's my problem
<dgoulet> I want to be able to diff
<garyvdm> bialix: I'm looking at bug 395817. I think the fix will be in pipeline, and not qbzr.
<ubottu> Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatable." [Medium,New] https://launchpad.net/bugs/395817
<dash> dgoulet: then you need the history
<garyvdm> bialix: Any thing that I can help with?
<garyvdm> Update NEWS.txt?
<bialix> garyvdm: I'm thinking what should be in NEWS
<bialix> yeah!
<bialix> you read mymind
<bialix> my mind
 * bialix tired a bit
<schmichael> bialix: its a bit embarrassing, but here's my bash history :) http://dpaste.com/64664/
<schmichael> somewhere around 507, "submit branch: ." was added (afaict)
<bialix> schmichael: have no idea
<bialix> I don't think it's horrible bug
<dgoulet> ok well... to be able to make a diff we need a "common ancester" so there is no way we can connect the first revision of the new branch to the last revision of the main repo ? hehe
<bialix> you can always override this settings or even delete it (see .bzr/branch/branch.conf file)
<schmichael> bialix: thanks for your help!
<bialix> dgoulet: -r0..N is the trick
<dash> dgoulet: so you want a branch who shares history with another branch, but doesn't share history with another branch? :)
<dash> dgoulet: perhaps your problem is not with bzr :)
<dash> dgoulet: if the issue is just downloading all the history to a remote host, there are stacked branches and lightweight checkouts
<bialix> garyvdm: revno 785: it's about compatibility with bzr 1.17?
<garyvdm> bialix: Yes
<bialix> I'll mention it in the NEWS then
<garyvdm> And rev 787
<bialix> what's 790?
<bialix> it was bug?
<bialix> or just regression?
<bialix> garyvdm: thanks for fixing revno painter!
<garyvdm> Cool - but it was not me - it was luks
<bialix> rats
<bialix> sorry luks: many thanks to you
<dgoulet> dash: lightweight checkout consist of?
<dash> dgoulet: a working tree and a reference to a remote branch
<dgoulet> ok right
<bialix> garyvdm: so here is news: http://pastebin.com/mf7817af
<bialix> is there anything I'm missing?
<dgoulet> but let me be clear (might be confusing...). There's a repo bzr on a server A containing files and a very large number of revision (over 18000). What I want a do is to create a branch from that repo on a server B BUT without getting all revision history but still having a link to the parent branch so I can make diff
<dgoulet> clearer? lolo
<dash> Right!
<dash> so maybe you want a stacked branch
<dash> which you can make local commits to, but doesn't store all history
<dash> instead it references a different branch as its parent
<garyvdm> bialix: Re:790 I added the feature before 0.10 (rev 720) but broke it before 0.10 (rev 729) - So we should mention it as a new feature.
<dash> when it needs data from the remote branch, it fetches it.
<dgoulet> I see
<garyvdm> bialix: I would like to add some detail.
<bialix> garyvdm: "Working Tree" label in qannotate looks a bit strange
<dgoulet> I found the page on doc.bazaar seems very interesting
<dgoulet> thanks a lot dash! much appreciate!
<bialix> garyvdm: I can commit my version and you'll have a chance to improve it, or you prefer pastebin your version?
<garyvdm> bialix: Commit it. I use a tool bzr that is great for merging stuff like this ;-)
<bialix> re revno 790: I was under impression it should open new qannotate window. but peraps from speed POV it's better reuse existing data
<bialix> log should be updated then I suppose
 * bialix committing NEWS
<garyvdm> I don't change log, because otherwise it's not possible to go back forward.
<garyvdm> bialix: I'm not sure what you mean about "Working Tree" label in qannotate.
<bialix> in left bottom corner where graph of revisions shown
<bialix> last revision marked with Working Tree lable (on blue background)
<bialix> pushed
<dgoulet> dash: with stacked branch you can still have all history with bzr log
<bialix> garyvdm: run qannotate for qbzr/__init__.py
<bialix> latest revno is 808
<bialix> but latest change for this file was in revno 781
<bialix> but revno 781 is marked in qannotate as Working Tree
<dash> dgoulet: correct
<garyvdm> qlog does that if you working tree tip is different from the branch tip.
<bialix> it's wrong
<bialix> garyvdm: I'm working in lightweight checkout
<dash> dgoulet: that's what you were asking for
<dgoulet> lol no the contrary :P
<bialix> garyvdm: so in reality I have 2 wt for one branch
<dgoulet> on the branch, I need NOT to see the log (revision history) ;)
<dash> dgoulet: if you can't read the log you can't make diffs
<bialix> there is used wrong wt
<dgoulet> but still having a link to the parent branch
<dgoulet> ;)
 * bialix checks
<dash> dgoulet: make up your mind :)
<dgoulet> okok well that's my problem...
<dgoulet> so I think what I want to do is not possible
<dash> why do you want this?
<bialix> garyvdm: anyway qannotate wrong: in my branch wt at revno 782, not on 781
<garyvdm> bialix: Hmmm - What qlog does is if there is are revisions filtered, and the tip is filtered, then the label for the tip is moved down to the next visible ancestor.
<garyvdm> that was to fix bug....
<dgoulet> concept of having a "reference copy" of files and getting these file for client but if the history comes with it ... security issue ;)
<bialix> for WT label it's maybe counter-intuitive
<dgoulet> but if the client modify something on is branch, I want to be able to make diff from the "reference"
<dgoulet> his*
<bialix> garyvdm: there is similar bugs when running qlog on shared repo: lables for merged branches tips shown incorrectly (for mainline revisions)
<dash> dgoulet: oh, so you don't actually need to make checkins
<dash> dgoulet: from that reference copy
<bialix> garyvdm: I don't want to block this release
<bialix> but it's looks not very good
<dash> dgoulet: use bzr export; when you want to produce a diff, copy their version into the working copy of a branch :)
<garyvdm> bialix: This feature was to fix bug 273311
<ubottu> Launchpad bug 273311 in qbzr "qlog FILE with pending merges: no "Pending Merge" label" [Medium,Fix released] https://launchpad.net/bugs/273311
<bialix> :-/
<dgoulet> that's a solution but diff does'nt consider deleted files or permission right?
<bialix> garyvdm: ok, I'll try to raise this q again after vacation
<garyvdm> ok
<dash> dgoulet: well. delete all the files in the wc then copy in your clients' code :)
<bialix> garyvdm: pushed again (translations update)
<garyvdm> ok
<dgoulet> well that's was the plan B hehe
<dgoulet> thx again
<bialix> garyvdm: please use https://code.launchpad.net/~qbzr-dev/qbzr/0.12 to merge 0.12-specific changes
<garyvdm> ok
<garyvdm> bialix: How do we describe rev 791 (revno painter)?
<bialix> there was bug
 * bialix bbl: House MD on TV
<garyvdm> qlog/qannotate/qbrowse: Revision numbers are right aligned on the mainline number.?
<lamalex> Can you guys help me chose a merge algorithm? the default one is giving tons of conflicts and im wondering if using a different one will help
<bialix> garyvdm: fine for me
<garyvdm> And I gave an example...
<garyvdm> bialix: I just pushed some changes for lp:~qbzr-dev/qbzr/0.12
<garyvdm> bbl
<bialix> ok
<bialix> garyvdm: so I'm ready to call it release
<lamalex> anyone able to help me with this merge?
<bialix> lamalex: what's up
<lamalex> bialix: I think a different merge algorithm would help me complete this merge, but im not sure what to pick
<bialix> did you saw message about criss-cross?
<lamalex> no, i know how tohandle that
<lamalex> give me a minute, im describing
<bialix> there is only 2 algorithms: merge3 and lca
<lamalex> in the branch im merging into mine, many files that i have edited were renamed and have small edits. Our edits dont conflict however. If I rename all of my files into the same name as the new ones, i get conflicting code paths for every file- no good. if i just merge i get text conflicts
<dash> lamalex: were the files renamed using 'bzr mv'/'bzr rename'?
<garyvdm> bialix: cool
<garyvdm> jam: I'm not sure why. I started using fireGPG, and on all of your mails, it say "Wrong signature".
<lamalex> dash: looking.. not sure off hand but i think so
<jam> bialix: and --weave
<jam> which IMO is better than --lca
<bialix> jam: in my experience lca is better for criss-cross
<jam> bialix: than --merge3 yes, than --weave probably not
<jam> bialix: especially given that I did a lot of work on it for mysql
<bialix> for me: better, but it's just for me
<bialix> sometimes weave produce wrong conflicts
<lamalex> dash: actually no, it doens't appear to be the case
<dash> lamalex: that's a significant problem then
<lamalex> maybe i can bzr mv --after them now..
<bialix> but you know better, of course
 * lamalex kills the person who did the renaming
<jam> bialix: so a while back --weave was utterly broken
<jam> I don't know if you used it since I worked on it
<bialix> I don't know when you worked on it
<jam> bialix: ~ earlier this year
<bialix> I've not used --weave about a year maybe
<bialix> will check it next time when I have some conflicts, thx for the info
<lamalex> dash: think it's possible to reverse cherrypick the commit that did the mvs, then redo it with bzr mv?
<dash> maybe
<dash> if i knew what "reverse cherrypick" meant
<lamalex> pick the commit out
<lamalex> pretty sure thats the term used in the docs..
<lamalex> dash: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking
<bialix> jam: one question: if I tag new qbzr release as `release-0.12' instead of `release-0.12.0' it will be ok for your build bzr.exe release script?
<RenatoSilva> lifeless: hi, about our encoding talk... I did the following...
<jam> bialix: Whatever you name it is what I'll put into build_release.py
<jam> so right now I believe I use '0.11.0'
<jam> but I can put '0.12' in there just as easily
<bialix> ok
<RenatoSilva> lifeless: there's a cmd.getStandardOutput() in the Java plugin. It is an XML, so I read the ascii preamble, get the encoding, change the XML itself to bytes form, then I decode it using the detected encoding. It is xmloutput's compromise to ensure that preamble and data encoding match.
<RenatoSilva> verterok: hi Guillermo. I've sent you a new branch to fix encoding in log view. Please forget what I said about the python-like string inside CDATA. It's not python-like, it's really an actual string. I was just confused by python's prompt when I decoded the base64 message...
<verterok> RenatoSilva: yes, I got the email. thanks!
<verterok> RenatoSilva: np :)
<verterok> RenatoSilva: I'll take a look to it tonight
<bialix> qbzr 0.12 released
 * bialix -> sleeps
<mwhudson> jam: would a complaint along the lines of "annotate often fails on stacked branches" surprise you?
<lamalex> how can I merge all revision since rev X
<lamalex> bzr merge -r X branch
<lamalex> ?
<jam> mwhudson: I would be shocked and appalled that you would even hint at such a thing :)
<mwhudson> hmm seems to be https://bugs.edge.launchpad.net/bzr/+bug/393366
<ubottu> Ubuntu bug 393366 in bzr "KeyError in knit.simple_annotate running annotate on a stacked branch" [High,Confirmed]
 * mwhudson comments
<lamalex> anyone got a suggestion for my merge question?
<lamalex> bzr merge -r X.. branch
<lamalex> ?
<NfNitLoop> I dunno, try 'bzr help merge'?
<NfNitLoop> generally I don't specify revisions.
<NfNitLoop> Just bzr merge branch.
<NfNitLoop> it figures out what needs merging.
<lamalex> NfNitLoop: yah tried --help
<lamalex> doesnt say and im not sure
<mwhudson> lamalex: yeah, merge -r x.. should do it
<mwhudson> it'll do a cherry pick though, not a true merge
<mwhudson> you can also merge -r ..x, bzr revert ., bzr commit (this is called a "null merge"), then merge normally
<lamalex> does one have any advantages over the other?
<lamalex> mwhudson: and just to be sure, that will merge [X,..] or (x,..]
<RenatoSilva> verterok: a note about my stacked branch: the encoding comes as cp1252 (not static utf-8 anymore ok) but the data as cp850
<RenatoSilva> verterok: in terminal I mean
<mwhudson> lamalex: if you'll be wanting to merge from the branch again, the null merge approach is probably better
<mwhudson> um, ranges are inclusive start exclusive end for merge i think
<NfNitLoop> not according to `bzr help merge`
<NfNitLoop> start exclusive, end inclusive.
<NfNitLoop> 81..82 will get the changes introduced by 82.
<mwhudson> ah right yes
<lamalex> mwhudson: for that null merge did you mean x.. or ..x
<lamalex> maybe i should just describe the problem :)
<mwhudson> lamalex: i meant ..x
<mwhudson> lamalex: yeah, that's probably a good idea
<lamalex> So we had someone add/remove a bunch of files instead of bzr mv them
<NfNitLoop> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<lamalex> this was a few commits back, i'm trying to undo what they've done so that i can cleanly merge with a branch that touches those files and was branched before their work
<NfNitLoop> "Unlike a normal merge, Bazaar does not currently track cherrypicks. In particular, the changes look like a normal commit and the (internal) revision history of the changes from the other branch is lost."
<mwhudson> lamalex: urgh
<lamalex> NfNitLoop: I'm not sure if oyu're talking to me, but that's irrelevant.
<NfNitLoop> ok.
<lamalex> so pleas shut up, you're not being helpful. I've read the docs- I'm asking because this is complex
<mwhudson> lamalex: so if x is the branch
<mwhudson> lamalex: that's a bit harsh, NfNitLoop is trying to help too
<lamalex> which branch :P
<mwhudson> lamalex: if x is the revision that screws things up
<lamalex> mwhudson: you're right. NfNitLoop sorry, im strsessed out trying to fix this
<mwhudson> lamalex: i think you can bzr merge -r x..(x-1) .; bzr ci; to undo the messy revision, then merge
<mwhudson> if there have been changes to the files added/removed since the messing up, you're somewhat doomed i think
<mwhudson> well not doomed, but it's going to be a fiddle
<lamalex> there's the guilty party
<lamalex> mwhudson: so there are 3 commits (theyre sequential) i want to cut out that
<lamalex> no, 2
<mwhudson> lamalex: do subsequent commits change the files that were touched by the commits you want to revert?
<lamalex> 631 and 632, so I would want to bzr merge -r 632..630 .
<mwhudson> lamalex: yes
<lamalex> mwhudson: yeah, these merges touched MANY files
<lamalex> like, at least 1 in every dir
<mwhudson> that merge command will probably conflict then
<lamalex> do you think it's possible to branch at the last good before the bad, do the rename, then merge the ones after the bad?
<dash> quite likely
<mwhudson> yesh
<mwhudson> that's probably a good idea, actually
<mwhudson> man this would be easier to explain with a whiteboard :)
<lamalex> :)
<lamalex> there isprobably some collabo software we could use
<mwhudson> yes, but that would not be easier, i expect
<lamalex> haha indeed
<NfNitLoop> Oh, yeah, that's what I'd do.
<NfNitLoop> If it had just been the *last* commit...
<NfNitLoop> there's the handy "Uncommit" command. :)
<mwhudson> yeah, the earlier you find these problems the easier, for sure
<lamalex> indeed
<NfNitLoop> you could in theory uncommit twice, if you have a way to reapply the 3rd patch.
<lamalex> this is autofoo type stuff
<NfNitLoop> autofoo?
<lamalex> so we tend to not review it that hard since RAOF is the only one who /really/ understands
<mwhudson> lamalex: i think it's possible that bzr-rebase's replay command will be useful here, but i've never used it
<lamalex> hm ill look at that
<lamalex> ugh
<lamalex> merge failed
<lamalex> Conflict because Zim is not versioned, but has versioned children.  Versioned directory.
<lamalex> Conflict: can't delete Zim/Resources because it is not empty.  Not deleting.
<lamalex> repeated many many times
<garyvdm> I have not been following this to carefully, so this might not be relevant, but rebase uses file-ids and not paths - so I don't think it will help
<NfNitLoop> you deleted files in r2, then readded them in r3?
<lamalex> is there a bzr log flag to just show what files changed and not the diff?
<lamalex> i guess like a diffstat
<lamalex> NfNitLoop: i think that's what happened in the revs i'm trying to fix
<lifeless> bzr log -v ?
<lamalex> lifeless: yes, wow thank you
<lamalex> so simple
<lamalex> so am i just totally fscked?
<NfNitLoop> well, you have history up to 3 revisions ago.
<NfNitLoop> you can always get your tree before it got all mucked up.
<NfNitLoop> and a tree after the fact.
<NfNitLoop> and do a manual merge.
<NfNitLoop> if you're on linux, I recommend 'meld'. :)
<lamalex> that's essentially being totally fscked
<NfNitLoop> why's that?
<lamalex> because that's a lot of work, more work than not fixing this issue and merging the branch that is the reason im trying to fix this manually
<lamalex> which is also a lot of work
<lamalex> but less than this
<lamalex> hmm.. when I merge my top part of the tree, the ones after it got mucked, it basically deletes EVERYTHING
<NfNitLoop> well, if you've made so many changes to the source tree in one revision that the one prior can't be cleanly reverse-merged...
<lamalex> why the hell would it be doing that
<NfNitLoop> then, yeah, you're out of luck.
<NfNitLoop> but that's the case with any SCM.
<NfNitLoop> "merge the top part of your tree"?
<lamalex> the commits after the botched ones im trying to fix
<lamalex> tree looks like this: 1---630 | 631, 632 | -- HEAD
<lamalex> I want to cut out 631, 632 and replace them with a commit that effecively does the same thing
<lamalex> but does it sanely, at 632 the tree would look the same, only have a slightly different history
<lamalex> s/at 632/after 632
<NfNitLoop> so you're trying to change the history, but leave the file contents as-is?
<lamalex> effectively
<NfNitLoop> OH.  that's not what I was understanding earlier.
<NfNitLoop> Hrmm.
<NfNitLoop> Oh, but in 631 you removed some files, and in 632 you re-added them?
<lamalex> In 631 a bunch of files were added, I actually have no idea how they were added, probably via some weird script RAOF wrote. They're basically copies of some other files with the same minor change to each one
<lamalex> then in 632 the old ones were removed
<NfNitLoop> That sounds fine.  WHy are you trying to rewrite history?
<lamalex> so what should have been a bzr mv, edit, commit was something like copy, edit, commit, remove
<NfNitLoop> right.
<NfNitLoop> It's total SCM fail.
<NfNitLoop> but, it's done.
<lamalex> right, and im trying to find a way t fix it
<dash> NfNitLoop: but now he needs to merge
<NfNitLoop> aha.
<NfNitLoop> So, yes, to fix it, you're going to have to do it the right way.
<NfNitLoop> create a branch at r630.
<NfNitLoop> write a script to do the renames.
<NfNitLoop> via bzr.
<lamalex> right, this is easy
<NfNitLoop> and then do a cp -r to copy the new changes on top of them.
<NfNitLoop> and commit.
<lamalex> wait, cp -r to what?
<NfNitLoop> then throw away the broken branch and shoot the idiot that caused that issue. :p
<NfNitLoop> so, say you've got broken_head/
<NfNitLoop> bzr branch broken_head fixing -r 630
<lifeless> NfNitLoop: you know we have a heuristic now?
<NfNitLoop> lifeless: a wha?
<NfNitLoop> lamalex: cd into fixing/ and run your script to do bzr mv commands.
<lifeless> 'bzr mv --auto'
<lifeless> lamalex: heres what I suggest:
<NfNitLoop> lifeless: Oh, nice!
<NfNitLoop> <3 you guys. :D
<lamalex> lifeless: that's cool to know
<lifeless> bzr branch -r 630 foo bar
<lifeless> bzr diff -r 630..632 foo | patch -p0
<lifeless> bzr mv --auto
<NfNitLoop> hot!
<lifeless> poke around, it should be right
<lifeless> bzr commit
<lifeless> bzr replay -r 631.. foo
<lifeless> erm actuallly the last one will fail
<lamalex> where does replay come from?
<lifeless> so just manually (bzr diff -c 632 | patch -p0), repeat
<lifeless> commit
<lifeless> diff -c ...
<lifeless> through any remaining commits
<garyvdm> lamalex: bzr-rebase plugin
<lamalex> ah, is there a version that works with 1.16?
<lamalex> the one in the jaunty repo doesn't
<NfNitLoop> lifeless: he's saying to do diff | patch, anyway.
<NfNitLoop> so you don't need replay.
<lifeless> lamalex: ^^
<lamalex> lifeless: so i need to bzr diff -c N for each rev until HEAD?
<lifeless> lamalex: bzr diff -c N | patch -p0; commit
<lifeless> lamalex: and yes, for 632, 633 etc
<lamalex> lifeless: so i branch -r 630 foo bar
<lamalex> do my renames
<lamalex> i need to give bzr diff a --old dont I?
<lifeless> lamalex: no
<lifeless> to do the renames do
<lifeless> bzr diff -r 630..632 old | patch -p0 ; bzr mv --auto
<lifeless> that should pick them all up for you
<lamalex> lifeless: so i dont branch foo bar?
<lifeless> you do
<lifeless> I skipped that step :P
<lamalex> right, so do i have to do the renames that way?
<NfNitLoop> the diff|patch does the renames.
<lamalex> i already have a bash line in my history that does the renames
<NfNitLoop> actually, the diff|patch will re-move the files...
<lifeless> lamalex: it does the renames and the first change
<NfNitLoop> but before you commit, you do: bzr mv --auto
<NfNitLoop> which does the renames automatically.
<RenatoSilva> verterok: about what I said: "a note about my stacked branch: the encoding comes as cp1252 (not static utf-8 anymore ok) but the data as cp850"...
<RenatoSilva> verterok: it is calling osutils.get_user_encoding() instead of bzrlib.user_encoding
<verterok> RenatoSilva: ok, osutils.get_user_encoding is the preffered way, bzrlib.user_encoding is deprecated
<lifeless> http://pastebin.com/m5fdf57c1
<verterok> RenatoSilva: the xmlrpc service handle that, so it should use utf-8
<RenatoSilva> verterok: really? then all the other code generating xml needs to change , xmllog is the only using osutils.get_user_encoding().
<lifeless> verterok: you probably *don't* want to autodetect user encoding though, if you want to specify always-utf8-output
<lamalex> lifeless: all of those bzr diff commands will fail
<lifeless> lamalex: why?
<lamalex> you dont hvae a 63X in your tree
<lamalex> you branched at 630
<lifeless> argh
<lifeless> I missed the path
<NfNitLoop> lamalex: he means bzr diff t"damaged"
<verterok> RenatoSilva: probably :)
<NfNitLoop> or, ../damaged
<lifeless> http://pastebin.com/m1084f4e
<RenatoSilva> verterok: but notice that osutils.get_user_encoding() is returning cp1252, but xmllog is returning cp850 data (from terminal)
<verterok> lifeless: xmloutput don't detect encoding, it's actually hack, but it set the osutils,_cached_user_encoding ;)
<RenatoSilva> verterok: this makes the xml document invalid
<verterok> RenatoSilva: in the terminal, the encoding is detected
<verterok> RenatoSilva: only in the xmlrpc service is forced to utf-8
<RenatoSilva> verterok: I'm running manually, no xml-rpc
<lifeless> RenatoSilva: thats really bad :(
<lifeless> sorry
<lifeless> verterok: ^^
<lifeless> because, your service is unfriendly to other bits of bzr that way
<verterok> lifeless: yes, as the xmlrpc is running commands and processing the output
<verterok> lifeless: my idea is to move out from executing commands over the xmlrpc service, and instead publish real xmlrpc methods
<RenatoSilva> verterok: I open a terminal, which is cp850, then I run bzr xmllog, then I get a preamble <?xml [..] encoding="cp1252"?>, however the whole output itself is cp850...
<verterok> RenatoSilva: xmllog don't fiddle with encoding, only the xmlrpc service
<verterok> lifeless: the only *real* xmlrpc methods published ATM is search
<lifeless> verterok: heheheh
<verterok> lifeless: and the one bzr-eclipse uses is run_bzr_xml
<RenatoSilva> verterok: even if you put cp850 in preamble, it seems that cp850 is an invalid value for an XML document, that is, you need to ensure that any detected charset has a compatible name. In my case, the preamble could declare cp850, it would be still an invalid XML documet anyway (I can't open it with the browser).
<verterok> RenatoSilva: Firefox? or IE?
<verterok> lifeless: run_bzr_xml is a wrapper around commands.run_bzr that returns xml version of the exception in case of error
<verterok> lifeless: that's the main issue with the xmlrpc service, we need to move it to pure methods :)
<lifeless> verterok: so arguably the bug is that this variable is global state and not a Command attribute?
<verterok> lifeless: I don't think so, in this case RenatoSilva is executing from the terminal, and xmllog uses the info provided by bzr, maybe something is wrong with the way encoding is used or detected in xmllog
<verterok> lifeless: the only place that xmloutput changes global state is the xmlrpc service started with: bzr start-xmlrpc
<lifeless> verterok: but RenatoSilva is doing this to test for bzr-eclipse, which does use the service ;)
<verterok> lifeless: yes, but now he is testing in the terminal
<verterok> RenatoSilva: ?
<verterok> ^ right?
<lifeless> so I'm saying that encoding results in the terminal don't help testing what the service does ; )
<verterok> :)
<RenatoSilva> verterok: a monet pelase...
<verterok> lifeless: for testing the service, besides the small tests, there is an example of a python xmlrpc client ;)
 * verterok need to write more tests
<RenatoSilva> verterok: reading...
<lamalex> wonderful, some of this involves binary files
<RenatoSilva> verterok: xmllog don't fiddle with encoding, only the xmlrpc service --> it is responsible too as it declares a preamble :)
<lifeless> lamalex: urggle. Many?
<verterok> RenatoSilva: yes, but XMLLogFormatter is using osutils.get_user_encoding() to set the encoding in the preamble
<verterok> RenatoSilva: and looks like isn't encoding the output :)
<lamalex> lifeless: not sure honestly, ill figure it out though
<RenatoSilva> verterok: IE says cp850 is invalid, FF ignores it and tries to decode as latin-1.
<RenatoSilva> verterok: ...
<verterok> RenatoSilva: ok, thanks
<verterok> RenatoSilva: I think the problem is that the message in the CDATA isn't encoded explicitly
<RenatoSilva> verterok: yes I'm testing in terminal, no xml-rpc!
<RenatoSilva> s/monet/moment
<verterok> RenatoSilva: would you try this patch? http://bazaar.pastebin.com/m2ec81e83
<RenatoSilva> verterok: es, but XMLLogFormatter is using osutils.get_user_encoding() to set the encoding in the preamble ---> either it should encode data with get_ser_encoding(), it it should put the current encoding (terminal) in the preamble
<lamalex> lifeless: mwhudson: NfNitLoop: thanks so much for your help
<RenatoSilva> verterok: in the latter case if would break the XML in my case anyway....
<verterok> RenatoSilva: right
<mwhudson> lamalex: np, did you get somewhere in the end?  work distracted me
<lamalex> mwhudson: yah, lifeless helped me solve it
<lamalex> not full-auto
<RenatoSilva> s/it it/or it
<mwhudson> cool
<lamalex> but semi
<RenatoSilva> verterok: about the patch, actually it's line 169
<RenatoSilva> verterok: I get an UnicodeDecodeError
<RenatoSilva> verterok: non-ascii chars in the message, to check encoding behavior
<verterok> RenatoSilva: ok, that's what I wanted to know
<RenatoSilva> verterok: sorry, IE says it does not support *cp1252*
<RenatoSilva> verterok: how about this...
<verterok> RenatoSilva: I don't know how much this is going break (don't know how many people is using xmloutput via the cli), but we could do the "always utf-8" encoding for all commands
<verterok> ar at least add a --encoding arg to all xmlcommands
<verterok> *or
<verterok> so the user can specify what encoding to use, but use utf-8 by default
<RenatoSilva> verterok: how about this patch: http://pastie.org/539361
<verterok> RenatoSilva: that's the terminal encoding right?
<RenatoSilva> verterok: IE deals with cp850 correctly, but FF does not. No error is raised, but it thinks it's a latin-1 XML, ignoring the preamble.
<RenatoSilva> verterok: not necessarily, it's the same encoding of the place where I'm writing
<verterok> RenatoSilva: if this works on windows, I'm ok with it :)
<garyvdm> I want to define 2 classes with the same name for a test. Is there a way to have a sub module in the same file in python ?
<RenatoSilva> verterok: data destination is to_file, and I'm guessing to_file.write is using to_file.encoding
<dash> no
<dash> why should they have the same name?
<verterok> RenatoSilva: I think so
<garyvdm> dash: I'
<garyvdm> dash: I'm testing the decorating of commands.
<garyvdm> and the command registory get the name of a command from class.__name__
<RenatoSilva> verterok: well it is right? even if you overwrite to_file  with codecs.getwriter, such a writer will set encoding prpoperty porperly, right? The only exception if if you put a dog acting a a duck, I mean, you change to_file with a self class containing a write method, but I don't think you have stuff like this in the code, I guess :)
<verterok> RenatoSilva: yes :)
<RenatoSilva> s/if if/is if
<RenatoSilva> s/prpo/prop
<RenatoSilva> s/a a/as a, sorry!
<RenatoSilva> verterok: yes you have, or yes you don't? :)
<verterok> RenatoSilva: yes, xmloutput don't have such code :)
<RenatoSilva> verterok: ok then I think the patch is fine
<RenatoSilva> verterok: the problem with trying to always use utf-8 in preamble is that you have to ensure that the data will also be the same, and I can't figure out a way to make to_file behave like this. If you use codecs.getwriter, then it will fail when receiving str objects. AFAIK to_file is provided by the super class from bzrlib, and as such other "guys" may be writing str objects to the file...
<RenatoSilva> verterok: out of xmloutput control
<verterok> RenatoSilva: yes, it's a but tricky, I think that using your patch would solve the terminal issues, regarding the xmlrpc service, I think using the encoding specified in start-xmlrpc (once de patch lands in trunk) should solve the issues with bzr-java-lib (plus your patch)
<garyvdm> For tests, is it ok to call self.addCleanup from setUp?
<verterok> RenatoSilva: if someone is writting bad data to the to_file, I'ld say that's a bug :)
#bzr 2009-07-09
<RenatoSilva> verterok: currently to_file expects str, if we change it with codecs.getwriter, it would now expect unicode
<RenatoSilva> verterok: btw, why do you use xml-rpc in java plugin? why not talk directly with xmloputput?
<verterok> RenatoSilva: I got lost :)
<verterok> RenatoSilva: directly how?
<RenatoSilva> verterok: currently to_file expects str, if we change it with codecs.getwriter, it would now expect unicode, and that py2 auto ascii encode/decode thing would get place, and would raise errors for non-ascii stuff...
<RenatoSilva> verterok: I mean for example
<RenatoSilva> verterok: you want to pull branch's log, then why not you run bzr locally and parse the XML response? why do you have to send an xml-rpc call to a local server, then get the response and parse it?
<RenatoSilva> verterok: the server runs bzr locally anyway
<verterok> RenatoSilva: mainly for performance reasons
<verterok> RenatoSilva: the startup time in windows is terrible
<RenatoSilva> verterok: you mean xml-rpc server keeps the executable in memory?
<verterok> RenatoSilva: I'll take a look to the codecs.getwritter, don't have the code fresh enough in my head
<verterok> RenatoSilva: right, only oone bzr process
<verterok> *one
<RenatoSilva> verterok: there isn't a way to do this in java?
<RenatoSilva> verterok: if python does, java does it too ^^
<verterok> RenatoSilva: hmm...what?
<RenatoSilva> verterok: the plugin could load bzr.exe into memory
<verterok> RenatoSilva: we need to use bzrlib API
<RenatoSilva> verterok: oh I see, bzr-java-lib...
<verterok> RenatoSilva: I'm missing something, could you extend? :)
<RenatoSilva> verterok: you mean start bzr.exe every time you need to run a command is too slow, so you put xml-rpc server in scene for keeping one executable in memory, and run the commands faster, right?
<verterok> RenatoSilva: yeap, exactly
<verterok> RenatoSilva: take a look to the different *Runner's in bzr-java-lib
<RenatoSilva> verterok: I don't have the code right now...
<verterok> RenatoSilva: the XMLRpc extends the CommandLine
<RenatoSilva> verterok: my idea was, when the plugin is loaded, it loads the executable into memory.When it wants to run something, then it activates bzr-java-lib, and passes the cached executable, so that bzr-java-lib does not have to start the proccess.
<RenatoSilva> verterok: both bzr-eclipse and bzr-java-lib would need changes in the code to achieve this
<RenatoSilva> verterok: however I'm not sure if you can do this kind of thing in Java
<verterok> RenatoSilva: how would you load the executable into memory and use it several times?
<RenatoSilva> verterok: I'm guessing: if python can, then yes java can!
<verterok> RenatoSilva: I think it could be possible with JNI...but you know...JNI
<RenatoSilva> verterok: and how python does?
<RenatoSilva> verterok: how does the xml-rpc server loads and keeps the executable in memory?
<verterok> RenatoSilva: bzr-java-lib executes: bzr start-xmlrpc in a subprocess
<RenatoSilva> verterok: also, maybe bazaar should have some kind of "daemon" mode
<RenatoSilva> verterok: oh I see, the server is a bzr instance itself + xmlrpc plugin. When you send a command, the server is "inside bzr", so it does not need to run bzr.exe. I thought for a moment that run_bzr was running the process...
<verterok> RenatoSilva: there is the bzr-serivce plugin
<verterok> RenatoSilva: right
<verterok> :)
<RenatoSilva> verterok: nice
<RenatoSilva> verterok: how does it work? you send raw arguments to a net socket?
<verterok> RenatoSilva: the bzr-service plugin? or the xmlrpc service?
<RenatoSilva> verterok: or do you have a formal protocol?
<RenatoSilva> verterok: bzr-service
<verterok> RenatoSilva: jam wrote it, I think it send the command args via the socket
<RenatoSilva> verterok: hum, what do you think is simpler code, talking with xmlrpc or bzr directly?
<verterok> RenatoSilva: bzr via bzrlib?
<RenatoSilva> verterok: ok, but you're the bzr-java-lib developer too, right? :)
<RenatoSilva> verterok: not talking about xmloutput anymore hehe
<verterok> RenatoSilva: xmlrpc is more flexible in that you can talk to it from almost every language
<lifeless> one issue with xml though
<RenatoSilva> verterok: every language?
<lifeless> not all bzr commit data can be put into xml now
<poolie> lifeless: hi
<RenatoSilva> lifeless: yeah, xml is maybe an unecessary middleware
<verterok> RenatoSilva: bzrlib is only usable from python
<lifeless> hi poolie
<poolie> what did you mean by "guess-good"?
<lifeless> that it had tried to help you ;)
<RenatoSilva> lifeless: also, things get weird when you send xmloutput stuff through xml-rpc: xml inside xml...
<poolie> and "it" is?
<verterok> RenatoSilva: the current xmlrpc service is a sort of a hack :)
<lifeless> bzr-guess
<lifeless> 're bzr-guess helping you that is good to know'
<RenatoSilva> verterok: sorry I read bzrlib as "bza-java-lib"
<RenatoSilva> verterok: what I mean with " hum, what do you think is simpler code, talking with xmlrpc or bzr directly?" is
<RenatoSilva> verterok: from java code
<RenatoSilva> verterok: in bzr-java-lib
<poolie> oh ok
<verterok> RenatoSilva: currently there is no way to talk to bzrlib directly from Java, I'm trying to implement OSLocks in Java, in order to use Jython
<RenatoSilva> verterok: maybe being able to directly send arguments to bzr, but having the process chached in memory, maybe it would be eassier to java code...
<RenatoSilva> verterok: I'm talking about service plugin
<verterok> RenatoSilva: xmlrpc is quite simple, you just send basic data types and receive the same (Strings, int, HashMap, Arrays)
<RenatoSilva> verterok: imagine  in java code something like Bazaar bzr = Bazaar.getServiceInstance(); then you bzr.run('log -r 10..12') ro so, instead of building an XML and send as xml-rpc
<RenatoSilva> verterok: what would be easier, that's what I mean
<RenatoSilva> s/ro/or
<verterok> RenatoSilva: that's the way bzr-java-lib is sending the command :)
<RenatoSilva> verterok: anyway, would  the plugin work if bzr.exe is in another host and you don't have one locally?
<verterok> RenatoSilva: but it's wrapped in IBazaarClient interface
<mwhudson> jelmer: we preserve the sha1 cache between runs now
<poolie> lifeless: quick call?
<RenatoSilva> verterok: that's the way bzr-java-lib is sending the command ---> bzr-java-lib could implement the cached process then, using the service plugin, so that users won't need xml-rpc anymore to run bzr faster...
<RenatoSilva> verterok: users could choose between xml-rpc or direct talk
<lifeless> poolie: sure
<RenatoSilva> .
<verterok> RenatoSilva: there is no cached process, it's just a python subprocess running a server
<verterok> RenatoSilva: the advantage of xmlrpc is that's more standard vs a custom socket service
<RenatoSilva> verterok: by cached process I just mean the service plugin
<verterok> RenatoSilva: in any case, the big plan is to have a more flexible xmlrpc service, using methods instead of running bzr commands
<verterok> RenatoSilva: and avoiding to send xml in xml ;)
<RenatoSilva> ok :)
<verterok> RenatoSilva: also I thinked a *lot* about using other protocol insted of xmlrpc, but the main issue are the dependencies
<verterok> RenatoSilva: e.g: using google protocol buffers
<verterok> RenatoSilva: the other option is to use bzr smart server
<RenatoSilva> verterok: the protocol could be just command line arguments
<RenatoSilva> verterok: Bazaar.getServiceinstance().run("--version")
<verterok> RenatoSilva: yes, but we need a way to receive the information, and possibly streaming it ;)
<RenatoSilva> verterok: through a socket
<verterok> RenatoSilva: I mean the format of this info
<RenatoSilva> verterok: you receive the response throught the socket, then you parse the xmloutput output
<RenatoSilva> verterok: format = keep using xmloutput
<verterok> RenatoSilva: with the current xmlrpc service in xmloutput (or with any other transport, e.g: socket) we need to send the whole info back
<verterok> RenatoSilva: e.g: bzr log -v of bzr trunk is going to take a while, and it's a lot of info kept in memory (in the case of xmlrpc+xmloutput)
<RenatoSilva> verterok: List<IBzrLog> logs = XMLLogParser.parse(Bazaar.getServiceInstance(BZR_PORT).run('xmllog'))
<verterok> RenatoSilva: we could stream with a custom socket server
<verterok> RenatoSilva: but why reinvent the wheel ;)
<RenatoSilva> verterok: what are you planning to do to stream it?
<verterok> RenatoSilva: also, using commands isn't such a good idea, in the case of bzr-java-lib it works, but it would be a lot better if we have custom service methods to call
<RenatoSilva> verterok: ok a more computer-friendly protocol, cmd line is mostly user-friendly, I agree
<verterok> RenatoSilva: I think that the first step could be to implement the method to replace the xmllog command, and customize the xmlrpc server to stream the response
<RenatoSilva> verterok: doesn't bzr-service stream the response too?
<RenatoSilva> verterok: I've heard it's mature...or would that be JRuby?
<verterok> RenatoSilva: I'm started a little experiment, write a Java version of the OSLocks, to be used with Jython
<RenatoSilva> verterok: what's OSLocks?
<verterok> lifeless: do you think that ^ might work? :)
<RenatoSilva> verterok: doesn't Jython gives you full access to python code from java?
<RenatoSilva> verterok: what is OSLocks and why do you need it
<verterok> RenatoSilva: bzr grabs a lock (read and/or write) on some files, it uses fctnl module or pywin32 to do that
<verterok> RenatoSilva: as the code is C, Jython don't have access to those modules
<verterok> RenatoSilva: Jython only can use pure python modules
<RenatoSilva> verterok: and you have something in python to access the C code, doesn't bzrlib do this for you?
<RenatoSilva> verterok: shouldn't all bzr C code be wrapped to python for proper third-party access?
<verterok> RenatoSilva: you can write python modules in C, but you can use those in Jython
<verterok> RenatoSilva: yes, but Jython can't import the required modules
<RenatoSilva> verterok: I see
<RenatoSilva> verterok: then Jython is not a full python VM right?
<verterok> RenatoSilva: it's
<RenatoSilva> verterok: environment I mean
<verterok> RenatoSilva: but it can't use C extensions
<verterok> RenatoSilva: some C extension are already ported to Java
<RenatoSilva> verterok: as it does not behave as a complete python vm (containing the c access module)
<RenatoSilva> verterok: if python itself can use C extensions, then Jython should be able too maybe
<verterok> RenatoSilva: because the "system" langauages are different, some python C extensions were ported to Java, so Jython can take advantage of it's speed
<verterok> RenatoSilva: not really, there is some related work in progress in JRuby using JNA, but not in Jython...yet
<RenatoSilva> verterok: ok
<wgrant> RenatoSilva: It's not a matter of having a "c access module". CPython extensions use the CPython C API, which a Java implementation of Python obviously doesn't have.
 * verterok --> dinner, bbl
<thumper> jelmer: lots of kudos to you, bzr-git imports working well now thanks to mwhudson's recent work to remember the sha1 cache
<thumper> jelmer: can we do the kernel yet?
<thumper> jelmer: mwhudson requested vlc which worked taking 13 or so hours, with 34k mainline revisions
<RenatoSilva> wgrant: I see
 * RenatoSilva --> go home
<RenatoSilva> thanks everybody
<wgrant> thumper: Now that you've perfected bzr-git imports, can we get bzr-svn too?
<lifeless> verterok: sorry was on a call
<lifeless> verterok: whats the question in short?
<thumper> wgrant: we are trying
<thumper> wgrant: but it has issues with python 2.4 right now
<thumper> wgrant: and our migration to python 2.5 took a hit with the developer working on it being sick for a week
<wgrant> thumper: Well, I see a solution to that that you need to implement in a few months...
<wgrant> Oh, so you're actually doing it>
<thumper> wgrant: but it is very much in the "near future"
<wgrant> But why only 2.5? Because Hardy doesn't have 2.6?
<mwhudson> thumper: https://code.edge.launchpad.net/~vcs-imports/wine/git-trunk still not happy :(
<thumper> wgrant: because we need to migrate zope through 2.5 first
<thumper> wgrant: we aren't jumping two versions at once
<mwhudson> wgrant: because going 2.4 -> 2.5 -> 2.6 is going to be easier than 2.4 -> 2.6
<wgrant> I guess so.
<thumper> mwhudson: -> #launchpad
<lifeless> mwhudson: !assertion
<mwhudson> lifeless: it's an opinion but a pretty firmly held one
<lifeless> mwhudson: yeah, I realise.
<lifeless> I hold the contrary position. Also fairly firmly ;)
<mwhudson> well it's not either of us doing the work, so i guess it doesn't matter very much
<poolie> thumper: were you going to  or did you propose an lca miniconf?
<thumper> poolie: thanks for reminding me, I'll talk to the people this afternoon
<verterok> lifeless: np
<poolie> jam, hello, if you're still here
<verterok> lifeless: it wasn't a question actually :), I'll try to add an OSLock implementation for Jython, using java FileLock class
<verterok> lifeless: is there any specific issues I should take care of?
<verterok> lifeless: FileLock docs: http://java.sun.com/javase/6/docs/api/java/nio/channels/FileLock.html
<lifeless> verterok: not really
<lifeless> the main thing would be to test interactions with python bzr oslocking of the dirstate file
<lifeless> make sure they mutex properly
<lifeless> (read locks sharable, write locks exclude all readers and writers)
<verterok> lifeless: ok, thanks for the tips :)
<krisfremen> hi all, i have a repo that i made weird changes to, how can i just make one directory go back to the last comit?
<lifeless> bzr revert -r -2 directoryname
<krisfremen> thanks lifeless
<garyvdm> I found a class that tests PyQt models. I'm using it now in qbzr.
<garyvdm> http://paste.ubuntu.com/213349/
<garyvdm> But it use assert(). How important is it to use TestCase.assert*()?
<poolie> garyvdm: the main difference is that assert is skipped when run with python -O
<poolie> so
<poolie> we ban its use in the main codebase
<poolie> in tests, it's ok
<poolie> but not great
<garyvdm> poolie: So do you think I should customize it?
<poolie> hm
<poolie> well, what are you going to do with it?
<poolie> copy it into qbzr?
<garyvdm> Yes - I have copied it into qbzr because it is not installed with pyqt
<garyvdm> And I call it from qbzr's tests
<poolie> i wouldn't stress about it
<garyvdm> Ok
<poolie> hope that helps :)
<poolie> for inconclusive advice :)
<garyvdm> lol
<garyvdm> Hmm - I can get a new test to run.
<garyvdm> This is qbzr/lib/tests/test_annotate.py : http://paste.ubuntu.com/213366/
<garyvdm> bzr selftest -s bp.qbzr.lib.tests.test_annotate = Ran 0 tests
<garyvdm> *cant get a new test...
<lifeless> bzr selftest qbzr.*annotate
<garyvdm> Ran 0 tests in 0.149s
<lifeless> its not being found then
<lifeless> hav you added the file to the qbzr test list?
<garyvdm> Ah
<garyvdm> No
<garyvdm> Thank lifeless.
<lifeless> poolie: ping; a) hunger, b) you'll need time to get home for your call
<poolie> lifeless: btw did you file a bug for the unstacking issue with inventories?
<poolie> well
<poolie> if you didn't it's ok, and i might just comment on 391411
<lifeless> I hadn't no
<lifeless> I was going to, but your adding a comment would be great
<lifeless> I've isolated my machine turn offs
<poolie> spiv, are you here?
<lifeless> if I hold the left side of my laptop and press firmly (key press firmness) on the top right, it turns off.
<poolie> that's handy
<poolie> much better than needing all that clicking through menus :)
<lifeless> ctrl-left click when the right edge is on my knee is enough
<MT-> How hard is it to create a bzr repository? Is there any simple guide?
<lifeless> bzr init-repo DIRECTORY
<lifeless> but you may not mean what you think you mean
<lifeless> what do you want to achieve, in nontechnical terms
<MT-> Me make pushy wordy stuff to metal box thingy and have wordy stuff in metal box thingy to get later :P
<MT-> I had to have fun with that
<lifeless> :)
<MT-> I want to create the repository on the server that was freshly installed with Ubuntu
<jam> poolie: I'm around for a bit now
<poolie> jam, was just going to say hi
<poolie> so "hi'
<poolie> lifeless, leaving now
<jam> hi poolie
<lifeless> MT-: sure; but I mean - do you want to put a new project under bzr control? or package trees, or ..?
<MT-> lifeless: I'll eventually want to put projects in it, I just want the repo available to do things with, fresh installation all the way to having groups of users that can edit specific branches
<lifeless> MT-: so, bzr doesn't really get organised that way :)
<lifeless> and the very question led me to suspect you were starting off oddly ;)
<lifeless> MT-: what VCS are you most familiar with?
<MT-> lifeless: bzr, but using with launchpad
<lifeless> ok
<lifeless> so on launchpad each branch is in its own repo
<MT-> I've setup svn before and had it running over http[
<MT-> oh
<lifeless> and bzr will create a repo automatically when you push if there isn't one
<spiv> poolie: I am, yeah.
<lifeless> MT-: if you want http/s hosting, you can set that up now
<MT-> I'd prefer only ssh
<lifeless> in which case you're already setup:)
<MT-> not yet :P
<MT-> I need to find the IP of the server so I can install bzr
<lifeless> MT-: oh, well thats entirely different :)
<lifeless> anyhow, use unix permissions to manage access
<lifeless> try to keep the permissions for an entire repo the same
<lifeless> (by which I mean *keep them the same*)
<lifeless> just create as many repos as you need
<lifeless> and for single-shot things, just use 'bzr push bzr+ssh://host/...foo' to push up a branch
<MT-> Can I set where the repos get created?
<lifeless> when bzr automatically creates one, its inline with the branch
<lifeless> otherwise they are all manually created
<MT-> lifeless: I just meant, can I tell bzr that whenever somebody tried to do bzr push bzr+ssh://server/blah, blah is created within /bzr
<lifeless> that would push to /blah
<lifeless> so its very easy, don't give them permission to write to / :)
<lifeless> what I mean is bzr+ssh://server/ == / on the filesystem (unless you've chrooted your ssh environment)
<spiv> Another option is to configure a different bzr serve command line in your ~/.ssh/authorized_keys.
<spiv> See e.g. contrib/bzr_ssh_path_limiter \
<lifeless> spiv: bzr on the client won't run that though
<lifeless> spiv: isn't the result a permission error ?
<spiv> lifeless: you can create a key that always runs a specified command no matter what the client asks for
<MT-> I just found the IP
<lifeless> fooding
<spiv> lifeless: (and that command can then inspect an env variable to get the command client asked for)
<MT-> So what I need to do is create a bzr group, add myself to the group, then set the group to own the directory where branches can be created in
<MT-> lifeless: does that sound like what you were saying?
<MT-> it didn't like that
<poolie> spiv, so, i'm ready when you are
<spiv> poolie: ok
<MT-> When I try to push, I'm getting this error - bzr: ERROR: Unsupported protocol for url "sftp://bzr@208.107.52.90/bzr/tmp": Unable to import paramiko (required for sftp support): No module named paramiko
<MT-> lovely that I pasted my ip...
<MT-> ok, I figured it out
<MT-> YES! I pushed it - although it still needs proper permission setup
<lifeless> MT-: use bzr+ssh rather than sftp
<lifeless> MT-: its a lot faster
<MT-> lifeless: I was just working off a guide online. I think I'm readdy to tackle loggerhead now but I'm not fully sure how
<MT-> looks like it defaults to port 8080
<MT-> ssh seems to work exactly the same except as you said, much faster :)
<MT-> I need to wait for the guy to get home and forward the port. We don't have a decent router setup yet.
<poolie> ok, back into 391411
<MT-> lifeless: you still around?
<lifeless> by accounts
<lifeless> though I'm working on shrinking
<MT-> lifeless: When I create a branch by pushing it, the branch is owner/group is me, so other users can't access it. How can I make it so the owner is bzr and the group is the top level directory of the files? If I just push a random branch the group is bzr for all files and if I push to a branch I set the group to devs the files group is devs.
<MT-> hopefully that's easy to deal with. I'm probably thinking wrong too
<MT-> if I do bzr initi-repo it's root:root, I imagine just changing that to bzr:devs would be easiest
<MT-> looks like I should justuse mkdir instead of init-repo instead though, maybe
<poolie> lifeless: filed bug 397286 from our call
<ubottu> Launchpad bug 397286 in bzr "fetch(find_ghosts=True) may not find all CHKMap pages" [High,Confirmed] https://launchpad.net/bugs/397286
<lifeless> poolie: thanks
<lifeless> MT-: set the sticky bit
<MT-> ?
<lifeless> MT-: unix permissions
<MT-> I've never heard of that..
<vila> hi all
<MT-> hi
<poolie> hey vila
<lifeless> actually, its not the sticky bit thats needed.
<lifeless> one sec
<MT-> lifeless: +t ?
<MT-> or apparently 1000
<MT-> lifeless: whenever you know, I'm all eyes :)
<MT-> s/know/remember/
<lifeless> set the group on the dir; oh, and the umask needs to be altered to preserve g+w in new subdirs
<lifeless> that should be all thats needed
<MT-> looks like +s on the parent directory
<MT-> hrm, that preserved the group
<MT-> shouldn't that inheret user too?
<MT-> or is that not possible?
<lifeless> you'd need everyone to be the same user for that to happen :P
<MT-> that's ok then :P
<MT-> I love how loggerhead is breaking... oh well
<MT-> not important atm :P
<MT-> lifeless: I'm confused though.. I add a file to the branch, push the branch, and then no files show up in it
<MT-> I guess it mush just be a server thing. I pull it and it shows up. Where does bzr keep the files?
<lifeless> MT-: compressed in a database in .bzr/repository
<MT-> oh
<MT-> wow... I'm learning a LOT today
<MT-> lifeless: thanks for all the help :
<MT-> :)*
<lifeless> anytime
<MT-> probably ina few minutes :P
<lifeless> EOD
<MT-> You mean F?
<MT-> oh - day
<MT-> lifeless: does that mean you're gone or here for a few minutes?
<poolie> night
<fullermd> I'm pretty sure bzr takes care of preserving the g+w if it's set on <mumble>.  I don't believe it tried to explicitly set the group though.
<fullermd> Depending on FS semantics, it'll inherit automatically all the time (BSD) or when the setgid bit is set on the dir (SysV)
<MT-> I think bzr is working perfect now - but loggerhead is irritating me
<poolie> vila: bzr-gtk release woo-hoo!
<vila> poolie: <cough> yeah ! First release ! :-/
<poolie> mm, why first release?
<poolie> your first one?
<vila> Hopefully someone can populate the PPAs from there
<vila> poolie: yes :)
<MT-> I'm trying to setup loggerhead. I have no idea what I'm doing... I installed it and I have no idea where to go from here. There doesn't seem to be any apache config created for it
<vila> MT-: Good idea ! You should file a bug asking for one
<MT-> vila: idk if I screwed up or not
<MT-> vila: Do you know what I'm supposed to do?
<poolie> i think there's a readme file describing what to do
<vila> MT-: no, but I know that you shouldn't have such doubts as a newcomer, so filing a bug right now, before getting your hands dirty will help make future newcomers experience better :)
<vila> MT-: try pinging beuno / mwhudson as the usual suspects
<MT-> vila: I already screwed with too much stuff. If I file a bug on it, It'll be on a fresh system. I did have it working for a short while before I did something stupid (following a random guide)
<MT-> I'll try to flush everything about loggerhead off this sytem
<MT-> vila: it's supposed to open port 8080 for it, right?
<vila> MT-: sorry, I never installed loggerhead myself so I can't really help here :-/
<MT-> oh
<vila> I kind of understood at one point that the http server was talking to the loggerhead one but even that bit may be outdated
<MT-> poolie: can you save my sanity?
<MT-> I fucked this up and idk how to get it back
<MT->  ^ I think that sums it up. I broke it
<poolie> you're not giving us much to go on there...
<spiv> MT-: can you be more specific?
<MT-> I tried following this guide - http://wiki.flexion.org/LoggerheadServer.html - Then tried aptitude install loggerhead over top of it. It kinda worked but it crashed some so I tried to finish the process. That wouldn't work so I went back the the loggerhead package. I realized how screwed up I made it so I tried to purge apache2 and loggerhead. I searched the system for files named loggerhead and removed them. I tried to them reinstall apache
<MT-> actually, now I'm getting this error - sh: getcwd() failed: No such file or directory
<spiv> Getting that error in what context?
<MT-> root@carpo:/etc/apache2# /etc/init.d/loggerhead start
<MT-> sh: getcwd() failed: No such file or directory
<MT-> start and stop are the exact same message
<bialix> have a question about API versioning
<bialix> developers/api-versioning.html said: In the plugin foo exporting the API (in __init__.py):
<bialix> version_info = (0, 0, 1, 'beta', 1)
<bialix> api_version = (0, 0, 1)
<bialix> what if my plugin don't have qpi_version declaration?
<bialix> does bzr will use just version_info?
<MT-> spiv: dpkg-reconfigure loggerhead and dpkg-reconfigure bzr-search show those messages too
<MT-> even /etc/init.d/apache2 stop is doing it too....
<MT-> I have a knack for destroying a system I guess
<spiv> MT-: if /etc/init.d/apache2 is doing that too then it sounds like you've somehow overwritten something pretty crucial in the system.  Hm..
<spiv> MT-: or,
<spiv> MT-: perhaps the shell you are invoking them from is running from a deleted directory?
<spiv> MT-: if you do "cd /" before running those commands, does that help?
<MT-> doesn't help
<spiv> It's certainly a misfeature of python on debian/ubuntu that "python setup.py install" of random projects tends to clash badly with OS-installed files.
 * MT- sucks at computers
<spiv> bialix: I don't know, sorry :(
<spiv> glyph: hey
<poolie> bialix: no,
<spiv> glyph: nice to see you in here :)
<poolie> i think it should just assume nothing about what api you need
<poolie> ie we don't know if you'll work with the current bzrlib or not
<bialix> wait
<bialix> it's about compatibility between plugins
<bialix> e.g. bzr-explorer requires qbzr >= 0.11
<poolie> spiv can i ask you about test_unstack_fetches in branch_implementations
<poolie> oh right, this is your api, not the required api
<bialix> but qbzr has no api_version declaration in old versions
<spiv> poolie: you can ask ;)
<poolie> spiv, i think it ends up with the stacked branch being a local one
<bialix> so now I'm checking qbzr version manually
<poolie> even when it's an iteration that's meant to be testing remote objects
<spiv> Without looking, that sort of test bug isn't unheard of...
<spiv> poolie: because of the sprout('newbranch') ?
<spiv> rather than sprout(self.get_url('newbranch')) ?
<spiv> That looks likely to me.
<poolie> spiv, yeah
<poolie> also, i really want to change get_transport and get_url to something like
<poolie> get_test_url
<spiv> I'm pretty sure I've seen (and corrected) that exact error in other tests.
<poolie> to make it more clear it's going to be parameterized depending on the test context
<spiv> It's probably not hard to grep for.
<spiv> Hmm, I think asking "self.get_url" where self is TestCase is pretty clearly doing that already.
<MT-> spiv: can you tell me what shoudl be in /etc/apache2/envvars ?
<lifeless> poolie: I don't see it being any more clear, and think that sort of naming is an antismell
<poolie> why?
<spiv> MT-: mine has http://pastebin.com/mfdeb8df, I haven't edited it since install.
<glyph> spiv: I'm in here quite a bit :)
<spiv> glyph: and it's nice to see you every time :P
<glyph> spiv: Well, then!  You too! :)
<poolie> oh, i guess an antismell would be a good thing?
<MT-> spiv: what file permissions?
<glyph> spiv: sadly I am not here for an awesome reason.
<lifeless> poolie: I mean 'foo.get_transport' is clearly parameterised already
<lifeless> by foo
<lifeless> ditto foo.get_url
<MT-> spiv: nvm...
<MT-> spiv: how do I get a scratch install of apache?
<spiv> MT-: you might want to try apt-get --reinstall
<glyph> I still use Hardy on most of my machines.  But, the bzr-gtk packages are broken there.  Are those packages in the PPA supported for Hardy any more, or is it just bzr itself?
<MT-> spiv: didn't do it..
<poolie> lifeless: well, that's just it, i think it's not clear
<poolie> the difference between self.thing and thing is not very large
<vila> poolie: I found it unclear for quite some time, but now that I've use get_transport and get_url quite a lot, I can't see how you can change them without massive disruption in the existing tests grep says 726 matches for get_transport and 475 for get_url...
<vila> There mat be places where one or the other miss a relpath parameter, but most of the time (at least in the tests *I* encounter) they seem fine
<vila> s/mat/may/
<poolie> well, i realize most of the tests mostly work
<vila> And I fixed a couple of bugs where the test were wrongly calling get_transport() instead of self.get_transport()
<spiv> poolie: I think with get_transport vs. self.get_transport it can be unclear, but there's no non-test equivalent of get_url.
<poolie> that's true
<poolie> and that there are many calls
<spiv> Or not so much unclear as easy to forget to use the self. version, and easy to miss when reading/reviewing.
<MT-> OK! Apache is back running... now back to figuring out loggerhead
<spiv> Actually, when I phrase it like that, that's the same sort of thing as this test bug -- it's easy to call sprout with a string that will implicitly use a local URL, rather than with a URL.
<spiv> If you had to give it a URL, that test error would be much less likely.
<poolie> that's what reminded me
<poolie> "it's possible to use it correctly" is not very convincing
<spiv> Right, too far down rusty's list.
<vila> well, if we could make get_transport() private, it makes me more happy :)
<spiv> It's easier to misuse than use correctly, at least in the context of testing.
<spiv> (It's convenient in ad hoc scripts though...)
<poolie> vila: which get_transport?
<poolie> :)
<poolie> presumably you mean the factory function
<vila> poolie: yes :D
<poolie> actually maybe tests for remote objects should have something to prevent them using the temporary directory unless they really want to
<poolie> i bet if we did that it would find some bugs
<poolie> spiv, have you thought at all about having a common base class between Repository and RemoteRepository?
<poolie> some things might like to live there
<spiv> A little.  It would probably be nice.
<poolie> like has_same_location etc
<poolie> i realize it probably can't share much actual implementation
<poolie> or shouldn't
<spiv> It could perhaps share some stuff like write group managment.
<spiv> glyph: wb
<MT-> oh....
<glyph> spiv: pro tip: fscking 3 terabytes takes a while, and probably shouldn't be done mid-conversation.
<spiv> glyph: I haven't looked at the state of PPA lately, but I see that bzr-gtk finally cut a release today
<glyph> ooh.
<glyph> spiv: well in that case I'll write a shell script to apt-get update in a tight loop :)
<spiv> glyph: I think the PPA package was probably broken due to lack of a release compatible with current bzr, so with that fixed hopefully someone will update the package soon.
<glyph> by the way
<glyph> I have I mentioned that I love bzr?
<vila> glyph: no, do you love it ?
<glyph> Because I do.  I love it.  I have a natural tendency to be biased towards it, of course, because all you fine folks work on it and I like you so much
<glyph> but every time I have to interact with git, darcs, or even hg (and I've been trying out a lot of software recently, so I've been doing a lot of that) I find myself thinking that it would be a lot nicer if it were bzr.
<MT-> spiv: ok... so loggerhead will load once. If I reload the page or click anythin the daemon dies... -_-
<spiv> glyph: btw, a test conversion I did of Twisted's trunk into the 2a format is only 20M.
<glyph> spiv: !!!!
<glyph> oh, just trunk.
<glyph> Still, I'm pretty sure that's smaller than the SVN equivalent export.
<spiv> Yeah, although I don't imagine a bunch of branches is going to explode it that much, the compression is pretty sexy.
<glyph> It took a minute, but 'du' reports the current repository is about half a gig.
<glyph> if trunk is only 20M in 2a, I bet that it will be a looot smaller than that.
<spiv> I'm sure it will be smaller than that!
<awilkins> I've done conversions and just as 1.14-rich-root the whole history of all repositories in the project list comes out smaller than a single export of one of the branches
<spiv> ISTR the last time I did a full conversion into an earlier format it was under 80M, and 2a is typically much much better...
<awilkins> A working copy would be huuuuge in comparison- 1.7 GB x2 is much bigger than 700MB (the bzr repo packs)
<awilkins> I converted it to 2a and only got a 50MB reduction from 700MB though
<spiv> It's a bit confusing because Twisted's repo has some 'branches' that aren't actually branches that confuses bzr-svn a little into making some garbage branches.
<glyph> spiv: I am 90% sure that the only 'branch' like that is actually 'releases/'
<poolie> spiv, lifeless, vila, how do we feel at the moment about having eq methods on things like Repository
<glyph> spiv: so if you could special-case that directory via some configuration...
<poolie> that check if they have the same format and location etc
<poolie> i have mixed feelings
<glyph> poolie: better make sure you have __ne__ methods too!  and __gt__ and __lt__ and __ge__ and __le__ and ... ;-)
<poolie> but if the checks are cheap and well defined it's probably food
<poolie> yeah, well, at least ne
<spiv> poolie: probably food indeed ;)
<spiv> I'm -0 I think.
<vila> poolie: I don't have good feeling about it, there equality concept between repository is not that obvious to me, I can easily imagine people considering repositories with the same *content* to be equal
<spiv> I think for something as complicated and general-purpose as a Repository "equality" has several possible meanings.
<vila> urgh, forget my typos, what spiv says ;)
<spiv> Which tends to mean that blessing just one meaning with __eq__ is asking for bugs.  Hence why we have has_same_location.
<poolie> it would have just been nice to compare x.fallback_repositories == y.fallback_repositories
<poolie> obviously you can write it out
<MT-> This is ALL I can get for error logs http://bzr.pastebin.com/m6d8b2cbb
<poolie> it's a bit longwinded in 2.4
<MT-> error.log is empty
<glyph> IMHO (not that anyone asked me, I just happen to be paying attention) equality checks should only be on objects which are "values", i.e. are trivially possible to serialize and unserialize.  Things like a "Point" with x, y numbers or "EmailAddress" with description/localpart/domain
<glyph> I don't even know enough about bzr's internals to know what a "Repository" is but it sounds big and mutable and scary.
<vila> and operator overloading is evil :)
<glyph> operator overloading is great!  everybody should do it all the time.
<MT-> loggerhead is dying after every single page load - AH!
<vila> It was evil back in the days where C++ wasn't even standardized, I think it's still evil, far too easy to abuse and leading to some of the most obscure bugs I  ever seen :D
<spiv> glyph: yes, a Repository is all of the above :)
<MT-> spiv: Does this look decent or very wrong? http://bzr.pastebin.com/ma4b26c3
<poolie> yeah, generally i agree with glyph too
<poolie> i was just tempted to sin
<spiv> MT-: no idea, sorry, I haven't actually set up loggerhead myself
<MT-> Can anybody tell me if this file looks right? I'm guessing it's probably why this is breaking? http://bzr.pastebin.com/ma4b26c3
<spiv> Ah, you need #confessional, not #bzr :P
<MT-> this is about to make me freak out...
<MT-> it should be a drop in thing...
<poolie> MT-: seriously, you can't just say "it's breaking"
<poolie> what's that meant to mean?
<poolie> MT- read this sometime -> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<MT-> poolie: I pasted log files and explained what happens.
<MT-> I run /etc/init.d/loggerhead, I load ope page, and it stops running.
<MT-> no errors
<poolie> one page?
<poolie> hm, that's not so good
<poolie> so the process exited?
<MT-> odd... I just tried running it in the foreground and it keeps running fine
<MT-> This keeps working perfect -> start-loggerhead -f -c /etc/loggerhead.conf
<MT-> Without -f, it dies after the first page load
<MT-> poolie: Does that sound odd enough??
<poolie> that's a bit strange
<poolie> what is -f meant to do?
<mwhudson> MT-: serve-branches is easier to use that start-loggerhead
<mwhudson> (though not packaged as neatly yet)
<MT-> poolie: keeps it int he foreground
<MT-> mwhudson: would you please be willing to walk me through setting that up? I think my mind is gone
<mwhudson> MT-: well, it's reasonably easy, you run ./serve-branches <where the branches are>
<mwhudson> it doesn't daemonize or anything though, so if you want to manage it with initscripts there will be some messing about to do
<MT-> I got an error :) _ http://bzr.pastebin.com/me75ca2d
<mwhudson> ehh
<MT-> wow, it's already 0400
<mwhudson> MT-: do you have loggerhead installed system-wide?
<mwhudson> MT-: and what version are you running?
<mwhudson> (must be fairly new)
<MT-> mwhudson: I did aptitude install loggerhead on 9.04
<MT-> !info loggerhead
<ubottu> loggerhead (source: loggerhead): Web viewer for Bazaar. In component universe, is optional. Version 1.10-1 (jaunty), package size 489 kB, installed size 3360 kB
<mwhudson> MT-: can you run dpkg -l loggerhead?
<MT-> ii  loggerhead                                     1.10-1                                         Web viewer for Bazaar
<poolie> try 'debsums loggerhead'?
<poolie> you might need 'sudo apt-get install debsums' first
<mwhudson> then i'm really confused, because loggerhead 1.10 doesn't have a main module
<mwhudson> which is what the error is saying i guess, but also serve-branches from that version shouldn't be trying to import it
<MT-> all OK
<mwhudson> hang on
<mwhudson> /usr/local/bin/serve-branches
<poolie> run 'which serve-branches' ?
<MT-> http://bzr.pastebin.com/m48a81032
<mwhudson> that's not from the package
<MT-> /usr/local/bin/serve-branches
<MT-> hrm...
<mwhudson> MT-: did you or someone else run 'python setup.py install' perhaps?
<poolie> 17:38 <MT-> I tried following this guide - http://wiki.flexion.org/LoggerheadServer.html -
<MT-> yup...
<poolie>             Then tried aptitude install loggerhead over top of it. It kinda worked but it
<poolie>             crashed some so I tried to finish the process. That wouldn't work so I went back
<poolie>             the the loggerhead package. I realized how screwed up I made it so I tried to
<poolie>             purge apache2 and loggerhead. I searched the system for files named loggerhead
<poolie>             and removed them. I tried to them reinstall apache
<MT-> mwhudson: Does that exist in any package from the repos?
<mwhudson> ah
<MT-> root@carpo:/bzr# find / -name serve-branches
<MT-> /usr/bin/serve-branches
<MT-> /usr/local/bin/serve-branches
<mwhudson> MT-: i guess you should remove the one in local/bin
<MT-> :)
<poolie> ok i might call it a night
<poolie> spiv, i think the unstacking thing is now all working, except that I'm getting TooManyConcurrentRequests
<poolie> for the first time in my experience i think this is actually because there really are too many concurrent requests :)
<poolie> not that there's an earlier error and it's failing to unwind
<poolie> http://bzr.pastebin.com/m6fe21766  <-- like so
<MT-> mwhudson: is there any easy way to run that from a daemon?
<poolie> anyhow i'll look tomorrow at how to tastefully make it create a new medium
<poolie> if there's no better way
<poolie> good night all
<spiv> poolie: :)
<mwhudson> MT-: nohup serve-branches ?
<mwhudson> MT-: basically, no
<mwhudson> MT-: we need to fix that
<MT-> ok
<poolie> mm
<poolie> surely there's something in the normal initscripts framework to do this?
<MT-> so for now it's just serve-branches /bzr &
<MT-> mwhudson: is there any way to make it hide directories?
<mwhudson> MT-: not with 1.10
<MT-> theres a lost+found showing up..
<mwhudson> MT-: with loggerhead trunk you can set http_serve = false in locations.conf
<MT-> bzr is still a baby, isn't it?
<mwhudson> loggerhead is, at least
<MT-> err - that*
<MT-> mwhudson: could you help me switch to trunk?
<mwhudson> MT-: sure, bzr branch lp:loggerhead loggerhead-trunk
<mwhudson> MT-: i wouldn't bother installing it system wide, just run it from the directory you branch into
<MT-> ok
<MT-> what does serve-branches run as?
<MT-> I wanna kill that service first :P
<mwhudson> i don't understand
<MT-> I started serve-branches /bzr &, now idk how to kill it...
<LarstiQ> jml: you mentioned a fixed .gdbinit, but I forgot where it lives
<vila> poolie: g'night
<MT-> THERE!
<MT-> mwhudson: sorry, I had to remember how to use netstat - and the command name
<vila> MT-: surely, if you used '&' the pid has been displayed
<MT-> vila: it wasn't
<vila> or is it just the job number ?
<vila> try 'fg'
<MT-> heh... I shoulda thought of that too - but anyway, I found it with netstat
<MT-> it was running as python
<MT-> mwhudson: thanks, :D
<MT-> mwhudson: one last question... Is there any easy way to make loggerhead private?
<mwhudson> MT-: run it behind apache using proxypass (and a firewall to stop people getting to the port loggerhead is listening on)
<MT-> heh... how do I run it behind apache?
<mwhudson> i think there is actually some documentation on this in the README file
<MT-> !info python-pastedeploy
<ubottu> python-pastedeploy (source: pastedeploy): Load, configure, and compose WSGI applications and servers. In component universe, is optional. Version 1.3.2-1 (jaunty), package size 29 kB, installed size 276 kB
<MT-> mwhudson: I purged the package
<MT-> oops
<MT-> mwhudson: anyway... I created that in conf.d/loggerhead and it didn't work. I don't have a /branches/ so I just left that part out
<MT-> replaced with /bzr/ *
<mwhudson> right, it's only meant to be an example
<MT-> the branches are located in /bzr
<MT-> mwhudson: it the directoy I'm putting the proxy on the loggerhead directory or the branch directory? I assumed branches
<mwhudson> branches
<mwhudson> heh, trying to browse laconica's source is being very slow
<mwhudson> (it's on gitorious)
<mwhudson> makes me feel a bit better
<fullermd> Well, you'd expect it to be laconic, now wouldn't you   :p
<MT-> mwhudson: am I at lesat close here? I'm at least getting 403's now...
<mwhudson> that does sound like it might be progress
<MT-> it I go to :8080 now it still works fine but I get the hint that I just close off :8080 to the outside world
<MT-> http://bzr.pastebin.com/m79213860
<MT-> or do I want that as a directory now...
<MT-> I was hopeing to have this runnign before nappy time - it's 0530 already :P
<MT-> I get up at 1200 at the latest
<MT-> I guess it just doesn't like the documentroot
<MT-> that's teh reason for the 403's
<MT-> Closer!
<MT-> Now I log in and get a 500 error
<MT-> Ok... so when I try to login I get this error - (13)Permission denied: Could not open password file: /bazaar/lh-users
<MT-> I know that file is readable...
<MT-> mwhudson: you have any of those really smart ideas?
<mwhudson> well it sounds like an apache problem i guess
<MT-> it is now, I'm making progress :D
<MT-> root@carpo:/var/log/apache2# ls -l /bazaar/lh-users
<MT-> -rwxrwxr-- 1 www-data www-data 22 2009-07-09 05:12 /bazaar/lh-users
 * MT- wants sleep and broblem solved
<michaelforrest> hi - would anybody be able to help me come up with a good repository structure for a project I'm working on..?
<michaelforrest> I have already started with a single branch and have the project on Launchpad, but now I want to have lots of different branches with different feature variations
<michaelforrest> I've read through http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#advanced-shared-repository-layouts but I'm still not sure how to approach it
<fullermd> michaelforrest: Well, for one thing, realize you don't want to approach it as "choosing _A_ repository structure".
<fullermd> You want a repository structure for a given place (and time).  Your repository structure in your workspace needn't (and probably doesn't or shouldn't) bear much resemblance to the structure in mine, and neither need be much related to the structure on the central server.
<fullermd> (of course, that holds double when the central server is LP, since you don't get to do anything with repo structure there  ;)
<michaelforrest> fullermd: ok so.....
<michaelforrest> fullermd: say I want to branch locally but keep some of those branches on launchpad
<fullermd> Remember, repositories aren't semantic units, they're just storage spaces.  Perhaps you mean more project structure than repo structure...
<michaelforrest> fullermd: argh. I like hierarchy in these things, so I'm looking at the --no-trees stuff, but I think I'll want a working tree for each branch on my local filesystem
<michaelforrest> fullermd: I want to be able to merge across branches so that .. arg. it seems complicated.
<MT-> GAHH!!!! If I remove the proxy lines, it works like it should, if I leave them it, it all of a suddent can't read from the password file
<michaelforrest> fullermd: plus I'm used to git, where I'd only see one branch at a time
<fullermd> Well, don't mix up problems   :)
<michaelforrest> fullermd: yes well - I'm trying to get it straight. hence asking for help.
<fullermd> First, forget about repos for the moment.  You'll definitely want to make use of them, but they won't change anything about how you work, so at least for mental modelling purposes forget they exist.
<fullermd> (e.g., if you have two branches project/a and project/b, working with them would be _exactly_ the same if they shared a repo at project/, versus each having separate internal repos.  So, what you do with repos doesn't affect how you work with stuff like it does in $OTHER_SYSTEM)
<fullermd> There's a large historical bias toward workflows where your branch and working tree are 'together'.  You can still work with a lot of treeless branches and a single checkout you switch among them (or multiple checkouts you switch among them, for that matter).
<fullermd> It's just not as polished; requires a bit more manual setup.
<MT-> I've had enough - g'night all
<MT-> mwhudson: poolie: others: thanks for the help
<fullermd> michaelforrest: (does any of that help at all, or am I speaking Greek, or belaboring the painfully obvious?   ;)
<michaelforrest> fullermd: if I use --no-trees will it behave the same way as git?
<michaelforrest> fullermd: I could live with that and then use export to output different versions
<fullermd> Not exactly.  You can setup an analogous workflow, with one WT switch'd among branches.  Various things won't be as polished, though.
<michaelforrest> but then I have to synchronise other aspects of the codebase at different points
<fullermd> Basically, the difference is that in git, the repository is the addressable unit, and branches are named within that.  In bzr, the branches are themselves the addressable unit, and identified purely by their location (URL/path/etc).
<michaelforrest> ok
<michaelforrest> that is a useful distinction
<fullermd> Some commands (like 'switch', to change the branch your WT is on) do some internal magic so you can ACT like you're addressing sibling branches by name.  But it turns it into paths underneath.
<fullermd> Other commands don't.  'branch', for instance, to create a new branch; I don't think it does, so to create a new branch you have to specify something like a path, not just a name.
<fullermd> (there are some tools like 'cbranch' in bzrtools that can help automate that too.  I've never used them.  Glancing at the docs, they will take a little config'ing to how your workspace is setup)
<michaelforrest> maybe I'd be able to visualise things easier if I installed some of these gui plugins
<michaelforrest> I tried to install one the other day but it didn't seem to work
<fullermd> I believe abentley works heavily in that fashion (one tree switch'd among branches).  So he might have some better advice on setting up that workflow; he should be around in a couple hours.
<michaelforrest> is there a bzr install plugin command?
<michaelforrest> or something like that?
<LarstiQ> michaelforrest: no. I do: `cd ~/.bazaar/plugins; bzr get lp:bzr-pluginname pluginname` usually
<fullermd> No, nothing builtin.  You can just stick plugins in ~/.bazaar/plugins/.  But that doesn't necessarily help with things like plugins' dependancies, like py-gtk or py-qt or the like.
<michaelforrest> LarstiQ: that sounds easy enough
<michaelforrest> fullermd: I think the key is that I will be doing bzr merges as part of my routine build process
<vila> LarstiQ: eerk, better do: cd ~/.bazaar ; bzr branch lp:bzr-pluginname plugins/pluginname
<fullermd> Not sure how much structure a GUI will make visible, though.  Like, things like 'branch layout' don't make the same sorta sense in bzr as they do in git.
<michaelforrest> so there will be a central branch driving global functionality forward but will occasionally be little 'leaves' with feature variations that need to stay in sync with main app head
<LarstiQ> vila: hmm, how much does that differ, and why not go `bzr branch lp:bzr-pluginname ~/.bazaar/plugins/pluginname` in one go?
<vila> even better !
 * vila searching the bug #
<michaelforrest> small step from 'bzr branch lp:bzr-pluginname ~/.bazaar/plugins/pluginname' to a bash command bzr-plugin-install pluginname ;)
<vila> well, you're not wrong here :-) While the bzr- prefix is more a social thing than a technical one, I can't think about a case where it will fail...
<LarstiQ> there are plugins on BzrPlugins not on launchpad
<fullermd> qbzr   :p
<vila> lol, yeah, right, I just 'bzr  pull -v' for qbzr for too long :)
<fullermd> bzrtools too...
<LarstiQ> so yeah, plugin registry and dependency information, then we're good to go
<fullermd> Also, a pony.
<vila> Ha ! Finally, LarstiQ, I was refering to bug #304891
<ubottu> Launchpad bug 304891 in bzr "bzr doesn't work in parent directories of python packages with certain names (dup-of: 72227)" [Undecided,New] https://launchpad.net/bugs/304891
<ubottu> Launchpad bug 72227 in bzr "should avoid loading modules from working directory" [High,Confirmed] https://launchpad.net/bugs/72227
<vila> james_w: ping
<james_w> hi vila
<LarstiQ> vila: why is that not fixed?
<LarstiQ> other than apathy I don't see a reason
<vila> :-/
<fullermd> Who wants to lose a bug with a nice palindromic number?
<vila> lack of time ?
<vila> and that too of course :)
<vila> even if, really, a small palindrom ...
<intellectronica> aloha
<intellectronica> bzr dropped to the debugger in the middle of reconciliation of a v2 repo with some old branches
<intellectronica> very frustrating, but since i now have a debugger prompt in front of me, is there anything i can do to help figure out what the problem is?
<james_w> intellectronica: is it a stray "pdb" in the code
<james_w> ?
<james_w> or are you running under BZR_PDB?
<intellectronica> i don't know what BZR_PDB is (an environment variable?) so i'd say the former
<james_w> yeah, environment variable that causes pdb to start if there is an unhandled exception
<james_w> if you "list" does it point at pdb.set_trace()
<james_w> ?
<intellectronica> yeah
<intellectronica> http://pastebin.ubuntu.com/213609/
<james_w> ah, it's the SIGQUIT handler
<james_w> did you try and kill the process?
<james_w> the paste suggests you typed ^\ :-)
<intellectronica> i didn't, and from the debug listing it looks like bzr sent it, no?
<james_w> ^\** SIGQUIT received,
<james_w> signal.signal sets signal handlers, not sends signals
<james_w> anyway, typing "c" should make it continue
<intellectronica> oh well. who knows, maybe i somehow accidentally typed ^\
<intellectronica> thanks!
<james_w> np
<james_w> let us know if it happens again
<RainCT> Hey
<RainCT> Â«bzr hooksÂ» crashes here, http://paste.ubuntu.com/213639/plain/
<rockstar> jam, you are freakin' awesome!  Thanks for trying Tarmac on Windows.
<jam> rockstar: I'm working on making it *work* there
<jam> if you give me a few more minutes :)
<rockstar> jam, that's awesome!
<jam> rockstar: I just got to the point of it popping up a Launchpad window
<jam> asking for me to authorize access
<jam> what should I do at this point?
<jam> For now, I suppose I could set it to read-only
<rockstar> So, you could allow it and continue.  It'll save the token it gives you.
<rockstar> Readonly is good enough.  There's only one thing that writes now, and that's only if you have a test failure.
<jam> well, at this point... it is crashing with:
<jam>   File "build\bdist.win32\egg\httplib2\__init__.py", line 972, in request
<jam> AttributeError: 'unicode' object has no attribute 'get'
<jam> However, it is getting close
<jam> And that at least looks like it is failing in launchpadlib
<jam> and not tarmac
<intellectronica> abentley: is reconcile atomic? what's the risk if i stop in the middle?
<abentley> intellectronica: There's no risk, but it won't pick up where it left off.
<intellectronica> abentley: cool, thanks. i'm not worried about that
<jam> rockstar: I'm pushing up a patch, and submitting a merge request
<jam> rockstar: It still doesn't work, but that seems to be a launchpadlib issue
<jam> and not a tarmac one (yet)
<rockstar> jam, hooray!  Thanks a ton!
<jam> rockstar: any idea why launchpadlib seems to be using: build\bdist.win32\egg\httplib2\__init__.py ?
<jam> is it using a custom httplib library?
<jam> rather that the one in python's stdlib?
<rockstar> jam, it might.  I know there was a bug about it recently.
<rockstar> jam, it's probably a question better aimed at leonardr
<jam> sure, I just don't know any launchpadlib devs, especially ones that are awake right now
<jam> I know jml and you :)
<rockstar> jam, :)
<jam> argh
<jam> it seems they are doing:
<jam> cache = tempfile.mkdtemp()
<jam>             atexit.register(shutil.rmtree, cache)
<jam> and then "cache" is the path to a cache directory
<jam> which is just a string
<jam> oh, I guess they try to do:
<jam> cache = MultipleRepresentationCache(cache)
<jam> I wonder if "cache" is a Unicode object on Win32
<jam> yep
<jam> ugh
<jam> rockstar: so I got it to stop crashing with an exception
<jam> what should I expect its output to be?
<jam> ooop, new exception
<jam> it seems to assume "/tmp/bzr" is available
<jam> bad tarmac
<jam> no cookie
<rockstar> jam, there's a new patch for /tmp/bzr, but I haven't landed that yet.
<jam> rockstar: Shouldn't it just be part of the Config class?
<rockstar> jam, it's not right now.
 * rockstar looks sheepishly
<jam> rockstar: .... *I'm* trying to get things to work on win32, and I'm trying to get info from you as to what I can do to make that happen
<jam> If you feel that I'm correct that "$TMP" should be in Config
<jam> I'll put it there
<rockstar> Ah, okay.  Yea, that makes sense to be in Config.
<jam> rockstar: what do you think about making it "tempfile.mkdtemp" ?
<jam> Do you prefer not to because it would leave trash around?
<jam> (as in, you always want to leave 1 directory around, but not 10?)
<rockstar> jam, that's fine with me.  Trash in the temp dir is pretty standard.
<jam> or do you even want to leave 1 copy
<jam> For example, Launchpadlib does "temp = tempfile.mkdtemp()
<jam> atexit.register(shutil.rmtree, temp)
<rockstar> jam, I think I'm already doing something similar, so that would be okay.
<jam> rockstar: it *is* likely to leave trash in temp, but downloading 100MB projects and leaving them around is a bit ugly
<jam> rockstar: you seem to do "shutil.rmtree()" if it exists when you go to create it
<jam> but not otherwise
<jam> however, I'm still wondering if this is the best solution
<jam> considering that we still need to download a lot of data to get "create_checkout" to work
<jam> not to mention, you aren't doing "light=True"
<jam> so it downloads the whole branch
<jam> fresh
<jam> every time
<rockstar> jam, light=True would be hard on a patch that's about to come in that needs the parent graph.
<rockstar> Downloading it every time is actually a feature.  I want it to be fresh.
<jam> rockstar: it *doesn't* scale well to projects like MySQL where you have 600MB to download...
<jam> (or the old Launchpad which had... 1+GB)
<rockstar> jam, yeah, that's a good point.
<jam> Heck, bzr in 1.9 format now has >100MB
<rockstar> Hm, I'll file a bug on that.  We're Tarmac mini sprinting tomorrow.
<jam> rockstar: ok. I'll let you think about that. I'll just try to get something working, and I'll submit it
<rockstar> jam, thanks!
<jam> rockstar: there seems to be "tempfile.gettempdir()" which should probably give /tmp on Linux and $TEMP on windows
<jam> so I'll go ahead and just to the simple change to that
<jam> rockstar: how do you run your test suite?
<rockstar> jam, yeah, I figured there'd be some weirdness in small things like that.  I tried to use os.path.join where I could, but I'm not surprised that I missed some places.
<jam> your .cleanup() is a bit strange, too. Given that it ends up checking out the tree a second time
<rockstar> jam, really?  I hadn't noticed that.
<rockstar> jam, Could you file a bug with the details?
 * rockstar facepalms
<lamalex> is there any way to find out why bzr thinks this merge is a criss-cross merge?
<lamalex> it shouldn't be afaik
<jam> rockstar: so it seems to work, except I believe it is paramiko which is hanging indefinitely when the tarmac script exits
<jam> bzr doesn't notice because we explicitly use
<jam> os._exit() when we are done
<jam> (i think)
<rockstar> jam, you don't have a specific config do you?  I noticed it hangs trying to comment with the test failures.
<jam> rockstar: So it works to the point of "no candidates to land"
<jam> and then that "return" triggers
<jam> and it exits the script, and just hangs
<rockstar> jam, ah, so it's not the issue I know about.
<jam> then again, I just removed the os._exit for bzr, and we still work just fine
<jam> so I need to probe deeper
<jam> probably an atexit() function is being naughty
<rockstar> jam, that's also a possibility.
<jam> I swear I've seen in with paramiko, though
<jam> because if in the interpreter I run paramiko, I'll get it to hang sometimes
<jam> hmm... lets see
<jam> rockstar: the crummy thing is that not even ^C works at that point
<rockstar> jam, ouch.
<rockstar> Why would paramiko even get imported?
<jam> rockstar: when you download the development target
<jam> see bug #397486
<ubottu> Launchpad bug 397486 in tarmac "Tarmac does a fresh download of the target *before* checking if anything is ready to land" [Undecided,New] https://launchpad.net/bugs/397486
<jam> ahh, I have a workaround
<jam> it seems that if you call "sys.exitfunc()" before you actually exit your script
<jam> things are happy
<dash> tarmac? is that an archive tool for OSX
<jam> the issue is probably that GC is happening in a weird order
<jam> dash: Think airports
<jam> it is a tool for "landing" code
<jam> (similar to PQM)
<jam> but more integrated with Launchpad
<rockstar> dash, Tarmac is the new hotness.
<rockstar> sabdfl said so.
<jam> rockstar: so... a few patches up for your review. And with those *and* the launchpadlib ones, I at least get "No branches for landing"
<rockstar> jam, we're doing the launchpadlib ones right now actually.
<npoektop> yo! is there a way to ignore executables in my code repository other than marking them with .exe (or smth) extension?
<sidnei> jam: thanks for the review! how do i get authorization to submit to bzr's pqm?
<garyvdm> Hi all
<jam> sidnei: we'll generally ask for a second review, and then the reviewer will submit it
<sidnei> jam: cool. i didn't know that. should it be explained in http://bazaar-vcs.org/BzrDevelopment ?
<sidnei> oh i guess it's in HACKING
<sidnei> uhm, nada. it only says 'someone with PQM access'
<malept> vila: ping
<vila> malept: pong
<malept> vila: I don't think credits.pickle is in bzr-gtk-0.96.1.tar.gz
<vila> malept: :-(
<vila> malept: you think right :-( The release roadmap is *really* wrong
<vila> jelmer: I did my best from your pointer but I'm afraid you'll have to give more precise info... How come credits.pickle is in .bzrignore ? Talk about a trap...
<malept> vila: build_credits should be in MANIFEST.in?
<malept> er
<malept> credits.pickle.
<malept> two different thoughts there
<vila> http://bazaar-vcs.org/bzr-gtk/releasing says: 'Build tarball (bzr export bzr-gtk-0.XX.Y.tar.gz) ', but since credits.pickle is ignored, of course it's not exported
<malept> ah...
<vila> build_credits *did* build it
<malept> vila: perhaps you should add credits.pickle to MANIFEST.in and then use `python setup.py sdist` to create the tarball?
<malept> although I'd do a diff between the 0.96.1 tarball and the sdist tarball to see what got lost, if anything
<malept> a filelist diff*
<vila> malept: I think deleting credits.pickel from .bzrignore and redoing bzr export is less risky
<malept> vila: is that how bzr export works?
<malept> vila: doesn't credits.pickle need to be versioned, too?
<vila> malept: it exports all versioned files, I don't know the previous tarballs were done, yes of course, I need to bzr add it.
<malept> vila: ok, just checking
<vila> malept: I'm glad you did :)
<vila> malept: this release is long overdue, at least let's make it right, who knows how long it will last :-D
<malept> vila: indeed :)
<vila> malept: see my pm ?
<malept> vila: yes, sorry about that
<garyvdm> Hi vila. Can bug you for some help with tests?
<vila> garyvdm: sure, I'm trying to release bzr-gtk *properly* so I may suffer some interruptions :)
<vila> err, I mean, let's talk about your tests, but I may be lagging a bit at some points
<garyvdm> vila: I found a class in the PyQt source that can be used to test a custom qt model.
<garyvdm> It attaches it's self to some signals (events), and runs a test when that signal is fired.
<vila> nice, and is there some standard way to store the test result ?
<garyvdm> If that fails though, it stops all the tests, rather than reporting that the test failed, and continuning.
<vila> failing or erroring ?
<garyvdm> Whats the differenc?
<garyvdm> diference
<vila> ERROR or FAIL in selftest -v output
<vila> FAIL is when a specific asertXXX fails and throw a specific exception while ERROR is when a different exception is thrown and not caught
<vila> So a typo in test for example will error out
<garyvdm> Neither (and it should be an error). There is an exception raised in the test that is fired from a signal. The stack of this exception is written to the console by the std python exception handler, and all other tests are not run.
<vila> hmm, strange, are there threads involved ?
<vila> can you pastebin the traceback ?
<garyvdm> No threads - pastebin on the way.
<garyvdm> http://paste.ubuntu.com/213912/
<garyvdm> vila ^^^
<vila> you're not using --parallel ?
<garyvdm> No
<vila> Try running only the failing test
<vila> this traceback is too short, it makes no sense
<garyvdm> So maybe I need to overwrite sys.excepthook, capture the exception. And in the test, check if there have been any exception caught by the excepthook, and raise those.
<garyvdm> http://paste.ubuntu.com/213917/
<garyvdm> vila ^^^^ running only 1 test
<garyvdm> bbl
<Imperion> does Bazaar have that binary bug search functionality like git bisect?
<vila> garyvdm: no idea, but now you can set a breakpoint and do bt
<garyvdm> vila: Thanks - I think I need to do what I suggested above. I just wanted to check that there is not a built in way to do that.
<vila> Oh, I didn't see that,
<vila> try to understand why the exception is not caught by the test framework first, there is something weird here, working around it may not be the best long term solution
<garyvdm> vila: Exceptions that are raised by code called from a signal don't get caught by the bzr error handler. So in qbzr, we overwrite sys.excepthook to be able add information to the error report.
<garyvdm> I think the same thing happens with gtk.
<vila> haa
<vila> no matches for grep excepthook in bzr-gtk though...
<vila> I remember that in perl-gtk there was various ways to catch the errors though (including ignoring them)...
<Imperion> does Bazaar have that binary bug search functionality like git bisect?
<LarstiQ> Imperion: yes, bisect plugin
<dash> Imperion: there's a bisect plugin
<Imperion> thanks
<LarstiQ> though likely not as polished
<garyvdm> vila: I did a test with gtk, and it behaves the same. If I add "raise Exception("test")" to line 83 of branchview/graphcell.py, The stack of the error it written to the console hundreds of times, but it's not written by the bzr exception handler., e.g.: this is bit of that is written to the console: http://paste.ubuntu.com/213931/
<vila> garyvdm: If everything else fails, you can still use a dedicated mainloop
<vila> yeah, I'm reading stuff on this subject to refresh my memory,
<vila> the idea is that once you called mainloop.run(), all exceptions happening inside that call are caught, displayed and ignored ;0
<garyvdm> And if you want to have a global handler for them, you overwrite sys.excepthook
<vila> There may be a way to do the same with qt or as I said, for tests, use a specific mainloop that will fire one event at a time, you may get your hands on the exception that way
<vila> but adding a global handler will not allow you to re-reraise
<garyvdm> But I can get the exc_info (type, value, traceback).
<vila> and then ? call quit and re-raise but from where ?
<garyvdm> Thats what I'm going to figure out :-)
<vila> :)
<lifeless> moinmoin
#bzr 2009-07-10
<dash> Crud
<dash> shelve ate my changes :(
<dash> i'm using loom, I shelved some changes, then did down-thread
<dash> after doing up-thread and reverting the files, unshelve complains that a file id doesn't exist in the tree
<mwhudson> dash: :(
<dash> is there a way to read stuff out of a pack file
<dash> or partially apply this shelf
<mwhudson> probably
<dash> that's great
<dash> i guess.
<jml> dash, I don't think there's a way to partially unshelve from the UI.
<dash> ah well, it's only 7 conflicts anyway, i'll just redo it and be careful this time. :)
<lifeless> dash: please file a bug
<lifeless> dash: on bzr
<dash> ok
<ddaa> Hey there.
<ddaa> It seems reviewboard 1.0 has some trouble handling patches whose base is not in the main history of a branch.
<poolie> hello ddaa
<ddaa> Here, I'm submitting reviews with diffs produced by merging repo/feature into repo/trunk, and I base them in reviewboard on repo/feature.
<ddaa> It works okay the first time. Then I have a branch "cowbell" which gets an additional commit for review fixes,
<ddaa> Then "cowbell" is merged to trunk (where a conflict is resolved). And a branch "moreso", initially based on "cowbell", merges trunk back.
<ddaa> Then I cannot find how to give an updated diff to reviewboard for the changes in "moreso" over trunk.
<ddaa> poolie: hello pal
<ddaa> So, anyone here has experience with reviewboard and could help me?
<ddaa> poolie: What's up on down under?
<lifeless> ddaa: statik does
 * ddaa takes a kitty and rubs it on statik
 * ddaa loves to have fun with statik electricity
<lifeless> ddaa: I think he even wrote the reviewboard bzr stufff
 * ddaa tries pushing to moreso a merge from moreso into trunk.
<ddaa> Nope, I get again "The file id "None" is not present in the tree <Inventory object at b9a9c4cc... blah blah blah"
<ddaa> I guess there might be a way to make it work by providing a parent diff, but in this case I have no idea what it should be.
<ddaa> Mh... I guess maybe statik in on the wrong hemisphere to be up at this time.
<lifeless> is there a bug tracker for the reviewboard bzr plugin
<lifeless> ?
<ddaa> there's probably launchpad
<ddaa> actually, it seems not
<ddaa> I guess it's sharing bug tracker with reviewboard itself.
<jml> lifeless, can you please create a pqm-managed branch for the 1.17 rc?
<jml> or maybe http://doc.bazaar-vcs.org/bzr.dev/developers/cycle.html needs to be updated to say 'ask a losa'.
<ddaa> lifeless: I'm producing the diagnostic data you asked me a few weeks back.
<ddaa> The throughput appears to be a bit better now with 1.16.1 on both sides.
<ddaa> But it's still very variable.
<ddaa> no clear stalling though
<ddaa> much better, 4m9s real time
<ddaa> Comparing now to an upload of a tar of the .bzr in the repo
<ddaa> scp of tar of .bzr, 4m39s real time
<ddaa> meh... it's actually slower than bzr push
<ddaa> my uplink officially sucks so much they could it in the LHC
<ddaa> lifeless: so nothing to see, bzr push in 1.16 with 1.9 format repo is as fast as uplink. Maybe it was a temporary internet problem, or something to with the structure of the repo just after fast-import runs.
<ddaa> I guess you are not interested in the -Dhpss log then.
<lifeless> jml: it should say losa preferentially
<poolie> hullo jml
<poolie> ddaa, things are good here
<poolie> barcelona was nice
<lifeless> ddaa has logged :P
<poolie> ah, i have that squelched in irssi
<poolie> too noisy otherwise
<RenatoSilva> verterok: https://bugs.eclipse.org/bugs/show_bug.cgi?id=282226
<ubottu> bugs.eclipse.org bug 282226 in CVS "CVS feature abstraction" [Enhancement,New]
 * spiv -> lunch
<thumper> abentley: ping
<thumper> abentley: nm
<poolie> hello thumper
<thumper> hi poolie
 * thumper wishes quassel was smarter with tab completion
<abentley> thumper: hi.
<thumper> abentley: I was just wanting a reminder of the bzr send command to send relative to the pipe below, but I found it in my command history
<thumper> bzr send -r branch::prev.. for those interested
<abentley> thumper: It's also in "bzr help pipelines".
<abentley> s/pipelines/pipeline
<abentley> thumper: Well, the version for diff is.
<thumper> abentley: right, that is what I wanted
<lifeless> thumper: glad you like the idea
<lifeless> thumper: it came out of a discussion with poolie about 'targetting' reviews
<lifeless> thumper: I'm very keen to mae it easy for people to get engaged without us having to know a-priori who they are
<lifeless> args
<lifeless> (Pdb) locals()['args'][1]
<lifeless> AssertionError(u"path_utf8 is not a str: <type 'unicode'> base/\u65e5\u672c\u4eba",)
<lifeless> (Pdb) str(locals()['args'][1])
<lifeless> *** UnicodeEncodeError: 'ascii' codec can't encode characters in position 46-48: ordinal not in range(128)
<lifeless> so
<lifeless> test suite epic fail
<lifeless> another reason not to raise AssertionError - it won't always format sanely ><
<spiv> Yeah, exception formatting in Python isn't perfect.
<abentley> thumper: I'm thinking the "take-changes" command we talked about adding to pipeline should actually be "merge --interactive", i.e. part of core.
<thumper> abentley: but I only want text changes not any merge revisions
<thumper> as long as it does that
<thumper> I'd be happy
<abentley> thumper: when we do partial merges, we don't set pen ding merges, if that's what you mean.
<abentley> s/pen ding/pending
<thumper> what about an interactive merge that takes everything?
<lifeless> I'd love to see that
<lifeless> I did a hacky one for bzrtools but never wrote enough tests to get it accepted ;P
<lifeless> thumper: it could ask about full merges
<abentley> thumper: well, the theory is that it would set pending merges.
<lifeless> thumper: why don't you want merge revisions though?
<lifeless> (we plan to eventually record partial merges too, in some fashion, to aid reporting of cherrypicks)
<thumper> abentley: jml has work in progress for a cleaned up merge interactive I believe
<spiv> There's always bzr revert --forget-merges if you really don't want merges recorded.
<lifeless> jml: did you get the branch made?
<poolie> lifeless: those decorator generators are kind of cute
<poolie> maybe almost too cute
<lifeless> poolie: we have many delta appliers
<lifeless> I was hoping to structure things to allow reuse
<lifeless> they could be structed as 'here, check this list', but that then requires that we have a list
<poolie> mm
<poolie> so you could have an explicit 'fan out this iterable' function
<poolie> there may be one in itertools?
<poolie> which calls some things for side effects and then yields the results of the original iterable
<poolie> this is essentially just to split out the 'for thing:... yield thing' from those functions
<poolie> to make it clear they don't change
<poolie> but i'm not sure that's much better
<poolie> anyhow, +1
<lifeless> thanks
<lifeless> I have the test fallout fixed
<lifeless> http://pastebin.ubuntu.com/214176/
<poolie> k
<lifeless> if you could eyeball that
<poolie> i'm going back to bug 391411
<ubottu> Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411
<poolie> oh ok
<lifeless> I just got that done before saying 'thanks' ;)
<lifeless> it corrects a couple of bugs in the validation code I added by testing against unicode entries, and cleans up some other tests that were expecting a different interface
<lifeless> and removes a doctest error case that really wasn't very helpful where it was. I did some doc cleanup at the same time.
<poolie> so in the 'parents = set()' thing
<poolie> can you explain in the comment which parents will be in this list
<lifeless> sure. Its all of them.
<poolie> all in the whole dirstate?
<poolie> ok
<lifeless> all in the delta
<lifeless> we don't know parents for removed items
<lifeless> I'll add some text
<poolie> maybe change dirname and basename to dirname_utf8 and basename_utf8, as they seem to be
<lifeless> roger
<lifeless> will do the same in check_parents too
<lifeless> poolie: anything else? and I'll let you get back to 391411
<poolie> still reading
<poolie> looks good
<lifeless> thanks
<poolie> i might put up a patch sometime that renames the other directories to per_workingtree etc
<poolie> spiv, in bug 391411 i'm thinking about how to do reconfigure --unstacked to an hpss branch
<ubottu> Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411
<poolie> it needs to fetch from the fallback repository into the to-be-unstacked one
<lifeless> poolie: I would like that; making them consistent again would be nice
<poolie> i think, unless you know something really clever, i need a new Client
<poolie> do you know a tasteful way to get one?
<poolie> k
<lifeless> SmartServerClient?
<lifeless> they are coupled to the transport; the most robust way would be 'b2 = bzrlib.branch.Branch.open(self.base)'
<poolie> yeah
<poolie> that's what i had in mind too - we don't implicitly share by url, so going back to a url should force a new connection
<lifeless> I think you should be able to solve this without writing specific code in remote.py at this point in time
<poolie> i think so too
<poolie> as i said on the phone it would almost be possible to do it over one connection
<poolie> but simple=good
<lifeless> I suggest a comment about the rationale
<lifeless> for review streamlining :)
<spiv> poolie: yes, I think you need a new client, well a new medium really...
<spiv> poolie: It might be nice to have a method on _SmartClient that can make a new connection for you, but as lifeless says taking the URL and constructing a new transport from that will work.
<GungaDin> How do I change the user to checkout stuff with?
<lifeless> GungaDin: what do you mean?
<GungaDin> my account user is X and I'd like to checkout from the repository as user Y.
<poolie> over ssh?
<lifeless> you can put Y@ into the url
<lifeless> if its launchpad however, you should use groups to manage this sort of thing, rather than impersonation
<GungaDin> yeah, alright.
<GungaDin> it's working now.
<GungaDin> thx
<lifeless> happy to help
<lifeless> poolie: EOD; ciao
<lifeless> well, nearly
<lifeless> ringing jml first
<poolie> cheerio
<vila> hi all
<poolie> hi vila
<vila> hey poolie !
<poolie> vila does bug 397716 ring any bells with you?
<ubottu> Launchpad bug 397716 in bzr "timezone-dependent annotation test failures" [High,Confirmed] https://launchpad.net/bugs/397716
<vila> hmm, indirectly yes
<vila> it's "It's yesterday in California" again :)
<poolie> again :)
<vila> so, I think there is a TZ arg somwehere that can be used (it was the case for log, not sure for annotate)
<poolie> arguably we should just set it in the tests for the sake of isolation
<poolie> however i think in some environments setting it after the program starts is not enough
<vila> I think the case you're encountering is only relevant in tests (it was the case for log when I saw that), if I'm not mistaken the problem here is that the TZ is not used coherently between commit and annotate, you can't do that from command-line
 * vila . o O ( TZ... Yet another interesting test farm variation...)
<vila> wow, 'tranche' is used in English ?
<bob2> yes
<vila> And it applies to ham as well as building houses ?
<poolie> lol
<poolie> :)
<poolie> it mostly applies to finance actually
<poolie> but it would be a nice word to use for ham
<poolie> where did you see that?
<vila> bzr.dev@4524 commit message :)
<vila> no connection to money here :)
<vila> "a portion of something " says my gnome-dictionary-applet... The french word come from "trancher" i.e. cut with a knive or sword, so I think literal translation should be slice :)
<poolie> yes, i was just going to say that
<poolie> i guess with the connotation that, perhaps, you eventually intend to eat all of it
<vila> Really ? Interesting, not the case in French :)
<fullermd> Did somebody say 'eat'?
 * fullermd perks up.
<poolie> mm, actually i do think that's why you'd use that word specifically
<poolie> that there are a small finite number and you expect them all to be taken
<vila> well, it's really used for ham and you really don't want to eat a full ham, 2 tranches, maybe 3 but no more :-)
<vila> ha, yes, the set of tranches is expected to be all eaten :)
 * fullermd thinks you underestimate his stomach for swine...
 * vila wonders what happens when you feed fullermd after midnight....
 * poolie gets undistracted
<fullermd> That's where adjusting TZ helps, see  ;)
<vila> poolie: regarding bug 3977716, looking at test_annotate it looks like the timezone parameter get lost in the refactoring, good diagnosis
<ubottu> Error: Launchpad bug 3977716 could not be found
<vila> what.. too much 7 ? Can't you just fix such obvious typos on the fly ? Come on... bug #397716
<ubottu> Launchpad bug 397716 in bzr "timezone-dependent annotation test failures" [High,Confirmed] https://launchpad.net/bugs/397716
<vila> poolie: I can reproduce the bug, are you working on it or should I assign it to me ?
<poolie> i'm not now
<poolie> i'm trying to finish 391411 before s gets home :)
<vila> poolie: ok, go !
<lifeless> poolie: interestingly, wiktionary has the finance definition as the 2nd meaning
<poolie> begone, forces of distraction
<lifeless> its friday
<lifeless> friday night
<poolie> :)
<vila> yeah, they are stronger :)
<poolie> well, it is the more specific use
<poolie> i think it's also the place you most commonly see it
 * vila just feels the difference since he changes its TZ to utc+10...
<poolie> nothing wrong with your use of course
 * vila blesses the one who removed ctrl-alt-backspace *default-and-hard-to-get-rid-of* shorcut that used to kill the X server, thank you, thank you, thank you
<pygi> vila: why lol? :D
<pygi> don't be silly, shooting xserver is cool
<vila> pygi: because the shorcut was too close to alt-backspace which I use a lot and killing my X server without confirmation (yeah I know, non-sense, but yet) and bringing down my http client, mail client, chat client, bunch of emacses just because I mystyped 'delete-word-backwards' is a not excessive for my taste
<vila> s/not/bit/.... some typos... are... not understandable :)
 * vila looks its keyboard... yes io and bn are contiguous on qwerty... clap-clap-clap, well seen big brain :)
<vila> s/its/his/
<poolie> that was quick :)
<vila> poolie: still there ? Regarding lp:~mbp/bzr/trivial into lp:bzr, let me know before leaving if you want me to do the tweaks and merge
<poolie> hi
<poolie> i am
<poolie> i think i fixed 391411
<poolie> thanks for reviewing it
<poolie> oh you didn't need to spend so long making all those dittos
<poolie> i probably should leave so if you'd like to sort them that would be nice
<poolie> i actually have mixed feelings about sorting them as part of an otherwise-mechanical change
<vila> poolie: you actually have or had ? The intent of your patch is to be more coherent in naming IMO, that's good reason to *not* break another convention :)
<poolie> :)
<poolie> have
<poolie> just in having less risk of breaking things
<poolie> but you're probaly right
<vila> ha ! That should be guarded by a full test suite passing :)
<poolie> :) true
<poolie> ok, good night
<saedelaere> hi, i'am completely new to bazaar and version control system. One thing i don't understand from the manual. I want to ignore to directories completely by "bzr add"
<saedelaere> as i understood correctly i can use .bzrignore for this task. I tried for example "org_icons/*.*" but still files in that directory will be added. Where do i have to put the file ".bzrignore"? thank you!
<fullermd> .bzrignore goes in the root of the tree.
<fullermd> And you probably want 'org_icons/*' more, though I guess it likely doesn't make a huge difference in this case...
<lamalex> Hi, i just ran bzr upgrade on my repo and now I get this -> bzr: ERROR: The branch lp:do-plugins has no revision None.
<saedelaere> fullermd. ok i think i got it
<saedelaere> thank you
<lamalex> this is mm .. kind of serious
<lamalex> wtfff I can do a merge frm lp:do-plugins but i cant branch
<vila> lamalex:  I can branch lp:do-plugins without problem from here, what bzr version are you using ?
<lamalex> vila: really?
<lamalex> what does bzr info -v say for you?
<vila> lamalex: do you always reply to a question by another question ?
<lamalex> vila: almsost always
<lamalex> Bazaar (bzr) 1.16.1
<vila> with bzr.dev I got a repository: Packs containing knits without subtree support, branch format 6
<vila> and the remote branch has the same repo/branch characteristics
<lamalex> hmm... what the hell
<lamalex> i just bzr upgraded it to 1.6.1-rich-root
<vila> so that's pack-0.92, it's pretty old now, what did you upgrade from ? And when ?
<lamalex> and now I can't branch, but you can, and you have the wrong format
<vila> lamalex: ha, we are not seeing the same branch then, certainly due to the fact that you have write access, so I still see the old one because it hasn't been mirrored yet
<lamalex> i wonder what wnet wrong
 * lamalex restores backup
<vila> what is your .bzr.log saying ?
<lamalex> vila: http://paste2.org/p/314256
<vila> 1) try without --stacked, 2) try with bzr.dev
<lamalex> ive tried without --stacked
<lamalex> same thing
<lamalex> will try bzr.dev
<lamalex> wwait what is bzr.dev
<vila> with and without --stacked (although if you have a local mirror using --stacked doesn't gain you much compared to a shared repo)
<vila> bzr.dev is lp:bzr
<vila> lamalex: what OS are you using ?
<lamalex> ubuntu 9.04 with bzr ppa
<vila> hmm, I can try to help you setup bzr from sources but you may prefer switching temporarily to the nightly ppa
<lamalex> i just reverted it to the pack-0.92
<lamalex> going to try this again..
<lamalex> is there anything special i should know aobut upgrading?
<lamalex> i've gotta be doing something wrong
<vila> what did you do ? Why did you chose 1.6.1-rr instead of say --1.9-rr ?
<vila> or even 1.14-rr or --default-rr ?
<vila> and why do you want to upgrade to start with ? :-) Mainly curious but it may help understand the issue...
<lamalex> we want stacked branches
<vila> locally or on lp ?
<lamalex> and we chose 1.6.1-rich-root because I think it was the greatest that jaunty bzr supported
<lamalex> vila: on lp
<lamalex> would you say not to use 1.6.1?
<vila> hooo, yes sorry, so used to ppas, I forgot about the version shipped with jaunty, but are you sure it's 1.6 that sounds really old...
<lamalex> RAOF said 1.6, I didnt check myself. I trusted his opinion on 1.6.1
<vila> http://packages.ubuntu.com/jaunty/bzr says 1.13
<vila> RAOF ?
<lamalex> a person
<vila> ha, ok :)
<lamalex> does our packaging, is generally more or less knowledgable about things like this
<lamalex> so you think we should do 1.13-rr
<vila> lamalex: no :-) that one doesn't exist but you can use 1.9-rich-root
<lamalex> heh
<vila> try 'bzr help current-formats'
<lamalex> whats the advantage of rich-root over normal besides svn/git
<npoektop> yo! is there a way to ignore executables in my code repository other than marking them with .exe (or smth) extension?
<lamalex> npoektop: .bzrignore?
<vila> none, but since you are migrating you'd better take the rich-root route once because it will become the default once we reach 2.0
<lamalex> vila: ok :)
<npoektop> lamalex: how to ignore executables?
<vila> the problem is that converting to rich-root is a one-way street, you can't come back nor interoperate with non-rr
<lamalex> so for upgrading- bzr upgrade --format=1.9-rich-root lp:do-plugins /should/ work?
<vila> lamalex: yes
<lamalex> hm
 * lamalex runs a check and a reconcile first just to be safe
<vila> but then you should also upgrade all branches you want to interact with it
<lamalex> right, we know that
<vila> good reflex, sorry, should have mentioned it :-/
<vila> then you need to make sure the branch is mirrored (see #launchpad for that, I'm not sure what the right procedure is needed here)
<lamalex> will do
<vila> since you have write access to lp:do-plugins, you cant really see the mirror yourself (that's why we got different results)
<lamalex> i can use a different account
<vila> that should do the trick as long as the other account doesn't have write access :)
<lamalex> heh :)
<vila> Is there a LOSA around ? I've got a very stange failure on PQM, as if some old python modules were still present in the working tree... a make clean there may address that
<npoektop> how to ignore executables in .bzrignore?
<vila> npoektop: by listing them either explicitly or by using a regexp, but there are no way to automatically recognize executables (so far)
<npoektop> now i mark them with .exe, but it looks ugly
<vila> npoektop: to you a lot of them ?
<vila> npoektop: do you a lot of them ?
<npoektop> yes, i have ~/code with many small projects
<mzz> well, bzr does know which are marked executable (if you're on a filesystem that supports this) but there's no way to use that info in .bzrignore
<mzz> I wonder if a plugin could add that
<npoektop> good idea
<amanica> vila: did you want me to change that test or can I just go ahead and resubmit?
<amanica> (I need to leave soon for the weekend)
<vila> amanica: just a sec, how long soon ?
<amanica> 20 minutes
<vila> amanica: it's ok, these tests could use more love anyway, if only to stop matching texts when we can use LogCatcher to get more precise comparisons
<amanica> vila: I didn't mean to rush you, but thanks. yes that makes sense.
<vila> amanica: if you keep working on log, I'd really appreciate if you could try to put more tests in tests/test_log.py and less in tests/blackbox/test_log.py :-D Not a requirement, but I'll appreciate :)
<amanica> vila, thats a pet peeve of me too
<amanica> but that sounds like a project on its own
<vila> amanica: no problem, nagging was perfectly reasonable here, I read the whole thread and then forgot that mentioned waiting for a feedback, sorry :-/
<vila> amanica: nahh, once test a time :)
<amanica> cool
<vila> amanica: I'd like the log tests to be as concise as the ones I lastly wrote for push and send (if you're interested)
<vila> too many tests try to test too many aspects of log, each time we tweak a particular aspect we have to fix a bunch of not directly related tests: that's a clear sign of bad defect localization :)
<amanica> vila: cool, an new chalenge! I won't mind doing that if I get time
<vila> amanica: great !
<amanica> it helps if someone is interested enough to review quickly.. thanks
<ddaa> statik: ping
<vila> amanica: I know...
<amanica> vila: if you have some thought you are welcome to write a short bug on this and assign it to me
<amanica> /thought/thoughts
<vila> amanica: ok
<vila> amanica: I need to look at it again, but from memory, some tests can be refactored as is, some needs some refactoring of the code itself to better separate the various aspects, so I need to re-read some code, feel free to ping me again on the subject if I forget to file that bug
<amanica> vila: cool, and you me
<vila> ok :)
<amanica> \me need to go soon
<amanica> whoops
<vila> amanica: enjoy your week-end !
<amanica> vila: thanks, you too
<amanica> bye
<ddaa> Ok, I found a way to make reviewboard work with my branching and merging situation.
<ddaa> It something involving a "parent diff"
<ddaa> If I understand correctly, reviewboard expects to have all diffs in the same review to have the same base.
<ddaa> So. I have trunk-base as a common base.
<ddaa> Then I have "feature" revision, and the first diff is trunk-base..feature.
<ddaa> Then if I have a some more commits in trunk, leading to trunk-new.
<ddaa> And I merge trunk-new in my feature branch, leading to feature-new.
<ddaa> I must update the diff in the review by specifying the "feature" branch as repository path.
<ddaa> trunk-new..feature-new diff as the new diff
<ddaa> and the trunk-base..trunk-new diff as its parent diff
<ddaa> Geez, that's so fricking complicated!
<ddaa> Is there a simpler way to say the same thing?
<ddaa> (jargon welcome)
<mzz> I'm going to wildly guess you might be looking for "ancestor:" but I haven't actually parsed your problem description
<ddaa> mzz: half of my problem is that i find the procedure to make revie
<ddaa> to make reviewboard happy very difficult to explain.
<ddaa> So I'm looking for better ways of explaining it.
<npoektop> there is an option for commit: --unchanged, it makes it commit even if no changes in repository. i don't want to commit with no changes and i don't want to see the error message that no changes. it is for crontab task. i don't want to 2>&1 /dev/null because i want to see sufficient errors. how to do that?
<lamalex> npoektop: why dont you do bzr stat -V first and only commit if there are changes?
 * npoektop reading docs
<npoektop> lamalex: thanx
<rockstar> jam, does TestCaseInTmpDir clean up after itself?
<jam> rockstar: yes
<rockstar> jam, great, thanks.
<rockstar> jam, I should be more specific.  Does it remove the temp dir it creates?
 * ddaa still talking alone about reviewboard
<ddaa> To state it better, I think what's needed is providing branch-point..ancestor as the parent diff, and ancestor..last as the review diff.
<ddaa> But there does not seem to be a way to select the branch point.
<ddaa> I need something that allows me to find the latest revision that common to the mainline of the current branch and another branch.
<ddaa> s/that common/that is common/
<LarstiQ> ddaa: based on -rancestor: ?
 * ddaa thinks more... no actually I need something different.
<ddaa> LarstiQ: kind of. I'm trying to figure a way to state how to feed diffs to reviewboard.
<ddaa> But common mainline ancestor does not work when the initial diff is feature-1->feature-2, and a later diff is trunk->feature-2-updated, because feature-1 was merged in trunk.
<vila> rockstar: with some help from atexit, yes
<rockstar> vila, yes, but the TestCase registers that handler right?  I don't have to do anything special?
<vila> rockstar: nothing special... except exiting from your python script :)
<vila> rockstar: since you were more specific in your last question I thought you had special use case (or bug) in mind, so I tried to be extra-precise
<rockstar> vila, thanks!  :)
<rockstar> What version of bzr introduced HookPoint?
<rockstar> jam, ^^  Which version did you need for your Windows work yesterday?
<garyvdm> Hi all
<jrwren> I'm having some weird issues. we use centralized workflow, and 1 person is having an issue when he does bzr up, he regularly gets conflicts that others don't get. On files that he has not touched at all.
<jrwren> most recently its "file already exists" and moving them to .moved files and showing that as a conflict.
<jam> rockstar: sorry about the delay.. I don't know what version introduced it. I'll check
<jam> (I just installed bzr.dev because that was the easiest)
<rockstar> jam, okay.  Not a big deal, we're just wanting to package a new Tarmac soon.
<jam> rockstar: looks like bzr 1.13 add hooks.known_hooks
<rockstar> (We're sprinting on Tarmac currently)
<jam> real sprinting, or virtual sprinting?
<al-maisan> Hello there, is there a way to go back a revision in a branch. I did a "bzr pull" but would like to go back to rev N-1
<Tak> al-maisan: temporarily, or permanently?
<Tak> jrwren: does it still happen if he does a clean checkout?
<jrwren> Tak: probably not, no.
<jrwren> but finding why it happens at all would be more useful
<Tak> my first WAG looking at the symptoms is that for some reason his checkout doesn't think it's on the same tree as upstream
<Tak> or maybe he reverted to some old revision and then updated from the server before reverting to head?
 * al-maisan has an idea: I can make another local branch and specify -r before:N
<Tak> or you can `bzr revert -r whatever`
<al-maisan> ah OK
<al-maisan> Thanks.
<fta> how do i specify a different email address for a directory containing a lot of branches?
 * SamB can't help but think of some kind of alist
<RenatoSilva> verterok: hi Guillermo, I've answered your comment about bzr-java-lib test. I suspect you don't have UTF-8 set either :) maybe it's just using system's default just like me :) how about including the .project and other stuff in lp's branch?
<verterok> RenatoSilva: Hi, I just got the email
<verterok> RenatoSilva: yes, I'm using UTF-8 at a workspace level
<verterok> RenatoSilva: the eclipse config files are generated by maven
<verterok> RenatoSilva: I'll look how to force maven to set UTF-8
<RenatoSilva> verterok: ok, but people could be using bzr-eclipse's new project wizard
<RenatoSilva> verterok: and forget to run mvn
<verterok> RenatoSilva: heh, yes, but in the case of bzr-java-lib, executing mvn eclipse:eclipse is a requirement, it's in the README ;)
<RenatoSilva> verterok: ok :)
<RenatoSilva> verterok: the file .settings/org.eclipse.core.resources.prefs is the one which stores project encoding
<verterok> RenatoSilva: oh, nice
<verterok> RenatoSilva: ok, I'll look into that
<RenatoSilva> ok
<verterok> RenatoSilva: fwiw, I landed some branches yesterday in bzr-eclipse (also in the headless build branch) and bzr-java-lib
<RenatoSilva> ok
#bzr 2009-07-11
<R4p70r> I sent [MERGE] email to the mailling list but I've put the merge directive inline instead of making an attachment. Is the Bundle Buggy smart enough to recognize it?
<dented42> I have a question about packaging...
<dented42> aimed at whoever can answer
<dented42> I have in my project directory, a folder that contains documentation generated by doxygen.  As this gets generated automatically, I put it in my ignore file to save space.  Whenever I export, the documentation is not included because naturally, it is ignored.
<dented42> My question is this: Can I somehow make this documentation a part of the exported tarball while at the same time not have it versioned?
<dented42> ok then, bye
<bob_f> Hello. I cannot see anything that resembles "hg convert" (i.e. to convert an existing hg/git/whatever repo to bzr). Is there such a utility ?
<mzz> bob_f: for what format(s)?
<bob_f> mzz: hg
<mzz> bob_f: I haven't used it, but http://bazaar-vcs.org/BzrForeignBranches/Mercurial might do the trick
<bob_f> Hmm, maybe I'll just stick with hg after all.
<dash> bob_f: last time i had to do that, the hg plugin worked pretty well
<bob_f> dash: Well, the other bpython dudes are whining.
<mzz> yes! we do that a lot
<dash> bob_f: sorry I mean: the bzr plugin for reading hg repos worked.
<mzz> I think that's the same one I linked to
<ddaa> last time I tried (a month back, or so)
<ddaa> bzr-hg failed miserably
<ddaa> so I used bzr fast-import with hg's export command
<ddaa> But it was pretty bad too. Apparently the export-import step lost all information about file renames and file deletions.
<RenatoSilva> verterok: http://bazaar.launchpad.net/%7Everterok/bzr-eclipse/trunk/annotate/head%3A/org.vcs.bazaar.eclipse.ui/src/org/vcs/bazaar/eclipse/ui/internal/TeamAction.java#L174
<RenatoSilva> verterok: Discouraged access: The method getContributedResources(Object[]) from the type Utils is not accessible due to restriction on required library C:\Arquivos de programas\Eclipse Galileo\plugins\org.eclipse.team.ui_3.5.0.I20090430-0408.jar
#bzr 2009-07-12
<RainCT> Hi
<RainCT> Isn't "bzr pack" supposed to reduce the size of .bzr, and not to double it? http://paste.ubuntu.com/215878/plain/
<RainCT> Or is it keeping an uncompressed backup around or something?
<pygi> RainCT, you need to clean the old packs
<RenatoSilva> bzr revno file:///d:/ProgramaÃ§Ã£o/Utilidades/csvt.rb
<RenatoSilva> bzr: ERROR: Unsupported protocol for url "file:///d:/ProgramaâÂºâÃºo/Utilidades/csvt.rb"
<jkakar> lifeless: I've integrated bzrlib.commands.Command and Command.hooks into Commandant and I have all the tests passing!
<jkakar> lifeless: There's still more tests to write and I'd like to do some cleanup.  Thanks a lot for the Command.hooks refactoring, it's really working well for me.
<Junqiang> EOL filter doesn't work in bzr, is there any plan on it?
<faceprint> how interested are you guys in hearing about crazy (but real world) comparisons between 2a and 1.14-rich-root?
<LarstiQ> faceprint: rather
<faceprint> I'm moving my development team off of CVS to bzr later this month.  The repository dates back to 2003, and I've used tailor to create and keep up to date a bzr mirror of the CVS repository.  I've got about 30k revisions of about 10k files.
<LarstiQ> faceprint: that's a nicely sized tree
<faceprint> I've got code files that have between 1 and a few hundred revisions, typical development commit patterns, and then some data files that are less-than-ideal for an SCM.  One example has 220 revisions, about 400k lines, and weighs in at about 10 MB
<LarstiQ> right
<faceprint> I've been trying to benchmark this repo 6 ways from sunday so I can be prepared for any complaints from my teammates
<faceprint> on a 1.14-rich-root copy, that big data file takes 5:30 to annotate, and chews up about 1.8 GB of memory in the process
<LarstiQ> ouch
<LarstiQ> faceprint: which version of bzr is that with?
<faceprint> 1.16.1
<LarstiQ> ok
 * LarstiQ looks up when jam's annotate-for-big-files changes landed
<faceprint> 2a has been running for 30 minutes so far, and I think it's up over 6 GB of memory
<faceprint> this is the first thing i've seen "worse" on 2a, thought you guys might like to hear about it
<Raim> hi
<LarstiQ> faceprint: certainly!
<Raim> is there a way to bypass aliases for automation?
<LarstiQ> faceprint: could one of the core devs experiment with a copy?
<faceprint> LarstiQ: unfortunately that's out of the question.  very private repo.
<LarstiQ> Raim: --no-aliases?
<faceprint> but if you can tell me which "dimension" of absurdity to go in, I might be able to try and recreate something similar that exhibits the behavior
<LarstiQ> faceprint: I think jam or igc would be better suited to give you that feedback
<Raim> LarstiQ: yeah, was looking for that exactly. thanks :)
<LarstiQ> Raim: lifted from `bzr help global-options`
<LarstiQ> Raim: now, if you're doing automation with python and bzrlib, the answer would be different :)
<LarstiQ> faceprint: are you subscribed to the mailing list?
<faceprint> LarstiQ: not yet.  i've been reading archives all weekend ;-)
<Raim> LarstiQ: no, it's about shell automation. I ran into a problem as I aliased "bzr diff" to "diff --using 'colordiff -u'" and then patch naturally chokes on the color codes
<LarstiQ> faceprint: since a post about this to the list will get more exposure than irc when most core devs are not working :)
<LarstiQ> Raim: right
<faceprint> LarstiQ: is it relatively easy to grab bzr.dev and use it w/o touching my regular install?
<LarstiQ> Raim: how about `bzr cdiff` from bzrtools? Doesn't it do terminal detection?
<LarstiQ> faceprint: yes, very
<LarstiQ> faceprint: since bzr runs from source, no installation required, just invoke the right binary
<faceprint> excellent.  i'll give that a whirl and see what kind of results I get.
<LarstiQ> faceprint: you will want to make sure the C extensions are built for performance, but that can happen inplace
<LarstiQ> just run `make` and install the dependencies (pyrex, python-dev and a C toolchain afaik. Oh, libz-dev perhaps
<LarstiQ> faceprint: do I understand it correctly that your 1.14-rr is based on a continual tailor conversion?
<Raim> LarstiQ: I think I tried that, but it had problems in combination with bzr-pager
<LarstiQ> Raim: ah
<LarstiQ> Raim: sounds like something to fix :)
<LarstiQ> Raim: if you can tell me how to reproduce it, I can file a bug
<faceprint> correct.  it syncs the CVS once an hour to a 1.14-rr that is bound to a server with a rich-root-pack repo (because I can't upgrade that copy of bzr yet)
<Raim> LarstiQ: this one, https://bugs.launchpad.net/bzr-pager/+bug/329845
<ubottu> Ubuntu bug 329845 in bzr-pager "Incompatibility with diff from bzrtools ('DiffWriter' object has no attribute 'isatty')" [Medium,Fix committed]
 * LarstiQ sits back as other people file bugs ;)
<LarstiQ> Raim: also seems like luks merged the fix
<faceprint> LarstiQ: FYI, bzr.dev on the 1.14-rr was twice as slow as 1.16.1.  I'm running it on 2a now.
<LarstiQ> faceprint: specifically annotate on that large file?
<faceprint> crap, I forgot about running make.  that's probably not valid results
<LarstiQ> valid if you want pure python, but slower :)
<faceprint> i'll wager that my 1.16.1 deb has the C extensions, so not apples to apples at the very least
<faceprint> wow, big difference.  bzr.dev much faster on that repo now.  1:02 vs 5:28 with 1.16.1
<fullermd> Yeah, there's some new stuff with annotate since then.  In the last few days, actually.
<faceprint> 2a is much better as well: 2:32 vs (did not finish) with 1.16.1.  and it ended up using a few hundred MB, vs 6 GB with 1.16.1
<faceprint> are those speedups destined for 1.17, or a later version?
<fullermd> They'll be in 1.17 I'm pretty sure, it hasn't branched yet.
<fullermd> (always barring bugs being found that call for backing it out prior to that of course)
<faceprint> naturally
<garyvdm> Is it possible to have shelve give me a move granular choice. It's groups some changes together.
<garyvdm> s/move/more
<LarstiQ> garyvdm: as opposed to?
<garyvdm> It groups some of the changes together.
<garyvdm> I want to shelve only some of them,
<LarstiQ> garyvdm: in one hunk you mean?
<LarstiQ> garyvdm: ie, you want hunksplitting?
<garyvdm> LarstiQ:http://paste.ubuntu.com/216364/
<garyvdm> I want to shelve the refresh button code.
<garyvdm> but not the larst change.
<LarstiQ> garyvdm: yeah, hunk splitting
<garyvdm> Ok
<LarstiQ> garyvdm: which would be very cool to have
<garyvdm> I would think that those are different hunks...
<garyvdm> anyway
<LarstiQ> garyvdm: right, but the diffing algorithm didn't
<LarstiQ> garyvdm: so that is where you as a human could come in to augment the algorithm
<garyvdm> LarstiQ: from my understanding of the term hunk - the diffing algorithm would think that those are different hunks.
<LarstiQ> garyvdm: they're both in the same set between @@' right?
<garyvdm> Yes
<LarstiQ> those are the hunk delineators
<garyvdm> Ok
<LarstiQ> gnu diff has some options to make it try harder to make the hunks smaller
<LarstiQ> don't know about patience diff
<LarstiQ> garyvdm: all a long way of saying, afaik you can not easily do that right now
<LarstiQ> garyvdm: but I'd really like to be able to :)
<saedelaere> hi
<saedelaere> i'am completely new to a vcs and bazaar. i've read the user guide but having some problems to understand some things.
<saedelaere> i'am developing a software that is hosted on sourceforge and want to use the bazaar service there. I'am the only developer there so i need the repo so users can get the latest source code.
<saedelaere> so the first thing. i did
<saedelaere> bzr init
<saedelaere> bzr add
<saedelaere> bzr commit -m "blabla"
<saedelaere> bzr push ...
<saedelaere> now i get a message
<saedelaere> "This transport does not update the working tree of: bzr+ssh://christianrapp@tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer/. See 'bzr help working-trees' for more information.
<saedelaere> Created new branch."
<saedelaere> what does this mean? when i did some changes to the code. how do i update the repository on sourceforge? using bzr push?
<LarstiQ> saedelaere: yes, using bzr push
<LarstiQ> saedelaere: I wonder why youget that message though
<LarstiQ> saedelaere: how did the branch at .../tv-viewer/ come into existance?
<LarstiQ> bzr should only say that if there is a working tree present, which there is no need for
<fullermd> Well, presumably by that push, since it said 'created new branch'...
<LarstiQ> fullermd: then why does it mention updating a working tree?
<saedelaere> should i have done this first?
<saedelaere> bzr init-repo --no-trees sftp://centralhost/srv/bzr/PROJECT
<saedelaere> and then continue like this?
<saedelaere> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#publishing-a-branch
<LarstiQ> saedelaere: not per se
<LarstiQ> saedelaere: it will consume less storage and be faster if you use multiple branches, but other than that no difference
<saedelaere> branch, working-trees puhh still not understanding completely :)
<saedelaere> ok then i've done nothing wrong
<saedelaere> like i said i need the repo on sourceforge only so users can get the latest source code
<garyvdm> No - people will still get a working tree when they pull
<garyvdm> I would think that is a bug with the hosting.
<garyvdm> *think*
<LarstiQ> garyvdm: are you seeing someting I'm missing?
<garyvdm> LarstiQ: I'm baseing that on a big assumption. Let me just somthing.
<LarstiQ> sure
<saedelaere> ok one more thing. when i ever find someone who whants to contribute and is also allowed to write to my repo, how do we keep our work synchronized? bzr merge "path_to_my_repo_on_sourceforge", will this command add all changes to my local repository?
<garyvdm> LarstiQ: my assumption was wrong. So the branch with working tree must have been created before the push?
<garyvdm> saedelaere: Yes
<LarstiQ> garyvdm: I don't really understand what is going on, lack of information
<LarstiQ> saedelaere: that will work
<garyvdm> saedelaere: and if someone else who does not have permissions to you trunk branch on sf, they can push there changes to another branch sf, and you can merge from that branch.
<garyvdm> This is one of the big wins for Distributed VCS.
<LarstiQ> or you can even use `bzr send` and email the commits
<garyvdm> saedelaere: If you get the "can't update remote wt" error in future...
<garyvdm> You need to get on of the sf admins to do "bzr remove-tree BRANCH" on the server.
<LarstiQ> if you can access it with bzr+ssh, you can do it yourself
<garyvdm> Oh
 * fullermd isn't sure that follows...
<garyvdm> LarstiQ: bzr: ERROR: You cannot remove the working tree of a remote path
<LarstiQ> garyvdm: I was thinking of hitchhiker
<LarstiQ> but you are right, that is more manual than `bzr remove-tree`
<garyvdm> hitchhiker?
<LarstiQ> which I guess is not a good idea for non-experienced people
<garyvdm> What is hitchhiker?
<LarstiQ> garyvdm: lp:hitchhiker, an ftp like client based on bzr's transports
<garyvdm> ok
<fullermd> It's sorta a manual shell on the bzr protocol.
<garyvdm> I understand why we can push to a remote wt, but would it not be easy to code bzr to remove a remote wt?
<garyvdm> s/can/can't
<LarstiQ> garyvdm: not entirely
<LarstiQ> garyvdm: you need to check for unknowns
<garyvdm> Oh - right
<LarstiQ> garyvdm: you are right that we don't have to do conflict merging, so no getting of the content
<LarstiQ> so at a minimum one extra listdir
<saedelaere> ok i just pushed my second revision and the error did not appear again.
<saedelaere> thanks for all your help and hints. oh and great tool. really easy to use. I also tried svn but that was much to complicated.
<LarstiQ> saedelaere: good to hear :)
<saedelaere> i do a commit with
<saedelaere> bzr commit -m "foo"
<saedelaere> now i want to add several different messages to this commit
<saedelaere> bzr -m "foo
<saedelaere> bar
<saedelaere> baz"
<saedelaere> seems not to be possible to split the message into several lines. Correct?
<LarstiQ> saedelaere: incorrect. But if you use -m it depends on your shell being able to handle it.
<LarstiQ> saedelaere: I use zsh and there it works.
<LarstiQ> saedelaere: alternatively, don't use -m and just let the editor come up, or write a commit message to file and use -F
<LarstiQ> saedelaere: see `bzr help commit`
<saedelaere> ah thats a good idea, thanks :)
<garyvdm> saedelaere: There also guis available.
<garyvdm> bzr qcommit from qbzr
<garyvdm> or bzr gcommit from bzr-gtk
<garyvdm> On windows - qbzr comes with the installer.
<saedelaere> i wanted to learn bazaar from the scratch so i started with the terminal. perhaps later i will try a frontend
<lifeless> moin
<lifeless> jkakar: glad you like it ;) I did it to tease apart bits of bzrlib mainly. Still its very nice that its found external love as well.
<jkakar> lifeless: It's awesome, getting takes_args and takes_options for free is worth a lot. :)
<jkakar> lifeless: I'm using run_bzr to run the commands and that's working pretty well too.
<jkakar> lifeless: At some point I'd like to see if there's a way to make use of the bzrlib.help_topics stuff.  Right now I'm using my own code, but using Command.get_help_text to generate verbose output for commands.
<lifeless> jkakar: have you seen bzr-guess?
<jkakar> lifeless: Nope.
<lifeless> It was one of the things I had in mind with the hooks ;)
<lifeless> you might like to load that particular bzr plugin in commandant
<jkakar> lifeless: That is creepy. :)
<lifeless> (import bzrlib.plugin; bzrlib.plugin.set_plugin_path(); import bzrlib.plugins.guess)
<lifeless> jkakar: ?
<jkakar> lifeless: bzr-guess, that is. :)
<lifeless> why creepy?
<jkakar> lifeless: Hmm, I guess I'd also need to register a function for "get_missing_command" to look at plugins.
<jkakar> lifeless: Right now I implement hooks for "list_commands" and "get_commands" and leave the rest in their default unbound state.
<lifeless> no; get_missing_command is one of the three hooks we provide
<lifeless> bzr-guess hooks get_missing_command
<lifeless> but it only depends on list and get
<jkakar> Ah ha, I get it, nice.
 * saedelaere zzz
<mwhudson> jelmer: hi?
<LarstiQ> mwhudson: iirc jelmer is on a 4-day trip atm
<mwhudson> LarstiQ: ok
<LarstiQ> mwhudson: yeah, at oxegen.ie
<jml> spm, hello.
<spm> jml: howdy!
<jml> spm, I need to release a new version of Bazaar, and I need you to help me
<spm> jml: your wish is my command :-)
<jml> spm, can you please make a pqm managed branch for 1.17?
<spm> jml: sure. one sec or three
<jml> spm, thanks
<spm> jml: that should be all systems go for 1.17
<jml> spm, thank you!
 * jml trundles off to a leisurely breakfast where bzr may in fact be released
<spm> jml: bzr v1.17 "Coffee & Danish" ?
<jpds> spm: Sounds better than KFC!
<jml> spm, "So late it's brunch", more likely
<spm> jpds: for breakfast? KFC? blurg. :-)
<spm> jml: not... optimistic enough imho :-)
<jml> oh well, I'll have plenty of time to think about it on the way to crows nest :)
<garyvdm> "So late it's brunch" - Ha Ha +1
<lifeless> jml: are you still on leave?
<igc> morning
<mwhudson> igc: hello
<igc> hi mwhudson!
<mwhudson> igc: i still need to reply to that mail about bzr-svn
<mwhudson> but basically i think we need to talk to jelmer a bit
<garyvdm> Hi igc
<igc> mwhudson: cool. I have 800 emails to start the day so I'm not missing it. :-)
<igc> hi garyvdm
<igc> garyvdm: it looks like jam has been playing with Qt tree models. Is he aware of your stuff yet?
<garyvdm> I don't know.
<garyvdm> igc: What's jam doing?
<igc> garyvdm: not sure exactly - fixing bugs maybe?
<igc> garyvdm: https://code.edge.launchpad.net/bzr-explorer
<garyvdm> igc: lp:~jameinel/bzr-explorer/wt_model very much duplicates the work I've done. - I'll send jam an email.
<igc> garyvdm: thanks
#bzr 2010-07-12
<humanfly> hello all
<humanfly> did the best i could
<humanfly> and its the truth
<humanfly> is Marks staff accesssible throughout the night ?  if they needed to be contacted for any reason.  no problem on irc here.
<michaelh> Hi there.  I'm having trouble with making my first feature branch: bzr branch has been sitting there at 100 % CPU for about 15 minutes
<spm> michaelh: that sounds... uncool. is this a private/public branch on lp? or?
<michaelh> I'm new to this, but it's a LP branch that I have locally and I'm trying to create a feature branch off it
<michaelh> (it is GCC so it's a good size, but still)
<michaelh> The LP branch is https://code.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.4
<michaelh> I pulled it down locally using bzr branch lp:gcc-linaro/4.4
<michaelh> I then used bzr branch linaro-4.4 linaro-mlh
<michaelh> It did complete in the end.  Sat at 100 % CPU on a dual core machine and ~600 MB of RAM
<michaelh> All under stock Lucid on i386
<spm> Oh! istr that gcc has some *insane* # of commits that are evilness personified. IMBW, but possibly that's cause/effect right there.
<spm> I vaguely recall it being problematic on the lp importds....
<michaelh> bzr revno shows 95535.  du -sk .bzr is 490 MB.
<michaelh> It finished so I'm happy.  I thought I'd hit a bug :)
<spm> heh, the bug is 'gcc is wildly optimistic with the number of revno's it really needs' ;-)
<michaelh> spm: Sorry, unrelated topic: I'm writing my first ChangeLog entry and want to link to the LP bug ID.  Is there a standard format?
<michaelh> spm: (It's only us NZ and AUS people awake at the moment so I can't ask my usuals :)
<spm> michaelh: there is a shortform URL? as for "style" format, no idea.
<spm> eg. https://launchpad.net/bugs/<bugid>
<michaelh> spm: The GCC people put a line like 'PR fortran/43836' on any ChangeLog entries that fix a issue
<michaelh> Perhaps lp:123456 would be fine?
<spm> heh, actually I think the bzr folks are all in prague atm with the lp sprint
<spm> no idea :-)
<michaelh> Ta.
<lifeless> moin
<spm> lifeless: no. I think that's more accurately called 'night', although, I grant, it is oft considered 'morning' :-)
<lifeless> is 0435
<lifeless> is morningk
<spm> I'm aware of that :-)
<spm> good flights over?
<lifeless> yeah, bad ones over too
<spm> bleh
<michaelh> I'm a bit stuck on using feature branches in bzr against LP.  Where's a good place to ask?
<lifeless> I don't know, depends on what you're stuck i'd say
<lifeless> what are you stuck on?
<michaelh> I have a branch of a lp:gcc-linaro/4.4.  I took a local feature branch of that.  I made my changes and committed to the feature branch.  I now want to push this feature branch to LP so that I can ask Loic to merge it to trunk
<michaelh> I think 'bzr push "lp:~michaelh1/gcc-linaro/4.4-dev" is right, but it stacks on the 4.5 branch instead
<lifeless> thats fine
<lifeless> stacking is just storage optimisation
<michaelh> OK.  So he'll be able to merge it just fine, even though they're based on mildly different things?
<lifeless> no
<lifeless> *stacking does not mean based on*
<lifeless> he'll be able to merge it fine because you based it on 4.4
<michaelh> Ah.  So feature branch is based on local branch is based on LP:4.4
<michaelh> It's pushing a lot of data up - is it going to push all of the 490 MB branch for my small change??
<lifeless> no
<lifeless> lool: ^
<michaelh> Hmm.  12 MB at 60 kB/s so far.  I guess that is due to 'trunk' being based off 4.5... let's see how it turns out...
<michaelh> Does bzr push resume on network loss?
<lifeless> not curently
<michaelh> If it does push the full 493 MB, then it will take 2.3 hours at the current 60 kB/s.  I'm worried about it dropping out at 99 % :)
<michaelh> Can I stage the push, rsync it to somewhere with a faster connection, then finish the push from there?
<lifeless> michaelh: lool was going to have a cronjob setup so that it doesn't need to upload all that much data
<lifeless> if you want to do things incrementally use the -r parameter -
<lifeless> push -r 10000
<lifeless> push -r 20000
<lifeless> etc
<michaelh> Ta.
<lifeless> (hopefully obviously, that will be less efficient)
<michaelh> Currently at 157 MB.  Let's see how it goes...
<lifeless> another possibility is that you interrupted the early attempts after object creation before storage of the stacking info
<lifeless> so you could be pushing to an unstacked instance
<michaelh> How can I tell, and how can I fix it if it's true?
<lifeless> bzr reconfigure can change it
<lifeless> and bzr info will tell you
<lifeless> (bzr info url)
<jbowtie> I just announced bzr-tfs on the mailing list, now awaiting my first bug report.
<jbowtie> Which will probably be someone telling me I did the announcement wrong.
<fullermd> Looks like it has too few vowels to me...
<jbowtie> fullermd: I'll try to put extra vowels in the blog posts about how I wrote the plugin.
<fullermd> Will you be consonant in your pursuit of this solemn vowel?
<jbowtie> fullermd: No.
<swathanthran> what does --versioned do actually? is it like ignoring the files that has not yet been added?
<lifeless> I think so
<swathanthran> ok.
<mwhudson> i think bzr ls lists all files in the tree, even ignored and unversioned
<mwhudson> (without more options)
<lool> lifeless: I did setup a cron job, and I could push a verbatim copy of a branch in almost no time
<lool> http://paste.ubuntu.com/462396/ is the job
<lool> It didn't even break when I moved the branches around
<lifeless> ok cool
<lifeless> I wonder what went wrong for michaelh
<lool> I moved the branches recently, I wonder whether that could have had such a side effect
<lool> (changed owner from ~gcc-linaro-dev to ~linaro-toolchain-dev)
<Noldorin> hi. i'm trying to get bzr to connection to launchpad behind an http proxy. any ideas?
<Noldorin> followed http://stackoverflow.com/questions/1039057/how-do-i-use-bazaar-with-a-http-proxy so far, ut no luck it seems
<GaryvdM> Noldorin: have you tested if it works using the long url, e.g. bzr+ssh://bazaar.launchpad.net/~user/project/branch/ ?
<Noldorin> GaryvdM: no, by i will do now.
<GaryvdM> Noldorin: It uses https to convert lp:~user/project/branch/ to  bzr+ssh://bazaar.launchpad.net/~user/project/branch/
<Noldorin> GaryvdM: same error i'm afraid
<Noldorin> cts\IRC.NET> bzr co bzr+ssh://bazaar.launchpad.net/~noldorin/ircdotnet/devel bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10060, 'Operation timed out')
<GaryvdM> Noldorin: then you will need to get you administrator to open port 22 (ssh) for you
<Noldorin> GaryvdM: i've set the appropiate env vars for the http proxy. that's not too reliale ehi?
<GaryvdM> Noldorin: http proxies only work for http, not ssh
<GaryvdM> Noldorin: if you only need read access, then you can access your branch over http
<GaryvdM> Noldorin: http://bazaar.launchpad.net/~ircdotnet-dev/ircdotnet/devel/
<GaryvdM> Noldorin: That url will allow you readonly access.
<Noldorin> GaryvdM: ah, that should do the job. thank you
<Noldorin> GaryvdM: odd. i get:
<Noldorin> bzr: ERROR: Connection closed: Connection lost while sending request.
<GaryvdM> Noldorin: I'm sorry - I'm not sure then.
<Noldorin> no worries
<Kream>  what are the downsides to bazaar over, say, git, for a VCS for config files?
<Kream> using etckeeper, I mean
<Kream>  what are the downsides to bazaar over, say, git, for a VCS for config files?
<maxb> none? :-)
<Kream> hehe
<Kream> some guys were saying it's slowness is a big downside
<Kream> is that really a problem with etckeeper?
<Kream> system isn't really very heavily loaded.
<maxb> Bazaar is slower than Git, this is true. But that only starts to become an issue on huge trees. An /etc is pretty tiny
<Kream> true, true.
<Kream> what's an advantage bazaar has over git?
<Kream> generally, and as far as the /etc tree is concerned as well
<maxb> I think that's mostly a question of personal preference. Personally I find git to be excessively obscure, and to have the learning curve from hell
<maxb> Whereas bzr can do everything I could use git to do, and leave me happier about doing it :-)
<Kream> great :)
<svaksha> Permission denied (publickey). bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required). Any idea why this error occurs while getting a branch from LP? TIA.
<BusError> given a failed merge, how to I just cancel and reset to the HEAD ?
<maxb> BusError: bzr revert
<maxb> svaksha: Connection problems of some sort? Check with ssh your-lp-id@bazaar.launchpad.net
<svaksha> maxb: that is odd. i'm able to push and pull to my branch but cant pull another's branch
#bzr 2010-07-13
<mkanat> <dwm> we're going through The Great DVCS Debate (Summer 2010 Edition) now, I have noticed the bazaar/subversion integration is way ahead of other DVCS offerings
<mkanat> ^^^^^^^^^^ That's Yahoo.
<GungaDin> in revisionspec, does 'ancestor' relate to any common revision? or a common branch?
<wgrant> GungaDin: Common revision.
<GungaDin> thx
<mtaylor> gah
<mtaylor> $ bzr push --no-stacked lp:~ozone-core/ozone/devel
<mtaylor> Using default stacking branch /~ozone-core/ozone/spm-test at lp-70455952:///~ozone-core/ozone
<mtaylor> FAIL
<spm> argh
<mtaylor> um. o hai --no-stacked
<parthm> hello. is 2.2b4 feature freeze or is it 2.2rc1? ... i am asking in the context of any new merge proposals.
<vila> parthm: AIUI the feature freeze is already in effect
<parthm> vila: ok. thanks. so the trunk is for 2.3 now?
<vila> parthm: ha, the tricky one :) I'd say no, but you should ask the RM !
<jam> parthm: 2.2b4 isn't a strict feature freeze, but it *is* an api freeze
<jam> so that plugins can stabilize for the 2.2rc1 in a month
<jam> however, if we need to, we can split 2.2 off
<jam> I'll ask poolie what he thinks
<jam> we certainly want to avoid waiting on landing code
<jam> parthm: poolie finalizes, trunk is now 2.3
<jam> I'll submit a patche
<jam> patch
<parthm> jam: ok. thanks for clarifying. one more question. should patches be submitted against trunk and proposed against 2.2 on a case by case basis? or (if they don't break api) they should be proposed against 2.2 branch and merged into trunk for now?
<parthm> looks like i may need to rework the news entry for https://code.launchpad.net/~parthm/bzr/603461-ensure-no-var-named-message/+merge/29624 :P and propose it again.
<poolie> parthm, jam, yes, features that don't break apis and aren't too risky are welcome
<jam> parthm: if you think it is safe for 2.2, propose it there
<jam> 2.x is always merged up into trunk
<jam> so it saves having multiple proposals
<parthm> poolie, jam: ok. i will do that. thanks.
<JoshBrown> I'm working with Bazaar on Launchpad and was wondering how the branch, change, commit, merge process goes? Currently I am pulling from the branch, working on it, then pushing it back, is this 'best practice'?
<rubbs> JoshBrown: that is one way of doing it. There is no one right way to do it, but what I tend to do is pull one down and have it as my "mirror" of the LP branch. then I branch from my local one and hack away. When I want to get it into lp I push/merge to the local one and push up to LP.
<rubbs> the reason i do this is if I want two or more branches from the same lp branch
<rubbs> it also allows for the mirror to keep up to date in case your work is taking a while.
<rubbs> but others here might offer a different workflow
<JoshBrown> rubbs: Great, I finally did something right! :)
<JoshBrown> rubbs: For some reason I thought that maybe merges were supposed to be done on the Launchpad end.
<rubbs> JoshBrown: usually not. Merges are easier to do locally and then push to lp
<rubbs> JoshBrown: the mirror approach also keeps all your history in line with the LP branch rather than jumping back and forth between branches
<rubbs> JoshBrown: in other words, the mirror/LP history is always on the left (first one seen) and the working branches are on the right (seen after you expand this history at the merges)
<JoshBrown> rubbs: Yeah, I'm glad you can merge locally for ease of use / keeping in sync. It's just the fact that merge /proposals/ are done on Launchpad that threw me off.
<rubbs> JoshBrown: well merge proposals are slightly different.
<rubbs> JoshBrown: LP's MPs are for branches you don't have commit access too. So you can clone/branch from them, but you won't be able to push to it.
<rubbs> in this case you submit a proposal and have a link to your branch and someone with commit access can merge it in for you (provided they accept it)
<JoshBrown> rubbs: Ah, so if you have access to the branch you don't bother with a merge proposal? Got it.
<rubbs> JoshBrown: you don't have to IIRC, but it may be good practice if you wish to have a process in place
<rubbs> http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html
<JoshBrown> Thanks.
<rubbs> np
<Meths> If you run bzr uncommit on a tree are the bzr pull references it gives you good for the life of the tree or can doing the wrong thing break those?
<Meths> It think my real question is can you run bzr revert after doing uncommit so you have a completely clean revision and then apply those pull commands?
<poolie> they will last within that repostiroy
<poolie> Meths, why would you want to do that?
<Meths> For some reason one of our devs had content conflicts doing a bzr update on their version of trunk.  They ran uncommit forgetting it would affect the lp copy but whatever caused the conflicts (which didn't show up on lp or others trees) shows in their bzr st
<Meths> So could they just revert so that they have a clean bzr st then run the bzr pull commands to reapply the uncommits and see if that cleans it up?
<poolie> right
<poolie> if they didn't like the conflicts they probably should have just reverted, i think
<Meths> Possibly, it still isn't clear how you can get content conflicts just running bzr update every so often on a checkout from lp so not sure what they could have done to their copy.
<poolie> when you update, it merges the upstream changes against your uncommitted changes
<Meths> poolie: Exactly, normally our workflow means you wouldn't make any changes directly in the trunk checkout.  I'll ask them if they may have done.  In the meantime we'll do the bzr revert to get it clean and run the pulls.
<poolie> k
<poolie> just for curiousity, which project?
<Meths> openlp
<Meths> poolie: will those pull references be in a fresh checkout from lp?
<maxb> Meths: I believe they will _not_ because they won't be in the ancestry of the branch head. However, a subsequent attempt to refer to them might pull them from the lp branch at that time
<Meths> maxb: Thanks.  They seemed to be though and all is fixed now.  I assume as the uncommit happened on the lp copy as well, the references were also stored there.
<[reed]> does bzr support pulling a repo within a repo? as in, I have a top level "server" repo, but within that repo, I want the "extensions" directory to pull from another repo (similar to svn:externals)
<[reed]> as the extensions apply to more than just this one server
<[reed]> ooo
<[reed]> https://edge.launchpad.net/bzr-externals
<bbutz> it is possible to cherry pick multiple files when merging? I have an intermediate branch, and want to merge files that are across multiple revisions of another branch into it
#bzr 2010-07-14
<michaelh> Hi there.  I recently did a commit/push but forgot to tag the commit as fixing a Launchpad hosted bug.  What's the best way of doing a --fixes after the commit?
<vila> parthm: ping
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<parthm> vila: hi
<vila> parthm: hey !
<vila> parthm: do you remember bug #376388
<ubot5> Launchpad bug 376388 in bzr (Ubuntu) "~/.bazaar created owned by root (when run under sudo) (affected: 4, heat: 20)" [Low,Confirmed] https://launchpad.net/bugs/376388
<parthm> vila: yes.
<vila> I think I introduced a regression with my fix for bug #525571
<ubot5> Launchpad bug 525571 in Bazaar Subversion Plugin "No locking when updating files in ~/.bazaar (affected: 6, heat: 52)" [High,In progress] https://launchpad.net/bugs/525571
<vila> i.e. when merging the fix from 2.0 -> 2.1 -> 2.2 the merge lost the copy_ownership call
<vila> I think the fix should b as simple as http://paste.ubuntu.com/463416/
<vila> So I was wondering if you could look into reproducing it  and confirm the regression
<parthm> vila: sure. i can look at that later today. i can propose a merge in case there is a regression.
<vila> Second, I don't clearly remember the constraints around calling copy_ownership, I think the file should exist but otherwise how did you minimize the races ?
<vila> parthm: thanks a lot
<vila> parthm: My main concern here is that the test suite didn't catch the regression
<vila> I know we need to run as root to be able to setup a test context and I think we may want to file a bug asking for a specialized test suite that requires running as root (handwaving a bit)
<parthm> vila: thats true. test suite should have caught it.
 * parthm looks at old merge proposal
<vila> parthm: I think the issue is that normal users can't run chwon to give ownership to someone else, so you can't test such things
<vila> chown
<vila> hence we need to run such tests as root, but I know some other tests should *not* be run as root or they will fail :)
<parthm> vila: yes. the test cases basically monkey patch and check that chown is being called.
<vila> parthm: anyway, thanks for looking into it !
<parthm> vila: np.
<vila> ha, yeah, I remember I wasn't so happy with that :-)
<parthm> vila: yup. we had a long discussion :)
<vila> parthm: in retrospect, tracking the chown calls looks like a good way to run the tests without being root, maybe there is a way to enrich the injected version so emulate the behavior we want
<vila> *to( emulate
<vila> *to* emulate
<parthm> vila: yes. considering that the regression was not caught the tests could probably use some improvement. i will see if i can think of something.
<poolie> hi parthm, vila
<parthm> poolie: hi
<vila> parthm: 2.2 should be the target
<parthm> vila: will do.
<vila> poolie: hey :-P
<parthm> poolie: ping
<poolie> hi parthm
<parthm> poolie: regarding bug #605098 for bzr-grep ... did you happen to check your bzr-grep version?
<ubot5> Launchpad bug 605098 in bzr-grep "ignore binary files (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605098
<poolie> i did, i was just out of date
<poolie> i closed it
<poolie> just now
<parthm> poolie: ok. cool.
<poolie> on really big trees it's much faster than grepping the working tree
<poolie> that's pretty cool
<parthm> poolie: :) i recently added -p/--diff to grep changesets. if you are using trunk you could try that too.
<poolie> i will
<asac> if i push to launchpad how can i prevent this to happen:
<asac> Created new stacked branch referring to /~mozillateam/firefox/firefox-4.0.head.
<asac> ?
<mwhudson> asac: bzr init the location, bzr reconfigure --unstacked the location, then push
<mwhudson> is one way
<asac> lets try
<asac> just to repeat how much i disagree with the not-being-able-to-easily-prevent branch format attitude
<asac> s/format/format upgrades/
<asac> hell
<asac> i have a good branch with old format still
<asac> and whenever i push it it stacks and converts on the fly
<asac> even though locally its not even stackable
<asac> bzr reconfigure --unstacked
<asac> bzr: ERROR: The branch 'file:///home/asac/Development/ubuntu/mozillateam/firefox-3.7.head/'(Branch format 6) is not a stackable format. You will need to upgrade the branch to permit branch stacking.
<asac> bzr push lp:~mozillateam/firefox/firefox-3.7.head/Doing on-the-fly conversion from RepositoryFormatKnitPack1() to RemoteRepositoryFormat(_network_name='Bazaar RepositoryFormatKnitPack5 (bzr 1.6)\n').
<asac> This may take some time. Upgrade the repositories to the same format for better performance.
<asac> bzr: interrupted                                                           bzr info
<asac> Repository tree (format: pack-0.92)
<fullermd> Well, FWIW, that conversion is essentially free...
<asac> it is not
<asac> its not pack-0.92 anymore
<asac> and hardy users cant branch it
<asac> without enabling ppas etc
<fullermd> It is in every way that counts, data-wise.
<asac> these kind of transitions of default have to wait until hardy is EOL
<asac> you are too focussed on bzr and the data. i am focussed on the user and the reputation bzr gets by this kind of experience
<fullermd> pack-0.92, 1.6, and 1.9 are all practically the same in terms of the data for the revisions/texts/etc.
<fullermd> Oh, sure, that's a valid reason.  But the cost of the conversion is almost immeasurable among that group.
<asac> then you shouldnt do this kind of default switch until the new branch format is out by at least 3 reasons
<fullermd> _I_'m not making any sort of switch.  I don't have anything to do with LP.
<asac> its not launchpad
<asac> at least i think
<fullermd> Yes it is, it's LP forcing a stackable format.
<asac> afaik bzr switch to the new default
<fullermd> Well, not _forcing_, but making it fair bits of work to avoid.
<fullermd> 1.6 was NEVER a default format.  The default format went straight from pack-0.92 to 2a.
<asac> i cant avoid it it seems
<asac> how can i do that?
<asac> i want to avoid it
<fullermd> I don't know offhand.  I'm pretty sure it can be done, but it may require manual fiddling.
<asac> manual fiddling on launchpad side?
<asac> or on my side?
<asac> fullermd: thanks for clarifying though :/
<fullermd> On your side.  I think reconfigure SHOULD be able to do it.
<asac> no its not
<asac> my local branch is not stacked at all
<fullermd> Not on your local branch.  On the lp branch.
<asac> bzr reconfigure --unstacked
<asac> 17:18 < asac> bzr: ERROR: The branch 'file:///home/asac/Development/ubuntu/mozillateam/firefox-3.7.head/'(Branch format 6) is not a stackable format. You will need to  upgrade the branch to permit branch stacking.
<fullermd> bzr reconfigure --unstacked lp:whatever
<asac> the online branch doesnt exist
<asac> i want to push to a new location
<asac> and it lways gets stacked
<asac> let me see
<fullermd> Yeah.  As mwhudson said, use 'init' to create an empty branch at that new location first, reconfigure, then push.
<asac> cool
<fullermd> Actually, maybe if you init --pack-0.92, it won't bother trying to setup a stack in the first place since that format isn't stackable.
<mwhudson> asac: the messages from bzr can be a bit deceptive, it might not actually be stacked even if it looks like its saying it is
<asac> doesnt work:
<asac> bzr init --pack-0.92 lp:~mozillateam/firefox/firefox-3.7.head
<asac> Created a standalone branch (format: unnamed)
<asac> asac@tinya:/tmp/new$ bzr reconfigure --unstacked lp:~mozillateam/firefox/firefox-3.7.head
<asac> bzr: ERROR: The branch 'bzr+ssh://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.7.head/'(Remote: Branch format 6) is not a stackable format. You will need to upgrade the branch to permit branch stacking.
<fullermd> IIRC branch6 is what you expect from pack-0.92, so that sounds right.
<asac> mwhudson: well. all i know is that when i push to the new place it upgrades on the fly because it thinks it is stacked
<asac> fullermd: but when i push my pack 0.92 branch now it gets a) stacked and by converted on-the-fly
<fullermd> Not on lp:~mozillateam/firefox/firefox-3.7.head; pack-0.92 isn't stackable.
<fullermd> % bzr info nosmart+lp:~mozillateam/firefox/firefox-3.7.head
<fullermd> Standalone branch (format: pack-0.92)
<asac> hmm. that remove init seemed to have helped indeed
<asac> let me see what comes back when i do a fresh branch (once the push has finished)
<fullermd> LP does a lot of magic, so you need a pretty big hammer like that to keep it from enstacking things.
<asac> i will go and fight this ;) (if i have engery left ;))
<asac> but i guess its too late now ... the harm is most likely done for many branches already
<asac> i am happy if i can safe just th e mozillateam branches for now ;)
<fullermd> Well, I DO get all twitchy at the thought of people running bzr's that can't read 1.6  ;p
<asac> yes. as i said. it doesnt give a professional and mature impression
<asac> i think bzr developers could have helped by not declaring 2.0a the default until its much older
<asac> that might have prevented launchpad to jump on it ;)
<asac> but thats just me
<asac> thanks a bunch fullermd and mwhudson
<fullermd> Well, you're not having LP jump to 2a here  ;)
<thrope> how can I delete some changes I've shelved?
<rubbs> thrope: try bzr help shelve
<thrope> rubbs: i tried ... it didnt say anything
<rubbs> I believe there is a --destroy option
<thrope> in the end I unshelved them and reverted
<thrope> thats only when you are doing the shelving
<thrope> nothing about deleting existing shalves
<thrope> but it would have been a pain if there were other changes that I didnt want them to mix with
<rubbs> ah, sorry
<rubbs> right.
<lamont> bzr: ERROR: gnomekeyring.IOError:
<lamont> wth does that mean?
<lamont> besides "no, you don't get to do a pull on that remote machine", of course
<rubbs> lamont: I'm not an expert but that looks like gnomekeyring isn't able to unlock the ssh key that bzr is looking for.
<lamont> not terribly surprising, since it's a remote session.  then again, one would hope for a prompt or some such before it threw its hands in the air
<rubbs> lamont: well bzr tries not to be interactive so it can be used as a library
<rubbs> the key needs to be unlocked before bzr can use it
<lamont> rubbs: and lacking a gui to talk to gnome, and a lacking a clue how to do it outside of gnome, I'm left with 'oh well'
<rubbs> lamont: I think you can use ssh-agent
<rubbs> http://mah.everybody.org/docs/ssh
<rubbs> something like that
<lamont> rubbs: I could, and I won't
<lamont> I see no reason to give root on the remote machine access to my ssh key
<rubbs> I was unaware that ssh-agent did that. I'm not an ssh expert, or really a bzr one for that matter. just trying to point out what I think was the problem
<rubbs> i was under the impression that ssh-agent only held keys in local memory, and only with agent-forwarding turned on did it forward those keys to the remote
<rubbs> but I could have misunderstood that
<lamont> rubbs: if you pass your agent to a remote machine, root on that machine can access the agent.  this might not be quite what you want.
<lamont> ah, yeah - agent forwarding hands the keys over
<lamont> that's usually what I've seen people be referring to when they start talking about ssh-agent... my bad for jumping to the conclusion
<rubbs> np.
<rubbs> I think just ssh-agent will unlock the key in local memory. bzr will not forward the key IIRC
<rubbs> but I can't tell you that for sure
<lamont> yeah - if it did, we'd have beaten them already, I suspect.
<rubbs> right. that's what I was thinking.
<rubbs> but I can't definitively tell you yes or no on that question
<rubbs> I understand people's aversion to security issues.
<rubbs> aversion may not have been the right word, but I think you know what I mean
<mgz> bug 605574 looks like a python 2.7 regression in xmlrpclib at first blush
<ubot5> Launchpad bug 605574 in Bazaar "impossible to branch from web (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/605574
<Stavros> hello
<Stavros> can i pull/push to hg branches?
#bzr 2010-07-15
<maxb> yes
<Carl0> We just installed Bzr on OS 10.6 and get an error whenever we try to init a repository: bzr: ERROR: '/Users/carl' is not a working copy
<Carl0> I cannot find other users talking about this error when I searched Google. Can anybody here please help us?
<maxb> Please give the *precise* command you ran, and run it again with the -Derror flag to see if it gives more information
<carl_> I accidentally disconnected. Can anybody help us figure out the cause of the following error when we init a repository: bzr: ERROR: '/Users/username' is not a working copy
<maxb> Please give the *precise* command you ran, and run it again with the -Derror flag to see if it gives more information
<carl_> We just installed bzr 2.2b3 on OS 10.6
<Stavros> maxb: how?
<carl_> $ bzr init
<carl_> .. UnsupportedFormatError: '/Users/carl' is not a working copy
<maxb> Is there already a /Users/carl/.bzr/ directory? or .git ? or .svn ? or .hg ?
<carl_> http://pastebin.org/397081
<maxb> Stavros: have you installed the bzr-hg plugin?
<carl_> maxb, there is only a .bzr.log
<maxb> carl_: OK, so bzr-svn is somehow breaking things
<carl_> Can we remove bzr-svn?
<Stavros> maxb: yes, but it's not working :/
<Stavros> i do bzr branch hg+http://url and it says that the scheme is not supported
<fullermd> Last I heard bzr-hg didn't support remote protocols.
<maxb> carl_: I would just delete it or move it aside. But then, I usually run bzr-svn directly from a branch. I am not familiar with OS X or what bzr installers may be there
<Stavros> oh
<Stavros> hmm, too bad...
<fullermd> (or really much of anything beyond PoC)
<maxb> fullermd: there are live bzr-hg imports on launchpad...
<maxb> Stavros: lose the hg+
<fullermd> Well, it's been years since I acquired the "last I heard", to be sure.  But it's always been a long time since I heard anybody actively working on bzr-hg too.
<fullermd> s/always/also/
<maxb> It's a lot less polished than bzr-svn, that's for certain, but it's often good enough
<fullermd> The last I heard was that it was capable of branch'ing and pull'ing and such from a local hg branch, but not over remote protocol, or able to push back.
<carl_> maxb, thanks for suggesting the svn folder removal.
<carl_> Now when I try to init a repository I get an error telling me 'No repository present'
<carl_> here is the traceback: http://pastebin.org/397096
<Meths> What does bzr do on a commit after printing "Committed revision xyz."?  Mine seems to take quite a while to return to the command prompt compared to what it used to.  Noticed with 2.1.x on WinXP.
<janisozaur> in svn I can "svn log BASE:HEAD", this shows all the commit logs that happened since last "svn up" - local revno is compared against server's revno. How can I achieve the same in bzr?
<janisozaur> I've tried "bzr log -r -1:lp:cybercarto" (as cybercarto is the project I manage) but bzr tells me that it had encountered an internal bug. Should I file it?
<janisozaur> *internal error
<parthm> janisozaur: internal error is almost always a bug. it would be good to file it.
<swathanthran> bzr commit won't look at $VISUAL? or which variable i should set to make it point to an editor i want?
<parthm> swathanthran: EDITOR or BZR_EDITOR. `bzr help env-variables`
<janisozaur> parthm: do I need to attach only the crash log or should I also include snapshot of local and server state of branches?
<parthm> janisozaur: crash log should be enough.
<swathanthran> parthm: thanks
<parthm> janisozaur: the way i do what you mention is that i keep a mirror of the trunk around
<parthm> janisozaur: then from my feature branch foo, i can do "bzr diff --old ../trunk"
<parthm> janisozaur: typically i keep all my branches in a shared repo locally so they share history.
<janisozaur> parthm: so... there is no way of fetching logs only for missing commits from server?
<parthm> janisozaur: you don't really need to connect to the server as all the logs are available locally.
<parthm> janisozaur: you could do a `bzr log | less` and that has the entire log.
<parthm> janisozaur: if you do `bzr revno lp:foo` you will get the revno of the trunk. you could then do `bzr log $revno..last:1`
<janisozaur> parthm: yes, they are stored locally, but what I'm used to, after using some svn, is checking the logs before updating.
<parthm> janisozaur: i think the revno + log which i mentioned above should do what you want.
<parthm> janisozaur: unless the trunk has moved ahead. i which case i don't know of a good way to accomplish what you mention.
<jam> janisozaur: bzr log -r -1..-1:. lp:cybercarto will probably work
<jam> sorry
<jam> you want to make sure one is the local, and one is the remote
<jam> but that you call "bzr log REMOTE -r local..remote"
<jam> I haven't found a syntax for the local branch that works as the first part of a range yet, checking
<jam> janisozaur: vila points out that "bzr missing --theirs" also works for this
<jam> janisozaur: bzr log lp:bzr -r -1::this..-1
<jam> its sort of magical syntax
<jam> but it does do what you want
<jam> missing can certainly be a lot easier, though
<ronny_> hi
<ronny_> can someone please make at least the recent bzr pip installable?
<ronny_> hum, it actually half-works
<ngirard> Hi all. I need to know about this while not beeing able to access bzr on the command line right now:
<ngirard> when calling
<ngirard> bzr export DEST [BRANCH]
<ngirard> will bzr create DEST if it doesn't exist ?
<ngirard> anyone ?
<bialix> hey
<mwhudson> ngirard: yes
<ngirard> mwhudson, thanks ! I'm currently writing a shell script that i cannot test now ;-)
<mwhudson> ngirard: that's not a good place to be!
<ngirard> well mwhudson, your answer was the sole thing I needed there !
<ngirard> I'm only using bzr do  export some stuff that'll never be modified. How can I get rid of the "you have not informed bzr" message ?
<beuno> ngirard, ser a name?
<ngirard> aha. I can bzr launchpad-login --no-check. That's fine. Thanks beuno
<d1b> morning
<d1b> can i use bzr to pull from an svn repo and then push to a git repo?
<d1b>  / does bzr understand / work with svn branches?
<poolie> d1b, yes, and yes
<d1b> poolie: how do i do this? :P
<d1b> like i mean easy
<poolie> bzr branch svn+ssh://example.com/foo
<d1b> erh the svn is https :// :P
<poolie> bzr push -d foo git+ssh://example.com/git
<d1b> and what if i want to do a local git export
<poolie> well, that then
<spiv> d1b: I bet your host isn't example.com either :)
<d1b> spiv: :P
<d1b> actually this isn't going to work either lol because i would need to merge git and git-svn
<d1b> mmm
<d1b> still history in bzr or git would be better than svn
<d1b> erh what if the remote https location has an invalid cert?
<spiv> try https+urllib: instead of https:
<d1b> nope fails :/
<d1b> doesn't like my username / pass
<d1b> or something :/ -both are valid
<lifeless> have you logged in with svn ?
<d1b> git-svn works as does svn
<d1b> i assume you guys are using pycurl
<lifeless> no
<d1b> if so, please add the support to add an external cert
<d1b> ok
<lifeless> you're talking to svn
<d1b> same thing holds :)
<lifeless> we use libsvn
<d1b> i am talkingto svn :)
<d1b> it doesn't like the user / pass and both are correct
<d1b> it starts to do the checkout then stops
<d1b> and reasks
<d1b> "bzr error not a branch"
<lifeless> d1b: firstly don't pass the user/pass in the url, for svn if you have logged in already its implicit
<d1b> lifeless: im not
<lifeless> secondly, perhaps you can run with -Derror and show what happens
<d1b> why would i put the username in the url :) ? ok will do
<d1b> http://paste.pocoo.org/show/237935/
<d1b> perhaps i need to say master?
<d1b> in which case this would violate my "easily get my svn branches"
<d1b> perhaps it is getting the username wrong ?
<d1b> (appending @example.com)
<d1b> ok so no ideas?
<svaksha> while trying to pull this branch, https://code.launchpad.net/~mailman-coders/mailman/2.1, i get this error: bzr: ERROR: Invalid url supplied to transport: "lp:mailman-2.1": No such project: mailman-2.1
<Ursinha> svaksha, wouldn't that be lp:mailman/2.1?
<svaksha> that is what i entered
<Ursinha> I mean, what command you ran?
<svaksha>  sudo bzr branch lp:mailman/2.1
<svaksha> which gave the above error
<svaksha> so i tried it with -
<svaksha> s/above/
<svaksha> bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<poolie> svaksha, maybe you need a newer bzr?
<d1b> upgrade your bzr!
<lifeless> d1b: if you have a branch called master, under foobar, then yes you need to specify it
<svaksha> poolie: i re-installed bzr a couple of days ago. *sigh*
<lifeless> d1b: the 'svn-import' command will however pull all the branches
<poolie> svaksha, what platform are you on?
<svaksha> poolie: hardy
<d1b> lifeless: how how does that work?
 * svaksha had some problems with bzr so i purged the old installation and reinstalled
<d1b> do i just add that to bzr branch?
<poolie> svaksha, use https://edge.launchpad.net/~bzr/+archive/ppa
<d1b> wow my brain is on stupid today
<svaksha> poolie: thanks. will get back to you on it
<d1b> ah right got it
<d1b> however, i put /trunk before - which does exist and that didn't work either
<d1b> bah turns out bzr-svn doesn't even do what i want. oh well. - according to the site it doesn't truncate branch svn branch copies
 * maxb wonders what "truncate svn branch copies" means
<d1b> maxb: i assume it means doesn't maintain the history of a file when copied toa branch
<d1b> which is exactly what git is getting confused with - i stupidily didn't make this change from git and now it is lots of fun!
<d1b> it works fine but i wanted to maintain / apply previous file history to the 'new' (copied) branch
<svaksha> poolie: on the development server i'm only allowed to install packed versions of software, so a ppa is not workable. is there another way to pull this Mailman revision?
<poolie> svaksha, you realise the things in there are packaged?
<svaksha> poolie: yes, i do.
<poolie> svaksha, branch it onto a different machine using an uptodate client i guess
 * maxb looks at .bzr.log and recoils at the amount of spurious errors bzr-svn is logging
<svaksha> poolie: i was suggested another method -- edited sources.list to add the hardy ppa, sudo upgrade +update allowed me to pull the branch
<poolie> uh yeah
<poolie> that's what i was suggesting you do
<svaksha> :) thanks
<sven_sandberg> hi! i have encountered what looks like wrong conflict markers when merging one tree to another. it looks similar to this: http://pastebin.com/gzxtEt2X
<sven_sandberg> note that after the merge, line 3 has moved from outside the conflict to TREE. so if you think you'd want to take the OTHER part of the conflict, you'd miss line 3.
<sven_sandberg> i can't reproduce it in this simple form, only in my local mysql tree. so it's probably history-dependent
<maxb> That sounds familiar
<sven_sandberg> i know these things can be counter-intuitive sometimes. is this likely to be a bug?
<maxb> Yes, that's definitely happened to me too. Unfortunately I've done no better than you at reproducing it
<sven_sandberg> is there a good place where i can upload the source tree so that others can reproduce it?
<sven_sandberg> maxb, or maybe you can already reproduce it in a public tree?
<maxb> my broken tree is private code
<maxb> Maybe you could just put the branches on launchpad and file a bug including instructions of what to merge where to reproduce?
<sven_sandberg> sure. how should i put it on launchpad? is there a 'scratch area' for things like this?
<maxb> sven_sandberg: You can push things to ~your-name/+junk/whatever
<sven_sandberg> maxb, thanks!
<maxb> Though if it's a branch of an established project, you're better off pushing it at lp:~you/project/tmp-something, so that the auto-stacking takes effect and you don't need to spend network traffic pushing the common history
<sven_sandberg> thank you. i'll see what works easiest for me
#bzr 2010-07-16
<GungaDin> I can't check out a branch because bzr raises an exception saying 'readline' is not defined...
<GungaDin> any ideas?
<GungaDin> (bzr version is 2.1.1)
<poolie> spiv, is https://bugs.edge.launchpad.net/bzr/+bug/496813 now fixed? just wondering about the strange state
<ubot5> Launchpad bug 496813 in Bazaar "until_no_eintr used on unrestartable IO, and cannot address all cases of EINTR. (affected: 1, heat: 3)" [High,In progress]
 * spiv looks
<spiv> Closed, thanks.
<rom1> Hi all,
<rom1> I have some questions about how to hide the "failed to load extensions" warning
<poolie> ok
<poolie> spiv, not closed for 2.0?
<rom1> I have tried the ignore_missing_extensions in bazaar.conf
<rom1> but the warniongs still appear... Do i have to do something else ? (Bazaar (bzr) 2.1.1 installed with packaging lucid)
<ronny_> hi
<ronny_> whats a good way to make bzr ignore missing whoami settings in unittests
<mwhudson> ronny_: 'use bzrlib's TestCase' is probably one answer
<ronny_> mwhudson: im using py.test, and anyvc is wrapping up much of bzr
<poolie> rom1, i'm a bit suprised, but you should file a bug
<poolie> ronny_, run the tests with $HOME set to something holding a .bazaar/bazaar.conf that's not your real one
<rom1> ok, thx poolie
<poolie> or BZR_HOME
<ronny_> any way to supply it in python code?
<mwhudson> ronny_: http://pastebin.ubuntu.com/464435/
<ronny_> hum, seems to depend on testtools
<mwhudson> yes
<ronny_> seems i'll need some nasty special cases for bzr
<spiv> poolie: weird that I failed to see that!  Closed for 2.0 as well now.
<rom1> Hou, found what my probleme was :
<rom1> In fact, i do a branch or any operation on a distant server in bzr+ssh
<poolie> ronny_, are you running bzr inprocess?
<rom1> the warning comes from the distant server and not the local bzr...
<poolie> ah ok
<rom1> which means that i have to put the ignore_missing_extensions my distant config
<poolie> fraid so
<poolie> you can't install the extensions there?
<poolie> which platform is it?
<rom1> debian etch
<rom1> we have backported the bzr 2.1. Have to check the compilation
<poolie> it would be cool if you can publish that backport
<poolie> if it's not already in the debian.org backprots
<rom1> gonna check with my packager
<ronny_> poolie: yup
<ronny_> poolie: its for the anyvc bzr backend
<ronny_> hum
<ronny_> if bzr wont listen i will just leave it out of ci
<lifeless> won't listen ?
<ronny_> lifeless: whops, that was a figure of spech
<ronny_> lifeless: whats a good way to set up bzr for one global whoami entry that isnt affected by the user home
<ronny_> (from the api)
<lifeless> ronny_: well, change the user home, then use the global config object as 'bzr whoami' does.
<ronny_> lifeless: can i do that from code so i can make it part of the test setup
<spiv> ronny_: yes, set HOME or BZR_HOME in os.environ
<spiv> ronny_: take a look at what bzrlib.tests.TestCase does
<ronny_> hum, looks nasty
<parthm> hello. how can i make the user-reference html? i tried `make docs` but that doesnt seem to build the user-reference.
<parthm> i am using 2.2 branch
<spiv> make docs-sphinx, IIRC
<parthm> spiv: thanks. make doc/en/user-reference/index.txt seems to create the rsts. then i did make html from within doc/en. yes, the sphinx style docs are generated.
<parthm> spiv: looks like basic html docs can't be generated for user-reference.
<dipnlik> hi, anyone here using bzr rebase? tried it with --dry-run but it did make the modifications, is this a known bug?
<JoshBrown> I've accidentally set my whois to 'Josh Brown joshbrown@site.com <joshbrown@site.com>' and done several commits. I've now fixed the whois, but is it possible to change the commits?
<maxb> Not easily, and not at all if they have been shared with other people
<Meths> Could combine uncommit with shelve ?
<maxb> That falls under than heading of "Not easily" :-)
<Meths> Yes :)
<Meths> Couldn't he just use the pull reference given by uncommit if there is an interspersed commit from another person?
<Meths> If he's feeling particularly masochistic
<maxb> That would pull the old versions of preceding commits
<maxb> uncommitting someone elses revisions is a big no-no anyway
<basic`> is there any way to debug some strange errors i'm getting with bzr?  it looks like bzr is giving a permission denied for the public key of my user, but i'm able to ssh to the remote machine with my key
<JoshBrown> Ah, well I'll take that as a 'no' - I suppose it isn't *such* a big deal anyway.
<basic`> any ideas?
<basic`> according to the auth.log on the master/host box, the session authenticates fine
<basic`> and then it disconnects
<basic`> it looks like bzr is disconnecting the thing, but it's outputing a permission denied (publickey,gssapi-with-mic). error
<basic`> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<james_w> poolie: are you around?
<poolie> hi, i am actually
<james_w> hi
<james_w> poolie: https://code.edge.launchpad.net/~rom1-chal/bzr-builder/reporting_conflict_from_merge/+merge/30127 <- could you look at analyse_conflicts there and tell me if you know of a better way to achieve that?
<poolie> ah interesting, i think he was online before
<poolie> well i probably wouldn't put it inline in the exception of course...
<james_w> I'm thinking of showing the "bzr log" for the revisions, rather than just printing the developers, but I imagine that parsing the annotate text isn't ideal either way.
<poolie> no, it's not
<james_w> indeed
<james_w> and doing it lazily would be better
<poolie> if you peek inside the implementation of annotate i think there's an easy structured form
<poolie> james_w, so i'd probably work from _expand_annotations, at least
<poolie> that should be easily parseable
<james_w> yeah
<poolie> i think ideally this would be separated into something people could use in other bzr applications
<poolie> like in tarmac or pqm
<james_w> I don't like having to construct a Revision like that
<poolie> mm, that's weird
<poolie> gannotate works on the uncommitted changes without needing that
<poolie> hm, apparently in the same way
<poolie> that's a bit gross but perhaps it needs to be fixed in the core
<poolie> i guess that's where he got the idea from
<poolie> hi svaksha
<james_w> parsing the lines seems kind of necessary, but we can't rely on MERGE-SOURCE and TREE, but without them we might get confused
<poolie> maybe he/she copied them from gannotate
<james_w> yeah
<james_w> I just mean in general, we can query a tree for conflicted files, but not for conflicted chunks
<poolie> right
<poolie> it would be better to do the merge and annotation together
<poolie> if you did a weave merge you'd get that built in
<james_w> hmm
<james_w> that could work
<poolie> and i think also in structured form
<james_w> this is certainly better than the "OH NO CONFLICTS!!" we have now, so I'd be inclined to merge some version of this and go for incremental improvement.
<poolie> i'd like to see this in core
<poolie> maybe not run by default...
<poolie> it's kind of hard to tell where to put things that don't justify a whole plugin but that could be generally useful
<poolie> it seems like the ideal here would be something like
<poolie> 'bzr conflicts --why' to give you this summary
<poolie> listing the revisions and authors involved in each file
<james_w> yes
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/606465
<ubot5> Launchpad bug 606465 in Bazaar "_expand_annotations should make it easier to annotate working tree with uncommitted changes (affected: 1, heat: 6)" [Wishlist,Confirmed]
<poolie> btw i set up http://pad.lv/606465 for a shorter form
<james_w> do you think taking the intersection of (revisions touching lines inside conflict markers) and (revisions after the LCA of the branches) would be the correct thing to do?
<james_w> (is LCA the right choice there?)
<james_w> oh, nice
<james_w> and thanks for the bug
<james_w> shall I file one for --why?
<poolie> yes, and please point to this
<poolie> right, the strange thing about annotating conflicts is that they're not guaranteed to be the ones that actually "caused" the conflicts
<poolie> i guess they will give you a decent clue
<poolie> enough it's worth trying it out
<dipnlik> can anyone help me use difffork as my bzr diff tool?
<sven_oostenbrink> Asked this before, but I have to ask again.. What is the best way to make merges of common libraries in between distinct projects?
<sven_oostenbrink> I have right now 3 projects, one is a framework, the other two are implementations of that framework
<sven_oostenbrink> Now, in the two implementation projects, we occasionally find and fix bugs
<sven_oostenbrink> I want to somehow merge those fixes back in to the framework project, and from there, send it as an update to the other implenmentation project
<sven_oostenbrink> implementation as in, it implements the framework...
<sven_oostenbrink> Now, this merging is so far good for a nice migraine everytime I try it
<sven_oostenbrink> I need to somehow be able to filter specific directories, but AFAIK, bzr can't do that
<sven_oostenbrink> so I go to the framework project, do a merge from that implementation project, then one by one filter out that which is project specific, and then commit the merge.. but everytime it gets more complex, and more error prone..
<sven_oostenbrink> So I'll have to ask again, isnt there a bettere way to do this? some sort of directory filter maybe? like, merge, but automatically filter (as in, ignore those directories) all that is ".........."
<StoneCypher> I would like to merge some of my subversion repositories while I transition to Bazaar, but I'm unwilling to let go of their histories.  It's fine if I lose their old version numbering.  Is this supportable?
<StoneCypher> that is, I have repos in the form lib1, lib2, lib3, and i'd like to transition to lib/lang/lib1, lib/lang/lib2, lib/lang2/lib3, etc
<maxb> sven_oostenbrink: I do not understand your terminology. In my mind, a framework is something other projects depend on, not something that other projects implement.
<sven_oostenbrink> maxb: Fair enough, the two other projects depend upon that framework..
<maxb> StoneCypher: Are you sure you want to combine all those libraries in a single bazaar tree, which is always branched/tagged/checked-out as a single entity?
<StoneCypher> max: yes
<sven_oostenbrink> Thing is, we fix bugs in that framework also directly in those two projects.. Makes it a hell of a lot easier to do so.. but then, how can I get those fixes back in the framwork branch?
<maxb> StoneCypher: then, I think the answer is to convert them all to Bazaar separately, and then look at the 'bzr join' command to assemble the combined tree
<StoneCypher> oh, ok
<maxb> sven_oostenbrink: sounds to me that the framework should be a subtree within the other projects, and that fixes should be made in the framework branch whereever possible
<StoneCypher> does bzr join weld B into A, or does it create C from A and B?
<maxb> when not possible, I suppose I'd cherrypick the fixes from the other projects back into the framework branch
<maxb> StoneCypher: the first
<sven_oostenbrink> maxb: yeah, but since that makes it at best very very hard to make those changes.. Every time you want to make changes to the framework, you'd have to open up another project, make sure you would not accidentally change stuff in the framework that is in the project tree, etc...
<sven_oostenbrink> In that case, its easier actually to just do what I do now.. Make the changes in the project, then merge all project changes to the framework branch, before committing that merge, remove all project changes, and then commit
<sven_oostenbrink> But even that is tedious..  There has to be a better way..
<StoneCypher> maxb: so, i create a bazaar repo under the desired final name, then one per library to be transitioned, then -join them to the final, one at a time?
<sven_oostenbrink> Would it be possible for BZR to include a filter like this?
#bzr 2010-07-17
<nataren> Hello. I am running bzr 1.16.1 on Windows, and I have a rules files saying 'eol = native', it used to work fine but all of a sudden stopped working, and now my checkout come down as LF only.
<nataren> Do you have any advice on how I can make it work fine.
<nataren> I am experiencing nasty merge conflicts due to the newlines problem.
<nataren> I created the repo and the branch as --2a
<rioch> I've just committed some code and I have a release ready. I want to tag this. Is it just a case of doing: bzr tag <tag-name> or do I need to specify the revision? I assume I also need to push after the tag?
<fullermd> tag will tag the head of the branch if you don't specify a revision, so if that's the rev you want to tag...
<rioch> it is :)
<rioch> is it also possible to get a list of all the tags?
<fullermd> tags
<rioch> it's strange that bzr status doesn't show that I've created a tag
<fullermd> Why would it?
<rioch> because my local repo. isn't the same as the repo. in launchpad, so I need to push that tag over there. I use bzr status as a way of seeing if I need to do that.
<fullermd> Ah.  Then you're misusing status  ;)
<fullermd> It talks about uncommitted stuff.  Doesn't have anything to say about differences between two branches.
<rioch> :) good point
<rioch> but I do need to push this tag to get it into launchpad, right?
<lifeless> yes
<fullermd> (and tags don't get committed anyway, so status wouldn't have anything to say about them regardless)
<lifeless> please file a bug about status not showing the tag
<fullermd> Err?
<lifeless> fullermd: people look there. therefore we should do *something* to make it clear either what does happen, or perhaps do what they expect
<rioch> I'm confused. If I tag and then push, it says "no new revision to push", so how do I get my tag into launchpad?
<lifeless> that should have pushed it
<rioch> even when it said "no revisions to push" it still pushed something?
<fullermd> Yeah, there's a bug about that.
<rioch> ah ok.
<fullermd> push only _talks_ about revisions, though it does push tags too.
<fullermd> Actually, at one point it didn't push tags if there weren't revs to push too, but I'm pretty sure that one got squashed a while ago.
<rioch> can I verify that it pushed it in launchpad?
<fullermd> `bzr tags $URL`.  Probably `bzr tags :push` in your branch, since the LP branch is presumably the push location.
<rioch> I normally do bzr push lp:prioritise
<rioch> I did bzr tags -d lp:prioritise and it took a bit of time, then came back with the tag so I think it's in there.
<rioch> If not, I can remember revision 10 for now :D
<fullermd> Yeah, tags is probably a bit slow remotely, looking up revids.
<fullermd> tags --show-ids may be faster since it doesn't have to do the translations.
<fullermd> prioritise-0.1.0     jon@nijmegen-20100717110900-hdevk45kz74p5rck
<rioch> :)
<Anteru1> Hi
<Anteru> Hi
<rockstar> jam, https://bugs.edge.launchpad.net/tarmac/+bug/604741
<ubot5> Launchpad bug 604741 in Tarmac "HookFailed is deprecated (affected: 1, heat: 6)" [Undecided,New]
#bzr 2010-07-18
<swathanthran> if i did "bzr branch http://project-site.org/r/project/trunk" i would have to pull it all again to get another branch, http://project-site.org/r/project/old-version right?
<abbe> Hi everyone
<abbe> I've a query regarding use of 'bzr'.
<abbe> What is the difference between 'bzr pull' and 'bzr update' ?
<abbe> hey swathanthran
<swathanthran> hi
<abbe> any ideas ?
<swathanthran> http://omgili.com/mailinglist/bazaar/lists/canonical/com/f7ccd24b0912160937q6d0fc32fv36f7e9fc5ae241b1mailgmailcom.html
<abbe> thanks
<swathanthran> <quote>Ah. Karl said: " I use 'pull' because it will error if the dest tree is not pristine [...]". Maybe I misunderstood him. </quote> seems like pull checks for local changes while update won't mind them..
<abbe> okay
<DaffyDuck_> If a directory within a bazaar repostitory contains a .bzr, will that directory be ignored?
#bzr 2011-07-11
<spiv> Hmm, I think I just found a hack to improve the test suite time by about 10%.
<poolie> nice
<poolie> what was it?
<lifeless> rm -r <some dir>
<spiv> Yep, seems to work: have _check_safety_net just open .bzr/checkout/dirstate directly and compare the raw bytes to its known pristine state, rather than open_workingtree and check .last_revision()
<spiv> Which perhaps hints we can optimise opening a working tree a little more, but this is easier ;)
<spiv> (And perhaps we can improve further by just using stat, but that's probably not worth the complexity)
<poolie> indeed
<poolie> +1
<spiv> Hmm, I thought I'd targetted that branchbuilder patch to lp:bzr/2.4.  I wonder if I entered lp:bzr/2.4 into the text field without also clicking the radio button...
<poolie> :/
<poolie> spiv your branch has conflicts
<poolie> so you probably need to resubmit anyhow
<poolie> or fix it before mine completes
<spiv> poolie: thanks, looking now
<spiv> Oh, lp:bzr/2.4 is the same as lp:bzr.  I got the impression that we'd split them already.
<spiv> Just in time to avoid resubmitting :)
<poolie> we were meant to have split but vila hasn't done it
<poolie> maybe we should
<vila> poolie, spiv: lp:bzr shouldn't be the same as lp:bzr/2.4 AIUI, at least I've seen poolie sending a cleanup on lp:bzr and that's ok, the plan is to open lp:bzr as 2.5dev1. A few commits before that won't matter.
<vila> poolie: I think we should keep the minimum API to 2.4.0 for a little while so plugin authors can focus on releasing for 2.4 without having to handle 2.5
<vila> poolie: Does delaying the API bump sounds ok ?
<spiv> vila: Well, https://launchpad.net/+branch/bzr/2.4 still resolves to ~bzr-pqm/bzr/bzr.dev
<poolie> vila, i'm not sure what you mean
<poolie> there might have been api changes on trunk that would not be appropriate post-final-beta
<poolie> if that's true, we should branch off 2.4 from a previous revision
<vila> spiv: eerk
<spiv> vila: Poking around I see there is a lp:~bzr-pqm/bzr/2.4, but that's not where lp:bzr/2.4 resolves to
<poolie> possibly we should branch from the revision tag anyhow
<vila> poolie: no no
<vila> spiv: yup, that's the bit I missed, hopefully we can fix that without losas
<vila> poolie: there is no known API break that I know
<vila> poolie: I'm talking about bumping to 2.5. Last time we did this bump early, I don't want to make it *too* early
<vila> at a minimum, not when opening for 2.5dev1
<poolie> you're talking about when to change the api version vs the library version?
<vila> After 2.4.0 sounds about right
<vila> yes
<poolie> i think the separate api version is almost a null concept
<vila> ha
<poolie> iow i think people should just depend on the implementation version
<poolie> i don't think the api version is reliable enough to be worth while
<poolie> i don't think the api version is reliable enough to be worth while
<vila> hmm, ok, in this case we should decide if we deprecate that and make it widely known
<poolie> there is a bug complaining about it
<vila> so in the short term, I can just open 2.5dev1 and leave it at that (and also fix the lp:bzr/2.4 associated branch)
<poolie> can we be more concrete?
<poolie> i think the actions are
<poolie>  - branch off bzr/2.4 from trunk
<poolie> - increment the version in trunk
<poolie> ...?
<poolie> - add pqm configuration for 2.4 if needed?
<vila> branch off and pqm are already done
<vila> and I have a branch to switch to 2.5dev1 where I should commit and land
<poolie> but the 2.4 series in lp is pointing at the wrong branch?
<poolie> - add news and other document stubs
<vila> last, lp:bzr/2.4 should point to lp:~bzr-pqm/bzr/2.4
<poolie> right
<vila> yup, document stubs are uncommitted but done
<vila> I need to create a 2.5 series and some milestones on lp
<vila> (while ensuring doc/developers/releasing.txt is still up to date)
<poolie> ok, thanks for taking care of it
<poolie> vila, babune seems unreachable
<vila> restarted
<poolie> i was wondering if spiv's changes would have made things faster
<vila> which ones ?
<poolie> he did a thing to make selftest faster at checking whether it needs to make a new scratch directory
<vila> hmm, just looking at it
<spiv> vila: r6020
<vila> but the dirstate doesn't protect against repository changes
<vila> we talked about making the branch/repo read-only but I don't think we ever implemented that
<spiv> It's no weaker than the check it replaces
<spiv> Which was just wt.last_revision() == 'null:'
<vila> spiv: yup, just saw that
<jam> morning all
<vila> spiv: may be it should :)
<spiv> vila: well, maybe
<spiv> vila: except that this check has proved quite sufficient for years
<poolie> hi there jam
<spiv> So I think probably the effort to make it stricter is probably not worth it :)
<vila> spiv: did you see it trigger often ?
<vila> I know I never did
<spiv> vila: a better question is:
<poolie> is this about the guard wt above the tests?
<spiv> vila: did you ever see a problem that a stricter check would have avoided or helped with?
<spiv> vila: I never have.
 * vila nods
<poolie> it's a little kludgy that it's even there
 * spiv -> gone for the day
<poolie> bye spiv
<vila> poolie: all done, 2.5dev1 sent to pqm
<vila> there will probably some tweaks needed to move news entries from 2.4 to 2.5 for the ones landed since the fork
<poolie> ok good, thanks
<poolie> jam, how are you?
<Riddell> good morning
<poolie> hi Riddell, how are you?
<jam> poolie: doing pretty good
<jam> did you enjoy your vacation?
<jam> seems you were productive on the flight back againg
<poolie> i did
<poolie> it was pretty good
<poolie> i got a bit closer to getting usertest to do what i want too
<poolie> i hope to get back to that tomorrow or wednesday
<poolie> jam, how did you go with the performance bug that was affecting linaro?
<jam> poolie: bzr-svn peak memory issues? I got a little ways, but mostly I have to learn the bzr-svn codebase a bit
<jam> they are unblocked for now, because of the manual improt
<jam> import
<Riddell> poolie: I'm bright and breezy and looking forward to another exciting week of bzr
<poolie> :) great
<poolie> any topics in particular? something on the developer guide perhaps?
<poolie> jam, so what's next for you?
<jam> I was hoping to meet up with Jelmer today
<jam> once he wakes up
<jam> and finish the "is branch up-to-date" stuff
<poolie> did you see his mail? he won't be back for another day
<poolie> *2 days
<poolie> vila, according to the wiki you're pp this week; will that fit with your RM work?
<Riddell> poolie: yes I began looking at the packaging guide, I'll make some changes to it.  although the main problem with it is working out how to sensibly split the UDD stuff and the traditional packaging stuff (which mostly isn't in it)
<poolie> yes, that is a big question
<poolie> depending a bit on how much this is supposed to be a description of the future vs practically useful today
<poolie> spiv's selftest change doesn't seem to have especially made a visible change on babune
<poolie> but, there is a fair bit of noise
<poolie> oh, it did on maverick
<poolie> http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/buildTimeTrend
<poolie> perhaps natty just ran when the machine was busy
<vila> poolie: argh, how did I manage to miss that :(
<vila> poolie: don't answer :)
<poolie> which bit?
<vila> pp'ing this week
<poolie> oh that's ok
<vila> yeah, the queue is pretty short
<vila> poolie: regarding spiv change: yeah, looks noticeable on maverick and lucid but not on natty
<vila> they run serialized and the machine was quiet otherwise so, a priori, no external noise
<vila> we'll see if the progress persists but it's a good improvement
<jam> maxb: ping for great justice! (Actually just to ask you what happened to your code that checks if a package-import branch is up-to-date.)
<jam> maxb: I found: https://code.launchpad.net/~jelmer/bzr-builddeb/check-udd-status
<jam> but jelmer said you made it much faster by avoiding launchpadlib
<jam> and I don't see a ~maxb branch of bzr-builddeb
<poolie> jam i wonder what the action is on lp ssh performance
<poolie> since it's partly just waiting for it to get to the top of the queue
<jam> poolie: the last state-of-the-losa report said it was being worked on
<poolie> oh, really
<jam> (getting ha proxy at least)
<poolie> that's great
<poolie> i rebuilt on natty and it did get faster
<poolie> so, go spiv
<jam> "Partial de-spof of codehosting in process "
<jam> I'm inferring a bit there
<jam> but haproxy would be getting rid of a SPOF
<bigjools> can anyone help with this please http://pastebin.ubuntu.com/641976/ - bzr switch thinks  that something I just branched is not a branch :(
<maxb> bigjools: I'd guess that your current checkout is a checkout of a local branch since deleted?
<bigjools> maxb: gah, yes
<bigjools> thanks
<bigjools> what a weird error though
<maxb> well, ish
<bigjools> I guess it would help if I'd realised it was referring to a different branch to the one I just tried to switch to!  /o\
<maxb> It's a perfectly sensible error, but thrown from too low-level a point in the code, and not decorated with suitably informative context
<muep> hello
<muep> is there something roughly equivalent to git fetch origin && git log master..origin/master in bzr?
<muep> I'd like to see the changelog before I actually apply the new upstream changes
<AuroraBorealis> just branch upstream and do a bzr log on it?
<AuroraBorealis> bzr branch <orgin> && bzr log <orgin> or something
<maxb> muep: 'bzr missing --theirs-only' ?
<muep> looks somewhat what I am looking for
<muep> is it safe to mv a directory to which I have cloned an upstream bzr-using project?
<muep> I currently have just trunk cloned in src/emacs/ and I guess to get other local branches I would need to get some other directory
<muep> so I though I should maybe move my current copy to src/emacs/trunk and branch my local branches from that alongside it
<jamdahl> Hey guys, I'm having a problem with bzr explorer not launching from its shortcut
<jamdahl> anytime I try to open bzrw.exe, nothing happens
<AuroraBorealis> is the launch argument like this? "C:\Program Files (x86)\Bazaar\bzr.exe" explorer
<jamdahl> not exactly"C:\Program Files (x86)\Bazaar\bzrw.exe" explorer
<AuroraBorealis> should still work. whats bzr.log say?
<AuroraBorealis> should be in your documents folder
<AuroraBorealis> .bzr.log i think
<jamdahl>  Mon 2011-07-11 16:36:30 -0400 0.041  bazaar version: 2.2.3 0.041  bzr arguments: [u'explorer'] 0.044  looking for plugins in C:/Users/jamdahl/AppData/Roaming/bazaar/2.0/plugins 0.044  looking for plugins in C:/Program Files (x86)/Bazaar/plugins 0.125  encoding stdout as osutils.get_user_encoding() 'cp1252' 0.255  loading explorer extensions for clothes ['Bazaar support', 'Register on Launchpad'] 0.255  explorer extensions provided by th
<jamdahl> gah, limit to length
<AuroraBorealis> pastebin
<AuroraBorealis> that shiz
<jamdahl> http://pastebin.com/q81TeHum
<AuroraBorealis> hmm weird
<jamdahl> when I run bzr explorer from command line I get the same NoRepositoryPresent: No repository present: "file:///C:/" line
<AuroraBorealis> is it trying to autoload a repository?
<AuroraBorealis> try deleting your config for bzr explorer and see if that fixes it
<jamdahl> Where is it?  I've tried deleting the folder in appdata/roaming
<jamdahl> that was the first thing I tried when reinstalling failed... pesky config files...
<AuroraBorealis> yeah
<AuroraBorealis> its %appdata%/Roaming/Bazaar
<jamdahl> Yep, I've deleted that and if I run bazaar explorer it will regenerate that directory but still doesn't launch a gui
<AuroraBorealis> are you running the latest version of both bzr and explorer?
<jamdahl> thankfully I can call pretty much everything else in bzr and qbzr from the command line
<AuroraBorealis> i dunno what its doing trying to load C:
<jamdahl> I'm using one of the standalone packages
<jamdahl> if I have the wrong version of python it isn't my fault :P
<jamdahl> and it's not exactly the latest version but I'm downloading that now
<jamdahl> I was using 2.2.3
<jamdahl> downloading 2.3.3 now
<AuroraBorealis> it comes bundled with python so you don't need that
<jamdahl> That's what I'm saying :P
<jamdahl> updating to latest version of bzr did not change anything
<AuroraBorealis> hmm =/ i dunno
<jamdahl> aha
<jamdahl> I've been writing a plugin for excel to use bzr for VBA version control
<jamdahl> it got a bit messy at ttimes
<jamdahl> apparently at one point it did an init on the c drive
<jamdahl> apprently bazaar didn't like that and tried to autoload it or somethign
<jamdahl> deleting the repo in the c drive fixed it
<AuroraBorealis> nice =)
<jamdahl> too bad I can't find a satisfactory tool to diff sheets themselves
<jamdahl> anyway, thanks for the help aurora
<Noldorin> is it possible to edit old commit messages?
<maxb> Noldorin: no
<Noldorin> maxb, is this feature being considered? i know it was at some point.
<AuroraBorealis> dunno why you would want to
<Noldorin> AuroraBorealis, typos in past messages, basically
<Noldorin> AuroraBorealis, or accidental misinformation
<maxb> Noldorin: The immutability of revisions is pretty much baked deep into the fundamental precepts of bzr (and git and hg)
<maxb> The only way that I can see it could ever be implemented is via some sort of "No, actually I meant ..." metadata attached to future revisions, which masked the appearance of earlier revisions in the UI
<Noldorin> maxb, that's not what i heard. was talking to one of the guys who designed the bzr system, a couple of years ago here, and he said it would be possible
<Noldorin> maxb, he said it would be hard and require some changes to the way hashing was done or something, but possible
<maxb> Sounds like you should ask him then :-)
<maxb> But in any case, it's definitely a Hard Problem, and I've not heard of anyone seeking to address it recently
<Noldorin> maxb, oh yeah, i totally agree it's non-trivial :-)
<Noldorin> maxb, was discussed briefly on the mailing list before i think...wish i knew the guy's name i once talked to.
<spiv> maxb: to be precise, I think it'd be possible to have that metadata not necessarily be "attached to future revisions"
<maxb> The benefit seems quite low compared to the necessary expenditure of effort, which makes it a feature fairly unlikely to be worked on
<spiv> maxb: but it would need to be stored in the repo somehow, and we'd need to figure out how/when to transmit it efficiently, etc.
<maxb> Hi spiv
 * maxb now has jubany access :-)
<spiv> maxb: yay!
<Noldorin> maxb, possibly, though bzr is fairly mature these days...there can't be *that* many more important thigns?
<Noldorin> well, perhaps there are
<Noldorin> maxb, spiv right, so what's making the problem trickier than simply editing the metadata file for the repo with the new comit message?
<maxb> Suppose you edit the embedded metadata of a revision in one repository... how does bzr know it needs propagating to other repositories?
<maxb> How do you manage the auditability of such changes - or otherwise prevent them from being done maliciously?
<Noldorin> maxb, a simple boolean flag? either per branch or per revision
<maxb> boolean? What happens when I want to edit my edit? :-)
<spiv> Noldorin: "per branch" doesn't work, a repository can be used by many branches, and the number can change over time
<maxb> And what about if two people edit a revision in conflicting ways?
<spiv> (And similarly a revision can be propogated any number of times)
<Noldorin> maxb, spiv ok, so i'm being naive. the only thing that would really work is versioning the commit messages *themselves* :-P
<Noldorin> having each commit message essentially as a file
<Noldorin> maxb, that would seem to solve all those issues
<spiv> Noldorin: you could prototype that approach as a plugin
<Noldorin> spiv, oh yes?
<maxb> Of course, once you start down this path, people will want to edit metadata other than messages :-)
<spiv> Noldorin: store the extra info in a secondary store next to the regular repo
<spiv> Noldorin: and hook into bzr's fetch etc logic to do the propagation the way you envisage
<spiv> Noldorin: I think that it'd be an interesting (and useful) way to prototype it.  I also think you'll find it's harder than it looks ;)
<Noldorin> spiv, no doubt it will be quite hard, yeah. good suggestion though
<Noldorin> spiv, just thinking, would the functionality really be so different to bzr tags?
<spiv> There *might* be one or two points in bzrlib that don't make it as easy to write that plugin as it ought to be -- file a bug if you find them, they can be fixed.
<spiv> It is different to tags, because tags are per-branch
<spiv> (and not versioned either :P)
<Noldorin> spiv, the tags list is simply merged in the case of a conflict i suppose?
<spiv> See bzrlib/tag.py; if there's a conflict bzr reports it and lets the user sort it out basically.
<spiv> And tag deletion isn't propagated.
<Noldorin> spiv, in terms of merges you mean?
<spiv> (See also https://bugs.launchpad.net/bzr/+bugs?field.tag=tags)
<spiv> Noldorin: well try it yourself: make a test branch with two commits, branch it, and do 'bzr tag foo -r1' in one and 'bzr tag foo -r2' in the other
<spiv> Noldorin: and see what happens if you try push/pull/merge between those
<Noldorin> spiv, right
<AuroraBorealis> what should i include in a bug report for bzr explorer?
<AuroraBorealis> just my bzr log?
<Noldorin> spiv, so wouldn't it be easier just to patch the source rather than do a plugin?
<Noldorin> spiv, since i'd really want to modify the metadata structure. otherwise it owuld work too differently to an intended working version
<spiv> Hmm, much of it would be the same, and it would probably avoid requiring a new repo format if you did it as a plugin that used a secondary store.
<Noldorin> spiv, yeah, we'll see...
<Noldorin> brb for now
<spiv> I guess it would be easier to patch bzr proper, but it's also harder for people to test a patch
<Noldorin> cheers for the info
<Noldorin> spiv, yeah, so it might not get known as quickly
<Noldorin> hmm
<Noldorin> i'll consider. bye for now
<spiv> And I don't think it would be *that* much easier.
<spiv> I might be wrong :)
<putrycy> hi! Let's assume that I am working on some project. In some point in the past I gave the source to my friend. He has been coding and how he is sending the modified source to me. In the meantime I made some changes too
<putrycy> what is the simpliest way to merge?
<putrycy> From my point of view of course
<spiv> putrycy: how did they send the modified source to you?
<putrycy> only source files
<spiv> Ah.
<putrycy> they don't have access to the repository
<spiv> Ideally you'd have been using bzr branches from the start.
<putrycy> nor they use bazaar
<putrycy> so, I should make a branch usning the received source files?
<spiv> Still, in your case the best you can do is basically make a branch starting from the revision they started from
<spiv> (i.e. 'bzr branch -r 1234 my-branch friend-branch')
<spiv> then in friend-branch apply their changes (copy their version of the source files into it)
<spiv> then commit that, and then use 'bzr merge' to merge that back into my-branch
<putrycy> OK, I get it, thank you very much
<putrycy> btw isn't there anything like patch in bazaar?
<spiv> You're welcome.
<spiv> Sure, the 'bzrtools' plugin adds a 'bzr patch' command
<putrycy> and does it resolve my problem too?
<spiv> But you said you had entire source files, not patches?
<putrycy> yes, of course
<putrycy> just looking for the simpliest way to merege
<putrycy> It would be perfect If I could make patch using the source tree and the branch from that they started development
<putrycy> and then just apply the patches
<spiv> Sure, you can use 'bzr diff' to generate patches, but I don't think it'd be easier (I don't think it'd be significantly harder either)
<spiv> If you already have patches, then just applying the patches is almost certainly the way to go.
<putrycy> I have to try out both to find out...
<sidnei> so, how easy is it to split a bzr branch while keeping history?
<putrycy> yesterday i noticed some strange (for me) bahaviour: bzr didn't want to add any files to the repository if there was a .svn directory in the same director what an added file
<putrycy> could somebody explain it to me? And how to overcome it?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/809048 any idea whats broken ?
<ubot5`> Ubuntu bug 809048 in bzr (Ubuntu) "bzr crashed with AttributeError in stopTest(): '_TypeEqualityDict' object has no attribute 'clear'" [Undecided,New]
<lifeless> dupondje: what python version ?
<lifeless> putrycy: you have bzr-svn installed
<lifeless> putrycy: so that is detecting you have an svn checkout there and is working with that instead
<dupondje> Python 2.7.2+ (default, Jul 10 2011, 09:48:58)
<dupondje> ubuntu oneiric
<lifeless> dupondje: I suspect testcase.__dict__ isn't what it used to be in earlier pythons ;)
<poolie> hi all
#bzr 2011-07-12
<spiv> Hmm, babune does seem to show a bit of a speed increase in the test suite, yay (and also from the Branch.open improvement from Dublin)
<spiv> Since before Dublin looks like its down to ~21min from ~24min, even though the test count has increased a bit. :)
<poolie_> hi spiv
<poolie_> that is indeed pretty cool
<sidnei> hey poolie, how easy is it to split a branch while keeping history?
<sidnei> #501828
<sidnei> https://bugs.launchpad.net/graphite/+bug/501828
<ubot5`> Ubuntu bug 501828 in Graphite 1.0 "Create separate branches for the webapp, carbon, and whisper" [Low,Triaged]
<lifeless> poolie_: btw, just doing an experiment
<lifeless> poolie_: bzr selftest --parallel=fork on my new desktop - looks like it will complete in ~ 3 minutes
<lifeless> poolie_: its causing writes to the disk of 1 and 2 MB/s which is a noticable amount (especially considering most things are expected to be deleted and never hit disk)
<spiv> lifeless: yeah, I've noticed that, haven't tracked it down yet
<spiv> (I haven't really spent much time looking either)
<lifeless> hmm, forgot --no-plugins
<lifeless> 3m8 seconds, 27172 tests
<spiv> There was an issue where some tests would cause writes to ~/.bzr.log, but that's fixed
<spiv> lifeless: :)
<lifeless> huh
<lifeless> 'failed to open trace file:[Errno 12] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
<lifeless> test stipple
<lifeless> andhow, --no-plugins timing, 2m33s 23794 tests.
<spiv> Yeah, that's fallout from said fix.
<lifeless> s/and/any/
<lifeless> s/12/13/
<spiv> lifeless: BZR_PLUGIN_PATH=-site is my usual, includes core plugins
<lifeless> want a run with that?
<spiv> Why not, it won't take long ;)
<lifeless> :)
<lifeless> I wonder if gnome-terminal is becoming a limiting factor
<lifeless> those lazr.restfulclient errors are really annoying
<lifeless> 2m52s 26708 tests
<spiv> Ah right, weave_fmt would be the bulk of the extra tests..
<spiv> lifeless: so 155 tests/second, not too bad.
<lifeless>  /8 to get tests-per-process-per-second
<lifeless> 19 or so
<lifeless> 2m54s in uxterm, and I was fiddling with things, - I remember we clamp our terminal IO now that I think about it :)
<poolie_> lifeless, it's about 4 minutes on my laptop
<poolie_> which lazr restfulclient errors?
<poolie_> using a tmpfs will help more
<lifeless> userwarning: modjule test was already imported from <path.pyx> but <different path> is being added to sys.path
<poolie_> i think some of it is that ext4 still flushes directory creation/deletion to disk
<poolie_> even if it could be shortcircuited
<lifeless> poolie_: interestingly enough, I see near-full use of my 8 cores
<lifeless> poolie_: for you be 25% slower, but with 4 cores, raises some interesting questions
<lifeless> poolie_: 32 or 64 bit environment ?
<poolie_> 64
<lifeless> huh
<poolie_> i haven't precisely measured it recently
<lifeless> fascinating
<poolie_> it's single digit minutes
<poolie_> by contrast to about an hour on bellany :)
<lifeless> naive math would suggest 6 minutes (*2 for 1/2 the cores)
<lifeless> do you have an ssd?
<poolie_> yes
<lifeless> that may be part of it, but we don't fsync so I wouldn't have expected it to block
<spiv> But there certainly is a lot of disk IO for something that should do net I/O of approx 0 bytes...
<poolie> lifeless, thanks for that mail review
<vila> poolie: standup ?
<vila> hi all !
<poolie> vila, oh, now?
<poolie> i'm confused
<vila> no ?
<poolie> it's only 0600utc, that seems too earl
<vila> ghaa, I'm the one confused then >-/
<poolie> i have it on my calendar for 2h from now
<vila> I won't be able to attend at 0800 UTC
<poolie> spiv, what happens next with https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634
<vila> which probably explains my confusion
<spiv> poolie: the pre-req branch gets landed, in theory by the time I wake up tomorrow
<poolie> vila, well, i sent mail last week with that time
<poolie> can you reply with an alternative?
<spiv> poolie: oh, and I guess I need to find the CSS class to use to address your tweak! :)
<poolie> spiv, rockin, and then it's unblocked?
<poolie> that'd be good
<poolie> and also the feature flag name, if you didn't already
<spiv> poolie: I think so, I'll certainly poke folks on #launchpad-dev to get it reviewed and hopefully landed
<vila> poolie: yes, sorry, dunno why I kept 0800 my time instead of UTC
<spiv> poolie: hmm, the feature flag is already âcode.ajax_revision_diffs.enabledâ
<poolie> oh great
<poolie> maybe i was out of date
<spiv> Oh, maybe not, maybe I'm confusing the syntax?
<spiv> Certainly the last time I tested it I put code.ajax_revision_diffs.enabled into +feature-rules and it worked!
<poolie> ah
<poolie> it's right in the tal but it's wrong in flags.py
<poolie> so, you'll get a warning, and it won't be documented properly
<spiv> Ah, yes, that'd be it.
<fullermd> vila: Still campaigning for the Paris Meridian?   :p
<poolie> well, earlier is certainly fine with me, basically you need to fight it out with other people in europe
<vila> fullermd: never resign !
<vila> poolie: yes :-}
<Riddell> good morning Bazaar
<jam> morning all
<jam> vila: aren't we doing the standup today?
<Riddell> no poolie or spiv either?
<jam> I see poolie was here 45min ago
<jam> not sure what happened
<Riddell> well I can go back to sleep for half an hour then :)
<oier> hi
<oier> I am not sure if I am on the correct channel, but I have problems using bzr builder (the recipes in launchpad to use dailys)
<oier> the problem is that I get translations exported automatically to a branch but I don't know how to merge it in the recipe
<oier> if I use nest or nest-part it creates a po/po directory, which is useless
<spiv> oier: this channel and/or #launchpad are good channels.
<oier> and merge doesn't work because the branches are unrelated
<spiv> oier: which branches?
<jam> hey spiv, have you seen poolie around? I thought we switched the standup to 15min ago
<oier> lp:indicator-bug and lp:~oier/indicator-bug/translations
<spiv> jam: based on chatter in this channel an hour or so ago I thought it was in 45min time!
<oier> in trunk I have a po directory which contains the po file, the translations branch is a po directory with the translated po files
<jam> spiv: yeah, looks like it, let me check the mail thread again
<spiv> oier: ah, hmm
<jam> spiv: yeah, martin's last message was 8:00UTC Tuesdays
<jam> I didn't pay enough attention to the actual post, vs what I felt was consensus. stupid timezones being confusing
<spiv> oier: I don't think build recipes can do that atm :(
<spiv> jam: agreed!
<jam> so jr can sleep 40 more minutes
<oier> i found a similar bug report where the status is fix released https://bugs.launchpad.net/bzr-builder/+bug/515731
<ubot5> Ubuntu bug 515731 in bzr-builder "Support merge of two branches that have no common ancestor" [High,Fix released]
<spiv> oier: as a workaround you could nest or nest-part the translations into a new directory and then make a branch of lp:indicator-bug that tweaks debian/rules to move the contents of that directory into po/ before doing anything else
<spiv> oier: yeah, that bug is what nest-part was added for, but it turns out not to address every case
<spiv> oier: like yours :/
<spiv> oier: probably best to file a new bug, reference that one
<spiv> oier: maybe it'll be marked as a dupe, but that's ok.
<oier> but isn't the fix for merging unrelated branches released?
<oier> it should be working according to it, or? https://code.launchpad.net/~jelmer/bzr-builder/merge-unrelated/+merge/51425
<spiv> oier: hmm, I'm not sure that that fix would deal with the case where both sides add the same directory, like your case :(
<jam> Riddell: hey, we're starting to get together now
<spiv> poolie: we were just talking about you :)
<poolie> hi
<spiv> (on mumble)
<poolie> hm :)
<poolie> pulseaudio crashed!
<poolie> :/
<jam> poolie: still down?
<poolie> yeah
<poolie> going to restart my session
<jam> k
* Topic unset by poolie on #bzr
<poolie> gah
* poolie changed the topic of #bzr to:  Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell and jam | UDD failures: 400
<jam> spiv: do you want to do PP on your last week ?
<spiv> jam: not sure!  I wouldn't be around to follow-up anything that lives beyond that week obviously.  I suspect I'll be hurrying to close off as much of my current work as possible first.
<spiv> It might still be a good idea though.
<jam> spiv: how about you take next week
<jam> seems like a lot of people are otherwise away
<spiv> Ok, sure.
 * spiv -> gone for the night.
<jam> spiv: have a good night
<jam> spiv: I had the weeks mixed. vila is here next week, but not the 25th. so for now I have you on the 25th.
<jam> We can also swap that out if we need to.
<maxb> spiv: On the UDD append-revisions-only issue, do you think it's worth backing out the change and manually unblocking the resulting failed imports, or is fixing it going to be easier than it seems?
<poolie> hi maxb
<maxb> morning
<jam> maxb: he's away for the night. I think he wants to try the 'simple' fix first, and if that doesn't work, then just back out the whole thing
<jam> Riddell: you wanted to pair on some reviews
<jam> let me know when you want to do so
<Riddell> jam: can do if you're doing them now
<Riddell> jam: mumble?
<jam> Riddell: I wasn't starting them, just thinking to plan it out. But I'm happy to get on mumble with you now
<jam> maxb: I wanted to find out about your "check-up-to-date" stuff if you have it
<Riddell> jam: well any time is good for me including now
<maxb> check-up-to-date?
<jam> maxb: check if a udd packaging branch is up-to-date vs its deb packages
<jam> jelmer had a branch
<jam> which he said you improved by removing launchpadlib
<maxb> Oh, that was mainly the discovery of how to successfully call the lp api without launchpadlib
<maxb> At the time, it involved mocking up a fake OAuth header
<jam> maxb: well, it was 'real' enough to get past launchpad, right?
<maxb> Nowadays, the squid has been fixed, and shouldn't even require that
<jam> maxb: I'd like to make sure that stuff doesn't get lost
<jam> so even if it is only a hint in the right direction, it would be nice to see
<maxb> http://paste.ubuntu.com/642517/
<maxb> So, if you safe that as a script, and run 'foo ubuntu/+archive/primary bzr' you'll get a familiar looking listing with only one http roundtrip
<jam> maxb: so the issue with oauth... LP wants oauth for authenticated users, but for anonymous queries it shouldn't require it?
<maxb> and no launchpadlib in sight
<maxb> Correct - *shouldn't* - but at the time, anonymous API access was being partially broken by the squid
<maxb> That, however, has since been fixed
<jam> maxb: yeah, you have the oath stuff commented out in your paste, and the bzr check worked fine for me
<jam> and nicely fast, too
<maxb> The lazr.restful collections stuff will paginate the response at a default batch size of 75 items, I believe.
<jam> [needsfixing] this is a change that is required
<jam> [needsinfo] this is a change that you're asking for questions
<poolie> lp is a bit confused about whether it's readonly atm
<poolie> should be fixed soon
<maxb> However, for the kinds of requests we need to make, we should be able to phrase the query parameters such that we are only expecting a collection of zero or one items, and thus avoid needing to reimplement any of lazr.restfulclient's paging navigation behaviour
<jam> poolie: by not having a "readonly" mode, right?
<jam> (just being down completely)
<poolie> no, it seems to have lost people's sessions
<arnetheduck> hi, I would like to replay a complete bzr history for a particular branch, running a script on the working tree for every commit (much like what git filter-branch) allows you to do...I haven't found any existing command that will do this in a simple way (I'd like to preseve commit authors, merges, renames etc), so I'm guessing I'll have to do a plugin myself - could anyone supply some useful pointers for where to look?
<poolie> hi arnetheduck
<poolie> just the mainline or every single revision?
<poolie> oh, you want to change the tree along the way?
<arnetheduck> poolie, every single revision and with a script applied for each one
<poolie> probably starting a plugin to do it would be good
<poolie> something like branch.iter_merge_sorted_revisions()
<poolie> then for each
<arnetheduck> (fixing line endings =)
<poolie> wt.update(revision)
<poolie> then, i guess, commit it to a separate branch
<poolie> you could perhaps look at adding this into the bzr-rewrite plugin
<arnetheduck> yeah, I had a quick look at that one but it wasn't obvious how to record renames for example and how to assign (one or more) parent revisions to a commit etc
<arnetheduck> I'm guessing iter_merge_sorted_revisions guarantees that all commits leading up to a particular revision have been visited?
<arnetheduck> getting a working tree looked simple enough so then the biggest problem would be to get the commit properties right
<poolie> yes
<poolie> the nice thing if you modify the working tree is that it should keep the same metadata for renames etc
<poolie> i thought bzr rewrite did this though
<poolie> if you come up with any kind of reusable patch that does this i'd really like to help merge it
<jam> poolie: we have "bzr fast-import-filter"
<jam> I don't think we have anything for rewrite yet
<poolie> Riddell, thanks for the review
<jam> arnetheduck: "bzr fast-export content.fi && cat content.fi | bzr fast-import-filter | bzr fast-import" I *think* works.
<arnetheduck> jam, fast-import-filter only allows filtering the file list, not contents, afaict
<jam> arnetheduck: probably
<jam> that is the only filtering that I'm currently aware of
<jam> I think adding it to replay/rebase/whatever looks good
<jam> arnetheduck: did you end up signing the contributor agreement? We'd like to land: https://code.launchpad.net/~arnetheduck/bzr/bzr-log-author/+merge/63751
<arnetheduck> jam, yes I did (but I think I might have misspelled your email when cc:ing)...martin pool has a copy though.
<jam> arnetheduck: no problems on my side, and martin may have already added you to the approved list. I just figured it was quickest to just ask you :)
<jam> yes, martin has marked it as such
<jam> I was just waiting for the script to finish running that verified it
<arnetheduck> so, a) how do I add a rename to a commit (code-wise...it looked messy on my first perusal of bzr commit/bzr rename) and b) apart from properties (incidentally the ones searched by log-author=), is there anything else that should be recorded?
<poolie> wt.rename ought to do it
<poolie> if you don't want to add new renames to the tree, you shouldn't need to worry
<poolie> the other thing you may need to take care to preserve is the revision DAG
<poolie> in particluar if you're rewriting them you'll need to set the tree revision parents to the newly rewritte ones
<arnetheduck> yeah, I'm guessing i should be committing to a separate branch essentially creating a copy (with different commit id's)
<arnetheduck> and the list of renames is available on the branch object?
<jam> poolie: I think arnetheduck is re-creating the ability to replay a diff
<jam> arnetheduck: I think you should try to use rewrite's code that already does that
<arnetheduck> also - how close to this is the rewrite plugin? not that I put very much effort into it but I didn't immedeately understand what it did (code-wise) so I stopped reading...perhaps I should take a second look?
<jam> arnetheduck: it should do 90% of the work for you, which is setting up a new tree that looks just like another tree but with a new source
<poolie> jelmer will be back online tomorrow, i think, and could talk to you about it
<poolie> right
<jam> you just need to add a hook/etc to call your code
<jam> with something that can mutate the tree content as well.
<jam> from what I can tell "WorkingTreeRevisionRewriter" and "RebaseState1" are things to look at
<arnetheduck> I think it was the references to "rebase" that scared me off...I've never quite understood why people would want to do that =)
<jam> arnetheduck: it is essentially, create a revision with this diff applied to that revision
<jam> which is pretty much what you are doing, with "this diff" being custom for your use case
<Riddell> jam: lp:~jr/bzr/bzr-log-author
<Riddell> jam: in bzrlib/log.py  at "searchRE ="
<arnetheduck> I'll have another look then, thanks
<poolie> good night
<jam> maxb: the other thing with your script, is that if it is fast enough we can easily put it in such that it happens whenever you access a given branch
<jam> rather than having a separate command.
<maxb> Or, at least whenever you branch/pull/update
<jam> maxb: right. is there a way to filter by series?
<jam> since when you go to "ubuntu/..." you know you want the latest 'oneiric', or whatever
<jam> I'm just noticing that the returned data seems oddly sorted
<jam> so I'm wondering if we can be sure we have the latest
<jam> maybe it is always the latest in each pocket/series/whatever?
<maxb>             'distro_series': '/ubuntu/natty', for example
<Riddell> jam: https://code.launchpad.net/~gary-wilson/bzr-loom/docs/+merge/66826 looks like it's ready for merging, does loom use pqm or direct merges?
<jam> Riddell: direct merges
<Riddell> ok, I'll do that
<maxb> jam: Given that we're filtering on the "Published" status, it will be the latest (except potentially you might get two if you hit the API at exactly the moment of a new publication, I think)
<jam> maxb: but the "distro series" has to be a full URI...
 * maxb hugs undocumented features :-)
<maxb> Also, technically "/ubuntu/natty" is an URI
<jam> maxb: I imagine it matches whatever comes back in "distro_series_link"
<jam> ah, I was just doing "natty"
<jam> yeah, /ubuntu/natty
<jam> works
<jam> and seems to be quite a bit faster
<maxb> jam: However, we won't be able to make this work so well for Debian, I think, since LP never actually sets Debian publications to the Published state, they remain Pending forever
<jam> well, 2-300 ms faster
<maxb> As such, we have no way to conveniently get just the most recent one
<jam> there doesn't seem to be anything in "Pending" for bzr
<jam> but that matches: https://launchpad.net/debian/+source/bzr
<maxb> There's nothing "Pending" in ubuntu, there is in debian
<maxb> Well, I suppose we always have the option of just setting ws.size to 1 and trusting the sort order to do something sensible
<jam> maxb: I did a query for "Pending" with no distro_series, and it came back empty
<jam> maxb: trusting the sort order to do something sensible....
<maxb> Did you also change the archive to debian/+archive/primary ?
<jam> I don't have that kind of faith
<jam> maxb: good point
<maxb> https://launchpad.net/debian/+source/bzr/+publishinghistory for example
<jam> the sort order does seem to be reverse debian sort order
<jam> however, that means it mixes distro_series groups
<jam> but that might be ok if we start restricting by that
<maxb> There is also a pocket parameter on the API call
<maxb> Takes a value like '"Backports"'
<jam> right
<jam> so if you grab "ubuntu/natty-proposed" we have to split that into a distro-series and a pocket, right?
<maxb> right
<jam> "lp:ubuntu/natty-proposed/bzr"
<maxb> (or do a bunch more round trips to resolve that, which somewhat defeats the point)
<jam> well, something small is ok, but I do notice that getting the debian results is quite a bit slower
<jam> I presume because it asks the db to sort and get everything to just return new stuff
<jam> ugh, my home network just decided it wasn't going to route packets to the world anymore. So now I'm on "3g". but at least I'm online
<indigo> in my dev branch, "bzr status" is showing an uncommitted merge, but I don't remember from what branch I merged. Is there some way to find out?
<indigo> i know if i commit the changes, then the branch nick will be displayed in the log, but i'd like to know without committing.
<maxb> If you have it, the GUI "bzr qlog" would be a simple way of seeing it
<indigo> gui? what's that? ;)
<fullermd> It's what you get when you spill coffee on your punch cards.
<indigo> i thought it was a way to run more terminals at a higher resolution than supported on the console.
<fullermd> 'stat -v' will give you the full list of revs pending; that might point you in the right direction.
<fullermd> Also: "history | grep merge"   :p
<indigo> yeah, stat -v gives me the log messages and dates of the pending revs, but not the branch nick
<indigo> i found the branch manually, but still i'd like to know for the future
<fullermd> I've often believed that --show-ids should make stat show the revids of pending merge revs (though space concerns make it not entirely obvious how).  That would let you point log at 'em.
<fullermd> Some way to dump info about pending merges would be handy, to be sure.  Of course, the nick may or may not really tell you anything useful.
<indigo> garbage in, garbage out applies for sure
<fullermd> Maybe WT_FORMAT++ should include a placeholder for "URL of pending merge"...
<indigo> maybe, but i'd think if information would be available in a log after a commit (like the branch nick) there should be a way to get that information without committing
<fullermd> Well, since the rev is in your local repo, you can show it with log.
<indigo> how do i show it without committing it?
<fullermd> Just a matter of finding the revid, which the CLI doesn't expose anywhere I know of.
<indigo> ah.
<indigo> i would say just changing stat -v to put the branch nick in the list of pending merges would be a good solution
<fullermd> (which is why qlog can do it; it just looks at the revid in the internal WT structure and shows from it)
<indigo> that's where i'd think to look for the information i want, anyway
<fullermd> IWBNI(tm) the full complement of 'log' options were available for that list of pending merges.  Alternately, a revspec/option for log to look directly at them from there.
<fullermd> ('course, that also ties into the "standardize log-like options" pile too.  Whee.)
<indigo> it would, but i never would have thought to use "log" to look at things i haven't committed.
<indigo> i always thought of "status" as a sort of "log" for uncomitted things.
<fullermd> Anyway.  I have to go yell at a client for screwing up their data.  Again.
<indigo> put those clients in their place
<fullermd> I DO have a shovel just lying around...
 * fullermd didn't say that out loud.
<vila> maxb: I'm about to announce 2.4b5, did you have troubles upgrading the ppas or is it just lack of time ?
<vila> maxb: or may be you're waiting for sid ?
<maxb> vila: Oh, whoops. I just failed to notice a release going on :-/
<maxb> I'd normally wait for sid, but do work to make sid happen faster
<maxb> I suggest announcing, and barring unexpected problems, I'll sort the PPA tonight
<jamdahl> I've got a storage efficiency question
<jamdahl> I'm working on a plugin for Excel that does version control for workbooks and VBA code using bazaar
<jamdahl> the code is exported to text files for easy diff-ing, but the excel files themselves are zipped
<jamdahl> looking at the size of my repos, it looks like bazaar is can't handle file deltas for zip files and instead ends up storing the equivalent of a whole new copy of the excel file with each commit
<jamdahl> if I switch to a non-binary excel format, like xml, am I going to get more efficient storage?
<jamdahl> even though each each individual xml excel file will be bigger than xlsm/xlsx
<maxb> Hmm, it's looking like oneiric's python has broken bzr test stuff
<maxb> A number of failures in the daily PPA
<dobey> hey all. i have some questions about locking branches inside a process using bzrlib. is there a way to lock a branch, do everything i want with it, and then unlock it, with bzrlib, or do i *have* to unlock/lock around certain actions like merge and commit?
<indigo> jamdahl: if the diffs are small, i believe the answer is "yes"
<indigo> jamdahl: actually, maybe bzr does do binary deltas, but if you are zipping your files, then you will never get small diffs
<indigo> jamdahl: https://lists.ubuntu.com/archives/bazaar/2006q4/019182.html
<jamdahl> To be clear, I'm not zipping the files, excel format from 2007 on is a zip file. :P
<jamdahl> really what I'm considering is unzipping stuff before I pass it to Bazaar
<jamdahl> Running an expirment with that now, but unforunately the tons of xml files are completely choking the diff even with small changes :(
<dobey> jamdahl: i'm guessing that the xml bits of msoffice/openoffice documents are not particularly well formatted
<jamdahl> Opened up one of the changed files.  It's all on one line...
<jamdahl> 137kb of xml on one line
<dobey> yep
<ZyX-I> Hello. All links for 2.4 beta release on http://wiki.bazaar.canonical.com/WindowsDownloads are broken.
<ZyX-I> Is there a msi installer for bzr somewhere or something other that does not require user interaction?
<jamdahl> unzipping the excel files is definitely not going to work with the lousy xml formatting.  Any ideas on how to avoid the storage problem?
<dobey> jamdahl: i must have missed it; what is your problem exactly?
<jamdahl> I've written a plugin to do version control for excel spreadsheets + the VBA inside them
<jamdahl> the VBA code exports to text files that bazaar plays nice with
<jamdahl> but every time the sheet changes, the whole new excel file (or close to it) gets stored because its a zip file
<jamdahl> so every time I do a new commit, the repo increases in size pretty close to whatever the size of the spreadsheet is... Not particularly good
<dobey> ah
<dobey> unfortunately, i think the only solutions to that are "don't use msoffice" or "don't store msoffice files in bzr" :/
<dobey> unless maybe you can also write a filter or something, so that when the office file gets saved, you format the XML nicely, so you don't get this problem
<jamdahl> unfortunately, it would be a pain in the ass to go into 20+ xml files for each excel document and reformat that every time after they are changed :(
<dobey> jamdahl: by "filter or something" i meant "extension to excel, such that it happens when the file is saved"
<fullermd> There is theoretically infrastructure in bzr to allow writing a plugin that does that for you.  There's occasional talk about how to do so.
<dobey> or you could do it with a bzr plug-in probably
<jamdahl> development of a bzr plugin is beyond my current coding capabilities
<jamdahl> I'm not terribly experienced in anything but VBA right now
<jamdahl> hmmm, expirimenting with the older excel format
<jamdahl> I don't think the older ones are zipped
<jamdahl> gah, older format breaks too much functionality
<dobey> the older format is a binary
<dobey> a funky majestic binary
<dobey> of course, a lot of the new format is just <xmltag>streamofbinary</xmltag>
<dobey> lovely insanity, that
 * dobey wonders who to talk to about bzrlib.branch.Branch locking, though
<jamdahl> binary isn't as bad as zipped :P
<dobey> zip files are binaries
<jamdahl> Zip files are a particularly kind of binaries that suck for deltas due to compression algorithms
<jamdahl> But the truth is, (most?, many?) binary files don't binary diff that well anyway. Frequently they are compressed, which means a modification near the beginning tends to have a chain reaction over a large distance (possibly the whole rest of the file).
<jamdahl> that's a quote from the page indigo linked
<jamdahl> so a non-compressed binary is less-than-ideal, but better than a compressed one
<dobey> well often, there's a header, and then the compressed content
<dobey> and if anything changes in the content, it gets recompressed, so the whole block changes
<jamdahl> Right now what I'm trying is the new binary excel format which is zipped binaries
<jamdahl> I don't think the binaries that are zipped are themselves compressed
<dobey> well, a lot of the data in them is probably compressed
<jamdahl> Doesn't make much sense to double-compress
<jamdahl> It wouldn't speak well of zip compression if that actually saved any space
<maxb> Hrm. The armel-cross-toolchain-base UDD import really is interestingly broken
<maxb> The importer has reimported several package versions multiple times onto the maverick branch
<poolie> hi all
<Riddell> g'day poolie
<maxb> Riddell: Hi. I think I've found a problem with the new signature checking changes to log - I've had bzr qlog crashing on me because RemoteRepository doesn't implement verify_revision
<maxb> I need to file a proper bug still - but since you're around :-)
<maxb> or not
<spiv> maxb: hmm, that suggests that a) we're missing per_repo tests for verify_revision, and b) that a quick _ensure_real shim would deal with the problem for now.
<mgz> ...how do I make hg give me something I can attach to a bug? their bundles aren't very friendly.
<mgz> I'm trying to get an upstream fix for bug 809048 accepted.
<ubot5> Launchpad bug 809048 in bzr (Ubuntu) "bzr crashed with AttributeError in stopTest(): '_TypeEqualityDict' object has no attribute 'clear'" [High,Confirmed] https://launchpad.net/bugs/809048
<lifeless> mgz: hg diff
#bzr 2011-07-13
<mgz> there's no way of getting the parent rev or my user id in the text?
<lifeless> hg diff --git perhaps
<mgz> ...seems not. ah well.
<mgz> they'll just have to take it on trust that I wrote the test first and it failed, rather than having two seperate revisions
<poolie> hi riddell, spiv, mgz, lifeless
<mgz> gra, dealing with python-dev is such a pain.
<mgz> I guess it's nice I got a response before I'd posted my patch, and that the fix was so obvious someone else landed the same thing right away.
<spiv> mgz: thanks for getting that fixed in upstream!
<poolie> spiv, robert asked if you had any outstanding work to do with the twisted haproxy availability stuff (mumble)
<poolie> ithink it's just blocked on losas but is there anything else still with you?
<spiv> Not that I can think of.
<spiv> Oh, there's this near trivial, approved patch that still hasn't been landed: https://code.launchpad.net/~spiv/launchpad/haproxy-for-twisted-services/+merge/48427 :/
<poolie> i could try to land it
<poolie> spiv, what should the commit message be?
<poolie> just "fixes a cosmetic glitch in the text in the new web status page for codehosting SSH: it was always saying "Unavailable""?
<poolie> ok i'm sending it
<spiv> That sounds good.
<spiv> Thanks!
<maxb> spiv: Hi. Is it time to roll back the UDD append revisions only change, or are you still hopeful of fixing shortly?
<spiv> maxb: time to roll it back, I hope to get to that tomorrow my time, but it's dragged on long enough in the mean time I think
<maxb> Unfortunately, even accounting for those failures, we have still acquired a several more in recent weeks, making the number in the topic a bit of a lie :-/
<maxb> Some of them are more packages switching to multiple upstream tarballs
<maxb> Not sure what the rest are
<maxb> lp downtime.
 * maxb has paused the UDD importer
<maxb> (echo 0 > max_threads)
<poolie> hi maxb
<jelmer> ji
<jelmer> hi poolie, maxb
<poolie> hey
<poolie> welcome back
<poolie> are you ok?
<jelmer> thanks, it's good to be back :)
<jelmer> I'm doing a lot better; my leg is still bandaged and contains traces of metal but I'm feeling well
<jelmer> No standing desk for me for the next little while :)
<jelmer> thanks for all the well wishes
<poolie> :)
<jelmer> how has everything been here?
<poolie> good
<poolie> you might like to look at the standup notes
<poolie> and my mail about next-quarter goals
<poolie> hm i was going to feed pqm a bit but it's a little hard with lp readonly
<poolie> those windows should be getting much shorter, which is great
<jelmer> ah, cool
<poolie> ah
<poolie> there was some fallout from your bzr & plugins updates into lp
<poolie> i'm not sure if this started before your break
<poolie> it might be useful if you check up with one of their developers about that
<poolie> once the current update has finished
<jelmer> oh, ok
<poolie> i wonder if we should actually have a short postmortem thread about it
<poolie> i'm not sure if the operational postmortems currently practiced are good value
<poolie> but, perhaps something about lessons to learn for next time would be good
<jelmer> yeah, that's probably a good idea
<poolie> one thing from talking to robert was that it would be nice, all else being equal, if those changes can easily be rolled back
<poolie> i think there was concern that the cache formats had changed so they could not roll back
<poolie> i'm not sure if that would actually have been true
<jelmer> the cache formats haven't actually changed in backwards-incompatible ways, as we also allow people to use multiple plugin versions in parallel on the same system
<jelmer> that should probably be documented somewhere though, and not just be in my head
<poolie> are you still on lp-dev?
<jelmer> yep, I need to catch up on the last week of email though
<poolie> :)
<poolie> i'll kick it off
<poolie> i think a lot of it will be in your head and robert's head so getting it out may help
<poolie> i should go and have dinner
<jelmer> that'd indeed be a good discussion to have on lp-dev
<jelmer> also, bon appetit! :)
<poolie> :)
<poolie> we're having a UDD meeting in 2h40m iirc
<maxb> hello all
 * maxb unpauses UDD imports
<maxb> sigh, too soon
<awilkins> jelmer, Just got hit by #485601
<awilkins> Happily I think I can work around it, it's just me working on the branch and I can push --overwrite from one repo and re-pull from the other. It does seem to be when you merge into the trunk and push it, and then pull that from SVN on another machine, and try to pull on the original machine
<awilkins> (from the second machine)
<awilkins> Ok, darn, that didn't fix it
<awilkins> Ok, so : removed repo on M2. Recreated empty repo. Pushed from M1  (machine that did the merges) to M2. Pulled new SVN-origin revisions from SVN on M2. Pulled these back from M1. Issue fixed.
<jam1> awilkins: jelmer may not be around yet. He was supposed to be returning from vacation today. I think that means he'll be around tomorrow, or maybe late tonight.
 * jelmer waves
<awilkins> jam, Ok... it's not a fatal problem for me, just making some notes as to avoidance on the bug ticket
<jelmer> jam: H
<jam> hey jelmer
<jelmer> Hi John, how are you?
<jam> doing pretty good, feeling better yourself?
 * jelmer is batch-processing email :)
<jam> I got maxb's code for finding the most-recent publication, and I'm poking at it to try to integrate it into something like "bzr branch"
<jelmer> jam: I'm doing a lot better, thanks; it'll take some more time for my leg to heal but seems to be going ok
<jelmer> jam: ah, cool
<poolie> hi jam
<vila> jam: just passing around, see my last comments about the 2.3.4 blocking bug: I agree with you, just wanted to make sure you're ok with landing the patch as is and addressing the larger issues in a followup
<vila> jam: I won't be able to land it until later today anyway, so no urgency
<vila> poolie, jelmer: Hi !
<jelmer> vila: hey!
<jml> If I start using loom to work on a project, am I going to regret it?
<jelmer> jml: there is no trap door - you can always go back (and just have your loom flattened) if you need to, in the future
<jml> jelmer: that's good to know.
<jelmer> jml: that said, looms need quite a bit more polish to be really usable IMHO
 * jml nods
<jml> I thought you guys were doing that as part of UDD
<jelmer> jml: we are, but that's long term - short term we're looking at having merge just handle quilts more sanely than it does at the moment
<jml> jelmer: ok. thanks.
<poolie> hi guys
<poolie> udd meeting in 5m
<poolie> Riddell, jam, #ubuntu-meeting?
<awilkins> I rather liked the look of Mercurial pbranches
<awilkins> I wanted to port it to bzr at one point but never got far enough to refactor it into the abstract and implementation-specific bits
<poolie> jam, that's great
<poolie> i think you could make the text a bit more clear
<poolie> "branch not up to date" might confuse people with eg the tree just being out of date
<poolie> so say something about ti being an ubuntu package branch
<jam> poolie: I'd certainly like some discussion about polish/wording/when-it-should-trigger/etc
<jam> but I think getting something is a good first step.
<poolie> it absolutely is, that's great to see
<poolie> thanks for pushing it through
<poolie> good night
<dobey> who is best to discuss branch locking issues with?
<dobey> what's the best way to copy the history for a specific file, from one branch to another, when copying that file to another branch?
<dobey> or can i do that?
<fullermd> As described, no.
<fullermd> Files don't have history.  History has files.
<dobey> i guess i'll just lose the history, since i guess doing it right is probably infinitely hard
<fullermd> There are ways to copy the file-id, so at least the files would be associated if the branches were ever merged, but...
<dobey> well the two branches wouldn't be merged, as they'd have different ancestors
<abentley> jam: The fixup_new_roots change is a regression, but a pretty minor one, so I didn't want to bother with the 2.4 series.  The test change is just a waste of CPU time and lines of code.
<dobey> abentley: hey. do you know much about locking in branches?
<abentley> dobey: sure.  What would you like to know?
<dobey> abentley: i'm fixing an issue in tarmac, and was wondering if there's a sane way to avoid having to unlock/lock all the time, when wanting to do some specific actions in bzrlib.
<dobey> abentley: the issue is that in certain cases, tarmac when run under cron, can end up being run multiple times simultaneously, and as tarmac itself isn't doing any specific locking in general, you can end up with two processes competing over the same branch
<dobey> abentley: so i started a branch to add locking, but it seems i can't just do a lock_write() once, and then unlock() at the end, unfortunately
<abentley> dobey: if you're doing locking, you need to lock at the beginning and unlock at the end.  Why can't you?
<dobey> abentley: i can't lock at the beginning, and then do branch.merge() or branch.commit() as they seem to try acquiring locks independently
<abentley> dobey: Read locks are internal to bzrlib, but write locks will live on after the process ends.
<dobey> so i have to unlock, then lock again, before/after the merge/commit
<dobey> and then finally unlock at the end
<abentley> dobey: If the branch is locked, taking another lock is fine.
<dobey> i was also wondering why there is only one unlock()
<dobey> abentley: i was getting errors about lock existing already
<abentley> dobey: bzr tracks the number and kind of locks taken.
<dobey> maybe it's due to the way tarmac is using bzrlib or something?
<abentley> dobey: It sounds like maybe you have two instances of the branch.
<dobey> abentley: it is a working tree only
<abentley> dobey: I'm not sure what you mean.  You're using working trees, not branches?  Fine, but each working tree is associated with a branch.
<dobey> abentley: a lightweight checkout
<abentley> dobey: Yes, a lightweight checkout is still associated with a branch.
<dobey> is what i meant. forgot the term
<dobey> right
<dobey> does that affect the locking though?
<dobey> that it's a lightweight checkout vs a full branch w/ history?
<abentley> dobey: A lightweight checkout behaves like a non-lightweight tree in almost every way.
<abentley> dobey: Can I see the traceback you were getting from commit?
<dobey> abentley: http://pastebin.ubuntu.com/643514/
<dobey> actually, in the test, i think that might be a full branch
<dobey> so that would throw the lightweight theory out the window :)(
<abentley> dobey: looking...
<abentley> dobey: the Branch class looks very suspicious.  It takes a branch as input, but commits to a working tree later.  Creating that working tree will create a new instance of the branch.
<abentley> dobey: I recommend retrieving the tree immediately, instead of in create_tree.
<dobey> hmm, ok; that makes some sense. thanks
<abentley> dobey: then you can use tree.branch.  Locking the tree will also lock the branch, and you'll be locking the right instance of both.
<dobey> right. i'll see if i can rearchitect it without breaking stuff. thanks :)
<abentley> dobey: np
<poolie_> hi all
<poolie_> hi spiv?
<poolie_> hi abentley
<spiv> Good morning poolie
<poolie_> hey there
<poolie_> did you see your lp branch failed?
<poolie_> are you ok to dig into it
<spiv> I did, all in JS tests
<poolie_> probably some not-yet-updated dependency
<spiv> Which is completely unrelated to my patch, so presumably spurious
<poolie_> let me know if you want me to re-fire it
<spiv> Yeah, it looks like that.
<spiv> They were all ImportError: No module named html5browser
#bzr 2011-07-14
<poolie_> spiv so shall i just retry? you're not hitting this locally?
<spiv> poolie_: I haven't tried locally, but it's totally unrelated to what that patch touches.
<spiv> It looks like some sort of dependency issue in the test environment.
 * poolie burns more coal
<AfC> I prefer burning midnight oil, myself.
<poolie> hi afc
<poolie> i started a new ec2 instance
<poolie> i wonder what actually ultimately fuels them
<lifeless> poolie: spiv: james would like the importer shutdown to -> lucid for you
<spiv> Sounds like a good thing.
<poolie> underway now
<poolie> maxb^
<poolie> spiv, are you busy?
<poolie> could you have a look at fixing the ppa daily build failures
<poolie> eg https://launchpadlibrarian.net/75172413/buildlog_ubuntu-maverick-amd64.bzr_2.4.0~beta5-0~bazaar1~maverick1_FAILEDTOBUILD.txt.gz
<poolie> some shallow problem with meliae it seems
<spiv> Hmm.
<spiv> At a glance it looks like the meliae package is broken on amd64?
<poolie> yes it does
<poolie> package importer is not running jobs atm, i'm working on it
<abentley> poolie: hi.
<Kamping_Kaiser> http://paste.debian.net/122834/
<Kamping_Kaiser> hm, my text went missing
<Kamping_Kaiser> does bzr-buildpackage require tags in the repo before it will build? paste above has it failing to find debian/chagnelog
<poolie> Kamping_Kaiser: it might require it's versioned in the same tree
<poolie> what does 'bzr st debian/changelog' show?
<Kamping_Kaiser> poolie: nothing returns
<poolie_> what was the context?
<Kamping_Kaiser> i have a bunch of <package>/debian/ dirs in a bzr brfanch (Standalone tree (format: 2a)). if i try and dpkg-buildpackage any of them it returns that error
<Kamping_Kaiser> it occrus to me that it might be disliking having all packages in one branch?
<poolie_> it could well do
<poolie_> that is not a typical setup
<poolie_> probably at least arguably a bug
<spiv> Kamping_Kaiser: so $(bzr root)/debian/changelog doesn't exist?  That sounds likely.
<Kamping_Kaiser> spiv: no it doens't.
<Kamping_Kaiser> (doesnt exist)
<Kamping_Kaiser> it would be nice if the error could be a little more verbose, and or br-builddeb had an option to use $PWD/debian. do either of those seem like valid bugs to you?
<poolie_> if an error's confusing i'd say that's almost always a bug
<poolie_> the second is perhaps worth filing
<poolie_> i think it has a pretty strong opinion of one branch per source package so i'm not sure if it's likely to be fixed
<Kamping_Kaiser> ok. i'll file them and see what returns
<Kamping_Kaiser> thanks both :)
<poolie> which packages are they for curiousity?
<poolie> something of your own?
<arnetheduck> jelmer, hi, I spoke the other day to poolie and jam who let on that you might be able to give me some pointers regarding bzr-rewrite?
<vila> hi all, despite today a national holiday, I didn't feel like putting heads on pikes (death penalty have been abolished for good reasons) so I'll be around instead ;)
<vila> s//being/
<fullermd> Aw, man.
 * fullermd reluctantly puts his pike away.
<vila> fullermd: there are better ways these days :)
<vila> http://www.internetevolution.com/video.asp?section_id=1361&doc_id=207380 comes to mind...
<fullermd> Better, maybe, but not as much fun.
<fullermd> Oh, ew.  You want to put heads on Flash?!
<fullermd> That's disgusting.
<vila> Some want to put flash on pikes, is it better ? ;)
<fullermd> See, that would be a holiday worth celebrating   :p
<poolie_> hi vila
<poolie_> hi fullermd
<poolie_> vila, i wonder if i should shut down the importer until lp is back up
<poolie_> in fact i think i will
<jam> poolie_: good idea
<poolie_> hi jam
<Riddell> hola
<poolie_> hi there
<maxb> poolie_: rather than shutting it down, just echoing 0 to max_threads works too, and is a bit easier to undo later
<maxb> jam: btw, do you know you have a copy of the udd scripts owned by jameinel, not pkg_import, in /srv/package-import.canonical.com/new/test-scripts/ ?
<maxb> vila: I noticed that your latest change to /etc/init.d/mass-import hasn't been deployed yet - I suppose you'll need to RT it or grab a LOSA informally
<maxb> (?)
<maxb> and morning all :-)
<jelmer> arnetheduck: hi
<poolie_> hi jelmer
<poolie_> maxb how 'easier to undo'?
<maxb> Well, mass-import isn't running right now, yes?
<maxb> And starting it either requires a LOSA, or a bit of creative tweaking
<poolie_> i think i can just start it?
<poolie_> just running that as pkg_import seems to work
<maxb> oh
<maxb> I didn't count on start-stop-daemon being that clever
<jelmer> 'morning maxb, poolie
<poolie_> i just added documentation saying this :)
<maxb> vila invoked a losa last time we needed to restart mass-import. I assumed from the way the init script was written that it wouldn't run as non-root
<poolie_> it is a bit unusually
<maxb> spiv: Any news on append-revisions-only?
<jam> yay, lp is back up
<jam> of course, it forgot who I was again
<poolie_> again?
<poolie_> vila, you fell off
<maxb> ooh
<maxb> so as a side effect of going lucid, we've also moved to bzr 2.4b4
<maxb> and a sane version of launchpadlib too
<maxb> jelmer: How would you feel about the daily-ppa bzr build having the python-dbg support removed? It's looking challenging to support back to lucid
<jelmer> hmm
<jelmer> maxb: I'd like to stay as close as possible to the official packaging to be able to catch problems
<jelmer> perhaps we can split the recipe and have a separate branch that removes the -dbg package for <= lucid ?
<maxb> well
<maxb> It's problematic for maverick too
<maxb> Although there only because there's no meliae-dbg, and the testsuite feature doesn't skip the meliae tests on the debug interpreter
<poolie_> maxb, so does everything seem to be working ok?
<poolie_> i'm going to head out in a bit
<vila> poolie, maxb: I don't remember the details but at some point not running as root was a no-go, may be things have been fixed since then ?
<poolie_> spiv, your patch landed
<poolie_> vila huh?
<vila> poolie: we're talking about mass-import on jubany right ?
<poolie_> yes
<poolie_> starting it not as root seems to work
<vila> great. That wasn't the case in the past
<vila> how did you launch it ? /etc/init.d/mass-import start or using mass_import.py directly ?
<vila> lucid ? jubanu runs lucid ? Since when ? New hardware too or just upgrade ?
<arnetheduck> jelmer, hi, I'm considering writing a plugin that replays a complete branch history while applying a script to the working tree for each commit - in other words I want to end up with the same sequence of commits including all commit properties and merges, but with different file data (depending on the script)...I was wondering if any parts of the bzr-rewrite plugin might help with this?
<vila> jam: seen my last comments about the 2.3.4 blocking bug ? I agree with you, just wanted to make sure you're ok with landing the patch as is and addressing the larger issues in a followup
<jelmer> maxb: We could use the same branch for lucid and maverick
<jelmer> maxb: maybe just with a bzr-daily and a bzr-daily-pre-natty recipe?
<jelmer> arnetheduck: hi
<jelmer> arnetheduck: You might be able to reuse some bits from the current bzr-rewrite, or at least get some inspiration from there.
<jelmer> arnetheduck: the current code is a bit more complex than it needs to be though
<vila> jam: ping
<arnetheduck> jelmer: heh, indeed, I had a quick look but nothing obvious came up on the first perusal so asking seemed like a better idea =)
<jml> jelmer: you were saying that there are long-term plans to polish loom. do you know of any detail attached to those plans?
<jml> poolie: ^
<jelmer> jml: everybody seems to agree we want to make looms rock, that having them better supported in core would be nice, and that they would be an awesome way to represent quilts in debian packages
<jelmer> but as far as I know there are only vague plans at this point
<jml> right. no specs for exactly what 'rock' means here, for example
<vila> jml: 'rock' should include the ability to share looms, including merging them
<jml> vila: agreed. but I guess I meant a list of things somewhere other than random IRC comments :0
<spiv> jml: bugs.launchpad.net/bzr-loom, I guess ;)
<jml> yeah yeah
<jml> because everyone knows that the full list of bugs is all you ever need to do focused work
<jml> spiv: wait till you see my specs for making Launchpad rock!
<maxb> Uhoh. The UDD importer seems to have lost the ability to write to debian branches.
<maxb> binged flacoste on #launchpad to fix
<jam> maxb: sounds like poolie's change to change credentials to the pkg_import robot
<maxb> yes
<vila> jam: ping
<jam> hey vila
<jam> sorry about the delay
<jam> for some reason IRC isn't actually making noise for me
<jam> I have the "beep when someone says your name" checked... :(
<vila> jam: np ;) As long as we meet in the end :)
<vila> :-/
<vila> I hate it when it stopped working for me
<vila> stops even
<vila> anyway
<vila> so, about bug #786980, I'd like to double-check you're ok to land the patch as is and handle the other issues in a follow-up
<ubot5> Launchpad bug 786980 in Bazaar 2.3 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,In progress] https://launchpad.net/bugs/786980
<vila> jam: I've added some comments to the review since your last one
<jam> reading now
<vila> thanks
<jam> vila: I think we talked past eachother a bit. I asked for more tests, and you said "I agree with that but I don't think the stable branch is the place to add more fixes"
<jam> I don't actually think we have more bugs in edge cases
<jam> just lack of test coverage.
<vila> ha
<jam> And if we *have* bugs, then we should be fixing them on the stable branch anywaay
<vila> hmm
<jam> and the 'update' thing is because I didn't realize you had extra commits on master branch
<jam> it is a bit hard to make that clear in tests, unfortunately.
<vila> well, I think we have more bugs, including storing url-encoded urls in the config files
<vila> so yeah, we weren't talking about the same things
<jam> I think they *should* be stored url encoded...
<vila> why ?
<jam> because URLs aren't UTF-8 strings
<jam> and 7-bit URLs fit just fine in a UTF-8 file.
<vila> but the config files are
<vila> and we get their content as unicode...
<vila> and I'm concerned about what people will put there
<vila> even if in this case bzr itself is storing them, a user can still edit them
<vila> but I don't feel like fixing this kind of bug in 2.3
<jam> vila: interpreting parts of a URL that we don't control is dangerous
<vila> exactly
<jam> as anyone can put their repo at "http://host/latin-1/repo/.bzr"
<jam> so trying to decode "latin-1" can fail
<jam> so it should stay encoded (as the user gave it to us)
<jam> and we shouldn't try to fake that we understand it
<vila> that's the point
<vila> users are likely to give them in their own encoding from the command-line (whereas internally bzr will attempt to store them as... well, I'm not entirely sure but probably url-encoded
<vila> (reading log: "'update' thing is because I didn't realize you had extra commits", ha good, thanks for confirming)
<jam> vila: URLs don't have the 8th bit set. psuedo-URLs might
<jam> we should be storing URLs
<jam> yes they come out of the config system as ascii
<jam> sory
<jam> as unicode
<jam> but we can safely '.encode(ascii)' them
<vila> hmm
<vila> yeah, that avoids the issue but url-encoded is not user-friendly
<vila> and whatever we chose, another bug is that we should raise a user error if we can't properly decide an url in a config file
<vila> s/decide/decode/
<vila> so this kind of problems (how do we store/retrieve URLs from config files) has ramifications far beyond this proposal which makes me a bit uncomfortable
<jam> vila: ATM, you can't supply a non-URL-encoded URL
<jam> you can supply a Unicode (ish) local path
<vila> you can, just edit the config file
<jam> we can consider that illegal, you can't pass them on the command line
<jam> I think overhauling this is *way* outside a stable release
<vila> ha good
<jam> certainly
<jam> but that was never what I asked for
<jam> I was asking for tests covering stuff like "~user"
<vila> right, but I couldn't understand where your drew the line
<jam> "valid URL" should match "valid URL"
<vila> but ~user *is* a non-URL-encoded URL
<jam> no, ~user is valid, IIRC
<jam> I'll check
<vila> well, +branch definitely isn't valid
<vila> but I need to check too :)
<jam> http://www.ietf.org/rfc/rfc1738.txt
<vila> yup, exact same link :)
<jam> says "~" is unsafe and "must always be encoded within a URL"
<maxb> jam: That's a very ancient RFC
<maxb> The more modern ones all agree that unencoded ~ is right and proper
<vila> maxb: urls ?
<vila> http://tools.ietf.org/html/rfc3986 ?
<lifeless> ttp://www.ietf.org/rfc/rfc3986.txt
<spiv> jam: see 2.3 and 2.4 of http://www.ietf.org/rfc/rfc3986.txt
<lifeless>       unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
<maxb> vila: Use the htmlified rfc browser at http://tools.ietf.org/html/rfc1738 - and click through to the obsoleted by
<maxb> hm, well that would work if the things in the obsoleted by field actually made sense
<vila> maxb: yeah, thanks, they kind of make sense if you include Updated by
<jam> and even then, it doesn't describe *what* is obsoleted by what
<vila> hehe, that's the nice part of dealing with RFCs :)
<vila> wow, so http://tools.ietf.org/html/rfc3986 has a red warning 'Errata Exist' but they aren't applied to the displayed text :-/
<jam> vila: anyway, you can land it, I'd like a bit more tests, but we ca ndo that on trunk if you feel strongly.
<vila> jam: ok thanks, I think this fix is enough to unblock the SRU which is my main target here
<vila> there is still uncertainity in this area which would be nice to address so I'll see what adding tests reveal (or not) and see from there whether it's ok to add them to trunk or whether I encounter other bugs (that I could then file)
<vila> jam: what stays unclear for me is how I should write such tests: specifically how do I introduce a distortion between what bzr stores and what is later retrieved...
<vila> jam: do you have an idea about why/when bould_location lost its final slash ?
<jam> vila: I haven't seen anything specifically that indicates we dropped the final slash.
<jam> We've been pretty good about Transport.base always having a trailing slash.
<vila> right, but the bug reports were about people lacking the final slash in their config files
<vila> a previous fix has activated the code path where we compare the urls, but it works ok if the branch is created from scratch
<vila> so the url present in the bug reporters config files has been created earlier at a point where there wasn't a final slash
<vila> and yes, transport._base should always have one (AFAICS)
<vila> revno for bzr-2.3.4 ? 5656 :D
<vila> And to be clear: 2.3.4 has gone gold, tarball uploaded on launchpad, email sent to ML, so: installers/packages needed ! ;)
<maxb> hrm I haven't finished 2.4b5 yet :-/
<maxb> (complications with sid changes to the packaging)
<fullermd> Shucks, another boring lplibrarian number.  No fun at all...
<SpamapS> Trying to use bzr-builder and I think I'm missing something..
<SpamapS> http://paste.ubuntu.com/644279/
<SpamapS> It doesn't seem to modify debian/changelog after 'bzr build recipe foo' .. foo/debian/changelog is identical to the one from the nest-part that I did.
<jelmer> SpamapS: I think you want "bzr dailydeb"
<jelmer> bzr build doesn't use deb-version AFAIK
<SpamapS> Hmm ok I thought bzr build would allow me to inspect and build it
<jelmer> SpamapS: bzr dailydeb only creates a source package IIUC
<SpamapS> ahh --no-build is what I want
<SpamapS> no dailydeb builds by default as it failed for me.
<SpamapS> jelmer: I see the point though, build just squishes the pieces together, whereas dailydeb does something with them.
<SpamapS> jelmer: cool.. the recipe actually works fine. :)
<SpamapS> jelmer: thanks for the reassurance. :)
<vila> fullermd: you should file a bug, I'm sure there is a way to fix it by creating a bzr lp-xxx command to get the right url
<vila> fullermd: or is requiring *a* bzr to do that a no-go ?
 * jelmer waves to vila
<fullermd> vila: ??  ECONTEXT...
<vila> fullermd: "another boring lplibrarian number"
<jelmer> vila: how's RMLL?
<vila> fullermd: Isn't the issue related to a url that you can't reliably use ?
<fullermd> What would a lp-xxx command have to do with that?  I mean, you don't upload the tarballs via bzr, right?  So it's not like you could pick an unboring one there...
<fullermd> Oh, it's not an "issue".  Just boring is all.  "75242790" is just no fun at all.
<vila> fullermd: http://launchpad.net/bzr/2.3/2.3.4/+download/bzr-2.3.4.tar.gz
<vila> fullermd: why don't you use that ?
<vila> fullermd: just to refresh my memory
<fullermd> Because ports exlicitly doesn't follow redirects, so I have to resolve through to the lplibrarian URL to put into the Makefile.
<vila> "exlicitly doesn't follow redirects" ?? What's the rationale ?
<fullermd> I think one major one was to avoid user confusion in the face of "friendly" servers that 302 to a "gee, I dunno what you were looking for" page instead of just 404'ing or the like.
<fullermd> (and thus winding up with a ".tar.gz" that contains 15k of HTML, and mysteriously fails the checksum tests, etc)
<vila> hmm and no config option to disable that ?
<vila> There aren't that many evil sites (bogus redirects) and tarball are not hosted there ? Aren't they ? ;)
<fullermd> Oh, I could big-hammer it in various ways.  Overwrite the fetch(1) args, say.  But there'd have to be a lot more compelling reason than "save me typing a command and C&P'ing a big number every month or two".
<fullermd> Enough that I remember it having come up at some point in the distant past.
<vila> Oh right, so you were Shuck'ing here so I know I could mention the BSD port in the official announcement
 * vila furiously takes notes to *not* forget
<fullermd> :p
<fullermd> I was just hoping for a palindrome or a perfect number or something...   shine a little light into my day.
<vila> mgz: I just setup an oneiric chroot on babune : http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastFailedBuild/
<vila> mgz: I'm pretty sure I read some emails were you talked about a fix
<mgz> I thought oneiric was the one with the broken python?
<vila> yup, that's it, I follow the mails to the python site
<vila> followed
<mgz> ah, it is. but... I'm suprised selftest runs at all.
<vila> have a look :)
<vila> only 43 identical failures, so your fix should be enough
<vila> what I didn't remember is if/when python will be fixed on oneiric
<vila> I don't remember, grr
<mgz> I can hack around in bzr if we need to, did I understand correctly that it had some non-release version of python 2.7 though?
<vila> who ? oneiric ?
<mgz> yeah.
<vila> no idea
<vila> jelmer runs oneiric
<vila> ha wait, stoopid
<jelmer> I can reproduce the issue on oneiric, fwiw
<mgz> jelmer: `python -V`?
<vila> jel... :)
<jelmer> Python 2.7.2+
<jelmer> not much help :)
<mgz> the '+' is what I thought.
<jelmer> it's a upstream snapshot from 20110709 apparently
<mgz> so, they built some version from hg rather than tarball.
<jelmer> yep
<mgz> so, what I don't know is how long that funky version is planning on lingering around. if they are going to update python, there's not much point working around in bzr a problem that existed for two weeks on python trunk.
<mgz> but it's not hard to do, so I can propose a change if that helps anyone out.
<vila> mgz: let's wait a bit
<vila> or rather, let see who we can poke to know if/when the oneiric python will be fixed
<vila> jelmer, maxb: any idea ?
<vila> mgz: do you have the url for the python bug ?
<mgz> <http://bugs.python.org/issue12544>
<vila> excellent, thanks
<mgz> my heat hurts from writing javascript all day.
<mgz> I am going to get some coffee and see if that helps.
<lifeless> mgz: heat eh?
<mgz> curly braces, I think.
<vila> curly braces turns heads into heat ?
<vila> like, burning them ?
<vila> Should be a cultural thing... we used to put them on pikes around couple of centuries ago
<fullermd> Far more civilized to use barracudas.
<vila> not according to the barracudas...
<vila> jelmer: already fixing bug #810701 ?
<ubot5> Launchpad bug 810701 in Bazaar "i18n.install fails in fails some situations" [High,In progress] https://launchpad.net/bugs/810701
<jelmer> vila: yep
<jelmer> and simplifying some of the i18n code in the process
<vila> if lang is not None in i18n.py should be enough
<vila> ha great
<mgz> I think I saw another report of that
<mgz> don't know if it was a bug entry though
<mgz> ah, mailing list.
<mgz> https://lists.ubuntu.com/archives/bazaar/2011q3/073189.html
<vila> mgz: thanks for the heads-up, replying
<vila> ooooh, fireworks time ! I forgot :)
<jelmer> vila: huh, what's the occasion?
<mgz> wait, it's november?
<mgz> what happened to the summer ;_;
<vila> we put heads on pikes, dance in the street and so on
<vila> celebrating freedom and getting rid of tyrans
<vila> hmm
<mgz> I think celebrating actually blowing something up is just wrong, you need to celebrate nearly but not quite blowing something up.
<vila> may be we need to do it again instead of celebrating it ;)
<fullermd> What, celebrate failure?  That's not for another 8 days.
 * fullermd points at the obligatory http://www.qwantz.com/index.php?comic=955
<vila> wow, my own Juliet is born on the Pi approximation day ! And I didn't notice earlier...
<smoser> hey...
<smoser> i'm trying to do a daily build
<smoser> and having some trouble
<fullermd> vila: I think that makes you a bad father.  Or a bad mathematician, maybe.  One or the other.
<smoser> http://paste.ubuntu.com/644352/
<smoser> i have 2 issues initially
<smoser> a.) i can't get '{debupstream}' to work
<smoser> Committed revision 453.
<smoser> bzr: ERROR: Invalid deb-version: {debupstream}+452+5: Invalid version string '{debupstream}+452+5'
<smoser> then, if i just say "forget that"
<smoser> b.) if I have '1.3.1-0ubuntu11' in the version, then it insists that the euca2ools branch have a 'upstream-1.3.1' tag in it
<jelmer> smoser: you can prevent b) by passing --allow-fallback-to-native
<jelmer> a) is probably bug 801618
<ubot5> Launchpad bug 801618 in bzr-builder "{debupstream} no longer looks at non-base branches for debian/changelog" [Critical,In progress] https://launchpad.net/bugs/801618
<james_w> hi jelmer
<jelmer> hey James
<james_w> have you seen bug 809412?
<ubot5> Launchpad bug 809412 in bzr-builder "{debupstream} isn't working in a local recipe" [Undecided,New] https://launchpad.net/bugs/809412
<smoser> so given those two things, how is it iexpected that soeone would build an upstream branch ?
<smoser> i think i might be hitting that.
<jelmer> james_w: I hadn't yet, it's a dupe of 801618
<james_w> jelmer, I wasn't sure, as he uses {debupstream:packaging}
<jelmer> james_w: oh, I hadn't seen that yet
<jelmer> smoser: Either add a upstream-FOO tag or specify --allow-fallback-to-native if you're ok with building a native package
<jelmer> smoser: The debupstream is the top item on my todo list (just got back from leave) and should be resolved soon.
<smoser> well 2 things sucks about tag.
<smoser> a.) i can't tag lp:euca2ools (no write access there)
<smoser> b.) there isn't actually even a tag that would make sense... their bzr branch and releases were not tied together.
<jelmer> smoser: --allow-fallback-to-native makes the most sense in that case then, I guess
<smoser> i guess the only option is allow fallback to native, which is fine , i just want something for now.
<smoser> how do i add that to the recipe?
<jelmer> it's specified on the command-line to "bzr dailydeb"
<smoser> and, would there be some other way to utilize the fact that lp:ubuntu/euca2ools *does* have a sane upstream-1.3.1 tag ?
<smoser> jelmer, right, but i want to push that to launchpad
<jelmer> smoser: launchpad runs an older version of bzr-builder that implicitly uses --allow-fallback-to-native
<smoser> :)
<jelmer> smoser: can you file a bug about looking for upstream-FOO tags in other branches?
<smoser> sure
<smoser> and we think that the {debupsream} would work ther ealso ?
<jelmer> yeah, the {debupstream} bug is not present in the bzr-builder on launchpad
<smoser> so if i hadnt' tried to test this locally i'd have a couple hours of my life back
<smoser> :)
<jelmer> (it's actually what's preventing the deployment of the new bzr-builder to launchpad)
<jelmer> smoser: sorry about that :-/
<smoser> well that will teach me to try to test something before pushing
<smoser> thanks for your help, though, jelmer
<smoser> jelmer, bug 810740
<ubot5> Launchpad bug 810740 in bzr-builder (Ubuntu) "support obtaining tag upstream-VERSION from other repository" [Undecided,New] https://launchpad.net/bugs/810740
<jelmer> smoser: thanks!
<smoser> you could probably add more context there.
<smoser> i'm not really sure i knwo what i'm talking about or explained myself clearly
<jelmer> smoser: I think that's a pretty good explanation of it
<poolie_> hi all
<mgz> hey poolie!
<poolie_> hey mgz
<poolie_> how are you?
<poolie_> did you get anywhere with my test-errors branch with the unicode failures?
<poolie_> otherwise i might try to finish it today
<mgz> only as far as tracking down the failures, I did mean to have a look at which changes need making
<mgz> but have been buried in curly braces
<mgz> I'm a little scared of what bad habits I'll have picked up when I get back to python.
<vila> poolie: hey !
<vila> definitely bed time for me :)
<marienz> I spent some time in a c codebase that did "func (args);" (notice the space), and then I started doing that in python :(
<poolie_> hi there
<poolie_> doesn't that work?
<mgz> night vila!
<marienz> what, that space? it does, but it looks really weird
<mgz> heh, yep, doing `if(a > b):` is another thing I've seen refugees from less kind languages fall into
<lifeless> marienz: its common practice in many C codebases
<marienz> I actually went from "if(a > b) { ... }" to "if (a > b) { ... }" in curly braces code after being exposed to python
<marienz> lifeless: yeah, but it's not all that usual in python code, and my fingers started writing that way after spending slightly too much time in c
<poolie_> i hate "if(foo)" in C
<poolie_> it makes it look like [the person thinks] it is a higher-order function
<marienz> I used to do that but python helped me get over it :)
<poolie_> and it's not
<poolie_> sadly
<maxb> hi poolie_ - so, turns out jubany is still using a james-w launchpadlib token
<poolie_> ah
<poolie_> yes, probably
<poolie_> is that actually breaking it or just an incomplete fix for the bug
<maxb> I'm guessing you might be the person with ~package-import's password?
<poolie_> either way, i will deal with it
<poolie_> i do
<poolie_> hm i should probably share that
<maxb> It temporarily broke stuff, but I asked and got james-w readded to ~launchpad-debian-maintainers to fix
<poolie_> that was silly
<maxb> p-i wasn't a member of ~ubuntu-branches either, bit I found a friendly techboard member to sort that
<maxb> *but
#bzr 2011-07-15
<poolie_> hi spiv
<spiv> Morning poolie.
<poolie_> hi there
<poolie_> your lp haproxy change landed
<poolie_> i don't know if you need to qa it or something
<jam> morning all
<vila> morning jam et al.
<poolie_> hi jam
<jam> vila: can you try to message me again, I might have gotten ping to work
<vila> jam: pingeling
<vila> jam: so, does it work ?
<poolie_> hi jam, vila
<AfC> Is there a newer CIA client than http://samba.org/~jelmer/bzr/cia_bzr.py ? I'm quite impressed with the notifications coming into #gnome-shell from a CIA bot.
<Riddell> good morning Bazaar
<vila> _o/
<jam> no, it doesn't work
<jam> hi Riddell
<jam> vila: it doesn't highlight lines with my name in them, either
<jam> it apparently doesn't think my username is actually my username
<vila> what a pity
<jam-other> jam-other: test
<jam-other> vila:  try with a different name
<vila> jam-other: like that ?
<jam-other> yeah, doesn't work either
<jam-other> try "jam1"
<jam-other> yep
<jam-other> it still thinks that is my name... ugh
<vila> jam1: you mean *this* works ?
<jam-other> when I logged in a long time ago, it had to fall back to that
<jam-other> vila: yep
<vila> hmm, nice bug
<jam-other> and it doesn't seem to be following "/nick"
<jam-other> I'm going to log back in
<jam-other> brb
<jam> ok, I think it is working now
<jam> hopefully I don't lose my name again
<vila> jam: pingeling
<jam> vila: got it
<vila> jam: regarding bug #786980,
<ubot5> Launchpad bug 786980 in Bazaar "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,In progress] https://launchpad.net/bugs/786980
<jam> yessir
<jam> vila: ??
<vila> jam: an interesting point is that the code involved is only triggered if bound_location is an url that will lead to the right branch
<vila> i.e. only small variations can trigger it (including the missing final slash)
<vila> so I've added tests for + and ~ but we already have coverage for urls that differs in a way that get_transport will point to a different branch (or no branch at all)
<vila> I'm merging 2.3 to 2.4 to trunk right now and will make my proposal when lp:bzr is up-to-date
<jam> vila: so you're saying we have coverage if URL mangling would cause us to not find the path?
<vila> yeah, because get_master_branch is called higher in the stack
<vila> so bound_location errors are also caught before we reach this code
<jam> sure, but %7E stuff will still open the right branch
<vila> it also explains why we didn't get more bug reports, the window is pretty small
<vila> jam: yup, hence the added tests
<vila> jam: but even %7E requires a manual user intervention
<jam> vila: we used to put one way into config files
<jam> and then changed which one we saved
<vila> jam: indeed
<jam> That may not be what is happening here
<vila> so the fix should cope with that
<jam> but *this* case could be that we used to keep the path read from the config file as Transport.base
<jam> and we started normalizing the path, etc.
<vila> oh, yeah, sorry isunderstanding
<vila> jam: yes, that may be the explanation, .base is now normalized so we shouldn't run into it anymore
<vila> s/that may be/that *is*/ but I don't feel like validating that by searching the history for the relevant change
<vila> maxb: is there some special stuff going on currently on jubany ?
<maxb> Not that I'm aware of
<vila> mac_threads == 1 seems... wird
<vila> weird
<vila> ghaa
<vila> maxb: any objection about setting it to 8 again ?
<maxb> hrm
<maxb> I wonder why it's set to 1
<vila> hehe, me too, hence my question
<maxb> Regardless, we should set it back to 8 since no reason not to has been advertised
<vila> http://webnumbr.com/ubuntu-package-importer-conccurrency
<vila> done
<vila> maxb: once the queue is down again, I'll retry enigmail and similar (NoFinalPath)
<maxb> Ah, when did your fix land?
<vila> hehe, when 2.4b4 did (or am I confused ?)
<maxb> great
<maxb> by the way, since we moved to 2.4b4, a number of packages seem to have started failing with BzrCheckError
<vila> ha crap, my fix is not included in 2.4b4 :-/
<vila> maxb: I didn't follow who/what/when/why the upgrade was done, could we ask for 2.4b5 with good changes of success ?
<maxb> The upgrade occurred as a side effect of jubany hardy->lucid
<maxb> To get 2.4b5, we should speak to jelmer since he did the lucid-cat upload for 2.4b4
<vila> ooooh, I see, so that's probably a side-effect of lp itself upgrading to 2.4b4
<vila> jelmer: ^
<spiv> What was the bzr version before the lucid upgrade?
<spiv> If it's https://bugs.launchpad.net/udd/+bug/806348, it may be that we now have a bzr version that fetches tags by default, which AFAICT is more likely to hit the corner case that triggers that error.
<ubot5> Ubuntu bug 806348 in Ubuntu Distributed Development "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [High,In progress]
<spiv> Anyway, I'm battling a cold today so I should probably log off.
<maxb> spiv: Before you go...
<maxb> Would you be ok with me doing the appendrevisionsonly udd rollback?
<maxb> I think the tag fetching is indeed the issue
<jelmer> hi vila, maxb
<jelmer> it's a side-effect of the builders almost upgrading to 2.4b4
<jelmer> (Launchpad has its own bzr copy, the builders use the bzr from lucid-cat)
<vila> ha, thanks for confirming
<vila> jelmer: so how about 2.4b5 ? :D
<jelmer> vila: Happy to backport 2.4b5 as well, though I'd prefer to get it into oneiric first
<vila> jelmer: fair enough
<vila> jelmer: just let me know when it's deployed on jubany so I can retry the affected packages
<jelmer> vila: ok
<maxb> jam: Thanks for proxying that RT for me :-)      By the way, do you need /srv/package-import.canonical.com/new/test-scripts/ any more? (I tried to mv it into probably_obsolete, but it's owned by jameinel not pkg_import, so I couldn't)
<jam> don't you have sudo rights?
<jam> anyway, not specifically
<maxb> I can sudo to pkg_import, but the file ownership is such that only jameinel or root can move it
<jam> removed
<maxb> Thanks.
<spiv> maxb: go ahead
<maxb> acknowledged
 * jelmer -> doctor, back in ~1.5 hrs
<vila> jam: https://code.launchpad.net/~vila/bzr/786980-url-aliases/+merge/68069 is up for review
<jam> vila: approved
<vila> \o/
<vila> jam: thanks ;)
<vila> jelmer: what did the doctor say ?
<jelmer> vila: Salut!
<jelmer> vila: she took most of the stitches out :)
<vila> \o/
<vila> (added bonus for 'she', they are more careful ;)
<fullermd> Careful?  Nah, you just gotta do it quick.  You grab one stick with a pair of pliers, see, and...
 * maxb unsubscribed ~bzr-core from lp:bzr/2.4 and subscribed ~bzr-codereview-subscribers instead
 * jelmer waves to maxb
 * vila fixes the wiki page used by the losas to create the 2.4 branch so in 6 months maxb won't have to tweak the subscriptions again
<maxb> It seems immensely silly that we need LOSAs for this
<vila> maxb: DRY :D
<jelmer> maxb: at least it's every 6 months now rather than every month..
<poolie_> lifeless, in theory of course we can detect someone else has started doing the replacemen
<poolie_> in practice there are quite a few different possible traces
<poolie_> maybe we should have initialize(threaded=True)
<lifeless> poolie_: that sounds like a possible compromise
<lifeless> poolie_: my concerns about single-threaded overhead are perhaps unwarranted
<lifeless> poolie_: changing it and testing should be pretty straight forward
<poolie_> by booting loggerhead and running several clients?
<lifeless> 'bzr st' or similar
<lifeless> I meant assessing the impact of a simple mutex solution
<poolie_> right
#bzr 2011-07-16
<terrycojones> does bzrlib.commands.Option let me have a command line option (e.g., --verbose) that results in a bool that's set according to whether --verbose is present on the command line or not?
<Kamping_Kaiser> bzr dh-make --v3 appears to fail creating the debian/source/format file. is there a way i can 'resume' it after it bails, or do i hav to do the rest manually?
<Kamping_Kaiser> http://paste.debian.net/123072/ is the output
<Kamping_Kaiser> (yes, i should tidy up the tarball a bit... but not today)
<jelmer> hey Kamping_Kaiser
<Kamping_Kaiser> jelmer: hi :)
<Kamping_Kaiser> on that same subject, i can pastebin bzr st or log if that helps too
<jelmer> Kamping_Kaiser, bzr st might be useful too
<jelmer> it seems like it failed to create debian/source/format
<Kamping_Kaiser> jelmer: http://paste.debian.net/123073/
<Kamping_Kaiser> http://paste.debian.net/123074/ plugins -v if it helps too
<jelmer> Kamping_Kaiser, thanks
<Kamping_Kaiser> np
<Kamping_Kaiser> wonder if i should put in a bug :/
<InFerNo_> I have setup bzr on my linux laptop with the explorer and created "feature branches"
<InFerNo_> i have installed the explorer on my windows desktop, so the question is how I can connect to the repo
<InFerNo_> D:
<mgz> InFerNo_: how do you normally connect to your linux laptop from your windows desktop?
<mgz> if the laptop runs an ssh server, you can branch over ssh
<InFerNo_> IP
<InFerNo_> well
<mgz> as a fallback, you can always push the branch to somewhere on the net (eg lp:~yourusername/+junk/projectname), then pull from there
<InFerNo_> how i usually connect is not really a good question, I think I can say I never really connect to the laptop, unless via samba and synergy :p
<mgz> if the laptop can see the windows desktop's filesystem over samba, you should be able to just branch from the laptop to make a copy on the desktop
<InFerNo_> so just copy the files over?
<InFerNo_> I think I'm missing something
<mgz> you can do that, but using `bzr branch /src/... /dest/...` is better
<InFerNo_> k, i'll look into that in an hour, i've got to mow my lawn :>
<mgz> in this weather?
<InFerNo_> it's "ok" here
<InFerNo_> yeah it's windy that's all
<InFerNo_> so i'm going to do it quickly before it does rain
<mgz> :)
<InFerNo_> meanwhile I found this: http://doc.bazaar.canonical.com/bzr-0.11/server.htm
<InFerNo_> will read that through when I return
<InFerNo_> I guess that's what I require?
<InFerNo_> checkin/out remotely
<InFerNo_> bbl
<brainwave92> If i ask for a source at launchpad with bzr branch, it asks me passphrase to my private key . Is that normal?
<brainwave92> Even for bzr log it asks me my private key
<brainwave92> brainwave92> If i ask for a source at launchpad with bzr branch, it asks me passphrase to my private key . Is that normal?
<brainwave92> <brainwave92> Even for bzr log it asks me my private key
<InFerNo_> pfrt started raining before i could get the lawnmower out
<InFerNo_> D:
<brainwave92> InFerNo_, can you answer my question?
<InFerNo_> I joined this channel 30 minutes before you to ask how I can remotely pull files
<InFerNo_> so no.
<brainwave92> i didnt get you...all i'm saying is, is launchpad supposed to ask my password when i use bzr branch?
<brainwave92> cause the tutorials dont mention that step
<InFerNo_> how do I upload my source to launchpad, I've created the project there
<InFerNo_> from Windows that is
<InFerNo_> not Linux
<brainwave92> dude no ones listening here....i dunno why
<jelmer> hi InFerNo_, brainwave92
<InFerNo_> I've got time and they have lives?
<InFerNo_> ll
<mgz> because of lunch!
<InFerNo_> lol
<InFerNo_> don't sweat
<jelmer> InFerNo_, see http://doc.bazaar.canonical.com/latest/en/tutorials/using_bazaar_with_launchpad.html
<mgz> brainwave92: if you have given bzr your lp login, it uses ssh to connect, hence asking for the key
 * jelmer waves to mgz
<mgz> generally people run an ssh agent to avoid retyping the password all the time
<brainwave92> mgz, so should i have it that way....?
<brainwave92> i prefer typing the password....i feel secure
<InFerNo_> I keep seeing this jelmer "login to launchpad like this:"
<InFerNo_> then there's a command to enter
<InFerNo_> windows 7 is what I'm using
<mgz> brainwave92: session locking is a better way of feeling secure
<brainwave92> mgz, i am new to all this...can  you explain a bit?
<InFerNo_> also, Bazaar Explorer
<mgz> ^hey jelmer :)
<mgz> InFerNo_: you don't strictly need to run a bzr server if you have one of a large number of other ways of communicating over lan between the two machines
<mgz> which is why I was asking you about that earlier
<jelmer> InFerNo_: Have you tried running that command (I don't have much experience with bzr explorer)?
<mgz> jelmer is a samba guru so may have opinions
<InFerNo_> in the command prompt?
<InFerNo_> will check
<InFerNo_> mgz, I'm trying to setup a way to work with some people all around the world (literally)
<mgz> brainwave92: even if you retype your password all the time, someone walking up to your machine can still access your home dir, which is also likely to contain things you care about
<brainwave92> mgz, home directory has my private keys stored in plaintext?
<mgz> brainwave92: so you may as well run an ssh agent, but get in the habit of always locking your session if you wander away
<mgz> no, but it has various application caches and things like your browser passwords in plain text, and other private wotsits generally
<brainwave92> mgz, so session locking is basically locking the comp? with screen lock?
<mgz> InFerNo_: one of the easier ways of doing that is to host the branch on launchpad (or some other internet-accessible machine)
<mgz> ^yeah
<InFerNo_> lol?
<InFerNo_> hence my other questions ;)
<InFerNo_> I'm getting there
<mgz> InFerNo_: am I failing to keep up here? :)
<InFerNo_> yes
<InFerNo_> :D
<InFerNo_> I have already registered with launchpad and created the project, I was just trying to get the files up there with Bazaar Explorer
<InFerNo_> i'm trying the commands
<mgz> play around and yell again if you get stuck then
<InFerNo_> C:\Windows>bzr launchpad-login infy.inferno. bzr wordt niet herkend als een interne of externe opdracht, programma of batchbestand.
<InFerNo_> no go jelmer
<jelmer> InFerNo_: ah, you're Dutch :)
<jelmer> InFerNo_: I'm not really familiar enough with the windows installation to know where it installs
<dOxxx> usually C:\Program Files\Bazaar
<mgz> in bzr explorer, under Bazaar/All Commands... you can type in a command and run in there
<mgz> there doesn't seem to be an easier way from browsing around the config stuff confusingly...
<brainwave92> dOxxx, the windows way...whole software more or less at one place. Just search na!
<InFerNo_> got it
<dOxxx> Although, I would have expected bzr to have been added to the PATH
<InFerNo_> yes
<InFerNo_> it asked and i allowed it
<dOxxx> so, why (if my reading of dutch is accurate) is it saying it can't find bzr when you run it at the cmmandline?
<dOxxx> was the command prompt you used already open before you installed bzr?
<brainwave92> dOxxx, i doubt if its bzr in windows is it?
<brainwave92> it might be some other name
<dOxxx> the commandline tool in the windows install is bzr
<dOxxx> I run Windows 7
<mgz> thats a good guess, dOxxx must be an expert in confusing windows situations
<mgz> anyway, InFerNo_, have you got something pushed to launchpad yet?
<dOxxx> command prompt windows don't see environment variable changes made by other apps after the prompt was opened
<dOxxx> so if you install something that changes the environment, you have to close and re-open all your command prompt windows if you want them to see that change
<dOxxx> it's pretty much the same as in Linux
<InFerNo_> no mgz  :p
<dOxxx> where are you stuck InFerNo_?
<InFerNo_> I have a project locally
<InFerNo_> I want it on launchpad so we can work on it together
<InFerNo_> i've created the project there
<InFerNo_> that's where i'm stuck
<InFerNo_> to get the files on launchpad
<mgz> okay, so inside the bzr explorer branch view
<InFerNo_> and bzr isn't working from the command line apparantly
<InFerNo_> yes
<mgz> one of the buttons at the top is "push", it's a green arrown pointing upwards
<InFerNo_> yes i pushed it
<InFerNo_> it asks for the locaion
<InFerNo_> location*
<mgz> okay, so that you can find from the launchpad webpage for your project
<InFerNo_> been looking around
<dOxxx> what's your project name?
<mgz> it's generally something like lp:projectname
<InFerNo_> dday
<dOxxx> so push to lp:dday
<InFerNo_> error
<InFerNo_> sec
<InFerNo_> synergy isn't moving the clipboard
<InFerNo_> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/dday": no supported schemes
<mgz> hm, I've not actually started a project from scratch with launchpad, you may just need to do something on the website. <https://code.launchpad.net/dday> currently has a pointer to a help page.
<mgz> ah, ugh
<dOxxx> hmm
<dOxxx> what version of bzr do you have installed?
<InFerNo_> 2.3.3
<mgz> that might be an ssh setup thing.
<InFerNo_> in windows?
<mgz> you don't have a key registered with launchpad currently
<InFerNo_> i see
<mgz> there's a help page for this...
<mgz> horrible error message though.
<mgz> https://help.launchpad.net/Code/QuickStart
<mgz> refer to that as you go
<mgz> where's the ssh guide...
<mgz> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<mgz> you can copy the key from your linux laptop (I'm betting you already have one there) to your windows machine if you like.
<InFerNo_> invalid public key
<InFerNo_> jezus christ lol
<InFerNo_> I'll never get the main developer persuaded D:
<mgz> the help page links a question that may help you there.
<mgz> ssh setup is a one time cost that pretty much every developer needs to do, telnetting across the public net is just a bad idea
<InFerNo_> bzr: ERROR: Connection error: Unable to authenticate to SSH host as  infy-inferno@bazaar.launchpad.net supported auth types: ['publickey']
<mgz> okay, that's progress
<InFerNo_> :)
<InFerNo_> and i've gotten the command prompt to work if i do it straigt from the program files folder
<mgz> so (this is the windows box right?), you probably either want to run pageant and load the key, or put the passphrase you used for the private key in a conf file (not generally sensible, but doesn't hurt for testing)
<InFerNo_> ok
<mgz> bzr explorer Settings/Credentials opens the right file for you, and add password=...
<mgz> ...is that right? I'm having doubts.
<InFerNo_> Connected (version 2.0, client Twisted)
<InFerNo_> bzr: ERROR: [Error 5] Toegang geweigerd: 'c:\\users\\win7\\appdata\\local\\temp\\tmplxzxnt.pag'
<mgz> really the launchpad help should cover this, I'm used to my own way of doing all this
<InFerNo_> Toegang geweigerd = access denied
<InFerNo_> i wasn't here if the launchpad help would've been clear
<mgz> the launchpad help mostly assumes you use ssh all the time anyway I think
<mgz> it's not much good having a page on generating keys if it doesn't also tell you how to use them, or at least point you at the putty help
<mgz> I guess step 6 is sort of it...
<InFerNo_> idd
<mgz> but somehow you've got a file in temp that bazaar thinks it needs to access
<InFerNo_> alright, it's pretty clear this is going nowhere, i've spent all afternoon
<InFerNo_> any alternatives
<InFerNo_> for easy collab?
<InFerNo_> :p
<mgz> basically you and whoever else just need a common place to put things.
<InFerNo_> and check if the file got changed
<mgz> somewhere you can ftp to and both have the password would be fine
<InFerNo_> that's a hassle for things like this
<InFerNo_> dday is a quake 2 mod
<mgz> if you right click on the pageant icon in your taskbar and to view keys, do you see the key you gave launchpad?
<mgz> I'm sure there must hae just been a slip up when you were following that ssh guide.
<mgz> once you get over that hump, the rest is easy.
<mgz> also, revert that config change I mentioned earlier if you did it.
<InFerNo_> yes i added it to pageant mgz
<InFerNo_> i'll revert it :)
<InFerNo_> rebooting
<mgz> okay.
<InFerNo_> no go
<InFerNo_> the files in the temp folder are created by pageant
<InFerNo_> hence the .pag extension
<InFerNo_> pagent off, ssh error, pageant on, can't read .pag file
<mgz> can you do from the command line `plink infy-inferno@bazaar.launchpad.net` and tell me what it prints?
<mgz> plink can be found in the PuTTY dir whereever you installed it
<mgz> so, eg, `cd "Program Files\PuTTY"` then run that command
<InFerNo_> just a second, I was starting to give up on Windows so I'm trying it in linux and I've gotten further
<InFerNo_> 1 sec
<mgz> it is easier on nix.
<InFerNo_> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/dday/".
<mgz> thaty's good.
<mgz> what command did you run to get that?
<InFerNo_> i did that in bazaar explorer :>
<mgz> with push?
<InFerNo_> no
<InFerNo_> with "Branch"
<InFerNo_> good point
<mgz> so, open your local branch, then push to lp:dday
<InFerNo_> 1 more thing
<InFerNo_> to start a new repository
<InFerNo_> what do I pick best
<mgz> you mean from explorer's "workspace model" options?
<InFerNo_> Colocated branches, Feature branches, plain branch or shared repository
<InFerNo_> I'm guess features..?
<mgz> I think feature branches are least confusing
<mgz> the idea there, is when you want to work on a new idea, you create a new branch inside your shared repository, commit as you go, and only when you're done merge it into the trunk branch and push it up to launchpad
<InFerNo_> alright no errors
<InFerNo_> i think it's pushed
<InFerNo_> :D
<InFerNo_> yeah that's exactly what's needen mgz
<InFerNo_> if i'm working on a jetpack, and he's working on a weapon we don't want to overwrite each other's changes
<mgz> right.
<mgz> and you can also be working on two things yourself locally, and not have either depend on finishing the other one first
<InFerNo_> 1 more quick question
<InFerNo_> how do I give the current "version" a revision number?
<mgz> you can generally just use the number bazaar counts up for you, but to do a release or something you can tag a numbered revision with a name
<InFerNo_> well, the current version number is at 5052
<InFerNo_> 5.052
<mgz> well, how you name your versions yourself is mostly a matter of taste, but you can add a tag every time you bump that number
<mgz> I wouldn't go overboard though, the revision numbers are often all you'll need, and they (mostly) just count up from 1
<InFerNo_> heh weird, on launchpad it says "this branch is empty"
<mgz> did you add files and commit in your local branch before pushing?
<mgz> bzr explorer gives you a pretty good overview of the state of your branch
<InFerNo_> yes they're there
<InFerNo_> all the status' say unrevisioned
<InFerNo_> that's why i asked
<InFerNo_> got it
<InFerNo_> something weird
<InFerNo_> there's a dialog where are the files are selected
<InFerNo_> deselected them all, pressed ok then reselected them all and pressed ok again, now it works
<InFerNo_> site still says no files are up lol
<dOxxx> when you initialized the branch in your working direcoty, did you "Add" the files and then "Commit" them?
<dOxxx> once you have done that, then Push to lp again
<InFerNo_> yes
<InFerNo_> "Working tree is up to date at revision 1."
<InFerNo_> code.launchpad.net/dday says the tree is empty
<dOxxx> I see the files
<dOxxx> http://bazaar.launchpad.net/~infy-inferno/dday/trunk/files
<InFerNo_> no i just did it again while i replied here :)
<dOxxx> the lp website may take a minute or two to update after you push stuff
<InFerNo_> good to know
<InFerNo_> alright
<InFerNo_> thanks for all the help so far, I'm going to start fresh on the windows part, so I'll stick around
<InFerNo_> works like a charm on XP
<InFerNo_> heh
<InFerNo_> trying again on 7
<InFerNo_> no go on 7
<InFerNo_> :/
<dOxxx> what's the problem on 7?
<InFerNo_> bzr: ERROR: [Error 5] Toegang geweigerd: 'c:\\users\\win7\\appdata\\local\\temp\\tmplxzxnt.pag'
<mgz> sounds like pageant may be running as a different user to bzr or something to me.
<InFerNo_> both started like normal
<mgz> try that plink command I suggested earlier
<InFerNo_> clicking the icon :')
<InFerNo_> http://pastebin.com/VGsE58Sm mgz
<mgz> was that with pageant running and the key added?
<InFerNo_> yes
<dOxxx> so putty's tools themselves aren't seeing the pageant and its loaded keys
<InFerNo_> apparantly
<dOxxx> may I suggst shutting down pageant and checking in task manager that there is no other pageant process?
<InFerNo_> no other pageant process is running
<InFerNo_> showing all users
<dOxxx> then restart pageant, add they key and try the plink test again
<InFerNo_> C:\Users\win7\Downloads>plink infy-inferno@bazaar.launchpad.net
<InFerNo_> Using username "infy-inferno".
<InFerNo_> No shells on this server.
<dOxxx> aha
<dOxxx> ok, try bzr now
<InFerNo_> bzr: ERROR: [Error 5] Toegang geweigerd: 'c:\\users\\win7\\appdata\\local\\temp\\tmpjadhy0.pag'
<dOxxx> ...
<mgz> mystery
<InFerNo_> :sadpanda:
<mgz> but at least doing BZR_SSH=/path/to/plink should now work
<dOxxx> InFerNo_: you're using bzr explorer, right?
<InFerNo_> yes
<dOxxx> ok, set a system env variable called BZR_SSH to the path to the plink executable
<dOxxx> and then restart bzr explorer
<InFerNo_> created
<InFerNo_> try to branch again?
<InFerNo_> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: BZR_SSH=C:\Users\win7\Downloads\plink.exe
<dOxxx> hmmm
<dOxxx> bleh. try setting it to just "plink" without the quotes
<dOxxx> and make sure plink is in the system PATH
<mgz> that... shouldn't matter
<mgz> is the path right? C:\Users\win7\Downloads\plink.exe doesn't seem likely
<mgz> you can test by typing %BZR_SSH% in a new command prompt, should give you the plink help
<InFerNo_> not recognized
<InFerNo_> the path is correct because I copied it
<mgz> I'd double check.
<InFerNo_> just did
<InFerNo_> same
<mgz> I'd expect it to be in "Programs" not "Downloads"
<InFerNo_> can it be installed?
<dOxxx> well, putty is just a zip
<dOxxx> not an installer
<InFerNo_> idd
<dOxxx> so you can put it wherever
<InFerNo_> and i've put it in downloads
<mgz> ...I remember having an installer.
<mgz> you might need to set a magic bit if you downloaded the exe straight and are trying to run it
<InFerNo_> i found an installer and am running it
<InFerNo_> variable BZR_SSH
<InFerNo_> value BZR_SSH=C:\Program Files (x86)\PuTTY\plink.exe
<InFerNo_> that's what it is now
<mgz> that should be fine.
<InFerNo_> C:\Users\win7\Downloads>%BZR_SSH%
<InFerNo_> %BZR_SSH% wordt niet herkend als een interne
<InFerNo_> of externe opdracht, programma of batchbestand.
<InFerNo_> aka not recognized
<dOxxx> don't put BZR_SSH= at the beginning of the value
<mgz> ah, whoops.
<InFerNo_> changd
<mgz> also, "%BZR_SSH%" to test.
<InFerNo_> still can't do %BZR_SSH%
<mgz> but bzr doesn't need it quoted.
<InFerNo_> uknown command
<dOxxx> remember to reopen your command prompt after you've changed the env variable
<InFerNo_> it's tripping over the space
<InFerNo_> got it
<InFerNo_> works
<mgz> you need those quotes.
<mgz> only for the test.
<mgz> now try bzr.
<InFerNo_> there's light at the end of the tunnel
<InFerNo_> it works
<InFerNo_> \o/
<dOxxx> yay!
<InFerNo_> heavy stuff
<InFerNo_> work instantly on XP
<InFerNo_> worked*
<mgz> yeah, I think windows 7 security model was causing you the problems there
<mgz> it sort of quarenteens binaries downloaded from the net
<InFerNo_> yeah probably
<InFerNo_> my colleague said win7 was going to give us headaches
<InFerNo_> I work at an IT department :/
 * jelmer waves
<saedelaere> hi
<lifeless> hi
<InFerNo_> hi
<saedelaere> I currently did resetup my local bzr repo where I develop a project hosted on sourceforge. today I wanted to commit to the trunk branch and now I get some strange error messages. http://pastebin.com/iBi0tmBh
<saedelaere> what is the problem there?
<saedelaere> I was able to commit locally but not able to push the new revisions to the server.
<saedelaere> normally I was asked for a password but now I get this error message.
<lifeless> well the bzr:// protocol doesn't have built in authentication
<lifeless> so probably you were using bzr+ssh before
<saedelaere> lifeless, thank you for opening my eyes :) your hint was the key...
<lifeless> de nada
 * saedelaere zzz
<mtaylor> lifeless: hey!
<lifeless> hiya
<LeoNerd> I've finally got around to switching from sftp to bzr+ssh
<mtaylor> lifeless: so ... one of the features I requested for a while is now in the tree and it's biting me in the ass :)
<LeoNerd> Previously my server was a celeron333, that was sufficiently slow to fork/exec/compile python that it was quicker to run the sftp server in the sshd itself.
<mtaylor> lifeless: oh - wait - I may have discovered a sequence around it ...
<lifeless> LeoNerd: yeah, if your server is low latency high bw sftp can be quite nice
<LeoNerd> When I'm at home, the two are fairly similar. But I'm out on the wrong end of a GPRS connection enough times to justify bzr+ssh now
<mtaylor> lifeless: ah - nope. it's still biting me.
<lifeless> mtaylor: some more detail may help :P
<mtaylor> lifeless: so - if I set bzr whoami and then do a branch from launchpad
<mtaylor> lifeless: it "helpfully" sets launchpad-login for me (which normally I want)
<mtaylor> except, in this case, it's happening on a jenkins slave, so I don't actually have a key ... HRM - *facepalm* - what if I set a whoami that doesn't match a launchpad user ...
<lifeless> as far as I know those are unrelated
<mtaylor> bzr branch lp:burrow /home/jenkins/workspace/burrow-tarball
<mtaylor> Setting ssh/sftp usernames for launchpad.net.
<mtaylor> lifeless: nope. it's even simpler - I was injecting too many lines in to a file
<mtaylor> all my fault
<lifeless> win
<sbl> Hi
<sbl> Could you help me with bazaar commit problems?
<sbl> When I try commit changes from my notebook I receive this error:
<sbl> bzr: ERROR: Cannot lock LockDir(ftp://username@host/remote/path/to/repo/.bzr/branch/lock): File exists: '/remote/path/to/repo/.bzr/branch/lock/vez6vu0c2n.tmp': 550 /remote/path/to/repo/.bzr/branch/lock/vez6vu0c2n.tmp: Permission denied
<sbl> Any ideas?
<sbl> In this localization file: vez6vu0c2n.tmp doesn't exist.
<sbl> I use TortoiseBazaar from Windows.
#bzr 2011-07-17
<bob2> sounds like perms on the ftp server are busted
<Peng> Or it's just FTP bustedness.
<lifeless> smells like that windows cluster-fs issue someone was running into a couple years back
<lifeless> where the cluster sync locked the file against renames or something-like-that
<Kamping_Kaiser> no jelmer?
<Kamping_Kaiser> sems not.
<rigel> hi, i'm trying to work with the bzreclipse plugin, and i can't figure out how to import a project directly from bzr with it, if indeed that is possible.
<rigel> just because my experience is that it's kind of a PITA to get source from a VCS, and then import that
 * maxb wonders why 'bzr pull' would be write-locking the source branch
<maxb> Oh, not the source branch per-se, but the bound branch
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell and jam
<jonathanj> hey
<jonathanj> i seem to have this happen to me often enough that i'm wondering if there is something in bzr to help me
<jonathanj> i start making changes in a branch and then realise later that these should probably be in another branch and i'd like to apply the diff on branch A to branch B
<jonathanj> currently i just do bzr diff > ~/tmp && bzr revert && cd .../other-branch && patch -p0 < ~/tmp && rm ~/tmp
<lifeless> bzr merge --uncommitted
<jonathanj> lifeless: but then don't i have to fiddle with revisions to only merge the thing i want and not all the other changes?
<jonathanj> oh i see, --uncommitted is *only* uncommitted
<lifeless> right
<jonathanj> great, thanks!
#bzr 2012-07-09
<Azendale> I have a directory that I ran bzr init in and since have made quite a few commits. Now I need to make a branch (I think that's the right word) of that directory (I'm making changes that may break it). From what I found on the web, you need a repository to do that?
<Azendale> If so, how do I change my directory into a repository?
<thumper> Azendale: if you ran bzr init, then that director is now a branch
<Azendale> So, I guess I'm trying to make a branch of a branch? Is there a way to do that?
<thumper> yes
<thumper> bzr branch
<thumper> however, what are you actually trying to do?
<Azendale> Mostly, have two different versions of the same thing. One with a feature and one without. Somewhere down the road maybe be able to take some improvements/changes from the plain version and add them to the extra feature version
<Azendale> Maybe I don't totally understand how having different versions of the same thing work. Do you just switch versions and the directory gets changed, just like when you do a bzr revert?
<Azendale> Ok, I think I just figured it out. You do bzr branch and you get a second directory with the different version.
<kees> jelmer: saaay, is there an upload planned for quantal? LP: #963769 has bit me there and now bzr is useless on my non-auth chroots
<kees> (i.e. over http)
<spm> heya kees
<kees> hi spm! :)
<jelmer> kees: I was planning on doing another upload once beta2 is released
<jelmer> vila: what are your plans for 2.6 wrt quantal? should we just ship a beta?
<vila> jelmer: quantal should get 2.6b1 as it has already been released
<jelmer> vila: it already has b1, though there are some fixes in trunk that would be relevant too (see kees' messages from earlier this morning)
<vila> oh, yeah, sry misread rmadison
<vila> so yeah, 2.6b2 needs to be released, https://launchpad.net/bzr/+milestone/2.6b2 reveals a few bugs that need to be either fix released or retargeted
<jelmer> vila: Should we do a proper 2.6.0 (with fewer betas) or just ship a beta with quantal?
<vila> I'd say betas for now and a proper 2.6.0 in due time
<jelmer> vila: in due time being before quantal is released, or after that?
<vila> before
<vila> like we did for other 2.x.0
<jelmer> vila: okay, works for me :)
<mgz> afternoon
<jelmer> it most certainly is
<ggherdov> Hi all, trying to get the extmerge plugin working on my bzr 2.1; it shows up nicely if I do "bzr plugins", but then "bzr extmerge" gives an error. details here http://bpaste.net/show/S5oCeADfMNiQheflCc2v/ . Any gotcha ?
<ggherdov> I installed it just wget-ing the two py files into $HOME/.bazaar/ from http://bazaar.launchpad.net/~zindar/bzr-extmerge/trunk/files
<ggherdov> $HOME/.bazaar/plugins/ I meant
<jelmer> ggherdov: they should be in a extmerge directory
<jelmer> ggherdov: rather than directly in ~/.bazaar/plugins
<ggherdov> jelmer: ah that makes sense :-) thanks a lot, trying it.
<kees> jelmer: okay. it'd be nice to get it in asap since not having bzr is breaking all my regression testing runs on quantal currently
<jelmer> kees: I guess we could do another upload to fix just this, though ideally I'd just pull it in with the next beta
<jelmer> vila: still there?
<vila> yup
<jelmer> vila: what sort of timeframe do you have in mind for b2?
<vila> let's talk about releasing 2.6b2 during tomorrow standup
<jelmer> okay
<vila> and if we agree, I can freeze it tomorrow
<kees> jelmer: I can go either way. other people are running regression tests too, so I can wait. :P
<jelmer> vila, mgz, jam: https://code.launchpad.net/~jelmer/bzr-gtk/remove-bzr-notify/+merge/113990
<vila> hey ! I'm using that !
<jelmer> vila: really?
<vila> yeah and I don't have trouble with it
<jelmer> vila: it's causing various issues for ubuntu users who just happen to have bzr-gtk installed
<vila> There was thatn shadow window stuff I encounter once or twice but never to the point I could really reproduce and adiagnose
<jelmer> it hasn't worked for me in a long time
<vila> Can't you just disable it ?
<vila> really ?
<vila> what is broken ?
<jelmer> anyway, if you think we should keep it then we should at least disable it by default I think
<vila> yeah, disabling sounds better
<jelmer> vila: what do you use it for though? it only notifies about local stuff these days anymore, unless you have somehow fixed bzr-avahi (and have somebody else that uses it too nearby?)
<vila> for now I use it for local commits indeed
<jelmer> vila: it just notifies for commit though, how is that useful? you're the one doing the commits :)
<vila> come to think of it, it works on my laptop but not my desktop
<vila> it also gives feedback when I'm updating
<jelmer> ah, okay
<jelmer> okay, let's disable it by default then
<jelmer> vila: any chance you can follow up to say you're still using bzr-notify on that mp?
<jelmer> Curtis just replied to it to
<jelmer> *too
<vila> yup just refreshed the page to do so and saw curtis answer
<vila> done
<jelmer> vila: replied :)
<jelmer> vila: reconsidering, we have a limited capacity for maintenance and bzr-notify in particular seems to require quite a bit
<jelmer> if it's going to blow up for this many users, I think we should either fix it or get rid of it completely
<vila> if it's disabled by default why should it blow ?
<vila> gtg, up to you, bbl
<jelmer> vila: it will still blow for those people who attempt to use it
<vila> this logic is flawed: you're implying that code that doesn't run everywhere should be removed
<jelmer> vila: I'm implying that it breaks for a large number of people, and as such does more harm than good
<jelmer> new users who try it out will be disappointed, and we don't really have the capacity to fix this
<jelmer> combined with the fact that bzr-notify isn't particularly useful in the first place, especially now that bzr-avahi is broken
<jelmer> the other thing is that it is the main (only?) thin that uses bzr-dbus
<jelmer> *thing
#bzr 2012-07-10
<mgz> morning!
<m1sc> hi. remove-branch seems to work for local locations only. how do I remove a remote branch?
<bob2> don't think bzr has that built in
<mgz> m1sc: that works over a smart server in recent versions, but deletes the branch only, any repository is left existing
<m1sc> mgz: smart http? I use bzr 2.5.1 on client side -- when trying "bzr remove-branch https+urllib://example.com/my/branch", it's doing http authentication but then tries to delete the branch locally.? (bzr: ERROR: Not a branch: "/home/user/foo/https+urllib://example.com/my/branch".)
<mgz> that's not smart.
<mgz> m1sc: this is what works <http://pastebin.ubuntu.com/1084259/>
<jelmer> it tries the remove branch first then falls back to locally
<mgz> (progress leakage there incidentially)
<mgz> falling back to treating it like a filename when it has a scheme seems like a bad idea
<mgz> m1sc: what you can do is just remove the directory via any other means
<jelmer> mgz: yeah
<m1sc> bob2, mgz, jelmer: thanks, will stick with ssh
<ggherdov> hello. I know I can ask bazaar for all commits involving file FOOBAR.txt. Can I show all commit made by a specific developer, too ?
<mgz> yup, see `bzr help log`
<mgz> note the author(s)/committer distinction
<mgz> but generally `bzr log -n0 -m "Your Name"` will be fine
<ggherdov> mgz thanks
<james_w> vila, hi, you around?
<vila> james_w: yup
<james_w> great
<james_w> hi :-)
<james_w> vila, what would be the best way of injecting the db configuration values in to the config stack during the tests?
<james_w> currently I believe it uses the standard dbs, which isn't great for test isolation
<james_w> I'm adding support for postgres to the test suite, so now we need to run against both
<vila> err, no, I think it uses ones under self.test_dir
<james_w> I don't want to be adding pkgimport.conf on the fly
<james_w> aha!
 * james_w tries to find that
<vila> TestCaseWithConfig does that for you, at least it sets pi.base_dir
<vila> now, I don't know postgres, but given the config you added for it it seems to be using a host:port to reach the db so I you can set that in the config and initialize the db itself
<james_w> vila, what's "_set_store_content"
<james_w> I mean, what's "store" in that context?
<vila> a trick to add additional content in the config, there are examples...
<vila> let me check
<vila> store as in config store, a physical container, here, a file :)
<james_w> ah, I see
<james_w> but it's a "set all" interface, rather than an "append" interface?
<vila> look into test_mass_import for how to add stuff
<vila> just calling super()  then
<vila> so each subclass can add what it needs
<james_w> oh, hmm
<james_w> ok
<james_w> thanks
 * james_w ponders moving this to fixtures
<Wiz_KeeD> hey guys
<lduros> hello, I have a bzr branch which I initialized with the source files from Firefox 12. Now, I made some changes to these files, and now there is a Firefox 13 with many many differences with both Firefox 12 or my own fork. My question is, what is the best way to merge all the changes from the files in Firefox 13, while keeping the changes in my own fork. I can see many ways to do that more or less efficiently with diff and bzr diff. But I'd like to know if the
<lduros> so what I did is use bzr diff -r1 > diff.txt
<lduros> which outputs all the difference with the current version with the first version in which the initial files were present
<lduros> and now I'll try to apply it as a patch to the new set of files
<lduros> does it make sense or is there a better way to do this with bzr and a special merge
<lduros> hello, I asked a question earlier, got no answer, and thought maybe i'd ask it again
<lduros> if you have upstream files, you create a branch with them
<lduros> make changes to them,
<lduros> and then the upstream releases a new version
<lduros> what's the best way to merge those new changes from upstream while keeping your own changes
<lduros> upstream does not use bzr by the way, i'm just using the tar
<lduros> using bzr diff and then patch does the trick, but is there a more elegant way? :-)
<lduros> or some documentation worth reading? :-)
<lifeless> lduros: bzr import can import the tar
<lifeless> lduros: have one branch representing upstream and one your work, import upstream onto the upstream branch, then merge that to your branch.
<lduros> ah
<lduros> ok, I see, I'll try this, thanks
<lduros> looking into bzr import at the moment
<lduros> lifeless: what you are describing is basically what's described in this page, minus the bzr import for the tar >> http://wiki.bazaar.canonical.com/TrackingUpstream -- correct?
<lifeless> yes
<lduros> ok cool
<lduros> :-)
#bzr 2012-07-11
<lduros> so basically I did: bzr import firefox-12.0.tar.bz2 upstream
<lduros> then bzr commit -m'ff12'
<lduros> then bzr import firefox-13.0.tar.bz2 upstream
<lduros> bzr commit -m'ff13'
<lduros> then in my other (previously existing branch), I do: bzr merge upstream
<lduros> does this make all sense?
<lduros> looks like the two imports worked
<lduros> but since my own branch is not related to upstream in any kind, since I created it beforehand, I get this when trying to merge:
<lduros> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<lduros> so base revision I should probably put 1
<lduros> i guess
<lduros> since a commit in my branch corresponds to Firefox 12
<AfC> lduros: so before you figure out how to fix this,
<lduros> AfC: ?
<AfC> lduros: I assume you recognize that if you had *started* with the imports and *then* created your own working branch(es) they would have had said common ancestor and all this would be Just Workingâ¢
<lduros> yes i know but I started that a while ago
<AfC> sure
<lduros> my own branch, I mean
<AfC> just setting the scene here
<AfC> lots of people don't realize that part
<lduros> yes, in retrospect I should have done it
<lduros> :-)
<AfC> now we just need to fix the scenario you've found yourself in
<AfC> lduros: rude question: how much history do you have on your working branch?
<lduros> 112 revisions, not that bad I guess
<AfC> lduros: a lot? only one or two
<lduros> I could probably just apply a patch
<AfC> No, that's a lot
<lduros> and forget about it
<AfC> so you're not going to want to throw that away.
<AfC> (sure, you could throw it away, but why should you have to?)
<lduros> well, I don't know, if it's easier I could
<AfC> at this point, as far as I know, you have two options
<lduros> ok
<AfC> lduros: (it's *certainly* easier)
<lduros> ok
<fullermd> I don't see how...
<lduros> so what if I do this:
<AfC> lduros: but it's also Wrong and the one thing that Bazaar has going for it over the other DVCSen is that it acts correctly.
<lduros> hmm, not sure how to interpret this
<AfC> fullermd: (because just dumping his current tree onto the upstream import will create a single delta that he can commit and then we can all move on and go drink coffee. Easier. More to the point, easier than:)
<AfC> lduros: at this point, as far as I know, you have two options:
<AfC> 1) use bzr rebase
<lduros> ok
<AfC> 2) use some magic merge that gets around the common ancestor problem.
<lduros> the magic merge seems tricky
<fullermd> I think it's way easier than either of those two.
<AfC> I have a feeling that (2) exists, but I don't know the syntax :(
<fullermd> You started with FF 12 and then made a pile of changes on top, neh?
<AfC> fullermd: if you've got (3) please, speak up
<lduros> and also I added the upstream files with a non-empty branch already
<lduros> meaning I had files in there
<lduros> hah
<lduros> yeh, so maybe i'll try to take the current version I have (which is IceCat 12)
<AfC> fullermd: right, so how can he merge a branch with 112 revisions from scratch (and some monster revision as #1 I bet) starting onto a branch with 2 imports of two versions of upstream?
<lduros> Take IceCat 12 and take Firefox 12, make a patch using diff
<fullermd> Oh, that wasn't what I read from your descriptions.  That does make it harder.
<lduros> then create an upstream branch, import FF12
<fullermd> Well, in my mind his r1 was already upstream 12, so he could just make a 'new' branch from that to use as the upstream.  Put 13 on that, then merge it in; done.
<lduros> fullermd: it was more like r41 which was upstream 12 + custom stuff
<lduros> so it's really a tangled mess
<lduros> :-)
<lduros> I'm willing to just keep it as an archive branch
<fullermd> Is your custom stuff off on the side, or all intertwined in the existing files?
<lduros> mostly on the side I guess
<lduros> but some might be intertwined, not much
<lduros> but I'm a bit lazy also
<lduros> :-)
<lduros> and maybe sometimes it's better to start clean
<fullermd> If you can isolate the changes in the existing files into a few small bits, you may be able to create a pure upstream 12 branch, dump the 'old' files you have and merge that in place, put your changes back into them, then go on with later version merges.
<lduros> ok
<fullermd> That would save all the history in your other files, and have the original versions of your changes sitting in the history too.
<fullermd> It would bloat up your repo with a giant delete and a giant add though.
<fullermd> And of course the "same" files wouldn't be related to each other historically.
<lduros> haha
<lduros> right
<lduros> alright, let me try
<fullermd> The latter is suboptimal ugliness that can be considered historical archive.  The former is some level of added size burden you'd carry forever; whether it's significant I don't know.
<fullermd> I have vague memories that the groupcompress format will compress content across file identities, in which case it may not be a big bump.
<lduros> yeh, I'm not sure, what I want to make sure is that all my custom changes are there
<fullermd> But if it doesn't, it would be.
<AfC> I'd judge the real question to be whether or not you will be continuing to track upstream. If so, then it's worth getting on to a workflow based on their releases, rather than your original tree.
<lduros> yes sure i'll keep tracking upstream
<AfC> otherwise, it's not entirely clear what the goal is
<fullermd> Definitely.  Doing a 12->13 merge up manually would suck.  Having a 14 and 15 and 16 after that too would be nightmarish.
<lduros> right
<fullermd> (and anyway, it's FF, so you'd have to do one of those, what, every 36 hours or something, when they make a new major release?)
<lduros> :-P
<lduros> alright, I'll experiment a bit, look again at these advice
<lduros> and try to get somewhere :-]
<fullermd> Yeah.  I'd probably experiment a bit with two or three options, see which seems to work best.
<lduros> yeh
<lduros> thanks much
<lduros> :-)
<mgz> morning
<fullermd> No, I don't think I'll allow that.
<mgz> it has been decreed.
<fullermd> Well, recreed it.
<rhitier> hi. I've commited many times before discovering my whoami was wrong. Can I edit the "committer" of previous commits ?
<mgrandi> dont think so unless you use one of those rabasing things that basically create new commits
<rhitier> "rabasing thing" ?
<mgrandi> rebasing*
<mgrandi> i dont know much about how bzr does it, basically edits the history im guessing
<LeoNerd> It's a form of history rewriting
<LeoNerd> It's rather rude on anyone else who's seen the branch, but if it's a private one currently with no chance anyone else has seen it it should be fine
<rhitier> mgrandi, LeoNerd : thanks, I'll try that as it is a private before sending.
<jelmer> bzr rebase isn't particularly useful in that regard
<mgz> what is the easiest way of replaying history? export then import?
<jelmer> I think so, or shelve + uncommitt
<rhitier> when I merge a contributor's patch, do I imports all its commits history ?
<jelmer> rhitier: if it's a bundle, yes
<mgz> or if you're merging a branch, anything using merge before commit basically
<rhitier> isnt bundle naturally created with bzr send ?
<jelmer> rhitier: yes
<rhitier> ok. I merged. Should I commit before being able to see history logs of applied patch ?
<jelmer> rhitier: yep, or you can use e.g. qlog
<rhitier> I created a branch. I merged the patch. And now the log shows a "Pending Merges". After a commit, contributor's commits appear as a branche of my latest commit. Is that it ?
<rhitier> (with strange rew numbers, like 50.1.2 )
<mgz> rhitier: roughly
<rhitier> thanks all. I go on branching/hacking ;-)
<jam> jelmer: ping, I think I need a refresher on getting and building source debs
<jelmer> jam: sure
<jelmer> mumble?
<jam> jelmer: sounds good
<cedeon> Hi guys.  Can anyone help me , i need to merge two branches which the data is absolutely identical yet for reasons that blow my mind bzr wont merge as it says it doesn't share a common ancestory.  Is there any simple way of doing this without it generating a whole bunch of .moved files in the process?
<jelmer> cedeon: the branches aren't related as far as bzr is concerned
<jelmer> cedeon: the files would all have different unique file identifiers
<jelmer> you can see this by running "bzr ls --show-ids" in the two branches
<cedeon> so its not like git where they have the file contents hashed?
<cedeon> is there anyway to force copy they file identifiers?
<cedeon> from one branch to the other?
<jelmer> cedeon: when you add a file, you can use "bzr add --file-ids-from <otherbranch>" to make it use the same file ids
<cedeon> cool thanks , i'll give that a try
<bob2> I don't think git works the way you think it does either
<bob2> oh heh
<bob2> don't quite understand how it works, the branches have no ca
<cedeon> well maybe im going about this the wrong way.. i cant 'add' because i have a lot of history on my branch... basically i have a situation where i have 31 revisions and some guy gave me a bzr repo with six revisions and different file ids.  I KNOW that my revision 30 equals his revision 0 yet i cant figure out how to merge these together
<cedeon> it just seems like this sort of thing should be simple
<bob2> nah
<bob2> you can bzr-rewrite his on top of yours though
<cedeon> i can rollback to rev 30 so im at the stage where the file bits are identicle
<bob2> how did all the fileids get lost
<cedeon> i dunno i guess he made a new repo from my files and didn't use my repo
<cedeon> how do i rewrite his on top of mine?
<cedeon> i tried merging his and then deleting all the .moved files.. committing but then i have his file ids so i cant merge my 31 back
<jelmer> cedeon: still there?
<jelmer> cedeon: I would:
<cedeon> yeah im here
<jelmer> 1) create a copy of the branch at the point where the histories are still shared
<cedeon> check :)
<jelmer> 2) sync his files over the new copy
<jelmer> 3) "bzr add --file-ids-from YOURBRANCH"
<cedeon> oh wait, they have no shared history if you mean bzr history
<jelmer> 4) remove files that weren't present in his branch
<jelmer> cedeon: in that case, start with an empty branch
<jelmer> or actually, revision 30 you were referring to earlier
<jelmer> (but revision 30 from your branch)
<cedeon> yeah i've rolled back to rev 30
<cedeon> ok i think i get you
#bzr 2012-07-12
<mgz> morning all!
<jelmer> vila: I'm still wondering about bzr-notify..
<jelmer> maybe I should ask on the mailing list whether anybody else uses it?
<vila> :) Good idea
<mgz> that seems reasonable regardless
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer: hey
<Noldorin> jelmer: do you have a link to that old bug i reported concerning dpush, just for reference?
<Noldorin> don't worry not asking you to fix it :)
<Noldorin> jelmer: if you have it available that is
<jelmer> Noldorin: https://bugs.launchpad.net/bzr-git/+bugs should have it
<Noldorin> jelmer: TA
<Noldorin> ta*
#bzr 2012-07-13
<Noldorin> jelmer: i see mine isn't the only complete. that actually makes sense heh
<Noldorin> jelmer: we all lose interest over time. sounds like it would be nice if canonical assigned someone else to maintain the project...
<Noldorin> jelmer: we all move onto more interesting and captivating things in time. so i sympathise :)
<Noldorin> btw
<Noldorin> does bzr have a gui on unix (specifically os x) ?
<Noldorin> like qbzr on windows
<mgz> morning
<jelmer> hi mgz
<jelmer> hi Noldorin
<jelmer> Noldorin: to answer your question from yesterday
<jelmer> Noldorin: I wasn't assigned to work on bzr-git, I just happened to be the main person contributing to it
<jelmer> Noldorin: nothing is stopping anybody else from working on it; in fact, it would be great if they/you would :)
<jelmer> s/to work on/to maintain/
<Noldorin> jelmer: back
<Noldorin> jelmer: yeah. it was your creation from the start wasn't it?
<Noldorin> jelmer: sadly i have too much going on. but i'm thinking about contributing little bits to it perhapsâ¦my python be it poor.
<jelmer> Noldorin: No, Rob the proof of concept for it way back when; I took over quikly after that
<Noldorin> jelmer: ah right. so mostly your work, althought not from the start.
<Noldorin> rob isâ¦ another canonical employee i guess
<jelmer> Noldorin: right, but for work the focus has really been on the code imports, not on stuff like dpush
<jelmer> Noldorin: yes, but IIRC he also started it in his spare time
<Noldorin> code imports?
<jelmer> Noldorin: the launchpad code imports from git into bzr
<Noldorin> oh i see
<Noldorin> jelmer: makes since, if launchpad needs bzr-git, then that is the priority i suppose
<Noldorin> jelmer: i've migrated to mac these days so hopefully testing should be easier :)
<Noldorin> jelmer: bzr-git works fine on Mac right?
<Noldorin> jelmer: i'm also trying to install QBzr, which i hear should work on OS X too
<jelmer> Noldorin: apparently, though I've never tried it myself
<Noldorin> ok cool
<Noldorin> jelmer: if it works, i intend to put it on homebrew first thing :)
<mobby> Hi, does anyone know if there is a way to compare two related branches and just see a list of  added, removed, modified files without having each individual file diff as well? I've tried looking through Help and Google but haven't found anything :)
<jelmer> mobby: "bzr missing -v"
<mobby> jelmer: Thanks!
<mobby> seems so simple, I must have read that a number of times in teh Help and it just didn't sink in
<mobby> :)
<mobby> Sorry another question... If I have a symlink in my home dirctory "~/dev" which points to "/media/other/dev" would it be a bug that for locations.conf to work I have to put in "/media/other/dev/XXX" rather than "~/dev/XXX" or even "/home/mobby/dev/XXX" or does it work like that by design?
#bzr 2012-07-15
<crass> is there a good way to make a repo of subdirs named "debian" of multiple external repos?
<Wiz_KeeD> how do i get the initial version of a file using bzr?
<Wiz_KeeD> if i've messed around it in and i want to undo and get the last revision of that particular file
<lifeless> Wiz_KeeD: initial or more recent? they are quite different usually ;)
<lifeless> Wiz_KeeD: bzr revert filename will restore filename to the state at the last commit.
<lifeless> Wiz_KeeD: bzr revert -r <revspec> filename will restore filename to its state as of <revspec>
<Wiz_KeeD> lifeless, so i can do bzr revert file.py and it will have the state frm the last commit registered
<lifeless> yes
<Wiz_KeeD> and if i do -r revno i get the version from that revision?
<lifeless> yes
<Wiz_KeeD> that is wonderful, thank you! :D
<lifeless> bzr help revert will tell you all the things it can do :)
<Wiz_KeeD> nice man
#bzr 2013-07-08
<shepard`> #join halflife
<shepard`> huuhhh ... :D
#bzr 2013-07-09
<kolbe> $ bzr branch lp:maria/5.5
<kolbe> - 498953KB   198KB/s | Fetching revisions:Inserting stream
<kolbe> bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' [Errno -2] Name or service not known
<kolbe> *cry*
<kolbe> there is really no way to resume this operation? when i try running the same thing again i get 'bzr: ERROR: Target directory "5.5" already exists' :(
<spiv> kolbe: sadly, no
<spiv> kolbe: you can manually fetch incrementally, though
<kolbe> how do i do that?
<spiv> kolbe: bzr branch lp:maria/5.5 -r 1000 ; cd 5.5 ; bzr pull -r 2000 ; bzr pull -r 3000 ; â¦
<spiv> It's not great, but it will eventually work.
<kolbe> heh, jesus :(
<kolbe> well, thanks :)
<spiv> Glad I could help.
<ElMonkey> hi
<ElMonkey> i'm trying to get to grips with bzr-git, with a repo hosted on github
<ElMonkey> does anybody know how to avoid the "diverged branches" crap every time i dpush from another computer, and then try to pull?
<ElMonkey> is there some other command to use, so that it doesnt happen?
<beuno> AttributeError: 'NoneType' object has no attribute 'save_changes'
<beuno> haven't seen that one before
<beuno> anyone have any clues?
<beuno> was trying to reconfigure --unstacked
<beuno> in saucy
<beuno> turns out it wasn't stacked
<beuno> not the best error message  :)
<ElMonkey> anybody have a decent workflow for using bzr-git with a github repo?
<chinoto> Is it possible for bazaar to know about branches that aren't ancestors of the current commit? It seems the only possible way to (almost) do this is to get a copy of all branches that are currently being worked on from your codevelopers, and even then I'm not sure. Currently I'm learning about git to see the differences and so I can convince my team to switch if it turns out better.
<chinoto> http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/#great-toolchain
<lifeless> chinoto: bzr can know about such branches of course
<lifeless> chinoto: it couldn't merge branches if it couldn't.
<chinoto> So far we've only worked with bzr in a straight line... I've tried to understand how to work with separate branches in bazaar, but it seems the only way to do so is having copies lying around, which would be a little inconvenient for web development :/
<chinoto> It's fine if developers only ever work on one thing at a time and commit their work somewhere when they are done.
<chinoto> I believe I'm seeking a workflow that isn't possible in bazaar :/
<lifeless> chinoto: colocated branches, or branches in a treeless shared repo, both will do exactly what you want
<lifeless> chinoto: http://doc.bazaar.canonical.com/developers/colocated-branches.html I believe.
<chinoto> The problem is that I don't want to reconfigure apache and project specific variables to make each branch work... I guess I could use symlinks, but I'm not sure how the Windows developers would deal with that.
<lifeless> you don't need to.
<lifeless> standard built in workflow in bzr :)
<chinoto> lifeless: Finally think I understand it, so basically you still have a directory for each branch, but you work on them from one?
<chinoto> ugh, got a headache from soda or something, seeya
#bzr 2013-07-10
<pmatulis> say i do a 'bzr branch lp:whatever'; then 'bzr merge lp:~jdoe/whatever/review1'; and then jdoe does more work before i merge his work into trunk (the 'whatever' project).  how do i avoid having to include a commit for the original merge?  i'd rather just have a single commit
<eridu> is there a way to tell git-import to use the development-subtree repo format? I want to import a repo with submodules.
<jelmer> eridu: nested trees aren't really supported yet - bzr-git supports them, but bzr itself does not
<eridu> jelmer: I'm aware of this and assume all risks related to using nested trees -- I understand they will blow up in my face, shoot my dog, and when I least expect it, destroy all that I love and hold dear
<jelmer> you can sort of force the combination to work by initializing the target repo before running git-import
<jelmer> bzr init-repo --development-subtree foo
<eridu> can you git-import over an existing repo?
<jelmer> bzr git-import /url/for/git-repo foo
<jelmer> eridu: yes
<eridu> jelmer: thanks! didn't know that
<fullermd> The trick is to constantly expect your dog to be shot.  Then you're safe.
<eridu> hah, that made bazaar crash
<eridu> I expected my dog to be shot, but not that quickly
#bzr 2013-07-12
<espressobuff> hi, i want to navigate our bazaar repo, similar to svn list
<espressobuff> but when i try bzr ls <uri>, i get ERROR: Not a branch.... location is a repository.
<espressobuff> how do you do it then?
<mgz> espressobuff: as it says, it needs a branch, not just a repository
<mgz> a repository is a store of data, a branch is the actual graph of history
<mgz> so, eg, `bzr ls lp:bzr` works fine, because that references an actual remote branch
<espressobuff> mgz: thanks. but i want to navigate the repo to search something that i might be interested in
<espressobuff> what's the correct way to do that then?
<mgz> without a branch which references the repo, you don't have anything to navigate
<mgz> there are ways to inspect repo contents, but nearly all the time what you care about is branches
<mgz> is there something specific you're trying to do?
<espressobuff> can you give example of a repo vs branch? sorry i'm a total bzr newbie (from svn)
<mgz> espressobuff: http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/core_concepts.html
<mgz> but for example, I have ~/bzr which is a shared repo, and under that I have ~/bzr/2.5 which is a branch and a bunch of other branches
<espressobuff> so repo is the root of branch(es)? as in svn, we usually have "trunk" and "branches" as branches of a project?
<espressobuff> anyway, what i'm trying to do is that, say i can "bzr co bzr://bzr/data/bzr/dir1/dir2/dir3/dir4/trunk"
<mgz> see also http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-svn-users.html
<espressobuff> and then do "bzr ls bzr://bzr/data/bzr/dir1/dir2/dir3/dir4/" just fine
<mgz> espressobuff: no, you can't
<mgz> that's a very svn thing to do
<espressobuff> but i want to see the content of, say "bzr://bzr/data/bzr/"
<mgz> well, you can, but not in the way you're thinking
<mgz> really what you want is to just branch trunk locally, then use ls
<espressobuff> can you give the actual command, in relation to my example? thanks
<mgz> not without knowing what you've actualyl got, but generally, `bzr branch remote-location`
<mgz> which gets you a local copy to work on.
<espressobuff> ugh, sorry, maybe i just need to read up more to override my old svn concept
<eridu> is there any way to coerce bzr into accepting filenames with backslashes
<jelmer> eridu: no, unfortunately not
<jelmer> eridu: there is an old bug report about this
<jelmer> eridu: http://pad.lv/81844
<ubot5> Launchpad bug 81844 in Bazaar "backslash in filename causes InvalidEntryName etc" [Medium,Confirmed]
<eridu> this breaks the git bridge for a project I want to hack on
<jelmer> it's a fairly hard bug to fix, there are assumptions in a number of places in bzr that / and \ are path valid path separators
<jelmer> well, perhaps not hard.. mostly just time-consuming I think :)
<eridu> why not os.path.sep?
<eridu> really I guess you'd want to forbid them in most cases but accept them if they appear
<SamB> it's a ROYALLY STUPID idea to EVER have \ in a path component
<jelmer> eridu: that means it becomes impossible to use some repositories on both Windows and POSIX/Mac
<eridu> SamB: I wouldn't have put it in, but this project literally has a file named '\'
<eridu> jelmer: I caught that just after sending it
<jelmer> ideally bzr should just use one path separator internally ("/"), and accept "\" as a path separator too on windows
<SamB> it is equally stupid to have / in a path component, of course, but since no major platform allows it ...
<jelmer> translating it from \ to / and from \ to / where necessary
<jelmer> but that means there are a fair number of code paths you have to update
<jelmer> SamB: I'm sure you can find a unicode character that looks enough like a forward slash if you really want to :)
<fullermd> That's what unicode is FOR, after all.  The old 7-bit ways of making confusing filenames are SO last century.
<jelmer> fullermd: ð
#bzr 2014-07-11
<shadeslayer> how can I remove a tag that I've already pushed to a remote branch?
<LeoNerd> tag --delete
<shadeslayer> did that, but the tag still exists in the remote
<shadeslayer> even though i did a push
<LeoNerd> You'll have to delete it in the remote
<shadeslayer> right, how?
<LeoNerd> -d URL  perhaps?
<shadeslayer> but, what action would that be?
<shadeslayer> bzr push -d ?
<shadeslayer> aha
<shadeslayer> it's --overwrite-tags
<Kees77> Alloha i had to restore my bazaar repo 3 times this week
<Kees77> i am in revision 999 now, but i cannot commit any more
<Kees77> it hangs during a commit
<Kees77> how can i fix this?
#bzr 2014-07-12
<AlexRussia> Hi! Does you have plugin/support import git/mercurial repositories?
<jelmer> AlexRussia: hi
<jelmer> AlexRussia: there is a plugin for importing git repositories, but it doesn't deal well with some newer git features and is unmaintained
#bzr 2017-07-10
<dorian_> Hey there. Is there a way to see a file at certain revision without updating the whole working tree ?
<dorian_> Something along the line of 'bzr show -r 123 path/my_file "
<fullermd> bzr cat
<dorian_> fullermd, thanks
#bzr 2017-07-12
<renatosilva> is there any config to specify the diff program to use for bzr diff, or can it be done only via --using?
<throstur> I did "bzr init ; bzr bind ...", then made changes, now I can't commit because readonly transport -- what do I need to do now?
<mgz> throstur: you can unbind them commit then push (to a non-readonly location)
<throstur> gotcha, worked binding to the bzr:// protocol x) was bound to http for some reason
#bzr 2017-07-13
<erry> How do i get qblame?
<erry> nevermind :p
