| spiv | Good morning. | 01:04 |
|---|---|---|
| jbowtie | spiv: Is PQM happy with bug 596239 now? | 01:40 |
| ubot5` | Launchpad bug 596239 in Bazaar "Bazaar supports https! Update documentation (affected: 1, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/596239 | 01:40 |
| spiv | jbowtie: good question, let's find out... | 01:40 |
| poolie | hi there spiv, jbowtie | 01:40 |
| jbowtie | 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 |
| jbowtie | That might put a crimp in my plan to fix up all the links. | 01:42 |
| spiv | I *think* we stopped using pure docutils, but I might be wrong. | 01:42 |
| spiv | I'm fairly sure we intended to, at least : | 01:43 |
| spiv | :) | 01:43 |
| jbowtie | HI, poolie, sorry for the lack of bug fixes this weekend, should land some mid-week. | 01:44 |
| poolie | np, no obligation, we appreciate them | 02:00 |
| spiv | jbowtie: same error, the Makefile still invokes the 'docs-plain' as part of 'check' target | 02:02 |
| spiv | poolie: any reason why we haven't switched to just Sphinx in trunk? | 02:02 |
| spiv | poolie: I thought that was the plan, maybe we just never got around to flipping the last switch? | 02:02 |
| poolie | spiv, there may be some snags | 02:05 |
| poolie | perhaps that it's not in the pqm chroot? | 02:05 |
| poolie | you should check with vila | 02:05 |
| spiv | Ok | 02:06 |
| lifeless | there is an rt open for sphinx in th chroot | 02:06 |
| lifeless | the chroot should be upgraded from hardy too | 02:06 |
| spiv | 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:08 |
| poolie | spiv, want to chase it with spm etc? | 02:14 |
| spiv | Sure. | 02:20 |
| spiv | 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:21 |
| spm | spiv: time probably | 02:22 |
| spiv | That's both good and bad news, then :) | 02:22 |
| spm | mmm :-) | 02:22 |
| spm | spiv: fwiw, it's 9th in priority in the LP queue atm, exclusive of all the other stuff going on. | 02:23 |
| spiv | Is that good or bad? :) | 02:23 |
| === _thumper_ is now known as thumper | ||
| lifeless | bad | 02:37 |
| lifeless | I have several month long things in there ;) | 02:37 |
| jbowtie | spiv: So should I rework the patch to be docs-plain compliant, or leave it as a useful test case? | 03:31 |
| spiv | 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. | 03:35 |
| jtv | This conflict looks incorrectly bracketed: http://paste.ubuntu.com/501267/ | 04:43 |
| jtv | One line is near-identical between the two conflicting versions (the only difference being punctuation at the end), | 04:43 |
| jtv | but it is shown as occurring only in one of the two conflicting versions. | 04:44 |
| spiv | jtv: I think a case like that came up on the list, or perhaps a bug report, recently... | 04:44 |
| spiv | jtv: https://bugs.edge.launchpad.net/bzr/+bug/616749 ? | 04:51 |
| ubot5` | Launchpad bug 616749 in Bazaar "Incorrect merge - Lines missing inside conflict markers (affected: 1, heat: 5)" [Medium,Confirmed] | 04:51 |
| jtv | spiv: thanks—I'll click "this bug affects me." | 04:51 |
| vila | hi all | 07:33 |
| poolie_ | hi there vila | 07:35 |
| === poolie_ is now known as poolie | ||
| vila | poolie: helllooo ! | 07:35 |
| poolie | hi there | 07:36 |
| spiv | 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 |
| spiv | I suspect one of these tools is coping better with a process bouncing between CPUs. | 07:40 |
| spiv | (to be fair I imagine vmstat probably has an easier job here) | 07:41 |
| spiv | 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:41 |
| poolie | interesting | 07:47 |
| spiv | Probably for per-process information on that I should be using perf anyway :) | 07:49 |
| poolie | that will tell you about all the cpu transitions, if you want that data | 07:51 |
| knittl | hey poolie *wave* | 07:52 |
| spiv | Hmm, interesting that sometimes top says Python is on just 100 | 07:53 |
| spiv | I wonder if that's when it's in pure python code that isn't frequently dropping the GIL? | 07:53 |
| vila | 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:00 |
| vila | spiv: leaving the unreleased one at top that is... (there should be only one at a time right ? :) | 08:01 |
| spiv | The current version punts as soon as it sees a conflict involving more than sections and bullets. | 08:05 |
| vila | spiv: ok | 08:05 |
| spiv | 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 |
| spiv | Although it probably could if we wanted it too... | 08:06 |
| poolie | hi knittl | 08:06 |
| vila | spiv: ok, I didn't respect this order when releasing, so I'm fixing it right now and was wondering... | 08:07 |
| knittl | poolie: do i really have to sign that agreement? | 08:07 |
| vila | 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:10 | |
| vila | spiv: bah, there *could* be several releases in progress in the same NEWS file | 08:13 |
| spiv | vila: yeah, but they'd all have version numbers... | 08:14 |
| vila | spiv: yes, but no release date | 08:14 |
| vila | I thought the consensus was to sort them by release date, intermixing series, did I get this wrong ? | 08:15 |
| vila | 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 |
| vila | and be on top if it's the first in a new series | 08:16 |
| spiv | I'd thought it was by version, not date. | 08:18 |
| spiv | But I'm not very sure of that. | 08:18 |
| vila | grep ^:2. NEWS | 08:19 |
| vila | 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:20 |
| vila | though :2.2b4: 2004-07-09 is not very convincing ;) | 08:21 |
| poolie | vila i think we should split the news out into one file per series and avoid the issue | 08:32 |
| poolie | also i think we should not copy news where things are just merged up | 08:33 |
| poolie | just say "includes everything from 2.0.6" etc | 08:33 |
| poolie | knittl: yes, i see you already did put "copyright Canonical" but we do need the email signature too | 08:33 |
| poolie | spiv istm that regarding network performance, we should file (or just mention) bugs about there being too many startup roundtrips | 08:34 |
| poolie | i think there is one, at least for the graph | 08:34 |
| poolie | and then i guess there's another about the stream holding fulltexts | 08:35 |
| vila | poolie: so you mean we stop using NEWS in favour of NEWS-2.0, NEWS-2.1, etc ? | 08:36 |
| poolie | yes | 08:36 |
| vila | poolie: there will be some fallouts regarding the news_merge plugin and the doc generation | 08:36 |
| vila | spiv: how far from completion is your wip on the news_merge plugin ? | 08:37 |
| vila | poolie: getting away from NEWS will rejoice jam ;) | 08:39 |
| knittl | poolie: i didn't do for my last patch | 08:44 |
| knittl | and i don't really want to | 08:44 |
| spiv | vila: I don't recall off the top of my head, but probably about 50%? | 08:45 |
| vila | 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 |
| vila | spiv: and can it easily be extended to target NEWS-* instead of NEWS ? | 08:45 |
| spiv | vila: yes, with the caveat that the hook is per-file | 08:46 |
| spiv | vila: so it can't really cope with situations that need to consider multiple files together. | 08:47 |
| vila | spiv: does this matter ? If a news entry should now appear only in a single file no ? | 08:47 |
| vila | s/should/would/ | 08:47 |
| spiv | Right. | 08:47 |
| vila | or did I forget something ? | 08:47 |
| spiv | 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:48 |
| spiv | vila: as far as doc generation goes, I'm pretty sure it would be a clear improvement | 08:49 |
| spiv | vila: currently the doc generation has to basically do the NEWS -> NEWS-* split itself | 08:50 |
| vila | 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 |
| spiv | So if we start keeping the data in that shape in the first place, we can just delete that cruft. | 08:50 |
| vila | spiv: yup, code wise it will simplify this part, but as a communication mean ? | 08:51 |
| spiv | Well, it apparently is how we are communicating — see the generated docs ;) | 08:51 |
| spiv | 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 |
| vila | spiv: no, I mean about duplicating the news entry or not | 08:52 |
| spiv | That's orthogonal, surely? | 08:53 |
| spiv | Besides, we aren't consistent on that today, I think. | 08:53 |
| vila | spiv: right, but part of the same proposal ;) | 08:53 |
| spiv | (Certainly we haven't been in the past) | 08:53 |
| spiv | Well, as an orthogonal issue, I'm mildly in favour of it. | 08:54 |
| spiv | But I don't really see it as being related to the split-NEWS proposal at all. | 08:54 |
| vila | <poolie> vila i think we should split the news out into one file per series and avoid the issue | 08:54 |
| poolie | it's true it's mildly related | 08:55 |
| vila | ha, hmm | 08:55 |
| poolie | i don't care strongly about them | 08:55 |
| spiv | Well, I don't know why poolie considers it related, but that doesn't change my view :) | 08:55 |
| poolie | i'd like to get the news merge plugin working | 08:55 |
| vila | sorry about the confusion, I ran into it *while* duplicating entries and I mixed the two | 08:55 |
| vila | 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 |
| spiv | (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 |
| vila | s/to failing/to be failing at(sp?)/ | 08:57 |
| vila | so, do you (poolie, spiv) mind if I finish my NEWS cleaning *before* looking at changing the scheme ? | 08:58 |
| vila | (which will also leave us a bit of time to at least prepare the new_merge plugin) | 08:59 |
| spiv | I don't think any preparation for news_merge is required to maintain the same quality of merging. | 09:00 |
| vila | <vila> spiv: and can it easily be extended to target NEWS-* instead of NEWS ? | 09:01 |
| vila | <spiv> vila: yes, with the caveat that the hook is per-file | 09:01 |
| vila | spiv: You mean it already accepts a glob ? | 09:01 |
| poolie | vila, what do you mean by 'news cleaning'? | 09:01 |
| poolie | i don't think i'll mind anyhow | 09:01 |
| spiv | I mean, developers will need to update their configs | 09:01 |
| spiv | But that's not a big deal. | 09:02 |
| spiv | It would be nice to improve, certainly. | 09:02 |
| spiv | But sufficiently minor to be a blocker. | 09:02 |
| vila | poolie: I'm duplicating the news entries while merging up 2.0 -> 2.1 -> 2.2 ... -> bzr.dev | 09:02 |
| spiv | vila: the "per-file" aspect I was referring to isn't about globbing | 09:02 |
| vila | and sorting them while doing it | 09:02 |
| spiv | vila: it's that imagine you have a single semantic conflict that spans two files | 09:03 |
| === spike_ is now known as spikeWRK | ||
| spiv | vila: maybe one branch renames a function, the other moves the definition from file A to file B | 09:03 |
| vila | spiv: sure, different topic, I thought you couldn't use a glob right now | 09:03 |
| spiv | 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:04 |
| spiv | 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 |
| spiv | But I don't see that as a blocker for reorganising NEWS. | 09:05 |
| vila | spiv: me neither, only as an interruption in another unrelated task | 09:06 |
| spiv | Well, changes in general do tend to be a bit disruptive. | 09:09 |
| spiv | So long as we do what we reasonably can to minimise the disruption, I think that's acceptable. | 09:10 |
| vila | 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 |
| vila | (both elapsed and CPU) | 09:12 |
| spiv | vila: well, get that other thing done soon then ;) | 09:15 |
| spiv | More seriously, I'm sure this isn't going to happen overnight. | 09:16 |
| spiv | Because of the need to tweak doc generation, etc. | 09:16 |
| spiv | Anyway, EOD for me. Happy autumnal hacking! | 09:16 |
| vila | spiv: happy evening | 09:17 |
| rom1 | Hi all | 10:44 |
| rom1 | Can we rollback packs to obsolete packs ? | 10:44 |
| vila | rom1: that sounds like a really weird and bad idea, may be you can explain the rationale ? | 11:06 |
| rom1 | 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:08 |
| rom1 | i guess that an operation has been interrupted while the repositry was packing... | 11:09 |
| vila | rom1: it's generally worse than that: a crash or a file system corruption | 11:09 |
| vila | rom1: os/fs versions ? | 11:10 |
| rom1 | That's why i am wondering if we can use the obsolete packas as a rollback | 11:10 |
| rom1 | etch/bzr 2.1 | 11:10 |
| vila | file system ? | 11:10 |
| rom1 | ie ? | 11:11 |
| vila | ext2 3 4 ? | 11:11 |
| ddaa | ext3 / xfs / reiserfs / ntfs / bttrfs | 11:11 |
| vila | nfs (urgh) | 11:11 |
| rom1 | ext3 | 11:12 |
| * ddaa blames cosmic mind-control rays | 11:13 | |
| vila | rom1: first, try: md5sum .bzr/repository/packs/* and look for files whose name doesn't match | 11:14 |
| vila | rom1: you can do the same for obsolete_packs | 11:14 |
| rom1 | ok, what if i have some ? | 11:16 |
| rom1 | 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 |
| vila | 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 |
| rom1 | I could do the blocked operations (ie the previous file not found errors) | 11:17 |
| rom1 | then i repacked the repository, all worked fine | 11:18 |
| vila | rom1: we'll come to that shortly, can you do the md5sum check ? | 11:18 |
| rom1 | vila : thx, i understand | 11:18 |
| rom1 | is has been done, and effectively, i have some differences | 11:18 |
| vila | bad bad, are these files empty ? | 11:19 |
| rom1 | no | 11:19 |
| vila | even worse :( | 11:19 |
| vila | rom1: now try: bzr dump-btree .bzr/repository/pack-names --raw | 11:20 |
| rom1 | :( | 11:20 |
| Glenjamin | would it be eaiser to reconstruct the repo from people's branches/checkouts? | 11:20 |
| vila | Glenjamin: last resort, yes | 11:20 |
| vila | rom1: pack-names is where the pack files *used* by the repo are recorded | 11:21 |
| rom1 | ok done | 11:21 |
| vila | !paste | 11:22 |
| ubot5` | 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 |
| rom1 | http://paste.ubuntu.com/501397/ | 11:22 |
| vila | hmpf, a single pack file | 11:23 |
| vila | rom1: now we need a .pack file with this base name and the associated index files | 11:24 |
| vila | rom1: and we need to know whether they are in packs/ dir or the obsolete_packs/ dir | 11:24 |
| rom1 | found in obsolete | 11:25 |
| vila | rom1: depending on the format you use there could be .cix .iix .rix .six .tix index files | 11:25 |
| vila | rom1: which ones ? | 11:25 |
| rom1 | all | 11:25 |
| rom1 | *ix and pack | 11:25 |
| vila | bah | 11:26 |
| vila | 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:26 |
| rom1 | vila : there's no annnoying. Really thx. | 11:27 |
| rom1 | My concern is about the reason of such a failure. | 11:27 |
| rom1 | You seem to target the filesystem ? | 11:27 |
| rom1 | io error, taht's it ? | 11:28 |
| vila | 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 |
| rom1 | :) | 11:28 |
| vila | 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 | 11:28 |
| === jtv is now known as jtv-afk | ||
| vila | rom1: when operations are buffered and the system crash, *some* operations are lost, somehow :-/ | 11:29 |
| rom1 | 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 |
| vila | 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 |
| rom1 | thx vila | 11:30 |
| vila | rom1: even ctrl-C'ing a 'bzr pack' should not lead to such a result | 11:30 |
| rom1 | vila : hope so because with 250 developers, i cannot imagine the mess ;) | 11:31 |
| rom1 | but the users are always stonger in the worst ! | 11:32 |
| vila | 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 |
| Glenjamin | in theory, pushing all the tips should leave you with a complete repo. | 11:32 |
| rom1 | 2.1.0 | 11:32 |
| vila | rom1: and your users access the repository with which protocol ? | 11:34 |
| rom1 | bzr+ssh | 11:34 |
| Kamping_Kaiser | are there known problems with pulling LP repos with bzr head? http://paste.debian.net/91961/ | 11:35 |
| vila | 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:36 |
| vila | 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 |
| rom1 | vila : thx again. I gonna track this disk/repository. If i find something, i keep you informed. | 11:37 |
| vila | rom1: thanks | 11:38 |
| vila | 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 |
| rom1 | ok | 11:38 |
| vila | Kamping_Kaiser: you need to upgrade your local repo if I read this right | 11:39 |
| vila | Kamping_Kaiser: which will be faster if you compile the extensions too ;) | 11:40 |
| Kamping_Kaiser | vila: cheers. i could probably have extratged that from the error, perhaps i'll readit a few more times in future :) | 11:42 |
| vila | Kamping_Kaiser: yeah, can be a bit hard to read :-/ | 11:42 |
| Kamping_Kaiser | :\ | 11:43 |
| vila | Kamping_Kaiser: but the reward is a faster bzr ! :-D | 11:52 |
| Kamping_Kaiser | well yes. but i'd rather it succeeded in doing it automagically ;) | 11:52 |
| vila | Kamping_Kaiser: the rich_root frontier is a no return one, this can't be done lightly when many people are involved | 11:53 |
| Kamping_Kaiser | 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:55 |
| vila | 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:57 |
| Kamping_Kaiser | grrr, i should have seen that coming :p | 11:58 |
| === jtv-afk is now known as jtv | ||
| Glenjamin | can anyone reproduce the :bound alias not working on lightweight checkouts? | 12:19 |
| Glenjamin | example use case: bzr branch; bzr colo-ify; bzr pull -d :bound :parent | 12:24 |
| mobby | Hi, I wonder if someone could clear something up for me please? It is to do with the "move" command... | 13:51 |
| mobby | If I have "folder_one/FileOne.txt" and I decide to move things around a bit using windows explorer rather than "move" command | 13:51 |
| mobby | 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 |
| mobby | that seems ok | 13:53 |
| mobby | so I do a "bzr move folder_one folder_two" | 13:53 |
| Kamping_Kaiser | mobby: try --after | 13:54 |
| mobby | bzr status gives me - removed: folder_one/FileOne.txt, renamed folder_one/ => folder_two/, unknown: folder_two/blah | 13:54 |
| Kamping_Kaiser | yvmf | 13:54 |
| Kamping_Kaiser | *yvmv | 13:54 |
| mobby | if i try to "bzr move" FileOne.txt I get an error saying it already exists. If I commit I end up with... | 13:55 |
| mobby | renamed folder_one => folder_two, missing folder_two/FileOne.txt renamed folder_one/FileOne.txt => folder_two/FileOne.txt | 13:56 |
| mobby | but folder_two/FileOne.txt doesn't exist in my working copy | 13:56 |
| mobby | is this correct? I'm not saying it's wrong, I'm just trying to better understand Bazaar :) | 13:57 |
| mobby | *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 |
| sysRPL | hello | 13:58 |
| sysRPL | a new bazaar user here .... Q: how do i add user accounts to a new bazaar project? | 13:59 |
| sysRPL | i.e. i want to allow other people to log into my zerver and check out/check in sources | 14:00 |
| rubbs | 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 |
| rubbs | I'll see if I can dig up a link | 14:02 |
| sysRPL | so i need to setup an ftp server? | 14:03 |
| sysRPL | i thought bazzar ould BE the server | 14:03 |
| rubbs | 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 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/index.html | 14:04 |
| rubbs | 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:04 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/simple-setups.html | 14:05 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/security.html | 14:05 |
| sysRPL | okay ... i am on windows here | 14:05 |
| sysRPL | no sshd | 14:05 |
| sysRPL | i'll explore getting it setup to share via ftp | 14:06 |
| rubbs | That link should help you out. | 14:06 |
| rubbs | the first one I mean | 14:06 |
| sysRPL | hrmmm | 14:07 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/serve-help.html | 14:08 |
| rubbs | this might help too. it's the command for serving directly with bzr | 14:08 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/other-setups.html#direct-smart-server-access | 14:09 |
| jml | hello | 15:34 |
| jam | hi jml | 15:34 |
| jml | we'd like to import non-master git branches in Launchpad | 15:34 |
| jml | I heard you guys were doing something that could help us with that | 15:34 |
| jam | jelmer has been working on describing the url format to be able to access it | 15:35 |
| jam | I'm not 100% sure why it can't be done in just bzr-git | 15:35 |
| jam | but he seems to say it still needs changes in bzr itself | 15:35 |
| jml | ok. | 15:35 |
| jam | I think we settled on http://path/to/something,name with something,branch=name allowed to be more specific | 15:36 |
| jml | makes sense. | 15:37 |
| === deryck is now known as deryck[lunch] | ||
| === Ursinha is now known as Ursinha-lunch | ||
| jeremiah | Hi :) | 16:17 |
| jeremiah | bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' | 16:17 |
| jeremiah | I'm getting that error ^^ | 16:17 |
| jeremiah | from launchpad. | 16:17 |
| ddaa | you're probably not getting that from launchpad | 16:18 |
| jeremiah | Ah, okay. But I am trying to download from Launchpad, that's for sure. | 16:18 |
| ddaa | 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 |
| ddaa | so you get the error from your bzr client | 16:18 |
| jeremiah | But my version of bzr is 1.5 | 16:18 |
| ddaa | so, that's older than 1.16 | 16:19 |
| jeremiah | Which ought to be older than the required 1.16 | 16:19 |
| ddaa | later = newer | 16:19 |
| ddaa | later != older | 16:19 |
| ddaa | so you DO need to install a newer bzr to get that branch | 16:20 |
| jeremiah | Well, 1.16 would be released _before_ 1.5 | 16:20 |
| jeremiah | So presumably 1.5 is newer. | 16:20 |
| jeremiah | Hence 1.16 being the opposite, older | 16:21 |
| fullermd | Um. No, 16 > 5. | 16:21 |
| jeremiah | Wha? | 16:21 |
| fullermd | At least, it used to be. Who knows what they've done to math lately... | 16:21 |
| jeremiah | So 1.50 < 1.16? | 16:21 |
| fullermd | 1.5 isn't 1.50. It's 1.5. | 16:21 |
| ddaa | 1.5 < 1.16 < 1.50 | 16:21 |
| jeremiah | EBADVERSIONNUM | 16:22 |
| fullermd | 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 |
| ddaa | but there is no bzr 1.50 anyway | 16:22 |
| jeremiah | okay, well, I guess I'm off to download a newer bzr. | 16:22 |
| fullermd | EVERSIONNUMBERSARENTDECIMALS | 16:22 |
| jeremiah | meh. | 16:22 |
| fullermd | (and cpp should learn to handle apostrophes in #define's, 'cuz it's really hard for me to misspell "aren't" :p) | 16:23 |
| maxb | Perl is the only thing I know crazy enough to treat versions as floats | 16:31 |
| fullermd | 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:32 |
| maxb | The Java world annoys me | 16:33 |
| maxb | Life would be so much easier if they just adopted debian-style versioning | 16:33 |
| fullermd | I know I went for a while trying increasingly rococo schemes before realizing I was being an idiot. | 16:33 |
| mtaylor | ok... what's the way I can fix a branch on launchpad to not be stacked on anything anymore? | 16:40 |
| fullermd | reconfigure has an --unstacked arg. Whether it works through LP's black magic I don't know. | 16:40 |
| maxb | It does work | 16:42 |
| maxb | Provided the old stacking branch exists | 16:42 |
| mtaylor | it does. cool | 16:42 |
| maxb | Otherwise, we can tell you about more esoteric solutions | 16:42 |
| * mtaylor moved the trunk focus branch of a project | 16:42 | |
| mtaylor | but pushing the new branch wound up stacking it on the old focus (of course) | 16:43 |
| maxb | I keep meaning to attempt to write a 'bzr push --unstacked' option | 16:44 |
| mtaylor | fullermd, maxb: thanks! that worked and was _hella_ easier than the last time I had to do that :) | 16:46 |
| === deryck[lunch] is now known as deryck | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| nekohayo | hey there, am I doing something wrong when doing "bzr push lp:~username/project_name/branch_name" ? | 18:01 |
| nekohayo | 'cause it returns "bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Bad status line received" | 18:02 |
| vila | nekohayo: sounds like a bad proxy, what os/bzr versions are you using ? | 18:12 |
| nekohayo | using ubuntu 10.04, but I'm in a SSH tunnel right now (SOCKS in gnome's proxy preferences) | 18:13 |
| vila | nekohayo: but if it try to use https instead of bzr+ssh, it's probably because you didn't 'bzr launchpad-login' (once) | 18:13 |
| maxb | 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 |
| nekohayo | maxb: is there a bug report about that? | 18:14 |
| nekohayo | or should there be? | 18:14 |
| nekohayo | vila: nah, I'm logged into launchpad already | 18:14 |
| maxb | probably, somewhere :-) | 18:15 |
| vila | 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:15 |
| vila | nekohayo: we had bugs with proxies, I don't remember the exact versions, what does 'bzr version' says ? | 18:16 |
| vila | nekohayo: there is also a 'bzr ping' plugin that could help validate your proxy | 18:17 |
| nekohayo | bzr version 2.1.1 | 18:18 |
| vila | bug #558343 may apply | 18:19 |
| ubot5` | 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 |
| vila | ha, may be not ;) | 18:19 |
| maxb | feeds?! | 18:19 |
| vila | maxb: that message was totally obscure too but coming from lp :) | 18:20 |
| mgz | 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:20 |
| nekohayo | ok | 18:21 |
| vila | nekohayo: or you can just try to file a bug and see if lp find a dupe... mgz types faster :) | 18:21 |
| mgz | redoing the (failing) command with -Dhpss and putting that in the bug may help. | 18:21 |
| nekohayo | yeah | 18:21 |
| vila | and -Dhttp since the error message refers to it | 18:22 |
| nekohayo | vila, mgz: putting either -Dhpss or -Dhttp between "bzr" and "push" = same output | 18:26 |
| nekohayo | no diff | 18:26 |
| mgz | ah, sorry, I meant then paste the contents of .bzr.log for that command | 18:26 |
| mgz | (which will have the extra debugging stuff) | 18:26 |
| mgz | vila: I've got a fix for tests not having times on babune, but it's ridiculous | 18:28 |
| vila | mgz: now you got me interested :) | 18:29 |
| nekohayo | filed as https://bugs.launchpad.net/bzr/+bug/649124 | 18:30 |
| ubot5` | Launchpad bug 649124 in Bazaar "push to launchpad doesn't work through a SOCKS proxy (SSH tunnel) (affected: 1, heat: 6)" [Undecided,New] | 18:30 |
| mgz | to get started, here's a picture of the test result classes involved when running selftest --parallel <http://float.endofinternet.org/temp/subcomprehensible.txt> | 18:31 |
| nekohayo | thanks folks, gotta go now :) | 18:31 |
| maxb | nekohayo: Do you have a moment to try one more command? | 18:31 |
| nekohayo | sure | 18:32 |
| maxb | Does bzr push bzr+ssh://bazaar.launchpad.net/~kiddo/recipe-manager/performance work? | 18:32 |
| nekohayo | damn, my top secret url! :P | 18:32 |
| maxb | If so, we can pin the problem squarely on the lp: xmlrpc resolved | 18:32 |
| maxb | *resolver | 18:32 |
| nekohayo | maxb: yes, it works | 18:33 |
| maxb | bug 186920 I think | 18:33 |
| ubot5` | 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:33 |
| vila | mgz: shudder | 18:34 |
| vila | mgz: the time is measured on the wrong side of the process boundary ? | 18:34 |
| maxb | nekohayo: According to comments in that bug, apparently bzr 2.2 will handle this better | 18:35 |
| maxb | If you are able to upgrade and retest, that would be greate | 18:35 |
| === beuno-lunch is now known as beuno | ||
| mgz | well, subunit doesn't actually time tests, it just has a think that whams timestamps in all over the place | 18:39 |
| mgz | anyway, can fix without touching subunit but need changes in both bzr and testtools | 18:41 |
| vila | :-( | 18:41 |
| vila | will your changes be *compatible with older testtools ? (Installing 0.9.6 on pqm is still pending for... unkown) | 18:42 |
| mgz | mmm, good crème caramel | 18:43 |
| mgz | ^I think so, but working out a way of fixing this without breaking the world (across three projects) was a pain | 18:44 |
| vila | mgz: worth mentioning :-/ | 18:44 |
| barry | 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 |
| james_w | barry: bzr selftest -s bp.builddeb | 18:54 |
| james_w | "run all the tests with ids starting with bzrlib.plugins.builddeb" | 18:54 |
| james_w | if your local branch is where builddeb plugin is currently being taken from | 18:55 |
| barry | james_w: cool. do i need to fiddle with ~/.bazaar/plugins to point to my branch? | 18:55 |
| barry | james_w: ah, i guess "yes" :) | 18:55 |
| james_w | if not, then BZR_PLUGINS_AT=builddeb@$PWD bzr selftest -s bp.builddeb | 18:55 |
| barry | james_w: nice | 18:55 |
| barry | thanks! | 18:56 |
| james_w | 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 |
| barry | james_w: that would be a nice addition | 18:56 |
| barry | james_w: what version of python does bzr-bd have to remain compatible with? | 19:26 |
| james_w | barry: bzr sticks with 2.4, and I tend to stick with that | 19:26 |
| barry | james_w: cool, so no ''.format() :) (and i'll have to install py24 and py25 from source) | 19:27 |
| james_w | barry: yeah, sorry | 19:27 |
| james_w | barry: I don't actually test on 2.4 anymore though :-) | 19:27 |
| barry | no worries | 19:27 |
| barry | :-D | 19:27 |
| james_w | it was just that until recently I didn't know any >=2.5 features, so would never write any ;-) | 19:28 |
| ScottK | Do it in a Debian VM and you won't have to build 2.5 from source. | 19:28 |
| barry | ScottK: yeah. james_w: 2.6 is a nice sweet spot. has some great features (.format among my favorites) | 19:29 |
| barry | but anyway... thanks | 19:29 |
| james_w | I've been enjoying context managers | 19:29 |
| james_w | haven't tried .format() yet | 19:30 |
| maxb | 2.5 for lucid is still lurking in the launchpad PPA | 19:31 |
| maxb | which reminds me, I should propose removing that | 19:31 |
| barry | james_w: with statements are highly awesome | 19:31 |
| * barry is old skool and builds python from source in his sleep | 19:32 | |
| barry | james_w: so BZR_PLUGINS_AT doesn't override a different version of the same plugin in ~/.bazaar/plugins, right? | 20:23 |
| james_w | barry: I thought it did | 20:23 |
| vila | barry: yes it does or it will be useless, or did I misunderstood the question ? | 20:24 |
| barry | james_w: oh, nm. i had conflicting registration code in a differently named plugin | 20:24 |
| james_w | hi vila | 20:24 |
| vila | james_w: hey :) | 20:24 |
| mwhudson | BZR_PLUGINS_AT is awesome, btw | 20:24 |
| barry | vila: no, it's pebkac. i register ubuntu: in bzr-debuntu but i'm moving that to bzr-builddeb ;) | 20:24 |
| barry | and testing the latter | 20:24 |
| barry | duh | 20:24 |
| vila | barry: ouch 8-) | 20:24 |
| vila | barry: there is also BZR_DISABLE_PLUGINS, just for you :) | 20:25 |
| barry | vila: you guys think of everything! :) | 20:25 |
| vila | barry: nah, just hacked it furiously and bzr pqm-submit --two-days-ago | 20:26 |
| agruman | is it possible to have a (binary) file in bzr that there is only one version of (ex update will delete old one completely)? | 20:47 |
| beuno | agruman, no, not possible | 20:52 |
| git__ | is there a way to bzr upload to a remote ftp site without having it delete the log file there that's not in the working tree | 20:59 |
| beuno | git__, I *think* we added a bzr-upload ignore command with vila a while back | 21:01 |
| vila | beuno: hehe almost, there is .bzrupload-ignore file, but don't forget to commit it as it applies to the uploaded revision | 21:02 |
| vila | git__: ^ | 21:03 |
| beuno | that's right | 21:03 |
| git__ | let me try | 21:04 |
| git__ | works like a charm, thanks !!! | 21:06 |
| vila | beuno: thumbs up ! | 21:06 |
| beuno | woo | 21:07 |
| roryy | huh. launchpad is pretty awesome. | 21:29 |
| ddaa | yup | 21:29 |
| roryy | g'night! | 21:29 |
| mgz | vila: put up both branches for the test timings fix, if you want to give 'em a run on babune. now I can go to bed and have nightmares about being chased by subunit streams. | 21:43 |
| vila | mgz: testools branch and bzr.dev branch ? | 21:44 |
| mgz | yup. | 21:44 |
| vila | urls ? | 21:45 |
| mgz | lp:~gz/bzr/use_testtools_timings_625594 and p:~gz/testtools/result_timings_forwarding_625594 | 21:45 |
| vila | mgz: caveats ? | 21:47 |
| vila | mgz: can use this testtools with an unmodified bzr, can we use this bzr with an unmodified testtools | 21:47 |
| vila | mgz: I don't want to sound too demanding, I just want to know what will break if mess things up :) | 21:48 |
| mgz | I think it's fine both ways, but the testtools change is more invasive. | 21:50 |
| vila | mgz: any significant subset we can try it against crosses your mind / | 21:50 |
| vila | mgz: any significant subset we can try it against crosses your mind ? | 21:50 |
| vila | -s subset I mean | 21:50 |
| mgz | I like bt.test_ or bb. | 21:51 |
| vila | oops, wrong branch :) | 21:54 |
| vila | mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/ in progress | 21:58 |
| mgz | oo, is that new? | 21:59 |
| vila | not quite, but the plan is to make it open to devs | 22:00 |
| vila | and *that* is not done yet | 22:00 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-gentoo/lastCompletedBuild/testReport/ | 22:01 |
| mgz | ...I was just pasting that too | 22:01 |
| mgz | looks good! | 22:01 |
| vila | ! | 22:01 |
| vila | yup :) | 22:01 |
| bialix | good sleepless night, evryone | 22:02 |
| vila | finally... we may get some idea why FreeBSD is so slower than the others (I'm pretty sure it's self specific but why...) | 22:02 |
| bialix | \o_ vila | 22:03 |
| vila | bialix: hey ! | 22:03 |
| vila | mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/lastCompletedBuild/aggregatedTestReport/ | 22:03 |
| bialix | \o_ mgz | 22:03 |
| vila | ^ is the right page to track for completion | 22:03 |
| mgz | hey bialix! | 22:03 |
| fullermd | It's slower because bialix isn't sleeping? | 22:05 |
| bialix | that will explain many problems | 22:05 |
| vila | ...and the solution will be sooo elegant: Hey ! Bialix, go to sleep | 22:06 |
| fullermd | To think, AMD and Intel are spending $kadzillions on speeding up CPU's, when they could just spend a few bucks on sleeping pills for you instead. | 22:06 |
| * fullermd has a revoluationary new business plan. | 22:06 | |
| bialix | kill the chicken? | 22:06 |
| bialix | or just me | 22:07 |
| * fullermd has TWO revolutionary new business plans! | 22:07 | |
| vila | bill the kitchen > | 22:07 |
| vila | bill the kitchen ? | 22:07 |
| vila | grrr | 22:07 |
| vila | bialix: nah, fullermd is in the goats business now | 22:07 |
| fullermd | "Your computer systems too slow? Pay us $2750 a day and provide a cot, and we'll fly bialix out to your location to take a nap!" | 22:08 |
| bialix | man who stares on the goat? | 22:08 |
| bialix | fullermd: that won't scale | 22:09 |
| bialix | or you need to buy a cloning license as well | 22:09 |
| vila | bialix: no, just selling goats to be killed, works better than chickens | 22:09 |
| fullermd | It doesn't have to scale; I'll split the proceeds down the middle with you, and I can live very happily on $1375 a day. | 22:09 |
| * ddaa applaudes fullermd for his business acumen | 22:10 | |
| * bialix mutters: a day or a night? | 22:10 | |
| fullermd | And heck, it'll be great for you; you'll have a boss who never yells at you for sleeping on the job. What more can you ask? | 22:10 |
| ddaa | the thing, is you'll need to sleep 24/7 | 22:11 |
| vila | bialix: fullermd doesn't care, he lives in a cave, no light there anyway | 22:11 |
| ddaa | lest customers start complaining | 22:11 |
| ddaa | so maybe it's not such a good deal for you | 22:11 |
| bialix | hey ddaa | 22:11 |
| ddaa | but at least it will sustain your wife and children ;-) | 22:11 |
| fullermd | Well, we price for risk. For an extra $20k, we'll put bialix into an induced coma. | 22:11 |
| bialix | sounds good, but the price is too slow, I think | 22:12 |
| fullermd | Well, that's per day. | 22:12 |
| fullermd | Anyway, if it kills you, I figure we can keep you from smelling for a week or so, and keep charging them for the extra days. | 22:13 |
| fullermd | (I know, it's hard to believe nobody's offering me senior executive positions, isn't it?) | 22:14 |
| bialix | yes, it is | 22:14 |
| ddaa | I figure ukrainians are essentially imputrescible, with all the vodka... | 22:14 |
| vila | mgz: don't forget to add the babune url in your mp | 22:14 |
| ddaa | otoh, the french decay very fast, with all the smelly cheese | 22:15 |
| fullermd | So, if we cross-bred them, we'd get... moldy vodka? | 22:16 |
| mgz | vila: which one? :) | 22:16 |
| vila | mgz: the aggregated one I thin, it gives access to all the details | 22:18 |
| vila | oh, hmm, you need in number in there | 22:18 |
| vila | http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/93/aggregatedTestReport/ | 22:18 |
| mgz | I've got a free bsd slowness guess. | 22:27 |
| mgz | Seems to be on writing to the filesystem. Different sort of tmp partition? | 22:28 |
| maxb | abentley: Hi. Could you upload the bzrtools 2.2.0 tarball to Launchpad? Thanks. | 22:45 |
| vila | mgz: tmpfs configured there AFAIR but I haven't checked for... pfew, never since I started hudson | 22:47 |
| dobey | how does one do _iter_revisions() on a RemoteRepository, since it doesn't seem to have an _iter_revisions() method? | 23:15 |
| bialix | dobey: it seems the closest method you can use is get_revisions() | 23:23 |
| dobey | yeah, i'm trying that now | 23:24 |
| lifeless | _iter_revisions is private ;) | 23:25 |
| lifeless | dobey: what are you trying to calculate? | 23:25 |
| dobey | lifeless: i have a graph result, and i am iterating over the revisions in it, to get the apparent authors for all the revisions in the set | 23:27 |
| lifeless | kk | 23:30 |
| dobey | and _foo isn't truly private in python, __foo is though. | 23:33 |
| bialix | it's a convention | 23:34 |
| lifeless | dobey: __foo is no more private. | 23:36 |
| lifeless | dobey: There's no enforcement ever; _ is widely recognised as not-public-thanks. | 23:36 |
| dobey | lifeless: trying to access __foo raises an exception. | 23:37 |
| dobey | accessing _foo does not | 23:37 |
| lifeless | thats because __foo is compiled to __ClassName_foo | 23:38 |
| lifeless | or something approximately like that | 23:38 |
| lifeless | anyhow | 23:38 |
| dobey | anyway, get_revisions() is sufficient | 23:40 |
| === Ursinha is now known as Ursinha-afk | ||
| dobey | thanks | 23:45 |
| bialix | dOxxx: hi | 23:50 |
| dOxxx | bialix: hey :) | 23:50 |
| bialix | can you comment something on bug #505692 ? | 23:50 |
| ubot5` | Launchpad bug 505692 in Bazaar Explorer "Bazaar Launcher (dock icon) for Mac OSX (affected: 4, heat: 20)" [Wishlist,Confirmed] https://launchpad.net/bugs/505692 | 23:50 |
| bialix | dOxxx: ^ | 23:51 |
| bialix | dOxxx: is it something that Mac installer should provide or? | 23:51 |
| dOxxx | bialix: the mac installer should provide an .app bundle for launching bzr explorer, I just haven't gotten around to doing it. | 23:52 |
| dOxxx | I think there's already a bug for it on the installer project | 23:52 |
| dOxxx | hmmm or not | 23:52 |
| dOxxx | ah it's in bzr-explorer project | 23:53 |
| dOxxx | https://bugs.launchpad.net/bzr-explorer/+bug/505692 | 23:53 |
| ubot5` | Launchpad bug 505692 in Bazaar Explorer "Bazaar Launcher (dock icon) for Mac OSX (affected: 4, heat: 20)" [Wishlist,Confirmed] | 23:53 |
| dOxxx | err | 23:54 |
| dOxxx | ues | 23:54 |
| dOxxx | yes | 23:54 |
| dOxxx | um | 23:54 |
| dOxxx | that's the same bug XD | 23:54 |
| bialix | yep | 23:55 |
| dOxxx | I can take a look at it, if you like. | 23:55 |
| dOxxx | It does seem to be something that should belong to the installer. | 23:55 |
| bialix | I need some comment along the bug discussion | 23:55 |
| bialix | so I can understand what needs to be done | 23:56 |
| dOxxx | ok, I'll add something | 23:56 |
| bialix | or change the project to mac-installer | 23:56 |
| dOxxx | I'll do that | 23:56 |
| bialix | or add mac-installer as affected too | 23:56 |
| bialix | something | 23:56 |
| bialix | anything | 23:57 |
| bialix | dOxxx: thank you | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!