[00:00] <lifeless> I haven't seen that
[00:00] <lifeless> bzr list?
[00:00] <vila> poolie: I submit a backport on lp:bzr/1.18, hope it's ok with you (windows lock)
[00:00] <poolie> vila, you mean a mp back into 1.18?
[00:00] <poolie> or something else?
[00:00] <vila> no here, yesterday, you didn't remember at first and then siad you edited it
[00:01] <lifeless> vila: oh yes, that wiki page.
[00:01] <lifeless> vila: uhm, something less broad
[00:01] <lifeless> 'problems to solve'
[00:01] <vila> poolie: http://bazaar.launchpad.net/~bzr-pqm/bzr/1.18/revision/4599
[00:02] <vila> lifeless: ok, I will think about it, at least I should brain dump a bit about incremental selftest
[00:02] <lifeless> vila: testing based on changes?
[00:02] <vila> yup
[00:02] <lifeless> vila: I should give you my code that does that then :P
[00:03] <vila> You surely should push that somwhere :)
[00:03] <poolie> ok i see
[00:03] <poolie> yes, that's fine
[00:03] <vila> poolie: great
[00:05]  * vila goes to bed
[00:05] <lifeless> vila: gnight
[00:05] <lifeless> vila: theres another test patch for your pleasure tomorrow :P
[00:06]  * lifeless sighs at check
[00:06] <lifeless> its still a very ugly duckling
[00:06] <poolie> quick poll: how does http://launchpadlibrarian.net/30906325/download.png look for a mockup of the downloads page
[00:08] <lifeless> seems fine. The how-recently-it-was-downloaded text is a bit awkward
[00:08] <lifeless> it makes the table taller
[00:09] <poolie> true
[00:09] <lifeless> for something ~ noone looking at the page cares about
[00:09] <poolie> this bug was actually about including the release notes
[00:09] <poolie> at the moment the page is too barren=
[00:09] <poolie> but it's a good poitn
[00:09] <lifeless> oh right
[00:09] <lifeless> perhaps expandable?
[00:10] <lifeless> This release of Bazaar marches on ... \n
[00:10] <lifeless> [more ...]
[00:10] <lifeless> some projects have very long release notes
[00:11] <AfC> poolie: feedback: "so Bazaar is a Windows only project?"
[00:12] <AfC> "Lots of Windows and .exe on that page. I use Linux, though. Guess I'll go elsewhere"
[00:12] <lifeless> heh
[00:12] <poolie> lifeless: lp distinguishes the notes from the changelog
[00:12] <poolie> the former is supposed to be fairly concise
[00:12] <poolie> afc, excellent point
[00:12] <lifeless> poolie: we're pushing it on that page then
[00:12] <poolie> though kind of a larger bug
[00:13] <lifeless> poolie: Alternatively, put them under the table.
[00:13] <AfC> poolie: (ie, even if it's essentially no-op, links to either direct .deb & .rpm files, or at the very least links to instructions one per distro. Windows should, at best, just be another distro.
[00:13] <lifeless> Windows PPA's!
[00:13] <lifeless> \o/
[00:13] <AfC> heh
[00:13] <poolie> direct integration with Steam
[00:14] <lifeless> yup
[00:14] <lifeless> poolie: have you spoken to valve?
[00:14] <AfC> poolie: (ie, you and I know what to do with a .tar.gz, but ...)
[00:14] <poolie> this is kind of the 'details' view of downloads
[00:14] <poolie> both on the bzr site and the launchpad project page, there should be an easy way to say
[00:15] <lifeless> poolie: I think the blurb we have should include links back to the wiki downloads page, or something
[00:15] <lifeless> poolie: as a workaround
[00:15] <AfC> poolie: also, I wouldn't include download numbers. Who cares? My software gets downloaded approximately 4 times per release. Once by Gentoo, once by Debian, once by Launchpad for it's own twisted and nefarious purposes,...  hm yup, that's about it.
[00:15] <poolie> "i'm running (windows/ubuntu/mac os/...) and I want the (latest stable/latest beta/...) release"
[00:16] <AfC> poolie: yeah, I'd do it with icon pairs:
[00:16] <poolie> anyhow i spent ages yesterday afternoon on launchpad
[00:16] <poolie> it's enough for now
[00:16] <AfC> Tux / Shadowman ; Tux / Debian Swirl ; Tux / Ubuntu thing ; ... ; Apple logo / MacOS smile ; Microsoft logo / Windows logo
[00:17] <poolie> bialix, re https://answers.edge.launchpad.net/bzr/+question/60728 shouldn't bzr on win32 automatically use paramiko if you don't have putty?
[00:17] <poolie> or is that only after your change?
[01:05] <poolie> lifeless: are you doing bug 416732 now, or today?
[01:10] <lifeless> poolie: nearly finished
[01:10] <poolie> yay
[01:10] <poolie> but
[01:10] <poolie> given your comments about assignment, you should have assigned it:)
[01:11] <lifeless> I wish launchpad wouldn't mail me twice
[01:11]  * lifeless files a bug
[01:15] <poolie> for what?
[01:15] <poolie> or just at all? :)
[01:16] <jml> poolie, spiv just told me about your quandary with the review system
[01:17] <jml> poolie, change the review team of the 2.0 branch to something that you're a member of, and I think everything will work out just fine.
[01:17] <poolie> how do i do that?
[01:17] <jml> https://code.edge.launchpad.net/+branch/bzr/2.0
[01:17] <jml> look for "Review team"
[01:18] <poolie> i can see it there
[01:18] <poolie> i can't see any control to change it
[01:18] <jml> ahh.
[01:18] <jml> there's a bootstrapping problem!
[01:18] <lifeless> spm: hi
[01:18] <poolie> that's one word for it :)
[01:18] <poolie> heh
[01:19] <spm> lifeless: hey hey
[01:19] <lifeless> spm: you can loging as pqm-launchpadthingy right?
[01:19] <poolie> spm, would you please strap our boots?
[01:19] <lifeless> spm: so please do ^ the above to make it bzr-core [thats right isn't it poolie?]
[01:19] <spm> -ENFI what you're talking aboot ? :-)
[01:19] <jml> poolie, I find it odd that you have a branch _created_ by a robotic user.
[01:19] <lifeless> spm: and update the docs, to do that on every new release branch
[01:20] <lifeless> jml: it pushes, the branch is made
[01:20] <poolie> jml, also, (and this is now your problem :-P) launchpad has a bit of a general problem in describing why you can't do something, or who is allowed to do something
[01:20] <poolie> specifically it doesn't :)
[01:20] <jml> poolie, yes.
[01:20] <poolie> it reminds me a bit of interacting with some govt departments
[01:20] <lifeless> spm: go to our bzr2.0 branch
[01:20] <lifeless>  on launchpad
[01:20] <poolie> you're just told you're wrong
[01:20] <poolie> not what to do
[01:20] <jml> poolie, that's a low blow.
[01:20] <spm> lifeless: the link above? yup.
[01:20] <poolie> fortunately we have very helpful developers :)
[01:20] <lifeless> spm: not quite
[01:21] <spm> ah
[01:21] <lifeless> spm: that the milestone
[01:21] <poolie> did spm make the branch while logged in as bzr-pqm?
[01:22] <lifeless> poolie: pqm made it when pushing
[01:22] <poolie> oh i see
[01:22] <lifeless> which spm will have done from the shell on balleny
[01:22] <spm> yes
[01:22] <poolie> it almost seems like you need a separate acl for "allowed to modify the branch" from "allowed to modify branch metadata"
[01:23] <lifeless> spm: ok, are you there?
[01:23] <poolie> i want the second, and _not_ the first
[01:23] <spm> lifeless: I think so :-) https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0
[01:23] <jml> poolie, maybe.
[01:23] <lifeless> poolie: you want ^pqm to have^ , right?
[01:23] <poolie> but that would complicate it
[01:23] <poolie> no i want ~mbp to have
[01:23] <poolie> or ~bzr-core
[01:23] <lifeless> spm: on the right, set the reviewer
[01:23] <poolie> i want bzr-pqm to be able to push
[01:24] <poolie> there's a longstanding request that project owners should be able to sudo change any contained object, but that's controversial
[01:24] <lifeless> poolie: I think you've confused me with your defintions of branch / branch metadata
[01:24] <lifeless> we want bzr-core as the reviewer team, right?
[01:24] <poolie> ~mbp should be able to change eg the review team of this branch
[01:24] <spm> lifeless: the review team is currently bzr-pqm
[01:24] <poolie> ~mbp shouldn't be able to push to this branch
[01:24] <poolie> that's the behaviour we actually want
[01:24] <lifeless> spm: change it please, to bzr-core
[01:24] <poolie> it's what we're executing indirectly through spm here
[01:25] <lifeless> poolie: yes, fully acking here. One way to do that would be to add permissions to series branches
[01:25] <spm> lifeless: done
[01:25] <lifeless> I don't mean manual config, I mean 'the owner of a series can alter data about the branch the series is connected to'
[01:25] <poolie> i'm not immediately suggesting coding that in because it may magnify complexity
[01:25] <spm> poolie: by proxying thru me - doesn't that imply you have the sudo perms? eg sudo spm do XYZ. ??? ;-)
[01:25] <lifeless> spm: thanks
[01:25] <poolie> right, thatseems to make sense
[01:25] <lifeless> spm: sudo make me a sandwich
[01:25] <poolie> shut up and make me a sandwich
[01:25]  * jml has to go
[01:26] <poolie> :)
[01:26] <lifeless> poolie: reviewer team set to bzr-core; please ack that that was the desired team.
[01:26] <spm> lifeless: I said poolie; not you; this attempt has been logged.
[01:26] <poolie> yes
[01:26] <lifeless> spm: sudo make me a sandwich
[01:26] <lifeless> spm: sudo make me a sandwich
[01:26] <lifeless> spm: sudo make me a sandwich
[01:26] <lifeless> spm: sudo make me a sandwich
[01:26] <spm> nagging doesn't work either. I haz a 6yo recall. :-D
[01:26] <lifeless> its fine, I don't like sandwiches anyhow
[01:26] <lifeless> :P
[01:27] <glyph> does bzr allow concurrent writers to a shared repository?
[01:27] <spm> bwhahahahahahaha
[01:27] <glyph> spm: was that an answer to me? :(
[01:27] <poolie> glyph: yes
[01:27] <lifeless> glyph: yes
[01:27] <spm> glyph: no, sorry. to a thread with lifeless. :-)
[01:27] <lifeless> glyph: no the answer was not to you.
[01:27] <poolie> for about a year or more
[01:27] <spm> my coworkers. charming folks.
[01:28] <glyph> okay
[01:28] <glyph> so, I'm checking out Twisted trunk, and a branch, from Launchpad
[01:29] <glyph> concurrently
[01:29] <lifeless> glyph: it doesn't allow concurrent writers to a branch
[01:29] <glyph> and the twisted trunk checkout is spewing "﻿inconsistent details in skipped record"
[01:29] <lifeless> glyph: because of domain model, nottech.
[01:29] <glyph> lifeless: right, that makes sense.
[01:29] <glyph> should I be worried about these errors?
[01:30] <lifeless> glyph: so, that means either a bzr-svn bug
[01:30] <lifeless> [likely]
[01:30] <lifeless> or you [or launchpad] have reconciled and the other has not
[01:30] <lifeless> its nothing to do with the concurrency
[01:30] <lifeless> glyph: I will note though that you probably have a lot of duplicate data being pulled doing that.
[01:31] <glyph> lifeless: I'm going to try this again because I've screwed up a bunch of stuff and I don't know if I can reproduce this repository reliably
[01:32] <lifeless> glyph: you can just ignore it
[01:32] <lifeless> glyph: file a bzr-svn bug with the log/output
[01:32] <lifeless> glyph: and keep on working
[01:33] <lifeless> poolie: launchpad has way to many bits
[01:33] <lifeless> e.g. whats a confirmed-assigned vs in-progress-assigned vs inprogress-unassigned
[01:33] <poolie> regarding ACLs?
[01:33] <poolie> yeah
[01:33] <poolie> there's only one logical state change here: robert is working on it
[01:34] <poolie> but it's getting better!
[01:34] <poolie> i'm pretty sure there used to be priority and severity?
[01:34] <poolie> and look at all the bits on blueprints!
[01:38] <glyph> lifeless: bugs in my VCS scare me :-\
[01:39] <glyph> lifeless: is it a harmless bug?
[01:39] <lifeless> glyph: yes; it means that two bits of inferred metadata (file graphs) differ in the two repositories, *and* that one repo chose to send that text to you though you already have it.
[01:40] <lifeless> The worst thing that can happen(assuming you're using 1.RECENT) is that 'bzr log file' might show too much/too little.
[01:41] <glyph> man, this is taking a really long time
[01:42] <lifeless> glyph: the pull?
[01:42] <glyph> is there any option or configuration that I might have forgotten which would cause a download to come down at 2kb/s?
[01:42] <lifeless> glyph: ~/.bazaar/locations.conf, set [/]\ngo_slow=False
[01:42] <lifeless> glyph: more usefully, what protocol are you pulling over?
[01:43] <glyph> lifeless: bzr+ssh
[01:44] <lifeless> glyph: are you suffering any packet loss or the like?
[01:45] <glyph> mtr says no
[01:46] <lifeless> spm: ping
[01:47] <lifeless> spm: meet glyph. glyph is seeing 2/kb [do you mean bits or bytes] a second downloading from codehosting over bzr+ssh
[01:47] <lifeless> glyph: also, is your machine thrashing
[01:47] <lifeless> do you have spare memory
[01:47] <spiv> glyph: whihc branch?
[01:47] <lifeless> is your cpu maxed
[01:47] <glyph> lifeless: nope
[01:47] <glyph> spiv: lp:twisted
[01:48] <glyph> lifeless: my CPU seems to be oscillating quite a bit; between 5% and 80% utilization, roughly
[01:49] <glyph> lifeless: sorry, KB/s, as reported by bzr itself.  I don't know ;)
[01:49] <glyph> you tell me if it's bits or bytes
[01:49] <spiv> bytes :)
[01:49] <spiv> Oh, and which version of bzr are you using?
[01:50] <glyph> spiv: 1.17
[01:50] <glyph> spiv: most recent from the hardy PPA
[01:50] <spiv> Hmm.  Into an empty shared repository?
[01:51] <glyph> Yep.
[01:51] <glyph> created as --2a, as suggested by the web page
[01:51] <spiv> Ah.
[01:51] <spiv> Oh!
[01:51] <spiv> You're hitting two bugs,
[01:52]  * spm defers all codehost slowness operational issues to spiv as bzr bugs for the forseeable future
[01:52] <spiv> the first is relatively minor, and it's that branching into an empty shared repository wastes a bit of time recursing through the remote revision graph first looking for common history with the existing repo that is your target.
[01:53] <lifeless> glyph: capital B - bytes
[01:53] <spiv> But the second is that with that version of bzr cross-format fetches over the network do a ridculous number of round trips.
[01:54] <lifeless> glyph: stop the operations
[01:54] <lifeless> glyph: do this:
[01:54] <lifeless> bzr branch <launchpad's trunk> /tmp/old
[01:54] <lifeless> cd /old
[01:54] <lifeless> bzr reconcile
[01:54] <lifeless> bzr upgrade --2a
[01:54] <lifeless> delete the repo you had made
[01:54] <lifeless> and bzr push /path/to/repo/trunk
[01:55] <lifeless> then go back to doing whatever
[01:55] <lifeless> glyph: 2a is radically different to older formats. It would be wonderful if twisted upgraded all its branches.
[01:56] <glyph> lifeless: I'm really confused :(
[01:56] <glyph> http://twistedmatrix.com/trac/wiki/BazaarMirror
[01:56] <lifeless> poolie: bug 420247
[01:56] <spiv> The cross-format slowness is fixed in 2.0rc1 (but requires both client and server to be that new)
[01:56] <glyph> is that page wrong?  lp:twisted doesn't require rich roots?
[01:56] <lifeless> glyph: 2a is more than rich roots; its a change from xml to temporal hash tables
[01:57] <spiv> glyph: lp:twisted requires rich-roots, but on launchpad it's in 1.9-rich-root format, not 2a format.
[01:57] <lifeless> ok
[01:57] <spiv> 2a is newer, faster, smaller, sexier.
[01:57] <lifeless> lets fix launchpad
[01:57] <lifeless> glyph: -> #twisted
[01:57] <spiv> But it's a different format than 1.9-rich-root, so it hits a crummy code path that only got fixed a couple of weeks ago.
[01:58] <spiv> Or rather, a code path that was optimised for local fetches.
[01:58] <glyph> lifeless: I'd rather not discuss the specifics of Twisted.  Obviously in order to use bzr I need to know a lot about formats and conversions in general.  So I'd appreciate it if you could explain how to detect the format of a branch before fetching it, so I can create an appropriately-shaped shared repository first
[01:58] <spiv> "bzr info URL"
[01:59] <lifeless> glyph: bzr info -v url, to be robust
[01:59] <spiv> (or look at the branch's web page on Launchpad...)
[01:59] <lifeless> bzr info url won't tell you enough sometimes
[02:00] <lifeless> glyph: we're trying to fix the issue with formats.
[02:00] <lifeless> glyph: its a great sadness that its the way it is
[02:00] <glyph> lifeless: well, to your credit, at least when it flat out doesn't work it tells me why :)
[02:02] <lifeless> small mercies ;)
[02:02] <glyph> okay
[02:03] <glyph> I created with --1.9-rich-root-pack and now everything's working great.
[02:04] <glyph> How come sometimes 'bzr diff -r ancestor' works, and sometimes it doesn't?
[02:05] <spiv> glyph: sometimes it doesn't?
[02:06] <spiv> (more details, please :)
[02:14] <SamB_XP> lifeless: so ... what's the client-side upgrade picture going to look like after lp:bzr is converted ?
[02:15] <lifeless> SamB_XP: for branches of bzr itself?
[02:15] <SamB_XP> yeah
[02:16] <SamB_XP> I, for one, don't think I have enough RAM to convert an entire branch to 2a
[02:16] <lifeless> of bzr?
[02:16] <SamB_XP> at least, not in a reasonable amount of time
[02:16] <SamB_XP> yeah
[02:16] <lifeless> how much ram do you have?
[02:17] <SamB_XP> 512 MiB total
[02:17] <lifeless> thats tonnes
[02:17] <SamB_XP> ... well, it was taking forever 2--3 weeks ago ...
[02:17] <lifeless> SamB_XP: please try and file bugs
[02:18] <lifeless> worst case though, pull fresh, make a repo, branch your old branches into it after trunk from the web is in it.
[02:18] <lifeless> I have a train to catch -> poolie
[02:18] <SamB_XP> ... anyway, I was just hoping there would be well-publicized directions for how to upgrade without converting lp:bzr itself
[02:23] <dvheumen> lifeless, hi, about the "Missing inventory" bug ... I've been looking through the source code yesterday, but I couldn't make much of it (because of my very limited experience with python and bzr). But I did notice that *every* revision is reported as missing and this same set of keys is reported as absent in bzrlib/knit.py line 1416: absent_keys = keys.difference(set(positions))
[02:23] <dvheumen> Hopefully it's some useful information
[02:25] <dvheumen> anyway, you don't seem to be here at this moment so I'll post it as a comment in the bug
[04:38]  * igc lunch and medical appointment - bbl
[04:54]  * SamB_XP suddenly wonders what prominent bzr devs do bzr-relevant blogging ...
[04:55] <lifeless> planet.bazaar-vcs.org
[04:55] <SamB_XP> hmm ...
[04:56] <SamB_XP> ... probably don't want to subscribe to that ...
[05:07] <lifeless> SamB_XP: I'm on advogato if you want to subscribe directly; or twitter or facebook
[05:07] <lifeless> review wanted: https://code.launchpad.net/~lifeless/bzr/bug-416732/+merge/10828
[05:07] <lifeless> this is for 2.0 and trunk
[05:09] <SamB_XP> lifeless: ah, that's a bit more my size ;-)
[06:11] <poolie1> spiv, how is bug 406687?
[06:14] <mwhudson> i have the very vague impression that there's a bug where bzr up in a checkout attempts to write lock the source
[06:14] <mwhudson> can someone confirm/deny this?
[06:16] <AfC> mwhudson: that sounds familiar (and horrid)
[07:05] <poolie1> mwhudson: yes
[07:06] <vila> hi all
[07:06] <vila> lifeless: check your comment 'is da... below' doesn't make sense to me, the rest is ok though ;D
[07:07] <vila> lifeless: and you dind't assign the bug to yourself it seems... (despite your comment reserving it... (you're obeying your own rules a bit too much here :))
[07:08] <vila> err, strange... ha ok, page refresh missing, forget me
[07:12] <poolie1> cheer squad :)
[07:12] <poolie1> hello vila
[07:13] <igc> back
[07:14] <igc> hi vila, poolie1
[07:14] <vila> hi igc
[07:14] <mwhudson> poolie1: i found the relevant but report in the end
[07:14] <vila> hi poolie1 (1!1!! :)
[07:16] <spm> vila: there can be only ... 1 ;-)
[07:17] <vila> spm: Referring to 'The One' with Jet Li you are ? :)
[07:17] <spm> nope - never seen a Jet Li movie. was actually thinking Highlander :-)
[07:18] <vila> spm: pff so last century... showing your age here ;-P
[07:19] <spm> vila: I have 2.5 months of being "young" for values of "young". I intend to maximise that period!
[07:20] <spm> 2.5 months *left*
[07:21] <vila> spm: I personally decided, a couple of months ago, that I will stay as young as I was 20 years ago, for the rest of my life. Sounds good so far :D
[07:21] <spm> vila: !?!?! why would you want to stay 63? wouldn't you be better off aiming for .. say.. .30? :-P
[07:22] <vila> spm: your forgit do divide by 3, 63 is 7 * 9, so people born that year got a special exception :)
[07:24] <spm> I don;t suppose there's any chance of that exception being extended to those from 69?
[07:25] <jml> spm, it depends
[07:25] <jml> spm, when did you get your first real six string?
[07:25] <spm> jml: sadly still waiting....
[07:26] <jml> dammit now I have that song stuck in my head
[07:27] <spm> ha! revenge is sweet! ;-)
[07:34] <vila> spm: 69 is 3 * 23, 23 is prime but 17 in hex so that's too young, sorry
[07:35] <spm> vila: I think my brain just imploded on that!
[07:37] <vila> spm: Try http://bazaar-vcs.org/Quotes any day :) (Search for SHA256 for example :)
[08:01] <poolie1> why does russel have to use such breathless subject lines?
[08:16] <vila> poolie1: nice reply... :)
[08:17] <poolie1> mm, to russel?
[08:17] <vila> yes
[08:17] <poolie1> i probably should have changed the subject myself
[08:17] <bialix> poolie1: paramiko used by default even without my patch
[08:17] <poolie1> bialix: hm i wonder what's happening then
[08:18] <bialix> without looking in .bzr.log I even don't guess
[08:18] <vila> to your initial question, I was thinking that I noticed a trend in being harsh with us to get more/quicker feedback... dunno what we can do about it, I think it's human :-/
[08:18] <bialix> answer opened in February, today is August
[08:18] <poolie1> mm, i think it is
[08:18] <bialix> something bad with topic starter install
[08:19] <poolie1> probably
[08:20] <bialix> poolie1: my best gues he can BZR_SSH=plink but removed plink at some point
[08:20] <poolie1> probably
[08:20] <bialix> ?
[08:20] <poolie1> we should probably change that detection code
[08:21]  * bialix wonder what was initial question to vila, but maybe I should not ask
[08:21] <vila> bialix: you asked. You're right. You shouldn't have :-P
[08:22] <bialix> bump
[08:22] <bialix> sorry
[08:22] <vila> oooops
[08:23] <vila> too late to explain the joke obviously :)
[08:29] <poolie1> about him being harsh to get a response
[08:29] <poolie1> maybe
[08:29] <poolie1> vila, i'm just going to send a metronome
[08:29] <poolie1> kinda rusty mentronome actually :)
[08:29] <poolie1> what are you planning to do today?
[08:32] <vila> getting back to conflicts resolution I hope
[08:32] <vila> while keeping an eye on a couple of reviews for jam
[08:35] <vila> bug #402652 looks too tied to what jam is working on already to be addressed before he finished #402645
[08:35] <vila> bialix-mute: oh, you got the joke finally :-D
[08:36] <bialix-mute> *nods*
[08:36] <vila> pfew
[08:40]  * bialix-mute got the mail. vila you're absolutely right
[08:41] <poolie1> vila i'd expect Mr 3-minute-test-suite not to have typos in his tests :-P
[08:41] <poolie1> vila, could you see if he wants a buddy on them when he wakes up?
[08:41] <poolie1> otherwise, conflict resolution ++
[08:46] <vila> LOL, just got the typo joke :)
[08:47] <vila> rats, he's gone, did my jokes smell bad today or what ?
[08:48] <vila> fullermd: will you run away if joke about freebsd being loser to geentoo than I thought ? Or will I make Afc goes away instead ?
[08:48] <vila> Ha, Afc quit *before* the joke even...
[08:53] <LarstiQ> maybe you should stop now ;P
[08:53] <vila> fullermd: ha ha, no reply, very funny
[08:54] <vila> LarstiQ: You're kidding ! I've got an infinite supply of jokes for the day with such a start :)
[08:58] <vila> montywi, mneptok : did you file a bug about keyring ?
[09:01] <gga> Hello! I have some trouble when using " bzr test-gtk". Can somebody help me ?
[09:10] <cody-somerville> Lets say I've branched a branch and I've committed some changes
[09:10] <cody-somerville> And I want to create a patch to send to a mailing list
[09:11] <cody-somerville> How would I go about doing that?
[09:11] <cody-somerville> The upstream uses git so I don't want to create a bundle
[09:14] <cody-somerville> besides using bzr diff I mean
[09:14] <cody-somerville> I'd like it to work like the git command does I guess
[09:14] <LarstiQ> cody-somerville: if you have bzr-git, `bzr send` should generate a git consumable patch
[09:15] <cody-somerville> really?
[09:15]  * cody-somerville tries.
[09:16] <cody-somerville> How can I tell that its git consumable?
[09:24] <cody-somerville> LarstiQ, how do I consume with git?
[09:25] <LarstiQ> cody-somerville: git apply or somesuch?
[09:25]  * LarstiQ hasn't used it, only knew jelmer wrote it
[09:40] <vila> cody-somerville: I think you need an option to send to specify the git format...
[09:45] <sabdfl> morning team bzr
[09:45] <sabdfl> is it possible to tell the version of a remote bzr server?
[09:45] <sabdfl> for example, bzr version bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk/
[09:47] <vila> sabdfl: from the command line, I'm pretty sure you can't
[09:48] <sabdfl> thanks vila - can you file a bug on that please? seems like a reasonable thing to do
[09:49] <vila> sabdfl: I'll check the existing one first, the subject comes back often, may be on 'bzr info' instead of bzr version though...
[09:51] <sabdfl> why? it's the version i want
[09:51] <sabdfl> i don't mind if it's also displayed on info -vv
[09:51] <vila> bzr version is for the client
[09:51] <sabdfl> says who
[09:52] <vila> ?
[09:52] <vila> you don't specify an url to bzr version
[09:52] <vila> bzr info <url> gives you info about the url, including ... bug #308472
[09:53] <vila> sabdfl: here you are, enjoy the patch :-D
[09:54] <sabdfl> vila
[09:54] <sabdfl> i would like this information on bzr version if a URL is supplied
[09:54] <sabdfl> don't tell me that "version does not take a URL"
[09:54] <sabdfl> i'm asking that you add that ability
[09:58] <vila> sabdfl: while filing a bug for that, I came across bug #308472, which already implements that on bzr info, I could add your comment there but... I think it makes more sense to accept that patch than to change the meanign of bzr version...
[09:59] <vila> the rationale for adding it to info rather than version is that:
[09:59] <vila> version url can gives info only if url is a smart server,
[09:59] <sabdfl> that's true for info, too
[09:59] <vila> whereas info will display it additionally when talking to a smart server
[10:00] <vila> now, it may seem weird to not be able to ask for the server info with 'bzr version <server>' but....
[10:00] <sabdfl> ok, i hear you, and appreciate the feedback, but the decision is to add an optional <url> to bzr version
[10:00] <vila> ...but maybe we can fill the other slots that bzr version displays for the server...
[10:01] <vila> that's more work though, so I'll see that the info patch lands and file a bug for bzr version with that discussion
[10:02] <vila> sabdfl: what prompted your question at start ? Only the bzr version or also the python version used there, the various paths the revid, etc ?
[10:02] <sabdfl> i just wanted to know the version of a server i was using
[10:02] <sabdfl> and that was the command i typed
[10:02] <sabdfl> then i remembered i did the same thing previously
[10:03] <sabdfl> i believe others will have done the same
[10:03] <vila> I agree
[10:03] <sabdfl> please, file the bug and implement it after 2.0
[10:04] <vila> So the basic info you wanted is what the info patch provides, adding an url to bzr version is what I file the bug with
[10:04] <vila> right
[10:04] <sabdfl> post-2.0 we will focus on user experience, and I'll be part of the review of that, so i'm confident this will pass review
[10:04] <vila> sabdfl: :-D
[10:07] <vila> sabdfl: bug #420408 if you want to subscribe
[10:46] <fullermd> vila: Whutwhut?  You?  Joke?  I didn't authorize that...
[10:47] <vila-bike> hehe, timing is everything, I should quit though ;)
[16:54] <bialix> abentley: hello
[16:54] <abentley> bialix: Hi.
[16:54] <bialix> abentley: I want to ask about your nested trees
[16:54] <bialix> as you maybe know I have plugin scmproj which is poor emulation of NT
[16:54] <abentley> Right.
[16:55] <bialix> because there is still no working solution I want to continue improve my plugin, because I'm using it in my real job
[16:55] <bialix> I'd like to reuse as much as possible of your work
[16:55] <bialix> I think I need your CompositeTree
[16:56] <bialix> is it possible to reuse it regardless of entire NT infrastructure?
[16:56] <bialix> abentley: i.e. how standalone CompositeTree is?
[16:57] <bialix> err, sorry. I wonder if I can just get your code hack it a bit and reuse for my needs?
[16:57] <abentley> bialix: it requires the contained trees to be referenced by TreeReferences.
[16:58] <abentley> bialix: I don't think that it would be easy to change that requirement.
[16:58] <bialix> can I create fake TreeReferences?
[16:59] <bialix> I wonder if some generic solution possible here
[16:59] <abentley> bialix: The code is here: http://bazaar.launchpad.net/~abentley/bzr/nested-trees
[17:00] <bialix> i.e. for Bzr-Trac plugin there is used some generic code that represents multiple of standalone branches as big mixed branch
[17:01] <bialix> abentley: your mereg proposal for NT docs seems to be approved. At least it in the approved but not merged queue. Or am I wrong?
[17:01] <abentley> It's a bit fuzzy what state it's in.
[17:02] <abentley> bialix: Martin approved the text without approving the plan.
[17:02] <bialix> do you think you will continue to work on NT in next 3-6 months?
[17:02] <bialix> abentley: it seems a bit controversial?
[17:03] <abentley> bialix: I don't think it's likely.  I was working on Canonical time, and my team needs me right now.
[17:03] <bialix> I understand.
[17:04] <bialix> But I need something like scmproj right now too, so I'm trying to figure out what I can reuse
[17:05] <abentley> bialix: That's a sane thing to do.
[17:05] <bialix> in the ideal worls I'd like to make scmproj as much as possible similar to future NT so I can switch painless
[17:05] <bialix> some of you rideas (AFAI) is very close to my implementation
[17:05] <bialix> your ideas, sorry
[17:06] <bialix> I'll try to read your current code, so I'll have more specific questions
[17:08] <bialix> abentley: last question: did you try to use your current code for real trees?
[17:10] <abentley> bialix: Like real codebases?  No, not for a couple of years.
[17:10] <bialix> couple of years? ok, it's a joke
[17:10] <bialix> we're using scmproj for ~ 6 months
[17:11] <bialix> I have enough feedback to understand what's wrong with my current scmproj
[17:11] <bialix> so do you think you'd like to change something in your current concept?
[17:12] <abentley> bialix: Not a joke, I started work on nested trees in 2006.
[17:12] <bialix> sorry, I misunderstood
[17:13] <bialix> I knew you started them a lon ago
[17:13] <bialix> but it seems they were more prototype
[17:13] <bialix> scmproj is ugly but we realy using it
[17:15] <abentley> bialix: They weren't meant as a prototype, and they haven't changed significantly since I stopped working on them in 2007.
[17:16] <bialix> ok, but there was no much news so most of the people know they're planned but not exist. at least I was under this impression.
[17:16] <bialix> maybe I was wrong
[17:18] <abentley> bialix: They're planned, there's an implementation, the implementation is out-of-date with the current plan.
[17:19] <bialix> "the implementation is out-of-date with the current plan" -- what it means?
[17:20] <bialix> you said Martin did not approved plan
[17:33] <bialix> ok, sorry for bother you. thanks
[17:56] <ajb> Can anyone explain what "M 040000 - content" means in the context of a fast-export?
[18:41] <Wox> someone that has time for a question?
[20:45] <mgedmin> hi folks!
[20:46] <mgedmin> suppose I've got an svn repository full of unrelated little tools, and I'd like to extract the history of a single file into a new bzr repository
[20:46] <mgedmin> how would I go about that?
[20:46] <mgedmin> svnadmin dump + svndumpfilter + ?
[20:46] <mgedmin> svnadmin import + bzr-svn?
[20:49] <phinze> sorry if this is a FAQ, but what is the current status of Cherry-pick metadata in bzr?  i.e. if i merge a single revision from one branch to another i get the file changes but no pending-merge revisions
[20:50] <phinze> and i found a blueprint from 2005 about it but no other info
[20:51] <phinze> mgedmin: that sounds like it would work
[20:51] <mgedmin> it did work :-)
[20:51] <phinze> huzzah ;)
[21:04] <bialix> hi garyvdm
[21:04] <garyvdm> Hi
[21:04] <bialix> is there any deadline for 0.14.1?
[21:04] <garyvdm> before bzr 2.0 final
[21:05]  * garyvdm is working on bug 420534
[21:05] <bialix-qbzr> garyvdm: look at util.py open_tree
[21:05] <garyvdm> funny - was just looking at it.
[21:05] <bialix-qbzr> I'm working on better wrapper class to open tree or branch and show errors better
[21:06] <garyvdm> I don't even think we need a wrapper class.
[21:06] <bialix-qbzr> do you want to use some universal error handler instead?
[21:06] <garyvdm> yes
[21:07] <garyvdm> Which is currently in place
[21:07] <bialix-qbzr> I need wrapper class to simplify args passing
[21:07] <bialix-qbzr> and to solve bug #.. wait
[21:08] <bialix-qbzr> bug 387320
[21:08] <bialix-qbzr> I'm tired about duplicating the same code to support both treeless, standalone and light co cases
[21:09] <bialix-qbzr> so I want wrapper
[21:10] <bialix-qbzr> garyvdm: btw, weird question that bother me a bit: can we move some of our GUI-specific code to some subpackage e.g. lib/ui and keep in lib/ only algorithmic stuff?
[21:11] <bialix-qbzr> we have ~66 files in lib/ now
[21:11] <bialix-qbzr> half of them is auto-generated UI files and simple dialogs
[21:12] <bialix-qbzr> other half very complex algorithms and com[lex GUI like qlog, qdiff, qann, qbw
[21:12] <bialix-qbzr> I wonder if we split them does it makes the code base any clearer? or you better keep current layout?
[21:13] <bialix-qbzr> garyvdm: ^
[21:13] <garyvdm> I was thinking we could split in into 1. reusable widgets (currenly log, treewidget), 2. browseing windows (log, annotate, browse, diff), and 3. actions windows....
[21:13] <bialix-qbzr> and 4. inner stuff
[21:13] <bialix-qbzr> like bugs.py, commmmit_data.py
[21:13] <garyvdm> util, trace,
[21:14] <garyvdm> commands
[21:14] <bialix-qbzr> commands is special
[21:14] <garyvdm> subprocess
[21:14] <bialix-qbzr> I like your 3 categories
[21:14] <garyvdm> or subprocess could go with all the actions windows.
[21:15] <bialix-qbzr> perhaps
[21:15] <bialix-qbzr> or keep it in the utils category
[21:15] <bialix-qbzr> so 4 is utils category
[21:15] <bialix-qbzr> or something like that
[21:16] <bialix-qbzr> the edge is fuzzy here
[21:18] <garyvdm> bilaix-qbzr: I would leave the common thing in lib/ - like this http://paste.ubuntu.com/261126/
[21:19] <bialix-qbzr> garyvdm: +1
[21:20] <bialix-qbzr> I think I'll wait with such serious changes till 0.14.1 is out
[21:20] <garyvdm> This is not important to me, but I might help new contributors. There are lost of other things I would prefer to spend time on..
[21:20]  * bialix-qbzr too
[21:20] <garyvdm> If you want to do it thats fine..
[21:20] <bialix-qbzr> yes, I want if you do not object
[21:20] <garyvdm> No objections..
[21:20] <bialix-qbzr> great
[21:21] <bialix-qbzr> right after 0.14.1
[21:21] <bialix-qbzr> year ago I moved everything into lib/ now time came to change layout again because qbzr is growing too much!
[21:22] <garyvdm> Does not have to wait. Last time I checked, the version control we use is very good a handling renames :-)
[21:22] <bialix-qbzr> I'll have to change a lot of imports statements
[21:22] <garyvdm> bailix-qbzr: I remember that was just after I started contributing...
[21:22] <bialix-qbzr> this may introduce conflicts on merging 0.14 branch back
[21:23] <garyvdm> Not a problem.
[21:23] <bialix-qbzr> garyvdm: you joined in June or July 2008
[21:23] <bialix-qbzr> ~ year ago ;-)
[21:23] <bialix-qbzr> and this was a great year, you rock
[21:23] <garyvdm> Only a year - seems much longer.
[21:24] <garyvdm> Ah - I was doing some hacking on bzr-gtk before qbzr
[21:24] <bialix-qbzr> check qlogs :-D
[21:24] <bialix-qbzr> I was under impression you working on bzr-gtk a lot
[21:24] <bialix-qbzr> always wonder why you switching
[21:25] <bialix-qbzr> do you remember?
[21:25] <garyvdm> The people I was developing for are Windows users.
[21:25] <fullermd> He's making the rounds of toolkits.  Next year he'll be working on bzr-motif.
[21:25] <garyvdm> qbzr much better than bzr-gtk on windows
[21:26] <bialix-qbzr> fullermd: lol
[21:26] <bialix-qbzr> garyvdm: yes, qt is much nicer on windows
[21:26] <bialix-qbzr> so I'm grateful to those people
[21:26] <garyvdm> I actually started on bzr-xul - but did not do much...
[21:27] <bialix-qbzr> never heard
[21:27] <garyvdm> xul is mozilla's toolkit
[21:27] <fullermd> That's pretty frightening...
[21:27] <garyvdm> firefox, thunderbird, etc are built with xull
[21:27] <garyvdm> *xul
[21:27] <bialix-qbzr> I'm slightly aware. Never heard about "bzr-xul"
[21:28] <garyvdm> Ah - it never got further than mu hdd
[21:28] <garyvdm> *my
[21:33] <bialix-qbzr> bug 420757
[21:37] <bialix> twins?
[21:39] <garyvdm> Yhea - I stared porting viz to qlog late june 2008
[21:39] <bialix> indeed
[21:40] <garyvdm> Actual the revision that I started working on way may 2008 - maybe my branch was just out of date when I started.
[21:41] <garyvdm> My first commit to bzr-gtk was in August 2007 - 2 years ago
[21:42] <bialix> cool
[21:42] <bialix> I've discover qbzr ~ 2 years ago
[21:43] <garyvdm> I started working almost straight away on the viz algorithm - That was crazy....
[21:43] <bialix> september or cotober 2007
[21:43] <bialix> :-D
[21:44] <bialix> and there is still a lot of things we can do to improvw it
[21:58] <bialix> garyvdm: btw, about that bug with report to console
[21:59] <bialix> open_containig* methods could emit nagging message about deprecated wt/branch format
[22:00] <bialix> docstrings insisst this info emits via ui module
[22:00] <bialix> we either need supress it, or show accordingly
[22:01] <bialix> this will become a problem in the future (post 2.0)
[22:04]  * bialix ~
[23:42] <SmileyChris> in a bit of a mess...
[23:43] <SmileyChris> had a bound branch, did bzr unbind to do some local work
[23:43] <SmileyChris> after restructuring entire project and checking it all in, i did bzr bind
[23:43] <SmileyChris> then ran bzr up, which checked out the pre-unbound revision
[23:44] <SmileyChris> bzr status showed all the files changed, with a pending merge
[23:44] <SmileyChris> tried bzr merge, but it said there were uncommitted changes
[23:44] <SmileyChris> so i ran bzr revert...
[23:45] <SmileyChris> and now it's the pre-unbound revision, with no pending merge... did i just lose everything?
[23:53] <garyvdm> :-(
[23:53] <garyvdm> No
[23:53] <garyvdm> run bzr up
[23:54] <garyvdm> You will then get "bzr status showed all the files changed, with a pending merge"
[23:54] <garyvdm> Now run bzr commit
[23:54] <garyvdm> No need to run bzr merge, bzr up does that for you
[23:54] <garyvdm> :-)
[23:55] <garyvdm> SmileyChris ^
[23:56] <garyvdm> SmileyChris: "pre-unbound revision" Should have all of your restructuring work.
[23:57] <mgedmin> I think I did once lose some data that way
[23:57] <mgedmin> there ought to be a bug about bzr bind not complaining when you've diverged
[23:58] <mgedmin> by "there ought to be" I mean "I either filed or found a bug already filed, but now I'm too lazy to look up the url"
[23:58] <garyvdm> jam: KnowGraph has shaved off 1.5 sec off loading mysql in qlog :-)
[23:58] <mgedmin> it's possible that the commits still exist in the revision graph somewhere
[23:58] <garyvdm> jam not here ::-o
[23:58] <mgedmin> shaving secs is nice
[23:58] <mgedmin> how many are left?
[23:59] <garyvdm> mgedmin: 15sec - but thats on a KnitIndex repo (1.6)
[23:59] <mgedmin> I remember reading release announcements saying "bzr someoperation is now 50% faster" and wondering if that means it's still very slow, just not as horribly slow as it used to be, or if it's now actually fast