[02:21] <optrusty> Hi 🙋 I can't 😞 reop my self on my own channel
[02:22] <jose> optrusty: /msg chanserv op #channelname
[02:25] <Unit193> Next time pass him http://irclogs.ubuntu.com/2014/04/12/%23ubuntu-irc.html and http://irclogs.ubuntu.com/2014/04/16/%23ubuntu-irc.html ?
[02:31] <optrusty> Can't it says you are not authorized
[02:33] <jose> optrusty: no, asking the same question here again and again will always get you the same answer :)
[02:34] <optrusty> Srry keep forgetting the command this Tim I will remeber
[02:35] <optrusty> Bye and sorry
[02:47] <Unit193> Pricey: Heh, just saw the wallop in another client.  Liked the correction. :)
[06:11] <MooDoo> hello all
[07:34] <rww> Got quiet in here all of a sudden after factoidpocalypse II.
[07:35] <rww> Maybe factoidpocalypse II solved all of the problems after all /s :P
[07:39]  * Unit193 pokes rww in the eye to prove there are issues. :P
[07:40] <Unit193> You can't see!  See? :D
[07:40]  * rww petitions the CC to remove Lubuntu's officialness
[07:41] <rww> pRoBlEm SoLvEd
[07:41] <Unit193> Wrong again, I'm more Xubuntu than Lubuntu. :D
[07:41] <rww> seriously though, i feel like that whole conversation died, which would be fine by me except I don't want it to flare up again next year
[07:41] <rww> oh
[07:41] <rww> didn't we bring you in as part of the #lubuntu capture?
[07:42] <Unit193> Yes, but I think nobody could identify what the main issue was in a way that could be fixed.  Yep, but used both at the time too.
[07:42] <rww> Indeed not. I certainly can't. It's difficult :\
[07:43] <rww> maybe we need group therapy at the next IRCC meeting, after we get done enrolling new victims
[07:44] <rww> assuming we're doing that then. the op appointment procedure fell out of my brain a while ago
[07:46]  * Unit193 opts out. :P
[07:47] <Tm_T> opts in
[07:47]  * Tm_T huggles Unit193
[07:47] <Unit193> Tm_T: Well hello kind sir!
[07:48] <Tm_T> and you thought you could escape our "therapy"
[07:48] <Unit193> Hugging typically is the cause of therapy. :P
[07:54] <elky> rww: considering (aiui) the lubuntu ops were a weird mix of people who once spoke in the channel and got ops for it, i'm not surprised about Unit193's origins
[07:55] <rww> that sounds like the process for #ubuntu-offtopic ops
[07:55] <Unit193> elky: Erm, not quite. :)
[07:55] <elky> no, we require more than one comment for that, and a display of insanity
[07:55] <elky> Unit193: perhaps not for you :P
[07:55] <rww> (and rehashing #lubuntu is not something I'm keen to do :P)
[07:55] <Unit193> elky: I got the insanity down good though! :D
[07:56] <rww> (suffice it to say the crew there is doing fine as far as I know, so all's well that ends well)
[07:56] <Unit193> rww: Speaking of systemd, I'm running it now to give it a spin, but not in Debian, in Ubuntu, so all hacked up. \o/
[08:07] <MooDoo> who needs therapy, I love to give hugs ;)
[08:09] <rww> Unit193: nice :)
[09:22] <MooDoo> http://tumbleweed.popey.com/ it's oh so quiet


[01:06] <bryceh> rickspencer3, you abouts?
[01:07] <bryceh> rickspencer3, we've got a bit of a conundrum with one of our bugs
[01:07] <rickspencer3> bryceh, yeah
[01:07] <rickspencer3> 'sup?
[01:07] <rickspencer3> I should have a good connection between here and home
[01:08] <bryceh> rickspencer3, the background is that glx 1.4 was backported by debian from xserver 1.8, however we've found it is buggy
[01:08] <RAOF> And seriously - bug #565981 - buggy.
[01:08]  * rickspencer3 looks
[01:08] <bryceh> rickspencer3, you might remember the issue of Clutter not working, that needed an xserver fix a few weeks ago
[01:09] <bryceh> rickspencer3, it turns out the fix we incorporated causes the memory leak issue that RAOF just mentioned
[01:09] <rickspencer3> yup
[01:09] <bryceh> Sarvatt's been banging his head all over this issue.  We're not finding a suitable solution
[01:09] <rickspencer3> fudge
[01:09] <rickspencer3> so we revert the change, and UNE breaks
[01:09] <rickspencer3> we don't revert the change, everything breaks?
[01:09] <bryceh> what we're considering is dropping both that fix, and the Debian glx backport stuff
[01:10] <rickspencer3> what is the impact of the leak?
[01:10] <bryceh> well, that's why I wanted to raise this with you before we did anything
[01:10] <bryceh> the leak seems to be encountered pretty widespreadedly
[01:11] <rickspencer3> so the clutter bug was caused by backported code?
[01:11] <bryceh> yes
[01:11] <rickspencer3> so you are consider going all the way back to what, glx 1.3?
[01:11] <rickspencer3> fuuuuuuuudge
[01:11] <RAOF> No; 1.2.
[01:11] <rickspencer3> 1.2
[01:11] <rickspencer3> ack
[01:11] <RAOF> 1.3 would be ok, because that's what clutter seems to use.
[01:12] <rickspencer3> whatever
[01:12] <rickspencer3> the point is, roll way back
[01:12] <rickspencer3> ?
[01:12] <RAOF> To the glx version (but not the code) we had in Karmic, yes.
[01:12] <rickspencer3> bryceh, why did we go to glx 1.4 to begin with?
[01:13] <bryceh> rickspencer3, debian had incorporated it into their packaging
[01:13] <bryceh> rickspencer3, so we essentially just inherited it
[01:13] <rickspencer3> ok
[01:13] <bryceh> rickspencer3, however jcristau just mentioned that they're going to drop it in Debian due to these problems
[01:13] <rickspencer3> so did any new and important functionality or bug fixes come with it?
[01:13] <rickspencer3> ah
[01:14] <bryceh> I'm not sure.  What I'm wondering mainly is if it'd negatively impact clutter
[01:14] <rickspencer3> okay, so the 1.2 version has been around a while, and is generally considered good?
[01:14] <RAOF> Yes.
[01:14] <bryceh> i.e. has clutter come to depend on having glx 1.3 / 1.4, and if so will we cause more problems if we remove it than we're solving?
[01:14] <rickspencer3> ah
[01:14] <rickspencer3> I don't know
[01:14] <rickspencer3> I would only be able to ask njpatel that question
[01:15] <RAOF> Apparently clutter only started using glx 1.3/1.4 in clutter 1.2, which we pulled in relatively recently.
[01:15] <bryceh> so, to the best of our knowledge, backing out these patches seems to be the right thing to do, but we don't want to decide this unilaterally and fsck up the clutter folks
[01:15] <rickspencer3> will this make my saurbraughten run slower?
[01:15] <rickspencer3> yeah, so njpatel and didrocks need to be consulted
[01:16] <rickspencer3> can you guys set up something that can be installed and tested in the meantime?
[01:16] <RAOF> Sarvatt's already got a package in the x-testing PPA dropping the glx 1.4 backport.
[01:16] <rickspencer3> bryceh, I agree with your concern, that there is some little thing in clutter that depends on 1.3 functionality
[01:16] <rickspencer3> RAOF, can you please run UNE on it
[01:16] <rickspencer3> and see how the launcher works?
[01:16] <rickspencer3> also try some of the clutter based games?
[01:17] <rickspencer3> robert_ancell, do you know which gnome-games rock clutter the mostest?
[01:21] <robert_ancell> rickspencer3, quadrapassel
[01:21] <robert_ancell> lots of bug reports on that one...
[01:21] <rickspencer3> RAOF, can you run that as well?
[01:21] <RAOF> Yup.
[01:22] <rickspencer3> robert_ancell, well, we're looking for apps that we can run to validate that clutter still works
[01:22] <robert_ancell> rickspencer3, it does like to break :)
[01:26] <Sarvatt> clutter apps shouldn't be affected, it picks which mode to use.. I just looked at netbook-launcher and it's using glx 1.2 functions for the only things not abstracted behind clutter so it's fine, its the apps that call glx 1.3 functions directly that would be a problem (but it's an application bug if it does anyway as the warning will say)
[01:29] <RAOF> Sarvatt: But we haven't tested clutter's glx 1.2 pathways as much recently.  So while clutter apps *shouldn't* be affected… :)
[01:36] <RAOF> UNE & quadrapassel seem to work fine with nvidia-current; I'll test moovida too.
[01:37]  * RAOF kills X to check on intel, too.
[01:46] <Sarvatt> RAOF: nvidia doesn't use the server's GLX anyway...
[01:51] <rickspencer3_> Sarvatt, where would you predict to see any regressions?
[01:53] <jjardon> Dou you know any PPA with unstable Glib/GTK+ packages?
[02:01] <rickspencer3_> RAOF, Sarvatt, bryce says that code that calls glx uses /usr/lib/libclutter-glx-0.8.so
[02:01] <rickspencer3_> is it possible to generate a list of code that calls this?
[02:01] <rickspencer3_> maybe packages that have a dependency?
[02:02] <bryceh> on lucid - /usr/lib/libclutter-glx-1.0.so.0
[02:02] <bryceh> and /usr/lib/libglitz-glx.so.1
[02:02] <rickspencer3_> shall I ask slangasek in #ubuntu-devel?
[02:02] <rickspencer3_> (for some reason it seems like he would know)
[02:03] <RAOF> http://pastebin.ca/1870751 is the rdepends of libclutter-1.0-0, which contains libclutter-glx
[02:03] <bryceh> he'd probably know
[02:03] <bryceh> $ nm /usr/lib/libclutter-glx-1.0.so.0.200.4
[02:03] <bryceh> nm: /usr/lib/libclutter-glx-1.0.so.0.200.4: no symbols
[02:03] <bryceh> hmm, I know there's a way to view the symbols of a library, but old age has made me forget
[02:04] <RAOF> From memory it's a magic objdump invocation.
[02:04] <rickspencer3_> RAOF that looks like a tractable list
[02:04] <bryceh> ahaa  /usr/lib/xorg/modules/extensions/libglx.so
[02:08] <rickspencer3_> RAOF, can you please start to tick these off and make sure they don't break if we roll back?
[02:08] <RAOF> So; UNE, moovida, quadrapassel all work fine on nvidia-current & -intel.
[02:08] <rickspencer3_> good start
[02:09] <rickspencer3_> so long as qudrapassel works, SHIP!
[02:09] <bryceh> hehe
[02:10] <RAOF> Incidentally, moovida is pretty cool :)
[02:10] <rickspencer3_> yes it is
[02:17] <rickspencer3_> RAOF, don't bother with moblin stuff
[02:18] <RAOF> Ok.
[02:19] <rickspencer3_> RAOF, is there way to see what out of this list has not been updated since we were on 1.2?
[02:20] <RAOF> Checking the changelogs would be possible.
[02:22] <RAOF> That's not necessarily enough, though; the libclutter codepaths will be different for the GLX 1.2 case, so we could hit bugs there without any client code changes.
[02:23] <rickspencer3_> RAOF, right, there are two classes of problems:
[02:23] <rickspencer3_> 1. bugs caused by 1.2 api calls, that is, bugs in glx 1.2
[02:23] <rickspencer3_> 2. apps that depend on version 1.3 api calls
[02:24] <rickspencer3_> just looking for apps that haven't changed since 1.2 is insufficient for case #1
[02:24] <RAOF> But sufficient for case 2, yeah.
[02:24] <rickspencer3_> and just smoke testing isn't sufficient for case #2 (as perhaps you won't exercise the code paths that make the 1.3 calls
[02:25] <rickspencer3_> because we are so short of time, we can't use the "upload and see who complains" QA message for this :/
[02:25] <RAOF> :)
[02:27] <RAOF> A large part of the libclutter-1.0-0 rdepends list is language bindings with no in-archive users.
[02:27] <rickspencer3_> interesting
[02:27] <rickspencer3_> just sitting there waiting to be used
[02:32] <rickspencer3_> training pulling in soon, see you guys tomorrow
[02:33] <RAOF> Have fun!
[02:37] <rickspencer3_> RAOF, do you overlap with didrocks at all?
[02:37] <RAOF> Yes, in the late afternoon.
[02:38] <rickspencer3_> RAOF, great
[02:38] <rickspencer3_> thanks
[02:38] <Sarvatt> ahh sorry, went to dinner there and just got back. clutter really is the only place I'd expect any kind of regressions (not that 1.2 isn't a regression already because it expects features from xserver 1.8). RAOF did you try running these apps with LIBGL_ALWAYS_INDIRECT=1 when you checked? also dont know if you caught my message but nvidia bypasses the server libglx anyway so it wouldnt be any different there
[02:39] <RAOF> Sarvatt: Of course!  I should have expected nvidia to use its own stack :)
[02:40] <RAOF> Sarvatt: I haven't been testing with LIBGL_ALWAYS_INDIRECT=1; should I have?
[02:40] <Sarvatt> you want to run through the server glx since KMS drivers supported glx 1.3+ before anyway
[02:44]  * RAOF should obviously have read the patch a little more carefully
[02:45] <RAOF> So this is going to affect a significantly smaller fraction of our users then.
[02:50] <RAOF> Ok.  gnome-shell is an unhappy camper.
[02:51] <RAOF> …as is netbook-launcher.
[03:07] <Sarvatt> yeah netbook-launcher is all kinds of messed up here
[03:08] <RAOF> It looks like font rendering is broken in the GLX 1.2 pathway.
[03:08] <Sarvatt> it uses -efi
[03:08] <Sarvatt> doesn't it?
[03:09] <RAOF> Sarvatt: Which one?  netbook-launcher, or netbook-launcher-efl?
[03:09] <Sarvatt> it uses low graphics mode when i launch it with LIBGL_ALWAYS_INDIRECT=1 here
[03:10] <RAOF> Nah; loads fine here.
[03:10] <RAOF> But text is rendered as small white squares.
[03:10] <Sarvatt> oh ok theres a seperate low quality mode for 3D?
[03:10] <RAOF> For non-3D?  Yes.
[03:10] <Sarvatt> yeah its the same here, white box fonts
[03:10] <RAOF> netbook-launcher-efl
[03:11] <Sarvatt> i dont have -efl installed
[03:11] <Sarvatt> (netbook-launcher:2653): libnetbook-launcher-DEBUG: CONFIG: Low graphics mode: True
[03:11] <Sarvatt> (netbook-launcher:2653): libnetbook-launcher-DEBUG: CONFIG: Low graphics mode: False
[03:11] <Sarvatt> first with indirect
[03:11] <Sarvatt> it plain doesn't work in direct mode here
[03:12] <Sarvatt> screens all garbled
[03:12] <jjardon> RAOF, You should try: swell foop (It uses clutter+seed(js))
[03:13] <Sarvatt> LIBGL_ALWAYS_INDIRECT=1 swell-foop
[03:13] <Sarvatt> Segmentation fault
[03:13] <Sarvatt> :)
[03:15] <RAOF> So, this looks both better and worse than we thought it was.
[03:18] <RAOF> Sarvatt: What crazy X server are you using?  LIBGL_ALWAYS_INDIRECT=1 swell-foop doesn't segfault here (although it also doesn't render anything, either)
[03:18] <bryceh> RAOF, it's past EOD for me, anything else I can help with on this bug before I go?
[03:20] <RAOF> I don't think so.
[03:21] <bryceh> ok, I'll try checking in again in several hours, so drop me a note if something needs sponsored or whatever
[03:21] <RAOF> Thanks.
[03:26] <RAOF> Sarvatt: So I think this puts the kybosh on just removing the GLX 1.4 backport.
[03:27] <Sarvatt> without downgrading to a stable clutter you mean?
[03:27] <RAOF> Yes.
[03:29] <RAOF> That would mean *at least* a bunch of rebuilds; clutter 1.2 has new API, and netbook-launcher at least hits that when you try to downgrade clutter.
[03:34] <Sarvatt> i'm using lucid + x-updates xserver on intel btw, it does segfault every time
[03:36] <RAOF> I'm using lucid + x-updates xserver on intel, it segfaults none of the time :/
[03:36] <Sarvatt> 945?
[03:36] <Sarvatt> oh
[03:36] <Sarvatt> my driconf settings for mesa were retained on the downgrade, I forgot about that
[03:36] <RAOF> GM45
[03:37] <RAOF> It crashes on quit, if that's any consolation :)
[03:37] <Sarvatt> yep GLXBadContextTag
[03:38] <RAOF> No GLX cleanup for you!
[03:38] <Sarvatt> how are you supposed to gdb that sucker?
[03:38] <RAOF> Run with --sync and break in gdk_x_error?
[03:39] <Sarvatt> nah attached to the pid, i was trying to launch it directly from gdb
[03:40] <RAOF> Ah.  It's all “I'm running your runtime in my runtime, dawg”
[03:40] <Sarvatt> darn forgot mesa symbols in the archive are messed up
[03:41] <RAOF> Anyway.  That's not exactly a critical bug.
[03:42] <RAOF> What was wrong with your master-fixes backport patch, apart from it being a code refactor?
[03:45] <RAOF> Sarvatt: LIBGL_ALWAYS_INDIRECT might have other side-effects besides dropping down to GLX 1.2, right?
[03:46] <Sarvatt> yep
[03:46] <Sarvatt> sorry, afk a few
[03:46] <RAOF> Would booting with i915.modeset=0 exercise the glx 1.2 codepaths?
[03:46] <RAOF> Ok.
[03:47] <RAOF> I'll give that a try anyway.
[03:47] <Sarvatt> no unless you were on ATI
[03:47] <Sarvatt> doh
[04:00] <lifeless> so whats the glx story - is there a bug I can read?
[04:08] <Sarvatt> lifeless: https://bugs.launchpad.net/bugs/565981
[04:10] <lifeless> Sarvatt: thanks
[04:11] <Sarvatt> ati and intel are getting memory leaks on the order of 1.5gb or so a day currently
[04:11] <TheMuso> Ouch.
[04:12] <lifeless> wow
[04:12] <lifeless> I won't reboot for a bit then
[04:14] <Sarvatt> you should reboot, often if you are using KMS :)
[04:14] <Sarvatt> its been this way for almost a month now
[04:14] <lifeless> Sarvatt:  13:14:34 up 15 days,  1:27, 11 users,  load average: 0.09, 0.13, 0.09
[04:15] <Sarvatt> cat /sys/kernel/debug/dri/0/gem_objects ?
[04:15] <lifeless> still got 1/2GB unallocated
[04:15] <lifeless> 1190 objects
[04:15] <lifeless> 69578752 object bytes
[04:15] <lifeless> 5 pinned
[04:15] <lifeless> 13725696 pin bytes
[04:15] <lifeless> 29446144 gtt bytes
[04:15] <lifeless> 234881024 gtt total
[04:15] <RAOF> That's the nice thing about 8GB laptops; you can have X silently consuming 6.9 GiB of memory and not notice.
[04:16] <rickspencer3> I'm confused ... how long has this leak been in the distro and why hasn't it been driving people insane?
[04:16] <Sarvatt> nice, can you give me some more details on your setup? what GPU, do you view a lot of flash sites on it?
[04:16] <lifeless> Sarvatt: sure
[04:16] <Sarvatt> looks like a intel 965+?
[04:16] <lifeless> gimme a sec, phone call
[04:16] <rickspencer3> it seems a widespread bug of this magnitude would drive people crazy and we would be getting a crush of feedback
[04:16] <lifeless> i7 64-bit
[04:17] <RAOF> rickspencer3: We possibly are, but distributed against all sorts of other packages.
[04:17] <RAOF> This memory is not accounted for anywhere that's particularly user-visible.
[04:17] <Sarvatt> its very hard to notice
[04:17] <rickspencer3> so if it's "very hard to notice" we should be careful about acting in haste
[04:18] <Sarvatt> RAOF: lifeless isn't hitting it here for some reason
[04:18] <rickspencer3> I would prefer to see a root cause analysis that identifies the code defect(s) causing this
[04:18] <rickspencer3> and see that fixed in an SRU
[04:18] <rickspencer3> instead of turning knobs all over the place at this point in the cycle hoping something works
[04:18] <lifeless> Sarvatt:  00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)
[04:19] <rickspencer3> Sarvatt, RAOF do you both agree that the roll back to 1.2 is off the table?
[04:19] <RAOF> Yes.
[04:19] <lifeless> Sarvatt: (II) Module intel: vendor="X.Org Foundation"
[04:19] <lifeless>         compiled for 1.7.5, module version = 2.9.1
[04:19] <lifeless> Linux lifeless-64 2.6.32-17-generic #26-Ubuntu SMP Sat Mar 20 02:23:45 UTC 2010 x86_64 GNU/Linux
[04:20] <lifeless> Sarvatt: anything else you want to know ?
[04:20] <Sarvatt> lifeless: oh you haven't upgraded to the broken packages yet is why
[04:20] <Sarvatt> they came on march 31st
[04:20] <lifeless> Sarvatt: thats why I said 'I won't reboot for a while' :P
[04:20] <rickspencer3> RAOF, bryceh, Sarvatt, what do you guys think of release noting the problem, and getting cracking with the debugger?
[04:20] <Sarvatt> (or haven't rebooted into them, sorry) yeah I see what you mean :)
[04:22] <RAOF> It's not too bad as long as you kill X every day or so.  Releasenoting might be appropriate.
[04:22] <rickspencer3> RAOF, there is only so far we can unwind
[04:22] <rickspencer3> I would like to see an SRU ready for this before we ship, if possible
[04:23] <rickspencer3> RAOF, do you feel you have the skills to snorkly into the code and find the leak?
[04:23] <rickspencer3> snorkle, even?
[04:23] <RAOF> I'd quite like to snorkly :)
[04:23] <rickspencer3> RAOF, we'll talk about that at UDS ;)
[04:23] <RAOF> Yes; I'll ask someone if I hit something incomprehensible.
[04:24] <rickspencer3> desktop-maverick-xorg-snorkly
[04:24] <rickspencer3> ok
[04:24] <RAOF> Snork!  Snork!
[04:24] <RAOF> And I'd love to do some code-diving.
[04:24] <rickspencer3> RAOF, can you please respond to bryceh's email with the new information
[04:24] <rickspencer3> ?
[04:24] <rickspencer3> ^the late question mark reveals that I didn't really mean that as a question ;)
[04:24] <Sarvatt> i'll try to dig into it more, yeah. spent all day trying to backport the upstream fix since the one we are carrying that is the cause of this is the root of the problem but haven't had any luck with that
[04:25] <rickspencer3> fruedian irc
[04:25] <RAOF> rickspencer3: :)
[04:25] <rickspencer3> Sarvatt, upstream fix to the leak, you mean?
[04:25] <rickspencer3> I didn't quite grock what you said there
[04:27] <Sarvatt> well, there was the bug where closing clutter apps crashed the server, during the course of the bug report a patch was posted that applies to xserver 1.7 that we picked up and is causing these memory leaks, and they decided to go another route to fix the bug instead of what we used
[04:27] <Sarvatt> but the fix that they used applies to xserver master which is drastically different than what we have
[04:28] <rickspencer3> I see
[04:28] <Sarvatt> and its not something they would bring to the xserver release we are using because upstream does not have these glx 1.4 enablement patches in xserver 1.7 branch in the first place that brought up the problem
[04:28] <rickspencer3> so the fixed the bug in a fundamental way in their "tip" (of xorg-xserver)?
[04:29] <rickspencer3> and due tot he delta between Ubuntu and the tip, that patch couldn't just apply cleanly, so now we're a bit on our own?
[04:29] <Sarvatt> yeah, exactly
[04:30] <Sarvatt> debian is affected as well and they are dropping the patches, we inherited them from them
[04:30] <rickspencer3> yeah
[04:31] <rickspencer3> ok, so root cause analysis next, and get an SRU ready?
[04:31] <rickspencer3> Sarvatt, sound right?
[04:32] <Sarvatt> the backport also touches a significant amount of code and would be risky to SRU, which is why I believed dropping the glx patches would be the better route, but indeed it's bringing up problems with clutter 1.2
[04:32] <Sarvatt> so trying to fix the patch would probably be the best route
[04:32] <Sarvatt> (and SRUing it like you said)
[04:33] <rickspencer3> RAOF, do you agree, root cause analysis then prepare an SRU?
[04:33] <RAOF> Yes.
[04:33] <rickspencer3> ok
[04:33] <rickspencer3> of course, it's a moot decision until bryceh weighs in ;)
[04:34] <RAOF> Again, that's the least terrible of our options :)
[04:34] <Sarvatt> rickspencer3: you are using intel right? can you do a cat /sys/kernel/debug/dri/0/gem_objects and paste the first two lines?
[04:34] <rickspencer3> yup
[04:34] <rickspencer3> 1247 objects
[04:34] <rickspencer3> 278298624 object bytes
[04:35] <rickspencer3> rick@rick-desktop:~$ uptime
[04:35] <rickspencer3>  20:34:56 up 40 min,  3 users,  load average: 0.66, 1.11, 1.21
[04:35] <Sarvatt> how long since you rebooted last?
[04:35] <Sarvatt> ah, was going to say..
[04:35] <rickspencer3> (always one step ahead)
[04:35] <rickspencer3> *cough*
[04:35] <Sarvatt> you didn't seem affected but yeah you are :)
[04:35] <rickspencer3> Sarvatt, well, I ran my UNE netbook all day for the last two days
[04:35] <Sarvatt> do you have swap?
[04:35] <rickspencer3> but I guess I shut it down a bit
[04:36] <rickspencer3> you mean a swap partition, then yes
[04:36] <rickspencer3> Sarvatt, I'm not denying the existence of the bug
[04:36] <Sarvatt> if you turn off your swap you will be frozen after a day because of the leak, I guarantee it :)
[04:36] <rickspencer3> that would suck
[04:36] <rickspencer3> indeed
[04:36] <rickspencer3> I'm not denying the severity of the bug
[04:37] <rickspencer3> I think we are all in agreement that a methodical approach to fixing it is our best bet now
[04:37] <Sarvatt> watch that gem_objects size there, it wraps around to a negative number around 3GB memory used
[04:37] <rickspencer3> I would very much like to see an SRU ready on day zero
[04:40] <Sarvatt> doing everything I can to work on it here, just found out the cause yesterday
[04:41] <rickspencer3> yeah
[04:41] <rickspencer3> hopefully the code defect is not too hard to identify
[04:43] <rickspencer3> Sarvatt, can people who are getting kicked hard by this bug downgrad to glx 1.2 themselves until we get it fixed?
[04:44] <Sarvatt> yes I posted a PPA for that on the bug report
[04:44] <rickspencer3> ok
[04:44] <rickspencer3> that's good
[04:44] <Sarvatt> it's in x-updates, also I am putting xserver 1.8 in xorg-edgers with the fixes
[04:45] <rickspencer3> by "the fixes" you mean the rolled back glx?
[04:45] <Sarvatt> no xserver 1.8 is fine with glx 1.4
[04:45] <rickspencer3> I see
[04:45] <rickspencer3> so another option is for users to basically update to the tip of xserver
[04:45] <Sarvatt> it's a major change that requires rebuilding all of the X related packages though
[04:45] <rickspencer3> so two things to try
[04:46] <RAOF> xserver 1.8 has refactored the way that GLX resources are disposed of; they're now handled as regular X resources and cleaned up there.
[04:46] <Sarvatt> nah, I wouldn't call it the tip, master is the tip and xserver 1.8 is the most recent stable release. xserver master is too cracky even for xorg-edgers crack :)
[04:46] <rickspencer3> hehe
[04:46] <rickspencer3> the crack for the crack
[04:47] <Sarvatt> I have to rebuild all of the video and input drivers weekly for alot of the cycle if i follow master
[04:48] <rickspencer3> Sarvatt, RAOF thanks!
[04:48] <rickspencer3> I
[04:49] <rickspencer3> 've got to go
[04:49] <rickspencer3> ttyt
[04:49] <Sarvatt> no worries, take care
[04:49] <RAOF> Have fun getting home.  Hope it doesn't take too long!
[04:49] <RAOF> Or, in fact, hope you *are* home now :)
[04:50] <rickspencer3> RAOF, I am home!
[04:50]  * Sarvatt hopes these ash clouds go away in time for UDS
[04:50] <rickspencer3> Sarvatt, yes!!
[04:50] <rickspencer3> ok, g'night
[04:51] <Sarvatt> they're talking about it taking 2 weeks to get everyone who is stranded now home, can't afford to get stuck
[04:55] <TheMuso> Sarvatt: For people like RAOF and myself who have to come/go home on long haul flights, this is being watched with some attention, at least by me.
[04:55] <Sarvatt> how long is your flight?
[04:56] <RAOF> In total?  About 28 hours.
[04:56] <RAOF> But that isn't all in the air.
[04:56] <Sarvatt> fun!
[04:56] <Sarvatt> at least your flights do go through iceland though? :)
[04:57] <TheMuso> Sarvatt: I think you meant don't.
[04:57] <RAOF> I presume you mean “don't” there :).  No.  But they do go through Heathrow.
[04:57] <Sarvatt> yeah, sorry
[04:58] <Sarvatt> yeah thats the airport with the 2 week backlog I was reading about
[08:17] <didrocks> good morning
[08:18] <pitti> Good morning
[08:19] <didrocks> Guten Morgen pitti, how are you?
[08:20] <pitti> bonjour didrocks! I'm good, thanks! how about you?
[08:20]  * pitti takes a stab at bug 566046
[08:20] <didrocks> I'm fine too, thanks ;)
[08:20] <didrocks> oh, that one, upstream didn't reply?
[08:23] <RAOF> didrocks: Good morning!
[08:24] <pitti> didrocks: right
[08:24] <pitti> hey RAOF
[08:24] <RAOF> Howdie pitti
[08:26] <didrocks> good morning RAOF
[08:28] <seb128> hello there
[08:29] <pitti> bonjour seb128
[08:29] <pitti> seb128: has there been any previous investigation on bug 566046?
[08:30] <pitti> seb128: I wanted to take a stab at this today
[08:31] <seb128> hey pitti, not that I know out of mdeslaur who said he looked a bit to the code without finding the issue
[08:32] <didrocks> salut seb128
[08:32] <seb128> lut didrocks
[08:49] <mvo> dear launchpad, please do not oops when I try to add a bug comment, love Michael
[08:55] <RAOF> Ok.  That's enough diving throug X for one day.  See y'all tomorrow :)
[08:58] <didrocks> good evening RAOF
[09:09] <pitti> seb128: do you know whether there is a CLI tool to dump the keyring?
[09:12] <seb128> pitti, not that I know about no
[09:44] <huats> morning
[09:45] <seb128> lut huats
[09:46] <huats> hello seb128
[09:48] <seb128> huats, ca va ?
[09:49] <huats> seb128, yes !
[09:50] <huats> et toi seb128 ?
[09:50] <seb128> huats, ca va merci
[09:50] <huats> :)
[09:57] <james_w> huats \o/
[09:57] <huats> hello james_w !
[09:57] <huats> how are you ?
[09:58] <huats> it's been a long time :)
[09:59] <james_w> good thanks, how are you?
[09:59] <huats> great thanks !
[10:00] <huats> a really happy  young father :)
[10:00] <james_w> glad to hear it :-)
[10:28] <chrisccoulson> is anyone here on i386 and using the flash plugin installed from the archive?
[10:29] <pitti> chrisccoulson: on my netbook
[10:29] <chrisccoulson> pitti - do you know if it is using nspluginwrapper?
[10:29] <pitti> it's a clean install from yesterday
[10:29] <chrisccoulson> or is that just used for the amd64 version?
[10:29]  * pitti boots
[10:30] <pitti> I thought it's just needed on amd64?
[10:30] <kklimonda> chrisccoulson: are you still working on bug 555870?
[10:30] <chrisccoulson> pitti - yeah, i think so. i just wanted to make sure we weren't using it on all archs ;)
[10:30] <chrisccoulson> kklimonda, no, because i've got no idea what is going on now ;)
[10:31] <chrisccoulson> kklimonda, if you can recreate it, please provide a xtrace log from the actual gnome-screensaver process
[10:31] <kklimonda> damn.. ;)
[10:31] <pitti> chrisccoulson: nspluginwrapper isn't installed here
[10:31] <seb128> chrisccoulson, hey, how are you?
[10:31] <chrisccoulson> we're unsure if the issue with test-fade is a red herring or not
[10:31] <chrisccoulson> thanks pitti
[10:31] <chrisccoulson> hey seb128, i'm good thanks. how are you?
[10:31] <seb128> chrisccoulson, no nspluginwrapper on i386 here either, I'm running the security ppa version which works fine btw
[10:31] <seb128> chrisccoulson, I'm good thank you
[10:32] <chrisccoulson> seb128 - excellent. i suppose i need to actually test the flash player with nspluginwrapper on amd64 ;)
[10:32] <chrisccoulson> i'm using the 64-bit plugin here
[10:39] <kklimonda> chrisccoulson: I can get you all xtraces you want if you think it will help :)
[10:40] <kklimonda> chrisccoulson: would you rather get it attached to the bug report or pasted somewhere http://pastebin.com/U231nmDq ? :)
[10:41] <chrisccoulson> kklimonda, attached to the bug would be good
[10:41] <kklimonda> ok
[10:44] <kklimonda> chrisccoulson: btw, sometimes I get a slightly less faded desktop instead of the pitch black one :)
[11:24] <seb128> tseliot, hey, what is the package which has the nvidia display configuration tool?
[11:24] <tseliot> seb128: nvidia-settings, why?
[11:25] <seb128> tseliot, thanks, looking where to reassign bug #528756
[11:25] <seb128> tseliot, where the user is using the nvidia tool to change the configuration
[11:26] <tseliot> seb128: right, that's a bug that I fixed in Lucid
[11:29] <seb128> tseliot, ok, feel free to close it then ;-)
[11:29] <tseliot> sure
[11:32] <c_korn> can someone please confirm an odd issue with gnome-panel ? first do this steps: http://pastebin.com/SfLG5Abs then do a killall gnome-panel and after it has restarted I see that one starter has been cloned and replaced another starter. e.g. I have two canonical starters but the starter for launchpad is gone.
[11:32] <c_korn> s/this/these/
[11:33] <c_korn> I use lucid of course. http://pastebin.com/nhbdg14W
[11:36] <pitti> I sometimes get that on login, but restarting the panel usually fixes it
[11:36] <pitti> it's an indicator-applet bug apparently :/
[11:38] <c_korn> so I should file a bug against indicator-applet instead of gnome-panel ?
[11:38] <c_korn> it is annoying that I always lose my urls this way :/
[11:40] <seb128> c_korn, you get the issue if you restart gnome-panel properly too?
[11:41] <c_korn> the better question acutally is: how can I find out that it really is an indicator-applet ?
[11:41] <c_korn> seb128: I get the issue also when I only restart.
[11:42] <seb128> well is the issue a display one and happening randomly?
[11:42] <seb128> or does it break your launchers?
[11:42] <c_korn> no, it is happening reliably always
[11:42] <seb128> pitti, oh? how did we figure it was an indicator issue?
[11:42] <pitti> well, I only ever see it happen for the indicator applets
[11:42] <seb128> I don't think it's the same issue pitti was mentioning which is a display one and randomly happening
[11:43] <c_korn> it is not a display issue. one starter just gets replaced by another, completely.
[11:43] <seb128> pitti, it's mostly happening for the notification area from bugs we received
[11:43] <pitti> sometimes the session one is missing completely, or only 1/4 drawn, sometimes the nm-applet is missing/looking like the keyboard indicator
[11:43] <seb128> c_korn, right, not the bug pitti was mentioning then
[11:43] <seb128> pitti, nm or keyboard don't use indicators
[11:43] <pitti> ok, misunderstood that then, sorry
[11:43] <pitti> ok; itz gtk bug then?
[11:44] <c_korn> how can I restart gnome-panel properly actually ?
[11:44] <pitti> alt+f2 killall gnome-panel
[11:44] <pitti> it'll restart itself
[11:44] <pitti> (well, gnome-session will, but same result)
[11:44] <c_korn> that is what I do currently.
[11:48] <seb128> c_korn, gnome-panel --replace
[11:51] <c_korn> ok, now I could not reproduce it. so maybe gnome-panel does not get closed properly. let me restart...
[11:57] <c_korn> hm, now I cannot reproduce it anymore. I need to find out what triggered it.
[12:19] <pitti> seb128: hm, so I stopped the user password from getting into the keyring, and now also have code to remove it during upgrades
[12:20] <pitti> seb128: however, this potentially breaks this "user.keystore" keyring, but I have NFC what this actually is or how to use it
[12:20] <pitti> it's empty everywhere, and seahorse doesn't have an option to fill it either
[12:20] <pitti> seb128: I dumped my thoughts on the upstream bug and also mailed Stef
[12:28] <chrisccoulson> pitti - if you have some spare time today, could you please look at bug 567819?
[12:29] <pitti> chrisccoulson: yay! will do
[12:29] <pitti> right after lunch
[12:29] <chrisccoulson> pitti - thanks :)
[12:42] <seb128> pitti, ok thanks, I'm not sure what it's used for either let's see if Stef replies, I already dropped him an email about the bug yesterday
[12:42] <seb128> pitti, you can perhaps upload your change to the ubuntu-desktop ppa to get testing?
[12:42] <pitti> seb128: can do; it's in bzr now
[12:44] <pitti> seb128: done
[12:44] <seb128> pitti, thanks
[13:35] <chrisccoulson> pitti - thanks for doing the removals :)
[13:35] <pitti> no problem
[13:35] <pitti> the cleaner the better :)
[13:44] <chrisccoulson> seb128 - did you ever figure out the gnome-appearance-properties DND crash?
[13:46] <seb128> chrisccoulson, depends on what you call figure out, it's a lack of proper locking issue and having gtk used out of the main process there
[13:46] <seb128> I didn't work on a fix though since I'm not sure how to fix that
[13:46] <chrisccoulson> i'll have a look at that this afternoon then
[13:47] <seb128> excellent, thanks
[13:47] <seb128> that one is collecting zillion of duplicates for cycles ;-)
[13:47] <seb128> and the stacktraces are random in pango calls so the retracers autoduping doesn't work
[13:48] <seb128> pitti, btw speaking of retracer, was there any discussion in the past about updating the bug title after retracing?
[13:48] <seb128> pitti, the crash in somewhere() is often wrong or misleading because it comes from the non debug stacktrace
[13:48] <seb128> tedg, hey
[13:49] <tedg> Morning seb128
[14:26] <seb128> tedg, pitti: should we drop fast-user-switch-applet in lucid?
[14:27] <seb128> bug #563922
[14:27] <seb128> I don't think it's of any use now right?
[14:27] <seb128> ie gdm has its own f-u-s-a and we have indicator-session
[14:27] <tedg> seb128: Yeah, but we get it for free from the gdm source package, right?
[14:27] <tedg> seb128: Oh, we still have the old FUSA and the GDM one?
[14:28] <seb128> tedg, yes, that's the old source in universe
[14:28] <tedg> seb128: Oh, my.  Yeah, does that work anywhere?  It won't work with the new GDM.
[14:28] <seb128> tedg, well I doubt it since it depends on gdm but gdm conflicts on it
[14:28] <seb128> since gdm has the new fusa version now
[14:28] <tedg> seb128: I'd make the new GDM FUSA "replaces" on it.
[14:29] <seb128> tedg, I was just double checking there was not an out of GNOME scenario I was missing there
[14:29] <tedg> seb128: Ah, not that I know of.
[14:30] <seb128> ok, what I though but better to check
[14:30] <seb128> tedg, thanks
[14:32] <rickspencer3> pitti, hi
[14:32] <rickspencer3> about bug #565981
[14:32] <seb128> rickspencer3, hey
[14:32] <rickspencer3> hi seb128, good morning
[14:35] <rickspencer3> didrocks, hi
[14:35] <didrocks> hey rickspencer3
[14:35] <rickspencer3> didrocks, I didn't understand what happened to bug #565981 ...
[14:35] <rickspencer3> were  you saying that there were no issues from rolling back to glx 1.2?
[14:36] <rickspencer3> (it was hard to piece together from the emails what is happening, and the bug wasn't updated)
[14:37] <didrocks> rickspencer3: I wasn't answering towards the bug, but more on rolling back on 1.2. I told that I looked through the code and played for a couple of hours with netbook-launcher using glx 1.2 and didn't notice any particular issue
[14:37] <rickspencer3> so you didn't see the "no text drawn" issue that RAOF saw?
[14:38] <rickspencer3> that's very odd
[14:38] <didrocks> no, on two of my hardwares
[14:38] <didrocks> njpatel told that he would test too
[14:39] <didrocks> I added the ppa mentioned in the email, dist-upgrade, and restart X
[14:40] <rickspencer3> weird
[14:41] <didrocks> I guess further testing on other device/graphic card is needed
[14:43] <pitti> hey rickspencer3
[14:43] <rickspencer3> hi pitti
[14:43] <pitti> seb128: sounds fine to remove
[14:43] <rickspencer3> pitti, I wanted to sync with you about this bug because I made decisions while you were asleep, and thought you better check on them ;)
[14:44] <seb128> pitti, ok, good
[14:44] <pitti> rickspencer3: oh, so that's why the computer gets slower and slower over time?
[14:44] <rickspencer3> pitti, most likely, yes
[14:45] <seb128> pitti, indeed
[14:45] <rickspencer3> so, on the table is to roll back to glx 1.2 before release
[14:45] <rickspencer3> but RAOF found this caused some apps, such netbook-launcher, to not paint text
[14:45] <rickspencer3> !!
[14:45] <rickspencer3> but didrocks did not see this effect
[14:45] <rickspencer3> so I told them:
[14:45] <didrocks> right, that's weird ::
[14:46] <rickspencer3> 1. RAOF should dive into the code and do a root cause analysis
[14:46] <rickspencer3> 2. get an SRU ready that fixes the memory leak in the patch of glx
[14:46] <rickspencer3> pitti, but as tech lead, I see this as your call, really
[14:47] <rickspencer3> that's why I wanted to sync with you
[14:47] <pitti> rickspencer3: SRU for fixing the leak would be very much appreciated, of course
[14:47] <rickspencer3> pitti, right
[14:47] <pitti> I think this stuff is too brittle to downgrade to an older glx
[14:48] <rickspencer3> so take that option off the table, even if testing shows it works?
[14:48] <pitti> and since the bug says that with latest trunk the problem doesn't occur any more, it seems at least principally feasible
[14:48] <rickspencer3> pitti, well, the latest trunk is way different than Lucid xserver
[14:48] <rickspencer3> so they fixed the initial problem much differently
[14:49] <pitti> rickspencer3: hm, Sarvatt just mentioned to drop the two 1.4 enablement patches, not to downgrade glx entirely?
[14:49] <rickspencer3> pitti, that's basically rolling back to 1.2
[14:49] <rickspencer3> (as I understand it)
[14:50] <rickspencer3> pitti, but even if we do roll back the patches, would we do that in an SRU, or try to make it into final?
[14:50] <chrisccoulson> seb128 - so, i've found one easy-to-fix locking issue in gnome-appearance-properties which could cause that crash
[14:51] <chrisccoulson> hey rickspencer3
[14:51] <rickspencer3> hi chrisccoulson
[14:51] <pitti> rickspencer3: ah, so the one in x-updates was confirmed to work
[14:52] <pitti> rickspencer3: hm, right now I can't do that decision objectively, I think; I know too little about the impact of rolling back the 1.4 glx patches, I'm afraid
[14:54]  * pitti researches history
[14:54] <rickspencer3> pitti, ok
[14:54] <rickspencer3> it'
[14:54] <rickspencer3> s a pretty serious bug, I hate to ship with it
[14:55] <rickspencer3> but it doesn't cause data loss, so I am inclined to
[14:55] <rickspencer3> not act in haste, and wait until we have deep understanding of the cause and the fix
[14:58] <ogra> rickspencer3, the gem objects one ?
[14:58] <ogra> i'm hit pretty hard by it
[14:59] <rickspencer3> ogra, yes
[14:59] <ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes"
[14:59] <ogra> -169566208 object bytes
[14:59] <rickspencer3> ogra, I'm very sorry
[14:59] <ogra> seems it just overflowed
[14:59] <rickspencer3> ah, integer math wrapping, sweet
[14:59] <ogra> rickspencer3, heh, no need to be sorry
[14:59] <ogra> i'm happy there is an identified root cause to my desktop getting mad :)
[15:00] <pitti> rickspencer3: I can't see in the changelog where the glx 1.4 enablement patches landed
[15:01] <pitti> probably in 2:<IP_ADDRESS>1-1 from December
[15:01] <rickspencer3> Sarvatt ^ ?
[15:02] <pitti> rickspencer3: did you already discuss which apps/parts use 1.4?
[15:02] <rickspencer3> pitti, yes
[15:02] <rickspencer3> in some depth
[15:03] <rickspencer3> RAOF ran an rdepends and then tested all the apps there
[15:03] <rickspencer3> he found an issue with UNE, where it wouldn't display text
[15:03] <rickspencer3> but no one else is seeing that, and njpatel thinks he just needed to reboot, that it was a font caching issue
[15:05]  * pitti just dislikes disabling features post-release
[15:07] <rickspencer3> pitti, are you referring to glx?
[15:07] <pitti> rickspencer3: so, perhaps we can do a call for testing and collect result on a wiki page
[15:07] <rickspencer3> ok
[15:07] <pitti> and then, based on the feedback, check on Friday how much and what kind of feedback we got
[15:07] <rickspencer3> pitti, I don't there is a feature regression if we remove the patches
[15:08] <pitti> rickspencer3: right, it could at most be a performance regression
[15:08] <pitti> but certainly not relative to karmic, anyway
[15:08] <rickspencer3> hardly a performance enhancement atm :)
[15:08] <rickspencer3> hehe
[15:08] <pitti> heh, yes
[15:10]  * pitti feels urged to fix that in final, since the patch was just introduced a few days ago
[15:10] <pitti> and it's such a nasty issue
[15:10] <rickspencer3> pitti, ok, do it!
[15:10] <rickspencer3> I suspect rolling back all the patches will work
[15:11] <rickspencer3> and it's basically a roll back to a "lost known good"
[15:11] <rickspencer3> it's not moving forward to crack
[15:11] <rickspencer3> ogra, can you help test a fix for the gem bug?
[15:12] <ogra> rickspencer3, it might take quite long to reproduce, it only kicks in if the counter filled up here
[15:12] <ogra> which is takeing about 24h
[15:12] <ogra> *taking
[15:12] <rickspencer3> hmmm
[15:12] <ogra> rickspencer3, but indeed i'm happy to
[15:12] <rickspencer3> can you play saurbraughten for an hour or so? maybe that will do it? ;)
[15:12] <ogra> i need to restart X anyway, all my chromium tabs OOMed
[15:13] <seb128> pitti, rolling back the change which made xorg crash when closing a clutter dialog?
[15:13] <rickspencer3> seb128, yes
[15:13] <pitti> robbiew: well, that, and the two changes which needed that 114 patch in the first place
[15:13] <pitti> sorry, seb128 ^
[15:13] <seb128> I'm not sure I would prefer crashy xorg to sluggish one
[15:13] <pitti> seb128: rolling back 114 alone would be crashy, AFAIUI
[15:14] <ogra> rickspencer3,  though i think if we see the gem_objects not climb as mad that would already be kind of a proof
[15:14] <pitti> but not 114 together with the two glx 1.4 patches
[15:14] <seb128> pitti, oh ok
[15:14] <seb128> pitti, when have the 2 glx ones be added?
[15:14] <pitti> seb128: not entirely clear to me, but I think somewhere around December/January; pretty early
[15:14] <rickspencer3> seb128, basically, as I understand it, it's rolling back to karmic glx
[15:15] <seb128> so it means it's not really a known to be good combinaison
[15:15] <seb128> karmic glx but non karmic stack around it
[15:15] <seb128> ie something we never tested
[15:17] <rickspencer3> seb128, correct
[15:19] <seb128> ogra, well you don't need to wait for the crash to watch the counter
[15:20] <seb128> rickspencer3, tricky one indeed :-(
[15:20] <rickspencer3> I think we move back to 1.2, it will be easier to move forward with patches in SRUs
[15:20] <rickspencer3> but that's a hunch
[15:20] <ogra> seb128, thats what i meant above :)
[15:21] <seb128> I can help testing candidate packages there but I've no really opinion on which way is the best one, I don't know enough about the changes and the issue
[15:21] <pitti> what I don't really understand is that 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff basically do nothing else than changing "1.2" to "1.4", but do not add any actual functionality
[15:21] <seb128> rickspencer3, we need to test 1.2 on lucid though to know how it behaves
[15:22] <rickspencer3> seb128, right
[15:22] <seb128> since that's not something we ever tested
[15:22] <rickspencer3> that's what we have started
[15:22] <pitti> i. e. rolling back doesn't remove any API, just goes back to announcing "glx version: 1.2"
[15:22] <rickspencer3> and what pitti suggested
[15:22] <seb128> ok good
[15:22] <seb128> +1 from me then
[15:22] <rickspencer3> test it until Friday, and then decide
[15:22] <rickspencer3> ^pitti's plan
[15:23] <seb128> pitti, is there anything which decide what to do at runtime based on the version announced?
[15:23] <pitti> seb128: I don't know, I just asked the same question a few minutes ago
[15:23] <seb128> I guess it's rather an #ubuntu-x discussion
[15:24] <pitti> I'll send a call for testing and set up a wiki page; that can't hurt either way, and let's see how much feedback we get until Friday
[15:25] <seb128> ok
[15:26] <didrocks> I'm running it on my two machines since this morning FYI
[15:26] <seb128> the issue is that I don't really know on what to test glx
[15:26] <seb128> games?
[15:26] <pitti> I get it by merely using compiz, firefox, and terminals
[15:26] <didrocks> I tried mostly  netbook-launcher/compiz/gnome-shell
[15:27] <seb128> well not checking if gems are leaked
[15:27] <seb128> but test if downgrading to 1.2s till behave correctly
[15:27] <pitti> right
[15:27] <seb128> ie no rendering issue, not 15 times slower
[15:27] <seb128> no crash
[15:27] <rickspencer3> seb128, so RAOF pasted in a list of redpends directly on glx last night
[15:27] <rickspencer3> and then, anything that uses clutter
[15:27] <rickspencer3> for clutter, it works fine with 1.2, apparantly
[15:28] <rickspencer3> but we should confirm that apps that use clutter continue to do so
[15:28] <seb128> right
[15:28] <rickspencer3> for direct glx clients, we need to confirm that none of them depend on features or bugs in a version later than 1.2
[15:29] <seb128> do you still have the list somewhere?
[15:29] <seb128> I close IRC at night so I don't have scrollback with it
[15:30] <rickspencer3> seb128, I can get it
[15:30] <rickspencer3> hold on
[15:30] <asac> http://irclogs.ubuntu.com/2010/04/20/%23ubuntu-desktop.txt
[15:31] <asac> or the date adjusted
[15:32] <kenvandine> does this effect certain hardware or anyone?
[15:32] <rickspencer3_> http://pastebin.ca/1870751
[15:32] <rickspencer3> seb128, ^
[15:32] <pitti> kenvandine: intel and ati, AFAICS
[15:32] <kenvandine> ok, so any intel
[15:33] <seb128> rickspencer3, thanks
[15:33] <rickspencer3> oops
[15:33] <rickspencer3> seb seems gone
[15:34] <seb128> rickspencer3: right, I was going to say, it's empty
[15:34] <seb128> not a lot to test ;-)
[15:34] <rickspencer3_> apt-cache rdepends libglitz-glx1
[15:34] <seb128> f-spot
[15:34] <rickspencer3> hmm
[15:34] <seb128> that's a short list ;-)
[15:34] <rickspencer3> that's not qutie the list
[15:35] <rickspencer3> oh well
[15:35] <rickspencer3> seb128, in any case, RAOF went over the apps in some detail last night
[15:36] <seb128> I'm always concerned about things we don't have direcly shipped
[15:36] <seb128> like ie games or google earth or whatever users can be running
[15:36] <rickspencer3> right
[15:36] <rickspencer3> but what can we do?
[15:36] <rickspencer3> anyway, those will be in Universe and can be updated more easily
[15:36] <seb128> I guess that best way forward is to test without those changes on what we can
[15:36] <rickspencer3> yeah
[15:36] <rickspencer3> RAOF already tested the apps that we can know about
[15:37] <seb128> and deal with issue with third party applications in a SRU later if any get raised
[15:37] <rickspencer3> and confirmed there were no issues
[15:37] <seb128> let's make the default installation work fine
[15:37] <rickspencer3> yes
[15:37] <seb128> and deal with corner cases as they come if there is any issue
[15:37]  * chrisccoulson wonders if the bug you're talking about is the reason for my laptop being virtually unusable atm
[15:37] <seb128> chrisccoulson, could well be, you can try the ppa to make sure ;-)
[15:38] <pitti> chrisccoulson: if restarting X helps, then most likely
[15:38] <chrisccoulson> ok, i will try that in a bit
[15:38] <pitti> chrisccoulson: cat /sys/kernel/debug/dri/0/gem_objects
[15:38] <chrisccoulson> pitti - "1174454272 object bytes"?
[15:39] <pitti> chrisccoulson: right, overflow
[15:39] <chrisccoulson> excellent
[15:39] <pitti> oops, the - wasn't part of the output
[15:39] <pitti> but still a lot
[15:39] <chrisccoulson> yeah, it's quite a big number
[15:39] <rickspencer3> well, you need to pair that with uptime
[15:40] <rickspencer3> at least it's easy to repro the bug
[15:40] <ogra> it will overflow at some point
[15:40] <rickspencer3> ;)
[15:40] <rickspencer3> ogra, right
[15:40] <ogra> i'm seeing that here every second day
[15:40]  * rickspencer3 recalls from 2nd day of c programming class
[15:40] <ogra> which is definately a bug in itself, the variable is to small
[15:41] <ogra> beyond the uncontrolled growth
[15:41] <rickspencer3> ogra, I can imagine when the functionality was written
[15:41] <ogra> heh, indeed
[15:41] <rickspencer3> "it will be hundreds of years before anyone has gigs of memory, and who needs more than 100 megs, anyway?"
[15:41] <chrisccoulson> my issues go away for a bit after a reboot, but then my laptop just starts swapping uncontrollably
[15:41] <rickspencer3> "just use a small in"
[15:41] <pitti> https://wiki.ubuntu.com/X/Testing/GEMLeak   <- first cut
[15:41] <rickspencer3> ;)
[15:41] <ogra> 640k are enough
[15:41] <didrocks> some told that with less ;)
[15:42] <didrocks> ogra: yes ;)
[15:42] <rickspencer3> "there is no way anyone will be using this software in year 2000"
[15:42] <ogra> chrisccoulson, heh, lucky you, you got swap ...
[15:42]  * ogra doesnt want to wear out his SSD
[15:42] <rickspencer3> pitti, you just gave me an excuse to play saurbraten this morning?
[15:42] <rickspencer3> sweeet~
[15:43] <pitti> rickspencer3: go, go, go!
[15:43] <rickspencer3> I"m going
[15:43] <chrisccoulson> ogra - and i get lots of hung task warnings in dmesg too (but i'm not sure if that's related to the excessive swapping)
[15:43]  * pitti apt-get install extremetuxracer
[15:43] <ogra> chrisccoulson, yeah, thats your kernel babbling about OOM
[15:44] <ogra> chrisccoulson, it gets funny if you use chromium ... tabs die randomly at some point and in the end all your screen is full with sad faces
[15:44]  * kenvandine reboots with new xorg
[15:44] <chrisccoulson> lol
[15:46]  * kenvandine thinks lucid boots too fast
[15:46] <kenvandine> doesn't give me time to refill my coffee :)
[15:47] <kenvandine> pitti, did your songs ever download?
[15:48] <pitti> kenvandine: it said "there was a problem" this morning and offered me a retry button. but didn't help, timing out again
[15:48] <kenvandine> ok
[15:52] <pitti> u-devel@ mail is out
[15:53] <rickspencer3> pitti, think someone can gin up a quick repro script?
[15:53] <rickspencer3> like does running glx-gears cause the leak?
[15:53] <pitti> rickspencer3: there's one in the bug, but I think that's not the main point of testing
[15:53] <pitti> we know that it fixes the leak
[15:53] <rickspencer3> ok
[15:54] <rickspencer3> good point
[15:54] <pitti> we need to find out about functional/performance regressions
[15:54] <rickspencer3> well, UNE seems to be working fine on my netbook
[15:54] <pitti> rickspencer3: but the eog loop was a good start, I think
[15:54] <rickspencer3> I'll use it for a couple of hours later though
[15:55] <pitti> didrocks, kenvandine: I added a "desktop" field, please update
[15:55] <kenvandine> ok
[15:55] <didrocks> oki
[15:56]  * kenvandine will test on his netbook too
[15:56] <didrocks> the issue is that I have the same chipset on both netbook and my laptop is a nvidia :/
[15:56] <didrocks> not good for wide testing
[15:57] <kenvandine> i am sure my netbook is a different chip
[15:57] <kenvandine> not sure which yet though :)
[15:57] <didrocks> kenvandine: exotic hardware? ;)
[15:57] <kenvandine> no
[15:57] <kenvandine> intel classmate
[15:57] <kenvandine> but different than my laptop
[15:58] <rodrigo_> hmm, the indicator applet seems to capture IM messages from empathy, but it doesn't open the IM window?
[15:59] <kenvandine> rodrigo_, it should if you click on it
[15:59] <seb128> rodrigo_, right, that's empathy behaviour, it doesn't do auto-opening
[15:59] <seb128> rodrigo_, upstream version makes the notification icon flash but you have to click on it too
[16:00] <rodrigo_> kenvandine, hmm, but it also shows an item under Chat for users that come online
[16:00] <rodrigo_> so I have to check all the time if it's a new message
[16:00] <seb128> rodrigo_, that one just stay a few seconds and go away
[16:00] <seb128> wait 5 seconds
[16:00] <kenvandine> and it won't so a time next to them
[16:00] <seb128> if it stays it's a message ;-)
[16:00] <rodrigo_> seb128, and if it's a real IM message, it stays there until I open it?
[16:00] <rodrigo_> ah, ok
[16:00] <seb128> yes
[16:01] <seb128> you can also turn the indicator off in the empathy preferences if you don't like it
[16:01] <rodrigo_> I like it, just got a bit confused
[16:01] <rodrigo_> I think I missed a message or 2 yesterday
[16:02] <seb128> I still think it could be better and be flashing a few times on message income
[16:03] <rodrigo_> yes
[16:03] <rodrigo_> or at least show a different icon than an envelope
[16:03] <rodrigo_> it shows green also when I get new mail, which is every 10 mins :D
[16:04] <seb128> right
[16:09] <Nafai> Morning guys, grabbing breakfast and then I'll be right back
[16:10] <didrocks> good morning Nafai
[16:11] <rickspencer3> pitti, fwiw, saurbraten seems to work fine on my 965
[16:12] <rickspencer3> I'll test desktop and UNE more this afternoon
[16:12] <didrocks> rickspencer3: I guess you have to ensure in completing all levels :)
[16:12] <rickspencer3> uh
[16:12] <rickspencer3> yeah, I'm not that good
[16:12] <rickspencer3> ;)
[16:12] <didrocks> heh
[16:14] <rickspencer3> rick@rick-desktop:~$ glxgears
[16:14] <rickspencer3> 2995 frames in 5.0 seconds
[16:14] <rickspencer3> does that seem like decent throughput?
[16:14] <pitti> yes, I think so; I get a couple of 100 :)
[16:15] <kenvandine> better than me :)
[16:15] <kenvandine> i get 2645
[16:15] <rickspencer3> pitti, I'll use my UNE netbook for some programming later today
[16:15] <pitti> oh, windowed I get 2470
[16:15] <rickspencer3> do some real usage
[16:15] <pitti> thanks
[16:15] <seb128> 2225 frames in 5.0 seconds
[16:15] <seb128> there
[16:15] <pitti> I have the update running on netbook and laptop now
[16:17] <pitti> argh, silly fishbones, they cost me 10 fish!
[16:17] <pitti> erm
[16:17] <pitti> I mean, tuxracer still works fine :)
[16:18] <kenvandine> hehe
[16:22] <rickspencer3> pitti, so:
[16:22] <rickspencer3> rick@rick-desktop:~$ glxgears -fullscreen
[16:22] <rickspencer3> 271 frames in 5.0 seconds
[16:22] <rickspencer3> seems reasonable based on what you said?
[16:23] <pitti> sounds fine
[16:23] <pitti> rickspencer3: did you get more with the lucid X.org?
[16:23] <rickspencer3> I dunno
[16:23] <rickspencer3> I don't much care, tbh
[16:24] <rickspencer3> ;)
[16:25] <Nafai> Hey didrocks
[16:27] <kenvandine> sauerbraten and tuxracer are fine
[16:29] <rickspencer3> kenvandine, maybe we need to test sauerbraten in multi-player mode?
[16:30] <kenvandine> hehe
[16:30]  * kenvandine had never played sauerbraten before
[16:30] <kenvandine> looks kid of fun :)
[16:35] <kenvandine> s/kid/like/
[16:36] <pitti> kenvandine: and it apparently causes immediate grammatical distortions :)
[16:36] <kenvandine> hehe
[16:36] <kenvandine> indeed
[16:56] <rickspencer3> seb128, do you have that BBC doesn't work in Totem bug # handy?
[16:57] <seb128> rickspencer3, hum, let me look to it, I closed it a few days ago because it was working but it's down ago now :-(
[16:57] <rickspencer3> well, it wasn't quite working apparantly
[16:57] <seb128> rickspencer3, bug #528728
[16:57] <rickspencer3> I just got an email from BBC, and it seems that totem isn't displaying the full list
[16:57] <seb128> rickspencer3, well it was displaying something
[16:57] <rickspencer3> right
[16:58] <seb128> rickspencer3, not I get a "fail to connect" again
[16:58] <rickspencer3> just the first entry
[16:58] <rickspencer3> maybe I should just open another bug
[16:58] <seb128> rickspencer3, no please reopen this one
[16:58] <seb128> rickspencer3, they blame it on the client side?
[16:58] <rickspencer3> seb128, yes
[16:58] <rickspencer3> they can view the feed in a web page
[16:59] <seb128> I get a can't connect to server there again
[16:59] <seb128> I very doubt it's a client side issue
[17:00] <rickspencer3> I think there are two issues
[17:00] <rickspencer3> seb128, let me just forward you the email for now
[17:00] <seb128> rickspencer3, ok thanks
[17:01] <seb128> "We have some downstream (from this service) connectivity problems which are hampering our ability to diagnose what looks like a probable server misconfiguration. I can connect intermittently to the service (stock Karmic) from my home box but it's very flaky."
[17:01] <seb128> rickspencer3, ^ I think that's still an issue
[17:02] <seb128> we might have a client side issue added to that too
[17:02] <seb128> though our code didn't change since it was written
[17:02] <rickspencer3> so I think they addressed the server side, and there is probably some xml parsing
[17:02] <rickspencer3> problems
[17:03] <rickspencer3> it could be bad xml, or a bug in totem
[17:03] <rickspencer3> I think totem gets the list of programs, but then doesn't display them all
[17:03] <rickspencer3> it sounds like a separate issue to me
[17:03] <seb128> right
[17:05] <seb128> rickspencer3, I don't get this parsing bug on lucid, I've a list of several screens of content now
[17:05] <rickspencer3> hmm
[17:05] <rickspencer3> kewl
[17:05] <seb128> rickspencer3, I will test a bit a different time until tomorrow and reply to the mail later
[17:05] <rickspencer3> seb128, well, prioritize appropriately
[17:05] <rickspencer3> thanks seb128
[17:05] <seb128> np
[17:06] <seb128> thank you for contacting them, it's good they fixed the server ;-)
[17:10] <zyga> has anyone heard of http://www.synaptics.com/solutions/technology/gestures/touchpad-linux
[17:12] <zyga> to quote: "Synaptics Gesture Suite Linux (SGS-L) provides users with a powerful and intuitive way to be more productive and interactive with their Linux based notebook systems. SGS-L was developed from analyzing the most common workflows, from entertainment activities such as viewing photos and listening to music, to productivity activities such as accessing emails and presentations. The result is an enhanced usability model that makes it intuitive
[17:12] <zyga> for consumers to easily understand and discover features, resulting in a better user experience." ... "Supported Linux operating systems include Fedora, Millos Linpus, Red Flag, SLED 11 (SuSE), Ubuntu, and Xandros. SGS-L includes a wide range of pointing enhancements and gestures including two-finger scrolling, PinchZoom, TwistRotate, PivotRotate™, three-finger flick, three-finger press, Momentum™ and ChiralScroll™"
[18:08] <matumba> hey, i added the ppa for the gem leak fix but after a reboot glxinfo still says "GLX version 1.4" - any ideas?
[18:16] <lool> pitti: Ah!  I was a victim of that slowness of xorg which you posted about and was searching for it all over the place
[18:18] <lool> I think it interfered with other issues I was seeing https://bugs.launchpad.net/ubuntu/+source/linux/+bug/549428
[18:21] <Nafai> lunching
[18:48] <pitti> Taekwondo time, good night everyone!
[18:53] <didrocks> enjoy pitti
[19:09] <james_w> http://jameswestby.net/scratch/offline-lp.ogv <- fun evening hacking outcode
[19:18] <Nafai> james_w: Cool, local caching of Launchpad info?
[19:19] <james_w> yeah
[19:22] <bryceh> james_w, bjf has done work along those lines, caching lp info into a couchdb
[19:23] <james_w> that's exactly what this is
[19:24] <didrocks> james_w: sweet!
[19:24] <bjf> james_w: https://chinstrap.canonical.com/~bradf/hwdb/
[19:25] <bjf> james_w, look at the Reports, these were generated from processing couchdb data obtained from LP
[19:26] <bjf> james_w, you can click on the individual bar graphs to "drill down"
[19:26] <bjf> james_w, once you get to a table of bugs, owner, and titles, you can click on one and it will take you to LP
[19:27] <james_w> so you are using it as it is quicker to cache it all upfront and then query the faster store?
[19:28] <bjf> james_w, partly yes, also that I can perform other queries faster
[19:28] <bjf> correlating the vendors and tags can be tough with just LP
[19:30] <bjf> james_w, the other thing I _really_ like about couchdb is how easy it is to replicate the database so it's easy to share with others
[19:31] <james_w> yeah
[19:44] <bryceh> bjf, james_w, this caching of lp is something I'm *quite* interested in myself, as many of my scripts take forever to run
[19:45] <bryceh> I've been too slammed with X to look into this myself, but if you two sync'd efforts up, it's something I'd be quite interested in looking at using as well
[19:53] <mvo> didrocks: still here?
[19:53] <didrocks> mvo: yes
[19:54] <mvo> didrocks: silly question, what stuff is in ubuntu-netbook that is not in ubuntu-desktop (or vice versa). i ask because of https://wiki.ubuntu.com/LucidLynx/ReleaseManifest
[19:55] <mvo> didrocks: and it says there that netbook gets 18m of support
[19:55] <mvo> didrocks: is that just the small bits like netbook-launcher?
[19:55] <mvo> instead of the panel?
[19:55] <didrocks> mvo: right: netbook-launcher, clutk, liblauncher and clutter I would say
[19:56] <mvo> didrocks: thanks, that is enough
[19:56] <didrocks> (also n-l-efl by extension)
[19:56] <mvo> didrocks: as info
[19:56] <mvo> n-l-efl?
[19:56] <mvo> efl?
[19:56] <didrocks> netbook-launcher-efl (the "2D one")
[19:56] <mvo> aha
[19:56] <mvo> thanks
[19:56] <didrocks> you're welcome :)
[20:11] <Sarvatt> Regarding the GLX version downgrade possibility I should probably clear up something. KMS users will be unaffected since clients will still be 1.4, non KMS intel users will be unaffected since they have DRI2 without KMS (and still having 1.4), proprietary driver users will be unaffected since they don't user the server's libglx. the main concerns would be non KMS ATI and other fringe drivers like savage that had problems already which is w
[20:11] <Sarvatt> hy I believed it was the sanest option. To test you want to abuse compiz as much as possible, browsing some flash heavy sites or flicker pages with huge images for instance and watch /sys/kernel/debug/dri/0/gem_objects while doing it to see if the number goes down to sane levels properly or steadily increases with no shrinking. if the gem object size listed there is over 1GB you for sure have problems
[20:17] <Keybuk> Sarvatt: I was doing that earlier
[20:18] <Keybuk> -1512136704 object bytes
[20:18] <Keybuk> confused me ;-)
[20:18] <Sarvatt> yeah you wrapped around to negatives, multi gigs of memory lost :(
[20:18] <Keybuk> this is on i915 with KMS
[20:18] <Sarvatt> thats with the stock lucid packages right?
[20:19] <Keybuk> yes
[20:20] <rickspencer3> pitti, glx 1.2 did not fix the bug for you?
[20:20] <rickspencer3> oh, never mind
[20:20] <rickspencer3> I see it says (testing)
[20:22] <Keybuk> ah sorry, I misinterpreted - somehow I'd got the impression you didn't think Intel was affected
[20:22] <Keybuk> I shall shut up and test the downgrade
[20:22] <bjf> bryceh, was thinking of it more last night and am starting to implement it now
[20:23] <bjf> bryceh, I figure if I can handle the 10K of 'linux' package bugs, it will work for any others :-)
[20:23] <rickspencer3> I wish glx really did install memory on your system
[20:26] <Keybuk> you know what's really funny?
[20:27] <Keybuk> my laptop had got so slow, I actually ordered more memory for it this week <g>
[20:31] <kenvandine> Keybuk, lol
[20:32] <kenvandine> i just thought evolution was dragging me down again :)
[20:32] <Keybuk> I was blaming evolution, chromium and docky
[20:37] <Keybuk> well, my object bytes isn't negative after rebooting ;-)
[20:49] <Sarvatt> bonus! clutter apps now work with swrast disabling glx 1.4 reporting in the server
[20:51] <Sarvatt> with stock lucid xserver using software rasterizer - failed to create drawable Failed to initialise clutter: Unable to select the newly created GLX context and the apps silently fail to load (widely reported bug against all clutter based apps right now)
[20:51] <Sarvatt> and with the x-updates version they now work fine
[21:00] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/561734
[21:03] <Sarvatt> easy to verify as well anywhere, running LIBGL_ALWAYS_SOFTWARE=1 quadrapassel with the lucid xserver fails and with x-updates it does not
[22:13] <leftyfb> Ok, so you guys are removing one of the most valuable features of a desktop ... the notification area. So tell me this, where would something like the Dropbox item go? or ksplice? or gSTM?
[23:25] <james_w> bryceh, bjf: this is what I am working towards: http://jameswestby.net/scratch/offline-lp.ogv
[23:25] <james_w> err, make that http://jameswestby.net/scratch/offline-lp2.ogv
[23:39] <TheMuso> Good morning.
[23:43] <Nafai> Hey TheMuso
[23:48] <rickspencer3> RAOF, hi
[23:48] <RAOF> rickspencer3: Good morning.
[23:48] <rickspencer3> RAOF, so, the did you see the glx 1.2 feedback, plans today?
[23:49] <RAOF> My email is on it's way to me now.
[23:50] <RAOF> I saw didrocks feedback from yesterday before I shut down, but haven't seen anything newer.
[23:52] <RAOF> I've got an idea of how the 114 patch is causing the leak, too.
[23:54] <rickspencer3> sweet
[23:56] <Keybuk> hmm
[23:56] <Keybuk> so I'm running the backported packages
[23:56] <Keybuk> but I think there's still a leak
[23:56] <rickspencer3> oh?
[23:56] <RAOF> Keybuk: Your running the X server from x-testing with the GLX 1.4 backport dropped?
[23:56] <Keybuk> RAOF: as far as I know
[23:56] <RAOF> s/your/you're/-
[23:56] <Keybuk> the number of GEM objects has increased from ~270 to over 400 so far
[23:57] <Keybuk> closing apps isn't making it go down
[23:57] <rickspencer3> urk


[08:10] <smartboyhw> OvenWerks, is there no way that you can do the test?
[08:10] <smartboyhw> i mean, the i386 one
[08:10] <smartboyhw> zequence_, got any time too?
[08:39] <zequence-work> smartboyhw: I can only do tests with the live DVD today
[08:41] <zequence-work> Maybe in the evening I can do an install
[08:45] <zequence_> Finally getting my tooth fixed today :P
[08:46] <smartboyhw> zequence_: Heh heh hhe
[10:24]  * smartboyhw tests the amd64 ISO
[10:27] <smartboyhw> ETA zsync time for i386: 1 hour 30 minutes (Impressive)
[10:29] <smartboyhw> Now, let's see if my ubiquity fix worked
[10:30] <smartboyhw> OK, it worked
[11:03] <smartboyhw> amd64 image passed...
[11:04] <smartboyhw> amd64 marked ready
[11:04] <smartboyhw> I have a hunch that the release will be delayed into Friday
[11:09] <smartboyhw> zequence-work, I don't know if this is improper practice, but can you ask apw to update the linux-lowlatency kernel in Saucy before KernelFreeze? The kernel hasn't been updated after Beta 1:(
[11:10] <smartboyhw> It's still in an -rc state
[11:11] <smartboyhw> (Which I consider unstable)
[11:12] <smartboyhw> Maybe you can update yourself
[11:12] <smartboyhw> Dunn
[11:12] <smartboyhw> s/Dunn/Dunno/
[11:12] <kubotu> smartboyhw meant: "Dunno"
[12:41] <smartboyhw> All Ubuntu Studio images has passed Quality Assurance and are marked ready.
[12:53] <zequence_> smartboyhw: I'm maintaining that kernel now. Theres no hurry
[12:53] <zequence_> smartboyhw: I will make sure it'sup to date before kernel freeze
[12:53] <smartboyhw> zequence_, many thanks:)
[13:03] <smartboyhw> http://www.techrepublic.com/blog/linux-and-open-source/linux-advocate-contemplates-the-purchase-of-a-mac/ !
[13:03] <smartboyhw> " I might jump from Ubuntu to Ubuntu Studio (or whichever platform gets audio right first), but I will always and forever be a champion for Linux."
[13:57] <ttoine> hello
[14:00] <smartboyhw> Hello ttoine :)