[00:18] <mterry> Laney, did you drop the filtering_out_users patch from accountsservice on purpose?
[03:30]  * Logan_ pokes siretart 
[03:30] <Logan_> can we sync libav?
[03:32] <Logan_> our only delta can be dropped
[04:10] <pitti> Good morning
[04:11] <pitti> mapreri: well, it's always office hours somewhere on the world :) (I'm in Germany)
[04:11] <Unit193> Howdy.
[04:11] <pitti> hey Unit193
[04:21] <pitti> xnox: oh BTW, yesterday I figured out the trouble with the py3 AP porting; so once the next autopilot lands in utopic, I'll update shotwell, autopilot-gtk, and ubuntu-system-settings-online-accounts to python3
[04:21] <pitti> xnox: I have the patches already more or less, they just need the autopilot3-sandbox-run
[04:30] <Logan_> hey pitti :)
[04:30] <pitti> hey Logan_, how are you?
[04:30] <Logan_> doing well, you?
[04:31] <pitti> quite fine, thanks
[04:50] <pitti> apw: I did the same for linux-exynos5 and also restricted the test to armhf (it will always fail on x86); files are again on http://people.canonical.com/~pitti/tmp/linux-autopkgtest/
[06:07] <tvoss> pitti, ping
[06:47] <Logan_> doko: FYI, you filed a bunch of dh-autoreconf bugs in Debian twice
[06:47] <Logan_> I'm merging them as I come across them
[07:03] <pitti> tvoss: sorry, missed your ping; hello
[07:03] <tvoss> pitti, hey there :) sorry, forgot what I meant to ask you :)
[07:07] <pitti> tvoss: heh - contentless pings FTL :/
[07:07] <tvoss> pitti, fair
[07:30] <geser> dholbach: Hi, re bug #1320612: it looks like your german locale slipped into the test suite. Based on the failure log I guess it could be fixed by setting the locale to "en_US" (like the previous test) but is it worth an additional Ubuntu delta?
[07:31] <dholbach> geser, hum... wouldn't this affect users of a non-English Debian session as well?
[07:32] <geser> only when running the test-suite I guess
[07:32] <geser> of course I would forward this to Debian or upstream
[07:33] <dholbach> geser, sure... I meant users of a non-English Debian session who are trying to run a build
[07:33] <dholbach> geser, if you want, I can try to build it again locally with LC_ALL=C and see if that works
[07:34] <dholbach> but it sounds like a bug to me to expect en_US in the testsuite
[07:35] <geser> yes, I'll try to fix it and forward it to Debian. Should this block the merge for now?
[07:35] <dholbach> geser, no, I'll do another test build now
[07:35] <dholbach> thanks
[07:38] <dholbach> geser, hum
[07:39] <dholbach> geser, 2ubuntu1 builds fine, 3ubuntu1 won't build, even not with LC_ALL=C
[07:39] <dholbach> ah of course - "Runs the unit test on build (Closes: #727616)" :)
[07:42] <geser> dholbach: hmm, why does my pbuilder have no problem in building this package?
[07:44] <dholbach> I have no idea
[07:46] <geser> I'll try to reproduce this myself and fix the locale issue in the test suite
[07:50] <dholbach> geser, it seems to be the LANG and LANGUAGE environment variables
[08:11] <geser> dholbach: it's already fixed upstream: https://github.com/mitsuhiko/babel/commit/2eb475f835375c1b3b7fefcb7d8aad7047d7fda7
[08:24] <dholbach> geser, great!
[09:05] <Mirv> is there a way to get PPA builders spit out all the changed symbols instead of stopping at the first library?
[09:07] <xnox> Mirv: i think that got implemented  in Debian, not sure if we have that merged yet.
[09:08] <cjwatson> That wouldn't be a property of PPA builders; it's dh_shlibdeps or thereabouts
[09:08] <Mirv> xnox: ok, well good to know
[09:09] <Mirv> yeah, not related to PPA
[09:09] <Mirv> I'll check dh_shlibdeps' current status
[09:09] <cjwatson> Worst case you could pass some permissive -c option to dpkg-gensymbols and then apply logic to the output
[09:09] <Laney> It's in dh_makeshlibs
[09:10] <cjwatson> Er yeah that
[09:10] <Laney> Looks like 9.20140227
[09:10] <Laney> Which we should have in trusty and utopic, going by the versions
[09:11] <xnox> Laney: only utopic, no? trusty is so 2013
[09:11] <Laney> oh yes
[09:11] <Laney> ha, I just saw the 0227 at the end
[09:11] <Laney> s/0//
[09:14] <Mirv> hmm, so it should actually already work but doesn't for me
[09:14] <Mirv> unsurprisingly it was the pkg-kde's Qt developer asking for the feature
[10:52] <cjwatson> lool: looks like that worked for fakeroot, btw
[10:52] <cjwatson> err, echan, but whatever
[11:25] <cjwatson> xnox: Could you merge php5?  php-geoip is waiting for it, and probably anything else that uses dh-php5.
[11:26] <xnox> ack.
[11:27] <cjwatson> ta
[12:18] <Riddell> Elv1313: yo, still need me to look at sflphone?
[12:27] <Riddell> Elv1313: I've uploaded to trusty and utopic, please add a test case to clearly describe how to test for the fix
[13:25] <zbenjamin> cjwatson: ping, can we get a pkcon local_uninstall? I'm writing a debug helper script for the SDK that is going to take a click package, install it , run a hook from it, and uninstall it to leave a clean device
[13:26] <zbenjamin> cjwatson: but i have no root priviledges at that point
[13:26] <cjwatson> zbenjamin: https://lists.launchpad.net/ubuntu-appstore-developers/msg00553.html
[13:27] <cjwatson> zbenjamin: "pkcon remove"
[13:27] <zbenjamin> cjwatson: awesomeeee thanke :)
[13:27] <cjwatson> Just note the bit at the end of that mail about the particular form of the argument you need to pass to pkcon remove
[13:29] <zbenjamin> cjwatson: ok so thats packagename;packageversion; ? whats the all? the target arch?
[13:30] <cjwatson> yes
[13:31] <zbenjamin> cjwatson: so if i have a fat package, how would that look like? only armhf for a armhf device?
[13:31] <cjwatson> IIRC it's not checked so you can just always shove "all" in that slot, I think
[13:31] <zbenjamin> ah good i'll try that
[13:32] <cjwatson> I think for a fat package it would strictly be "multi", but whatever
[13:33] <zbenjamin> yeah i can put that in once we are there
[13:34] <cjwatson> strictly it would match the filename, so com.ubuntu.test_1.3_all.click => all
[13:35] <cjwatson> (well, even more strictly it would match what "dpkg-deb -f foo.click Architecture" says)
[13:43] <pitti> vila, ev: writing tests for the debci worker is fun :) (creating 100 requests, 30 workers, killing two thirds of the workers, and making sure that all requests still arrive)
[13:43] <ev> \o/
[13:44] <ev> pitti: next step: test that chaos in production
[13:44] <pitti> http://anonscm.debian.org/gitweb/?p=users/mpitt/debci.git;a=commitdiff;h=3c03eec
[13:44] <dobey> who can i beg/bribe to accept some SRUs into their respective -proposed pockets?
[13:44] <ev> whoa, ruby?
[13:44] <pitti> ev: well, not quite the next step (still need to implement the swift up/download and the health monitor), but getting closer
[13:45] <ev> heh, indeed
[13:45] <pitti> ev: Antonio wrote some parts of it in ruby (most things are in sh), he's the ruby maintainer
[13:45] <ev> ah
[13:45] <pitti> ev: not that happy, but as long as it's mostly test helpers and RSS generators I can live with it
[13:45] <ev> that's a shame :-P
[13:47] <pitti> ev: but the implementation of the worker is absurdly simple, I really like that AMQP stuff (http://anonscm.debian.org/gitweb/?p=users/mpitt/debci.git;a=blob;f=bin/debci-worker)
[13:48] <pitti> the actual core logic is like 3 lines, the rest is just prettyness
[13:48] <ev> nice
[13:53] <Elv1313> Riddell: Hi, thanks. what kind of test do you want? It is an integration problem (in Akonadi), so it is not really possible to create an unit test without re-creating the contact topology that cause the freeze
[13:53] <Elv1313> Maybe I can ask the 2 users that had it to test the new package?
[13:53]  * Laney wows at the number of tests python-defaults has triggered
[13:54] <mterry> Laney, did you drop the filtering_out_users patch from accountsservice on purpose?
[13:57] <Laney> mterry: it's upstream now, no?
[14:00] <Riddell> Elv1313: a manual test is needed "install sflphone and akonadi, start sflphone, check e-mail, notice freeze, repeat with new version, freeze will not occur" that sort of thing
[14:00] <Elv1313> ok
[14:01] <zbenjamin> cjwatson: works perfectly
[14:02] <vila> pitti: nice
[14:02] <mterry> Laney, parts of it, but not the login.defs support
[14:03] <vila> pitti: I'm not sure how you assert how many requests are processed when many are killed though
[14:04] <pitti> vila: if I submit N requests I should get N results, as long as at least one worker is still running
[14:04] <vila> pitti: oh, that's the one or two
[14:04] <pitti> vila: i. e. if a worker dies in the middle of a test, the AMQP request should go back to the queue as it won't get ack'ed
[14:05] <vila> pitti: so worse case you have duplicates ?
[14:05] <pitti> vila: no, the 1 or 2 is how many result directories you get (as the dir gets created when the test starts)
[14:06] <pitti> vila: right, worst case is you get two results, when it crashes after it wrote the "exitcode" file but before ack'ing the request
[14:06] <pitti> vila: I can probably refine that a bit to remove an incomplete result directory (when there's no exit code), still on my list
[14:06] <Elv1313> Riddell: done
[14:07] <cjwatson> zbenjamin: great
[14:08] <vila> pitti: ack
[14:09] <vila> ev: that confirms that we either need to stop using prefetch_count=1 or have the worker commit suicide to fix bug #1320205
[14:09] <Riddell> Elv1313: lovely, now we just need a friendly archive admin to review and accept the trusty SRU, try batting your eyelids at ScottK
[14:09] <Elv1313> thanks
[14:09] <Laney> mterry: that wasn't part of the patch, this is new upstream behaviour
[14:09] <Laney> is it causing a problem?
[14:10] <mterry> Laney, no we used to support login.defs in our patch, but upstream doesn't.  So dropping the patch means dropping support for login.defs
[14:11] <mterry> Laney, (to define a MIN_UID for considering which users are human)
[14:11] <mterry> or UID_MIN, can't remember which way  :)
[14:12] <Laney> sec, just got a phone call
[14:12] <brendand> cjwatson, how is click chroot create supposed to be run?
[14:13] <brendand> cjwatson, click chroot create -a i386 gives option errors
[14:13] <brendand> cjwatson, not particularly helpful ones
[14:14] <cjwatson> click chroot -f ubuntu-sdk-14.04 -a i386 create
[14:14] <cjwatson> order matters (perhaps unhelpfully)
[14:14] <cjwatson> that is, the subcommand name needs to come after the options to the chroot command
[14:15] <cjwatson> (oh and the whole thing needs to run under sudo)
[14:17] <Laney> mterry: okay, the patch added login.defs and went upstream
[14:17] <Laney> mterry: we had that in the previous AS in ubuntu
[14:17] <Laney> and now in this release they've dropped that support
[14:17] <cjwatson> argh, python multiprocessing is basically the worst
[14:18] <mterry> Laney, ah interesting...  do they say why?
[14:18] <Laney> so yes indeed the minimum UID is specified in configure
[14:18] <Laney> but I think it should be okay
[14:18] <cjwatson> agonisingly confusing errors
[14:18] <Laney> mterry: fragile and broken or wording to that effect
[14:18] <Laney> if necessary we could bring it back as a configure option I guess
[14:18] <mterry> Laney, why should it be OK?  The touch images use users at 1000 and 1001 and we were relying on that support to not show them in the greeter
[14:19] <Laney> what were we doing?
[14:19] <Laney> wait
[14:19] <Laney> that has a different login.defs?
[14:21] <mterry> Laney, on Ubuntu Touch images, we set UID_MIN in login.defs to 1002
[14:21] <mterry> Laney, there are radio and system users at 1000 and 1001 used by android
[14:21] <dobey> SRUs are such a pain to do :(
[14:22] <Laney> bah
[14:22] <Laney> mterry: okay I guess we can revert this then :/
[14:22] <Laney> do you want to upload that?
[14:22] <Laney> ba13b59c
[14:23] <mterry> Laney, sure I can do that
[14:23] <Laney> I'll see about making it configurable
[14:24] <pkern> Also a UID_MAX of 60000 is funny, especially if it's compiled into the binary and not overridable.
[14:25] <Laney> the new behaviour doesn't consider a maximum
[14:27] <pkern> Yay.
[14:28] <Laney> and under the old one login.defs was able to override it
[14:28] <Laney> ho hum
[14:46] <ev> vila: can you add that to the bug report? That pitti has confirmed this
[14:51] <pitti> sorry, what did I confirm?
[14:52] <vila> pitti: that killing a worker that is processing a message puts that message back onto the queue so another worker picks it up
[14:52] <pitti> vila: yes, as long as it doesn't get ack'ed yet; isn't that the whole point of it?
[14:53] <vila> pitti: yes, but we thought that *nacking* a message will have the same effect but it doesn't
[14:53] <vila> pitti: the worker has to die
[14:53] <pitti> vila: ah; it sounds like it should, but I haven't played around with that yet
[14:57] <vila> pitti: all your workers are on the same host right ?
[14:57] <pitti> vila: for the test suite, yes (not in production, of course)
[14:57] <vila> pitti: yup, that was the question indeed
[14:58] <pitti> ah, I figured out how to run rabbitmq-server in a test suite as my user
[14:58] <pitti> vila: oh, does that matter?
[14:58] <vila> pitti: not sure, but I can imagine that the behavior may be different when different hosts are involved
[14:59] <pitti> vila: I hope not..
[15:00] <vila> pitti: I mean, at least when thinking about failures, a host dieing with a single worker is not the same as a host dieing with multiple workers :)
[15:00] <pitti> vila: ah, of course; I meant, it's hopefully transparent wrt. queue ack/nack handling
[15:01] <vila> pitti: yes, me too
[15:29] <xnox> slangasek: pitti: what is "fastboot" mode in the boot initscripts?! was that ever supported with mountall?
[15:34] <pitti> xnox: I'm afraid I never heard of it
[15:34] <pitti> xnox: I thought "fast boot" was "upstartification in lucid"
[15:35] <slangasek> xnox: I don't know anything about fastboot as regards initscripts
[15:35] <xnox> ack.
[15:36] <xnox> pitti: slangasek: should the re-introduced scripts actually just be lsb-headers, source init-functions and otherwise empty?
[15:38] <pitti> xnox: I don't think it hurts that much to just take the debian ones, to make merges easier; there's no other waste than a few kB of hard disk, is there?
[15:39]  * pitti needs to run out now, cu tomorrow
[15:47] <xnox> pitti: slangasek: pushed updates to sysvinit merge proposal. And responded to a bunch of comments.
[16:33] <slangasek> xnox: I much prefer the re-introduced scripts be as close as possible to the Debian ones, for future merging
[16:35] <xnox> slangasek: ok.
[17:50] <xnox> is launchpad being sad, or is it me? (code hosting / branch scanning?!)
[18:05] <roadmr> it was a bit slow about an hour ago, took about 10 minutes to produce a diff
[18:06] <bdmurray> mvo: bug 1320683 is surely because of phased updates
[18:07] <bdmurray> mvo: you can see the status of packages phasing at http://people.canonical.com/~ubuntu-archive/phased-updates.html
[18:09] <sarnold> bdmurray: ah, thanks. I'd forgotten about that entirely.
[18:10] <bdmurray> sarnold: no problem
[19:05] <lamont> Riddell: you around by chance?
[19:05] <lamont> or xnox
[19:06] <xnox> lamont: hi!
[19:07] <lamont> I have sflphone questions, and your name is on it
[19:08] <xnox> lamont: only marginally =) go on =)
[19:11] <lamont> it believes in binding to the IP address of the default gateway, rather than the IP address associated with the route to the server... I wish to fix that, and it's a rather large codebase... hoping for a pointer
[19:11] <lamont> s/of/associated with/
[19:12] <lamont> xnox: ^^
[19:12] <lamont> or I an pester msp later
[19:14] <xnox> lamont: wow. definitely beyond what i've done with sflphone.
[19:17] <lamont> xnox: no worries
[19:32] <mterry> pitti, do you know much about how the volume up/down events are handled in Ubuntu Touch?
[19:45] <lamont> xnox: and figured out how to do it, though there is a bug
[19:58] <lamont> xnox: gnome/src/config/accountconfigdialog.c line 1048... help me understand "CONFIG_LOCAL_INTERFACE" there?
[19:59] <lamont> which is more of a dbus question thananything else
[20:03] <xnox> lamont: that does look wrong.
[20:04] <dobey> xnox: can you approve things to go into -proposed for SRUs?
[20:05] <xnox> dobey: no. you want ~ubuntu-sru
[20:05] <xnox> (loop up their team on launchpad to see who is in it)
[20:06] <xnox> lamont: what is account_lookup?
[20:06]  * xnox presume calling into gnome account settings api.
[20:06] <dobey> infinity: can you accept some things to -proposed for me?
[20:06] <xnox> lamont: and i guess you want to make sure CONFIG_PUBLISHED_SAMEAS_LOCAL is false.
[20:07] <dobey> stgraber, slangasek: ^^ or one of you can accept stuff to -proposed for these SRUs for me?
[20:08] <xnox> dobey: it's typically useful to mention which package you are after, and for which of the stable series....
[20:09] <xnox> there 68 unapproved requests at the moment
[20:09] <lamont> xnox: yeah it sure looks like it wants a bug
[20:09] <dobey> ubuntuone-client and ubuntuone-storage-protocol for saucy and precise
[20:09] <stgraber> anyway, I'm off till Monday and on a pretty sucky internet so I won't do any queue review until I'm back some place with better connectivity (that may very well be on Monday in Malta)
[20:10] <dobey> stgraber: ok, thanks. didn't know you were away. enjoy
[20:11] <xnox> lamont: so the full line is all withing sflphone configuration of the account (and it's properties).
[20:11] <lamont> ok
[20:11] <xnox> lamont: that's not really stock dbus api or anything, just a bunch of functions that sfphone wraps.
[20:12] <infinity> dobey: I'll have a look.
[20:12] <dobey> infinity: thanks
[20:12] <lamont> xnox: what I want is for it to pick the IP address of the interface I override, and not the default-gateway interface
[20:14] <xnox> lamont: right, that dbus call is defined in ./daemon/src/client/dbus/configurationmanager-introspec.xml
[20:14] <xnox> lamont: which takes you to getAddrFromInterfaceName C++ method
[20:15] <xnox> which is defined as
[20:15] <xnox> return SipTransport::getInterfaceAddrFromName(interface);
[20:16] <xnox> line 107 in ./daemon/src/sip/siptransport.cpp
[20:16] <xnox> lamont: i think you'll need to fix that function ^
[20:17] <xnox> cause that's where it computes the value it uses, in a cryptic way...
[20:17] <xnox> lamont: does that help at all?!
[20:21] <infinity> dobey: Why the en_US.UTF-8 requirement for tests on saucy?
[20:24] <dobey> infinity: becasue some of the cert files have non-ascii names, and the default locale is that weird ANSI thing that only does ascii, which breaks python encode/decode stuff
[20:25] <infinity> dobey: Ahh.  C.UTF-8 would probably do the trick without making you need a langpack build-dep.
[20:25] <infinity> dobey: But I this works too.  *shrug*
[20:25] <infinity> dobey: Was just curious.
[20:26] <dobey> maybe. we were already doing the en_US.UTF-8 bit elsewhere though, so i just copied that
[20:26] <infinity> TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
[20:26] <infinity> Wow.
[20:26] <dobey> yeah
[20:26] <infinity> Kay, explanation accepted. :)
[20:27] <infinity> dobey: The only followup, then, is why not the same patch for precise, in case ca-certs gets updated there with similar consequences?
[20:27] <dobey> i thought i did do the en_US thing on precise too
[20:27] <lamont> xnox: that may help.  C++ may not.
[20:27] <infinity> Not in this upload.  If you did, it was a previous one.
[20:28]  * infinity looks.
[20:28] <xnox> lamont: that function, is pure C by the looks of it thought.
[20:28] <dobey> huh. well, i did it like a month ago, so i don't remember exactly
[20:28] <dobey> if i didn't do it on precise, it was because the tests didn't fail when i did the test build, most likely
[20:29] <infinity> Oh.  precise might not run a testsuite at all.
[20:29] <dobey> oh or that
[20:29] <infinity> It doesn't have the override with ./tun-tests
[20:29] <dobey> precise is quite old, yeah
[20:29] <infinity> So, yeah.
[20:29] <infinity> Alrighty.  Acceptiferating.
[20:29] <dobey> thanks
[20:30] <infinity> dobey: Also, this isn't carte blanche to be annoying, but when you have deadlines like the U1 shutdown in 10 days, bugging people earlier wouldn't be a bad thing.
[20:30] <dobey> infinity: i have been bugging :(
[20:30] <infinity> dobey: Oh.  You should have bugged me.  And maybe included the "hey, there's a deadline" bit.  Oh well.
[20:31] <infinity> dobey: As it stands now, I think I'm going to ask you guys to verify the crap out of those u1-client uploads as best you can, so we can phase them to 100% when we release, and hope they get out to most people ASAP.
[20:31] <lamont> xnox: wondering if maybe that's getting called with DEFAULT_INTERFACE
[20:32] <xnox> lamont: hm. not sure. if you file a bug CC / subscribe me on it. for me to have a look, when i'm bored on a connection flight.
[20:33] <xnox> lamont: cause i'm deep in async upstart code at the moment and hope to get this done before EOW.
[20:35] <infinity> dobey: And poke me personally when it's verified, I think the client one is worthy of an early release if you've tested it well.
[20:35] <lamont> xnox: sure
[20:36] <xnox> lamont: the argument that should be called, should be whatever was stored in the account key, no?!
[20:36] <dobey> infinity: sure
[20:36] <infinity> dobey: Oh, except https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/1306225/comments/3 isn't very promising...
[20:37] <dobey> infinity: thanks much
[20:37] <infinity> dobey: Is there no way to get that working at runtime instead of shutdown?
[20:38] <dobey> infinity: yeah, though at this point i'm thinking it's worth it to just release the update anyway, given how close june 1 is. the "not connecting" bit is going to be more important by the time we could get a new upload to fix the notification on precise (i have no idea why the notification is behaving that way on precise. it might be a much larger problem)
[20:38] <dobey> trying to test on saucy right now. just waiting for the archive to get updated so apt will work
[20:38] <lamont> ioctl(13, SIOCGIFADDR, {ifr_name="tun0", ifr_addr={AF_INET, inet_addr("10.172.126.2")}}) = 0
[20:38] <lamont> hrmpf
[20:39] <xnox> lamont: cheat =) debugging c++ with strace =)))))
[20:39] <lamont> xnox: I was doing thatbefore I looked at the source
[20:39] <lamont> because that's how I roll
[20:39] <xnox> =)))))
[20:39] <xnox> s/roll/troll/ ?!
[20:39] <Riddell> lamont: Elv1313 is the sflphone man, try tracking him down if you have questions
[20:40] <mdeslaur> mvo: can you confirm there's nothing to do with apt in bug 1016643?
[20:40] <mdeslaur> (/me is closing ancient bugs...)
[20:43] <lamont> xnox: and now I can't getit to fail
[20:44] <lamont> Riddell: thanks.  here or deban?
[20:44] <lamont> debian
[20:47] <Riddell> lamont: upstream
[20:50] <lamont> amusingly, I can't actually reproduce the bug
[20:50] <lamont> things do, in fact, seem to work as expected.
[20:51] <dobey> turns out that setting your clock 2 weeks forward really screws up some things
[20:52] <dobey> bah
[21:08] <dobey> what a bother :(
[21:14] <dobey> infinity: https://bugs.launchpad.net/ubuntuone-client/+bug/1306225/comments/5 doesn't look good :(
[21:15] <infinity> dobey: Is that something you can turn around a quick(ish) fix for?  I'm happy to be responsive and process that one quickly if you can.
[21:16] <dobey> infinity: well, i haven't been able to do so in the ~15 minutes i've been poking at it (trying to get it to exit cleanly anyway). maybe i can if i just try to make it not ever connect, and leave the process running and acting normally like a disconnected client
[21:41] <dobey> infinity: so i managed to make a patch that makes it not connect, but keep the process alive and working otherwise normally, for 13.10, but 12.04 code is a bit different so i'll have to make a different patch for it
[21:42] <infinity> dobey: Alright.  Keep me in the loop.  I'm around most of the evening if you're working late, or tomorrow if not.
[21:43] <infinity> (Need to run out soon to visit a post office and remind myself how to send paper through the air, though.  Weird backward-ass lawyer people)
[21:44] <dobey> infinity: yeah. i need to go now. i'll probably need to finish this up in the morning, so ping me when you hop on-line tomorrow