[00:38] poolie, hey. [00:38] how's progress on bzr 2.5? :-) [00:38] generally [00:39] how can I continue an interrupted cloning of bzr repo? I started with bzr branch lp:calibre but interrupted in between [00:43] nixmaniack, interrupted how exactly? [00:43] ctrl+c? [00:43] process kill? [00:43] Noldorin, ctrl+c [00:44] i want to resume the process from where it stopped [00:44] nixmaniack, yeah, i think that would just fuck it during a branch [00:44] you can try bzr break-lock followed by bzr pull [00:44] that *might* work [00:44] or bzr update even for the 2nd command [00:45] Unfortunately you can't resume an interrupted pull [00:45] bzr update didn't work, it gives me error [00:45] spiv, a branch is like an init followed by a pull no? [00:45] Noldorin: yeah [00:45] bzr: ERROR: No WorkingTree exists for "file:///home .... [00:46] nixmaniack, yeah, so just wipe the directory and start again i say [00:46] don't think there's a better solution sorry [00:46] spiv, why the separate command then? just convenience/semantics, or does it actually do something cleverer? :-) [00:46] Noldorin, i would have to download so much data again! that's why i was trying for other solution [00:47] nixmaniack, yeah, it sucks. you can't exactly blame bzr though. you pressed the keys ;-) [00:47] unlucky, as i said [00:47] (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] 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] (or in increments of 1000, or whatever) [00:48] Noldorin: a bit of both [00:48] Noldorin: but mainly convenience. [00:48] 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] nixmaniack: yes, we agree [00:49] nixmaniack: read and/or subscribe to the bug talking about it :) [00:49] nixmaniack, oh sure, it's a pain. but it's not *that* important to most people [00:50] i've done it before... [00:50] and i'm angry until i realise it was me being silly [00:50] server could go down though [00:50] so in that case :-) [00:50] nixmaniack: also, in many cases the better fix would be to not require the user fetch so much data :) [00:51] nixmaniack: e.g. the shallow branching proposal [00:51] what's that? [00:51] shallow branching [00:51] hello! can anybody give me some help regarding getting a branch with bzr causing extreme network traffic? [00:52] bzr is downloading insanely high amounts of data for "small" stuff ... since i'm on umts internet, that really sucks [00:53] 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] and now being on mobile network i can't afford much traffic! [00:53] mamalala, might want to define what umts is :-P [00:54] Noldorin: mobile internet connection, only 4.something mbits/sec [00:54] ah [00:54] sounds American [00:54] hey that's still faster than 3G :-P [00:54] nah, i'm in germany actually ;) [00:54] or at least the same [00:54] hah [00:54] okay fine [00:54] not British though :-) [00:55] i'd like to grab the sources, doc's and libraries for kicad, and they use bazaar on launchpad [00:55] already got the sources, after hundreds of megabytes of bzr download traffic, for only a handfull of mbytes of actual sourcecode [00:55] so i'm wondering if there is a sane way to get stuff from bazaar? [00:56] mamalala, that's because you grabbed the entire revision history :-P [00:56] 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] mamalala, you probably just want bzr export [00:57] ahh [00:57] for the latest revision, only actual content [00:57] will try that, i'm totally new to that bazaar stuff [00:58] 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] 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] spiv, oh right, interesting. [00:59] spiv, isn't that like a lightweigh checkout? [00:59] 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] mamalala, just bzr export mylocaldir/ lp:... [01:00] Noldorin: yes, but without the need to hit the network for every operation [01:00] hi spiv [01:00] Noldorin: e.g. seeing a diff of what you've changed [01:00] spiv, ah interesting. so more apt for the distributed workflow then :-) [01:00] Noldorin: ah, thanks! i was a bit confused because that branch thingy automatically created a directory [01:00] stupid me ;) [01:00] spiv, what's the diff between --stacked and --lightweight incidentally? [01:01] 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] Noldorin: --stacked is a branch [01:01] Noldorin: so an independent line of development, can have its own commits etc. [01:02] 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] spiv, sounds cool [01:02] 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] spiv, so lightweight checkouts are like the centralised version of stacked branches eh? [01:02] Noldorin: (a bit like shared in that it's a mechanism for multiple things to share one resource for repo data) [01:02] Noldorin: yes [01:03] yeah [01:03] Hey poolie [01:03] 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] spiv, i guess you're working on shallow branching mainly for speed/efficiency reasons then? [01:03] mamalala, yep yep, so export should work fine. let me know if you have luck [01:04] Noldorin: well, it's causing some traffic, but not telling me what it actually does ;) [01:04] Noldorin: yes, although it's a natural way to work IMO [01:04] but seems there is a lot of overhead as well [01:04] Noldorin: I usually don't care about the full history of something I want to hack on [01:05] spiv, sure. just the logic is more complex/bug-prone. [01:05] 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] mamalala, sounds like you're doing somethign weird/on a really old version of bzr heh [01:05] 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] Yeah. Although we've already dealt with most of the hard logic, for stacking. [01:06] mamalala, ask the devs. i think you have an edge case though. bzr has always proven efficient for me in such things [01:06] spiv, currently there's no way to do local hacking on a remote branch without pulling the full history, eh? [01:07] so i guess that's the crux [01:07] mamalala: are you branching into a shared repository, or a standalone branch? [01:07] mamalala: there's a known bug with branching into an empty shared repository [01:07] also, hi again poolie. just wanted to update you that i'm planning to start hacking on that LP downloads feature soon.. [01:07] spiv: good question ... i have no idea, i'm not involved in development there or anything ... [01:08] spiv: http://kicad.sourceforge.net/wiki/Downloads [01:08] spiv: that's the stuff i want to grab as sources (see bottom of the page) [01:08] sourceforge offers bzr these days? :O [01:08] 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] 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] spiv, i mean, correct me if i'm wrong about that ^ [01:11] 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] it's one feature really lacking. one of few [01:12] 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] mamalala, well did bzr export not succeed at least? [01:13] Noldorin: i cancelled it now ... [01:13] mamalala, could well be the server that's (temporarily) fucked [01:13] Noldorin: it just sucked up all the bandwidth, and only got about 8 mbytes of data a minute ago [01:14] 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] thats just insane [01:14] 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] mamalala, as i said, fringe case most likely. never heard of that before. either the server, client, or repo is fucked :-P [01:15] i know bzr to be excellent and efficient software in general [01:15] seems you just have the luck now [01:15] heh [01:16] 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] simply -> simple [01:16] mamalala, yeah, i always hate it too when i just want to grab the source but can't do it easily [01:16] Launchpad lets you do it [01:16] but i guess they use a custom host [01:17] which increases the chance their bzr server is messed up too, perhaps [01:17] from what i know they use launchpad [01:17] mamalala, then you can just download the latest revision [01:17] point me to the LP project site [01:17] and i'll tell you [01:17] heh [01:17] hmm [01:19] good idea, if i would know where that project site is on launchpad [01:19] i only have the links on their wiki for use with bazaar [01:20] and that bazaar stuff seems to be on launchpad, since it uses lp:... as address [01:20] already tried to use bzr+ssh://@bazaar.launchpad.net/~kicad.... and that worked as well [01:21] but same slowness as with lp: [01:21] If you're logged in, lp: _is_ bzr+ssh://.... [01:21] already created an account on launchpad for me, added my ssh key, etc... [01:21] fullermd: ok [01:24] 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] At any rate, I wouldn't expect an export from remote to be too speedy. Kinda off the beaten path. [01:25] fullermd: well, i really donÄt care about the speed itself, but the badwidth [01:25] Bandwidth is just the FFT of speed ;> [01:26] fullermd: i only have a 5 gig flatrate on umts, after which it will throttle down to gprs speed [01:26] 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] 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] But to be sure, neither tops the list when you have to count every byte that closely. [01:29] 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] Do your fiddling on a shell server somewhere, maybe? [01:30] alas, no more hacking for today [01:30] night folks [01:30] Or at least could branch there and make yourself a tarball. [01:30] 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] fullermd: unfortunately not [01:31] fullermd: used to have my own server and fixed/static sdsl line in my previous location ... oh well, good old times [01:31] What branch is it you're trying to get? [01:32] fullermd: lp:~kicad-developers/kicad/doc and then lp:~kicad-lib-committers/kicad/library [01:33] 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] And http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/tarball/112 looks like the latest of library. [01:34] fullermd: hey, thanks! how did you derive that download link from that information? [01:35] fullermd: again, thanks a lot! that's very helpfull indeed [01:35] 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] 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] Then there's a 'download tarball' link. [01:36] Then I just manually fiddled with the link to get to the other branch. [01:36] fullermd: oh boy, now i feel really stupid ;-D [01:37] Well, it's Hump Day. Nobody's smart on hump day ;p [01:37] didn't know that there were "real" webpages behind all that as well [01:37] hehe [01:37] That's all (or mostly, anyway) loggerhead. Any branch on LP will have that interface available. [01:38] Or is it loggerhead? I don't really know, I s'pose. Still. It's colored clicky stuff :p [01:39] (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] hmmm, already 85 mbytes downloaded and continuing ... doesn't look well either ... [01:40] ah, just finished [01:40] Could be a big tarball if it's got a bunch of images and such in it. [01:40] ok, that's definitely much less traffic than using bzr [01:40] fullermd: again, many thanks for helping an old stupid chap ;) [01:41] Hey, that's why they pay me the Big Bucks. [01:41] lucky you ;) [01:41] I think I'll put myself in for a 50% bonus just for this conversation, in fact. [01:41] haha [01:42] go for 100% .. [01:42] I don't want to sound greedy. Especially right before christmas. [01:43] ah, great ... got the two tarballs already ... _much_ better than before [01:44] 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] fullermd: i'm with you on that, same here [01:45] maybe i should hope for a "bzr --just-grab-the-damn-tarball" option for christmas :D [01:46] I was thinking of going for world peace. But then what would they put on the news? [01:47] i blame the broadband-effect for such things nowdays. big pipes everywhere makes people forget about caring about bandwidth [01:47] yea, world peace would be nice, but surely won't happen in the next few millenia [01:48] Well, it'll take you that long to run bzr export over your cell, right? ;p [01:48] hahaha [01:48] actually it can get pretty fast, on good days i get about 7 mbit/sec, but on average it's around 4 [01:49] but speed is only half the business if you have to look at traffic usage [01:49] Not too bad. But man, 5 gig disappears faster than you can blink. [01:49] because being dropped down to gprs speed ain't no fun ... 64 kbit/sec [01:49] yeah [01:50] tell me ... when i had the sdsl line, it had a flatrate as well [01:50] 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] Back when I ran ISP's, I had a block of 16 at home. [01:51] 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] hehe [01:51] well, sdsl is a bit different, at least here in germany [01:51] no nat or such crap involved [01:52] you get one ip, and tell them you need more, and then get 8 [01:52] I've got cable with a cap. But I don't get very near it. [01:52] flatrates are the most common stuff here in germany. pretty much everyone has them [01:52] 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] Very bursty usage to get that average, but... [01:53] friend of mine has cable-dsl at home, 50 mbit/sec, fixed ip, for something around 50 euros per month [01:53] I get about 20mbit down. 250 gig cap. [01:53] average dsl here is 8 or 16 mbits for around 30 euro-bucks including flatrate, but no fixed ip [01:54] 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] ahh, 250 gig ... i would be happy if i had 20 or 30 gig included [01:54] 5 gigs is really borderline [01:55] oh well ... [01:55] Yeah, I'd hit that in about 3 days of my usage. [01:55] Maybe a little less, since that figure is just downstream. But my upstream is a lot smaller anyway. [01:55] 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] 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] Luckily, all my MUD data is compressed. [01:58] 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] 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] I especially love them, since I don't have flash. [01:59] hehe [01:59] Gives me a nice quick warning that the site is stupid and not worth bothering with. [01:59] true [02:00] well, i have flash installed, because some customers want to show me their latest-and-greatest... [02:01] I get that from time to time. I tell them "Yes, that's a pretty big white box". [02:01] 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] 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] fullermd: again, many thanks for the help! i could send you a sixpack of nice, tasty german beer if you like :D [02:04] I'm sure that would be highly illegal. [02:04] Therefore, my address is... [02:04] hehe [02:06] 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] ok, i'm off, good night everyone, and thanks again! [02:06] * fullermd waves. [02:06] * mamalala waves back [02:16] hi fullermd [02:17] * fullermd waves at poolie. [02:26] poolie: Out of curiosity, _is_ that "download a tarball" part of loggerhead proper, or something LP adds? [02:26] it's in lh trunk [02:26] Shiny. [02:26] in fact one of the remaining things to do is to add a direct link to it from the main lp ui === r0bby is now known as robbyoconnor [06:39] happy un-morning [07:30] hey guys [07:36] hey vila... bus soon [07:36] as in: see you in the bus ??? /me confused [07:36] :) [07:39] as in, I need to catch it :) [08:32] wgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ? [08:35] morning! [08:37] mgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ? [08:37] and re-hi by the way ;) [08:41] vila: don't think I touched that path, as debian.changelog is in charge there and doing the right thing [08:41] (debian policy states that changelogs are utf-8, if a package has other random bytes in there it's borked) [08:42] hmm, ok, I'll need to dig deeper then [08:42] I encounter this while running mass_import locally so I may need to upgrade some packages (I'm running oneiric though) [08:42] it's a likely failure from a package with a bad changelog [08:44] if you can pdb in there and go up, will be easy enough to find the part debian.changelog doesn't like [08:45] 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] ...I need to fix my news anyway, will reorder at same time [08:46] which bit are you looking at? [08:48] fixed, in my proposal for bug #904550 [08:48] Launchpad bug 904550 in Bazaar "gpg signing key doesn't default to 'email' anymore" [Critical,In progress] https://launchpad.net/bugs/904550 [08:48] ...now that needs to land before I can fix my news? :) [08:49] mgz: won't be enough, you'll also need pqm patch from jelmer for 2.5-compat [08:50] ah, or pqm won't let anything through at all? [08:51] pqm-submit will crash, see bug comments [08:51] hmm [08:51] 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] 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] mgz: weird, that same import succeeded on jubany :-/ [09:57] vila: likely it has a different version of python-debian [09:58] I have 0.1.18 which does not fall over in a bunch of cases newer versions do [09:59] you mean it's a regression in python-debian ? [09:59] it's a behaviour change [09:59] 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] this is complicated by the fact the tools don't make an effort to raise sane errors [10:01] 0.1.14ubunt2 on jubany, 0.1.20ubuntu2 locally :-( [10:02] ^s/thing/think/ obviously [10:02] ThingPad [10:04] I don't skip the importer can afford to skip versions :-/ [10:12] meh, we both have trouble with think this morning... s/skip/think/ [10:15] trying with a dirty hack: force latin_1 when UnicodeDecodeError is encountered :-{ [10:17] I never thought I'd say this, but using bzrlib.tests.TestCase feels kind of primitive [10:19] jml: don't do that then :) [10:19] vila: I don't want to add another dependency to udd in this branch. [10:19] using bzrlib.tests.TestCase means you already depend on testtools... [10:21] mgz: what do you know about the debian/changelog encodings ? [10:22] mgz: as in: what is/was allowed, what is/was used ? [10:22] vila: in historical revisions, pretty much anything is used [10:23] jelmer: oh hi ! [10:23] IIRC now the recommendation is to use utf8, but I'm not sure if that's a recommendation or mandatory [10:23] mgz: oh really? [10:23] 'morning vila [10:23] [10:23] jelmer: with recent versions of python-debian, latin_1 is used in once case and breaks import_dsc [10:24] vila: it uses chardet I think [10:24] handy! [10:24] huh, what's charder ? [10:24] det [10:24] it's manditory now, but historically there wasn't any guidance and people can still accidentally do the wrong thing [10:24] vila: uses heuristics to determine the relevant encoding [10:24] mgz, vila: what version of testtools is on production? [10:24] jelmer: ha, exactly what I was going to suggest, so what is chardet, a package ? [10:25] >>> testtools.__version__ [10:25] (0, 9, 6, 'final', 0) [10:25] 0.9.6-0~bazaar1.0.IS.8.0 [10:25] 0.9.6-0~bazaar1.0.IS.8.04 [10:25] thanks! [10:26] damn mouse [10:26] chardet is a bad idea, and you'd need to change debian.changelog which wouldn't really help the now [10:26] encodings aren't the only way parsing a changelog can fail either [10:26] mgz: no, changelog can be provided with a unicode string so we can handle that [10:26] if builddeb relies on sane package metadata, and the package metadata is borked, something has to give [10:27] I need to get on the case wrt packaging [10:27] using 0.9.6 is almost criminal neglect. [10:27] vila: yes, python-chardet [10:27] mgz,jelmer : the question is: what do we really need out of the changelog ? [10:27] chardet *probably* gets utf-8 right, but adds a lot of overhead and is a heuristic [10:28] so, can flip flop depending on content [10:28] the case at hand is an author with an latin_1 encoded name [10:28] we're better off catching errors from places that need to parse changelogs and gracefully handling borked ones [10:29] yeah, with gracefully including: try again with a working encoding that can be as fine-grained as a line [10:29] 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] 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] and note that ChangeLog() accepts an encoding parameter [10:31] 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] you need to also not break older python-debian versions that had completely different handling [10:33] isn't python-debian supposed to handle this stuff for us though? What version of it is on jubany? [10:33] it's an older and more reliable version on jubany :) [10:34] jelmer: a version that doesn't break, but the oneiric one I'm testing with locally breaks [10:34] hmm [10:34] I would argue we should fix python-debian instead, rather than trying to work around it [10:34] __init__(self, file=None, max_blocks=None, allow_empty_author=False, strict=True) [10:35] Set up the Changelog for use. file is the contects of the changelog. [10:35] you see something different I guess vila? [10:35] file can be a string, unicode or iterator [10:36] I see an additional encoding='utf-8' [10:36] ah, right, but not if you want it to work across versions :) [10:37] passing unicoded containing non-ascii here will die. [10:37] I want it to work across versions, [10:37] -s [10:37] argh [10:37] err, yes [10:37] passing bytestrings containing non-utf8 on newer versions will die. [10:37] yes [10:37] with a UnicodeDecodeError [10:37] ...can possibly sniff and work around, I did that in bzr-builder already [10:38] catching it and re-trying with an appropriate encoding is worth a try, if it's still fail... so be it [10:54] s//it still fails/ [10:55] trying now with 瑨灴⼺瀯獡整甮畢瑮⹵潣⽭㜷㤰㜹 [10:56] ghaa, the irony :) [10:57] that was http://paste.ubuntu.com/770997/ with some facetious gremlin in the loop [10:57] no, that's bad, you can't pass unicode unconditionally [10:58] you cann fall back to passing unicode, or trying to pass a different encoding name [10:59] can't pass an encoding name for compatibility with old versions, why can't I pass unicode ? [10:59] because the old versions treat what you pass in as a byte string [11:00] basestring [11:00] or an iterator [11:01] at least with the lucid and oneiric versions under my eyes [11:04] it depends how the changelog is used, for instance... [11:05] >>> str(cb) [11:05] Traceback (most recent call last): [11:05] File "", line 1, in [11:05] File "/usr/lib/pymodules/python2.6/debian/changelog.py", line 437, in __str__ [11:05] cl += str(block) [11:05] UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 1332: ordinal not in range(128) [11:05] if you need to write it back out again, it dies. [11:05] if you just need to inspect you might be able to get away with it [11:10] 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] yeah, looking now [11:11] most of the logic is in util [11:13] there's also other Changelog creating function there [11:15] bah, s/max_blocks=False/max_blocks=None/ most stooped tyop ever [11:17] all the code looks like it's doing enough hoop jumping with the values it's taking out [11:18] okay, so I think the safest, but maybe not the best thing, [11:18] would be to always decode from utf-8 where possible as you are [11:19] fall back as needed, [11:19] then re-encode to utf-8 for the older versions [11:21] err, not decode at all for older versions you mean (for that last part) ? [11:22] bah, may be too much, I don't think the parsed content is ever used to re-generate the changelog [11:22] jelmer: two things, [11:23] 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] jelmer: I have a dirty patch (gee, that's my dirty day ;) for bzr log -r bzr-2.5b3..bzr-2.5b4 [11:23] I almost forgot it [11:23] vila: see 'safe'_decode at the top of bzr-builddeb [11:24] it does basically your logic already, but expecting bytestrings back from Changelog attributes [11:24] ECONTEXT top of what ? [11:25]