[00:02] mwhudson: ui api changes [00:02] mwhudson: silentuifactory is generally regarded as testing only so if you're using it in production you may need to fix it. [00:03] lifeless: all i was doing is calling run_bzr [00:03] but ok [00:03] anyway, i cribbed some code to set a ui factory and it works now [00:03] mwhudson: oh, so the default 'call run_bzr' breaks now? I'd really like it if you file a bug about that. [00:04] lifeless: yes; ok [00:06] lifeless: https://bugs.edge.launchpad.net/bzr/+bug/499637 [00:06] Ubuntu bug 499637 in bzr "run_bzr() fails unless you set a ui factory" [Undecided,New] [00:09] poolie: No idea, sorry [00:10] in general, CIFS shares should have the same semantics as NTFS drives [00:21] mwhudson: it does mean something to me [00:21] mwhudson: it means that you're calling code that wants to do an output stream but you've asked it to be silent [00:21] so you have to make up your mind :) [00:21] or fix one of these things [00:22] poolie: i haven't asked for it to be silent; that's the default [00:22] spiv: bug 495023 is nice :) [00:22] Launchpad bug 495023 in bzr "Interrupting commit to smart server sometimes removes files" [High,Confirmed] https://launchpad.net/bugs/495023 [00:22] poolie: I think you misread the no idea comment, it was from jelmer [00:22] poolie: and I think SilentUI should eat an output stream :) [00:22] lifeless: no i didn't [00:22] poolie: if by nice you mean "signals are die die die" :) [00:23] s/are/argh/ [00:23] (weird typo!) [00:24] how do I change the submit branch that shows up in bzr info? [00:24] poolie: ok [00:24] :) [00:25] poolie: ah I see, it made sense to the earlier comment ;) [00:25] scorp007: via bzr submit [00:25] oh [00:26] there's no such command? you mean send? [00:27] yes [01:02] poolie: and boom, it lands === abentley1 is now known as abentley [01:37] james_w: I've blogged about getting started with bzr-builddeb [01:41] http://radar.oreilly.com/2009/12/the-best-and-the-worst-tech-of.html [01:42] I love the quote about scrum-as-practiced :) [02:40] Launchpad should announce new merge proposals in this IRC channel. [02:50] spiv: statik has a thingummy that does that [02:50] (it works off email i guess) [02:51] Yeah, something email triggered would do I suppose. [02:51] I don't want to look after an IRC bot, I want someone else to do all the hard work :) [02:53] i suggest you talk to statik then [02:53] yo [02:53] ! [02:53] all i had was a procmail rule the spit text at radix's publishbot [02:54] niemeyers mup supports the same interface [03:54] poolie: where does make_uifactory_for_stream live? [03:54] oh hang on, maybe the checkout i'm grepping is out of date [03:54] actually make_ui_for_terminal [03:54] in bzrlib.ui [03:54] ah ok [03:54] you know what i mean :) [03:54] ui.ui_factory = ui.make_ui_for_terminal( [03:54] sys.stdin, sys.stdout, sys.stderr) [03:54] doing this seems to work [03:55] (i cargo culted that from some where else) [04:03] jml, still around? [04:34] poolie, yes. [04:48] okay, used explorer to make a trunk "repository" on my hard drive for something, how do I push it up to lp? [06:16] lifeless: first test against testtools trunk and it fails with an AttributeError :/ [06:17] poolie: ugh :( pastebin ? [06:18] self.exception_handlers.insert(0, [06:18] AttributeError: 'TestAdd' object has no attribute 'exception_handlers' [06:19] Oh? In what, lp:bzr? [06:19] poolie: that indicates you have an old testtools version [06:20] poolie: definitely not trunk, or 0.9.2 [06:20] it does look like it [06:20] i'm pretty sure i have trunk [06:20] python -c 'import testtools; print testtools.__file__' [06:20] ah maybe i have jml's old trunk [06:21] i thought you were going to check the version? [06:26] https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/16525 [06:26] bit of a bug in lp that this can happen [06:28] that what can happen? [06:28] that i can do 'bzr pull' in a checkout of testtools trunk, but not get what's the new trunk [06:28] yes [06:28] this can be seen as a bug in putting the owner into the url [06:29] if jml had moved the branch you would have gotten an error [06:29] right [06:29] I consider the bug to be bzr storing the resolved branch though [06:29] Well, there can be more than one bug :) [06:29] anyhow [06:29] spiv: true, but I *like* owner in url :P [06:29] does it? [06:30] spiv: I'll agree to 'side effect' [06:30] i guess it does, though it's possible i just used the full url originally [06:30] anyhow [06:30] i am glad this is in [06:30] i'd like to tweak the display to show errors as they happen [06:30] and that's better done not specific to bzr [06:30] poolie: yes, bzr branch lp:foo -> parent will be bzr+ssh://b.l.n/foo/~bar/baz [06:30] assuming it can be merged [06:31] poolie: so, errors showing as they happen - change bzr's reporter to not use the 'current global ui factory' and instead cache the ui factory it is started with. [06:32] ok [06:32] that sounds good [06:32] poolie: tests running with silent ui are hiding reporting of things via note() - I saw this, but its an orthogonal change to the root class [06:32] what's the connection? [06:32] ah [06:34] if you run with --parallel=fork, the global ui isn't ever changed, and the current encoded behaviour can be seen. With a normal run, things get masked. [06:34] poolie: btw you can use the testtools packages in the beta ppa - or install the subunit releases ppa and get subunit and testtools from there. [06:35] i know [06:35] poolie: I'm happy for you to run from trunk of these dependencies, just want to be sure you know its optional. [06:35] but i may actually patch them [06:35] so (barely) slightly easier to start with branches [06:35] poolie: sure. They both have bzr packaging branches, so you can patch with packages too :) [06:36] poolie: fwiw I run from packages on them, regardless of patched-or-not, it just works out easier overall, I think. [06:37] definitely helps by the time there are binaries [06:40] Someone next year I'll do the 'include the failed test work area' patch [06:40] using the addOnException TestCase api to add a tarball detail [06:41] s/Someone/Sometime/ [07:04] poolie: well, I find it has a bunch of benefits; I find out about things that would make packaging harder (such as files not included in the tarball) early; [07:04] I don't need to remember to set the python path [07:04] true [07:04] ok, maybe i'll build from them [07:04] and I don't need to futz with a local python install getting in the way in the future. [07:04] k [07:05] signing off soon [07:07] see you in the new year [07:17] Ok, I'm off too. [07:22] * lifeless sniffs [07:23] I can't tell from here [07:23] Peng: new test dependency [07:23] * Peng nods [07:35] Peng: its in lucid, or the bzr-beta-ppa [07:36] I've got it from source. [07:43] kk [07:55] hi [08:11] I like playing with --parallel, so I already needed it anyway. :P [08:11] Besides, I don't run the test suite much. [08:19] Peng: :P [08:22] I should probably RTFM, but: subunit is a superset of testtools, right? And bzr now always depends on testtools, but only uses subunit for --parallel, right? [08:22] subunit is orthogonal to testtools [08:22] It doesn't depend on testtools? [08:22] it does [08:23] so its a superset in the same way that bzrlib is a superset of testtools :) [08:23] Heh, okay. [08:24] subunit is: a protocol definition, serialiser in [languages], parser in [languages] and command line filters for the protocol. [08:29] Oooh. [08:36] e.g. see libcppunit-subunit-dev - link that in and use it as your test reporter, and you can use subunit-filter,subunit-stats, subunit-tags etc with your favourite cppunit using test suite. [08:36] and even subunit-diff [08:51] lifeless: is there any buildin sheduling in subunit [08:51] (i.e. choosing what tests get executed) [08:52] ronny: no, but it encourages an idiom of having unique ids for tests, and you can use subunit-ls to turn a stream into a \n separated list of test ids [08:52] which works very will with runners that support choosing based on test id (such as bzr, or zopes test runner) [08:53] ronny: however, the python 'subunit.run' module can select tests with whatever granularity you give it. It would be appropriate for that module to gain a --load-list feature, I think. [08:54] ronny: (wouldn't help non-python runners, but would be convenient for python folk) [08:55] lifeless: im thinking in terms of 2-way communication in ad-hoc networks [08:57] ronny: subunit itself is unidirectional, but it should play nice in larger systems that do 2-way stuff (an example of which is vilas patch to bzr selftest --parallel to feed small chunks to the worker processes) [08:57] at least thats what we want to build for py.test and possibly others [08:57] ronny: sure, I'd be delighted to see subunit as part of that [08:58] lifeless: does it have separate message lines for collect/discover and run? [08:58] it doesn't have the first two concepts [08:59] then there is little use for it [08:59] I think thats a premature opinion [08:59] for several reasons [09:00] firstly, subunit passes things it doesn't understand through, so you can embed it in other protocols without needing special out-of-band signalling [09:01] secondly, setup and control of a test process is a very different problem to machine readable output from the test process; its the latter that subunit provides (and pretty nicely now, I think). [09:02] lastly, setting up a remote process isn't a test protocol problem, its a remote execution problem, and there are plenty of tools to do that today, so I don't see why you'd want to write it again :) [09:02] the other test protocols around: [09:02] pandokia [09:02] tap [09:03] junit-xml [09:03] none of them provide for setting up a remote process [09:03] (pandokia in aggregate does, but not in its test description format) [09:05] hmm [09:05] i suppose i really ought to take another look [09:06] discovery/feedback will be an important part tho [09:06] I never said it wasn't important :) [09:06] what do you mean by feedback [09:06] you said collect/discovery before [09:07] lifeless: test nodes report the tests they discover, the node manager gives feedback on if they should run it [09:07] ronny: why do it that way? [09:08] the set of tests that gets run depends on the platform/environment [09:08] sure [09:08] but that doesn't imply chatty protocols [09:10] lifeless: well, parallelize test-runs over a ad-hoc network and it suddenly gets handy [09:11] something needs to keep track of what tests had been executed [09:11] ronny: here is a different way: master node calculates all tests, inspects for machine requirements, partitions by available machines and their info [09:12] thats a lot more tricky than just letting things happen and react according to that [09:13] anyhow.. here is how you can do the approach you have in mind with subunit easily [09:14] from the node send "available: id\n" to advertise a test that can be run [09:14] on the node read "run: id\n" to run a test, and EOF to shutdown the node [09:15] yes, thats along what i was thinking [09:15] lifeless: feel like adding that as optional extension to subunit, so runners for other languages can add it? [09:16] on the master, hook each nodes output up to either a subunit.ProtocolTestCase or subunit.TestProtocolServer (if you are running twisted or asyncore you'll want the second) [09:16] lifeless: we'll most likely be using execnet at least for the setup [09:16] to hook it up, use [09:17] parser = ProtocolTestCase(stream, passthrough=extra) [09:17] where extra is a closure with a write method, [09:17] that write method will get called with "available: id\n" and any other extensions you have. [09:18] and to kick if off with ProtocolTestCasse, do run(masterresultobject) [09:18] using the TestProtocolServer is slightly different, but not much. [09:18] you need to arrange to call lineReceived for it. [09:19] ronny: are you saying 'reserve the token "available" so that other folk doing similar things might choose the same token'? [09:19] lifeless: yes [09:19] ronny: If so, I'm happy to note that your project is doing this in the subunit docs [09:19] also the token run [09:19] ronny: subunit won't see the token run at all [09:20] ronny: subunit is unidirectional [09:20] lifeless: just as note in the docs, so other folks know the feedback protocol [09:20] sure [09:20] well, actually run and skip [09:20] ronny: why would you need skip ? [09:21] ronny: only tell it to run things you want it to run :) [09:21] lifeless: then the collect/run parts would have to be async [09:22] I don't see the connection. [09:23] ronny: so, I think a document describing what you're doing and how it hangs together would be great; that could be either included in subunit, or referenced from subunits docs, depending on how you write it and what focus you put in it. [09:23] ronny: one thing I've been considering doing is making subunit easier to install with e.g. pip or easy_install. [09:24] ronny: I mention this in case ease of install comes up for you. [09:24] lifeless: please do that, we'll most likely use virtualenvs [09:27] lifeless: as far as i remember various testrunners execute tests as they find them, and dont collect the whole suite before starting test runs [09:27] ronny: only nose does that [09:27] ronny: you can use a lazy loader to do that in any unittest runner that can run a callable (e.g. via the test_suite idiom) [09:29] thats why a skip directive would be helpfull [09:29] ronny: sorry, I still don't follow [09:29] just report what you find as you go, and get feedback on if you should run the tests [09:30] ronny: yes, I get that, but I don't see why you need a skip directive on the control side [09:30] i dont like having to guess the dont cases [09:31] seems like a waste to me, but sure, I can see how it would work [09:31] i want to have a simple sync loop along while test=find_next() { report; read action; if action { run }} [09:32] I think that would be very slow [09:32] I'd do [09:32] tests = find_all() [09:32] advertise_tests(tests) [09:32] to_run = (read all run: commands) [09:32] tests.filter(to_run) [09:32] run_tests(tests) [09:33] well, with the last three lines in a loop [09:33] lifeless: i dont want to tell them all to run at a time [09:33] read one or more run commands, execute, look for more [09:34] ronny: sure, but that is orthogonal to discovering them all at once, isn't it ? [09:34] i like more granular events tho [09:34] ronny: I have some experience with this, having done --parallel and --parallel=ec2 for bzr; you really don't want to be waiting for network latency on each test [09:35] hmk [09:35] if you have enough tests that multi machine parallelisation is worth doing, per test latency will kill your performance. [09:35] unless your tests are several times slower than that latency [09:37] hmm, well, mine probably are, but other are most likely not [09:44] lifeless: i just discovered that mine and holgers mindmodels rather differ (his already solved the latency stuff, i suppose other issues as well) [09:45] well, mail me :) or t-i-p, or something :) [09:47] lifeless: yes, i'll get my mindmodel fixed, then i suppose start something on tip [11:52] hi all, sorry if this is covered in a faq: [11:53] can i pull in a file from a repository which *does not* share a common ancestor with my current branch? [11:53] (keeping history) [12:00] Kamping_Kaiser: you can merge in an entire, unrelated branch. bzr in general can't track revision history when cherrypicking just parts of revisions (like single files rather than all changes) [12:02] spiv: the branch is 1 script + a README, as long as the merge doesn't eat my existing README that would be fine for me. [12:03] Kamping_Kaiser: cool [12:03] Kamping_Kaiser: the trick then is "bzr merge -r0..-1 ../unrelated_branch [12:03] " [12:03] Kamping_Kaiser: The README will probably conflict. Anyway, even if it does get eaten, nothing's set in stone until you commit; you can just revert it. [12:04] it'll probably give a path conflict about the README file; they'll both be there (one will be README, the other README.moved, probably) [12:04] spiv: if i understand that correctly, from revision 0 until latest revision? [12:04] Kamping_Kaiser: Uh-huh. [12:05] you can 'bzr mv' and/or 'bzr rm' things before committing of course to make sure they are how you want them. [12:05] Peng: re README, noted, I'll try and see what happens. [12:05] Conflict adding file README. Moved existing file to README.moved. [12:05] Kamping_Kaiser: right. The zeroth "revision" is in a sense a common ancestor for all branches :) [12:05] *grin* [12:06] I'm interested that the existing readme is moved, rather then the new one. [12:07] Yeah, I'm not sure why that choice was made. Possibly a coin toss came up heads rather than tails when the implementer had to choose ;) [12:08] hehe. [12:08] I must admit I tend to find it backwards to my expectations most of the time too. [12:08] I'll resist the urge to pontificate about what I think shoul happen instead, since I won't be offering patches ;) [12:09] Kamping_Kaiser: you can always file bugs or post to the list :) [12:09] Anyway, I'm off to bed. I'm glad that that merge seems to have worked for you. [12:10] thanks for that, sleep well [13:12] Morning [13:54] okay, I got a local repository. I'm using Windows. How would I push it up to Launchpad? [14:04] Viper550: are you trying to contribute to a specific project? [14:04] yeah, trying to bring it up to my project [14:05] what is your project's name. [14:07] lp:~viper550/bbesque/platypus [14:07] I can explain the name "platypus" though :P [14:09] no need... just a sec, and I can help you out. [14:12] ok, so you've got a branch you want to push to the bbesque project. The simplest way to do that is to say "bzr push lp:~viper550/bbesque/branch-name" where branch name is whatever you want (platypus I think is what you got). [14:12] you will need to set up some ssh keys and get them working with pagent [14:12] do you know how to do that? [14:12] I could help you out with that if you don't [14:13] dunno [14:13] k... do you have putty installed? [14:14] if not go here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and download the link under "A Windows installer for everything except PuTTYtel" [14:15] done [14:15] once you have the putty suite installed, you need to generate some ssh keys. [14:16] puttygen? [14:16] yep [14:17] https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair?action=show&redirect=CreatingAnSSHKeyPair [14:20] let me know when you are ready for more info. I'll brb. [14:21] done [14:23] rubbs: done the pagent part === Noldorin is now known as Noldorin2 === Noldorin2 is now known as Noldorin [14:35] Viper550: sorry about being away for so long. [14:36] so if you've added your keys to pagent and added the key to launchpad you should be able to just push to the location. like this: bzr push lp:~viper550/bbesque/branch-name [14:37] can it be done through a GUI? [14:37] yes [14:37] okay...how? I got Bazaar Explorer open with my local branch [14:37] I'm looking up exatly how to do it... shouldn't take me more than a sec [14:39] Viper550: when you push, you should be able to just put "lp:~viper550/bbesque/branch-name" into the "location" text field [14:40] bzr: ERROR: Parent directory of bzr push lp:~viper550/bbesque/platypus does not exist. [14:41] wait whoops [14:41] "You have not informed bzr of your Launchpad ID" [14:41] Oh, k... sorry forgot that step myself. just a sec I'll find out where yo uset that [14:43] under settings -> credentials [14:43] you need to have an entry like this: [14:43] [Launchpad] [14:43] host = .launchpad.net [14:43] scheme = ssh [14:43] user = patrick-regan [14:44] er... sorry others out there, forgot to pastebin [14:45] rubbs: Running "bzr lp-login patrick-regan" should create that for you [14:46] jelmer_ I know, but he was asking on how to do this with bzr explorer [14:51] Is it possible to define an alias command including a shell fragment? e.g. I'd love to define bzr diffstat => bzr diff | diffstat [14:55] yay got it [14:57] Viper550: cool glad you got it working. it should be easier from now on [14:57] come back if you have any other questions. [14:58] thanks :) [15:00] np [15:03] LeoNerd: I don't think that's possible [15:03] LeoNerd: you could alias that at the shell level though [15:06] Yeah, I know... but doing it in bzr itself would be cute :) [15:07] LeoNerd: agreed. I pretty sure it's not possible (at this point) though. [15:08] Ahwell.. no great problem.. [15:29] quick question: how do I set my commit email address on a directory basis? [15:30] can I do it from the command line or do I have to mess with ~/.bazaar/locations.conf [15:35] LaserJock: use the --branch option on the whoami command [15:35] see "bzr help whoami" for more info === pass is now known as kriss === kriss is now known as krissn [15:49] rubbs: ah, I thought I could just be in the dir and run bzr whoami [15:49] rubbs: switching to an actual branch in the dir and using --branch solved the mystery :-) [15:49] LaserJock: good to hear that helped. [15:50] the problem with whoami working on the dir level only is that you have to go out of a branch then to set it globally. [15:50] that and most people use the global email for most/all of their projects. [15:50] but I can see where you came up with that... [15:51] I'll see about the documentation... Maybe somethign needs to be clarified. [15:54] rubbs: I guess I was going by "if there was a branch right here what would it use?" [15:57] LaserJock: [15:58] er... LaserJock: I see. I'll look into that === beuno is now known as beuno-lunch === Linkadmin is now known as alanpee === beuno-lunch is now known as beuno [17:26] does olive-gtk visualize the relationship between branches in a repo? [17:28] LaserJock: not as well as qlog or explorer (which uses qlog). [17:28] LaserJock: qlog is part of the qbzr plugin [17:38] oh dang it, how do I make a file I just did a bzr add to untracked again? I haven't committed yet [17:39] LaserJock: bzr remove --keep $file === weigon__ is now known as weigon === alanpee is now known as Linkadmin [19:03] I forgot how much I liked bzrlib [19:03] 90% of the time it's already solved a problem I'm trying to solve [19:18] \o/ [19:18] merry christmas beuno [19:18] hey lifeless [19:18] merry christmas to you [19:19] even more so considering you're in the future [19:19] -> plane to catch :) ciao [19:20] lifeless, have a great flight [19:20] Manny Krramer! [19:48] is there an equivalent of git-filter-branch for bzr? I can fast-export/fast-import, of course, but it'd be nice to stay in bzr if possible. [19:49] use case: I have a repo which I've tried to deliberately keep fairly small. I now realize that some time ago I inadvertently committed some directories with contents much larger than I'd like. [19:49] jwhitley: so really you just want to strip out some stuff from your history? [19:49] It happens to be practical to rewrite the repo history (it's a personal and private repo, so far), FWIW. [19:49] rubbs: yes, precisely. [19:50] just a sec... someone yesterday was asking the same thing. I'll look through my logs and see what the best answers where [19:50] lovely, thanks. [19:53] jwhitley: http://irclogs.ubuntu.com/2009/12/21/%23bzr.html check the post from 20:40 (time) on. I think that may be what you're looking for [19:55] rubbs: outstanding, just what I needed. thanks! [19:56] np === cjohnston is now known as FFEMTcJ === FFEMTcJ is now known as cjohnston === khmarbaise_ is now known as khmarbaise [22:35] hey bzr folks, are "oh no my repo is broken" inquiries acceptable here? [22:35] I am a bzr noob who upgraded a lp: branch, and managed to break it somehow. [22:36] le google is not currently turning up useful advice. [22:37] ah, you know what? I think I followed some bad bug report advice and changed a stacking branch to a non-stacking format [22:39] how is it broken? [22:39] chromakode: If you explain more about what exactly you did and what's broken, someone here can probably help [22:39] thanks. didn't want to bug you if this was an inappropriate channel [22:39] any operation [upgrade,check] fails with "RepositoryFormatKnitPack4 ... is not a stackable format." [22:40] trying `push --overwrite` yields "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format" [22:40] what's bzr info? [22:41] stacking was added in 1.6, aka KnitPack5 [22:41] I believe my original sin was running `bzr upgrade --rich-root-pack lp:myrepo` [22:41] (lp:myrepo was 2a, I believe) [22:41] gutworth, bzr info returns the same "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format" [22:41] and stacked? [22:41] maxb, yes. [22:42] is this a public branch? [22:42] public how so? [22:42] it's on launchpad: lp:~chromakode/drizzle-interface/dbapi [22:42] so, my local branch was in a repo [22:42] I remember there being a "bzr release" command... but apparently I'm mistaken. What is the proper command name? [22:43] and I think what happened was that I needed to upgrade my repo. however, I googled and saw the `bzr upgrade --rich-root-pack lp:myrepo` command, which probably borked my remote format [22:44] chromakode: Launchpad has a rather peculiar way of storing branches - it has a public and a writable copy. So it might be simplest for you to simply branch the public copy, which is still intact [22:45] If you try accessing it over http, you'll end up at the public copy, since http branch access is unauthenticated [22:45] got it, bzr export [22:52] maxb, I think my local branch is in order, but it seems like any operations on the lp branch will break. should I just throw out the lp branch using the web interface, and remake it? [22:53] chromakode: Either that, which will wipe metadata such as bug<->branch links, or subscriptions, or, you could delete just the branch files using an sftp client, and re-push [22:54] maxb, sounds good. so, just for the learning experience, my fault was downgrading the repo to a non-stacking format? [22:54] Sounds like that [22:54] Though one could say it's bzr's fault for not shrieking loudly and refusing [22:55] I might claim that if I wasn't a nice user ;) [23:05] morning === igc1 is now known as igc [23:31] Does bzr-git do git SSH URLs? [23:31] I tried the URL I was given [ ssh://@git.gnome.org/git/gtk+ ] and Bazaar gave me a helpful error message about how I had to use bzr+ssh:// as the protocol [23:32] So then I tried git+ssh and it didn't work. [23:32] So presumably my answer is "no" but perhaps I'm missing something? [23:35] AfC: It does, yes. [23:35] I forget quite how I managed to make it happen, though. [23:36] hi all [23:36] AfC: I'd guess you'd be after a URI of the form git+ssh://git@gitorious.org/~raof/banshee/gapless-work.git [23:37] RAOF: Hm. I thought I'd tried that. [23:37] afc: looking at the code, git+ssh should work [23:39] poolie: ok, thanks! [23:39] * AfC tries again [23:41]