[00:56] <Logan_> wgrant: Are you around?
[00:58] <Logan_> Or lifeless?
[00:58] <wgrant> Logan_: Hi
[00:59] <Logan_> wgrant: Hey! Would you mind doing $ requeue_package.py --full openafs # ?
[01:00] <wgrant> Logan_: Do you know why the tags changed?
[01:01] <Logan_> No idea, honestly - someone must've done a push --overwrite during the Precise cycle or something. The trace makes it seem like a Debian tag issue, though.
[05:19] <pitti_> Good morning
[05:23] <bkerensa> pitti_: top of the morning to you
[05:41] <pitti> doko_, cjwatson_: I wondered whether Debian's glib2.0 could now build-dep on python:any (our only delta); is that a question of apt, dpkg, wanna-build, python-defaults, or something else?
[05:56] <bkerensa> pitti: ping
[05:57] <pitti> bkerensa: hello
[05:57] <bkerensa> pitti: May I PM?
[05:57] <pitti> sure :)
[05:57] <bkerensa> :D
[06:40] <dholbach> good morning
[07:51] <jibel> cjwatson_, I get bug 1179202 with latest openssh on saucy, could you have a look?
[08:01] <jodh> @pilot in
[08:04] <jodh> jibel: could you add a comment to lp:~jamesodhunt/ubuntu/raring/sbuild/dep8-procenv if you are happy with the changes I made? (Nothing seems to be happening on the Debian side yet).
[08:19] <jibel> jodh, sure, I'll review the changes.
[08:19] <jodh> jibel: thanks!
[08:23] <pitti> slangasek, stgraber: I sent a mail to u-devel@ about testing the new udev (I now ported all our patches and packaging), as well as whether to move to the new net iface naming schema
[08:25] <doko_> pitti, afaik, debian can't do that yet
[08:25] <pitti> doko_: good morning
[08:25] <pitti> doko_: do you know what part in particular handles that? sbuild's/wanna-build's build dep parsers?
[08:31] <geser> does somebody know if it's intended to have/keep "fglrx-legacy-driver" in multiverse? (it got synced from non-free into saucy)
[08:33] <tjaalton> geser: no
[08:34] <tjaalton> most likely won't work on ubuntu, or will break things
[08:34] <geser> tjaalton: so it should get removed from the archive again?
[08:34] <tjaalton> yes, and blacklisted
[08:34] <tjaalton> again?
[08:36] <geser> ok, will file a remove bug for it then
[08:39] <mardy> seb128: hi :-) Do you know if there is a Google calendar for the UDS?
[08:39] <seb128> mardy, hey
[08:39] <seb128> not that I know :-(
[08:40] <seb128> mardy, http://summit.ubuntu.com/uds-1305/2013-05-15/display has a feed and a mobile version
[08:40] <seb128> not sure if you can make the mobile version send you reminders
[08:49] <mardy> seb128: oh, it works. In Google calendar, under "Other calendars", one can add a URL of an ical feed
[08:49] <seb128> mardy, good to know, thanks ;-)
[09:09] <soren> Holy crap, developers in India are cheap. I knew they were cheap, but not this cheap. They seem to average around USD 7500. A year.
[09:09] <soren> Wow.
[09:09] <soren> Wrong channel :)
[09:09] <mlankhorst> 16 roof painters won't make a mondrian, though :P
[09:11] <soren> I don't know, man. I know a lot of very good Indian devs. It seems disproportionate.
[09:47] <cjwatson_> mitya57: proposed-migration only cares about regressions in the set of architectures with successful builds; it doesn't care about whether there are build failures on architectures that were never built before
[09:48] <cjwatson_> pitti: I'm pretty sure there are still wanna-build/sbuild issues we need to fix before you can upload that to Debian.
[09:48] <cjwatson_> jibel: ok
[09:49] <mitya57> cjwatson_: thanks for responding! that's what I thought, yes
[10:19] <yossarianuk> hi - I have an existing ppa - https://launchpad.net/~morgancoxuk - I am on a new desktop though and didn;t copy my GPG key over
[10:19] <yossarianuk> i.e 6BDD7F66
[10:20] <yossarianuk> do I have to create a new GPG key or can I just copy the existing one from the PPA sire / ubuntu keyserver some how?
[10:22] <yossarianuk> i.e - if I go to  http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x711A47FD6BDD7F66
[10:22] <yossarianuk> I can see the key - how can I use that key
[10:22] <mitya57> yossarianuk: ubuntu keyserver only has your public key (not private), so you'll need to generate a new one
[10:22] <yossarianuk> mitya57: thanks
[10:24] <tkamppeter> Who is responsible for the UDS schedules, two of my sessions were put at the same time.
[10:24] <Laney> talk to the track lead(s)
[10:26] <yossarianuk> mitya57: Yes I guess it was silly question... (if anyone can get my key the security is broken...)
[10:26] <yossarianuk> Just so I know for next time I migrate - where afre the key files kept?  is it just ~/.gpg ?
[10:26] <StevenK> yossarianuk: ~/.gnupg
[10:27] <StevenK> That always trips me up, I look for .gpg first
[10:28] <seb128> tkamppeter, hey, what sessions?
[10:28] <tkamppeter> Sorry, I see that it got already corrected. Thanks.
[10:28] <seb128> yw
[10:31] <mitya57> cjwatson: in bug 537998, we only want to localize two strings that are coming from https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/memtest86+/saucy/view/head:/debian/grub, right?
[10:31] <yossarianuk> StevenK: cheers !
[10:31] <yossarianuk> btw the whole reason i'm creating packages is to get the latest nvidia driver
[10:31] <yossarianuk> I wish Ubuntu just worked easily with the Nvidia bin file...
[10:32] <cjwatson> mitya57: which are fundamentally unlocalisable right now
[10:32] <yossarianuk> the 313 drivers are now out of date....
[10:32] <cjwatson> mitya57: (yes)
[10:33] <yossarianuk> xorg-edgers upgrades far to much (i.e kernel, xorg, etc..)
[10:33] <mitya57> cjwatson: why fundamentally? we can create a gettext template (right inside debian/), allow rosetta to accept translations for it, and then use gettext(1) in that script
[10:34] <cjwatson> mitya57: It needs to be localised at boot time, not when that script runs
[10:35] <mitya57> cjwatson: why?
[10:36] <cjwatson> Hmm, I swear menu entry strings used to be localised at boot time
[10:36] <cjwatson> Maybe they aren't any more
[10:37] <mitya57> (I know that different users can have different locales, but that's a rare corner-case)
[10:37] <cjwatson> Possibly TEXTDOMAIN=memtest86+ gettext_printf blah would do then
[10:37] <cjwatson> (Do use grub-mkconfig_lib's helpers rather than bare gettext
[10:37] <cjwatson> )
[10:39] <mitya57> $ which gettext_printf
[10:39] <mitya57> $
[10:39] <cjwatson> view /usr/share/grub/grub-mkconfig_lib
[10:39] <cjwatson> which /etc/grub.d/20_memtest86+ already sources, albeit via a deprecated symlink
[10:40] <mitya57> ok, I'll now try to implement that (and fix the symlink)
[10:40] <cjwatson> compare with other current grub.d scripts
[10:40] <cjwatson> the symlink isn't a major problem or anything, just mentioned it in case you were confused
[10:40] <cjwatson> thanks :)
[10:42] <mitya57> can /usr/lib/grub/grub-mkconfig_lib also be replaced with /usr/share/grub/grub-mkconfig_lib?
[10:42] <mitya57> oops
[10:42] <cjwatson> Don't replace anything - probably better to extend the conditional
[10:43] <mitya57> I meant /usr/lib/grub/update-grub_lib
[10:43] <mitya57> ok
[10:43] <cjwatson> They're all various incarnations of the same thing, but it would be a hassle to have to have tight dependencies there
[10:43] <cjwatson> However let's check when gettext_printf was introduced relative to those changes
[10:44] <cjwatson> 2010-12-21 upstream, so 1.99
[10:46] <mitya57> that was a long time before precise, so I don't think we should care about that...
[10:46] <cjwatson> grub-mkconfig_lib was moved to /usr/share/grub in 2012-01-24
[10:47] <cjwatson> The switch from update-grub_lib to grub-mkconfig_lib was 2008-09-29
[10:47] <cjwatson> So I think you can drop update-grub_lib now and update any relevant dependencies/breaks/whatever to 1.99; but keep the check for /usr/lib/grub/grub-mkconfig_lib
[10:48] <cjwatson> Looks like there aren't any relevant deps, it just uses whatever it can find
[10:48] <cjwatson> Breaks: grub-common (<< 1.99) mightn't be terrible
[10:49] <mitya57> ok
[10:49]  * mitya57 's xgettext doesn't understand '[type: gettext/rfc822deb]' in POTFILES.in, weird
[10:50] <cjwatson> Isn't that an intltool-debian thing?
[10:52] <mitya57> right, I never used that before... :)
[11:21] <mitya57> cjwatson: if I do "msgfmt debian/po/{}.po -o debian/memtest86+/usr/share/locale/{}/LC_MESSAGES/memtest86.mo" in build target, will it be correctly picked by dh_translations?
[11:21] <mitya57> (using xargs)
[11:26] <cjwatson> mitya57: I'm afraid you probably know dh_translations as well as I do
[11:29] <mitya57> AFAIR removing .mo files happens after install step, so it should work
[11:31] <cjwatson> Perhaps you mean pkgstriptranslations rather than dh_translations?
[11:32] <cjwatson> Which happens in a dpkg-deb diversion, so at dh_builddeb time
[11:34] <mitya57> yes, thanks
[11:41] <cjwatson> wookey: mind if I merge libsepol from Debian?  you're touched-it-last in Ubuntu
[11:43] <cjwatson> wookey: ditto zlib
[11:52] <wookey> cjwatson: sure - just try not to lose the fixes if they've not propogated to debian yet
[11:52] <cjwatson> wookey: that's within my meaning of "merge", yes :)
[11:52] <cjwatson> thanks
[11:52] <wookey> indeed. I realise I am teaching egg-sucking here. I wondered why you even asked  :-)
[11:53] <cjwatson> wookey: Because the rule for merging from Debian is that you check with the previous uploader first, to avoid duplicate work
[11:53] <cjwatson> And I should practice what I preach
[11:53] <wookey> OK. in case they have other stuff pending, or were about to do it themselves?
[11:54] <cjwatson> Either
[11:54] <cjwatson> Or in case it's delicate somehow
[11:54] <wookey> OK. noted for future use.
[12:00] <jodh> @pilot out
[12:18] <mitya57> working!
[12:18] <mitya57> ### BEGIN /etc/grub.d/20_memtest86+ ###
[12:18] <mitya57> menuentry 'Диагностика памяти (memtest86+)' {
[12:23] <cjwatson> mitya57: well done
[12:24]  * mitya57 is trying to make the template updating automatically, not manually
[12:32] <mitya57> intltool-extract doesn't support .sh files, so that doesn't seem to be possible
[12:48] <hallyn> hi - is the import from lp:ubuntu/raring/* into lp:ubuntu/saucy/* still on-going?
[12:49] <hallyn> bzr branch ubuntu:lxc is still failing...
[13:09] <apw> cjwatson, hey, i see you did some work on openssh, specifically on monitor_read stuff; i am seeing incoming interactive logins to saucy dropping immediatly with 'monitor_read: unsupported request: 144' -- seen anything like that in your testing ?
[13:10] <cjwatson> apw: already fixed in unstable, fix will auto-sync tonight
[13:10] <cjwatson> apw: bug 1179202
[13:10] <apw> cjwatson, ahh thanks
[13:17] <hallyn> wgrant: ^  is the bzr import into lp:ubuntu/saucy done?
[13:19] <wgrant> hallyn: package-import has caught up with both saucy and jessie, yeah
[13:21] <hallyn> wgrant: drat.  ubuntu:lxc is still not right
[13:22] <wgrant> hallyn: No, it's broken
[13:22] <wgrant> http://package-import.ubuntu.com/status/lxc.html
[13:22] <wgrant> package-import sees it as corrupt, but it works OK for me
[13:23] <wgrant> I haven't had time to investigate properly
[13:23] <smoser`> xnox, around ?
[13:27] <hallyn> wgrant: ok, thanks
[13:30] <stgraber> wgrant: I've been running manual import-dsc against ubuntu:lxc in the past after the importer apparently gave up on the branch, not sure whether that made it any worse
[13:31] <stgraber> oh, I see, it's even more broken now than it used to be (can't even pull from it)
[13:33] <wgrant> stgraber: Yeah, except that I can branch the branch fine :/
[13:33] <wgrant> I might have time to poke harder at it late this week, but if someone else wants to have a look..
[13:39] <apw> pitti, i just tried out your udevd-202, seems to work on a UEFI machine here; boots fine and sees USB sticks and the like
[13:39] <pitti> apw: thank you!
[13:44] <smoser> anyone want to venture a guess here:
[13:44] <smoser> https://bugs.launchpad.net/ubuntu/+bug/1179513
[13:45] <smoser> in the cloud images (at least, possibly elsewhere) on saucy i cannot ssh in
[13:46] <smoser> well, cannot get a pty/console. I can ssh in only by giving giving commands to run
[13:47] <pitti> smoser: duplicate of bug 1179202
[13:47] <pitti> will be fixed in a few hours
[13:47] <apw> smoser, do you see a 'monitor_read: unsupported request: 144' in /var/log/auth.log on the other end, if so, what pitti said
[13:48] <pitti> I get that with today's cloud images
[13:48] <smoser> apw, yes, seeing that.
[13:50] <smoser> pitti, apw thank you. pitti, you use cloud images?
[13:51] <pitti> smoser: yes, with jibel's run-adt-test script
[13:51] <pitti> in fact, I'm just using them for "give me a throwaway VM really fast in tmpfs" :)
[13:51] <pitti> (doing NetworkManager testing, and I manage to screw it up quite often)
[13:52] <smoser> i iddn't know about run-adt-test. neat.
[13:52] <smoser> pitti, you use via kvm ? (for the tmpfs case)
[13:53] <pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[13:53] <pitti> smoser: yes, that creates a kvm based on the cloud image with an overlay qcowfs in tmpfs
[13:54] <pitti> IOW, "run-adt-test -sl" -> shell in a pristine saucy environment
[13:54] <pitti> same with -r raring -> raring VM, etc.
[13:54] <pitti> and as I have apt-cacher-ng, installing a bunch of packages is literally done in two seconds
[13:58] <smoser> pitti, nice.
[13:58] <smoser> i've recently been using libeatmydata for everything like that.
[13:58] <smoser> (and patching apt to always call eatmydata on itself)
[13:59] <smoser> and also if you do 'cache=unsafe' in kvm, performance is really good.
[13:59] <smoser> just mentioning those things as they may get you to closer to tmpfs performance without explicitly using memory.
[14:00] <smoser> jibel, around?
[14:02] <smoser> jibel, well, when you see this, i'd really like to talk to you some about simplestreams, which i hope can provide a way for http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/bin/prepare-testbed to download/sync images more easily
[14:03] <smoser> hm.. i never thought to EATMYDATA kvm
[14:03] <smoser> interesting.
[14:38] <tedg> jdstrand_, Okay, I unwrapped the GIO stuff there a bit (not as much error handling) but the upstart app branch should be happier now.
[14:39] <jdstrand_> tedg: cool, thanks! :)
[15:26] <ogra_> cjwatson, are you replacing slangasek while he is sick ? i have two specs in the foundations realm that need approval and scheduling
[15:27] <SpamapS> so, does anybody even triage bugs for compiz?
[15:27] <SpamapS> https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs?search=Search&field.status=New
[15:27] <SpamapS> 524 New
[15:34] <cjwatson> ogra_: yes
[15:34] <cjwatson> (if I can remember how)
[15:35] <ogra_> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-non-interactive-touch-boot and https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-android-builds-revisited
[15:36] <cjwatson> ogra_: OK, poked on LP, let's see if/when they show up in summit
[15:36] <ogra_> thx
[15:39] <cjwatson> cjohnston: Is there a guide somewhere for how to run a vUDS track?
[15:40]  * cjwatson finds http://summit.readthedocs.org/en/latest/ and hopes it's up to date
[15:40] <cjwatson> Hm, not entirely convinced
[15:40] <cjohnston> cjwatson: that has everything except the hangout stuff
[15:41] <cjohnston> mhall119_: sent out instructions last time on the hangout stuff. I don't know, but I would assume that is planned again
[16:05] <mpt> cyphermox, are Bluetooth PINs always four digits?
[16:05] <cyphermox> no, they could be longer
[16:06] <mpt> "Any 16-byte UTF-8 string may be used as a PIN code; however, not all devices may be capable of entering all possible PIN codes."
[16:06]  * mpt should have Googled first
[16:07] <mpt> PIN: 🙈🙉🙊😱
[16:11] <cyphermox> hehe
[16:30] <mlankhorst> mpt: but you can have 1 UTF-8 character that's 6 bytes in length, limiting you to 2 characters :>
[16:52] <cjwatson> cjohnston,mhall119: I have two more foundations sessions to schedule, and no free slots.  Would it be best to steal slots from another track (appdev seems to have quite a few free)?
[16:54] <cjohnston> cjwatson: you can ask the appdev track leads if you can have a slot or two.
[16:59] <cjwatson> popey,dpm,mhall119: ^-
[17:01] <dpm> cjwatson, I think you can use some of ours, yes. Otherwise if that is not enough perhaps we might want a second room for Foundations
[17:01] <dpm> cjohnston, ^
[17:01] <cjohnston> dpm: I think that would prolly be jono's call
[17:02] <cjohnston> initially the one foundations room was added because client was too big
[17:03] <jono> just add them to appdev
[17:04] <mhall119> cjwatson: how many sessions?  I have a handful more to add today for appdev
[17:06] <cjwatson> mhall119: two at the moment
[17:06] <cjwatson> hoping that'll be it - it's a bit late to be adding things anyway
[17:07] <tedg> jodh, On the instance interface in upstart the processes are a(si).  What is that string for?
[17:12] <mhall119> cjwatson: that should be fine then
[17:13] <seb128> cjwatson, mhall119: desktop is not full either and can probably host a few extra ones if needed
[17:13] <mhall119> seb128: you mean client?
[17:13] <seb128> mhall119, safe difference :p
[17:14] <seb128> same*
[17:37]  * cjwatson finds https://wiki.ubuntu.com/UDS/Sessions re how to do the hangout stuff
[18:36] <slangasek> @pilot in
[19:53] <balachmar> I am having a problem installing 13.04 on my system. The upgrade failed, but the installer is giving me problems as well. It boots and then when you should be able to select the installation type it stays empty: https://owncloud.wligtenberg.nl/public.php?service=files&t=3de9d7b808a91cfc69d0b6e159216be2
[19:53] <balachmar>   And whenever I click on the change or (+/-) it crashes...
[19:54] <balachmar> My old system, which is broken by the upgrade still boots. But I cannot perform a dist-upgrade because of some dbus error...
[19:57] <ScottK> bdmurray: How would phased updates work in a case where I've got a new KDE SC upstream release with several dozens of packages that have been tested as a set and should hit a user's system at ~the same time?
[20:00] <bdmurray> ScottK: that's a good question and something we haven't explicitly thought about.
[20:02] <sarnold> ScottK: in your example, would you have versioned dependencies in place to force an all-or-nothing upgrade?
[20:02] <sarnold> (just for my own curiosity..)
[20:13] <dobey> hrmm, what does "[] Willing to be Crew" even mean for vUDS? :)
[20:13] <dobey> balachmar: #ubuntu is the help channel
[20:33] <balachmar> @dobey yeah I found that out later, I thought this was technical enough...
[20:33] <udevbot> Error: "dobey" is not a valid command.
[20:33] <balachmar> dobey: yeah I found that out later, I thought this was technical enough...
[21:33] <Daviey> stgraber: For reference mongodb is keen to allow us (and derivatives) to link against openssl and is actively working on a declared exception.  *They* questioned why it required extra work, as they assumed it was a system library.
[21:34] <stgraber> Daviey: ah, ok, thanks for the update. I haven't rechecked the bug report in the past week or so, good to see it going in the right direction.
[21:35] <Daviey> stgraber: That upstream bug report seems to be simply poor triaging
[22:13] <kees> stgraber: hm, do you think /etc/init/container-detect.conf (and console.conf) should detect KVM as a container? Nice to have a serial console Just Work under KVM...
[22:14] <stgraber> kees: it definitely shouldn't detect kvm as a container or it'll do very very bad things to it (like not install grub), but yeah, having an extra console job which does the right check for kvm either through a udev start on pattern or through pre-start would be nice
[22:15] <stgraber> I think there's a tty-device-added or something similar that's emitted in upstart at boot time for console devices, so with the right starton pattern it should be possible to DTRT for kvm serial console
[22:16] <sarnold> what does grub get you in a container?
[22:16] <stgraber> sarnold: nothing, that's why we have a check in the grub scripts to turn them into no-op when in a container
[22:17] <sarnold> stgraber: then not having grub doesn't sound so horrible?
[22:17] <stgraber> we technically support running a full Ubuntu system (think desktop squashfs) in a LXC container without modification, so it's possible (and happens often) that you have grub and a kernel installed in the container, even though they're completely useless
[22:17] <stgraber> the default container you get with lxc-create doesn't contain grub+kernel but things like the images used by the QA team do and so do the cloud images
[22:20] <infinity> sarnold: I think his point was that if you detect KVM as a container, you won't get a functional grub in your kvm VM.
[22:20] <stgraber> right
[22:21] <infinity> Anyhow, some better way to automatically set up serial consoles has been a long-time wishlist of a lot of people.
[22:21] <infinity> It's a point of contention on devices where you might still be using serial ports for weird things like, I dunno, talking to serial devices.
[22:22] <infinity> (But if udev has some sort of event for "the kernel ran a console on this tty already", then that would be perfect)
[22:22] <stgraber> yeah, jodh tried to build a generic job a while back, which worked pretty well except for all the cases where you want to use your serial port to talk to serial devices
[22:23] <sarnold> infinity: wow. somehow I misread KVM -> LXC. thanks for fixing my reading. hehe. :)
[22:23] <stgraber> I think we can pretty easily deal with the stndard /dev/tty[123456] and get down to just one multi-instance job dealing with them, hypervisor consoles should also be detectable, it gets tricky when you're talking about ttySX and ttyUSBX where you're never quite sure what you want on those
[22:24] <infinity> stgraber: I could probably come up with some sick pathological case of using an hvc* serial port for something other than a console, but that's probably approaching "you get to keep both pieces" territory.
[22:25] <infinity> stgraber: As for ttyS* (and friends), I've long been of the opinion that if you have console=/dev/ttyS32 on your kernel command-line, that's probably what you want for userspace too (and you can effin' kill the getty yourself if it's not what you wanted)
[22:27] <stgraber> infinity: indeed, parsing /proc/cmdline and starting a getty on what console= points to should be safe and we should definitely do that
[22:28] <kees> stgraber, infinity: yeah, I like this idea.
[22:29] <kees> the thing is, I think the existing console.conf is correct already.
[22:30] <kees> hm
[22:30] <kees> actually... is there a way to detect if /dev/console != /dev/tty1 ?
[22:30] <kees> because always starting a console on /dev/console seems like a sensible idea.
[22:30] <lifeless> +1 on getty on your cmdline console
[22:36] <stgraber> kees: I think it'd be more reliable to have upstart parse the console= argument if only because it'll need to get the bitrate and other stuff from there anyway. Then move upstart to have a single "getty.conf" job which uses instances (taking PATH, BAUDRATE as variables), then have that job triggered by another job or by a starton condition
[22:36] <stgraber> the advantage being that upstart instances will prevent ever starting a getty twice on the same device
[22:38] <lifeless> barry: hey
[22:39] <barry> lifeless: hey
[22:39] <lifeless> barry: so, image based updates - I'm going to be online for the session I think; but I wanted to ask - have you looked at e.g. lmirror for the updates ?
[22:39] <lifeless> barry: it's got a bunch of properties that seem to match the stuff you wanted according to the wiki page
[22:39] <barry> lifeless: i have not
[22:40] <barry> stgraber: ^^
[22:40] <lifeless> barry: including HTTP streaming, signed updates, sliding windows of history and so forth.
[22:41] <barry> lifeless: https://launchpad.net/lmirror
[22:41] <lifeless> it's probably not an exact fit, but I'd be delighted to have it's design tweaked to fit, if conceptually it fits.
[22:41] <lifeless> barry: yeah
[22:41] <barry> lifeless: is there more documentation on it available?
[22:42] <barry> lifeless: or should i just grab the code and poke around?
[22:42] <kees> stgraber: hm, yeah
[22:42] <lifeless> barry: http://bazaar.launchpad.net/~lmirror/lmirror/trunk/files/head:/doc/
[22:42] <lifeless> barry: http://bazaar.launchpad.net/~lmirror/lmirror/trunk/view/head:/doc/MANUAL.txt
[22:43] <barry> lifeless: cool.  it's dinner time here, but i'll take a look either later tonight or in the morning
[22:44] <lifeless> barry: kk
[22:44] <barry> lifeless: thanks.  /me -> dinner
[22:44] <stgraber> barry, lifeless: bookmarked, will try to read through the doc/ a bit later