[00:00] <ayan> i see.  i'm trying to map git concepts onto bzr.
[00:02] <ayan> how do i copy a repository with all of the associated history a la ``git clone''?
[00:02] <dash> ayan: i'd use tar, probably
[00:03] <dash> ayan: but usually, it's not necessary
[00:03] <dash> ayan: just use 'bzr clone' to get the branch you want
[00:03] <ayan> okay, thanks.  off to rtfm harder. :)
[00:21] <poolie> hi jelmer, all
[01:01] <spiv> Good morning.
[01:21] <mangojambo> 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] <mangojambo> QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory
[01:21] <mangojambo> QFileSystemWatcher: failed to add paths: /Users/mj/.bazaar/bazaar.conf
[01:21] <mangojambo> Please, how can I fix it?
[01:25] <maxb> Does /Users/mj/.bazaar/bazaar.conf exist?
[01:27] <mangojambo> maxb: no. But I creat a file ( touch ~/.bazaar/bazaar.conf) and the error stops, but nothing happens
[01:40] <maxb> mangojambo: Ok, that sounds fairly likely
[01:41] <maxb> This means that the "errors" you posted are not errors, but just informational notes, and the real problem is something else
[01:43] <mangojambo> so, how can I fix it, or just access user configuration to set my user, email, etc ?
[01:46] <maxb> I'm afraid I don't know enough about qbzr to suggest what the problem might be
[01:56] <mangojambo> maxb: ok, thanks man. I will keep trying here.
[01:56] <mangojambo> seeya
[02:06] <poolie_> hi spiv
[02:06] <poolie_> apparently search on the bzr web site is broken so i'm going to try to fix that now
[02:06] <poolie_> then do something about stale locks
[02:06] <poolie_> i hope you got back eventually
[02:07] <poolie_> and apparently i'm the pilot
[02:07] <spiv> 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] <poolie_> :)
[02:08] <poolie_> slower exit, but greater survivability
[02:08] <spiv> Plus I got to watch the rest of the neverending press conference.
[02:08] <poolie_> everyone can have 30 minutes of fame if they ramble enough
[02:08] <spiv> And the gradually increasing groans and eyerolls from the people watching it waiting for the result.
[02:09] <spiv> The mood towards rambling could be summarised as: "don't they know some people have planes to catch?"
[02:09] <spm> hahah
[02:10] <spiv> 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] <jam> 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] <spiv> jam: sounds like a bug (in either docs or implementation...)
[02:19] <spiv> jam: on windwos?
[02:19] <jam> spiv: PosixReactorBase
[02:20] <jam> spiv: twisted/internet/interfaces.py says thait IReactorProcess returns IProcessTransport
[02:20] <spiv> So the default reactor (select)?
[02:20] <jam> PosixReactorBase returns internet.process.Process directly
[02:21] <jam> spiv: I don't really know, but IOCPReactor does the same thing
[02:21] <jam> spiv: I'm trying to replace a spawnProcess call with my own stuff, but the details are a bit.. hazy
[02:21] <spiv> Well, Process is supposed to implement that IIRC
[02:21] <spiv> Certainly twisted.internet._dumbwin32proc.Process does
[02:22] <jam> spiv: well, I can't find it saying "implements()"
[02:22] <poolie> hello jam
[02:22] <jam> spiv: right, that is the only thing that *does* implement it
[02:22] <jam> hi poolie
[02:22]  * jam is digging into twisted internals right now
[02:22] <spiv> jam: please file a bug
[02:22] <jam> which isn't a whole lot of fun, but doesn't seem too bad
[02:22] <spiv> jam: I think it's just missing the implements declaration
[02:22] <jam> spiv: so my concern is whether implementing the minimal IProcessTransport will be enough
[02:23] <spiv> jam: AFAICS it does actually satisfy that contract
[02:23] <jam> spiv: Process probably does
[02:23] <poolie> jam, is this because the reviewers really wanted twisted rather than otherwise?
[02:23] <jam> *I* don't know if I need to implement more
[02:23] <poolie> or because you need to fix the conch server?
[02:23] <jam> poolie: the ssh daemon is a Twisted process
[02:23] <jam> poolie: right
[02:24] <jam> I need to connect up the ssh incoming with the spawned process
[02:24] <jam> IProcessTransport is pretty minimal, so it shouldn't be too bad
[02:24] <jam> the concern is that it also seems intermingled with IProcessProtocol
[02:24] <jam> and that is a much larger api
[02:25] <jam> spiv: for example, I don't think spawnProcess calls transport.makeConnection(proto)
[02:25] <jam> though I'm still wrapping my head around everythingf
[02:25] <spiv> Process.__init__ does that
[02:25] <spiv> IIRC
[02:26] <jam> spiv: yeah, in a try/except: loop, no less
[02:26] <jam> (bare except)
[02:27] <jam> I didn't see it originally because __init__ is quite long
[02:27] <jam> I *did* see it in the win32 one, and was trying to reconcile that
[02:27] <spiv> (I wonder if it would be clearer if ProcessProtocol didn't implement IProtocol, and instead was explicitly adapted...)
[02:27] <jam> 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] <jam> spiv: and the docstring for IProcessTransport is: A process transport.
[02:28] <spiv> 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] <jam> which is *mighty* helpful
[02:28] <spiv> Well, it's the transport for a process! :)
[02:29] <jam> Very true
[02:29] <spiv> IProtocol is very slim, take a look at it.
[02:29] <jam> spiv: so I'm spawning a process outside of the current process and connecting to it
[02:30] <jam> which is ~ a subclass of Process
[02:30] <jam> I have pipes to read / write to
[02:30] <jam> I have a PID
[02:30] <jam> etc
[02:30] <jam> it is a good fit for IProcessTransport
[02:30] <spiv> 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] <jam> I also have to manage talking on several file descriptors, etc, which Process already implements
[02:30] <spiv> (and decode it into HTTP request objects or whatever the protocol is)
[02:30] <jam> I just don't want to call _fork
[02:31] <jam> I might inherit from BaseProcess, or _BaseProcess (which inherits from BaseProcess oddly enough...)
[02:31] <spiv> A IProcessTransport is a transport with some extra features like pid and the ability to send signals.
[02:32] <jam> spiv, poolie: Do you know if waiting for a pid that isn't a child just raises an error?
[02:32] <jam> (I can test it, but I figured I could ask first)
[02:34] <spiv> jam: that sounds like a reasonable fit for IProcessTransport too
[02:34] <spiv> s/that/I think that/
[02:35] <jam> spiv: I don't know how to submit bugs to twisted, and probably have to log in
[02:35] <jam> any chance you could submit one for me?
[02:35] <jam> Just a simple "internet.process.Process' does not implement IProcessTransport
[02:35] <jam> (though it is returned by spawnProcess, which claims to return one of those)
[02:35] <spiv> You do need to log in, it's a Trac instance: twistedmatrix.com/trac
[02:36] <jam> 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] <spiv> 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] <jam> spiv: well, I'm certainly trying to avoid poking at any twisted internals :)
[02:39] <mkanat> Why does it seem like committing to a remote bound branch is so much slower than committing locally and then pushing?
[02:39] <jam> mkanat: it is possible, time it and check
[02:39] <jam> it pretty much does exactly that internally
[02:39] <jam> but it is possible there is a different code path
[02:40] <poolie> mkanat: because we're compressing the things to store relative to things stored remotely, maybe?
[02:40] <jam> poolie: we write it locally, then push, then update the branch pointer
[02:40] <mkanat> poolie: That could be. It could also have to do with taking a lock on the remote repo, or something.
[02:40] <poolie> mkanat: also, if there's a difference, getting a -Dhpss log should make it obvious why
[02:40] <mkanat> poolie: Okay.
[02:40] <jam> and/or --lsprof-file foo.callgrind
[02:40] <jam> anyway, back to family time
[02:41] <poolie> jam i'll try to catch you tomorrow afternoon your time
[02:43] <spiv> jam: http://twistedmatrix.com/trac/ticket/4648
[02:58] <poolie> i think i'll delete the rendered html from the website branch
[02:59] <poolie> now we can generate it on the server it just seems to be noise
[03:06] <mkanat> 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] <mkanat> We used to store compiled docs along with Bugzilla; we removed them many years ago. It was a good idea. :-)
[03:12] <poolie> ok, and i think site search is working again, can someone test it?
[03:49] <anteru> Hi, is anyone working on the Website?
[03:49] <poolie> i am
[03:49] <poolie> is it broken?
[03:49] <anteru> 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] <poolie> ok
[03:50] <poolie> i think it could certainly be improved and clarified
[03:50] <poolie> do you mean a requirements doc, or technical requirements?
[03:50] <anteru> I.e. a prominent download link fed from Launchpad directly, and two boxes for quick start
[03:50] <poolie> the source is in lp:bzr-website
[03:50] <poolie> that would be gerat
[03:51] <anteru> poolie: Requirements as in what _has_ to be on it, and technical as in lib x must be used
[03:51] <anteru> I don't know if there is some requirement from canonical for instance
[03:51] <poolie> nup, both are negotiable
[03:51] <poolie> whatever makes sense
[03:51] <anteru> Ok
[03:51] <anteru> I assume it should work with Python 2.x?
[03:52] <poolie> yes
[03:52] <poolie> any dependencies for generation should ideally be packaged in ubuntu
[03:52] <poolie> but we can work that out o
[03:52] <anteru> 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] <poolie> also, i think it's nice to keep the current approach of static generation, if possible
[03:52] <poolie> that would be great
[03:52] <poolie> you could post some screenshots or urls to the list, or here
[03:53] <anteru> Sure, as soon as I'm happy with it :)
[03:53] <anteru> I just wanted to check if someone else already works on a redesign for the front-page.
[03:55] <jbowtie> 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] <poolie> that would be great too
[03:55] <poolie> also to make the wp blog consistent with the site
[03:55] <poolie> anteru: you can look at the canonical design standards for inspiration
[03:56] <poolie> which are probably linked from wiki.ubuntu.com
[03:56] <anteru> uh oh folks :) one at a time, maybe (:
[03:56] <poolie> but we don't have to stick to them
[03:57] <jbowtie> 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] <anteru> 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] <anteru> give me a minute, and I can show you the current hacky state, basically blocking out the layout/content
[04:04] <anteru> quick: screenshot tool for kubuntu?
[04:04] <anteru> got it
[04:05] <anteru> http://img13.imageshack.us/img13/2373/bildschirmfoto1vt.png
[04:07] <anteru> danger: ugly and work-in-progress
[04:07] <anteru> 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] <jbowtie> You're right about ugly.  :)
[04:14] <anteru> it's work in progress
[04:15] <jbowtie> I know, I was kidding, you should see my early designs. Actually better if you don't.
[04:16] <jbowtie> 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] <anteru> with some more context: http://img84.imageshack.us/img84/6872/bildschirmfoto2q.png
[04:17] <anteru> 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] <anteru> it also needs a bit stronger colours IMAO
[04:19] <anteru> but the yellow logo means it will basically only go well with blue, or some orange-looking stuff
[04:20] <jbowtie> I'd lose those borders, makes it too blocky.
[04:20] <anteru> ok. I'm keeping them for now, as it eases layout a bit
[04:21] <jbowtie> 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] <jbowtie> 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] <anteru> also need to move it into some grid, right now it's completely ad-hoc
[04:23] <jbowtie> Maybe those quick-start blocks could link through to more detailed instructions (in the gui case with step-by-step screenshots)
[04:24] <jbowtie> I think you could try recoloring the logo (and making it smaller). Or maybe we can come up with a better one.
[04:24] <anteru> hm, one possibility would be to have a jquery powered slide-show basically, showing you both step by step
[04:24] <anteru> I.e. you just click and you see a "focus" screenshot on the left and the corresponding shell instructions on the right
[04:25] <jbowtie> Worth experimenting with, might not work on the front page though with everything else that needs to be communicated.
[04:26] <anteru> 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] <anteru> args, I need to learn to type :/
[04:27] <jbowtie> 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] <anteru> just for reference, my own website has lots of whitespace: anteru.net :P
[04:28] <anteru> Yeah, I actually have to do some graphics stuff as well ... but still good to get some early opinions.
[04:29] <anteru> graphics == opengl code, not the painting style
[04:32]  * anteru goes lurking again
[04:55] <JoshBrown> Where do I file a bug about launchpad documentation?
[05:11] <twb> 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] <twb> Is that expected?  Should I fall back to sftp: ?
[05:13] <JoshBrown> What does the backtrace say?
[05:13] <twb> Sorry, one moment
[05:13] <twb> http://paste.debian.net/88489/
[05:13] <twb> (I got distracted in another channel.)
[05:15] <twb> OK, and sftp fails with "EOF during negotiation"
[05:16] <twb> 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] <JoshBrown> twb: That suggests that is may be a more generic error
[05:16] <twb> bare ssh IS working
[05:16] <twb> Oh, maybe it's because these fucktards block ICMP, so MTU negotiation doesn't happen.
[05:16] <twb> Let me try dialing the MTU down to 1450 or so.
[05:17] <mkanat> twb: 1.3.0 is really old.
[05:18] <twb> mkanat: I'm not going to upgrade random stuff on a customer's production server.
[05:18] <mkanat> twb: That's certainly your prerogative.
[05:19] <twb> Thank you for understanding that :-)
[05:20] <JoshBrown> twb: He has a point, why can't you upgrade it?
[05:20] <twb> Because upgrading software, particularly out-of-band, tends to introduce bugs as well as features.
[05:21] <twb> Unless I *really truly NEED* a feature, I'm not going to go out of my way to upgrade things.
[05:23] <mkanat> twb: If you're using just ssh:// or sftp:// then you're not interacting with the bzr on the server at all.
[05:23] <mkanat> twb: So that would be something protocol related.
[05:23] <twb> Right; which is why I suspect MTU
[05:23] <mkanat> twb: Could be.
[05:24] <mkanat> 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] <twb> mkanat: MTU negotiation definitely *doesn't* happen on this network
[05:24] <twb> Because they block ICMP
[05:25] <mkanat> twb: Okay. So it would be odd for the server to have specified an MTU below the standard then, right?
[05:25] <twb> mkanat: it's a pptp vpn, unfortunately
[05:26] <mkanat> twb: Ohh.
[05:26] <mkanat> twb: So you might be hitting the problem before you even really get into their network.
[05:26] <mkanat> twb: But in that case, bzr+ssh wouldn't have worked at all, right?
[05:26] <twb> Why not?  ssh works over the VPN
[05:26] <mkanat> twb: If there was an MTU problem, I mean.
[05:27] <twb> IIRC MTU problems manifest only when you start shoving nontrivial data
[05:27] <twb> e.g. ssh works until you run "ls"
[05:27] <mkanat> twb: That could be.
[05:27] <mkanat> twb: You'd have to send a packet larger than the MTU, I suppose.
[05:27] <twb> FWIW, with an mtu of 1446 I still see the symptoms described above for sftp: and bzr+ssh:
[05:28] <twb> Right.
[05:28] <twb> (Larger than *their* MTU,  that is)
[05:28] <mkanat> Right.
[05:28] <mkanat> twb: Can you normally "ssh" or "sftp" to the server?
[05:31] <twb> Yeah
[05:32] <twb> My bzr URI syntax is right, right?
[05:32] <twb> I always fuck it up when using hg
[05:33] <twb> Ugh ugh ugh
[05:33] <twb> ssh works, sftp doesn't
[05:34] <twb> AFAICT someone has installed an sshd_config on this host that's not compatible with the version they're actually running.
[05:34] <spiv> twb: ugh, that's a regression
[05:34] <twb> spiv: let me clarify
[05:34] <twb> sftp bwired-dvmh-mgmt-01.bulletproof.net ==> subsystem request failed on channel 0 \n Couldn't read packet: Connection reset by peer
[05:35] <twb> i.e. sftp fails outside of bzr
[05:35] <spiv> twb: the traceback for 2.2.0 against 1.3.0 is the regression I'm referring to
[05:35] <twb> Oh right
[05:35] <spiv> (Possibly would happen with 2.1 as well?)
[05:36] <twb> 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] <twb> Re. sftp, the problem is *definitely* ssh, *not* bzr
[05:37] <twb> Sep  8 14:33:18 bwired-dvmh-mgmt-01 sshd[31333]: error: subsystem: cannot stat internal-sftp: No such file or directory
[05:38] <paul__> hi.  HELP!  rebase has stuffed my working branch in a very bad way,
[05:38] <paul__> https://bugs.launchpad.net/bzr-rewrite/+bug/632894
[05:39] <paul__> i've reported the bug, but now i need to fix the problem in a hurry
[05:39] <paul__> i assume the commits are still in the repo *somewhere*, how can i find and pull them?
[05:39] <mkanat> twb: Glad at least that you've got it figured out now, though.
[05:40] <spiv> twb: I think I can give you a workaround, just a sec
[05:40] <paul__> 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] <paul__> how do i get a list of those?
[05:41] <fullermd> paul__: There's a 'head' command in bzrtools that digs through the repo and tells you what head revs there are.
[05:41] <spiv> paul__: bzr heads --dead-only
[05:41] <spiv> paul__: you'll need the 'bzrtools' plugin if you don't already have it
[05:41] <fullermd> It should be a short enough list that you can make a good stab at which you want.
[05:42] <paul__> oh god, thanks, there it is
[05:42] <fullermd> 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] <fullermd> (don't miss the '.' in that command line)
[05:43] <paul__> i'll do a branch to check first
[05:43] <paul__> if this doesnt work my only remaining copy is in my editor
[05:43] <paul__> there are quite a few heads, more than i thought there would be
[05:44] <paul__> and theres more than one for this particular checkin!
[05:44] <paul__> same timestamp
[05:44] <paul__> i only checked it in once, then i did a rebase which stuffed things up
[05:46] <paul__> can someone please check that bug?  if its real, then it could be a very serious problem to a lot of projects
[05:46] <fullermd> Well, you can check both.  It may take some rooting, but it's there.
[05:46] <twb> spiv: thanks, please stick a "twb:" in front when you have it, so my notification system wakes me up
[05:47] <spiv> 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] <twb> 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] <twb> Is there an equivalent of "bzr viz" that works on the terminal (like "hg glog")?
[05:52] <spiv> bzr log -n0, to an extent.
[05:53] <twb> I meant for the little DAG down the side
[05:54] <spiv> Not that I know of, but it'd be nice to have.
[05:54] <twb> Oh well.  I'll xinit /usr/bin/bzr viz
[06:18] <spiv> twb: bzr branch lp:~spiv/+junk/bzr_ssh_v2_hack ~/.bazaar/plugins/
[06:24] <twb> spiv: Branched 0 revision(s).
[06:24] <spiv> Oh, gar.
[06:24] <spiv> I'll fix that :)
[06:25] <spiv> twb: ok, pull now (or delete and rebranch)
[06:26] <twb> Still fails
[06:27] <spiv> Details?
[06:27] <twb> Sorry
[06:28] <twb> http://paste.debian.net/88495/
[06:28] <spiv> I don't see bzr_ssh_v2_hack in your list of plugins there.
[06:28] <twb> That's because you told it to dl to plugins/ itself
[06:29] <spiv> Oh!
[06:29] <spiv> Sorry, that was careless.
[06:29] <twb> OK, now I did something bad
[06:30] <twb> ImportError: No module named bzrlib
[06:30] <spiv> Huh.  pastebin the traceback (add -Derror to the command line if it doesn't emit one)
[06:31] <twb> And now that error is gone agan
[06:31] <twb> I have no idea what happened there
[06:32] <spiv> Weird!
[06:35] <twb> spiv: bzr+ssh works after that plugin is cloned into a subdir of ~/.bazaar/plugins/
[06:36] <spiv> twb: great!  I'll work on fixing the bug properly for 2.2.1/2.3
[06:37] <twb> Will that branch remain available?
[06:37] <twb> I'd like to mention it in my ticket system
[06:39] <spiv> twb: sure
[06:39] <twb> Thanks for the prompt response
[06:43] <spiv> You're welcome, I'm glad the workaround worked.
[07:34] <vila> hi all !
[07:53] <poolie> hi there vila
[07:53] <vila> poolie: hey !
[07:53] <vila> poolie: Can you clarify your comment on bug #323111 ? Oh, you already did
[07:53] <poolie> :)
[07:54] <vila> yeah, I had that policy thing in mind too, I'm about to write the tests and code for that.
[07:55] <vila> Blueskying, a registry could be used to decide that based on a... config variable maybe ;)
[07:55] <vila> but I think it will be overkill for a first submission
[07:56] <vila> 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] <twb> $ /usr/bin/time bzr log --help >/dev/null ==> 2.73user 0.08system 0:02.81elapsed 99%CPU (0avgtext+0avgdata 84320maxresident)k
[08:00] <twb> Why does bzr need three seconds in the CPU even to print the help text?
[08:01] <twb> On the same host, "hg log --help" takes less than half a second of CPU time
[08:01] <fullermd> 0.090u 0.030s 0:00.12 100.0%
[08:01] <vila> 0.11user 0.00system 0:00.11elapsed 97%CPU
[08:01] <twb> The host in question is running bzr 2.2.0 on Debian sid.
[08:02] <fullermd> I tend to suspect my system isn't REALLY 20x as fast as yours...
[08:02] <spiv> 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] <twb> spiv: with --no-plugins it's still 1.2s user
[08:02] <spiv> (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] <spiv> Ok, well that's half the problem at least ;)
[08:04] <twb> 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] <spiv> twb: that is pretty slow, though!  It's 0.096s user on my laptop.
[08:05] <spiv> twb: perhaps somehow the .pyc files are missing or stale in your install?
[08:05] <twb> About the only thing I can think of is "byte-compile = optimize" in /etc/python/debian_configuration
[08:05] <twb> But I would *hope* that it's only byte-compiling files once
[08:06] <spiv> Hmm, possibly.
[08:06] <twb> And in any case, if it was a python problem it ought to break hg, too
[08:06] <spiv> Yeah, unless the packaging is quite different or something.
[08:07] <twb> Oh, and I'm on an SSD, so probably my read speeds are good and my write speeds are bad.
[08:07] <vila> or unless bzr triggers something hg doesn't but it still python related :)
[08:07] <vila> twb: check your install for the .pyc files, if they aren't there python have to generate them at each run
[08:07] <spiv> twb: try 'python -v /usr/bin/bzr rocks'
[08:08] <twb> http://paste.debian.net/88516/
[08:08] <spiv> 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] <spiv> twb: yep, it is looking for and failing to load .pyc files.
[08:09] <twb> That's stupid :-/
[08:09] <twb> I shouldn't have to run bzr as root to get pycs
[08:09] <spiv> twb: ah, because /usr/bin/bzr has "#!/usr/bin/python", which won't look for .pyo
[08:09] <twb> Stupid debian
[08:10] <spiv> twb: if you have "#!/usr/bin/python -O" it would look for .py
[08:10] <spiv> Er,
[08:10] <spiv> twb: if you have "#!/usr/bin/python -O" it would look for .pyo
[08:10] <spiv> That extra char matters :)
[08:10] <spiv> twb: Perhaps you should set byte-compile = standard, optimize in /etc/python/debian_config ?
[08:11] <vila> spiv: ETOOCLOSE(pyo, typo)
[08:11] <spiv> (if that works)
[08:11] <spiv> vila: hah
[08:12] <twb> spiv: hum, I'll try that.
[08:12] <spiv> 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] <twb> You'd think that part would be done in some magical way for *all* packages
[08:14] <spiv> Yeah, it seems like something that python-central ought to help with.
[08:14] <spiv> Maybe it does, and the bzr package just doesn't use it?
[08:14] <twb> Damned if I know
[08:14] <spiv> I'm no expert in packaging :)
[08:14] <spiv> Definitely this counts as a bug in the packaging, though.  That's a pretty unpleasant result :(
[08:15] <spiv> Setting a config var to optimize shouldn't make programs go 10x slower :(
[08:15] <vila> Hopefully it doesn't disable the C extensions...
[08:15] <spiv> vila: on that count at least we ought to be safe.
[08:16] <vila> Is it conceivable to set -O from a running python script without spawning a new interpreter ? ....
[08:17] <twb> OK, after changing that to standard, optimize, and dpkg-reconfigure bzr bzrtools, I get 0.6s or 0.4s without plugins
[08:17] <twb> And with python -O it's 0.056s for both
[08:18] <vila> twb: more in line with hg then ?
[08:18] <twb> Yeah, thanks
[08:19] <vila> twb: would you mind filing a bug for that ?
[08:19] <vila> urgh, a raw 'bzr' tracebacks
[08:22] <vila> hmm, bad wikkid
[08:23] <twb> vila: against what, though?
[08:23] <twb> Last time I looked, the debian maintainers basically said "don't change /etc/python/debian_config or we will ignore you"
[08:24] <vila> err, you lost me here, do you mean the bug is triggered because you modify /etc/python/debian_config; ?
[08:25] <twb> vila: yes, I think so
[08:25] <twb> IIUC I accidentally said "make .pyo but not .pyc" when I should've said "make .pyo AND .pyc"
[08:25] <spiv> Right.
[08:25] <twb> And a more or less separate bug is that python programs in Debian ignore .pyo files
[08:26] <vila> twb: then file it at https://bugs.launchpad.net/bzr/+filebug and we'll see from there
[08:27] <vila> twb: I don't have such a setup but hopefully someone will be able to reproduce
[08:27] <vila> twb: and if nothing else, it will document your workaround
[08:27] <spiv> vila: it's a packaging issue, really, filing it against Debian is probably more appropriate
[08:28] <twb> spiv: so anyway, what I'm gonna do now is sudo sed -i '1s/^#!.*python$/& -O/' /usr/bin/* ;-)
[08:28] <vila> spiv: unless it's immediately triaged as WontFix as twb hinted
[08:29] <bialix> heya
[08:29] <spiv> twb: *shudder* :)
[08:29] <twb> Well, if it increases bzr's speed tenfold, it'll probably increase other stuff
[08:29]  * bialix waves hello at GaryvdM
[08:29] <GaryvdM> Hi bialix
[08:30] <vila> twb: I won't bet the increase will apply to every command...
[08:30] <bialix> thank you for new installer
[08:30] <spiv> twb: well, I'd expect optimised bytecode to have minimal impact on bzr over unoptimised.
[08:30] <GaryvdM> bialix: Does it fix the bug? Did not seam to work for me.
[08:31] <bialix> bug with russian characters? yes!!!
[08:31] <twb> spiv: it was 0.6 vs. 0.05
[08:31] <twb> spiv: for --help, anyway
[08:31] <spiv> twb: Strange.  I don't see that here.  I see basically no difference.
[08:32] <bialix> GaryvdM: I suspect you should test with accented characters instead of russian ones for your system
[08:32] <twb> spiv: did you make .pyo's for all your libraries and stuff?
[08:32] <spiv> twb: to be clear, I mean where the bytecode is precached for both cases (i.e. with .pyc and .pyo files)
[08:32] <spiv> twb: right
[08:33] <bialix> GaryvdM: I'm going to test PyQt 4.5.2 which I have in my archives re bug with frozen child window
[08:33] <GaryvdM> bialix: ok
[08:33] <bialix> GaryvdM: is there specific reasons for us to use the latest PyQt?
[08:33] <bialix> at least on windows
[08:33] <spiv> twb: forcing Python to recompile the bytecode every invocation is certainly going to hurt a lot, but at least for bzr the practical benefit of the -O optimisations should be negligible
[08:33] <twb> OK, I remeasured it and I can't see the difference anymore
[08:33] <twb> (pyo vs pyc)
[08:34] <spiv> -O is very, very mild in what it does.
[08:34] <GaryvdM> bialix: I was hoping to be able some new features. Does 4.5.2 support QVarent.toPyObject
[08:34] <spiv> There's also -OO, which possibly would help bzr a little bit if only by reducing the size of the bytecode to load by omitting most docstrings.
[08:34] <bialix> GaryvdM: I dunno
[08:35] <GaryvdM> *to be able to *use* some new features
[08:35] <bialix> yep, I understood
[08:35] <spiv> It's a nasty trap to have /etc/python/debian_config contain such an attractive option that actually means "please break me" :(
[08:39] <fullermd> Eh, it's just like a lava pit in Quake.  Just there to see if you're paying attention.
[08:39] <bialix> GaryvdM: about new features: IIRC we discussed this at UDS and decided to not break backward compatibility in 0.19; and 0.19 is our bzr 2.2 companion, right?
[08:39] <GaryvdM> bialix: Yes
[08:40] <bialix> I don't mind to change required PyQt for 0.20
[08:42] <bialix> GaryvdM: 4.5.2 works ok
[08:43]  * bialix re-testing with 4.7.2
[08:45]  * bialix wants qabout dialog as in Explorer to easily see the versions of used PyQt/Qt
[08:48] <bialix> GaryvdM: 4.7.2 is buggy.
[08:48] <bialix> GaryvdM: can we downgrade to 4.5.2? please? pretty pretty please?
[08:50] <GaryvdM> bialix: Ok - I'm busy building my own build host. If I get that to work, I'll do that. Else we are going to have to ask jam to do it for us.
[08:51] <GaryvdM> bialix: Please will you put the 4.5.2 installer somewhere I can download it.
[08:51] <bialix> bialix.com will be OK for you?
[08:52] <GaryvdM> That's cool
[08:53]  * bialix is uploading, installer is 17MB big
[08:59] <vila> GaryvdM: Can I ask you to document every single step so anybody can reproduce ?
[09:00] <GaryvdM> vila: I'm following jam document
[09:00] <vila> GaryvdM: then update and complete ;)
[09:00] <GaryvdM> bzr.dev/doc/developers/win32_build_setup.txt
[09:01] <bialix> oh, that will be awesome
[09:01] <GaryvdM> vila: sure. I've chosen to use msys rather than cygwin
[09:01] <vila> GaryvdM: great, any chance you're doing that in a fresh VM ?
[09:01] <GaryvdM> vila: So if that works, I'll note that.
[09:01] <bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc (gpg signature)
[09:01] <GaryvdM> vila: I am
[09:02] <GaryvdM> bialix: Thanks
[09:02] <bialix> when I will have a free week or so, I will try to re-create my build environment without cygwin/msys. Heh
[09:02] <vila> GaryvdM: Woohoo ! Make copies ! Argh, no, windows licenses :-(
[09:03] <vila> GaryvdM: anyway, make copies for you so you can restart from a clean state if needed
[09:03]  * bialix is trying PyQt 4.7.6 now
[09:04] <bialix> riverbank guys even don't have RSS for their news %( in which age they're living?
[09:07] <bialix> 4.7.6 -> nope, the same
[09:15]  * bialix bbl
[09:33] <fullermd> Still no bzrtools for 2.2?   :(
[09:38] <poolie> fullermd: does anything fail or does it just need a release?
[09:39] <fullermd> I'm not aware of anything failing, which doesn't mean much since I don't use much of anything from it.
[09:40] <fullermd> Though I'd offhand assume enough people use both stuff from it and have upgraded to 2.2 by now that we'd have heard about any major breakages.
[09:58] <maxb> erm, huh. If there's no bzrtools for 2.2, how do we have one in the PPA?
[09:59] <Ddorda> hey guys, how do i clean modifications i did on a branch?
[09:59] <Ddorda> i mean locally changes
[09:59] <maxb> fullermd: It's been tagged, apparently
[09:59] <maxb> Ddorda: bzr revert
[10:00] <Ddorda> maxb: awesome thanks
[10:28] <MacSlow> Greetings
[10:29] <MacSlow> Can someone tell me what happended to olive (of bzr-gtk)?
[10:29] <MacSlow> it doesn't seem to be installed with it anymore.
[10:31] <vila> MacSlow: is has been split off bzr-gtk
[10:31] <MacSlow> so there's no more stand-alone way to start it?
[10:31] <MacSlow> only bzr visualise?
[10:32] <vila> MacSlow: it's now at lp:olive
[10:32] <MacSlow> vila, ok thanks
[10:32] <vila> MacSlow: much of the activity around stand-alone GUI for bzr is around lp:bzr-explorer
[10:33] <vila> MacSlow: which use qbzr mainly (even if on eof its early goals was to remain toolkit agnostic so in theory it could also use a bzr-gtk back-end)
[10:34] <vila> s/on eof/one of/ funny typo
[11:42] <maxb> abentley: Hi, will you be releasing a bzrtools 2.2.0 tarball?
[12:48] <mangojambo> Hi, where do I report a small bug ?
[14:43] <mgz> bug 633180 is funny.
[15:18] <git__> hi
[15:19] <git__> how well does bzr do with image versioning?
[18:14] <nDuff> I vaguely recall y'all having some shiny, shiny toolage analyzing Bazaar's performance over time (and isolating specific changesets where performance regressions occurred). Not having much luck googling it, though -- is that all in my head?
[18:26] <jml> nDuff, bzr-usertest
[18:30] <nDuff> jml, ahh -- thanks!
[21:22] <ddaa> I noticed that bzr-git does not support push
[21:22] <ddaa> but a look at the code suggests that it does support commit-to-git with roundtripping.
[21:23] <ddaa> Meaning, a commit done directly on checkout based on a git foreign branch will store all the good metadata, but that feature is missing from push.
[21:24] <jelmer> ddaa: it supports push, too
[21:24] <ddaa> I am wondering, maybe "rebase" or "replay" can be used to produce essentially the same effect as push.
[21:24] <jelmer> ddaa: Just that roundtripping is still disabled at the moment.
[21:25] <ddaa> jelmer: obviously, it supports dpush
[21:25] <ddaa> what do you mean "the roundtripping is disabled"?
[21:25] <jelmer> ddaa: I'd like to make sure that we have a stable format before enabling roundtripping.
[21:25] <jelmer> ddaa: There are two mapping formats - 'v1' which doesn't support roundtripping and 'experimental', which does. v1 is the default.
[21:26] <ddaa> Oh.
[21:26] <ddaa> Any idea when experimental will become v2 and v2 becomes the default?
[21:28] <jelmer> when I finish my work to make the bzrlib testsuite run against foreign formats
[21:28] <ddaa> So, if I understand correctly, commit on git foreign checkout currently does not work?
[21:29] <jelmer> ddaa: It's got some issues - for example it won't use what's in the working tree but what's in the index.
[21:29] <ddaa> Oh, that's interesting.
[21:29] <jelmer> ddaa: and I don't think it will use the revision id that's specified by the caller of WorkingTree.commit, if any.
[21:29] <ddaa> That's actually not what I meant though :-)
[21:30] <jelmer> ddaa: Sorry
[21:30] <ddaa> I meant commit on a bzr branch bound to a git branch, or commit to a bzr lightweight checkout of a git branch.
[21:30] <jelmer> ddaa: I doubt that commit on a git foreign checkout will work; on a non-bound branch it might.
[21:30] <ddaa> Gotcha.
[21:30] <jelmer> commit to a lightweight branch *might* work
[21:30] <jelmer> uhm, lightweight checkout
[21:31] <ddaa> Once roundtripping is enable, that will all magically work, right?
[21:31] <jelmer> in theory, yep
[21:31] <jelmer> there will probably be minor things to fix up
[21:38] <glyph> does the bot here pipe up about bzr-svn bugs as well?
[21:39] <glyph> well, assuming it doesn't
[21:39] <jelmer> glyph: I don't think it tells us about bzr bugs either :-)
[21:39] <glyph> https://bugs.launchpad.net/bzr-svn/+bug/633522
[21:39] <glyph> dash: you broke the internet :(
[21:40] <dash> glyph: oh noooo
[21:40]  * jelmer fires off a clone of calendarserver
[21:41] <glyph> jelmer: please be kind, use a shared repo :)
[21:41] <dash> glyph: what, you guys don't have a giant svn server farm over there?
[21:41] <dash> ;)
[21:41] <glyph> dash: uh yeah, "us guys", sure
[21:41] <glyph> I think you are closer to the "cloud" than me :-P
[21:42] <dash> true
[21:46] <glyph> I'm sure there are ... servers
[21:46] <glyph> I just don't want to get the bill for all of them because all 111 people in #bzr decide to clone it from scratch :)
[21:54] <jelmer> glyph: If only a bug report would immediately get the attention of 111 developers...
[21:59] <glyph> jelmer: if only!
[21:59] <glyph> thanks for looking at it
[21:59] <glyph> can you repro?
[22:03] <jelmer> glyph: nope
[22:03] <jelmer> glyph: The branch that you're working in, did it or its repo exist before you switched to bzr-svn 1.0.4 ?
[22:03] <glyph> jelmer: I guess it probably did.
[22:04] <glyph> If I locally clone into a new repo, will I work around it, or do I need to do a fresh clone from the server?
[22:04] <jelmer> glyph: I suspect one of the older versions of bzr-svn that you used probably introduced broken data
[22:04] <glyph> and do I need to blow away my svn cache
[22:04] <jelmer> glyph: A local clone will just copy the broken data, so you'd need a fresh one from the svn server.
[22:05] <jelmer> I don't think the cache would be affected but it's quite quick to regenerate so I would recommend blowing it away.
[22:05] <dash> glyph: a lot of times i've had odd issues with bzr-svn on 'pull' or 'up' that have gone away if i do a fresh pull from the svn server into a different branch, then in the afflicted branch do a pull from the fresh one
[22:06] <jelmer> dash: can you still reproduce that sort of thing with 1.0. 4?
[22:06] <dash> jelmer: i haven't yet, IIRC
[22:06] <dash> jelmer: if i do, i will let you know. :)
[22:06] <jelmer> dash: thanks
[22:08] <glyph> dash: OK, I'll try that first, I guess :)
[22:08] <glyph> sooo slow :(
[22:20] <mgz> hm, if I want to do a cosmetic edit to someone else's branch before merging it with hydrazine, is there a way? or would that have to be a whole new mp?
[22:22] <jelmer> mgz: I think that would have to be a whole new MP
[22:22] <mgz> argh, and bugger, I can't merge to 2.2
[22:22] <jelmer> at least, I can't think of a way around that..
[22:22]  * glyph discovers hydrazine and becomes excited
[22:22] <glyph> is there a bug-reporting GUI?
[22:24] <mgz> ...I struggle to envision how that would improve on a web browser
[22:24] <mgz> generally people want bug reporting clis
[22:25] <jelmer> glyph: I think bughugger is a GUI for bugs (among other things) on Launchpad
[22:26] <glyph> screenshots plz
[22:26] <jelmer> heh, I don't use it.. but I'm sure Google can help.
[22:26] <dash> http://www.murraytwins.com/blog/?p=60
[22:26] <dash> eeenteresting
[22:30] <glyph> jelmer: qannotate works on a fresh pull
[22:30] <glyph> erm, annotate, too ;)
[22:31] <jelmer> great (-:
[22:31] <glyph> pulling the fresh pull into my existing repo blows up with a different traceback though
[22:31] <jelmer> so that would've been a bug in an older version of bzr-svn that's since been fixed
[22:31] <glyph> I've saved the broken branch (branching it produces the same error) in case you're interested in me pushing it somewhere later
[22:31] <jelmer> glyph: yes, that's to be expected tas your existing repo has some broken data
[22:32] <glyph> gotta run now
[22:32] <jelmer> glyph: I would recommend cloning your existing branches into the new repo and getting rid of the old one
[22:32] <jelmer> I'm not really interested in the broken repo - the fact you've just successfully used annotate means this is an old bug.
[22:32] <jelmer> 'morning mwhudson
[22:32] <mwhudson> hi jelmer
[22:33] <mwhudson> jelmer: btw, is importing from a local git repo known to be broken in bzr-git currently?
[22:33] <jelmer> mwhudson: it was earlier, perhaps I forgot to push my fixes
[22:40] <mwhudson> jelmer: i think that might be the case
[22:40] <mwhudson> (i did this a couple of days ago, but i don't think i've seen any lp:bzr-git changes since)
[22:41] <jelmer> I'll check
[22:41] <jelmer> it reminds me...
[22:41] <jelmer> https://dev.launchpad.net/FailingBzrSvnImports, https://dev.launchpad.net/FailingBzrGitImports
[22:41] <jelmer> with much thanks to maxb
[22:42] <mwhudson> nice
[22:43] <mwhudson> 1.0.4 will be deployed tomorrow, right?
[22:43] <jelmer> yep
[22:43] <mwhudson> a few to retry then
[22:44] <mwhudson> https://dev.launchpad.net/FailingBzrGitImports#Nested%20trees is a bit uh, well....
[22:46] <ddaa> when 2.3 is out, someone will have the joy to update cscvs to deal with those too :-)
[22:46] <ddaa> Or maybe not...
[23:08] <mwhudson> ddaa: weeeeeeeeeeeeeeeeeeeeeeeeeeeeellllllllllllllllllllllllllll
[23:09] <ddaa> is that the sound of you falling in one?
[23:09] <jelmer> ddaa: nested trees in CVS? Do I want to know?
[23:09] <ddaa> module references
[23:10] <jelmer> aha
[23:10] <ddaa> historically, the policy was "just ignore those, only import the root module"
[23:10] <ddaa> conceptually, it's not very tricky
[23:11] <ddaa> I think svn externals are worse, with their ability to refer to branches in other repositories
[23:13] <mwhudson> ddaa: oh right
[23:13] <mwhudson> ddaa: well, actually the current policy is "just ignore those, only import the root module, then blow up doing the validation cross check at the end"
[23:14] <ddaa> oh right :-)
[23:14] <jelmer> ddaa: the main issue with svn externals is that they can create implicit directories
[23:15] <ddaa> I remember the motivation for not fixing this one was that anyway, cvs repos using those are essentially useless without the module references.
[23:15] <mwhudson> ddaa: it's CVS's fault really, if you do cvs co compound-module, the CVS/Root file (i think it's that one) only references the root module
[23:15] <ddaa> jelmer: that sounds like an instance of "I can't decide whether it's a branch or a directory"
[23:15] <mwhudson> "conceivably versions something" indeed
[23:16] <ddaa> mwhudson: right, I guess fixing that would have involved touching the graph magic lifeless put there once, and that I was never able to make sense of.
[23:18] <mwhudson> fortunately the day when one can just ignore cvs is getting closer
[23:18] <bialix> mgz: around?
[23:18] <mgz> yo bialix
[23:19] <bialix> yo martin
[23:19] <bialix> are you using hydrazine to send merge requests?
[23:19] <mgz> I am, want a tutorial?
[23:20] <ddaa> mwhudson: btw, I was a bit amused at noticing the import failure at ~vcs-imports/cvs/trunk
[23:21] <ddaa> also, lp REALLY needs a new icon for ~vcs-imports
[23:21]  * mwhudson hadn't seen that one
[23:21] <ddaa> not only my artwork sucks, but it does not make sense anymore
[23:21] <bialix> mgz: no, just a confirmation you're using it from windows machine and it's possible to install it for mere mortals
[23:22] <ddaa> it dates back to the time this was called ~buttress
[23:22] <bialix> lol
[23:22] <mgz> yup, about the only windows-hostile thing I've run into is the script you want to run doesn't have '.py' on the end
[23:22] <bialix> oh
[23:22] <bialix> then
[23:22] <mgz> launchpadlib does mean having to deal with setuptools, but that's a pain everywhere
[23:23] <bialix> [01:20]	<mgz>	I am, want a tutorial?  --- YES!!!
[23:23] <mgz> and there's 2.5ism in one of the many launchpadlib dependencies that I put a mp up to fix some months ago and have heard nothing about, so still have to patch locally
[23:25] <bialix> because you prefer py2.4, as I remember
[23:25] <bialix> that's ok
[23:25] <bialix> so, can I have a cookie, err, short tutorial how you install it?
[23:26]  * fullermd ships bialix a cookie.
[23:26] <bialix> *crunch* *crunch* yummy!
[23:31] <mgz> bialix: something like http://paste.ubuntu.com/490588/
[23:32] <mgz> and... I misplaced an apostrophe again
[23:32] <bialix> mgz: yummy, awesome, thanks!
[23:33] <mgz> yell if I got anything wrong there or you run into anything else, I might polish this up and post somewhere
[23:33]  * ddaa refrains from making a bad jokes involving poles and ukrainians
[23:34] <bialix> ddaa: :-P
[23:34] <bialix> I think I know this joke
[23:34] <ddaa> that would not be "spiritual" :-P
[23:34] <bialix> please, don't
[23:35] <ddaa> tell me about it!
[23:36] <bialix> in Ukraine we're usually telling jokes about unkrainians and russians
[23:40] <ddaa> next time you see sabdfl, ask him about that Baikonour launch operator he saw the day before he took off :-)
[23:41] <bialix> I'll note
[23:42] <bialix> at uds I was too shy to talk with him
[23:44] <ddaa> you're not alone there, but it's all in your head. He's remarkably level headed.
[23:44] <ddaa> Actually, I find that somewhat disturbing.
[23:45] <jelmer> n
[23:45] <jelmer> n
[23:46] <jelmer> grr, wrong window has focus
[23:50] <poolie> good morning
[23:58] <fullermd> jelmer: No, it's n w.
[23:59]  * bialix waves hello at poolie