=== cjwatson_ is now known as cjwatson
=== Ng_ is now known as Ng
=== Spaz_ is now known as Guest27683
=== Spaz|afk is now known as Spaz_
=== _thumper_ is now known as thumper
[02:04] <jml> $ bzr push sftp://<hostname>/<path>
[02:04] <jml> No revisions to pull.
[02:04] <jml> wtf?
[02:06] <Spaz_> did you specify trunk/ perhaps?
[02:06] <Spaz_> :)
[02:07] <jml> It's the "pull" bit that weirds me out.
[02:14] <lifeless> jml: using  loom?
[02:14] <jml> yeah.
[02:14] <lifeless> bug xxxxx
[02:15] <lifeless> (its open)
[02:15] <jml> it took me a while to figure out it was a loomified branch
[02:15] <jml> export-loom ftw
[02:24] <libwilliam> I'm working on parsing the bzr error messages in my program. I can't seem to find if there is a standard way of doing error messages in bzr. Do all error messages start with "bzr: ERROR: "?
[02:25] <jml> lifeless: can you merge my testresources branch please?
[02:28] <spiv> libwilliam: pretty much.  See bzrlib.trace.report_exception
[02:28] <libwilliam> spiv: thanks
[03:22]  * emmajane waves.
[03:22] <emmajane> I wanted to give the bzr_upload plugin a try, but it doesn't seem to want to load.
[03:23] <emmajane> I've downloaded it from launchpad and run the setup.py script, but I'm still getting:
[03:23] <emmajane> Unable to load plugin 'bzr_upload' from '/home/emmajane/.bazaar/plugins'
[03:57] <alecwh> Hello, can bazaar commit to a repository through the FTP protocol?
[03:57] <alecwh> push*
[04:00] <alecwh> And is it possible to grab the latest working version of a repository - not the entire history?
[04:00] <emmajane> alecwh: yes you can use FTP.
[04:00] <alecwh> emmajane: how would the command look, with a username and password, and can I get bzr to save the location, so I don't need to type it each time I want to push?
[04:01] <emmajane> I believe it's just: bzr push ftp://username@ftpserver
[04:01] <alecwh> emmajane: yes, but I have a password too.
[04:01] <emmajane> does it not prompt you for a password?
[04:02] <alecwh> emmajane: I haven't tried yet, I just assumed there was another variable to set.
[04:02] <alecwh> thanks!
[04:04] <emmajane> I think it should just work.
[04:15] <emmajane> alecwh: try also: bzr help
[04:15] <emmajane> and bzr help <command name>
[04:16] <emmajane> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
[04:21] <alecwh> emmajane: thanks
[04:21] <emmajane> did it work?
[04:31] <alecwh> emmajane: really sorry, haven't tried yet (not at my computer), I'll get back to you later though
[04:31] <emmajane> np
=== beuno-afk is now known as beuno
[07:49] <Kamping_Kaiser> can someone suggest a tool to keep track of bzr branches? (other then LP...)
[07:54] <mwhudson> Kamping_Kaiser: keeping track in what sense?
[07:55] <Kamping_Kaiser> mwhudson, via a web interface, as i recall (sorry, i wasnt clear)
[07:56] <mwhudson> Kamping_Kaiser: there's loggerhead
[07:56] <nosklo> I am having trouble using bzr-svn plugin. Tried both ubuntu hardy package and trunk version. Ubuntu hardy package segfaults on bzr selftest svn.
[07:56] <mwhudson> it can browse directories now, so you can just point it at the directory containing all your repos, for example
[07:56] <Kamping_Kaiser> mwhudson, thanks, i'll go and check it out
[09:00] <fdv> nosklo: have you tried installing the most recent bzr-svn locally (in ~/.bazaar/plugins)?
[09:00] <fdv> that bit me yesterday
[09:01] <nosklo> fdv, using ubuntu package bzr + recent bzr-svn?
[09:01] <fdv> nosklo: what was the question?
[09:01] <nosklo> fdv, getting bzr-svn to work somehow
[09:02] <fdv> nosklo: yes, but what did you just ask me?
[09:02] <fdv> whether I use "ubuntu's" bzr and not ubuntu bzr-svn?
[09:02] <nosklo> fdv, I can't make it work. I have tried: installing bzr and bzr-svn packages, and installing bzr.dev and bzr-svn trunks
[09:03] <fdv> ok..
[09:03] <nosklo> fdv, I am asking if maybe combining the package with the trunk
[09:03] <fdv> which bzr version?
[09:09] <fdv> nosklo: if you get your packages from http://ppa.launchpad.net/bzr/ubuntu it seems to me you _should_ be fine
[09:10] <nosklo> fdv, I will try.
[09:11] <fdv> nosklo: otherwise, check which bzr version you have and compare to http://bazaar-vcs.org/BzrForeignBranches/Subversion#releases
[09:12] <fdv> I have bzr 1.6.1 and bzr-svn 0.4.12, which at least to me seems to be a combination that works
=== beaumonta is now known as abeaumont
[09:39] <fdv> uhm.. pqm depends on config-manager, which in turn depends on pybaz. the latter is no longer in use, is it?
=== beaumonta is now known as abeaumont
=== fta_ is now known as fta
[13:47] <Leonidas> hi
[13:47] <Leonidas> could someone take a look at the changes between aaron.bentley@utoronto.ca-20070517163555-3i7jamitmffdg85l and aaron.bentley@utoronto.ca-20070611021058-7mqy4fsayv27zper
[13:48] <Odd_Bloke> Leonidas: Umm, in what context?
[13:50] <Leonidas> Odd_Bloke: there is a change with the fileid TREE_ROOT and I'd like to ask someone what that means.
[13:51] <Odd_Bloke> Leonidas: In what branch?
[13:51] <Leonidas> Odd_Bloke: bzr.dev
[13:51] <Odd_Bloke> Right, that's all I was looking for. :)
[13:52] <Leonidas> iter_changes gives me ('TREE_ROOT', (None, u''), True, (False, True), (None, None), (None, u''), (None, 'directory'), (None, False))
[13:52] <Odd_Bloke> Leonidas: It'd be more normal to use revnos for a branch like bzr.dev.
[13:53] <Leonidas> Odd_Bloke: right, but I don't have the revno.
[13:54] <Leonidas> when working with bzrlib, one almost never gets any revnos
[13:57] <Leonidas> abentley: do you have a moment and can take a look on that changeset?
[13:59] <abentley> Leonidas: That looks like it's creating the root directory.
[14:00] <Leonidas> abentley: how is this possible? The root directory must have existed earlier.
[14:00] <abentley> There may have been a different root directory
[14:01] <abentley> Yes, the root directory for aaron.bentley@utoronto.ca-20070517163555-3i7jamitmffdg85l was "tree_root-20070410133226-3795pjcs6oz73ncz-1"
[14:02] <Leonidas> abentley: how can something like this be reproduced? TREE_ROOT looks like it is something special, whereas tree_root-2007... is not.
[14:03] <abentley> Leonidas: Using bzrlib, you should be able to set whatever tree root you want.
[14:07] <Leonidas> abentley: how? By modifiying a revision tree's inventory?
[14:08] <abentley> Leonidas: By calling set_root_id on a WorkingTree.
[14:08] <Leonidas> ah!
[14:09] <abentley> I should point out that released versions of bzr will always select TREE_ROOT if the repo format isn't a rich root format.
[14:11] <Leonidas> but, erm, what use does it have to be able to change the TREE_ROOT? I'm trying to understand this, but somehow a the root directory cannot track any changes like setting it +x or something.
[14:12] <abentley> The root directory can do anything any other directory can do.  Especially, it can be moved and renamed.
[14:14] <abentley> Or deleted, even.  This tends to happen when splitting one tree into two.
[14:14] <Leonidas> I see, didn't know that. I always thought about the root directory to be just a container for the content.
[14:16] <Leonidas> abentley: ok, thanks a lot. Now that I can reproduce this in simple repositories, I can figure out that to do.
[14:16] <abentley> you're welcome.
[15:34] <Leonidas> abentley: I suppose there needs to be a file/directory with that fileid already created to set_root_id, right? But the ``bzr`` program seems not to have any problems with nonexistent root_ids
[15:41] <Zelgadis> Hi! Does bzr supports nested trees?
[15:58] <Teddy> Zelgadis: Apparently, yes.
[15:59] <Zelgadis> Teddy: how?
[15:59] <Teddy> Zelgadis: http://bazaar-vcs.org/NestedTrees
[16:00] <LarstiQ> I might need to update that soon
[16:00] <LarstiQ> Zelgadis: I guess the answer is: it's not where we want it yet, but you can do a number of things already
[16:01] <Zelgadis> wow, thank you
[16:01] <LarstiQ> Zelgadis: if you can desribe your use case more clearly I can give more detailed directions.
[16:03] <Zelgadis> ok. I have a directory with a lib, doc, layouts and episodes
[16:04] <Zelgadis> every person, who works on particular episode will need lib folder
[16:04] <Zelgadis> but some person don't need lib folder, he just wants the doc folder
[16:06] <Zelgadis> that's the complex case. But I can simplify it.
[16:08] <LarstiQ> Zelgadis: I see, nested trees would ease working like that
[16:09] <Zelgadis> yep. The main purpose is to reduce bandwidth usage
[16:09] <Zelgadis> every episode is extremely huge
[16:09] <LarstiQ> Zelgadis: right, I would recommend keeping each episode in its own branch.
[16:10] <LarstiQ> Zelgadis: but you can work with multiple branches like that without having nested-trees, it will be more manual work that way
[16:11] <Zelgadis> LarstiQ: If I'll do it without ConfigManager then everytime user do a checkout a whole repository history will be retrieved, right?
[16:13] <LarstiQ> Zelgadis: cm doesn't impact that aspect, it just takes away some of the manual aspect of checking out different trees into a hierarchy
[16:13] <LarstiQ> Zelgadis: so, you have a couple of seperate problems to be solved
[16:14] <LarstiQ> Zelgadis: one thing you mentioned is breaking up into multiple branches because each individual episode is very big
[16:14] <LarstiQ> Zelgadis: another thing might be that you don't want all history for one specific episode when you're working on it
[16:15] <LarstiQ> Zelgadis: options to help there are stacked branches or lightweight checkouts
[16:15] <Zelgadis> LarstiQ: yes, lightweight checkouts - is a option because I've choosed the bazaar among others VCS
[16:15] <LarstiQ> Zelgadis: what is the workflow like on an episode? Do people need to work against the history often?
[16:16] <Zelgadis> LarstiQ: what is a stacked branches?
[16:16] <Zelgadis> Yes we doing commits often
[16:17] <LarstiQ> Zelgadis: stacked branches allow you to have only some of the historical data yourself, and for older revisions to talk to the branch they are stacked upon
[16:17] <LarstiQ> Zelgadis: it's a feature introduced in 1.6, see --stacked in `bzr help branch` for instance
[16:18] <LarstiQ> Zelgadis: for committing you don't need to access history, diff and log are cases where you need older revisions
[16:20] <Zelgadis> LarstiQ: But if I want to commit locally?
[16:20] <Zelgadis> (with a lightweight checkout that's seems impossible)
[16:20] <Zelgadis> But that's not a big problem.
[16:21] <LarstiQ> Zelgadis: correct, a lightweight checkout needs to contact it's master for everything
[16:21] <LarstiQ> Zelgadis: a stacked branch doesn't need to, it can operate locally
[16:21] <Zelgadis> nice
[16:22] <LarstiQ> Zelgadis: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches
[16:23] <LarstiQ> Zelgadis: out of curiousity, what is an episode?
[16:23] <Zelgadis> cartoon episode - source files (.blend, .sif, .xcf, .kra)
[16:24] <LarstiQ> ooh, cool
[16:25] <Zelgadis> LarstiQ: You may find more at http://morevnaproject.org/
[16:25] <Zelgadis> althrough, not much there yet
[16:27] <Zelgadis> LarstiQ: So, back to the NestedTrees problem - all I need, is just organize folders in branches
[16:28] <LarstiQ> Zelgadis: yeah
[16:29] <LarstiQ> Zelgadis: it sounds to me like most people will only have one or two branches (lib/episodeX or doc) at a time
[16:30] <Zelgadis> yep
[16:31] <LarstiQ> Zelgadis: in that case it isn't too much overhead to just get them by hand
[16:33] <Zelgadis> the problem is what I need some files (like Makefile and README) at the root of branches
[16:33] <Zelgadis> outside the branches
[16:34] <LarstiQ> Zelgadis: you could do something like: cd morevna; bzr branch http://host/environment; cd environment; bzr branch http://host/episodeX
[16:35] <Zelgadis> LarstiQ: ...and tell to .bzrignore in environment to ignore the subdirectories?
[16:35] <LarstiQ> where environment has the Makefile, README and all other things you need for all of them
[16:35] <LarstiQ> Zelgadis: bzr will do that automatically
[16:36] <LarstiQ> or well, I should rephrase that
[16:37] <LarstiQ> Zelgadis: if you have a bzr branch in another bzr branch, bzr status will not list all the files in that inner branch as unknown
[16:37] <Zelgadis> cool!
[16:37] <LarstiQ> Zelgadis: it will see that the directory is a bzr branch, and not recurse into it
[16:37] <Zelgadis> didn't know that - that simplifies things!
[16:37] <LarstiQ> Zelgadis: it will show up only once as an unknown dir
[16:38] <Zelgadis> but we could still add that unknown dir?
[16:38] <Zelgadis> LarstiQ: it will help people to figure out what branches they could need
[16:39] <LarstiQ> Zelgadis: not `bzr add`
[16:39] <LarstiQ> Zelgadis: what do you mean, figure out what branches they need?
[16:40] <Zelgadis> LarstiQ: so, they appear as unknown, but 'bzr add' won't add them?
[16:40] <LarstiQ> (and not recursing into unknown directories is something bzr does for all unknown dirs btw)
[16:40] <LarstiQ> Zelgadis: correct
[16:41] <LarstiQ> Zelgadis: try: cd /tmp; bzr init foo; cd foo; bzr init bar; bzr st; bzr add bar; bzr st;
[16:42] <Zelgadis> LarstiQ: Ah, understand. That's ok.
[16:43] <Zelgadis> LarstiQ: Thanks alot!
[16:44] <LarstiQ> Zelgadis: np :)
[16:44] <Zelgadis> back to work ^___^
[16:55] <Leonidas> bzrlib.errors.InconsistentDelta: An inconsistent delta was supplied involving 'newdir/secondfile', 'secondfile-20080921155404-xxpouw03i8s29crx-3'
[16:55] <Leonidas> reason: This was marked as a real delete, but the WT state claims that it still exists and is versioned.
[16:56] <Leonidas> hmm, this is strange.
[16:56] <Leonidas> I just tried to change the root_id to the id of the subdirectory newdir, but that does not seem to work.
[16:57] <LarstiQ> Leonidas: that would give two paths with the same file_id, no?
[17:12] <stewart> lifeless: ping?
[17:12] <ronny> hi
[17:13] <ronny> how can i convert a branch with rich root support into one without rich root support?
[17:13] <stewart> ronny: bzr upgrade (has parameters)
[17:14] <stewart> anybody know if you can combine two bzr trees for separate projects (i.e. no common history) into one?
[17:14] <LarstiQ> stewart: bzr merge -r 0..-1 otherbranch
[17:14] <ronny> stewart: it goes only in one direction
[17:15] <LarstiQ> stewart: you may want to move the contents of one of them into a subdir to reduce conflicts
[17:15] <ronny> stewart: i can convert from non-rich to rich, but not back
[17:15] <stewart> ronny: okay - not 100% of that.
[17:15] <stewart> LarstiQ: that's what we'd do. it's adding a storage engine into the mysql tree that's been maintained externally.
[17:15] <LarstiQ> ronny: that would be because a non-rich root format can not represent all of the information in a rich root format
[17:16] <LarstiQ> ronny: so by default that isn't possible. May I ask why you'd want to do so?
[17:16] <LarstiQ> stewart: ah, I see.
[17:16] <ronny> cause the remote is not a rich repo
[17:16] <ronny> and i want to push
[17:17] <ronny> however bzr doesnt let me to
[17:18] <LarstiQ> right, for the reason I just mentioned.
[17:18] <LarstiQ> ronny: upgrading remote isn't feasible?
[17:19] <ronny> i could do that, but its just my branch of another project, i dont want to enforce anything and i dont want to redo the cahnges i did
[17:19] <LarstiQ> ronny: right.
[17:19] <ronny> what kind of metadata does the rich-root hold, cause im pretty sure i dont use any of it
[17:19] <stewart> LarstiQ: just tested the merge command above, worked great. thanks!
[17:21] <LarstiQ> ronny: the root path gets to have a real file_id, which enables you to move it and such.
[17:22] <LarstiQ> ronny: I'm looking for ways to help you deal with this, without having to exercise bzrib directly.
[17:23] <LarstiQ> next up, rebase
[17:24] <ronny> hu?
[17:24] <LarstiQ> ronny: I looked at creating a bundle and applying that, didn't work. Now I'm looking at rebase.
[17:25] <ronny> hmm, the __dozenz__ of partially incompatible repo formats are a pain :/
[17:25] <LarstiQ> __dozenz__?
[17:26] <ronny> well, i count at least 6 of them
[17:26] <ronny> well, more like 13
[17:27] <LarstiQ> ah, dozens, not a python __attribute
[17:31] <Leonidas> LarstiQ: no, not really, since the newdir has a different fileid than '' which has the fileid TREE_ROOT.
[17:32] <LarstiQ> Leonidas: but you said you dit set_root_id(newdir_id)?
[17:33] <LarstiQ> ronny: I can't really think straight right now
[17:34] <LarstiQ> ronny: but I'd try the list next
=== BasicPRO is now known as BasicOSX
[18:30] <Leonidas> LarstiQ: yeah, I had a working tree with the root id set to TREE_ROOT and then I tried changing it to the file-id of my subdirectory
[18:58] <fdv> anybody around who might have a hint or two on how to get pqm working?
[18:58] <fdv> or are there alternatives?
[19:42] <Odd_Bloke> fdv: What are you struggling with?
[19:54] <fdv> Odd_Bloke: pqm requires config-manager, which requires pybaz
[19:55] <Odd_Bloke> fdv: Yes.
[19:55] <fdv> afaik, baz, and therefore pybaz, is discontinued
[19:55] <Odd_Bloke> Yes.
[19:55] <Odd_Bloke> It's a bug in CM, rather than PQM.
[19:55] <fdv> yes, I presumed as much
[19:56] <fdv> but I don't really know neither pybaz, nor bzrlib very well, so migrating is a rather tough option :)
[19:56] <Odd_Bloke> fdv: PQM doesn't require you to use baz.
[19:57] <Odd_Bloke> It just required libraries for using baz to be installed.
[19:57] <Odd_Bloke> Which is why it's such an irritating bug.
[19:57] <fdv> right, so pybaz is enough?
[19:57] <Odd_Bloke> fdv: Enough for what?
[19:58] <Odd_Bloke> If you want to use PQM for bzr, you only need what's in PQM.  Unfortunately, PQM currently requires config-manager which requires pybaz, but that's orthogonal to what you really need.
[19:58] <Odd_Bloke> fdv: What platform are you on?
[19:59] <fdv> Odd_Bloke: ubuntu
[19:59] <fdv> sorry, was distracted a moment
[20:00] <Odd_Bloke> fdv: 'apt-get install config-manager' should be enough for PQM to not complain about it. :)
[20:00] <fdv> the config-manager package is broken, as it depends on pybaz, but that one doesn't exist
[20:00] <fdv> ...anymore
[20:01] <Odd_Bloke> *shakes fist at Ubuntu*
[20:01] <fdv> still, when trying to use config-manager from source, there are lots of 'import pybaz' statements in there
[20:01] <fdv> so I can't really see how it'd work
[20:01] <fdv> oh, right
[20:01] <Odd_Bloke> Try using https://code.launchpad.net/~daniel-thewatkins/pqm/config-manager
[20:02] <fdv> maybe that code is only called when one uses baz
[20:02] <Odd_Bloke> fdv: That code _should_ only be called when one uses baz.
[20:02] <fdv> right, I see
[20:02] <Odd_Bloke> Unfortunately, it is not.
[20:02] <fdv> oh
[20:02] <fdv> bummer
[20:02] <Odd_Bloke> Hence the whole issue. :p
[20:02] <fdv> sounds like it should be fairly easy to fix
[20:03] <fdv> I see
[20:03] <Odd_Bloke> fdv: Patches welcome. ;)
[20:03] <fdv> hehe :)
[20:03] <Odd_Bloke> I've spent a little while looking at it (I worked on PQM over the summer), but didn't get very far.
[20:03] <fdv> so config-manager is only needed by pqm when used with baz, is it so?
[20:03] <Odd_Bloke> fdv: Nope, CM isn't _needed_ even then.
[20:03] <fdv> ok, but it _can_ be used
[20:04] <Odd_Bloke> Yeah, but it also _can_ be used when you're using PQM with bzr.
[20:04] <fdv> but it might also be nice to have with bzr?
[20:04] <fdv> right
[20:04] <Odd_Bloke> It should be completely independent of baz.
[20:04] <Odd_Bloke> But it's not.
[20:04] <fdv> I see
[20:05] <Odd_Bloke> fdv: Actually, that's not the branch you should use.
[20:05] <fdv> oh
[20:05] <Odd_Bloke> fdv: It depends on a lot of other unmerged work.
[20:06] <fdv> right
[20:06] <Odd_Bloke> fdv: If you don't want to use config-manager, ISTR that just removing the imports works.
[20:06] <Odd_Bloke> Which is nasty, but will let you get on with things.
[20:07] <fdv> ok
[20:07] <fdv> (another issue, btw, is that config-manager won't build without the dir ./libgetopt, which is not there, but I nicked it from the .deb)
[20:07] <fdv> Odd_Bloke: what would I need config-manager for anoway?
[20:08] <Odd_Bloke> fdv: If your build required you to pull in a few branches.
[20:08] <Odd_Bloke> It's _kinda_ like svn:externals.
[20:08] <fdv> aha
[20:08] <fdv> makes sense
[20:08] <fdv> kind of hard to put the pieces together without prior knowledge :)
[20:09] <fdv> (this channel, of course, is _very_ helpful in that respect :))
[20:09] <Odd_Bloke> fdv: Yeah, PQM is still fairly obtuse.
[20:11] <fdv> config-manager seems to be a bit out of date, actually
[20:11] <fdv> though maybe I just don't understand it
[20:11] <Odd_Bloke> Well, it depends on pybaz, which is a reasonable indicator. :p
[20:12] <fdv> under implementations, there is only arch_vcs.py and fake_vcs.py
[20:12] <Odd_Bloke> Yeah, that's where the baz and bzr stuff should be.
[20:13] <fdv> only baz, afaics
[20:13] <Odd_Bloke> Whereas currently it's intermingled with the core code.
[20:13] <fdv> aha
[20:13] <fdv> I see
[20:14] <fdv> doesn't sound like a very pleasing place to start :)
[20:14] <fdv> Odd_Bloke: thanks a lot, at least I know part of the rationale now and I might be able to get it together
[20:14] <Odd_Bloke> fdv: No worries. :)
[21:34] <fdv> Odd_Bloke: wouldn't it make sense in pqm to import config_manager only inside the two methods using it?
[21:34] <fdv> I'm not sure if I see why that is ugly
[22:01] <Odd_Bloke> fdv: It would make sense, I think.
[22:14] <lifeless> stewart: yo
[22:37] <libwilliam> I was doing some messing around with the different commands to see what they did and now my tag revnos are listed as ?.. My guess is because I uncommitted the revisions that had tags. So if this is the case I was wondering if those tags should even exist?
[22:40] <Odd_Bloke> libwilliam: Those tags will point at the old revisions.  The '?' just means that those revisions don't have a revision number in this branch (as they are not part of the history).
[22:42] <libwilliam> Alright, well I am trying to do a bzr log -r tag:<tag with ?> and I am getting a crash
[22:42] <libwilliam> Is this worthy of a bug report?
[22:43] <jelmer> libwilliam, please
[22:43] <libwilliam> jelmer, k
[22:44] <rsc-> Is there a way for me to use "meld" to resolve conflicts when merging?
[22:48] <beuno> jml, hi
[22:48] <beuno> I've given your lp stacked branch experiment a spin
[22:48] <beuno> and I get this: http://paste.ubuntu.com/49082/
[22:49] <beuno> I have a shared repo
[22:52] <jml> beuno: oh, the branch called 'experiment' is broken.
[22:53] <jml> beuno: but even if it was ok, if you branch it locally, it should work, and won't be stacked unless you say --stacked
=== davi__ is now known as davi
[22:56] <rsc--> Is there a way for me to use "meld" to resolve conflicts when merging?
[23:00] <beuno> jml, that explais it, thanks
=== beaumonta is now known as abeaumont