[00:00] hi [00:00] Ok, so I'm trying to branch mysql-server/5.1 from launchpad [00:00] I've set my launchpad login using "bzr lp-login" previously [00:00] but now the branching fails with a Permission denied (publickey) error message [00:01] I just want a checkout, nothing fancy. [00:01] uws: its using bzr+ssh [00:01] so? [00:01] uws: the lp: foo doesnt know whether your pulling or pushing, so always goes through bzr+ssh [00:01] uws: and your public key is either not registered with lp, or no available to your local ssh [00:02] note that I'm not involved with mysql, is that a requirement? [00:02] no [00:02] mkanat: having fun yet? [00:02] uws: not at all [00:02] uws: 09:01 < lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh [00:02] mwhudson: I thought it might be trying my login first, and failing in falling back to anonymous checkout. [00:02] anyway, I'll check my ssh keys\ [00:04] ah, there we go. Launchpad only knew about my laptop's ssh key [00:04] thanks [00:05] cool [00:16] _argh_ evolution [00:17] gcc -version [00:17] oops [00:19] jelmer: Those C extensions are not compiling for me. [00:21] poolie_: I'm going to try to finish stacking-kints today === rockstar_ is now known as rockstar [00:25] awilkins: what errors do you get? [00:26] mwhudson: I get [00:26] Firefox has detected that the server is redirecting the request for this address in a way that will never complete. [00:26] initializer element is not constant [00:26] lifeless: Hmm, looks like it's failing to do proper caching in the case of bzr-search [00:26] mwhudson: when trying server-branches [00:26] lifeless: Looking into it further... [00:26] jelmer: thanks [00:26] jelmer: its lock_read'd, and fast on bzr branches [00:26] lifeless: hm [00:26] 500MB/hour now [00:26] jelmer: core.c (73) ; looks like it doesn't like the sizeof call setting the initial value [00:27] jelmer: This is gcc 3..4.5 [00:27] lifeless: more details? which directory are you running from, what url are you trying to view? [00:27] mwhudson: http://www.robertcollins.net/ [00:28] mwhudson: I cd'd to that dir on the fs; ran python ~/source/loggerhead/bzr-search.integration/serve-branches.py; [00:28] mwhudson: clicked on config-manager [00:28] (note my html pages are woefully old; ignore that aspect :P) [00:29] config-manager/ has a subdir trunk that is a branch [00:29] config-manager/ is not a repository [00:29] i wonder if this is dir -> dir/ redirection going strange then [00:30] lifeless: hi [00:30] the url that it wanted was config-manager/, yes [00:30] poolie_: ho [00:30] awilkins: Hmm, that's an old version [00:30] awilkins: core.c is not there anymore [00:30] awilkins: What branch are you using? [00:30] lp:bzr-svn [00:30] awilkins: the mirror is probably out of date [00:31] http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [00:31] * awilkins pulls [00:31] lifeless: i can't reproduce here [00:32] lifeless: are there proxies involved or anything? [00:33] http://rafb.net/p/q5BkUZ65.html [00:33] mwhudson: not yet [00:34] jelmer: Darn, more setup.py blues [00:34] lifeless: paste version? [00:35] feisty [00:35] lifeless: as in, which version of python-paste [00:35] hmm [00:35] jelmer: apr-config naturally doesn't run on Windows so I have this awesomely bad patch to make it work :-| [00:35] mwhudson: 1.1.1-1 [00:35] ok, that's definitely older than what has been tested so far [00:35] * mwhudson goes to try to find a changelog [00:36] its on my todo to upgrade [00:36] but, time. [00:36] yeah [00:38] jelmer: Right, It's too late to hack this into shape, I'll get back to it. Gnight [00:38] lifeless: changes from 1.1 -> 1.2: [00:38] * Regression in 1.1 fixed, where Paste's HTTP server would drop [00:38] trailing slashes from paths. [00:39] mwhudson: fuckers. [00:39] why can't all software have /tests/ [00:51] like loggerhead, for example... [00:53] mwhudson: this is a bit of a show stopper though ;P [00:53] lifeless: i don't really have any good ideas [00:54] for starters, document paste 1.1 as fuxored and check it at startup [00:54] python-paste is pure python, there's a good chance the deb from hardy will install fine i guess [00:54] mwhudson: na-uh, python-central [00:54] mwhudson: pure python doesn't mean what you think it does in a binary distribution world [00:55] well, perhaps [00:56] but getting a newer version installed somehow shouldn't be difficult === mark1 is now known as markh [00:57] it would be a backport [00:58] I'm not terribly interested in doing that; I'll just not play with loggerhead for a while [00:58] 'for a while' -- until you get around to dist-upgrade? [00:58] yes [00:58] probably august or so [01:04] 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:05] well, you could probably just untar a paste release and use PYTHONPATH [01:05] which then becomes a sysadmin thing-to-remember [01:06] and for my home server I want as close to 0 of them as possible [01:06] its not a _high_ burden, but they sum [01:06] and it deifnitely raises the effort past what I'm willing to do to experiment with loggerhead [01:07] - its not 'easy' at this point [01:09] well, ok [01:09] 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] i can't really see anything i can do to help here [01:09] mwhudson: as a consumer of it, its a different feel to a developer [01:10] 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:11] gutsy has paste 1.4 that i suspect will work [01:11] _my_ interest in supporting feisty is not so large [01:11] I have a sinking feeling about freebsd though [01:12] I'm not looking forward to finding out what version it has [01:12] fullermd: feel free to give me good news about now [01:12] [19:12:09] mortis:/usr/ports/www/py-paste (ttyp9):{550}% make -V PORTVERSION [01:12] 1.6 [01:12] ok, thats good news [01:13] 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] i'd like to monkeywrench tg [01:13] fullermd: to be fair, I suspect that's tg's fault [01:13] i guess it's not a problem for me any more [01:13] mwhudson: what would it take to make bb not need tg ? :) [01:14] lifeless: oof [01:14] don't know, probably quite a bit i guess [01:14] because BB is still not properly operational for squid [01:21] lifeless: It would require an alternative identity layer. [01:21] mwhudson: Sorry, was away for a bit there. [01:21] mwhudson: I'm back now, I'll try that patch. [01:21] abentley: thats a tg supplied thing ? [01:22] Yes, it handles users, groups, permissions, passwords, that sort of thing. [01:22] k [01:23] lifeless: believe me, I've thought about it. [01:23] abentley: :> [01:24] mwhudson: Yep, that does it. I have to make webpath = '', though, not actually comment it out. [01:25] mkanat: hm, strange, but glad you've got something working [01:26] mornin' [01:27] mwhudson: Without it I get: http://pastebin.ubuntu.com/22252/ [01:28] mkanat: with this patch? http://pastebin.ubuntu.com/22228/ [01:29] Oh, hmm. [01:30] but anyway, it works, good :) [01:30] mwhudson: Ah right, when I use teh *actual* patch it works, yes. :-) [01:31] Now let's see if I can figure out what's causing those tracebacks. [01:37] mwhudson: Unfortunately GoogleBot doesn't send referers. :-( [01:37] mkanat: yeah :/ [01:38] abentley: hi, did you notice the mail/branch about BB on mysql? :-) [01:38] mkanat: can you see what the file id in the url is for? [01:38] Verterok: I see it now. [01:39] 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] Verterok: I want to migrate to postres [01:39] ups :P [01:39] mwhudson: It's for a file. [01:40] mkanat: any particular one? [01:40] I can abstract the scripts to have multiple dest. engine [01:40] or is it a variety? [01:40] mwhudson: It's a variety. [01:40] hum [01:40] mwhudson: However, they're all in the same branch, which might actually have errors in it, since it was made by cvsps-import. [01:41] i can't really imagine how a branch could be _this_ broken :) [01:42] 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] mwhudson: Hmm, might be a race condition--I can open that URL fine. [01:42] mkanat: ?? [01:43] but i thought you said it was a file id for a file? [01:43] markh: You're right. I saw what I expected to see, not what was there. [01:43] mwhudson: I picked out one of the URLs that caused a traceback, and when I open it, there's no problem. [01:43] 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:44] if I use a bzr.exe from a binary package, it works correctly [01:44] mkanat: that's really odd [01:44] 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] my bzr is probably not finding paramiko - is there a recommended way to enable debugging messages for that kind of thing? [01:45] markh: So the problem is that the orig_error param is being misused. [01:45] abentley: yes, that that seems true [01:46] well, that is *a* problem, not *the* problem ;) [01:46] markh: There are other problems remaining? [01:47] mwhudson: Well, it's not causing any visible problem anyhow. [01:47] mkanat: ok [01:47] well - the original problem was simply the recommendation to "-D..." - thats independent of the orig_error abuse :) [01:47] 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] 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:48] mwhudson: My non-auto-publish branches have the correct URL. [01:48] I do see a message "No supported authentication methods left to try!" so putty is trying to do someting [01:48] mwhudson: Because I specified it, of course. [01:48] but my "connectivity and permissions" are fine (which is what bzr suggests I check) [01:49] mkanat: this is probably my url_prefix fix being wrong [01:49] abentley: so even if that isn't really a bug in bzr, any suggestions how I can diagnose what is missing myself? [01:51] (to be clear - putty etc is all setup fine - it works perfectly if I use 'bzr.exe' instead of a source distro) [01:54] have you tried -Dtransport? [01:54] hi lifeless - tried nothing yet, still fishing for clues. I'll try it! [01:56] Output appears identical with -Dtransport [01:56] log too [01:56] ok [01:56] uhm [01:56] python -c 'import paramiko' [01:56] yeah, I'm confident that will fail [01:57] but how could I have bzr tell me that? :) [01:57] ie, I'm not sure what else I don't know I don't have! [01:58] markh: the suggestion to use D... was orig_error abuse. [01:59] 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] mkanat: try this: http://pastebin.ubuntu.com/22255/ [02:00] as usual, take one bug, get a few for free! [02:01] markh: If you want to act clever, that's fine. But I don't need to be involved. [02:01] abentley: sorry, that wasn't my intent [02:02] mwhudson: Yes, that works! :-) [02:03] mkanat: cool, i'll commit it then [02:03] * markh gets back in his box... [02:03] markh: If you want to diagnose why putty can't make a connection, I'd start by running putty. [02:03] 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] putty can connect fine [02:04] mwhudson: No, that works. [02:04] mwhudson: I just had read the patch wrong (I did it manually). [02:04] markh: I wasn't even aware that putty could be used for this. I would have thought plink [02:04] mkanat: i'd like to remain compatible with old loggerhead.conf files [02:05] Ahh. [02:05] But I guess the next step would be to find out what line bzr is emitting to connect. [02:05] yes, putty's plink [02:05] So to be clear: plink can connect just fine? [02:07] yes, plink can connect fine. Putty's pageant is the only program with my ssh key loaded [02:08] so when bzr.exe successfully does ssh, I expect that is also via plink [02:08] but when 'python bzr' does not connect via ssh, the bzr log still indicates it is using putty's plink [02:09] markh: I wouldn't be surprised if bzr.exe is using paramiko. [02:09] bzr can use pagent. [02:10] 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:11] markh: we use paramiko for sftp logic, not encryption [02:12] markh: What makes you say pagent uses plink? I would have assumed that plink uses pagent, not the other way around. [02:12] I meant paramiko uses plink (or at least it has *some* interaction with putty's suite - it talks to pageant's window iirc) [02:13] markh: It interacts directly with pagent AIUI. [02:13] It does not have to invoke plink to do it. [02:14] ok - but I'm confident pageant/plink/putty etc are all configured correctly [02:15] abentley: how does make_mpdiffs returning a dict sound to you? [02:15] abentley: (that or (key, diff) tuples) === timely is now known as timelyx [02:17] lifeless: I'd prefer key, diff tuples, so the API doesn't demand loading many file versions in memory at once. [02:19] abentley: ok [02:19] markh: So you probably want to look at bzrlib.transport.ssh.PLinkSubprocessVendor [02:19] 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] abentley: and as we have a massive api break occuring this would be timely [02:22] lifeless: If we're breaking the API, maybe it should accept keys instead of revision ids. [02:48] hmm [02:48] poolie_: can I call ? [02:49] hmm EAFTP I guess :P [03:34] What's this? API changes which could reduce memory use? :) [03:34] (last time I did a "bzr branch lp:bzr", it failed until I allocated 200+MiB RAM for it) [03:35] ToyKeeper: heh. I have test cases that chew up 3-4GB of ram [03:41] 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] It's easy to bump up the limit, at least. :) [03:55] hey mwhudson_ [03:55] hi beuno === mwhudson_ is now known as mwhudson [03:55] I did notice it. Scratched an itch I had :) [03:55] how was your weekend? [03:56] fine, fine [03:56] we're moving this week, so lots of packing and tidying [03:56] ah, and maybe a better ISP? :) [03:56] we shall see [03:58] beuno: i played with the merge proposal stuff in launchpad, you probably got some mails about that [03:58] 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] beuno: i'd like you to look at it, yes [03:59] so [03:59] the big thing remaining for gnome seems to be branding? [03:59] Jc2k: ^? [04:00] 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:01] beuno: i think trivial stuff is ok to push directly, but if in doubt get it reviewed [04:01] (not necessarily by me, i suppose) [04:01] anyone have any experience serving a repository over bzr+ssh on a chrooted shell? [04:02] not directly; but in theory yes [04:02] whats up [04:03] 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] I don't see why bzr would care about that [04:04] me neither, hehe [04:06] well, why do you think it is the root dir owner thats the problem? [04:06] I was getting an error message along those lines in auth.log [04:07] jelmer: around? [04:07] whats auth.log [04:07] its not a bzr file [04:07] it's the log file that ssh logs error messages to, located in /var/logs [04:08] er, /var/log [04:08] mwhudson, I get OOPS-905EB7 when reviewing your merge request :) [04:08] sounds like ssh is having the problem then [04:08] beuno: :) [04:08] [I need more detail - I can't guess at what an error message I haven't seen means] [04:09] mwhudson, seems it works if I specify the *optional* subject [04:09] beuno: oh that [04:09] poolie_: ping [04:09] it's a known bug, to be fixed soon [04:10] does this merge automagically? [04:10] * igc lunch [04:10] beuno: no [04:11] oh, this does remind me [04:11] serve-branches.py currently just sticks the cache in some temporary directory [04:11] this probably isn't totally smar [04:11] t [04:12] serve-branches.py doesn't use anything from loggerhead.conf, right? [04:13] haha [04:13] 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:14] beuno: right [04:15] mwhudson, is that out of choice or just "was faster at the time"? [04:15] beuno: a bit of both, but mostly the former [04:17] so the plan is to use something else for configuration? [04:17] co [04:17] beuno: you perhaps do me a bit too much credit to assume i have a plan :) [04:18] hahaha [04:18] I may be still a bit naive, I'll get over it eventually [04:18] wee [04:18] well [04:18] i guess the first thing to decide, in fact, is: what configuration do we actually need? [04:19] s/we/people/ [04:19] what port to run, where to cache, and what to publish, for starters [04:20] I suppose then it would get expanded to *what* to cache (search, ie), and new features like exporting tarballs and serving repos [04:20] proxying details [04:21] is there something very wrong about the current conf file? [04:22] maybe it still has some turbogears stink on it [04:22] 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:23] i think that's my main complaint [04:23] and yeah, it's a bit tg-ish [04:25] 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] no [04:25] to be honest, the main use cases i've been thinking around are [04:26] ... [04:27] uhm, my X restarted for no apparent reason [04:27] beuno: wb [04:27] L) [04:27] so, last I read was what you where thinking of [04:28] (1) zero configuration (serve-branches.py) [04:28] (2) Launchpad (custom WSGI glue) [04:28] i'm less sure of a good answer for a middle ground [04:29] 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:31] 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:32] 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] adding per-branch configurations seems to me like a normal operation [04:32] hmm? [04:32] (2) Implies coding, right? [04:33] tweaking a .py file? [04:34] i'm not saying that these are the only things we should support [04:34] but rather that these two cases are where the bulk of my thinking has gone so far [04:34] ah, ok. Well, maybe we can work something out on a wiki page or something [04:35] zero configuration is good to have, will get people using it faster [04:46] sigh [04:46] mwhudson_: I believe you can buy it in a box [04:58] it's a bit odd to get an email for a merge request, and then for a review request [04:58] isn't a merge request a review request by itself? [05:03] reviewing jam's iter_references patch now [05:03] mwhudson, LH is misbehaving in LP again. "Please try again" pretty often [05:04] 14:03 < beuno> mwhudson, LH is misbehaving in LP again. "Please try again" pretty often [05:04] mwhudson_: who is your ISP === mwhudson__ is now known as mwhudson [05:04] lifeless: ihug [05:05] oh [05:05] i think it's problems with the line, but i'm moving in three days [05:05] I don't know that it is :P [05:06] hm, it's codehosting that's bashing vostok currently [05:08] beuno: so re bug 240512, i think your change will sort symlinks after directories and files [05:08] Launchpad bug 240512 in loggerhead "Files view should show/sort directories before files" [Medium,In progress] https://launchpad.net/bugs/240512 [05:08] beuno: is that what we want? [05:08] 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] I don't think we want that [05:09] So I've been working on a thread in a loom. [05:10] And I've realised that the top thread should actually be the next-to-bottom thread. [05:10] make a new thread over it it [05:10] merge -r thread:thing..thread: . into it [05:10] commit [05:10] 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] combine-thread the one you want to get rid of [05:10] up-thread and commit till its all resolved [05:11] get on wif ur life [05:11] hmm [05:11] lifeless: that merge will lose my commit history, right? [05:11] actually, I think you need to do a reverse merge too into the one you're removing the change from [05:11] there is a TODO about making this easier [05:11] jml: yes, see under 'its a cherrypicking problem' [05:12] lifeless: just checking. I'm ok with losing history this time, I think. [05:13] beuno: well i think that's crazy :) [05:13] I think matching nautilus is ok [05:13] mwhudson, all other applications I've fired up do it that way [05:13] what kind of ordering is "directories first then"? [05:14] as in, how would I go back to it once I order by name? [05:14] the finder doesn't put folders first :) [05:14] but i guess i don't care very much [05:15] mwhudson, it doesn't order directories first by default? [05:15] no [05:16] and that doesn't feel wrong to you? [05:16] when you order by name, it put things in ... name order [05:16] and how do you go back to ordering by directory-first? [05:16] i have to admit, i don't use a graphical file browser very much at all on any system [05:16] beuno: you don't [05:17] that's what I was worried about :p [05:24] lifeless: oh my client had disconnected that's why i didn't see it [05:24] poolie_: ah [05:24] poolie_: you use a irc poxy? [05:24] ssh to a server [05:24] running screen [05:25] how do I make a thread in a loom between two? [05:25] does create-thread make it directly above the current thread? [05:25] yes [05:26] ta [05:28] With PrefixMiddleware in serve-branches.py, shouldn't there be arguments passed to it? Is it just example code? [05:30] Peng: no, it works off x-forwarded-server [05:31] you might need to add a prefix [05:31] Oh. [05:31] Yeah. [05:31] I am using a prefix. [05:31] then yeah, you need to edit code [05:32] if you can tell me how you'd like to specify this sort of thing, then i can see what i can do :) [05:33] Oh, I dunno. [05:33] Maybe just a "prefix = None" line you can edit. [05:34] 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:35] * Peng wanders off. 24 is on! [05:35] when I up-thread in a loom, should I commit? [05:35] hmm [05:35] status seems to indicate I should [05:36] if there were unintegrated changes, yes [05:36] up-thread is 'switch and then merge ' [05:36] 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:38] Suigintou: that would cause bzr some trouble, yes. [05:38] lifeless: I am quite enjoying my first use of looms-in-anger [05:38] thumper: great [05:38] * thumper makes note to write about it [05:53]