| igc | morning | 00:24 |
|---|---|---|
| === blueyed_ is now known as blueyed | ||
| spiv | Hmm, I could add a post-commit hook to the better-news-merge branch that warns if you are committing a NEWS file that isn't in the canonical format (non-alphabetical bullets, etc) | 01:49 |
| spiv | Er, or pre-commit even. | 01:49 |
| lifeless | with code ? | 01:50 |
| lifeless | spiv: are you asking 'what hook to use' ? | 01:51 |
| lifeless | oh ignore me, I misread 'I could' as 'how do I' | 01:51 |
| spiv | Right. | 01:51 |
| spiv | I'm just musing out loud. | 01:51 |
| lifeless | <- thwack | 01:51 |
| lifeless | spiv: you could do a start commit one instead, that just fixes it. | 01:52 |
| spiv | I just realised I have most of the code already, and it would help devs catch "oops I forgot to put the bullet in the right spot" | 01:52 |
| spiv | That'd be neat too. | 01:52 |
| lifeless | spiv: or even a filter :> | 01:52 |
| spiv | Perhaps we could have a merge-hook that is configured on the PQM instance to merge a detached NEWS entry into its final home (i.e. into the appropriate section of whatever the current release is). | 01:53 |
| spiv | To avoid the "I wrote the NEWS entry before the 2.1.1 release, but my change landed after 2.1.1 was released" problem | 01:54 |
| lifeless | spiv: as long as it doesn't break 2.1->2.2 and similar merges | 01:54 |
| spiv | *nod* | 01:54 |
| lifeless | I think its worth heading towards | 01:55 |
| spiv | There's also the Twisted-style solution: build up a directory of newsfiles/$bugnumber.$kind, e.g. newsfiles/1234.feature or newsfiles/2345.bug | 01:56 |
| poolie | that could be better | 01:56 |
| poolie | spiv does it run in pqm yet? | 01:56 |
| poolie | that could be a good next step | 01:56 |
| poolie | though perhaps pqm is being tortured enough right at the moment | 01:56 |
| lifeless | I find the directory approach a bit ugly tbh | 01:56 |
| lifeless | I don't see that its really any easier or better | 01:56 |
| spiv | And only build them into a single file at either release time or maybe build time. | 01:56 |
| poolie | it is a kind of a workaround for an insufficiently good tool | 01:57 |
| poolie | there's also the issue of how to represent the DAG of releases | 01:57 |
| poolie | that 2.2b2 includes 2.0.6 etc | 01:57 |
| spiv | Yes. | 01:57 |
| lifeless | I think that we're heading into diminishing returns for now | 01:57 |
| spiv | As a reader of the NEWS file, I'd like to see the 2.0.6 entries repeated under the appropriate 2.2 release. | 01:58 |
| spiv | But as a developer I find it a PITA :) | 01:58 |
| poolie | spiv, so for me the most useful thing at the moment would be a mechanism/document for how to do your own merge code | 01:58 |
| poolie | eg how to call an arbitrary shell command to merge them | 01:59 |
| poolie | oh, or the thing of making some files always conflict | 01:59 |
| poolie | but for today i'm going to look at the loggerhead mp queue | 01:59 |
| poolie | igc: the top refererer to loggerhead was this blog post: | 02:08 |
| poolie | http://www.outflux.net/blog/archives/2010/02/18/data-mining-for-nx-bit/2/18Q | 02:08 |
| poolie | and it is pretty interesting | 02:08 |
| poolie | http://www.outflux.net/blog/archives/2010/02/18/data-mining-for-nx-bit/ | 02:08 |
| lifeless | ok, pqm is currently executing with bzrlib 1.17 | 02:09 |
| lifeless | so we'll need a potentially risky upgrade to do news-merge; will look at it with spm probably next week | 02:09 |
| poolie | it's probably not urgent then | 02:15 |
| poolie | perhaps we should defer until after the lucid release and uds | 02:15 |
| lifeless | I think we should do it as time permits | 02:16 |
| lifeless | if folk are busy, defer, otherwise do. | 02:17 |
| lifeless | I guess I mean that if make it clear to the losas that its not high priority they can guide us as to their stress levels and fit it in accordingly | 02:19 |
| poolie | ok; i think we should let them know to expect some fallout | 02:19 |
| poolie | well, they probably would already | 02:20 |
| lifeless | right - potentially risky as I say :) | 02:21 |
| lifeless | after thats in place we can look at turning on news merge for it | 02:22 |
| lifeless | we should also look at turning on news merge on lp | 02:22 |
| lifeless | for mp reviews | 02:22 |
| lifeless | poolie: the code in | 02:26 |
| lifeless | https://code.launchpad.net/~salgado/launchpad/meliae-librarian/+merge/23771 might be interesting | 02:26 |
| poolie | ooh | 02:32 |
| jrmorrisnc | hi I need to present a comparison of bazaar versus CVS to my team at work. Any good resources? | 05:08 |
| spiv | jrmorrisnc: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html and http://wiki.bazaar.canonical.com/BzrForCVSUsers | 05:12 |
| spiv | jrmorrisnc: there are probably others too, but not at my fingertips :) | 05:12 |
| jrmorrisnc | ty | 05:12 |
| mkanat | spm: Hey. How long does the loggerhead check wait until it assumes that codebrowse has failed to respond? | 05:13 |
| spm | mkanat: hey max; 3 tries of ~ 10 secs each | 05:13 |
| mkanat | spm: Ahh. | 05:13 |
| mkanat | spm: You might want to up that to 15 seconds. | 05:17 |
| spm | mkanat: I *believe* that's not technically possible. nature of how the beast is assembled across all the servers.... | 05:17 |
| mkanat | spm: Ahh. | 05:17 |
| spm | I think we can increase to 5 tries tho. | 05:18 |
| spm | which'll have the same effect. | 05:18 |
| mkanat | spm: Well, no, that might make it worse. | 05:18 |
| spm | oh? | 05:19 |
| spm | too much repeated polling? | 05:19 |
| mkanat | spm: Yeah, the problem is that sometimes loggerhead gets slow, and you're asking it to do something that might be slow. | 05:19 |
| mkanat | spm: So if you ask multiple times when it's not completed, at the least it's making the problem worse. | 05:19 |
| spm | excellent | 05:19 |
| mkanat | spm: Is it the sort of checker that looks for a string in the page, or just tests for a 200 response? | 05:24 |
| spm | I think both. lemme verify... | 05:25 |
| mkanat | spm: Okay. | 05:25 |
| spm | mkanat: /usr/lib/nagios/plugins/check_http -H bazaar.launchpad.net -u /~vcs-imports/busybox/main/changes -e " 200 OK" | 05:26 |
| mkanat | spm: Okay, so it's just a 200 check. | 05:27 |
| mkanat | spm: There's not also a string checker? | 05:27 |
| spm | istr the -e bit is to ensure we catch 3xx's & 4xx's as fatal | 05:27 |
| spm | not on that one, no. we do on some other services. | 05:27 |
| mkanat | spm: Okay. | 05:28 |
| * spiv -> food | 05:28 | |
| spm | spiv: get a 2400 baud odem while you're at too eh? | 05:28 |
| mkanat | spm: Ah ha. So sometimes, the checker is getting a 500. | 05:42 |
| spm | mkanat: that... that sounds about right - relying on my memory | 05:43 |
| mkanat | spm: Ah, okay. | 05:43 |
| mkanat | spm: So this is more a crash than a hang, in a way. But effectively loggerhead is non-responsive. | 05:44 |
| spm | sounds a fair description :-) | 05:44 |
| mkanat | spm: Oh, okay, I found an actual hang in the log. | 05:54 |
| spm | mkanat: ah! so we are getting real hangs? I was somewhat in a context free zone responding to that bug report. and it showed. ;-) | 05:55 |
| mkanat | spm: That's OK. I think we might actually be getting multiple different hangs and other bugs. | 05:55 |
| mkanat | spm: I suspect there are at least two hang bugs, maybe three. And then there's a bug that causes loggerhead to throw a bunch of KeyErrors. | 05:55 |
| spm | luveryly | 05:55 |
| mkanat | spm: The problem is that I can't reproduce *any* of the hangs locally. | 05:56 |
| mkanat | spm: So I'm totally dependent upon reading logs in detail and looking at the stack traces that I get from y'all. | 05:56 |
| spm | mkanat: :-) and more importantly: is "y'all" the correct spelling? I've been doing "ya'll".... but not being a native of the USA.... | 05:57 |
| dash | spm: it's a contraction of "you all" | 05:57 |
| mkanat | spm: Yeah, it'd be y'all, because "you" is contracted. | 05:57 |
| dash | and the only sensible plural of "you" that I know of :) | 05:57 |
| mkanat | dash: Agreed. I'm not living in the South anymore, but I still use it as the second person plural from time to time. | 05:58 |
| spm | ha. I thought it was one of those phrases like 'crikey' that is only used in the piss-taking sense. | 05:59 |
| fullermd | But... y'all is singular. | 06:00 |
| fullermd | "all y'all" is the plural. | 06:00 |
| dash | fullermd: die in a fire, etc | 06:00 |
| fullermd | 8-} | 06:00 |
| dash | spm: no, i say it pretty consistently | 06:00 |
| spm | dash: I may never look at you the same way again. :-P | 06:01 |
| spm | Naturally, this is coming from the perspective of "Teasing Americans being an Australian National Sport" perspective... so..... | 06:02 |
| * spm also notes the reaction to fullermd's "all y'all" sugegstion and takes additional notes for later abuse | 06:03 | |
| * fullermd is a helper! | 06:03 | |
| lifeless | -> food | 06:20 |
| mkanat | fullermd: lol | 06:21 |
| lifeless | you're missing the 'now | 06:21 |
| lifeless | y'all die in a fire, now | 06:21 |
| mkanat | lol | 06:21 |
| mkanat | Where does tuned_gzip come from? I see people import it from bzrlib but I don't see a definition in bzrlib/__init__.py. | 06:28 |
| mkanat | Oh, nevermind. | 06:28 |
| mkanat | Haha. Found it. Duh. | 06:28 |
| lifeless | mkanat ;) | 06:53 |
| mkanat | lifeless: Is there any known thread-unsafety inside of the btree_index pyx stuff? | 06:54 |
| lifeless | the usual about sharing objects | 06:54 |
| mkanat | lifeless: Like sharing a repository object between two threads and then attempting to call the btree_index methods on it? But that should normally be prevented by...oh, no, it wouldn't be by two read locks. | 07:00 |
| lifeless | mkanat: at a high level, yes. | 07:01 |
| * mkanat nods. | 07:01 | |
| lifeless | the lru cache bug we had was a global with the same issue | 07:02 |
| mkanat | lifeless: Specifically an issue with the btree_index, or just a thread-safety issue with the pyx code? | 07:03 |
| lifeless | mkanat: neither, just a data structure being updated without a thread mutex around it | 07:03 |
| mkanat | lifeless: Ah, okay. | 07:03 |
| lifeless | mkanat: and because the chk_map module has a global cache object | 07:03 |
| mkanat | lifeless: Ah, okay. | 07:04 |
| lifeless | mkanat: calls from different repos were interacting with the global cache, and *boom* | 07:04 |
| lifeless | loggerhead told us about it :P | 07:04 |
| vila | hi all ! | 07:17 |
| poolie | hi vila | 07:17 |
| vila | lifeless: what's the status on pqm ? I still see some of the merges that were queued yesterday :-/ | 07:18 |
| vila | hi poolie :) | 07:18 |
| vila | lifeless: having *no* feedback on failures is really frustrating :-( | 07:19 |
| fullermd | You mean "hi y'all" O:-> | 07:19 |
| poolie | yeah, john complained about this too | 07:19 |
| lifeless | vila: its extremely frustrating | 07:19 |
| igc | hi vila | 07:19 |
| lifeless | vila: I'm polling losas hourly to find new exceptions and have two bugs in launchpadlib/launchpad that are affecting us: | 07:20 |
| igc | hi fullermd, mkanat | 07:20 |
| vila | fullermd: I tried to decipher the discussion about that but coudnn't make sense of it (apart from spm teasing americans people that is :) | 07:20 |
| poolie | is it true that if you submit by mail you get a reply in the regular way? | 07:20 |
| lifeless | vila: a 110 timeout error with no obvious reason - you might be able to help with that | 07:20 |
| lifeless | vila: as its ssl related | 07:20 |
| vila | poolie: not my case yesterday | 07:20 |
| spm | vila: glad you understood the important part. ;-) | 07:20 |
| lifeless | vila: and a 502 gateway error which is apparently backend flakiness + launchpadlib not retrying | 07:20 |
| poolie | lifeless: can we reevert whatever broke that? | 07:20 |
| lifeless | we can disable the lp api usage entirely by removing the config option./ | 07:21 |
| vila | lifeless: logs ? tracebacks ? Anything I can chew ? | 07:21 |
| lifeless | https://bugs.edge.launchpad.net/launchpadlib/+bug/380504 is the 502 one | 07:22 |
| ubottu | Launchpad bug 380504 in launchpadlib "Handle HTTP Error 502: Bad Gateway automatically" [High,Triaged] | 07:22 |
| poolie | there's no easy way to just take it out of the codepath of non-api-based merges? | 07:22 |
| lifeless | poolie: no | 07:22 |
| poolie | :/ | 07:22 |
| lifeless | poolie: they dovetail, same code | 07:22 |
| vila | lifeless: so, bad gateway is the one I see when lp is down or performing really badly | 07:22 |
| lifeless | vila: yes, and we're hitting it unpleasantly often | 07:22 |
| lifeless | oh thats a fun bug | 07:23 |
| lifeless | search for 110 in a bug tracker search - takes you to the bug directly. | 07:23 |
| lifeless | <fail> | 07:23 |
| lifeless | https://bugs.edge.launchpad.net/launchpadlib/+bug/567180 | 07:24 |
| ubottu | Launchpad bug 567180 in launchpadlib "timeout submitting request - can't tell if its lplib or lp" [Undecided,New] | 07:24 |
| lifeless | thats the ssl related one | 07:24 |
| lifeless | poolie: I'm happy to rollback if you want; we have solved many of the issues but I know at least one remaining - there is diagnostic code in production that should enable it to be fixed when it next triggers | 07:25 |
| poolie | john seemed to be about +0.8 on rolling back | 07:26 |
| poolie | i'm about +0.1 but only because i haven't submitted yet this week :) | 07:27 |
| poolie | how about you, igc, vila and spiv? | 07:27 |
| lifeless | poolie: I don't think we should rollback today | 07:27 |
| lifeless | tomorrow afternoon if its still gltiching we should, because I'm going to be off friday | 07:27 |
| poolie | ok, wfm | 07:27 |
| poolie | before you fly and before the anz holiday | 07:28 |
| vila | Unless there are ways to reproduce the actual bugs in a separate instance, I'd prefer to endure the pain *now* than postponing it :) | 07:28 |
| vila | *BUT* gimme me feedback on my failures so I can see if the problem is on my side or not | 07:29 |
| vila | lifeless: the parthm chown one has just failed (I've seen 6 failures mentioned by the progress report on http://pqm.bazaar-vcs.org/), did you get some feedback there ? (for example) | 07:31 |
| spiv | vila, lifeless: maybe PQM is still not allowed to send the large failure emails? | 07:31 |
| lifeless | vila: yes, its blowing up truncating the 44MB error output | 07:31 |
| lifeless | spiv: no, see the exception spm pasted | 07:31 |
| vila | lifeless: you see that on the host running pqm or from your laptop ? | 07:32 |
| spiv | lifeless: link? There have been so many conversations about pqm lately. | 07:32 |
| lifeless | spiv: https://pastebin.canonical.com/31025/ | 07:32 |
| spiv | ta | 07:32 |
| lifeless | spiv: are you in #launchpad-code ? :P | 07:32 |
| lifeless | vila: ^ | 07:32 |
| spiv | lifeless: I am, but don't follow it closely | 07:33 |
| vila | ValueError: invalid literal for int() with base 16: '' rings some bell.... | 07:33 |
| lifeless | vila: however there are no text streams in play here | 07:33 |
| lifeless | so I think its definitely a pqm bug | 07:33 |
| lifeless | but perhaps subunit | 07:34 |
| spiv | lifeless: I don't know enough to make much sense of that exception, although wouldn't gzipping be a better option than truncating if this is just to get the email to a reasonable size? | 07:34 |
| lifeless | spiv: we're attaching it to the merge proposal. | 07:34 |
| lifeless | but they don't permit 'attachments' at the moment (bug iz open), so it will be a comment. | 07:34 |
| spiv | Oh, bleagh :( | 07:34 |
| vila | 44MB in a comment ? pfew | 07:35 |
| lifeless | spiv: thus I want it to be as useful as possible. Besides which, if pqm can't filter it, neither can a user. | 07:35 |
| === radoe_ is now known as radoe | ||
| lifeless | so I need to fix the bug. fixing the subunit fragility is one route | 07:35 |
| spiv | lifeless: so you're filtering out successes? | 07:35 |
| lifeless | eys | 07:35 |
| spiv | and xfails? :) | 07:35 |
| poolie | and time markers? | 07:35 |
| lifeless | time markers yes | 07:35 |
| lifeless | xfails I don't know | 07:35 |
| vila | Do I see a pattern about filtering just the failures and the errors here ? :-P | 07:36 |
| gour | morning | 07:36 |
| lifeless | I'm using a default TestResultFilter at the moment, I can change that easily. | 07:36 |
| * vila runs | 07:36 | |
| gour | using bzr with git repos fails with stuff like http://dpaste.com/186054/ | 07:36 |
| vila | gour: I'm pretty sure it's a known bug about github returning some invalid URLs | 07:37 |
| gour | vila: thank you...any workaround? | 07:37 |
| vila | gour: are you using the latest bzr-git version ? | 07:38 |
| gour | vila: no. will try to pull | 07:38 |
| vila | lifeless: both bug #567180 and bug #380504 are as obscure as pqm failures to me :-/ sorry | 07:42 |
| ubottu | Launchpad bug 567180 in launchpadlib "timeout submitting request - can't tell if its lplib or lp" [Undecided,New] https://launchpad.net/bugs/567180 | 07:42 |
| ubottu | Launchpad bug 380504 in launchpadlib "Handle HTTP Error 502: Bad Gateway automatically" [High,Triaged] https://launchpad.net/bugs/380504 | 07:42 |
| lifeless | vila: no idea what would cause the first one ? the second is well analyzed | 07:43 |
| vila | they look like timeouts on the server side to me | 07:43 |
| vila | errr, server taking too long I mean | 07:43 |
| vila | timeouts on the client | 07:44 |
| vila | I never encountered the ssl one though | 07:44 |
| vila | lifeless: any reason to suspect they don't share the same cause ? | 07:48 |
| * gour is encountering some problems updating bzr-git...need to do it manually | 07:48 | |
| gour | vila: i've updated bzr-git, but now i get: bzr: ERROR: Unsupported protocol for url...also with non-github urls | 07:51 |
| lifeless | vila: non reason to suspect either for or against | 07:51 |
| vila | gour: file a bug, with any luck lp will show you the relevant one, I don't remember the details, but I'm pretty sure the subject was discussed there | 07:52 |
| gour | vila: ok | 07:53 |
| vila | lifeless: both fail to get an answer, the only difference I see is one is using http and the other https. The http one went a bit farther and get a 502, but that may just be a reflect of the different servers involved, it's hard to tell from here :-/ | 07:55 |
| lifeless | vila: all api calls are https | 07:55 |
| lifeless | at the moment anyhow | 07:55 |
| vila | hmm, and involve the same servers ? | 07:55 |
| lifeless | vila: what I find odd is that the ssl one is timing out on *write* | 07:56 |
| lifeless | vila: yes, launchpad apis | 07:56 |
| vila | lifeless: wild guess: the timeouts on the client and the server are close and one fire before the other ... | 07:56 |
| lifeless | vila: interesting | 07:56 |
| lifeless | I think I'm going to have to take wild guesses | 07:57 |
| vila | in both cases, I'll check server logs... | 07:57 |
| lifeless | spm: ^ | 07:57 |
| gour | hmm...something is wrong here...i pulled the dulwich from the the trunk and i get: "bzr: ERROR: Unsupported protocol for url "git://github.com/maxlapshin/mysql2postgres.git": Unable to import library "dulwich": bzr-git: Dulwich is too old; at least 0.5.1 is required" | 08:00 |
| poolie | maybe it's finding a different one on your pythonpath | 08:01 |
| vila | lifeless: but... but... my submission from yesterday (avoid zombies) landed ??? Now I'm ever more confused :-( | 08:14 |
| vila | lifeless: can I still use pqm-submit directly ? | 08:17 |
| lifeless | yes, but I would not expect any difference if there is an MP for what you are submitting | 08:17 |
| vila | lifeless: it's for a trivial patch without MP so far | 08:18 |
| vila | lifeless: test import cleanups | 08:18 |
| lifeless | vila: you can just do it | 08:18 |
| vila | lifeless: cool | 08:18 |
| lifeless | it will jump the queue, too | 08:19 |
| vila | lifeless: I'll try to wait for it to be empty | 08:20 |
| lifeless | why? | 08:20 |
| vila | lifeless: just to avoid random problems | 08:20 |
| lifeless | ok | 08:20 |
| vila | lifeless: and about my landed mp ? I've seen the progress report mentioning 1 error, where did it go ? | 08:21 |
| lifeless | what error? | 08:21 |
| vila | lifeless: stop teasing me :-) That's the whole point: I have no idea what the error was ! | 08:22 |
| vila | at one point I saw: Running [ xx% nnnnn test(s), 1 error ] (or something similar) | 08:23 |
| lifeless | presumably transient then | 08:24 |
| vila | scary | 08:24 |
| vila | lifeless: I also feel that pqm is slower these days, is the host under more load ? | 08:25 |
| lifeless | I think I have a fix for the reporting | 08:25 |
| lifeless | vila: launchpadlib is slow | 08:25 |
| lifeless | vila: I can't answer about load. spm can ? | 08:25 |
| vila | lifeless: that shouldn't reflect on the time to run the test suite which is where my feeling of slowness is | 08:25 |
| lifeless | spm: ^ | 08:26 |
| spm | i wonder if we log ballenys load anywhere you guys can see... | 08:26 |
| vila | spm: no worries, just give me root access, I'll find my way from there | 08:26 |
| spm | vila: ha! misconception 1. *I* don't have root access.... | 08:26 |
| vila | spm: see ? That's why it's so hard for you :) | 08:27 |
| spm | heh | 08:27 |
| vila | spm: Anyway, I didn't imply that you have root access, I know you're far too responsible to use that, but just give it to me, ok ? | 08:28 |
| lifeless | vila: FYI, pqm error blow up was because stdout and stderr were being combined | 08:30 |
| lifeless | vila: *and* | 08:30 |
| lifeless | vila: we still have crap on stderr | 08:30 |
| spm | vila: something like that..... | 08:30 |
| lifeless | that will break most any serialisation you care to think about | 08:30 |
| lifeless | vila: if you wanted to review my adhoc fix, its pqm's most recent commit | 08:31 |
| vila | lifeless: argh | 08:33 |
| lifeless | ok, EOD time | 08:42 |
| vila | lifeless: will this commit be deployed ? | 08:43 |
| gour | cool...pulling dulwich from the trunk resolved bzr-git issue(s) | 08:46 |
| lifeless | vila: Tomorrow morning | 08:58 |
| vila | lifeless: ok | 09:00 |
| lifeless | vila: so if its crap, I can fix | 09:01 |
| vila | lifeless: nothing caught my eyes, but I have a poor context here :-/ | 09:01 |
| vila | lifeless: I'd use from cStringIO import StringIO , but... detail | 09:02 |
| vila | lifeless: grrr, lp:~jameinel/bzr/2.0.6-peak-commit-mem lp:bzr/2.0 is looping like my submission from yesterday :-( | 09:13 |
| vila | spm: still around ? ^ | 09:13 |
| spm | vila: not really - in post cleanup from a major librarian crash | 09:14 |
| vila | spm: ok | 09:14 |
| vila | Any other LOSA around ? | 09:14 |
| vila | lifeless: wow, I set https://code.edge.launchpad.net/~jameinel/bzr/2.0.6-peak-commit-mem/+merge/23718 status to 'Approved' (from 'Queued') and it went out of pqm instantly (pqm had just started processing it again...) ? | 09:19 |
| mthaddon | vila: o/ | 09:19 |
| vila | mthaddon: I just broke the loop apparently, stay tuned but nothing needed immediately :) | 09:20 |
| mthaddon | k | 09:20 |
| lifeless | vila: it hasn't gone from pqm really | 09:21 |
| lifeless | vila: the webui and the cron job only have a tenuous connection to each other | 09:21 |
| lifeless | vila: the next time it refreshes the list though, it won't find it | 09:21 |
| lifeless | vila: you might like to get mthaddon to look at the bzr pqm log and tell you the patch it most recently started playing from that; and if its jam's branch shut all of the bzr --cron processes down (set a stop.patch and wait) | 09:22 |
| vila | lifeless: but I saw: Running [ 0% 1 test(s) ] for jam's branch, went to the mp page, switched the status, came back to pqm page, it was gone, does that make sense ? | 09:23 |
| vila | lifeless: or rather, | 09:23 |
| lifeless | vila: yes, as I said, the web ui and the cron daemon are only tenuously linked | 09:24 |
| vila | lifeless: is the pqm web UI lagging so much ? | 09:24 |
| lifeless | no | 09:24 |
| lifeless | its reading from lp | 09:24 |
| lifeless | change the lp status, change what it sees | 09:24 |
| lifeless | doesn't change the behaviour of the *already running* pqm cron instance | 09:24 |
| vila | lifeless: that's my point, the pqm run appeared to stop while the web UI was reporting Running [ 0% 1 test(s) ] | 09:25 |
| lifeless | however, the cron instance loops around all the items queued | 09:25 |
| lifeless | vila: it didn't. | 09:25 |
| vila | lifeless: I'm talking about seconds between my actions, not even minutes | 09:26 |
| lifeless | one of the bugs stops failing proposals being set back to approved | 09:26 |
| lifeless | vila: yes, I understand. | 09:26 |
| lifeless | nevertheless. | 09:26 |
| lifeless | Not Possible. | 09:26 |
| lifeless | the 'current playing' entry in the queue is total lies | 09:26 |
| vila | lifeless: pfew, so I'm not dreaming | 09:27 |
| lifeless | read the code - in particular pqm/queue/lp.py 'next_script' and compare with pqm/ui/twisted.py | 09:27 |
| lifeless | the status region is accurate | 09:27 |
| lifeless | the claimed patch will be more accurate once the bugs preventing lp updates are fixed | 09:27 |
| lifeless | but even then, if you dequeue the active thing, it will take a full pqm run to sync up again | 09:28 |
| lifeless | not something worth fixing | 09:28 |
| vila | lifeless: ok, that matches my expectations... now where should I look to find reliable info about what is running... | 09:28 |
| lifeless | ask-a-losa *if* it matters | 09:29 |
| lifeless | the thing to remember is that pqm won't loop on one patch | 09:29 |
| lifeless | it will loop on all patches | 09:29 |
| vila | lifeless: right | 09:29 |
| lifeless | the web page will look like its looping on the first; its not. | 09:29 |
| lifeless | every time it hits the end, it will refresh from lp | 09:29 |
| vila | https://code.edge.launchpad.net/bzr/+merges?field.status=QUEUED&field.status-empty-marker=1 is the only reliable source then | 09:29 |
| lifeless | and go around again, if there are unmerged things. | 09:29 |
| lifeless | vila: uhm, thats == the pqm web ui | 09:30 |
| lifeless | so its equally inaccurate | 09:30 |
| vila | lifeless: it's the source that pqm read no ? | 09:30 |
| lifeless | vila: when it refreshes the queue, yes. Which it only does after trying everything it knew about. | 09:31 |
| lifeless | the web ui refreshes every 30 seconds | 09:31 |
| lifeless | so the web ui == the launchpad page, in terms of being totally wrong about what merge the cron job is actually processnig | 09:31 |
| vila | oh that, yes, I realize | 09:32 |
| vila | but in terms of accessible info, that's all I have | 09:32 |
| lifeless | the pqm web ui tells you a little more | 09:32 |
| lifeless | test_permissions.TestPermissions.test_new_files OK 545ms | 09:32 |
| lifeless | ...permissions.TestPermissions.test_new_files_group_sticky_bit OK 185ms | 09:32 |
| lifeless | ... | 09:32 |
| lifeless | etc | 09:32 |
| vila | argh: | 09:33 |
| lifeless | anyhow, I think you dequeued the wrong thing :P | 09:33 |
| vila | bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2449 leaking tests. | 09:33 |
| vila | make: *** [check-nodocs] Error 1 | 09:33 |
| lifeless | I'm pretty sure the Oo flag thing is the broken thing | 09:33 |
| vila | for support_OO flag | 09:33 |
| lifeless | vila: you ran locally ? | 09:33 |
| vila | lifeless: no | 09:33 |
| lifeless | babune? | 09:33 |
| vila | lifeless: just copied from pqm.b.o | 09:33 |
| lifeless | vila: see the comments I put in parthm's merge; that I said were odd .... | 09:34 |
| vila | lifeless: babune needs love | 09:34 |
| vila | lifeless: where did you get these failures ? ... pfff, nm, | 09:34 |
| vila | lifeless: wait, I dequeued the wrong thing ? How comes ? I dequeued the first mp in the list... | 09:35 |
| vila | lifeless: the order reported is a lie too ? | 09:36 |
| * vila stops refreshing pqm web page, 30 seconds man ! | 09:37 | |
| mwhudson | jelmer: hi | 09:43 |
| jelmer | mwhudson: hi | 09:44 |
| jelmer | mwhudson: otp | 09:44 |
| mwhudson | jelmer: we cherry picked the bzr-git import and it failed on kernel import with a keyerror | 09:44 |
| mwhudson | jelmer: should we just delete the import and start again? | 09:44 |
| spm | mwhudson: \o/ | 09:45 |
| jelmer | mwhudson: re | 09:46 |
| jelmer | mwhudson: what's the keyerror? | 09:47 |
| jelmer | mwhudson: still there? | 09:59 |
| mwhudson | jelmer: https://code.edge.launchpad.net/~kiko/linux/2.6.31 | 10:00 |
| jelmer | mwhudson: is the fetch interval 1k revisions or 5k ? | 10:00 |
| mwhudson | jelmer: 10k | 10:01 |
| jelmer | mwhudson: but yeah, restarting it would probably be a good idea | 10:03 |
| parthm | lifeless: i responded to you on no-chown-if-bzrlog-exists about 30min ago but somehow my response hasn't shown up on the merge proposal | 10:15 |
| * mwhudson starts https://code.staging.launchpad.net/~vcs-imports/linux/trunk again | 10:16 | |
| parthm | lifeless: i ran all the failed tests and didn't see any issues. its weird. | 10:16 |
| lifeless | parthm: ok, its not your branches issue; however it is failing somehow on pqm; have you run all the tests? | 10:16 |
| mwhudson | except, not on stagin | 10:16 |
| parthm | lifeless: i usually run bb and a subset of bt as results get lost in "error: can't start new thread". those were passing. i am running the full suite now. nothing suspicious yet. | 10:18 |
| lifeless | parthm: if you do | 10:19 |
| lifeless | bzr selftest --list-tests | 10:19 |
| lifeless | partition that list into (say) 10 | 10:19 |
| lifeless | and use --load-list to load each partition in series, you may have more luck | 10:19 |
| lifeless | parthm: what OS are you on ? | 10:19 |
| parthm | lifeless: yes. that might work. because when i ran failed (memory/new thread error) tests individually they tend to pass. | 10:20 |
| parthm | lifeless: i am on ubuntu 9.10. 1GB memory. | 10:20 |
| lifeless | interesting, I wouldn't have expected isues there | 10:23 |
| lifeless | parthm: you could also try | 10:23 |
| lifeless | selftest --parallel=fork | 10:23 |
| lifeless | but you might not have enough cpu's to get a large enough partition to avoid the thread issue | 10:23 |
| parthm | lifeless: i am already using --parallel=fork. i have 2 cpus ... maybe it time to upgrade :) | 10:24 |
| vila | parthm, lifeless : indeed 2 is often not enough to work around the thread/socket leaks | 10:39 |
| parthm | vila: i have taken the results of --list-only as suggested by lifeless. that seems to be working out ok but i think it will take some time to run :) | 10:41 |
| vila | I should find that script I wrote long ago selftest-run-by... | 10:43 |
| parthm | vila: sounds useful. for now i just used my vimfu + regex to make a simple sh with one line for one test class. maybe your script can go in bzr/contrib? | 10:44 |
| vila | parthm: selfest-by-n: http://paste.ubuntu.com/419750/ | 10:45 |
| lifeless | vila: so what is this thread leaking thing | 10:45 |
| vila | lifeless: basically python SocketServer is not safe to run in the same process as the client | 10:45 |
| lifeless | why not | 10:45 |
| vila | lifeless: ha ! | 10:46 |
| vila | lifeless: something related to the way python polls for socket | 10:46 |
| vila | sockets | 10:46 |
| spiv | Last time I tried digging into it tests using the smart server seemed to be at least part of the issue, at least judging from the concurrent access to log file warnings. | 10:46 |
| spiv | But I might be wrong. | 10:46 |
| vila | spiv: *any* server test using SocketServer | 10:46 |
| lifeless | vila: this is interfering with various people; others don't see it. | 10:46 |
| lifeless | specifically I've never seen it, and PQM seems immune. | 10:47 |
| spiv | vila: the smart server code doesn't use SocketServer | 10:47 |
| spiv | lifeless: FWIW, I see it :( | 10:47 |
| lifeless | so I am curious whether the analysis is actually complete | 10:47 |
| * spiv -> afk | 10:48 | |
| vila | lifeless: well, feel free to dig yourself, but I've digged it enough to be sure | 10:48 |
| lifeless | vila: I don't see it | 10:48 |
| lifeless | vila: hard to dig when you don't suffer it at all. | 10:48 |
| vila | lifeless: sure | 10:49 |
| lifeless | vila: do you think you could create a synthetic cause-the-problem example ? | 10:49 |
| vila | no | 10:49 |
| lifeless | like a tiny test case that starts a server, does a get, stops it, and we populate 10000 of the same test case into one suite | 10:49 |
| vila | but forcing the test servers to shutdown were making it more obvious last time I worked on the subject | 10:49 |
| vila | OSX, FreeBSD, gentoo reproduce it with reasonable success | 10:51 |
| vila | so to speak | 10:51 |
| vila | years ago we were retrying operations on socket not available in the http server, same root cause | 10:51 |
| vila | lifeless: see bugs #392117 and bug #405745 | 10:54 |
| ubottu | Launchpad bug 392117 in ubuntu "The application Run Command Interface (krunner) crashed and caused the signal 6 (SIGABRT)." [Undecided,New] https://launchpad.net/bugs/392117 | 10:54 |
| ubottu | Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745 | 10:54 |
| vila | bah bug #392127 | 10:54 |
| ubottu | Launchpad bug 392127 in bzr "selftest fails with "can't start new thread"" [High,In progress] https://launchpad.net/bugs/392127 | 10:54 |
| vila | lifeless: also lp:~vila/bzr/405745-http-hangs and lp:~vila/bzr/392127-thread-leak for some wip | 10:55 |
| vila | lifeless: common symtoms include: test server hangs, uncaught exceptions in server threads | 10:56 |
| vila | lifeless: next try will be to start with wrapping threads to propagate/report/catch exceptions | 10:57 |
| jelmer | mwhudson: I think disabling the fetching in batches for git would actually be possible now | 10:59 |
| jelmer | mwhudson: and improve performance significantly | 10:59 |
| mwhudson | jelmer: memory usage doesn't grow? | 11:01 |
| jelmer | mwhudson: nope | 11:01 |
| mwhudson | jelmer: anyway, file a bug maybe? | 11:01 |
| jelmer | mwhudson: sure | 11:01 |
| mwhudson | i'm going back to the hotel now, might be biab if the internet is working there tonight | 11:02 |
| jelmer | mwhudson: sorry about this, I realise you've put quite some work into the incremental fetching | 11:02 |
| jelmer | mwhudson: I just didn't expect bzr-git fetch to get so much better this quickly | 11:02 |
| lifeless | vila: what I'd most like is something that is dedicated to provoking it | 11:02 |
| lifeless | vila: if it is a python upstream issue that will let us file a bug | 11:02 |
| mwhudson | jelmer: :-) | 11:02 |
| lifeless | vila: if its not, then its something that I can hopefully trigger the issue with and help fix it | 11:03 |
| vila | lifeless: I've never been able to track it down (or reduce it) to test simple enough to point a finger at python | 11:03 |
| vila | lifeless: I suspected it for a long time, but I'm now convinced that the problem is more in a bad use of SocketServer (except for spiv remark above for which I don't have a good explanation, but I haven't dug that yet) | 11:04 |
| parthm | vila: i can't seem to get the script command right. "./selftest-by-n.py --in-tmp ~/tmp --number 20 --starting-with tests.txt" ? | 11:08 |
| parthm | vila: tests.txt is the list of tests e.g. bzrlib.tests.blackbox.TestXXX.test_foo etc. | 11:08 |
| vila | lifeless: basically, there is no guarantee that the socket state is coherent (inside the same process) between a server and a client (I don't remember the exact details from the top of my head) | 11:09 |
| vila | parthm: hmm, let me see | 11:09 |
| vila | parthm: my .bash_history says: selftest-by-n.py --load-list --number 1000 all.tests | 11:10 |
| vila | parthm: where all.tests has been produced by a previous 'bzr selftest --list >all.tests' | 11:11 |
| vila | parthm: BZR_PLUGIN_PATH=-site may be needed too | 11:11 |
| parthm | vila: weird. it prints out ": No such file or directory" | 11:13 |
| vila | parthm: and 'selftest-by-n.py -n 1000 all.tests' ? | 11:14 |
| parthm | vila: that produces "ERROR: Unkown test runner". i think its looking for --starting-with option. | 11:15 |
| vila | parthm: selftest-by-n.py --load-list --number 1000 all.tests seems to work here | 11:15 |
| parthm | vila: weird. I get ": No such file or directory". i will try some more. I also did a sys.path.append with my bzr branch near FIXME in the script. same error with/without it. | 11:17 |
| vila | no such file for what ? | 11:18 |
| lifeless | vila: but there are separate fds for each end of the socket | 11:19 |
| lifeless | vila: and the OS is what keeps things coherent | 11:19 |
| vila | the sys.path.append shouldn't be needed, we call './bzr' in a subprocess anyway | 11:19 |
| lifeless | vila: we really do a 'make it happen' script. | 11:20 |
| vila | lifeless: geee, of course, I've fought for that since the beginning ! | 11:20 |
| lifeless | vila: since you can make it happen, try: | 11:20 |
| vila | ENOTYET :-( | 11:20 |
| lifeless | def load_test(tests, _, _): | 11:21 |
| a212901390231901 | sorry parthm, seems my screwup got blamed on your branch | 11:21 |
| lifeless | return TestSuite([tests[0]]*1000) | 11:21 |
| lifeless | class breaks(TestCaseWithTransport): | 11:21 |
| lifeless | def test_hurts(self): | 11:21 |
| lifeless | self.transport_server = http | 11:21 |
| parthm | vila: got it. all.tests needed a little preprocessing. basically removed (.*) from end of --list-only names and ran through uniq | 11:22 |
| parthm | vila: works nicely. thanks. | 11:22 |
| lifeless | get_transport(self.get_url('')).has('something') | 11:22 |
| lifeless | -done- | 11:22 |
| parthm | a212901390231901: np :) | 11:23 |
| vila | lifeless: I really can't work on that *now*, but as far as I recall, the lp:~vila/bzr/405745-http-hang was failing with python2.4, you may be able to reproduce from there | 11:25 |
| vila | lifeless: on Ubuntu that is | 11:26 |
| cody-somerville | wtf. bzr diff is giving a completely incorrect patch | 12:37 |
| fullermd | It's just seeing if you're paying attention. | 12:37 |
| cody-somerville | lol | 12:39 |
| cody-somerville | lifeless, any clue why bzr would be doing that? | 12:40 |
| vila | cody-somerville: your hints are a bit sparse... a pastebin maybe ? | 12:41 |
| fullermd | Shucks, you broke my concentration; I was getting my clairvoyance all fired up. | 12:41 |
| vila | sorry | 12:44 |
| cody-somerville | vila, I can't seem to browse the branch on launchpad so I can't prove to you the patch is incorrect. | 12:46 |
| vila | cody-somerville: I don't ask for proof (yet :) just evidence to understand *what* is incorrect, different file, path mangled, wrong diff content, et | 12:47 |
| vila | etc | 12:47 |
| cody-somerville | wrong diff content | 12:47 |
| vila | cody-somerville: plain 'bzr diff' or with some option ? | 12:47 |
| spiv | cody-somerville: wrong in what way? | 12:47 |
| cody-somerville | just bzr diff | 12:47 |
| vila | cody-somerville: standalone branch, checkout ? | 12:48 |
| vila | cody-somerville: is 'bzr st' wrong too ? | 12:48 |
| cody-somerville | binded branch | 12:48 |
| vila | no 'run bzr update' warning ? | 12:49 |
| cody-somerville | and the diff is hard to describe why its wrong. Its adding lines that were already there and the context in the patch would result in the patch not apply anyhow. | 12:49 |
| cody-somerville | *applying | 12:50 |
| cody-somerville | nothing is instructing me to run bzr update, if thats your question | 12:50 |
| vila | cody-somerville: do 'bzr revno' and 'bzr revno --tree' agree ? | 12:50 |
| cody-somerville | vila, yes | 12:51 |
| vila | bzr missing ? | 12:51 |
| fullermd | May want an explicit `missing :bound`... | 12:52 |
| cody-somerville | I'm afraid if I run more bzr commands, what ever state bzr is in to cause this error will be resolved | 12:53 |
| vila | cody-somerville: yeah, on the othe hand, that's the point :) | 12:53 |
| cody-somerville | I'd rather get the debug info needed for the bug to be fixed. | 12:54 |
| vila | Well, I don't have enough info yet to say whether it's a bug or not :-/ | 12:54 |
| spiv | cody-somerville: make a tarball (including .bzr/repository, .bzr/branch, .bzr/checkout, and the actual workingtree)? | 12:55 |
| vila | ensuring you get the repo if it's shared | 12:55 |
| cody-somerville | interesting, bzr export gives me a directory that the patch would apply against | 12:55 |
| cody-somerville | holy crap | 12:57 |
| spiv | Sounds like the issue isn't with 'diff' per se, but with the branch you are working on not having the contents you think it does? | 12:57 |
| lifeless | cody-somerville: the problem with 'wrong' is that there are many ways something can be wrong, and usually only one way something can be right | 12:57 |
| lifeless | cody-somerville: so when you say 'wrong', we have -no- idea which of the many forms of wrong has occured. | 12:57 |
| cody-somerville | loggerhead shows different content for the file | 12:57 |
| cody-somerville | but if I download the file by clicking 'download file', I get the content I expect | 12:58 |
| spiv | URL? | 12:58 |
| vila | spiv: tsk, you spoil then fun | 12:58 |
| cody-somerville | spiv, Sent you the URL via PM | 12:59 |
| === salgado-afk is now known as salgado | ||
| cody-somerville | lifeless, Indeed. Unfortunately this isn't an easy case of 'wrong' to articulate. The branch in question being Canonical confidential doesn't help. | 13:02 |
| cody-somerville | However, in the case of loggerhead, the last line of the file is missing (but isn't when I download the file). | 13:03 |
| lifeless | is the last line missing a \n ? | 13:03 |
| cody-somerville | lifeless, yes | 13:04 |
| lifeless | please file a bug | 13:05 |
| cody-somerville | lifeless, on the loggerhead issue? | 13:07 |
| lifeless | yes | 13:07 |
| cody-somerville | lifeless, actually, there is a newline. | 13:08 |
| lifeless | cody-somerville: in both versions? | 13:08 |
| cody-somerville | holy crap | 13:10 |
| cody-somerville | this is weird. | 13:10 |
| cody-somerville | If I save the file to disk, I get what bzr is saying the file is | 13:10 |
| cody-somerville | if I open it in firefox and look at the source, I see what I expect | 13:10 |
| lifeless | ah | 13:10 |
| lifeless | try less | 13:11 |
| lifeless | and also remember that browsers have defined eol markers in html docs which are not necessarily whats sent on the wire | 13:11 |
| cody-somerville | I sorta see what I expect except there is a ^M where I expect a newline at the end of the second to last line. | 13:12 |
| === mrevell is now known as mrevell-lunch | ||
| lifeless | yup | 13:12 |
| lifeless | in which case, I think there isn't a bug | 13:13 |
| lifeless | you've just got a crap file | 13:13 |
| cody-somerville | I think there clearly is a bug. | 13:13 |
| lifeless | perhaps in the http/html specs | 13:13 |
| lifeless | gotta run | 13:13 |
| cody-somerville | The file was fine though. I dunno how this happened. | 13:13 |
| cody-somerville | and changing "I'm sorry. You're not authorized to access this page." to "You're not authorized to access this page." seems very odd for a EOL marker issue to cause | 13:14 |
| MvG | Hi there! trying to understand bug #370710, I would like to know what consequences can be expected from a call to WorkingTree.set_root_id. | 13:15 |
| MvG | Am I correct to assume that the root ID is stored in the branch, even if I set it via the working tree? What information is associated with that ID, which might break when changing the ID? | 13:15 |
| MvG | Is there a particular reason an upgrade chooses a fixed root id? Wouldn't it be preferable to calculate a hopefully unique ID e.g. based on the revid of the revision with revno 1 or some such? That would give the same id for all branches, and still give different IDs for independent branches. | 13:15 |
| ubottu | Launchpad bug 370710 in bzr "bzr: ERROR: File id {TREE_ROOT} already exists" [Medium,Confirmed] https://launchpad.net/bugs/370710 | 13:15 |
| cody-somerville | lifeless, I got rid of the ^M and bzr is still giving me the incorrect diff | 13:15 |
| cody-somerville | vila, Are you still around to help? | 13:16 |
| vila | cody-somerville: a bit but I need meat to chew | 13:18 |
| cody-somerville | vila, https://pastebin.canonical.com/31047/ | 13:19 |
| cody-somerville | vila, https://pastebin.canonical.com/31050/ <-- actual current content of file in tree | 13:19 |
| vila | cody-somerville: both have a final newline right ? | 13:20 |
| cody-somerville | vila, as far as I can tell, yes. | 13:20 |
| vila | so, given the current content of the file and the diff, I need that content of the file in the branch tip | 13:22 |
| cody-somerville | vila, Sent you link | 13:23 |
| cody-somerville | vila, What I noticed is loggerhead does not show last line of file | 13:23 |
| vila | cody-somerville: urgh, yes | 13:23 |
| cody-somerville | vila, IF you download file and open in firefox, and then click show source the file looks as expected | 13:23 |
| vila | cody-somerville: so at least file a bug against loggerhead | 13:23 |
| vila | but the diff is weird, it shows the '{% endif %}' *before* the text | 13:25 |
| lifeless | cody-somerville: ^M is CR as opposed to LF, IIRC. | 13:25 |
| cody-somerville | vila, if You download and save to disk, it looks like bzr sees it if you cat the file. If you less it, it looks like how I expect except for an ^M instead of a new line at the end of the second to last line. | 13:25 |
| lifeless | cody-somerville: the line is there, it just looks missing | 13:25 |
| vila | cody-somerville: isn't there a CR somehwere | 13:25 |
| spiv | cody-somerville: try 'cat -v', not 'cat' | 13:26 |
| cody-somerville | spiv, That gets me what I see with less | 13:27 |
| vila | cody-somerville: there is a litteral '^M' there | 13:27 |
| vila | that triggers various display bugs... | 13:27 |
| spiv | vila: odd use of the term literal, don't you mean there is a CR byte? | 13:27 |
| lifeless | vila: features :P it is after all how our progress bars work. | 13:27 |
| cody-somerville | I fixed that issue in the branch tree | 13:27 |
| cody-somerville | and I still have the issue | 13:28 |
| lifeless | cody-somerville: and you've committed ? | 13:28 |
| cody-somerville | no | 13:28 |
| spiv | cody-somerville: pipe the diff through 'cat -v'? | 13:28 |
| vila | spiv: yeah, I meant there literraly is a CR there. Is that more correct ? | 13:28 |
| cody-somerville | spiv, that completely changes the output of the patch | 13:28 |
| spiv | vila: well, it at least doesn't sound like you are saying there is a ^ followed by a M ;) | 13:28 |
| vila | lifeless: I agree, it's a feature | 13:29 |
| lifeless | vila: literaly can be a superlative, or used when there is doubt that one speaks seriously. | 13:29 |
| vila | spiv: oh, ok | 13:29 |
| cody-somerville | spiv, https://pastebin.canonical.com/31051/ | 13:29 |
| lifeless | vila: I wouldn't use literaly in this context, it was clear you were serious, and literally is a literally terrible superlative :) | 13:29 |
| vila | lifeless: lol,, ok, | 13:30 |
| vila | cody-somerville: yeah, this last diff is correct, so blame the diff viewer you were using ? | 13:30 |
| * fullermd literally checks for an XKCD ref... | 13:30 | |
| spiv | cody-somerville: so the change according to that diff is that a CR got changed to a LF | 13:31 |
| cody-somerville | It might be a bug in the xfce4 terminal | 13:31 |
| lifeless | cody-somerville: its a feature, all the bits operating as intended. How you got the \r there is a mystery but the rest is totally explicable | 13:31 |
| spiv | Well, CR is generally meant to be interpreted by terminals as "move the cursor back to the start of the line", i.e. "carriage return" | 13:32 |
| vila | cody-somerville: yes and no, CR *must* be interpreted as: go to the beginning of line in some contexts | 13:32 |
| vila | blam, stereo effect :) | 13:32 |
| cody-somerville | So bzr should probably do what ever the -v does to cat to its output | 13:32 |
| vila | cody-somerville: vade retro satanas, it's not bzr job | 13:33 |
| spiv | Well, AFAIK that's the correct diff output; that's the sequence of bytes you'd need to feed to GNU patch to reproduce that change. | 13:33 |
| cody-somerville | hmmm | 13:34 |
| cody-somerville | there has to be a way to provide a better user experience in this case. | 13:34 |
| lifeless | cody-somerville: I'm still not sure what went wrong; it sounds like you tried to apply a patch to a file you got from your browser, but it didn't work from bzr ? | 13:35 |
| spiv | Well, loggerhead seems to have a bug, which doesn't help. | 13:35 |
| vila | yes, use the right viewer, mine displays ^M and don't interpret it in that case | 13:35 |
| lifeless | or something like that | 13:35 |
| lifeless | spiv: it does ? | 13:36 |
| cody-somerville | lifeless, nope | 13:36 |
| vila | cody-somerville: but loggerhead should certainly be fixed | 13:36 |
| lifeless | spiv: are you aware that browsers munge \r and \n together ? | 13:36 |
| spiv | Perhaps a graphical diff tool like "bzr qdiff" or "bzr gdiff" would show tht more clearly. | 13:36 |
| lifeless | deliberately | 13:36 |
| cody-somerville | lifeless, I think it might be a bug in gedit | 13:36 |
| spiv | lifeless: not really, but I don't see how that explains the absence of the final "{% endif %}" text in loggerhead's annotate view | 13:37 |
| lifeless | spiv: I thought cody was saying that it shows in loggerhead ? | 13:38 |
| lifeless | /ETIRED | 13:38 |
| lifeless | tomrrow | 13:38 |
| lifeless | cody-somerville: if loggerhead or bzr hid the content, please file bugs. | 13:38 |
| spiv | lifeless: no, in loggerhead the final line seems to be missing in the annotate view | 13:38 |
| lifeless | we don't want to mangle stuff, and cat really needs to show the canonical content [by default] | 13:38 |
| lifeless | but we can record that you had an issue | 13:39 |
| spiv | lifeless: at a glance perhaps because the final line doesn't have a newline | 13:39 |
| lifeless | ah, 'perfect storm' :P | 13:39 |
| lifeless | gnight | 13:39 |
| === mrevell-lunch is now known as mrevell | ||
| salgado | I've just got a merge conflict but this time around I was left with just the .BASE and .OTHER files and no original file with inline conflict markers | 14:08 |
| salgado | has anything changed recently? | 14:08 |
| salgado | I'm using 2.1.1, btw | 14:08 |
| vila | salgado: no recent change, what does 'bzr conflicts' says ? | 14:09 |
| salgado | Contents conflict in cronscripts/branch-scanner.py | 14:10 |
| salgado | Contents conflict in lib/lp/codehosting/scanner/branch_scanner.py | 14:10 |
| salgado | vila, I use --lca by default, btw | 14:10 |
| salgado | renamed: | 14:11 |
| salgado | cronscripts/branch-scanner.py => cronscripts/branch-scanner.py.THIS | 14:11 |
| salgado | unknown: | 14:11 |
| salgado | cronscripts/branch-scanner.py.BASE | 14:11 |
| vila | so you should have a cronscripts/branch-scanner.py.THIS file | 14:11 |
| salgado | I do, yes | 14:12 |
| salgado | I said OTHER but I meant THIS | 14:12 |
| vila | silly me, of course :-P | 14:12 |
| vila | salgado: so, presumably the branch you're merging from has deleted these files | 14:14 |
| vila | but they have been modified locally, hence the conflict | 14:15 |
| vila | salgado: to resolve you need to either delete the file OR keep it with its modifications | 14:15 |
| salgado | yeah, I assumed it'd be that but when I checked it was still there | 14:16 |
| salgado | of course, I checked on the wrong branch | 14:16 |
| vila | pfew, I had a wtf moment... | 14:16 |
| salgado | vila, yeah, so did I when I saw the file was still there. anyway, thanks for the help | 14:18 |
| cody-somerville | loggerhead bug appears to already be reported: lp ##387225 | 15:05 |
| vila | bug #387225 | 15:18 |
| ubottu | Launchpad bug 387225 in loggerhead "\r line endings poorly handled" [Medium,Confirmed] https://launchpad.net/bugs/387225 | 15:18 |
| vila | cody-somerville: well done, did you click the me-too ? | 15:19 |
| vila | cody-somerville: oh yeah, even added a tag | 15:19 |
| vila | naoki^, bialix: Can you test an alternative fix for bug #523746 from lp:~vila/bzr/523746-difftool-file-names ? | 15:29 |
| ubottu | Launchpad bug 523746 in bzr "crash with winmerge in cp932 japanese character" [Undecided,In progress] https://launchpad.net/bugs/523746 | 15:30 |
| === CobaltMike is now known as cobalt_mike | ||
| cobalt_mike | Does anyone have experience building on bzrlib directly? I have a few questions.... | 15:47 |
| === jelmer is now known as ctrlsoft | ||
| maxb | cobalt_mike: Better to just ask them | 16:04 |
| cobalt_mike | Alright, for example, if I want to implement checkout, but I want a hook for every file that's created, am I better off starting with the cmd_checkout class from builtins, or building up equivalent functionality with lower-level primitives like Branch, etc. | 16:05 |
| cobalt_mike | I'm guessing I'm going to have to add some hooks somewhere, as well... | 16:05 |
| lfaraone | How can I include a folder with a git repo in a bzr repository? I'm developing some software to work with git repos (among other VCSs), but when "bzr add"ding the .git/ folder I get " ... chl = debian_bundle.changelog.Changelog(file=open(os.path.join(test_folder, 'debian', 'changelog'), 'r').read())". | 16:09 |
| lfaraone | ... chl.full_version | 16:09 |
| lfaraone | oops, I mean "bzr: ERROR: No WorkingTree exists for "/home/lfaraone/Projects/ubuntu-dev-tools/trunk/uvs-tests/git-test-1/gitrepo/.git/"." | 16:09 |
| cobalt_mike | lfaraone: Not a direct answer to your problem, but I've had to include SCM repositories for testing in SCM repositories before, and I've found it was just easier to store it as a zip or tarball and have the test fixture extract it | 16:11 |
| ctrlsoft | lifeless: do you perhaps have bzr-git installed? | 16:11 |
| lfaraone | cobalt_mike: yes, I do. | 16:11 |
| lfaraone | * ctrlsoft | 16:11 |
| ctrlsoft | lfaraone: that would explain it, that will attempt to use the .git directory | 16:12 |
| lfaraone | ctrlsoft: okay. How can I disable the plugin for this repository? | 16:13 |
| ctrlsoft | lfaraone: if the .git directory doesn't have a working tree I would recommend changing it into a bare repository | 16:13 |
| ctrlsoft | lfaraone: you can uninstall the plugin or use --disable-plugins | 16:13 |
| lfaraone | ctrlsoft: it does have a working tree as far as I can tell, I just created and committed a few changes into it. | 16:13 |
| cobalt_mike | Another question re: bzrlib - what's the right way to initialize a repository? The documentation seems to indicate I should use BzrDir.create, but the builtins use BzrDir.format_registry.make_bzrdir | 16:18 |
| ctrlsoft | cobalt_mike: the first actually creates a BzrDir, the latter creates a format object | 16:20 |
| ctrlsoft | lfaraone: as far as bazaar is concerned this is a nested tree, so it's trying to add it that way | 16:20 |
| ctrlsoft | lfaraone: I think the only real workaround is to remove bzr-git for now | 16:20 |
| cobalt_mike | ctrlsoft: errr, right =)... why would I want to create the format object over just building the directory directly? BzrDir.create takes an optional format param | 16:23 |
| ctrlsoft | cobalt_mike: right, so if you want to biuld a repository with a specific format you'd use BzrDir.format_registry.make_bzrdir first | 16:29 |
| ctrlsoft | cobalt_mike: and then pass what it returned into BzrDir.create()'s format argument | 16:29 |
| ctrlsoft | cobalt_mike: if you just want the default format, use BzrDir.create() without specifying the format argument | 16:30 |
| cobalt_mike | thanks! | 16:30 |
| cobalt_mike | maybe I'll eventually compile my notes into a wiki page about using bzrlib =) | 16:31 |
| === kfogel is now known as kfogelunch | ||
| === salgado is now known as salgado-lunch | ||
| jannn | hey, how to I tell bzr checkout to ignore invalid certificates instead of just erroring out? | 17:02 |
| cbz | does anyone here use subversion from bzr? i'm just wondering why the revision numbers in bzr are a lot lower than the revno in subversion | 17:18 |
| ctrlsoft | cbz: bzr revision numbers are per-branch, in subversion they are per-repository | 17:19 |
| ctrlsoft | cbz: if you have bzr-svn installed then "bzr log" should show both | 17:19 |
| cbz | okay - but i assumed after an initial bzr branch command the numbers would match, as at least initially each svn revid would have a bzr revision it maps to | 17:21 |
| ctrlsoft | cbz: subversion doesn't have revision ids | 17:22 |
| ctrlsoft | cbz: it only has revision numbers, and those do indeed map to bzr revids | 17:23 |
| ctrlsoft | cbz: the bzr revno's differ per branch | 17:23 |
| ctrlsoft | cbz: if you e.g. look at "bzr log /trunk" and "bzr log /branches/foo" then revno X may refer to different revisions in both outputs, but the svn revno will be the same | 17:23 |
| cbz | Yeah, but i haven't created any more branches. All i've done is a bzr branch svn+repurl | 17:24 |
| cbz | And i've got things like revno: 2932 | 17:25 |
| cbz | svn revno: 14362 (on /core/trunk) | 17:25 |
| ctrlsoft | cbz: right, so you have more branches in the svn repo | 17:25 |
| ctrlsoft | cbz: unless /core/trunk is the only branch that exists? | 17:25 |
| cbz | oh yeah - i see what you mean. | 17:25 |
| cbz | Thanks. | 17:25 |
| ctrlsoft | np | 17:25 |
| cobalt_mike | ok, next question: I'd like to add hooks to bzrlib to fire whenever a file is created or updated during a checkout/update | 17:29 |
| cobalt_mike | any pointers on where to start looking? | 17:29 |
| ctrlsoft | cobalt_mike: I don't think there are any hooks that you could use for that yet | 17:30 |
| ctrlsoft | cobalt_mike: see the output of 'bzr hooks' | 17:30 |
| cobalt_mike | right, I want to add them at the library level (and hopefully contrib back) | 17:31 |
| ctrlsoft | cobalt_mike: jam or vila are probably the best people to talk to about this | 17:33 |
| jam | cobalt_mike: is there a particular difference to what you want to do, vs using a content filter? | 17:33 |
| cobalt_mike | ah, hadn't seen content filters.... reading.... | 17:35 |
| cobalt_mike | well for one, I'm not actually modifying the file, I essentially need to post-process it, but not in-place | 17:36 |
| cobalt_mike | so I guess I could make a no-op filter that what I needed | 17:36 |
| cobalt_mike | that ^did | 17:37 |
| jam | cobalt_mike: I think it would be a potential hook point for what you need, but if you have a clear idea of what you would like to see added, I'd be happy to discuss it | 17:37 |
| === beuno is now known as beuno-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === kfogelunch is now known as kfogel | ||
| === beuno-lunch is now known as beuno | ||
| servilio | hi all! is it possible to move a branch into a shared repository and take advantage of the sharing? | 19:26 |
| servilio | I've googled a little bit, but haven't a way to do it so far | 19:26 |
| jam | servilio: 'bzr reconfigure --use-shared' | 19:26 |
| servilio | jam: :O great! thanks! | 19:27 |
| servilio | jam: so I only need to "mv branch repo/" then "bzr reconfigure --use-shared"? | 19:28 |
| servilio | seems to have worked, thanks! | 19:37 |
| ccxCZ | how do I check for uncommitted changes in WorkingTree using bzrlib? | 19:40 |
| jam | ccxCZ: tree.has_changes() ? | 20:18 |
| jam | or do you need the specific changes | 20:18 |
| ccxCZ | jam: that's it, thanks | 20:20 |
| jam | is there a losa around that can take a look at pqm? | 20:22 |
| jam | I just tried to submit something, and I'm now seeing a webserver traceback on http | 20:22 |
| a212901390231901 | erk, hope it's not still my screwup | 20:22 |
| jam | well, it may have been a race, as now doing a refresh shows things as ok | 20:23 |
| jam | I saved the html just to be sure | 20:23 |
| jam | of course, it isn't *telling* me that my request succeeded / failed | 20:23 |
| a212901390231901 | also, | 20:23 |
| a212901390231901 | Definitions of losa on the Web: | 20:23 |
| a212901390231901 | The nuraghe Losa (in Sardinia, close to the village of Abbasanta) is a complex prehistoric building in the shape of a tholos tomb. | 20:23 |
| a212901390231901 | losa? | 20:23 |
| jam | a212901390231901: It's a launchpad sysadmin | 20:24 |
| jam | not sure the exact acronym | 20:24 |
| Chex | jam: ill be with you in a moment | 20:24 |
| jam | thanks Chex | 20:24 |
| Chex | jam: few minutes | 20:24 |
| jam | Chex: so no big rush, I filed a bug about the traceback, and it seems to be running. Though it should have given me a "failure" message from the first submission. | 20:29 |
| rephormat | greetings everyone. | 20:32 |
| rephormat | I am attempting to compile bzr-2.1.0 with python setup.py install, but am getting a gcc failed with exit status 1 | 20:33 |
| jam | rephormat: do you have zlib1-devel ? | 20:35 |
| jam | and other such python devel packages? | 20:35 |
| jam | (also win32/mac/linux ?) | 20:36 |
| Chex | jam: ok, I can try to look for you now | 20:43 |
| jam | Chex: so the first submission seemed to fail without telling me. If you can check the log to see why it didn't send a failure email, I would appreciate it. | 20:45 |
| rephormat | sorry I'm on linux | 20:46 |
| Chex | jam: can you give me the subject line of your submit? makes it easier to find in the logs | 20:46 |
| rephormat | I install python-devel | 20:46 |
| jam | Chex: '(jam) Reduce peak memory usage by 1 compressed text copy during commit in 2a formats.' | 20:46 |
| jam | though I re-submitted that again with a correct url | 20:47 |
| jam | which seems to be running successfully now | 20:47 |
| jam | rephormat: you probably also need to install zlib1g-devel or something along those lines | 20:47 |
| jam | I don't remember the exact name of the package | 20:47 |
| jam | zlib and -dev at least :) | 20:47 |
| rephormat | THANK YOU VERY MUCH!~ | 20:48 |
| rephormat | Thast what it was | 20:48 |
| rephormat | ok now for second question | 20:48 |
| rephormat | what is a good web frontend for bazaar version control system that allows bug reporting? | 20:49 |
| jam | rephormat: Launchpad ? | 20:50 |
| jam | there is loggerhead to view the branch history, there is some integration with trac | 20:50 |
| rephormat | oh yes of course I love that web interface, but I was hoping for something that I could setup and admin internally | 20:50 |
| rephormat | I have tried bzr-trac, but it requires me to start from scratch | 20:51 |
| rephormat | which is kinda strange | 20:51 |
| jam | rephormat: well launchpad is open source, other than needing to rebrand it, you can use it | 20:51 |
| jam | rephormat: 'start from scratch' ? | 20:51 |
| rephormat | I was unable to find a download for launchpad | 20:51 |
| rephormat | I thought you had to use their service | 20:51 |
| jam | https://dev.launchpad.net/ | 20:52 |
| jam | big link for "Get the source code" | 20:52 |
| jam | AFAIK it is a fairly large bit of software to set up | 20:53 |
| jam | and the images are trademarked | 20:53 |
| jam | however | 20:53 |
| jam | I see both: | 20:53 |
| jam | https://edge.launchpad.net/bzr-trac | 20:53 |
| jam | and | 20:53 |
| jam | https://edge.launchpad.net/trac-bzr | 20:53 |
| jam | the former being a "complete rewrite" of the latter | 20:53 |
| rephormat | I'm not sure which of those I used... | 20:53 |
| jam | the latter is the only one I actually knew about | 20:53 |
| rephormat | but one of them was relatively complex to admin | 20:53 |
| mkanat | jam: The trademark guidelines forbid anybody but Canonical from using the images at all? | 20:59 |
| jam | mkanat: I don't really know. I'm not deep in that discussion, its just something I've seen mentioned. | 21:02 |
| jam | I'm certainly not a lawyer | 21:02 |
| jam | my personal impression, is that if you used it in-house only, then you'd probably be fine | 21:02 |
| jam | but once you put it on the web | 21:02 |
| jam | then you are serving images you don't own | 21:02 |
| jam | https://dev.launchpad.net/Getting has some discussion on it | 21:03 |
| jam | "The images/icons are still copyrighted traditionally, to protect Launchpad's visual identity. But they're shipped with the code and are fine to use for development and testing purposes. Just if you launch a production server, it needs to look different -- and have a different name, of course, as "Launchpad" is a trademark. From our point of view, we're doing this to improve our hosted service. " | 21:03 |
| mkanat | jam: Okay. I don't see any Trademark Guidelines for "Launchpad". | 21:08 |
| mkanat | jam: Uuuusually that means that anybody could put up a version of the system and call it Launchpad, as long as they didn't put up some *different* system and call it Launchpad. | 21:09 |
| mkanat | jam: For example, Mozilla and GNOME customize the hell out of Bugzilla, and still call it Bugzilla. | 21:09 |
| mkanat | jam: That could just be because we don't enforce the trademark, though. :-) | 21:10 |
| edgimar | If I've made a commit, and then made additional changes I wanted in that commit, what do I do to get them in there? Is there a way to 'collapse' commits together? | 21:15 |
| jam | edgimar: are you sure it *really* matters? | 21:16 |
| jam | but anyway | 21:16 |
| jam | bzr uncommit; bzr commit | 21:16 |
| jam | bzr uncommit = >remove the last commit from this branch's history, but leave the WT unchanged | 21:16 |
| edgimar | jam, ok - I wasn't clear on what uncommit would do to the WT. | 21:17 |
| jam | edgimar: right, it exists to do this sort of thing :) | 21:17 |
| jam | bzr uncommit && bzr revert if you really want it all gone | 21:17 |
| edgimar | you mean all changes since the tip-1 commit, right? | 21:18 |
| jam | edgimar: bzr revert reverts all changes vs the current tip | 21:21 |
| jam | not just the ones you had uncommitted | 21:21 |
| jam | if you want just those gone | 21:21 |
| jam | bzr merge . -r -1..-2; bzr uncommit | 21:21 |
| a212901390231901 | jam: is it worth submitting a merge req. shaving four bytes off chk_map.LeafNode? I poked it while doing something else, but don't know if enough are ever created to make much of saving. | 21:25 |
| jam | a212901390231901: there are a fair number created sometimes | 21:26 |
| jam | it would probably be worth reviewing | 21:26 |
| SimonK | Has any work been done on any plugins that might support tagging files with labels? | 21:26 |
| a212901390231901 | thanks! | 21:26 |
| mkanat | spm: Hey hey. What version of pygments is installed on the codebrowse server? | 21:38 |
| edgimar | one other question: is there an equivalent to mercurial's 'hg incoming' for bzr? (shows differences between two branches -- i.e. what commits are in one that aren't in another) | 21:56 |
| krisives-gearbox | edgimar: doesn't `bzr missing` do that/ | 21:56 |
| edgimar | krisives-gearbox: indeed it appears to. Thanks - I hadn't noticed it before. | 21:57 |
| krisives-gearbox | edgimar: np, feel free to read my list http://santiance.com/2010/04/a-bazaar-list-of-things/) | 21:59 |
| krisives-gearbox | err URL paste fail http://santiance.com/2010/04/a-bazaar-list-of-things | 21:59 |
| === salgado is now known as salgado-afk | ||
| edgimar | ok another question: if I wanted, say, to change something about commit rev -3 (in fact I do -- forgot to change my 'whoami' setting), what's the way to do that? | 22:13 |
| jam | Chex: any luck? I just submitted another revision, and I don't know whether it succeeded or failed | 22:20 |
| jam | no email | 22:20 |
| jam | no movement on the pqm branch tip | 22:20 |
| Chex | jam: I have 3 patch logs matching that submit subject | 22:23 |
| Chex | you want to see them? | 22:23 |
| jam | Chex: sure | 22:23 |
| Chex | k hang on | 22:24 |
| edgimar | so, I take it there's no easy way to edit an arbitrary commit (i.e. just to change some metadata)? | 22:26 |
| cbz | I don't really understand repositories. What does the last sentence in this mean: | 22:26 |
| cbz | "It is a good idea to create a repository whenever you might create more than one branch of a project. This is true for both working areas where you are doing the development, and any server areas that you use for hosting projects. In the latter case, it is common to want branches without working trees. Since the files in the branch will not be edited directly there is no need to use up disk space for a working tree." | 22:26 |
| eric_f | Is there a good way to do nested trees? Looking to have a top-level project which part of it comes form a separate sub-project. | 22:27 |
| edgimar | Will 'bzr re-sign' change the username used for a commit? | 22:31 |
| Chex | jam: chinstrap:~stasik/isd/ | 22:32 |
| Chex | jam: 1st 2 patches that failed are in there, the 3 patch is giving me an error, empty file for some reason.. , checking on the status of bzr-pqm for you now | 22:33 |
| jam | Chex: so patch.1271877495.log just say "no such file patch.1271877495" | 22:34 |
| jam | are you sure that's right? | 22:34 |
| Chex | jam: | 22:36 |
| Chex | jam: erm, let me see | 22:36 |
| Chex | jam: yes it is.. so both the 2nd and 3rd patch logfile errored out that way.. | 22:43 |
| Chex | jam: and theres nothing exciting in the general pqm.log, either.. | 22:44 |
| jam | k | 22:44 |
| Chex | lifeless: when you are available, please ping us losas, the update we did yesterday seemed to cause issues with ubunet pqm | 22:55 |
| mkanat | Huh, I wonder if pygments is not threadsafe. | 22:58 |
| mwhudson | !/ | 22:58 |
| mwhudson | !?, rather | 22:58 |
| mwhudson | i guess it's possible | 22:58 |
| mkanat | mwhudson: I'm doing a really thorough log analysis, so far there's a vague indication that pygments may indeed be the culprit. But I will let you know when it's fully complete, and I'll post it to the bug. | 22:59 |
| mwhudson | heh, i time "!?, rather" and ubottu sends me a private message | 23:00 |
| mwhudson | type! | 23:00 |
| mwhudson | mkanat: ok | 23:00 |
| jam | !? | 23:06 |
| jam | doesn't seem to if you don't get more verbose | 23:06 |
| mkanat | mwhudson: As a side note, the hung-thread killer needs to be way more aggressive. | 23:09 |
| mwhudson | mkanat: yeah, probably | 23:09 |
| mkanat | mwhudson: In this log it only kills threads after they haven't responded for like 3-5 minutes. | 23:09 |
| mkanat | (Or sometimes 5-10 minutes.) | 23:10 |
| lifeless | Chex: -> lp-code | 23:13 |
| Chex | lifeless: great, thank you | 23:21 |
| krisives-gearbox | edgimar: You can do that by `bzr revert -r 3 myFile` then edit the file and do another `bzr commit` | 23:41 |
| igc | morning | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!