[00:00] <AfC> Good morning
[00:02] <ckontros> james-w: Could you look into this for us. It's gonna make it damn hard for the  Studio team to hit the ground running for Oneiric. :) I'm unsure why this was done in the first place. I might not be around when you are so I'll have ScottL (current Studio lead) catch up with you.
[00:04] <ckontros> Darn. Did the name wrong. james_w` ^^^
[00:06] <ckontros> lifeless: Thanx to the help. I'll get it sorted.
[07:36] <jam2> morning all
[07:38] <lifeless> jelmer: :( I didn't fix the build after all
[07:38] <lifeless> jelmer: (subunit dailies)
[07:44] <vila> hi all !
[07:44] <vila> jam, jelmer, spiv: stand up ?
[07:44] <jam> vila: in 1 hour
[07:44] <jam> I would guess jelmer isn't awake yet, but I could be wrong
[07:45] <vila> 8:00 UTC ?
[07:45] <vila> spiv: is that ok for you ?
[07:45] <jam> vila: that is what the schedule says
[07:45]  * vila nods
[07:45] <jam> I'm usually not on until 7:00, but I'm here now
[07:46] <vila> doesn't mean we can't adjust ;)
[07:46] <jam> So today I'm fine moving it
[08:05] <spiv> vila, jam: if jelmer's around, now suits me
[08:05]  * vila acks
[08:05] <jam> same here, but I think jelmer is still sleeping
[08:05] <spiv> Otherwise I'll head afk for a bit and be back for the standup
[08:05] <jam> is poolie gone today, then?
[08:05] <vila> yup
[08:07] <Peng> vila: pm?
[08:07] <vila> Peng: sure
[08:15] <Kaleetos> I'm having some trouble installing bazaar on my computer, anyone available to help me out?
[08:17] <vila> Kaleetos: OS/bzr versions ?
[08:18] <Kaleetos> i'm on mac os 10.5-- bazaar 2.3.1. It installs but when I try to run the bzr it tries to execute from a version of python I don't have anymore (2.5)
[08:18] <spiv> vila, jam: see you in 40 minutes or so.
[08:18] <vila> spiv: ack
[08:18] <Kaleetos> is there a way for me to have bazaar execute from 2.6
[08:18] <vila> Kaleetos: you deleted the OSX provided python ?
[08:19] <Kaleetos> as per the instructions on python.org, yes
[08:19] <vila> Kaleetos: hmm, interesting, do you an URL for that ?
[08:19] <vila> s/you/you have/
[08:19] <Kaleetos> this was a long while ago when i was having problems with programs defaulting to the 2.5
[08:20] <Kaleetos> http://docs.python.org/using/mac.html
[08:20] <Kaleetos> section 4.1
[08:20] <Kaleetos> the second bullet point
[08:20] <vila> Kaleetos: yup, reading
[08:22] <vila> so, I wasn't aware of that but it's interesting, see bug #776523 for a related issue (a bit reversed to yours but your experience may help decide on how to fix it)
[08:22] <vila> Kaleetos: now, what is the precise issue you're having ?
[08:23] <vila> i.e. what does 'bzr version' says ?
[08:23] <Kaleetos> vila-- if its necessary I can put that version of python right back where it was (i stored backups), it just causes headaches when running certain programs
[08:23] <Kaleetos> whenever i run bzr anything it says this: -bash: /usr/local/bin/bzr: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/: bad interpreter: No such file or directory
[08:24] <vila> ok, and what does the first line in /usr/local/bin/bzr says ?
[08:25] <Kaleetos> -bash: usr/local/bin/bzr: No such file or directory
[08:25] <vila> Kaleetos: the first line *in* the script
[08:25] <Kaleetos> i'm sorry-- i have no idea what that means =(
[08:26] <Kaleetos> what script?
[08:26] <vila> Kaleetos: 'head /usr/local/bin/bzr' will display the first few lines in the script
[08:27] <Kaleetos> # Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Canonical Ltd
[08:27] <Kaleetos> that?
[08:27] <vila> just a sec, searching for a 10.5 mac
[08:28] <vila> no, not that, a line starting with #!
[08:28] <Kaleetos> #!/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
[08:29] <vila> yup, that one
[08:29] <vila> this instructs OSX to use the python located at that path
[08:29] <Kaleetos> ahh. so just change that path and thats it?
[08:30] <vila> that would be a first try but there could be fallouts
[08:30] <Kaleetos> well before i do that
[08:30] <Kaleetos> I'm going to put that backup of 2.5 back in place to see what happens
[08:32] <Kaleetos> would it matter much if I was running bazaar on the older version of python?
[08:32] <vila> if you put your backup back in place, everything should be fine
[08:32] <vila> Kaleetos: quite the contrary, the installer is build against the system provided version
[08:32] <vila> built
[08:33] <Kaleetos> oh ok
[08:33] <vila> Kaleetos: out of curiosity, do you plan to upgrade your mac to 10.6 or 10.7 ?
[08:34] <Kaleetos> when money permits
[08:34] <Kaleetos> i would love to now, but I don't have the money and I'd rather not deal with upgrading this old guy
[08:34] <Kaleetos> I want to get a new mac
[08:34] <vila> which model is it ?
[08:34] <Kaleetos> macbook pro
[08:35] <Kaleetos> ok so now I'm getting this message
[08:35] <Kaleetos> should I paste it right in here or do you guys have a pasting page?
[08:36] <vila> !paste
[08:36] <Kaleetos> http://paste.ubuntu.com/603135/
[08:39] <vila> Kaleetos: the installer should have installed bzrlib in /Library/Python/2.5/site-packages/bzrlib
[08:39] <Kaleetos> hm... i'll reinstall
[08:39] <vila> Kaleetos: either it's not there anymore or some other setting (PYTHONPATH ?) is borked
[08:40] <vila> re-installing is the safest route
[08:40] <Kaleetos> nope, same deal
[08:40] <vila> do you have /Library/Python/2.5/site-packages/bzrlib ?
[08:44] <Kaleetos> hmm no. and according to my backups I haven't had a Library/Python since October(before I started using python)
[08:45] <Kaleetos> I don't even see a library/python directory now
[08:45] <vila> weird
[08:46] <vila> are you sure you'looking at /Library not /Users/xxx/Library ?
[08:46] <Kaleetos> maybe the backups don't save that particular directory?
[08:46] <Kaleetos> !
[08:46] <Kaleetos> sorry,
[08:46] <Kaleetos> yup all there
[08:47] <Kaleetos> including the bzrlib
[08:48] <vila> ha, better
[08:48] <Kaleetos> should I manually add that directory into the PYTHONPATH?
[08:48] <vila> you shouldn't have to
[08:49] <vila> try: python -v /usr/local/bin/bzr
[08:50] <Kaleetos> same error
[08:51] <vila> pastebin output ?
[08:52] <Kaleetos> !paste
[08:52] <Kaleetos> http://paste.ubuntu.com/603140/
[08:53] <vila> you're using 2.6
[08:53] <Kaleetos> yes
[08:54] <Kaleetos> is it seraching in 2.6 now?
[08:54] <Kaleetos> lol
[08:54] <vila> but /usr/local/bin/bzr points to 2.5 so using this script should do the right thing, try python2.5 -v /usr/...
[08:56] <Kaleetos> python2.5 -v /usr/...
[08:56] <Kaleetos> oops hold on
[08:57] <Kaleetos> http://paste.ubuntu.com/603141/
[08:57] <vila> use the full path to the bzr script, I was lazy ;)
[08:57] <Kaleetos> OH
[08:57] <Kaleetos> hahaha
[08:57] <vila> :)
[08:59] <Kaleetos> this directory right? /usr/local/bin/bzr/
[08:59] <vila> this file  /usr/local/bin/bzr
[08:59] <vila> no trailing /
[09:00] <Kaleetos> yea just figrued that out heh. ok so it did a bunch of stuff, should i paste that?
[09:00]  * jelmer waves
[09:00] <vila> if it doesn't end with the list of basic bzr commands, yes, paste the output
[09:00] <Kaleetos> http://paste.ubuntu.com/603143/
[09:02]  * vila scratches head
[09:03] <vila> Kaleetos: python2.5 -c 'import sys; print sys.path'
[09:04] <Kaleetos> http://paste.ubuntu.com/603144/
[09:05] <vila> Kaleetos: otp, be back later
[09:05] <Kaleetos> ok
[09:06] <jelmer> vila: can you hear me?
[09:06] <vila> jelmer: yes, but you don't seem to hear me ;)
[09:07] <Kaleetos> vila when you get back here is a copy of my bash_profile: http://paste.ubuntu.com/603145/
[09:07] <Kaleetos> incase maybe something is wrong in there
[09:18] <spiv> vila: http://package-import.ubuntu.com/status/67061a280d79e806c089681dd8b4a524.html
[09:34] <jelmer> jam, vila: did somebody say they were going to review spiv's branch?
[09:35] <jam> jelmer: the one he just put up? I already reviewed it
[09:35] <jam> was there another one?
[09:35] <jelmer> jam: Yeah, the parents provider smart request one.
[09:36] <jam> I looked at it
[09:36] <chriscauser> vila: Many thanks for the tip (about wt.has_changes().) It seems to shave about .1 second off the script running time (.5 seconds to .4). Unfortunately, it doesn't seem to check for unknowns. Is there a similar method to check if the tree has unknowns? (I can't seem to find one.)
[09:36] <jelmer> jam: I haven't seen your reply yet, I guess Launchpad is still in read only mode
[09:39] <vila> chriscauser: glad you see my message, you were gone when I posted it
[09:39] <vila> chriscauser: as for unknowns, let me check
[09:39] <chriscauser> vila: Yeah, I went back and checked just now in case I'd missed anything
[09:42] <Kaleetos> question. If I write a python script containing this : print os.environ['PYTHONPATH'].split(os.pathsep)  ---(after importing os)--- and run it through terminal, shouldn't I get back the PYTHONPATH?
[09:43] <vila> chriscauser: if wt.unknowns() should do
[09:44] <vila> Kaleetos: yes, but better use sys.path which will already include PYTHONPATH
[09:44] <chriscauser> vila: Thanks. That was what I was originally using. The only problem with that is that it doesn't shortcircuit (i.e. It finds all unknowns, even though it returns an iterator)
[09:44] <Kaleetos> hm.. when I do exactly that, i'm getting a key error
[09:45] <vila> Kaleetos: exactly what ? The snippet above ?
[09:45] <Kaleetos> i created a script called test.py containing what I wrote above
[09:45] <Kaleetos> then i run it through terminal and i get a key error
[09:46] <Kaleetos> if i run it through textmate's built in terminal i get a PYTHONPATH referring to the textmate installation
[09:46] <Kaleetos> but directly through terminal gives the key error
[09:47] <chriscauser> Kaleetos: What happens when you type in 'export PYTHONPATH="/imaginary:/second_imaginary"'' before running from the terminal?
[09:48] <vila> echo $PYTHONPATH ?
[09:48] <vila> python -c 'import os; print "\n".join(os.environ["PYTHONPATH"].split(os.pathsep))' works fine here
[09:48] <vila> or python2.5 -c 'import os; print "\n".join(os.environ["PYTHONPATH"].split(os.pathsep))' works fine here
[09:48] <vila> in your case
[09:49] <Kaleetos> the echo thing just shoots back a question mark
[09:49] <Kaleetos> chris, should I copy and paste that exactly?
[09:50] <chriscauser> Kaleetos: Everything in the double quotes exactly
[09:50] <vila> Kaleetos: python2.5 -c 'import sys; print "\n".join(sys.path)'
[09:50] <Kaleetos> and vila
[09:50] <Kaleetos> i get the same key error
[09:50] <Kaleetos> the last thing u gave me worked
[09:50] <chriscauser> Kaleetos: * single quotes
[09:50] <vila> Kaleetos: then PYTHONPATH is not in your environment, 'env' will tell you what is defined
[09:52] <Kaleetos> chris, I get the same keyerror
[09:53] <vila> Kaleetos: because PYTHONPATH is not in your env, try the 'env' command in a terminal without the single quotes
[09:53] <Kaleetos> !paste
[09:54] <Kaleetos> http://paste.ubuntu.com/603163/
[09:54] <vila> Kaleetos: right, no PYTHONPATH there
[09:54] <Kaleetos> is that the problem?
[09:54] <vila> python2.5 -c 'import sys; print "\n".join(sys.path)'
[09:55] <vila> Kaleetos: you shouldn't have to modify PYTHONPATH, /Libray/blah blah should already be added automatically by python, if it's not, something weird is going on
[09:56] <Kaleetos> perhaps i broke something at some point?
[09:56] <Kaleetos> http://paste.ubuntu.com/603165/
[09:57] <vila> ls -l /Library/Python/2.5/site-packages
[09:58] <Kaleetos> http://paste.ubuntu.com/603167/
[10:03] <vila> can you re-paste the output of: python2.5 -c 'import sys; print "\n".join(sys.path)'
[10:03] <vila> meh, nm
[10:04] <vila> Kaleetos: the weird thing here is that you have site-packages directories below /System instead of /Library
[10:04] <Kaleetos> what would happen if i tried installing the osx10.6 bazaar in my 10.5 (because 10.6 bazaar installs to python 2.6). would that create all sorts of disaster?
[10:05] <chriscauser> vila: I've pushed your suggestion to lp. Thank you so much for the help. I hope the script will be of use to other people.
[10:06] <vila> Kaleetos: that's would be a useful experiment, it may well work
[10:07] <Kaleetos> or what about installing the version intended for osx 10.4 (designed specifically for python 2.6 downloaded directly from python.org)
[10:07] <vila> Kaleetos: try un-installing the 10.5 version first if only to limit the clutter
[10:07] <Kaleetos> ok
[10:07] <vila> Kaleetos: there two things here, python install and bzr install
[10:08] <vila> Kaleetos: AFAIK, the bzr installers assume that you're using the system installed python but I don't think they check
[10:08] <Kaleetos> the OS is not relevant?
[10:08] <vila> well, the OS is indirectly relevant
[10:08] <vila> AFAIK it's python version that matters
[10:09] <Kaleetos> ok, i'll try to install the one for 10.6
[10:11] <Kaleetos> the uninstaller doesn't work for me =/
[10:11] <Kaleetos> any other options?
[10:15] <vila> Kaleetos: :-/
[10:15] <Kaleetos> ...
[10:15] <Kaleetos> ok so 10.6's installed
[10:15] <Kaleetos> and same thing
[10:16] <vila> for which value of same ? ;D
[10:16] <Kaleetos>  same != good
[10:16] <vila> right, that leave many possible causes opened :)
[10:17] <Kaleetos> i've been trying to get this to work for so long
[10:17] <vila> I'm starting to suspect that the OSX python and the python.org python may have different ideas about how sys.path is built...
[10:17] <vila> Kaleetos: *what* is failing with the 10.6 one ?
[10:18] <vila> Kaleetos: keep in mind that we have many users on both 10.5 and 10.6 with working setups so I'm trying to help you find what is different in *your* setup and how the installers can be fixed...
[10:18] <Kaleetos> i get the same "please check the directory containing bzrlib is in your PYTHONPATH"
[10:19] <vila> then paste the sys.path output for 2.6
[10:19] <lifeless> jelmer: hi
[10:19] <lifeless> jelmer: what do you think is the right way to fix the subunit recipe
[10:19] <Kaleetos> i understand, i'm just worried maybe i broke something when i first installed python 2.6
[10:20] <Kaleetos> !paste
[10:21] <Kaleetos> http://paste.ubuntu.com/603180/
[10:21] <Kaleetos> http://paste.ubuntu.com/603182/
[10:22] <Kaleetos> sorry, second one is easier to read
[10:24] <vila> ls -l /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
[10:24] <vila> and
[10:25] <vila> ls -l /Library/Python/2.6/site-packages
[10:25] <Kaleetos> http://paste.ubuntu.com/603184/
[10:26] <vila> Kaleetos: ls -l /Library/Python/2.6/site-packages
[10:28] <Kaleetos> http://paste.ubuntu.com/603185/
[10:28] <vila> here we are :)
[10:29] <vila> ok, so indeed, sys.path is built differently
[10:29] <vila> which explain both failures
[10:29] <vila> so, PYTHONPATH is indeed the way to fix that
[10:30] <Kaleetos> i hope you know how to do that too, because I sure don't :)
[10:31] <vila> so, let's start with what is installed currently:
[10:31] <vila> head /usr/local/bin/bzr
[10:31] <Kaleetos> #!/usr/bin/python
[10:31] <vila> arf :)
[10:31] <vila> python -V
[10:31] <vila> err
[10:31] <vila> /usr/bin/python -V
[10:32] <Kaleetos> Python 2.6.6
[10:32] <vila> so
[10:32] <Kaleetos> to the second
[10:32] <Kaleetos> Python 2.5.1
[10:32] <vila> ha
[10:33] <vila> err, that's weird but let's see if we can deal with that:
[10:33] <vila> PYTHONPATH=/Library/Python/2.5/site-packages bzr version
[10:34] <Kaleetos> it paused for a second and then printed out some text from bazaar
[10:34] <vila> rhaaaa no
[10:34] <vila> err, yes
[10:35] <vila> good that text should mention bzrlib: a_path_here
[10:35] <vila> a_path_here should be /Library/Python/2.5/site-packages/bzrlib
[10:35] <Kaleetos> http://paste.ubuntu.com/603186/
[10:36] <vila> Kaleetos: pfew, here we are
[10:36] <vila> so, the "funny" thing is that you're using the bzr script installed for 10.6 but still using the bzrlib installed for 10.5
[10:37] <vila> since the script is the same except for the #! line, it doesn't really matter
[10:37] <Kaleetos> well that would have only occurred just now when I installed the 10.6 version right?
[10:37] <vila> yes
[10:38] <vila> now you need to set the proper PYTHONPATH which is tricky since you still want to use 2.6 for other reasons, so let's try something else:
[10:39] <vila> first, change the first line in the bzr script by adding '2.6': /usr/bin/python2.6 then try
[10:39] <vila> PYTHONPATH=/Library/Python/2.6/site-packages bzr version
[10:39] <Kaleetos> wait.. how do i change the bzr script?
[10:39] <vila> with a text editor
[10:40] <vila> which one do you use usually ?
[10:40] <Kaleetos> textmate
[10:40] <vila> ha, you may need admin access
[10:40] <chriscauser> vila, Kaleetos: Sorry to butt in, but perhaps a bash alias could help here? (eg. "alias bzr='PYTHONPATH=/Library/Python/2.5/site-packages /usr/local/bin/bzr")
[10:40] <vila> do you know how to launch textmate as an admin ?
[10:41] <vila> chriscauser: worth a try
[10:41] <Kaleetos> no i don't
[10:41] <chriscauser> Sorry guys, I'm messing up my quotes here
[10:41] <vila> alias bzr ='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr
[10:41] <Kaleetos> should i paste that then?
[10:41] <vila> alias bzr ='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr'
[10:42] <vila> Kaleetos: startup a fresh terminal so we better control where the alias is defined
[10:42] <Kaleetos> it says not found
[10:42] <chriscauser> *"alias bzr='PYTHONPATH=/Library/Python/2.5/site-packages /usr/local/bin/bzr'"
[10:42] <Kaleetos> double or single quotes
[10:43] <vila> chriscauser: nope, we want the 2.6 version so specifying python2.6 ignores the #! line
[10:43] <chriscauser> Everything in the double quotes
[10:43] <chriscauser> vila: Sorry. I was just trying to correct my quoting rather than anything else
[10:43] <vila> chriscauser: np :)
[10:43] <chriscauser> Kaleetos: Do what vila says only remove the space between bzr and =
[10:44] <vila> argh, good catch ;)
[10:44] <Kaleetos> should it be 2.5 or 2.6?
[10:44] <vila> alias bzr='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr'
[10:45] <Kaleetos> can i just say
[10:45] <Kaleetos> that i love both you
[10:45] <Kaleetos> ITS WORKING FINALLY
[10:45] <Kaleetos> !!!!
[10:45] <vila> almost
[10:45] <Kaleetos> ...
[10:45] <Kaleetos> joy kill
[10:45] <Kaleetos> lol
[10:45] <vila> now you need to record that alias to avoid typing it every time you want to use it
[10:46] <Kaleetos> how do i do that?
[10:47] <Kaleetos> by record are you talking some special command I don't know about, or just copy and paste it into a text file for future reference
[10:48] <vila> ha, good question, I can never remember which file is right for that on OSX to cover all cases
[10:48] <vila> Kaleetos: I mean adding it to a file that all shells will read so you don't have to type it again
[10:49] <vila> it's one of .profile, .bashrc or .bash_profile
[10:49] <vila> Kaleetos: to you have one of those in your home directory ?
[10:49] <Kaleetos> i have the bash_profile
[10:50] <Kaleetos> its open in the terminal for editing now
[10:50] <vila> then just add that alias command there
[10:50] <vila> save the file and start a new terminal
[10:51] <Kaleetos> it worked
[10:51] <vila> pfew
[10:51] <vila> Kaleetos: *now* you can rejoice ;)
[10:51] <Kaleetos> thank you so much for your patience, and thank you chris for that solution
[10:52] <Kaleetos> i'm rejoicing by downloading what i've been trying to get for all these hours lol
[10:52] <vila> Kaleetos: it would help if you could file a bug explaining your issue, setup and workaround
[10:52] <vila> https://launchpad.net/bzr-mac-installers/+filebug
[10:53] <Kaleetos> sure I'll do that. Although I'm not sure if it was a bug, my removing the built in insallation of macpython and then putting it back might have broken something. So maybe it was a one time issue
[10:53] <vila> Kaleetos: the root issue is that the installers don't play well with pythons installed on top of the system one but there should be a way to address that without forcing the users to define an alias
[10:54] <vila> Kaleetos: I'm afraid your setup is a bit unclean by now and sorting that out may be tricky
[10:54] <vila> Kaleetos: keep an open eye about weird behaviors still, read your ~/.bzr.log if in doubt for further clues
[10:55] <Kaleetos> ok
[10:56] <Kaleetos> well one thing i wanted to ask actually
[10:56] <Kaleetos> when i installed the 10.6 version, the action was set to "update"
[10:56] <Kaleetos> I'm guessing that would have over written a significant amount if not all of the previous installation?
[10:58] <vila> Kaleetos: hmm, if you still have /Library/Python/2.5/bzrlib (and I think you do), then file *another* bug for that
[10:59] <Kaleetos> yup i do
[10:59] <Kaleetos> so i should write a bug stating that the update did not remove the previous install
[10:59] <vila> yup
[11:00] <vila> if only because you asked here ;)
[11:00] <Kaleetos> i have 3 different copies of bzr lib in here now 0.0
[11:00] <vila> 3 ?
[11:00] <vila> where ?
[11:01] <Kaleetos> "/Library/Python/2.6/site-packages/bzrlib"
[11:01] <Kaleetos> "/Library/Python/2.5/site-packages/bzrlib"
[11:02] <vila> that's the two I was expecting :)
[11:02] <vila> where is the third ?
[11:02] <Kaleetos> oh no, one of them was being repeated in my file search for some reason
[11:03] <Kaleetos> i just closed the finder window and tried again
[11:03] <Kaleetos> its only 2
[11:03] <vila> pfew
[11:03] <vila> I prefer that ;)
[11:03] <Kaleetos> should i leave the copies alone or can i delete one(whichever one not being used preferably lol)
[11:04] <vila> another way to address the problem could to create a symlink in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
[11:05] <vila> to tell the python.org python about the bzrlib installed by the OSX 10.6 installer
[11:05] <vila> the alias won't be needed then and this may be more robust than the alias
[11:06] <vila> Kaleetos: you could probably delete the 2.5 one
[11:09] <Kaleetos> hmm i just noticed
[11:09] <Kaleetos> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
[11:09] <Kaleetos> i'm getting that warning when i load bzr
[11:09] <vila> that's bad
[11:10] <Kaleetos> anything I can do about that?
[11:11] <vila> bzr version
[11:11] <vila> again ?
[11:12] <vila> the extensions are .so files in the bzrlib directory
[11:12] <Kaleetos> http://paste.ubuntu.com/603203/
[11:13] <vila> they enhance the performances but we provide python fallbacks so it's a problem only if you're dealing with big projects
[11:13] <Kaleetos> I see the .so files, are they supposed to be associated with WINE?
[11:14] <Kaleetos> they're all whine bottles
[11:14] <vila> noo, they are regular .so OSX files
[11:14] <Kaleetos> well whine has decided to take over the show for me
[11:14] <Kaleetos> lol
[11:14] <vila> Kaleetos: any more details in ~/.bzr.log (~ is a shorcut for /Users/Carlitos
[11:14] <jelmer> lifeless: sorry, missed that earlier - looking at the recipe now
[11:15] <Kaleetos> i get permission denied without sudo
[11:15] <Kaleetos> and command not found with sudo
[11:15] <jelmer> lifeless: the previous packaging branch probably patched debian/rules to always run the autotools chain
[11:18] <spiv> jam: an idea that just occurred to me for "bzr branch --stacked"
[11:18] <jam> ?
[11:18] <spiv> jam: BzrDir.sprout, which would do the fetch, also knows if it needs to create a working tree
[11:18] <vila> Kaleetos: it's a text file, open it with a text editor
[11:19] <vila> Kaleetos: it's the bzr log file
[11:19] <spiv> jam: in which case it may as well fetch the tree contents up front, because that data is going to be needed anyway
[11:20] <spiv> jam: so it wouldn't make "bzr push" of a new stacked branch any larger, but would make "bzr branch --stacked $remote local" more efficient
[11:20] <jam> interesting idea
[11:22] <Kaleetos> i can't find that file vila
[11:22] <Kaleetos> is it hidden in the folder?
[11:22] <vila> Kaleetos: yes, it starts with a dot (.) so the finder doesn't show it by default
[11:24] <Kaleetos> got it
[11:24] <lifeless> jelmer: my packaging rules had
[11:24] <lifeless>         [ -f configure ] || autoreconf -fi
[11:24] <lifeless> jelmer: (in debian, not just recipes)
[11:25] <Kaleetos> vila: you want a copy of the whole the
[11:25] <jelmer> lifeless: in clean: ?
[11:25] <Kaleetos> *the whole thing
[11:25] <jelmer> lifeless: that's the only target that gets run by the recipe builder
[11:26] <vila> Kaleetos: only the end should be relevant i.e. the last few commands
[11:28] <Kaleetos> there's a snipit of the en
[11:28] <Kaleetos> *end
[11:29] <lifeless> jelmer: build:
[11:29] <lifeless>         [ -f configure ] || autoreconf -fi
[11:29] <lifeless>         INSTALLDIRS=vendor $(DH) build
[11:29] <lifeless> clean:
[11:29] <lifeless>         make distclean || true
[11:29] <lifeless>         rm -f configure
[11:29] <lifeless> jelmer: so clean will trigger the rules to build when the package itself is built
[11:29] <Kaleetos> and bzr is not working for me :( I'm trying run a command to download some files, but I'm getting this: ERROR: Unable to import library "subvertpy": bzr-svn: Unable to load subvertpy extensions.....
[11:29] <lifeless> jelmer: I suspect this is also lost in your changes
[11:29] <jelmer> lifeless: there's no dependency on build in clean?
[11:30] <lifeless> jelmer: no, why would there be?
[11:30] <jelmer> lifeless: the recipe builder only runs the clean target, it doesn't run any of the other targets
[11:30] <Kaleetos> vila: i guess the compiled stuff is indeed necessary
[11:30] <lifeless> jelmer: right, I don't see the problem though
[11:30] <vila> Kaleetos: if you're talking to a remote svn server, yes
[11:30] <lifeless> jelmer: at least not with my packaging rules
[11:31] <lifeless> I haven't looked at what you did in -2 yet
[11:31] <Kaleetos> vila: would this problem have anything to do with whine being associated with all of those .so files?
[11:31] <lifeless> ah, I know
[11:31] <lifeless> I didn't delete setup.py again, I should have.
[11:32] <lifeless> the debhelper stuff wrongly runs setup.py
[11:32] <Kaleetos> vila: and if so, should i associate it with something else or just remove the association?
[11:32] <vila> Kaleetos: I dunno what whine is, but no, associations shouldn't come into play there
[11:33] <Kaleetos> whine is an x11 wrapper for windows programs on mac. basically lets me run .exe's directly on mac osx
[11:33] <vila> wine you mean ?
[11:33] <Kaleetos> hah yes, wine
[11:33] <Kaleetos> sorry
[11:33] <vila> no worries
[11:34] <vila> Kaleetos: ls -lR /Library/Python/2.6/site-packages/bzrlib
[11:35] <lifeless> jelmer: ok, fixed branch pushed
[11:35] <lifeless> jelmer: on the collab-maint packaging
[11:35] <Kaleetos> !paste
[11:35] <jelmer> lifeless: I don't see any changes?
[11:35] <Kaleetos> http://paste.ubuntu.com/603211/
[11:36] <lifeless> lp:~testing-cabal/debian/sid/subunit/daily-builds
[11:36] <vila> Kaleetos: nope, you've added tests
[11:37] <lifeless> jelmer: you've preserved this in your -2 patch anyway
[11:37] <lifeless> just updated it, which is good.
[11:37] <lifeless> need to add a nuke of setup.py there so that it doesn't need to be a delta in the branch
[11:37] <vila> Kaleetos: err, or you lost the beginning
[11:37] <Kaleetos> vila: you lost me?
[11:37] <jelmer> lifeless: ah, found it
[11:38] <jelmer> lifeless: thanks for fixing it
[11:38] <lifeless> de nada, I broke your fix in my confusion
[11:38] <vila> Kaleetos: your paste started in bzrlib/tests, it doesn't contain the part I want :-/
[11:38] <Kaleetos> ah sorry
[11:40] <Kaleetos> mm
[11:40] <Kaleetos> i restarted the terminal to clear it out
[11:40] <Kaleetos> now i'm getting that there is no such file or directory
[11:40] <Kaleetos> when i run the command ending in daily-builds
[11:41] <vila> Kaleetos: you copied the wrong line
[11:42] <vila> ls -lR /Library/Python/2.6/site-packages/bzrlib >~/topaste
[11:42] <vila> and then copy the content of the ~/topaste file
[11:42] <vila> Kaleetos: lucky you nobody pasted sudo rm -fr / :D
[11:43] <Kaleetos> LOL
[11:43] <Kaleetos> i'm not THAT lost
[11:47] <Kaleetos> !paste
[11:47] <Kaleetos> http://paste.ubuntu.com/603215/
[11:47] <Kaleetos> there you go
[11:48] <vila> hmm, so the .so are right there :-/
[11:49] <Kaleetos> yup
[11:50] <vila> PYTHONPATH=/Library/Python/2.6/site-packages python2.6 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
[11:51] <Kaleetos> http://paste.ubuntu.com/603219/
[11:52]  * vila blinks
[11:53] <vila> darn, probably means the 10.6 extensions can't be used on 10.5 :-(
[11:53] <Kaleetos> mm
[11:53] <Kaleetos> what if I
[11:53] <vila> PYTHONPATH=/Library/Python/2.5/site-packages python2.5 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
[11:53] <Kaleetos> change the alias to point to the 2.5 bzr
[11:54] <vila> yup, if you haven't deleted it yet :-}
[11:54] <Kaleetos> in the trash
[11:54] <Kaleetos> i can restore it
[11:54] <vila> pfew, almost
[11:56] <Kaleetos> PYTHONPATH=/Library/Python/2.5/site-packages python2.6
[11:56] <Kaleetos> should i change both to 2.5
[11:57] <Kaleetos> or just that first one
[11:57] <spiv> http://webnumbr.com/bzr-active-reviews is a bit alarming
[11:57] <Kaleetos> since the bzr script head is still 2.6?
[11:57] <vila> spiv: yup, time for me to patch pilot for good ;-}
[11:58] <vila> Kaleetos: PYTHONPATH=/Library/Python/2.5/site-packages python2.5 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
[11:58] <vila> both 2.5, we'll worry about the bzr script later
[11:59] <Kaleetos> http://paste.ubuntu.com/603222/
[12:00] <spiv> Hmm, I guess I should plot merged reviews too so we have something positive to enjoy :)
[12:00] <vila> Kaleetos: geee, what the hell is wrong with your setup !!!
[12:00] <Kaleetos> vila: Its fixed!
[12:01] <vila> Kaleetos: what ? how ?
[12:01] <Kaleetos> i just restarted terminal, reloaded bzr
[12:01] <Kaleetos> and no error
[12:01] <Kaleetos> and the download worked too!
[12:01]  * vila blinks twice
[12:02] <Kaleetos> using the 2.5 change in the alias of course
[12:02] <vila> Kaleetos: may I recommend you some goats&chikens providers for your daily sacrifices ?
[12:02] <vila> ooooh
[12:03] <Kaleetos> yea, haha. that terminal session was still using bzr for 2.6
[12:03] <Kaleetos> so when i restarted with the alias in place it switched
[12:03] <vila> Kaleetos: pfew, so hopefully you're an happy sailor now
[12:03] <Kaleetos> so I have one last question to harass you with
[12:04] <Kaleetos> where did the file i downloaded go??
[12:04] <Kaleetos> haha
[12:04] <fullermd> I would suspect that a .so built for py2.5 would get all cranky running on 2.6 (and vice versa)...
[12:05] <vila> fullermd: nope, tested it locally
[12:05] <Kaleetos> yea, that makes sense now that I think about it
[12:05] <fullermd> That creeps me out more   :p
[12:05] <vila> well, 2.6 can load 2.5, I didn't test the opposite
[12:05] <Kaleetos> vila, does bzr have a specific directory it downloads to?
[12:06] <vila> Kaleetos: what command did you issue ?
[12:06] <Kaleetos> bzr co http://infiniteplatformer.com/dev/Infinite8BitPlatformer/
[12:07] <Kaleetos> i found it
[12:07] <Kaleetos> it went to my home folder
[12:07] <vila> Kaleetos: that's where you issued the command then
[12:07] <Kaleetos> oh ok, so whatever directory i'm sitting in when i issue the command
[12:07] <Kaleetos> thats where it goes
[12:09] <vila> Kaleetos: yup
[12:10] <Kaleetos> thank you so much for all your help vila
[12:10] <Kaleetos> now its 7am here and I started this journey at around 12am. so I seriously need to crash, but I will write up that second bug report first thing in the morning
[12:10] <Kaleetos> thanks again!
[12:16] <Riddell> jelmer: thanks for approving, what happens to it next?
[12:17] <jelmer> Riddell: no problemo. I guess you don't have PQM access yet; I can submit it for you
[12:18] <vila> Kaleetos: thanks
[12:20] <Dr_Al> vila: Yesterday, you provided some very helpful informal review comments on my first attempt at writing some test code.
[12:20] <Dr_Al> I (think I) have taken into account everything that you said; would it be possible for you to have another look and see what you think now?
[12:21] <Dr_Al> The latest revision diff is here: http://tinyurl.com/6556fg5
[12:21] <Dr_Al> My saved copy of your review comments (for reference) is here: http://paste.ubuntu.com/603195
[12:21] <jelmer> Riddell: submitted - it's now in PQM and should land on lp:bzr when finished. You can see the progress here: http://pqm.bazaar-vcs.org/
[12:23] <vila> Dr_Al: seems correct, but just add your new class to test_switch, no need to create a new file (files under blackbox are ~named after the command they are testing)
[12:24] <vila> Dr_Al: blank line missing after the class name to comply with pep8 too
[12:24] <vila> Dr_Al: but more importantly: do they *fail* now ?
[12:25] <Dr_Al> The lightweight one passes and the heavyweight one fails (as expected)
[12:25] <vila> Dr_Al: and otherwise, feel free to make a merge proposal even for early feedback, you can set the mp to 'work in progress' once you get it
[12:25] <vila> Dr_Al: great !
[12:25] <Dr_Al> vila: On another note, should I test "bzr branch --switch" separately to "bzr switch --create-branch" or can they be assumed to be functionally identical?
[12:26] <Dr_Al> Although I guess that would mean splitting the tests between test_switch.py and test_branch.py
[12:26] <vila> Dr_Al: it doesn't hurt to add such tests (especially if you manage to parametrize a bit more your script to easily vary for such cases)
[12:26] <vila> ha, sorry, misread
[12:27] <vila> hmm, have a look at their implementation in builtins.py and decide from that
[12:27]  * vila goes to lunch
[12:28] <Dr_Al> vila: They look sufficiently different to me to seem to need to be tested independently
[12:33] <Dr_Al> If I move the tests into test_switch and test_branch, should I move assertParentCorrect into TestCaseWithTransport instead of having two copies?  I don't want to start editing parent classes without checking here first!
[13:37] <jelmer> vila, jam: Aren't parents supposed to be tuples? Tree.get_parent_ids() confusingly returns a list in some case
[13:37] <jelmer> s
[13:38] <jam> jelmer: I don't think we've ever been perfectly strict on it
[13:38] <jam> get_parent_map, IIRC, always returns tuples
[13:38] <jam> there have also been some odd cases with stuff-being-built vs stuff-read-from-disk
[13:38] <jam> I'm fine if we want to change it to always be a tuple of revision_ids
[13:39] <jelmer> jam: I'll submit a MP to change it to a tuple
[13:39] <jelmer> jam: Thanks
[13:52] <vila> Dr_Al: hmm, not on TestCaseWithTransport, it's too specific for that, better put it in blackbox/__init__.py may be
[13:53] <Dr_Al> vila: It would be the only assert.* in there if that's the case: is that okay?
[13:56] <vila> Dr_Al: hmm, blackbox/__init__.py is indeed almost empty...
[14:00] <vila> Dr_Al: just make an mp and we'll discuss it there,
[14:00] <Dr_Al> Okay.
[14:00] <Dr_Al> Another point for discussion (perhaps this should be in a merge proposal as well, but it's a bit further down the line):
[14:01] <Dr_Al> When doing "switch -b" on a bound branch, a new branch is created and I'm changing the parent of that new branch to match the source branch.
[14:02] <Dr_Al> I'm also thinking that I should set the parent location of the heavyweight checkout to match that of the branch to which it is bound.
[14:02] <Dr_Al> Do you agree?
[14:03] <vila> Dr_Al: re-reading your last proposal, I think assertParentCorrect can be further simplified, ideally the split shouldn't be needed at all if you were providing the right expected parents (and the None case would be also covered in this case)
[14:03] <Dr_Al> (As background, the reason for me obsessing about this is that I want to get the submit panel working in Bazaar Explorer... according to the comments in view_workingtree.py there are some other issues that may also be resolved, but I'll come to those next...
[14:03] <Dr_Al> )
[14:04] <vila> Dr_Al: yeah, better to address these issues one by one so that the controversial bits don't block the others
[14:04] <Dr_Al> Okay, the reason it came up was that my current test (which obviously can be fixed) is checking the parent of the bound branch rather than the master branch!
[14:04] <vila> Dr_Al: and all these discussions are easier with code and tests to explain the issues
[14:05] <Dr_Al> Good point
[14:05] <vila> Dr_Al: and mps also track the discussion which help
[14:06] <Dr_Al> Okay, I'll throw a merge proposal in with a few controversial things and we'll see where we go from there!
[14:33] <Dr_Al> vila: Merge proposal created: https://code.launchpad.net/~abudden/bzr/switch_parent_513709/+merge/59924
[14:33] <vila> Dr_Al: ok
[14:34] <vila> jelmer: move-more-more ? You already did move-more or is it just showing your enthusiasm ? :D
[14:35] <jelmer> vila: I think I already did two move-more's so I thought it was time for more-more :)
[14:35] <vila> hehe
[15:01] <vila> maxb: around ? I just pull hydrazine and get an AttributeError for web_link ??
[15:01] <vila> maxb: while using feed-pqm that is
[15:02] <maxb> vila: Hello
[15:02] <maxb> As a first step, I would try purging your launchpadlib cache.
[15:02] <vila> maxb: hi ! (Sorry, where are my manners...)
[15:03] <maxb> Cached stale wadl could produce that error
[15:03] <vila> .cache/launchpadlib ?
[15:04] <vila> maxb: or is there a command to do that ?
[15:04] <maxb> rm -r :-)
[15:05] <vila> hehe, right, but is it the right directory ?
[15:05] <vila> :)
[15:05] <maxb> I'm unsure, I think it moved in natty too
[15:05] <maxb> I don't have that directory
[15:09] <vila> hmm
[15:10] <maxb> vila: Are you on natty?
[15:10] <vila> and what is this new access scheme, feed-pqm now trigger a dialog with lp asking to confirm access for my host instead of hydrazine only ?
[15:10] <vila> yes, migrated a couple of days ago
[15:10] <maxb> If so, ~/.launchpadlib/api.launchpad.net/cache/
[15:10] <maxb> This new access scheme is about authorizing your Unix user account rather than individual apps.
[15:11] <vila> weird and what if I want to give read access to some apps ?
[15:11] <vila> ha, at least purging the cache addressed the issue at hand, thanks maxb !
[15:12] <maxb> I believe the party line is that if you trust the apps to not go and search for a write-enabled credential somewhere else on your machine, you can just trust them not to write
[15:12] <maxb> Or, for that matter, steal your firefox cookie and grant themselves a new credential headlessly
[15:13] <vila> well, I wasn't in the paranoiac mode, more in the idiot-proof mode ;)
[15:13] <maxb> FWIW, I disagree with the arbitrary changes to the launchpadlib API to ram the new authentication scheme down the throat of existing apps
[15:14] <vila> I guess people were getting tired authorizing so many apps...
[15:15] <maxb> I do agree with the overall idea, at least for most purposes
[15:16] <maxb> I was actually emulating the "one token per host" model using symlinks long before natty
[15:18] <vila> maxb: wow, I should report you to the good citizen police ! :-P
[16:12] <vila> someone is monopolizing pqm ;)
[16:14] <vila> the good side is that it will reduce the review queue...
[16:14] <vila> hey poolie !
[16:14] <poolie> hi vila
[16:14] <poolie> nice to see you at this time of day
[16:14] <poolie> are you piloting today?
[16:15] <vila> indeed :) see pqm ;)
[16:16] <vila> poolie: and land lp:~mbp/bzr/rules (or tell me to do it ;)
[16:17] <doppiabeo> Hy guys
[16:17] <poolie> heh, i'll see about that
[16:17] <poolie> hi doppiabeo
[16:17] <poolie> i have some lp branches to push too
[16:17] <poolie> landing there is a bit scary
[16:20] <doppiabeo> I'm in trouble. My situation: I pulled from a tree... a created a new bzr-working-copy-tree, and now I must update the main tree with my changes, and I'd like to keep my history along with the main history.... is it possible to merge in this case?
[16:20] <doppiabeo> Thanks in advance
[16:21] <Dr_Al> Hello all
[16:22] <Dr_Al> Can anyone tell me: is there a way to get an equivalent of revisionspec.RevisionSpec.from_string("submit:") for the parent branch?  In "bzr help revisionspec" it says that "submit:" will return the parent branch if there is no submit branch, but what if you want the parent branch and there IS a submit branch?
[16:23] <vila> parent: ?
[16:23] <vila> err or is that ancestor: instead ?
[16:23] <Dr_Al> I've tried from_string("parent:") but that produces Unsupported protocol for url "parent:"
[16:23] <Dr_Al> vila: From the help, "ancestor:" looks like a parent revision rather than a parent branch.  Maybe I'm reading it wrong
[16:24] <vila> well, it's the common ancestor between the branch and its parent IIRC
[16:28] <Dr_Al> Okay, I guess I need to separate the two implementations for submit and parent.  I'll see what I can figure out.
[16:30] <poolie> doppiabeo, one way is:
[16:30] <poolie> actually, just let me check first
[16:31] <poolie> you have your own branch with multiple committed changes, and now you want to commit a merge of them onto trunk
[16:31] <poolie> hi jelmer, jam
[16:31] <bialix> strange, poolie around at this time :-) hey pooliw
[16:32] <bialix> hey poolie
[16:32] <poolie> hi bialix
[16:32] <poolie> i'm pretty close to you now, in Budapest
[16:32] <poolie> relatively speaking
[16:33] <bialix> yep, that's very close :-) UDS-O?
[16:33] <doppiabeo> I made the mistake to create a new repository at the beginning...
[16:33] <poolie> yes
[16:33] <doppiabeo> compyng files from the main one... (I didn't know how bzr work)
[16:33] <poolie> actually in a directly neighbouring country, i see (i wasn't sure if that was true)
[16:34] <doppiabeo> and now I want to merge it back in the main one
[16:34] <bialix> poolie: yes, that's correct
[16:34] <poolie> doppiabeo, there's a good quick tutorial
[16:34] <poolie> at, say http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html
[16:34] <bialix> next time Canonical can choose Kiev for this event ;-)
[16:34] <doppiabeo> thanks poolie
[16:35] <doppiabeo> as you know, is it possible to do what I want to do?
[16:35] <poolie> so you just copied the directory?
[16:35] <poolie> or you copied across particular source files then edited them
[16:36] <doppiabeo> files inside directory in a new one, then I added them to a new repo
[16:36] <jelmer> hey poolie
[16:37] <doppiabeo> (so know I have two different trees without common ancestors)
[16:37] <doppiabeo> *now*
[16:37] <vila> doppiabeo: how many commits in the smallest branch ?
[16:38] <doppiabeo> 6-7
[16:42] <a3Dman> http://dl.dropbox.com/u/14234621/May2011/Screen%20shot%202011-05-04%20at%2016.25.34.png
[16:42] <a3Dman> xD
[16:45] <doppiabeo> but if I find out howto merge different bzr repositories maybe I can recover more history from another working dir... evenif the most important are the two that I'm trying to unify now...
[16:46] <doppiabeo> maybe I found something http://www.cuberick.com/2009/02/merge-bazaar-repositories-with-no.html
[17:09] <ams_cs> hi all
[17:10] <ams_cs> I push a commit to a launchpad branch this morning, and now somebody else has overwritten it (presumably by mistake)
[17:11] <ams_cs> I'm trying to fix it up, but 'bzr merge' now says "Nothing to do."
[17:11] <ams_cs> any suggestions how to fix it?
[17:11] <maxb> This suggests you are not merging what you think you are merging
[17:12] <maxb> What is the branch in question?
[17:13] <ams_cs> I merged lp:~ams-codesourcery/gcc-linaro/compound-conditionals into lp:gcc-linaro/4.6 this morning
[17:14] <ams_cs> it was committed at 106740
[17:15] <ams_cs> then at 14:29 UTC+0100 I got a notification saying "1 revision was removed from the branch."
[17:16] <ams_cs> and two more commits have been pushed at the same time by somebody else
[17:16] <ams_cs> presumably they used --overwrite by mistake?
[17:16] <maxb> Yes
[17:17] <ams_cs> so I did bzr pull --overwrite to sync my local tree
[17:17] <ams_cs> and then tried the merge again, but it won't work
[17:18] <maxb> Hmm, that sounds a little odd
[17:18] <maxb> I'm grabbing the branches to have a look, but of course, they are huge, so it's taking a little while
[17:19] <ams_cs> very huge
[17:20] <poolie> doppiabeo, still here?
[17:20] <poolie> i see what you mean
[17:20] <ams_cs> I'm doing a fresh branch from lp:gcc-linaro/4.6 to see if that works better
[17:21] <ams_cs> init-repo should mean it's all cached, but is that likely to defeat the 'freshness' I wonder?
[17:21] <maxb> It should not matter.
[17:21] <maxb> Just how big is this branch, I'm > 200MB already ?
[17:22] <ams_cs> maxb: a compress tarball is like 50MB
[17:23] <doppiabeo> yes
[17:23] <ams_cs> maxb: sorry, I'm wrong, it's 7MB
[17:23] <ams_cs> maxb: sorry, I'm wrong, it's 70MB
[17:24] <ams_cs> this is not a small project
[17:24] <poolie> doppiabeo, do you know ,or can you work out, which revision of trunk you started from?
[17:24] <poolie> if so, perhaps you can
[17:24] <poolie> branch from thta
[17:24] <poolie> copy over your work into that working tree
[17:24] <poolie> run diff to see what you actually changed
[17:24] <poolie> then merge that in
[17:25] <doppiabeo> I'm here but working, so I look here every now and then
[17:25] <doppiabeo> yes I know the revision
[17:28] <ams_cs> maxb: I get the same failure when I try to merge into my fresh branch :(
[17:37] <maxb> ams_cs: OK, I have the branches locally
[17:37] <maxb> bzr is telling you there's nothing to merge because there really isn't
[17:37] <maxb> Your branch is merged to the current 4.6 branch in 106741: Richard Sandiford 2011-05-04 [merge] Resolve conflicts.
[17:37] <poolie> hi maxb
[17:38] <maxb> So, what has happened is that Richard Sandiford has merged 4.6 into his local work branch, and then pushed the result to replace the shared 4.6 branch
[17:38] <maxb> hi poolie
[17:38] <ams_cs> maxb: oh, I see, very not-intuitive :(
[17:39] <maxb> So, there's two things we can do here
[17:39] <maxb> One, there's a flag, append_revisions_only, that you can set on a branch which will make bzr refuse to push revisions which move existing revisions off the mainline
[17:39] <ams_cs> maxb: ok, I want that - how?
[17:40] <maxb> Two, we can straighten out this history goof if we act before any more commits land on the 4.6 branch
[17:40] <maxb> If your local bzr is new enough, "bzr config -d lp:gcc-linaro/4.6 append_revisions_only=True" ought to do the trick
[17:40]  * ams_cs examines history more closely
[17:42] <ams_cs> hmm, bzr: ERROR: unknown command "config"
[17:42] <maxb> To straighten out the shifted history, you would need to branch from your original landing commit, and then merge the current tip of 4.6
[17:42] <ams_cs> I'll try a different machine ....
[17:43] <ams_cs> maxb: ok, I've found a bzr new enough to do the config thing
[17:43] <maxb> python -c 'from bzrlib.branch import Branch; Branch.open("bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6").set_append_revisions_only(True)'
[17:43] <ams_cs> I'll leave the history as is
[17:43] <maxb> would be an alternate way to do it
[17:44] <poolie> ams_cs, hi there, i saw your mail
[17:44] <ams_cs> I disapprove of rewriting history enough without doing it myself
[17:44] <poolie> ams_cs, _cs, do you have the mail launchpad sent you?
[17:44] <ams_cs> yes
[17:45] <poolie> could you forward that to mbp@canonical.com?
[17:49] <ams_cs> poolie: sent
[17:51] <poolie> thanks
[19:12] <m4n1sh> in which package is "launchpad-login" for bzr provided?
[19:12] <m4n1sh> or is it the part of the main bzr package?
[19:23] <lifeless> its part of the launchpad plugin which is included in the main tree
[19:29] <m4n1sh> lifeless: if my ssh key is uploaded
[19:29] <m4n1sh> to launchpad
[19:30] <m4n1sh> then using some bzr extension can I file a bug
[19:30] <m4n1sh> using my ssh key?
[19:30] <m4n1sh> to authenticate?
[19:30] <lifeless> no
[19:30] <lifeless> the ssh key is used to authenticate for bzr uploads/downloads only
[19:30] <m4n1sh> the use-case is
[19:30] <m4n1sh> firefox is crashing
[19:30] <lifeless> you can file a bug using the API (which apport/ubuntu-bug do)
[19:30] <m4n1sh> every time
[19:31] <m4n1sh> and apport collects the data
[19:31] <m4n1sh> but you need to submit it
[19:31] <lifeless> so the upload is not done with firefox
[19:31] <m4n1sh> but you cant open firefox as it keeps on crashing
[19:31] <lifeless> you can take the url it opens and open it in a different browset
[19:31] <m4n1sh> but launchpadlib uses oatuh
[19:31] <m4n1sh> that is there
[19:31] <m4n1sh> different browser is the only solution there
[19:32] <lifeless> Its an interesting case
[19:32] <lifeless> I would change the defa...
[19:32] <m4n1sh> lifeless: yes it is
[19:32] <m4n1sh> this is as I heard a wishlist on apport
[21:33] <theAdib> hi all. simple question: I run into conflicts. Can I simply rename the foo.h.OTHER file to foo.h?
[21:39] <abentley> theAdib: Sometimes you can, but usually you need to combine the changes.
[23:55] <hbeck> hi folks, having some trouble figuring out the proper usage - for a given URL to a repo, I check a specified 'download' directory; if it doesn't exist as a bzr (branch, checkout?) I want to get a specified revision from a master repository and stick it in the specified location. If it's already there, I want to overwrite it with the revision specified.
[23:55] <hbeck> I think checkout/update are the appropriate things to use here, but not sure?