| === Edwin-lunch is now known as Edwin | ||
| === Edwin is now known as EdwinGrubbs | ||
| 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:23 |
|---|---|---|
| sven_oostenbrink | Can bzr diff also NOT throw errors when a file has a diff? | 00:31 |
| igc | morning | 00:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| sven_oostenbrink | poolie1: interresting... | 00:35 |
| bob2 | svn diff || true | 00:38 |
| 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:51 |
| johnf | or I could just search first instead of wasting peoples time and find the existing bug in launchpad | 00:52 |
| spiv | johnf: :) | 00:56 |
| johnf | hmm except that bug is fr symlinks which this isn't | 00:56 |
| 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:57 |
| 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 :( | 00:59 |
| 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:00 |
| jelmer | johnf: that check issue is the symlink one? | 01:03 |
| jelmer | johnf: reconcile should be able to fix that | 01:03 |
| 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:04 |
| 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:05 |
| spiv | IIRC bzr-svn doesn't use python-subversion, it uses jelmer's subvertpy | 01:11 |
| johnf | that's special fast-export-from-svn skips every single revision :) | 01:12 |
| johnf | spiv: ahh looks that way | 01:12 |
| johnf | This SVN repository is doing a good job of protesting my move to bazaar | 01:13 |
| === jam changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b2 have gone gold! time to build those installers| try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| 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:32 |
| 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:33 |
| * 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:34 |
| jam | well, just came out.. 5 min ago | 01:35 |
| jam | :) | 01:35 |
| jam | anyway, see y'all around later | 01:35 |
| 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:53 |
| igc | johnf: fast-export-from-svn just does trunk currently and it has a range of problems | 01:55 |
| 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:56 |
| 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:57 |
| johnf | Although I think I just got it working. I just need trunk anyway | 01:58 |
| 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:00 |
| poolie1 | igc, hi | 02:04 |
| poolie1 | igc, good idea | 02:04 |
| poolie1 | spiv, hi? | 02:04 |
| enatom | how can i use BZR with my www folder, if my www folder wont even allow me to create folders? | 02:07 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| enatom | the group i created isnt in the list, for the permission of the folder | 02:23 |
| 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 | 02:53 |
| 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:09 |
| 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:10 |
| poolie1 | does another volume come up in the mgmt console for that account? | 03:11 |
| mwhudson | is D: the part of the storage that doesn't persist on bunding? | 03:12 |
| 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:13 |
| jam | I see a "created volumes" section, but I don't see anything present | 03:15 |
| 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:17 |
| === timchen1` is now known as nasloc__ | ||
| 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:39 |
| johnf | Can I merge from B to A somehow. Can i manually specify the common ancestor or something? | 03:40 |
| SamB_XP_ | I think you'd need to use something evil | 03:41 |
| SamB_XP_ | like rebase or more fast-export | fast-import | 03:41 |
| johnf | yeah I tried fast-import but it can't add revisions to an existing branch | 03:42 |
| SamB_XP_ | oh, lame | 03:43 |
| johnf | I wonder what happens if I cat to fast-import files together :) | 03:43 |
| 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:44 |
| SamB_XP_ | well, what you should really avoid is using fast-import on SVN repos ;-P | 03:45 |
| * igc lunch | 03:54 | |
| johnf | sweet catting together fast-import files works!! | 04:02 |
| 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:08 |
| spiv | johnf: chmod -R a-w yourbranch | 05:10 |
| spiv | Oh, but you want to pull. | 05:10 |
| 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:11 |
| spiv | Or only make it writeable to a special user and then provide a sudo command to run pull (and only pull)? | 05:12 |
| 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:13 |
| 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:39 |
| 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:40 |
| lifeless | gight jam | 05:45 |
| igc | night jam | 06:02 |
| 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:28 |
| cody-somerville | oh, luckily I still had the files open so I can just resave and overwrite what bzr did. | 06:32 |
| bob2 | have you considered just using unbound branches? | 06:34 |
| vila | hi all | 07:15 |
| fullermd | vila: Heydere. What was it you muttered at my about this weekend? | 07:24 |
| fullermd | Oh, time drift. | 07:26 |
| 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:27 |
| 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:28 |
| fullermd | Oh. Well, so your problems solved then 8-} | 07:29 |
| vila | s/glag/glad/ :) | 07:29 |
| 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:31 |
| * 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| vila | 'via that' ? | 07:36 |
| fullermd | Yah, watching what ntpd is doing. | 07:36 |
| vila | /var/log/ ? | 07:36 |
| 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:37 |
| vila | grep -i ntp /var/log* => ./Xorg.0.log:24:(**) FontPath set to: , yeah great | 07:40 |
| vila | :) | 07:40 |
| 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:43 |
| vila | how ? | 07:44 |
| fullermd | ntpq -p | 07:44 |
| bob2 | ntpdate is the thing that (sometimes) runs only at boot | 07:44 |
| 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:45 |
| 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:46 |
| fullermd | And edit the config to point at your local ntp server, of course. | 07:47 |
| 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:48 |
| 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:49 |
| vila | fullermd: great, you rock :) | 07:50 |
| * fullermd buffs his nails on his lapel and looks important. | 07:52 | |
| 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:54 |
| 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:55 |
| 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:56 |
| vila | ha. I have ntp.conf under bzr, I *thought* I was using it at one point... :-/ | 07:57 |
| vila | ...but since there is a typo in it.... | 07:58 |
| fullermd | Oooh, somebody made a port of dulwich. | 07:58 |
| fullermd | As a side effect of making a hg-git port. Cute. | 07:59 |
| vila | Interesting... | 07:59 |
| marccc | good morning | 08:24 |
| marccc | i was wondering how i could add revision number and branch in the source when commiting automatically, any qlue's? | 08:27 |
| vila | marccc: bzr help version-info | 08:28 |
| vila | but putting such infos somewhere when committing is rarely the right thing to do | 08:28 |
| marccc | why is that? | 08:29 |
| fullermd | It sounds like what you really want is keyword expansion. | 08:29 |
| 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:30 |
| bob2 | so have your 'generate source tarball' script call version-info :) | 08:31 |
| bob2 | no need to do it on every ommit | 08:31 |
| * igc dinner | 08:34 | |
| marccc | is there a nice way to checkout and create a tarball with a revision number? | 08:34 |
| vila | fullermd: Ha, got that message back: calcru: runtime went backwards from 5773628818061961 usec to 4285 usec for pid 12 (intr) | 08:37 |
| 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:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| thumper | Adys: launchpad doesn't support updates over http | 08:44 |
| thumper | Adys: what is the command line you are using? | 08:44 |
| 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:45 |
| 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:47 | |
| vila | :) | 08:54 |
| 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:13 |
| 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:14 |
| Zapelius | I have a project that I initially | 09:16 |
| 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:17 |
| bob2 | so: bzr init-repo ~/repo/ ; bzr branch /wherver/it/is/now ~/repo/thingo/trunk | 09:18 |
| 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:19 |
| Zapelius | I'll look into that. thanks | 09:22 |
| 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:27 |
| spiv | ferringb: it'd be nice to do, but I don't think anyone has done one. | 09:33 |
| ferringb | spiv: anyone looked into it? | 09:38 |
| bialix | hi all | 09:39 |
| spiv | ferringb: not that I know of | 09:40 |
| ferringb | wonder if a lightweight checkout could be bastardized for it | 09:44 |
| 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:45 |
| vila | hi bialix | 09:59 |
| 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:08 |
| bialix | but it was you choice | 10:09 |
| vila | wow the series and milestones picture makes sense on https://launchpad.net/bzr ... that wasn't always the case... | 10:10 |
| vila | bialix: it's importance is medium, I didn't think it was urgent... | 10:12 |
| bialix | I don't understand this | 10:12 |
| vila | ? | 10:14 |
| bialix | IMO if bugfix is not API break it should got to latest stable release too | 10:16 |
| 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:17 |
| bialix | ok, nm | 10:18 |
| marccc | vila: thanks | 10:26 |
| vila | marccc: ?? export... bzr export... ? | 10:27 |
| marccc | bzr export | 10:27 |
| vila | marccc: ok, so you don't need any commit hook anymore ? (Just trying to understand if you original need is addressed) | 10:30 |
| marccc | yes, but the only thing i need now is the tag | 10:32 |
| vila | hmm, version-info doesn't support tag ? Worth filing a bug... | 10:34 |
| marccc | lets do that! | 10:35 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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 | 11:59 |
| 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:00 |
| backslash | soubor is file | 12:01 |
| backslash | it's actually Czech | 12:01 |
| bialix | ah, ok | 12:01 |
| 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:02 |
| bialix | hi GaryvdM | 12:03 |
| GaryvdM | Hi bialix | 12:03 |
| backslash | bialix: yes, 2.0 | 12:03 |
| 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:04 |
| === weigon_ is now known as weigon | ||
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| backslash | bialix, I'll go with C:\Project :) | 12:09 |
| bialix | :-) | 12:09 |
| bialix | C:\Prj :-D | 12:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| backslash | bialix: http://pastebin.com/m7fb93aa | 12:14 |
| 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:15 |
| 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:16 |
| bialix | also it fails on attempt to create directory | 12:17 |
| backslash | bialix: the directory is really there :DDD | 12:20 |
| bialix | what? | 12:21 |
| backslash | bialix, there really was a directory named ' ..' :) | 12:21 |
| bialix | ah | 12:21 |
| 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:22 |
| bialix | when this directory will gone you can get the branch | 12:23 |
| 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:25 |
| 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:26 |
| Peng | Murder seems a disproportionate response to crappy directory naming... :P | 12:28 |
| 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:44 |
| 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:45 |
| Peng | The version numbers are more a feature than a bug. | 13:46 |
| 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:47 |
| guilhembi | a test before push would have avoided spreading this problem to users (several colleagues hit this at Sun). | 13:48 |
| vila | guilhembi: but we can't make bzr check for all existing plugins, it has to be the other way around | 13:50 |
| 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:51 |
| 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:52 | |
| vila | this is being worked on with the PPAs that provide coherent versions, but then you have to use them | 13:53 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| vila | http://babune.ladeuil.net:26862/waterfall is where things are at today | 14:00 |
| guilhembi | vila: ok... nice... looks similar to buildbot? | 14:01 |
| vila | May be because it *is* buildbot :-D Good catch ;) | 14:01 |
| guilhembi | ahah | 14:02 |
| vila | guilhembi: by the way, your failing pull may be due to bzr-gtk migrating to the 2a format | 14:06 |
| Peng | guilhembi: Yeah, what was the error message? | 14:07 |
| mthaddon | pqm machine going down for hardware maintenance | 14:10 |
| Peng | Fun. What kind of maintenance? | 14:12 |
| jam | mthaddon: I'm trying to decide how hard to cheer for that :) | 14:18 |
| mthaddon | jam: I'd go with "a little" | 14:18 |
| vila | morning jam ! | 14:20 |
| jam | morning vila | 14:20 |
| 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:21 | |
| 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:22 |
| Peng | Great, now PQM can test 450 patches at once. :D | 14:23 |
| vila | james_w: ready for you when you are | 14:23 |
| james_w | vila: good timing! | 14:27 |
| === thunderstruck is now known as gnomefreak | ||
| jcastro | emmajane, about an hour! | 15:05 |
| emmajane | jcastro, amber already pinged me. ;) | 15:06 |
| emmajane | jcastro, you're late. ;) | 15:06 |
| jcastro | heh | 15:06 |
| LarstiQ | hour? | 15:06 |
| emmajane | LarstiQ, I'm giving a "so you think you want to be an author" talk for Ubuntu Open Week. | 15:07 |
| LarstiQ | aah :) | 15:08 |
| === statik` is now known as statik | ||
| marccc | ls | 15:19 |
| marccc | :-) | 15:19 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| Tak | is it intentional that bzr doesn't handle symlinks to symlinks? | 17:00 |
| Tak | hmm, it does handle them somewhat - but a recursive add misses them | 17:03 |
| === Dude-X_ is now known as Dude-X | ||
| === deryck[lunch] is now known as deryck | ||
| === fenris__ is now known as ejat | ||
| === beuno-lunch is now known as beuno | ||
| 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:15 |
| 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:16 |
| jfroy|work | verterok: pushed my changes for 2.0.2 to lp:~jeanfrancois.roy/+junk/SnowLeopard-package | 19:30 |
| 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:01 |
| 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:07 |
| 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:08 |
| phoenixz | perfect, perfect... | 20:09 |
| ferringb | yes'm. | 20:09 |
| === abentley1 is now known as abentley | ||
| === EdwinGrubbs is now known as Edwin-lunch | ||
| === sidnei is now known as sidnei-away | ||
| === Edwin-lunch is now known as EdwinGrubbs | ||
| 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:52 |
| mwhudson | happens with no-plugins too | 22:53 |
| mwhudson | seems something of a regression...... | 22:53 |
| mwhudson | jam: here? | 22:53 |
| mwhudson | seems to only happen on committing a merge | 22:57 |
| mwhudson | and a trivial test case doesn't reproduce | 22:58 |
| mwhudson | bah :( | 22:58 |
| lifeless | mwhudson: file a bug | 23:05 |
| mwhudson | lifeless: yeah will do | 23:05 |
| lifeless | some fallout expected | 23:05 |
| lifeless | releases will disable this with a flag to enable it | 23:06 |
| lifeless | trunk will continue to die die die | 23:06 |
| 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:07 |
| jam | which should be merged into bzr.dev | 23:08 |
| ubottu | Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,Fix released] https://launchpad.net/bugs/471193 | 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:08 |
| 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:09 |
| mwhudson | jam: http://pastebin.ubuntu.com/308926/ | 23:10 |
| lifeless | jam: suggestions were printing the result keys out and they because StaticTuples | 23:10 |
| 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:12 |
| 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:13 |
| poolie | hi jam | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!