| lifeless | hi | 00:00 |
|---|---|---|
| uws | Ok, so I'm trying to branch mysql-server/5.1 from launchpad | 00:00 |
| uws | I've set my launchpad login using "bzr lp-login" previously | 00:00 |
| uws | but now the branching fails with a Permission denied (publickey) error message | 00:00 |
| uws | I just want a checkout, nothing fancy. | 00:01 |
| lifeless | uws: its using bzr+ssh | 00:01 |
| uws | so? | 00:01 |
| Jc2k | uws: the lp: foo doesnt know whether your pulling or pushing, so always goes through bzr+ssh | 00:01 |
| lifeless | uws: and your public key is either not registered with lp, or no available to your local ssh | 00:01 |
| uws | note that I'm not involved with mysql, is that a requirement? | 00:02 |
| lifeless | no | 00:02 |
| mwhudson | mkanat: having fun yet? | 00:02 |
| mwhudson | uws: not at all | 00:02 |
| lifeless | uws: 09:01 < lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh | 00:02 |
| uws | mwhudson: I thought it might be trying my login first, and failing in falling back to anonymous checkout. | 00:02 |
| uws | anyway, I'll check my ssh keys\ | 00:02 |
| uws | ah, there we go. Launchpad only knew about my laptop's ssh key | 00:04 |
| uws | thanks | 00:04 |
| mwhudson | cool | 00:05 |
| lifeless | _argh_ evolution | 00:16 |
| awilkins | gcc -version | 00:17 |
| awilkins | oops | 00:17 |
| awilkins | jelmer: Those C extensions are not compiling for me. | 00:19 |
| lifeless | poolie_: I'm going to try to finish stacking-kints today | 00:21 |
| === rockstar_ is now known as rockstar | ||
| jelmer | awilkins: what errors do you get? | 00:25 |
| lifeless | mwhudson: I get | 00:26 |
| lifeless | Firefox has detected that the server is redirecting the request for this address in a way that will never complete. | 00:26 |
| awilkins | initializer element is not constant | 00:26 |
| jelmer | lifeless: Hmm, looks like it's failing to do proper caching in the case of bzr-search | 00:26 |
| lifeless | mwhudson: when trying server-branches | 00:26 |
| jelmer | lifeless: Looking into it further... | 00:26 |
| lifeless | jelmer: thanks | 00:26 |
| lifeless | jelmer: its lock_read'd, and fast on bzr branches | 00:26 |
| mwhudson | lifeless: hm | 00:26 |
| lifeless | 500MB/hour now | 00:26 |
| awilkins | jelmer: core.c (73) ; looks like it doesn't like the sizeof call setting the initial value | 00:26 |
| awilkins | jelmer: This is gcc 3..4.5 | 00:27 |
| mwhudson | lifeless: more details? which directory are you running from, what url are you trying to view? | 00:27 |
| lifeless | mwhudson: http://www.robertcollins.net/ | 00:27 |
| lifeless | mwhudson: I cd'd to that dir on the fs; ran python ~/source/loggerhead/bzr-search.integration/serve-branches.py; | 00:28 |
| lifeless | mwhudson: clicked on config-manager | 00:28 |
| lifeless | (note my html pages are woefully old; ignore that aspect :P) | 00:28 |
| lifeless | config-manager/ has a subdir trunk that is a branch | 00:29 |
| lifeless | config-manager/ is not a repository | 00:29 |
| mwhudson | i wonder if this is dir -> dir/ redirection going strange then | 00:29 |
| poolie_ | lifeless: hi | 00:30 |
| lifeless | the url that it wanted was config-manager/, yes | 00:30 |
| lifeless | poolie_: ho | 00:30 |
| jelmer | awilkins: Hmm, that's an old version | 00:30 |
| jelmer | awilkins: core.c is not there anymore | 00:30 |
| jelmer | awilkins: What branch are you using? | 00:30 |
| awilkins | lp:bzr-svn | 00:30 |
| jelmer | awilkins: the mirror is probably out of date | 00:30 |
| jelmer | http://people.samba.org/bzr/jelmer/bzr-svn/0.4 | 00:31 |
| * awilkins pulls | 00:31 | |
| mwhudson | lifeless: i can't reproduce here | 00:31 |
| mwhudson | lifeless: are there proxies involved or anything? | 00:32 |
| lifeless | http://rafb.net/p/q5BkUZ65.html | 00:33 |
| lifeless | mwhudson: not yet | 00:33 |
| awilkins | jelmer: Darn, more setup.py blues | 00:34 |
| mwhudson | lifeless: paste version? | 00:34 |
| lifeless | feisty | 00:35 |
| mwhudson | lifeless: as in, which version of python-paste | 00:35 |
| mwhudson | hmm | 00:35 |
| awilkins | jelmer: apr-config naturally doesn't run on Windows so I have this awesomely bad patch to make it work :-| | 00:35 |
| lifeless | mwhudson: 1.1.1-1 | 00:35 |
| mwhudson | ok, that's definitely older than what has been tested so far | 00:35 |
| * mwhudson goes to try to find a changelog | 00:35 | |
| lifeless | its on my todo to upgrade | 00:36 |
| lifeless | but, time. | 00:36 |
| mwhudson | yeah | 00:36 |
| awilkins | jelmer: Right, It's too late to hack this into shape, I'll get back to it. Gnight | 00:38 |
| mwhudson | lifeless: changes from 1.1 -> 1.2: | 00:38 |
| mwhudson | * Regression in 1.1 fixed, where Paste's HTTP server would drop | 00:38 |
| mwhudson | trailing slashes from paths. | 00:38 |
| lifeless | mwhudson: fuckers. | 00:39 |
| lifeless | why can't all software have /tests/ | 00:39 |
| mwhudson | like loggerhead, for example... | 00:51 |
| lifeless | mwhudson: this is a bit of a show stopper though ;P | 00:53 |
| mwhudson | lifeless: i don't really have any good ideas | 00:53 |
| lifeless | for starters, document paste 1.1 as fuxored and check it at startup | 00:54 |
| mwhudson | python-paste is pure python, there's a good chance the deb from hardy will install fine i guess | 00:54 |
| lifeless | mwhudson: na-uh, python-central | 00:54 |
| lifeless | mwhudson: pure python doesn't mean what you think it does in a binary distribution world | 00:54 |
| mwhudson | well, perhaps | 00:55 |
| mwhudson | but getting a newer version installed somehow shouldn't be difficult | 00:56 |
| === mark1 is now known as markh | ||
| lifeless | it would be a backport | 00:57 |
| lifeless | I'm not terribly interested in doing that; I'll just not play with loggerhead for a while | 00:58 |
| mwhudson | 'for a while' -- until you get around to dist-upgrade? | 00:58 |
| lifeless | yes | 00:58 |
| lifeless | probably august or so | 00:58 |
| lifeless | doing an adhoc backport is a nuisance; its a local delta, the package manager will try to uninstall it under various circumstances, i need to setup a temp archive, or build it in a ppa | 01:04 |
| mwhudson | well, you could probably just untar a paste release and use PYTHONPATH | 01:05 |
| lifeless | which then becomes a sysadmin thing-to-remember | 01:05 |
| lifeless | and for my home server I want as close to 0 of them as possible | 01:06 |
| lifeless | its not a _high_ burden, but they sum | 01:06 |
| lifeless | and it deifnitely raises the effort past what I'm willing to do to experiment with loggerhead | 01:06 |
| lifeless | - its not 'easy' at this point | 01:07 |
| mwhudson | well, ok | 01:09 |
| lifeless | mwhudson: I guess I should note that having spent days+ of effort on loggerhead for squid-cache.org, I'm not enthused about more time | 01:09 |
| mwhudson | i can't really see anything i can do to help here | 01:09 |
| lifeless | mwhudson: as a consumer of it, its a different feel to a developer | 01:09 |
| lifeless | mwhudson: I don't think there is much to do; I guess loggerhead could in theory ship a fixed paste function and monkey patch affected versions; but thats quite a lot gross | 01:10 |
| mwhudson | gutsy has paste 1.4 that i suspect will work | 01:11 |
| mwhudson | _my_ interest in supporting feisty is not so large | 01:11 |
| lifeless | I have a sinking feeling about freebsd though | 01:11 |
| lifeless | I'm not looking forward to finding out what version it has | 01:12 |
| lifeless | fullermd: feel free to give me good news about now | 01:12 |
| fullermd | [19:12:09] mortis:/usr/ports/www/py-paste (ttyp9):{550}% make -V PORTVERSION | 01:12 |
| fullermd | 1.6 | 01:12 |
| lifeless | ok, thats good news | 01:12 |
| fullermd | It's usually pretty good about being up-to-date on things. It's just the occasional exceptions like TG that really monkeywrench things :| | 01:13 |
| mwhudson | i'd like to monkeywrench tg | 01:13 |
| lifeless | fullermd: to be fair, I suspect that's tg's fault | 01:13 |
| mwhudson | i guess it's not a problem for me any more | 01:13 |
| lifeless | mwhudson: what would it take to make bb not need tg ? :) | 01:13 |
| mwhudson | lifeless: oof | 01:14 |
| mwhudson | don't know, probably quite a bit i guess | 01:14 |
| lifeless | because BB is still not properly operational for squid | 01:14 |
| abentley | lifeless: It would require an alternative identity layer. | 01:21 |
| mkanat | mwhudson: Sorry, was away for a bit there. | 01:21 |
| mkanat | mwhudson: I'm back now, I'll try that patch. | 01:21 |
| lifeless | abentley: thats a tg supplied thing ? | 01:21 |
| abentley | Yes, it handles users, groups, permissions, passwords, that sort of thing. | 01:22 |
| lifeless | k | 01:22 |
| abentley | lifeless: believe me, I've thought about it. | 01:23 |
| lifeless | abentley: :> | 01:23 |
| mkanat | mwhudson: Yep, that does it. I have to make webpath = '', though, not actually comment it out. | 01:24 |
| mwhudson | mkanat: hm, strange, but glad you've got something working | 01:25 |
| Verterok | mornin' | 01:26 |
| mkanat | mwhudson: Without it I get: http://pastebin.ubuntu.com/22252/ | 01:27 |
| mwhudson | mkanat: with this patch? http://pastebin.ubuntu.com/22228/ | 01:28 |
| mkanat | Oh, hmm. | 01:29 |
| mwhudson | but anyway, it works, good :) | 01:30 |
| mkanat | mwhudson: Ah right, when I use teh *actual* patch it works, yes. :-) | 01:30 |
| mkanat | Now let's see if I can figure out what's causing those tracebacks. | 01:31 |
| mkanat | mwhudson: Unfortunately GoogleBot doesn't send referers. :-( | 01:37 |
| mwhudson | mkanat: yeah :/ | 01:37 |
| Verterok | abentley: hi, did you notice the mail/branch about BB on mysql? :-) | 01:38 |
| mwhudson | mkanat: can you see what the file id in the url is for? | 01:38 |
| abentley | Verterok: I see it now. | 01:38 |
| Verterok | abentley: in case you want to migrate it to mysql, I already have the env setup, etc...and I'm willing to do it ;-) | 01:39 |
| abentley | Verterok: I want to migrate to postres | 01:39 |
| Verterok | ups :P | 01:39 |
| mkanat | mwhudson: It's for a file. | 01:39 |
| mwhudson | mkanat: any particular one? | 01:40 |
| Verterok | I can abstract the scripts to have multiple dest. engine | 01:40 |
| mwhudson | or is it a variety? | 01:40 |
| mkanat | mwhudson: It's a variety. | 01:40 |
| mwhudson | hum | 01:40 |
| mkanat | mwhudson: However, they're all in the same branch, which might actually have errors in it, since it was made by cvsps-import. | 01:40 |
| mwhudson | i can't really imagine how a branch could be _this_ broken :) | 01:41 |
| markh | abentley: re that "Trivial UI Change" patch - it seems to me that the 2 strings are actually 2 params - so the spacing was correct in the initial patch | 01:42 |
| mkanat | mwhudson: Hmm, might be a race condition--I can open that URL fine. | 01:42 |
| mwhudson | mkanat: ?? | 01:42 |
| mwhudson | but i thought you said it was a file id for a file? | 01:43 |
| abentley | markh: You're right. I saw what I expected to see, not what was there. | 01:43 |
| mkanat | mwhudson: I picked out one of the URLs that caused a traceback, and when I open it, there's no problem. | 01:43 |
| markh | and while I'm here :) In my case at least, that message really means "your bzr package is missing something that allows you to do successful ssh" - but strangely, the log in that case does mention that the 'ssh implementation is Putty's plink.' | 01:43 |
| markh | if I use a bzr.exe from a binary package, it works correctly | 01:44 |
| mwhudson | mkanat: that's really odd | 01:44 |
| mkanat | mwhudson: Hmm, or something is wrong with logging--my on-disk debug.log contains no tracebacks, I only saw them with -f -- that could be coincidental, though. | 01:44 |
| markh | my bzr is probably not finding paramiko - is there a recommended way to enable debugging messages for that kind of thing? | 01:44 |
| abentley | markh: So the problem is that the orig_error param is being misused. | 01:45 |
| markh | abentley: yes, that that seems true | 01:45 |
| markh | well, that is *a* problem, not *the* problem ;) | 01:46 |
| abentley | markh: There are other problems remaining? | 01:46 |
| mkanat | mwhudson: Well, it's not causing any visible problem anyhow. | 01:47 |
| mwhudson | mkanat: ok | 01:47 |
| markh | well - the original problem was simply the recommendation to "-D..." - thats independent of the orig_error abuse :) | 01:47 |
| markh | A possible remaining problem is that bzr is being less than helpful - the problem appears to be some inability to auth or otherwise do something related to ssh. | 01:47 |
| mkanat | mwhudson: So let's take the one last visible problem that I see--my auto_publish branches have their on-disk path as their bzr URL on the frontpage. | 01:47 |
| mkanat | mwhudson: My non-auto-publish branches have the correct URL. | 01:48 |
| markh | I do see a message "No supported authentication methods left to try!" so putty is trying to do someting | 01:48 |
| mkanat | mwhudson: Because I specified it, of course. | 01:48 |
| markh | but my "connectivity and permissions" are fine (which is what bzr suggests I check) | 01:48 |
| mwhudson | mkanat: this is probably my url_prefix fix being wrong | 01:49 |
| markh | abentley: so even if that isn't really a bug in bzr, any suggestions how I can diagnose what is missing myself? | 01:49 |
| markh | (to be clear - putty etc is all setup fine - it works perfectly if I use 'bzr.exe' instead of a source distro) | 01:51 |
| lifeless | have you tried -Dtransport? | 01:54 |
| markh | hi lifeless - tried nothing yet, still fishing for clues. I'll try it! | 01:54 |
| markh | Output appears identical with -Dtransport | 01:56 |
| markh | log too | 01:56 |
| lifeless | ok | 01:56 |
| lifeless | uhm | 01:56 |
| lifeless | python -c 'import paramiko' | 01:56 |
| markh | yeah, I'm confident that will fail | 01:56 |
| markh | but how could I have bzr tell me that? :) | 01:57 |
| markh | ie, I'm not sure what else I don't know I don't have! | 01:57 |
| abentley | markh: the suggestion to use D... was orig_error abuse. | 01:58 |
| markh | abentley: yeah - I was just saying that the original error was the text itself with is largely independent of the abuse that was uncovered while looking at it | 01:59 |
| mwhudson | mkanat: try this: http://pastebin.ubuntu.com/22255/ | 01:59 |
| markh | as usual, take one bug, get a few for free! | 02:00 |
| abentley | markh: If you want to act clever, that's fine. But I don't need to be involved. | 02:01 |
| markh | abentley: sorry, that wasn't my intent | 02:01 |
| mkanat | mwhudson: Yes, that works! :-) | 02:02 |
| mwhudson | mkanat: cool, i'll commit it then | 02:03 |
| * markh gets back in his box... | 02:03 | |
| abentley | markh: If you want to diagnose why putty can't make a connection, I'd start by running putty. | 02:03 |
| mwhudson | mkanat: i'll try to work on the server.webpath thing too, that's going to take a bit more thinking though i expect | 02:03 |
| markh | putty can connect fine | 02:03 |
| mkanat | mwhudson: No, that works. | 02:04 |
| mkanat | mwhudson: I just had read the patch wrong (I did it manually). | 02:04 |
| abentley | markh: I wasn't even aware that putty could be used for this. I would have thought plink | 02:04 |
| mwhudson | mkanat: i'd like to remain compatible with old loggerhead.conf files | 02:04 |
| mkanat | Ahh. | 02:05 |
| abentley | But I guess the next step would be to find out what line bzr is emitting to connect. | 02:05 |
| markh | yes, putty's plink | 02:05 |
| abentley | So to be clear: plink can connect just fine? | 02:05 |
| markh | yes, plink can connect fine. Putty's pageant is the only program with my ssh key loaded | 02:07 |
| markh | so when bzr.exe successfully does ssh, I expect that is also via plink | 02:08 |
| markh | but when 'python bzr' does not connect via ssh, the bzr log still indicates it is using putty's plink | 02:08 |
| abentley | markh: I wouldn't be surprised if bzr.exe is using paramiko. | 02:09 |
| abentley | bzr can use pagent. | 02:09 |
| markh | yes, which uses plink :) I'm not aware of enough of the internals to know if bzr will attempt to use putty *without* paramiko. I'm not even 100% sure paramiko missing is the problem :) I was hoping to find something that might tell me so I'm not playing a game of trial-and-error is all. | 02:10 |
| lifeless | markh: we use paramiko for sftp logic, not encryption | 02:11 |
| abentley | markh: What makes you say pagent uses plink? I would have assumed that plink uses pagent, not the other way around. | 02:12 |
| markh | I meant paramiko uses plink (or at least it has *some* interaction with putty's suite - it talks to pageant's window iirc) | 02:12 |
| abentley | markh: It interacts directly with pagent AIUI. | 02:13 |
| abentley | It does not have to invoke plink to do it. | 02:13 |
| markh | ok - but I'm confident pageant/plink/putty etc are all configured correctly | 02:14 |
| lifeless | abentley: how does make_mpdiffs returning a dict sound to you? | 02:15 |
| lifeless | abentley: (that or (key, diff) tuples) | 02:15 |
| === timely is now known as timelyx | ||
| abentley | lifeless: I'd prefer key, diff tuples, so the API doesn't demand loading many file versions in memory at once. | 02:17 |
| lifeless | abentley: ok | 02:19 |
| abentley | markh: So you probably want to look at bzrlib.transport.ssh.PLinkSubprocessVendor | 02:19 |
| lifeless | abentley: I won't guarantee to get to it; but it irritated me to have to zip() in bzr-search over the weekend | 02:19 |
| lifeless | abentley: and as we have a massive api break occuring this would be timely | 02:19 |
| abentley | lifeless: If we're breaking the API, maybe it should accept keys instead of revision ids. | 02:22 |
| lifeless | hmm | 02:48 |
| lifeless | poolie_: can I call ? | 02:48 |
| lifeless | hmm EAFTP I guess :P | 02:49 |
| ToyKeeper | What's this? API changes which could reduce memory use? :) | 03:34 |
| ToyKeeper | (last time I did a "bzr branch lp:bzr", it failed until I allocated 200+MiB RAM for it) | 03:34 |
| lifeless | ToyKeeper: heh. I have test cases that chew up 3-4GB of ram | 03:35 |
| ToyKeeper | I finally got around to setting up a bzr server on my openvz host, and was surprised to see branching fail due to memory limits. | 03:41 |
| ToyKeeper | It's easy to bump up the limit, at least. :) | 03:41 |
| beuno | hey mwhudson_ | 03:55 |
| mwhudson_ | hi beuno | 03:55 |
| === mwhudson_ is now known as mwhudson | ||
| beuno | I did notice it. Scratched an itch I had :) | 03:55 |
| beuno | how was your weekend? | 03:55 |
| mwhudson | fine, fine | 03:56 |
| mwhudson | we're moving this week, so lots of packing and tidying | 03:56 |
| beuno | ah, and maybe a better ISP? :) | 03:56 |
| mwhudson | we shall see | 03:56 |
| mwhudson | beuno: i played with the merge proposal stuff in launchpad, you probably got some mails about that | 03:58 |
| beuno | mwhudson, ah, yes. I was about to ask if you really wanted me to review it or it was a proof-of-concept | 03:58 |
| mwhudson | beuno: i'd like you to look at it, yes | 03:58 |
| lifeless | so | 03:59 |
| lifeless | the big thing remaining for gnome seems to be branding? | 03:59 |
| lifeless | Jc2k: ^? | 03:59 |
| beuno | mwhudson, cool. That reminds me, now that I can commit to trunk, how would you like the workflow to be? Commit trivial stuff directly, review bigger changes? Review everything? I don't want to step on any toes :) | 04:00 |
| mwhudson | beuno: i think trivial stuff is ok to push directly, but if in doubt get it reviewed | 04:01 |
| mwhudson | (not necessarily by me, i suppose) | 04:01 |
| Suigintou | anyone have any experience serving a repository over bzr+ssh on a chrooted shell? | 04:01 |
| lifeless | not directly; but in theory yes | 04:02 |
| lifeless | whats up | 04:02 |
| Suigintou | I tried setting it up with jailkit, but bzr doesn't like the new root directory permissions enforced by jailkit (the root dir must be owned by root) | 04:03 |
| lifeless | I don't see why bzr would care about that | 04:03 |
| Suigintou | me neither, hehe | 04:04 |
| lifeless | well, why do you think it is the root dir owner thats the problem? | 04:06 |
| Suigintou | I was getting an error message along those lines in auth.log | 04:06 |
| Verterok | jelmer: around? | 04:07 |
| lifeless | whats auth.log | 04:07 |
| lifeless | its not a bzr file | 04:07 |
| Suigintou | it's the log file that ssh logs error messages to, located in /var/logs | 04:07 |
| Suigintou | er, /var/log | 04:08 |
| beuno | mwhudson, I get OOPS-905EB7 when reviewing your merge request :) | 04:08 |
| lifeless | sounds like ssh is having the problem then | 04:08 |
| mwhudson | beuno: :) | 04:08 |
| lifeless | [I need more detail - I can't guess at what an error message I haven't seen means] | 04:08 |
| beuno | mwhudson, seems it works if I specify the *optional* subject | 04:09 |
| mwhudson | beuno: oh that | 04:09 |
| lifeless | poolie_: ping | 04:09 |
| mwhudson | it's a known bug, to be fixed soon | 04:09 |
| beuno | does this merge automagically? | 04:10 |
| * igc lunch | 04:10 | |
| mwhudson | beuno: no | 04:10 |
| mwhudson | oh, this does remind me | 04:11 |
| mwhudson | serve-branches.py currently just sticks the cache in some temporary directory | 04:11 |
| mwhudson | this probably isn't totally smar | 04:11 |
| mwhudson | t | 04:11 |
| beuno | serve-branches.py doesn't use anything from loggerhead.conf, right? | 04:12 |
| Suigintou | haha | 04:13 |
| Suigintou | now that I'm looking through auth.log, I see that someone has been trying to brute force their way into my server, time to run ssh on a non standard port :) | 04:13 |
| mwhudson | beuno: right | 04:14 |
| beuno | mwhudson, is that out of choice or just "was faster at the time"? | 04:15 |
| mwhudson | beuno: a bit of both, but mostly the former | 04:15 |
| beuno | so the plan is to use something else for configuration? | 04:17 |
| Suigintou | co | 04:17 |
| mwhudson | beuno: you perhaps do me a bit too much credit to assume i have a plan :) | 04:17 |
| beuno | hahaha | 04:18 |
| beuno | I may be still a bit naive, I'll get over it eventually | 04:18 |
| mwhudson | wee | 04:18 |
| mwhudson | well | 04:18 |
| mwhudson | i guess the first thing to decide, in fact, is: what configuration do we actually need? | 04:18 |
| mwhudson | s/we/people/ | 04:19 |
| beuno | what port to run, where to cache, and what to publish, for starters | 04:19 |
| beuno | I suppose then it would get expanded to *what* to cache (search, ie), and new features like exporting tarballs and serving repos | 04:20 |
| mwhudson | proxying details | 04:20 |
| beuno | is there something very wrong about the current conf file? | 04:21 |
| jamesh | maybe it still has some turbogears stink on it | 04:22 |
| mwhudson | i find it's way of listing which branches to show and where in the url hierarchy to show them to be almost entirely bogus | 04:22 |
| mwhudson | i think that's my main complaint | 04:23 |
| mwhudson | and yeah, it's a bit tg-ish | 04:23 |
| beuno | right. I've been avoiding getting into some parts of the new code because I'm not sure where it's headed. Is there some config file you where thinking of making it similar to? | 04:25 |
| mwhudson | no | 04:25 |
| mwhudson | to be honest, the main use cases i've been thinking around are | 04:25 |
| mwhudson | ... | 04:26 |
| beuno | uhm, my X restarted for no apparent reason | 04:27 |
| mwhudson | beuno: wb | 04:27 |
| beuno | L) | 04:27 |
| beuno | so, last I read was what you where thinking of | 04:27 |
| mwhudson | (1) zero configuration (serve-branches.py) | 04:28 |
| mwhudson | (2) Launchpad (custom WSGI glue) | 04:28 |
| mwhudson | i'm less sure of a good answer for a middle ground | 04:28 |
| mwhudson | someone who has a bunch of branches they want to serve using ProxyPass from their site and who doesn't really want to write code | 04:29 |
| beuno | I think that's a bit too drastic. It should be easy to enable/disable certain features, at least if we want to keep building on top of it | 04:31 |
| lifeless | poolie_: whhat do you think; committing against a revision only present in a stacked-on repository; should it delta [always], delta[usual algorithm], never-delta? | 04:32 |
| beuno | adding per-branch configurations seems to me like a normal operation | 04:32 |
| mwhudson | hmm? | 04:32 |
| beuno | (2) Implies coding, right? | 04:32 |
| beuno | tweaking a .py file? | 04:33 |
| mwhudson | i'm not saying that these are the only things we should support | 04:34 |
| mwhudson | but rather that these two cases are where the bulk of my thinking has gone so far | 04:34 |
| beuno | ah, ok. Well, maybe we can work something out on a wiki page or something | 04:34 |
| beuno | zero configuration is good to have, will get people using it faster | 04:35 |
| mwhudson_ | sigh | 04:46 |
| lifeless | mwhudson_: I believe you can buy it in a box | 04:46 |
| beuno | it's a bit odd to get an email for a merge request, and then for a review request | 04:58 |
| beuno | isn't a merge request a review request by itself? | 04:58 |
| igc | reviewing jam's iter_references patch now | 05:03 |
| beuno | mwhudson, LH is misbehaving in LP again. "Please try again" pretty often | 05:03 |
| lifeless | 14:03 < beuno> mwhudson, LH is misbehaving in LP again. "Please try again" pretty often | 05:04 |
| lifeless | mwhudson_: who is your ISP | 05:04 |
| === mwhudson__ is now known as mwhudson | ||
| mwhudson | lifeless: ihug | 05:04 |
| lifeless | oh | 05:05 |
| mwhudson | i think it's problems with the line, but i'm moving in three days | 05:05 |
| lifeless | I don't know that it is :P | 05:05 |
| mwhudson | hm, it's codehosting that's bashing vostok currently | 05:06 |
| mwhudson | beuno: so re bug 240512, i think your change will sort symlinks after directories and files | 05:08 |
| ubottu | Launchpad bug 240512 in loggerhead "Files view should show/sort directories before files" [Medium,In progress] https://launchpad.net/bugs/240512 | 05:08 |
| mwhudson | beuno: is that what we want? | 05:08 |
| mwhudson | beuno: and also, i don't think we want to still put directories first when the user is trying to sort by name | 05:08 |
| lifeless | I don't think we want that | 05:08 |
| jml | So I've been working on a thread in a loom. | 05:09 |
| jml | And I've realised that the top thread should actually be the next-to-bottom thread. | 05:10 |
| lifeless | make a new thread over it it | 05:10 |
| lifeless | merge -r thread:thing..thread: . into it | 05:10 |
| lifeless | commit | 05:10 |
| beuno | mwhudson, well, ideally, no. A more complex ordering way would be better, but I cherrypicked that off my new-theme branch, since it's so ugly to see it ordered as currently. Nautilus orders directories before files by name ordering, so that seemed natural to always have | 05:10 |
| lifeless | combine-thread the one you want to get rid of | 05:10 |
| lifeless | up-thread and commit till its all resolved | 05:10 |
| lifeless | get on wif ur life | 05:11 |
| lifeless | hmm | 05:11 |
| jml | lifeless: that merge will lose my commit history, right? | 05:11 |
| lifeless | actually, I think you need to do a reverse merge too into the one you're removing the change from | 05:11 |
| lifeless | there is a TODO about making this easier | 05:11 |
| lifeless | jml: yes, see under 'its a cherrypicking problem' | 05:11 |
| jml | lifeless: just checking. I'm ok with losing history this time, I think. | 05:12 |
| mwhudson | beuno: well i think that's crazy :) | 05:13 |
| lifeless | I think matching nautilus is ok | 05:13 |
| beuno | mwhudson, all other applications I've fired up do it that way | 05:13 |
| beuno | what kind of ordering is "directories first then"? | 05:13 |
| beuno | as in, how would I go back to it once I order by name? | 05:14 |
| mwhudson | the finder doesn't put folders first :) | 05:14 |
| mwhudson | but i guess i don't care very much | 05:14 |
| beuno | mwhudson, it doesn't order directories first by default? | 05:15 |
| mwhudson | no | 05:15 |
| beuno | and that doesn't feel wrong to you? | 05:16 |
| mwhudson | when you order by name, it put things in ... name order | 05:16 |
| beuno | and how do you go back to ordering by directory-first? | 05:16 |
| mwhudson | i have to admit, i don't use a graphical file browser very much at all on any system | 05:16 |
| mwhudson | beuno: you don't | 05:16 |
| beuno | that's what I was worried about :p | 05:17 |
| poolie_ | lifeless: oh my client had disconnected that's why i didn't see it | 05:24 |
| lifeless | poolie_: ah | 05:24 |
| lifeless | poolie_: you use a irc poxy? | 05:24 |
| poolie_ | ssh to a server | 05:24 |
| poolie_ | running screen | 05:24 |
| thumper | how do I make a thread in a loom between two? | 05:25 |
| thumper | does create-thread make it directly above the current thread? | 05:25 |
| lifeless | yes | 05:25 |
| thumper | ta | 05:26 |
| Peng | With PrefixMiddleware in serve-branches.py, shouldn't there be arguments passed to it? Is it just example code? | 05:28 |
| mwhudson | Peng: no, it works off x-forwarded-server | 05:30 |
| mwhudson | you might need to add a prefix | 05:31 |
| Peng | Oh. | 05:31 |
| Peng | Yeah. | 05:31 |
| Peng | I am using a prefix. | 05:31 |
| mwhudson | then yeah, you need to edit code | 05:31 |
| mwhudson | if you can tell me how you'd like to specify this sort of thing, then i can see what i can do :) | 05:32 |
| Peng | Oh, I dunno. | 05:33 |
| Peng | Maybe just a "prefix = None" line you can edit. | 05:33 |
| Peng | Though, since I need the prefix middleware, I'd probably take out the try...except to force it to error out so I'd see it. | 05:34 |
| * Peng wanders off. 24 is on! | 05:35 | |
| thumper | when I up-thread in a loom, should I commit? | 05:35 |
| thumper | hmm | 05:35 |
| thumper | status seems to indicate I should | 05:35 |
| lifeless | if there were unintegrated changes, yes | 05:36 |
| lifeless | up-thread is 'switch and then merge ' | 05:36 |
| Suigintou | ahh, I fixed my problem with getting bzr+ssh working from a chrooted shell, I forgot to make python available to the shell, lol | 05:36 |
| lifeless | Suigintou: that would cause bzr some trouble, yes. | 05:38 |
| thumper | lifeless: I am quite enjoying my first use of looms-in-anger | 05:38 |
| lifeless | thumper: great | 05:38 |
| * thumper makes note to write about it | 05:38 | |
| igc | looking at spiv's patch re Remote-2 tests now | 05:53 |
| beuno | mwhudson, sorry for the spam on merge-proposals. It confuses me a lot | 06:27 |
| Peng | Hmm, I think the latest changes caused Loggerhead to use more RAM on startup. | 06:45 |
| Jc2k | morning lifeless | 06:46 |
| beuno | Peng, how "latest"? | 06:46 |
| Jc2k | the guadec-web module seemed to choke bzr index - it was at it all night | 06:46 |
| Peng | beuno: trunk as of an hour ago vs. trunk as of...a few hours ago. | 06:46 |
| Peng | r166 vs. r171. | 06:48 |
| beuno | Peng, interesting. Can you revert to 169 and see if the problem persists? | 06:49 |
| lifeless | Jc2k: interesting. how big is that modules .bzr/repository ? | 06:49 |
| Peng | Urgh. | 06:49 |
| Peng | beuno: It used to use 11856 KB. 171 uses 12544 and 169 uses 12244. | 06:52 |
| spiv | igc: thanks for the review | 06:53 |
| igc | spiv: no problem | 06:53 |
| beuno | hrm, so it's not the author bit. mwhudson_, any idea what could of caused the jump since rev166? | 06:53 |
| beuno | maybe urlparser import, but 1mb is quite a jump | 06:54 |
| Peng | This is odd. | 06:55 |
| Peng | 166 is using 12244 too. | 06:55 |
| beuno | did your repos get bigger? | 06:55 |
| Peng | Does Loggerhead end up importing Bazaar's plugins? | 06:55 |
| lifeless | yes | 06:56 |
| lifeless | I don't think it loads them all | 06:56 |
| lifeless | but it will try for ones it uses itself | 06:56 |
| Peng | I upgraded bzr-svn recently.. | 06:57 |
| Peng | Nothing else though, | 06:57 |
| Peng | Anyway, there was still a 300 KB increase between 169 and 171, I think. | 06:57 |
| beuno | it may be due to trying to get the author, if there is one. It may be a fair tradeoff :) | 06:58 |
| beuno | I'm off to bed | 07:00 |
| beuno | g'night everyone | 07:00 |
| Peng | It's right after startup, without any hits. | 07:01 |
| Peng | Good night. :) | 07:01 |
| vila | beuno: don't go to bed yet ! Just send me a quick reply :) | 07:02 |
| Peng | Did someone forget to write a template for the directory index page? | 07:03 |
| beuno | damn! I knew I should of closed the laptop :p | 07:03 |
| Peng | :D | 07:03 |
| beuno | vila, I'll get to it now | 07:03 |
| beuno | Peng, directory index? | 07:04 |
| vila | beuno: great :) | 07:04 |
| beuno | vila, chmod bits? | 07:04 |
| vila | yup, working version already pushed | 07:04 |
| Peng | beuno: Like, when you're outside of a branch, and it just lists directories. http://bzr.mattnordhoff.com/loggerhead/ | 07:04 |
| igc | that's it for me today - off to see a doctor | 07:04 |
| igc | see you all tomorrow | 07:05 |
| beuno | Peng, ah, that's mwhudson_'s black magic. We probably will need to wrap that around a template | 07:06 |
| Peng | loggerhead.apps.filesystem.BranchesFromFileSystemServer.directory_listing | 07:06 |
| beuno | vila, sent | 07:10 |
| * beuno is off | 07:10 | |
| lifeless | bye beuno | 07:11 |
| beuno | Peng, could you file a bug for that | 07:11 |
| lifeless | beuno: also any word on theming for gnome-mirror? | 07:11 |
| Peng | beuno: okay | 07:11 |
| vila | beuno: thanks, sleep well :) | 07:11 |
| Jc2k | lifeless: | 07:12 |
| Jc2k | x469yq@isshin:/srv/bzr/guadec-web/.bzr$ du -s repository/ | 07:12 |
| Jc2k | 338308 repository/ | 07:12 |
| beuno | lifeless, not yet. It turns out that the current theme is a bit sucky to edit. I will get something reasonable in the next few days, if Jc2k can wait that long :) | 07:12 |
| lifeless | beuno: cool | 07:12 |
| * Jc2k can't wait | 07:12 | |
| Peng | Theme of what? | 07:12 |
| lifeless | Jc2k: how many commits is that in ? | 07:13 |
| mwhudson_ | Peng: the directory listing was written at about 1am i think :) | 07:13 |
| lifeless | Jc2k: (bzr revno in the branch you were indexing) | 07:13 |
| Peng | mwhudson_: Heh. | 07:13 |
| Jc2k | lifeless: only 962 | 07:13 |
| lifeless | Peng: loggerhead, for http://bzr-mirror.gnome.org | 07:13 |
| Peng | mwhudson_: Want me to file a bug? | 07:13 |
| Peng | lifeless: Ah. | 07:13 |
| mwhudson_ | yes please | 07:13 |
| Peng | ok | 07:13 |
| Jc2k | lifeless: 964, even. but still. it indexed gtk+ with ease, and just gets stuck with no progress bar on guadec-web. | 07:14 |
| lifeless | so, it was indexing 300MB of content in one go | 07:15 |
| lifeless | Jc2k: try dropping the group count down to 100 | 07:15 |
| lifeless | that will give it 30MB chunks | 07:15 |
| Jc2k | kk | 07:15 |
| lifeless | (roughl) | 07:16 |
| Jc2k | lifeless: not right now, the git stuff is repacking so they can claim its "smaller and more efficient" | 07:16 |
| * Jc2k skuttles off to make an lzma(7z?) repository format for bzr | 07:16 | |
| lifeless | Jc2k: :P | 07:17 |
| Peng | Jc2k: With no fulltexts! | 07:17 |
| Peng | Filed as bug 242270. | 07:17 |
| ubottu | Launchpad bug 242270 in loggerhead "Directory listing page doesn't use a template" [Undecided,New] https://launchpad.net/bugs/242270 | 07:17 |
| lifeless | meh, we will do better on size over time; but I really find it hard to credit that that is a significant objection | 07:17 |
| lifeless | because, its like claiming gnome 1.2 is what gnome should be judged on | 07:17 |
| Jc2k | yeah | 07:18 |
| lifeless | rather than (e.g.) focus on usability, direction, responsiveness | 07:18 |
| Jc2k | you would think that bzr would be GNOMEy | 07:19 |
| Jc2k | i mean it just works | 07:19 |
| Jc2k | if GNOME had as many dials and sharp edges as Git, for example, the HIG people would cry. | 07:20 |
| lifeless | right | 07:20 |
| Jc2k | (actually, someone had the nerve to complain that bzr-gtk could do more to adhere to the hig :P) | 07:20 |
| lifeless | and if you want contributors to a friendly system, I think its reasonable to expect the toolchain to be friendly too | 07:20 |
| lifeless | Jc2k: turn it into a bug :) | 07:20 |
| Jc2k | i think if bzr had rebase -i and the everything-in-one-dir repository format, we could turn a few big names at guadec. | 07:22 |
| Jc2k | regardless of whether they are good ideas or not. | 07:22 |
| lifeless | jelmer: ^ what are your thoughts on -i? | 07:24 |
| lifeless | Jc2k: how hard is -i? | 07:24 |
| Jc2k | lifeless: i dont think too hard. the rebase plugin generates a script - we just need to make the script human readable on the -i path and have actions like edit, squash and kill | 07:25 |
| lifeless | so, | 07:25 |
| Jc2k | lifeless: if you edit though.. you need to be able to commit | 07:25 |
| Jc2k | so you can break a commit up in to pieces | 07:26 |
| lifeless | I'd like to have everything that gnome folk are calling showstoppers filed as bugs | 07:26 |
| lifeless | on the relevant bzr components | 07:26 |
| Jc2k | kk | 07:26 |
| lifeless | if you think its a good idea, also tag them gnome | 07:26 |
| Jc2k | i was just going to say :) | 07:26 |
| lifeless | but if we have the bugs, we can track their acceptance/progress more coherently | 07:26 |
| Jc2k | i have to head off in a bit, first day at codethink woo, but i'll make sure its done before sleepy time | 07:28 |
| lifeless | cool | 07:28 |
| mwhudson_ | Peng: thanks for the bug, but if you think loggerhead's current look is nice and slick i want some of what you're smoking :) | 07:41 |
| Peng | mwhudson_: Hahah. | 07:51 |
| Peng | a | 07:51 |
| Peng | mwhudson_: Want me to change it to "hideous, overcomplicated, bloated and slow"? :) | 07:51 |
| Peng | In all seriousness, I do like Loggerhead's theme. | 07:55 |
| Peng | But, I like hgweb's too. | 07:55 |
| eMBee | good afternoon | 09:08 |
| * eMBee is looking for help on using bzr on an svn repo. is there a howto or manual somewhere? (i am new to bzr) | 09:12 | |
| RAOF | eMBee: Hi! It should be pretty simple. | 09:13 |
| eMBee | my main concern is that i need to get the trunk and a branch from the svn repo, then commit my changes to the branch and then merge into the trunk (all on svn side) | 09:14 |
| RAOF | Hah! there it is. http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn | 09:14 |
| RAOF | That should work, with the bonus that you get to use bzr for the merge :) | 09:14 |
| eMBee | oh, nice | 09:15 |
| eMBee | is there a way to get all branches from the svn repo? | 09:15 |
| RAOF | I don't believe so, no. Unless the multi-pull plugin works with bzr-svn. | 09:15 |
| eMBee | ah, ok, so at least bzr knows about the concept :-) | 09:16 |
| * eMBee is used to git, where this is the default | 09:16 | |
| RAOF | Right. Whereas bzr has quite a different idea. | 09:17 |
| RAOF | You really, really want to create a repository to store the branches you check out from svn, though. | 09:17 |
| RAOF | (Basically bzr-init repo svn-branches-go-here; cd svn-branches-go-here; bzr branch svn://mysvn.com/svn/branches/foo) | 09:18 |
| eMBee | so i make one repo, and add the branches as i need them? | 09:19 |
| eMBee | and then they all live in the same place | 09:19 |
| RAOF | The bzr repository is just a space and time saver. You don't _have_ to have one, but they make it much faster and much smaller. | 09:19 |
| RAOF | Branches are everything, one branch per directory. | 09:20 |
| eMBee | yes, well, i like the idea of having everything in one repo. that's one thing that is nice about git | 09:20 |
| eMBee | can you explain this: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#python-subversion-1-5 | 09:20 |
| eMBee | what does that mean? (don't answer if it's in the faq, didn't read that yet) | 09:21 |
| RAOF | Wheras I really dislike git's branch handling :) | 09:21 |
| eMBee | ok, i don't want to do a git-bzr comparison now, just enough to get me started with bzr :-) | 09:21 |
| RAOF | That's about bugs in subversion's python bindings. Particularly, there's a huge memory leak IIRC. | 09:21 |
| lifeless | jelmer just committed branch new python svn bindings to bzr-svn trunk | 09:22 |
| RAOF | Oh, that's right, true. | 09:22 |
| lifeless | eMBee: bzr svn-import will get all branches | 09:23 |
| * gour dislike git's all-in-one as well | 09:23 | |
| eMBee | oh | 09:23 |
| RAOF | lifeless: Cool. Learn something new every day :) | 09:23 |
| * eMBee will leave the git-vs-bzr discussion for another day :-) | 09:23 | |
| RAOF | Awww :) | 09:24 |
| lifeless | eMBee: please excuse us vis-a-vis that discussion; we get some advocates here that are +convinced+ there is only one true way | 09:24 |
| lifeless | eMBee: svn-import will give you all the branches, and I think it creates everything sensibly for you - e.g. cd /tmp; bzr svn-import svn://blag output | 09:25 |
| RAOF | Gah. Why must clutter's svn be down when I want to branch clutter-sharp? | 09:27 |
| lifeless | is clutter gnome? | 09:28 |
| eMBee | lifeless: i prefer to convince myself of the better way after i have tried all of them | 09:28 |
| RAOF | No, but it might be soonish. | 09:28 |
| eMBee | or at least studied someone else try | 09:28 |
| lifeless | RAOF: it might be on bzr-mirror.gnome.org | 09:28 |
| lifeless | eMBee: I think thats a good idea | 09:28 |
| RAOF | lifeless: No, but thanks :( | 09:29 |
| strk | help help help ! :) | 09:34 |
| lifeless | hi | 09:34 |
| strk | moving from cvs to bzr for gnash project | 09:34 |
| strk | lifeless: glad to see you up :) | 09:34 |
| lifeless | whats up? | 09:34 |
| strk | so, I used your suggested init-repo; checkout | 09:35 |
| strk | then I've been offline | 09:35 |
| strk | so I tought to try 'unbind' | 09:35 |
| strk | to commit locally | 09:35 |
| strk | and I did | 09:35 |
| strk | now (I guess) my changes are in my local repo, right ? | 09:35 |
| lifeless | yes | 09:35 |
| strk | bzr status doesn't tell me anymore what's different between my copy and the online one | 09:35 |
| lifeless | local branch specifically, because you've unbound | 09:35 |
| lifeless | as you're working in a checkout style, you should bind again | 09:35 |
| lifeless | (just 'bzr bind') | 09:36 |
| strk | bzr: ERROR: No location supplied and no previous location known | 09:36 |
| lifeless | ok, bzr bzr bzr+ssh://..../trunk | 09:36 |
| strk | can it --remember ? | 09:36 |
| lifeless | it will after this | 09:36 |
| lifeless | (note that you could just have done 'commit --local' | 09:37 |
| strk | but it *was* bound before... | 09:37 |
| strk | why did it discard in the first place ? | 09:37 |
| asabil_ | strk: you can use bzr missing in unbound mode | 09:37 |
| lifeless | yes, I smell a bug I think :P | 09:37 |
| lifeless | asabil_: thats more of a branch-branch workflow | 09:37 |
| strk | ah, maybe it's bound already | 09:37 |
| lifeless | asabil_: strk is just been thrown in the deep end :P | 09:37 |
| strk | after 'bind bzr+ssh...' | 09:37 |
| strk | if you 'bind' again (no args) | 09:37 |
| strk | it'll give you taht message | 09:38 |
| asabil_ | lol ok :) | 09:38 |
| lifeless | strk: ok | 09:38 |
| strk | confusing message | 09:38 |
| lifeless | strk: so, 'bzr update; bzr commit' | 09:38 |
| strk | request-for-improvement: could it tell you 'already bound to xxxxy' ? | 09:38 |
| lifeless | strk: sure; care to file a bug? | 09:38 |
| strk | url ? | 09:38 |
| lifeless | https://launchpad.net/bzr/ | 09:38 |
| strk | rob suggested 'pull' in the past, what's the difference between 'pull' and 'update' ? | 09:39 |
| lifeless | pull maintains a mirror | 09:40 |
| lifeless | but you have local changes | 09:41 |
| lifeless | so you need to integrate those with trunk | 09:41 |
| _zou | how to uninstall bzr? I'v no experience with python. | 09:42 |
| lifeless | there are two ways to integrate - 'update' when you have a checkout(aka bound branch), and 'merge' when you have separate branches | 09:42 |
| lifeless | _zou: setup.py uninstall I think. Not sure how good it is | 09:42 |
| lifeless | _zou: if you installed via apt/synaptic/rpm use the package managers method for uninstalling | 09:42 |
| strk | lifeless: after 'update' I got that message telling me that local commits are now shown as changes, and I have to commit. sounds good. | 09:42 |
| strk | problem is, I seem to have 'pending merges' | 09:43 |
| strk | no idea what they are | 09:43 |
| lifeless | strk: thats your local commit | 09:43 |
| lifeless | strk: do 'bzr st' | 09:43 |
| gour | jelmer: there will be new bzr-svn release soon? | 09:43 |
| _zou | I installed it with "python setup.py install". "python setup.py uninstall" doesn't work. | 09:43 |
| strk | lifeless: unfortunately not only | 09:43 |
| strk | I issues a 'merge' before, and got something else | 09:43 |
| strk | (things from nelson) | 09:44 |
| strk | lemme pastebin 'bzr status' output | 09:44 |
| _zou | error: invalid command 'uninstall' | 09:44 |
| lifeless | _zou: oh. | 09:44 |
| strk | http://rafb.net/p/Kdt8Bz59.html | 09:44 |
| lifeless | _zou: you can just remove the bzrlib directory it created, and the bzr binary then | 09:45 |
| _zou | can I just reinstall again? I just want to do a uninstall + reinstall. | 09:46 |
| strk | lifeless: from that output above, modified and added are my duty, pending merges I'd like to ignore :) | 09:46 |
| lifeless | _zou: sure, just install | 09:46 |
| lifeless | strk: ok; uhm. | 09:47 |
| strk | except for a thing: pending merge include (twice) my own commits :? | 09:47 |
| lifeless | strk: I think update should warn then :P | 09:47 |
| strk | file another bug ? | 09:47 |
| lifeless | strk: lets dig a little deeper irst | 09:47 |
| lifeless | you are Sandro ? | 09:47 |
| strk | FYI: bug for the other is https://bugs.launchpad.net/bzr/+bug/242284 | 09:47 |
| ubottu | Launchpad bug 242284 in bzr "confusing error on 'bind'" [Undecided,New] | 09:47 |
| strk | yes, I'm Sandro | 09:47 |
| * strk belives he made too much noise shooting in the dark | 09:48 | |
| lifeless | so | 09:48 |
| lifeless | I think we should peek behind the scenes a little | 09:49 |
| * strk is all ears | 09:49 | |
| lifeless | can you start up python? | 09:49 |
| lifeless | $ python | 09:49 |
| lifeless | >>> from bzrlib import workingtree | 09:49 |
| lifeless | >>> tree = workingtree.WorkingTree.open('.') | 09:49 |
| lifeless | tree.lock_read() | 09:49 |
| strk | yep | 09:49 |
| lifeless | print tree.get_parent_ids() | 09:49 |
| strk | ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv'] | 09:50 |
| lifeless | strk: ok, you are suffering a bug that is fixed in trunk | 09:50 |
| * strk has no idea how did the nelson's desktop got in | 09:50 | |
| lifeless | tree.unlock() | 09:50 |
| lifeless | strk: it was committed to trunk already | 09:50 |
| strk | what was committed ? | 09:50 |
| lifeless | strk: nelson's change | 09:50 |
| lifeless | strk: 'bzr log bzr+ssh://bzr.savannah.gnu.org/gnash/trunk -r -1 | 09:51 |
| lifeless | strk: bet you his change is the most recent | 09:51 |
| strk | ehm... I'm on a gprs connection, would rather avoid bandwidth intensive things | 09:51 |
| lifeless | strk: anyhow, see the three duplicates - thats the symptom of the bug, it should just be: ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv'] | 09:51 |
| lifeless | strk: shouldn't be that intensive :P | 09:52 |
| lifeless | anyhow | 09:52 |
| lifeless | do this | 09:52 |
| lifeless | tree.unlock() | 09:52 |
| lifeless | tree.lock_write() | 09:52 |
| strk | ops, got out of python | 09:52 |
| strk | doing the 'log' thing | 09:52 |
| lifeless | tree.set_parent_ids(['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv']) | 09:52 |
| lifeless | tree.unlock() | 09:52 |
| lifeless | ^D | 09:52 |
| eMBee | in order to branch from svn i need to prefix the svn url with svn? or will the original svn url (which is https://...) do? | 09:53 |
| strk | ok, killed the log and did the set_parent_ids | 09:54 |
| lifeless | eMBee: for most svn repositories the original url will do | 09:54 |
| strk | nelson things are gone from 'status' now | 09:54 |
| eMBee | most? :-) | 09:54 |
| lifeless | eMBee: sometimes (due to bugs/code interactions) you need svn+ | 09:54 |
| strk | pending merges only contain my own now | 09:54 |
| lifeless | strk: 'bzr commit' | 09:54 |
| strk | why are then nested ? (mine) | 09:54 |
| eMBee | so the svn+ can't hurt? how will i know if it fails? | 09:54 |
| strk | http://rafb.net/p/zvJQ3Z11.html <-- this is output | 09:54 |
| lifeless | eMBee: it will error at you | 09:54 |
| lifeless | strk: they are nested because they are from one parent | 09:55 |
| lifeless | strk: if you had two parents, with 5 each you'd see | 09:55 |
| lifeless | merge1 | 09:55 |
| lifeless | nested2 | 09:55 |
| lifeless | nested3 | 09:55 |
| lifeless | nested4 | 09:55 |
| lifeless | nested5 | 09:55 |
| lifeless | merge2 | 09:55 |
| lifeless | ... | 09:55 |
| lifeless | etc | 09:55 |
| eMBee | hmm: bzr: ERROR: Unsupported protocol for url "svn+https://... | 09:55 |
| eMBee | am i missing the bzr-svn plugin? | 09:55 |
| lifeless | you have more than 2 parents when you do what git calls an octopus merge | 09:55 |
| lifeless | eMBee: do 'bzr help svn' | 09:56 |
| eMBee | this is debian etch with bzr from backposrts | 09:56 |
| eMBee | backports | 09:56 |
| eMBee | no help found, looks like it's missing | 09:56 |
| strk | lifeless: I find that indenting confusing too :) | 09:56 |
| eMBee | where do i get the svn plugin for etch/backports? | 09:56 |
| strk | it looks like 'nested2' is somewhat 'contained into' 'merge1' | 09:56 |
| lifeless | strk: hmm, we'll need to look at making it better. but that is what it means | 09:57 |
| lifeless | strk: merge1 is the tip of the branch being merged; neste2..nested5 are other commits on that branch | 09:57 |
| strk | but the change log for first-level (what you call 'merge1') only talks about a change which is on the same level of the change advertised in log for 'nested2' | 09:57 |
| lifeless | strk: topologically, merge1 is a child of nested2; and nested2 is being indirectly merged, rather than directly referenced | 09:58 |
| eMBee | looks like bzr-svn is not in backports yet. can i risk installing the lenny version? | 09:58 |
| strk | indeed 'Add test for global/local registers | 09:58 |
| strk | was committed locally *after* 'Make registers access safer and more general | 09:59 |
| lifeless | eMBee: I would say it should be fine; you'll want svn too | 09:59 |
| lifeless | strk: right | 09:59 |
| lifeless | strk: thats what its showing you | 09:59 |
| eMBee | lifeless: what do you mean? i want to update svn? | 09:59 |
| strk | confusingly :) | 10:00 |
| lifeless | eMBee: bzr-svn needs certain versions of the svn python bindings; many bugs in those were found while writing the plugin | 10:00 |
| eMBee | ah, right, i was asking about that earlier (maybe missed the reply then) | 10:00 |
| lifeless | if you are running packaged bzr-svn, its dependencies sould force this update anyway | 10:01 |
| eMBee | right | 10:01 |
| eMBee | thanks | 10:01 |
| lifeless | np | 10:01 |
| strk | commit is taking a lot, should transfer ~ 120 kb for a new file and 4/5 Makefile.am change | 10:03 |
| strk | and, mmm.. I guess 2/3 lines of commit log | 10:03 |
| lifeless | strk: check ~/.bzr.log | 10:03 |
| _zou | What I did at step1: bzr branch bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck | 10:03 |
| _zou | step2: I modified a local file named MatrixTest.cpp | 10:03 |
| lifeless | strk: there is a thing called autopack which will kick in about 1 time in 10 (and in the next release of bzr hopefully never) | 10:04 |
| lifeless | strk: that may have occured | 10:04 |
| _zou | step3: bzr commit MatrixTest.cpp (seems succeeded) | 10:04 |
| strk | 63.403 Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('bzr+ssh://strk@bzr.savannah.gnu.org/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>) | 10:04 |
| lifeless | strk: oh yeah, waht version of bzr do you have ? | 10:04 |
| strk | _zou: I guess you've committed to local branch, not remote | 10:04 |
| strk | _zou: bzr info should tell you the kind of tree you have | 10:05 |
| strk | lifeless: 1.3.1 | 10:05 |
| lifeless | strk: right, 1.5 is substantially faster; 1.6 should be even more so | 10:05 |
| _zou | strk: "Committed revision 9422" I guess so, I haven't see any mail notifications. | 10:05 |
| lifeless | that reminds me | 10:06 |
| strk | _zou: mail notification doesn't work yet it seems | 10:06 |
| lifeless | I was going to nag | 10:06 |
| lifeless | spiv: ping | 10:06 |
| spiv | lifeless: pong | 10:06 |
| lifeless | strk: centralised ones are tricky, *decentralised* work just fine - the bzr-email plugin :) | 10:06 |
| lifeless | spiv: ^ email notifications && smart server && HOWTO | 10:06 |
| strk | _zou: I guess you should 'bzr bind' to make commits go to the master repo | 10:06 |
| strk | lifeless: I don't have a working outputing mail system | 10:07 |
| strk | it's easier when done centralized... | 10:07 |
| lifeless | strk: sure, and there are a couple of answers for it | 10:07 |
| strk | we likely don't want to get mail on each local commit anyway | 10:07 |
| lifeless | first I interrogate spiv | 10:07 |
| spiv | lifeless: first server-side notifications need to work :( | 10:07 |
| lifeless | spiv: you had a patch I thought ? | 10:07 |
| spiv | They're close, but when I did a quick experiment they aren't there yet. Probably fixed by accident by one of my push-acceleration patches in BB atm though. | 10:08 |
| lifeless | spiv: ah | 10:08 |
| _zou | strk: There should be a commands list to follow. And some feedbacks to confirm if I have done it successfully. | 10:08 |
| spiv | (IIRC the current problem is that the client does not actually invoke a set_last_revision RPC) | 10:08 |
| lifeless | strk: I'll mail rob and sylvain the alioth solution tomorrow | 10:08 |
| strk | _zou: we're all trying to find out :) | 10:09 |
| strk | _zou: the simplest seems to be 'checkout; add; commit;' | 10:09 |
| spiv | lifeless: the next issue after that is making sure the configuration isn't terrible :) | 10:09 |
| strk | _zou: warranty void since you did 'branch' instead of 'checkout' I guess :P | 10:09 |
| lifeless | spiv: I want it to be 'install bzr-email on the server; set a config just like you would on your own machine' | 10:09 |
| spiv | lifeless: me too, I think. | 10:10 |
| * strk commit is still hung with high network traffic | 10:10 | |
| lifeless | I think mtaylor has some stuff for email on push/pull with bzr-email | 10:11 |
| spiv | lifeless: I'm sure that's a great first cut at least, and no doubt user feedback will help refine from there. | 10:11 |
| _zou | strk: "bzr branch bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck" that's what I did. | 10:11 |
| strk | is an upgrade of bzr planned in Feisty ? | 10:11 |
| lifeless | strk: we'll probably get something into a backport | 10:11 |
| strk | _zou: that should have created a local repository, to which your commit would go (I think) | 10:11 |
| lifeless | strk: but we already offer a ppa | 10:11 |
| lifeless | _zou: that has made a new branch | 10:11 |
| strk | ppa? | 10:11 |
| lifeless | _zou: and your commits are isolated in that branch until you merge them into trunk | 10:12 |
| lifeless | _zou: to merge them into trunk: | 10:12 |
| lifeless | 'bzr co bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk trunk; cd trunk; bzr merge OTHERBRANCH; bzr commit' | 10:12 |
| lifeless | _zou: or, do exactly what I did with strk above - bind the branch, then update and commit | 10:13 |
| strk | ouch, sounds expensive | 10:13 |
| _zou | lifeless: tree.lock()? | 10:13 |
| lifeless | strk: well, a shared repository - which you all should have - means that that has almost no network overhead | 10:13 |
| strk | _zou: no, that's just debugging stuff | 10:13 |
| strk | _zou: bzr help; bzr help bind; | 10:13 |
| lifeless | _zou: what bzr version do you have | 10:13 |
| lifeless | http://bazaar-vcs.org/Download | 10:14 |
| strk | bzr bind bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk | 10:14 |
| _zou | lifeless: 1.5 | 10:14 |
| strk | argh! | 10:15 |
| strk | 956.587 Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x85efbcc>, which has 33 pack files, containing 9971 revisions into 26 packs. | 10:15 |
| strk | it kicked in, it's my day ! | 10:15 |
| lifeless | strk: congrats, you get a prize | 10:15 |
| lifeless | strk: its going to be combining 7 packs, should be 1 commit each and small - but if you want to cancel, just hit ctrl-C | 10:16 |
| lifeless | strk: actually, don't | 10:16 |
| _zou | lifeless: "bzr merge OTHERBRANCH" I don't know any other branches. I want my commit to be in head. | 10:16 |
| lifeless | strk: I just remembered, you're commiting :) | 10:16 |
| lifeless | _zou: you made a new branch when you ran 'bzr branch' | 10:16 |
| lifeless | _zou: the 'branch' command always makes a new branch | 10:16 |
| strk | lifeless: how should the /etc/apt/source.list line look like to get a new version ? | 10:17 |
| strk | deb https://launchpad.net/~bzr/+archive <-- this is reported to be malformed, never learned exact format | 10:17 |
| strk | http://bazaar-vcs.org/DistroDownloads <-- this page doesn't tell exactly | 10:18 |
| lifeless | strk: click on the ppa repository link | 10:18 |
| strk | beta ? | 10:18 |
| lifeless | no | 10:18 |
| strk | k | 10:18 |
| lifeless | 'ppa repository' I think it says | 10:18 |
| strk | the intrepid stuff ? | 10:19 |
| lifeless | well, there is a drop-down | 10:19 |
| lifeless | change the drop-down to feisty :) | 10:19 |
| strk | is that 'bzr' specific ? | 10:19 |
| strk | or would I get new versions of other packages too ? | 10:20 |
| strk | or, what does 'ppa' stands for ? :) | 10:20 |
| Kinnison | personal package archive IIRC | 10:21 |
| Peng | indeed | 10:21 |
| * strk Committed revision 9422. (hurray) | 10:21 | |
| * strk_ hates gprs ... | 10:24 | |
| strk_ | 9422 committed ... | 10:24 |
| strk_ | so, I was asking, will the ppa addition in source.list pull-in other experimental packages beside bazaar ? | 10:25 |
| lifeless | strk: no | 10:26 |
| lifeless | strk: only what we upload there, and we only put bzr + plugins | 10:26 |
| strk_ | is there a way to tell apt-get update to only fetch from the new url (to reduce bandwidth) | 10:26 |
| lifeless | strk: no, but it does HEAD's anyway | 10:27 |
| strk_ | ok | 10:27 |
| strk_ | safe to upgrade to 1.5 ? any preparatory work I need ? | 10:27 |
| lifeless | go for it | 10:28 |
| strk_ | uhm... Get:6 http://us.archive.ubuntu.com hardy-updates/main Packages [258kB] <--- my day.. taking time | 10:28 |
| strk_ | is it normal to have 'hardy' stuff in a 'feisty' system btw ? | 10:28 |
| === yacc_ is now known as yacc | ||
| lifeless | strk_: uhm, thats unusual indeed | 10:29 |
| lifeless | strk_: are you sure you haven't upgraded to hardy already ? :) | 10:29 |
| lifeless | strk_: 'lsb-release -a' | 10:29 |
| strk_ | uhm... | 10:33 |
| strk_ | I guess I did, I tought feisty was more recent | 10:33 |
| strk_ | what's this fever to give releases a name ?! gah | 10:34 |
| lifeless | 'f', 'g', 'h' | 10:34 |
| lifeless | you should use the hardy line for the ppa too :P | 10:34 |
| strk_ | oh, that helps, thanks :) | 10:34 |
| strk_ | alright, I hope it won't break everything (pm are so weak) | 10:35 |
| strk_ | 30minutes to go... | 10:36 |
| strk_ | so, about 'bind/unbind' .. is that a good habit for switching between online-offline work ? | 10:37 |
| lifeless | its designed to support that | 10:37 |
| lifeless | a better one would be to create a new branch | 10:37 |
| lifeless | and work in the branch all the time | 10:37 |
| lifeless | then when you are online and ready to put your work in trunk | 10:37 |
| lifeless | cd $trunk | 10:37 |
| lifeless | bzr update | 10:37 |
| lifeless | bzr merge ../your-other-branch | 10:37 |
| lifeless | bzr commit | 10:37 |
| strk_ | good. I guess the alternative would be keeping two different trees, which would mean reconfiguring all build trees | 10:38 |
| strk_ | bzr merge $mybranch. | 10:38 |
| Ng | if I have two branches, one of which is suppoesd to be a clone of the other but has somehow diverged, can I get some useful information as to how they have diverged? or should I just diff them? | 10:38 |
| lifeless | Ng: bzr missing | 10:38 |
| strk_ | right | 10:38 |
| lifeless | Ng: bzr diff -r branch:other | 10:38 |
| lifeless | Ng: bzr merge --preview other | 10:38 |
| strk_ | but all the build trees point to a single source tree | 10:38 |
| Ng | lifeless: hmm, missing is interesting, thanks :) | 10:39 |
| lifeless | strk_: ok | 10:39 |
| strk_ | if I have the build trees point to my own branch I'll have to keep it up to date too when it seems safe. sounds too complex atm. | 10:40 |
| lifeless | strk_: you might find having the build tree not be a branch at all | 10:40 |
| lifeless | strk_: consider this: | 10:40 |
| lifeless | ~ | 10:40 |
| lifeless | repo/trunk | 10:40 |
| lifeless | repo/mybranch | 10:40 |
| lifeless | source/working | 10:40 |
| lifeless | build/treea,treeb etc etc | 10:41 |
| strk_ | working symlinking to trunk/mybranch as needed ? | 10:41 |
| lifeless | if you create source/working by doing 'bzr checkout --lightweight | 10:42 |
| lifeless | and in repo/trunk and repo/mybranch there is no source code files at all | 10:42 |
| lifeless | you would use the 'bzr switch' command to point working at either trunk, or mybranch, as you desire | 10:42 |
| bob2 | lifeless: how crack-headed do you think a git-ish-all-branches-in-one-dir repo format would be? | 10:42 |
| lifeless | bob2: I don't think its crack-headed, but I think its really less nice to work with | 10:43 |
| Kinnison | bob2: my 2¢ is that it'd be nasty :-) | 10:43 |
| strk_ | I don't get the 'no source code files at all' part | 10:43 |
| lifeless | strk_: ok | 10:44 |
| strk_ | you mean no 'working' files, but 'in-repo' only ones ? | 10:44 |
| lifeless | strk_: I think doco is the best thing at this point | 10:44 |
| lifeless | bzr help working-trees | 10:44 |
| lifeless | strk_: I mean that there would only be a .bzr diredctory at repo/trunk and repo/mybranch | 10:46 |
| strk_ | there would be two repos with no working trees in them | 10:47 |
| lifeless | strk_: 1 repo. 2 branches. no working trees | 10:47 |
| strk_ | or, two branches | 10:48 |
| lifeless | it might be easiest to show you | 10:48 |
| lifeless | you made a repo already correct? | 10:48 |
| strk_ | yes, and I just tried 'remove-tree' | 10:49 |
| strk_ | unfortunately, it didn't clean everything up (./autogen.sh created files left) | 10:49 |
| strk_ | would a rm -Rf * be safe ? | 10:49 |
| lifeless | yes (as long as .bzr stays around, its fine) | 10:50 |
| strk_ | then I'm doing: | 10:50 |
| strk_ | cd ../gnash-head; bzr checkout --lightweight ../bzr-local-repository/trunk | 10:50 |
| strk_ | bzr-local-repository/trunk | 10:50 |
| strk_ | gnash-head | 10:50 |
| lifeless | right | 10:50 |
| strk_ | ok | 10:50 |
| strk_ | now, the local branch | 10:50 |
| strk_ | cd bzr-local-repository; bzr branch trunk mybranch ? | 10:51 |
| lifeless | yes | 10:51 |
| lifeless | exactly in fact | 10:51 |
| lifeless | because your repository is set to create trees you'll want to remove-tree right away | 10:51 |
| strk_ | k | 10:51 |
| strk_ | ops | 10:51 |
| strk_ | what tells me when the repository is set to create trees ? | 10:51 |
| strk_ | and how to change it ? | 10:51 |
| * strk_ running remove-tree in 'mybranch' meanwhile | 10:52 | |
| lifeless | touch .bzr/repository/no-working-trees | 10:52 |
| strk_ | alright, I have trunk and mybranch with no working trees now | 10:52 |
| lifeless | ok | 10:52 |
| lifeless | and your builds all can point at gnash-head. (actually I'd rename it gnash-working or something) | 10:52 |
| strk_ | I'll need multiple 'working' trees | 10:53 |
| lifeless | strk_: you will? | 10:53 |
| strk_ | with cvs, I had one each branch | 10:53 |
| lifeless | (I got the impression you wanted just one) | 10:53 |
| strk_ | usually only using head and release branch | 10:53 |
| strk_ | well, just one each 'set' of build trees | 10:53 |
| strk_ | I usually work with 2 ones, head and release branch | 10:54 |
| lifeless | you can have as many working trees as you want | 10:54 |
| strk_ | actually, I also have a third one, which I used to call 'gnash-head-backup' | 10:54 |
| strk_ | that's for when I made local changes and wanted to use plain trunk | 10:54 |
| lifeless | now there is a new command that you can use | 10:54 |
| lifeless | cd to the working tree | 10:54 |
| lifeless | and run 'bzr switch mybranch' | 10:55 |
| strk_ | ok, gnash-head is now my working tree: | 10:55 |
| strk_ | Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) | 10:55 |
| strk_ | Switched to branch: /home/strk/src/gnash/bzr-local-repository/mybranch/ | 10:55 |
| strk_ | Switched to branch: /home/strk/src/gnash/bzr-local-repository/trunk/ | 10:55 |
| strk_ | nice :) | 10:55 |
| lifeless | now when you commit the commits will go to mybranch | 10:55 |
| lifeless | and now trunk | 10:55 |
| lifeless | so to work offline: | 10:56 |
| lifeless | switch mybranch | 10:56 |
| lifeless | hack commit hack commit hack commit | 10:56 |
| lifeless | come oneline | 10:56 |
| lifeless | bzr shelve/revert/commit (so that 'bzr st' shows no changes) | 10:56 |
| lifeless | bzr switch trunk | 10:56 |
| lifeless | bzr update | 10:56 |
| lifeless | bzr merge ../bzr-local-repository/mybranch | 10:57 |
| lifeless | (run any tests etc) | 10:57 |
| lifeless | bzr commit | 10:57 |
| lifeless | make sense? | 10:57 |
| strk_ | I guess so | 10:57 |
| strk_ | this is assuming 'commit' on a trunk-bound working tree will push online ? | 10:57 |
| lifeless | yes | 10:58 |
| strk_ | even if 'trunk' is local... | 10:58 |
| lifeless | its assuming trunk is still a bound branch | 10:58 |
| strk_ | trunk info: Repository bound branch (format: pack-0.92) | 10:58 |
| lifeless | yup | 10:58 |
| strk_ | mybranch info: Repository branch (format: pack-0.92) | 10:58 |
| strk_ | bzr @ 1.5 now | 10:58 |
| strk_ | now, lemme try to do the 'gnash-head-backup' equivalent | 10:59 |
| strk_ | that'd be a working tree bound to the local 'trunk' which is bound to the online 'trunk' | 10:59 |
| strk_ | which I'll use for in-source-tree building | 10:59 |
| strk_ | still --lightweight ? | 10:59 |
| lifeless | yes | 10:59 |
| strk_ | bzr checkout --lightweight bzr-local-repository/trunk | 11:00 |
| strk_ | can I give an additional arg to name the created dir ? | 11:00 |
| strk_ | bzr checkout --lightweight bzr-local-repository/trunk gnash-head-backup ? | 11:00 |
| lifeless | yes | 11:00 |
| strk_ | I guess last thing would be release branches | 11:04 |
| strk_ | is there a command to query a repository for the list of branches available there ? | 11:04 |
| lifeless | bzr branches | 11:04 |
| lifeless | (with URL for a remote list) | 11:04 |
| strk_ | with no URL what does it use ? | 11:05 |
| lifeless | '.' | 11:05 |
| lifeless | hmm, probably could give it some heuristic love | 11:05 |
| lifeless | make it aware of being in a checkout | 11:05 |
| strk_ | mmm... I guess I have no branches locally, since I only have trunk... | 11:05 |
| lifeless | strk_: and mybranch | 11:06 |
| strk_ | oh | 11:06 |
| strk_ | still bzr branches lists nothing when issued inside 'trunk' or inside the working tree | 11:06 |
| lifeless | yeah, its a very literal commanda t the moment | 11:06 |
| strk_ | it does when isued from top-level dir | 11:06 |
| strk_ | makes sense | 11:06 |
| strk_ | trying it remotely | 11:07 |
| strk_ | sloooow :( | 11:08 |
| strk_ | bzr branches bzr+ssh://strk@bzr.savannah.gnu.org/gnash | 11:09 |
| strk_ | isn't it just 10/15 strings to transfer ? | 11:09 |
| lifeless | there is no specific RPC for it yet | 11:09 |
| lifeless | so its listdir + open_branch per dir | 11:09 |
| lifeless | which is another way of saying 'no but it will be in the future' | 11:10 |
| strk_ | still not done fetching branches... | 11:15 |
| strk_ | 6 minutes later | 11:15 |
| lifeless | its recursed into the tags and branches dirs | 11:15 |
| lifeless | you're paying GPRS latency :(. This is all predictable (and frustrating) | 11:16 |
| strk_ | ? how many ssh connections ? | 11:16 |
| lifeless | one connection | 11:16 |
| lifeless | and it should be one round trip per branch/tag | 11:16 |
| lifeless | back in a sec | 11:17 |
| * strk_ realizes he didn't pipe to less :! | 11:17 | |
| * strk_ gets the videocam ready ;P | 11:17 | |
| strk_ | nah, I kill, don't care about branches now anyway | 11:18 |
| strk_ | thanks for your time lifeless, I'll be offline | 11:20 |
| shai_hulud | hi. how do I merge pending merges. I did bzr merge --pull <repo> and had a conflict on the way. now I'd like to continue merging, but I get a message that i have uncommited changes | 12:09 |
| === mneptok_ is now known as mneptok | ||
| === lifeless_ is now known as lifeless | ||
| mlh | what's 1.6 got over 1.5? | 12:27 |
| mlh | I'm about to d/l for windows and curious about the difference 1.5 -> 1.6b2 | 12:27 |
| mlh | and didn't find release notes / roadmap | 12:27 |
| === `6og is now known as Kamping_Kaiser | ||
| mlh | hrm, never mind, there is no 1.6b for win | 12:31 |
| === eMxyzptlk[away] is now known as eMxyzptlk | ||
| lifeless | :P | 12:33 |
| === kiko is now known as kiko-afk | ||
| mlh | :-) | 12:38 |
| mlh | you just got mail on a trivial wiki change | 12:38 |
| mlh | Bialix's last name | 12:38 |
| === elmo_ is now known as elmo | ||
| jelmer | Verterok: hi | 13:12 |
| Verterok | jelmer: hi | 13:39 |
| jrb_ | In a shared repository if I don't need some branch anymore: is it enough to just delete the branch (rm) to remove all traces of the branch? | 13:41 |
| radix | jrb_: the revisions that the branch pointed to will still be in the repository | 13:41 |
| radix | jrb_: mostly that's fine since generally those revisions become a part of trunk or whatever | 13:42 |
| Verterok | jelmer: while playing with bzr-svn new bindings (I must say, cool!), before building the mac OSX package/installer I encountered with a known bzr tests problem in os x, http://rafb.net/p/MbdV9D77.html | 13:42 |
| radix | if you've got a branch with a commit of a 8GB file and you don't want that sitting in your repository, though, it can be a problem | 13:42 |
| jrb_ | radix: So what happens if I create a branch with the same name later on? Is there no remove-branch command? | 13:43 |
| radix | jrb_: the name of the branch won't matter at all | 13:43 |
| lifeless | jrb_: just delete the directory, that gets rid of teh branch | 13:43 |
| radix | jrb_: what's your concern, exactly? | 13:44 |
| nysin | Is there a way to bzr diff (without making basically a shell program to use --using or --diff-options with) ignoring certain files and directories? Mainly certain big ones that are in one branch but not another and just clutter up a diff uninterestingly. | 13:44 |
| jrb_ | since the name of the branch does not matter it isn't much of a problem to me. I was just wondering. | 13:45 |
| lifeless | nysin: well you can use filterdiff | 13:45 |
| radix | jrb_: cool | 13:45 |
| nysin | oh IIRC in difftools or something, a separate package, right? | 13:45 |
| lifeless | nysin: but there is a bug option to support --exclude or some such as part of bzr diff | 13:45 |
| nysin | Ah, well, I look forward to that, in the meantime I'd forgotten about filterdiff | 13:46 |
| jrb_ | radix: thanks for the info and bye | 13:46 |
| nysin | lifeless, have a link to that bug? | 13:47 |
| lifeless | nope, just remember someone talking about it last week | 13:47 |
| nysin | okay | 13:48 |
| lifeless | nysin: if you can't find it, feel free to open another | 13:48 |
| jelmer | Verterok: what sort of thing were you pushing? | 13:48 |
| nysin | yup; I'm sure someone will mark it as a dupe, but that's just as good | 13:48 |
| Verterok | jelmer: the bzr-eclipse, just for testing....it contains ~160 mainline commits | 13:49 |
| nysin | https://bugs.launchpad.net/bzr/+bug/53992 | 13:49 |
| ubottu | Launchpad bug 53992 in bzr "diff should have an -x option (exclude certain files)" [Wishlist,Confirmed] | 13:49 |
| jelmer | Verterok: you seem to've hit an endless loop somehow | 13:50 |
| jrb_ | radix: oh wait. one more question. since the history of the deleted branch is still available in the repository how can I get it back after I have deleted the branch. just in case I ever need that. | 13:50 |
| jelmer | Verterok: _dir_process() should be run for each level of directories that's being committed | 13:50 |
| lifeless | jrb_: there is a heads() plugin | 13:51 |
| radix | jrb_: If you've merged the branch into another, it's much easier | 13:51 |
| radix | oh | 13:51 |
| radix | or maybe you can use something called the heads() plugin, but I have no idea what that is. | 13:51 |
| lifeless | jrb_: you can just run heads --all (IIRC) and it will list the revision ids | 13:51 |
| radix | I know how to get a branch that's been merged into another | 13:51 |
| jrb_ | lifeless: okay I look into that, thx | 13:51 |
| lifeless | jrb_: I think there is an option to list only the invisible heads, which will be your deleted branch | 13:51 |
| Verterok | jelmer: oh, I see. bzr-eclipsse structure conatins lots of empty and nested, directories, i.e: core/org/vcs/bazaar/eclipse/foo/bar,java | 13:52 |
| Verterok | jelmer: could that be a problem? | 13:53 |
| === emgent_ is now known as emgent | ||
| jelmer | Verterok: that probably explains why svn needs that many open file handles | 13:56 |
| jelmer | Verterok: if your limits are very conservative atm you may want to consider increasing them | 13:57 |
| Pilky | is bzr pull --overwrite just meant to replace what is on my branch with whatever is on the branch I'm pulling from? | 13:58 |
| Pilky | because I tried it yesterday but got conflicts | 13:58 |
| lifeless | Pilky: you shouldn't have, unless a directory with non-versioned files in it was deleted | 13:59 |
| Verterok | jelmer: ok, thanks. I'll try to increase the limits | 14:00 |
| Pilky | lifeless: all I'd done was change some files, and then want to replace them with the ones on my server | 14:00 |
| lifeless | Pilky: had you committed those changes? | 14:00 |
| Pilky | nope | 14:01 |
| lifeless | then thats why | 14:01 |
| Pilky | ah | 14:01 |
| lifeless | pull preserves local edits | 14:01 |
| lifeless | they were local edits (as opposed to commits which can be overriden) | 14:01 |
| Pilky | so in future, revert and then pull | 14:01 |
| Pilky | if I want to replace what I have | 14:01 |
| lifeless | for this scnenario, yes | 14:01 |
| Pilky | ok, thanks | 14:03 |
| nysin | It appears that using --diff-options doesn't even work | 14:06 |
| nysin | because bzr seems to special-case new files | 14:06 |
| nysin | so if e.g. I tell it to use --using=cat, then most files are just cat'd, but wholly new files are done internally (because they still look vaguely diff-like) | 14:07 |
| lifeless | uhm | 14:07 |
| lifeless | --using | 14:07 |
| lifeless | and --diff-options | 14:07 |
| lifeless | are mutually exclusive options | 14:07 |
| nysin | oh | 14:07 |
| lifeless | --diff-options says 'pass these options to diff' | 14:08 |
| Verterok | abentley: the script to move from sqlite, now also works in postgres :-) | 14:08 |
| lifeless | --using says 'use this script to do diffs' | 14:08 |
| nysin | Er, right. Whoops. Well right now I'm acutally only specifying --using | 14:08 |
| nysin | So my comment above still applies except just to --using I guess | 14:08 |
| lifeless | I'm not sure they /should/ be mutually incompatible, but thats what I recall reading in a bug report | 14:08 |
| Verterok | abentley: sorry, to move BB db from sqlite | 14:08 |
| jelmer | beuno: hi | 14:16 |
| nysin | And --diff-options seems problematic because it (as determined by forcing it to throw an error to see commandline) uses randomly named files in /tmp and just --labels them so -x and -X don't seem to work (I've tried the very simplest cases, where it's not in a directory, has no spaces in the filenames, etc) | 14:16 |
| Jc2k | beuno, lifeless: lo | 14:17 |
| Jc2k | i was talking to robtaylor and we wondered.... | 14:17 |
| Jc2k | could we have a "wall of outstanding" | 14:17 |
| Jc2k | e.g. get all fixmes in the whole of gnome :p | 14:18 |
| Jc2k | laggy laggy | 14:18 |
| * Jc2k back to work | 14:19 | |
| abentley | lifeless: Well --diff-options is unnecessary when using --using | 14:23 |
| abentley | And what are you doing up? | 14:23 |
| === fbond_ is now known as fbond | ||
| mlh | is there anyway to get a branch over http if the http server hides dot files? | 14:48 |
| mlh | (Im thinking maybe bzr has an alternate name for .bzr - _bzr perhaps? | 14:48 |
| jelmer | Jc2k: that sounds like a nice idea | 14:49 |
| mlh | if not, thats ok , I can get via ftp with password | 14:50 |
| === kiko-afk is now known as kiko | ||
| nysin | (filterdiff ended up working fine, though there would be substantial network win if the filtering could be done before retrieving megabytes of stuff...) | 15:03 |
| nysin | doing it locally for the moment means it doesn't really matter though | 15:03 |
| === toyto1 is now known as toytoy | ||
| === thekorn_ is now known as thekorn | ||
| Pieter | is bzr under windows really slow or is it possible it hangs without giving any output? | 15:29 |
| jelmer | mlh: you should be able to fetch that branch even if it's not included in directory listings | 15:49 |
| Peng | mlh: Server-generated directory listings really don't matter. They're nothing magic, just another HTML page. Of course, the server could actually access to dot files too... | 16:01 |
| === fredreichbier_ is now known as fredreichbier | ||
| beuno | jelmer, hey | 16:25 |
| jelmer | beuno: I'm still interested in uploading bzr-upload's Debian package | 16:28 |
| beuno | jelmer, ah, yes. I have an email about no bein able to branch that... can you give me the URL again? | 16:28 |
| jelmer | http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable | 16:32 |
| jelmer | e.g. bzr builddeb http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable | 16:32 |
| james_w | you might need nosmart+ to access bzr.debian.org until 1.6 is out. | 16:33 |
| james_w | hi jelmer | 16:33 |
| james_w | hi beuno | 16:33 |
| beuno | howdy james_w | 16:33 |
| beuno | jelmer, thanks, I'll pass that on now | 16:33 |
| jelmer | hi James | 16:34 |
| === thekorn_ is now known as thekorn | ||
| jelmer | james_w: Ah, bzr builddeb nosmart+http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable fails for me atm because the tree isn't locked | 16:49 |
| james_w | ok | 16:49 |
| jelmer | adding a lock in cmd_builddeb() fixes it. I'll send you a patch | 16:51 |
| james_w | thanks | 16:51 |
| jelmer | sent | 16:57 |
| jelmer | beuno: so it may be necessary to create a local copy of that branch first | 16:57 |
| jelmer | rather than using bzr builddeb on the remote url | 16:57 |
| beuno | jelmer, ah, ok. Just sent that off in another email too. | 16:58 |
| === gour is now known as gour|afk | ||
| === kiko is now known as kiko-fud | ||
| emgent | fog: hi | 17:26 |
| lamont | No handlers could be found for logger "bzr" | 17:30 |
| lamont | what's that mean? | 17:30 |
| fog | emgent: hey | 17:30 |
| quicksilver | if you did a bzr update (or bzr pull) which yielded some conflicts | 17:34 |
| quicksilver | and you decide you don't really want to resolve them now | 17:34 |
| quicksilver | can you undo it? | 17:34 |
| beuno | quicksilver, bzr revert | 17:40 |
| quicksilver | I don't think so. | 17:40 |
| quicksilver | I think bzr rever will throw away my local changes. | 17:40 |
| jelmer | quicksilver: You mean, commit with conflict markers? | 17:40 |
| quicksilver | precisely the opposite of what I wish to do. | 17:40 |
| quicksilver | jelmer: rollback the update/pull. | 17:40 |
| quicksilver | previously my local copy was on revision 10 (say). | 17:41 |
| quicksilver | I had local changes. | 17:41 |
| jelmer | quicksilver, maybe something like "bzr merge --force -r43..41" | 17:41 |
| quicksilver | pulling revision 11 lead to lots of conflicts I don't wish to resolve today. | 17:41 |
| quicksilver | instead I wish to return to my previous situation | 17:41 |
| jelmer | if the changes you merged in were revno 41 to 43 | 17:41 |
| quicksilver | (revision 10 + local changes) | 17:41 |
| jelmer | hmm, I doubt that'd help with conflicts though | 17:42 |
| beuno | can you merge with uncommitted changes? | 17:42 |
| beuno | if so, you shouldn't :) | 17:43 |
| beuno | and then use revert | 17:43 |
| jelmer | beuno, you can't merge | 17:47 |
| jelmer | but you can pull | 17:47 |
| quicksilver | you can both pull and update with uncommitted changes | 17:49 |
| quicksilver | as long as you're tracking fairly closely it's quite a sane thing to do | 17:49 |
| quicksilver | btu I believe it lacks the ability to undo if it goes wrong | 17:49 |
| quicksilver | which is why I asked the question here ;) | 17:49 |
| quicksilver | it's a bit unusual since most bzr operations are undoable. | 17:50 |
| jelmer | yeah, reversibility ftw | 17:55 |
| jelmer | quicksilver: I wonder what the sanest UI for this would be though | 17:56 |
| strk | lifeless: so I did 'commit' when bound to 'mybranch', then 'switch', 'merge ../mybranch', cleanup stuff, commit | 18:21 |
| strk | taking forever as usual :) | 18:21 |
| === yacc_ is now known as yacc | ||
| === mark2 is now known as Guest28613 | ||
| === ndim_ is now known as ndim | ||
| awilkins | Once again, win32 packages lag behind the bleeding edge.... | 19:57 |
| * awilkins waves his neatly set up win32 build environment that takes about 10 seconds to build both Python-style packages | 19:58 | |
| jelmer | hi awilkins | 20:02 |
| awilkins | jelmer: Hello jelmer, after dinner I can spend some time trying to get those extensions to build | 20:08 |
| awilkins | I think maybe I should install a 4-series GCC in my MinGW | 20:08 |
| awilkins | Anyhow, time to cook some chicken soup ; back later | 20:09 |
| cr3 | how can I reverse a commit between release 530..529? too late for an uncommit | 20:35 |
| beuno | cr3, you want to go back to the state of 529? | 20:35 |
| cr3 | maybe bzr diff -r530..529 | patch -p1 or somesuch | 20:35 |
| beuno | cr3, bzr revert -r 529 | 20:36 |
| cr3 | beuno: only reverse that commit, not all the commits since then | 20:36 |
| fullermd | No, you don't want that... merge can do it. | 20:36 |
| fullermd | bzr merge -r530..529 . | 20:36 |
| cr3 | fullermd: excellent, thanks! | 20:36 |
| === mw is now known as mw|food | ||
| melat0nin | hi all | 20:47 |
| melat0nin | got a simple question.. how do i download a branch from a revision other than the most recent? | 20:48 |
| beuno | melat0nin, bzr branch -r revno | 20:48 |
| melat0nin | beuno: then the branch url? | 20:49 |
| beuno | melat0nin, yeap, the order doesn't matter really | 20:49 |
| melat0nin | beuno: great, thanks :) | 20:49 |
| beuno | as long as -r is followed by the revno | 20:49 |
| melat0nin | cool | 20:50 |
| quicksilver | jelmer: bzr backtrack -r123 ? | 20:50 |
| quicksilver | jelmer: meaning backtrack repo to revision 123, keep uncommitted working changes | 20:50 |
| tethridge | where is the mailing list for bazaar? | 20:56 |
| tethridge | found it | 20:57 |
| tethridge | I was looking on launchpad | 20:57 |
| tethridge | it's not on there. :-) | 20:57 |
| awilkins | jelmer: Ping? | 21:11 |
| jelmer | awilkins: pong | 21:11 |
| awilkins | Which compiler are you using on these extensions? | 21:11 |
| jelmer | quicksilver: Hmm, what if you do two pulls in a row and then want to back both of them out? | 21:11 |
| jelmer | awilkins: I'm using gcc | 21:12 |
| awilkins | Which version? | 21:12 |
| awilkins | The MinGW 4-series GCC is marked as "Warning: This is an alpha testing release. That means the build may | 21:13 |
| awilkins | contain major missing functionality and serious bugs, including silent | 21:13 |
| awilkins | incorrect code compilation. | 21:13 |
| jelmer | awilkins: 4.3.1 | 21:14 |
| jelmer | awilkins: I'm on Linux though | 21:14 |
| awilkins | I think some of the C idioms you are using are not liked by the 3 series compiler | 21:14 |
| jelmer | which ones? Can you pastebin the output? | 21:16 |
| awilkins | Sure | 21:16 |
| awilkins | jelmer: Going to be a little while, the last revision busted my windows setup script | 21:26 |
| jelmer | awilkins: k | 21:26 |
| === emgent is now known as emgent` | ||
| awilkins | jelmer: Are the PAR ldflags very important? | 21:34 |
| awilkins | *APR | 21:34 |
| === mw|food is now known as mw | ||
| jelmer | awilkins: depends on what they are exactly :-) | 21:34 |
| jelmer | here on Linux, they're actually empty | 21:35 |
| === beuno_ is now known as beuno | ||
| awilkins | jelmer: On windows, it's hard to tell because apr-config is a bash script :-) | 21:38 |
| jelmer | awilkins, ah :-) | 21:39 |
| jelmer | awilkins, I think you should be able to get away with ignoring them | 21:39 |
| === eMxyzptlk is now known as eMxyzptlk[away] | ||
| lifeless | Jc2k: interesting ide | 21:41 |
| lifeless | abentley: it was 23:20 or so; | 21:41 |
| lifeless | *now* its 0640 and wtf am I doing up is what I'm asking myself | 21:41 |
| abentley | hehe | 21:41 |
| Jc2k | thinking about implementing the wall of GNOME ;) | 21:42 |
| beuno | goooooooood morning lifeless | 21:42 |
| beuno | Jc2k, if everything goes as planned, I'll get to theming for Gnome in about an hour or so | 21:43 |
| beuno | then we have to see if that actually brings any useful results :) | 21:43 |
| Verterok | mornin' | 21:43 |
| lifeless | beuno: cool! | 21:44 |
| mwhudson | mornings | 21:45 |
| beuno | señor mwhudson, good morning | 21:46 |
| Jc2k | beuno: awesome :) | 21:46 |
| beuno | I have a few things to bounce off you when you're past your morning coffee | 21:46 |
| beuno | remember=revid is bugging the hell out of me | 21:46 |
| mwhudson | ah haha | 21:47 |
| beuno | it doesn't seem to work, the UI for it sucks badly, and it breaks the beautiful new theme | 21:48 |
| mwhudson | hm, if it's broken it broke recently | 21:48 |
| beuno | so it's down to "fix it" or "remove it, make plans for something much better soon" | 21:48 |
| beuno | mwhudson, well, it's broken on LP | 21:48 |
| mwhudson | it's a terrible terrible ui though | 21:48 |
| mwhudson | beuno: oh | 21:48 |
| mwhudson | :) | 21:48 |
| mwhudson | maybe it works in trunk then | 21:48 |
| beuno | let me try, I think not | 21:49 |
| beuno | it does not! | 21:49 |
| beuno | oh | 21:49 |
| beuno | it does | 21:49 |
| beuno | ew | 21:49 |
| mwhudson | i think it may just be even harder to use than you expected :) | 21:50 |
| beuno | it works on LP too | 21:50 |
| beuno | yes | 21:50 |
| beuno | it's an extra step | 21:50 |
| beuno | worse UI then I thought then | 21:50 |
| beuno | ugh, ok, I'll change the bug si it's "make it better" | 21:51 |
| quicksilver | jelmer: I don't know. I don't know enough about how bzr stores stuff. | 21:52 |
| Verterok | abentley: hi | 21:52 |
| quicksilver | jelmer: I don't even know if the data exists to unmerge the local changes. | 21:52 |
| Verterok | abentley: done, the migration scripts now support postgresql ;-) | 21:52 |
| quicksilver | jelmer: or if you'd have to explicitly 'save' state when doing a 'bzr update'. | 21:52 |
| abentley | Verterok: Thanks. I saw that this morning. Haven't had a chance to try it. | 21:52 |
| quicksilver | jelmer: maybe that is the simplest solution; have 'bzr update' (or pull) explicitly save the local diff and the revision number in an undo history. | 21:53 |
| Verterok | abentley: np, glad to help, in case you find any problems with the scripts drop me an email or ping me | 21:53 |
| beuno | abentley, that would be a cool link to add to "merge request" in LP. A link to the diff between the missing revisions. | 21:53 |
| abentley | beuno: Yes, showing diffs is on our roadmap. | 21:55 |
| beuno | abentley, cool :) That would make it much more BB-like | 21:55 |
| abentley | beuno: In fact, today I've been working on adding the ability to show a diff of "x merged into y assuming z is already merged into y". | 21:56 |
| beuno | abentley, It's getting more advanced, yay! :) | 21:57 |
| awilkins | jelmer: Ok, first problem, no svn_client_commit_item_2_t in 1.4.6 (although now 1.5 is live I suppose I ought to use it ...) | 22:02 |
| jelmer | awilkins: Strange, it works fine here | 22:02 |
| awilkins | Is it in the headers? | 22:02 |
| jelmer | ahh, it's a typo | 22:03 |
| jelmer | awilkins, please pull from the 0.4 branch | 22:03 |
| jelmer | It was part of an assert() that wasn't being compiled on my machine | 22:04 |
| * awilkins pulls | 22:04 | |
| jelmer | because I was using -DNDEBUG | 22:04 |
| awilkins | Bugger, more conflicts :-( | 22:04 |
| mwhudson | beuno: your update of the description on 242469 made me chuckle | 22:04 |
| beuno | mwhudson, some frustration may of passed on to there :) | 22:06 |
| awilkins | jelmer: Same error, line 85 of client.c | 22:08 |
| awilkins | jelmer: Ok, typo fixed | 22:09 |
| awilkins | jelmer: And now back to our friendly "initializer element not constant" | 22:10 |
| awilkins | client.c:750 | 22:10 |
| awilkins | I think it's the sizeof() | 22:11 |
| jelmer | awilkins: You may want to change the &PyType_Type to just NULL | 22:12 |
| awilkins | jelmer: Same in editor.c:[63,135,139,35-,354,444] | 22:14 |
| awilkins | jelmer: Changing to NULL fixed some of those (where the &PyTYpe_Type was) | 22:17 |
| awilkins | But not all | 22:17 |
| awilkins | http://pastebin.ca/1054359 | 22:18 |
| jelmer | awilkins: you may want to try setting tp_dealloc to NULL in some of these cases where I've set it to PyObject_Del | 22:19 |
| awilkins | jelmer: Wahey, next .c files worth of errors :-) | 22:21 |
| awilkins | Same things again , methinks | 22:22 |
| * awilkins hands out the NULL pointers | 22:22 | |
| * awilkins updates paste | 22:24 | |
| awilkins | OK, C errors fixed, now back to Python ones :-) | 22:26 |
| mwhudson | if the objects go through PyType_Ready you can leave ob_type and tp_dealloc to null (and maybe some other fields too) | 22:28 |
| awilkins | Distutils is choking now :-( | 22:28 |
| lazy1 | is there a way to preview what "bzr push" will do? | 22:41 |
| mwhudson | missing, sorta | 22:41 |
| mwhudson | lazy1: what sort of answer do you want? | 22:42 |
| mwhudson | a diff? a list of revisions? | 22:42 |
| lazy1 | bzr push --preview | 22:42 |
| lazy1 | :) | 22:42 |
| lazy1 | is there a shortcut for "last pulled revision"? (so I can use "bzr log") | 22:43 |
| LarstiQ | lazy1: yes, but what would you like the output of that to be? (Ie, are you after `bzr missing push/location`?) | 22:43 |
| awilkins | jelmer: Would you happen to know whether you need to build things with the same compiler used to build the SVN and APR libs... because it's become VERY unhappy now | 22:43 |
| lazy1 | I about to push my changes and would like to know which revision will get pushed | 22:43 |
| jelmer | awilkins: I'm not sure | 22:44 |
| LarstiQ | lazy1: I'd recommend `bzr missing` for that scenario | 22:44 |
| awilkins | jelmer: From the output, SVN and APR I have were built with MSVC | 22:44 |
| james_w | lazy1: hi, "bzr diff -r submit:" will show you a diff of your changes compared to the branch "bzr push" will push to | 22:44 |
| james_w | bzr diff -r ancestor:.../wherever will do it for other branches | 22:44 |
| james_w | "bzr send -o-" will show you something like the first. | 22:44 |
| lazy1 | thanks | 22:45 |
| awilkins | jelmer: MSVC hates you because you used stdbool.h though :-) | 22:46 |
| lazy1 | james_w: is there a way to set the submit branch? (not with bzr pull --remember) | 22:46 |
| jelmer | awilkins: heh, ok | 22:47 |
| * awilkins pastes in a simple stdbool.h | 22:49 | |
| awilkins | Heh, MSVC also hates you for using those funky dot things (sorry, my C is virtually absent) on client.c:724 | 22:50 |
| lazy1 | works like a charm, thanks | 22:51 |
| beuno | mwhudson, downloading bundles from LH (trunk and LP) seems really broken. It outputs a binary file which is unmergeable: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/argentina%40gmail.com-20080622180415-9ognqtaiptt58z7p?start_revid=argentina%40gmail.com-20080623155739-je1svgi6ikjyudfq&remember=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib&compare_revid=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib | 22:51 |
| beuno | am I doing something wrong this time too? | 22:52 |
| mwhudson | i wouldn't be at all surprised | 22:52 |
| mwhudson | it's a bit of a crazy feature really | 22:52 |
| jelmer | awilkins, wow, that's quite an old C compiler | 22:52 |
| awilkins | I'm using the VS2003 compiler because of all the warnings in the distutils files about having to use the same compiler that Python was built with | 22:53 |
| * beuno files a bug | 22:53 | |
| mwhudson | beuno: here is somewhere where i really think "delete the feature" is a viable choice | 22:54 |
| awilkins | jelmer: I had a terrible time finding a package for it, and poking all the magic values into the registry that the full Visual Studio install shoves in so msvccompiler.py can read them and set it up | 22:54 |
| jelmer | awilkins: It's not very easy to work around that :-/ | 22:56 |
| beuno | mwhudson, fair enough. I'll clean it up after I finish going through the last bits for today for the new theme | 22:56 |
| jelmer | awilkins: Specifying these member values in the right order is a pain | 22:56 |
| awilkins | I suppose I can keep trying the mingw compiler | 22:57 |
| awilkins | jelmer: Have a shufty at the mingw output | 23:00 |
| awilkins | http://pastebin.ca/1054520 | 23:00 |
| beuno | jelmer, bzr.debian.org seems to hate people, so I'm going to send a tarball to the DD | 23:01 |
| jelmer | beuno, ah, ok | 23:01 |
| jelmer | beuno, there's also a tarball and all that up on my site | 23:01 |
| beuno | doesn't work with nosmart either :/ | 23:02 |
| jelmer | http://samba.org/~jelmer/debian/unstable | 23:02 |
| beuno | (it does for me) | 23:02 |
| beuno | jelmer, I don't see it on there, but I sent it off anyway, so no worries | 23:02 |
| jelmer | awilkins, yikes | 23:04 |
| jelmer | awilkins, yeah, that doesn't look like it's going to work | 23:04 |
| jelmer | awilkins, you don't have a newer msvc? | 23:04 |
| awilkins | jelmer: Yes, but is that going to link properly with Python? | 23:05 |
| jelmer | awilkins: Not sure :-/ | 23:05 |
| awilkins | I have the latest windows SDK, which is MSVC 9 | 23:05 |
| awilkins | Python 2.5 was built on MSVC 7 | 23:05 |
| * awilkins has very few clues as far as C goes | 23:06 | |
| awilkins | I mostly stick to languages that link dynamically and don't whine about it. | 23:06 |
| jelmer | I think it's worth a try to check with MSVC9 | 23:07 |
| awilkins | jelmer: I'm not convinced IU've got the libraries right ; they all have different names on Win32 | 23:08 |
| awilkins | But I got the object files to build | 23:08 |
| jelmer | alternatively, you could avoid the dot notation, but that's quite a lot of work | 23:09 |
| tethridge | anybody know the size of the mysql repository? | 23:12 |
| awilkins | jelmer: MSVC 9 hates that syntax too | 23:14 |
| jelmer | hmm, it's standard C99 | 23:14 |
| jelmer | awilkins, what's the error exactly? | 23:14 |
| mwhudson | msvc will probably never support c99 | 23:15 |
| awilkins | I'll paste | 23:15 |
| mwhudson | for fun and games echoing down the years | 23:15 |
| awilkins | http://pastebin.ca/1054580 | 23:15 |
| * awilkins switches back to mingw | 23:16 | |
| awilkins | Hmm, are warnings like "defined locally after being referenced with dllimport linkage" relevant? | 23:20 |
| beuno | hrm... | 23:28 |
| beuno | anyone know what this could be: | 23:28 |
| beuno | beuno@beuno-laptop:~/bzr_devel/loggerhead.no_bundles$ bzr push lp:loggerhead | 23:28 |
| beuno | Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) | 23:28 |
| beuno | bzr: ERROR: Pack '13c6ba3d1a8d731ec8f18bfb908585d6' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x89eb72c> | 23:28 |
| beuno | I've never seen that :/ | 23:28 |
| beuno | hm, while autopacking... | 23:29 |
| mwhudson | beuno: try again i think | 23:30 |
| beuno | abentley, I see you worked on a bug related to that, is this what it fixed (I'm running bzr.dev, but maybe it's on the LP side): http://paste.ubuntu.com/22456/ | 23:33 |
| beuno | mwhudson, that worked, thanks | 23:33 |
| igc | morning | 23:37 |
| beuno | mornin' igc | 23:38 |
| igc | hi beuno | 23:38 |
| beuno | Jc2k, incidently, while working on the gnome theme for LH, I found you have an unclosed <li> in the header: <li><a href="http://live.gnome.org/BzrForGnomeDevelopers"><span>Bazaar wiki page</span></a><li> | 23:40 |
| lifeless | beuno: oh! | 23:45 |
| lifeless | beuno: that bug is biting pqm for launchpad developers | 23:45 |
| awilkins | jelmer: Look like libraries ; I don't the the auto-library-finding is quite so luxurious on Win32 ; you can look at the horrible pathes I've had to do afterward | 23:45 |
| lifeless | mthaddon: ^^^^ | 23:46 |
| lifeless | beuno: could you make sure there is a bug exactly matching that, and grab all log details possible etc | 23:46 |
| beuno | lifeless, sure. I see two of them, but it could be related to either | 23:46 |
| beuno | bug #165293 and #212908 | 23:47 |
| ubottu | Launchpad bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed] https://launchpad.net/bugs/165293 | 23:47 |
| ubottu | Launchpad bug 212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Fix committed] https://launchpad.net/bugs/212908 | 23:47 |
| mwhudson | neither of those bugs mention autopacking | 23:49 |
| lifeless | beuno: the thing is, push shouldn't trigger either under normal circumstances | 23:50 |
| beuno | alright, new bug, here I come | 23:50 |
| lifeless | beuno: either we're hitting md5 collisions in loggerhed (a possibility) | 23:50 |
| lifeless | or, something is funky | 23:51 |
| lifeless | mwhudson: can you grab a copy of the launchpad data for the branch beuno was pushing too | 23:51 |
| lifeless | beuno: can you take a copy of your branch & repository that you pushed from, so we can reproducce | 23:51 |
| mwhudson | lifeless: i think when beuno pushed again, it worked | 23:51 |
| beuno | it did | 23:51 |
| lifeless | mwhudson: we can rollback one push | 23:51 |
| mwhudson | lifeless: ok | 23:51 |
| lifeless | mwhudson: through the magic of robert | 23:52 |
| jam | abentley: I have a question about bzrlib.merge.transform_tree | 23:52 |
| lifeless | (but only if we have the obsolete packs etc). Its not guaranteed but should be doable | 23:52 |
| mwhudson | beuno: which branch was it? | 23:52 |
| jam | abently: If I do: merge.transform_tree(tree, tree.basis_tree(), [file_id]), shouldn't it revert that text to the value in the basis? | 23:52 |
| beuno | mwhudson, a branch I did lh.dev -> lh.feature -> commit -> push to trunk | 23:53 |
| mwhudson | beuno: can you not push over non-lefthand parents to trunk please? | 23:54 |
| mwhudson | if that's what you did | 23:54 |
| mwhudson | lifeless: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk, er, interesting | 23:54 |
| lifeless | mwhudson: set allow_append_revisions_only=True (or whatever the setting is - 'bzr help configuration') | 23:55 |
| beuno | mwhudson, you mean, merge in trunk and push? Ah, yes, I can see how that's annoying, sorry | 23:55 |
| lifeless | mwhudson: you'll want to uncommit the tip | 23:55 |
| beuno | mwhudson, that's now what I just did though | 23:56 |
| lifeless | mwhudson: or push --overwrite, to restore it | 23:56 |
| mwhudson | beuno: can you clean it up? | 23:56 |
| mwhudson | feel free to push --overwrite or whatever | 23:56 |
| lifeless | mwhudson: did you get a copy of the repo already ? | 23:57 |
| beuno | mwhudson, sure, I'll clean it up now and overwrite | 23:57 |
| mwhudson | lifeless: so i have two tarballs of the branch, one from the push area, one mirror | 23:57 |
| beuno | well, after you copy whatever you need to debug :) | 23:57 |
| mwhudson | lifeless: ye | 23:57 |
| mwhudson | s | 23:57 |
| mwhudson | lifeless: what did you want me to do with them? | 23:57 |
| lifeless | mwhudson: thanks, drop them on devpad | 23:57 |
| lifeless | beuno: can you mail me the copy of your repository & branch too | 23:57 |
| beuno | mwhudson, sure, on it's way | 23:57 |
| mwhudson | beuno: thanks | 23:58 |
| beuno | er, lifeless | 23:58 |
| === eMxyzptlk[away] is now known as eMxyzptlk | ||
| lifeless | beuno: thanks | 23:58 |
| beuno | just finishing filing the bug | 23:58 |
| lifeless | I'm so tempted to repeat by mini-python-dbs-suck rant | 23:58 |
| tolstoy | If I tag in a repo, push it to a server, then, from somewhere else, pull from that server, how come I don't get the new tags? | 23:58 |
| * mwhudson gets confused by network reachability in the data centre | 23:59 | |
| bob2 | tolstoy: iirc push doesn't push tags unless it also has some other data to push | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!