[01:04] <spiv> Good morning.
[01:40] <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:42] <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:43] <spiv> I'm fairly sure we intended to, at least :
[01:43] <spiv> :)
[01:44] <jbowtie> HI, poolie, sorry for the lack of bug fixes this weekend, should land some mid-week.
[02:00] <poolie> np, no obligation, we appreciate them
[02:02] <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:05] <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:06] <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:08] <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:14] <poolie> spiv, want to chase it with spm etc?
[02:20] <spiv> Sure.
[02:21] <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:22] <spm> spiv: time probably
[02:22] <spiv> That's both good and bad news, then :)
[02:22] <spm> mmm :-)
[02:23] <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:37] <lifeless> bad
[02:37] <lifeless> I have several month long things in there ;)
[03:31] <jbowtie> spiv: So should I rework the patch to be docs-plain compliant, or leave it as a useful test case?
[03:35] <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.
[04:43] <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:44] <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:51] <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."
[07:33] <vila> hi all
[07:35] <poolie_> hi there vila
[07:35] <vila> poolie: helllooo !
[07:36] <poolie> hi there
[07:40] <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:41] <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:47] <poolie> interesting
[07:49] <spiv> Probably for per-process information on that I should be using perf anyway :)
[07:51] <poolie> that will tell you about all the cpu transitions, if you want that data
[07:52] <knittl> hey poolie *wave*
[07:53] <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?
[08:00] <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:01] <vila> spiv: leaving the unreleased one at top that is... (there should be only one at a time right ? :)
[08:05] <spiv> The current version punts as soon as it sees a conflict involving more than sections and bullets.
[08:05] <vila> spiv: ok
[08:06] <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:07] <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:10] <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:13] <vila> spiv: bah, there *could* be several releases in progress in the same NEWS file
[08:14] <spiv> vila: yeah, but they'd all have version numbers...
[08:14] <vila> spiv: yes, but no release date
[08:15] <vila> I thought the consensus was to sort them by release date, intermixing series, did I get this wrong ?
[08:16] <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:18] <spiv> I'd thought it was by version, not date.
[08:18] <spiv> But I'm not very sure of that.
[08:19] <vila> grep ^:2. NEWS
[08:20] <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:21] <vila> though :2.2b4: 2004-07-09 is not very convincing ;)
[08:32] <poolie> vila i think we should split the news out into one file per series and avoid the issue
[08:33] <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:34] <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:35] <poolie> and then i guess there's another about the stream holding fulltexts
[08:36] <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:37] <vila> spiv: how far from completion is your wip on the news_merge plugin ?
[08:39] <vila> poolie: getting away from NEWS will rejoice jam ;)
[08:44] <knittl> poolie: i didn't do for my last patch
[08:44] <knittl> and i don't really want to
[08:45] <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:46] <spiv> vila: yes, with the caveat that the hook is per-file
[08:47] <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:48] <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:49] <spiv> vila: as far as doc generation goes, I'm pretty sure it would be a clear improvement
[08:50] <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:51] <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:52] <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:53] <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:54] <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.
 vila i think we should split the news out into one file per series and avoid the issue
[08:55] <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:57] <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:58] <vila> so, do you (poolie, spiv) mind if I finish my NEWS cleaning *before* looking at changing the scheme ?
[08:59] <vila> (which will also leave us a bit of time to at least prepare the new_merge plugin)
[09:00] <spiv> I don't think any preparation for news_merge is required to maintain the same quality of merging.
 spiv: and can it easily be extended to target NEWS-* instead of NEWS ?
 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:02] <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:03] <spiv> vila: it's that imagine you have a single semantic conflict that spans two files
[09:03] <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:04] <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:05] <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:06] <vila> spiv: me neither, only as an interruption in another unrelated task
[09:09] <spiv> Well, changes in general do tend to be a bit disruptive.
[09:10] <spiv> So long as we do what we reasonably can to minimise the disruption, I think that's acceptable.
[09:12] <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:15] <spiv> vila: well, get that other thing done soon then ;)
[09:16] <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:17] <vila> spiv: happy evening
[10:44] <rom1> Hi all
[10:44] <rom1> Can we rollback packs to obsolete packs ?
[11:06] <vila> rom1: that sounds like a really weird and bad idea, may be you can explain the rationale ?
[11:08] <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:09] <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:10] <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:11] <rom1> ie ?
[11:11] <vila> ext2 3 4 ?
[11:11] <ddaa> ext3 / xfs / reiserfs / ntfs / bttrfs
[11:11] <vila> nfs (urgh)
[11:12] <rom1> ext3
[11:13]  * ddaa blames cosmic mind-control rays
[11:14] <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:16] <rom1> ok, what if i have some ?
[11:17] <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:18] <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:19] <vila> bad bad, are these files empty ?
[11:19] <rom1> no
[11:19] <vila> even worse :(
[11:20] <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:21] <vila> rom1: pack-names is where the pack files *used* by the repo are recorded
[11:21] <rom1> ok done
[11:22] <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:23] <vila> hmpf, a single pack file
[11:24] <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:25] <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:26] <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:27] <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:28] <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:29] <vila> rom1: when operations are buffered and the system crash, *some* operations are lost, somehow :-/
[11:30] <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:31] <rom1> vila : hope so because with 250 developers, i cannot imagine the mess ;)
[11:32] <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:34] <vila> rom1: and your users access the repository with which protocol ?
[11:34] <rom1> bzr+ssh
[11:35] <Kamping_Kaiser> are there known problems with pulling LP repos with bzr head? http://paste.debian.net/91961/
[11:36] <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:37] <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:38] <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:39] <vila> Kamping_Kaiser: you need to upgrade your local repo if I read this right
[11:40] <vila> Kamping_Kaiser: which will be faster if you compile the extensions too ;)
[11:42] <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:43] <Kamping_Kaiser> :\
[11:52] <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:53] <vila> Kamping_Kaiser: the rich_root frontier is a no return one, this can't be done lightly when many people are involved
[11:55] <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:57] <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:58] <Kamping_Kaiser> grrr, i should have seen that coming :p
[12:19] <Glenjamin> can anyone reproduce the :bound alias not working on lightweight checkouts?
[12:24] <Glenjamin> example use case: bzr branch; bzr colo-ify; bzr pull -d :bound :parent
[13:51] <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:53] <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:54] <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:55] <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:56] <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:57] <mobby> is this correct? I'm not saying it's wrong, I'm just trying to better understand Bazaar :)
[13:58] <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:59] <sysRPL> a new bazaar user here .... Q: how do i add user accounts to a new bazaar project?
[14:00] <sysRPL> i.e. i want to allow other people to log into my zerver and check out/check in sources
[14:02] <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:03] <sysRPL> so i need to setup an ftp server?
[14:03] <sysRPL> i thought bazzar ould BE the server
[14:04] <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:05] <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:06] <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:07] <sysRPL> hrmmm
[14:08] <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:09] <rubbs> http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/other-setups.html#direct-smart-server-access
[15:34] <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:35] <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:36] <jam> I think we settled on http://path/to/something,name with something,branch=name allowed to be more specific
[15:37] <jml> makes sense.
[16:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <fullermd> (and cpp should learn to handle apostrophes in #define's, 'cuz it's really hard for me to misspell "aren't"  :p)
[16:31] <maxb> Perl is the only thing I know crazy enough to treat versions as floats
[16:32] <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:33] <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:40] <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:42] <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:43] <mtaylor> but pushing the new branch wound up stacking it on the old focus (of course)
[16:44] <maxb> I keep meaning to attempt to write a 'bzr push --unstacked' option
[16:46] <mtaylor> fullermd, maxb: thanks! that worked and was _hella_ easier than the last time I had to do that :)
[18:01] <nekohayo> hey there, am I doing something wrong when doing "bzr push lp:~username/project_name/branch_name" ?
[18:02] <nekohayo> 'cause it returns "bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Bad status line received"
[18:12] <vila> nekohayo: sounds like a bad proxy, what os/bzr versions are you using ?
[18:13] <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:14] <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:15] <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:16] <vila> nekohayo: we had bugs with proxies, I don't remember the exact versions, what does 'bzr version' says ?
[18:17] <vila> nekohayo: there is also a 'bzr ping' plugin that could help validate your proxy
[18:18] <nekohayo> bzr version 2.1.1
[18:19] <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:20] <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:21] <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:22] <vila> and -Dhttp since the error message refers to it
[18:26] <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:28] <mgz> vila: I've got a fix for tests not having times on babune, but it's ridiculous
[18:29] <vila> mgz: now you got me interested :)
[18:30] <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:31] <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:32] <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:33] <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:34] <vila> mgz: shudder
[18:34] <vila> mgz: the time is measured on the wrong side of the process boundary ?
[18:35] <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:39] <mgz> well, subunit doesn't actually time tests, it just has a think that whams timestamps in all over the place
[18:41] <mgz> anyway, can fix without touching subunit but need changes in both bzr and testtools
[18:41] <vila> :-(
[18:42] <vila> will your changes be *compatible with older testtools ? (Installing 0.9.6 on pqm is still pending for... unkown)
[18:43] <mgz> mmm, good crème caramel
[18:44] <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:54] <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:55] <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:56] <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
[19:26] <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:27] <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:28] <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:29] <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:30] <james_w> haven't tried .format() yet
[19:31] <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:32]  * barry is old skool and builds python from source in his sleep
[20:23] <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:24] <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:25] <vila> barry: there is also BZR_DISABLE_PLUGINS, just for you :)
[20:25] <barry> vila: you guys think of everything! :)
[20:26] <vila> barry: nah, just hacked it furiously and bzr pqm-submit --two-days-ago
[20:47] <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:52] <beuno> agruman, no, not possible
[20:59] <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
[21:01] <beuno> git__, I *think* we added a bzr-upload ignore command with vila a while back
[21:02] <vila> beuno: hehe almost, there is .bzrupload-ignore file, but don't forget to commit it as it applies to the uploaded revision
[21:03] <vila> git__: ^
[21:03] <beuno> that's right
[21:04] <git__> let me try
[21:06] <git__> works like a charm, thanks !!!
[21:06] <vila> beuno: thumbs up !
[21:07] <beuno> woo
[21:29] <roryy> huh. launchpad is pretty awesome.
[21:29] <ddaa> yup
[21:29] <roryy> g'night!
[21:43] <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:44] <vila> mgz: testools branch and bzr.dev branch ?
[21:44] <mgz> yup.
[21:45] <vila> urls ?
[21:45] <mgz> lp:~gz/bzr/use_testtools_timings_625594 and p:~gz/testtools/result_timings_forwarding_625594
[21:47] <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:48] <vila> mgz: I don't want to sound too demanding, I just want to know what will break if mess things up :)
[21:50] <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:51] <mgz> I like bt.test_ or bb.
[21:54] <vila> oops, wrong branch :)
[21:58] <vila> mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/ in progress
[21:59] <mgz> oo, is that new?
[22:00] <vila> not quite, but the plan is to make it open to devs
[22:00] <vila> and *that* is not done yet
[22:01] <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:02] <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:03] <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:05] <fullermd> It's slower because bialix isn't sleeping?
[22:05] <bialix> that will explain many problems
[22:06] <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:07] <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:08] <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:09] <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:10]  * 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:11] <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:12] <bialix> sounds good, but the price is too slow, I think
[22:12] <fullermd> Well, that's per day.
[22:13] <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:14] <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:15] <ddaa> otoh, the french decay very fast, with all the smelly cheese
[22:16] <fullermd> So, if we cross-bred them, we'd get...   moldy vodka?
[22:16] <mgz> vila: which one? :)
[22:18] <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:27] <mgz> I've got a free bsd slowness guess.
[22:28] <mgz> Seems to be on writing to the filesystem. Different sort of tmp partition?
[22:45] <maxb> abentley: Hi. Could you upload the bzrtools 2.2.0 tarball to Launchpad? Thanks.
[22:47] <vila> mgz: tmpfs configured there AFAIR but I haven't checked for... pfew, never since I started hudson
[23:15] <dobey> how does one do _iter_revisions() on a RemoteRepository, since it doesn't seem to have an _iter_revisions() method?
[23:23] <bialix> dobey: it seems the closest method you can use is get_revisions()
[23:24] <dobey> yeah, i'm trying that now
[23:25] <lifeless> _iter_revisions is private ;)
[23:25] <lifeless> dobey: what are you trying to calculate?
[23:27] <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:30] <lifeless> kk
[23:33] <dobey> and _foo isn't truly private in python, __foo is though.
[23:34] <bialix> it's a convention
[23:36] <lifeless> dobey: __foo is no more private.
[23:36] <lifeless> dobey: There's no enforcement ever; _ is widely recognised as not-public-thanks.
[23:37] <dobey> lifeless: trying to access __foo raises an exception.
[23:37] <dobey> accessing _foo does not
[23:38] <lifeless> thats because __foo is compiled to __ClassName_foo
[23:38] <lifeless> or something approximately like that
[23:38] <lifeless> anyhow
[23:40] <dobey> anyway, get_revisions() is sufficient
[23:45] <dobey> thanks
[23:50] <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:51] <bialix> dOxxx: ^
[23:51] <bialix> dOxxx: is it something that Mac installer should provide or?
[23:52] <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:53] <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:54] <dOxxx> err
[23:54] <dOxxx> ues
[23:54] <dOxxx> yes
[23:54] <dOxxx> um
[23:54] <dOxxx> that's the same bug XD
[23:55] <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:56] <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:57] <bialix> anything
[23:57] <bialix> dOxxx: thank you