| onox | can I make a branch of a checkout or a checkout of a checkout? | 00:08 |
|---|---|---|
| fullermd | You can branch a checkout (of course, what you're really doing is branching the branch the checkout is of). | 00:08 |
| lifeless | johnf: is there an ETA on 2.0.0 in the PPA ? | 00:08 |
| lifeless | [not the beta PPA, the PPA] | 00:08 |
| fullermd | Checking out a checkout doesn't make much sense though. | 00:08 |
| johnf | lifeless: about 20 minutes | 00:08 |
| johnf | just finishing off bzrtools | 00:08 |
| lifeless | mtaylor: ^ | 00:09 |
| * mtaylor is excited | 00:10 | |
| onox | fullermd: ok, I was just wondering :) | 00:10 |
| thumper | any eta on windows installers? | 00:14 |
| poolie | hello all | 00:14 |
| bombcar_ | How can I push a tag to a remote bzr+ssh repository without doing a pointless commit? | 00:14 |
| spiv | bombcar_: just "bzr push" | 00:15 |
| spiv | bombcar_: the message about "nothing to push" is misleading :( | 00:15 |
| bombcar_ | oh, really? | 00:15 |
| bombcar_ | so it does push it? | 00:15 |
| bombcar_ | It does! Thanks | 00:16 |
| meoblast | with the fast-import-filter, can you filter text in all source files? | 00:16 |
| bombcar_ | I wonder if there's a bug on that ... | 00:16 |
| zsquareplusc | will i be able to install svn-bzr and bzr itself together again from the PPA when 2.0 is out? because upgrading to bzr 1.18 removes bzr-svn (both from the PPA, jaunty 64 bit) | 00:16 |
| bombcar_ | does a commit push it, too? | 00:18 |
| bombcar_ | hmm | 00:19 |
| bombcar_ | it doesn't seem to need a commit | 00:20 |
| lamalex | Does anyone know anything about bzr-fastexport? I'm trying to export into git but it's failing | 00:21 |
| meoblast | bzr fast-export mybranch/ thestuff.fi | 00:22 |
| mwhudson | wow doing a standalone branch of launchpad is slow.... | 00:23 |
| johnf | lifeless: actually maybe an hour since PPA builders seem a bit busy | 00:23 |
| meoblast | does bzr have tree-filtering ability? | 00:24 |
| lamalex | anyone know about fast-export/ | 00:29 |
| lifeless | igc | 00:29 |
| lamalex | lifeless: are you telling me to ask igc, or talking to someone else | 00:29 |
| lifeless | lamalex: I'm telling you that igc knows about fast export | 00:29 |
| lamalex | thanks | 00:30 |
| poolie | hello lifeless, spiv | 00:30 |
| lifeless | johnf: bzr-svn too? | 00:30 |
| lifeless | hi poolie | 00:30 |
| johnf | lifeless: I've got latest versions of bzr, bzrtools, subvertpy and bzr-svn ready to go | 00:30 |
| lifeless | awesome | 00:30 |
| lifeless | johnf: its an ubuntu archive rebuild | 00:32 |
| lamalex | igc: http://paste2.org/p/436081 <-- log | 00:32 |
| lifeless | johnf: your build should score in front of it | 00:32 |
| poolie | lifeless/igc/spiv: so, 2.0.0 or not? | 00:35 |
| poolie | i said i'd do it today | 00:36 |
| poolie | s/do/announce it | 00:36 |
| poolie | we have no site update yet afaics | 00:36 |
| poolie | and maybe no windows installers? | 00:36 |
| igc | hi poolie, lifeless, lamalex | 00:36 |
| igc | hi spiv | 00:36 |
| poolie | jelmer: still around at all? | 00:36 |
| johnf | Eww really don't like the ordering of https://launchpad.net/builders Can't easily see what the PPA builders are up to | 00:36 |
| poolie | johnf: say it (also) in #launchpad where bigjools or someone can hear you | 00:37 |
| poolie | also try clicking the 'status' heading | 00:37 |
| lamalex | igc: lifeless said you know about fast-export | 00:38 |
| igc | lamalex: I do - I'll take a look in a few moments | 00:38 |
| lamalex | igc: thanks :) | 00:38 |
| lamalex | ill be around just ping me | 00:38 |
| igc | poolie: I'm not sure why there's no windows installer built | 00:38 |
| igc | lamalex - shall do | 00:39 |
| poolie | jam, still here? | 00:39 |
| igc | poolie: I though jam had all he needed but maybe he was waiting on an rc2 for bzr-svn or something like that | 00:39 |
| igc | poolie: I certainly don't want to announce 2.0.0 until a few people have tested the 'final' windows installer | 00:40 |
| poolie | mm, me either | 00:40 |
| poolie | i was wondering in the shower whether i'd wait for the web site | 00:41 |
| poolie | but i don't want to announce without windows installers | 00:41 |
| lifeless | softpedia is odd | 00:54 |
| igc | poolie: so I suspect the holdup on the windows installer was that the official branch didn't have you patch for going 2.0.0 gold | 01:08 |
| igc | poolie: it looks like jam has fixed that overnight | 01:09 |
| poolie | maybe so, but i thought john said yesterday he would just change it in the tree | 01:09 |
| poolie | i'll look in to why it didn't get in, as i'm pretty sure it was submitted | 01:09 |
| meoblast | lifeless: i'm writting a program to automate this :P | 01:14 |
| poolie | i just tried to call jam but couldn't reach him | 01:16 |
| lamalex | igc: anything? | 01:17 |
| igc | lamalex: just getting to it now | 01:18 |
| lamalex | k :) let me know if you need anything | 01:18 |
| igc | lamalex: so that's a git crash report, yes? | 01:20 |
| lamalex | igc: yah | 01:20 |
| lamalex | http://paste2.org/p/436137 | 01:21 |
| lamalex | that's the terminal output aside from the log | 01:21 |
| igc | lamalex: there's a known bug with a patch | 01:21 |
| igc | https://bugs.launchpad.net/bzr-fastimport/+bug/427188 | 01:22 |
| ubottu | Launchpad bug 427188 in bzr-fastimport "bzr fast-export --plain into git fast-import fails" [Undecided,New] | 01:22 |
| igc | lamalex: I'm yet to check the patch so it's not merged into the trunk yet | 01:22 |
| igc | lamalex: but it will be in the next few days | 01:23 |
| lamalex | thanks | 01:23 |
| igc | lamalex: can you let me know if that fixes things for you? | 01:24 |
| lamalex | yah, it's at least gotten farther thatn it did before | 01:24 |
| lamalex | igc: works! | 01:28 |
| igc | lamalex: cool | 01:28 |
| lamalex | erm, maybe.. | 01:28 |
| lamalex | it doesn't crash at least | 01:28 |
| lamalex | igc: how is this supposed to work. Can you maybe give me a summary from start to finish? Do I run this in a bzr branch that I want to convert to git? It shows all of my files as deleted since the dir I ran it in was empty, but I guess I thought it copied content | 01:30 |
| _habnabit | Is there a way to make bzr-svn remember the HTTP auth username/password used when connecting to a svn repository over HTTP? | 01:31 |
| igc | lamalex: I didn't think it mattered which directory you ran it in but to be safe, run it in the root directory of the bzr branch you want to import into git | 01:33 |
| lamalex | igc: Do you think I should "git init . ; git add" first? | 01:33 |
| igc | lamalex: I'd generate the dump file first | 01:34 |
| igc | lamalex: I don't know exactly how git-fast-import works so see it's man page for usage | 01:34 |
| lamalex | igc: k, thanks a lot for your help on that crash | 01:35 |
| === AfC1 is now known as AfC | ||
| Raim | _habnabit: run something like 'svn ls $URL' once, bzr will use the credentials stored by svn AFAIK | 01:40 |
| _habnabit | Raim, do I have to login via svn before I do the 'bzr co'? I tried doing the 'bzr co' and then 'svn co' but bzr didn't use svn's credentials. | 01:40 |
| lifeless | _habnabit: there is a ~/.svnsomething dir with auth cache under that | 01:40 |
| lifeless | poolie: a while back you considered making subunit test output the default, or perhaps for -v, or something. Have you had further thoughts? | 01:45 |
| poolie | yes, and the answer is no | 01:46 |
| poolie | it's too unreadable | 01:46 |
| lifeless | yup, I was surprised at your suggestion :) | 01:47 |
| poolie | my suggestion? | 01:47 |
| lifeless | you suggested it | 01:47 |
| poolie | actually i asked the question "would it be reasonable to just always use it?" | 01:48 |
| poolie | and the answer is no. | 01:48 |
| lifeless | To me thats suggesting the possibility ;) | 01:48 |
| poolie | so you said "I'm happy typing --subunit always" | 01:48 |
| poolie | and i'm happy you're happy :) | 01:49 |
| lifeless | anyhow, I only brought it up now because I remembered that the thread hadn't been closed | 01:49 |
| poolie | the thing i want to fix here is to actually make progress bars still display with subunit redirected | 01:49 |
| poolie | should be easy | 01:49 |
| poolie | oh btw, zsh love: | 01:49 |
| poolie | bzr selftest --subunit >subunit.out |subunit-filter --failures | 01:49 |
| poolie | does what it should | 01:49 |
| lifeless | mini-tee ? | 01:50 |
| poolie | yes | 01:50 |
| lifeless | btw subunit2pyunit --progress will show a bzr progress bar | 01:50 |
| lifeless | poolie: you were going to show me how to get zsh to do a Y pipe | 01:55 |
| lifeless | a -> process B and a-> process C | 01:56 |
| poolie | mm | 01:59 |
| poolie | i can't recall | 01:59 |
| poolie | it should be possible | 01:59 |
| lifeless | 1>3 & manual handling I guess | 02:00 |
| lifeless | 1>3 | B 3>1 | C | 02:00 |
| poolie | btw tell your team mates when you'll be away | 02:01 |
| lifeless | sure thing | 02:01 |
| lifeless | poolie: bzrlib/tests/blackbox/test_breakin.py, wait_for_process - can you comment on why it sleeps at the start of the loop, rather than the end? | 02:07 |
| johnf1 | ppa packages are building now | 02:08 |
| lifeless | johnf1: awesome | 02:08 |
| zsquareplusc | i'm versioning my editor settings with bzr. now i thought about making some of the plugins public. but that would somehow require that i needed to "overlay" two (private/public) repositories in one place. that's probably not supported but how can i do it differently? | 02:12 |
| lifeless | zsquareplusc: I think we'd need some more information, I don't know what 'it' entails. | 02:13 |
| bob2 | ghetto solution is symlinks | 02:13 |
| igc | poolie: any word from emmajane? | 02:15 |
| poolie | igc, no :-( | 02:19 |
| zsquareplusc | lifeless: like having two files that are maintained in two different branches that have to be in the same directory. but there can only be one .bzr | 02:19 |
| lifeless | zsquareplusc: and how does this tie into bzr plugins? | 02:19 |
| zsquareplusc | bzr plugins? no no, editor plugins and settings | 02:20 |
| lifeless | can you symlink to the editor plugins | 02:20 |
| lifeless | e.g. ~/bzr1/foo ~/bzr2/bar ~/.editor/foo->~/bzr1/foo ~/.editor/bar->~/bzr2/bar | 02:21 |
| zsquareplusc | if i would use two different VCS i could manage half of the files with e.g. svn and the other half with bzr. but 2x bzr probably wont work | 02:21 |
| zsquareplusc | yes, symlinks would work, but it will be many symlinks :/ | 02:21 |
| lifeless | well you only need a symlink for the public stuff [or the private stuff] | 02:22 |
| lifeless | poolie: its all pure technical, just needto change the template | 02:26 |
| poolie | what is? | 02:26 |
| lifeless | the slides | 02:26 |
| zsquareplusc | sure, but thats still a number of symlinks that have to be maintained manually for each file in the second branch | 02:26 |
| poolie | ok +1 | 02:26 |
| lifeless | the phone call wasn't MITM'd was it ? :) | 02:26 |
| poolie | yes by jam | 02:26 |
| lifeless | say hi! | 02:26 |
| lifeless | and perhaps ring me from the car? | 02:27 |
| zsquareplusc | hm, maybe i can get around the symlinks, it seems the editor can be configured to load plugins from several places | 02:30 |
| lifeless | \o/ | 02:30 |
| meoblast | lifeless: my program is lieing to m | 02:38 |
| meoblast | me* | 02:38 |
| meoblast | the one i wrote for my bazaar repository | 02:38 |
| meoblast | :P | 02:39 |
| thumper | lifeless: I'm grabbing some mysql branches for testing | 02:47 |
| thumper | lifeless: I hit the branching into empty shared repo problem again | 02:47 |
| thumper | lifeless: so I branched into a standalone | 02:47 |
| thumper | lifeless: then pulled into a shared repo | 02:47 |
| thumper | lifeless: now I'm branching a second branch into the repo | 02:47 |
| thumper | lifeless: and it is streaming very slowly compared to the first one | 02:48 |
| thumper | lifeless: is this expected? | 02:48 |
| thumper | seems to be maxing out at about 20KB/s | 02:48 |
| lifeless | do you have hpss logging on? | 02:48 |
| thumper | not sure, possibly not | 02:48 |
| lifeless | I suspect the branches have little shared history, or something, and its doing a massive history walk. | 02:48 |
| lifeless | *or* | 02:48 |
| lifeless | its doing conversion on the fly because you're using a different repo format | 02:48 |
| thumper | same repo format | 02:49 |
| thumper | 1.9 | 02:49 |
| lifeless | \o/ 2.0.0 | 02:52 |
| johnf1 | ok Packages are ready | 02:55 |
| lifeless | spiv: is asyncore in 2.4? | 02:55 |
| johnf1 | Can someone to an upgrade from the bzr-beta-ppa? If that works ok I'll copy to ~bzr | 02:55 |
| spiv | lifeless: it's ancient | 03:02 |
| spiv | lifeless: it's probably in 1.5.2 | 03:02 |
| igc | poolie: I've pushed some updates to the website. Please check them | 03:02 |
| igc | poolie: I'm out to lunch for a while - bbl | 03:02 |
| * igc lunch | 03:02 | |
| mwhudson | spiv: it was new in 1.5.2 it seems | 03:03 |
| mwhudson | heh, 1.5.2 was just over a decade ago | 03:04 |
| spiv | mwhudson: heh :) | 03:08 |
| spiv | mwhudson: I just said that version because it was more-or-less the first I used | 03:08 |
| mwhudson | yeah, me too | 03:08 |
| mwhudson | i think i just about remember 1.5.1 being released | 03:09 |
| mwhudson | actually i probably hit comp.lang.python for the first time just after 1.5 was released | 03:10 |
| johnf1 | hmm the bzrtools 2.0.0 in karmic is broken | 03:14 |
| === johnf1 is now known as johnf | ||
| johnf | jelmer: you about? | 03:16 |
| lifeless | johnf: please file a bug on bzrtools then; flag it critical or point me at it and I will | 03:17 |
| johnf | lifeless: https://bugs.launchpad.net/bzrtools/+bug/436331 | 03:23 |
| ubottu | Launchpad bug 436331 in bzrtools "bzrtools 2.0.0 in karmic thinks it is 1.18.0" [Undecided,Confirmed] | 03:23 |
| johnf | I can't change the importance | 03:23 |
| johnf | So I'm wondering what to do with Build-Depends for bzr-svn. Currently it is Depends: bzr (>= 1.16~), bzr (<< 2.1~) | 03:24 |
| johnf | but that makes a bold assumption on what the next version is | 03:24 |
| johnf | I'm tempted to change it to just Depends: bzr (>= 1.16~) | 03:24 |
| johnf | since we release pretty much in lockstep anyway so I don't know that the << has much value | 03:25 |
| mzz | am I correctly assuming the contents of "bzr help formats" in 2.0 isn't quite right? | 03:26 |
| mzz | specifically it is recommending 1.14 for projects with big trees or deep history (instead of the default format) | 03:26 |
| AfC | mzz: I'd have to say so. Use 2a. | 03:26 |
| mzz | would this be worth filing a bug on? | 03:27 |
| AfC | mzz: yes | 03:27 |
| lifeless | johnf: can you prepare a fix for bzrtool? | 03:27 |
| johnf | lifeless: bzrtool itself is fine. I don't think that package was built against the release tar ball | 03:28 |
| johnf | ie my packages in the PPA are fine | 03:28 |
| lifeless | johnf: so the orig.tar.gz in karmic is whack? | 03:29 |
| johnf | just confirming now | 03:29 |
| meoblast | configure, the endless file | 03:29 |
| lifeless | johnf: if so, you'll need to make a debdiff that includes the actual changes to 2.0 upstream against that bad orig | 03:30 |
| lifeless | you/we/us/coders | 03:30 |
| johnf | Ahh no I know what it is | 03:30 |
| johnf | For some reason the debian repo has the version set to 1.18.0 and it is overriding the tar.gz. ie the diff.gz in that package is setting it to 1.18.0 | 03:31 |
| johnf | If I fix up debian package on alioth and then we request a reimport to ubuntu that will do the trick right? | 03:32 |
| lifeless | if you upload to debian unstable, yes | 03:32 |
| lifeless | syncs go from unstable | 03:32 |
| johnf | ok let me try and do that. Should be a good test of if I'm really a DD :) | 03:33 |
| lifeless | also that bug should be on the package | 03:33 |
| lifeless | fixing | 03:33 |
| johnf | good point | 03:33 |
| mzz | (filed it, I'd write the patch but I don't know what the wording for existing projects should be, if not the current) | 03:34 |
| lifeless | johnf: can you upload 2.0.0 to experimental and/or unstable? | 03:34 |
| lifeless | johnf: experimental has 2.0rc1, which is brain damaged | 03:34 |
| mzz | and just confirming: running "bzr check" and possibly "reconcile" in the root of a shared repo is sufficient, right? No need to run it in all the branches too? | 03:35 |
| lifeless | mzz: for upgrading, yes | 03:35 |
| mzz | yay | 03:36 |
| lifeless | johnf: and yes for http://packages.qa.debian.org/b/bzrtools.html fixing it then asking for a sync | 03:36 |
| meoblast | ok, this makes no sense | 03:36 |
| meoblast | bzr: ERROR: line 36528: Invalid command 'sr/share/fonts/truetype' | 03:36 |
| meoblast | let me show you line 36528 | 03:37 |
| meoblast | @(echo "$(distdir) archives ready for distribution: "; \ | 03:37 |
| lifeless | meoblast: is there a $u somewhere there ? | 03:39 |
| meoblast | not that i see | 03:39 |
| SmileyChris | LarstiQ: I'm using the Bazaar (PPA https://launchpad.net/~bzr/+archive/ppa) and bzr-svn is too old in there. Noticed you were the uploader of the last version. Any chance of getting bzr-svn 1.0.0 pushed there? | 03:39 |
| meoblast | lifeless: my checks are saying that everything is perfect | 03:47 |
| jam | igc: ping | 03:47 |
| johnf | SmileyChris: Will be happening very soon. Just waiting for it to rebuild in beta-ppa | 03:49 |
| meoblast | the minute these errors make sense is the minute i can actually fix this | 03:49 |
| SmileyChris | johnf: cheers, it's been pestering me for a while so I thought I may as well ask :) | 03:51 |
| lifeless | SmileyChris: please file bugs on such things; tells us stuff we may not have noticed :) | 03:55 |
| SmileyChris | you're right - I should have done as much | 03:55 |
| lifeless | no worries | 03:56 |
| mzz | mmm, bzr check is apparently not very fast | 03:58 |
| * mzz is running it on a shared repo with a bunch of branches of bzr itself in it | 03:58 | |
| jam | igc: the windows builds aren't working because of whatever you did to add the new icons | 04:04 |
| jam | I'm getting: | 04:04 |
| jam | Error on line 22 in C:\home\shared\bzr\bzr-windows-installers\build-win32\release\bzr.2.0. | 04:04 |
| jam | 0\tools\win32\bzr.iss: The system cannot find the file specified. | 04:04 |
| jam | and line 22 is | 04:04 |
| jam | WizardSmallImageFile="bzr-48.bmp" | 04:05 |
| jam | I don't really have the time to fix this up tonight, unfortunately. | 04:05 |
| jam | I tried just adding a 'copytree' to the Makefile, but that didn't seem to be enough | 04:05 |
| jam | then again, I don't know why it is using 'bzr.2.0.0\tools/win32\bzr.iss' rather than using the one from bzr-windows-installer, etc. | 04:06 |
| jam | something certainly doesn't seem right | 04:06 |
| jam | (given that it sort of has to be using the source file from bzr-windows installer, or it wouldn't have those lines from a pure bzr-2.0.0 tree...) | 04:07 |
| jam | igc: Anyway, if you get back online and have a chance to look at it, it would be nice to get the windows installers built | 04:07 |
| jam | worst case, I guess I can revert your changes | 04:07 |
| lifeless | hi jam | 04:08 |
| jam | hi lifeless | 04:08 |
| jam | I'm pretty close to bedtime | 04:08 |
| jam | but I responded to some of your emails | 04:08 |
| lifeless | cool | 04:08 |
| meoblast | Bazaar is really starting to tick me off | 04:13 |
| lifeless | what is it [not] doing? | 04:14 |
| meoblast | i need to change a particular text string in every single file in every revision | 04:14 |
| meoblast | i'm completely removing a font we used and replacing it with another | 04:14 |
| meoblast | and i need revisions 1 - 70 to still work | 04:14 |
| lifeless | did you grab gits fast import filter tools? | 04:15 |
| meoblast | i was told i'd have to convert my repo into a git repo | 04:15 |
| lifeless | huh? no | 04:16 |
| lifeless | who told you that | 04:16 |
| meoblast | the people in #git | 04:16 |
| lifeless | and you listened to them :( | 04:16 |
| meoblast | they told me to write a program that automates this | 04:16 |
| meoblast | i spent the past few hours trying to perfect a small C (++) program | 04:17 |
| * mzz boggles | 04:17 | |
| mzz | revising history is certainly a bit awkward, but I don't see why it should involve c++ | 04:17 |
| meoblast | well, the fast-import dumps are very awkward | 04:17 |
| meoblast | they contain the string "data XXXX" followed by the data | 04:17 |
| meoblast | the XXXX has to be an integer matching the amount of bytes proceed | 04:18 |
| mzz | ah, I didn't know that detail. | 04:18 |
| meoblast | so if i switch Vera.ttf with LiberationSans-Regular.ttf, i need to add 18 to each of those numbers | 04:18 |
| mzz | while awkward c++ wouldn't be what I'd use to muck with this | 04:18 |
| lifeless | meoblast: but what is it you're changing? | 04:18 |
| lifeless | the commit messages? | 04:18 |
| mzz | the font name, presumably | 04:18 |
| mzz | oh, or the actual font | 04:19 |
| meoblast | well, the commit messages would be easy | 04:19 |
| meoblast | i'm trying to change the actual code so that things will still function with Liberation sans | 04:19 |
| meoblast | if all the code still says "Vera.ttf" yet there's only a LiberationSans-Regular.ttf, revisions 1 - 70 will be completely broken | 04:19 |
| lifeless | so, personally I'd accept that you did it differently and just commit a change; I really don't understand deep history rewriting like this. | 04:19 |
| lifeless | that said | 04:19 |
| lifeless | lets try and help you | 04:19 |
| lifeless | bzr'-fast-import has a command fast-import-filter is likely a good place to start to be editing the content like you need to | 04:21 |
| meoblast | lifeless: want to see the program i wrote? | 04:21 |
| lifeless | sure | 04:21 |
| meoblast | it's ugly and inefficient but as i went down the file, it seemed to be doing _most_ things right | 04:22 |
| meoblast | http://codepad.org/BOTe3oKK | 04:22 |
| meoblast | what made me finally say "wtf" is when i saw a bunch of "NULL" bytes all over the place in the output | 04:22 |
| meoblast | one major problem is that it's not good at crossing the digit border | 04:23 |
| meoblast | from 98 to 116 let's say | 04:23 |
| mzz | well, if there's no pre-existing way of doing this I'd attempt to hack up bzr's fastimport plugin | 04:23 |
| mzz | since it already has to know how to read fastimport files, so you should be able to get at the raw text you want to manipulate as python strings | 04:24 |
| meoblast | i don't know python | 04:24 |
| mzz | ah | 04:24 |
| meoblast | only a little | 04:24 |
| mzz | that explains why you went for c then | 04:24 |
| meoblast | doubt i know it enough to do anything useful | 04:24 |
| meoblast | that program is "C++" but i'm sure it could be compiled with a C compiler and run fine | 04:25 |
| lifeless | I'm fairly sure \0 is valid in a .fi | 04:25 |
| lifeless | its a binary file | 04:25 |
| meoblast | yes, but i'm unsure why a ton of those started showing up | 04:25 |
| lifeless | because you have binary content in your repo? | 04:25 |
| lifeless | such as, oh, fonts? :) | 04:25 |
| mzz | ah, neat, the fastimport plugin already has a filters concept | 04:25 |
| meoblast | yeah, i still have to actually remove the Vera font from the stream | 04:26 |
| meoblast | and pop in the Liberation | 04:26 |
| meoblast | Liberation's license looks a lot prettier | 04:26 |
| meoblast | i'm trying to use very unrestrictive licenses | 04:26 |
| lifeless | not sure why this means you have to rewrite history | 04:27 |
| meoblast | because i have OCD? | 04:27 |
| ScottK | The whole point of history is that it reflects the actual history. | 04:27 |
| meoblast | trust me, the actual history of this project isn't too pretty :P | 04:27 |
| lifeless | ScottK: how did you go with that performance thing? | 04:27 |
| mzz | well, I wouldn't bother rewriting history for this, I think, but if I did anyway I'd probably write a custom "processor" for bzr's fastimport plugin | 04:28 |
| mzz | it looks like the ones currently in there can't quite do this | 04:28 |
| meoblast | due to me not having a thorough grasp of version control early on, i quickly brought sizes up | 04:28 |
| ScottK | lifeless: Got sidetracked. The 'milli' that was here yesterday asking about formats was the git freak on the project in question. | 04:28 |
| lifeless | heh :) | 04:28 |
| meoblast | i thought i might as well clean things up before more than 2 people have a checkout | 04:29 |
| ScottK | We have a little time to play as the project can't really get started until some contractual details are resolved. | 04:29 |
| meoblast | if the line numbers on these errors weren't misleading, that would be great :P | 04:30 |
| mzz | meoblast: so what were you trying to do again? simple search/replace on raw file content across all commits? | 04:34 |
| meoblast | yup | 04:34 |
| meoblast | all the numbers seem right on my end | 04:34 |
| meoblast | i'm testing the file | 04:34 |
| mzz | oh, you got it working already? | 04:34 |
| meoblast | i see no problems (at least not where it tells me the problems are) | 04:35 |
| meoblast | no, i should have it working | 04:35 |
| mzz | was going to say this seems pretty doable by hacking up fastimport, so I could do that if you can throw me a .fi file to test with | 04:35 |
| meoblast | bzr: ERROR: line 89879: Invalid command '' | 04:35 |
| meoblast | it's been telling me bad line numbers on errors all day | 04:35 |
| meoblast | i'm expected to figure out where the error is manually | 04:35 |
| meoblast | i checked that line, it was counted perfectly | 04:35 |
| RenatoSilva | how to view --fixes information in bzr log? | 04:36 |
| meoblast | mzz: this is just karma getting me back | 04:36 |
| meoblast | i've been telling another developer that bazaar kills git for weeks now | 04:36 |
| mzz | well, this is history rewriting | 04:36 |
| mzz | is that really something git's good at? because it's not usually a good idea | 04:37 |
| lifeless | mzz: git has some fairly polished tools | 04:37 |
| lifeless | mzz: callback per commit style thing. | 04:37 |
| mzz | (because like you said yourself it breaks pretty badly if people already got their hands on your branch) | 04:37 |
| lifeless | mzz: we need to do a lot better here :) | 04:37 |
| mzz | lifeless: there's a "foreach" plugin, I noticed | 04:37 |
| mzz | although I guess that doesn't mutate | 04:38 |
| mzz | hrm | 04:38 |
| meoblast | i probably should have made a rerolling script | 04:39 |
| meoblast | lifeless: i go through all these files in this dump thinking "oh i hope this one has some kind of discrepency" | 04:46 |
| meoblast | no, all the number match :( | 04:46 |
| meoblast | yay, it works | 04:47 |
| meoblast | it was those NULLS at the end of the file | 04:47 |
| johnf | OK packages now copies to ~bzr PPA | 04:55 |
| meoblast | last step, and i'm failing at it | 04:55 |
| johnf | and bzr and bzrtools now both uploaded to debian | 04:57 |
| meoblast | java :O | 04:57 |
| meoblast | anyone know of any text editors that can let me copy and paste binary without corrupting it? | 05:01 |
| mwhudson | emacs, i think? | 05:02 |
| meoblast | how do you copy and paste in emacs? | 05:04 |
| meoblast | wait, i have GTK emacs | 05:05 |
| igc | hi jam | 05:07 |
| jam | meoblast: vim if you ':set binary' | 05:08 |
| meoblast | how do you select all in emacs? | 05:08 |
| mzz | meoblast: C-x h | 05:09 |
| jam | hey igc, any ideas about why the build would fail? | 05:10 |
| jam | I assume you had it working when you committed it | 05:10 |
| mzz | (it's silly but I actually had to type that into emacs, I have it in muscle memory) | 05:10 |
| igc | jam: I'm just trying it now | 05:12 |
| igc | jam: the images are meant to be copied across so it should be finding them | 05:12 |
| meoblast | i'm getting angry :( | 05:13 |
| meoblast | there has to be a way to just pop this file into this stream without something breaking | 05:13 |
| igc | jam: I hadn't tested it sorry on the bzr installer (as I never had that fully working) but I did on the explorer one | 05:14 |
| meoblast | i'm not getting errors but i'm not getting any font data | 05:14 |
| meoblast | just a title | 05:14 |
| meoblast | if emacs can't do it, nothing can | 05:14 |
| meoblast | looks like i'm writting a new program? | 05:16 |
| meoblast | one that will insert a binary file right in here | 05:16 |
| jam | igc: k, I think it just needs to be pointed to the right location | 05:17 |
| jam | I just don't know exactly where that would be with all the copying, cogifying, etc. | 05:17 |
| jam | meoblast: i would really recommend looking at the 'filter-branch' portion of the fast-import code. | 05:18 |
| meoblast | but i'm so close :( | 05:18 |
| jam | and poke at igc since he's the one that has done most of the work for fast-import | 05:18 |
| jam | but let him fix my problem first :) | 05:18 |
| meoblast | you have to understand how close i am | 05:18 |
| meoblast | last thing i have to do is get this font into the stream | 05:18 |
| meoblast | that's it | 05:18 |
| meoblast | i'm trying to write a program that will do it | 05:19 |
| igc | jam: so I'm copying the images into the top build directory - maybe it needs to be a subdirectory of that | 05:20 |
| igc | jam: I'm trying it now fwiw | 05:20 |
| igc | jam: lines 142-143 in build-installer.bat.in ... | 05:25 |
| igc | maybe the target destination needs to be %TARGET% instead of ... | 05:25 |
| igc | win32_bzr.exe | 05:26 |
| jam | igc: I would guess you could just change the path in bzr.iss.cog | 05:28 |
| jam | to be ../../bzr-48.bmp | 05:28 |
| jam | given that you are creating tools/win32/bzr.iss | 05:28 |
| igc | jam: the path is relative to wherever issc is run btw, not the location of bzr.iss | 05:29 |
| igc | I *think* it being run in %TARGET% ?? | 05:29 |
| jam | igc: if that is true, then either the cp needs to go to . | 05:29 |
| mzz | also, am I the only one who always forgets to check shelve before deciding a branch is obsolete and can be deleted? | 05:29 |
| jam | or the path updated to win32bzr.exe/xxx.bmp | 05:30 |
| mzz | perhaps I should extend status to have a single line "shelved changes present" | 05:30 |
| igc | mzz: that would be good | 05:30 |
| mzz | has someone beaten me to that yet? :) | 05:30 |
| igc | jam: it's taking forever here for my various branches to be refreshed so ... | 05:31 |
| igc | jam: if you could try chagning those copy statements, that would be good | 05:31 |
| jam | igc: it takes just as long on kerguelen when things are up to date | 05:31 |
| jam | problem is that IO on kerguelen is awful | 05:31 |
| jam | but I'll try it, start it running | 05:32 |
| jam | and go to bed | 05:32 |
| jam | so no 2.0.0-1 installer tonight | 05:32 |
| igc | jam: yeah, I'm hitting that refresh bug so it keeps falling over on tags not being present | 05:32 |
| jam | but maybe tomorrow early | 05:32 |
| jam | igc: yeah, that's pretty annoying | 05:32 |
| jam | given that the point of using buildbot | 05:32 |
| jam | was so that we could have it autorefresh | 05:32 |
| jam | my 'build_release.py' did that just fine | 05:32 |
| jam | so far, my net experience of the buildout.cfg switch has been a net loss | 05:33 |
| jam | a lot more complexity without it actually working better | 05:34 |
| jam | and 'bin/buildout' seems to spend a huge amount of time verifying stuff | 05:34 |
| jam | at least on kerguelen | 05:34 |
| meoblast | this is impossible | 05:34 |
| jam | that may just be I/O being awful there | 05:34 |
| meoblast | no D': | 05:34 |
| meoblast | these streams are defective | 05:35 |
| igc | jam: so I've needed to start from scratch with a clean build_win32 directory :-( | 05:36 |
| jam | igc: ouch | 05:37 |
| jam | though I updated it so that all clients will share your local repo | 05:37 |
| jam | rather than building one per plugin | 05:37 |
| jam | so at least you will only redownload everything 1 time | 05:37 |
| jam | (I did it *because* of stuff like this) | 05:37 |
| meoblast | i think i might have this working | 05:40 |
| meoblast | i have to test | 05:40 |
| meoblast | the font i have in here isn't working in KFontView but Gnome font viewer is displaying it fine | 05:40 |
| meoblast | time to see if my app can display it | 05:40 |
| lifeless | jam: dropped you a callgrind you might find interesting; not urgent. | 05:41 |
| meoblast | nvm.. i'm seeing some epoch fail | 05:42 |
| meoblast | good night | 05:42 |
| meoblast | mom's yelling at me.. like always | 05:42 |
| lifeless | ITYM 'epic' | 05:42 |
| meoblast | no comprendo | 05:42 |
| meoblast | ITYM? | 05:42 |
| lifeless | I think you mean | 05:42 |
| meoblast | yeah | 05:42 |
| meoblast | i used the word epoch to describe how epic the fail was | 05:43 |
| meoblast | anyways, i'll work more on this tomorrow | 05:43 |
| meoblast | i'm seeing tons of work to do | 05:43 |
| meoblast | good night | 05:43 |
| mzz | is there a helper for subclassing a builtin command? things like the help text (__doc__) don't survive if I just subclass | 05:47 |
| lifeless | mzz: you can decorate instead. | 05:47 |
| lifeless | or say __doc__ = builtincmd.__doc__ | 05:48 |
| mzz | that's what I thought, but it doesn't actually work | 05:48 |
| mzz | "attribute '__doc__' of 'type' objects is not writable" | 05:48 |
| mzz | unless I did something braindead, of course | 05:48 |
| mzz | what does "decorate" mean in this context? | 05:48 |
| lifeless | did you say 'class.__doc__ = ..' | 05:48 |
| mzz | yes | 05:49 |
| lifeless | or __doc__ = .. ? | 05:49 |
| mzz | what should I be saying instead? | 05:49 |
| mzz | oh, gah | 05:49 |
| mzz | I am a moron | 05:49 |
| mzz | "decorate" sounds promising though, how does that work in this context? | 05:49 |
| mzz | I definitely don't want to replace the whole thing, I just want to add a line of output unless certain switches were passed | 05:50 |
| jderose | FYI, there is a problem with the bzrtools package in the PPA: bzrtools: Depends: bzr (< 2.0~) but 2.0.0-1~bazaar1~jaunty1 is to be installed | 05:50 |
| jderose | i filed a bug: https://bugs.launchpad.net/bzr/+bug/436371 | 05:50 |
| ubottu | Launchpad bug 436371 in bzr "bzrtools 2.0 package broken in PPA" [Undecided,New] | 05:50 |
| jderose | great job on the 2.0 release, everyone. i'm lovin' it! ;) | 05:51 |
| lifeless | jderose: cool | 05:51 |
| lifeless | mzz: have a look at cmd_switch in bzr-loom | 05:51 |
| mzz | ah, thanks | 05:51 |
| * mzz is rarely too lazy to read the manual or example code, but occasionally too lazy to go hunting for sane example code to read | 05:52 | |
| mzz | ah, I see. That should hopefully allow multiple plugins extending the same command? | 05:54 |
| mzz | probably unrelated, but what's up with those getattr(commands, 'cmd_switch') calls in __init__.py? Can't that just be commands.cmd_switch? | 05:56 |
| jam | mzz: old versions of bzrlib didn't have cmd_switch | 05:56 |
| lifeless | loom still runs with bzr's that don't have a built in switch | 05:56 |
| lifeless | jam: inore that .callgrind; the user had 256MB of ram allocated to his VM >< | 05:57 |
| lifeless | jam: so its swapping showing up | 05:57 |
| jam | lifeless: interesting | 05:57 |
| jam | I'm curious what the peak memory was | 05:57 |
| jam | if those 165MB files are moderately compressible | 05:57 |
| jam | we should have been able to do it in <=256MB | 05:57 |
| jam | though not that + system | 05:58 |
| jam | anyway, me sleep | 05:58 |
| lifeless | shoo | 05:58 |
| lifeless | talk to you monday :) | 05:58 |
| mzz | I know, that's what the hasattr call is for. But why does it do getattr(commands, 'cmd_switch')? Even if it wasn't inside a hasattr it still wouldn't do anything different from just commands.cmd_switch | 05:59 |
| lifeless | dunno, not looking at the code right now :) | 05:59 |
| lifeless | probably a buglet snuck in | 05:59 |
| mzz | I don't think a bug, it just seems like an unnecessarily complicated way of writing the same thing, unless I'm confused about how python works again | 06:00 |
| === _thumper_ is now known as thumper | ||
| mzz | lp:~marienz/+junk/shelfstatus is now a plugin adding one line "%d shelved changes" to "bzr status" if there are any. Does that seem like a good idea to anyone else? Perhaps I should file a feature request bug. | 06:57 |
| lifeless | please | 07:00 |
| lifeless | that would be good in core | 07:00 |
| mzz | yay | 07:02 |
| mzz | drat, already filed | 07:03 |
| mzz | bug 403687 that is, which I commented on. | 07:06 |
| ubottu | Launchpad bug 403687 in bzr "bzr status should show shelved changes" [Wishlist,Confirmed] https://launchpad.net/bugs/403687 | 07:07 |
| mzz | (it's obviously not hard to implement, although figuring out exactly what modes of the status command it should shut up in might require a bit more thinking than I did) | 07:07 |
| mzz | I'm glad there's a plugin mechanism so I can scratch this kind of itch without having to run a patched bzr :) | 07:08 |
| vila | hi all | 07:20 |
| vila | hmm, looks like I tried to run update-manager *just* at the wrong time :-/ | 07:21 |
| vila | I thought copying packages from one PPA to another will avoid such synchro issues... bur bzrtools-2.0.0-2 is still pending publication while bzr-2.0.0-1 has been published 2 hours ago ? | 07:23 |
| vila | james_w: Can you shed some light ? ^ | 07:23 |
| igc | hi vila! | 07:29 |
| igc | poolie: I've update the website branch with a 2.0.0 news item, better executive summary and working links | 07:32 |
| jderose | vila: there is an error in debian/control: Depends: bzr (<< 2.0~) | 07:32 |
| jderose | vila: https://bugs.launchpad.net/bzr/+bug/436371 | 07:32 |
| ubottu | Launchpad bug 436371 in bzr "bzrtools 2.0 package broken in PPA" [Undecided,New] | 07:32 |
| igc | poolie: is it worth rolling this out somewhere? | 07:33 |
| jderose | ubottu: ;) | 07:33 |
| vila | jderose: I'm pretty sure someone is already working on that | 07:40 |
| jderose | vila: ah, oops. | 07:41 |
| vila | yeah, it's already fixed for jaunty at least | 07:41 |
| vila | jderose: no oops, you were right to file a bug | 07:41 |
| vila | jderose: are you on jaunty too ? Can you check it's fixed fir you | 07:41 |
| vila | s/fir/for/ | 07:41 |
| jderose | vila: yeah i am, just apt-get update and it works now, thanks | 07:42 |
| vila | hehe, thanks jonhf instead, I was just whining :D | 07:42 |
| jderose | vila: works on my hardy vm too | 07:42 |
| vila | jderose: great, I'll mark it fix released then | 07:43 |
| jderose | cool | 07:43 |
| igc | poolie: http://people.canonical.com/~ianc/dancingmonkeys/ (latest website live) | 07:46 |
| bialix | hello bzr | 07:54 |
| bialix | anybody can provide me hints what I need to write plugin which controls default format in bzr? | 07:55 |
| bialix | maybe there is already one? | 07:55 |
| bialix | just yesterday I've stepped in the problem with undesirable upgrade to 2a format of branbch which should be in 0.92 | 07:55 |
| Peng_ | bialix: It's set with bzrlib.bzrdir.format_registry.set_default('2a') | 07:57 |
| * bialix looking | 07:57 | |
| Peng_ | bialix: (it's the last line of bzrdir.py) | 07:58 |
| bialix | I see | 07:58 |
| bialix | so all I need is to override this in my plugin? | 07:58 |
| Peng_ | Probably. Try it and see. | 07:58 |
| mzz | I don't recall bzr implicitly upgrading branches on me though. | 07:59 |
| Peng_ | I've been slowly upgrading to 2a anyway. :P | 07:59 |
| bialix | mzz: easy: create shared repo in 2a and branch there from 0.92 | 07:59 |
| mzz | yes. | 07:59 |
| mzz | I don't see changing the default format helping with that though, unless you mean by making it harder to create a 2a repo | 08:00 |
| bialix | yes | 08:00 |
| bialix | Peng_: this does not work: "Key 'default' already registered" | 08:03 |
| bialix | I can't change default | 08:03 |
| bialix | help? | 08:03 |
| Peng_ | Oh, darn. | 08:03 |
| Peng_ | bialix: .remove it first, I guess? | 08:04 |
| mzz | shrug, it's python, if you really want to you can find a way around it | 08:04 |
| vila | wow, karmic VM booting in 10 secs... (shutdown in 20s though.... surprising :) | 08:05 |
| LarstiQ | bialix: isn't there a setdefault() call? | 08:05 |
| bob2 | bialix: https://code.launchpad.net/mbp/+junk/default2a | 08:05 |
| bob2 | bialix: maybe hack that? | 08:05 |
| vila | bialix: poolie wrote such a plugin | 08:05 |
| bialix | bob2: Page not found | 08:06 |
| vila | bialix: lol, yeah, what bob2 said | 08:06 |
| vila | bialix: it's a branch | 08:06 |
| bob2 | https://code.launchpad.net/~mbp/bzr/default2a | 08:06 |
| bialix | This branch has not been pushed to yet. | 08:06 |
| bob2 | hmmm | 08:06 |
| bialix | bob2: third try? | 08:06 |
| bob2 | bialix: I got the initial link from https://bugs.launchpad.net/bzr/+bug/398668 | 08:07 |
| ubottu | Launchpad bug 398668 in bzr "2a format should be the default but some tests fail" [Critical,Fix released] | 08:07 |
| bob2 | ask poolie I guess | 08:07 |
| bialix | vila: any help? | 08:07 |
| vila | bialix: searching | 08:07 |
| bialix | poolie is not here | 08:08 |
| vila | bialix: lp:~bzr/+junk/default2a | 08:09 |
| vila | third is a charm :) | 08:10 |
| bialix | ok, thanks | 08:11 |
| bialix | working | 08:12 |
| bialix | anybody need it? do I need to publish my format switcher? | 08:13 |
| bialix | vila, Peng_, bob2: thanks, I'm almost happy now | 08:31 |
| bialix | 2.0 is unblocked for me | 08:31 |
| vila | great | 08:31 |
| bialix | now waiting for jam and installer | 08:34 |
| Lo-lan-do | 2.0 in unstable \o/ | 08:36 |
| * Lo-lan-do throws flowers all around | 08:37 | |
| igc | bbl | 08:40 |
| awilkins | 2.0! Shiny. | 08:51 |
| vila | lifeless: are you kidding with leaving a zombie from test_breakin ? I explicitly spend time ensuring that we don't... or may be you think it rarely occurs ? Want some stats to change your mind or do you trust me on hat one ? | 08:55 |
| vila | s/hat/that/ | 08:56 |
| maxb | Hmm. I'd dearly like to see bug 45719 fixed, but the more I look at it the more complex it seems | 09:01 |
| ubottu | Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] https://launchpad.net/bugs/45719 | 09:01 |
| maxb | Especially as I've never hacked on bzr before :-) | 09:01 |
| awilkins | jelmer: Is bzr-svn 1.0 really Python 2.5 and up only? | 09:39 |
| awilkins | jelmer: I've been using Python 2.4 on earlier versions.... is there a version where it specifically changed? | 09:40 |
| * awilkins runs bzr selftest svn bzr 2.0.0 / bzr-svn 1.0.0 / subvertpy 0.6.9 / python 2.4.3 / CentOS | 09:46 | |
| AfC | awilkins: I was just going to suggest that. Presumably that'll give you at least some indication | 09:49 |
| awilkins | AfC: Very reassuring ; compared to the codebase I'm working on, which is 277 thousand lines of Java and about ooooo, a hundred lines of tests. | 09:51 |
| AfC | awilkins: yeah, well, I very deliberately don't use libraries like that. | 09:53 |
| AfC | admittedly, testing end-user GUI code is hard, but I try my best. | 09:54 |
| awilkins | I'm ashamed to have written 22k lines of Java last year with no tests (mostly not GUI). | 09:54 |
| awilkins | In my defence, I get about 1 bug reported every 2 months | 09:54 |
| awilkins | And that's tailing off. | 09:55 |
| awilkins | This thing.... we've had a new release, seemingly with new bugs, every day this week. | 09:55 |
| awilkins | Bloody contractors | 09:55 |
| lifeless | vila: if its going to leave a zombie thats not desirable, but 10 seconds on fail isn't either | 09:58 |
| lifeless | vila: perhaps you could tweak it to meet the intent of my change? | 09:58 |
| vila | lifeless: by reducing the delay ? | 09:59 |
| lifeless | vila: yes | 09:59 |
| awilkins | Bah, needs tdb to run all the tests.... <install/run/curse> | 10:00 |
| lifeless | vila: right now, about one run in 3 it XFAIL's | 10:00 |
| vila | lifeless: to say the truth, when I reviewed it I was secretly hoping you will be deleting that tests :-) | 10:00 |
| lifeless | vila: my patch still closes it, no zomibie | 10:00 |
| lifeless | vila: if there is a zombie left it fails() | 10:00 |
| vila | oh, I was wrong then ? | 10:00 |
| lifeless | vila: I think you may be assuming something, yes. | 10:00 |
| vila | but then you comment is misleading since that from it that I based my comment ? | 10:01 |
| vila | errr | 10:01 |
| vila | I thought it left a zombie from: | 10:01 |
| vila | # process isn't gone, user will have to hunt it down and kill | 10:02 |
| vila | 128+ # it. | 10:02 |
| lifeless | look at the current code, it can do that too | 10:02 |
| lifeless | and if that happens, it does self.fail(...) | 10:03 |
| vila | ooooooh | 10:04 |
| vila | but you try to killl it once only | 10:05 |
| vila | ok, +1 then, I'll comment for mor e ideas | 10:05 |
| james_w | vila: no idea, sorry. | 10:06 |
| vila | james_w: np. I thought you encountered the same kind of issues for karmic yesterday or the day before ? | 10:07 |
| james_w | don't think so | 10:07 |
| vila | james_w: nm then | 10:07 |
| lifeless | vila: we wait once, we kill it 3 times | 10:08 |
| lifeless | vila: capped 0.4 seconds overhead | 10:08 |
| vila | lifeless: I seem to recall other numbers and experiences but things may have changed or my memory may betray me, I like your cleanup anyway, let's try it and wait for more evidence (if any !) | 10:09 |
| lifeless | vila: http://www.informationweek.com/blog/main/archives/2009/09/a_gpl_court_vic.html - did that make the mainstream press in france? | 10:11 |
| vila | lifeless: first time I hear about it, but I'm not really paying attention to mainstream press myself (but my friends know me enough to warn me for such subjects generally...) | 10:12 |
| jelmer | awilkins: no, it should work with 2.4 as well | 10:12 |
| awilkins | jelmer: I read INSTALL and thought the worst :-) ; I've been successfully using it on Python2.4 for a while though (version 0.6.5) | 10:14 |
| Lo-lan-do | lifeless: It did. | 10:15 |
| Lo-lan-do | lifeless: Didn't make a large splash, but the main papers reported it. | 10:16 |
| awilkins | jelmer: That's odd ; I installed python-tdb but it still says "Missing feature 'tdb' skipped 23 tests." | 10:18 |
| awilkins | jelmer: Still, it passed the other 1200 or so... | 10:19 |
| Lo-lan-do | lifeless: However, strictly speaking, the court decision isn't upholding the GPL. It's mostly about a contract that wasn't completely fulfilled, and the GPL was only incidental. | 10:20 |
| === strk_away is now known as strk | ||
| vila | lifeless: researching the subject a bit: 1) it's mentioned on zdnet which is well known but not mainstream. 2) There seem to be a lot of discussions about whether the GPL was really exercised there as opposed to a simple contract violation (evidence points to the later) | 10:22 |
| vila | lifeless: summary, good, but not that big a victory IMHO | 10:23 |
| awilkins | vila: Open source proceeds via incremental small victories :-) | 10:23 |
| vila | lifeless: ie I think Germany has more real GPL uses in court | 10:23 |
| awilkins | Think of it as a small but useful patch :-) | 10:23 |
| vila | awilkins: sure, I'm happy with that, just giving lifeless feedback on my "local" POV | 10:23 |
| davidstrauss | vila: There was a brief period where the 9th circuit court in the U.S. had some interesting findings on GPL violations being contract (not copyright) violations, but those were reversed later. | 10:24 |
| vila | which may or may not be relevant... | 10:24 |
| vila | davidstrauss: the contract didn't involved the GPL explicitly here | 10:24 |
| vila | sounds more like crass ignorance than wrong behaviour to me, but IANAL and I'm tend to be naive too sometimes (just to compensate for my natural cynical inclinations :D | 10:26 |
| vila | lifeless: oh, and they had to pay 8000 euros, just to give some scale... | 10:26 |
| lifeless | heh | 10:27 |
| awilkins | That would buy me a new car. As long as it was a very small one. | 10:27 |
| awilkins | Heck, with my "eco-friendly" scrappage bonus for having an old junker, it might even buy me a _nice_, new, small, car | 10:27 |
| Lo-lan-do | Or a new motorbike, moderately flashy. | 10:28 |
| awilkins | Lo-lan-do: I like having cargo space... and ungrated knees | 10:28 |
| * Lo-lan-do got a new bike for 6000€ this week :-) | 10:28 | |
| awilkins | I'd really like a small car powered by one of these (currently vaporware) new ultracapacitors they are supposedly making in Texas | 10:29 |
| awilkins | But I've had the one I've got 10 years and it's only done about 43,000 miles | 10:29 |
| davidstrauss | awilkins: Wait, what are we supposedly making? | 10:29 |
| awilkins | It's called EESTOR | 10:30 |
| awilkins | They claim to have found a way of producing a capacitor that can store 52kWh in under 200kg | 10:31 |
| awilkins | It's an array of 38,000 elements made of some sintered glass/alumina/barium titanate composite | 10:32 |
| lifeless | woo | 10:33 |
| davidstrauss | awilkins: Both EESTOR and the UT Austin supercapacitor teams are within ~10 miles of my office | 10:33 |
| awilkins | davidstrauss: Heh, don't tell the nutters at eestory.com, they'll want you to go and scout them out | 10:34 |
| davidstrauss | awilkins: eestory.com is a 404 | 10:35 |
| awilkins | davidstrauss: Sorry... theeestory.com | 10:35 |
| awilkins | And bariumtitanate.blogspot.com | 10:35 |
| awilkins | If it works I'll be pretty enthused | 10:36 |
| awilkins | It would make electric vehicles and domestic microgeneration somewhat more practical | 10:36 |
| awilkins | Hmm. Isn't --2a supposed to make your repository smaller | 10:37 |
| vila | davidstrauss: 404 is well known old Peugeot french car, I don't think it's related :D | 10:38 |
| davidstrauss | awilkins: --2a is the zombocom of repo formats. | 10:38 |
| awilkins | up to 1.7G from 949M | 10:38 |
| davidstrauss | awilkins: Run pack once more | 10:38 |
| Kinnison | awilkins: did you then try repacking? | 10:39 |
| * awilkins is doing that now | 10:39 | |
| davidstrauss | awilkins: Bzr archives a lot of junk during the first pack | 10:39 |
| davidstrauss | awilkins: there's a good reason, but the junk doesn't get dumped until the *second* repack | 10:39 |
| awilkins | Am I imagining it or does 2a take a lot longer to repack than previous formats :-/ | 10:40 |
| awilkins | Ok, it's a large repo | 10:41 |
| lifeless | awilkins: 1) make sure you have the C extensions | 10:41 |
| lifeless | 2) remove the contents of .bzr/repository/obsolete_packs after doing a sync() | 10:41 |
| awilkins | Got my 2.0 install from the ubuntu package manager | 10:41 |
| lifeless | davidstrauss: your advice is outdated btw | 10:42 |
| davidstrauss | lifeless: how so? | 10:42 |
| lifeless | awilkins: you don't need to pack after converting if you used 2.0.0 to do the conversion | 10:42 |
| lifeless | davidstrauss: ^ | 10:42 |
| lifeless | davidstrauss: bzr packs if it needs to while converting | 10:42 |
| awilkins | I thought it said "repacking" a lot :-) | 10:42 |
| Kinnison | lifeless: What's the obsolete_packs stuff and why doesn't bzr clean it up itself? | 10:42 |
| lifeless | Kinnison: ext4 insurance | 10:42 |
| davidstrauss | lifeless: oh, i just mean how pack archives stuff and doesn't dump archives until the second repack | 10:43 |
| awilkins | Aha, obsolete_packs has 865M | 10:43 |
| Kinnison | lifeless: bah, I don't use ext4. Can I opt out of the insurance? | 10:43 |
| awilkins | I should know this, I've been using it that long | 10:43 |
| lifeless | Kinnison: no, because I was trolling. More details... | 10:43 |
| lifeless | fsync() is silly, we want fbarrier. | 10:43 |
| lifeless | obsolete_packs is our manual fbarrier basically; when we delete a data containing file we: | 10:44 |
| lifeless | rm obsolete_packs/* | 10:44 |
| lifeless | mv foo obsolete_packs/ | 10:44 |
| lifeless | it will typically carry about 10 commits worth of content [thats the most common autopack size] | 10:44 |
| Kinnison | Mine was 33% of the size of my branch (which has many more than 30 commits) | 10:45 |
| lifeless | Kinnison: even if we had barrier, FTP & windows would be an issue | 10:45 |
| lifeless | Kinnison: it does this at power of 10 intervals | 10:46 |
| Kinnison | What's the semantics you need from fbarrier() ? | 10:46 |
| lifeless | if you have 123456 commits | 10:46 |
| lifeless | the max pack counts is 1 + 2 +3 + 4 +5 +6 | 10:46 |
| lifeless | if the pack count in the repo is larger autopack is triggered for the excess packs (taking the smallest packs first) | 10:47 |
| lifeless | so if you (say) were at 109 commits | 10:47 |
| lifeless | your most recent autopack would have aggregated 100 commits, and moved your entire prior repo contents | 10:47 |
| lifeless | bbiab | 10:47 |
| awilkins | Down to 866 MB from 949... well, not too bad | 10:52 |
| Peng_ | What's the change that means users no longer need to pack twice after a conversion to 2a? The thing in NEWS about more stable sorting? | 10:55 |
| vila | lifeless: final word about that GPL in court in France, the suit was an appeal of a first suit that granted ~1Meuros to the plaintiff, and was reverted tp give 8000euros to the defender (sp ?), so more important than I thought (I had to read the judgement to get a bit more context) | 10:59 |
| vila | and the GPL is clearly cited in one of the last conclusions, so it is in fact clearly an real use in court | 10:59 |
| vila | and the story started in 2000... | 10:59 |
| vila | ... and for the fun stuff, it involved using VNC with an hidden undisclosed to the client password for PC installed in public places.... | 11:00 |
| vila | tenths of PCs if the contract had been completed | 11:01 |
| awilkins | Bet it wasn't Linux machines with the VNC in a chroot jail either :-) | 11:02 |
| vila | windows indeed | 11:03 |
| vila | and the full contract was ~3Meuros | 11:04 |
| vila | So yes, basically even with that bunch of money involved they try to replace the GPL with their own copyright... | 11:05 |
| vila | idiots | 11:05 |
| orattue | is there a command to check what revision a working tree is on. bzr revno will tell me the revision of the repo tree, but not my working tree. | 11:09 |
| awilkins | orattue: There must be a way, because qbzr does it in some of it's dialogs, but I don't know the CLI version off the top of my head | 11:10 |
| orattue | hmm | 11:11 |
| awilkins | Heavens, `bzr help commands` is really long now, even with --no-plugins | 11:11 |
| awilkins | orattue: bzr revno --tree | 11:11 |
| orattue | hmm so that must be in newer version of bzr | 11:12 |
| orattue | will update my bzr now | 11:12 |
| orattue | odd that parameter is not in the online manual | 11:18 |
| orattue | ah no it is :) | 11:19 |
| Peng_ | Random off-topic question: Do they sell C5-size notepads? | 12:10 |
| awilkins | Question ; would it be possible to pull multiple branches in a single ssh / bzr+ssh session? | 12:12 |
| Lo-lan-do | awilkins: Yes, with SSHÂ connection multiplexing. | 12:12 |
| awilkins | It's not a real concern but I'm finding that the session creation and teardown is much more time consuming than the actual pull | 12:12 |
| awilkins | Lo-lan-do: How might I achieve that? | 12:13 |
| * awilkins googles | 12:13 | |
| Lo-lan-do | awilkins: The keyword is "controlmaster" in man ssh_config | 12:14 |
| Lo-lan-do | This only avoids the SSH session overhead though, the remote bzr will still be invoked several times. | 12:15 |
| awilkins | Lo-lan-do: Hmm. Working, but not that much faster | 12:15 |
| awilkins | Lo-lan-do: Maybe it is the remote process creation. Never mind, wasn't critical | 12:16 |
| AfC | awilkins: as an alternative you might try running a bzr:// on the server side. {shrug} | 12:16 |
| AfC | [one process, period] | 12:16 |
| awilkins | Yes | 12:16 |
| AfC | [for pulling, anyway. Still gotta use bzr+ssh to push] | 12:16 |
| awilkins | AfC: Not if it only listens to a local port that you have to tunnel to with ssh | 12:17 |
| awilkins | AfC: And you use --allow-writes | 12:17 |
| awilkins | But not critical, it's just very slightly annoying when the rest of it is so fast :-) | 12:18 |
| === loxs_wrk is now known as loxs | ||
| lifeless | visik7: thanks | 12:47 |
| jml | jelmer, you around? | 12:48 |
| jelmer | jml: somewhat | 12:48 |
| lifeless | visik7: sorry, typo | 12:48 |
| lifeless | vila: thanks | 12:48 |
| lifeless | hi jml | 12:48 |
| jml | jelmer, I was just talking to beuno about the ohloh import of Bazaar | 12:48 |
| jml | lifeless, hello | 12:48 |
| jml | jelmer, it's really slow, and I'd like to help them. He said that you knew some of the people involved. | 12:49 |
| jelmer | jml: yeah | 12:49 |
| jelmer | jml: obnox (a fellow samba developer) did the original support together with Robin from ohloh. | 12:50 |
| jelmer | jml: robin_at_ohloh hangs out in #ohloh, he's probably the best person to talk to | 12:50 |
| jml | jelmer, what would it take to get them to ask "we're doing <<DETAILS>> and it's really slow, how can we do it better?" | 12:50 |
| jml | jelmer, ok, thanks. | 12:50 |
| jelmer | jml: the source code importer in ruby is open source and on github somewhere | 12:50 |
| jelmer | jml: unfortunately it's all in Ruby | 12:51 |
| jml | jelmer, ahh, I see. | 12:51 |
| jml | jelmer, I'm sure we can do _something_ to make it better. | 12:52 |
| Peng_ | Wow, SSH connection multiplexing is coool. I should've set that up long ago. | 12:52 |
| jelmer | jml: They're basically invoking bzr cat for every file+revision combination IIRC | 12:52 |
| jelmer | jml: Let me see if I can find the repo URL.. | 12:53 |
| jelmer | jml: git://labs.ohloh.net/git/ohloh_scm.git | 12:53 |
| jml | jelmer, thanks. | 12:53 |
| mthaddon | lifeless: any objections to updating the chroot for bzr pqm from dapper -> hardy (will make python-subunit dependency much easier)? | 13:03 |
| Lo-lan-do | jelmer: Unstable's bzrtools 2.0.0 has a version.py that still says 1.18… | 13:07 |
| vila | mthaddon: check with lifeless but I think one reason to stay with dapper is python-2.4 compatibility, if we can get that with hardy (and I think we can), there shouldn't be a problem | 13:07 |
| === mrevell is now known as mrevell-lunch | ||
| mthaddon | vila: that's why I was asking lifeless :) but hardy has 2.4 no problems | 13:08 |
| vila | mthaddon: hehe, sry was trying to help without knowing the full context :D | 13:09 |
| mthaddon | np :) | 13:09 |
| === doko__ is now known as doko | ||
| === mrevell-lunch is now known as mrevell | ||
| Tak | does this suggest anything particular? http://paste2.org/p/437109 | 14:02 |
| vila | Tak: that you're trying to open a None object ? | 14:16 |
| Tak | I wish, then I could fix it! | 14:17 |
| vila | you mean 'directory' is not None ? | 14:18 |
| Tak | this is all happening internal to cmd_pull | 14:20 |
| vila | Tak: huh ? From the command-line ? | 14:21 |
| vila | Tak: are you using bzr.dev ? | 14:21 |
| vila | that 1552 line is different her | 14:21 |
| vila | that 1552 line is different here | 14:21 |
| Tak | no, I'm using cmd_pull from code | 14:21 |
| vila | ha, no silly, site-packages, installed version ? | 14:22 |
| vila | Tak: did you set .outf and are you sure your encodings are correct ? Can you show me the code ? | 14:22 |
| Tak | bzr --version gives me 1.18 | 14:22 |
| vila | what os/distro ? | 14:23 |
| Tak | debian sid | 14:25 |
| Tak | http://paste2.org/p/437125 | 14:25 |
| Tak | is basically the code | 14:25 |
| vila | did you load the plugins ? | 14:25 |
| Tak | bzrlib.plugin.load_plugins() ‽ | 14:26 |
| vila | yes | 14:26 |
| Tak | then yes | 14:26 |
| vila | Tak: use cmd._setup_outf() | 14:26 |
| vila | errr | 14:27 |
| vila | hmm, yeah, should work better than cmd.outf = sys.stdout for roughly the same results | 14:27 |
| vila | funnily enough I whine about that today on the ML... | 14:27 |
| Tak | two other things: 1) I'm evaling this code from libpython and 2) I see this error intermittently with the same arguments | 14:28 |
| vila | Tak: well, try usin g_setup_ouf() first, then we'll see :-D | 14:29 |
| Tak | heh, ok | 14:29 |
| vila | What do you mean by libpython ? | 14:29 |
| vila | you main program is ? | 14:29 |
| Tak | I mean...not natively from python | 14:29 |
| * Tak cough | 14:29 | |
| Tak | c# | 14:29 |
| vila | hmm | 14:29 |
| vila | any idea what is persistent in your env ? | 14:30 |
| vila | between lazy_loading, encodings being cached, etc, *not* using _setup_outf().... blurry the things a lot | 14:30 |
| * Tak nod | 14:31 | |
| Tak | I'm basically calling PyRun_SimpleString repeatedly with blocks of code, and trying to make sure everything's cleaned up with each block | 14:31 |
| vila | Tak: also are you pulling a lot of different branches ? | 14:31 |
| vila | wow, what do you mean by cleaning ?? | 14:32 |
| Tak | explicitly deleting instances | 14:32 |
| vila | ha, of the blocks run you mean / | 14:33 |
| vila | ha, of the blocks run you mean / | 14:33 |
| vila | ? | 14:33 |
| Tak | no, of temporary variables that get reused within the blocks | 14:33 |
| vila | by the way, if you do: mycmd.run('lp:blah', directory='/path/to/blah') you'll be protected against changes in the command parameters | 14:34 |
| * Tak nod | 14:35 | |
| vila | temporay like mycmd ? | 14:35 |
| Tak | well, in other instances: mytree = workingtree.WorkingTree.open_containing('blah')[0] # like mytree | 14:36 |
| Tak | switching to _setup_outf() eventually results in: http://paste2.org/p/437130 | 14:37 |
| Tak | maybe my whole approach is flawed | 14:39 |
| vila | I don't understand how an import can raise such an error.... | 14:42 |
| Tak | yeah, nor I | 14:42 |
| jam | anyone know if bug #436467 means I should be trying to package a qbzr 0.14.3 for Windows? | 14:54 |
| ubottu | Launchpad bug 436467 in qbzr/trunk "show log from browse inventory" [Critical,Confirmed] https://launchpad.net/bugs/436467 | 14:54 |
| jam | (still don't have packages because changing the installer icon broke the build for me, and I'm still sorting it out) | 14:54 |
| jam | vila, Tak: import runs the script it is importing | 14:58 |
| jam | which is why you need the "if __name__ == '__main__':" workaround if you want a script to both be importable, and runnable directly | 14:58 |
| jam | my guess is that osutils is being lazy imported | 14:58 |
| jam | so that you're getting a slightly strange timing issue | 14:59 |
| vila | jam: wow... and python can't report that ? | 14:59 |
| jam | so something is seriously weird about the traceback | 14:59 |
| vila | or is the lazy stuff masking it ? | 15:00 |
| jam | vila: I'm guessing the problem is in osutils.get_terminal_encoding() giving an exception, and osutils is lazy imported | 15:01 |
| jam | I don't know why it is claiming line 425 | 15:01 |
| jam | That looks bogus to me | 15:01 |
| vila | it's bzr-1.18 | 15:02 |
| jam | If I was guessing, this is the code that is failing: | 15:02 |
| jam | # check encoding | 15:02 |
| jam | try: | 15:02 |
| jam | codecs.lookup(output_encoding) | 15:02 |
| jam | except LookupError: | 15:02 |
| jam | to get that, it looks like both stdout and get_user_encoding() have to return None | 15:03 |
| jam | though this should prevent that: | 15:03 |
| jam | if user_encoding in (None, 'cp0', ''): | 15:03 |
| jam | user_encoding = 'ascii' | 15:03 |
| jam | vila: anyway, given the final exception is consistently: TypeError: expected string or Unicode object, NoneType found | 15:05 |
| jam | I wonder if there isn't a latent exception that he squashed but didn't clean up | 15:05 |
| jam | I've run into that with extensions | 15:05 |
| jam | you can accidentally leave an exception pending | 15:05 |
| vila | "he" ? | 15:05 |
| jam | even though you don't return NULL, or whatever to signal that an exception is coming | 15:06 |
| jam | Tak | 15:06 |
| Tak | hmm, I am doing some exception handling in a couple of places | 15:06 |
| Tak | I didn't realize there was something I needed to do to "clean up" | 15:06 |
| * Tak python noob | 15:06 | |
| Tak | what should I be doing/ | 15:07 |
| jam | PyExc_Clear() | 15:07 |
| jam | if you are doing stuff in python lib | 15:07 |
| jam | so if you are doing something like | 15:07 |
| Tak | will that have adverse effects if there are no exceptions pending? | 15:07 |
| jam | result = Py_DoSomething(); | 15:07 |
| jam | if result == NULL: # There was an exception | 15:07 |
| jam | # do something else | 15:07 |
| jam | at that point you *should* | 15:08 |
| jam | call "PyExc_Clear()" | 15:08 |
| Tak | yeah, I'm scraping the exception output already | 15:08 |
| jam | Tak: http://docs.python.org/c-api/intro.html#exceptions is the details | 15:08 |
| jam | sorry, PyErr_Clear() | 15:08 |
| jam | http://docs.python.org/c-api/exceptions.html | 15:09 |
| jam | or specifically: http://docs.python.org/c-api/exceptions.html#PyErr_Clear | 15:09 |
| jam | Tak: which says: "Clear the error indicator. If the error indicator is not set, there is no effect." | 15:09 |
| jam | so it sounds safe to do whenever you won't be propogating an exception | 15:09 |
| jam | I forget the specific cases, but there are some Python functions that return '-1' to indicate an error | 15:10 |
| jam | and there are some where '-1' is also a valid value, so when it returns they have to check | 15:10 |
| jam | PyErr_Occurred() | 15:10 |
| jam | and if you leave an exception around | 15:10 |
| jam | that will trip accidentally | 15:10 |
| Tak | I'm intentionally keeping my api exposure minimal | 15:11 |
| Tak | so I'm only using PyRun_SimpleString, PyMapping_GetItemString, and one or two others | 15:12 |
| Tak | hmm...first try didn't resolve the issue | 15:15 |
| Stavros | hello | 15:17 |
| Stavros | is anyone working on bzr-git here? | 15:17 |
| jam | Stavros: I believe jelmer is the primary person working on it, though I don't think he is here right now | 15:18 |
| Peng_ | jelmer was here a few hours ago. | 15:18 |
| Stavros | oh :/ | 15:18 |
| Stavros | i have investigated a windows bug i'd like to report, and i wouldn't want to file a duplicate | 15:18 |
| Stavros | but i guess i'll have to | 15:18 |
| jam | Stavros: you can certainly ask in here | 15:19 |
| jam | but launchpad has a decent de-dup feature | 15:19 |
| Tak | aha - a more liberal sprinkling thus far appears to have resolved it | 15:19 |
| Stavros | jam: i searched and there aren't any that appear to be duplicates, so i can file it | 15:19 |
| Stavros | bzr expects to find a tempfile that isn't there, and crashes | 15:19 |
| Peng_ | Stavros: Filing a dupe isn't a big deal. Don't worry about it! | 15:20 |
| Peng_ | I mean, do try to make sure you're not filing a dupe, but if it happens, it's fine. | 15:20 |
| Peng_ | It's a lot better than not filing bug reports at all. | 15:20 |
| Stavros | Ah, thanks | 15:21 |
| Stavros | i'll do that then | 15:21 |
| shled | I accidently added a confidential sqlite db about 30 commits ago. How can I completely remove it from the repository? | 15:34 |
| Lo-lan-do | shled: You'll need to uncommit, then garbage-collect. | 15:35 |
| Lo-lan-do | Unfortunately, I don't think garbage-collection is implemented right now, so you'll have to rebuild your repository. | 15:36 |
| Lo-lan-do | Well, depending on whether you're in a repo or in a standalone branch. | 15:37 |
| Peng_ | Ehh, rebase and/or fastimport can help you not totally destroy the last 30 revisions of history. | 15:37 |
| shled | Lo-lan-do: that sounds like lots of work | 15:37 |
| shled | Peng_: that sounds better | 15:38 |
| Peng_ | shled: There isn't any super-easy way out of this. It will take a bit of work. | 15:38 |
| Lo-lan-do | shled: Not necessarily. If it's just a single branch, the rebuilding won't be too hard. | 15:38 |
| Peng_ | Still, I think fastimport is supposed to be quite easy, once you learn how to do it. | 15:38 |
| shled | Lo-lan-do: it is a single branch | 15:38 |
| shled | Lo-lan-do: so what would I do exactly? | 15:39 |
| Lo-lan-do | Try something like "bzr branch -r $goodrev $oldbranch $newbranch ; cd $newbranch ; bzr replay -r $badrev+1.. $oldbranch" | 15:39 |
| Lo-lan-do | With $badrev=$goodrev+1=the rev where you committed the file. | 15:40 |
| Lo-lan-do | I don't really know fastimport. | 15:40 |
| LeoNerd | Hrm... shelve in a svn checkout really doesn't seem to work nicely when some of the changes are added files | 15:41 |
| LeoNerd | I think I've broken it so now I can't unshelve. :/ | 15:42 |
| shled | Lo-lan-do: sweet, many thanks! | 15:42 |
| Peng_ | Lo-lan-do: Oh, that works? Nice. | 15:43 |
| Lo-lan-do | Oh, yes, you could also do it with repeated uncommit+shelve then unshelve+commit | 15:43 |
| Peng_ | You'd lose the commit metadata. | 15:43 |
| Lo-lan-do | Peng_: I don't know for sure, but it should. | 15:43 |
| Lo-lan-do | Right. replay it is, then. | 15:44 |
| === oubiwann_ is now known as oubiwann | ||
| smoser | is there anythign in bzr like git-format-patch and git-am ? i'm looking for some way that i "export" a commit (or series of commits), and then import them in another bzr branch. | 15:49 |
| smoser | i want to keep the commit messages | 15:49 |
| Peng_ | smoser: bzr send | 15:50 |
| vila | smoser: why don't you just merge ? | 15:50 |
| smoser | another can of worms | 15:50 |
| Peng_ | smoser: If you just want to generate a patch, "bzr send -o foo.patch", then in the other branch, "bzr merge foo.patch" (or probably "bzr pull foo.patch", I dunno) | 15:50 |
| smoser | i'm having issues with merge due to repository format issues. | 15:50 |
| Peng_ | smoser: Transferring the revisions in another way won't change that. | 15:51 |
| Peng_ | smoser: That's easy enough to solve, though. What's going on? | 15:51 |
| shled | Lo-lan-do: bzr: ERROR: unknown command "replay" | 15:51 |
| Lo-lan-do | shled: It's in the bzr-rebase plugin | 15:52 |
| shled | Lo-lan-do: Thanks! | 15:52 |
| smoser | Peng_, well, transfering thenm in another way *should* solve that... ie, if i make a patch , copy it, change repos, patch -p0 < patch , bzr commit -m .... | 15:52 |
| Peng_ | smoser: Well, then you wouldn't be transferring the revisions themselves. Just the patch, no metadata. | 15:53 |
| Lo-lan-do | In which case, maybe a "bzr dpush" would do the trick? | 15:54 |
| smoser | Peng_, i dont care about metadata other than commit messages | 15:54 |
| Peng_ | smoser: Anyway, details. What are the repository formats involved? Did you "bzr upgrade" anything? Convert to rich-roots or subtrees? | 15:54 |
| smoser | http://paste.ubuntu.com/277965/ is what shows my issue. i seem to constantly be facing issues with different archive formats on launchpad and elsewhere, and just want a way to say forget it | 15:55 |
| Lo-lan-do | I think dpush is what you want. | 15:55 |
| smoser | in git, i would just git-format-patch, and then on the other side git-am | 15:55 |
| Peng_ | Eh. | 15:56 |
| Peng_ | Ohhhh. | 15:57 |
| smoser | is there just no equivalent in the bzr world ? if someone wants to send an email with a patch, and you (the bzr branch maintainer) want to say "yeah, that looks good" or even "i'd like that applied to my tree to test" is there no way to do that ? | 15:57 |
| smoser | without sending merge metadata and dealing with archive format issues ? | 15:57 |
| Peng_ | smoser: You didn't do anything wrong, and and using a patch won't help. | 15:58 |
| Peng_ | smoser: s/and using a patch/throwing out the metadata/ | 15:58 |
| smoser | yes it would help | 15:58 |
| Peng_ | smoser: Not with the issue you pastebinned. | 15:58 |
| smoser | i dont care about the metadata. | 15:58 |
| Peng_ | Actually, wait, no, you could downgrade. Umm. | 15:58 |
| smoser | so i would "fix" this issue by branching from the branch that launchpad would want | 15:58 |
| Peng_ | Hmm. | 15:58 |
| smoser | and then sending my patches to that new copy | 15:58 |
| smoser | and then pushing | 15:58 |
| smoser | thank you for your help. | 15:59 |
| Peng_ | The problem is that your parent branch and your branch are in one format, and LP is trying to automatically stack on a third branch for efficiency, but that branch is in a different format. | 15:59 |
| smoser | correct. so i'm saying "forget about my branch" . other than i just want to get the 5 commits *out* of my branch in a way that is easy to pull in in another branch | 16:00 |
| Peng_ | Ideally, LP and bzr would be less dumb, and lp:~soren would upgrade lp:~soren/ec2-init/0.5 to 2a. | 16:00 |
| Peng_ | Hold on a second. | 16:00 |
| Lo-lan-do | You could export each of the commits with bzr send and only apply the patch but not the metadata. | 16:00 |
| soren | It would be rude to just update my branch without asking me. | 16:00 |
| soren | Maybe I don't run a recent enough bzr. | 16:01 |
| luks | bah, gmane is broken and doesn't let me to send a mail to the bzr ml | 16:02 |
| smoser | Lo-lan-do, how would i do this ? | 16:02 |
| Peng_ | smoser: This should work: http://paste.pocoo.org/show/141468/ | 16:02 |
| * Peng_ hates stacking. | 16:02 | |
| Peng_ | (Well, not as a concept, but the current implementation is a format minefield.) | 16:03 |
| james_w | Peng_: thanks, but we're past that issue now, and still smoser wants to be able to do this | 16:03 |
| james_w | Peng_: we've created two unrelated branches of the same code and are dealing with the fallout | 16:03 |
| Lo-lan-do | smoser: "bzr send -r $rev --no-bundle -o $rev.patch" or so | 16:03 |
| Peng_ | @_@ | 16:03 |
| james_w | smoser: there is no equivalent currently | 16:04 |
| Peng_ | Peng's brain doesn't have room for technical things right now. Bye! :P | 16:04 |
| smoser | Peng_, and then would that allow soren to easily merge ? | 16:04 |
| james_w | wouldn't be too hard to write, but except in weird situations like this "send" is preferred | 16:04 |
| soren | Hardly. It doesn't solve the "no common ancestry" problem. | 16:04 |
| Peng_ | Oh, hi soren! | 16:05 |
| Peng_ | soren: You should upgrade your branches to 2a! :D | 16:05 |
| Peng_ | soren: It's spiffy and cool and wrecks backwards compatibility! | 16:05 |
| soren | You should be a salesman. | 16:05 |
| Peng_ | Mixing rich-root-pack and 2a is not a problem for merging. It's just a problem for stacking. | 16:05 |
| smoser | git-cherry-pick and git-format-patch and git-am is just something i dont understand how you're supposed to live without | 16:06 |
| Peng_ | Eh, I have no attention span right now. I'm mostly basing what I say on the last 3 lines of conversation. :P | 16:06 |
| smoser | Lo-lan-do, thank you. i will at least keep that around. | 16:07 |
| soren | smoser: I use "bzr log -c <revno> -p", fwiw. | 16:10 |
| luks | smoser: what's better about git-format-patch/git-am instead of bzr send/bzr merge? | 16:10 |
| soren | luks: The former do not care what sort of vcs the submitter is using. | 16:11 |
| luks | I doubt it would do something smart a bzr diff | 16:12 |
| soren | Huh? | 16:12 |
| luks | does git-am import the commit message from a patch generated by bzr send? | 16:13 |
| soren | smoser: ^ | 16:13 |
| luks | er, there is missing 'with' in the line | 16:13 |
| luks | but if you have a project in bzr, it's expectable that you work with bzr | 16:14 |
| soren | No, it's not. | 16:14 |
| smoser | luks, i dont know if it does from bzr send. it does from git-format-patch or git-send-email | 16:14 |
| soren | vcs-imports on Launchpad. nuff said. | 16:14 |
| smoser | luks, i'm *trying* to work with bzr | 16:14 |
| soren | smoser: https://bugs.edge.launchpad.net/bzr/+bug/227340 | 16:14 |
| ubottu | Launchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Wishlist,Confirmed] | 16:14 |
| soren | smoser: You may want to subscribe to that one. | 16:14 |
| luks | right, so it does care about the VCS the submitter is using | 16:14 |
| luks | it must be git | 16:15 |
| smoser | no | 16:15 |
| smoser | its patch and a comment | 16:15 |
| soren | luks: Eh? | 16:15 |
| luks | with metadata | 16:15 |
| luks | like author, date | 16:15 |
| smoser | metadata like "From:" | 16:15 |
| smoser | thats about it | 16:15 |
| luks | you expect people to write those by hand? | 16:15 |
| soren | I think it's being horribly abused in git, but I certainly do see its usefulness. | 16:16 |
| luks | I find it weird | 16:16 |
| smoser | you find sending emails to mailing lists wierd ? | 16:16 |
| luks | bzr send/merge/pull is a much simpler concept | 16:16 |
| luks | you can treat the patch as a standalone branch | 16:16 |
| smoser | and then wanting to *use* those emails without a bunch of hassle | 16:16 |
| soren | luks: Look, not everyone's upstreams are using bzr. | 16:17 |
| luks | soren: why not use the project's VCS then? | 16:17 |
| soren | luks: Because I happen to like bzr, and I can import all sorts of stuff into bzr. | 16:17 |
| LaserJock | soren: +1 | 16:17 |
| luks | btw, there bzr send --format=git in bzr-git | 16:17 |
| soren | I don't use bzr-git. | 16:17 |
| luks | how do you convert the git repository to bzr? | 16:18 |
| soren | Launchpad. | 16:18 |
| luks | whoa, did they create another incompatible importer? | 16:18 |
| Peng_ | I think they use bzr-git. | 16:18 |
| soren | I have no clue what they do. It's magic. | 16:18 |
| === Kinnison_ is now known as Kinnison | ||
| luks | then bzr send --format=git should work | 16:18 |
| Peng_ | They have interns type it all out. | 16:19 |
| luks | it will give you a patch with all the metadata git-am expects | 16:19 |
| luks | so that you can use native git tools to work with it | 16:19 |
| soren | I also occasionally receive patches from git users. | 16:19 |
| smoser | i really didn't mean to start a dvcs war | 16:19 |
| smoser | i promise | 16:19 |
| smoser | drcs | 16:19 |
| soren | I would like to import them. | 16:19 |
| smoser | can someone maybe just help me with a simple (i think) problem. | 16:20 |
| smoser | i have this branch, that has 4 commits on it. i'd like to export those 4 commits to some format that i can then import into another branch. | 16:20 |
| luks | well, my point was that it's wrong trying to use bzr as if it was git | 16:20 |
| luks | because it's not | 16:20 |
| smoser | the other branch is in a different format (which i dont thin kshould matter) | 16:20 |
| smoser | bzr send -r 34 --no-bundle -o - | 16:20 |
| smoser | is what i tried. | 16:21 |
| luks | there are different tools and methods when working with patched in bzr | 16:21 |
| smoser | i tells me: | 16:21 |
| luks | use bzr send without any -r argument | 16:21 |
| smoser | bzr: ERROR: No public branch specified or known | 16:21 |
| luks | see bzr help send for that | 16:21 |
| Peng_ | smoser: Which formats are the two branches? | 16:21 |
| soren | luks: When we create importers for all sort of other VCS's we can't expect the upstreams to just accept bzr bundles or whatever. They should get patches or whatever in the format THEY prefer. | 16:22 |
| james_w | it's not about formats | 16:22 |
| luks | soren: that's why bzr-svn has send --format=svn, bzr-git has send --format=git | 16:22 |
| luks | which produce patches in native formats | 16:22 |
| soren | Right. I want to /IMPORT/ patches from these people as well. | 16:23 |
| luks | bzr patch foo.patch | 16:23 |
| james_w | but that doesn't do the metadata | 16:23 |
| smoser | ok, i'm apparently missing something in the help, or a concept even. because i would think that my request to 'send -r 34 --no-bundle -o -' would be a compmletelyi offline operation | 16:23 |
| soren | luks: I'm not talking to you anymore. | 16:23 |
| luks | james_w: neither does git-am on a bzr send patch | 16:23 |
| luks | soren: ok :) | 16:24 |
| soren | luks: It's pointless. You refuse there's a problem, and that's just silly. | 16:24 |
| smoser | that woudl be very similar to 'log -3 34 -p' | 16:24 |
| james_w | luks: please stop. I'd like to help smoser get his work done | 16:24 |
| soren | It's bloody rude to create importers for other VCS's and be a prick about submitting patches to them and then going ahead and being a prick when they do the same onto you. | 16:24 |
| soren | If we want to work with other VCS's, we should do so both ways. Expecting everyone else to submit the the ways of bzr is a losing battle. | 16:25 |
| soren | And extremely arrogant. | 16:25 |
| james_w | smoser: there is currently no way in bzr to apply a plain patch and commit it with metadata from that patch | 16:25 |
| james_w | smoser: we can hack up a shell pipeline to approximate it | 16:26 |
| LarstiQ | soren: it seems to me that the foreign vcs would be the way to apply their format, then pull across? | 16:26 |
| smoser | james_w, yes, i can hack up similar shell pipeline. | 16:26 |
| smoser | thanks. | 16:26 |
| luks | soren: look, I regularly work with svn repositories over bzr | 16:26 |
| luks | soren: bzr send --format=svn was created becasue of that (thanks to jelmer for finishing it) | 16:27 |
| soren | LarstiQ: Different VCS's, different customes. | 16:27 |
| soren | customs, I mean. | 16:27 |
| soren | LarstiQ: git users tend to submit patches by e-mail, not by pushing a branch somewhere. | 16:27 |
| luks | I'm not trying to be arrogant, I know what are the problems when working with a foreign VCS | 16:27 |
| soren | I don't blame them. Pushing git trees is a hassle. | 16:27 |
| luks | and I wrote code to support that | 16:27 |
| LarstiQ | soren: yes, so I'd apply the patch with git, then pull to bzr, at first. | 16:28 |
| soren | LarstiQ: That's the thing. That's quite different from how git users work. | 16:29 |
| LarstiQ | soren: isn't that how git users integrate the work, apply the patch? | 16:29 |
| Tak | I agree with LarstiQ - I'd have a local git branch that I used as a gateway | 16:31 |
| soren | Take a look at lkml. | 16:31 |
| soren | People don't usually have their own tree. They submit patches by e-mail. That's the custom. | 16:32 |
| jam | vila: do you know what ESRCH is used for? | 16:32 |
| jam | I don't recognize the error code, and lifeless is probably sleeping | 16:32 |
| LarstiQ | soren: yes. So how does Linus integrate their contributions? | 16:32 |
| vila | jam: in a kill context ? | 16:32 |
| jam | vila: yeah | 16:32 |
| vila | jam: I'm 80% sure it means the process doesn't exist anymore (failure during some SeaRCH) | 16:33 |
| Tak | vila, jam: with continued use, it looks like that error is resolved - thanks for all the help | 16:33 |
| Tak | I would never have tracked that down on my own | 16:33 |
| vila | Tak: what was it then ? | 16:34 |
| jam | vila: not clearing an exception that he silently squashed | 16:34 |
| jam | doing that leads to random exceptions when some python function decides to check if an exception is pending | 16:34 |
| smoser | LarstiQ, the difference is that linus can 'integrate' from a that patch, or from their published git repo wholescale or from theri public repo with cherry-pick | 16:34 |
| Tak | not even that I necessarily squashed, but that possibly got squashed somewhere in library code | 16:34 |
| smoser | (and cherry-pick does the commit, it doesn't just leave you there having to do it yourself) | 16:35 |
| LarstiQ | smoser: ok, so why not do the same, and then bzr pull from the resulting git branches? | 16:35 |
| smoser | the difference is that there is no option (as far as I can tell) to take a commit from an email | 16:36 |
| smoser | with metadata without by-hand or shell scripting | 16:36 |
| LarstiQ | ok | 16:36 |
| smoser | its an extremely simple work flow that works for lots of things. | 16:37 |
| smoser | i open up my email program, type a 'To', 'Subject:' describe a set of changes in a patch (ie write the commit messgae), and then append the patch. | 16:38 |
| smoser | and you just say 'git-am < mbox' to apply it | 16:39 |
| james_w | (not that we will copy the git-am interface, it's one of the most unpleasant things I've ever used) | 16:40 |
| jam | smoser: so *if* you are using bzr bundles 'bzr merge' just works, and if you are using patches 'bzr patch' will apply the data, but not the commit message. | 16:42 |
| jam | One possibility is to try to recognize the git "patch+" format as another bundle format | 16:42 |
| jam | so that you can use 'bzr merge' if in a slightly lossy fashion | 16:42 |
| Tak | that seems like the most sensible option | 16:43 |
| jam | It is probably non-trivial | 16:43 |
| jam | and if done | 16:43 |
| jam | it would be probably first implemented in bzr-git | 16:43 |
| Tak | either that or extend `bzr patch` in bzr-git the same way that `bzr send` was extended | 16:43 |
| * Tak nod | 16:43 | |
| jam | and if I read the traceback correctly smoser didn't want to install bzrgit | 16:43 |
| jam | etc | 16:43 |
| smoser | i have no problem with bzr git | 16:43 |
| vila | jam: is there a way to display the working tree revid from the command line ? | 16:44 |
| jam | vila, igc: \o/ windows installers finally worked out, and being uploaded now | 16:45 |
| jam | vila: not the wt | 16:45 |
| vila | jam: thks | 16:45 |
| sidnei | jam: congrats! | 16:45 |
| jam | though I thought fullermd was trying to fix stuff like 'bzr revision-info' to add a '--tree' option | 16:45 |
| vila | bug # ? | 16:45 |
| jam | vila: it has been merged | 16:45 |
| jam | 'bzr revision-info --tree' | 16:45 |
| jam | $ bzr revision-info --tree | 16:45 |
| jam | 4683 john@arbash-meinel.com-20090924221525-5vezfwzai1d2ajnn | 16:45 |
| vila | excellent, thanks | 16:46 |
| jam | vila: landed in bzr 1.17 in fact | 16:46 |
| jam | well, at least according to NEWS | 16:46 |
| vila | Never needed it... | 16:46 |
| vila | ..and didn't grepped it when doing bzr revision-info --help :-/ | 16:47 |
| vila | jam: congrats for the installers !!! (Missed that one :D) | 16:50 |
| jam | vila: I think you mean 'grok' it | 16:51 |
| vila | vila: thanks, but I meant that I didn't *see* it at all | 16:52 |
| === deryck is now known as deryck[lunch] | ||
| * zsquareplusc is waiting for 2.0.0 for windoze | 16:55 | |
| fullermd | Yeah, I added it to rev-info and revno. The only places that looked likely... | 16:56 |
| Lo-lan-do | Is there a way to know if a repo contains ghost revisions faster than a bzr check? | 17:00 |
| james_w | Lo-lan-do: I'd reach for "python -c", why do you need to know? | 17:04 |
| Lo-lan-do | james_w: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538056 | 17:09 |
| ubottu | Debian bug 538056 in bzr "bzr: push should (optionally) push ghosts" [Wishlist,Open] | 17:09 |
| Lo-lan-do | I'd like to be sure the bzr branches I provide are complete. | 17:09 |
| james_w | ah | 17:10 |
| james_w | I'm not sure of any other command that can tell you I'm afraid | 17:10 |
| Lo-lan-do | I'm currently pushing into a fresh repo on the server, from which I'll "bzr fetch-ghosts", but it's a bit meh. | 17:11 |
| Lo-lan-do | (Largeish repo and ADSL) | 17:11 |
| garyvdm | Hi all | 17:19 |
| garyvdm | jam: please will you take a look a https://code.edge.launchpad.net/~garyvdm/bzr/get_trees_and_branches_to_diff/+merge/12341 | 17:19 |
| garyvdm | jam: it's to fix a bug you loged :-) | 17:19 |
| garyvdm | Hi vila | 17:20 |
| vila | hey gary :D | 17:20 |
| garyvdm | err - just been summoned for dinner, bbl | 17:21 |
| vila | lol at garyvdm, but daughters are likely to do the same quickly :D | 17:22 |
| zsquareplusc | bzr branch using a bzr+ssh URL (Windows cmd) it says "command-line: line 0: Bad configuration option: ClearAllForwardings" followed by a connection closed error. can someome translate this error from "techincal" to "english"? | 17:35 |
| LarstiQ | zsquareplusc: what ssh client is that using? | 17:35 |
| zsquareplusc | i dont know. i hope paramiko that was installed with the BZR windows standalone setup | 17:36 |
| zsquareplusc | hm, i see just launching bzr explorer gives the same error | 17:37 |
| luks | what version of bzr? | 17:37 |
| Peng_ | That's one of the args bzr passes when running OpenSSH. | 17:37 |
| luks | https://bugs.launchpad.net/bzr/+bug/47414 | 17:37 |
| ubottu | Launchpad bug 47414 in bzr "sftp doesn't work on windows" [Medium,Fix released] | 17:38 |
| luks | oops, that's from 2006 | 17:38 |
| luks | ignore that :) | 17:38 |
| zsquareplusc | oh no, my last comment was wron, explorer gives no warning | 17:38 |
| zsquareplusc | it is the 2.0.0 release i'm using. though i had the same error with 1.16 (which i deinstalled) | 17:38 |
| luks | do you have cygwin or something in %PATH%? | 17:39 |
| zsquareplusc | yes | 17:39 |
| jam | zsquareplusc: given that I just uploaded it... 10 minutes ago, did you already download it? | 17:39 |
| zsquareplusc | jam yes, jam :-) | 17:39 |
| jam | Do you have an 'ssh.exe' somewhere on your path? | 17:39 |
| luks | try with "set BZR_SSH=paramiko" | 17:39 |
| jam | It looks like a case where someone may have renamed "putty.exe" to "ssh.exe" | 17:40 |
| jam | and then bzr is trying to interact with a putty executable as though it was an OpenSSH one | 17:40 |
| jam | alternatively, there is another SSH implementation out there, can't remember the name off hand | 17:40 |
| jam | as mentioned, I would recommend "set BZR_SSH=paramiko" | 17:40 |
| jam | which should be bundled with the installer | 17:40 |
| zsquareplusc | there is a ssh.exe (openssh). maybe from mingw | 17:41 |
| jam | zsquareplusc: well, if you have an ssh.exe around we will default to using it | 17:41 |
| Peng_ | bzr does check "ssh --version", no? | 17:41 |
| luks | is there a bazaar.conf option for BZR_SSH? | 17:41 |
| jam | though if it was openssh it should support "ClearAllForwardings" | 17:41 |
| jam | luks: no | 17:41 |
| jam | you can set the global env var | 17:42 |
| zsquareplusc | ok it works when i set BZR_SSH thanks | 17:42 |
| luks | hm, something like this could be configurable in qconfig | 17:42 |
| jam | My Computer / Properties / Advanced System Settings / Environment Variables / New... user variable | 17:42 |
| luks | yeah, but that's not as nice | 17:43 |
| zsquareplusc | jam: using an existing ssh is probably the best thing on every OS except windows. i don't know if it is a good idea there. | 17:43 |
| jam | zsquareplusc: the main issue is that 'it depends' | 17:43 |
| jam | because if you have ssh.exe on your path, it is 'somewhat' likely that you have it configured | 17:44 |
| maxb | Have the columns in "bzr viz" ever been dynamically resizable? I thought they were, but they don't seem to be now. | 17:44 |
| jam | maxb: I think they are, but there are limits. And IIRC if you have a very wide graph, it pushes everything to their limits and then you can't adjust it | 17:44 |
| jam | maxb: (I might recommend 'bzr qlog' instead...) | 17:44 |
| maxb | I have a very thin graph, and I can't see the tags | 17:45 |
| zsquareplusc | well if the error would at least somehow indicate that the problem happened when executing an external "ssh" i would have been so puzzled | 17:45 |
| maxb | and it doesn't seem to want to let me resize anything at al | 17:45 |
| jam | zsquareplusc: we've certainly talked about disabling the ssh.exe check on Windows, and instead having the user "set BZR_SSH=ssh" manually if they want it | 17:47 |
| jam | just trying to find the right balance | 17:47 |
| jam | leaning towards it, though | 17:48 |
| zsquareplusc | i would agree. well at least i was expecting that it is using the bundled ssh client. anyway i've made a bug report | 18:00 |
| Peng_ | You can check the SSH client being used in .bzr.log. | 18:02 |
| zsquareplusc | if you knew that file file exists and where it is located | 18:05 |
| garyvdm | jam: Thanks for doing the review :-) | 18:08 |
| === mrevell is now known as mrevell-dinner | ||
| Peng_ | zsquareplusc: "bzr version" will tell you. | 18:09 |
| === deryck[lunch] is now known as deryck | ||
| beuno | jelmer, ping | 18:49 |
| beuno | do you happen to know anything about this: http://launchpadlibrarian.net/32430314/opensim-new-trunk-log.txt | 18:49 |
| james_w | beuno: that looks like a difference between path names that git will store and those that bzr will store | 19:06 |
| james_w | I think part of the reason is that the serialiser doesn't or can't escape some of the things that it should | 19:07 |
| james_w | but there's also a question of whether you should e.g. store paths that you can't create on ntfs | 19:07 |
| beuno | right | 19:07 |
| rubic | looking for docs to upgrade repository format from 1.x to 2.0 | 19:12 |
| beuno | rubic, bzr check && bzr reconcile && bzr upgrade | 19:12 |
| beuno | that should do the trick | 19:13 |
| mzz | http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html if you want a document but it's pretty much that | 19:14 |
| rubic | beuno: mzz: thanks | 19:14 |
| jam | beuno: for your traceback, I'm pretty sure that is a filename that has a literal '\' character in it | 19:22 |
| jam | and currently bzrlib refuses to allow you to add files with '\' | 19:22 |
| barry | hi all. i have a (hopefully) quick question about read locks. i'm trying to update setuptoolsbzr to bzr 2.0 but something that was working earlier is now failing with an ObjectNotLocked error | 19:22 |
| barry | here's what the code does: | 19:23 |
| barry | # Open an existing branch which contains the url. | 19:23 |
| barry | branch, inpath = Branch.open_containing(path) | 19:23 |
| barry | # Get the inventory of the branch's last revision. | 19:23 |
| barry | inv = branch.repository.get_revision_inventory(branch.last_revision()) | 19:23 |
| barry | # Get the inventory entry for the path. | 19:23 |
| barry | entry = inv[inv.path2id(path)] | 19:23 |
| barry | 19:23 | |
| jam | barry: as soon as you open something, you should probably do 'lock_read()' | 19:23 |
| jam | and put the rest of the code into a try/finally and unlock at the end | 19:23 |
| jam | unless you will be writing to it | 19:23 |
| barry | jam: nope, i'm just reading from it | 19:23 |
| barry | jam: is where is lock_read() and how do i unlock? | 19:23 |
| jam | barry: lock_read() basically sets the lifetime for caching | 19:23 |
| jam | branch.lock_read() | 19:24 |
| jam | branch.unlock)( | 19:24 |
| jam | branch.unlock() | 19:24 |
| barry | jam: super, thanks! let me try that... | 19:24 |
| jam | so if you did "for x in range(10): branch.last_revision()" | 19:24 |
| jam | if it is locked, we read the remote file 1 time | 19:24 |
| jam | if it isn't | 19:24 |
| jam | we read it 10 times | 19:24 |
| jam | we used to have more of our api have @needs_read_lock() which auto-locked for us | 19:24 |
| jam | but that ends up just letting people write things that perform poorly | 19:25 |
| jam | because it doesn't maintain the cache | 19:25 |
| jam | between calls | 19:25 |
| barry | jam: that makes sense | 19:25 |
| jam | note that the lock_read() calls have always been supported | 19:26 |
| jam | so it works with older bzr versions | 19:26 |
| barry | jam: excellent, i was going to ask about that | 19:26 |
| jam | we just weren't as likely to complain when you didn't | 19:26 |
| barry | jam: so i was getting away with things by being lazy :) | 19:26 |
| barry | AttributeError: 'BzrBranch6' object has no attribute 'lock' | 19:27 |
| barry | 19:27 | |
| fullermd | Laziness is a virtue. | 19:27 |
| barry | jam: am i doing the right thing by calling .lock() on the first item in the tuple returned by Branch.open_containing() ? | 19:28 |
| jam | barry: 'lock_read()' | 19:28 |
| jam | (vs lock_write()) | 19:28 |
| jam | not just "lock()" | 19:28 |
| barry | jam: gah! i r an idiot | 19:28 |
| ronny | bw, what is lock() | 19:28 |
| jam | ronny: there is no plain 'lock()' | 19:29 |
| jam | hence the 'AttributeError" | 19:29 |
| ronny | oh, i see | 19:29 |
| ronny | i suppose i could use some rest | 19:29 |
| barry | jam: thanks! worked like a charm | 19:37 |
| jam | barry: great to hear | 19:38 |
| Stavros | hello | 20:00 |
| Stavros | how do you guys debug bzr? | 20:00 |
| Stavros | which debugger do you use? | 20:07 |
| luks | I guess most people just print some debug info, or use pdb.set_trace() | 20:08 |
| Stavros | luks: i tried pdb, but it crashes bzr | 20:09 |
| garyvdm | stavros: pastebin the error | 20:16 |
| Stavros | http://dpaste.com/98287/ | 20:16 |
| garyvdm | stavros: I use komodo, but I can't get it to break on raise, so then I use pdb. | 20:17 |
| Stavros | garyvdm: how do you get komodo to start debugging? a breakpoint will work, but i couldn't get it to work | 20:17 |
| garyvdm | stavros: set break point, run with bzr as the script. | 20:18 |
| Stavros | garyvdm: tried that, no dice :/ | 20:19 |
| garyvdm | stavros: run bzr --version from komodo, and make sure the bzrlib is where you think it is. | 20:19 |
| Stavros | let me try again | 20:19 |
| Stavros | ah, let me try that | 20:19 |
| garyvdm | stavros: what is bdb? Have you tried with pdb? | 20:19 |
| Stavros | ah, version does run | 20:20 |
| Stavros | garyvdm: i was trying with pdb, no idea what bdb is | 20:20 |
| Stavros | oh, debugging worked now | 20:21 |
| Stavros | odd | 20:21 |
| Stavros | what the hell, it worked in the debugger | 20:25 |
| Stavros | damn, i hate nondeterminism in programs | 20:25 |
| Stavros | who is the maintainer of bzr-git? | 20:35 |
| fullermd | No, who's on first. | 20:37 |
| dsuch | Martin Torvalds? | 20:37 |
| dsuch | sorry, couldn't resist :) | 20:37 |
| garyvdm | Stavros: I believe jelmer is the author and maintainer of bzr-git. | 20:45 |
| garyvdm | dsuch - Took me a while to catch that... | 20:45 |
| Stavros | ah, he's away :/ | 20:46 |
| fullermd | Yeah, you might THINK that... that's how he catches you. | 20:46 |
| Stavros | haha | 20:47 |
| Stavros | i think i've gotten pretty far with the debugging | 20:47 |
| Stavros | unfortunately, i have no clue what i'm doing | 20:47 |
| Stavros | so i need his help | 20:47 |
| Stavros | i have to go now, though | 20:48 |
| Stavros | later all | 20:48 |
| Stavros | thanks for your help | 20:48 |
| der| | hello, when you use bzr revert, it generates some files like x.~1~, etc. Is there a bzr command that removes those ? | 21:10 |
| jderose | der|: bzr clean-tree --detritus | 21:11 |
| jderose | see bzr help clean-tree | 21:11 |
| der| | jderose, got it, thanks | 21:11 |
| jderose | np | 21:11 |
| Meths | Also bzr revert --no-backup so they aren't created in the first place | 21:16 |
| vila | garyvdm: do you have pqm access ? | 21:16 |
| jderose | Meths: hmm, i didn't know about that option, nice | 21:16 |
| garyvdm | vila: No. I believe I need to ask lifeless, with a gpg key. | 21:17 |
| vila | garyvdm: send him a mail then and welcome :) | 21:18 |
| vila | fullermd: nasty comment on that bug :D Afraid we can forgot ? | 21:19 |
| garyvdm | vila: I'm confused by what you said. | 21:23 |
| vila | garyvdm: let's talk to clarify that, I ahd enough misunderstandings today ;) | 21:24 |
| awilkins1 | Bah, bzr-explorer things lightweight checkouts are their parent branch | 21:29 |
| fullermd | Hm? What bug? | 21:30 |
| fullermd | Oh, you mean the checkout thing? | 21:31 |
| vila | fullermd: yup :D | 21:32 |
| vila | fullermd: at least it seems I didn't say anything wronger :D | 21:32 |
| garyvdm | vila: I just started on a threaded version of qbzr :-0 | 21:33 |
| fullermd | Hm. I didn't mean nasty per se. | 21:33 |
| fullermd | But your statement DID seem a little like it was saying "that's not a bug, that's just how it works". | 21:33 |
| fullermd | The two aren't mututally exclusive :> | 21:33 |
| vila | fullermd: oh, good point, I didn't mean that, thanks for clarifying that | 21:34 |
| vila | In fact I refrain to add that we plan to rework the way checkouts works | 21:35 |
| vila | I refrained | 21:35 |
| vila | work | 21:35 |
| vila | gha | 21:35 |
| fullermd | Tpying is hrad. | 21:35 |
| === JaredWigmore is now known as JaredW | ||
| LarstiQ | but jokes comes easy to the fullermd | 21:37 |
| LarstiQ | or seemingly | 21:37 |
| dsuch | garyvdm: yea, I was visiting launchpad.net/bzr five seconds prior to that | 21:37 |
| fullermd | Yeah, I just wink at 'em and they fall all over me. | 21:38 |
| === kiko is now known as kiko-afk | ||
| === EdwinGrubbs2 is now known as EdwinGrubbs | ||
| jam | 2.0.0-2-setup.exe is available | 22:25 |
| jam | includes updated chm files | 22:25 |
| jam | (2.0.0 docs rather than 2.0rc2 docs.) | 22:25 |
| lifeless | mthaddon: I think it should be fine as long as we stay on 2.4; our advertised support is '2.4' not 'dapper' | 22:54 |
| lifeless | mthaddon: if you could please take a backup of the dapper state, in case we change our mind :P | 22:54 |
| fullermd | lifeless: Hey, I wanted to run something by you... | 22:57 |
| lifeless | poolie: sysadmins would like to move the pqm chroot to hardy; will still be python2.4. I ack'd and asked for a back up in case you disagreed. Do you ? | 22:58 |
| poolie | hi lifeless | 22:58 |
| poolie | good with me | 22:58 |
| poolie | and good timing too | 22:58 |
| lifeless | mthaddon: don't worry about that backup :P | 22:58 |
| fullermd | Re: bug 430672 (and the dupe filed today) | 22:58 |
| lifeless | poolie: thanks | 22:58 |
| ubottu | Launchpad bug 430672 in bzr "Crash when renaming a directory" [High,Confirmed] https://launchpad.net/bugs/430672 | 22:58 |
| fullermd | This seems pretty easy to trigger, and it leaves you in an ugly state afterward. | 22:59 |
| jam | hi poolie, lifeless | 22:59 |
| jam | I was just about to head out | 22:59 |
| lifeless | hi jam | 22:59 |
| fullermd | I feel like it should probably be made Critical, but I don't feel comfortable making that strong a statement. | 23:00 |
| jam | poolie: bzr-2.0.0-2-setup.exe is available | 23:00 |
| poolie | hi jam, i'm not going to stay on for long either | 23:03 |
| poolie | thanks for the builds | 23:03 |
| lifeless | fullermd: yes | 23:06 |
| lifeless | fullermd: so frequency of impact say it doesn't happen to a large % of our users. | 23:08 |
| lifeless | fullermd: I think its high | 23:08 |
| lifeless | fullermd: does it fail check? | 23:16 |
| poolie | i wondered if anyone would reply about uifactories :) | 23:21 |
| fullermd | No, but it does move the file and then lose track of it. | 23:22 |
| lifeless | recovering from a clean dirstate is easier than a corrupt on | 23:28 |
| lifeless | I think this is very important but straightforward to deal with, with a low incident rate, thus high | 23:28 |
| fullermd | Fair enough. | 23:29 |
| fullermd | (this of course is why I don't permit myself to judge Critical :p) | 23:29 |
| lifeless | fullermd: ;) | 23:47 |
| lifeless | fullermd: one reason to be slightly more careful with critical is that there is confusion about whether it == release-blocker | 23:47 |
| lifeless | its not /labelled/ release-critical; but opinions vary. And expectations too. | 23:48 |
| fullermd | Yah, that's a source of my concern. | 23:49 |
| fullermd | I'm neither doing the work, nor managing the release, so making declarations about work needed for the release is slightly hubristic. | 23:49 |
| fullermd | I mean, even by MY standards. | 23:49 |
| lifeless | but even if it clearly-unambiguously didn't mean 'block' | 23:49 |
| lifeless | I'd still only label this high, by our guidelines | 23:50 |
| zsquareplusc | when i committed after a merge it told something about pending merges in the text below, do i have to do something special now? merging again just says "nothing to do" | 23:53 |
| fullermd | zsquareplusc: No, that's informative; like the list of files, it's tell you what you're committing. | 23:54 |
| zsquareplusc | yup, it's just that "pending merges" that was new for me. | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!