[01:30] <cyphermox> robert_ancell: hey
[02:04] <RAOF> ARGH STUPID DAMN SSDs.
[02:05] <lifeless> RAOF: ?
[02:05] <RAOF> The ssd in my laptop has decided that it's *too good* to talk to the bios. Therefore, the bios sees it not.
[02:05] <lifeless> hah
[02:06] <lifeless> 'too good'? Is that hyperbole, or an actual error symptom ?
[02:06] <RAOF> Hyperbole ;)
[02:06] <RAOF> It no longer appears in the BIOS' list of devices; presumably it's not responding to SATA commands.
[02:08] <RAOF> This is why déjà dup is set to daily backups.
[02:23] <bryceh> RAOF, last week I had a problem where the SSD wouldn't come up, because the freakin' liveusb stick installed the boot loader on the usb stick.  wtf.
[02:24] <RAOF> That's a bit sub-optimal
[02:24] <bryceh> RAOF, so the ssd only booted when the usb stick was installed.  fun!
[02:24] <bryceh> of course, easy to fix once I figured out what was going on, but eesh.
[02:24] <bryceh> common problem with liveusb's with persistent storage enabled, apparently.
[03:03] <thomi> Does anyone know what "failed to set drm interface version" means? It's an error that I'm getting from X on three separate boxes with different graphics cards when trying to live-boot the precise daily CD image.
[03:03] <TheMuso> Given all the things I've heard about SSDs, I can't help but wonder if the tech is still a little immature.
[03:05] <RAOF> thomi: "failed to set drm interface version" generally means one of two things: the drm modules aren't ready, or you don't have the requisite permissions.
[03:06] <RAOF> Woot! Thank you deja-dup; now I have the actual code I want to palm off to robert_ancell :)
[03:06] <thomi> hmmm, I'm guessing it's the former, rather than the latter, since this is the live CD
[03:06] <thomi> RAOF: any idea how I'd check that?
[03:06] <RAOF> Where are you seeing that?
[03:06] <robert_ancell> RAOF, lost then found again?
[03:07] <RAOF> robert_ancell: On an SSD that's died, then extracted from yesterday's backup.
[03:07] <thomi> RAOF: in the X log, instead of booting into the desktop I get the "system running in low graphics mode" dialog.
[03:08] <RAOF> thomi: You could pastebin the Xorg.0.log; you could also try logging in to a VT and checking that the drm module's up and running - that'd be one of i915, radeon, or nouveau.
[03:09] <bryceh> TheMuso, I've a bunch of systems on SSD's now, and anecdotally would say they're definitely no worse than HDDs generally
[03:09] <thomi> RAOF: the 'radeon' module is indeed listed in 'lsmod'
[03:09] <bryceh> TheMuso, remember with HDD's there's a class of mechanical problems you can run into, which just aren't going to happen on SSD's.
[03:10] <cyphermox> robert_ancell: fyi; seb told me you were working on g-s-d 3.5; might want to merge with what's currently in lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu if you have a local branch, I did an upload earlier.
[03:10] <RAOF> thomi: If you start lightdm now, does it work?
[03:10] <TheMuso> bryceh: Yeah I know, same for both I guess, I've just heard of some pretty bad SSD failings, which surprises me for drives with no moving parts.
[03:12] <thomi> RAOF: I don't get an error, but I can't seem to switch to VT7, I just get a black screen. However, there's a chance that's the KVM I'm fighting with
[03:12]  * thomi checks logs
[03:12] <RAOF> I think the vertex series is particularly bad; I heard similar bad things about vertex 2 drives, but (at the time I bought it) people were saying that the vertex 3 had resolved that.
[03:17] <bryceh> TheMuso, maybe so.  I always research my drive purchases on newegg and have yet to have an SSD failure (out of about a dozen I own currently).
[03:18] <bryceh> TheMuso, of course having said that I'm sure tomorrow I'll have the SSD in my most critical system go down...
[03:18] <micahg> bryceh: how old is your oldest drive?
[03:19] <thomi> RAOF: OK, I finally beat the KVM into submission. Yes, if I start lightdm manually it works perfectly
[03:19] <RAOF> thomi: In that case it sounds like a race between X startup and drm.
[03:19] <RAOF> thomi: Are you only seeing this on radeon cards?
[03:20] <thomi> RAOF: nope, I have *exactly* the same issue on three separate machines running radeon, nvidia, and intel chipsets
[03:20] <RAOF> That's very odd.
[03:21] <thomi> RAOF: possibly something to do with it being a PXE boot?
[03:22] <thomi> I dunno how that would change anything though, but I guess having an NFS FS might make some race conditions rear their heads
[03:22] <RAOF> I guess it *could* be? But intel and nouveau are usually better at actually waiting for their devices to come up before bailing in that way.
[03:24] <thomi> RAOF: I am able to tweak the OS before it boots, so if there's a hack you can think of to make sure things happen in the right order I'm happy to try it out
[03:25] <bryceh> micahg, hardy timeframe.
[03:25] <RAOF> thomi: Loading the drm modules into the initramfs should rule out a race.
[03:25] <micahg> bryceh: a 4 yr old SSD?
[03:27] <bryceh> micahg, hmm that doesn't sound right
[03:27] <thomi> hmmm
[03:28] <RAOF> thomi: An easy way to get the drm modules into the initramfs is to install cryptsetup, then rebuild the initramfs.
[03:33] <thomi> RAOF: sp is the kernel module always called 'drm', or does that change between drivers?
[03:38] <RAOF> thomi: There's drm.ko, drm_kms_helper.ko, and a hardware-specific driver - i915.ko, radeon.ko, nouveau.ko.
[03:38] <bryceh> micahg, I'm a year off; it was right after berlin, which looks like it was the Jaunty sprint in Feb 2009
[03:39] <micahg> bryceh: still, a 3yr SSD seems amazing
[03:39] <thomi> RAOF: thanks
[03:42] <bryceh> micahg, yeah I got in early on ssd's.  That particular drive has been hand-me-downed through a few systems.  I've lost track of where it exists now but think it's in a netbook I gave to a relative.
[04:06] <thomi> RAOF: possibly a stupid question: Would it matter if I loaded a graphics driver in the initramfs that wasn't needed for the hardware? For example, I had the 'radeon' module in there and the machine had an intel card?
[04:06] <thomi> ...reason being: I have one OS image that serves several different machines
[04:07] <RAOF> No; the modules will only autoload if the hardware they support is present, and (generally) will fail to load if you try to manually modprobe them on a system without hardware they can drive.
[04:08] <RAOF> And won't *harm* anything even if they do load.
[04:09] <thomi> ok, cool
[04:14] <pitti> Good morning
[04:40] <cyphermox> hey pitti
[04:40] <cyphermox> I'm planning on starting on the drivers stuff "tomorrow", basically in a few hours
[04:41] <cyphermox> I'll poke your brain about the plans then :)
[04:47] <pitti> cyphermox: nice!
[04:47] <pitti> looking forward to the new GUI
[05:41] <rickspencer3> good morning all
[05:43] <pitti> hey rickspencer3
[05:43] <rickspencer3> hiya pitti
[05:43] <rickspencer3> pitti,  how is your new upstream QA work going?
[05:44] <pitti> rickspencer3: some slow progress; still working on desktop backlog
[05:44] <pitti> rickspencer3: but I submitted my first kernel patch last week and did not get flamed (didn't get applied yet, though)
[05:44] <rickspencer3> pitti, backlog of desktop work, or backlog of desktop QA?
[05:45] <pitti> rickspencer3: and I'm making some nice progress on the udisks2 test suite; it already helped to discover one bug in udisks2 itself, and one in util-linux, which is quite nice (and unexpected)
[05:45] <rickspencer3> congrats!
[05:45] <pitti> rickspencer3: desktop work; some python3 porting and the like
[05:45] <pitti> but that's fine
[05:46] <rickspencer3> well, looks like daily quality is still marching along, except KDE seems to be in some difficulties
[05:46] <pitti> yeah, today quantal is much better than yesterday
[05:51] <BigWhale> Good Morning.
[06:03] <didrocks> good morning
[06:10] <rickspencer3> 'morning didrocks
[06:10] <didrocks> bonjour rickspencer3, ça va ?
[06:11] <rickspencer3> ça va bien
[06:12] <rickspencer3> expeté, je n'ai pas café
[06:12] <rickspencer3> je dois sortir pour café biento ....
[06:12] <rickspencer3> je dorm ....
[06:12] <rickspencer3> zzzzzzz
[06:13] <rickspencer3> didrocks, et tois? ça va?
[06:14] <didrocks> rickspencer3: ça va bien! pas encore pris de café non plus, mais je vais me faire un petit thé bientôt
[06:16] <rickspencer3> tu as la vie sànte
[06:17] <didrocks> je sais pas si le thé est plus zen que le café, mais je préfère son goût
=== tkamppeter_ is now known as tkamppeter
=== rickspencer3_ is now known as rickspencer3
[08:06] <seb128> hey
[08:06] <didrocks> salut seb128, ça va?
[08:06] <seb128> lut didrocks, ouais, et toi ?
[08:07] <didrocks> ça va bien :)
[08:07] <Sweetshark> bonjours mes amis!
[08:07] <seb128> Sweetshark, guten tag!
[08:08] <Sweetshark> ;)
[08:12] <Sweetshark> seb128: I could need a helping hand with forcing gcc to 4.6 on quantal. I have "build-conflicts: gcc (>= 4:4.7~) [!kfreebsd-i386 !kfreebsd-amd64], g++ (>= 4:4.7~) [!kfreebsd-i386 !kfreebsd-amd64]" but dpkg complains that g++ 4.7 whats gcc 4.7. yeah, right. but it shouldnt fiddle with g++ 4.7 anyway ...
[08:12] <Sweetshark> seb128: https://launchpadlibrarian.net/107401324/buildlog_ubuntu-quantal-amd64.libreoffice_1%3A3.6.0~beta1-0ubuntu4_FAILEDTOBUILD.txt.gz
[08:12] <seb128> Sweetshark, do you need to remove 4.7? can't you just build-depends on 4.6 and tweak CC= and equivalents?
[08:16] <Sweetshark> seb128: maybe -- Im unsure, if the old build system respects CC in every corner ...
[08:16] <seb128> Sweetshark, the issue there is that build-essential depends on 4.7
[08:16] <seb128> Sweetshark, I'm not sure you can remove build-essential from the buildds
[08:17] <Sweetshark> seb128: right
[08:19] <Sweetshark> well, the old bs should work on that too ...
[08:19] <seb128> Sweetshark, ?
[08:19] <seb128> bs?
[08:20] <Sweetshark> seb128: old build system (or old bull****) ;)
[08:21] <seb128> heh, I see ;-)
[08:28] <glatzor> hello mvo
[08:29] <glatzor> mvo I added some patches to lp:~aptdaemon-developers/aptdaemon/ubuntu-precise to reduce the shame on errors.ubuntu.com :)
[08:32] <pitti> popey: hey Alan, how are you?
[08:33] <pitti> popey: do you guys plan to port unity away from libgdu to libudisks2 soon? udisks1 and libgdu are both obsolete
[08:35] <seb128> pitti, I doubt anyone is working on that yet, I'm not even sure they knew about that transition, can you open a bug?
[08:35] <pitti> sure
[08:36] <pitti> should be fairly easy
[08:36] <BigWhale> seb128, I chatted with DktrKranz yesterday. He'll update keybinder and get it ready for Wheezy in the next couple of days.
[08:38] <popey> pitti: I was not aware of that
[08:38] <popey> thanks!
[08:38] <pitti> popey, seb128: I filed bug 1012000 about it
[08:38] <ubot2> Launchpad bug 1012000 in unity "Port to libudisks2" [Undecided,New] https://launchpad.net/bugs/1012000
[08:39] <seb128> pitti, thanks
[08:39] <pitti> popey: please let me know if there is any trouble; I know udisks rather well, so can help if there are any questions
[08:39] <pitti> just got bug 1011997, which reminded me about this :)
[08:39] <ubot2> Launchpad bug 1011997 in compiz "compiz crashed with SIGABRT in g_assertion_message()" [Undecided,New] https://launchpad.net/bugs/1011997
[08:40] <pitti> I can reliably crash compiz by running udisks' test suite
[08:40] <popey> delightful!
[08:40] <seb128> pitti, you probably want to talk to the unity hackers rather than the packagers, I will ping andyrock, I think he's the closer of a maintainer for that code
[08:41] <pitti> right; I pinged popey because I thought he would know best whom to assign/forward it to
[08:41] <pitti> seb128: merci
[08:43] <seb128> pitti, andyrock said he would work on it ... btw is the sigabrt a unity issue or a libgdu one?
[08:44] <pitti> I don't have the full stack trace yet, but I figure it's calling gdu_pool_get_by_device_file() with a NULL argument or so
[08:44] <pitti> it seems the code/logic for getting teh actual assertion message isn't working, meh
[08:44] <pitti> that even has a test in glib
[08:44]  * pitti puts that on his todo
[08:44] <seb128> pitti, https://launchpadlibrarian.net/107405806/Stacktrace.txt
[08:44] <seb128> stacktrace from the retracer
[08:45] <seb128> interesting stuff are optimized out...
[08:45] <seb128> get_device_for_device_file (device_file=0x375a880 "/dev/sdb")
[08:45] <mvo> glatzor: awsome, let me sponsor that
[08:45] <seb128> though
[08:46] <pitti> get_device_for_device_file (device_file=0x375a880 "/dev/sdb") seems complete, though
[08:46] <pitti> so, presumably in libgdu
[08:46]  * pitti reassigns
[08:47] <mvo> glatzor: I'm currently working on your python-apt MP for the auth stuff too
[08:47] <pitti> seb128: updated the bug, FYI
[08:47] <seb128> pitti, danke
[08:48] <pitti> seb128: I got your ping about bug 1010141, btw; on my todo list
[08:48] <ubot2> Launchpad bug 1010141 in gvfs "gvfs-gdu-volume-monitor automounts loop devices, preventing them from being unmounted" [Low,Triaged] https://launchpad.net/bugs/1010141
[08:48] <seb128> pitti, danke
[08:48] <seb128> pitti, I got pinged by kees about it, I've the feeling the google guys are bothered about it ;-)
[09:03] <chrisccoulson> good morning everyone
[09:07] <didrocks> seb128: oh, meeting report reminder!
[09:07] <didrocks> hey chrisccoulson ;)
[09:07] <seb128> chrisccoulson, hey, how are you?
[09:07] <seb128> didrocks, thanks
[09:09] <chrisccoulson> hi didrocks seb128
[09:10] <chrisccoulson> i'm good thanks, how are you?
[09:10] <chrisccoulson> i'd be better if i didn't have to drop everything to fix a bug i can't even reproduce though ;)
[09:11] <jibel> Sweetshark, ping
[09:11] <Sweetshark> jibel: pong
[09:12] <jibel> Sweetshark, hey, I have setup an environment in the lab that builds LO periodically
[09:13] <jibel> it's currently setup to build from the pre-release PPA on Quantal
[09:13] <jibel> Sweetshark, the results are here https://jenkins.qa.ubuntu.com/job/quantal-pkg-libreoffice/
[09:13] <Sweetshark> lemme guess, you want a 3.6 beta building against gcc 4.6 on quantal?
[09:14] <jibel> Sweetshark, it's using 4.7 currently
[09:14] <jibel> and fails on i386 as expected
[09:14] <jibel> Sweetshark, amd64 builds but make check fail
[09:14] <jibel> https://jenkins.qa.ubuntu.com/job/quantal-pkg-libreoffice/ARCH=amd64,label=albali/26/
[09:14] <jibel> Sweetshark, is there any log I should collect from the build env when check fail ?
[09:17] <Sweetshark> not as it is now, but with next upload (for quantal), ./debian/rules should set "ulimit -c unlimited" if you have gdb installed and that should give us a helpful stacktrace from the crashers ...
[09:18] <seb128> chrisccoulson, I'm good thanks
[09:18] <Sweetshark> s/stacktrace/stacktraces/
[09:19] <Sweetshark> jibel: however, I am trying to force gcc=4.6 on quantal for now -- I dont see these issues on gcc-4.6.
[09:19] <Sweetshark> jibel: so, it might be interesting to see if those are indeed introduced by gcc 4.7
[09:21] <Sweetshark> see https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+sourcepub/2504240/+listing-archive-extra for the current build of beta on quantal (hopefully against 4.6)
[09:27] <jibel> Sweetshark, ok, I updated the source and it's building.
[09:43] <Sweetshark> jibel: as for archiving artifacts from that: while the logs should be a lot more helpful already with the new version and gdb around (because they then have stacktraces), it might actually be interesting to get the core dumps in the long run.
[09:44] <Sweetshark> jibel: they should be generated by the build system then and might be rather helpful in debugging the issues ...
=== rickspencer3_ is now known as rickspencer3
[10:56] <seb128> Laney, hey
[10:56] <Laney> hiya!
[10:56] <seb128> Laney, librhythmbox-core5_2.97-0ubuntu1_i386.deb contains librhythmbox-core.so.6
[10:56] <seb128> Laney, can you fix?
[10:56] <Laney> args
[10:56] <Laney> yes
[10:57] <Laney> i'll merge it from debian, was going to do that anyway
[10:57] <seb128> Laney, sorry for not spotting that when sponsoring, I just trusted the update and uploaded, I noticed today because it's in Debian NEW and I looked what binary changed
[10:57] <seb128> Laney, thanks
[11:02]  * Laney configures sbuild to run lintian
=== MacSlow is now known as MacSlow|lunch
[12:27] <valentin_mu> hi guys, i have problems with google earth package - i see corrupted chars everywhere, have no menu "File"
[12:27] <valentin_mu>  i tryed both deb from google and deb made by googleearth-package - they both have problems
=== MacSlow|lunch is now known as MacSlow
=== slomo_ is now known as slomo
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest63012
[13:55] <cyphermox> seb128: mvo: re https://wiki.ubuntu.com/SoftwareAndUpdatesSettings . I'd like to start implementing the Drivers tab; but if it's all supposed to be stuff in our control center, seems like pretty high effort to reimplement the whole software-properties thing in g-c-c before being "able to" add drivers.
[13:56] <cyphermox> OTOH, if the plan is to have this in software-properties for now, I guess it's much simpler
[14:08] <seb128> cyphermox, can we embed python in g-c-c? I think we can't right?
[14:08] <seb128> cyphermox, well I was not at the session at UDS, did we sign to make it a proper panel?
[14:09] <seb128> pitti, ^ do you remember what was stupid us to make panels in i.e python?
[14:10] <pitti> seb128: we didn't use the shell for a long time, so it didn't matter :)
[14:10] <cyphermox> seb128: I have no idea on python in g-c-c
[14:11] <cyphermox> seb128: ok, so from what I see in the blueprint perhaps I'm jumping ahead a little bit
[14:11] <pitti> rodrigo_ looked into this, and AFAIR it was by and large "won't do"
[14:11] <seb128> pitti, well I think the "embed python" was discussed for u1 or similar in oneiric
[14:11] <cyphermox> there's no question of g-c-c in there, just software-properties
[14:11] <seb128> cyphermox, I would say "implement the design in software-properties" to start, we can do the "port to a g-c-c panel" later one, I think we do that most of the code will be able to be reused
[14:12] <cyphermox> yes, most likely
[14:12] <seb128> pitti, do you remember if there was a technical limitation that blocked i.e python panels?
[14:12] <pitti> seb128: I don't know the details, I'm afraid (I never did)
[14:13] <seb128> pitti, I guess the loader code would need to be updated, it's loaded .so atm
[14:13] <seb128> pitti, ok, thanks
[14:13] <seb128> cyphermox, so, yeah, forget about g-c-c in a first time
[14:13] <cyphermox> g-c-what?
[14:14] <dobey> gcc. not needed for python :)
[14:15] <seb128> cyphermox, exactly ;-)
[14:16] <cyphermox> gah, glade dies on me
[14:20] <jbicha> hmm, gnome-documents recommends unoconv which needs python-uno which pulls in libreoffice-core & -common
[14:23] <cyphermox> cute.
=== Guest63012 is now known as Ursinha
=== Ursinha is now known as Guest90889
=== Guest90889 is now known as Ursula
[15:04] <cyphermox> seb128: pitti: well, it's started; I'll get on looking at how I can display the information, but I'm keeping all in lp:~mathieu-tl/software-properties/additional-drivers
[15:04] <seb128> cyphermox, great
[15:04] <cyphermox> UI is already there
[15:05] <seb128> cyphermox, you got glade to behave? ;-)
[15:05] <cyphermox> yeah
[15:05] <cyphermox> it was crashing because of the overlay scrollbars, somewhere in cairo
[15:06] <cyphermox> thanks for reminding me, I should file a bug about this ;)
[15:06] <seb128> you should yes!
[15:22] <seb128> didrocks, chrisccoulson, Sweetshark, cyphermox, mlankhorst, Ursula, Laney, tkamppeter, mterry, kenvandine: 10 minutes before meeting if anyone has a topic to discuss
[15:22] <didrocks> seems there is nothing planned on the wiki yet :)
[15:23] <chrisccoulson> hmmm, i really should add something to the wiki ;)
[15:24] <chrisccoulson> can i assign someone bug 1010466? thanks! :-)
[15:24] <ubot2> Launchpad bug 1010466 in firefox "dropdown boxes on sites stop working" [Undecided,Incomplete] https://launchpad.net/bugs/1010466
[15:25] <didrocks> chrisccoulson: you would feel jalous if we steal it from you :)
[15:25] <chrisccoulson> heh, no, i wouldn't mind ;)
[15:25] <kenvandine> seb128, no agenda items from me
[15:25]  * kenvandine is trying to get info for a partner update, but getting ignored
[15:26] <chrisccoulson> heh
[15:28] <seb128> chrisccoulson, did you manage to reproduce?
[15:28] <seb128> chrisccoulson, I guess reassign to micahg if he can reproduce it?
[15:28] <chrisccoulson> seb128, not yet. and none of the reporters have responded yet. i've tried using unity 2d all day, just in case ;)
[15:28] <seb128> micahg, could you have a look to https://launchpad.net/bugs/1010466 if you are able to trigger the issue? we are not...
[15:28] <ubot2> Launchpad bug 1010466 in firefox "dropdown boxes on sites stop working" [Undecided,Incomplete]
[15:28] <chrisccoulson> yeah, that makes sense
[16:08] <micahg> seb128: I could only reproduce in thunderbird, and even then, I don't think it was every time
[16:13] <seb128> micahg, can you try to see if you can get it again? it might be useful to have somebody around who can reproduce to get us debug infos at least
[16:17] <micahg> seb128: sure
[16:39] <chrisccoulson> the timestamps in X events are in units of milliseconds, aren't they?
[16:39] <chrisccoulson> actually, may be one for #ubuntu-x
[16:41] <bryceh> chrisccoulson, yep
[16:41] <chrisccoulson> bryceh, ah, thanks :)
[16:41] <chrisccoulson> (sorry, just asked on #ubuntu-x as well) ;)
=== rickspencer3 is now known as rickspencer3_
=== rickspencer3_ is now known as rickspencer3
[17:00] <didrocks> see you tomorrow guys! :)
[17:11] <seb128> pitti, are you still around?
[21:39] <bigon> pitti: I've seen you name in the consolekit changelog, so maybe you will have more clue than me
[21:39] <bigon> are you around :)?
[22:16] <jasoncwarner_> robert_ancell RAOF TheMuso just a reminder about the meeting, wiki and agenda items: https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-06-12
[22:17] <jasoncwarner_> and bryceh ^^
[22:18]  * bryceh waves
[22:50] <chrisccoulson> howdy people from the other hemisphere
[22:51] <TheMuso> chrisccoulson: Hey there.
[22:51] <chrisccoulson> hi TheMuso, how are you?
[22:51] <TheMuso> chrisccoulson: Nice catch re unity and C++ ABIs.
[22:51] <TheMuso> chrisccoulson: Not too bad thanks, yourself?
[22:51] <chrisccoulson> TheMuso, yeah, that was a fun one. and i've spent all day today tracking down another nice bug :)
[22:52] <chrisccoulson> other than that, i'm not too bad thanks
[22:52]  * TheMuso feels much more justified in not liking C++ to the point where he feels he'd rather not learn more than he absolutely has to.
[22:53] <TheMuso> All this stuff that pops up with C++ ABIs and gcc issues every minor release puts me right off the language.
[22:53]  * micahg likes C++ much more than the PHP he used to work with
[22:54] <chrisccoulson> TheMuso, oh, C++ isn't too bad. it's the STL that sucks ;)
[22:54] <TheMuso> Its not hard to be better than php. :)
[22:55] <TheMuso> Yeah but thats rather heavily used afaik.
[22:55] <jasoncwarner_> TheMuso robert_ancell RAOF bryceh doesn't look like any agenda items...so no meeting. please update the wiki when you get a chance.
[22:55]  * micahg thought the purpose of the STL was to not have to reinvent the wheel
[22:56] <chrisccoulson> the purpose of the STL is to make yourself suicidal :)
[22:56] <TheMuso> jasoncwarner_: Done thank,
[22:56] <TheMuso> thanks
[22:57] <bryceh> jasoncwarner_, thanks