| igc | morning | 00:43 |
|---|---|---|
| Peng_ | Good morning. :) | 00:52 |
| verterok | jfroy: pong | 01:38 |
| jfroy | verterok: just wanted to let you know I had pushed my packaging stuff | 01:52 |
| verterok | jfroy: cool :) | 01:53 |
| jfroy | it's kind of a half-baked solution. | 01:53 |
| jfroy | it will stage the various packages and plug-ins into independent "destination roots" that make it easy to build the distribution using Package Maker. | 01:53 |
| jfroy | The next step is to build the Package Maker document, or at least update the content files. | 01:54 |
| verterok | jfroy: I'm quite curious about this way of building the installer, as the weak point of my scrits is that I need to manually edit the pmproj/pmdoc | 01:55 |
| jfroy | same deal | 01:56 |
| verterok | jfroy: oh, :( | 01:56 |
| jfroy | I started building a PackageMakerDocument class in the script | 01:56 |
| jfroy | but it's not quite done | 01:56 |
| jfroy | I'll try to work on it when I have some free time. | 01:56 |
| verterok | jfroy: well at least in the case of .pmdoc it might be possible to do that from the script, as it's a bunch of xml's in a dir :) ,right? | 01:57 |
| jfroy | yep, that's the plan | 01:57 |
| verterok | jfroy: did you checkedout the branch I talked about in the mails? | 01:57 |
| jfroy | yes3 | 01:58 |
| jfroy | I picked the installer background from it :p | 01:58 |
| verterok | :) | 01:58 |
| verterok | jfroy: we should unify this into a single branch ;) | 01:58 |
| jfroy | yeah | 01:59 |
| verterok | jfroy: please..url of your branch? (/me is imIn the branch there is a lot of stuff to download depedencies, plugins, etc and build the packages, docs, and also to generate the DMG.) | 01:59 |
| verterok | Looks like you know a thing or two about building installer ;) | 01:59 |
| verterok | It would be great if you can include this way of building it as part of the scripts included in https://code.launchpad.net/~verterok/bzr/OSX-10.4-dmg so we finally get an automated way to build thins. | 01:59 |
| verterok | oops, sorry | 01:59 |
| verterok | cliboard failure :( | 01:59 |
| jfroy | lp:~jeanfrancois.roy/+junk/SnowLeopard-package | 01:59 |
| verterok | jfroy: please..url of your branch? (/me is impatiante) :) | 01:59 |
| verterok | jfroy: thanks | 01:59 |
| verterok | jfroy: the PackageMakerDocument it's quite cool | 02:01 |
| jfroy | and very much not done :p | 02:02 |
| verterok | jfroy: yes, but it's a start | 02:02 |
| jfroy | it shouldn't be too hard though to finish | 02:02 |
| jfroy | although there are some complexities to deal with, well special cases really | 02:02 |
| jfroy | My package has a custom requirement on bzr-svn such that bzr-svn is disabled if subvertpy is disabled | 02:03 |
| jfroy | need to figure out a nice way to put that in place | 02:03 |
| verterok | jfroy: I just read your mail. both solutions are quite similar from 1000ft, mine using bdist_mpkg and generating the doc. | 02:06 |
| jfroy | yeah | 02:07 |
| jfroy | though I produce a more "modern" single-file package | 02:07 |
| verterok | jfroy: I;d like to remove the dependency on bdist_mpkg as it forces me to patch each plugin setup.py in the build process | 02:07 |
| jfroy | yeah, for plug-ins I don't "install" them | 02:07 |
| jfroy | I just stage them inside bzrlib | 02:08 |
| jfroy | and run build_ext --in-place on them | 02:08 |
| lifeless | I have a patch for bzr | 02:08 |
| lifeless | back on bundle buggy | 02:08 |
| lifeless | which bundles many plugins | 02:08 |
| lifeless | the reason its not merged | 02:08 |
| lifeless | is that it doesn't run build_ext --in-place on them nor install them when setup.py install is called. | 02:09 |
| * lifeless would love to see someone pick that up and run with it | 02:09 | |
| verterok | jfroy: I'll try to use your scripts to build the Leopard and Tiger installers | 02:11 |
| jfroy | ok | 02:12 |
| verterok | jfroy: and possibly include the download script from my branch ;) | 02:12 |
| jfroy | yes, that would be a nice combo | 02:12 |
| verterok | jfroy: so, regarding ian comments, it's ok with you about labeling your installer as a core-installer? (I'll try to build a matching installer for Leopard and Tiger) | 02:14 |
| verterok | jfroy: and also build the 'desktop' version for them too | 02:14 |
| jfroy | yes it's fine I think | 02:15 |
| jfroy | since I don't include any GUI-related plug-ins. | 02:15 |
| verterok | jfroy: ok, cool :) | 02:15 |
| jfroy | In any case, I think it's useless to offer qbzr and bzr-explorer if you're not going to also bundle Qt and py-qt | 02:15 |
| jfroy | It's like "here's a super nice car, but we won't give you the engine. Go build one yourself." | 02:16 |
| verterok | jfroy: it might be, I don't really know | 02:16 |
| verterok | jfroy: I'll packaging pyqt with your approach | 02:17 |
| verterok | jfroy: don't know about QT, installing it is quite easy | 02:17 |
| jfroy | Qt is OK. | 02:17 |
| jfroy | If you bundle PyQT that would make it all pretty easy. | 02:17 |
| jfroy | oh one particular thing | 02:18 |
| jfroy | we should refactor the compiler to use based on the system version and store it as a Builder class attribute or something. | 02:18 |
| jfroy | We want gcc 4.0 on 10.4, gcc 4.2 on 10.5 and llvm-gcc-4.2 on 10.6 :/ | 02:19 |
| verterok | jfroy: ok, I'll take a look to this compiler thing :) | 02:20 |
| verterok | thanks | 02:21 |
| jfroy | verterok: I've pushed an updated readme that addresses Ian's feedback. | 02:26 |
| verterok | jfroy: ok, thanks | 02:29 |
| jfroy | fixing the compiler thing now | 02:30 |
| verterok | jfroy: I was thinking about that, we can check which compiler to use at runtime ;) | 02:32 |
| jfroy | and fixed | 02:33 |
| jfroy | (and pushed) | 02:33 |
| jfroy | whoa, or not | 02:33 |
| jfroy | oh, duh | 02:34 |
| jfroy | hate you mac_ver() | 02:34 |
| verterok | jfroy: I'm using bdist_mpkg to do that in my scripts: "from bdist_mpkg import tools; osx_version = '.'.join(map(str, tools.sw_vers().version[:2]))" | 02:34 |
| lifeless | igc: on the wiki | 02:34 |
| lifeless | igc: perhaps we should say 'every 6 months, with beta releases available every month' | 02:35 |
| igc | lifeless: yep, that's better | 02:35 |
| jfroy | OK fix pushed :p | 02:35 |
| jfroy | yeah, I wasn't casting to ints and using ints in my branch :p | 02:36 |
| lifeless | igc: are you still editing [in which case can you do it], or should I make the change? | 02:36 |
| igc | lifeless: you can do it - I'm not editing | 02:37 |
| verterok | jfroy: cool, thx | 02:39 |
| jfroy | strange | 02:39 |
| jfroy | it's not using llvm for linking... | 02:39 |
| jfroy | Do you need to set more than CC? | 02:39 |
| verterok | jfroy: no idea :) | 02:40 |
| jfroy | and yes you do, LDSHARED :/ | 02:41 |
| jfroy | bah | 02:41 |
| jfroy | or not? | 02:42 |
| jfroy | weird, nm | 02:46 |
| igc | jfroy, verterok: great to see you guys chatting about this stuff! While it's desirable in the medium term, I don't think we're ready to combine the Windows and Mac installers into one project yet ... | 02:48 |
| jfroy | huh, we didn't propose that? | 02:48 |
| igc | jfroy, verterok: so maybe one of you should create a project called bzr-mac-packaging and put your combined branch there | 02:49 |
| verterok | igc: agreed | 02:49 |
| igc | jfroy: no, jam suggested it on the mailing list | 02:49 |
| jfroy | oh, well, it doesn't make sense? | 02:50 |
| igc | jfroy: so plugin authors like jelmer had one project to update after releasing a new bzr-svn say | 02:50 |
| jfroy | it's not their responsibility IMO | 02:50 |
| jfroy | they should just announce new releases on the mailing list | 02:51 |
| jfroy | package maintainers can pick them up when appropriate | 02:51 |
| verterok | igc: once I merge both branches, actualle jfroy branch + some utilities from my branch, I'll push it and create the project | 02:51 |
| igc | jfroy: that would work as well. The trick is getting the right combo of bzr-svn+subvertpy+bzr-rewrite and we'd prefer jelmer to own updating that for the Windows installer | 02:52 |
| igc | jfroy,verterok: anyhow, I'm *really* pleased to see os x packaging progressing | 02:53 |
| igc | verterok: I'm with jfroy wrt needing PyQt and Qt bundled for the "desktop" installer - bundling qbzr and explorer without those also bundled doesn't help much | 02:55 |
| jfroy | igc: fair enough, but I'm sure we can establish communication with him and deal with it | 02:55 |
| igc | verterok: Qt is a simple install but PyQt is a nightmare for casual users | 02:55 |
| verterok | igc: I'll try to use jfroy approach to build pyqt | 02:55 |
| jfroy | igc: this is going to take more time to come up with, which is why I only worked on a core installer. | 02:56 |
| jfroy | we could get the open-source Qt installer and merge it all in into one giant package :p | 02:57 |
| jfroy | but it won't be small -- probably > 30 MB | 02:57 |
| jfroy | well, not that that's particularly large by today's standards | 02:57 |
| lifeless | spiv: around? | 03:25 |
| fullermd | Huh. First 2 chars of the MD5 of bzrtools 2.0.1 are the same as that of 2.0. Good thing it's not an 8-bit hash... | 03:25 |
| lifeless | \o/ | 03:26 |
| lifeless | creepy | 03:26 |
| fullermd | Maybe it's a coincidence. Or maybe it's part of the plan of the global banking cartel! | 03:27 |
| spm | that'd be the new bzr --crack-md5 feature isn't it? | 03:30 |
| lifeless | distributed virtual cracking system | 03:31 |
| spm | 'zactly | 03:31 |
| === sdboyer_ is now known as sdboyer | ||
| fullermd | Yeah, we're merging that into 2.0.x, just 'cuz nobody would expect to see it in a stable release. It's more sekrit that way. | 03:31 |
| lifeless | we'll respin 2.0.0 in fact, without changing the md5sum, cause thats the point | 03:32 |
| spm | bzr: taking over the world, one cracked md5sum at a time | 03:33 |
| fullermd | 1 down, 340282366920938463463374607431768211455 to go! | 03:33 |
| spm | so by next tuesday? | 03:33 |
| fullermd | Wednesday more likely. I have an early tee time on Tuesday. | 03:34 |
| spm | far be it for us to let world domination get in the way of a game of golf! your excuse is acceptable. | 03:35 |
| === tro|| is now known as tro | ||
| spiv | lifeless: yeah, what can I do for you? | 03:58 |
| lifeless | spiv: various bug state questions | 03:58 |
| spiv | hit me, as they say. | 03:58 |
| lifeless | spiv: I'm picking $foo to work on, check your mail is sufficient at this point | 03:58 |
| lifeless | 'hit me with your rhthym Stig' could have a whole new meaning ;) | 03:59 |
| meoblast001 | how do you apply patches with Bazaar? | 04:00 |
| lifeless | from other bzr users? | 04:01 |
| meoblast001 | no, from myself | 04:01 |
| lifeless | bzr merge generally | 04:01 |
| meoblast001 | well, i created a diff with bzr diff | 04:01 |
| spiv | (A rhythm Stig? I'm imagining a car racing around a course while playing a tune by careful revving of the engine...) | 04:01 |
| meoblast001 | and i'd like to apply it at a different directory | 04:01 |
| lifeless | spiv: yup | 04:01 |
| lifeless | spiv: that was the sort of image I was hoping to provoke | 04:02 |
| AfC | meoblast001: the "different directory" is also a Branch with a WorkingTree ? | 04:02 |
| lifeless | meoblast001: bzr patch can do that, but if you did something like | 04:02 |
| lifeless | 'bzr diff -r x..y' | 04:02 |
| lifeless | to make the patch, then I'd like to introduce you to | 04:02 |
| meoblast001 | hm, i checked bzr <tab> and didn't see patch | 04:02 |
| lifeless | 'bzr send -r x..y $path_to_trunk -o-' | 04:02 |
| lifeless | which will make a rich patch | 04:03 |
| lifeless | which 'bzr merge' or 'bzr pull' can use directly. | 04:03 |
| meoblast001 | bzr: ERROR: unknown command "patch" | 04:03 |
| lifeless | its in the bzrtools plugin | 04:03 |
| meoblast001 | oh | 04:03 |
| lifeless | but like I say, its _very_ unusual to use patches to move stuff from one bzr tree to another | 04:03 |
| spiv | meoblast001: I'm not certain about exactly what you want to achieve, but GNU patch doesn't stop working just because there's a .bzr directory somewhere :) | 04:03 |
| lifeless | and by very, I mean very very very very | 04:04 |
| meoblast001 | spiv: i tried GNU patch and it didn't do anything, maybe i don't know how to use it :/ | 04:04 |
| meoblast001 | patch -p0 blah.diff? | 04:04 |
| spiv | meoblast001: but as lifeless is saying, I'm surprised that you can't use "bzr merge". Can you explain more about what you are doing? | 04:04 |
| meoblast001 | i have 1 branch that i was modifying, when i realized i had to make some modifications to my entire branch that would make all checkouts incompatible (had to overwrite the branch on launchpad) | 04:05 |
| meoblast001 | so now, i can't continue editing the old copy until i apply the difference to the new one | 04:05 |
| spiv | meoblast001: perhaps you want "bzr merge --uncommitted"? | 04:06 |
| meoblast001 | which am i doing bzr merge on? | 04:06 |
| meoblast001 | how would i apply the patch with GNU patch? | 04:06 |
| spiv | You have an "old copy" and a "new one", and they are both bzr branches of the same project? | 04:06 |
| meoblast001 | yes, but one is now incompatible | 04:06 |
| meoblast001 | i knew that not many people at all had a checkout of my project, so i went forth with fixing some problems with older commits | 04:07 |
| meoblast001 | this made my own older branches incompatible | 04:07 |
| spiv | You rebased? | 04:07 |
| meoblast001 | well, i fast-exported :P | 04:07 |
| meoblast001 | i had to remove a font, a directory, and 2 source files that really should have never been there | 04:08 |
| spiv | Ok, that explains a lot. | 04:08 |
| spiv | (As well as demonstrating why history rewriting of published branches is a bad idea :P ) | 04:08 |
| meoblast001 | and my project is only a half year old, i'm pretty sure only 2 people (including me) have a checkout | 04:08 |
| * fullermd . o O (Famous last words? :) | 04:09 | |
| spiv | So you effectively want to rebase some changes from the old history onto the new history. | 04:09 |
| meoblast001 | basically, i want to construct a patch of uncommitted changes to my old, incompatible branch, and apply them to my new branch | 04:10 |
| spiv | diff/patch should work ok for that, I'd think, assuming you don't mind bringing the change across in a single commit. | 04:10 |
| meoblast001 | i made the diff, i just can't get it to apply | 04:10 |
| meoblast001 | well, the only thing i'm trying to bring across is uncommitted changes anyway | 04:10 |
| spiv | If fast-export has kept the file-ids the same, then "cd new-one; bzr merge --uncommitted ../old-one" would work,. | 04:10 |
| spiv | But I would expect "patch -p0 blah.diff" to work too. How does it fail? | 04:11 |
| meoblast001 | it just sits there, and does nothing | 04:12 |
| meoblast001 | maybe i'm not waiting long enough? | 04:12 |
| fullermd | patch doesn't take the patch file as an argument... | 04:12 |
| spiv | Oh, "patch -p0 < blah.diff" maybe. | 04:12 |
| spiv | "bzr patch" is more convenient in this respect :) | 04:13 |
| meoblast001 | 1 out of 1 hunk FAILED -- saving rejects to file src/Makefile.am.rej | 04:13 |
| meoblast001 | hm | 04:13 |
| meoblast001 | i know what that is | 04:13 |
| meoblast001 | since fallbacks.cpp was one of the files i removed, it isn't in the new Makefile.am | 04:13 |
| * igc lunch | 04:18 | |
| malibu | Hi there... so now that bzr is at 2.0.0.... Does TortoiseBZR work better / FASTER ? | 04:43 |
| lifeless | malibu: Tortoise hasn't been radically changed by the work on 2.0; I think naoki was doing some work on it though. | 04:45 |
| lifeless | so it may be better, but its not really cause of 2.0 :) | 04:45 |
| malibu | Is there anywhere where the changes may be logged? | 04:46 |
| lifeless | the tortoisebzr project I imagine ;) | 04:48 |
| lifeless | [sorry I don't know quite where that is] | 04:48 |
| malibu | ohh.. yeah I found it | 04:49 |
| malibu | it doesn't work for lightweight checkouts and won't be fixed.... darn | 04:49 |
| lifeless | why do you need lightweight checkouts? for most folk a regular checkout is much better | 04:50 |
| malibu | I put everything in my repository.. install files, config files.. I use it to sync my machines from my own server, like dropbox | 04:51 |
| malibu | If I do not do lightweight, there is too much space used by the .bzr directory | 04:52 |
| malibu | I had the same problem with subversion and git | 04:52 |
| malibu | But using lightweight, the .bzr directory stays small | 04:52 |
| malibu | It has been working quite well for me for a couple months now.. But I had hoped to get TortoiseBZR to work at some point | 04:53 |
| malibu | I didn't realize there wasn't enough in the .bzr directory to allow it to work at all | 04:54 |
| malibu | I had thought bazaar could still track what files had been changed since last update / commit | 04:54 |
| lifeless | we can tell 'not the same' | 04:55 |
| lifeless | but will stil connect to the network | 04:56 |
| malibu | For lightweight, it would be nice to still work offline by checking modification dates. | 04:56 |
| malibu | oh erll | 04:58 |
| malibu | well | 04:58 |
| lifeless | there is metadata needed that isnt in a lightweight checkout | 04:58 |
| lifeless | which is why we connect to the repo | 04:58 |
| malibu | unfortunately for me.. | 04:59 |
| malibu | Still, bzr is the best for my purposes | 05:00 |
| malibu | Is there a way to do a normal checkout but limit the size of the .bzr ? | 05:00 |
| malibu | Sometimes I've seen it get just as big as the actual working copy | 05:01 |
| lifeless | malibu: sorry, I've got to pop out | 05:01 |
| malibu | I guess something like lightweight with the metadata.. which I assume is small | 05:02 |
| malibu | ok | 05:02 |
| malibu | later | 05:02 |
| verterok | jfroy: still around? | 05:02 |
| lifeless | spiv: igc: if you need me SMS me | 05:02 |
| jfroy | aye | 05:02 |
| lifeless | I won't be far, but $stuff to $do | 05:02 |
| verterok | jfroy: looking to your branch, I realized there is no mention of pycrypto or paramiko | 05:02 |
| jfroy | yeah I haven't included them. | 05:03 |
| jfroy | probably should I guess | 05:03 |
| verterok | jfroy: hmm, probably :) | 05:04 |
| spiv | lifeless: happy $doing of $stuff :) | 05:05 |
| * spiv -> lunch | 06:03 | |
| vila | hi all | 07:19 |
| Peng_ | Hello. :) | 07:23 |
| bialix | hello bzr | 08:08 |
| spiv | Hello bialix :) | 08:09 |
| bialix | hello spiv | 08:09 |
| bialix | :-) | 08:09 |
| rusty | So, if I really want people to be able to browse my repo in a web server, I really need fastCGI et al? (ccan used the hgweb stuff, and it broke with a recent upgrade) | 08:33 |
| nedosa | hi, i have a question about rebase, i'm getting the "No revisions to rebase." message | 08:36 |
| nedosa | Tried it on a simple test case, created a new child branch, made some commits, then tried to run rebase on the child branch against the parent | 08:37 |
| nedosa | even then, it would give me "No revisions to rebase" | 08:37 |
| spm | rusty: if I understand your meaning; you can use loggerhead without an apache/web-server per-se. Or are you meaning super performance issues? | 08:39 |
| rusty | spm: nope... thanks, just found that by punching right keywords into google :) | 08:40 |
| poolie | hello spm, rusty | 08:40 |
| spm | hey poolie | 08:40 |
| spm | poolie: how's london? | 08:40 |
| rusty | poolie: hi! | 08:41 |
| poolie | pretty normal: grey, coldish, full of canonical people | 08:41 |
| poolie | pretty good really | 08:41 |
| spm | heh | 08:42 |
| lifeless | poolie: hi poolie | 08:56 |
| bialix | hello poolie | 08:56 |
| bialix | the whole universe looking at poolie and asking: when? | 08:57 |
| poolie | the final announce? | 08:59 |
| poolie | today! | 09:00 |
| poolie | but right now... tada, a meeting! | 09:00 |
| spiv | Woo! | 09:00 |
| lifeless | poolie: :P | 09:00 |
| lifeless | poolie: have a good week | 09:00 |
| poolie | exciting lp & bzr hacks for 4.0 | 09:00 |
| spiv | He's such a tease. | 09:01 |
| lifeless | hehe | 09:01 |
| fullermd | Jeez, we just finally got 2.0, and already we're talking about 4.0? | 09:01 |
| lifeless | lp 4.0 | 09:01 |
| spiv | fullermd: exponential improvement! | 09:01 |
| spiv | (or he's talking about Launchpad 4.0...) | 09:02 |
| lifeless | txen rzb si 1.2 | 09:02 |
| * spiv wanders off | 09:02 | |
| lifeless | igc: are we talking past each other? | 09:13 |
| rusty | OK, how does loggerhead know what repos to serve? | 09:14 |
| rusty | So far I have a blank page: http://ccan.ozlabs.org/repo/ | 09:14 |
| lifeless | rusty: how are you running it? | 09:14 |
| lifeless | rusty: the general way is 'bzr serve --http <path[cwd implied]>' | 09:14 |
| rusty | lifeless: via apache. I am *TRYING* to replace the hgweb hack which was broken in the move. | 09:14 |
| lifeless | rusty: so in apache you have a proxypass | 09:15 |
| lifeless | rusty: yes? | 09:15 |
| rusty | Yep... | 09:15 |
| lifeless | right | 09:15 |
| rusty | lifeless: as you can see, it's hitting loggerhead. | 09:15 |
| lifeless | so the backend is what matters - how are you starting loggerhead | 09:15 |
| rusty | lifeless: ? from /etc/init.d/loggerhead ? | 09:15 |
| lifeless | rusty: can you pastebin that somewhere? | 09:16 |
| rusty | lifeless: it's standard ubuntu package... | 09:16 |
| lifeless | rusty: I'm pretty sure that the packaging adds the init script | 09:16 |
| lifeless | rusty: upstream its 'bzr serve --http' as I said :) | 09:16 |
| Peng_ | Which version of Loggerhead? | 09:18 |
| rusty | Peng: 1.10-1.. actually,t his is debian Sid. | 09:19 |
| rusty | lifeless: basically "start-stop-daemon -p $PIDFILE -S --startas /usr/bin/start-loggerhead -- -p $PIDFILE -c /etc/loggerhead.conf -L /var/log/loggerhead 2>/dev/null" | 09:20 |
| lifeless | ugh | 09:20 |
| lifeless | so we all roundly hate loggerhead.conf | 09:20 |
| lifeless | but thats what you'll need to edit | 09:20 |
| rusty | lifeless: it doesn't seem to have a "here is my repo" option. | 09:21 |
| Peng_ | Or you could upgrade. | 09:21 |
| lifeless | rusty: | 09:22 |
| lifeless | [ccan] | 09:22 |
| lifeless | name = 'ccan' | 09:22 |
| lifeless | auto_publish_foder='/path/to/root/containing/branches' | 09:22 |
| lifeless | url_prefix='http://ccan/webroot/branches' | 09:23 |
| lifeless | #(or whatever) | 09:23 |
| rusty | lifeless: /path == dir which has .bzr subdir? | 09:23 |
| lifeless | rusty: the root area to want to server our | 09:24 |
| lifeless | *out* | 09:24 |
| lifeless | root-of-the-area | 09:24 |
| rusty | lifeless: I ahve a ccan repo. Actually, just a .bzr/ dir (it's not checked out). | 09:25 |
| rusty | lifeless: I want to serve it on the intertubes. | 09:25 |
| lifeless | rusty: righto, so put the path to the repo as the auto_publish_folder | 09:25 |
| rusty | lifeless: it is in /home/ccan/ccan/ | 09:25 |
| lifeless | rusty: is it just one branch, or many? | 09:25 |
| rusty | lifeless: yeah, that's waht I though. Still blank. | 09:25 |
| rusty | lifeless: just one. | 09:26 |
| lifeless | I was assuming many | 09:26 |
| lifeless | for one | 09:26 |
| rusty | May have branches in future, but today, one. | 09:26 |
| lifeless | is there a shared repo at /home/ccan ? | 09:26 |
| lifeless | [where would other branches go, in future] | 09:26 |
| rusty | No, I use ssh hack to allow commit access. OK, -ETIMEDOUT. I'll decide what to do tomorrow... | 09:27 |
| garyvdm | Hi all | 09:31 |
| garyvdm | vila: I would like to make a change to bzr-upload. I just want to see what you think of the idea first. | 09:31 |
| vila | garyvdm: hi, what is your idea ? | 09:32 |
| garyvdm | I would like for it to check on upload, that the revision that you are uploading is a decedent of the revision that was there. | 09:32 |
| garyvdm | Just like bzr push | 09:32 |
| vila | wow poolie in my TZ ! Welcome ! :) | 09:32 |
| garyvdm | And add a --overwrite option to disable it. | 09:33 |
| lifeless | vila: poolie is offline :P | 09:34 |
| vila | garyvdm: That sounds useful and coherent with push, so +1 on the idea | 09:34 |
| garyvdm | vila: Cool - I'm going to start on that now :-) | 09:34 |
| vila | lifeless: rats, missed that in my vgrep, and of course I didn't use completion *this* time :D | 09:36 |
| vila | hi bialix | 09:36 |
| loxs_wrk | folks is it safe to rename branches inside a --no-trees repository? Is it ok to do it with mv or do I need to use bazaar somehow for this purpose? | 09:39 |
| fullermd | loxs_wrk: As long as you don't mv it outside the repository, that's fine. | 09:39 |
| fullermd | (of course, anything pointing at the old location will need to be updated) | 09:39 |
| loxs_wrk | yeah, that's obvious | 09:40 |
| loxs_wrk | thanks | 09:40 |
| nedosa | hi all, i have a quick question about bzr rebase | 09:42 |
| nedosa | I keep getting "No revisions to pull." whenever i try and do a rebase | 09:45 |
| NET||abuse | hey guys. | 09:50 |
| NET||abuse | i've got a local branch for a stand alone branch, but i pushed it up to my web server over bzr+ssh last week, to just get the branch backed up,, how can i alias the remote branch address? | 09:51 |
| NET||abuse | so i can just do bzr push mywebsitealiasname | 09:51 |
| NET||abuse | since the web bzr+ssh path is already stored in the related branches attribute in bzr info. | 09:52 |
| lifeless | nedosa: probably you have no local work or something; file bugs on bzr-rebase please. | 09:52 |
| lifeless | NET||abuse: install the bookmarks plugin | 09:52 |
| NET||abuse | aohhhh,, | 09:52 |
| NET||abuse | i'm on intrepid, is that installed by default? | 09:53 |
| vila | NET||abuse: 'bzr plugins' will tell you | 09:53 |
| NET||abuse | pqm, upload, dbus, tools, deb, netrc credential store. | 09:56 |
| nedosa | lifeless: well, i have a very simple test case, empty an empty repo, add a file, commit, then branch that, add a few more commits to my child branch | 09:56 |
| vila | NET||abuse: then you don't have it | 09:56 |
| lifeless | nedosa: yes, and so you have nothing new to pull into your child branch do you? | 09:57 |
| vila | NET||abuse: cd $PLUGINS ; bzr branch lp:bzr-bookmarks bookmarks | 09:57 |
| nedosa | lifeless: sorry, i meant create an empty repo....now if I do a bzr rebase from my child branch, it say "No revision to rebase." | 09:57 |
| lifeless | nedosa: yes, as I said, you have nothing new to pull in in the example you've described | 09:59 |
| nedosa | lifeless: I see o.k., maybe I'm missing how rebase should work then | 10:00 |
| lifeless | nedosa: you have two branches, the trunk and the child, and the child is missing nothing from trunk; what do you expect rebase to do in that situation? | 10:00 |
| nedosa | lifeless: I expected the changes to be pushed onto the trunk and there I would be able to re-arrange my commits | 10:01 |
| lifeless | so, to push changes to trunk, use bzr push | 10:01 |
| lifeless | even in git rebase wouldn't do anything in this situation :) | 10:01 |
| lifeless | as for rearranging commits, I think thats basically unimplemented in bzr's rebase - there isn't a rebase -i yet. | 10:02 |
| NET||abuse | vila, $PLUGINS doesn't seem to be set to anything for me. | 10:02 |
| vila | NET||abuse: sorry, I meant <whatever your plugins directory is> | 10:03 |
| bialix | bonjour vila | 10:03 |
| nedosa | oh i see, I thought modifying the history of a branch meant rearranging the commits, apologies | 10:03 |
| vila | NET||abuse: 'bzr version' should tell you that | 10:03 |
| NET||abuse | vila, :) figured... ok, branched that stuff.. | 10:03 |
| nedosa | lifeless: so as it stands, there's nothing in bzr that re-arrange commits, is that right ? | 10:03 |
| spiv | NET||abuse: out of interest, why do you need an alias? "bzr push" remembers the push address so you don't need to type it again next time. | 10:10 |
| lifeless | spiv: he wants two, lp and a backup | 10:10 |
| lifeless | spiv: AIUI | 10:10 |
| NET||abuse | exactly, i was planing on pushing to a backup server location also.. so having a few bookmarks / aliases is a good thing. | 10:11 |
| igc | hi lifeless | 10:16 |
| igc | lifeless: so I think we can't close bug 116094 as "Fix Released" | 10:17 |
| ubottu | Launchpad bug 116094 in bzr "local clone without shared repository is too slow" [High,Fix released] https://launchpad.net/bugs/116094 | 10:17 |
| igc | we could say "Won't fix" - don't do that | 10:17 |
| lifeless | igc: do you think we're going to make copying history substantially faster? | 10:17 |
| igc | lifeless: not while we have our current approach | 10:18 |
| lifeless | igc: because I think we've tapped out all the low hanging fruit that make sense, and the next speed jump is going to be a tonne more C | 10:18 |
| igc | lifeless: if we detected 'local branch' and did just (lock branch, cp -a) under the covers we could | 10:19 |
| lifeless | igc: I think it *is* fixed, because we've made it fast, its not doing what 'hg is'. | 10:19 |
| igc | lifeless: the trap with reocmmending cp -a is lack of locking | 10:19 |
| fullermd | cp -a also isn't what you want when branch'ing into an existing repo... | 10:20 |
| lifeless | igc: I'd be amazed if git is as fast as hg, git does an actual history copy AFAIK | 10:20 |
| lifeless | igc: the recommended way to use git is to make a local branch in the repo, which is ~ what bzr branch in a shared repo is. | 10:20 |
| igc | lifeless: so the use cases for 'local branch' are (1) create a feature branch (2) take a backup | 10:20 |
| lifeless | igc: I want to understand why you think we *haven't* solved it - we got a report that cloning was way to slow, and now its not. | 10:21 |
| lifeless | igc: its not the same as hg, because we're not hg. | 10:21 |
| igc | lifeless: I still think the bug is clear ... *local* branch *outside* a shared repo is slow | 10:22 |
| igc | lifeless: and at 20 minutes for OOo on a super-fast desktop, I don't understand how you think we can say it's fixed | 10:22 |
| lifeless | igc: I think its exactly as slow as it should be to do a history copy | 10:22 |
| lifeless | its very understandable: copying within repositories is ~= symlinking, copying out of them processes history | 10:23 |
| igc | lifeless: as I said, 'cp -a' is what we'll be compared against and 20 minutes is far greater than 90 seconds | 10:23 |
| lifeless | igc: If we're going to do more work on it, the bug should stay open. If not, it should be closed. | 10:23 |
| lifeless | igc: this isn't about what we're compared to, its about whether we're going to do more in this space or not. | 10:24 |
| igc | lifeless: so close it as "Won't Fix" | 10:24 |
| lifeless | fine | 10:24 |
| igc | lifeless: please don't claim it's fixed | 10:24 |
| lifeless | igc: having spent nearly 2 years making it faster I find calling that work 'wont fix' really objectionable | 10:24 |
| igc | lifeless: branching over a network is faster - granted | 10:25 |
| lifeless | but if it will stop the fighting, we'll call it that | 10:25 |
| lifeless | I feel like you are arguing 3 different bugs as reasons to keep this open | 10:25 |
| lifeless | but not suggesting that we should be doing more work on the specific thing this bug was about | 10:26 |
| igc | lifeless: I don't think local branching is much faster for 2a than pack is it? | 10:26 |
| lifeless | igc: it was opened *on knits* | 10:26 |
| lifeless | igc: I think fix released is appropriate when we've done a lot of work to address a bug, whether or not we reached the rather arbitrary goal that the filer set | 10:28 |
| lifeless | igc: if we didn't address it at all, wont fix would be appropriate | 10:28 |
| NET||abuse | hmm, so i have a bit of a disjointed directory structure in my app, how can i export a portion or two from my bzr working tree to deployment locations, | 10:31 |
| NET||abuse | doing this locally to the web server | 10:31 |
| lifeless | igc: and I've got to say, this back and forward leaves a rather unpleasant taste in ones mouth. How can we avoid it? | 10:35 |
| igc | lifeless: sorry, I'm not trying to be difficult | 10:35 |
| igc | lifeless: I just feel the bug isn't fixed | 10:36 |
| lifeless | igc: If I demonstrated that on the history of the day we're now appropriately fast, would you be convinced? | 10:36 |
| igc | lifeless: if you take any large project and bzr is within 100% of git or hg for 'local clone', I think it's fixed | 10:37 |
| igc | lifeless: i just timed 'git clone' on the kernel - 13 seconds | 10:38 |
| igc | lifeless: I don't think my fastimport of the kernel worked but I suspect we're a few minutes, not 26 seconds | 10:39 |
| igc | the git time was cold cache btw | 10:39 |
| lifeless | igc: I'm presuming it does history processing | 10:41 |
| igc | lifeless: http://www.kernel.org/pub/software/scm/git-core/docs/git-clone.html suggests it hardlinks by default if the source and target are both local | 10:45 |
| lifeless | igc: test across two filesystem then ;) | 10:45 |
| lifeless | igc: hardlinking is a really bad behaviour IMO, for a number of reasons | 10:45 |
| lifeless | igc: or perhaps use --no-hardlinks | 10:46 |
| lifeless | igc: so, I object to bugs being open that we're not going to action; I feel that as we have improved more than enough to fix the original report it should be closed. | 10:47 |
| lifeless | igc: and I feel like you're basically moving the goalposts on the bug | 10:48 |
| igc | so git clone --no-hardlinks on the kernel took 10.3 seconds (cold cache) | 10:48 |
| spiv | Less than hardlinking? That's surprising. | 10:49 |
| igc | spiv: maybe my drop-caches script is too soft? | 10:50 |
| igc | echo 1 | sudo tee /proc/sys/vm/drop_caches | 10:50 |
| igc | should I use 3 instead of 1? | 10:50 |
| spiv | I think 2 or 3. | 10:50 |
| igc | spiv: thanks. I'll try again | 10:51 |
| spiv | You need 2 to drop the fs metadata cache. | 10:51 |
| lifeless | I use 3 | 10:51 |
| spiv | I'd just use 3, you may as well turn the knob up to the max :) | 10:51 |
| lifeless | also you still need to avoid the 'just cp' facilies | 10:52 |
| lifeless | facility | 10:52 |
| igc | hmm - just tried 3 - still takes 10 seconds | 10:52 |
| spiv | The man page for proc also says you ought to run sync before writing to drop_cache, otherwise there may be dirty pages the kernel cannot drop. | 10:54 |
| ScriptFanix | helloo | 10:54 |
| ScriptFanix | -o | 10:54 |
| spiv | Hi | 10:55 |
| ScriptFanix | I have a question abour bzr builddeb and file permissions | 10:55 |
| james_w | hello ScriptFanix | 10:55 |
| ScriptFanix | in my branch, I have file with mode 700 or 600 | 10:55 |
| lifeless | :!less ~/bin/drop-caches | 10:55 |
| lifeless | #!/bin/sh | 10:56 |
| lifeless | # get written data to disk (not that its guaranteed) | 10:56 |
| lifeless | sync | 10:56 |
| lifeless | # (drop the unmodified pages) | 10:56 |
| lifeless | echo 3 | sudo dd of=/proc/sys/vm/drop_caches 2>/dev/null | 10:56 |
| lifeless | is mine | 10:56 |
| ScriptFanix | when I run bzr builddeb -e --native, those file and up with permissions 644 / 755 | 10:56 |
| james_w | ScriptFanix: which files? | 10:57 |
| ScriptFanix | I and up with a debian package with files containing potentially sensitive information world-readable (bad bad bad) | 10:57 |
| spiv | igc, lifeless: I don't have a firm opinion on what to do with the bug report that's controversial, but I agree with lifeless that it's good to have something that can be closed positively after a good chunk of work has been done | 10:57 |
| ScriptFanix | james_w: for one package it's an ssh authorized_keys file | 10:57 |
| spiv | igc, lifeless: both for giving ourselves and users warm fuzzy feelings, and also for making the reports of work queued and work done reasonably intelligible. | 10:58 |
| james_w | ScriptFanix: inside the package? | 10:58 |
| ScriptFanix | for another, it's a file where the user is supposed to enter a mysql root password | 10:58 |
| ScriptFanix | james_w: yup | 10:58 |
| james_w | ScriptFanix: "man dh_fixperms" | 10:58 |
| NET||abuse | i'm googling around alot trying to find good articles on methods of exporting to publish to your webserver,, and i'm not really finding the right articles at all.. .can anyone point me at some good material for this? | 10:58 |
| spiv | igc, lifeless: so doing a large chunk of work towards fixing a bug, and then closing that bug Won't Fix definitely feels wrong. | 10:58 |
| lifeless | spiv: https://bugs.edge.launchpad.net/bzr/+bug/342869 is that fixed, do you think? | 10:59 |
| ScriptFanix | james_w: thanks, that should do the trick | 10:59 |
| ubottu | Launchpad bug 342869 in bzr "Internal error on push" [Undecided,New] | 10:59 |
| NET||abuse | i remember seeing one article which had you setup a bare repo on the server and setup auto hooks to push commits to it straight out to your web server,,, | 10:59 |
| ScriptFanix | (I'm new to debian packaging) | 10:59 |
| NET||abuse | would someone show me something like this? | 10:59 |
| spiv | igc, lifeless: I'm not sure if that's an argument for leaving this bug unresolved for now, or splitting difficult bugs into smaller ones, or something else... | 11:00 |
| igc | spiv: performance bugs are hard to make the call on w.r.t. fixed vs otherwise | 11:00 |
| NET||abuse | oh,, and if i have a wt on my web server, can i just cp -r part/of/working/tree /path/to/site.com/www/ and not be moving bzr related meta files over also? | 11:00 |
| spiv | (although leaving unresolved is probably poor for much the same reason) | 11:00 |
| igc | spiv: I simply saying that 'local branch outside a shared repo' is still slow so ... | 11:00 |
| igc | closing it simply because we're done work on it doesn't make sense IMO | 11:01 |
| spiv | But if the outcome for this bug isn't "mark fixed" (and I'm not saying it should or shouldn't be) then I think we probably need to do something a bit differently. | 11:01 |
| igc | slow is slow | 11:01 |
| igc | spiv: you, lifeless and jam have made *great* stride wrt network performance | 11:02 |
| lifeless | igc: unless we make the system fragile - see the number of options git clone _requires_ because they support hardlinking etc. | 11:02 |
| spiv | Anyway, dinner needs me! | 11:02 |
| lifeless | then its not going to get radically faster | 11:02 |
| spiv | Happy bug-squashing, whatever form it takes! | 11:02 |
| lifeless | without considerable elbow grease | 11:02 |
| lifeless | I am pretty damn sure we've exceeded the requirements of the original bug report; upcasting it to 'bzr is not as fast as git' isn't useful | 11:03 |
| lifeless | I'm done for the day | 11:05 |
| Fly-Man- | Morning | 11:50 |
| Fly-Man- | Any Bazaar developers awake that could have a look at a pastebin | 11:50 |
| Fly-Man- | captured after the nice message | 11:50 |
| Fly-Man- | segmentation fault | 11:51 |
| Fly-Man- | while trying to capture a bzr branch | 11:51 |
| mzz | Fly-Man-: I'm not a bazaar developer, but if the segfault isn't in a bazaar-specific extension I can look | 11:53 |
| Fly-Man- | mzz | 11:53 |
| Fly-Man- | let me grab the pastebins for ya | 11:53 |
| * mzz wishes people would just include the pastebin link the first time around in cases like this | 11:53 | |
| Fly-Man- | used gdb for debugging | 11:54 |
| Fly-Man- | http://launchpad.pastebin.com/d364c32a9 | 11:54 |
| Fly-Man- | this is what gdb gave | 11:54 |
| Fly-Man- | http://launchpad.pastebin.com/d1e011574 | 11:54 |
| Fly-Man- | Used the ppa that's mentioned in this posting | 11:54 |
| Fly-Man- | https://dev.launchpad.net/Getting | 11:54 |
| Fly-Man- | => https://edge.launchpad.net/~bzr/+archive/ppa | 11:55 |
| mzz | bah, memory corruption | 11:55 |
| mzz | Fly-Man-: is the branch data needed to reproduce this available? | 11:55 |
| mzz | Fly-Man-: and what python is that? | 11:56 |
| Fly-Man- | python 2.6 | 11:56 |
| Fly-Man- | bzr 2.0.0-1~bazaar1~jaunty1 | 11:56 |
| mzz | Fly-Man-: ubuntu jaunty's? ubuntu karmic's? | 11:56 |
| Fly-Man- | Jaunty | 11:56 |
| Fly-Man- | I don't run Karmic yet | 11:56 |
| Fly-Man- | Was planning to | 11:56 |
| mzz | that's fine | 11:56 |
| Fly-Man- | if this won't work | 11:56 |
| * mzz has jaunty here | 11:56 | |
| mzz | Fly-Man-: can you give me instructions for reproducing this? | 11:57 |
| Fly-Man- | Yes | 11:57 |
| Fly-Man- | I installed a clean slate Jaunty | 11:57 |
| Fly-Man- | then I ran apt-get update / upgrade / dist-upgrade | 11:57 |
| Fly-Man- | to get the system setup fully | 11:57 |
| Fly-Man- | after that, I added the 2 lines from the ppa to the /etc/sources.lst | 11:57 |
| Fly-Man- | ran apt-get update again | 11:57 |
| Fly-Man- | added the keys for the pp | 11:58 |
| Fly-Man- | and started to follow the instructions on that page | 11:58 |
| mzz | (mainly interested in the bzr commands you ran) | 11:58 |
| Fly-Man- | after about 140 / 175 mb pulling | 11:58 |
| Fly-Man- | it just dies | 11:58 |
| mzz | ahh | 11:58 |
| mzz | launchpad, got it. | 11:58 |
| Fly-Man- | mzz, I ran the rocketsetup | 11:58 |
| Fly-Man- | that has the commands in it | 11:58 |
| mzz | yeah, got it now. Running... | 12:00 |
| Fly-Man- | mzz: thanks | 12:00 |
| Fly-Man- | if you get the same error, I know it's not my bzr | 12:00 |
| GaryvdM | Hi - I'm getting an error: bzr: ERROR: wanted 8638 bytes but next hunk only contains 322: 'gcb1z\n8621\n19545\nx\x9c\x9d'... | 12:00 |
| Fly-Man- | but I think i'll jump to Karmic then | 12:00 |
| GaryvdM | This is the .bzr.log: http://pastebin.com/d2f71d8e4 | 12:01 |
| GaryvdM | How can I work out what's wrong? | 12:01 |
| mzz | GaryvdM: I'd start by running "bzr check" on both ends | 12:02 |
| GaryvdM | mzz: | 12:02 |
| GaryvdM | mzz: Ok | 12:02 |
| GaryvdM | mzz: both are ok | 12:04 |
| mzz | GaryvdM: then I'm afraid for someone who actually knows bzr to show up | 12:05 |
| SamB_XP | mzz: you're afraid ? | 12:06 |
| mzz | SamB_XP: frequently | 12:06 |
| SamB_XP | why are you afraid of people who know bzr ? | 12:06 |
| mzz | err, wait | 12:06 |
| mzz | I don't know what happened there | 12:06 |
| SamB_XP | lol | 12:06 |
| mzz | GaryvdM: then I'm afraid *you'll have to wait* for someone who actually knows bzr to show up | 12:06 |
| GaryvdM | :-) | 12:07 |
| mzz | my brain got ahead of my fingers a little there, I think | 12:07 |
| GaryvdM | Hmm - odd - bzr pack on the source fixed it. | 12:23 |
| igc | night all | 12:33 |
| Fly-Man- | mzz: I think I found something that could explain the behaviour | 12:37 |
| mzz | Fly-Man-: I haven't reproduced yet (it's pulling revisions) | 12:37 |
| Fly-Man- | mzz: It will pull revisions | 12:38 |
| Fly-Man- | but around 140 Mb or 171 mb it will give the error | 12:38 |
| bialix | GaryvdM: hello | 12:50 |
| mzz | Fly-Man-: looks like it's well past that point now (still going though). Are you sure your physical ram is ok? | 13:03 |
| Fly-Man- | yup | 13:03 |
| mzz | (bzr is pretty ram-hungry while it's doing this) | 13:03 |
| Fly-Man- | it's a virtual machine | 13:04 |
| Fly-Man- | with 2 gb ram | 13:04 |
| mzz | Fly-Man-: if I wanted to debug this I'd first try to reproduce locally somehow, and then running a debug build of python under valgrind, assuming I'm correct about this being memory corruption | 13:05 |
| mzz | (running valgrind on a regular build of python is fairly pointless) | 13:05 |
| mzz | but only if you're sure about the hardware being ok (in this case that means the vm software being ok and the hardware the host is running on being ok) | 13:06 |
| Fly-Man- | yupz, the machine is brandnew | 13:07 |
| mzz | I'd trust it more if it was old | 13:08 |
| orattue | What's the difference between using the protocol bzr+ssh:// over sftp:// - I can't seem to find any clear answers in documentation... | 13:15 |
| garyvdm | Hi bialix | 13:19 |
| Tak | orattue: as I understand it, bzr+ssh invokes (and thus requires) bzr at both ends, while sftp just uses raw sftp to transfer data | 13:20 |
| orattue | Tak: are there any benefits to using bzr+ssh? | 13:20 |
| === doko__ is now known as doko | ||
| garyvdm | orattue: bzr+ssh has some performance advantages | 13:22 |
| garyvdm | orattue: e.g. Sometimes bzr will autopack it's repository. With sftp, this has to be done on the client, transferring all the data over the wire. With bzr+ssh, that is all done on the server. | 13:24 |
| orattue | GaryvdM: yeah think I have experience an autopack over sftp:// not good :( | 13:24 |
| === garyvdm is now known as GaryvdM | ||
| mzz | bzr+ssh should cut down on the number of roundtrips, so I'd expect the performance difference to be more noticable if there's a lot of network latency | 13:28 |
| bialix | GaryvdM: what you think about upgrading qbzr trunk to 2a? | 13:30 |
| GaryvdM | bialix: That would be good. | 13:32 |
| Fly-Man- | mzz: Same error occurs with the installed version from Karmic | 13:32 |
| bialix | GaryvdM: I won't object, because 2a is supported at least since bzr 1.17 | 13:33 |
| bialix | and qbzr support only recent bzr versions | 13:33 |
| GaryvdM | bialix: Though, it's not urgent for me. | 13:34 |
| bialix | GaryvdM: I'm unlikely will have chance to do upgrade soon | 13:34 |
| Fly-Man- | mzz: It seems to be in all 2.0.x branches | 13:41 |
| Fly-Man- | when I try it on another machine with 1.18 | 13:42 |
| Fly-Man- | it works instantly | 13:42 |
| mzz | Fly-Man-: works for me using the same jaunty+ppa | 13:53 |
| Fly-Man- | mzz: that's odd .... | 13:54 |
| Tak | hmm, shouldn't dpush have the same option set as push? (e.g. --no-strict) | 14:35 |
| GaryvdM | Tak: probably, but --no-strict is quite a new option. | 14:38 |
| GaryvdM | Tak: I think the right thing to do here is to log a bug... | 14:39 |
| allenap | Hi, I'm using the Ubuntu Jaunty PPA ("deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu jaunty main") and I noticed that bzrlib is no longer available for Python 2.4. Does anyone know if this is a new policy, an issue with the package, or a local problem? | 14:40 |
| GaryvdM | allenap: As far as I know, bzr still supports py 2.4. What distro are you using. | 14:42 |
| GaryvdM | allenap: The version of py in jaunty is 2.6... | 14:42 |
| allenap | GaryvdM: Ubuntu Jaunty (9.04). | 14:42 |
| GaryvdM | allenap: Have you specifically chosen to run py 2.4? | 14:43 |
| allenap | GaryvdM: Unfortunately yes :) Developing Launchpad. | 14:44 |
| Tak | hmm, is dpush part of bzr proper? or one of the plugins? | 14:45 |
| allenap | GaryvdM: When Launchpad builds, it creates an egg for bzr, so that's fine, no dependency on the system bzr. However, to prepare the build there is a script that needs bzrlib. | 14:45 |
| GaryvdM | allenap: *I think* that the .deb in the ppa are built against the default py version for the distro, so you may need to build from source. I am not an expert on this though... | 14:46 |
| allenap | GaryvdM: It's not a huge problem; that script can be run using python2.6, but I wanted to ask in case something had been removed. | 14:46 |
| allenap | GaryvdM: ... by mistake. | 14:46 |
| GaryvdM | allenap: I think it is just the .debs that require py 2.6, not the source... | 14:47 |
| allenap | GaryvdM: Okay, that's reasonable. Thanks. | 14:47 |
| jelmer | tak: It's part of bzr itself | 14:47 |
| === EdwinGrubbs2 is now known as EdwinGrubbs | ||
| Tak | k, thanks | 14:48 |
| Tak | what determines whether a command goes into the "hidden" list or not? (bzr help [hidden-]commands) | 15:07 |
| * Tak full of silly questions today | 15:07 | |
| jelmer | Tak: if it's got 'hidden = True' set in the class IIRC | 15:09 |
| Tak | well...I mean more philosophically | 15:10 |
| james_w | if it has the aura of a hidden command | 15:10 |
| james_w | basically whether it should show up in "bzr help commands" | 15:11 |
| james_w | so internal, experimental, highly specialised or similar | 15:11 |
| Tak | I see | 15:12 |
| GaryvdM | Tak: Alot of the hidden commands are things that would be used by bzr devs, but not by ordinary users (e.g. dump-btree) | 15:14 |
| GaryvdM | Tak: qsubprocess is use by qbzr to launch a command with a specialized ui_factory, would never be used directly by a user. | 15:15 |
| Tak | dpush is what prompted my question ;-) | 15:16 |
| Tak | I just found out about it the other day, and it seems like it would be highly useful to many bzr-#{othervcs} users | 15:17 |
| smoser | kirkland, i know you use 'bzr cdiff' is it busted for you right now? | 15:31 |
| smoser | $ bzr cdiff | 15:31 |
| smoser | Plugin "Bzrtools" is not up to date with installed Bazaar version 2.0.0. | 15:31 |
| smoser | There should be a newer version of Bzrtools available, e.g. 2.0. | 15:31 |
| james_w | smoser: install updates | 15:33 |
| james_w | it should be built by now | 15:33 |
| smoser | james_w, looks like it. i *can* read, but i'd done that some time before when update wasn't available. thanks. | 15:35 |
| james_w | yeah, it was just fixed this morning, not your fault as you have bzrtools 2.0 installed :-) | 15:36 |
| * GaryvdM seeks poolie... | 15:53 | |
| orattue | hmm - bzr: ERROR: Cannot commit to branch BzrBranch6('file:///Library/WebServer/Documents/example.com/apps/'). It is bound to BzrBranch6('sftp://pixeco@dev.pixeco.com/home/bazaar/pixeco/example.com/apps/trunk/'), which is bound to file:///home/bazaar/pixeco/example.com/apps/trunk/. | 17:38 |
| orattue | v.circular - anyone ever seen this before? | 17:39 |
| LarstiQ | yeah | 17:40 |
| LarstiQ | orattue: `bzr unbind` sftp://pixeco@dev.pixeco.com/home/bazaar/pixeco/example.com/apps/trunk/ | 17:40 |
| orattue | LarstiQ: right but I want to commit to that location... | 17:41 |
| rbistolfi | Hi, I get this error trying to branch from lp, any ideas? http://pastie.org/633561 | 17:42 |
| LarstiQ | orattue: yes, but it is bound to itself, you need to fix that first | 17:43 |
| LarstiQ | orattue: so unbind it from itself, and continue | 17:43 |
| luke-jr | how do you undelete in Bazaar? O.o | 17:44 |
| luks | undelete? | 17:44 |
| LarstiQ | luke-jr: vague term like that, use case? | 17:44 |
| luke-jr | in Subversion, I would copy the file from its last revision | 17:44 |
| luks | bzr revert -r X path/to/file | 17:44 |
| luke-jr | no, teh delete is commmitted | 17:45 |
| LarstiQ | luke-jr: yes, what luks said | 17:45 |
| luks | that's why there is "-r X" | 17:45 |
| dash | luke-jr: revert does more in bzr than in svn :) | 17:45 |
| luke-jr | o | 17:45 |
| luke-jr | so that will restore the old file and commit it with its original history? | 17:46 |
| dash | restore yes, commit no. | 17:46 |
| luke-jr | O.o? | 17:46 |
| dash | it just changes your WC | 17:46 |
| luke-jr | :/ | 17:46 |
| dash | but you can commit it then. :) | 17:46 |
| luks | why :/? | 17:46 |
| LarstiQ | luke-jr: unlike svn revert, you can commit the result of a revert | 17:46 |
| luks | commit is as simple as bzr commit -m 'restored path/to/file' | 17:46 |
| luks | but people usually want more than that | 17:47 |
| luke-jr | but then I'd lose the history? | 17:47 |
| luks | no | 17:47 |
| luke-jr | and probably break merges | 17:47 |
| luks | it will be the same file with the same history | 17:47 |
| luks | again, no | 17:47 |
| luke-jr | oh | 17:47 |
| luke-jr | so it restores the history, so when I commit manually, it's there | 17:47 |
| luke-jr | ? | 17:48 |
| dash | yes | 17:48 |
| luke-jr | ok | 17:48 |
| luks | it's there when you run revert | 17:48 |
| luke-jr | thanks | 17:48 |
| luks | then you commit manually | 17:48 |
| luke-jr | and does that work smoothly with bzr-svn? | 17:48 |
| dash | bzr in general won't let you do stuff that breaks merges | 17:48 |
| LarstiQ | yes (although the history was never gone, so didn't really need restoring) | 17:48 |
| luke-jr | or am I better off using svn to restore it? | 17:48 |
| dash | luke-jr: works fine with bzr-svn | 17:48 |
| luke-jr | so bzr-svn will represent it as a copy in svn? :) | 17:48 |
| nedosa | hi all, is there anything in bzr to support rearranging commits ? I thought bzr-rebase can do it, but apparently not yet | 17:53 |
| LarstiQ | luke-jr: euh, that I don't know exactly | 17:53 |
| LarstiQ | luke-jr: try it! :) | 17:53 |
| luke-jr | LarstiQ: svn has no simple undo if not :/ | 17:54 |
| LarstiQ | luke-jr: do you really need it to be a copyz? | 17:54 |
| LarstiQ | svndump if you need to be sure | 17:54 |
| luke-jr | LarstiQ: of course... :/ | 17:54 |
| LarstiQ | or try it on a an example repo | 17:54 |
| LarstiQ | luke-jr: why? | 17:54 |
| luke-jr | because I'm a perfectionist | 17:54 |
| luke-jr | and some of these might be big | 17:55 |
| LarstiQ | if bzr-svn doesn't use a copy, I'd think it uses the original entry | 17:57 |
| LarstiQ | by pivoting in the revision | 17:57 |
| LarstiQ | thereby using even less space | 17:57 |
| LarstiQ | buuut, that's svn details I'm not going to vow on :) | 17:58 |
| luke-jr | eh? | 18:00 |
| luke-jr | Subversion can only do it with a copy... | 18:00 |
| LarstiQ | luke-jr: not if you say "use this prior revision" | 18:00 |
| LarstiQ | which may or may not be possible in the case of reverting one file | 18:01 |
| * LarstiQ knows enough about svn inner workings to be dangerous | 18:01 | |
| LarstiQ | not enough to know exactly how it will play out | 18:01 |
| LarstiQ | luke-jr: the bundled svn _client_ can only do it with a copy | 18:01 |
| luke-jr | LarstiQ: how would that be represented in a svn dump? | 18:01 |
| LarstiQ | luke-jr: good question | 18:02 |
| luks | is this something you are going to do regularly? | 18:02 |
| * luke-jr notes his Subversion repository is generated from a hand-crafted svn dump of his | 18:02 | |
| luks | if not, I'd just use svn copy and be done | 18:02 |
| luke-jr | heh | 18:02 |
| luks | otherwise I'd test bzr-svn on a test local repository | 18:02 |
| luks | the file will use the same history and everything in bzr | 18:03 |
| luks | but I don't think anybody here, except jelmer, knows what will it do in svn :) | 18:03 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| luks | ouch, bzrlib version check in qbzr :( | 18:30 |
| GaryvdM | luks: I wanted to have just a minimum check, but there is no api for that :-( | 18:43 |
| GaryvdM | luks: I really think it's better overall to do a version check. It takes away alot of unknowns. | 18:45 |
| luks | GaryvdM: my problem with it is that parts of qbzr might easily work with older bzrlib, but it will refuse to run | 18:46 |
| luks | I had enough of that with bzrtools and bzr-svn | 18:46 |
| luks | (upgrade bzr => oops, no plugin works anymore => locally comment out version checks => they all work fine) | 18:47 |
| GaryvdM | luks: Ok - that could be solve by not defining a max version. | 18:48 |
| luks | I can understand it in bzr-svn, where a different format API might lead to data corruption | 18:48 |
| luks | but not in a tool plugin, like qbzr or bzrtools | 18:49 |
| luks | well, max version is only one end of it | 18:49 |
| luks | the point is that one version number is not a good way to represent "compatibility" | 18:50 |
| Tak | heh, I put a min version check on md-bzr because of the strict/no-strict behavior | 18:50 |
| jelmer | Tak: how do I build monodevelop-bzr from the command-line *and* build the GUI code? | 18:59 |
| jelmer | Tak: so far I've used mdtool but that doesn't seem to create the .cs files | 18:59 |
| Tak | hmm, good question | 19:03 |
| GaryvdM | luks: Sorry - I had some one talking to me. | 19:08 |
| GaryvdM | There is some system wide code (SubprocessUIFactory) that was not compatible with bzrlib 1.16. That affects a large scope of the qbzr functionality. | 19:08 |
| Tak | jelmer: apparently there's not a way; I guess we should add a generated.cs and then add it to ignores | 19:09 |
| luks | GaryvdM: I have no real problem with that, it's your choice | 19:09 |
| GaryvdM | I agree on the max check though. | 19:10 |
| luks | just note that the lack of a version check in earlier qbzr versions was intentional | 19:10 |
| GaryvdM | luks: yes | 19:10 |
| luks | for example, the qcommit code from qbzr r1 (3 years old, written against bzr 0.10) still works fine | 19:10 |
| luks | that's two major bzr versions | 19:10 |
| luks | it didn't do much, but it shows that some API does not change while some does | 19:11 |
| luks | and a single number can't reflect that | 19:11 |
| jelmer | Tak: just for everything in gtk-gui/ ? | 19:12 |
| Tak | jelmer: yeah | 19:14 |
| RobOakes | I've got a quick question about creating a branch from a separate user account. Is there any way to tell bzr which public key I want to use? | 19:18 |
| jfroy|work | Is there documentation on the attributes or properties of things in bzrlib? | 19:40 |
| jfroy|work | I just looked everywhere on a way of getting a revision object from a branch and a revid, only to dig out of the source that I could do branch.repository.get_revision() | 19:42 |
| jfroy|work | pydoctor is hugely not helpful by being silent on attributes / properties completely :| | 19:42 |
| mwhudson | it should document @properties, but yeah | 19:43 |
| * gerard_ loves bazaar | 19:47 | |
| gerard_ | and now the complaint: bzr svn-import <path to local repo> is SLOOOW | 19:48 |
| gerard_ | any way to get data from svn into bzr faster? | 19:48 |
| gerard_ | is bzr-fastimport much faster? | 19:49 |
| GaryvdM | jfroy|work: branch.repository.get_revision() is the correct way to do what you want. | 19:55 |
| jfroy|work | GaryvdM: precisely what I am doing :p | 19:56 |
| GaryvdM | jfroy|work: "getting a revision object from a branch and a revid" :-p | 19:56 |
| jelmer | gerard_: how slow is slow? | 20:01 |
| gerard_ | good question | 20:02 |
| Tak | so zen | 20:02 |
| gerard_ | about 1s per revision | 20:02 |
| jelmer | gerard_: could be right, depending on the size of the trees | 20:02 |
| jelmer | gerard_: what versions of bzr/bzr-svn? | 20:02 |
| gerard_ | meh | 20:02 |
| gerard_ | Bazaar (bzr) 1.5, bzr-svn 0.4.10 | 20:03 |
| gerard_ | about 8000 revisions in total | 20:03 |
| jelmer | gerard_: oh, upgrading will definitely get things a lot faster | 20:03 |
| gerard_ | jelmer: probably, but it's the latest version in debian testing | 20:04 |
| jelmer | gerard_: in debian stable I think | 20:05 |
| jelmer | gerard_: testing has 1.17 | 20:05 |
| gerard_ | hmm, I was in the opinions that I was running testing | 20:05 |
| gerard_ | let me check | 20:05 |
| gerard_ | not the first time they switched around stuff and I got stuck with stable | 20:06 |
| gerard_ | jelmer: right, I feel stupid now | 20:16 |
| gerard_ | let me check how much faster it is | 20:16 |
| === Noldorin__ is now known as Noldorin | ||
| gerard_ | jelmer: ahh, thanks alot | 20:28 |
| gerard_ | works much much better now | 20:28 |
| Tak | ugh, speaking of version limiting, I made a stupid mistake that breaks the md-bzr version check for 2.0 | 20:28 |
| gerard_ | now I need to plan when I'm going to update my system to testing again.... | 20:28 |
| gerard_ | it still doesn't understand ^C very well but that's ok | 20:30 |
| jfroy|work | Is there a way to get an output similar to 'bzr log -c FOO' but using the bzrlib API for a specific Revision object? | 21:18 |
| jfroy|work | mmm, bzrlib.log | 21:24 |
| Mez | how do I find the revid of the current branch tip | 21:27 |
| Mez | nvm, found it. | 21:29 |
| jfroy|work | mmm, that's not a simple API | 21:30 |
| jrwren | https://bugs.launchpad.net/bzr/+bug/186014 says fix release, how can I find out what the fix was ? | 22:06 |
| ubottu | Launchpad bug 186014 in bzr "MemoryError on diff/commit due to corrupted dirstate" [High,Fix released] | 22:06 |
| GaryvdM | jrwren: The milestone says 1.17 | 22:08 |
| jrwren | hrm, well I'm on 1.18.1, wondering how I can fix up a corrupted dirstate | 22:11 |
| scrash09 | Hi! I just started using bzr, and need a little help. | 22:11 |
| scrash09 | If I checkout a source tree (e.g., /webapp) that contains a user-files directory (e.g., /webapp/files) that I replace with my local stuff. Every once in a while I want to merge upstream changes into my local setup. | 22:11 |
| scrash09 | When I try a merge, though, I get 'bzr: ERROR: Working tree "/webapp" has uncommitted changes (See bzr status).'; 'bzr status' then lists any files i've modified/added in /webapp/files. | 22:11 |
| scrash09 | Do I _have_ to manage /webapp/files under bzr control in order to keep the upstream changes in sync? Or is there a way to exclude the /webapp/files folder from the sync/merge process? | 22:11 |
| jrwren | you can ignore those files, but then you get no help for merging. | 22:12 |
| scrash09 | jrwren: Sorry, I don't understand what you mean by "no help" ... | 22:14 |
| jrwren | scrash09: teh whole point is to use VCS to help you merge. If you commit those files, and then "every once in a while" merge upstream changes... bzr will help you merge those changes, or rather, help you manage teh versions of them. You still need a nice diff tool to merge conflicts. | 22:15 |
| jrwren | scrash09: but if it is source, quite often it can just merge and work. | 22:15 |
| scrash09 | jrwren: Hm. I'm not grokking this. :-( E.g., the 'upstream' in my case is a Drupal-clone, Pressflow (not that it matters, I suppose). It includes a 'sites' folder .... that I'll put my stuff into. So, Pressflow changes and I want to merge those changes "around" my sites folder. I _try_ to do that, using bzr merge, but get an ERROR -- and it refuses. | 22:18 |
| scrash09 | Oh, and I will _never_ merge _my_ local stuff back into upstream ... | 22:19 |
| dub | hi, is there a dns name for a launchpad.net bzr server? | 22:20 |
| Peng_ | dub: What do you mean? | 22:21 |
| dub | I've been given a probelm with 'bzr.launchpad.net' to look at, which appears to be wrong | 22:22 |
| Peng_ | dub: It's bazaar.launchpad.net. | 22:23 |
| dub | thanks, are there any known issues with bazaar and transparent HTTP caching that you are aware of? | 22:24 |
| Peng_ | dub: Broken HTTP caches sometimes get freaked out by what bzr does, but not that often, and I think it might've been worked around anyway. | 22:25 |
| Peng_ | dub: You can access bazaar.launchpad.net over SSH if you need to. It's faster, too. | 22:25 |
| scrash09 | Can 'bzr ignore' be used to ignore an entire subdirectory below my tree root? Or just file-name pattern matching? | 22:25 |
| dub | thanks for your help | 22:26 |
| Peng_ | That one didn't wait long. | 22:26 |
| dash | maybe he tried it | 22:27 |
| Peng_ | Hopefully, but we'll never know. | 22:28 |
| jrwren | any good docs for working with multiple heads? we ahve 3 heads, adn I don't know why. | 22:34 |
| dash | jrwren: hmm. where are you seeing this? :) | 22:39 |
| jrwren | bzr heads --all | 22:41 |
| jrwren | shows 3 heads, only 1 tip. somehow, some of us are using different heads, not sure how/why | 22:41 |
| jrwren | i guess this is called nested trees? | 22:43 |
| zsquareplusc | running heads within a branch in a shared repo also lists the heads of the other branches in the repo, at least is seems to do that here | 22:43 |
| jrwren | oh no, nested trees is something else entirely. | 22:44 |
| jrwren | zsquareplusc: yes, and would hopefully show on TIP per branch | 22:44 |
| zsquareplusc | yes | 22:44 |
| jrwren | mine shows one TIP per branch, but also 2 other HEAD things that aren't TIP | 22:45 |
| zsquareplusc | maybe with stacked trees you see a head for each "layer"? | 22:45 |
| jrwren | hrm... maybe I inadvertently stacked my trees. | 22:45 |
| jrwren | stacked branches teh same as stacked trees? | 22:47 |
| Fly-Man- | mzz: *ping* | 22:47 |
| Fly-Man- | mzz: For some stupid reason, it works now ;) | 22:47 |
| Fly-Man- | I baked 1.18 from source | 22:47 |
| Fly-Man- | then all of a sudden it worked | 22:48 |
| lifeless | moin | 22:49 |
| lifeless | dub: intercepting caches - no. Unless they ignore cache control headers | 22:50 |
| dub | does it user tcp/80? | 22:53 |
| dub | I get a 302 to https://launchpad.net | 22:53 |
| dub | use* | 22:53 |
| lifeless | port 80 for http, 443 for https, as normal | 22:54 |
| dub | is there another URI that the application uses? | 22:55 |
| dub | ie, not bazaar.lp | 22:55 |
| zsquareplusc | jrwren: is it a shared repo where you deleted branches? | 22:59 |
| lifeless | dub: many, depends on what the user types in ;) | 23:00 |
| lifeless | dub: why? | 23:00 |
| dub | I have a user complaining about inability to 'edit stuff on bzr.launchpad.net' | 23:01 |
| dub | using bazaar as the client | 23:01 |
| lifeless | are they able to connect to port 22 ? | 23:02 |
| Peng_ | dub: The user needs to pastebin the error he's getting. | 23:02 |
| lifeless | to push or commit on launchpad, we use bzr+ssh, which tunnels over ssh - on port 22 | 23:02 |
| dub | I can ask, at this stage I was just trying to establish the actual URI and do the usual checks on if its cache friendly | 23:02 |
| lifeless | and as Peng_ says, seeing the error would help immensely, as there are multiple possible causes. | 23:02 |
| lifeless | dub: I wouldn't say its friendly, we cache bust a lot (because of the nature of the beast). However, 'works when folk are doing interception' - yes. | 23:03 |
| jrwren | zsquareplusc: it is a shared repo, but we did not delete branches | 23:06 |
| Peng_ | dub: The http access is read-only. If the user wants to "edit stuff", he/she/other has to use ssh anyway, and who in the world has a transparent SSH cache? | 23:07 |
| dash | One way to get multiple heads is to use incommit | 23:08 |
| dash | er uncommit | 23:08 |
| Peng_ | I've heard that radiation can do it too. | 23:09 |
| dub | Peng_, we're caching tcp/80. The user is rather vague on details but is sending through the error message | 23:15 |
| rbistolfi | Hi, any idea about why do I get this? http://pastie.org/633561 | 23:20 |
| Peng_ | rbistolfi: ...Do you have a transparent proxy? What happens if you try again? | 23:22 |
| Peng_ | dub: Is rbistolfi the person you were talking about? | 23:24 |
| dub | no idea sorry | 23:24 |
| dub | the IP suggests not | 23:25 |
| === oubiwann_ is now known as oubiwann | ||
| lifeless | oubiwann: you're flapping | 23:27 |
| oubiwann | yeah... I need to extend my wireless network | 23:28 |
| lifeless | rbistolfi: is it a private branch? | 23:28 |
| lifeless | oh sorry, terrible pastebin site. | 23:29 |
| lifeless | uhm as Peng says, looks like something mangling the http response | 23:29 |
| lifeless | rbistolfi: ^ | 23:29 |
| dub | not seeing much in the way of cache control headers | 23:33 |
| dub | should be using expires | 23:33 |
| lifeless | dub: not really, if you're seeing web pages, they don't matter. if you're see VCS metadata, we no-cache them all in the client | 23:49 |
| dub | my users error is much the same as rbistolfi | 23:51 |
| dub | looking at headers returned from an HTTP request for the URI I see no attempt at cache control. | 23:53 |
| lifeless | dub: thats right. | 23:54 |
| lifeless | dub: Completely consistent with what I was saying ;) | 23:55 |
| lifeless | dub: if you're running squid, you have an old version. | 23:55 |
| dub | im not | 23:55 |
| lifeless | known bug, fixed a while back. | 23:55 |
| lifeless | ok | 23:56 |
| lifeless | in which case could you please open a bug? We'll need to figure out if the product you've got is doing the wrong thing so we can add it to our knowledgebase [or fix bzr if its a bzr http bug] | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!