[00:23] <johnf> quick question re packaging. When we release 2.0.2 will there be a 2.0.2rc1 or are we just releasing since it should only be bug fixes?
[00:31] <sven_oostenbrink> Can bzr diff also NOT throw errors when a file has a diff?
[00:31] <igc> morning
[00:32] <sven_oostenbrink> don't really like that behaviour :) I need it to just show the diff and thats it
[00:32] <bob2> throw error = set return code?
[00:33] <enatom> i just setup my project
[00:33] <sven_oostenbrink> bob2: correctly, sorry, it sets a return code while there is no error
[00:33] <enatom> but where in "trunk" folder will i put my files ?
[00:34] <sven_oostenbrink> igc: Evening..
[00:34] <poolie1> sven_oostenbrink: you're talking just about the shell return code?
[00:34] <sven_oostenbrink> poolie1: yes
[00:34] <poolie1> there's no builtin option to turn it off
[00:34] <igc> hi sven_oostenbrink
[00:35] <sven_oostenbrink> poolie1: interresting...
[00:38] <bob2> svn diff || true
[00:51] <johnf> I just did "bzr branch svn_reop trunk; bzr check" if I get a sha1 mismatch should I file/look for a bug or could it indicate dodgey svn data (which isn't inconceivable in this case)
[00:52] <johnf> or I could just search first instead of wasting peoples time and find the existing bug in launchpad
[00:56] <spiv> johnf: :)
[00:56] <johnf> hmm except that bug is fr symlinks which this isn't
[00:57] <johnf> is bzr-svn the best way to move from svn to bzr. Assuming that I don't care about any of the svn data at all. I just want the revisions. I don't cae about svn ids etc
[00:57] <johnf> Maybe I should try tailor
[00:59] <spiv> johnf: people mostly seem to use bzr-svn or fast-export
[00:59] <johnf> can't use fast-export since I don't want the whole svn repo just a few branches
[00:59] <johnf> and bzr-svn is creating the above problem with a bzr-check :(
[01:00] <spiv> I believe fast-export and/or the importer can do some filtering of that sort of thing
[01:00] <bob2> there's a filter thing
[01:00] <johnf> ahh :)
[01:00] <spiv> igc knows lots about it
[01:03] <jelmer> johnf: that check issue is the symlink one?
[01:03] <jelmer> johnf: reconcile should be able to fix that
[01:04] <johnf> jelmer: I thought it was the symlink one but the file it is complaing about isn't a symlink. Reconcile thinks everything is OK which is strange since bzr check doesn't
[01:05] <johnf> hmm I had a very old version of python-subversion 0.6 even though subversion was 1.5 I wonder if that could cause problems
[01:11] <spiv> IIRC bzr-svn doesn't use python-subversion, it uses jelmer's subvertpy
[01:12] <johnf> that's special fast-export-from-svn skips every single revision :)
[01:12] <johnf> spiv: ahh looks that way
[01:13] <johnf> This SVN repository is doing a good job of protesting my move to bazaar
[01:32] <jam> johnf: we are *just* doing simple releases. The only 'rc' we will be doing is just before a new stable release
[01:32] <johnf> jam: ok cool
[01:32] <johnf> thanks
[01:32] <jam> johnf: and 2.0.2 and 2.1.0b2 are now out
[01:33] <jam> well, 'gone gold' waiting on you to build installers :)
[01:33] <jam> as for '~beta-ppa' stuff. The 'b1' release is generally going to cause problems
[01:33] <jam> but b2+ shouldn't cause as much strife
[01:33] <jam> because the 'major.minor' version isn't changing
[01:34]  * jam crosses fingers eyes and toes, because b1 was pretty awful :)
[01:34] <johnf> agh I missed the 2.0.2 email. Will sort that tonight
[01:35] <jam> well, just came out.. 5 min ago
[01:35] <jam> :)
[01:35] <jam> anyway, see y'all around later
[01:53] <igc> poolie1: now that 2.0.2 and 2.1.0b2 have gone gold, can we work together on automating the doc builds some more?
[01:55] <igc> johnf: fast-export-from-svn just does trunk currently and it has a range of problems
[01:56] <igc> johnf: jelmer has fixed the biggest of those by adding fast-export support to subvertpy 0.7.1
[01:56] <johnf> igc: ahh I need a newer subverty
[01:57] <igc> johnf: ping jelmer if you need help running his fast-export script
[01:57] <igc> johnf: I want to change fast-export-from-svn to use his script if it's present but I haven't done that yet
[01:58] <johnf> Although I think I just got it working. I just need trunk anyway
[02:00] <Kilroo> Oooh, 2.0.2.
[02:00] <Kilroo> Here's hoping somehow building subvertpy against Subversion 1.6 for the Windows installer's bzr-svn gets worked into that somehow...
[02:04] <poolie1> igc, hi
[02:04] <poolie1> igc, good idea
[02:04] <poolie1> spiv, hi?
[02:07] <enatom> how can i use BZR with my www folder, if my www folder wont even allow me to create folders?
[02:09] <RAOF> enatom: Change the permissions on your www folder so that the users who should have commit access can write to your www folder?
[02:09] <enatom> ok ill try that
[02:10] <RAOF> ie: add all the users who should be able to commit to bzr to a "bzrusers" group or somesuch and then chown the relevant directory.
[02:10] <enatom> hmm sounds relatively easy, ill go through it now
[02:12] <enatom> bzrusers group doesnt exist, should i just create it RAOF
[02:12] <RAOF> You certainly could.
[02:12] <RAOF> The details of what you want to do will depend on what, exactly, you want to do. :)
[02:13] <RAOF> But the general plan is: "give all the users who'll need to commit to bzr permissions to write in the relevant directories".
[02:14] <enatom> the problem is bzr-explorer doesnt even create the trunk folder
[02:14] <enatom> becuase the actual program doesnt ahve access etc
[02:14] <jam> poolie1: ping
[02:23] <enatom> the group i created isnt in the list, for the permission of the folder
[02:53] <jam> poolie1: Something is wrong with the Visual Studio 2008 installation on 'desolation'. It shows up as being in the start menu, but there is nothing in D:\ where it thinks it is installed.
[02:53] <jam> I'm going to stop trying to configure it for now, in case we need to start with a new EC2 image
[03:09] <poolie1> jam, hi
[03:09] <poolie1> jam, ok, i may look at it too
[03:09] <jam> poolie1: please do
[03:09] <poolie1> i think this is because of the distinction between the two types of storage
[03:09] <poolie1> it may be that disk needs to be remounted or i may have broken it
[03:10] <jam> sure
[03:10] <jam> that is sort of what I was thinking
[03:10] <jam> I started installing and documenting my progress, and I didn't want to get to far
[03:10] <jam> too far
[03:11] <poolie1> does another volume come up in the mgmt console for that account?
[03:12] <mwhudson> is D: the part of the storage that doesn't persist on bunding?
[03:13] <mwhudson> like /mnt for linux images
[03:13] <jam> poolie1: there is a 'D:' present
[03:13] <jam> but it only had a 'hash' directory in it
[03:15] <jam> I see a "created volumes" section, but I don't see anything present
[03:17] <poolie1> mwhudson: yes, D: is the part stored on S3
[03:17] <poolie1> i can't recall what the state of it is
[03:17] <mwhudson> oh ok
[03:39] <johnf> Say I have two branches. Branch A created by bzr-svn  has 20 revision and branch B created by fast import has the first 10 revision in branch A.
[03:40] <johnf> Can I merge from B to A somehow. Can i manually specify the common ancestor or something?
[03:41] <SamB_XP_> I think you'd need to use something evil
[03:41] <SamB_XP_> like rebase or more fast-export | fast-import
[03:42] <johnf> yeah I tried fast-import but it can't add revisions to an existing branch
[03:43] <SamB_XP_> oh, lame
[03:43] <johnf> I wonder what happens if I cat to fast-import files together :)
[03:44] <SamB_XP_> I don't think that's going to help!
[03:44] <SamB_XP_> another option is to make patches for each change and apply/commit each of those ...
[03:44] <johnf> yeah trying to avoid that
[03:45] <SamB_XP_> well, what you should really avoid is using fast-import on SVN repos ;-P
[03:54]  * igc lunch
[04:02] <johnf> sweet catting together fast-import files works!!
[05:08] <johnf> Is it possible to set a branch as readonly?
[05:08] <johnf> Reasoning is I have a branch on a web server where  I want to be able to pull
[05:08] <johnf> but I want bzr to slap me if I try and commit
[05:08] <johnf> I suppose I could write a pre-commit hook
[05:10] <spiv> johnf: chmod -R a-w yourbranch
[05:10] <spiv> Oh, but you want to pull.
[05:11] <spiv> That's not readonly, exactly.
[05:11] <johnf> spiv: yeah only sort of read only :)
[05:11] <johnf> just don't want anyone to commit to it
[05:11] <johnf> let me try writing a hook
[05:11] <spiv> I guess a pre-commit hook is probably the way to go then.
[05:12] <spiv> Or only make it writeable to a special user and then provide a sudo command to run pull (and only pull)?
[05:13] <lifeless> precommit hook won't necessarily do it
[05:13] <lifeless> as commit on a bound branch is a fetch operation
[05:13] <lifeless> but if you are worried about local commits, then yes, precommit is fine
[05:39] <jam> johnf: alternatively make the branch a checkout of the thing you want to pull from, and make the upstream location readonly from your local branch
[05:40] <jam> It is what I do for my 'bzr.dev' local copy
[05:40] <jam> I used to checkout from http
[05:40] <jam> anyway, night all
[05:45] <lifeless> gight jam
[06:02] <igc> night jam
[06:28] <cody-somerville> I had local commits and against a binded branch and then I did bzr update
[06:28] <cody-somerville> how can I undo the bzr update as it totally did not turn out good
[06:32] <cody-somerville> oh, luckily I still had the files open so I can just resave and overwrite what bzr did.
[06:34] <bob2> have you considered just using unbound branches?
[07:15] <vila> hi all
[07:24] <fullermd> vila: Heydere.  What was it you muttered at my about this weekend?
[07:26] <fullermd> Oh, time drift.
[07:27] <fullermd> I think that's usually "solved" (worked around anyway) by dropping the kernel HZ.
[07:27] <fullermd> You can do that in loader.conf...   kern.hz="100" say.
[07:27] <fullermd> (the default 1000 sometimes interacts poorly with VM's...  thought I thought there were actually some changes made that detected in-VM status and dropped it)
[07:28] <vila> fullermd: hi !
[07:28] <vila> fullermd: I *have* kern.hz=100 already
[07:28] <vila> fullermd: I'm glag you already know that much context...
[07:29] <fullermd> Oh.  Well, so your problems solved then   8-}
[07:29] <vila> s/glag/glad/ :)
[07:31] <vila> hmm, interesting, freebsd7 lost 4 hours in the last 41 hours while freebsd8 lost "only" 20 minutes
[07:31] <fullermd> Is it steady drift or jumps?
[07:31] <vila> What I use so far to resync is: 1) reboot :-/ OR 2) ntpdate
[07:32]  * fullermd has no idea what to actually _do_ with the answer to that question of course...
[07:32] <fullermd> Well, you should probably run ntpd in them anyway...
[07:33] <vila> I don't actually monitor that closely but I often see messages about calcru something... of course none are available right now :-/
[07:33] <vila> ntpd is enabled
[07:33] <fullermd> runtime went backwards.
[07:33] <fullermd> Symptom.
[07:33] <vila> yeah
[07:34] <vila> but is that a drift or jump symptom ?
[07:34] <vila> I suspect drift myself but that may be seen as jumps by some processes
[07:34] <fullermd> Doesn't really differentiate.  Just sorta a general symtom of "WTF, time isn't seeming monotonic"
[07:35] <vila> The most annoying one is that the slave lost the connection with the master... that's the symptom I want to cure
[07:35] <vila> . o 0 ( Monotonic time is too boring for FreeBSD )
[07:35] <fullermd> If ntpd is running, letting it drift like that means it's over the correction rate.  You could probably watch the offset grow via that.
[07:36] <vila> 'via that' ?
[07:36] <fullermd> Yah, watching what ntpd is doing.
[07:36] <vila> /var/log/ ?
[07:37] <fullermd> Well, I was thinking more "watching ntpq -p"
[07:37] <fullermd> Though it probably spits something in messages when it gives up on slewing.
[07:40] <vila> grep -i ntp /var/log* => ./Xorg.0.log:24:(**) FontPath set to: , yeah great
[07:40] <vila> :)
[07:43] <vila> My impression is that ntpd is run only at boot and never more from there... Any idea how to check that theory ?
[07:43] <fullermd> ntpd is a daemon...
[07:43] <fullermd> You can use ntpq to see if it's running.
[07:44] <vila> how ?
[07:44] <fullermd> ntpq -p
[07:44] <bob2> ntpdate is the thing that (sometimes) runs only at boot
[07:45] <bob2> but modern ntpd has an option for "jsut set the damn clock at boot"
[07:45] <vila> ntpq -p
[07:45] <vila> ntpq: read: Connection refused
[07:45] <vila> daemon not running ?
[07:45] <fullermd> Yeah, and they keep yacking about obsoleting ntpdate because of it.  Totally missing the point...
[07:45] <fullermd> vila: Yah.
[07:45] <vila> haaa
[07:46] <bob2> do you need to run ntpq as root?
[07:46] <vila> bob2: I'm root
[07:46] <bob2> ah
[07:46] <fullermd> Not unless you have funky firewalling or something.  It talks over UDP.
[07:46] <bob2> oh
[07:46] <fullermd> vila: So you presumably need to enable it in rc.conf (and then fire it up manually for this boot)
[07:47] <fullermd> And edit the config to point at your local ntp server, of course.
[07:48] <vila> the later is done, remind me the magic path to search for the options I can use in rc.conf ? (That's not /usr/ports/net/ntp)
[07:48] <fullermd> % grep ^ntpd_ /etc/rc.conf
[07:48] <fullermd> ntpd_enable="YES"
[07:48] <fullermd> ntpd_sync_on_start="YES"
[07:49] <vila> ntpdate_enable="YES"
[07:49] <vila> is all I have !
[07:49] <fullermd> (grep'ing in /etc/defaults/rc.conf would be how you'd find the choices)
[07:49] <fullermd> Yah.  Which is why you're running ntpdate, but not ntpd   8-}
[07:50] <vila> fullermd: great, you rock :)
[07:52]  * fullermd buffs his nails on his lapel and looks important.
[07:54] <fullermd> Now, that still suggests a hyuge amount of drift.  It may be more than ntpd is willing to cope with.
[07:54] <fullermd> I believe the default builds refuse to skew more than 500ppm.
[07:55] <vila> fullermd: my feeling is that the drift is not constant, so having ntpd *running* may be enough, I'll need a couple of days to be sure though :-/
[07:56] <fullermd> Naturally.  Checking on problems with time requires time   ;)
[07:56] <vila> hehe, yeah, non-monotonic time and virtual time help a bit, but not that much here :)
[07:57] <vila> ha. I have ntp.conf under bzr, I *thought* I was using it at one point... :-/
[07:58] <vila> ...but since there is a typo in it....
[07:58] <fullermd> Oooh, somebody made a port of dulwich.
[07:59] <fullermd> As a side effect of making a hg-git port.  Cute.
[07:59] <vila> Interesting...
[08:24] <marccc> good morning
[08:27] <marccc> i was wondering how i could add revision number and branch in the source when commiting automatically, any qlue's?
[08:28] <vila> marccc: bzr help version-info
[08:28] <vila> but putting such infos somewhere when committing is rarely the right thing to do
[08:29] <marccc> why is that?
[08:29] <fullermd> It sounds like what you really want is keyword expansion.
[08:30] <bob2> because it is already visible with bzr version-info
[08:30] <bob2> it's arguably useful in source tarballs, so hook version-info into your build system
[08:30] <marccc> true, but i want to export source tarballs
[08:30] <vila> . o 0 (Thanks guys, you type faster than me ;)
[08:31] <bob2> so have your 'generate source tarball' script call version-info :)
[08:31] <bob2> no need to do it on every ommit
[08:34]  * igc dinner
[08:34] <marccc> is there a nice way to checkout and create a tarball with a revision number?
[08:37] <vila> fullermd: Ha, got that message back: calcru: runtime went backwards from 5773628818061961 usec to 4285 usec for pid 12 (intr)
[08:39] <Adys> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[08:40] <fullermd> That's a pretty significant jumpback.  Probably corresponds to a big clock step.
[08:40] <Adys> trying to update loggerhead, any idea how to fix?
[08:42] <vila> fullermd: as in: ntpd started after some processes and they catch up ? (I have several messages)
[08:42] <vila> marccc: $ export REV=`bzr version-info --custom --template 'no}' `
[08:42] <vila> marccc: bzr export ../package-${REV}.tar
[08:42] <vila> errr
[08:42] <fullermd> Well, it's basically just a general symptom of time not being monotonically increasing.  ntpd doing a step is one way that could happen (I believe it logs when it steps, and they end up in messages)
[08:43] <vila> marccc: $ export REV=`bzr version-info --custom --template {revno}' `
[08:43] <vila> fullermd: ha, yes, I have messages in /var/log/messages now
[08:44] <thumper> Adys: launchpad doesn't support updates over http
[08:44] <thumper> Adys: what is the command line you are using?
[08:45] <vila> fullermd: I don't have an /etc/ntp.conf for FreeBSD7, any idea why ?
[08:45] <Adys> thumper: nvm, I just branched again
[08:47] <fullermd> Pre-8, there wasn't one made by default.
[08:47] <fullermd> 8 added one with pool servers.
[08:47] <vila> fullermd: great, thanks for confirming, I'll just copy the 8 one
[08:47]  * fullermd has all the CVS logs in his brain just for questions like that  ;p
[08:54] <vila> :)
[09:13] <Zapelius> Could someone point me to a howto, how to convert/merge a 'bzr init':ed repo to a new 'bzr init-repo trunk':d one ?
[09:14] <fullermd> Zapelius: That question in and of itself doesn't quite make sense...
[09:14] <fullermd> You can use reconfigure to conver a standalone branch to using an existing shared repo (or vice versa).
[09:16] <Zapelius> I have a project that I initially
[09:17] <Zapelius> ... init'ed but that grow a bit too big and now needs several branches
[09:17] <Zapelius> so I just read that the init-repo would save my HD a bit
[09:17] <Zapelius> when doing a lot of branches
[09:18] <bob2> so: bzr init-repo ~/repo/ ; bzr branch /wherver/it/is/now ~/repo/thingo/trunk
[09:19] <fullermd> That would be one way.  It can lose config though.
[09:19] <fullermd> Moving the standalone branch in and using reconfigure is probably better.
[09:22] <Zapelius> I'll look into that. thanks
[09:27] <ferringb> insane question... anyone looked into doing a caching proxy for bzr?  specifically, I've multiple clients locally accessing the same remote repo, been toying w/ having the clients hit a bzr server first which in turn returns what it has (updating as needs be)
[09:27] <ferringb> yes it's insane.  yes, I probably could do it via having the share an nfs/remote mount of some sort instead and a bit of trickery
[09:27] <ferringb> just wondering if anyone has poked around deep enough to comment if it's viable w/ the architecture
[09:33] <spiv> ferringb: it'd be nice to do, but I don't think anyone has done one.
[09:38] <ferringb> spiv: anyone looked into it?
[09:39] <bialix> hi all
[09:40] <spiv> ferringb: not that I know of
[09:44] <ferringb> wonder if a lightweight checkout could be bastardized for it
[09:45] <ferringb> basically do a pull from a bzr server serving a lightweight checkout that caches...
[09:45] <ferringb> via that, could reuse it's "always connected" design, although I suspect lightweights still have a specific rev bound to the local checkout
[09:59] <vila> hi bialix
[10:08] <bialix> hi vila
[10:08] <bialix> bugfix for hooks really was simple, not sure why you don't try to apply it for 2.0.x series
[10:09] <bialix> but it was you choice
[10:10] <vila> wow the series and milestones picture makes sense on https://launchpad.net/bzr ... that wasn't always the case...
[10:12] <vila> bialix: it's importance is medium, I didn't think it was urgent...
[10:12] <bialix> I don't understand this
[10:14] <vila> ?
[10:16] <bialix> IMO if bugfix is not API break it should got to latest stable release too
[10:17] <bialix> it seems you guys using different judge here
[10:17] <vila> The added test may detect bugs in plugins, that's what betas and trunk are for
[10:18] <bialix> ok, nm
[10:26] <marccc> vila: thanks
[10:27] <vila> marccc: ?? export... bzr export... ?
[10:27] <marccc> bzr export
[10:30] <vila> marccc: ok, so you don't need any commit hook anymore ? (Just trying to understand if you original need is addressed)
[10:32] <marccc> yes, but the only thing i need now is the tag
[10:34] <vila> hmm, version-info doesn't support tag ? Worth filing a bug...
[10:35] <marccc> lets do that!
[11:55] <backslash> Hi, we have a bzr repository running on Linux server. There's a weird problem with branching the repo from Win 7. When the bzr branch command is issued an error is returned: bzr: ERROR: [Error 183] Nelze vytvoøit soubor, který již existuje: u'C:/Users/Backslash/Work/novawinnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..' -- that non-english part is Unable to create a file which already exists -- what could be the problem? Thanks a lot
[11:56] <backslash> Strange thing in that error message is the double dot at the end and the slashes in the path while Windows use backslashes ^^
[11:58] <bialix> backslash: mjst likely in your branch there is 2 files which different only in case, e.g. Foo.txt and foo.txt
[11:58] <bialix> backslash: most likely in your branch there is 2 files which different only in case, e.g. Foo.txt and foo.txt
[11:59] <bialix> backslash: or directory
[11:59] <backslash> bialix but those files are not the AbsoluteLayout direcotory, are they? I'll try to find them under it...
[11:59] <bialix> you can run qbrowse command for this branch (even on server) and inspect files
[12:00] <backslash> bialix: thanks a lot, I'll look into it ^^
[12:00] <bialix> "soubor" means file or directory?
[12:00] <bialix> what is your language?
[12:00] <bialix> backslash: ^
[12:00] <bialix> I see it slavic
[12:01] <backslash> soubor is file
[12:01] <backslash> it's actually Czech
[12:01] <bialix> ah, ok
[12:02] <GaryvdM> Hi igc
[12:02] <bialix> backslash: just for the record: bzr.exe v.2.0?
[12:02] <GaryvdM> igc: I landed the rename/move functionalty into lp:qbzr last night.
[12:03] <bialix> hi GaryvdM
[12:03] <GaryvdM> Hi bialix
[12:03] <backslash> bialix: yes, 2.0
[12:04] <backslash> bialix, is there a problem with that version?
[12:04] <bialix> backslash: most likely case name clash
[12:04] <bialix> backslash: no no no
[12:04] <backslash> bialix, damn :)
[12:05] <bialix> IIRC it was "fixed" in bzr 1.0, I just don't remember how exactly it should report this problem to user
[12:05] <bialix> although error message could be clearer, yes
[12:05] <backslash> bialix, but why does it output that directory name when you are saying that it can be any file in the repo?
[12:06] <backslash> bialix, that's what's strange :)
[12:06] <bialix> backslash: the error comes from deep internals of bzr, from TreeTransform class. This class use special pseudo-names for newly created files/dirs to avoid clash
[12:06] <bialix> and then on some stage it renames them into your working tree with real names
[12:06] <bialix> can you show me relevant part of .bzr.log
[12:07] <bialix> ?
[12:07] <backslash> bialix, could that be because Windows filesystems cannot store file which paths are longer than 255 chars?
[12:07] <bialix> the author of TreeTransform is abentley, you can try to catch him several hours later
[12:07] <bialix> backslash: yes, this is also problem
[12:08] <backslash> bialix, I'll try to branch it somewhere else.
[12:08] <bialix> backslash: you can check this easily too, just using shorter base directory
[12:08] <bialix> e.g. C:\Users\1
[12:08] <bialix> short enough ;-)
[12:09] <backslash> bialix, I'll go with C:\Project :)
[12:09] <bialix> :-)
[12:09] <bialix> C:\Prj :-D
[12:10] <backslash> bialix, possibly not, I got the same error with the u'C:/Winnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..' path...
[12:10] <backslash> bialix, why are  there the two dots at the end ? :)
[12:11] <bialix> no idea, really
[12:11] <bialix> there is space before 2 dots, see?
[12:11] <bialix> pastebin relevant part of .bzr.log please
[12:12] <backslash> bialix: I know, that is the strangest thing I've ever seen :)
[12:12] <backslash> bialix, where is the log usually located?
[12:12] <bialix> run `bzr version` it will show you location
[12:14] <backslash> bialix: http://pastebin.com/m7fb93aa
[12:15] <backslash> bialix, that's mostly weird :)
[12:15] <bialix> backslash: it seems this is exact path u'C:/Winnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..'
[12:15] <bialix> some file or dir in your branch named as ' ..'
[12:16] <bialix> is it possible?
[12:16] <bialix> I suggest using qbrowse to inspect
[12:16] <backslash> bialix, unlikely :) I'll try to search for it
[12:16] <bialix> otherwise file a bug and attach that part of .bzr.log
[12:16] <bialix> something really bad happens
[12:17] <bialix> also it fails on attempt to create directory
[12:20] <backslash> bialix: the directory is really there :DDD
[12:21] <bialix> what?
[12:21] <backslash> bialix, there really was a directory named ' ..' :)
[12:21] <bialix> ah
[12:22] <bialix> how's weird
[12:22] <bialix> :-)
[12:22] <backslash> bialix, someone at our team is weird for commiting such directories :)
[12:22] <bialix> bite him
[12:22] <bialix> and ask to rename/delete this directory
[12:23] <bialix> when this directory will gone you can get the branch
[12:25] <backslash> bialix, thanks a lot for your help :)
[12:25] <backslash> bialix, the person is already a dead man :)
[12:25] <bialix> :-)
[12:25] <bialix> really?
[12:26] <SamB_XP> meaning you already yelled at him and told him he has to take out the garbage next ?
[12:26] <SamB_XP> or that his bus number came up?
[12:28] <Peng> Murder seems a disproportionate response to crappy directory naming... :P
[13:44] <guilhembi> Unable to load plugin 'gtk'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/home/mysql_src/logiciels/bzr_versions/bzr.dev/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
[13:44] <guilhembi> after pulling the latest bzr-gtk and bzr.dev.
[13:44] <guilhembi> It's a bit tiring... such "wrong API version" errors have happened in the past already...
[13:45] <Peng> 1.17.0? That's not very recent...
[13:45] <guilhembi> I continue to think that it would be great if the bzr unit tests included a basic test of compatibility with bzr-gtk if bzr-gtk is present; it would catch those bugs before they affect people...
[13:46] <Peng> The version numbers are more a feature than a bug.
[13:47] <guilhembi> Peng: ahah, this time it's my "cd plugins/gtk; bzr pull" which didn't work, hence the error;
[13:47] <guilhembi> regarding feature vs bug, I mean that in the past, someone bumped the API in bzr,
[13:47] <guilhembi> and that broke bzr-gtk. Whether the fault is in bzr or bzr-gtk,
[13:48] <guilhembi> a test before push would have avoided spreading this problem to users (several colleagues hit this at Sun).
[13:50] <vila> guilhembi: but we can't make bzr check for all existing plugins, it has to be the other way around
[13:51] <guilhembi> vila: it looks natural that the one who does a change does the check too; otherwise, how do you prevent the problem from spreading?
[13:51] <vila> bumping the API is intended to *avoid* bugs, the check failing early helps
[13:51] <vila> but the fix has been done in bzr-gtk, if the check wasn't failing how would *you* know you need to update ?
[13:52] <vila> the problem is not in the plugin nor bzr IMHO, it's a packaging issue
[13:52]  * bialix_ mutters things will be much simpler with qbzr. :-P
[13:53] <vila> this is being worked on with the PPAs that provide coherent versions, but then you have to use them
[13:56] <guilhembi> vila: you remember a certain bug report, where the latest bzr.dev and the latest bzr didn't work together, and it took days to fix;
[13:57] <vila> guilhembi: yes
[13:57] <guilhembi> so it means that for some days, things were just unusable for users (they had to revert to older versions, not obvious to remember which one they had before pulling);
[13:57] <vila> yes
[13:57] <guilhembi> so, how do you suggest that this doesn't happen anymore.
[13:57] <guilhembi> ?
[13:57] <vila> by running automated tests
[13:57] <vila> this is planned, but not yet implemented
[13:58] <guilhembi> vila: then I think we are in agreement. Automated with high frequency ("every few days" wouldn't improve the situation).
[13:58] <vila> Oh I'm sure we agree on the goal :)
[13:58] <guilhembi> vila: I wasn't sure; I had the impression that you were telling me that everything is right.
[13:59] <vila> The planned frequency is at least once a day at most once on every commit on bzr.dev
[13:59] <guilhembi> vila: looks perfect!!
[13:59] <vila> Sorry for the confusion, I meant the design is right, there are still rough edges for people running bzr.dev and plugins tips
[13:59] <guilhembi> ok I get it
[14:00] <vila> http://babune.ladeuil.net:26862/waterfall is where things are at today
[14:01] <guilhembi> vila: ok... nice... looks similar to buildbot?
[14:01] <vila> May be because it *is* buildbot :-D Good catch ;)
[14:02] <guilhembi> ahah
[14:06] <vila> guilhembi: by the way, your failing pull may be due to bzr-gtk migrating to the 2a format
[14:07] <Peng> guilhembi: Yeah, what was the error message?
[14:10] <mthaddon> pqm machine going down for hardware maintenance
[14:12] <Peng> Fun. What kind of maintenance?
[14:18] <jam> mthaddon: I'm trying to decide how hard to cheer for that :)
[14:18] <mthaddon> jam: I'd go with "a little"
[14:20] <vila> morning jam !
[14:20] <jam> morning vila
[14:21] <vila> mthaddon: a little cheer for hardware upgrade to a quad-core CPU !!!
[14:21]  * vila just loves spreading rumors :)
[14:21] <mthaddon> vila: just updating firmware I'm afraid
[14:21]  * vila doesn't always succeed :)
[14:22] <Peng> Maybe the firmware upgrade unlocks the secret power inherent in the CPU?
[14:22] <beuno> vila, sometimes they *say* firmware, but they mean "128gb of ram"
[14:22] <vila> lol
[14:23] <Peng> Great, now PQM can test 450 patches at once. :D
[14:23] <vila> james_w: ready for you when you are
[14:27] <james_w> vila: good timing!
[15:05] <jcastro> emmajane, about an hour!
[15:06] <emmajane> jcastro, amber already pinged me. ;)
[15:06] <emmajane> jcastro, you're late. ;)
[15:06] <jcastro> heh
[15:06] <LarstiQ> hour?
[15:07] <emmajane> LarstiQ, I'm giving a "so you think you want to be an author" talk for Ubuntu Open Week.
[15:08] <LarstiQ> aah :)
[15:19] <marccc> ls
[15:19] <marccc> :-)
[17:00] <Tak> is it intentional that bzr doesn't handle symlinks to symlinks?
[17:03] <Tak> hmm, it does handle them somewhat - but a recursive add misses them
[19:15] <phoenixz> When doing an bzr push while still having uncommitted changes in my WT, bzr errors with bzr: ERROR: Working tree "/home/sven/projects/kloud/" has uncommitted changes (See bzr status). Use --no-strict to force the push...
[19:15] <phoenixz> Whats the "danger" of pushing whilst still having uncomitted changes?
[19:16] <Peng> phoenixz: It's just a safeguard, in case you have something you forgot to commit. There's zero "danger".
[19:16] <phoenixz> Peng: Ah, perfect.. I figured so, but I wanted to be sure :)
[19:16] <phoenixz> Peng: thanks!
[19:16] <Peng> :)
[19:30] <jfroy|work> verterok: pushed my changes for 2.0.2 to lp:~jeanfrancois.roy/+junk/SnowLeopard-package
[20:01] <phoenixz> If I have a trunk and users A, B, C.. We all work from the trunk, push, pull, merge, etc.. but one day, user A pushes some revisions to user B.. then all continue.. Will there be a problem? Will BZR know that the revisions that B recieved? Will those revisions also end up in the trunk? When A, AFTER the push to B, pushes to the trunk again, will the same changes sent to B also be sent to the trunk again? Will BZR know what changes B already received from A
[20:01] <phoenixz>  by means of the trunk? how does this work?
[20:07] <ferringb> phoenixz: revs commited to a branch are uniquely identified, and are handled accordingly
[20:07] <ferringb> phoenixz: iow, a -> b, a -> trunk, b -> trunk, will work as you'd expect
[20:08] <phoenixz> ferringb: sooo.. if A pushes its own rev 5 to B, that same rev will also be sent to trunk when pushing there, correct?
[20:08] <ferringb> yes.
[20:08] <phoenixz> ferringb: and then when B pulls from the trunk, it will not again receive that revA5, because it already has it..
[20:08] <ferringb> yep
[20:09] <phoenixz> perfect, perfect...
[20:09] <ferringb> yes'm.
[22:52] <mwhudson> hmm!
[22:52] <mwhudson> commit just failed for me
[22:52] <mwhudson> aborting commit write group: AssertionError("deserialise should be called with a StaticTuple not <type 'tuple'>",)
[22:53] <mwhudson> happens with no-plugins too
[22:53] <mwhudson> seems something of a regression......
[22:53] <mwhudson> jam: here?
[22:57] <mwhudson> seems to only happen on committing a merge
[22:58] <mwhudson> and a trivial test case doesn't reproduce
[22:58] <mwhudson> bah :(
[23:05] <lifeless> mwhudson: file a bug
[23:05] <mwhudson> lifeless: yeah will do
[23:05] <lifeless> some fallout expected
[23:06] <lifeless> releases will disable this with a flag to enable it
[23:06] <lifeless> trunk will continue to die die die
[23:07] <mwhudson> hm
[23:07] <mwhudson> bzr.dev actually committed it ok
[23:07] <jam> mwhudson: that should be a bugfix from: 4671 Canonical.com Patch Queue Manager 2009-11-02 [merge]
[23:07] <jam>      (jam) Fix bug #471193, make chk_map type checking less strict.
[23:07] <jam> in 2.1.0b2
[23:08] <jam> which should be merged into bzr.dev
[23:08] <jam> bzr.dev 4782:
[23:08] <mwhudson> jam: ah ok
[23:08] <jam> 4782 Canonical.com Patch Queue Manager 2009-11-03 [merge]
[23:08] <jam>      (jam) Merge 2.1.0b2 (-final) to bzr.dev
[23:08] <mwhudson> i guess the ppa is a little out of date
[23:08] <jam> mwhudson: nightlies?
[23:08] <mwhudson> jam: yeah, i think so
[23:08] <jam> mwhudson: btw, is this a commit of a merge in a heavy checkout?
[23:08] <mwhudson> jam: no, lightweight
[23:08] <jam> hmm...
[23:09] <jam> anyway, should still be fixed
[23:09] <jam> though I should figure out why it is happening there
[23:09] <mwhudson> yeah, seems to be
[23:09] <mwhudson> jam: want the crash file?
[23:09] <jam> I *want* to have strict type checking, but I need to track down the code that is introducing it
[23:09] <jam> mwhudson: sure
[23:09] <lifeless> jam: interesting, StaticTuple broke bzr-search
[23:09] <lifeless> s/g,/gly,/
[23:10] <mwhudson> jam: http://pastebin.ubuntu.com/308926/
[23:10] <lifeless> jam: suggestions were printing the result keys out and they because StaticTuples
[23:12] <jam> lifeless: yeah, I saw your patch there
[23:12] <jam> though your code was assuming the form for 'repr()' of keys
[23:12] <lifeless> yes ;)
[23:13] <jam> mwhudson: what really surprises me about the bug, is that I've been running bzr.dev with the chk_map strict type checking for a while, and didn't encounter any problems until the day of release
[23:13] <jam> which is when I relaxed the type checking
[23:13] <jam> anyway, off to pick up the little boy
[23:13] <jam> have a good night
[23:13] <lifeless> never underestimate the power of users
[23:47] <poolie> hi jam