[00:00] Cool, I've never had anything destroyed by customs before. :D [00:01] Peng_, I'll make sure to not send any live animals in it [00:01] canonical t-shirts have successfully got past nz biosecurity [00:03] which is probably about the strictest border control going [00:03] mwhudson: which one was problematic ? I don't recall having pushed anything large recently [00:04] jelmer: not sure, perhaps i'm being over the top [00:04] jelmer: the openoffice ones certainly did, but they're disabled now [00:05] What sizes are the t-shirts? Some strange, foreign measurement system that I've never heard of? [00:06] mwhudson: I think the second largest one I've pushed so far would be samba, which is ~50k [00:06] (Hey, I may not know anything about foreign countries, but at least I know they exist! :P ) [00:06] jelmer: hm, i'd hope that would work [00:06] jelmer: ah, maybe not on prod actually [00:07] Peng_, they're measured en em's [00:09] I wonder what my waist size is in ems? [00:09] ...I wonder what it is in inches or centimeters? [00:10] Peng_, of course, I was kidding [00:10] s/m/l/xl? [00:10] hi! I have a working dir that I started from scratch and now I'd like make its history look like if it would have been started off from another branch [00:10] Peng_, http://shop.canonical.com/product_info.php?products_id=399&osCsid=deb8dc669413edbef04a27d04685add7 [00:10] see size charts [00:10] I've tried bzr-rebase, but only to have the other pulled and completely overwriting the new one [00:10] any suggestions? [00:12] * servilio notes that it is his first time using rebase, so it might easily be that he's used it wrongly [00:12] Cue Firefox freezing. Argh. [00:19] beuno: XL, I guess. Can you steal my address from my Canonical Store account? [00:19] (Actually, if you could, that'd probably be a huge privacy violation... :P ) [00:20] Peng_: beuno can't. A sysadmin could; you should file a question asking them to give him the address :) [00:20] Peng_: or... you could just tell beuno [00:20] :D [00:20] Hmm, which of those is less typing? If the question was really terse... [00:20] yo, give bueno moi address [00:22] beuno: Normal lp:~beuno email address? [00:23] You can't see the sizing chart without logging in. :\ === arjenAU2 is now known as arjenAU [00:33] Peng_, got it, thanks [00:34] beuno: ok :) [00:52] hi all [00:52] * igc off to the dentist - bbl [00:52] jam: let me know when you pass the token [01:23] jam: ping [01:49] mwhudson: btw, is it right that the API doesn't support removing branches yet? [01:49] mwhudson: (I'm interested in cleaning up all those broken mirrored branches at some point) [01:53] jelmer: yes, the api doesn't yet support removing branches [01:53] jelmer: file a bug please :) [01:53] jelmer: tag with "api", kthxbye [02:23] poolie: I can hack if you need me to try something [02:26] jelmer: what are the urls for samba, both git an dbzr ? [02:45] back [02:50] jelmer: jeeeeelmer [03:06] This branch may be out of date, as Launchpad was not able to access it 21 minutes ago. (Not a branch: "http://bazaar-vcs.org/bzr/bzr.1.15/".) Launchpad will try again shortly. [03:06] BasicOSX: I don't think it has been created [03:07] BasicOSX: poolie asked in a company channel a couple of weeks back, I think noone actioned. [03:07] ok, I'll wait, just anxious to work on it [03:07] poolie: btw, when asking for a branch; if you don't get an ACK from a LOSA, the process is - file an RT [03:07] i know [03:07] i thought i did [03:07] BasicOSX: we'll look at getting 1.15 on lp natively; that will need losa support, and I've started the discussion now. [03:07] it may be just a typo, hold on [03:07] hello BasicOSX [03:08] hello poolie [03:08] lifeless: could this just be the quirk that it doesn't push til the first commit? [03:08] spm^^ does the pqm 1.15 branch exist? [03:08] poolie: the instructions for making a branch for pqm include a manual push [03:09] poolie: it has been made actually [03:09] poolie: but it will be very out of date [03:09] i don't see it in http://bazaar-vcs.org/bzr/ [03:09] yah [03:10] do you want it made this far ahead of the rc? [03:10] 2 days? sure [03:10] especially considering for spm there's only 1.5 working days until the rc [03:10] even less depending on travel [03:10] spm: might like to update the docs, insofar as its make, setup config, and push once ;) [03:10] updating docs is good. doing. [03:11] spm: its a manual push as there isn't a default push location [03:11] e.g. [03:11] bzr info ../1.14 [03:11] copy, paste, change 1.14->1.15, bzr push [03:11] (which I've just done) [03:11] ta [03:12] BasicOSX: its all there [03:12] we'll do native lp for 1.16/2.0 [03:13] Should be able to get via lp or http? [03:13] lp will need to try again [03:13] http://bazaar-vcs.org/bzr/bzr.1.15 for now [03:13] lifeless: that push was to escu I assume. verifying. [03:13] spm: look in pqm's bash history [03:13] spm: it was litteraly [03:13] bzr info ../1.14 [03:14] bzr push (copied and adjusted url) [03:14] awesome. perfect, ta. [03:14] thanks spm [03:20] lifeless: so is my bug a dupe? and being fixed? [03:21] thumper: have you donethe test ? [03:21] lifeless: yes, and added comments to the bug [03:21] lifeless: bug mail is delayed... [03:21] lifeless: I thought it would have gone out by now [03:21] :-| [03:21] thumper: which? [03:23] poolie1: which what? which bug? bug 376287 [03:23] Launchpad bug 376287 in bzr "branch fails with "bzr: ERROR: The branch ... has no revision None."" [High,New] https://launchpad.net/bugs/376287 [03:25] bug 376255 [03:25] Launchpad bug 376255 in bzr "smart server, new branch, ghosts, boom." [Critical,Confirmed] https://launchpad.net/bugs/376255 [03:25] is what I think it may be a dup of [03:25] or at least very close [03:27] lifeless: but the smart server isn't being used between two local directories is it? [03:27] thumper: same code path can be [03:28] ok === photon is now known as Guest52575 [03:57] jam: ping [03:58] hey lifeless, I just saw your earlier request. [03:58] I'm sorry to say I didn't get to presentations. [03:58] We had the power go out last night [03:58] ok [03:58] and I didn't have internet for half the day [03:58] I'll carry on then [03:58] jam: was just blocked until I got the token back [03:58] Please push them up somewhere and I'll be happy to focus on them tomorrow [03:58] And if you sent me an email... I didn't get it [03:58] jam: I did; its in mail to you from yesterday [03:58] problem with hosting your own... [03:59] I'll send another one when I finish up with them today [03:59] lifeless: yeah, no mail from 12am => 6am [03:59] and then down again 9:30 => 12 [03:59] jam: it'll be queued somewhere. I sent to jam@c.c [03:59] lifeless: right, my queue hasn't all flushed yet [03:59] jam: anyhow, look for a mail from me tomorrow; as I'm grabbing the lock now :) [04:00] Yeah, the power going out was pretty flukish, but it really messed up the day [04:01] of course, it didn't help that when the internet went out it took them 1.5 hours to realize it was an site-wide effect [04:12] * igc lunch [05:21] does bzr use "pyftpdlib"? [05:21] we use the stdlib ftp client [05:21] and medusa as a test servere [05:23] bugs.debian.org/528602 [05:29] :!grep -n pyftp bzrlib/transport/ftp/* /dev/null 2>&1| tee /tmp/v308109/0 [05:29] [05:29] I'd query it [05:56] bah [05:56] bzr takes way [05:56] too much memory when adding large files [05:56] or rather when committing large files for the first time [05:56] Keeps biting me since I tend to work with large media files on a regular basis (1 GB + HD files) [05:56] :( [05:56] jfroy: :( [05:57] it's at 2 GB real ATM [05:57] >.> [05:59] is there any hope of addressing that in the future? [06:00] yes [06:00] or it is a design necessity and someone need to slap me for versioning large binary files? [06:00] but for a trivial answer, split and join your files yourself ;) [06:01] yeah well if I split those files they won't work anymore :p [06:01] 'and join' :) [06:02] jfroy: you didn't ask if there was any hope of $whatever being addressed in the _near_ future... [06:02] thought: could use a fancy content filter to auto-split and auto-unsplit stuff [06:03] content filter api is probably not powerful enough [06:03] but yes, broadly; and patches to make such a thing would be good [06:03] :( [06:03] I wouldn't even know where to start looking :| [07:06] thumper: try lp:~lifeless/bzr/repo-source [07:15] lifeless: do I need to build extensions? [07:15] no [07:15] lifeless: just branch and try? [07:15] but you should [07:15] how? [07:15] yah [07:15] make [07:15] you need python-dev and zlib1g-dev packages installed === herb__ is now known as herb [07:16] pyrex? [07:16] python-pyrex [07:18] bbs, caving in and having a pastry [07:21] hi all [07:22] lifeless: branch that with 1.15dev I got AbsentContentFactory :( [07:22] branching from it ? [07:23] lifeless: object has no attribute get_bytes_as [07:23] yes [07:23] well, cbranch, but yes [07:23] so pushing worked but the result is broken ? [07:24] lifeless: I got the error getting your bzr branch from launchpad :( [07:24] thumper: very interesting [07:24] thumper: you have a broken bzr in production, is what that means [07:25] lifeless: it is 1.14.1 + patches that you got mwhudson to do [07:25] yes [07:25] so... [07:25] now what? [07:25] clearly thats not quite enough [07:25] clearly [07:26] it would be nice if my bundle was not deleted when I send to merge@... [07:26] lifeless: it isn't [07:26] its not in the mail that gets sent out [07:26] lifeless: it is in the librarian [07:26] well [07:26] branch bzr.dev [07:26] all incoming email is stored [07:26] and pull from the bundle [07:26] and you'll have a working bzr to test with [07:27] the email is stored, but not really accessible [07:27] so [07:27] I'm updating my trunk [07:27] I mean 'people should get the bundle I send' [07:27] to be precise [07:27] and I'll try again to see if it matters [07:27] lifeless: interesting idea [07:28] with BB I would mail the list [07:28] and people get my original signed email [07:28] BB then send out additional data [07:28] I quite liked that [07:31] really fooding now [08:09] https://code.edge.launchpad.net/~lifeless/+junk/bbctest [08:14] bbc = brisbane something core? [08:15] hah, poor lp doesn't like that branch [08:18] yes [08:18] https://bugs.edge.launchpad.net/launchpad-code/+bug/376255 [08:18] Ubuntu bug 376255 in bzr "CHK stream source doesn't handle ghosts." [Critical,Confirmed] [08:21] mwhudson: ^ [08:37] poolie: can you review my patch for bug 376255 [08:37] Launchpad bug 376255 in bzr "CHK stream source doesn't handle ghosts." [Critical,Confirmed] https://launchpad.net/bugs/376255 [08:37] poolie: I'll send it in tonight if you do, if looks sane to you [08:38] lifeless: i'll try [08:38] lifeless: are you talking in barcelona? [08:38] more than usual i mean :) [08:38] poolie: 3 times [08:38] of course you are, you told me you're preparing them [08:41] poolie: I did:) [09:01] poolie: /wave, done for day modulo adhoc chats and submitting that branch if you ok it [09:01] i'll looknow [09:01] was talking to vila [09:17] bob2: BBC == BrisBane Core [09:17] bob2: BC was already taken [09:29] i kind of wish you'd just spell it out [09:29] having one name was meant to avoid confusion, not invite new names === knielsen_ is now known as knielsen [09:32] poolie: when creating a test branch, abbreviations will be used, by nearly everyone [09:32] I do use brisbane-core for tags and other things ;) [09:33] yeah, the branch name that provoked bob's question was not a good example [09:35] :) [09:44] lifeless: review done, effectively a 'tweak' [09:44] and i already filed last week the bug asking for a 'tweak' status [09:53] * igc dinner [09:55] hi igc [09:55] night [10:03] hi poolie. first cut at smarter upgrades just pushed to lp btw [10:03] hope to clean-up & submit for review tonight or tomorrow [10:04] poolie: also, branch making commit FILE 4x faster on dev6-rr pushed for review last night [10:04] nice one [10:04] ones :) [10:04] * igc ready heads for dinner now [10:04] really [10:04] hello everyone. For one of my project, instead of having one branch for the whole thing, I split it into a branch per component, figuring that would be smarter. [10:05] igc: one thing that would be really useful would be a pack() after an upgrade to rr6 [10:05] I have by now concluded that it's not so smart after all, and would like to unify all those branches into one ? Are there tools/ways to do that, without losing the history ? [10:09] So, to summarize, what I'm looking for is a way or tool, to go from many branches with no common ancestor to one branch, without losing the history. So kinda of a "repo merge" operation. [10:10] anyone knows of such a thing ? :) [10:11] branch, not repo [10:16] bob2: well, I didn't want someone to tell to go for "bzr merge" :) so i figured branch might be confusing. [10:28] flo_hns: merge-into [10:29] lifeless: ah awesome, looks like what I need. thanks! === arjenAU2 is now known as arjenAU === fta_ is now known as fta [13:36] lifeless: man, that pack is taking long [13:51] I have a problem trying to pqm-submit a branch on launchpad, after asking for the gpg passphrase bzr just hangs [14:10] jelmer: you're doing it local right ? [14:13] jelmer: do you have the C extensions build ? === nekohayo_ is now known as nekohayo [14:24] lifeless: yes; no [14:24] lifeless: no python-dev on target machine [14:26] lifeless: done [15:06] jelmer: It would be nice to get it repacked with the C extensions [15:06] jelmer: I'm pulling a copy myself to test [15:07] jam: fetch from a non-optimal-packed bbc branch over VFS is _painful_. Something we might want to address before 2.0 [15:07] jam: one readv per revision painful [15:07] lifeless: well, given that it is what, 2-40x larger? [15:07] lifeless: so I've written code to "batch up" groups [15:07] it is just the eternal question between [15:07] how much do you batch [15:07] and when do you issue the request [15:07] sure [15:07] by *not* batching, we avoid holding the whole repo in memory [15:07] lifeless: this branch is also on launchpad, but disabled I think because of size issues [15:07] we have reasonable asnwers though [15:07] e.g. 64KB [15:07] lifeless: actually, the batching was a large win for stuff like 'bzr ls' because it had to hit a lot of tiny groups [15:07] jelmer: yes, it was 1.5GB :P [15:07] jam: I must sleep, was just finishing off a little personal hacking when you happened by ;) [15:07] 23:40 here [15:07] sure [15:07] sleep well [15:07] g'night lifeless [15:07] lifeless: argh.... 'bzr push lp:...' AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as' [15:07] I sent you a couple of mails too, largely content free :P [15:07] when should I be using str.decode("utf-8") and when osutils.decode_utf8() ? [15:07] pushing up a non-stacked branch, as the project doesn't have any development focus yet [15:07] jam: it has ghosts [15:07] jam: updated your bzr [15:07] * lifeless is gone [15:07] well, this is 4359 [15:08] jam: ^ [15:08] way to old you need 4362 or so [15:08] jelmer: my copy of osutils doesn't have decode_utf8 [15:08] jam: sorry, I mean cache_utf8.decode [15:08] jelmer: I would generally use .decode('utf-8'). cache_utf8.decode will shove the unicode and str objects into dicts [15:08] so as to 'de-dupe' them later [15:08] jam: https://code.edge.launchpad.net/~lifeless/bzr/repo-source. [15:08] * lifeless is gone [15:24] hah, the maintenance of http://bazaar-vcs.org/ is returning html when bzr looks for the bzrdir format on http://bazaar-vcs.org/bzr/bzr.dev === thunderstruck is now known as gnomefreak [16:14] LarstiQ: yep, just ran into that myself [16:15] It seems bzr is about 3 revs old in Launchpad [16:15] Fortunately, I get to cheat [16:15] and I can connect directly to the host via bzr+ssh :) [16:15] tsk :) [16:17] that said, even with Robert's fix, 'bzr push' fails for this branch unless I do 'nosmart+' [16:24] is the most recent bzr.dev available via a smart protocol? [16:24] for the general public [16:27] jam: hi [16:28] hey bialix [16:28] LarstiQ: no, I just have SSH access to that machine [16:28] does merging through pqm still the same as year ago? [16:28] bialix: yep [16:30] I can submit if you prefer [16:30] I know there is also some maintenance going on, though I don't think it effects pqm right now [16:30] jam: please do [16:30] jam: I think your latest note should be tweak [16:30] if you'll send merge request, can you tweak, please? [16:30] sure [16:30] jone more question [16:30] s/jone/one/ [16:30] bialix meant: one more question [16:30] well, it depended on whether we actually wanted to do the change or not, I left it open for you to decide [16:30] jam: it was premature optimisation [16:30] Tak: are you a bot? [16:31] s/you/running/ [16:31] LarstiQ meant: Tak: are running a bot? [16:31] nice [16:31] Tak: teach me English please [16:31] s/s/&/ [16:32] hmm, I hope that didn't cause an infinite loop [16:32] jam: my patch for unicode cmdline: it will be in next bzr 1.16? [16:33] bialix: well, 1.15, yes [16:33] ah, even so [16:33] that's nice to have in rc1. more people will test it [16:35] today we have a question in ru-bzr about diff headers and non-ascii filenames [16:35] the problem is: diff headers encode filenames as utf-8 [16:36] this is very bad for windows console [16:36] I remember we discussed it in the past [16:36] there is no right choice here [16:37] I'm thinking about adding special command-line option, e.g. --header-encoding, to force diff header show filenames in other encoding (oher than utf-8) [16:37] jam: ^ [16:37] bialix: so the code to fix that sort of thing is rather involved [16:37] It required changing 3-4 layers to pass around a 'path_encoding' parameter [16:37] wdym? [16:37] oops [16:37] does it will affect merge directives? [16:37] The place where we would know the output encoding [16:38] is it will be major API break? [16:38] argh [16:38] then has to pass that down through about 4 layers to actually get that value set to the code that writes to the screen [16:38] Tak: ?? [16:38] sorry, I didn't mean for the regex script to be running in this channel [16:38] LarstiQ: what is s/s/&? [16:39] or is it just that you were regexing a regex? [16:41] :-D [16:41] bialix: It isn't a "major" break, but a minor one, and tracking down all the cases was ugly enough I didn't continue to persue it a while ago [16:41] jam: s/prefix/& append/ [16:41] jam: and indeed, the s was an attempt to regex the regex :) [16:41] jam: and this change also affects log -p IIUC [16:42] I'm not sure about merge directoves [16:42] directives [16:42] bialix: if we had support to pass a value for path encoding [16:42] we can just make sure that merge directives pass utf-8 there [16:42] one thing that bothers me is behavior of GNU diff (from gnuwin32.sf.net). It emits filenames in user_encoding [16:43] bialix: I'm pretty sure GNU diff emits everything in OEM encoding [16:45] so Unicode names aren't guaranteed to work [16:45] jam: no [16:45] what do you get for: "diff Тест جوجو" ? [16:45] My very strong guess is that 'GNU diff' thinks of filenames as pure 8-bit octets [16:45] and if OEM encoding can't handle a given Unicode filename [16:45] it just fails [16:45] since it can't *read* the file [16:45] (on my platform, both of those would show up as ???? ????, and I don't have a filename named ????) [16:45] I could certainly be wrong [16:46] jam: I've got nothing [16:46] I'll try to create Arabic filename first [16:48] bialix: Explorer should handle it fine [16:50] C:\Temp\2>diff -u Тест جوجو.txt [16:50] diff: ????.txt: Invalid argument [16:50] bialix: yep [16:50] GNU diff does not handle pure unicode [16:50] bialix: right, so if you don't deal with unicode ,then you just write the 8-bit string that you read, back onto the wire [16:50] which is generally OEM encoding [16:50] IIRC [16:50] it doesn't specifically matter what it is [16:50] but [16:50] C:\Temp\2>diff -u Тест Тест2 [16:50] --- Тест 2009-05-14 18:44:25.953125000 +0300 [16:50] +++ Тест2 2009-05-14 18:44:38.734375000 +0300 [16:50] @@ -1 +1 @@ [16:50] -foo [16:50] +bar [16:50] filenames in cp1251 [16:50] bialix: Is this on Russian windows? [16:50] no [16:50] it's on English netbook [16:50] LarstiQ: it disallows that :-P [16:51] but with Russian settings [16:52] bialix: http://www.eggheadcafe.com/conversation.aspx?messageid=33050149&threadid=33050144 [16:55] If an application is compiled for ANSI API, then the filenames will be recoded to/from current codepage. [16:55] Which means, try doing "chcp 437" [16:55] and see if 'diff' continues to work [16:55] yes, it works [16:55] C:\Temp\2>diff -u Тест Тест2 [16:55] --- ╥σ±≥ 2009-05-14 18:44:25.953125000 +0300 [16:55] +++ ╥σ±≥2 2009-05-14 18:44:38.734375000 +0300 [16:55] @@ -1 +1 @@ [16:55] -foo [16:55] +bar [16:55]