[00:12] <meoblast001> hi
[00:12] <meoblast001> i have 4 files that use 4 space indents and i want them to be 2 space indents.. would that be worth it in terms of VC efficiency?
[00:42] <lifeless> meoblast001: do you mean 'will the vc same much space if you use 2 space indents'?
[00:42] <lifeless> meoblast001: or 'how inefficient is the vc at storing a change from 4 space to 2 space indents
[00:42] <meoblast001> i mean, is it worth it to make this consistent on these 4 files and lose the efficiency
[00:43] <meoblast001> the sum of the 2 files is about 400 lines
[00:43] <meoblast001> or, 4 files
[00:43] <lifeless> worth it is up to you :)
[00:43] <lifeless> its c=going to cost about 400 bytes
[00:44] <meoblast001> 400 bytes? try 400 lines
[00:44] <meoblast001> right?
[00:44] <lifeless> 400 bytes, in 2a
[00:44] <meoblast001> 2a?
[00:44] <lifeless> the 2.0 default format
[00:44] <lifeless> if you're not using it yet, thats fine, when you upgrade it will compress it then
[00:44] <meoblast001> oh, so it only actually records changes byte for byte?
[00:44] <lifeless> yes
[00:44] <meoblast001> i use Ubuntu 9.04, which version do i use then?
[00:45] <lifeless> bzr --version
[00:45] <ScottK> 1.13
[00:45] <meoblast001> Bazaar (bzr) 1.13.1
[00:45] <meoblast001> does that mean i have to update now?
[00:45] <meoblast001> if i want to get the new optimization
[00:46] <SamB_XP> yeah ;-P
[00:46] <meoblast001> so if i previously did something like this, it will still remain in it's unoptimized form?
[00:48] <meoblast001> although my previous change was a rewrite of most of the source so it wouldn't really change
[00:48] <meoblast001> this time it's mainly just removal of those spaces
[00:50] <lifeless> when you do upgrade your repository, it will gain the benefits
[00:50] <SamB_XP> meoblast001: well, if/when you convert your repository to 2a, which maybe you'll want to do after you upgrade to 2.x, you'll get the goods
[00:50] <lifeless> there is no rush
[00:50] <meoblast001> ah, how does that work technically?
[00:50] <meoblast001> i sometimes don't believe things that sound too good to be true
[00:50] <lifeless> 'bzr upgrade' converts your data from one disk format to another
[00:51] <lifeless> we typically see repositories drop to 30% of their older size (once our gc kicks in and removes the rollback stuff we store in obsolete packs)
[00:52] <meoblast001> "disk format"?
[00:52] <SamB_XP> bzr supports a dizzying array of disk formats for repositories
[00:52] <ScottK> lifeless: Is there a significant speed difference between the 1.19 format and 2.0?
[00:52] <lifeless> ScottK: huge
[00:52] <lifeless> ScottK: there isn't a 1.19 format though, perhaps you mean 1.9?
[00:53] <ScottK> I mean the one immediately previous.
[00:53] <ScottK> Let me check
[00:53] <lifeless> in repo terms thats 1.9
[00:53] <SamB_XP> lifeless: you didn't up the default in 1.19 ?
[00:53] <lifeless> 1.14 as a label was actually a working tree change
[00:53] <ScottK> 1.14 actually
[00:53] <meoblast001> so how does it convert it from a format of detecting changes by lines to a format of changes by bytes?
[00:53] <lifeless> SamB_XP: we haven't done a 1.19 release :P
[00:54] <ScottK> Right, I mis-remembered.
[00:54] <lifeless> meoblast001: reads ins, writes out :P
[00:54] <lifeless> meoblast001: I'm not really sure what you're asking.
[00:54] <ScottK> lifeless: OK, so from 1.14, how huge?
[00:55] <meoblast001> well, if revisions 1 - 90 were made with 1.x, how would you convert those to 2.x
[00:55] <lifeless> ScottK: depends on what you're doing. Small trees and short histories the difference is swamped by startup time
[00:55] <meoblast001> they aren't the same format of revision logs
[00:55] <lifeless> meoblast001: 'bzr upgrade'
[00:55] <lifeless> ScottK: large trees, 'bzr commit' is something like 1/5 the duration; log -v is even more significantly improved.
[00:56] <meoblast001> so it magically figures out "oh, this whole line didn't need changed, only these 3 bytes needed to be"
[00:56] <ScottK> lifeless: bzr stat on the project I'm thinking of is currently taking 8 seconds with bzr.
[00:56] <lifeless> meoblast001: nothing magic about it, it converts the data
[00:57] <lifeless> ScottK: bzr st is entirely working tree; so its not going to change. However 8 seconds is about 8 times longer than stat on openoffice for me.
[00:57] <ScottK> Not sure if that qualifies as large, medium, or small.
[00:57] <ScottK> Hmmm.
[00:57] <ScottK> Interesting.
[00:57] <lifeless> ScottK: so there's a good chance something is wrong like:
[00:57] <ScottK> Thanks.
[00:57] <lifeless>  - missing C extensions
[00:57] <ScottK> OK.
[00:57] <lifeless>  - uncompiled/stale .pyc files causing just-in-time compilation
[00:57] <ScottK> Could the fact that it was imported from Git matter?
[00:57] <meoblast001> lifeless: but it still does exactly what i said in that quote, except in Python code?
[00:58] <lifeless> meoblast001: not really, it doesn't look at the old /changes/ at all.
[00:58] <ScottK> lifeless: We're operating from Ubuntu packages, so is there more was can do to make it faster?
[00:58] <lifeless> meoblast001: bzr doesn't model things by deltas, rather by the full content.
[00:58] <meoblast001> uh oh
[00:58] <meoblast001> bzr: WARNING: bzrlib version doesn't match the bzr program.
[00:58] <ScottK> Our resident git fanatic is still all over speed.
[00:58] <meoblast001> lifeless: what do you mean by deltas?
[00:58] <lifeless> ScottK: the packages should have the C extensions; I have seen python-* helpers blow up.
[00:59] <lifeless> meoblast001: don't worry about it, we're clearly not connecting :)
[00:59] <ScottK> OK.  Is there any docs on how to check into this?
[00:59] <lifeless> meoblast001: if you're interested in the exact details of the storage delta algorithm, have a look at group_compress in the bzr source for 2.0
[00:59] <meoblast001> but basically old revisions will be updated perfectly up to the new format?
[00:59] <lifeless> meoblast001: yes
[00:59] <meoblast001> ok :)
[00:59] <ScottK> Oops.  Noticed the time.  Need to run.
[00:59] <lifeless> ScottK: strace 'bzr st' on a empty tree
[00:59] <ScottK> OK
[01:00] <lifeless> bzr init; bzr st
[01:00] <ScottK> Thanks
[01:00] <lifeless> that will tell you the system minimum time to st
[01:00] <lifeless> ask a question on LP's answers thing, or on the list
[01:00] <lifeless> or back here, when you aren't running
[01:00] <meoblast001> anyways, i broke my bzr install
[01:00] <meoblast001> bzr: WARNING: bzrlib version doesn't match the bzr program. < that's the warning i get, followed by a crash
[01:01] <lifeless> meoblast001: what did you do?
[01:01] <meoblast001> make (did that on accident)
[01:01] <meoblast001> then i did sudo python setup.py install
[01:02] <lifeless> so, you've probably got two copies of 'bzr' on your path
[01:02] <SamB_XP> meoblast001: did you wait for it to *finish*?
[01:02] <meoblast001> yup
[01:02] <lifeless> and the first one on your path doesn't match the first bzrlib on your PYTHONPATH
[01:03] <meoblast001> PYTHONPATH is an environment variable?
[01:03] <SamB_XP> yeah
[01:03] <lifeless> its like PATH
[01:03] <lifeless> when PYTHONPATH is empty it has a default
[01:03] <meoblast001> i echo'd it, aparently i don't have one
[01:03] <meoblast001> ok
[01:03] <lifeless> you can see the effectice PYTHONPATH by doing
[01:03] <lifeless> python -c 'import sys; print sys.path'
[01:04] <lifeless> meoblast001: you should read the upgrade guide though
[01:06] <meoblast001> lifeless: what should that say?
[01:06] <SamB_XP> meoblast001: if he knew what it should say, he could have told you what to set PYTHONPATH to ;-P
[01:06] <meoblast001> ['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/Numeric', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/var/lib/python-support/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/var/lib/python-support/p
[01:06] <meoblast001> ython2.6/gtk-2.0', '/usr/local/lib/python2.6/dist-packages']
[01:07] <meoblast001> oops
[01:07] <meoblast001> i expected that to be 1 line
[01:07] <meoblast001> and not so, well, long
[01:07] <meoblast001> everything looks shorter in the terminal
[01:32] <meoblast001> lifeless: i just reinstalled again
[01:35] <zsquareplusc> i have a remote repository with several branches and "bzr branches" lists all of them. can i also pull all of them at once? "pull" does not seem to support that
[01:36] <meoblast001> am i supposed to install bzrlib seperately?
[01:36] <bob2> meoblast001: no
[01:36] <bob2> zsquareplusc: multi-pull plugin, not sure if it is maintained anymore
[01:37] <meoblast001> is the release candidate known to be broken?
[01:37] <bob2> oh, sorry, ignore me
[01:38] <meoblast001> ?
[01:53] <meoblast001> i honestly don't think it's installing bzrlib
[01:54] <lifeless> meoblast001: python -c 'import bzrlib; print bzrlib.__path__'
[01:54] <meoblast001> ['bzrlib']
[01:58] <meoblast001> lifeless: is that supposed to be an absolute directory?
[01:59] <meoblast001> lifeless: should i just install the debs?
[01:59] <meoblast001> although i'll never really get an understanding of what installing this from source is like if i do that
[02:00] <lifeless> meoblast001: that means its in your local directory
[02:00] <lifeless> cd somewhere else
[02:01] <meoblast001> lifeless: ['/usr/lib/python2.6/dist-packages/bzrlib']
[02:02] <lifeless> thats the packaged bzr
[02:03] <lifeless> which is your 1.13 or whatever version
[02:03] <lifeless> you might prefer the PPA rather than installing from source
[02:03] <meoblast001> should i remove the bzr package?
[02:03] <lifeless> anyhow, must go, back later
[02:03] <meoblast001> ok, ttyl
[02:08] <zsquareplusc> bob2: hm ok. its multi-pull contained in bzrtools, when i run it, it just lists *local* file URLs and tells me that these are no branches, even though i specified a remote repo
[02:09] <meoblast001> got it working
[02:13] <zsquareplusc> i wonder from where it takes that local paths, i want to do a fresh download and i'm in an empty directory
[02:22] <meoblast001> oh no
[02:22] <meoblast001> http://codepad.org/MIoiOxGQ
[02:22] <meoblast001> if i would have known upgrading to 2.0 would cause tons of problems, i wouldn't have done it
[02:23] <meoblast001> nvm, i'm an idiot
[02:35] <Colonel-Rosa> morning
[02:35] <meoblast001> good norning
[02:35] <meoblast001> morning*
[02:38] <Colonel-Rosa> does bazaar have a feature where it can work with multiple push locations, eg push production, push staging
[02:38] <meoblast001> you can push to 2 different locations if that's what you mean
[02:39] <Colonel-Rosa> right, but bazaar would only remember 1 at a time?
[02:39] <Colonel-Rosa> So I would have to keep typing in the other location
[02:39] <meoblast001> i'm not sure
[02:40] <Colonel-Rosa> alright, thanks
[03:22] <lifeless> Colonel-Rosa: you can create location bookmarks I believe, with the bookmark plugin
[03:48] <Colonel-Rosa> lifeless, I will check it out
[03:48] <Colonel-Rosa> Can not find any documentation for it though
[09:29] <vila> lifeless: lots of attempts to escape test isolation on OSX failures=84, errors=167 for tiger, failures=73, errors=167 for leopard, probably a single cause having to do with /tmp access rights though
[09:31] <vila> vila: pff, not even, it's the infamous /tmp is really /private/tmp on OSX...
[12:10] <aboSamoor> I am searching any resource to understand bzr split, any idea
[12:29] <dsuch> not exactly bzr-specific question but what have you guys used to be able to tab-complete the commands?
[12:29] <dsuch> I'd like to use something like that in my own Python application.
[12:30] <dsuch> Or is it something specific to Bash?
[12:31] <Kamping_Kaiser> if i understand you correctly, its a bash thing.
[12:31] <Kamping_Kaiser> look in /etc/bash_completion.d/ , you'll probably see a bzr script
[12:35] <dsuch> oh right, thanks Kamping_Kaiser
[12:35] <aboSamoor> is there anything wrong with this check http://paste.ubuntu.com/274091/ ?
[12:41] <dsuch> aboSamoor: sorry, can't help you, you'll need to wait a bit more
[12:43] <aboSamoor> dsuch: I am trying to learn how to use bzr split which I don't know how it can help me to answer my Q https://answers.launchpad.net/bzr/+question/83031
[12:43] <dsuch> aboSamoor: not really
[12:44] <aboSamoor> dsuch: no problem :)
[12:44] <dsuch> you'll just need to wait for someone more knowledgeable to join in
[13:19] <aboSamoor> ok, any idea which is the latest format ? is it 2a ?
[13:30] <dsuch> I think it is.
[14:15] <aboSamoor> does upgrading branch locally upgrade the format on the launchpad repository ?
[14:17] <dsuch> aboSamoor: I don't know but I would've created a test repo in a sandbox to test it out
[14:17] <dsuch> in fact, I'm interested in knowing it too :)
[14:18] <dsuch> aboSamoor: so I would appreciate it if you could tell me if it did
[14:18] <aboSamoor> dsuch: it is giving me errors
[14:18] <aboSamoor> so I will rollback then I will try to make a new branch and push it
[14:19] <dsuch> pastebin it somewhere and perhaps someone will know why it's giving you errors
[14:23] <aboSamoor> the error while trying to push the new format to launchpad
[14:23] <aboSamoor> http://paste.ubuntu.com/274143/
[14:24] <davidstrauss> aboSamoor: Upgrade the remote repo first
[14:25] <davidstrauss> aboSamoor: bzr upgrade --default-rich-root bzr+ssh://rmyeid@bazaar.launchpad.net/~rmyeid/%2Bjunk/code/
[14:25] <aboSamoor> davidstrauss: I am usign 1.18 because 2.0rc1 gave me errors and I am using 2a format
[14:26] <davidstrauss> aboSamoor: You shouldn't be using 2a for production use yet.
[14:27] <aboSamoor> davidstrauss: I asked this question https://answers.launchpad.net/bzr/+question/83031. and the answer was to use split.
[14:27] <aboSamoor> split needs rich root format, so I thought the best to upgrade to the future format so I won't do it again
[14:27] <davidstrauss> aboSamoor: A split branch has a rich root
[14:28] <davidstrauss> aboSamoor: you shouldn't upgrade to unstable formats
[14:28] <aboSamoor> davidstrauss: I see. can you please take a look at the question, so I am sure that I am in the correct path
[14:29] <davidstrauss> aboSamoor: I already said you should be using split.
[14:30] <aboSamoor> davidstrauss: I searched for explanation how split is working and how to use. My first VCS is bzr and I am not sure of the technical terms used
[14:30] <aboSamoor> but I did not find anything other than bzr help split
[14:30] <davidstrauss> aboSamoor: Split takes the current directory in the current branch and converts it into its own branch
[14:31] <aboSamoor> inside the same directory ? should I move outside the directory and push as new branch ?
[14:32] <davidstrauss> aboSamoor: right after running split in a directory, you can stay in that directory and push it as a new branch
[14:32] <fullermd> You should note though that split doesn't rewrite any history, so you're still carrying around the whole thing.
[14:33] <davidstrauss> fullermd: from before the split, yes
[14:35] <aboSamoor> davidstrauss: ok, I will do the following. 1-bzr check , 2-bzr reconcile 3-bze upgrade [not sure now what to use !], 4-bzr split dir1 5- cd dir1 6- bzr push
[14:35] <davidstrauss> aboSamoor: bzr upgrade --default-rich-root
[14:36] <davidstrauss> aboSamoor: Otherwise looks good
[14:36] <davidstrauss> aboSamoor: You can skip the reconcile if check doesn't find anything
[14:36] <aboSamoor> davidstrauss: I forgot to mention to use bzr upgrade --default-rich-root remote-repo before everything
[14:36] <davidstrauss> aboSamoor: Indeed
[14:37] <davidstrauss> aboSamoor: You could also pick --1.14-rich-root if you'd like the latest stable rich-root format.
[14:39] <davidstrauss> aboSamoor: make sense?
[14:40] <aboSamoor> now, I understand the big picture. I applied the default-rich root for the remote repo .  Waiting, it takes long time.
[14:41] <davidstrauss> aboSamoor: Yes, it takes quite a while
[14:43] <aboSamoor> davidstrauss: I reported bug 433039 while trying to use bzr 2.0rc1
[14:44] <davidstrauss> aboSamoor: Don't file those against the Ubuntu package. File them against the bzr project.
[14:47] <aboSamoor> davidstrauss: done, but don't know how to remove the ubuntu package from the "Affects" column
[14:47] <davidstrauss> aboSamoor: They'll have to
[14:47] <aboSamoor> davidstrauss: :-D, making mess all  the time
[14:48] <davidstrauss> aboSamoor: This was probably the bug you ran into: https://bugs.launchpad.net/bzr/+bug/422849
[14:49] <davidstrauss> aboSamoor: And I've marked yours as a duplicate
[14:49] <aboSamoor> davidstrauss: it was hard for me to figure that out, but the fix was released and I still have it !
[14:50] <davidstrauss> aboSamoor: but you were running rc1
[14:50] <aboSamoor> davidstrauss: yeah, it is released in RC2
[14:50] <aboSamoor> davidstrauss:  which I could not grab because of the build errors
[14:52] <aboSamoor> davidstrauss: by the way, this upgrade process is not friendly, no sign what is going on ! still blinking cursor :(
[14:52] <davidstrauss> aboSamoor: there should be a progress bar
[14:53] <aboSamoor> davidstrauss: http://paste.ubuntu.com/274159/
[14:54] <davidstrauss> aboSamoor: It doesn't give progress for making the backup
[14:54] <aboSamoor> davidstrauss: it was giving when I make the upgrade locally, but with the remote one no progress bar
[14:55] <davidstrauss> aboSamoor: that's because it's still copying the backup
[14:57] <fullermd> LP really needs an upgrade widget.  Doing it remotely is pure pain.
[14:57] <fullermd> It's probably much faster to dump the current branch there and push a new one fresh in the new format.
[15:00] <aboSamoor> fullermd: I don't think it is a good idea to cancel the process
[15:07] <aboSamoor> I got this message before the progress bar
[15:07] <aboSamoor> !!! [Hook] hook(): title not found
[15:09] <davidstrauss> aboSamoor: What's the full output?
[15:10] <aboSamoor> davidstrauss: http://paste.ubuntu.com/274169/
[15:10] <davidstrauss> aboSamoor: I'd ignore that. It didn't cause a backtrace, so it was handled.
[15:38] <aboSamoor> davidstrauss: after updating the remote repo. bzr check operation gave me this output http://paste.ubuntu.com/274179/
[15:41] <davidstrauss> aboSamoor: try running reconcile on it
[15:41] <davidstrauss> aboSamoor: wait
[15:41] <davidstrauss> Standalone tree (format: pack-0.92)
[15:41] <davidstrauss> aboSamoor: That looks un-upgraded
[15:41] <aboSamoor> davidstrauss: seems ok
[15:42] <aboSamoor> I upgraded only the remote repo only
[15:42] <davidstrauss> aboSamoor: did that succeed?
[15:42] <aboSamoor> I did not upgrade the local one
[15:43] <aboSamoor> davidstrauss: http://paste.ubuntu.com/274184/
[15:43] <davidstrauss> aboSamoor: OK. Does check succeed now?
[15:44] <aboSamoor> davidstrauss: nothing changed after the reconcile
[15:45] <aboSamoor> the check operation still gives the same output
[15:47] <davidstrauss> aboSamoor: can you just get a fresh branch from the remote (upgraded) branch?
[15:48] <aboSamoor> yeah, if I understand that I should branch the current repo
[15:49] <davidstrauss> aboSamoor: yeah
[15:49] <davidstrauss> aboSamoor: easier to do that than upgrade both
[15:51] <aboSamoor> davidstrauss: I did the branching, bzr info gives me Standalone tree (format: rich-root-pack)
[15:52] <davidstrauss> aboSamoor: sounds right
[15:52] <aboSamoor> davidstrauss: I will delete the old branch from my desktop, and I will start to split the folders
[15:52] <davidstrauss> k
[16:04] <flvr8> hello all... what's the "bzr way" to move a directory between two (unrelated) branches but maintain revision control of that folder? [the branches are projects; the folder is a module; the module is "graduating" to a more general project]\
[16:17] <davidstrauss> flvr8: split, mv (not bzr mv), and then join
[16:17] <davidstrauss> flvr8: But upgrade your branch first: bzr upgrade --default-rich-root
[16:19] <flvr8> so...    cd Project1 && bzr split mymodule   //    bzr mv mymodule bzr+ssh://somewhere/Project2/trunk     //     cd ../Project2 && bzr update    //    bzr join mymodule    ?
[16:20] <davidstrauss> flvr8: do not bzr mv. just mv
[16:20] <flvr8> oh
[16:20] <flvr8> ok
[16:20] <flvr8> thanks
[16:21] <davidstrauss> flvr8: and you need to do the mv and join locally
[16:21] <flvr8> is there an parallel operation for individual files?
[16:21] <davidstrauss> flvr8: other than moving a file into a directory of its own and doing a split+join, i don't know of a way to take a file's history from one branch to another
[16:21] <flvr8> k
[16:22] <davidstrauss> flvr8: make sure you read all the split+join docs first. what you're doing is quite advanced
[16:23] <flvr8> will do, thanks
[16:46] <aboSamoor> davidstrauss: everything works fine, thanks very much :)
[16:47] <davidstrauss> aboSamoor: :-D
[17:11] <flvr8> davidstrauss: it seems to be getting stuck doing "inserting stream" after doing the above and then add/commit... it's uploaded 300MBs (of something) to the server so far (the module is fairly small); i do not see a similar growth in disk space on the server
[17:12] <davidstrauss> flvr8: Commits are streamed to memory before being committed to disk, AFAIK.
[17:12] <davidstrauss> flvr8: But I have to go. I'll be back online later this weekend. Not sure when. Consider posting your question to http://answers.launchpad.net/bzr
[17:12] <flvr8> ok, thanks
[17:25] <vila> flvr8: just passing around, no time to double check, but keep in mind that join/split still keep the while history (or you wouldn't be able to merge from before split otherwise) so that may explain the volumes you see
[17:26] <flvr8> ah ok
[17:35] <SamB_XP_> hmm, I really like the repoalias plugin ...
[17:56] <blueyed> Are there things planned to make conflict resolving better? BeyondCompare can resolve a lot more conflicts then bzr. Maybe just because of content inspection? (it handles files in different charsets, which bzr does not, ie a file gets converted to another charset in the deriving branch).
[18:05] <james_w> blueyed: that would be good
[18:05] <james_w> blueyed: but check the extmerge plugin
[18:05] <james_w> you can use an external tool, e.g. BeyondCompare to resolve conflicts
[18:06] <blueyed> oh well.. I have a bc-resolve-conflict(s) shell script already. I'll check it out.
[18:08] <blueyed> james_w: should I file a wishlist bug about encoding ambivalence in comparisons? Might you want to just file it (you now more of the inners)? (Link: https://bugs.launchpad.net/bzr/+filebug ;))
[18:09] <blueyed> extmerge is nice, should get added to the core.. :)
[18:10] <blueyed> btw: my script asks about resolving the conflict, when coming back.. I'll forward that as an idea
[18:14] <james_w> please file bugs for anything you think could be improved
[18:14] <james_w> you're in a better place to file than me as you know what you want to happen
[19:37] <Colonel-Rosa> lifeless, thank you for the bzr-bookmarks recommendation yesterday, was what I needed.
[19:37] <Colonel-Rosa> ta
[20:17] <RenatoSilva> Is it possible to directly push a merge directive to launchpad?
[20:18] <RenatoSilva> I mean, instead of pulling from it, then pushing the branch, you'd push the patch, and then pull the changes
[23:32] <lifeless> vila: if they need protecting, they aren't innocent ;)
[23:32] <vila> lifeless: ok, that was you and me :-D
[23:34] <lifeless> vila: and jam and poolie that reviewed ;P
[23:35] <vila> lifeless: ow, that's rude :)
[23:39] <vila> lifeless: by the way, even if t was for a wrong reason, you trapped ~130 tests that were trying to escape isolation, not so bad...
[23:40] <lifeless> vila: they were?
[23:40] <vila> that's what make them failed yes
[23:40] <lifeless> cool
[23:40] <lifeless> uhm
[23:40] <lifeless> I excluded /tmp because ETOOHARD
[23:41] <vila> but you caught TESTROOT, based on tmp
[23:41] <vila> or was it test_dir ?
[23:41] <vila> babune has the logs if you're interested anyway
[23:45] <lifeless> vila: maybe tomorrow; can you link the build in the bug?
[23:45] <lifeless> vila: oh maybe I misremember stuff
[23:45] <vila> lifeless: yup, I wanted to add some info there if only for historical value, I'll do that right now
[23:45] <lifeless> vila: anyhow, its good that the things that have failed are legitimate escape attempts.
[23:46] <lifeless> vila: I thought by the way you described it that it was an isolation-checking bug
[23:46] <vila> lifeless: yes, they *look* like legitimate attempts but it's just an aliasing problem (/private/tmp is not inside /tmp, but in fact they are the same)
[23:47] <lifeless> urgle
[23:47] <lifeless> so we have to permit /private/tmp when we see /tmp ?
[23:47] <lifeless> because realpath is /private/tmp ?
[23:54] <wgrant> bzr-beta-ppa just tried to give me 2.0rc1 (karmic i386). That seems like a really bad idea.
[23:55] <vila> lifeless: no, by using realpath early, we just have to permit /private/tmp and be done with the problem
[23:57] <lifeless> wgrant: its a terrible idea
[23:58] <vila> lifeless, wgrant : bug #432390
[23:58] <wgrant> vila, lifeless: Somebody might want to delete 2.0rc1 from it?
[23:58] <wgrant> I think nothing is better than 2.0rc1.