[01:04] Good morning. [01:40] spiv: Is PQM happy with bug 596239 now? [01:40] Launchpad bug 596239 in Bazaar "Bazaar supports https! Update documentation (affected: 1, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/596239 [01:40] jbowtie: good question, let's find out... [01:40] hi there spiv, jbowtie [01:42] I'm just wondering if it's actually using sphinx on Python 2.4 - if it's using pure docutils it won't recognize the ref directive even with the better line wrapping. [01:42] That might put a crimp in my plan to fix up all the links. [01:42] I *think* we stopped using pure docutils, but I might be wrong. [01:43] I'm fairly sure we intended to, at least : [01:43] :) [01:44] HI, poolie, sorry for the lack of bug fixes this weekend, should land some mid-week. [02:00] np, no obligation, we appreciate them [02:02] jbowtie: same error, the Makefile still invokes the 'docs-plain' as part of 'check' target [02:02] poolie: any reason why we haven't switched to just Sphinx in trunk? [02:02] poolie: I thought that was the plan, maybe we just never got around to flipping the last switch? [02:05] spiv, there may be some snags [02:05] perhaps that it's not in the pqm chroot? [02:05] you should check with vila [02:06] Ok [02:06] there is an rt open for sphinx in th chroot [02:06] the chroot should be upgraded from hardy too [02:08] The Makefile has a comment about how "Post 2.0" we will most likely switch the 'docs' target from 'docs-plain' to 'docs-sphinx'. [02:14] spiv, want to chase it with spm etc? [02:20] Sure. [02:21] spm: ping? I'm wondering about the status of installing sphinx in the PQM chroot. lifeless says an RT open, is it blocked on anything? [02:22] spiv: time probably [02:22] That's both good and bad news, then :) [02:22] mmm :-) [02:23] spiv: fwiw, it's 9th in priority in the LP queue atm, exclusive of all the other stuff going on. [02:23] Is that good or bad? :) === _thumper_ is now known as thumper [02:37] bad [02:37] I have several month long things in there ;) [03:31] spiv: So should I rework the patch to be docs-plain compliant, or leave it as a useful test case? [03:35] jbowtie: I think rework it to be docs-plain compliant. You can leave a XXX comment in the source about how to improve it when we can require sphinx. [04:43] This conflict looks incorrectly bracketed: http://paste.ubuntu.com/501267/ [04:43] One line is near-identical between the two conflicting versions (the only difference being punctuation at the end), [04:44] but it is shown as occurring only in one of the two conflicting versions. [04:44] jtv: I think a case like that came up on the list, or perhaps a bug report, recently... [04:51] jtv: https://bugs.edge.launchpad.net/bzr/+bug/616749 ? [04:51] Launchpad bug 616749 in Bazaar "Incorrect merge - Lines missing inside conflict markers (affected: 1, heat: 5)" [Medium,Confirmed] [04:51] spiv: thanks—I'll click "this bug affects me." [07:33] hi all [07:35] hi there vila === poolie_ is now known as poolie [07:35] poolie: helllooo ! [07:36] hi there [07:40] Interesting; running a 'bzr pack' top reports Python is using ~160% CPU (on a 4 CPU laptop), but vmstat consistently shows 25% for the same period. [07:40] I suspect one of these tools is coping better with a process bouncing between CPUs. [07:41] (to be fair I imagine vmstat probably has an easier job here) [07:41] That does mean I need to avoid trusting 'top' as an indication of whether a process is productively using more than one CPU (or even using more than one concurrently at all). [07:47] interesting [07:49] Probably for per-process information on that I should be using perf anyway :) [07:51] that will tell you about all the cpu transitions, if you want that data [07:52] hey poolie *wave* [07:53] Hmm, interesting that sometimes top says Python is on just 100 [07:53] I wonder if that's when it's in pure python code that isn't frequently dropping the GIL? [08:00] spiv: quick question: does the news_merge plugin takes releases into account and sort them in chronological order or does it just left them untouched ? [08:01] spiv: leaving the unreleased one at top that is... (there should be only one at a time right ? :) [08:05] The current version punts as soon as it sees a conflict involving more than sections and bullets. [08:05] spiv: ok [08:06] There's a work-in-progress prototype of one that can cope with more, but it doesn't try re-ordering releases either. [08:06] Although it probably could if we wanted it too... [08:06] hi knittl [08:07] spiv: ok, I didn't respect this order when releasing, so I'm fixing it right now and was wondering... [08:07] poolie: do i really have to sign that agreement? [08:10] weird weird stuff: a VM suddenly colliding with its own ipv6 address... [08:10] * vila suddenly remembers he didn't sacrifice any chiken or goat this morning... [08:13] spiv: bah, there *could* be several releases in progress in the same NEWS file [08:14] vila: yeah, but they'd all have version numbers... [08:14] spiv: yes, but no release date [08:15] I thought the consensus was to sort them by release date, intermixing series, did I get this wrong ? [08:16] now since we can't predict release dates (haha), 'NOT RELEASED YET' should probably stick to the last know one in its series [08:16] and be on top if it's the first in a new series [08:18] I'd thought it was by version, not date. [08:18] But I'm not very sure of that. [08:19] grep ^:2. NEWS [08:20] spiv: at least during the 2.1b era we did sort by date, I think it makes more sense but I'll respect the consensus, so poolie, what's your remembering here ? [08:21] though :2.2b4: 2004-07-09 is not very convincing ;) [08:32] vila i think we should split the news out into one file per series and avoid the issue [08:33] also i think we should not copy news where things are just merged up [08:33] just say "includes everything from 2.0.6" etc [08:33] knittl: yes, i see you already did put "copyright Canonical" but we do need the email signature too [08:34] spiv istm that regarding network performance, we should file (or just mention) bugs about there being too many startup roundtrips [08:34] i think there is one, at least for the graph [08:35] and then i guess there's another about the stream holding fulltexts [08:36] poolie: so you mean we stop using NEWS in favour of NEWS-2.0, NEWS-2.1, etc ? [08:36] yes [08:36] poolie: there will be some fallouts regarding the news_merge plugin and the doc generation [08:37] spiv: how far from completion is your wip on the news_merge plugin ? [08:39] poolie: getting away from NEWS will rejoice jam ;) [08:44] poolie: i didn't do for my last patch [08:44] and i don't really want to [08:45] vila: I don't recall off the top of my head, but probably about 50%? [08:45] poolie: hmm, thinking a bit more about this proposal, I think the consequences are a bit heavy to switch to it quickly and transparently: we'll need to teach evrybody to use the new scheme, update the news_merge plugin, update the doc generation and fix all the quirks encountered doing that (and who knows what I forget here). I'm not that comfortable doing it without giving it a lot of publicity... [08:45] spiv: and can it easily be extended to target NEWS-* instead of NEWS ? [08:46] vila: yes, with the caveat that the hook is per-file [08:47] vila: so it can't really cope with situations that need to consider multiple files together. [08:47] spiv: does this matter ? If a news entry should now appear only in a single file no ? [08:47] s/should/would/ [08:47] Right. [08:47] or did I forget something ? [08:48] It just means it would be hard to make it to implement something like "automatically propagate NEWS entries when merging 2.x -> 2.x+1", if we wanted to do that. [08:49] vila: as far as doc generation goes, I'm pretty sure it would be a clear improvement [08:50] vila: currently the doc generation has to basically do the NEWS -> NEWS-* split itself [08:50] yeah, poolie, I'm not sure the incremental step you're proposing really address the "where did this bug get fixed" need as conveniently as the duplication does today [08:50] So if we start keeping the data in that shape in the first place, we can just delete that cruft. [08:51] spiv: yup, code wise it will simplify this part, but as a communication mean ? [08:51] Well, it apparently is how we are communicating — see the generated docs ;) [08:52] Certainly, as someone that looks at the NEWS file fair frequently to see what changed and/or when something was done, I think I'd find it a little more convenient, if anything. [08:52] spiv: no, I mean about duplicating the news entry or not [08:53] That's orthogonal, surely? [08:53] Besides, we aren't consistent on that today, I think. [08:53] spiv: right, but part of the same proposal ;) [08:53] (Certainly we haven't been in the past) [08:54] Well, as an orthogonal issue, I'm mildly in favour of it. [08:54] But I don't really see it as being related to the split-NEWS proposal at all. [08:54] vila i think we should split the news out into one file per series and avoid the issue [08:55] it's true it's mildly related [08:55] ha, hmm [08:55] i don't care strongly about them [08:55] Well, I don't know why poolie considers it related, but that doesn't change my view :) [08:55] i'd like to get the news merge plugin working [08:55] sorry about the confusion, I ran into it *while* duplicating entries and I mixed the two [08:57] and I ran into this while merging up the bugfixes targeted at running the tests during the package build and I try to avoid losing my focus which I seem to failing :) [08:57] (Separately, it would be nice to explore how to have nice hooks that deal with situations involving multiple files. I think actually it might be possible with the current hook after all, at least in some cases...) [08:57] s/to failing/to be failing at(sp?)/ [08:58] so, do you (poolie, spiv) mind if I finish my NEWS cleaning *before* looking at changing the scheme ? [08:59] (which will also leave us a bit of time to at least prepare the new_merge plugin) [09:00] I don't think any preparation for news_merge is required to maintain the same quality of merging. [09:01] spiv: and can it easily be extended to target NEWS-* instead of NEWS ? [09:01] vila: yes, with the caveat that the hook is per-file [09:01] spiv: You mean it already accepts a glob ? [09:01] vila, what do you mean by 'news cleaning'? [09:01] i don't think i'll mind anyhow [09:01] I mean, developers will need to update their configs [09:02] But that's not a big deal. [09:02] It would be nice to improve, certainly. [09:02] But sufficiently minor to be a blocker. [09:02] poolie: I'm duplicating the news entries while merging up 2.0 -> 2.1 -> 2.2 ... -> bzr.dev [09:02] vila: the "per-file" aspect I was referring to isn't about globbing [09:02] and sorting them while doing it [09:03] vila: it's that imagine you have a single semantic conflict that spans two files === spike_ is now known as spikeWRK [09:03] vila: maybe one branch renames a function, the other moves the definition from file A to file B [09:03] spiv: sure, different topic, I thought you couldn't use a glob right now [09:04] I don't think you can, but it's not a big deal. Update your news_merge_files right now to say news_merge_files=NEWS,NEWS-2.0,NEWS-2.1,NEWS-2.2,NEWS-2.3,NEWS-2.4,NEWS-2.5,NEWS-3.0 and you're sorted for probably the next year at least ;) [09:05] It'd be a nice improvement, and relates I think to a feature request for the bzr-changelog-merger, so I'll definitely look at it quite soon. [09:05] But I don't see that as a blocker for reorganising NEWS. [09:06] spiv: me neither, only as an interruption in another unrelated task [09:09] Well, changes in general do tend to be a bit disruptive. [09:10] So long as we do what we reasonably can to minimise the disruption, I think that's acceptable. [09:12] spiv: I'm not saying it's bad, I'm just saying I don't want to do it while I'm already doing something else than can be done without it in less time :) [09:12] (both elapsed and CPU) [09:15] vila: well, get that other thing done soon then ;) [09:16] More seriously, I'm sure this isn't going to happen overnight. [09:16] Because of the need to tweak doc generation, etc. [09:16] Anyway, EOD for me. Happy autumnal hacking! [09:17] spiv: happy evening [10:44] Hi all [10:44] Can we rollback packs to obsolete packs ? [11:06] rom1: that sounds like a really weird and bad idea, may be you can explain the rationale ? [11:08] well, i have a corrupted repository (i still look for the cause of the corruption). When a user does any operation in the shared repository, a file nopt found error is returned from an indice which is in obsolete packs. [11:09] i guess that an operation has been interrupted while the repositry was packing... [11:09] rom1: it's generally worse than that: a crash or a file system corruption [11:10] rom1: os/fs versions ? [11:10] That's why i am wondering if we can use the obsolete packas as a rollback [11:10] etch/bzr 2.1 [11:10] file system ? [11:11] ie ? [11:11] ext2 3 4 ? [11:11] ext3 / xfs / reiserfs / ntfs / bttrfs [11:11] nfs (urgh) [11:12] ext3 [11:13] * ddaa blames cosmic mind-control rays [11:14] rom1: first, try: md5sum .bzr/repository/packs/* and look for files whose name doesn't match [11:14] rom1: you can do the same for obsolete_packs [11:16] ok, what if i have some ? [11:17] I have made the following test in a copy of my corrupted repository : i copied the expected indices from obsolete to indices & packs [11:17] rom1: the files are created with a name matching their content and *never* modified by bzr, so the files that don't match indicate a problem with the fs or worse the hd [11:17] I could do the blocked operations (ie the previous file not found errors) [11:18] then i repacked the repository, all worked fine [11:18] rom1: we'll come to that shortly, can you do the md5sum check ? [11:18] vila : thx, i understand [11:18] is has been done, and effectively, i have some differences [11:19] bad bad, are these files empty ? [11:19] no [11:19] even worse :( [11:20] rom1: now try: bzr dump-btree .bzr/repository/pack-names --raw [11:20] :( [11:20] would it be eaiser to reconstruct the repo from people's branches/checkouts? [11:20] Glenjamin: last resort, yes [11:21] rom1: pack-names is where the pack files *used* by the repo are recorded [11:21] ok done [11:22] !paste [11:22] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [11:22] http://paste.ubuntu.com/501397/ [11:23] hmpf, a single pack file [11:24] rom1: now we need a .pack file with this base name and the associated index files [11:24] rom1: and we need to know whether they are in packs/ dir or the obsolete_packs/ dir [11:25] found in obsolete [11:25] rom1: depending on the format you use there could be .cix .iix .rix .six .tix index files [11:25] rom1: which ones ? [11:25] all [11:25] *ix and pack [11:26] bah [11:26] rom1: then sorry for annoying you, you were just right to begin with :-) Puth them all in the packs/ dir and all should be fine [11:27] vila : there's no annnoying. Really thx. [11:27] My concern is about the reason of such a failure. [11:27] You seem to target the filesystem ? [11:28] io error, taht's it ? [11:28] rom1: now, bzr move these files *before* creating the new pack-names file, so what you're seeing is X-file-esque, and all reports of such result have *always* been tracked down to a fs failure, generally a system crash [11:28] :) [11:28] rom1: it's an ordering issue with the file system, things happened in a way that doesn't match what the fs is telling us === jtv is now known as jtv-afk [11:29] rom1: when operations are buffered and the system crash, *some* operations are lost, somehow :-/ [11:30] ok, get it. It the first and only repository that causes such a failure. It is a huge one, a really huge one. I suspect the time consuming in packing such a repository and something done/undone during that time... [11:30] rom1: but if you *also* have f.pack files that doesn't pass the md5sum check... it's an indication that your hd may be dying... [11:30] thx vila [11:30] rom1: even ctrl-C'ing a 'bzr pack' should not lead to such a result [11:31] vila : hope so because with 250 developers, i cannot imagine the mess ;) [11:32] but the users are always stonger in the worst ! [11:32] rom1: now 2.1... we've fixed some related bugs in the last.. monthS, nothing recent, which 2.1.x are you using ? [11:32] in theory, pushing all the tips should leave you with a complete repo. [11:32] 2.1.0 [11:34] rom1: and your users access the repository with which protocol ? [11:34] bzr+ssh [11:35] are there known problems with pulling LP repos with bzr head? http://paste.debian.net/91961/ [11:36] rom1: the last fix I had in mind seem to be part of 2.1.0 already... so I'm pretty sure you're safe on bzr side.. which leave only the fs/crash or hd theories [11:37] rom1: now, as Glenjamin hinted, as a last resort, you can ask all devs to push *all* their branches again... hoping that they didn't locally delete some relying on the server... [11:37] vila : thx again. I gonna track this disk/repository. If i find something, i keep you informed. [11:38] rom1: thanks [11:38] rom1: at least for the record, it would be good to file a bug mentioning the file sizes for the .pack files that failed the md5sum check [11:38] ok [11:39] Kamping_Kaiser: you need to upgrade your local repo if I read this right [11:40] Kamping_Kaiser: which will be faster if you compile the extensions too ;) [11:42] vila: cheers. i could probably have extratged that from the error, perhaps i'll readit a few more times in future :) [11:42] Kamping_Kaiser: yeah, can be a bit hard to read :-/ [11:43] :\ [11:52] Kamping_Kaiser: but the reward is a faster bzr ! :-D [11:52] well yes. but i'd rather it succeeded in doing it automagically ;) [11:53] Kamping_Kaiser: the rich_root frontier is a no return one, this can't be done lightly when many people are involved [11:55] vila: the error implies it tried to though. i wouldn't mind it saying 'manually update', i just object to the 'tried, failed, you do it' [11:57] Kamping_Kaiser: hmm, that's convincing :) I don't remember the details though, may be you can file a bug with your rationale to get more feedback or luckily a fix ;) [11:58] grrr, i should have seen that coming :p === jtv-afk is now known as jtv [12:19] can anyone reproduce the :bound alias not working on lightweight checkouts? [12:24] example use case: bzr branch; bzr colo-ify; bzr pull -d :bound :parent [13:51] Hi, I wonder if someone could clear something up for me please? It is to do with the "move" command... [13:51] If I have "folder_one/FileOne.txt" and I decide to move things around a bit using windows explorer rather than "move" command [13:53] so I end up with "folder_two/blah/FileOne.txt", when I do a "bzr status" I get.. removed: folder_one/ folder_one/FileOne.txt, Unknow: folder_two [13:53] that seems ok [13:53] so I do a "bzr move folder_one folder_two" [13:54] mobby: try --after [13:54] bzr status gives me - removed: folder_one/FileOne.txt, renamed folder_one/ => folder_two/, unknown: folder_two/blah [13:54] yvmf [13:54] *yvmv [13:55] if i try to "bzr move" FileOne.txt I get an error saying it already exists. If I commit I end up with... [13:56] renamed folder_one => folder_two, missing folder_two/FileOne.txt renamed folder_one/FileOne.txt => folder_two/FileOne.txt [13:56] but folder_two/FileOne.txt doesn't exist in my working copy [13:57] is this correct? I'm not saying it's wrong, I'm just trying to better understand Bazaar :) [13:58] *Kamping_Kaiser I did wonder about --after but seeing as the commands were working without it I assumed it was automatically guessing the "--after" flag [13:58] hello [13:59] a new bazaar user here .... Q: how do i add user accounts to a new bazaar project? [14:00] i.e. i want to allow other people to log into my zerver and check out/check in sources [14:02] sysRPL: there is no bzr specific user authentication. bzr respects filesystem permissions, so the best way to allow people access is to create accounts either via ssh/sftp, or ftp. And regulate their permissions with existing user management tools [14:02] I'll see if I can dig up a link [14:03] so i need to setup an ftp server? [14:03] i thought bazzar ould BE the server [14:04] bzr can be a server, but there is no user authentication. Also bzr's built in server isn't secure for write access. It's ok for read-only access. [14:04] http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/index.html [14:04] This is the admin guide. It may be a little over kill for you, but it covers everything you need. I'll pick out the parts most important to you. [14:05] http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/simple-setups.html [14:05] http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/security.html [14:05] okay ... i am on windows here [14:05] no sshd [14:06] i'll explore getting it setup to share via ftp [14:06] That link should help you out. [14:06] the first one I mean [14:07] hrmmm [14:08] http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/serve-help.html [14:08] this might help too. it's the command for serving directly with bzr [14:09] http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/other-setups.html#direct-smart-server-access [15:34] hello [15:34] hi jml [15:34] we'd like to import non-master git branches in Launchpad [15:34] I heard you guys were doing something that could help us with that [15:35] jelmer has been working on describing the url format to be able to access it [15:35] I'm not 100% sure why it can't be done in just bzr-git [15:35] but he seems to say it still needs changes in bzr itself [15:35] ok. [15:36] I think we settled on http://path/to/something,name with something,branch=name allowed to be more specific [15:37] makes sense. === deryck is now known as deryck[lunch] === Ursinha is now known as Ursinha-lunch [16:17] Hi :) [16:17] bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' [16:17] I'm getting that error ^^ [16:17] from launchpad. [16:18] you're probably not getting that from launchpad [16:18] Ah, okay. But I am trying to download from Launchpad, that's for sure. [16:18] instead, you are probably trying to get a branch in format 2a on launchpad using a version of bzr that's too old [16:18] so you get the error from your bzr client [16:18] But my version of bzr is 1.5 [16:19] so, that's older than 1.16 [16:19] Which ought to be older than the required 1.16 [16:19] later = newer [16:19] later != older [16:20] so you DO need to install a newer bzr to get that branch [16:20] Well, 1.16 would be released _before_ 1.5 [16:20] So presumably 1.5 is newer. [16:21] Hence 1.16 being the opposite, older [16:21] Um. No, 16 > 5. [16:21] Wha? [16:21] At least, it used to be. Who knows what they've done to math lately... [16:21] So 1.50 < 1.16? [16:21] 1.5 isn't 1.50. It's 1.5. [16:21] 1.5 < 1.16 < 1.50 [16:22] EBADVERSIONNUM [16:22] 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16 [16:22] but there is no bzr 1.50 anyway [16:22] okay, well, I guess I'm off to download a newer bzr. [16:22] EVERSIONNUMBERSARENTDECIMALS [16:22] meh. [16:23] (and cpp should learn to handle apostrophes in #define's, 'cuz it's really hard for me to misspell "aren't" :p) [16:31] Perl is the only thing I know crazy enough to treat versions as floats [16:32] I think everything goes through a cycle of trying, with increasingly ugly hacks, until finally giving up and just treating them implicitly or explicitly and n-ples. [16:33] The Java world annoys me [16:33] Life would be so much easier if they just adopted debian-style versioning [16:33] I know I went for a while trying increasingly rococo schemes before realizing I was being an idiot. [16:40] ok... what's the way I can fix a branch on launchpad to not be stacked on anything anymore? [16:40] reconfigure has an --unstacked arg. Whether it works through LP's black magic I don't know. [16:42] It does work [16:42] Provided the old stacking branch exists [16:42] it does. cool [16:42] Otherwise, we can tell you about more esoteric solutions [16:42] * mtaylor moved the trunk focus branch of a project [16:43] but pushing the new branch wound up stacking it on the old focus (of course) [16:44] I keep meaning to attempt to write a 'bzr push --unstacked' option [16:46] fullermd, maxb: thanks! that worked and was _hella_ easier than the last time I had to do that :) === deryck[lunch] is now known as deryck === Ursinha-lunch is now known as Ursinha === beuno is now known as beuno-lunch [18:01] hey there, am I doing something wrong when doing "bzr push lp:~username/project_name/branch_name" ? [18:02] 'cause it returns "bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Bad status line received" [18:12] nekohayo: sounds like a bad proxy, what os/bzr versions are you using ? [18:13] using ubuntu 10.04, but I'm in a SSH tunnel right now (SOCKS in gnome's proxy preferences) [18:13] nekohayo: but if it try to use https instead of bzr+ssh, it's probably because you didn't 'bzr launchpad-login' (once) [18:14] I believe the thing that resolves lp: URLs doesn't integrate well with proxies. You might like to try manually replacing the lp: with bzr+ssh://bazaar.launchpad.net/ [18:14] maxb: is there a bug report about that? [18:14] or should there be? [18:14] vila: nah, I'm logged into launchpad already [18:15] probably, somewhere :-) [18:15] nekohayo: I'm not sure, it depends on how you configure your proxy... we shouldn't give such an obscure error... but I'm not sure I understand what happens here [18:16] nekohayo: we had bugs with proxies, I don't remember the exact versions, what does 'bzr version' says ? [18:17] nekohayo: there is also a 'bzr ping' plugin that could help validate your proxy [18:18] bzr version 2.1.1 [18:19] bug #558343 may apply [18:19] Launchpad bug 558343 in Bazaar 2.1 "NotImplementedError: "should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented" during lp name lookup (affected: 17, heat: 105)" [Undecided,In progress] https://launchpad.net/bugs/558343 [18:19] ha, may be not ;) [18:19] feeds?! [18:20] maxb: that message was totally obscure too but coming from lp :) [18:20] nekohayo: I'd file a bug, your specific symptom doesn't turn up any other bugs though as vila says one of the wider proxy issue ones might cover it [18:21] ok [18:21] nekohayo: or you can just try to file a bug and see if lp find a dupe... mgz types faster :) [18:21] redoing the (failing) command with -Dhpss and putting that in the bug may help. [18:21] yeah [18:22] and -Dhttp since the error message refers to it [18:26] vila, mgz: putting either -Dhpss or -Dhttp between "bzr" and "push" = same output [18:26] no diff [18:26] ah, sorry, I meant then paste the contents of .bzr.log for that command [18:26] (which will have the extra debugging stuff) [18:28] vila: I've got a fix for tests not having times on babune, but it's ridiculous [18:29] mgz: now you got me interested :) [18:30] filed as https://bugs.launchpad.net/bzr/+bug/649124 [18:30] Launchpad bug 649124 in Bazaar "push to launchpad doesn't work through a SOCKS proxy (SSH tunnel) (affected: 1, heat: 6)" [Undecided,New] [18:31] to get started, here's a picture of the test result classes involved when running selftest --parallel [18:31] thanks folks, gotta go now :) [18:31] nekohayo: Do you have a moment to try one more command? [18:32] sure [18:32] Does bzr push bzr+ssh://bazaar.launchpad.net/~kiddo/recipe-manager/performance work? [18:32] damn, my top secret url! :P [18:32] If so, we can pin the problem squarely on the lp: xmlrpc resolved [18:32] *resolver [18:33] maxb: yes, it works [18:33] bug 186920 I think [18:33] Launchpad bug 186920 in Python "bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls (affected: 18, heat: 139)" [Unknown,Confirmed] https://launchpad.net/bugs/186920 [18:34] mgz: shudder [18:34] mgz: the time is measured on the wrong side of the process boundary ? [18:35] nekohayo: According to comments in that bug, apparently bzr 2.2 will handle this better [18:35] If you are able to upgrade and retest, that would be greate === beuno-lunch is now known as beuno [18:39] well, subunit doesn't actually time tests, it just has a think that whams timestamps in all over the place [18:41] anyway, can fix without touching subunit but need changes in both bzr and testtools [18:41] :-( [18:42] will your changes be *compatible with older testtools ? (Installing 0.9.6 on pqm is still pending for... unkown) [18:43] mmm, good crème caramel [18:44] ^I think so, but working out a way of fixing this without breaking the world (across three projects) was a pain [18:44] mgz: worth mentioning :-/ [18:54] hi folks. i'm working on a branch that adds some functionality to a plugin (bzr-builddeb). obviously i want to do tdd, but i'm not sure of the right/best way to run tests locally. i'd like to disable all plugins but run the tests from my working branch of the bzr-builddeb trunk. the online testing guide didn't help too much with this scenario (or i missed it). any suggestions? [18:54] barry: bzr selftest -s bp.builddeb [18:54] "run all the tests with ids starting with bzrlib.plugins.builddeb" [18:55] if your local branch is where builddeb plugin is currently being taken from [18:55] james_w: cool. do i need to fiddle with ~/.bazaar/plugins to point to my branch? [18:55] james_w: ah, i guess "yes" :) [18:55] if not, then BZR_PLUGINS_AT=builddeb@$PWD bzr selftest -s bp.builddeb [18:55] james_w: nice [18:56] thanks! [18:56] we're closer to being able to have a test.py in builddeb that runs the tests from where it is invoked from [18:56] james_w: that would be a nice addition [19:26]