[00:00] i see. i'm trying to map git concepts onto bzr. [00:02] how do i copy a repository with all of the associated history a la ``git clone''? [00:02] ayan: i'd use tar, probably [00:03] ayan: but usually, it's not necessary [00:03] ayan: just use 'bzr clone' to get the branch you want [00:03] okay, thanks. off to rtfm harder. :) [00:21] hi jelmer, all [01:01] Good morning. [01:21] Hi, I need a help here with osx bazaar: I'm running bazaar explorer and I'm getting the follow error when I try to open Settings > Configuration > User Configuration : [01:21] QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory [01:21] QFileSystemWatcher: failed to add paths: /Users/mj/.bazaar/bazaar.conf [01:21] Please, how can I fix it? [01:25] Does /Users/mj/.bazaar/bazaar.conf exist? [01:27] maxb: no. But I creat a file ( touch ~/.bazaar/bazaar.conf) and the error stops, but nothing happens [01:40] mangojambo: Ok, that sounds fairly likely [01:41] This means that the "errors" you posted are not errors, but just informational notes, and the real problem is something else [01:43] so, how can I fix it, or just access user configuration to set my user, email, etc ? [01:46] I'm afraid I don't know enough about qbzr to suggest what the problem might be [01:56] maxb: ok, thanks man. I will keep trying here. [01:56] seeya [02:06] hi spiv [02:06] apparently search on the bzr web site is broken so i'm going to try to fix that now [02:06] then do something about stale locks [02:06] i hope you got back eventually [02:07] and apparently i'm the pilot === poolie_ changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out [02:07] Yes, I did get back eventually! Very back row of the plane, but that arrives very shortly after the front so it was ok ;) [02:07] :) [02:08] slower exit, but greater survivability [02:08] Plus I got to watch the rest of the neverending press conference. [02:08] everyone can have 30 minutes of fame if they ramble enough [02:08] And the gradually increasing groans and eyerolls from the people watching it waiting for the result. [02:09] The mood towards rambling could be summarised as: "don't they know some people have planes to catch?" [02:09] hahah [02:10] As soon as the key bit arrived the suddenly 2/3rds of the people hanging around disappeared, or at least it felt like that. [02:18] spiv: do you know why spawnProcess seems to return a 'Process' object that doesn't claim to implement IProcessTransport (though spawnProcess claims to return that type?) [02:19] jam: sounds like a bug (in either docs or implementation...) [02:19] jam: on windwos? [02:19] spiv: PosixReactorBase [02:20] spiv: twisted/internet/interfaces.py says thait IReactorProcess returns IProcessTransport [02:20] So the default reactor (select)? [02:20] PosixReactorBase returns internet.process.Process directly [02:21] spiv: I don't really know, but IOCPReactor does the same thing [02:21] spiv: I'm trying to replace a spawnProcess call with my own stuff, but the details are a bit.. hazy [02:21] Well, Process is supposed to implement that IIRC [02:21] Certainly twisted.internet._dumbwin32proc.Process does [02:22] spiv: well, I can't find it saying "implements()" === poolie_ is now known as poolie [02:22] hello jam [02:22] spiv: right, that is the only thing that *does* implement it [02:22] hi poolie [02:22] * jam is digging into twisted internals right now [02:22] jam: please file a bug [02:22] which isn't a whole lot of fun, but doesn't seem too bad [02:22] jam: I think it's just missing the implements declaration [02:22] spiv: so my concern is whether implementing the minimal IProcessTransport will be enough [02:23] jam: AFAICS it does actually satisfy that contract [02:23] spiv: Process probably does [02:23] jam, is this because the reviewers really wanted twisted rather than otherwise? [02:23] *I* don't know if I need to implement more [02:23] or because you need to fix the conch server? [02:23] poolie: the ssh daemon is a Twisted process [02:23] poolie: right [02:24] I need to connect up the ssh incoming with the spawned process [02:24] IProcessTransport is pretty minimal, so it shouldn't be too bad [02:24] the concern is that it also seems intermingled with IProcessProtocol [02:24] and that is a much larger api [02:25] spiv: for example, I don't think spawnProcess calls transport.makeConnection(proto) [02:25] though I'm still wrapping my head around everythingf [02:25] Process.__init__ does that [02:25] IIRC [02:26] spiv: yeah, in a try/except: loop, no less [02:26] (bare except) [02:27] I didn't see it originally because __init__ is quite long [02:27] I *did* see it in the win32 one, and was trying to reconcile that [02:27] (I wonder if it would be clearer if ProcessProtocol didn't implement IProtocol, and instead was explicitly adapted...) [02:27] I'm thinking about inheriting from one of the classes in the Process stack, to get some of the file handle polling stuff [02:28] * jam doesn't really know what IProtocol is, or where Protocol is different from something else [02:28] spiv: and the docstring for IProcessTransport is: A process transport. [02:28] I think if you are trying to inherit from Process for anything other than implementing a new reactor you're probably not gelling with Twisted well. [02:28] which is *mighty* helpful [02:28] Well, it's the transport for a process! :) [02:29] Very true [02:29] IProtocol is very slim, take a look at it. [02:29] spiv: so I'm spawning a process outside of the current process and connecting to it [02:30] which is ~ a subclass of Process [02:30] I have pipes to read / write to [02:30] I have a PID [02:30] etc [02:30] it is a good fit for IProcessTransport [02:30] Just thinking of network services for a moment, Twisted has "protocols" and "transports": a transport is something like TCP or SSL (or a pipe...) that can convey a bytestream. A protocol is something that can receive a byte stream. [02:30] I also have to manage talking on several file descriptors, etc, which Process already implements [02:30] (and decode it into HTTP request objects or whatever the protocol is) [02:30] I just don't want to call _fork [02:31] I might inherit from BaseProcess, or _BaseProcess (which inherits from BaseProcess oddly enough...) [02:31] A IProcessTransport is a transport with some extra features like pid and the ability to send signals. [02:32] spiv, poolie: Do you know if waiting for a pid that isn't a child just raises an error? [02:32] (I can test it, but I figured I could ask first) [02:34] jam: that sounds like a reasonable fit for IProcessTransport too [02:34] s/that/I think that/ [02:35] spiv: I don't know how to submit bugs to twisted, and probably have to log in [02:35] any chance you could submit one for me? [02:35] Just a simple "internet.process.Process' does not implement IProcessTransport [02:35] (though it is returned by spawnProcess, which claims to return one of those) [02:35] You do need to log in, it's a Trac instance: twistedmatrix.com/trac [02:36] spiv: yeah, I know where it is, but have no user, and it isn't really worth signing up for a 2 line bug report :) [02:36] Ok, but if you're poking at Conch I can almost guarantee you'll have more bugs to file before you're done ;) [02:36] spiv: well, I'm certainly trying to avoid poking at any twisted internals :) [02:39] Why does it seem like committing to a remote bound branch is so much slower than committing locally and then pushing? [02:39] mkanat: it is possible, time it and check [02:39] it pretty much does exactly that internally [02:39] but it is possible there is a different code path [02:40] mkanat: because we're compressing the things to store relative to things stored remotely, maybe? [02:40] poolie: we write it locally, then push, then update the branch pointer [02:40] poolie: That could be. It could also have to do with taking a lock on the remote repo, or something. [02:40] mkanat: also, if there's a difference, getting a -Dhpss log should make it obvious why [02:40] poolie: Okay. [02:40] and/or --lsprof-file foo.callgrind [02:40] anyway, back to family time [02:41] jam i'll try to catch you tomorrow afternoon your time [02:43] jam: http://twistedmatrix.com/trac/ticket/4648 [02:58] i think i'll delete the rendered html from the website branch [02:59] now we can generate it on the server it just seems to be noise [03:06] poolie: Yeah, and probably confusing to anybody who checks it out, if by some chance it ever wasn't up to date with the source. [03:06] We used to store compiled docs along with Bugzilla; we removed them many years ago. It was a good idea. :-) [03:12] ok, and i think site search is working again, can someone test it? [03:49] Hi, is anyone working on the Website? [03:49] i am [03:49] is it broken? [03:49] If so, are there specific requirements for it? I'm playing around with a new layout which moves bzr slightly closer to what git and hg have on their front-page. [03:50] ok [03:50] i think it could certainly be improved and clarified [03:50] do you mean a requirements doc, or technical requirements? [03:50] I.e. a prominent download link fed from Launchpad directly, and two boxes for quick start [03:50] the source is in lp:bzr-website [03:50] that would be gerat [03:51] poolie: Requirements as in what _has_ to be on it, and technical as in lib x must be used [03:51] I don't know if there is some requirement from canonical for instance [03:51] nup, both are negotiable [03:51] whatever makes sense [03:51] Ok [03:51] I assume it should work with Python 2.x? [03:52] yes [03:52] any dependencies for generation should ideally be packaged in ubuntu [03:52] but we can work that out o [03:52] All right, I'll keep on hacking then. As soon as I have some mockup done, I'll be back, but it might take some while. [03:52] also, i think it's nice to keep the current approach of static generation, if possible [03:52] that would be great [03:52] you could post some screenshots or urls to the list, or here [03:53] Sure, as soon as I'm happy with it :) [03:53] I just wanted to check if someone else already works on a redesign for the front-page. [03:55] Please send them to the list, I wanted to tweak the Sphinx template for the documentation to feel more integrated with the website. [03:55] that would be great too [03:55] also to make the wp blog consistent with the site [03:55] anteru: you can look at the canonical design standards for inspiration [03:56] which are probably linked from wiki.ubuntu.com [03:56] uh oh folks :) one at a time, maybe (: [03:56] but we don't have to stick to them [03:57] anteru: I'm putting my hand up to work on the Sphinx template, I just want to see what you're thinking so I head in the same direction. ;) [03:57] actually, I wanted to do some clean-slate CSS3 and modern web design stuff, and as the bazaar frontpage is only a single page, I thought this is a good victim. Especially as it has some problems right now (tiny fonts, too many links, difficult to navigate, outdated content.) [03:58] give me a minute, and I can show you the current hacky state, basically blocking out the layout/content [04:04] quick: screenshot tool for kubuntu? [04:04] got it [04:05] http://img13.imageshack.us/img13/2373/bildschirmfoto1vt.png [04:07] danger: ugly and work-in-progress [04:07] anything which looks remotely fancy is CSS3 shadow/rounded-borders/etc. so the amount of images is kept to a minimum and it should degrade gracefully [04:13] You're right about ugly. :) [04:14] it's work in progress [04:15] I know, I was kidding, you should see my early designs. Actually better if you don't. [04:16] First impressions: better (already) than the existing site. somewhat text-heavy for a front page. shell scripts might scare off those looking for bzr explorer. [04:16] with some more context: http://img84.imageshack.us/img84/6872/bildschirmfoto2q.png [04:17] well, that's why I want to keep the image at the top, then the explanation, then I'll probably add a small breaker with projects currently using it, and then the shell scripts [04:18] it also needs a bit stronger colours IMAO [04:19] but the yellow logo means it will basically only go well with blue, or some orange-looking stuff [04:20] I'd lose those borders, makes it too blocky. [04:20] ok. I'm keeping them for now, as it eases layout a bit [04:21] If you make them a light grey you can still see your layout but get a better feel for what it looks like with just whitespace. [04:22] I'm thinking it would be nice to show both the command line and a close-up of the gui interface. Play to both audiences. [04:22] also need to move it into some grid, right now it's completely ad-hoc [04:23] Maybe those quick-start blocks could link through to more detailed instructions (in the gui case with step-by-step screenshots) [04:24] I think you could try recoloring the logo (and making it smaller). Or maybe we can come up with a better one. [04:24] hm, one possibility would be to have a jquery powered slide-show basically, showing you both step by step [04:24] I.e. you just click and you see a "focus" screenshot on the left and the corresponding shell instructions on the right [04:25] Worth experimenting with, might not work on the front page though with everything else that needs to be communicated. [04:26] but first things first, but current todo is to get a proper grid in place first, then get all the content onto the page, then fix colors, then do some real layout, and then get back to discussion [04:26] args, I need to learn to type :/ [04:27] No worries, I'm supposed to be working anyway. Send it to the mailing list when ready, I don't spend a lot of time on IRC. [04:27] just for reference, my own website has lots of whitespace: anteru.net :P [04:28] Yeah, I actually have to do some graphics stuff as well ... but still good to get some early opinions. [04:29] graphics == opengl code, not the painting style [04:32] * anteru goes lurking again [04:55] Where do I file a bug about launchpad documentation? [05:11] I get a backtrace trying to branch a repository over bzr+ssh, with 2.2.0 on my end and 1.3.1 on their end. [05:12] Is that expected? Should I fall back to sftp: ? [05:13] What does the backtrace say? [05:13] Sorry, one moment [05:13] http://paste.debian.net/88489/ [05:13] (I got distracted in another channel.) [05:15] OK, and sftp fails with "EOF during negotiation" [05:16] Note: I know that repo exists (I can see .bzr and such with ls -a on the far end), but I don't know if it's the repo I want, nor if bzr is actually working on the far end. [05:16] twb: That suggests that is may be a more generic error [05:16] bare ssh IS working [05:16] Oh, maybe it's because these fucktards block ICMP, so MTU negotiation doesn't happen. [05:16] Let me try dialing the MTU down to 1450 or so. [05:17] twb: 1.3.0 is really old. [05:18] mkanat: I'm not going to upgrade random stuff on a customer's production server. [05:18] twb: That's certainly your prerogative. [05:19] Thank you for understanding that :-) [05:20] twb: He has a point, why can't you upgrade it? [05:20] Because upgrading software, particularly out-of-band, tends to introduce bugs as well as features. [05:21] Unless I *really truly NEED* a feature, I'm not going to go out of my way to upgrade things. [05:23] twb: If you're using just ssh:// or sftp:// then you're not interacting with the bzr on the server at all. [05:23] twb: So that would be something protocol related. [05:23] Right; which is why I suspect MTU [05:23] twb: Could be. [05:24] twb: Are you on some network where MTU auto-negotiation actually happens? I haven't seen one of those in quite some time. [05:24] mkanat: MTU negotiation definitely *doesn't* happen on this network [05:24] Because they block ICMP [05:25] twb: Okay. So it would be odd for the server to have specified an MTU below the standard then, right? [05:25] mkanat: it's a pptp vpn, unfortunately [05:26] twb: Ohh. [05:26] twb: So you might be hitting the problem before you even really get into their network. [05:26] twb: But in that case, bzr+ssh wouldn't have worked at all, right? [05:26] Why not? ssh works over the VPN [05:26] twb: If there was an MTU problem, I mean. [05:27] IIRC MTU problems manifest only when you start shoving nontrivial data [05:27] e.g. ssh works until you run "ls" [05:27] twb: That could be. [05:27] twb: You'd have to send a packet larger than the MTU, I suppose. [05:27] FWIW, with an mtu of 1446 I still see the symptoms described above for sftp: and bzr+ssh: [05:28] Right. [05:28] (Larger than *their* MTU, that is) [05:28] Right. [05:28] twb: Can you normally "ssh" or "sftp" to the server? [05:31] Yeah [05:32] My bzr URI syntax is right, right? [05:32] I always fuck it up when using hg [05:33] Ugh ugh ugh [05:33] ssh works, sftp doesn't [05:34] AFAICT someone has installed an sshd_config on this host that's not compatible with the version they're actually running. [05:34] twb: ugh, that's a regression [05:34] spiv: let me clarify [05:34] sftp bwired-dvmh-mgmt-01.bulletproof.net ==> subsystem request failed on channel 0 \n Couldn't read packet: Connection reset by peer [05:35] i.e. sftp fails outside of bzr [05:35] twb: the traceback for 2.2.0 against 1.3.0 is the regression I'm referring to [05:35] Oh right [05:35] (Possibly would happen with 2.1 as well?) [05:36] So it looks like I can't actually clone this repo, since the regression happens for 2.2.0 vs. 1.3.0 on bzr+ssh, and sftp isn't available (though ssh and scp ARE) [05:37] Re. sftp, the problem is *definitely* ssh, *not* bzr [05:37] Sep 8 14:33:18 bwired-dvmh-mgmt-01 sshd[31333]: error: subsystem: cannot stat internal-sftp: No such file or directory [05:38] hi. HELP! rebase has stuffed my working branch in a very bad way, [05:38] https://bugs.launchpad.net/bzr-rewrite/+bug/632894 [05:38] Launchpad bug 632894 in bzr-rewrite "rebase did NOT include all the commits AFTER a merge (affected: 1, heat: 8)" [Undecided,New] [05:39] i've reported the bug, but now i need to fix the problem in a hurry [05:39] i assume the commits are still in the repo *somewhere*, how can i find and pull them? [05:39] twb: Glad at least that you've got it figured out now, though. [05:40] twb: I think I can give you a workaround, just a sec [05:40] eg, i know when i do bzr uncommit, it tells me a magic thing i can type in to retrieve that commit back [05:40] how do i get a list of those? [05:41] paul__: There's a 'head' command in bzrtools that digs through the repo and tells you what head revs there are. [05:41] paul__: bzr heads --dead-only [05:41] paul__: you'll need the 'bzrtools' plugin if you don't already have it [05:41] It should be a short enough list that you can make a good stab at which you want. [05:42] oh god, thanks, there it is [05:42] So you should be able to 'pull --overwrite -rwhatever .` to restore it in-place (or fiddle around with making a new branch at that rev if you prefer) [05:42] (don't miss the '.' in that command line) [05:43] i'll do a branch to check first [05:43] if this doesnt work my only remaining copy is in my editor [05:43] there are quite a few heads, more than i thought there would be [05:44] and theres more than one for this particular checkin! [05:44] same timestamp [05:44] i only checked it in once, then i did a rebase which stuffed things up [05:46] can someone please check that bug? if its real, then it could be a very serious problem to a lot of projects [05:46] Well, you can check both. It may take some rooting, but it's there. [05:46] spiv: thanks, please stick a "twb:" in front when you have it, so my notification system wakes me up [05:47] twb: will do, sorry something else has come up right at this second, but I will get back to you soon I hope. [05:48] No rush; I'm just gonna scp -r it across and look at the repo; I don't need to patch it just yet [05:49] Is there an equivalent of "bzr viz" that works on the terminal (like "hg glog")? [05:52] bzr log -n0, to an extent. [05:53] I meant for the little DAG down the side [05:54] Not that I know of, but it'd be nice to have. [05:54] Oh well. I'll xinit /usr/bin/bzr viz [06:18] twb: bzr branch lp:~spiv/+junk/bzr_ssh_v2_hack ~/.bazaar/plugins/ [06:24] spiv: Branched 0 revision(s). [06:24] Oh, gar. [06:24] I'll fix that :) [06:25] twb: ok, pull now (or delete and rebranch) [06:26] Still fails [06:27] Details? [06:27] Sorry [06:28] http://paste.debian.net/88495/ [06:28] I don't see bzr_ssh_v2_hack in your list of plugins there. [06:28] That's because you told it to dl to plugins/ itself [06:29] Oh! [06:29] Sorry, that was careless. [06:29] OK, now I did something bad [06:30] ImportError: No module named bzrlib [06:30] Huh. pastebin the traceback (add -Derror to the command line if it doesn't emit one) [06:31] And now that error is gone agan [06:31] I have no idea what happened there [06:32] Weird! [06:35] spiv: bzr+ssh works after that plugin is cloned into a subdir of ~/.bazaar/plugins/ [06:36] twb: great! I'll work on fixing the bug properly for 2.2.1/2.3 [06:37] Will that branch remain available? [06:37] I'd like to mention it in my ticket system [06:39] twb: sure [06:39] Thanks for the prompt response [06:43] You're welcome, I'm glad the workaround worked. [07:34] hi all ! [07:53] hi there vila [07:53] poolie: hey ! [07:53] poolie: Can you clarify your comment on bug #323111 ? Oh, you already did [07:53] Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 1, heat: 8)" [Medium,In progress] https://launchpad.net/bugs/323111 [07:53] :) [07:54] yeah, I had that policy thing in mind too, I'm about to write the tests and code for that. [07:55] Blueskying, a registry could be used to decide that based on a... config variable maybe ;) [07:55] but I think it will be overkill for a first submission [07:56] and there are some interactions with junk files we may want to address first too (though that's a bit more invasive, currently my patch modify TreeTransform only) [08:00] $ /usr/bin/time bzr log --help >/dev/null ==> 2.73user 0.08system 0:02.81elapsed 99%CPU (0avgtext+0avgdata 84320maxresident)k [08:00] Why does bzr need three seconds in the CPU even to print the help text? [08:01] On the same host, "hg log --help" takes less than half a second of CPU time [08:01] 0.090u 0.030s 0:00.12 100.0% [08:01] 0.11user 0.00system 0:00.11elapsed 97%CPU [08:01] The host in question is running bzr 2.2.0 on Debian sid. [08:02] I tend to suspect my system isn't REALLY 20x as fast as yours... [08:02] twb: try with --no-plugins; the hack I gave you would have the side-effect of forcing the import of a bunch of often unnecessary code. [08:02] spiv: with --no-plugins it's still 1.2s user [08:02] (As might some of the other plugins you have installed, I haven't looked at e.g. etckeeper's impact on load times) [08:03] Ok, well that's half the problem at least ;) [08:04] I have bzrtools and python-paramiko installed, but not bzr-{doc,gtk,svn}, python-kerberos, python-pycurl or xdg-utils installed (the packages bzr suggests). [08:04] twb: that is pretty slow, though! It's 0.096s user on my laptop. [08:05] twb: perhaps somehow the .pyc files are missing or stale in your install? [08:05] About the only thing I can think of is "byte-compile = optimize" in /etc/python/debian_configuration [08:05] But I would *hope* that it's only byte-compiling files once [08:06] Hmm, possibly. [08:06] And in any case, if it was a python problem it ought to break hg, too [08:06] Yeah, unless the packaging is quite different or something. [08:07] Oh, and I'm on an SSD, so probably my read speeds are good and my write speeds are bad. [08:07] or unless bzr triggers something hg doesn't but it still python related :) [08:07] twb: check your install for the .pyc files, if they aren't there python have to generate them at each run [08:07] twb: try 'python -v /usr/bin/bzr rocks' [08:08] http://paste.debian.net/88516/ [08:08] twb: if it is importing from .py files rather than .pyc/.pyo, and/or emitting a bunch of "can't create", that'd be a problem [08:09] twb: yep, it is looking for and failing to load .pyc files. [08:09] That's stupid :-/ [08:09] I shouldn't have to run bzr as root to get pycs [08:09] twb: ah, because /usr/bin/bzr has "#!/usr/bin/python", which won't look for .pyo [08:09] Stupid debian [08:10] twb: if you have "#!/usr/bin/python -O" it would look for .py [08:10] Er, [08:10] twb: if you have "#!/usr/bin/python -O" it would look for .pyo [08:10] That extra char matters :) [08:10] twb: Perhaps you should set byte-compile = standard, optimize in /etc/python/debian_config ? [08:11] spiv: ETOOCLOSE(pyo, typo) [08:11] (if that works) [08:11] vila: hah [08:12] spiv: hum, I'll try that. [08:12] twb: arguably the bzr deb package could check that config and adjust the #! line accordingly, it might be good to file a bug about that. [08:13] You'd think that part would be done in some magical way for *all* packages [08:14] Yeah, it seems like something that python-central ought to help with. [08:14] Maybe it does, and the bzr package just doesn't use it? [08:14] Damned if I know [08:14] I'm no expert in packaging :) [08:14] Definitely this counts as a bug in the packaging, though. That's a pretty unpleasant result :( [08:15] Setting a config var to optimize shouldn't make programs go 10x slower :( [08:15] Hopefully it doesn't disable the C extensions... [08:15] vila: on that count at least we ought to be safe. [08:16] Is it conceivable to set -O from a running python script without spawning a new interpreter ? .... [08:17] OK, after changing that to standard, optimize, and dpkg-reconfigure bzr bzrtools, I get 0.6s or 0.4s without plugins [08:17] And with python -O it's 0.056s for both [08:18] twb: more in line with hg then ? [08:18] Yeah, thanks [08:19] twb: would you mind filing a bug for that ? [08:19] urgh, a raw 'bzr' tracebacks [08:22] hmm, bad wikkid [08:23] vila: against what, though? [08:23] Last time I looked, the debian maintainers basically said "don't change /etc/python/debian_config or we will ignore you" [08:24] err, you lost me here, do you mean the bug is triggered because you modify /etc/python/debian_config; ? [08:25] vila: yes, I think so [08:25] IIUC I accidentally said "make .pyo but not .pyc" when I should've said "make .pyo AND .pyc" [08:25] Right. [08:25] And a more or less separate bug is that python programs in Debian ignore .pyo files [08:26] twb: then file it at https://bugs.launchpad.net/bzr/+filebug and we'll see from there [08:27] twb: I don't have such a setup but hopefully someone will be able to reproduce [08:27] twb: and if nothing else, it will document your workaround [08:27] vila: it's a packaging issue, really, filing it against Debian is probably more appropriate [08:28] spiv: so anyway, what I'm gonna do now is sudo sed -i '1s/^#!.*python$/& -O/' /usr/bin/* ;-) [08:28] spiv: unless it's immediately triaged as WontFix as twb hinted [08:29] heya [08:29] twb: *shudder* :) [08:29] Well, if it increases bzr's speed tenfold, it'll probably increase other stuff [08:29] * bialix waves hello at GaryvdM [08:29] Hi bialix [08:30] twb: I won't bet the increase will apply to every command... [08:30] thank you for new installer [08:30] twb: well, I'd expect optimised bytecode to have minimal impact on bzr over unoptimised. [08:30] bialix: Does it fix the bug? Did not seam to work for me. [08:31] bug with russian characters? yes!!! [08:31] spiv: it was 0.6 vs. 0.05 [08:31] spiv: for --help, anyway [08:31] twb: Strange. I don't see that here. I see basically no difference. [08:32] GaryvdM: I suspect you should test with accented characters instead of russian ones for your system [08:32] spiv: did you make .pyo's for all your libraries and stuff? [08:32] twb: to be clear, I mean where the bytecode is precached for both cases (i.e. with .pyc and .pyo files) [08:32] twb: right [08:33] GaryvdM: I'm going to test PyQt 4.5.2 which I have in my archives re bug with frozen child window [08:33]