| Noldorin | poolie, hey. | 00:38 |
|---|---|---|
| Noldorin | how's progress on bzr 2.5? :-) | 00:38 |
| Noldorin | generally | 00:38 |
| nixmaniack | how can I continue an interrupted cloning of bzr repo? I started with bzr branch lp:calibre but interrupted in between | 00:39 |
| Noldorin | nixmaniack, interrupted how exactly? | 00:43 |
| Noldorin | ctrl+c? | 00:43 |
| Noldorin | process kill? | 00:43 |
| nixmaniack | Noldorin, ctrl+c | 00:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| mamalala | bzr is downloading insanely high amounts of data for "small" stuff ... since i'm on umts internet, that really sucks | 00:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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:... | 00:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:29 |
| 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:30 |
| 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:31 |
| mamalala | fullermd: lp:~kicad-developers/kicad/doc and then lp:~kicad-lib-committers/kicad/library | 01:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| fullermd | Or is it loggerhead? I don't really know, I s'pose. Still. It's colored clicky stuff :p | 01:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| mamalala | go for 100% .. | 01:42 |
| fullermd | I don't want to sound greedy. Especially right before christmas. | 01:42 |
| mamalala | ah, great ... got the two tarballs already ... _much_ better than before | 01:43 |
| 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:44 |
| mamalala | maybe i should hope for a "bzr --just-grab-the-damn-tarball" option for christmas :D | 01:45 |
| fullermd | I was thinking of going for world peace. But then what would they put on the news? | 01:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| fullermd | Luckily, all my MUD data is compressed. | 01:57 |
| 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:58 |
| 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 | 01:59 |
| mamalala | well, i have flash installed, because some customers want to show me their latest-and-greatest... | 02:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:06 | |
| poolie | hi fullermd | 02:16 |
| * fullermd waves at poolie. | 02:17 | |
| 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 | 02:26 |
| === r0bby is now known as robbyoconnor | ||
| wgz | happy un-morning | 06:39 |
| vila | hey guys | 07:30 |
| wgz | hey vila... bus soon | 07:36 |
| vila | as in: see you in the bus ??? /me confused | 07:36 |
| vila | :) | 07:36 |
| wgz | as in, I need to catch it :) | 07:39 |
| vila | wgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ? | 08:32 |
| mgz | morning! | 08:35 |
| 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:37 |
| 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:41 |
| 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:42 |
| mgz | if you can pdb in there and go up, will be easy enough to find the part debian.changelog doesn't like | 08:44 |
| 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:45 | |
| mgz | ...I need to fix my news anyway, will reorder at same time | 08:46 |
| mgz | which bit are you looking at? | 08:46 |
| vila | fixed, in my proposal for bug #904550 | 08:48 |
| ubot5 | Launchpad bug 904550 in Bazaar "gpg signing key doesn't default to 'email' anymore" [Critical,In progress] https://launchpad.net/bugs/904550 | 08:48 |
| mgz | ...now that needs to land before I can fix my news? :) | 08:48 |
| vila | mgz: won't be enough, you'll also need pqm patch from jelmer for 2.5-compat | 08:49 |
| mgz | ah, or pqm won't let anything through at all? | 08:50 |
| 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:51 |
| vila | mgz: ok, the debian changelog contains Küster which emacs sees as iso-latin-1 in fityk_0.4.3p1-1.diff.gz | 08:52 |
| vila | mgz: weird, that same import succeeded on jubany :-/ | 09:54 |
| mgz | vila: likely it has a different version of python-debian | 09:57 |
| mgz | I have 0.1.18 which does not fall over in a bunch of cases newer versions do | 09:58 |
| 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) | 09:59 |
| mgz | this is complicated by the fact the tools don't make an effort to raise sane errors | 10:00 |
| vila | 0.1.14ubunt2 on jubany, 0.1.20ubuntu2 locally :-( | 10:01 |
| mgz | ^s/thing/think/ obviously | 10:02 |
| mgz | ThingPad | 10:02 |
| vila | I don't skip the importer can afford to skip versions :-/ | 10:04 |
| vila | meh, we both have trouble with think this morning... s/skip/think/ | 10:12 |
| vila | trying with a dirty hack: force latin_1 when UnicodeDecodeError is encountered :-{ | 10:15 |
| jml | I never thought I'd say this, but using bzrlib.tests.TestCase feels kind of primitive | 10:17 |
| 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:19 |
| vila | mgz: what do you know about the debian/changelog encodings ? | 10:21 |
| 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:22 |
| 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 |
| mgz | <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog> | 10:23 |
| vila | jelmer: with recent versions of python-debian, latin_1 is used in once case and breaks import_dsc | 10:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| mgz | you need to also not break older python-debian versions that had completely different handling | 10:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| vila | I see an additional encoding='utf-8' | 10:36 |
| mgz | ah, right, but not if you want it to work across versions :) | 10:36 |
| 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:37 |
| vila | catching it and re-trying with an appropriate encoding is worth a try, if it's still fail... so be it | 10:38 |
| vila | s//it still fails/ | 10:54 |
| vila | trying now with 瑨灴⼺瀯獡整甮畢瑮潣⽭㜷㤰㜹 | 10:55 |
| vila | ghaa, the irony :) | 10:56 |
| 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:57 |
| mgz | you cann fall back to passing unicode, or trying to pass a different encoding name | 10:58 |
| 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 | 10:59 |
| vila | basestring | 11:00 |
| vila | or an iterator | 11:00 |
| vila | at least with the lucid and oneiric versions under my eyes | 11:01 |
| mgz | it depends how the changelog is used, for instance... | 11:04 |
| 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:05 |
| 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:10 |
| mgz | yeah, looking now | 11:11 |
| mgz | most of the logic is in util | 11:11 |
| mgz | there's also other Changelog creating function there | 11:13 |
| vila | bah, s/max_blocks=False/max_blocks=None/ most stooped tyop ever | 11:15 |
| mgz | all the code looks like it's doing enough hoop jumping with the values it's taking out | 11:17 |
| 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:18 |
| mgz | fall back as needed, | 11:19 |
| mgz | then re-encode to utf-8 for the older versions | 11:19 |
| vila | err, not decode at all for older versions you mean (for that last part) ? | 11:21 |
| 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:22 |
| 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:23 |
| mgz | it does basically your logic already, but expecting bytestrings back from Changelog attributes | 11:24 |
| vila | ECONTEXT top of what ? | 11:24 |
| mgz | util.py sorry. | 11:25 |
| vila | yeah, was there, my bad | 11:25 |
| vila | haha, sounds like an ad-hoc way already in use, will probably makes mgz cry though... | 11:26 |
| 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:28 |
| vila | jelmer, mgz : I can't even read my mail that you've already landed the fix ;) | 11:29 |
| jelmer | :) | 11:33 |
| vila | both fixes even ! | 11:34 |
| vila | and my dirty patch works ! | 11:34 |
| 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:39 |
| jelmer | vila: tests/test_import_dsc.py I guess, but that file is scary | 11:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:45 |
| vila | bah, useless, won't work for people relying on BZR_EMAIL only | 11:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| vila | jelmer: approved, and commit message set | 11:50 |
| jelmer | vila: thanks | 11:51 |
| * mgz jumps in front of the queue with release notes changes | 11:57 | |
| jelmer | mgz: no you didn't :) | 12:00 |
| vila | hehe | 12:00 |
| jelmer | mgz: I resubmitted your post_connect transport hook btw, it works beautifully for counting the number of hpss connections. | 12:01 |
| 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:02 |
| vila | :) | 12:03 |
| mgz | ...if I conflict now I'll cry ;_; | 12:03 |
| 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:04 |
| mgz | vila: yes, that's a mp you should review (again, look at the discussion from the last one too) | 12:07 |
| 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:08 |
| 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:09 |
| 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:47 |
| mgz | vila: looks like the right one to me, has the post_commit_to going to bazaar-commits | 12:50 |
| mgz | (helps that gnuoy is just across the table for low latency though :) | 12:51 |
| 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:52 |
| vila | news_merge_files = doc/en/release-notes/bzr-2.5.txt is needed | 12:53 |
| vila | updated appropriately for each series | 12:53 |
| 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:54 |
| vila | eeerk, lunch time ! | 12:55 |
| mgz | vila, do you remember the rt # from when we needed to unbreak bzr-email? | 12:56 |
| vila | 48346 ? | 12:58 |
| vila | mgz: ^ | 12:59 |
| mgz | ta, annoyingly doesn't specify exactly what changes were made | 13:00 |
| jml | https://code.launchpad.net/~jml/udd/binary-scan-mode/+merge/85853 up for review | 13:02 |
| === yofel_ is now known as yofel | ||
| 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:12 |
| 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:13 |
| 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:53 |
| 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:54 |
| kinkie | any way to trace this? | 14:55 |
| james_w | jelmer, hi, have you seen http://paste.ubuntu.com/771186/ ? | 14:57 |
| james_w | seems to only happen with older bzr? | 14:58 |
| 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 | 14:59 |
| 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:00 |
| james_w | err, forget I ever said that last line | 15:01 |
| 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:02 |
| mgz | ah, already did that, but not in a way that supports earlier bzrs | 15:03 |
| james_w | jelmer, mgz, have any ideas better than http://paste.ubuntu.com/771206/ ? | 15:13 |
| 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:17 |
| mgz | james_w: for reference, <https://code.launchpad.net/~jelmer/bzr/revspec-no-full-revhistory/+merge/84189> | 15:20 |
| jelmer | james_w: would you like me to look into providing a patch or are you working on it? | 15:24 |
| james_w | jelmer, if you could that would be great, your obviously much more familiar with this code than I | 15:25 |
| jelmer | kinkie: there should be a checkbox in the gcommit window (bottom-left corner) that determines whether to commit locally or not | 15:26 |
| kinkie | yes | 15:41 |
| kinkie | My problem is that on that one machine (it's a kubuntu 11.10) it's checked on by default. | 15:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| jelmer | james_w: which version of bzr are you using? | 15:51 |
| jelmer | mgz: did you see the post_connect_transport_hook branch ? | 15:52 |
| james_w | jelmer, 2.4.1 | 15:52 |
| 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:56 |
| 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 | 15:58 |
| jelmer | vila: I care about counting the number of TCP connections, basically. | 16:04 |
| 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:07 |
| vila | mgz: in tools/ | 16:08 |
| vila | mgz: subunit-sum | 16:08 |
| vila | mgz: adding some regexp would be neat ;-p | 16:09 |
| jelmer | vila: I mostly care about possible_transports being used where necessary | 16:11 |
| * 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:12 |
| 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:13 |
| 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:14 |
| vila | jelmer: because it's called when the medium is created not after a connection is established | 16:15 |
| 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:16 |
| jelmer | vila: no, but there are transports that use connections | 16:18 |
| jelmer | and what is considered a connection seems to be quite vague | 16:19 |
| vila | hehe, indeed | 16:19 |
| 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:20 |
| vila | the connection object (and its associated credentials) is specific to each kind of transport | 16:21 |
| 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:31 |
| 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:32 |
| 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:34 |
| kinkie | gotta go.. see you! | 16:36 |
| 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:38 |
| 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:39 |
| mgz | connected_transport_count: 149 | 16:46 |
| mgz | so, the hook version is seeing a lot fewer | 16:46 |
| mgz | shall dig into it and see if where the difference lies | 16:47 |
| 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:48 |
| vila | current as in monkey-patching get_transport ? | 16:49 |
| mgz | vila: yup | 16:53 |
| mgz | which we know gets the same transport object multiple times in some cases | 16:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| * vila wonders whether the automatic reconnection may have aggravated the situation... | 16:59 | |
| 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:00 |
| 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:01 |
| === deryck is now known as deryck[lunch] | ||
| vila | it retries only once though so probably not enough to explain the pike | 17:02 |
| mgz | as in, nothing is actively disconnecting people, but yeah | 17:06 |
| 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:07 |
| vila | I wanted to ask if he get the news_merge stuff sorted out on pqm... | 17:08 |
| vila | s/get/got/ | 17:09 |
| === deryck[lunch] is now known as deryck | ||
| 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:18 |
| 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 |
| ubot5 | Launchpad bug 662448 in Bazaar "docs should describe how to set up ssh keys" [Medium,In progress] https://launchpad.net/bugs/662448 | 19:22 |
| razam | interesting.. | 19:22 |
| razam | jelmer: thanks.. | 19:22 |
| 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:34 | |
| zyga | http://pastebin.ubuntu.com/771499/ | 19:35 |
| zyga | jelmer, if you are interested that's what happened ^^ | 19:35 |
| jelmer | zyga: yeah, that was recently fixed | 20:16 |
| zyga | jelmer, thanks | 20:16 |
| 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:19 |
| 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:20 |
| Noldorin | hi jelmer | 20:21 |
| Noldorin | jelmer, nope what is it? | 20:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| jelmer | zyga: mapping.py, around line 443 | 20:25 |
| zyga | jelmer, I used dpush once | 20:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:35 |
| 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:36 |
| 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:37 |
| zyga | and it seems to work when it's in ~/.local/bin (assuming your PATH looks there) | 20:38 |
| zyga | jelmer, it failed :/ | 20:39 |
| zyga | http://pastebin.ubuntu.com/771550/ | 20:39 |
| 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:42 |
| zyga | then push that to a git repo | 20:43 |
| zyga | and pull back | 20:43 |
| zyga | https://bugs.launchpad.net/bzr-git/+bug/904951 | 20:45 |
| ubot5 | Ubuntu bug 904951 in Bazaar Git Plugin "Fails on git clone bzr::lp:lava-server" [Undecided,New] | 20:45 |
| jelmer | zyga: thanks | 20:50 |
| 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:56 |
| hrw | jelmer: I read most of backlog now. if it works then beer from me as well | 20:58 |
| 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:04 |
| 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:05 |
| 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:06 |
| hrw | unknown command "commit" | 21:08 |
| hrw | like zyga ;) | 21:08 |
| hrw | jelmer: apport-bug bzr-git? | 21:08 |
| hrw | jelmer: will you check bug 680833 too? | 21:09 |
| ubot5 | Launchpad bug 680833 in bzr-git (Ubuntu) ""git-apply" does not add new files" [Medium,Triaged] https://launchpad.net/bugs/680833 | 21:09 |
| hrw | bug 904963 | 21:11 |
| ubot5 | Launchpad bug 904963 in bzr-git (Ubuntu) "unknown command "commit"" [Undecided,New] https://launchpad.net/bugs/904963 | 21:11 |
| hrw | zyga: mark it as 'affects me' so it will be confirmed? | 21:11 |
| 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:12 |
| hrw | will report | 21:13 |
| hrw | but tomorrow | 21:14 |
| hrw | have a nice rest of day | 21:14 |
| zyga | hrw, you got it backwards | 22:08 |
| zyga | :-) | 22:08 |
| zyga | hrw, looks promising | 22:08 |
| hrw | zyga: ? | 22:16 |
| zyga | hrw, sorry, was reading backlog | 22:21 |
| zyga | hrw, I too hope for git with bzr workflow | 22:21 |
| Noldorin | hi poolie | 22:22 |
| Noldorin | you around at present? | 22:22 |
| 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:37 |
| 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:38 |
| jelmer | though BZR_DISABLE_PLUGINS should work.. | 22:39 |
| SpamapS | Yeah I'm a bit confused. :-P | 22:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| SpamapS | much better | 22:43 |
| SpamapS | usually its *awesome* | 22:43 |
| SpamapS | but this time.. it was just #$@!ing things up :) | 22:43 |
| jelmer | SpamapS: thanks, glad to know it's useful :-) | 22:47 |
| jelmer | SpamapS: bug 842144 | 22:47 |
| ubot5 | Launchpad bug 842144 in python-debian (Ubuntu) "bzr crashed with ValueError in _set_full_version(): Invalid version string '2.0.37+cvs.JCW_PRE2_2037-1'" [Medium,Triaged] https://launchpad.net/bugs/842144 | 22:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| Noldorin | oh | 22:51 |
| Noldorin | poolie suggested it was more doable than that | 22:51 |
| Noldorin | hmm | 22:51 |
| Noldorin | oh well | 22:51 |
| 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:52 |
| jelmer | Noldorin: right, but I don't think a lot of people actually run their own launchpad instance | 22:53 |
| 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 | 22:54 |
| 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:34 |
| spiv | bzr viz | 23:35 |
| coventry | Terrific, thank you. | 23:35 |
| spiv | Or 'bzr qlog' if you have the qbzr plugin | 23:35 |
| spiv | (Which is probably a bit more polished than bzr-gtk atm) | 23:36 |
| spiv | (Also, I'm pretty sure the invocation has been 'bzr viz' since almost the very beginning of that code!) | 23:37 |
| coventry | Probably I was confused because I was expecting a standalone program like gitk. Thanks again. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!