[00:00] and defeat the purpose of 'console' at all in the case of cryptsetup [00:00] it only wants it for prompting, not output [00:00] (rather: if there's no prompting, there's no reason to output either) [00:01] does it defeat it? [00:02] not sure [00:02] cryptsetup wants the console for prompting [00:02] does that work with 'console output'? [00:02] yeah, but does it need to have it as the controlling terminal? [00:03] sure, the difference between the two is whether you get signals from the console driver [00:03] ok, then perhaps not [00:03] if cryptsetup doesn't need SIGHUP, SIGINT, SIGTSTP, etc. it should be ok [00:03] but I still don't like the idea of cryptsetup prompting for a passphrase while X is running [00:03] sits badly with me [00:04] * jdong watches some funky policykit-gnome-auth-handler-thingie arise out of this discussion... [00:04] god know [00:04] god no even [00:04] haha joking :) [00:04] Keybuk: no, I agree, I think we either need cryptsetup to block X until it's done, or die when the dm starts [00:04] right [00:05] but then I start to wonder whether the same shouldn't really be true of mountall as well [00:05] should we really be checking filesystems behind X ? [00:06] perhaps not... but mountall is trickier because it may be running waiting for remote filesystems and there's no way presently to distinguish that from the "going to fsck" case? [00:06] I guess it could emit a "no more fsck" signal [00:07] anyway, is mountall getting fixed to talk to usplash for karmic so people don't get into a reboot loop wondering why their systems have hung at boot? [00:07] doesn't cryptsetup use X already? [00:07] err [00:07] I mean use usplash already? [00:08] should do [00:08] but you're the one who added the 'console owner' upstart job, so I don't know :) [00:09] yeah I think that was wrong of me ;) [00:09] heh :) [00:11] writing an operating system is *hard& [00:13] anyone know how to prevent malicious hardware initialization while im away? [00:13] is stopping hald while im good enough? [00:14] crypt-0: turn off the machine? [00:14] i would go one further and unplug it from the wall [00:15] just in case it switches itself back on again [00:15] chrisccoulson: I was being serious ;) rather than just joking [00:15] right, you only need to disable wake-on-lan for the latter [00:15] Keybuk - i wasn't sure if you were being serious or not ;) [00:17] Keybuk: I wonder if it would make sense to use usplash's bogl backend on KMS [00:17] cjwatson: isn't it only 16-colour? [00:17] 256 [00:18] I don't think that's intrinsic anyway, depends on the framebuffer type [00:18] hmm [00:18] how easy would it be to test? :p [00:19] is the current problem KMS-specific? [00:19] Keybuk, besides turning off the machine [00:19] or would we need another solution for !KMS cryptsetup users? [00:19] current problem? [00:19] crypt-0: if you want to avoid attack, powering off the machine is the only solution [00:19] Keybuk: the bug number I cited 800 lines ago? [00:19] Keybuk: I think you just need to nobble uplash_setup_func [00:19] I don't think bogl vs. svgalib is relevant here [00:19] usplash_setup_funcs [00:19] Keybuk, why wont stopping hald work? [00:19] apparently my key is a bit wonky [00:20] Keybuk, can i PM you? [00:20] crypt-0: no. [00:23] crypt-0: seriously though, there's no way to disable things against malicious use short of powering down the box [00:23] crypt-0: assumedly you're leaving it up so you can access [00:23] crypt-0: well, so can naughty people [00:24] (and for the exact question you were asking, hardware configuration and activation is largely performed by the kernel - which you kinda need running ) [00:24] so my answer was correct [00:29] am I supposed to have green check marks on all my files? [00:29] LaserJock: Known, its an UbuntuOne bug. [00:29] oh [00:29] can I just uninstall UbuntuOne and it'll go away? [00:29] I guess so, I don't know for sure./ [00:32] is there a way to "lock" the kernel? [00:33] as in make no hardware initialization possible without x password [00:34] urm. Don't load the kernel? [00:35] bryce, tjaalton: either of you around? [00:35] I am [00:35] bryce: how do I make nouveau work? [00:35] crypt-0: you will *require* the kernel have have initialised various bits of hardware in order for you to interact with the machine [00:36] Keybuk, first you must have the right hardware [00:36] bryce: I have an nvidia ;) [00:36] [ 7.994703] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086700a2) [00:36] [ 7.994981] [drm] Initialized nouveau 0.0.15 v2.6.31-rc6-539-ged53f9fcabd42f004 for 0000:01:00.0 on minor 0 [00:36] I have that in dmesg [00:36] lspci is smarter [00:36] Keybuk, seriously, in my testing I've found so many card-specific bugs that I ended up giving up trying to make it the default driver for us [00:37] bryce: I want to try something out with usplash which needs mode setting [00:37] Keybuk: right now I use xorg.conf [00:37] Driver "nouveau" [00:38] pwnguin, you using any special kernel? xorg-edgers? [00:38] X isn't smart enough to use nouveau automatically? [00:38] Keybuk, re: my comment about defaults on karmic [00:38] its smart enough not to :P [00:38] bryce: even if you've loaded the nouveau module? [00:38] Keybuk: smart enough is the wrong phrase. crazy enough is the rgiht one [00:38] there was a patch floating around to make it try nouveau first if installed, then -nv if failed, but don't know the status on that [00:39] bryce: honestly, i switched to nvidia a few weeks ago to try out 3d accelleration of unr [00:39] Keybuk, in any case, that's a pretty minor issue, like pwnguin says it's sort of a box of chocolates at the moment [00:39] sladen, right but if hald inst running "evil" hardware cant be intilizied right? [00:39] bryce: but until then it'd been running nouveau on karmic [00:39] bryce: ok [00:39] bryce: if I have nouveau modeset=1 will X burn in flames? [00:40] no clue [00:40] err [00:40] pwnguin, was this stock karmic or were you using one of our special ppas? [00:40] crypt-0: evil hardware will still be initialised, the kernel does the initialisation [00:40] bryce: i believe it's stock. might have what's his name's ppa [00:40] RAOF? [00:40] ah yes [00:40] Keybuk, I'd certainly wear flame retardant underware [00:40] anyways, it's at home and im not [00:40] I think it's nouveau.modeset=1 btw [00:41] right [00:41] its probably time for me to turn off the nouveau hilight on irssi [00:41] im not smart enough to handle it [00:41] apw also had a special kernel built for us with updated nouveau bits, although I think by now that's all in the stock kernel [00:42] Keybuk, but wont it be "ignored" rendering it useless? [00:42] Keybuk, how about killing dbus? [00:42] crypt-0: no, it will not be ignored [00:43] killing dbus won't help you either [00:43] frankly, you're being rude now [00:43] you asked us a question, we gave you answer [00:43] we're not lying to you [00:43] https://edge.launchpad.net/~xorg-edgers/+archive/nouveau [00:43] that's it... but looks like it's probably way out of date now [00:44] Keybuk, so there is no software solution then. Will have ti implement a hardware one [00:44] in any case, was buggy as hell when I tested it on a few cards, but the intro directions might be useful [00:44] crypt-0: there's already a hardware solution - it's the plug on the wall [00:45] Keybuk, i know, but i like to run my pc 24.7 [00:45] crypt-0: your electricity supplier loves you [00:45] * walters likes the "kill dbus" solution to arbitrary problems [00:46] Keybuk, rmod [00:46] walters: "kill init" works well ;) [00:47] Keybuk, correct me if im wrong, but blacklisting and unloading every kernel module for anything hot-swappable excapt for PS/2 should do it , but its a rater crude way of doing it [00:48] crypt-0: if you don't trust the hardware don't use the machine. [00:48] crypt-0: PCI is hot swappable, as is USB [00:48] crypt-0: its extremely simple. [00:48] in fact, Linux supports hot-swappable CPUs [00:48] so good luck with *that* [00:49] no need for USB. my mobo doenst support PCI hot swap [00:49] crypt-0: you'd need a custom kernel though, ours has the USB host drivers built-in [00:50] Keybuk, for example with a "live image hack tool" wouldnt you need to root the system? [00:51] (no DMA for anything hot-swappable is already applied) [00:51] crypt-0: always assume that's possible [00:51] Keybuk, but if your sys gets rooted, arent you owned anyway? [00:56] LaserJock: this edubuntu karmic livefs build failure looks kinda edubuntu-specific, like it doesn't want to install the default kernel or something? [00:57] slangasek: for which build? [00:58] LaserJock: edubuntu/karmic/amd64, email just came in [00:58] crypt-0: r00ted == 0wned. [00:58] (not on the website yet) [00:59] slangasek: k [00:59] slangasek: I wouldn't think that'd be edubuntu-specific. Could it be that the build caught the archive at a bad time? [01:00] slangasek: we don't do anything with the kernel I don't think [01:00] LaserJock: possible; let me double-check, then [01:01] sladen, i know, there is no point to protecting against any attack if your rooted... [01:02] unless the evil hardware is what roots you [01:03] crypt-0: unplug the evil hardware. It's not forcing you to use it [01:04] crypt-0: if you're running Free Software, you've got the source code and are free to analysis. If you're choosing to run on hardware you don't have source code for, then that's a risk you are *choosing* to take [01:05] LaserJock: can't reproduce the problem locally, so I don't know [01:05] LaserJock: can try to respin in a bit [01:06] slangasek: ok === dendro-afk is now known as dendrobates [01:10] sladen, evil hardware such as in a hackers laptop plugged into my USB port [01:11] I go test usplash now [01:12] ive seen windows machines rooted from something like a hackers laptop, [01:14] crypt-0: I'd care if somebody had a firewire cable... unsolicated incoming DMA [01:15] crypt-0: if you can't unplug the USB hardware, get some superglue and bung it up [01:15] LaserJock: I've committed a cdimage fix which might sort out Edubuntu on the next build, so please shout if it doesn't (unfortunately I'm probably not going to have enough attention to check myself) [01:16] cjwatson: no problem, I'll let you know [01:16] Turn off all ports and DVD etc in BIOS setup then though the computer wouldn't be very useful [01:17] That includes network [01:18] LaserJock: thanks [01:21] sladen, i have no firewire, its de-soldered [01:23] crypt-0: cricky. +1. That is paranoid [01:40] cjwatson: well, this is truly fascinating [01:42] sladen, what use is disk crypto if any script kiddie can crack your system wide open with thier laptop? [01:43] If you give an attacker physical access, you’re screwed.' [01:45] I still haven't seen any reasonably plausible demonstrations of how SHA1 in this case comprises a major vulnerability [01:55] bryce: well, that's nice [01:55] usplash uses bogl with noueveau too ;p [02:05] Keybuk: are you subscribed to 'boot' bugs just because people like to file boot issues there or do you actually use it? :) [02:06] Amaranth: because people like to file boot issues there [02:06] I have never knowingly known anything about 'R' [02:07] hehe, figured [02:07] including why 'R' maintainers think namespaces only happen to other people [02:08] Well, R isn’t even a word. “A” would be a better name. [02:10] I'm pretty sure I objected to R's namespacing on debian-devel in like 2002 or something [02:13] the way its packaged, or some internal of its implementation? [02:15] slangasek: around? [02:15] can you remember why we decided to unconditionally load vesafb? [02:16] cjwatson: I take it dirk objected to your naming? :) [02:16] is it just me or is packages.ubuntu.com down? (port 80 closed) [02:17] he sure loves his R [02:17] geofft: there are a few machines that are experiencing issues...I just ran across a bug report for p.u.c so it is known [02:17] okay, thanks [02:17] keyserver is another one with issues [02:18] lifeless: the binary packages have r-cran-* namespacing; the source packages typically do not, hence 'boot' (binary: 'r-cran-boot') [02:18] Keybuk: ... was I around when that decision was made? [02:18] there was some excuse about "boot" being the upstream name [02:18] slangasek: yup [02:18] I have a feeling it got noted down somewhere with a ? and the ? got lost, so we force load it [02:18] Keybuk: well, I don't think I was party to the decision... [02:18] I was talking at you :) [02:18] hmm :) [02:18] you were being a teddy bear [02:19] I wondered if you could remember *why* I did that [02:19] hey guys [02:19] is anyone here? [02:20] cjwatson: yeah, I remember when I was doing MOTU Science we got a ton of mis-filed bugs :-) [02:20] d3xter: no [02:20] alright ^^ [02:23] well, one of my friends tryed to install nvidia 185 on 9.04, but the installation messed up, so he tried to get back to 180, but the links libGL and libGLcore still remained at the 185 versions of this libraries [02:23] is there any way, so that other users dont get stuck with this problem? [02:24] usplash hates me [02:27] I bet it's pitti's fault [02:30] cjwatson: ughhhhh [02:35] that's interesting [02:35] it is *kinda* pitti's fault ;) === NCommander is now known as NC|G1 [02:36] the problem isn't that the console is screwed [02:36] the problem is that usplash isn't exiting [02:36] but you can't tell that, because he's set the entire palette to a trendy black-on-black :p [02:37] I seem to find the ?no-redirect thing for filing Ubuntu bugs offensive somehow. === NC|G1 is now known as NCommander [02:38] It doesn't help that it combines with the frequent timeout bug in a way which probably makes it even harder to report bugs against Ubuntu than whoever came up with the idea intended. [02:38] timeout, hit back, get bounced back to the wiki page asking for people to not report bugs [02:39] I almost gave up and didn't report this bug that I'm now going to report [02:39] exarkun: #ubuntu-bugs is probably the best channel for feedback on that decision. [02:39] I'm sure the average Ubuntu user wouldn't have gotten nearly this far [02:41] ScottK: This is about barrier to participation. And as a demonstration, I'm afraid I'm going to have to decline to join #ubuntu-bugs and re-complain about it there. If no one here cares enough to pass on the message, then I guess the feedback will be lost and the community will suffer. Or maybe not even notice. Beats me. Anyway, this has already taken twice as long as I expected, I'm not going out of my way to find more work. [02:41] exarkun: we've been shouting about the message ourselves [02:42] exarkun: It wasn't anyone here who made that decision. You are declining then to discuss it with the people that can do something about it. Not very effective. [02:43] ScottK: Yes, it's too bad. [02:43] My bug is filed. Good night. [02:45] hmm [02:45] well I wish everything was that easy [02:49] :-) [02:56] Hereby world peace has been achieved. Good night. [02:58] Ah ha! 2.6.31-14 did hit universe. Thanks for making that helpful to find out, LP. [03:06] ok [03:06] so usplash is getting SIGTERM ok [03:06] and is exiting [03:06] but is not unpainting the screen [03:06] or changing the console [03:06] or, in fact, anything === greeneggsnospam is now known as jsgotangco [03:08] StevenK: it did? [03:08] hyperair: Yup [03:08] er where does it say? [03:08] i only see it in main [03:08] I can see the kernels themselves in universe. [03:08] huh? [03:09] link? [03:09] hyperair: I can't give you a link, I'm doing it from a shell on the archive master. [03:09] aah i see [03:10] but why are there kernels in universe? [03:10] They aren't supposed to be [03:10] Keybuk: do you have a way to reliably reproduce the X+cryptsetup conflict bug? I've never seen it here and can't reproduce it at all, regardless of what sleeps I put where [03:11] * hyperair doesn't understand [03:11] slangasek: I can't even get cryptsetup to work for me normally [03:12] slangasek: whats the bug ? [03:13] Keybuk: getting cryptsetup to work is orthogonal to reproducing the bug [03:13] Keybuk: most users complaining about this aren't using crypted disks [03:13] slangasek, cjwatson: The 2.6.31-14 kernel was accepted to universe, I'm just in the middle of processing it into main. [03:13] well. I /hope/ it's orthogonal... maybe you have to not be using cryptsetup to reproduce it :P [03:14] StevenK: ah, sigh; thanks [03:14] slangasek: is there a bug # ? [03:14] lifeless: bug #439138 [03:14] Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Confirmed] https://launchpad.net/bugs/439138 [03:18] slangasek: hey, i need to move a couple of upstart scripts from one binary package to another [03:18] slangasek: should i purge it in the old package in a preinst script (conditional on the version)? [03:19] kirkland: that's what Conflicts/Replaces is for [03:19] Amaranth: good call [03:21] /c/c [03:22] ok bogl is fine [03:22] it's the svga backend [03:22] which explains why intel people don't see this [03:26] wow busy bug [03:28] the best ones are === Whoopie_ is now known as Whoopie [03:53] hmm [03:53] that's the third screwed initramfs in a row [04:16] what's the recipe for moving a file from one package to another, when both packages are going to be installed at the same time on the same system [04:17] conflicts/replaces i know, more detail please [04:17] (it's late) [04:17] replaces: [04:17] that's all you need [04:17] Keybuk: okay [04:17] I think I just beat usplash [04:17] that's like the biggest end-of-level boss ever [04:17] * kirkland high fives Keybuk [04:18] in the last four hours, I have learned more about svgalib than any human should have to [04:18] Keybuk: is it 3:20am for you? [04:18] 4:20am [04:19] Keybuk: prime hacking time [04:20] exactly, and this is a *good* bug [04:20] one of the ones you can really get your teeth into [04:21] ooohohhhhhh yes! [04:21] usplash just exited normally with a console flip ;) [04:21] and now I just got a getty [04:22] now the ultimate test, booting into X [04:22] then seeing if C-A-F1 works again [04:23] \o/ [04:24] * TheMuso follows with interest. :p [04:24] kirkland: replaces says 'when this package is installed take over files from that package' [04:25] kirkland: so its necessary; sometimes its not sufficient,and in that case 'breaks' is wanted - not conflicts. conflicts is a last resort [04:25] lifeless: thanks that makes more sense [04:26] lifeless: replaces is confusing, because only a couple of files are replaced, not the whole package [04:26] to determine if you need breaks:, consider 'if the old version of the other package is not upgraded will things still work' [04:27] if the answer is no, you need to either breaks other << VERSION or depend other >= VERSION [04:27] depending on why things wouldn't work, which is clearly situation specific [04:27] if you cannot _unpack_ the packages at all at the same time, then you need conflicts: rather than breaks: [04:29] TheMuso: https://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/revision/323 if you're curious [04:29] lifeless: great, thanks, that's very helpful [04:29] anytime [04:39] Keybuk: why intel> ah, damn, so that's why I can't reproduce it at all here [04:41] Keybuk, please disregard earlier noise on a possible mountall regression; it was an unfortunate red hearing [04:42] NCommander: yes, most mountall bugs that happen before it's even started are ;) [04:42] slangasek: right, you had mode setting [04:42] mode setting uses the bogl backend [04:42] which is fine [04:43] right, just means that the time I spent trying to reproduce the problem was wasted [04:43] (AIUI) [04:43] yeah we never saw corrupted text on intel [04:44] if you added intel.modeset=0 to your command-line you may well have done [04:44] Keybuk, *cough*. I'm not very familiar with mountall. So sorry for the noise ^ 2 [04:44] Keybuk: what's the upstart debug variable i can set to get more verbose output in syslog? [04:44] kirkland: initctl log-priority debug ? [04:44] well, I also couldn't reproduce the 100% CPU usae [04:44] usage [04:45] slangasek: that's a different issue to this one [04:45] should that be reproducible on intel? [04:45] oh [04:45] what bug # are you working on? [04:45] this was the "text consoles always corrupted and unusable, whether or not you start X" bug ;) [04:46] StevenK: did you get through moving the kernel back to main? it looks like only amd64+i386 have been fixed, maybe? [04:46] slangasek: I took the binary names from the ACCEPTed .changes [04:46] Keybuk: cool; i can put that anywhere in there? [04:47] StevenK: on all archs? [04:47] kirkland: anywhere in where? [04:47] kirkland: it's a command to be run [04:47] slangasek: lpia and ia64 should have it that list too [04:47] slangasek: what is the 100% bug # ? [04:47] Keybuk: oh [04:47] kirkland: so you need to run it before the stuff you care about logging [04:47] slangasek: thx [04:47] s/ it/ hit/ [04:47] Keybuk: bug #439198 [04:47] Launchpad bug 439198 in nvidia-settings "using propretory drivers for my nvidia 9500gt did not function correctly. also, i got a crash when trying to install the upgrade tool." [Undecided,New] https://launchpad.net/bugs/439198 [04:48] no, that's not it [04:48] Keybuk: bug #439138 [04:48] Launchpad bug 439138 in cryptsetup "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Confirmed] https://launchpad.net/bugs/439138 [04:48] better [04:49] ok [04:49] I shall upload the owner -> output fix [04:49] slangasek: I can pastebin the entire list of packages I touched, but I can see powerpc, ia64 in that list. Interestingly only -di bits for i386/amd64 [04:49] and if that makes it go away, we know we isolated the real cause [04:49] we do? [04:49] and can "improve" it later [04:50] StevenK: ah. Ok, I've punched the rest into main now; I just did it by source package, and after the next publisher run I'll demote those that aren't supposed to be in main [04:50] Ah, I did the piecemeal approach. [04:50] ehm, if there even are any [04:51] slangasek: I think it's because the publisher hasn't run yet [04:51] slangasek: Contents generation is running, which has taken over the publisher running this hour [04:52] StevenK: change-override assured me that there were packages still needing their components updated [04:52] Curious [04:52] I'm concerned that I didn't see -di bits for !i386,amd64 [04:53] yeah, that's what I saw being picked up by change-override this time === dendrobates is now known as dendro-afk [05:32] slangasek: i just uploaded eucalyptus_1.6~bzr931-0ubuntu1_source.changes ... should this make it onto tonight's daily CD build? [06:34] kirkland: server daily build is at 10:30 BST, so yeah === pwnguin is now known as `Xenocide === `Xenocide is now known as pwnguin === Richie is now known as YDdraigGoch [07:32] pitti, slangasek: please trigger a -server daily CD respin [07:38] good morning === tkamppeter_ is now known as tkamppeter [07:54] lool, paulliu: there's a bunch of sync requests of new packages in the sponsoring queue... did you guys talk to the release team about it? [07:57] dholbach: not yet. How to do that? We only have an FFE. [07:58] oh... you have a FFE [07:58] sorry [07:58] nevermind me [07:58] dholbach: Those new packages are already well tested in our PPA for a long time. We are conservative now and not chasing the latest version of Intel's Moblin repo. [07:58] ok [08:00] where does libmoblin-panel-dev come from? [08:01] dholbach: mutter-moblin. [08:01] dholbach: There are some dependencies. anerley should go first. And then mutter-moblin. [08:01] looks like they are still waiting in the queue somewhere? [08:01] dholbach: Yes. In New. [08:01] ok [08:03] dholbach: (Right, we have a LP #425547 as some kind of standing FFE on Moblin packages) [08:03] Launchpad bug 425547 in Ubuntu Karmic "Ubuntu Moblin Remix: Merging ~moblin PPA packages into karmic" [Undecided,In progress] https://launchpad.net/bugs/425547 [08:03] (Morning) [08:04] ok, super [08:04] hi lool [08:06] * dholbach loves Launchpad's -changes mails that tell us how to spell "non-Standard" letters: ALEFHAHMEEMDAL ALEFLAMMEEMHAHMEEMWAWDALYEH [08:29] pitti, hey good morning. I've tried to provide a fix for bug 449411 (extracting .desktop translations for onboard). Onboard is using the auto module from python-distutils-extra, which should autodetect .desktop.in files. However, it didn't seem to do it, and I had to explicitly list them in a setup.cfg file. I'm just wondering, was that the right way to do it? [08:29] Launchpad bug 449411 in ubuntu-translations "Make the desktop entries translatable" [High,In progress] https://launchpad.net/bugs/449411 [08:38] cjwatson: do you have the magic power to respin server ISOs ? My usual helper doesn't seem to be around :) [08:39] Good morning [08:40] pitti: good morning ! [08:42] dpm: hm, can you please show me your changes? [08:42] hey ttx [08:43] pitti: see backlog, I need a server CD respin when you have 2 minutes. [08:43] HI! packages.ubuntu.com does not work again. Who to report that? [08:43] wgrant: I guess none of the counts on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html deduct the "superseded source versions"? [08:43] ttx: running (CC: slangasek) [08:44] pitti: great! [08:44] pitti, yes, the changes are here -> http://launchpadlibrarian.net/33487525/make-desktop-files-translatable.debdiff [08:45] (I basically renamed the .desktop files to .desktop.in, marked them for translation and added them to setup.cfg) [08:46] slangasek: No, they don't. I can easily enough fix that. [08:46] dpm: oh, there are two patches, one for renaming and one for adding the X-Ubuntu-Gettext-Domain one [08:47] dpm: (they could be just merged, but nevermind; just looked confusing) [08:47] hm, LP isn't talking to me -- is this happening to anyone else? [08:47] pitti, ah, ok, I'll take that into account for the next time [08:47] wgrant: would appreciate it, seeing as I noticed this 5 minutes /after/ sending out a mail to u-d-a with some overinflated numbers ;) [08:48]