| === jaypipes_mysql is now known as jaypipes | ||
| nefertum | lifeless: in a structure like /repo/tom/feature1/ for example, tom is a branch? or only feature1 ? | 00:07 |
|---|---|---|
| nefertum | i need to create tom/ withg 'bzr init tom' ? | 00:07 |
| LarstiQ | nefertum: both can be, it's more usual to have only feature1/ be the branch though | 00:09 |
| nefertum | LarstiQ: i have the next problem...i have in a machine a repo and in local i've created a new branch that i've just pushed to the server | 00:09 |
| nefertum | but now i don't know if i can get all the content of the repository | 00:10 |
| nefertum | in the remote server the repo is /bazaar, and i've created the branch /bazaar/main | 00:10 |
| nefertum | but if i created /bazaar/feature1 i'd like in the future to get all the repository content in another machine, for example | 00:11 |
| LarstiQ | you mean you want to get all the branches instead of specific ones? | 00:11 |
| nefertum | yes, all the repo tree | 00:12 |
| nefertum | i have to do a checkout? | 00:12 |
| LarstiQ | nefertum: no | 00:12 |
| LarstiQ | nefertum: maybe I don't really understand what your goal is | 00:13 |
| nefertum | like in svn, i can do svn co url/svn/repo/ and this gives me all the repo | 00:14 |
| nefertum | i don't know how to do this in bazaar | 00:14 |
| AmanicA | fwiw, I think you can just copy it | 00:15 |
| LarstiQ | nefertum: in bazaar branches are much more loosely coupled with a repository | 00:17 |
| LarstiQ | (than in subversion) | 00:17 |
| nefertum | aham.. | 00:17 |
| LarstiQ | nefertum: but even in svn, there are usually only a couple of branches you care about, and not the rest | 00:18 |
| nefertum | yes...that's what i've seen | 00:19 |
| Verterok | nefertum: unlike svn, in bzr a repository is just a place to store revisions. you can have standalone branches (without a separate repository) | 00:20 |
| nefertum | Verterok: the idea is that i'd like to have a remote server with a repository and i don't know if i should create it first in the remote machine or push the repository from my local repo... | 00:21 |
| nefertum | basic things i supose... | 00:22 |
| AmanicA | you can just create it on the remote side | 00:22 |
| Verterok | nefertum: first, we should clarify what a repository means :) | 00:22 |
| nefertum | mmmm, well, in bazaar is also my local branches, but i mean about a server that stores the main branches in a project | 00:23 |
| nefertum | so the developers push the changes in it | 00:23 |
| Verterok | nefertum: in that case, as AmanicA said, you can create it in the remote side | 00:24 |
| nefertum | aham... | 00:24 |
| nefertum | ok, but i should create with --no-trees or --trees ? | 00:24 |
| Verterok | nefertum: and probably you would have a local repository in you workstation | 00:25 |
| lifeless | nefertum: if its on a central server, --no-trees | 00:25 |
| AmanicA | I prefer --no-trees on the central server | 00:25 |
| nefertum | yes, actually i have a local repo | 00:25 |
| nefertum | ok, so i can create an empty repo with --no-trees an later push my branches in it? | 00:25 |
| lifeless | nefertum: if its on your workstation, and you want to edit your code inside the repo (rather than doing a checkout), --trees | 00:25 |
| Verterok | nefertum: yeap | 00:26 |
| nefertum | i'll try... | 00:26 |
| mwhudson | i find myself wanting to do cd :this | 00:43 |
| AmanicA | will `bzr cd :this` work ? :) | 00:44 |
| LarstiQ | markh: I recently got a very cryptic bzr-svn message on windows, is there a list somewhere (I looked at http://bazaar-vcs.org/WindowsDownloads and regular Downloads) that mentions what components go into a specific installer release? | 01:10 |
| markh | LarstiQ: not really :( There is a wiki that describes the parts needed, but the version numbers are often stale - eg, bzr-svn is now using svn-1.5.x rather than 1.4.x. | 01:13 |
| LarstiQ | markh: that's exactly what I ran into btw, a "upgrade your Subversion client" message | 01:14 |
| markh | LarstiQ: that wiki page is http://bazaar-vcs.org/WindowsInstall | 01:14 |
| LarstiQ | markh: thanks! | 01:14 |
| markh | I've seen that error on my local svn repos lately too (ie, without bzr-svn) | 01:14 |
| LarstiQ | markh: so the installer has it's own subversion library? | 01:14 |
| markh | yeah | 01:14 |
| LarstiQ | aaah, ok | 01:15 |
| LarstiQ | markh: the problem was that I had a svn 1.5 working copy | 01:15 |
| markh | LarstiQ: you using 1.7 binaries? | 01:15 |
| markh | or 1.6? | 01:15 |
| LarstiQ | markh: and then tried to bzr diff on that, but I guess it must have been with 1.4 | 01:15 |
| LarstiQ | markh: 1.5 | 01:15 |
| markh | 1.6 was built with 1.4 | 01:15 |
| markh | right! | 01:15 |
| markh | 1,7 is built with later libs | 01:15 |
| * LarstiQ nods | 01:15 | |
| LarstiQ | that should fix it in this case then | 01:15 |
| markh | IIUC, 1.5 used the "pysvn" bindings - now bzr-svn uses its own bindings | 01:16 |
| LarstiQ | markh: Would it be possible to detect if TortoiseSvn is installed and use those libraries? | 01:16 |
| LarstiQ | markh: right, but it steel needs an svn library to talk to? | 01:16 |
| LarstiQ | still even | 01:16 |
| markh | it would be a bit of a qa nightmare. But for 1.7 etc, we should be using the latest available anyway... | 01:16 |
| markh | yeah - but what svn library was used was outside the control of bzr-svn - it just relied on whatever pysvn uses. Now things are directly under bzr-svn's control | 01:17 |
| markh | it bundles the full svn runtim | 01:17 |
| LarstiQ | ah ok, so less problems there | 01:17 |
| LarstiQ | markh: the main thing to do I guess is to catch that message thrown by svn and display something that makes more sense to the user | 01:18 |
| LarstiQ | markh: since upgrading Tortoise makes the problem of incompatible working copies worse :) | 01:18 |
| markh | LarstiQ: but IIUC, only old bzr clients will display that message, and its too late to fix them? | 01:19 |
| * LarstiQ will file a bug/patch for that tomorrow | 01:19 | |
| LarstiQ | markh: I'll test it | 01:19 |
| LarstiQ | markh: for svn 1.5, yes. But if I use svn trunk I think I'd get the same message | 01:19 |
| markh | IIUC, the problem is the old version of bzr you have uses old versions of svn libs? And newer TSVN and bzr versions use a later version? | 01:20 |
| LarstiQ | markh: correct | 01:20 |
| markh | LarstiQ: right - so you want to upgrade just the bzr-svn for your old bzr binary? | 01:20 |
| markh | I mean, your old 'svn.exe' copies will no longer work either. All the other tools need an upgrade to work - same with bzr | 01:21 |
| LarstiQ | markh: for my concrete problem, I'll just install bzr 1.7 | 01:21 |
| markh | (fyi, 1.6 uses old svn too - only 1.7 has svn 1.5) | 01:21 |
| LarstiQ | markh: but when the next svn release comes out and is incompatible, there is a window for confusing errors until we can say "use the latest bzr installer, that will work" | 01:22 |
| LarstiQ | markh: ok | 01:22 |
| LarstiQ | markh: so I'd like to nail that confusing message before the next incompatible svn release comes out | 01:22 |
| markh | right. | 01:23 |
| === kiko is now known as kiko-zzz | ||
| lifeless | what-da-fark ? | 01:58 |
| lifeless | bzr: ERROR: No module named chkmap | 01:58 |
| lifeless | You may need to install this Python library separately. | 01:58 |
| mneptok | lifeless: that dependency issue has caused a lot of failed marriages when it crops up while driving | 02:08 |
| poolie | hhe | 02:09 |
| poolie | heh* | 02:09 |
| poolie | spiv, are your around? | 02:09 |
| poolie | you* | 02:09 |
| poolie | typo city | 02:09 |
| mneptok | oh, is that where we're going? i'm pretty sure it's the next left. no need to get the map out ... | 02:10 |
| * mneptok accelerates and turns up the radio | 02:10 | |
| spiv | poolie: yeah | 02:17 |
| poolie | would my comment at the end of https://bugs.edge.launchpad.net/bzr/+bug/260335 be allright? | 02:22 |
| ubottu | Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid] | 02:22 |
| spiv | poolie: that seems ok. We certainly don't want to advise downgrading :) | 02:25 |
| === jaypipes is now known as jaypipes-afk | ||
| poolie | out to lunch, biab | 03:33 |
| jml | I'm pushing a new revision up to a stacked branch and getting a "Revision {...} not present" error. | 04:49 |
| jml | I had just created that branch, did a local commit, and then pushed again. | 04:50 |
| fullermd | board 1 | 04:50 |
| * fullermd twitches. | 04:50 | |
| jml | I get the same thing even if I don't commit :( | 04:53 |
| jml | oh, branchformat6... | 04:53 |
| mwhudson | i guess someone should file a report for that bug :( | 05:01 |
| leo2007 | after upgrading to bzr 1.7, I won't be able to push to a remote ssh repository anymore. Any ideas? | 05:24 |
| lifeless | leo2007: why won't you be able to? | 05:24 |
| leo2007 | lifeless: I've just posted the error here: http://pastebin.com/d7f25357c | 05:39 |
| spiv | markh: see leo2007's traceback | 05:40 |
| markh | thats a new one :) | 05:40 |
| markh | leo2007: do you use putty or ssh? | 05:42 |
| lifeless | leo2007: your use of the future tense was quite confusing :) | 05:42 |
| leo2007 | markh: sorry for my English. I used to be able to push to remote server with version 1.5. But couldn't. I use putty. | 05:43 |
| markh | leo2007: Try setting BZR_SSH=plink and trying again | 05:44 |
| markh | ie, at the cmd-prompt | 05:44 |
| markh | set BZR_SSH=plink<enter> | 05:44 |
| markh | and try again | 05:44 |
| leo2007 | markh: same error | 05:47 |
| markh | hrm - is plink.exe on your path? The traceback shouldn't reference paramiko if putty's plink is being used (I think :) | 05:48 |
| lifeless | markh: paramiko provides our sfp:// implementation, FWIW | 05:48 |
| markh | lifeless: right - sftp:// urls? But ssh+... ones use ssh/putty? | 05:49 |
| markh | hrm | 05:49 |
| * markh thinks he is confused... | 05:50 | |
| markh | putty/ssh only used for auth, not for "remote file-system" work? | 05:50 |
| markh | The windows error message for that error code is the (not very helpful) "'Key not valid for use in specified state." | 05:51 |
| markh | oh | 05:52 |
| markh | I've seen this error before :( | 05:52 |
| leo2007 | The new error is here: http://pastebin.com/d5fe02026 | 05:52 |
| lifeless | markh: if you use bzr+ssh then paramiko shouldn't be needed; but if you use sftp then paramiko gives use the parsing logic, still use putty or whatever for the transport | 05:52 |
| leo2007 | plink is in my path | 05:53 |
| lifeless | poolie: ping | 05:56 |
| lifeless | poolie: I need to decide where to put some tests; you've moved the pack repository specific tests out of test_repository, but these tests I am writing are not really pack specific | 05:57 |
| lifeless | poolie: rather they are the actual format I'm working on specific | 05:57 |
| lifeless | I would have previously put them in test_repository, I'm just not sure why the pack ones got moved out, I'm confused and wondering if I should be doing the same | 05:57 |
| spiv | markh: I vaguely recall a thread or two on the paramiko list about random number sources, perhaps that's related? | 05:58 |
| markh | ah yes, its all coming back to me now :) Its a bug I reported in pycrypto a while back | 05:58 |
| markh | hrmph - the bug was #1343753 at sourceforge, but apparently the project is now managed at launchpad - and there are 20 bugs in total ever reported. It is as if the bugs didn't migrate. | 06:00 |
| markh | so I can't work out the status of the bug in that package at the moment :( | 06:01 |
| markh | a copy of the sourceforge bug message is at http://osdir.com/ml/python.cryptography.cvs/2005-11/msg00000.html | 06:01 |
| leo2007 | so what's the solution? | 06:03 |
| markh | good question :( Use the version you were in the past for now I guess... | 06:04 |
| markh | the bug still exists in pycrypto best I can tell. I guess I better open a new bug. | 06:08 |
| leo2007 | where to get older versions? | 06:09 |
| spiv | leo2007: https://edge.launchpad.net/bzr/+download | 06:11 |
| spiv | (Or just https://launchpad.net/bzr/+download) | 06:11 |
| lifeless | spiv: of pycrypto ? :P | 06:12 |
| poolie | lifeless: (back) | 06:12 |
| spiv | lifeless: I thought it was bundled in the win32 installer? | 06:12 |
| poolie | re test_repository: as i recall, test_repository was just getting too big | 06:13 |
| poolie | and, i think having one file or module per scope of parameterization is probably something good to aim for | 06:14 |
| markh | leo2007: I might be able to get a fix in an hour or so - will you be around? The error doesn't happen everywhere, so having someone to repro it is important... | 06:15 |
| lifeless | poolie: on the former, mmm, possibly. On the latter, I disagree | 06:15 |
| lifeless | poolie: because, it makes choosing to parameterise a heavier task than it should be | 06:16 |
| leo2007 | markh: I'll be around and happy to test | 06:16 |
| poolie | it's (just) over a thousand lines, that's the point where i start wondering if it can easily be split | 06:16 |
| poolie | do you mean that if parameterizing means adding a new file it'll make people not do it? | 06:17 |
| lifeless | poolie: yes | 06:18 |
| lifeless | poolie: jam has complained about the cost already, comparing it to mixins | 06:18 |
| leo2007 | I am restarting my computer. | 06:18 |
| lifeless | poolie: not to mention that we have lots of examples of parameterisation within a single module already | 06:18 |
| poolie | so, my thinking was basically "hm this is getting big; oh, these tests are somewhat logically separate so i'll hive them off" | 06:19 |
| poolie | this is not to say they must always be that way | 06:19 |
| poolie | as i see it the cost is in understanding how to set it up - like that 20-25 line function we looked at yesterday | 06:20 |
| markh | so a recent bug on pycrypto's launchpad page has just been marked "fix committed" - but the points points at some *git* repository! | 06:37 |
| markh | there are 4 bzr branches on launchpad, but none are marked as "trunk" nor owned by the project itself. I'm really not sure *where* the trunk is! | 06:38 |
| spiv | markh: the homepage linked from launchpad.net/pycrypto does list a git branch, so I guess that is the current trunk. | 06:45 |
| markh | right - so the "problem" seems to be a new maintainer. The most recent version looks like it came from amk's launchpad branch | 06:48 |
| vila | hi all | 06:57 |
| spiv | vila: good afternoon | 07:01 |
| markh | leo2007: grab http://starship.python.net/crew/mhammond/Crypto.Util.winrandom.pyd and replace the existing copy of that file in the bzr directory with the new copy (take a copy of the old one first though!) | 07:12 |
| chandlerc | jelmer: i have a self-contained local reproduction now. | 07:16 |
| === jfroy is now known as BahamutZERO | ||
| spiv | vila: thanks for that review | 07:19 |
| === BahamutZERO is now known as jfroy | ||
| chandlerc | jelmer: this is the weirdest crash i've seen in a long time | 07:26 |
| markh | leo2007: any joy? | 07:31 |
| vila | spiv: thanks for yours :) | 07:35 |
| chandlerc | anyone want to try and reproduce bug #276219 with the tarball i posted? | 07:36 |
| ubottu | Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219 | 07:37 |
| chandlerc | just wanna make sure i've done enough for others to reproduce, and it reproduces it on my machine, but that's hardly a good sample | 07:37 |
| leo2007 | markh: I will test it in a minute. | 07:46 |
| leo2007 | markh: need to reinstall version 1.u | 07:46 |
| leo2007 | s/1.u/1.7/ | 07:46 |
| poolie | spiv/lifeless: re your comment on bug 260335 - we're still issuing this error about Repository.get_parent_map in 1.8pre | 08:05 |
| ubottu | Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid] https://launchpad.net/bugs/260335 | 08:05 |
| poolie | jml, are you still here? | 08:11 |
| jml | poolie: yes. | 08:14 |
| spiv | poolie: you mean when the client is 1.8pre? What version is the server? | 08:14 |
| poolie | so jml said that error still occurs if you use 1.5 against a 1.6 server | 08:15 |
| poolie | the error seems to be issued from inside get_parent_map | 08:15 |
| poolie | did we really remove that, and if so why is the client still trying to call it? | 08:15 |
| poolie | and, kind of related to that, the conclusion the client draws if its unsupported is that the server is older than 1.2 | 08:16 |
| poolie | so if what was said in that bug is correct, maybe the other code is wrong? | 08:16 |
| AfC | Any idea why the signature tab of bzr-gtk's visualize would say "Revision committer is not the same as the signer." for all the revisions for which I just did `sign-my-commits`? | 08:19 |
| spiv | I'm confused. The error in that bug will be emitted by 1.5 against a 1.6 server because the streaming pull verb (Repository.stream_revision_chunked) was removed as fallout of the versionedfiles work. | 08:19 |
| spiv | I don't see anything in that bug talking about get_parent_map or get_revision_graph? | 08:19 |
| poolie | ok i might just be confused... | 08:20 |
| lifeless | poolie: the guy that filed it is running 1.5 | 08:21 |
| lifeless | poolie: he says 'i want to run whats in debian stable' or something like that | 08:21 |
| lifeless | in other news, I've written a dumb CHKMap | 08:23 |
| lifeless | and am fixing repository so it can work with a CHKMapInventory | 08:23 |
| jml | poolie: was here something you wanted in particular? | 08:24 |
| poolie | jml, i was just going to ask you about your comment on that bug | 08:24 |
| spiv | AfC: maybe it's verifying that the committer ID (i.e. the 'bzr whoami' of the committer) matches an ID on the GPG key that signed it? | 08:24 |
| poolie | but it's fine | 08:24 |
| * spiv -> yoga | 08:24 | |
| jml | ok :) | 08:24 |
| AfC | spiv: not sure. Have a happy downwards dog. | 08:29 |
| poolie | afc, that would be my guess too that it's used the wrong userid | 08:34 |
| poolie | does it show which one did sign it? | 08:34 |
| AfC | poolie: yeah, it does | 08:34 |
| AfC | poolie: and it notes that that one is ultimately trusted | 08:34 |
| poolie | but is it the same as the committer userid? | 08:34 |
| AfC | um | 08:35 |
| AfC | huh? | 08:35 |
| AfC | I'm not really sure what you're asking. I issued `bzr sign-my-commits` and it chugged away for a while. | 08:35 |
| poolie | so | 08:35 |
| poolie | you said that bzr-gtk complains that "revision committer is not the same as the signer" | 08:35 |
| poolie | and i'm wondering if they are actually different, or if it's just misunderstanding them | 08:36 |
| AfC | poolie: that's what it's saying | 08:36 |
| poolie | and if they are different, in what way they're wrong | 08:36 |
| AfC | poolie: I'd assume so | 08:36 |
| poolie | but does it show you which key was used to sign it? | 08:36 |
| AfC | Yes its does. | 08:36 |
| AfC | I mean, it could only have identified what key to use to sign what commits if sign-my-commits made the correlation. So is bzr-gtk not using the same logic maybe? | 08:37 |
| poolie | that's what i'm wondering | 08:37 |
| AfC | Yes its does -> mine | 08:37 |
| AfC | [This is in the category of "I'd file a bug if I knew I wasn't doing something wrong and if I knew what to report"] | 08:39 |
| poolie | could it be that your gpg key does not have a uid for precisely the same address that was used to make the commits? | 08:40 |
| AfC | Hm. | 08:41 |
| AfC | Yes, I guess that's the case. | 08:41 |
| AfC | bzr whoami : Andrew Cowie <andrew@operationaldynamics.com> | 08:41 |
| AfC | gpg --fingerprint ... : uid Andrew Frederick Cowie <andrew@operationaldynamics.com> | 08:42 |
| AfC | So, like, the fact that `sign-my-commits` figured out what key to use is sorta damning as far as `visualize` is concerned, right? | 08:42 |
| poolie | well, they should be consistent with each other | 08:45 |
| AfC | Or, put the other way, how on earth did `sign-my-commits` know what to use if it is going to be so pedantic as to try and match the stuff outside the email address? | 08:45 |
| AfC | yeah | 08:45 |
| poolie | i'd be inclined to say that sign-my-commits should complain if there's no key that corresponds to your committer address | 08:45 |
| lifeless | AfC: gpg has a default key for signing | 08:45 |
| AfC | Well, it's too late now. The testaments are made, and I'm sure not about to change my key. | 08:45 |
| AfC | lifeless: ah, yes, I have that set. | 08:46 |
| AfC | poolie: (though I point out that there IS a key that corresponds to my committer _email_ address. I had assumed that was what it looked up until Robert pointed out that maybe gpg did the default thing) | 08:47 |
| luks | AfC: well, it shouldn't sign somebody else's revisions with your key | 08:49 |
| AfC | I would hope not :) | 08:50 |
| luks | and as far as gpg is concerned, the uid was different so technically it's somebody else | 08:50 |
| * luks would report a bug against bzr sign-my-commits | 08:50 | |
| AfC | {shrug} | 08:50 |
| * AfC hopes sign-my-commits keeps doing what it's doing, actually. | 08:50 | |
| AfC | otherwise I won't be able to use it anymore. | 08:50 |
| luks | you can have multiple uids on your key, can't you? | 08:51 |
| poolie | so, there is a separate key (not uid) that it's used instead? | 08:51 |
| AfC | luks: I've worked hard not to pollute my key. I'll keep it that way, thanks. | 08:52 |
| luks | ok | 08:52 |
| AfC | poolie: no, I only have one uid on one key. | 08:52 |
| AfC | poolie: the email address of the uid matches `whoami` | 08:52 |
| AfC | Huh. My key is back into the top 100. How about that. Can't say as I've been doing _that_ many signings lately. I guess a bunch of keys must have expired. | 08:56 |
| poolie | afc, and it's the same uid as on the revisions? | 08:56 |
| AfC | poolie: `bzr vis` reports key 57F6E7BD was used to sign the revisions. That is indeed me. Judging by what flew by when I ran `bzr sign-my-commits`, I'd say that my key was in fact used to sign, correlating what visualize is saying. | 08:58 |
| AfC | poolie: The only crink in the works is that something is not recognizing that 57F6E7BD is me (or, more to the point, the same person as "Andrew Cowie <andrew@operationaldynamics.com>") | 08:59 |
| poolie | ok, so it seems like there's a bug in bzr-gtk displaying that warning when in fact the key does correspond to the author | 08:59 |
| sabdfl | when bzr tries to delete a directory during a merge or pull, it baulks if the directory is not empty | 09:56 |
| sabdfl | does it factor in whether or not the files in question are "ignored"? | 09:56 |
| poolie | sabdfl: i think so; if not that would be a bug | 09:58 |
| poolie | hi btw | 09:58 |
| sabdfl | howdy! | 09:59 |
| arnarl | hi, we have a branch where a binary directory (about 30M) has been checked in (a while back) which makes the whole thing much larger than it needs to be. Is there any surgery I can do that drops this directory from the history and the branch? | 10:03 |
| arnarl | (it is not a public branch) | 10:03 |
| poolie | arnarl: you can use launchpad.net/bzr-rebase to make a new history in which "that never happened" | 10:03 |
| poolie | but carrying across your later commits | 10:04 |
| poolie | you'll have to get everyone to restart their work based on that branch | 10:04 |
| arnarl | poolis: sounds great | 10:04 |
| arnarl | what do you mean by restart? | 10:04 |
| arnarl | check it out again? | 10:04 |
| poolie | yes, | 10:04 |
| arnarl | ah, that shouldn't be a problem | 10:04 |
| arnarl | poolie: thnx | 10:04 |
| lllama | Hello all. I'm trying to "bzr init" in an existing directory and I'm getting an error saying "No repository present". Any idea what I'm doing wrong? | 10:24 |
| poolie | lllama: what does 'bzr info' show there? | 10:27 |
| AfC | lllama: what version of Bazaar are you running? | 10:27 |
| lllama | poolie: Same error | 10:32 |
| lllama | AfC: 1.6.1 | 10:32 |
| AfC | lllama: that's certainly reasonably recent. | 10:33 |
| poolie | is there a traceback? | 10:33 |
| AfC | lllama: is there a .bzr directory in any parent directory above where you are trying to `bzr init` | 10:33 |
| AfC | lllama: ? | 10:33 |
| lllama | poolie: Nope. Just a "bzr: ERROR" line. | 10:33 |
| lllama | AfC: checking.... | 10:33 |
| lllama | AfC: Ah. There is. There shouldn't be though. | 10:34 |
| lllama | If I do a bzr st in the parent then I get told it's not a branch. | 10:34 |
| lllama | same with info. | 10:35 |
| lllama | I'll try moving the .bzr dir out of the parent and see what breaks... | 10:36 |
| lllama | Hm. Same error. I think I'll try a big clean out. | 10:38 |
| poolie | lllama: if pain persists can you look in ~/.bzr.log, see if there's a traceback at the end, and put it in answers.launchpad.net/bzr | 10:40 |
| leo2007 | markh: sorry I won't be able to test the new BZR. | 10:43 |
| lllama | poolie: will do. Thanks for the help. | 10:43 |
| === kiko-zzz is now known as kiko | ||
| === Ng_ is now known as Ng | ||
| zrg_needsjob | Folks, i got bzr-synchronized dev and live setups of php app. Problem is, there are certain parts of few configuration files that have to differ on those installations, but leaving those files entirely out is not a good solution. I was wondering if there was way to mark part of file to be "ignored" by bzr, or how is such situation best handled? | 11:56 |
| james_w | zrg_needsjob: that's not possible | 11:57 |
| james_w | zrg_needsjob: the usual ways are to have a .local file which is included in to the main one, if possible with the format | 11:58 |
| james_w | zrg_needsjob: or have a .template which is copied and customised in each branch | 11:58 |
| zrg_needsjob | james_w: including unfortunately not possible but would be good solution, what do you mean by template? | 12:00 |
| bob2 | zrg_needsjob: can you just merge only one way? | 12:01 |
| james_w | zrg_needsjob: the same file basically, but with blanks for the passwords or whatever. When you make a new branch you copy the file and make any changes necessary. It's a pain to update the common bits then though | 12:02 |
| zrg_needsjob | bob_2: there are occasional changes in live setup too that have to be backported and actually now i have 2 dev setups. they all use same remote repository, so commits and updates go whichever way. | 12:04 |
| === jamesh_ is now known as jamesh | ||
| zrg_needsjob | ignore blocks would be cool feature tho i think :) | 12:06 |
| uws | does trac-bzr work with trac 0.11? | 12:21 |
| thrope | is it possible to get colored difs with bzr? | 12:52 |
| Odd_Bloke | thrope: Yes, look at the cdiff command in bzrtools. | 12:52 |
| thrope | Odd_Bloke: great - had it installed just didnt know the command, thanks | 12:54 |
| === jaypipes-afk is now known as jaypipes | ||
| === kiko is now known as kiko-phone | ||
| nosklo | hi people | 13:51 |
| nosklo | when using bzr-svn, how does one specify the username to authenticate? | 13:52 |
| LarstiQ | nosklo: http://user@host/svn/... is one way | 13:52 |
| trotek | LarstiQ: is there another? :) | 13:55 |
| LarstiQ | trotek: yes, but it depends on what you are trying to do | 13:56 |
| nosklo | when I do it. It segfaults :( | 13:56 |
| nosklo | bzr-svn just segfaults, no traceback. http://dpaste.com/81664/ | 14:00 |
| === kiko-phone is now known as kiko | ||
| jelmer | nosklo, what version of bzr-svn? | 14:07 |
| === thunderstruck is now known as gnomefreak | ||
| nosklo | jelmer, bzr 1.3.1, bzr-svn 0.4.9 | 14:08 |
| nosklo | jelmer, ubuntu default | 14:08 |
| jelmer | nosklo, 0.4.13 should work better | 14:08 |
| nosklo | jelmer, okay. updating. | 14:09 |
| awilkins | Heh, mercurial still can't cut it for my use case | 14:36 |
| awilkins | It still goes "boink" on long paths with lots of caps in them | 14:36 |
| fullermd | They're getting way ahead of us. bzr still doesn't even have a prototype "boink" feature :| | 14:38 |
| luks | I'll try to make a plugin | 14:38 |
| awilkins | I think I'd prefer "boink" to be written in Erlang, not Python | 14:39 |
| awilkins | That way you can work on other implementations of "boink" and replace them at runtime without interfering with other instances | 14:39 |
| awilkins | Although doesn't stackless Python achieve that also? | 14:39 |
| Odd_Bloke | Quick, let's rewrite bzr in Erlang. | 14:39 |
| fullermd | True. We could be the only VCS on the planet that supports massively-parallel boinking. | 14:39 |
| Odd_Bloke | Only then can it be truly distributed version control. | 14:40 |
| jam | sabdfl, poolie: We don not factor in if the files are ignored. We don't know if they are ignored because they are private (your secret passwords) or because they are junk (your .pyc cruft) | 14:40 |
| jam | so when we delete a directory, it must be fully empty | 14:40 |
| LeoNerd | "boink" ? | 14:41 |
| jam | it is an open bug that we want to solve | 14:41 |
| jam | I think we were talking about putting things in a "lost+found" or something like that | 14:41 |
| === thunderstruck is now known as gnomefreak | ||
| === toytoy_ is now known as toytoy | ||
| === thunderstruck is now known as gnomefreak | ||
| === jaypipes_mysql is now known as jaypipes | ||
| * fullermd contemplates being left in a darkened room with `log -v` and a blunt object. | 15:55 | |
| fullermd | Gaah. Stupid inability-to-refer-to-historical-files bug! | 15:57 |
| * fullermd stabbies. | 15:57 | |
| Pieter | fix it | 16:00 |
| davidmac | I have had many clients that have asked the following question with many vcs's, any idea how to do with bzr? Q: How do I export *only* the files changed since the last revision or a specific revision? | 16:01 |
| davidmac | The idea is they only want to push the smallest set of changes when version production-type deployments. | 16:02 |
| LarstiQ | davidmac: use bzr-upload? | 16:02 |
| fullermd | You could wrap a little scripting around 'stat' to do it, I s'pose. | 16:03 |
| fullermd | Or just use bzr diff | patch | 16:03 |
| fullermd | Or what LarstiQ said. Depends on just what's involved in the deployment. | 16:03 |
| davidmac | hmmm. I'll check into that. I don't think diff is the answer they want. I'll explain deployment... | 16:03 |
| davidmac | Just an example: They version production which has a lot of binaries: executables, images, etc. on linux and it is very large to do a full export from stage to prode. They only want to export the changed binaries so they can zip them up and send them from stage. | 16:04 |
| davidmac | I'm new to bzr so I'll check in to bzr-upload and stat. | 16:05 |
| LarstiQ | 'zip them up and send them from staging', is there some difficulty in getting something to production? | 16:06 |
| davidmac | Yes, in many cases. This specific client has that case. They are in a hosting environment where they can make changes in dev and stage, but have to provide a tgz file when pushing to prod. | 16:07 |
| fullermd | How does that handle deletions or moves? | 16:07 |
| davidmac | Ops team doesn't want them sending the entire 2 gig file every time, just the changes files. | 16:07 |
| davidmac | It doesn't handle deletions and moves, pretty problematic as I see it. I'm encouraging them to use bzr in production too to export a tagged build. | 16:08 |
| davidmac | I was thinking as a temporary workaround, since they have control of stage, they could just do a find -mtime type of approach to create a zip. | 16:09 |
| fullermd | Anyway, wrapping some scripting around 'stat' to figure out what to export is probably the easiest way to work up a tarball. Still won't do well at moves, or at all at deletions. Dunno how you could do that easily. shar, maybe. | 16:10 |
| davidmac | thx | 16:10 |
| fullermd | You can use bzr stat -rx..y to see what files were touched between those revs, and go from there. | 16:10 |
| davidmac | very kewl fullermd, I'll check that out | 16:10 |
| davidmac | One more piece of advice I need, then I'll leave you guys alone :) | 16:10 |
| fullermd | (for scriptability, especially see stat -S) | 16:11 |
| davidmac | This is the logical description of what they want to do: They have a program.cfg config file for dev, same name but different contents for dev, also for prod. How would you recommend they do an export and get only the correct config file in each environment? | 16:12 |
| davidmac | They have done this with clearcase filters before. | 16:12 |
| fullermd | Well, I do similar things by having a dev.conf and a live.conf under version control, and just choose which is applied in each case by a symlink. Whether that's an option in your environment... | 16:13 |
| davidmac | k, anything is an option at this point, just looking for inputs in case there is some elegant semi-automatic way to do it in bzr. | 16:14 |
| fullermd | Not really. What's versioned is what's versioned. You could have the contents of the files be different in different branches, but that would take careful manual maintenance merging between them. | 16:15 |
| fullermd | I find it easier to just have the separate files, and have the program load a "conf.conf" or something that's a symlink to one or the other. | 16:15 |
| fullermd | (it also means I can craft up custom conf.conf files for certain places to have different settings, without having to worry about them being local changes not to commit) | 16:16 |
| davidmac | Okay, thanks. And thanks for all your help. I like what I've seen so far of bzr, so much that I'll probably start hacking some plugins or scripts myself, and maybe a ulipad integration :) | 16:16 |
| davidmac | y'all have a good one! | 16:18 |
| === thunderstruck is now known as gnomefreak | ||
| Verterok | º | 16:44 |
| Verterok | ups | 16:44 |
| thrope | hi - I am using bzr-svn in what I think it the recommended way - I have a checkout of my svn trunk, which I branch to do work, then merge updates, then merge into my bazaar checkout and commit to svn | 16:48 |
| thrope | this is working great - it is really nice to be able to work with subversion in this way | 16:48 |
| thrope | but I loose all the information about the commits in the branch - in subversion I just see the merge commit | 16:48 |
| Odd_Bloke | thrope: Check out the 'rebase' plugin. | 16:49 |
| thrope | I wondered if there is a better way of working - or perhaps a bazaar plugin to automatically propograte the commit message with some infromation about the seperate commits. | 16:49 |
| thrope | Odd_Bloke: I have the rebase plugin - but I must admit I have some trouble understanding what it does | 16:49 |
| thrope | Odd_Bloke: do you mean I should rebase my trunk bzr checkout before comitting | 16:50 |
| Odd_Bloke | thrope: I'm not entirely sure myself, I don't use it. But you should 'rebase' your branch onto the trunk. | 16:50 |
| thrope | no - you mean rebase my branch to the trunk checkout before merging (then I could push in theory) back and committing to svn | 16:50 |
| Odd_Bloke | thrope: Yes. | 16:51 |
| Odd_Bloke | That essentially throws away the commits in your branch and creates new, similar ones based on a different revision. | 16:51 |
| thrope | right I think I get it | 16:51 |
| Odd_Bloke | Which is fine, so long as you haven't branched from the commits that are being thrown away. | 16:52 |
| thrope | I didn't want that initially because it's nice to have the branch structure in my bzr trunk, but I loose it in svn. If I do the rebase, I have all the commits in svn (and my bzr trunk) but I loose the branch structure in my trunk | 16:52 |
| Odd_Bloke | thrope: Why are you using SVN? | 16:53 |
| Odd_Bloke | You could perhaps push your branches to SVN branches... | 16:53 |
| Odd_Bloke | jelmer will know better. | 16:53 |
| thrope | partly habit, got all my stuff in there at the moment, partly because it's easier to work with other people and has nice things like viewvcs | 16:53 |
| Odd_Bloke | thrope: For the latter, have you seen Loggerhead? | 16:54 |
| thrope | also I didn't quite figure out how to have a central bazaar repo that works like svn - I work on a lot of different machines and use svn to keep them in sync | 16:54 |
| LarstiQ | thrope: bzr-snv will set the meta data so at least the bzr revisions will be known, even if you only see the merge commit in svn | 16:54 |
| thrope | ok | 16:54 |
| jelmer | you can set push-merged-revisions in newer versions of bzr-svn | 16:54 |
| Odd_Bloke | LarstiQ: But the bzr revisions won't be pulled into a new branch, you'll get ghosts, right? | 16:54 |
| jelmer | and it'll push the merged revisions as well, not just the mainline | 16:54 |
| Odd_Bloke | jelmer: So, to answer my own question, 'no'? | 16:55 |
| LarstiQ | Odd_Bloke: right, but you could distribute your bzr branch for other bzr users to pull from, or apparently set push-merged-revisions ;) | 16:55 |
| thrope | Odd_Bloke: I had a look at loggerhead and will try and install it - but it wasn't clear to me how to run a centralised bzr branch on a remote server... If I understand to update I need to merge 'into' that central branch to maintain the mainline - which would require logging onto the server... I couldn't see anyway to push a merge and resolve conflicts remotely | 16:56 |
| Odd_Bloke | thrope: The way to do it is to keep a pristine copy of the branch locally. | 16:57 |
| Odd_Bloke | So you merge into the pristine copy and push from there. | 16:57 |
| Odd_Bloke | thrope: If you've been doing that and it hasn't been working, something's going wrong somewhere along the line. | 16:58 |
| thrope | Odd_Bloke: no I haven't really tried because everythings in svn at the moment anyway... I will have a look though | 16:59 |
| thrope | jelmer: where do I set push-merged-revisions? | 17:00 |
| jelmer | thrope, in ~/.bazaar/subversion.conf for the relevant repository | 17:01 |
| thrope | ok thanks | 17:01 |
| jelmer | thrope: s/push-merged-revisions/push_merged_revisions/ | 17:01 |
| === kiko is now known as kiko-fud | ||
| alejandro_ | hey, I have a question about the eclipse plugin | 17:37 |
| Verterok | alejandro_: shoot :) (I'll try to answer) | 17:38 |
| alejandro_ | I just installed the plugin using the update site | 17:39 |
| Verterok | alejandro_: ok, did you installed the bzr-xmloutput plugin? | 17:40 |
| alejandro_ | and in the preference/configuration dialog I get "invalid command 'xmlversion'" | 17:40 |
| alejandro_ | yes | 17:40 |
| alejandro_ | 0.8 | 17:40 |
| Verterok | alejandro_: which OS? windows? | 17:40 |
| alejandro_ | ubuntu | 17:40 |
| Verterok | alejandro_: from a terminal, try: bzr -Derror xmlversion | 17:41 |
| Verterok | alejandro_: it seems that the xmloutput plugin is not correctly installed | 17:41 |
| alejandro_ | I just dropped it at $HOME/.bazaar/plugins and ran setup.py build_ext -i | 17:43 |
| alejandro_ | should that produce any output? | 17:43 |
| Verterok | alejandro_: the plugin must be installed as xmloutput, not bzr-xmloutput | 17:44 |
| Verterok | bzr-xmloutput is an invalid name for a python module | 17:44 |
| alejandro_ | oh, that could be | 17:45 |
| Verterok | alejandro_: also the setup.py step is not neccesary :). it's a pure python plugin | 17:45 |
| alejandro_ | great, it works now. Thanks a lot | 17:48 |
| thrope | jelmer: is there anywhere I can find info on the format of subversion.conf - how to specify repositories etc. | 17:48 |
| Verterok | alejandro_: np | 17:51 |
| aantn | hello | 17:57 |
| aantn | is it possible to set bzr to automatically ignore certain files with bzr add? | 17:57 |
| LarstiQ | aantn: bzr add will ignore files that match patterns, see `bzr ignore` | 17:58 |
| aantn | LarstiQ: I know | 17:58 |
| aantn | I'd like to set it to always ignore two or three files of my choice | 17:58 |
| LarstiQ | aantn: ok, then I don't understand your question? | 17:58 |
| LarstiQ | aantn: ah, globally, and not on a per branch basis? | 17:59 |
| aantn | LarstiQ: no, just per branch | 17:59 |
| * LarstiQ swings back to not understanding the question | 17:59 | |
| aantn | LarstiQ: sorry, never mind | 17:59 |
| aantn | LarstiQ: I misread your initial answer. Thanks :) | 18:00 |
| LarstiQ | aantn: ah, ok :) | 18:00 |
| === doomster__ is now known as doomster | ||
| === mw____ is now known as mw|food | ||
| thrope | I had to leave earlier - does anyone know where I can get some info on the format of the subversion.conf file for bzr-svn? | 18:34 |
| sharms | If I did a bzr co on a remote branch, how can I make that checkout be the master instead? | 18:53 |
| justizin | hi folks, i downloaded the bzr 1.7 installer for leopard, but the only bzr i can find is in /usr/local/bin, from macports.. | 18:53 |
| LarstiQ | justizin: are you sure it's from macports? | 18:54 |
| LarstiQ | justizin: as that is also the location the .dmg uses afaik | 18:54 |
| === kiko-fud is now known as kiko | ||
| LarstiQ | sharms: `bzr unbind` will make the checkout into a regular branch. Do you also want to switch the remote branch to be a checkout of your local one? In that case, do a `bzr bind path/to/new/master` | 18:55 |
| sharms | thanks! | 18:55 |
| thrope | justizin: macports normally uses /opt/local | 18:55 |
| justizin | LarstiQ: FYI, its' an FHS violation. | 18:55 |
| justizin | i have something in /usr/local, but yah, it's probably overwritten without consent. ;) | 18:55 |
| LarstiQ | justizin: FHS, on OSX? | 18:55 |
| justizin | FHS is not Linux, it's UNIX | 18:55 |
| justizin | if you use OSX's installer facilities, it's like using rpm, which counts as "vendor installed", and goes in /usr | 18:56 |
| LarstiQ | justizin: All I know is that the .dmg switched from /usr/bin to /usr/local/bin | 18:56 |
| justizin | right on, good to know, it's a pain in the ass because it's not on path, and yes, whether anyone cares, it's an FHS violation | 18:56 |
| * justizin memorized the FHS in high school | 18:56 | |
| LarstiQ | justizin: you'll have to take it up with someone who actually knows anything about it to know why though | 18:56 |
| justizin | thanks for the heads up | 18:56 |
| justizin | yeh | 18:56 |
| justizin | they wont want to hear it | 18:57 |
| * justizin symlinks | 18:57 | |
| justizin | :) | 18:57 |
| LarstiQ | ookay | 18:57 |
| Keltia | uh, FHS is not really a UNIX thing, it started as a pure linux thingy and some people tried to extend it to others but it has never really taken off outside linux | 18:59 |
| * Keltia goes back to lurk mode | 18:59 | |
| === kiko is now known as kiko-phone | ||
| Odd_Bloke | Yeah, but people who use free software on the Macs feel they have to make up their inferiority somehow. ;) | 19:00 |
| === Spaz is now known as Kittens | ||
| Keltia | Odd_Bloke: I'm one of them :) | 19:25 |
| Odd_Bloke | Keltia: :D | 19:36 |
| === mw|food is now known as mw | ||
| komputes | If I see a file that is part of a bzr branch, is there a simple way that I can track down who added that specific file? | 19:53 |
| fullermd | log it and keep scrolling back? | 19:53 |
| fullermd | (or log --forward it and don't scroll, of course) | 19:54 |
| Peng_ | "log --forward -l 1" maybe? | 19:58 |
| === bac is now known as bac_afk | ||
| === kiko-phone is now known as kiko | ||
| guilhembi_ | jam: hi! I wonder if you saw this: today when I "make" bzr.dev (linux gcc), I get lots of compiler warnings, and the resulting bzr segfaults on simple "bzr branch" (no problem if no "make"); no problem with bzr-1.7-rc1. | 20:31 |
| jam | guilhembi_: hmmm. I certainly haven't seen that | 20:32 |
| guilhembi_ | I re-tried with a fresh branch of bzr.dev, same problem. Seems to have been recently introduced... | 20:32 |
| jam | are you on 64-bit or 32 bit | 20:32 |
| guilhembi_ | jam: 32; I'm diff-ing some c files like _btree_serializer_c.c (lots of warnings), | 20:33 |
| guilhembi_ | and it's really different between bzr.dev and 1.7.1-rc1: | 20:33 |
| jam | guilhembi_: so my *guess* is an issue with Py_ssize_t and int, but 32-bit shouldn't matter | 20:33 |
| guilhembi_ | for example, 1.7.1-rc1 starts with | 20:33 |
| guilhembi_ | Generated by Pyrex 0.9.6.4 | 20:33 |
| guilhembi_ | and bzr.dev starts with Generated by Pyrex 0.9.4.1 | 20:33 |
| jam | well, that is *your* pyrex version | 20:34 |
| guilhembi_ | then lots of code difference in this C file. | 20:34 |
| jam | I tend to build with 0.9.8 | 20:34 |
| jam | guilhembi_: but it is generated from the _btree_serializer_pyx.pyx | 20:34 |
| guilhembi_ | But still, I had no issue the previous time I did "make" in bzr.dev, which was only a few weeks ago... | 20:34 |
| === mvo_ is now known as mvo | ||
| jam | guilhembi_: sure, I'll email you a "current" form for all of them, and see if that fixes it | 20:37 |
| jam | we certainly could have done something that broke pyrex 0.9.4 | 20:37 |
| Peng_ | Hmm, I'm on 0.9.51a-1 without problems. | 20:38 |
| Peng_ | 5.1* | 20:38 |
| jam | guilhembi_: also, btree_serializer shouldn't be the problem, as I doubt you are using a btree repo yet | 20:43 |
| guilhembi_ | jam: other files give lots of warnings: | 20:43 |
| guilhembi_ | bzrlib/_knit_load_data_c.c | 20:43 |
| guilhembi_ | bzrlib/_dirstate_helpers_c.c | 20:43 |
| guilhembi_ | bzrlib/_readdir_pyx.c | 20:43 |
| guilhembi_ | eof | 20:43 |
| guilhembi_ | jam: I'll just upgrade my pyrex | 20:44 |
| guilhembi_ | and see if it helps | 20:44 |
| jam | just make sure you "make clean" first | 20:46 |
| guilhembi_ | yes | 20:46 |
| guilhembi_ | jam: that's funny: "make clean" does not remove bzrlib/_btree_serializer_c.c | 20:47 |
| guilhembi_ | shouldn't it? | 20:47 |
| jam | yeah, it is just hard to do arbitrarily, as we have some .c files that need to be kept | 20:48 |
| guilhembi_ | jam: ok, so better re-branch... | 20:48 |
| jam | guilhembi_: well "rm bzrlib/*.c ; bzr revert" works, too | 20:48 |
| Peng_ | Or bzrtools's clean-tree command may help | 20:49 |
| guilhembi_ | jam: ok, my too old pyrex was the cause, sorry for eating your time | 20:49 |
| jam | guilhembi_: not really, we still need to know what we did | 20:50 |
| jam | because unless necessary | 20:50 |
| jam | we'd like to support older versions | 20:50 |
| stefanlsd | Is it safe to delete obsolete_packs | 20:50 |
| jam | stefanlsd: not the directory, but everything *in* the directory, yes | 20:51 |
| jam | bbiab, need to reboot | 20:51 |
| stefanlsd | jam: k. thanks | 20:51 |
| mwhudson | beuno: have you looked at the loggerhead breadcrumbs bug? | 20:56 |
| Peng_ | Which bug? | 20:57 |
| mwhudson | the same one | 20:57 |
| mwhudson | abadger1999 has been having fun | 20:57 |
| Peng_ | Oh | 20:57 |
| beuno | mwhudson, not yet. Do you have a number handy? | 20:57 |
| abadger1999 | mwhudson: heh. "fun" heh. | 20:57 |
| abadger1999 | :-) | 20:57 |
| mwhudson | beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/268867 | 20:58 |
| ubottu | Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,In progress] | 20:58 |
| jam | guilhembi_: We might just open a bug about bzr.dev not supporting pyrex 0.9.4, but if you could include any of the errors, .c files, etc it would be helpful | 20:58 |
| beuno | mwhudson, I merged that into trunk already | 20:59 |
| guilhembi_ | jam: where should I put the errors? | 20:59 |
| beuno | mwhudson, https://code.edge.launchpad.net/~toshio/loggerhead/breadcrumb | 20:59 |
| mwhudson | beuno: um, there is more | 20:59 |
| jam | guilhembi_: well, as attachments when possible | 20:59 |
| beuno | mwhudson, ah? sorry, didn't look into it that deep | 21:00 |
| guilhembi_ | jam: ok if you open the bug report, I'll attach my errors. Or do you want me to open the bug report? | 21:00 |
| mwhudson | well, abadger1999 commented yesterday complaining about r227 | 21:00 |
| jam | either way, I don't have much to go on from my side, though | 21:00 |
| abadger1999 | mwhudson: Yeah. the original branch that was merged fixed things for start-loggerhead and my mod_wsgi script. | 21:01 |
| beuno | mwhudson, ah, I see. | 21:01 |
| mwhudson | abadger1999: does https://code.edge.launchpad.net/~toshio/loggerhead/mod_wsgi fix the problems you've been having? | 21:01 |
| abadger1999 | mwhudson: But by r227, those were broken and only serve-branches worked. | 21:01 |
| abadger1999 | mwhudson: yes... I'm toshio :-) | 21:02 |
| beuno | ah! hi abadger1999! :) | 21:02 |
| beuno | thanks for the fixes | 21:02 |
| mwhudson | abadger1999: yes, i've figured that much out :) | 21:02 |
| abadger1999 | beuno: No problems :-) | 21:02 |
| * beuno re-assigns the bug to abadger1999 | 21:03 | |
| mwhudson | AmanicA: thankks for the python2.4 branch :) | 21:03 |
| abadger1999 | hah :-) | 21:03 |
| * beuno is *very* happy to see Loggerhead getting more and more contributions | 21:03 | |
| abadger1999 | Ugh. | 21:05 |
| === jfroy|work is now known as jfroy | ||
| abadger1999 | okay, that branch doesn't fix my problems because I pushed mod_wsgi code to it. | 21:06 |
| guilhembi_ | jam: https://bugs.launchpad.net/bzr/+bug/276868 | 21:06 |
| abadger1999 | which has a merge to trunk at some point | 21:06 |
| ubottu | Launchpad bug 276868 in bzr "bzr.dev does not support pyrex 0.9.4.1" [Undecided,New] | 21:06 |
| abadger1999 | So here's the relevant line in what was the branch: | 21:08 |
| abadger1999 | <tal:block repeat="crumb directory_breadcrumbs"><span tal:condition="not:repeat/crumb/start">/</span><a tal:attributes="href python:url([crumb['suffix']])" tal:content="crumb/dir_name" /></tal:block> | 21:08 |
| abadger1999 | specifically: href python:url([crumb['suffix']])" | 21:08 |
| abadger1999 | mwhudson: But at some point after my branch was merged you commited a change with this: href python:static_url('/'+crumb['path'])" | 21:10 |
| AmanicA | mwhudson cool | 21:11 |
| abadger1999 | the comment is: "fix breadcrumbs, maybe" | 21:11 |
| mwhudson | abadger1999: ah yes | 21:11 |
| mwhudson | hmm | 21:11 |
| abadger1999 | I don't know TAL very well (first exposure to it) so I don't know what the practical difference is. | 21:12 |
| mwhudson | i'm not sure that breadcrumbs make much sense when using start-loggerhead ... | 21:12 |
| abadger1999 | Hmm... That could be. | 21:12 |
| mwhudson | i guess i should write myself a loggerhead.conf and see what happens | 21:12 |
| jam | guilhembi_: thanks for reporting it. I wish there was more info. But I believe 0.9.4 could easily cause compiler warnings, so that isn't a strictly obvious problem. | 21:13 |
| jam | stuff like the "declared static but not used" I remember being in older versions of pyrex | 21:13 |
| abadger1999 | mwhudson: Here's mine for reference: http://toshio.fedorapeople.org/loggerhead.conf | 21:14 |
| abadger1999 | I've been playing with server.webpath. Normally it's uncommented. | 21:14 |
| Peng_ | Yeah, I get a lot of warnings with 0.9.5.whatever, but no actual problems. | 21:15 |
| guilhembi_ | jam: if this bzr.dev/pyrex cannot be fixed, maybe one can add something like "require pyrex_version >=x.y.z" to "make". | 21:23 |
| guilhembi_ | opensuse 10.2 is from end of 2006, upgrading pyrex is imaginable. | 21:24 |
| guilhembi_ | (that's my distro). | 21:24 |
| jam | guilhembi_: well, we try to support back to python2.4, so whatever was around in that era | 21:25 |
| jam | though for *packaged* versions | 21:25 |
| jam | we always bundle the .c files directly | 21:25 |
| jam | so it doesn't matter what version of pyrex you have | 21:25 |
| guilhembi_ | jam: so, maybe: | 21:26 |
| guilhembi_ | "if .c file is missing, require pyrex_version >=x.y.z" in "make"... | 21:26 |
| guilhembi_ | if someone uses bzr.dev he may/should accept having recent tools, I believe we require that in MySQL. | 21:27 |
| guilhembi_ | we do for m4/automake/autoconf. | 21:27 |
| jam | guilhembi_: do you still have access to the older code? | 21:27 |
| jam | I'm curious what you would get with | 21:27 |
| mwhudson | hm, a url like http://localhost:8080/None/static/images/ico_branch.gif seems suspicious :) | 21:27 |
| jam | bzr revert -r 3731 | 21:28 |
| jam | as one of the last changes is: | 21:28 |
| jam | 3732 Canonical.com Patch Queue Manager2008-09-24 [merge] | 21:28 |
| jam | (robertc) Allow C extensions to build on python2.4 with older pyrex | 21:28 |
| jam | versions. (Robert Collins) | 21:28 |
| jam | guilhembi_: what version, btw, 0.9.4, or 0.9.4.1? | 21:30 |
| jam | and what version of python? | 21:31 |
| * mwhudson stabs ff | 21:31 | |
| guilhembi_ | jam: | 21:31 |
| guilhembi_ | Python 2.5 (r25:51908, Nov 27 2006, 19:14:46) | 21:32 |
| guilhembi_ | pyrex was 0.9.4.1-25 | 21:32 |
| guilhembi_ | but I upgraded it, I don't have it around, I can see to restore it... | 21:32 |
| jam | well, I don't know Suse's packaging system very well anymore | 21:32 |
| jam | you *could* rm /usr/lib/python2.5/site-packages/Pyrex and then install from scratch, but I'll try doing that here first | 21:33 |
| guilhembi_ | jam: wait, I started | 21:34 |
| guilhembi_ | removed 0.9.8, reinstalling 0.9.4.1... | 21:34 |
| jam | wow, *lots* of exceptions with 0.9.4 and python2.4 | 21:35 |
| stefanlsd | how can drop a commit revision? i tried revert, but not exactly what i want. | 21:36 |
| guilhembi_ | jam: "bzr branch -r3731" still warnings and segfault | 21:36 |
| jam | just a sec, I'll give you another node to check | 21:37 |
| Peng_ | stefanlsd: If you want to remove the most recent revision(s) from history, use "bzr uncommit". | 21:37 |
| jam | you say that 1.7 series works | 21:37 |
| guilhembi_ | jam: 1.7.1-rc1 yes | 21:37 |
| guilhembi_ | jam: but 1.7 source package! | 21:37 |
| jam | sure | 21:37 |
| guilhembi_ | which has the .c built with canonical's pyrex, more recent than mine. | 21:37 |
| stefanlsd | Peng_: thanks. that was it | 21:37 |
| jam | but haven't you been using bzr.dev for a while? | 21:37 |
| jam | or you just haven't done 'make' in a while? | 21:38 |
| jam | well, *my* compile issues for 2.4 were because of a missing Python.h :) | 21:39 |
| jam | no wonder it wasn't working | 21:39 |
| guilhembi_ | jam: I hadn't done "make" since a few weeks. | 21:40 |
| jam | k, I still have some thoughts | 21:41 |
| guilhembi_ | jam: wait | 21:41 |
| guilhembi_ | jam: I read wrongly: | 21:42 |
| guilhembi_ | with -r3731, warnings but no segfault | 21:42 |
| jam | guilhembi_: so there is still a question, did the extensions actually *build* correctly | 21:44 |
| jam | do you have all of the .so files that we might expect | 21:44 |
| guilhembi_ | jam: wait | 21:44 |
| guilhembi_ | with -r3731, warnings but no segfault | 21:44 |
| jam | it is possible it doesn't segfault because it doesn't finish compiling | 21:44 |
| guilhembi_ | with -r3757, warnings but segfault | 21:44 |
| guilhembi_ | s/but/and/ .I'm doing dichotomy | 21:44 |
| jam | bisection, I would say :) | 21:45 |
| guilhembi_ | from the messages, it finishes compiling | 21:45 |
| mwhudson | abadger1999: um | 21:45 |
| guilhembi_ | mmm in my maths lessons, "dichotomie" (in French) was looking at a and b, then (a+b)/2 and (a or b), etc. | 21:45 |
| abadger1999 | mwhudson: yes. | 21:45 |
| guilhembi_ | 3732 is ok | 21:46 |
| mwhudson | abadger1999: your rearrangement of interpreting the 'potential_overrides' values from the config file is broken | 21:46 |
| guilhembi_ | 3745 broken, continuing | 21:46 |
| abadger1999 | mwhudson: k. I nthe latest mod_wsgi branch? | 21:46 |
| jam | well 3738 is suspicious | 21:47 |
| mwhudson | value = keytype(config.get(key, default)) | 21:47 |
| mwhudson | if value is not None: | 21:47 |
| mwhudson | parsed_conf[key] = keytype(value) | 21:47 |
| jam | 3739 is too | 21:47 |
| guilhembi_ | jam: 3738 ok | 21:47 |
| mwhudson | if keytype is str and default is None... | 21:47 |
| guilhembi_ | 3741 broken | 21:47 |
| guilhembi_ | 3739 broken | 21:48 |
| === thrope_ is now known as thrope | ||
| guilhembi_ | jam: 3739 introduced the problem. | 21:48 |
| guilhembi_ | the segfault. | 21:48 |
| jam | yeah, that was a big code drop | 21:49 |
| abadger1999 | Yeah... that's broke. | 21:49 |
| * abadger1999 looks at what was there before | 21:50 | |
| jam | guilhembi_: so... new code breaks older compiler. Not entirely surprising :) | 21:51 |
| jam | I just wish we had more to go on as to *why* the segfault occurs | 21:51 |
| jam | I'll see if I can reproduce here | 21:51 |
| jam | and maybe I can get a gdb traceback | 21:51 |
| jam | crap | 21:52 |
| jam | it seems you can't have multiple versions of pyrex installed side-by-side | 21:52 |
| abadger1999 | value = config.get(key, default) | 21:52 |
| abadger1999 | if value is not None: | 21:52 |
| abadger1999 | parsed_conf[key] = keytype(value) | 21:52 |
| jam | there is only one /usr/bin/pyrexc | 21:52 |
| abadger1999 | mwhudson: That better? ^ | 21:52 |
| mwhudson | abadger1999: maybe | 21:53 |
| mwhudson | value = config.get(key) | 21:53 |
| mwhudson | if value is not None: | 21:53 |
| mwhudson | parsed_conf[key] = keytype(value) | 21:53 |
| mwhudson | else: | 21:53 |
| mwhudson | parsed_conf[key] = default | 21:53 |
| mwhudson | ? | 21:53 |
| abadger1999 | mwhudson: That works. I might do keytype(default) as well... it shouldn't hurt if default is already an int or a str | 21:55 |
| abadger1999 | but it will protect us if someone set '10' instead of 10. | 21:56 |
| abadger1999 | (OTHOH, it might break on non-simple types.) | 21:56 |
| mwhudson | i don't think it's worth worrying about being very generic here | 21:56 |
| abadger1999 | k. | 21:56 |
| jam | guilhembi_: segfault :) | 21:56 |
| jam | Segfault at bzrlib/_dirstate_helpers_c.c:7785 | 21:57 |
| lifeless | moin | 21:58 |
| jam | lifeless: morning. Seems that the compiled iter_changes breaks on pyrex 0.9.4 with a segfault | 21:58 |
| mwhudson | abadger1999: can you commit/push that change, then i'll get back to digging? | 21:58 |
| lifeless | jam: fun | 21:58 |
| jam | anyway, I'll be back in a few minutes | 21:58 |
| abadger1999 | k | 21:58 |
| jam | lifeless: it works fine with pyrex 0.9.6 and 0.9.8 | 21:58 |
| jam | So i'm trying to figure if it is a simple fix | 21:58 |
| jam | or if we just make a dependency for running from source | 21:59 |
| lifeless | jam: hmm, isn't dapper 0.9.4 anyhow?, if so it worked on pqm ... | 21:59 |
| guilhembi_ | jam: ok, it seems you have good insight now, I'll head to bed. | 21:59 |
| lifeless | no, feisty has it though | 22:00 |
| jam | lifeless: I was able to reproduce it with a local install and some creative PATH settings, so I'll poke at it for a while | 22:01 |
| abadger1999 | mwhudson: Which branch are you pulling from? | 22:01 |
| mwhudson | abadger1999: ~toshio/loggerhead/mod_wsgi | 22:02 |
| thumper | are there any pre-canned presentations about bzr that I can pillage for a 15 minute talk I'm giving to a PUG? | 22:02 |
| abadger1999 | mwhudson: Cool. It's pushed. | 22:02 |
| lifeless | thumper: PUG? | 22:03 |
| beuno | thumper, http://bazaar-vcs.org/Talks | 22:03 |
| thumper | lifeless: python user group | 22:03 |
| lifeless | oh lol :P | 22:03 |
| thumper | beuno: thanks | 22:03 |
| lifeless | clearly I've been playing too much wow - I was thinking 'pick up group?' surely not. | 22:04 |
| thumper | lol | 22:05 |
| jfroy | What is the proper way to install Bazaar plugins system-wide? I'm having an issue where on a stock Leopard system, easy_install bzr bzr-svn results in a functional bzr install, a successful installation of bzr-svn, but the plugin doesn't get found (e.g. there are no load failures either, it's just not found). | 22:41 |
| lifeless | jfroy: wherever 'python -c import bzrlib.plugins; print bzrlib.plugins.__path__' | 22:42 |
| lifeless | jfroy: is where they should go; I'm not sure on the right way to install bzr-svn though | 22:43 |
| === `6og is now known as Kamping_Kaiser | ||
| jfroy | Ah, it seems bzr-svn doesn't install itself properly, or rather this is probably a setuptools issue | 22:44 |
| nosklo | I checked out a svn repository by using bzr checkout. Made a small change in a file, and now I want to commit. Repository uses simple http auth on apache. Why doesn't it work? It works fine with svn. | 22:44 |
| lifeless | mwhudson_: are you aware of any downsides to putting a proxy object in sys.modules? | 22:44 |
| jfroy | ls -l /Library/Python/2.5/site-packages/bzr_svn-0.4.13-py2.5-macosx-10.5-i386.egg/ | 22:44 |
| jfroy | drwxr-xr-x 3 root admin 102 Oct 1 14:30 bzrlib | 22:44 |
| === mwhudson_ is now known as mwhudson | ||
| jfroy | it installs as an egg | 22:44 |
| mwhudson | lifeless: not really | 22:44 |
| nosklo | it never asked for my password http://dpaste.com/81778/ | 22:44 |
| jfroy | (And so does bzr: /Library/Python/2.5/site-packages/bzr-1.7.1rc1-py2.5-macosx-10.5-i386.egg/bzrlib/plugins) | 22:45 |
| jfroy | Although bzr seems to be smart enough to add site-packages/bzrlib/plugins to its plugin import path as well | 22:45 |
| lifeless | nosklo: have you read te FAQ I think it talks about auth | 22:46 |
| jfroy | In general, is it recommend to use easy_install for plugins (apparently there are issues), or should one generally download them and run the standard setup.py (that may not even address the issue). | 22:46 |
| lifeless | jfroy: I am of the 'easy install is a broken concept' school; other than digging into what-why-and-how of eggs to decide I really do dislike them, I don't ever use the egg-and-related facilities | 22:47 |
| lifeless | jfroy: thus my recommendation will always be to use bzr's setup.py, and ditto bzr-svn's setup.py | 22:48 |
| nosklo | lifeless, hmm, can you point me to it? is it this faq http://samba.org/~jelmer/bzr-svn/FAQ.html here? can't find it. | 22:48 |
| jam | lifeless: so... as near as I can tell it is just a buggy pyrex that would be really hard to work around | 22:48 |
| jam | (for the 'fails with pyrex 1.4.1 stuff) | 22:48 |
| lifeless | patches from users of easy_install are welcome, as long as they don't degrade support for non-easy-install environments | 22:48 |
| jam | It is re-using a variable | 22:48 |
| jfroy | lifeless: noted. I will agree with you there are issues with setuptools, but easy_install is truly useful as a Python package manager of sort. Until a better solution is developed... | 22:48 |
| jam | and sometimes setting "pointer = 0" and using PY_XDECREF | 22:48 |
| jam | and sometimes using PY_DECREF | 22:49 |
| lifeless | jfroy: macosX? fink|maxports|the packaged bzr installer | 22:49 |
| jam | and it is failing because it is using PY_DECREF when it should be using PY_XDECREF | 22:49 |
| lifeless | jam: uhg | 22:49 |
| jfroy | Just this morning, I had to hack some of the guts of setuptools because its zip unarchiver didn't restore UNIX mode bits when installing an egg, and I had UNIX executables as package data that wouldn't run after installation (obviously) | 22:49 |
| lifeless | nosklo: oh, its changed; uhm | 22:50 |
| jam | lifeless: so I get the feeling that if we want to support 1.4.1, we just need to create smaller functios | 22:50 |
| lifeless | jelmer: ^ haaalp | 22:50 |
| jam | functions | 22:50 |
| lifeless | jam: 1.4.1 ? | 22:50 |
| jam | lifeless: sorry pyrex 0.9.4.1 | 22:50 |
| lifeless | jam: :P | 22:50 |
| jfroy | lifeless: that's general a good solution; however, unfortunately, there is no easy way to install or manage python packages using MacPorts while using the system's interpreter | 22:50 |
| jam | It seems to just be something it runs into when a function is complex enough | 22:50 |
| lifeless | jam: can we blacklist that version or something? | 22:50 |
| jam | lifeless: sure, we can do it as part of setup.py I believe | 22:51 |
| lifeless | jfroy: oh, ah well | 22:51 |
| jfroy | And I need the system's interpreter because I heavily use PyObjC import packages for system frameworks | 22:51 |
| jam | we can look at Pyrex.Compiler.Version or somesuch | 22:51 |
| jfroy | mmm, it may be a worthwhile idea to see if a bzr install-plugin command / plugin would be useful to assist in installing plugins | 22:52 |
| lifeless | jfroy: ok; well like I say, happy to review patches to work better in that environment; you might like to look at 'bzrlib.plugin' to see how the 'load plugins' code works | 22:52 |
| * jfroy add item to TODO | 22:52 | |
| jam | lifeless: either that, or it is this bugfix | 22:53 |
| jam | - Temporary vars used by del statement not being properly released, sometimes leading to double decrefs. [Jiba] | 22:53 |
| jfroy | lifeless: I think, unfortunately, that it's not a Bazaar issue, but a plugin packaging issue, e.g. I've seen plugins install in various different ways based on weather they use setuptools or plain distutils, and how their setup.py is configured. It's somewhat of a mess... | 22:53 |
| jam | but the "del" statements I see aren't near where it is segfaulting | 22:53 |
| jfroy | *whether | 22:53 |
| lifeless | jfroy: actual install for plugins is really just their setup.py; this works very well in other environments; it *sounds* like failing introspection | 23:03 |
| jfroy | lifeless: yeah it's setuptools' doing. Bazaar just doesn't scan eggs on the path for plugins. The "fix" would be to have bazaar scan every entry in sys.path for "bzrlib-plugins/" as a subdirectory of every entry, making sure that's not an actual package, and then adding that as a plugin import path | 23:13 |
| jfroy | let alone refactoring the plugin code to support importing from potentially a virtual directory, e.g. if the plugin was installed as a zipped egg | 23:14 |
| jfroy | Sounds like a lot of work that's not really worth the trouble :| | 23:14 |
| jam | jfroy: it isn't worth some of our time, but it may be worth it for others | 23:17 |
| jam | if people really need to use setuptools to install everything | 23:17 |
| jfroy | jam: it's not an issue for people comfortable with Python, but in a situation (such as mine) where you'd like to promote adoption of Bazaar, it does help to be able to tell people to just "sudo easy_install bzr bzr-svn ..." | 23:18 |
| jfroy | One liner install instructions are A Good Thing™ | 23:18 |
| jam | jfroy: well, if they have "easy_install" available | 23:19 |
| jfroy | No matter how flawed the underlying install mechanism may be... | 23:19 |
| jam | apt-get install bzr works well here | 23:19 |
| jfroy | jam: quite true... | 23:19 |
| jam | or "start bzr-setup.exe" | 23:19 |
| jam | depending on your platform | 23:19 |
| jfroy | I'm mostly concerned with Mac OS X. MacPorts is certainly viable in a lot of cases. | 23:19 |
| jfroy | But not in mine :( | 23:20 |
| jfroy | I should get in touch with the maintainer of the 10.5 Installer package to help improve it. | 23:22 |
| jam | jfroy: sure, I know I'd certainly appreciate the help in getting things packaged everywhere | 23:36 |
| Verterok | jfroy: I usually build the 10.4 installer, what improvements to recommend? | 23:43 |
| Verterok | ah, mornin' all | 23:43 |
| jfroy | Verterok: I just sent an email to Szilveszter Farkas, I can forward it to you. | 23:44 |
| Verterok | jfroy: that would be nice, I know the installers are a bit different, but I'ld like improve it | 23:45 |
| jfroy | The 10.4 installer actually offers more plugins than the 10.5 one (bundling loom would be nice), but the critical one is bzr-svn (in my case). | 23:45 |
| Verterok | jfroy: right, I'm working to include bzr-svn in the 10.4 installer, but I'm fighting with PackageManager to include both versions (for 1.4.x and 1.5.2) | 23:46 |
| Verterok | jfroy: actually, buidling a mpkg for bzr-svn is quite easy | 23:47 |
| jfroy | The maintainer for the 10.5 package recommends using bdist_mpkg | 23:48 |
| Verterok | jfroy: yeap, I use that. just need to patch the setup.py to use setuptools instead of distutils | 23:49 |
| === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7.1 now available! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| mxpxpod | I'm using bzr-svn version 0.4.13 and I'm trying to branch an svn repo without using svn+ in the URL (since it's deprecated), but when I do that, it tells me that authorization is required... how do I get around that? | 23:52 |
| Verterok | jfroy: and to build it run something like: http://rafb.net/p/qlHJMT35.html | 23:55 |
| jfroy | Verterok: it dies on me, fails to find the nidump command | 23:56 |
| jfroy | looking at the source right now | 23:56 |
| jelmer | mxpxpod, that's a known bug | 23:57 |
| Verterok | jfroy: I have it at /usr/bin/nidump | 23:57 |
| jfroy | That sounds like one of the old netinfo tools | 23:57 |
| mxpxpod | jelmer: any fix? | 23:57 |
| jfroy | Verterok: they're gone on 10.5 :p | 23:57 |
| jelmer | mxpxpod, for now please just use svn+ until that bug is fixed | 23:57 |
| mxpxpod | jelmer: ok, thanks | 23:57 |
| Verterok | jfroy: setuptools is trying ot use it? | 23:58 |
| jelmer | mxpxpod: bug 256612 | 23:58 |
| ubottu | Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612 | 23:58 |
| mxpxpod | jelmer: thank you | 23:58 |
| poolie | hi jelmer, all | 23:58 |
| jfroy | Verterok: it's used by bdist_mpgk.tools.get_gid() | 23:59 |
| jam | poolie: morning. Can you call the house today for the standup? Or my cellphone | 23:59 |
| jelmer | hi poolie, Verterok, jfroy, jam | 23:59 |
| poolie | sure | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
