[00:25] <cheezeburga> hello?
[00:30] <cheezeburga> can anyone tell me the command to open up the sound board?
[00:31] <micahg> !support | cheezeburga
[00:32] <cheezeburga> oh sorry
[01:06] <psusi> is there something like cut that isn't so stupid simple?  I'm trying to extract the rss column from the output of ps and cut seems to be incapable of doing so since the columns are separated with multiple spaces
[01:07] <micahg> psusi: perl? :)
[01:07] <psusi> a little lighter than that? ;)
[01:08] <psusi> I can't bloody believe cut can't do this.... you would think it would be the default mode
[01:08] <micahg> psusi: you can't places the spaces in quotes?
[01:08] <psusi> one or more consecutive whitespace characters... sheesh..  heh
[01:08] <psusi> no... it's the output of ps... I"m not typing it by hand
[01:09] <psusi> and I don't think that would matter anyhow
[01:09] <ajmitch> psusi: pipe it through tr first?
[01:09] <tumbleweed> psusi: awk
[01:10] <psusi> hrm... tr might do it... I keep meaning to learn awk and never do... heh
[01:11] <tumbleweed> psusi: ps waux  | awk '{print $6 " " $11}'
[01:11] <tumbleweed> or just {print $6} for just RSS
[01:11] <ajmitch> or you could be bad & work out which character ranges fit the field you want from the ps output, but that seems awkward
[01:11] <ajmitch> awk just fits better in this case, I think
[01:12] <psusi> ahh, thanks
[01:14] <psusi> hrm... can awk sum the values? ;)
[01:14] <ajmitch> yes
[01:15]  * psusi is trying to track down why the stock ubuntu kernels seem to use 400+ mb more ram than mainline
[01:15] <psusi> 545 mb actually...
[01:17] <micahg> psusi: if each line is a value then: php -r '$myArray = file(my_file); echo array_sum($myArray);'
[01:18] <ajmitch> that involves php..
[01:18]  * micahg forgets most people don't have php installed :-)
[01:18] <ajmitch> s/most/sane/
[01:18]  * micahg doesn't remember offhand how to do the same thing in perl...
[01:20] <ajmitch> how about ps axu |awk '{sum += $5} END {print sum}'
[01:20] <psusi> I was just coming to that conclusion after reading the man page ;)
[01:21] <psusi> hrm.. yea... rss totals virtually the same, yet I have 545 mb more free mem after buffers/cache when running the mainline kernel...
[01:22] <psusi> 845 vs 305 mb
[01:22] <psusi> used
[01:22] <ajmitch> psusi: memory reserved for kernel use?
[01:22] <ajmitch> is this 32 bit vs 64-bit?
[01:22] <psusi> I guess so... but how to figure out why?  64 bit
[01:23] <psusi> that's a LOT of memory for the kernel to be using....
[01:23] <ajmitch>  grep 'Memory.*reserved' /var/log/dmesg
[01:24] <psusi> Memory: 1982480k/2096000k available (5600k kernel code, 468k absent, 113052k reserved, 5522k data, 884k init)
[01:24] <psusi> that seems to be with the running mainline kernel...
[01:25] <psusi> this is the Ubuntu 2.6.35-4: [    0.000000] Memory: 2041420k/2096000k available (5689k kernel code, 468k absent, 54112k reserved, 5436k data, 896k init)
[01:25] <psusi> looks about the same...
[01:26] <ajmitch> [    0.004000] Memory: 8073096k/9175040k available (4743k kernel code, 787460k absent, 313600k reserved, 2525k data, 532k init)
[01:26] <ajmitch> but it's jaunty, on a desktop box
[01:27] <psusi> not much different...
[01:27] <ajmitch> much larger values absent/reserved
[01:28] <ajmitch> though I think that's due to having 8GB RAM
[01:28] <psusi> yea, but not hundreds of mb... and absent I'm pretty sure just means you have more physical ram that is unusable due to poor motherboard/bios
[01:29]  * psusi goes hunting for kernel vm knobs
[02:02]  * andreserl TestDrive PyGTK Front-end Demo Released!
[06:28] <micahg> RoAkSoAx: I think I have the virtualbox patch
[06:40] <micahg> is it proper to give credit to the person that does the original work (by direct name reference instead of commit reference) if you backport their patch?
[07:00] <dholbach> good morning
[07:12] <iulian> Hello dholbach.
[07:12] <dholbach> hey iulian
[07:47] <slytherin> Can anyone help with this error - http://paste.ubuntu.com/453248/ I see this when doing debuild -S -sa, but 'quilt applied' says there are no patches applied.
[07:51] <RAOF> slytherin: Is that a 3.0 (quilt) package?
[07:51] <carstenh> slytherin: remove this hunk from the patch and rebuild?
[07:51] <slytherin> yes
[07:52] <RAOF> slytherin: Then it'll be trying to unapply the patch before constructing the source package (because the patch has been *applied* to the unpacked source).
[07:52] <slytherin> carstenh: you might be right. I never checked if the patch was applied upstream.
[07:52] <carstenh> in dpkg 3.0 patches need to apply _cleanly_
[07:55] <slytherin> carstenh: you were right. The patch was cherry picked form upstream git. Hence it is not needed anymore with latest upstream release.
[07:57] <carstenh> how does ubuntu handle ftbfs bugs in general? if the package has been built by chance release ubuntu including this package and this bug if nobody cares enought to fix it or are this bugs that need to be fixed before releasing?
[07:59] <slytherin> carstenh: The priority of FTBFS bugs depends on which section the package belongs to i.e. main/universe and then which package set, desktop/server/core.
[08:00] <carstenh> it's chromium or rather libv8 on 64 bit kernel with 32 bit userland, i'll check if it is in main
[08:02] <slytherin> it is in universe
[08:02] <carstenh> actually it is chromium-browser since chromium is a game
[08:03] <RAOF> carstenh: Is the FTBFS really that specific?  We don't support that combination, except somewhat half-heartedly, so it's not terribly surprising that it doesn't work.
[08:03] <carstenh> also universe, thanks :)
[08:05] <carstenh> RAOF: in debian it's a serious bug and I know no other package that fails to build with 32 bit userland under an amd64 kernel.
[08:06] <carstenh> but "not supported" is what I wanted to know, thanks
[08:06] <RAOF> carstenh: You mean a real, full 32bit userland?
[08:06] <RAOF> Not multiarch?
[08:07] <RAOF> We still don't support that, but a FTBFS in that situation is going to be significantly more weird.
[08:07] <carstenh> RAOF: uname -a: Linux pergolesi 2.6.26-2-amd64 #1 SMP Wed May 12 23:40:58 UTC 2010 x86_64 GNU/Linux
[08:07] <carstenh> RAOF: dpkg --print-architecture: i386
[08:08] <RAOF> carstenh: Weird.  It's not something to do with the old kernel?
[08:08] <carstenh> RAOF: they do (among other things) to detect the target arch: python -c 'import platform; print platform.machine()'
[08:08] <carstenh> RAOF: no, same with .32
[08:09] <carstenh> and just for the record: no multiarch :)
[08:09] <RAOF> Gah.  This is the problem with autotools.  It's crazy and annoying and awkward, but everything else is *worse*
[08:09] <carstenh> the problem is more not using autotools but scons and inventing weird NIH things ;)
[08:10] <carstenh> and full ack to autotools :)
[08:20] <slytherin> Does anyone know for sure of launchpad supports orig.tar.bz2 when using 3.0 format?
[08:22] <carstenh> supporting 3.0 implies supporting orig.tar.bz2, so if it does not it's a bug
[08:22] <kaushal> hi
[08:22] <carstenh> hi
[08:22] <kaushal> which package contains mutt ?
[08:22] <carstenh> mutt
[08:22] <kaushal> on hardy
[08:22] <carstenh> maybe you need to enable universe
[08:23] <kaushal> ok
[08:23] <slytherin> mutt is in main since start.
[08:31] <Rhonda> Now that's the absolte sweetest thing I ever read in a launchpad bug: "Nothing seems to work, and my dad said that you should raport your problem to ubuntu, so now im here. Thans if you fix problem."  bug 590645
[08:36] <slytherin> Rhonda: Is there any particular reason why you repackage upstream tarball as .tar.gz for wesnoth?
[08:38] <Rhonda> Because source format 1.0 doesn't support .tar.bz2?
[08:38] <directhex> presumably for backportability
[08:38] <directhex> that's the usual reason to repack these days
[08:38] <Rhonda> And the benefits of source format 3.0 are pretty minor when one is using quilt already.
[08:39] <Rhonda> Actually the workflow that source format 3.0 likes to push onto packagers is quite different from 1.0+quilt.
[08:39] <Rhonda> And the most obvious reason: Because wesnoth upstream doesn't provide .tar.gz  :P
[08:40] <RAOF> If you're storing in revision control I think that source 3.0 makes more sense.  Apart from that, eh.
[08:40] <slytherin> Rhonda: If nothing else you could save quite a few MB on mirror by using 3.0 + bz2.
[08:40] <Rhonda> RAOF: Erm, it makes less sense because source 3.0 applies patches to source in unpack stage _additional_ to in debian/patches/foo
[08:41] <Rhonda> So you get the same difference _twice_ into the VCS
[08:41] <Rhonda> slytherin: That's only a very minor gain.
[08:41] <Rhonda> slytherin: Along the same reasoning I would waste quite some processing time on the buildds or anyone who likes to fiddle around with the source.
[08:42] <Rhonda> Diskspace is cheap, I always was told, and the gain isn't that much.
[08:43] <hyperair> i don't have the money for disk space anyway >_>
[08:43] <hyperair> unless you count a 1G thumbdrive.
[08:45] <RAOF> Rhonda: Yeah, you get the changes twice in the VCS.  On the other hand, you also get to use “bzr annotate” on the unpacked source and it works.
[08:46] <Rhonda> RAOF: I wouldn't be insane enough to store upstream sources for wesnoth in git anyway.
[08:46] <Rhonda> Disk space isn't _that_ cheap. And I removed myself from wormux packaging because of the upstream sources got imported into the VCS, too.
[08:47] <Rhonda> You have the annotate on debian/patches/foo too.
[08:47] <Rhonda> So even that part is duplicated.
[08:47] <slytherin> Rhonda: You live in a country with expensive electronics and expensive bandwidth, every bit counts. Anyway it is your decision as maintainer.
[08:49] <Rhonda> slytherin: It requires less bandwidth and diskspace if I pull the tarball seperately and only unpack it when it's needed. If it would be in the VCS I am required to have it unpacked on the harddisk all the time.
[08:50] <Rhonda> So yes, I am doing a decision as maintainer that helps along those lines. :)
[08:50] <slytherin> Rhonda: No. I wasn't even talking about VCS.
[08:50] <slytherin> I was just talking about space in archive.
[08:51] <Rhonda> People don't mirror the archive when they have expensive electronics and expensive bandwidth. They pull only the parts they need.
[08:55] <slytherin> That's where expensive bandwidth comes into picture. The difference is about 30MB. Anyway, let's close the discussion.
[08:56] <Rhonda> The difference in percentage? wesnoth unfortunately isn't the best choice for a package to work on in such an environment, I'm afraid.
[08:57] <Rhonda> Gimme source 1.0 + bz2 and I'll upload it as is. source 3.0 isn't helpful just because of that, it's rather a pain on the contrary, sorry.
[08:58] <slytherin> I can understand.
[08:58] <slytherin> Maintaining something like wesnoth is surely pain. :-)
[08:59] <Rhonda> It really is. Deeper changes are tedious because the build process takes so long. It was a real annoyance to get DEB_BUILD_OPTIONS=parallel working, for a start.
[09:00] <Rhonda> And I still fear a bit the required testing/work for creating the unversioned meta package properly, with dpkg-divert and update-alternatives and the likes.
[09:01] <Rhonda> slytherin: For the last security issues within wesnoth I had to do no less than 6 builds for the various distributions, and when I say builds I mean that, no source-only uploads in Debian.
[09:01] <slytherin> :-)
[09:01]  * Rhonda . o O ( given that a source-only upload without a build for a security issue is a braindead thing anyway )
[09:02] <Rhonda> … s/a build/at least a local-build/
[14:47] <DeeJay1> dholbach: I think I managed to fsck up on samarium - https://code.edge.launchpad.net/~deejay1/+recipe/daily/+build/60 it seems to be running 3 hours now
[14:48] <dholbach> DeeJay1: can you ask in #launchpad - they know what has to be done
[15:06] <DeeJay1> dholbach: will do
[15:42] <AnAnt> Hello, is something missing in 588736 ?
[15:43] <AnAnt> LP #588736
[15:48] <MTecknology> There's an init.d file in debian/ in this package. I want to add an additional init.d script - i'm kind of lost because I don't see where this init.d file gets installed
[15:49] <AnAnt> which package ?
[15:50] <MTecknology> nginx
[15:50] <tumbleweed> MTecknology: dh_installinit normally installs them for you
[15:50] <micahg> AnAnt: bug title: https://wiki.ubuntu.com/UbuntuDevelopment/Merging?action=show&redirect=MOTU%2FPackages%2FMerging#File%20a%20merge%20bug
[15:51] <MTecknology> tumbleweed: the file is init.d - how can I add another file?
[15:51] <AnAnt> MTecknology: why add another init ?
[15:51] <AnAnt> MTecknology: for the -dbg package ?
[15:53] <MTecknology> AnAnt: I've been using a completely different init script for starting php processes that doesn't really fit into the purpose of nginx init script - i have no use for it if I don't install nginx so i figured this would be a decent place to put it - i've had others ask me for the script and i figure this is a way to distribute it too
[15:54] <tumbleweed> MTecknology: put it into examples?
[15:55] <MTecknology> tumbleweed: I want it to wind up executable in /etc/init.d/
[15:55] <tumbleweed> MTecknology: what about the nginx users who don't use php?
[15:55] <AnAnt> MTecknology: well,  dh_installinit  manpage would help you then
[15:55] <MTecknology> tumbleweed: they won't have a reason to grab my version of the packace
[15:56] <MTecknology> package*
[15:56] <tumbleweed> MTecknology: oh, ok then. yes what AnAnt said.
[15:57] <MTecknology> oh...
[15:57] <MTecknology> debian/nginx.init and debian/php-fcgi.init <- add those and the magic dh will work?
[15:58] <AnAnt> MTecknology: you will have to name the init.d file as package.<name>.init, then you will need to pass --name=<name> to dh_installinit in debian/rules file
[15:59] <MTecknology> thanks :)
[16:00] <MTecknology> AnAnt: the man page makes it sounds like I can't pass --name= twice in one line, the dh_prep part makes it sound like i need to pass dh_install_init twice - is that right?
[16:01] <AnAnt> maybe you can run dh_installinit several times
[16:02] <MTecknology> THANKS A LOT :)
[16:03] <MTecknology> sorry- bumped caps
[16:03] <AnAnt> no problem
[16:04]  * tumbleweed disables capslock. it's unecessary
[16:04] <MTecknology> tumbleweed: .. that's an amazing idea
[16:05] <tumbleweed> some oldschool sun-people remap it to ctrl
[16:11] <MTecknology> tumbleweed: I fixed it :D
[16:11] <MTecknology> tumbleweed: took the key off the board
[17:51] <shadeslayer_> tumbleweed: quick question,can i put the current year in debian/copyright if upstream doesnt ship a year for the copyright stuff?
[17:52] <shadeslayer_> or can i leave the year...
[18:17] <MTecknology> darn.. when you spell something wrong the package doesn't build
[18:18] <MTecknology> computer magic should cover that - it should do what i want instead of what i tell it to :P
[19:00] <shadeslayer_> hi is this rules file ( specifically the part about the get-orig-source ) ok ? : http://pastebin.com/b9pFKvy7
[19:03] <geser> shadeslayer_: do I see it correctly that you only repack it to remove the debian directory?
[19:05] <geser> shadeslayer_: have you thought about using v3 source format? that way you could use the upstream tar.bz2 as is (v3 gives you "You don't have to repack the upstream tarball to strip the debian directory." for free)
[19:05] <shadeslayer_> geser: yes,upstream ships a debian/ folder
[19:07] <shadeslayer_> geser: uh... im using the new source format ... the one with debian/source/format
[19:09] <shadeslayer> so no need to use the get-orig-source part?
[19:09] <maxb> You can use source format 1.0 with an explicit debian/source/format - that doesn't tell us anything :-)
[19:10] <shadeslayer> maxb: so what do i have to do for fomat v3 ?
[19:13] <maxb> To enable use of it? Have a debian/source/format that contains "3.0 (quilt)" or "3.0 (native)"
[19:17] <shadeslayer> maxb: thats what i have :P
[19:17] <maxb> Right, the point was just that "the one with debian/source/format" doesn't actually say anything
[19:21] <geser> shadeslayer: no need for get-orig-source in this case (see point 4 in http://wiki.debian.org/Projects/DebSrc3.0)
[19:24] <NorthernLights> Hello all
[19:25] <geser> Hi
[19:47] <gubatron> Good day, who can I talk to to include a package in the official Ubuntu repository? I'm a member of the FrostWire Development team and we've finished gathering all the requirements asked from us on launchpad.net https://bugs.launchpad.net/ubuntu/+bug/94011/comments/27
[19:50] <BlackZ> gubatron: why don't you want to get it in debian directly?
[19:50] <gubatron> BlackZ that'd be even better
[19:51] <BlackZ> gubatron: well, start by reading http://mentors.debian.net/cgi-bin/welcome
[19:51] <gubatron> (I'm fairly new to the process, per your suggestion I understand that it'd make it also to ubuntu users if it got it there)
[19:51] <gubatron> thanks BlackZ
[19:52] <BlackZ> gubatron: you will get it in ubuntu however
[19:53] <gubatron> BlackZ: does your last message mean we're gonna be in Ubuntu? (or only after we get in Debian)
[19:53] <BlackZ> gubatron: if you will get it in debian it will be synced in ubuntu as well
[19:53] <BlackZ> (from debian)
[19:53] <gubatron> 10-4
[19:53] <BlackZ> so I'd say after getting it in debian
[19:53] <BlackZ> hm?
[19:54] <gubatron> 10-4=acknowledged
[20:03] <carstenh> gubatron: do you want to maintain the software yourself or do you want that someone different takes care of the package?
[20:04] <gubatron> carstenh: we can mantain it ourselves, we have done it so we can package everything (.deb binary and .deb sources) in one step whenever we have a new release.
[20:05] <carstenh> gubatron: how do you build the package? normaly there is a .dsc file that is being generated whilst building
[20:05] <gubatron> we build it using dpkg
[20:06] <gubatron> (and a lot of bash and ant before the dpkg)
[20:06] <carstenh> the bash is where?
[20:06] <carstenh> +script
[20:07] <carstenh> (i don't want a url)
[20:07] <gubatron> yeah, it's a script that copies all the sources from our codebase and all the sources from all the GPL third party libraries we need
[20:07] <carstenh> gubatron: do you run ubuntu?
[20:08] <carstenh> currently
[20:08] <gubatron> then it packages everything into a .tar.gz and then we create a file structure that represents how it all will be uncompressed once isntalled. Yes I run ubuntu (and debian)
[20:08] <gubatron> right now, ubuntu
[20:08] <carstenh> good, please run apt-get build-dep pal as root (might require sudo before apt-get)
[20:09] <carstenh> then apt-get install devscripts
[20:10] <carstenh> (i try to show you how rebuilding a package should work since you are doing it wrong)
[20:10] <carstenh> and tell me when these commands have finished
[20:11] <gubatron> I get E: Unable to find a source package for frostwire-src-4.20.6.noarch.deb (so I must be doing it wrong), will read about the devscripts
[20:12] <carstenh> why don't you run the commands I told you?
[20:12] <gubatron> fetching (thought I had to replace pal > mypackage), sorry
[20:13] <carstenh> don't think ;)
[20:13] <gubatron> lol
[20:13] <gubatron> k done
[20:13] <carstenh> now run as normal user (without sudo): apt-get source pal
[20:14] <gubatron> done
[20:14] <carstenh> oh, wait
[20:14] <carstenh> wrong command, at least I should think ...
[20:15] <carstenh> sudo apt-get build-dep hnb
[20:15] <carstenh> and then as user: dget http://ftp.de.debian.org/debian/pool/main/h/hnb/hnb_1.9.18-7.dsc
[20:16] <carstenh> dpkg-source -x hnb_1.9.18-7.dsc
[20:16] <carstenh> cd hnb-1.9.18
[20:16] <carstenh> dpkg-buildpackage -us -uc -rfakeroot
[20:16] <carstenh> cd ..
[20:17] <carstenh> ls
[20:17] <gubatron> [compiling...]
[20:17] <gubatron> done
[20:17] <carstenh> now you see that you have gererated a deb file for hnb
[20:17] <gubatron> hnb_1.9.18-7_amd64.deb
[20:18] <carstenh> every package in ubuntu or debian must be buildable using these commands
[20:18] <carstenh> find :)
[20:18] <carstenh> fine :)
[20:18] <gubatron> got you
[20:19] <carstenh> so, your homework is: make this work for frostwire (except the apt-get build-dep part, you need to install your build dependencies by hand since the package is not yet in ubuntu)
[20:20] <carstenh> before this has been done nobody can review your package
[20:20] <gubatron> thank you very much, this clarifies a lot of questions we had
[20:20] <carstenh> you can delete the downloaded pal and hnb files now
[20:26] <carstenh> gubatron: lintian is very helpful to find errors in the package, after you made this dget some/url/whatever.dsc part work and build the package locally you should run lintian -I -E --pedantic *.changes to see packaging errors and warnings
[20:26] <carstenh> (or without options to see the more major ones if the list is very long)
[21:09] <fabrice_sp> How can I check what is "default-mta"? a package in Debian has been changed to replace exim4 by default-mta
[21:10] <fabrice_sp> I don't find it in p.u.c
[21:10] <carstenh> fabrice_sp: which package?
[21:11] <fabrice_sp> capisuite
[21:11] <fabrice_sp> I mean, the diff between Ubuntu and Debian is that Ubutnu is using default-mta
[21:12] <carstenh> exim4-daemon-light provides default-mta in debian, this is a virtual package
[21:13] <carstenh> when debian switches to postfix only exim4-daemon-light and postfix need to be adapted
[21:13] <carstenh> I would just sync the debian package
[21:14] <fabrice_sp> how can I check which package provides default-mta in Ubuntu?
[21:14] <carstenh> apt-cache showpkg default-mta
[21:14] <fabrice_sp> thx ;-)
[21:14] <carstenh> otoh, Maintainer: Debian QA Group <packages@qa.debian.org> ...
[21:15] <carstenh> find a sponsor and do a upload in debian? :)
[21:16] <fabrice_sp> you said sponsor?! :-)
[21:16] <DktrKranz> s-p-o-n-s-o-r is better? :)
[21:17] <carstenh> fabrice_sp: I'm not here ... but ask me tomorrow if you plan to prepare a qa-upload in debian
[21:17] <carstenh> (unless someone else is faster)
[21:17] <fabrice_sp> cool :-)
[21:18] <fabrice_sp> hmm, it seems that DktrKranz is interested ;-)
[21:18] <carstenh> . o O ( motu is the new debian qa )
[21:18] <fabrice_sp> well, we have a lot in common
[21:18] <fabrice_sp> like trying to maintain unmaintained packages :-)
[21:19] <DktrKranz> fabrice_sp: I'm currently breaking dak with my code, so I don't think I survive this night :P
[21:19] <fabrice_sp> lol
[21:19] <DktrKranz> it works so far, but who knows? :)
[21:21] <ajmitch> DktrKranz: noone uses dak though, right?
[21:22] <DktrKranz> ajmitch: nobody except some old-timer DDs, some mid-timer DDs and some new-timer DDs
[21:22] <Laney> needs moar Launchpad
[21:23] <DktrKranz> go and tell Ganneff ;)
[21:23] <ajmitch> then everything would be sweetness & ponies :)
[21:24] <DktrKranz> ponies!
[21:39]  * geser gives ajmitch http://loldebian.files.wordpress.com/2007/06/pony-small1.png
[21:39] <ajmitch> heh
[23:12] <MTecknology>  [FAILEDTOUPLOAD]  Failed to upload  on ........
[23:13] <MTecknology> What causes this?
[23:15] <MTecknology> oh...
[23:15] <shadeslayer_> :P
[23:25] <jpds> MTecknology: log?
[23:27] <MTecknology> jpds: it was a newer version thing
[23:31] <Laney> 22/06 23:27:58 <MTecknology> jpds: it was a newer version thing
[23:31] <Laney> >> (22/06 23:31:12) (Laney[+i]) (11:#ubuntu-motu[+Ccnz]) (211 nicks (@0 %0 +0 211))
[23:31] <Laney> >> (1=1 |#crumbs    2=2 |#php       3=3 |#short.bus 4=4 |#haskell   5=5 |#toast~ers 6=6 |#debian-uk 7=7 |#relax     8=8 |#deb~n-cli 9=9 |#agda
[23:31] <Laney> 22/06 23:27:58 <MTecknology> jpds: it was a newer version thing
[23:31] <Laney> >> (22/06 23:31:12) (Laney[+i]) (11:#ubuntu-motu[+Ccnz]) (211 nicks (@0 %0 +0 211))
[23:31] <Laney> >> (1=1 |#crumbs    2=2 |#php       3=3 |#short.bus 4=4 |#haskell   5=5 |#toast~ers 6=6 |#debian-uk 7=7 |#relax     8=8 |#deb~n-cli 9=9 |#agda
[23:31] <Laney> 22/06 23:27:58 <MTecknology> jpds: it was a newer version thing
[23:31] <jpds> Laney: Righto.
[23:31] <Laney> >> (22/06 23:31:12) (Laney[+i]) (11:#ubuntu-motu[+Ccnz]) (211 nicks (@0 %0 +0 211))
[23:31] <Laney> >> (1=1 |#crumbs    2=2 |#php       3=3 |#short.bus 4=4 |#haskell   5=5 |#toast~ers 6=6 |#debian-uk 7=7 |#relax     8=8 |#deb~n-cli 9=9 |#agda
[23:31] <Laney> argh
[23:31] <Laney> erase that from your eyes
[23:31] <jpds> What has been seen, cannot be unseen.
[23:32] <jpds> Although... your first window sounds fitting.
[23:32]  * Laney #relax-es
[23:41]  * ajmitch sees spam