[00:38] <Noldorin> poolie, hey.
[00:38] <Noldorin> how's progress on bzr 2.5? :-)
[00:38] <Noldorin> generally
[00:39] <nixmaniack> how can I continue an interrupted cloning of bzr repo? I started with bzr branch lp:calibre but interrupted in between
[00:43] <Noldorin> nixmaniack, interrupted how exactly?
[00:43] <Noldorin> ctrl+c?
[00:43] <Noldorin> process kill?
[00:43] <nixmaniack> Noldorin, ctrl+c
[00:44] <nixmaniack> i want to resume the process from where it stopped
[00:44] <Noldorin> nixmaniack, yeah, i think that would just fuck it during a branch
[00:44] <Noldorin> you can try bzr break-lock followed by bzr pull
[00:44] <Noldorin> that *might* work
[00:44] <Noldorin> or bzr update even for the 2nd command
[00:45] <spiv> Unfortunately you can't resume an interrupted pull
[00:45] <nixmaniack> bzr update didn't work, it gives me error
[00:45] <Noldorin> spiv, a branch is like an init followed by a pull no?
[00:45] <spiv> Noldorin: yeah
[00:45] <nixmaniack> bzr: ERROR: No WorkingTree exists for "file:///home ....
[00:46] <Noldorin> nixmaniack, yeah, so just wipe the directory and start again i say
[00:46] <Noldorin> don't think there's a better solution sorry
[00:46] <Noldorin> spiv, why the separate command then? just convenience/semantics, or does it actually do something cleverer? :-)
[00:46] <nixmaniack> Noldorin, i would have to download so much data again! that's why i was trying for other solution
[00:47] <Noldorin> nixmaniack, yeah, it sucks. you can't exactly blame bzr though. you pressed the keys ;-)
[00:47] <Noldorin> unlucky, as i said
[00:47] <spiv> (bzr can't commit an incomplete stream, because it almost certainly has references to records that didn't get received yet.  There's a bug about improving this situation, but it's tricky to do well and right.)
[00:47] <spiv> nixmaniack: if you need incremental fetches, the easiest hack is to do e.g. "bzr branch -r100 lp:foo; cd foo; bzr pull -r200; bzr pull -r300; ..."
[00:48] <spiv> (or in increments of 1000, or whatever)
[00:48] <spiv> Noldorin: a bit of both
[00:48] <spiv> Noldorin: but mainly convenience.
[00:48] <nixmaniack> Noldorin, actually this should be handled in some way (i think). what if a persons connection gets inturrupted after 90% cloning (and suppose the repo is quite big)
[00:48] <spiv> nixmaniack: yes, we agree
[00:49] <spiv> nixmaniack: read and/or subscribe to the bug talking about it :)
[00:49] <Noldorin> nixmaniack, oh sure, it's a pain. but it's not *that* important to most people
[00:50] <Noldorin> i've done it before...
[00:50] <Noldorin> and i'm angry until i realise it was me being silly
[00:50] <Noldorin> server could go down though
[00:50] <Noldorin> so in that case :-)
[00:50] <spiv> nixmaniack: also, in many cases the better fix would be to not require the user fetch so much data :)
[00:51] <spiv> nixmaniack: e.g. the shallow branching proposal
[00:51] <Noldorin> what's that?
[00:51] <Noldorin> shallow branching
[00:51] <mamalala> hello! can anybody give me some help regarding getting a branch with bzr causing extreme network traffic?
[00:52] <mamalala> bzr is downloading insanely high amounts of data for "small" stuff ... since i'm on umts internet, that really sucks
[00:53] <nixmaniack> spiv, actually I don't understand much about VCS! I just Git (that to not very often) but the project on which i want work is on bazaar repo, and i'm stuck at cloning only!
[00:53] <nixmaniack> and now being on mobile network i can't afford much traffic!
[00:53] <Noldorin> mamalala, might want to define what umts is :-P
[00:54] <mamalala> Noldorin: mobile internet connection, only 4.something mbits/sec
[00:54] <Noldorin> ah
[00:54] <Noldorin> sounds American
[00:54] <Noldorin> hey that's still faster than 3G :-P
[00:54] <mamalala> nah, i'm in germany actually ;)
[00:54] <Noldorin> or at least the same
[00:54] <Noldorin> hah
[00:54] <Noldorin> okay fine
[00:54] <Noldorin> not British though :-)
[00:55] <mamalala> i'd like to grab the sources, doc's and libraries for kicad, and they use bazaar on launchpad
[00:55] <mamalala> already got the sources, after hundreds of megabytes of bzr download traffic, for only a handfull of mbytes of actual sourcecode
[00:55] <mamalala> so i'm wondering if there is a sane way to get stuff from bazaar?
[00:56] <Noldorin> mamalala, that's because you grabbed the entire revision history :-P
[00:56] <mamalala> right now i'm getting the doc's, and it already transferred > 100 mbytes ... and you can bet that the actual doc's aren't that big
[00:56] <Noldorin> mamalala, you probably just want bzr export
[00:57] <mamalala> ahh
[00:57] <Noldorin> for the latest revision, only actual content
[00:57] <mamalala> will try that, i'm totally new to that bazaar stuff
[00:58] <mamalala> Noldorin: what would be the correct syntax for that then? what the kicad folks tell on their wiki to grab stuff is, for example: bzr branch lp:~kicad-developers/kicad/doc
[00:58] <spiv> Noldorin: see the list archives, but the proposals for it are mostly along the lines of "local branch stacked on remote trunk + some amount of local caching"
[00:59] <Noldorin> spiv, oh right, interesting.
[00:59] <Noldorin> spiv, isn't that like a lightweigh checkout?
[00:59] <spiv> Although if jelmer can finish my branch for making 'bzr branch --stacked' from a smart server faster, that would be a fair chunk of a basic version of that already.
[00:59] <Noldorin> mamalala, just bzr export mylocaldir/ lp:...
[01:00] <spiv> Noldorin: yes, but without the need to hit the network for every operation
[01:00] <poolie> hi spiv
[01:00] <spiv> Noldorin: e.g. seeing a diff of what you've changed
[01:00] <Noldorin> spiv, ah interesting. so more apt for the distributed workflow then :-)
[01:00] <mamalala> Noldorin: ah, thanks! i was a bit confused because that branch thingy automatically created a directory
[01:00] <mamalala> stupid me ;)
[01:00] <Noldorin> spiv, what's the diff between --stacked and --lightweight incidentally?
[01:01] <spiv> Noldorin: and potentially if you say e.g. "bzr log -r -20.." it could not just fetch that from the network to show you the log, but also add that to the local cache so next time you do it is fast.
[01:01] <spiv> Noldorin: --stacked is a branch
[01:01] <spiv> Noldorin: so an independent line of development, can have its own commits etc.
[01:02] <Noldorin> mamalala, you could also do bzr init, bzr clone -r 123 if you wanted the bzr metadata too.... i *think* that would only pull the latest revision? or maybe you want bzr merge. spiv can probably tell
[01:02] <Noldorin> spiv, sounds cool
[01:02] <spiv> Noldorin: but a bit like a shared repo: if its repo doesn't have some data bzr will automatically fetch it from the stacked-on repo instead.
[01:02] <Noldorin> spiv, so lightweight checkouts are like the centralised version of stacked branches eh?
[01:02] <spiv> Noldorin: (a bit like shared in that it's a mechanism for multiple things to share one resource for repo data)
[01:02] <spiv> Noldorin: yes
[01:03] <Noldorin> yeah
[01:03] <spiv> Hey poolie
[01:03] <mamalala> Noldorin: alright ... thing is, i simply want the doc's, code and lib's ... i don't care about updating the local repository in the future anyways, so any version control is useless for me here
[01:03] <Noldorin> spiv, i guess you're working on shallow branching mainly for speed/efficiency reasons then?
[01:03] <Noldorin> mamalala, yep yep, so export should work fine. let me know if you have luck
[01:04] <mamalala> Noldorin: well, it's causing some traffic, but not telling me what it actually does ;)
[01:04] <spiv> Noldorin: yes, although it's a natural way to work IMO
[01:04] <mamalala> but seems there is a lot of overhead as well
[01:04] <spiv> Noldorin: I usually don't care about the full history of something I want to hack on
[01:05] <Noldorin> spiv, sure. just the logic is more complex/bug-prone.
[01:05] <spiv> Noldorin: I mainly want my hacking to be fast, and as a secondary thing I want the full history to be available for the odd time when I want to dig into it.
[01:05] <Noldorin> mamalala, sounds like you're doing somethign weird/on a really old version of bzr heh
[01:05] <mamalala> only got 6 mbytes of data in the directory yet, but downloading at almost full bandwidth for a while ... which means still a lot of wasted traffic ... oh well
[01:05] <spiv> Yeah.  Although we've already dealt with most of the hard logic, for stacking.
[01:06] <Noldorin> mamalala, ask the devs. i think you have an edge case though. bzr has always proven efficient for me in such things
[01:06] <Noldorin> spiv, currently there's no way to do local hacking on a remote branch without pulling the full history, eh?
[01:07] <Noldorin> so i guess that's the crux
[01:07] <spiv> mamalala: are you branching into a shared repository, or a standalone branch?
[01:07] <spiv> mamalala: there's a known bug with branching into an empty shared repository
[01:07] <Noldorin> also, hi again poolie. just wanted to update you that i'm planning to start hacking on that LP downloads feature soon..
[01:07] <mamalala> spiv: good question ... i have no idea, i'm not involved in development there or anything ...
[01:08] <mamalala> spiv: http://kicad.sourceforge.net/wiki/Downloads
[01:08] <mamalala> spiv: that's the stuff i want to grab as sources (see bottom of the page)
[01:08] <Noldorin> sourceforge offers bzr these days? :O
[01:08] <mamalala> spiv: after way too much traffic i got the sources already, and now iÄd like to get the doc's and lib's as well ... but at the current state of affairs, i'm about to drop it ..
[01:10] <mamalala> Noldorin: nah, i guess they just used sf for the wiki stuff ... there are no files or anything to download at sf for that project
[01:10] <Noldorin> spiv, i mean, correct me if i'm wrong about that ^
[01:11] <Noldorin> mamalala, ah fair enough. speaking of which, i was actually planning on starting work on a wiki feature for Launchpad at some point
[01:11] <Noldorin> it's one feature really lacking. one of few
[01:12] <mamalala> Noldorin: right now, from my pov, being able to just grab the actual source/whatever from a repository in a fast way is sorely lacking ;)
[01:12] <Noldorin> mamalala, well did bzr export not succeed at least?
[01:13] <mamalala> Noldorin: i cancelled it now ...
[01:13] <Noldorin> mamalala, could well be the server that's (temporarily) fucked
[01:13] <mamalala> Noldorin: it just sucked up all the bandwidth, and only got about 8 mbytes of data a minute ago
[01:14] <mamalala> Noldorin: i had it running since you gave me the hint about export ... suring all that time only 8 mbytes of real data, while constantly using about 4mbit/s of bandwidth
[01:14] <mamalala> thats just insane
[01:14] <mamalala> if i had broadband dsl or something, i wouldn't really care ... but at such "slow" speeds, it makes no fun at all
[01:15] <Noldorin> mamalala, as i said, fringe case most likely. never heard of that before. either the server, client, or repo is fucked :-P
[01:15] <Noldorin> i know bzr to be excellent and efficient software in general
[01:15] <Noldorin> seems you just have the luck now
[01:15] <Noldorin> heh
[01:16] <mamalala> Noldorin: i don't doubt that .. just in that case it really sucks ... but then, i also blame the kicad folks for being unable to provide a simply tarball of that stuff
[01:16] <mamalala> simply -> simple
[01:16] <Noldorin> mamalala, yeah, i always hate it too when i just want to grab the source but can't do it easily
[01:16] <Noldorin> Launchpad lets you do it
[01:16] <Noldorin> but i guess they use a custom host
[01:17] <Noldorin> which increases the chance their bzr server is messed up too, perhaps
[01:17] <mamalala> from what i know they use launchpad
[01:17] <Noldorin> mamalala, then you can just download the latest revision
[01:17] <Noldorin> point me to the LP project site
[01:17] <Noldorin> and i'll tell you
[01:17] <Noldorin> heh
[01:17] <mamalala> hmm
[01:19] <mamalala> good idea, if i would know where that project site is on launchpad
[01:19] <mamalala> i only have the links on their wiki for use with bazaar
[01:20] <mamalala> and that bazaar stuff seems to be on launchpad, since it uses lp:... as address
[01:20] <mamalala> already tried to use bzr+ssh://<myid>@bazaar.launchpad.net/~kicad.... and that worked as well
[01:21] <mamalala> but same slowness as with lp:
[01:21] <fullermd> If you're logged in, lp: _is_ bzr+ssh://....
[01:21] <mamalala> already created an account on launchpad for me, added my ssh key, etc...
[01:21] <mamalala> fullermd: ok
[01:24] <mamalala> guess i'll simply have to try again in a few days, in case something is messed up on their end ... and if nothing changes, i just give it up ...
[01:25] <fullermd> At any rate, I wouldn't expect an export from remote to be too speedy.  Kinda off the beaten path.
[01:25] <mamalala> fullermd: well, i really donÄt care about the speed itself, but the badwidth
[01:25] <fullermd> Bandwidth is just the FFT of speed   ;>
[01:26] <mamalala> fullermd: i only have a 5 gig flatrate on umts, after which it will throttle down to gprs speed
[01:26] <mamalala> and that means that using up hundres of megabytes just to get a few mbytes of real data is simply a no-go for me ;(
[01:29] <fullermd> It was (at least.  Maybe still is) often the case that an export or light checkout would involve more transfer than just doing a full branch.
[01:29] <fullermd> But to be sure, neither tops the list when you have to count every byte that closely.
[01:29] <mamalala> fullermd: well, i could live with a few megabytes excess traffic in this case ... but the traffic/usable-data ratio is just insane in this case
[01:30] <fullermd> Do your fiddling on a shell server somewhere, maybe?
[01:30] <Noldorin> alas, no more hacking for today
[01:30] <Noldorin> night folks
[01:30] <fullermd> Or at least could branch there and make yourself a tarball.
[01:30] <mamalala> and i'm unable to get a real dsl line here, since there are no free lines available anymore where i live, so umts is my only option ;-/
[01:31] <mamalala> fullermd: unfortunately not
[01:31] <mamalala> fullermd: used to have my own server and fixed/static sdsl line in my previous location ... oh well, good old times
[01:31] <fullermd> What branch is it you're trying to get?
[01:32] <mamalala> fullermd: lp:~kicad-developers/kicad/doc and then lp:~kicad-lib-committers/kicad/library
[01:33] <fullermd> http://bazaar.launchpad.net/~kicad-developers/kicad/doc/tarball/302 should be a tarball of the latest rev of the /doc branch.  If it works right.
[01:34] <fullermd> And http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/tarball/112 looks like the latest of library.
[01:34] <mamalala> fullermd: hey, thanks! how did you derive that download link from that information?
[01:35] <mamalala> fullermd: again, thanks a lot! that's very helpfull indeed
[01:35] <fullermd> I went and poked at https://launchpad.net/~kicad-developers, hit the 'Code' link up top, which showed the branches (in this case, just the one)
[01:36] <fullermd> Hit the branch, it shows the recent revs down the page.  Click the latest rest (302; the number, not the name beside it), and that gets you to http://bazaar.launchpad.net/~kicad-developers/kicad/doc/revision/302
[01:36] <fullermd> Then there's a 'download tarball' link.
[01:36] <fullermd> Then I just manually fiddled with the link to get to the other branch.
[01:36] <mamalala> fullermd: oh boy, now i feel really stupid ;-D
[01:37] <fullermd> Well, it's Hump Day.  Nobody's smart on hump day   ;p
[01:37] <mamalala> didn't know that there were "real" webpages behind all that as well
[01:37] <mamalala> hehe
[01:37] <fullermd> That's all (or mostly, anyway) loggerhead.  Any branch on LP will have that interface available.
[01:38] <fullermd> Or is it loggerhead?  I don't really know, I s'pose.  Still.  It's colored clicky stuff   :p
[01:39] <fullermd> (and alternately, if you have a SF account, they still have shell servers, don't they?  Don't remember if they have access to the outside world though)
[01:40] <mamalala> hmmm, already 85 mbytes downloaded and continuing ... doesn't look well either ...
[01:40] <mamalala> ah, just finished
[01:40] <fullermd> Could be a big tarball if it's got a bunch of images and such in it.
[01:40] <mamalala> ok, that's definitely much less traffic than using bzr
[01:40] <mamalala> fullermd: again, many thanks for helping an old stupid chap ;)
[01:41] <fullermd> Hey, that's why they pay me the Big Bucks.
[01:41] <mamalala> lucky you ;)
[01:41] <fullermd> I think I'll put myself in for a 50% bonus just for this conversation, in fact.
[01:41] <mamalala> haha
[01:42] <mamalala> go for 100% ..
[01:42] <fullermd> I don't want to sound greedy.  Especially right before christmas.
[01:43] <mamalala> ah, great ... got the two tarballs already ... _much_ better than before
[01:44] <fullermd> Anyway, I have to be helpful once in a while.  That way I can get away with the buffoonery I engage in the other 90% of the time.
[01:44] <mamalala> fullermd: i'm with you on that, same here
[01:45] <mamalala> maybe i should hope for a "bzr --just-grab-the-damn-tarball" option for christmas :D
[01:46] <fullermd> I was thinking of going for world peace.  But then what would they put on the news?
[01:47] <mamalala> i blame the broadband-effect for such things nowdays. big pipes everywhere makes people forget about caring about bandwidth
[01:47] <mamalala> yea, world peace would be nice, but surely won't happen in the next few millenia
[01:48] <fullermd> Well, it'll take you that long to run bzr export over your cell, right?   ;p
[01:48] <mamalala> hahaha
[01:48] <mamalala> actually it can get pretty fast, on good days i get about 7 mbit/sec, but on average it's around 4
[01:49] <mamalala> but speed is only half the business if you have to look at traffic usage
[01:49] <fullermd> Not too bad.  But man, 5 gig disappears faster than you can blink.
[01:49] <mamalala> because being dropped down to gprs speed ain't no fun ... 64 kbit/sec
[01:49] <mamalala> yeah
[01:50] <mamalala> tell me ... when i had the sdsl line, it had a flatrate as well
[01:50] <mamalala> i'm really missing that, especially the fixed ip's and stuff. it's really great to have your own server at home together with 8 ip's
[01:51] <fullermd> Back when I ran ISP's, I had a block of 16 at home.
[01:51] <fullermd> That was on dialup, though.  Still, it was nice.  When I left that business and got DSL, suddenly I had to learn about NAT.  That _sucked_.
[01:51] <mamalala> hehe
[01:51] <mamalala> well, sdsl is a bit different, at least here in germany
[01:51] <mamalala> no nat or such crap involved
[01:52] <mamalala> you get one ip, and tell them you need more, and then get 8
[01:52] <fullermd> I've got cable with a cap.  But I don't get very near it.
[01:52] <mamalala> flatrates are the most common stuff here in germany. pretty much everyone has them
[01:52] <fullermd> Still.  According to my cricket graphs, I'm averageing something like 175kbps over the mid term.  That's a bit under 2 gig a day.
[01:53] <fullermd> Very bursty usage to get that average, but...
[01:53] <mamalala> friend of mine has cable-dsl at home, 50 mbit/sec, fixed ip, for something around 50 euros per month
[01:53] <fullermd> I get about 20mbit down.  250 gig cap.
[01:53] <mamalala> average dsl here is 8 or 16 mbits for around 30 euro-bucks including flatrate, but no fixed ip
[01:54] <fullermd> Looks like I'm at 26 so far this month.  So I'll be around 50 total.  That would be unpleasant to try and pull off over cell...
[01:54] <mamalala> ahh, 250 gig ... i would be happy if i had 20 or 30 gig included
[01:54] <mamalala> 5 gigs is really borderline
[01:55] <mamalala> oh well ...
[01:55] <fullermd> Yeah, I'd hit that in about 3 days of my usage.
[01:55] <fullermd> Maybe a little less, since that figure is just downstream.  But my upstream is a lot smaller anyway.
[01:55] <mamalala> tell me... when i moved in here, found out that no lines are available, and then used umts the forst time... after one day i was down to gprs speed ;-/
[01:56] <mamalala> nowdays i'm wondering what i did to use it up so quickly... probably all those downloads and stuff to get my net-based backups back to y local machine
[01:57] <fullermd> Luckily, all my MUD data is compressed.
[01:58] <mamalala> but then ... the average website is crap-full with flash and other useless waste, so just by surfing around the net you get a lot of wasted bandwidth
[01:59] <mamalala> i really "love" those sites where these bozos use flash to implement basic navigation through the site, etc. what a load of crap
[01:59] <fullermd> I especially love them, since I don't have flash.
[01:59] <mamalala> hehe
[01:59] <fullermd> Gives me a nice quick warning that the site is stupid and not worth bothering with.
[01:59] <mamalala> true
[02:00] <mamalala> well, i have flash installed, because some customers want to show me their latest-and-greatest...
[02:01] <fullermd> I get that from time to time.  I tell them "Yes, that's a pretty big white box".
[02:01] <mamalala> but then, somehow they all got rather quiet re: telling me about their flash stuff... might have something to do with me telling them what a load of bulldung that is
[02:03] <mamalala> alright, i'm leaving now, poking around with that kicad stuff, hopefully getting me to make the transition from my current pcb software to this one
[02:04] <mamalala> fullermd: again, many thanks for the help! i could send you a sixpack of nice, tasty german beer if you like :D
[02:04] <fullermd> I'm sure that would be highly illegal.
[02:04] <fullermd> Therefore, my address is...
[02:04] <mamalala> hehe
[02:06] <mamalala> fullermd: if you really want me to send you some beer, no problem ... just /query me, i'm almost 24/7 on freenode anyways (and have channel #mamalala as well)
[02:06] <mamalala> ok, i'm off, good night everyone, and thanks again!
[02:06]  * fullermd waves.
[02:06]  * mamalala waves back
[02:16] <poolie> hi fullermd
[02:17]  * fullermd waves at poolie.
[02:26] <fullermd> poolie: Out of curiosity, _is_ that "download a tarball" part of loggerhead proper, or something LP adds?
[02:26] <poolie> it's in lh trunk
[02:26] <fullermd> Shiny.
[02:26] <poolie> in fact one of the remaining things to do is to add a direct link to it from the main lp ui
[06:39] <wgz> happy un-morning
[07:30] <vila> hey guys
[07:36] <wgz> hey vila... bus soon
[07:36] <vila> as in: see you in the bus ??? /me confused
[07:36] <vila> :)
[07:39] <wgz> as in, I need to catch it :)
[08:32] <vila> wgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ?
[08:35] <mgz> morning!
[08:37] <vila> mgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ?
[08:37] <vila> and re-hi by the way ;)
[08:41] <mgz> vila: don't think I touched that path, as debian.changelog is in charge there and doing the right thing
[08:41] <mgz> (debian policy states that changelogs are utf-8, if a package has other random bytes in there it's borked)
[08:42] <vila> hmm, ok, I'll need to dig deeper then
[08:42] <vila> I encounter this while running mass_import locally so I may need to upgrade some packages (I'm running oneiric though)
[08:42] <mgz> it's a likely failure from a package with a bad changelog
[08:44] <mgz> if you can pdb in there and go up, will be easy enough to find the part debian.changelog doesn't like
[08:45] <vila> yeah, that's the plan, I run locally keeping all local branches for such debug purposes
[08:45]  * vila facepalms, wrong order for news entry :)
[08:46] <mgz> ...I need to fix my news anyway, will reorder at same time
[08:46] <mgz> which bit are you looking at?
[08:48] <vila> fixed, in my proposal for bug #904550
[08:48] <mgz> ...now that needs to land before I can fix my news? :)
[08:49] <vila> mgz: won't be enough, you'll also need pqm patch from jelmer for 2.5-compat
[08:50] <mgz> ah, or pqm won't let anything through at all?
[08:51] <vila> pqm-submit will crash, see bug comments
[08:51] <vila> hmm
[08:51] <vila> well, bug comments are about bzr, see https://code.launchpad.net/~jelmer/bzr-pqm/bzr-2.5-compat/+merge/85775 for pqm-submit
[08:52] <vila> mgz: ok, the debian changelog contains Küster which emacs sees as iso-latin-1 in fityk_0.4.3p1-1.diff.gz
[09:54] <vila> mgz: weird, that same import succeeded on jubany :-/
[09:57] <mgz> vila: likely it has a different version of python-debian
[09:58] <mgz> I have 0.1.18 which does not fall over in a bunch of cases newer versions do
[09:59] <vila> you mean it's a regression in python-debian ?
[09:59] <mgz> it's a behaviour change
[09:59] <mgz> possibly bzr-builddeb needs to grow code to handle packages the that debian tools thing are broken in some way (by skipping revisions or such like)
[10:00] <mgz> this is complicated by the fact the tools don't make an effort to raise sane errors
[10:01] <vila> 0.1.14ubunt2 on jubany, 0.1.20ubuntu2 locally :-(
[10:02] <mgz> ^s/thing/think/ obviously
[10:02] <mgz> ThingPad
[10:04] <vila> I don't skip the importer can afford to skip versions :-/
[10:12] <vila> meh, we both  have trouble with think this morning... s/skip/think/
[10:15] <vila> trying with a dirty hack: force latin_1 when UnicodeDecodeError is encountered :-{
[10:17] <jml> I never thought I'd say this, but using bzrlib.tests.TestCase feels kind of primitive
[10:19] <vila> jml: don't do that then :)
[10:19] <jml> vila: I don't want to add another dependency to udd in this branch.
[10:19] <mgz> using bzrlib.tests.TestCase means you already depend on testtools...
[10:21] <vila> mgz: what do you know about the debian/changelog encodings ?
[10:22] <vila> mgz: as in: what is/was allowed, what is/was used ?
[10:22] <jelmer> vila: in historical revisions, pretty much anything is used
[10:23] <vila> jelmer: oh  hi !
[10:23] <jelmer> IIRC now the recommendation is to use utf8, but I'm not sure if that's a recommendation or mandatory
[10:23] <jml> mgz: oh really?
[10:23] <jelmer> 'morning vila

[10:23] <vila> jelmer: with recent versions of python-debian, latin_1 is used in once case and breaks import_dsc
[10:24] <jelmer> vila: it uses chardet I think
[10:24] <jml> handy!
[10:24] <vila> huh, what's charder ?
[10:24] <vila> det
[10:24] <mgz> it's manditory now, but historically there wasn't any guidance and people can still accidentally do the wrong thing
[10:24] <jelmer> vila: uses heuristics to determine the relevant encoding
[10:24] <jml> mgz, vila:  what version of testtools is on production?
[10:24] <vila> jelmer: ha, exactly what I was going to suggest, so what is chardet, a package ?
[10:25] <mgz> >>> testtools.__version__
[10:25] <mgz> (0, 9, 6, 'final', 0)
[10:25] <vila> 0.9.6-0~bazaar1.0.IS.8.0
[10:25] <vila> 0.9.6-0~bazaar1.0.IS.8.04
[10:25] <jml> thanks!
[10:26] <vila> damn mouse
[10:26] <mgz> chardet is a bad idea, and you'd need to change debian.changelog which wouldn't really help the now
[10:26] <mgz> encodings aren't the only way parsing a changelog can fail either
[10:26] <vila> mgz: no, changelog can be provided with a unicode string so we can handle that
[10:26] <mgz> if builddeb relies on sane package metadata, and the package metadata is borked, something has to give
[10:27] <jml> I need to get on the case wrt packaging
[10:27] <jml> using 0.9.6 is almost criminal neglect.
[10:27] <jelmer> vila: yes, python-chardet
[10:27] <vila> mgz,jelmer : the question is: what do we really need out of the changelog ?
[10:27] <mgz> chardet *probably* gets utf-8 right, but adds a lot of overhead and is a heuristic
[10:28] <mgz> so, can flip flop depending on content
[10:28] <vila> the case at hand is an author with an latin_1 encoded name
[10:28] <mgz> we're better off catching errors from places that need to parse changelogs and gracefully handling borked ones
[10:29] <vila> yeah, with gracefully including: try again with a working encoding that can be as fine-grained as a line
[10:29] <mgz> the case could equally be they forgot to enter their name, though some classes of errors may be better and more reliably caught by packaging tooling
[10:30] <vila> mgz: right now, re-trying with latin_1 allowed me to continue up to the next call site trying to parse the changelog ;)
[10:30] <vila> and note that ChangeLog() accepts an encoding parameter
[10:31] <vila> and a content which can be either: a string (encoding will be used, that's where we fail), unicode (good), iterator of string or unicode
[10:32] <mgz> you need to also not break older python-debian versions that had completely different handling
[10:33] <jelmer> isn't python-debian supposed to handle this stuff for us though? What version of it is on jubany?
[10:33] <mgz> it's an older and more reliable version on jubany :)
[10:34] <vila> jelmer: a version that doesn't break, but the oneiric one I'm testing with locally breaks
[10:34] <jelmer> hmm
[10:34] <jelmer> I would argue we should fix python-debian instead, rather than trying to work around it
[10:34] <mgz> __init__(self, file=None, max_blocks=None, allow_empty_author=False, strict=True)
[10:35] <mgz> Set up the Changelog for use. file is the contects of the changelog.
[10:35] <mgz> you see something different I guess vila?
[10:35] <vila> file can be a string, unicode or iterator
[10:36] <vila> I see an additional encoding='utf-8'
[10:36] <mgz> ah, right, but not if you want it to work across versions :)
[10:37] <mgz> passing unicoded containing non-ascii here will die.
[10:37] <vila> I want it to work across versions,
[10:37] <mgz> -s
[10:37] <vila> argh
[10:37] <vila> err, yes
[10:37] <mgz> passing bytestrings containing non-utf8 on newer versions will die.
[10:37] <vila> yes
[10:37] <vila> with a UnicodeDecodeError
[10:37] <mgz> ...can possibly sniff and work around, I did that in bzr-builder already
[10:38] <vila> catching it and re-trying with an appropriate encoding is worth a try, if it's still fail... so be it
[10:54] <vila> s//it still fails/
[10:55] <vila> trying now with 瑨灴⼺瀯獡整甮畢瑮⹵潣⽭㜷㤰㜹
[10:56] <vila> ghaa, the irony :)
[10:57] <vila> that was http://paste.ubuntu.com/770997/ with some facetious gremlin in the loop
[10:57] <mgz> no, that's bad, you can't pass unicode unconditionally
[10:58] <mgz> you cann fall back to passing unicode, or trying to pass a different encoding name
[10:59] <vila> can't pass an encoding name for compatibility with old versions, why can't I pass unicode ?
[10:59] <mgz> because the old versions treat what you pass in as a byte string
[11:00] <vila> basestring
[11:00] <vila> or an iterator
[11:01] <vila> at least with the lucid and oneiric versions under my eyes
[11:04] <mgz> it depends how the changelog is used, for instance...
[11:05] <mgz> >>> str(cb)
[11:05] <mgz> Traceback (most recent call last):
[11:05] <mgz>   File "<stdin>", line 1, in <module>
[11:05] <mgz>   File "/usr/lib/pymodules/python2.6/debian/changelog.py", line 437, in __str__
[11:05] <mgz>     cl += str(block)
[11:05] <mgz> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 1332: ordinal not in range(128)
[11:05] <mgz> if you need to write it back out again, it dies.
[11:05] <mgz> if you just need to inspect you might be able to get away with it
[11:10] <vila> hence my previous question ;) : what do we need the changelog for, from a quick read, it seems we extract some infos but I dunno what format is acceptable for that
[11:11] <mgz> yeah, looking now
[11:11] <mgz> most of the logic is in util
[11:13] <mgz> there's also other Changelog creating function there
[11:15] <vila> bah, s/max_blocks=False/max_blocks=None/ most stooped tyop ever
[11:17] <mgz> all the code looks like it's doing enough hoop jumping with the values it's taking out
[11:18] <mgz> okay, so I think the safest, but maybe not the best thing,
[11:18] <mgz> would be to always decode from utf-8 where possible as you are
[11:19] <mgz> fall back as needed,
[11:19] <mgz> then re-encode to utf-8 for the older versions
[11:21] <vila> err, not decode at all for older versions you mean (for that last part) ?
[11:22] <vila> bah, may be too much, I don't think the parsed content is ever used to re-generate the changelog
[11:22] <vila> jelmer: two things,
[11:23] <vila> jelmer: thanks for your speedy reaction about gog_signing_key, I've put up a patch for review for bzr and approved your proposal for pqm
[11:23] <vila> jelmer: I have a dirty patch (gee, that's my dirty day ;) for bzr log -r bzr-2.5b3..bzr-2.5b4
[11:23] <vila> I almost forgot it
[11:23] <mgz> vila: see 'safe'_decode at the top of bzr-builddeb
[11:24] <mgz> it does basically your logic already, but expecting bytestrings back from Changelog attributes
[11:24] <vila> ECONTEXT top of what ?
[11:25] <mgz> util.py sorry.
[11:25] <vila> yeah, was there, my bad
[11:26] <vila> haha, sounds like an ad-hoc way already in use, will probably makes mgz cry though...
[11:28] <mgz> yeah, but unfortunately something along the lines is required given the ad hoc nature of historical changelogs and the api change in python-debian
[11:28] <vila> meh, you guys rock :)
[11:29] <vila> jelmer, mgz : I can't even read my mail that you've already landed the fix ;)
[11:33] <jelmer> :)
[11:34] <vila> both fixes even !
[11:34] <vila> and my dirty patch works !
[11:39] <vila> jelmer: given http://paste.ubuntu.com/771034 where should I search to add tests ?
[11:39] <jelmer> vila: hmm, another regression
[11:39] <jelmer> BZR_EMAIL is only checked if there is something in the store
[11:40] <jelmer> vila: tests/test_import_dsc.py I guess, but that file is scary
[11:41] <vila> darn, default=None, so default_email is not triggered :-(
[11:41] <vila> err, wait
[11:41] <jelmer> vila: default_email doesn't look at BZR_EMAIL, only email_from_store does
[11:42] <vila> but if nothing is in store, default_email should be called and them email_from_store should be called on the returned value
[11:42] <vila> s/them/then/
[11:42] <vila> where do you encounter that ?
[11:43] <jelmer> vila: default_email raises NoWhoAmi if it doesn't find any values
[11:43] <vila> test_import_dsc, ok, will look, will that be run against various python-debian ?
[11:43] <jelmer> vila: I'm hitting this in the launchpad testsuite
[11:43] <jelmer> vila: no, it only runs against the current python-debian
[11:43] <vila> ok, will have to do
[11:45] <vila> ha crap, no place to catch NoWhoami...
[11:45] <vila> jelmer: any way to force a config setting instead of relying on BZR_EMAIL ?
[11:46] <vila> bah, useless, won't work for people relying on BZR_EMAIL only
[11:47] <vila> oh, easy
[11:47] <jelmer> vila: I can fix it in Launchpad, it's a regression in general too though
[11:47] <vila> default_email should check BZR_EMAIL too
[11:47] <vila> yeah ^
[11:48] <vila> email_for_store enforces the policy but default_email should still respect BZR_EMAIL
[11:48] <vila> yeah and if EMAIL wasn't set in the bzr test suite I suspect we should have caught this earlier
[11:49] <vila>     'EMAIL': 'jrandom@example.com', # set EMAIL as bzr does not guess
[11:49] <jelmer> https://code.launchpad.net/~jelmer/bzr/config-store-BZR_EMAIL/+merge/85839
[11:49] <vila> oh, really ?
[11:49] <vila> hehe, yeah, spurious empty lines, just saw them :)
[11:50] <vila> jelmer: approved, and commit message set
[11:51] <jelmer> vila: thanks
[11:57]  * mgz jumps in front of the queue with release notes changes
[12:00] <jelmer> mgz: no you didn't :)
[12:00] <vila> hehe
[12:01] <jelmer> mgz: I resubmitted your post_connect transport hook btw, it works beautifully for counting the number of hpss connections.
[12:02] <vila> jelmer: oh, about that, why kind of hang were you referring to in one of those proposals ?
[12:02] <jelmer> vila: ask mgz :) it's one of his old branches from 2010, which used to hang, but no longer
[12:02] <vila> mgz: oh, about that, why kind of hang were you referring to in one of those proposals ?
[12:03] <vila> :)
[12:03] <mgz> ...if I conflict now I'll cry ;_;
[12:04] <vila> ...yeah, one of us should really ping some losa to get a copy of their locations.conf and fix it, AFAIK, the bzr version used there should be able to avoid most of the news conflicts
[12:07] <mgz> vila: yes, that's a mp you should review (again, look at the discussion from the last one too)
[12:08] <gnuoy`> vila, mgz, https://pastebin.canonical.com/57193/
[12:08] <vila> . o O (I asked and all I got was more questions and more work ;)
[12:09] <vila> mgz: justasec, I have a test to write to file a first proposal, then another test to write to file another proposal then I'm all yours :)
[12:47] <vila> holly cow ! losas now shoot faster than I can read too !!! Thanks gnuoy` !
[12:47] <vila> gnuoy`: not sure it's the right one though, there is no mention of bzr-2.x there
[12:50] <mgz> vila: looks like the right one to me, has the post_commit_to going to bazaar-commits
[12:51] <mgz> (helps that gnuoy is just across the table for low latency though :)
[12:52] <vila> well, if it's the right one, no wonder it doesn't try to resolve the news conflicts !
[12:52] <mgz> hm, is an old copy
[12:52] <mgz> not clear where the modern one is though
[12:53] <vila> news_merge_files = doc/en/release-notes/bzr-2.5.txt is needed
[12:53] <vila> updated appropriately for each series
[12:54] <vila> mgz: in the chroot ?
[12:54] <vila> or outside  :) Depends where you are looking :)
[12:54] <vila> the pqm host has been migrated some time (months) ago too, if it helps
[12:55] <vila> eeerk, lunch time !
[12:56] <mgz> vila, do you remember the rt # from when we needed to unbreak bzr-email?
[12:58] <vila> 48346 ?
[12:59] <vila> mgz: ^
[13:00] <mgz> ta, annoyingly doesn't specify exactly what changes were made
[13:02] <jml> https://code.launchpad.net/~jml/udd/binary-scan-mode/+merge/85853 up for review
[14:12] <seiflotfy> hey guys i cant seem to push anything to lp
[14:12] <jelmer> seiflotfy: hi
[14:12] <seiflotfy> ssh_exchange_identification: Connection closed by remote host
[14:12] <seiflotfy> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[14:13] <jelmer> seiflotfy: somebody else just reported that as well, but also that it seemed to be a temporary glitch
[14:13] <seiflotfy> i guess this is the wrong channel
[14:13] <seiflotfy> ah ok
[14:53] <kinkie> Hi all.. I have a strange issue on one of my bzr setups.. "bzr gcommit" will always insist on doing a local commit by default for a bzr+ssh-hosted branch. What may I check to have it default to a standard commit?
[14:53] <jelmer> kinkie: It tries to use network manager to see if you are online I think
[14:54] <jelmer> kinkie: do you have network manager installed but disabled?
[14:54] <kinkie> Hi Jelmer, long time no see :) NetworkManager it should be installed and working, but I'm not on that machine so I can't be sure.
[14:55] <kinkie> any way to trace this?
[14:57] <james_w> jelmer, hi, have you seen http://paste.ubuntu.com/771186/ ?
[14:58] <james_w> seems to only happen with older bzr?
[14:59] <jelmer> kinkie: hey, it has been indeed. :)
[14:59] <jelmer> kinkie: checking the code to see what it's doing exactly...
[14:59] <jelmer> james_w: no, also looking at that..
[14:59] <mgz> james_w: I get it locally as well
[15:00] <james_w> it looks like we need self.wants_revision_history for this to work?
[15:00] <james_w> or it's the local copies not being used?
[15:01] <james_w> err, forget I ever said that last line
[15:02] <mgz> I guess it's a regression from the revspec change recently jelmer did
[15:02] <mgz> can probably just change builddeb to not need wants_revision_history
[15:02] <jelmer> james_w: yeah, it's related to my deprecating wants_revision_history and updating bzr-builddeb to not request the full branch history
[15:02] <jelmer> mgz: that's what I did, but apparently, one of the bzr things it hands off to expects the full branch history anyway
[15:03] <mgz> ah, already did that, but not in a way that supports earlier bzrs
[15:13] <james_w> jelmer, mgz, have any ideas better than http://paste.ubuntu.com/771206/ ?
[15:17] <jelmer> james_w: we shouldn't be setting wants_revision_history to true. I'd rather look at the bzrlib version and then pass the history into RevisionInfo.from_revision_id as necessary
[15:17] <james_w> ok
[15:20] <mgz> james_w: for reference, <https://code.launchpad.net/~jelmer/bzr/revspec-no-full-revhistory/+merge/84189>
[15:24] <jelmer> james_w: would you like me to look into providing a patch or are you working on it?
[15:25] <james_w> jelmer, if you could that would be great, your obviously much more familiar with this code than I
[15:26] <jelmer> kinkie: there should be a checkbox in the gcommit window (bottom-left corner) that determines whether to commit locally or not
[15:41] <kinkie> yes
[15:42] <kinkie> My problem is that on that one machine (it's a kubuntu 11.10) it's checked on by default.
[15:43] <kinkie> but on another machine with the same kubuntu release it's working fine. Only difference between the two pc's I can think of, is that the one which is "failing" is connected over eth0, while the one that has the expected behaviour is running over wifi
[15:44] <jelmer> kinkie: hmm, trying it locally I can reproduce it here as well
[15:44] <jelmer> kinkie: shouldn't be a hard fix. I'll file a bug and submit a fix after I look at this bzr-builddeb issue James mentioned.
[15:45] <kinkie> great, thank you very much
[15:45] <kinkie> it's not a big deal, but it's annoying
[15:45] <kinkie> also because there is no real command to say "flush my local queue to the local repository", I have to go through a real commit :\
[15:51] <jelmer> james_w: which version of bzr are you using?
[15:52] <jelmer> mgz: did you see the post_connect_transport_hook branch ?
[15:52] <james_w> jelmer, 2.4.1
[15:56] <vila> jelmer: just reviewed, the same issue still stands, it doesn't provide a reliable way to count smart connections
[15:56] <mgz> jelmer: yes, thanks, I'm just trying out some tests on it now to see whether it does cover the same cases as the current monkey patching
[15:58] <vila> mgz: it should but if you can add more tests (like, parametrized ones) that would be nice, one case I wonder about is smart http transport, is the hook called once or twice
[16:04] <jelmer> vila: I care about counting the number of TCP connections, basically.
[16:07] <mgz> vila: have you got your counter aggregating subunit filter?
[16:07] <mgz> save me writing my own for this...
[16:07] <vila> jelmer: hmm.. I wonder... If the code you're testing properly calls .clone() and pass possible_transports in the right places... you should encounter only false positives (i.e. connections that are created but not used, which in this case means there is no connection)
[16:08] <vila> mgz: in tools/
[16:08] <vila> mgz: subunit-sum
[16:09] <vila> mgz: adding some regexp would be neat ;-p
[16:11] <jelmer> vila: I mostly care about possible_transports being used where necessary
[16:12]  * vila nods
[16:12] <vila> jelmer: a less ambiguous hook name could do for now with proper warnings for users
[16:12] <vila> then
[16:13] <vila> jelmer: at worst you'll get false positives and we'll need to find a better way
[16:13] <jelmer> vila: it would be nice to also address the original use case that mgz was trying to address
[16:14] <jelmer> vila: is the post_connect hook actually called for smart transports? I didn't see any evidence of that.
[16:14] <vila> jelmer: this original use case *is* addressed with the current proposal AFAICS
[16:14] <vila> jelmer: it's called for RemoteTransport yes, that's the controversial call
[16:15] <vila> jelmer: because it's called when the medium is created not after a connection is established
[16:16] <vila> jelmer: of course you should stay away from bzr+http or you'll probably see twice as much connections
[16:16] <jelmer> vila: it's still a transport connect though, isn't it?
[16:16] <vila> no
[16:16] <vila> there is no such thing as transport.connect()
[16:18] <jelmer> vila: no, but there are transports that use connections
[16:19] <jelmer> and what is considered a connection seems to be quite vague
[16:19] <vila> hehe, indeed
[16:20] <vila> and if you re-read the old comments on the proposal you'll see that I wanted feedback about whether medium could be dropped so all transports at least use the SharedConnection object in the same way
[16:20] <vila> well, for the ones it applies to of course
[16:21] <vila> the connection object (and its associated credentials) is specific to each kind of transport
[16:31] <mgz> so, I screwed up the first run and am redoing it
[16:31] <mgz> but I think I have something under smart covered at least, despite the fact it doesn't use ConnectedTransport
[16:32] <mgz> it might not be completely correct, but was giving jelmer approximately correct numbers
[16:32] <mgz> the issue of overcounting may well still be present.
[16:34] <jelmer> I can always filter out RemoteTransport in my hook, if necessary
[16:34] <mgz> okay, that's better@
[16:34] <mgz> connected_transport_count: 220
[16:34] <mgz> now for the other branch
[16:36] <kinkie> gotta go.. see you!
[16:38] <vila> mgz: overcouting because of the backing transport or because of not really connected smart transports ?
[16:38] <vila> jelmer can filter if it's the former, the later may be worth investigating anyway
[16:39] <vila> during tests, there is no good reason to create an unwanted transport
[16:39] <mgz> the former I think, the latter I *think* I may have avoided
[16:46] <mgz> connected_transport_count: 149
[16:46] <mgz> so, the hook version is seeing a lot fewer
[16:47] <mgz> shall dig into it and see if where the difference lies
[16:48] <mgz> I suspect the current method is mostly overcounting from having things returned from get_transport that don't line up well with the underlying connections
[16:49] <vila> current as in monkey-patching get_transport ?
[16:53] <mgz> vila: yup
[16:53] <mgz> which we know gets the same transport object multiple times in some cases
[16:54] <mgz> but I've done an identity check for that in the count, so it must also get different but same-connection-backed objects
[16:54] <mgz> else hook is missing real connection
[16:54] <mgz> eg
[16:55] <mgz> in bb.test_branch, test_branch_local_remote and test_branch_remote_remote are respectively:
[16:55] <mgz> monkey: 4, 5
[16:55] <mgz> hook: 3, 4
[16:56] <vila> ok, the number are small enough to relate them to the objects created in the tests right ?
[16:56] <om26er_> Hey everyone, when we do a 'bzr branch lp:somethings' where is the source tree placed before the completion?
[16:56] <mgz> that's the plan
[16:56] <vila> the test servers may use some transports too... both methods should catch them in the same way though
[16:56] <vila> om26er_: nowhere
[16:57] <om26er_> i am pulling a branch and seem launchpad have some problem so the download gets stuck in the middle and i have to bzr branch again but it gets stuck again :/
[16:57] <vila> om26er_: known issue, the lp guys are working on it
[16:58] <om26er_> oh sad for me :/
[16:58] <om26er_> i hope its fixed soon
[16:58] <vila> om26er_: known as in: something is going on since a couple of hours, first time I hear about a so long incident
[16:58] <vila> om26er_: we all do :)
[16:58] <om26er_> vila, thx :)
[16:59]  * vila wonders whether the automatic reconnection may have aggravated the situation...
[17:00] <vila> jelmer: sorry to bother you again about that but what is the bzr version used on codehosting right now ?
[17:00] <jelmer> vila: snapshot of something early in the 2.5 cycle
[17:01] <mgz> not deployed yet vila
[17:01] <jelmer> vila: (and not a problem)
[17:01] <mgz> and doubt there are enough beta users on client side to have an impact anyway
[17:01] <jelmer> mgz: there are quite a few people running precies
[17:01] <jelmer> *precise
[17:01] <vila> mgz: of course it's deployed, it's part of 2.5b4
[17:01] <vila> yup
[17:02] <vila> it retries only once though so probably not enough to explain the pike
[17:06] <mgz> as in, nothing is actively disconnecting people, but yeah
[17:07] <vila> He did that on purpose ?
[17:07] <jelmer> vila: ? who did?
[17:07] <jelmer> and what ? :)
[17:07] <vila> mgz, talking about " actively disconnecting people" and getting disconnected :-D
[17:08] <vila> I wanted to ask if he get the news_merge stuff sorted out on pqm...
[17:09] <vila> s/get/got/
[19:18] <razam> is there a way to ignore a directory except for a subdirectory under it?  use case is a distribution's themes directory where i created my own theme under it
[19:22] <jelmer> razam: You can just ignore everything in that directory and explicitly add the directory you do want to add.
[19:22] <jelmer> "bzr ignore 'directory/*'"
[19:22] <jelmer> "bzr add directory/thesubdirectory"
[19:22] <jelmer> Noldorin: did you see bug 662448 ?
[19:22] <razam> hmmm
[19:22] <razam> interesting..
[19:22] <razam> jelmer: thanks..
[19:34] <zyga> jelmer, hi
[19:34] <zyga> jelmer, fancy looking at a bzr-git bug?
[19:34] <zyga> eh...
[19:34]  * zyga just updated bzr-git to trunk and ... the bug is gone
[19:35] <zyga> http://pastebin.ubuntu.com/771499/
[19:35] <zyga> jelmer, if you are interested that's what happened ^^
[20:16] <jelmer> zyga: yeah, that was recently fixed
[20:16] <zyga> jelmer, thanks
[20:19] <jelmer> zyga: hmm, you're using "bzr pull" into a git repository? Do you have local changes to your bzr-git branch to enable the experimental mappings?
[20:20] <zyga> jelmer, I don't thinks so
[20:20] <zyga> jelmer, tell me more, I want to be your beta user
[20:20] <zyga> jelmer, i'm moving to git workflow with trunks in bzr (for team workflow)
[20:20] <zyga> jelmer, I want to ensure I can hack in git, then publish in bzr
[20:21] <Noldorin> hi jelmer
[20:21] <Noldorin> jelmer, nope what is it?
[20:22] <jelmer> Noldorin: bug about documentation for bzr+ssh on Windows, including a text document with notes
[20:22] <jelmer> zyga: hmm, that's odd
[20:22] <Noldorin> jelmer, relevant to me in what way though?
[20:22] <jelmer> zyga: so, this is one of the things I would like to support in bzr-git, but it shouldn't be enabled by default
[20:22] <zyga> jelmer, tell me more about that, how do I enable it
[20:23] <jelmer> Noldorin: you were trying to set up a ssh server on Windows, right?
[20:23] <jelmer> zyga: it seems you already have, which is what puzzles me
[20:23]  * jelmer tries it locally
[20:23] <zyga> hmm
[20:23] <zyga> jelmer, how do I check
[20:23] <Noldorin> jelmer, oh. succeeded days ago hehehe
[20:23] <zyga> is it a branch format?
[20:23] <Noldorin> jelmer, symlinks it doesn't like still though...but oh well
[20:23] <Noldorin> that's to be expected
[20:24] <jelmer> zyga: pulling and pushing from bzr into git shouldn't work yet, only "bzr dpush" (which is lossy)
[20:24] <jelmer> zyga: to enable lossless push/pull you should have to change the default mapping format in bzr-git to 'experimental'
[20:25] <jelmer> zyga: mapping.py, around line 443
[20:25] <zyga> jelmer, I used dpush once
[20:27] <zyga> jelmer, I just enabled that locally
[20:27] <zyga> jelmer, let me try playing with my bzr/git trees
[20:27] <zyga> jelmer, do I get this right: I can branch from bzr, push to git and pull back with all the state tracked?
[20:28] <jelmer> zyga: well, that's the idea
[20:28]  * zyga jumps in joy
[20:28] <jelmer> zyga: I've just added a Big Fat Warning, since this is all this experimental
[20:28] <zyga> I'll gladly report bugs and feedback
[20:28] <jelmer> zyga: great
[20:28] <zyga> hrw, ^^^^^^
[20:28] <zyga> hrw, xmas came
[20:28] <jelmer> zyga: btw, do you know about git-remote-bzr in bzr-git ?
[20:28] <zyga> jelmer, nope
[20:28] <jelmer> zyga: it basically exposes this functionality, but as a remote helper in git
[20:29] <zyga> O :-)
[20:29] <zyga> so I get a remote in git that works with bzr repos?
[20:29] <zyga> :D
[20:29] <jelmer> IOW, "git clone bzr::lp:dulwich"
[20:29] <zyga> jelmer, I'm sorry I won't see you at the next linaro connect or UDS but I'll get you a big beer once we sprint together
[20:29] <zyga> does it need any config on git part?
[20:30] <jelmer> zyga: It's still slow as hell, since the emphasis in bzr-git has always been on importing from git into bzr, not the other way around
[20:30] <jelmer> zyga: but it's gradually improving
[20:30] <jelmer> zyga: :-)
[20:30] <jelmer> zyga: you need to install git-remote-bzr in /usr/lib/git-core. The bzr-git Debian/Ubuntu package will do this for you
[20:31] <zyga> http://paste.ubuntu.com/771537/
[20:31] <zyga> ok
[20:31] <zyga> I'm pretty sure I have that package, let me check
[20:32] <zyga> yup, 0.6.5+bzr1465-1
[20:32] <jelmer> zyga: you have a mismatching git-remote-bzr and bzr-git plugin in ~/.bazaar/plugins/git
[20:32] <zyga> jelmer, I have trunk in .b/p/git
[20:32] <zyga> hmm
[20:32] <zyga> so what should I do
[20:33] <jelmer> zyga: you'll need git-remote-bzr from lp:bzr-git as well in that case
[20:33] <zyga> or -- how should I upgrade the other
[20:33] <zyga> ok
[20:33] <zyga> let me try
[20:33] <zyga> ah, so it's in the same repo
[20:34] <zyga> jelmer, can I setup.py install --user for your plugin to work
[20:34] <zyga> and for git to pick up git-remote-bzr magically from my local path
[20:35]  * zyga tries
[20:35] <jelmer> zyga: I usually just create a symlink from ~/.bazaar/plugins/git to my checkout of lp:bzr-git
[20:35] <jelmer> zyga: that means I don't have to touch setup.py at all
[20:35] <zyga> that's what I have for bzr
[20:35] <jelmer> zyga: I'm not sure if git looks at anything beyond /usr/lib/git-core. If you find out, please let me know :)
[20:35] <zyga> but for git I need that script in my PATH
[20:35] <zyga> beh, installing it did not install the script
[20:35] <zyga> ok
[20:36] <jelmer> zyga: right, setup.py doesn't install git-remote-bzr yet as I haven't found a good way of getting at the locations git uses
[20:36] <zyga> it seems to have worked
[20:37] <zyga> er... wait
[20:37] <zyga> ok
[20:37] <zyga> I've got this: unknown command "commit"
[20:37] <zyga> and it's doing the branch it seems
[20:37] <zyga> so, the good part is:
[20:37] <zyga> you can add that to the scripts=[]
[20:38] <zyga> and it seems to work when it's in ~/.local/bin (assuming your PATH looks there)
[20:39] <zyga> jelmer, it failed :/
[20:39] <zyga> http://pastebin.ubuntu.com/771550/
[20:42] <jelmer> zyga: bug reports welcome, don't say I didn't warn you :-)
[20:42] <jelmer> e.g. git clone bzr::lp:etckeeper works
[20:42] <zyga> I see
[20:42] <zyga> ok
[20:42] <zyga> jelmer, ok, but that's secondary (filing bug now)
[20:42] <zyga> if I can branch from bzr trunk on launchpad
[20:43] <zyga> then push that to a git repo
[20:43] <zyga> and pull back
[20:45] <zyga> https://bugs.launchpad.net/bzr-git/+bug/904951
[20:50] <jelmer> zyga: thanks
[20:56] <hrw> zyga: its not xmas. I do not want to use bzr to manage git repos
[20:56] <hrw> but using git to manage bzr would be lovely
[20:58] <hrw> jelmer: I read most of backlog now. if it works then beer from me as well
[21:04] <hrw> jelmer: would it be possible to have information which git rev is which bzr rev? like git-svn does
[21:04] <hrw> warning: Duplicated ref: refs/tags/1.68
[21:05] <hrw> I did: git clone bzr::lp:ubuntu/armel-cross-toolchain-base (which I normally develop in git and it has bzr copy done from releases)
[21:05] <jelmer> zyga, hrw: it's by no means useful for production yet
[21:06] <jelmer> importing git repositories into bzr works pretty well, but the other way around still has lots of issues and hasn't been optimised
[21:06] <hrw> sure
[21:06] <hrw> jelmer: but if you need tester then I'm in
[21:06] <jelmer> the main reason I work on it is so I can contribute to git projects with bzr, but improvements in bzr-git help for both our use cases
[21:06] <jelmer> hrw: cool
[21:08] <hrw> unknown command "commit"
[21:08] <hrw> like zyga ;)
[21:08] <hrw> jelmer: apport-bug bzr-git?
[21:09] <hrw> jelmer: will you check bug 680833 too?
[21:11] <hrw> bug 904963
[21:11] <hrw> zyga: mark it as 'affects me' so it will be confirmed?
[21:12] <hrw> jelmer: 'git clone bzr::lp:ubuntu/armel-cross-toolchain-base' generates warnings about duplicated tags.
[21:12] <hrw> jelmer: but 'git remote add bzr bzr::lp:ubuntu/armel-cross-toolchain-base;git remote update' does not
[21:13] <hrw> will report
[21:14] <hrw> but tomorrow
[21:14] <hrw> have a nice rest of day
[22:08] <zyga> hrw, you got it backwards
[22:08] <zyga> :-)
[22:08] <zyga> hrw, looks promising
[22:16] <hrw> zyga: ?
[22:21] <zyga> hrw, sorry, was reading backlog
[22:21] <zyga> hrw, I too hope for git with bzr workflow
[22:22] <Noldorin> hi poolie
[22:22] <Noldorin> you around at present?
[22:37] <SpamapS> Hm, so if I do BZR_DISABLE_PLUGINS='changelog_merge' bzr plugins  .. I do not see the changelog_merge plugin. But then later, if I do a merge of a packaging branch, it still uses the plugin...
[22:37] <SpamapS> $ BZR_DISABLE_PLUGINS='changelog_merge' bzr merge ../fix-
[22:37] <SpamapS> ask-for-passphrase
[22:37] <SpamapS> dpkg-mergechangelogs: error: 2.0.37+cvs.JCW_PRE2_2037-1 is not a valid version
[22:38] <jelmer> hey Noldorin
[22:38] <jelmer> hi SpamapS
[22:38] <SpamapS> jelmer: o/
[22:38] <jelmer> SpamapS: FWIW mgz submitted a fix for bzr-builddeb for that issue, we should be uploading it to precise shortly
[22:39] <jelmer> though BZR_DISABLE_PLUGINS should work..
[22:39] <SpamapS> Yeah I'm a bit confused. :-P
[22:40] <Noldorin> hi again jelmer
[22:40] <jelmer> Noldorin: I think poolie isn't around today
[22:40] <Noldorin> jelmer, remind me, how did you recommend i set up bzr+ssh on windows so that i get two different users sharing the same set of repos/directory?
[22:40] <Noldorin> ah okay
[22:40] <Noldorin> fair enough
[22:40] <Noldorin> was going to set up LP to hack on my windows server. apparently it's difficult, but possible
[22:40] <Noldorin> a local LP server that is
[22:41] <jelmer> SpamapS: hmm, I can't really see how that would be the case. Are you sure you haven't made a typo or something like that?
[22:42] <SpamapS> jelmer: thats kind of why I pasted the cmdline
[22:42] <jelmer> SpamapS: ah, found it
[22:42] <jelmer> SpamapS: changelog_merge is for Changelog-like files. the debian/changelog merger is in bzr-builddeb
[22:42] <SpamapS> OH
[22:42] <jelmer> SpamapS: so you want BZR_DISABLE_PLUGINS=builddeb
[22:43] <SpamapS> much better
[22:43] <SpamapS> usually its *awesome*
[22:43] <SpamapS> but this time.. it was just #$@!ing things up :)
[22:47] <jelmer> SpamapS: thanks, glad to know it's useful :-)
[22:47] <jelmer> SpamapS: bug 842144
[22:48] <SpamapS> jelmer: ah fantastic
[22:48] <Noldorin> jelmer, well? :-)
[22:48] <jelmer> hmm, bug 842144
[22:48] <jelmer> SpamapS: it's actually fixcommitted, but ubot doesn't seem to recognize that
[22:48] <jelmer> Noldorin: sorry?
[22:49] <Noldorin> jelmer, see my previous message(s) to you...
[22:49] <Noldorin> think you may have missed them
[22:49] <jelmer> Noldorin: I did see them, I'm just not sure what you're asking :)
[22:49] <Noldorin> oh with what?
[22:49] <Noldorin> hmm
[22:50] <Noldorin> thought we talked abut this before
[22:50] <Noldorin> maybe just mgz and lifeless and poolie
[22:50] <Noldorin> heh
[22:50] <jelmer> Noldorin: whether it's feasible to set up a Launchpad instance on Windows? I don't think that's possible without doing a lot of porting work.
[22:51] <Noldorin> oh
[22:51] <Noldorin> poolie suggested it was more doable than that
[22:51] <Noldorin> hmm
[22:51] <Noldorin> oh well
[22:52] <Noldorin> what about the dir/repo shared between ssh users on bzr server? :-)
[22:52] <jelmer> Noldorin: I don't think anybody has ever done that.. (Launchpad on Windows)
[22:52] <Noldorin> ah
[22:52] <Noldorin> hmm
[22:52] <jelmer> Noldorin: Are you sure he wasn't talking about loggerhead?
[22:52] <Noldorin> Ubuntu is standard i guess?
[22:53] <jelmer> Noldorin: right, but I don't think a lot of people actually run their own launchpad instance
[22:54] <Noldorin> yeah true heh
[22:54] <jelmer> Noldorin: either way, #launchpad is probably more appropriate for that discussion :)
[22:54] <Noldorin> i was going to do some hacking
[22:54] <Noldorin> oops, yes
[22:54] <Noldorin> sorry
[22:54] <Noldorin> i merge the two channels in my mind sometimes
[22:54] <Noldorin> many of the same people ;-)
[22:54] <Noldorin> all Canonical
[22:54] <Noldorin> brb
[23:34] <coventry> What is the bzr equivalent of gitk?  I have found references to bzrk, which seems to have been subsumed by bzr-gtk, but I haven't found a clear description of how to invoke it.
[23:35] <spiv> bzr viz
[23:35] <coventry> Terrific, thank you.
[23:35] <spiv> Or 'bzr qlog' if you have the qbzr plugin
[23:36] <spiv> (Which is probably a bit more polished than bzr-gtk atm)
[23:37] <spiv> (Also, I'm pretty sure the invocation has been 'bzr viz' since almost the very beginning of that code!)
[23:40] <coventry> Probably I was confused because I was expecting a standalone program like gitk.  Thanks again.