[00:25] <BUGabundo> who was doing an whois on me ?
[00:48] <hggdh> who?
[00:51] <BUGabundo> no idea
[00:52] <BUGabundo> some one did in some channel
[00:52] <BUGabundo> while I kept logging and crashing
[00:52] <BUGabundo> darn pa
[01:00] <bcurtiswx> you can see when someone does a whois on you?
[01:06] <BUGabundo> bcurtiswx: no... no logs, cause it crashed
[01:06] <BUGabundo> :(
[01:07] <bcurtiswx> oh, lol
[01:07] <bcurtiswx> ok
[01:09] <Pici> whoises are server side, they do not query your client.
[01:10] <BUGabundo> Pici: now server... some one asked "whois BUGabundo"
[01:10] <BUGabundo> and I'm trying to figure where that happened
[01:10] <BUGabundo> eheh
[01:11] <hggdh> what me to do it again?
[01:12] <hggdh> done
[01:14] <bcurtiswx> me too :-D
[01:16] <BUGabundo> do what?
[01:17] <bcurtiswx> whois'd you
[01:17] <BUGabundo> LOLOL
[01:17] <BUGabundo> you guys didn't understand my Q
[01:17] <BUGabundo> nvm
[01:17] <BUGabundo> I guess ill never know now
[01:17] <bcurtiswx> well then ask a better question :P
[01:33] <BUGabundo> need https://bugs.edge.launchpad.net/ubuntu/+source/kdepim/+bug/194416 set as won't fix. thanks
[01:33] <ubot4> Launchpad bug 194416 in kdepim "[hardy] kmail shortcut for search bar is missing from Settings menu" [Wishlist,New]
[01:35] <Ampelbein> BUGabundo: done
[01:35] <BUGabundo> thanks Ampelbein
[01:35]  * BUGabundo goes back to bug mail
[01:40]  * BUGabundo $ sleep in 3,2,1, errrr. No Device Found
[07:20] <dholbach> good morning
[10:15] <BUGabundo> guud day
[13:28] <lim123> oh my god, ubuntu 9.04 upgrade broke my working desktop.  Where are QA teams?
[13:28] <lim123> svk seems really broken
[13:31] <lim123> afair when upgrading 8.04 -> 8.10 svk was also epically broken
[13:32]  * lim123 whacks everyone with a clue bat
[13:48]  * Hobbsee smashes lim123 into the middle ofnext milenium, in return.
[13:51] <Hobbsee> damn those people who don't check that svk works when they dist upgrade.  Do they just only test *some* packages or something?  Why can't they check everything!
[13:54] <ogra> whats svk ?
[13:56] <seb128> apt-cache show svk
[13:56] <seb128> distributed svn
[14:01] <lim123> Hobbsee: there is a lot of bugs about this SVK problem. And even solutions / patches
[14:01] <lim123> ogra: svk is svn + local cache.  Overall very nice (but have some quirks sometimes)
[14:02] <ogra> heh, svn
[14:05]  * lim123 ponders ogra's comment
[14:05] <ogra> wasnt that comment enough ?
[14:29] <stiVal> hello people! can anyone confirm this bug and my rating, that it is security related? or if I'm wrong and the reloading of a service via logrotate should in fact start a stopped service? https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/393792
[14:29] <ubot4> Launchpad bug 393792 in lighttpd "lighttpd reload executes restart (bad on logrotate!)" [Undecided,New]
[15:04] <lim123> ogra: not really, SVN is good tool, and popular, you disagree? git is for complex uses :)
[15:05] <ogra> bzr is for compley uses and user friendly :)
[15:05] <ogra> *complex
[15:05] <lim123> stiVal: I would say it indeed is a security bug, and a big one
[15:05] <lim123> lol bazar
[15:06] <lim123> although name bazar would in fact reflect on quality of some of the software <_<
[15:27] <hggdh> meaning software would be better?
[15:38] <stiVal> lim123: We'll see how they respond - i guess it would be interesting to see which services have the same behaviour (where reload does the same as restart) ... I don't believe lighty is the only service
[15:39] <stiVal> it's in fact a packaging issue ... are there any rules for init scripts of services?
[16:50] <lim123> Hobbsee: in fact, why not?
[16:50] <lim123> professional developers use unit testing
[16:50] <limcore[tmp]> we could in fact test all packages
[16:51] <limcore[tmp]> upstream (or distro managers) could write some standarized unit tests for each program / package,  and it would all be executed when needed
[16:53] <limcore[tmp]> hggdh: I was refering to the discussion that perhaps baazar "business" model is not working out for real software, and some "catedral" is needed; And I would be happy to see more Catedral (professionall qa etc) in ubuntu
[16:55] <limcore[tmp]> Hobbsee: some things can not be easly unit tested automatically, on thoes manual/hand testers would focus
[16:55] <hggdh> limcore[tmp], most of the work done on Ubuntu is voluntary. AFAICR, Canonical banks some of them, but we still depend heavily on volunteers. Do I understand you are volunteering?
[16:56] <limcore[tmp]> I do \o/
[16:56]  * limcore[tmp] puts a +9 ring of qa
[17:00] <limcore[tmp]> ok, so...
[17:01] <limcore[tmp]> how to help then
[17:02] <limcore[tmp]> example, ubuntu fails to fully support my LCD (modelines problems)  and  xvidtune seems broken.   I reported, and what?  How to get in pair with developer experienced in X to debug this bug and then fix it
[17:03] <limcore[tmp]> we could test all
[17:04] <limcore[tmp]> erm wrong paste.         https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/393501
[17:04] <ubot4> Launchpad bug 393501 in x11-xserver-utils "xvidtune: can not set any frequency - XF86VidModeModeUnsuitable ; also: more debug patch" [Undecided,New]
[17:05] <hggdh> limcore[tmp], start with https://wiki.ubuntu.com/Testing
[17:12] <showard> limcore and hggdh: Should he open a new bug: "xvidtune should have better debugging information" and attach his patch to that report as well (mark it as a patch)? many developers are volunteers too, and they would be more able to try a small patch like that than work through debugging a more difficult problem. Since limcore has a bug with a specific hardware configuration it may take a while to find a tester or developer to help confirm an
[17:13] <limcore[tmp]> also, perhaps the bug is not that xvidtune is broken (for me), but that xvidtune is outdated and should not be used nowdays?  but whom to ask that
[17:15] <hggdh> showard, it is a good option
[18:05] <nhasian> hello peoples
[18:05] <limcore[tmp]> hi nhasian
[18:06] <nhasian> hey did the hugday start already?
[18:10] <pedro_> nhasian: yeah, it's the whole day
[18:10] <nhasian> dang you guys already triaged all the bugs.  i guess there werent that many to begin with
[18:11] <nhasian> i'm glad my bug got confirmed and sent upstream
[18:11] <pedro_> nhasian: there's still a few to be triaged on empathy ;-)
[18:11] <pedro_> i'm having a look into those now
[19:14] <wilClay> hello - i am new to bug triage and am looking at bug 393955 about flash vid not playing with extra visual effects on.
[19:14] <ubot4> Launchpad bug 393955 in ubuntu "Extra Visual Effects cause Flash video to fail" [Undecided,New] https://launchpad.net/bugs/393955
[19:16] <wilClay> I notice his report suggests yelp as the package but yelp is a help utility - I assume this is erroneous and probably something to do with the use of apport maybe?
[19:17] <wilClay> Or is that part of the bug report user generated?  Thanks for any insights given to a noob...
[19:18] <pedro_> wilClay: no, it seems he just used the Help->Report a problem menu item on yelp
[19:19] <wilClay> gotcha - thanks.  I'll ask for more specifics on reproducing the prob.  i can play vids with extra on in firefox 3 FWIW
[19:19] <pedro_> wilClay: we get a few reports like that, people seems to think that the yelp program is for asking for help rather than searching/reading for it on the docs
[19:19] <pedro_> wilClay: that'd be good, thanks for helping ;-)
[19:20] <wilClay> pedro_:  No prob - glad to be here!
[20:02] <mahfouz> I had a problem today with 2.6.30-10-generic in jaunty
[20:02] <mahfouz> talked to the people in #kernel but they only started a distro flame war
[20:03] <mahfouz> starting up with 2.6.30-10-generic, I get the splash screen all the way to the end but then an unresponsive black screen
[20:03] <mahfouz> it worked yesterday, but today it didn't anymore, even though there were no updates afaik
[20:04] <Pici> mahfouz: 2.6.30-10 isnt in Jaunty though.
[20:05] <mahfouz> that's the thing, I think it was temporarily in the repos
[20:05] <mahfouz> but now removed
[20:05] <mahfouz> I downloaded it thru apt though
[20:05] <mahfouz> now I'm using the mainline ppa and that works atm
[20:07] <pedro_> mahfouz: you might want to try asking on #ubuntu-kernel which is where the ubuntu kernel folks hang around
[20:07] <mahfouz> oh
[20:07] <mahfouz> ok
[21:09] <fdr> hello... is there please anybody willing to teach me how to report a bug upstream? Thanks! This is the one: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/195359
[21:09] <ubot4> Launchpad bug 195359 in epiphany-browser "Italian translation is incomplete" [Undecided,Incomplete]
[21:26] <stiVal> hello again ...! Could someone please look at https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/393792 for a second - i really don't think this should be a "low" priority. this is pretty serious for production environments imo ;)
[21:26] <ubot4> Launchpad bug 393792 in lighttpd "lighttpd reload executes restart (bad on logrotate!)" [Low,Confirmed]
[22:27] <BUGabundo> guys! enjoy this last week! new job starts on Monday! I should be less in here hehe
[22:46] <nhasian> wow i went to view the bugs for telepathy-butterfly in launchpad and they are all set to confirmed now.


[00:00] <RAOF> My r700 likes compiz just fine.
[00:00] <RAOF> And, with mesa 7.9, is pretty happy with Unity.
[00:00] <RAOF> It doesn't run Civ 4 under wine, though.
[00:00] <ajmitch> mobility radeon HD 4850, I'm wondering how well it'll go with games instead of using fglrx :)
[00:00] <ajmitch> namely WoW under wine, of course
[00:01] <RAOF> :P
[00:01] <ajmitch> civ iv looks a bit funny even with fglrx
[00:01] <RAOF> I'd give it a go; it's possible that the driver doesn't implement something that wine wants, though.
[00:01] <ajmitch> quite probably :)
[00:02] <ajmitch> I geuss we should be hoping for fglrx to still work by release
[00:02] <RAOF> It works now?
[00:03] <ajmitch> I mean it works in lucid, having it break for people upgrading could be bad
[00:03] <RAOF> Ah.  Yeah.
[00:05] <RAOF> apw: Is that wedge in mutex_lock_slowpath?  There seems to be a deadlock somewhere you can hit, and hit it much more frequently with two monitors.
[00:27] <ScottK> RAOF: Thanks.
[01:09] <JanC> I'll try my Radeon HD 4350 one of the next days...  ☺
[08:34] <apw> RAOF yes its trying to get the dev struct_mutex, from the minimal analysis I did I cannot find anyone holding it and doing anything
[08:35] <apw> that one is going to bite us hard after release, do you have a bug open on it?
[10:35] <RAOF> apw: I think this is it: https://bugs.freedesktop.org/show_bug.cgi?id=28805
[10:35] <ubot4> Freedesktop bug 28805 in Driver/intel "[Arrandale] Intermittent freezes - missed interrupt?" [Normal,Resolved: fixed]
[10:36] <RAOF> apw: Launchpad bug #568138
[10:36] <ubot4> Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 11) (dups: 1) (heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/568138
[10:38] <apw> RAOF, interesting, then its not arrandale specific
[10:38] <RAOF> apw: Yeah, I think the bug is mis-titled.
[10:38] <apw> mine is certainly something older ... thanks for the ptr
[10:39] <RAOF> Hm.  I need to re-check my upstream bugmail filtering; I should have noticed that getting marked as resolved.
[10:40] <RAOF> I could reproduce it relatively frequently (~1/day) when I plugged in my second monitor.
[10:40] <RAOF> I should try the 2.6.36-rc3 kernel to see if it resolves it.
[10:44] <seb128> hey there
[10:44] <seb128> is there any known bug about external monitor on dock stations not activating since recently?
[10:44] <seb128> on intel card
[10:44] <seb128> on a dell latitude serie
[10:44] <seb128> what would be buggy? xorg? intel driver?
[10:45] <seb128> it started a few days ago and it doesn't seem to be the linux version in use
[10:52] <RAOF> It's likely to be either the intel driver or the kernel; most likely the kernel.
[10:55] <RAOF> We haven't had an -intel upload for a while, so I'd guess at kernel.
[11:12] <apw> RAOF, i can reproduce it pretty much once a day as well with just single screen
[11:13] <apw> RAOF, and thats with maverick kernel on lucid userspace
[11:30] <RAOF> apw: Ah, well.  That might be a different bug to mine, then.
[11:30] <RAOF> apw: Or it could be exactly the same bug, and it just gets triggered much more infrequently on gm45
[11:34] <apw> RAOF, hard to say isn't it, sounds very similar
[11:35] <RAOF> Yeah.
[11:35] <RAOF> The kernel PPA has a build of 2.6.36-rc3, right?
[11:36] <apw> RAOF, should do yes
[11:37] <apw> RAOF, it does indeed
[11:37] <RAOF> Man, my arms are so much better after pushups this week than last week.
[11:38] <RAOF> But still enervated.
[12:09] <RAOF> tseliot: I've investigated the xserver-xorg-video-ati diff.  That's the removal of a copy of the XRandR modes code that was added to the -ati in order to build properly against xserver 1.2, but it actually has never been built (as it's conditional on XRandR 1.2 support, which xserver 1.2 didn't have).
[12:14] <RAOF> tseliot: It's in upstream git; I haven't found where we've picked up that commit, but it's entirely benign.
[12:34] <tseliot> RAOF: can you add it to the changelog, please?
[12:35] <RAOF> It wasn't introduced in that change; I can hunt down when it _was_ introduced if you like.
[12:37] <RAOF> git is being remarkably unhelpful at working this out.
[12:38] <tseliot> RAOF: it would suffice to mention the change in the changelog
[12:38] <tseliot> a one line explanation would be fine
[12:39] <tseliot> for example what you wrote here on irc
[12:43] <ricotz> tseliot, hello, do you still expierencing the docky freeze on application starts?
[12:44] <tseliot> ricotz: yes, shall I update my system?
[12:44] <ricotz> tseliot, are you using 2.0.6-2 now?
[12:44] <RAOF> tseliot: Pushed to pkg-xorg git.
[12:45] <tseliot> ricotz: no, I'm using 2.0.5-1
[12:46] <tseliot> RAOF: ok, thanks, I'll have a look at it and upload your changes
[12:46] <RAOF> Thanks muchly.
[12:47] <ricotz> tseliot, the newer version should be available, i didnt ran into this bug myself, and i thought it might be some glib problem
[12:52] <tseliot> ricotz: ok, let me check
[12:56] <tseliot> ricotz: yes, I can still reproduce the problem with 2.0.6-2. Let me update the whole system and see if anything changes
[12:58] <ricotz> tseliot, this must be related to some dependency and it is only affecting maverick
[13:00] <tseliot> ricotz: yes and I recall an update of glib just before the breakage
[13:01] <ricotz> tseliot, you are now on glib2.0 2.25.15?
[13:02] <tseliot> ricotz: 2.25.14-1ubuntu2 but I'm about to upgrade to 2.25.15-0ubuntu2
[13:02] <ricotz> ok
[13:03] <tseliot> I'll let you know how it goes
[13:03] <ricotz> tseliot, thanks
[13:36] <tseliot> ricotz: same problem with the new glib
[13:36] <tseliot> let me know if you need further information
[13:39] <tseliot> the last few comments are interesting though: https://bugs.launchpad.net/ubuntu/+source/docky/+bug/628372
[13:39] <ubot4> Launchpad bug 628372 in docky (Ubuntu) (and 1 other project) "Docky freezes when launching application (affects: 10) (dups: 1) (heat: 52)" [Undecided,Confirmed]
[13:41] <tseliot> ricotz: if you tell me how to try the latest code, I'll tests it here
[13:41] <tseliot> s/tests/test/
[13:43] <ricotz> tseliot, you can try the trunk version with this ppa https://launchpad.net/~docky-core/+archive/ppa
[13:44] <tseliot> ricotz: shall I update gio-sharp too?
[13:45] <ricotz> tseliot, if should be the same as maverick ships now
[13:45] <tseliot> ah, right
[13:52] <tseliot> ricotz: same problem again. Maybe something in the handler of the ButtonReleaseEvent triggers a bug somewhere e.g. in gtk# ?
[13:57] <ricotz> tseliot, ok, this really needs some more investigation, thanks for your time, too bad i can't reproduce this
[13:58] <tseliot> ricotz: np
[14:06] <Sarvatt> hmm I can't reproduce that docky problem on nouveau nvidia or intel on maverick
[14:06] <Sarvatt> maybe I need to enable all those plugins and helpers
[14:06] <ricotz> i am suspecting nvidia-blob, but didnt want to say it
[14:09] <tseliot> ricotz: wait a second, I purged the packages from the PPA, ran docky in debug mode and I can't reproduce the problem any more now. Maybe some cached content (or configuration file in /etc ) was removed
[14:09] <Sarvatt> well I didn't test the blob very well, the machine i tested it on can't use the blob because the board is failing and graphics are corrupted all over the place but i didn't see any freeze through all of the corruption
[14:09] <tseliot> oh, and I'm using radeon
[14:12] <Sarvatt> oh just read the bug
[14:12] <Sarvatt> i'm using 2.1.0~bzr1623-0ubuntu1~10.10~dockycore1
[14:12] <Sarvatt> Revision 1622 fixed it on kernel version <IP_ADDRESS>. Thanks! -- Well then 1624 will break it again because I reverted 1622.
[14:12] <ricotz> tseliot, could you add a comment to the bug for this purge?
[14:13] <ricotz> Sarvatt, yeah someone got motivated doing things
[14:15] <tseliot> ricotz: sure
[14:16] <Sarvatt> ricotz: wait, so its fixed again in 1625? lol
[14:16] <Sarvatt> fixed in 1622, reverted in 1624, revert reverted in 1625?
[14:17] <tseliot> it's fixed here with:
[14:17] <tseliot> [Info  15:06:51.480] Docky version: 2.0.6 Release
[14:17] <tseliot> [Info  15:06:51.486] Kernel version: <IP_ADDRESS>
[14:17] <tseliot> [Info  15:06:51.486] CLR version: 2.0.50727.1433
[14:17] <tseliot> maybe try purging docky?
[14:17] <Sarvatt> oh guess it's not related to that then
[14:19] <ricotz> tseliot, i cant imaging what a purge could cause to our config, it is all saved in the user dirs, it is pretty weird
[14:19]  * tseliot nods
[14:25] <ScottK> Sarvatt: Did you get my ping on intel stuff from over the weekend?
[14:26] <Sarvatt> ScottK: I just got up and haven't read the scrollback yet, checking now
[14:26] <ScottK> Sarvatt: OK.  Thanks.
[14:38] <Sarvatt> ScottK: #dri-devel is where all of the mesa developers are and I've never seen a kde dev in there. Is it just intel thats broken or everyone using mesa like it sounds like? It looks like phoronix picked up on the story giving it a lot more exposure and some mesa devs have replied in here - http://www.phoronix.com/forums/showthread.php?t=25907
[14:40] <ScottK> Sarvatt: It's hard for me to tell what's accurate and what's complete crack from that thread.  I know the stuff about trolltech  controlling KDE development is complete crap.
[14:41] <Sarvatt> just the posts from marek and airlied and bridgman basically
[14:41] <ScottK> Sarvatt: The feeling among the KDE devs is that the Intel people can't be communicated with.  I suspect that's not accurate and would like to find a way to fix the social disconnect.
[14:42] <ScottK> Reading it again (knowing who to pay attention to)
[14:42] <Sarvatt> ScottK: Intel specifically? They are around every day pretty much all of the time in #intel-gfx and #dri-devel
[14:42] <ScottK> I'm not saying they are right, just that's the perception.
[14:43] <ScottK> As is usual when people are pissed off, I'm sure it's not so bad as that, just it takes some work to bridge the gap.
[14:45] <ScottK> Sarvatt: Do any of the right people come to UDS?
[14:45] <Dr_Jakob> ScottK: I only know of Jesse Barnes (from intel) going to UDS.
[14:45] <Sarvatt> jbarnes has in the past but not recently, perhaps you can speak to RAOF about bringing it up at the XDS coming up soon?
[14:48] <Dr_Jakob> So what is the actuall problem?
 Sarvatt: What would be the way to communicate the following to Intel developers in a way that would be constructive and useful (re the ongoing kwin mess):
 <ScottK> mgraesslin: While I'm waiting for kdebase-workspace to compile, it would help a lot if I could get a list of the capabilities Intel is misreporting (or some idea how to figure it out).  Canonical does have people that can talk to Intel if I can tell them what needs to be communicated.
 <mgraesslin> the list is rather short: we need framebuffer objects and shaders and in inderict rendering mode the unsupported (impossible) extensions should be removed. That's nothing I can provide as that's something only the driver developers can know
 Additionally:
 <mgraesslin> ScottK: if they need a reference: https://bugs.kde.org/show_bug.cgi?id=173556#c41
 <mgraesslin> that's how NVIDIA does it
[14:49] <ubot4> KDE bug 173556 in compositing "Shader support not detected on various systems" [Normal,Resolved: fixed]
[14:51] <Sarvatt> the impression that I get is that GL compositing in KDE is designed around the nvidia binary drivers and is messed up with mesa because of extensions being reported that only partially work
[14:52] <Sarvatt> which is largely based on hardware limitations..
[14:52] <Dr_Jakob> Well and a totaly crap GLSL compiler.
[14:52] <Dr_Jakob> Which intel fixed in 7.9
[14:52]  * Sarvatt nods
[14:55] <Dr_Jakob> Heh, that bug you posted is just some guy who can't get direct rendering work :)
[14:56] <Dr_Jakob> But yeah, bug reports from people having problems would be nice.
[14:56]  * ScottK has several systems with problems.
[14:56] <ScottK> FWIW, mgraesslin was trying yesterday (and failing, AFAIK) to get ATI working.
[14:57] <ScottK> The one Intel system he has access to seems to actually work.
[14:57] <Dr_Jakob> ATI prop or ATI mesa?
[14:57] <ScottK> IIRC mesa.
[14:57] <Dr_Jakob> driver?
[14:57] <ScottK> Dunni
[14:57] <Dr_Jakob> ok
[14:57] <ScottK> Dunno
[14:58] <Sarvatt> ScottK: maybe you can suggest to him to just make it so blur/lanczos are never used with mesa by default so a huge blacklist doesn't need to be maintained?
[14:58] <ScottK> Having read the thread again it seems like a communication issue primarily.
[14:58] <Dr_Jakob> 7.9 will hopefully be a really nice release.
[14:59] <Sarvatt> yeah I'm hoping there will be a RC release soon so we can try to get it in maverick, putting a git snapshot is sketchy. it's supposed to branch from master this week at least
[15:00] <Dr_Jakob> http://www.x.org/wiki/Events/XDS2010/Program
[15:00] <Dr_Jakob> Somebody is going to talk about what is there.
[15:01] <Dr_Jakob> "Which functions can app developers rely on ?"
[15:01] <Sarvatt> oh nice - Which functions can app developers rely on ?
[15:01] <Sarvatt> yeah, thanks for the heads up!
[15:01] <Sarvatt> RAOF and cnd are going
[15:01] <Dr_Jakob> Ok, I'll say hi
[15:22] <ScottK> Sarvatt: No blur plus the new mesa isn't too bad.
[15:23] <Sarvatt> I dont get that because your 945GME doesn't support GLSL so it shouldn't be trying to use blur anyway
[15:35] <Sarvatt> oh ok looks like theres a non GLSL version in there too, I thought I read there wasn't in that blog..
[15:41] <cnd> RAOF, have you had a chance to take a look at my xorg-server and synaptics changes for maverick?
[15:50] <Sarvatt> ScottK: can you try new mesa, install driconf, and disable the "Enable limited ARB_fragment_shader support on 915/945" option and see if blur works?
[15:51] <ScottK> Sure
[15:56] <Sarvatt> actually you can just put this as ~/.drirc and restart if driconf pulls in too much gtk stuff - http://sarvatt.com/downloads/drirc.txt
[15:57] <ScottK> First I have to purge the patched kwin.
[15:57] <ScottK> It won't let me activate blur.
[16:00] <Sarvatt> it should switch to the GL_ARB_fragment_program blur implementation with that and that might actually work, 7.9 enabled that ARB_fragment_shader option by default which was disabled on 7.8.x and it looks like that's the extension it checks to use the GLSL shader variant instead
[16:01] <ScottK> I see.
[16:04] <Sarvatt> I don't know enough about this to know whats wrong with the actual shader it compiles if that doesn't work
[16:14] <ScottK> Sarvatt: Odd result.  Started with effects enabled (inclulding blur).
[16:15] <Sarvatt> any problems?
[16:15] <ScottK> Not so far (on 30 seconds of using)
[16:16] <Sarvatt> so 7.9 is better but that option was making it bad :)
[16:16] <Sarvatt> i'm not sure if you can just use fragment_shader=0 in the env when launching kwin to fix that, hmm
[16:20] <ScottK> Keeping in mind I know little about this part of the system (and hope to keep it that way), can we suggest a different way to detect to use GLSL that would be more reliable?
[16:24] <Sarvatt> ScottK: I'm sorry, got something else that needs my attention ASAP and I need to step away from it for a bit, there are a few ways we can work around it though
[16:24] <ScottK> Sarvatt: OK.  Let me know when you can chat.
[17:41] <Sarvatt> ScottK: sorry, got caught up in some intel sandybridge stuff. I think the first step is to rebase that mesa to the mesa 7.9 branch as soon as it opens any day now and get the output from launching kwin with MESA_GLSL=dump,nopt env variable set to get a good upstreamable bug report. it may already be fixed in git, they've been fixing it crazy amounts since that 0825 snapshot. we can disable that option by default in mesa easily or kwin can export
[17:41] <Sarvatt>  fragment_shader=false into the env on 915/945 possibly to work around it?
[17:44] <ScottK> Sarvatt: I've got roughly 60 seconds until I have to leave for the next 10 hours or so.  If the extension isn't working reliably why don't we just globally disable it?
[17:44] <ScottK> Let me know when there's an updated package for me to test.
[17:47] <Sarvatt> that's a question best asked in #dri-devel, I assume they enable it because it does work for some situations and the benefits outweigh the negatives but I'm not sure :) things like cairo-gl are reliant on that option being enabled or they don't work on this old class of hardware
[17:47] <Sarvatt> will do!
[17:48] <Sarvatt> i'll patch it to disable by default anyhow
[17:49] <Sarvatt> really, convince that guy to discuss this in #dri-devel with the mesa devs somehow if you can instead of just saying its broken, it might be easily fixed but they dont use KDE or something
[18:46] <Sarvatt> jcristau: how would you say the results with the legacy 2.12 have been in squeeze? looks quite negative from a quick glance
[18:46] <jcristau> Sarvatt: yeah ums is all broken
[18:47] <jcristau> my 945 crashes X with a lockup message on startup, and 855 just get hard hangs
[23:44] <ScottK> Sarvatt: Kwin upstream doesn't have the right hardware to make it fall over, so it's a little hard for him to report bugs.
[23:45] <ScottK> I'd be willing to help, but don't exactly know what to provide.


[11:38] <BluesKaj> Hiyas all
[20:55] <jukeboh> uh-oh... I opened a plasma vault, moved in a couple of files and now I am unable to close it
[20:56] <jukeboh> I've no Dolphin windows in there. The Plasma Vault is taking up 100% of CPU, even as it should have nothing to do at all
[20:56] <jukeboh> Plasma Vaults have broken on me previously, so don't feel like restarting the machine and hoping that it did not break
[21:06] <jukeboh> I rebooted anyways
[21:07] <jukeboh> Now trying to open the Vault sorta succeeds, but CPU utilization goes to 100% and I cannot access the vault
[21:21] <jukeboh> After 2nd reboot I can open the vault and see inside with shell. But Dolphin window hangs. I try to kill the Dolphin and see if it starts up ok and the Vault is ok
[21:25] <jukeboh> Nope. Dolphin will just not die 'sudo kill -9 pid' does nothing
[21:28] <jukeboh> In 'ps aux  | grep dolphin' I see the program that will not die with 'sudo kill -9' and there are also 3 pcs slave sockets.
[21:31] <jukeboh> To get the Vault to work is not a urgent thing, nor very critical as the information is also stored elsewhere, but would be nice to get working. Got irccloud, will hang around if someone can help
[21:44] <jukeboh> Rebooting, I can open the vault and see its contents in Bash, but when I try to access  ~/Vaults with Dolphin it freezes.
[21:59] <jukeboh> Yeah. When Dolphin enters ~/Vaults it freezes and for reasons unknown to me cannot be killed. Maybe I need a better file browser. Any suggestions?


[00:33] <RAOF> infinity: Hey, how do syncs-from-PPAs happen?
[00:33] <infinity> RAOF: You might need to expand on that.
[00:34] <infinity> RAOF: At a most fundamental level, they happen the same way that "copy-package -b" works.
[00:34] <infinity> RAOF: If you mean who triggers them and why and under what circumstances, not really my department. ;)
[00:34] <RAOF> infinity: Specifically - those really annoying sync-from-unity-SRU-PPA syncs. robru would like one to happen :)
[00:34] <infinity> RAOF: Well, he knows how to make one happen...
[00:35] <robru> infinity, well, I thought I did.
[00:35] <infinity> robru: Okay, what are you actually trying to do here? :P
[00:35] <infinity> robru: You know how to land things in the queue.
[00:35] <robru> infinity, but I'm trying to get an SRU into saucy-proposed and it won't go
[00:35] <infinity> robru: What happens in the queue is up to us, but everything up to there is you.
[00:36] <robru> infinity, ok I have this SRU: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1304798 make it go ;-)
[00:36] <ubot2> Launchpad bug 1304798 in Online Accounts: Account plugins "Unable to access Facebook online account" [Critical,In progress]
[00:36] <robru> I mean, please. ;-)
[00:36] <infinity> robru: Is that https://launchpad.net/~ubuntu-unity/+archive/sru-staging/+sourcepub/4094719/+listing-archive-extra ?
[00:37] <RAOF> robru: Oh, it actually _is_ in the queue already.
[00:37] <robru> RAOF, oh, is it? crap.
[00:37] <robru> RAOF, ok, please accept it in saucy-proposed then ;-)
[00:37] <robru> infinity, yeah, that one
[00:37] <infinity> Right, that's sitting in the queue.
[00:38] <infinity> RAOF: The only real annoyance here is that debdiffing against the archive often involves downloading current archive tip and the PPA sources and diffing locally.
[00:38] <infinity> RAOF: Since the diffs in the PPA are almost never against the version you want.
[00:38] <RAOF> infinity: Carefully breaking all our nice tooling.
[00:38] <infinity> RAOF: Otherwise, review and accept as usual.
[00:38] <robru> infinity, yeah, I saw stupid diffs in the PPA
[00:38] <infinity> RAOF: And use sru-accept instead of sru-review. :/
[00:38] <RAOF> Right.
[00:38] <RAOF> And manually specify the version, etc.
[00:39]  * infinity nods.
[00:39] <robru> infinity, ok thanks
[00:39] <RAOF> That's what I find annoying :)
[00:39]  * RAOF *has* processed a bunch of these SRUs before, just not the bit leading up to it landing in the unapproved queue ☺
[00:39] <infinity> Well, sru-review should probably just grow the option to not care about diffs/etc so it can accept syncs without you entering all the info manually.
[00:40] <infinity> And then more fun to make it hunt down the original source of the sync, and do a local debdiff for you.
[00:40] <RAOF> I guess that'd be no worse than the screen-scraping it already does...
[05:05] <pitti> apw: is that the "tar: unexpected EOF" again (I'm on that, #1 prio), or something else?
[06:18] <pitti> apw: or do you mean the bunch of tests which failed due to gnat/ada now being uninstallable?
[06:41] <infinity> pitti: That'll be fixed (well, fsvo "fixed" that implies things that need gnat-4.6 also need transitioning) when gnat is bumped to 4.9
[06:41] <infinity> With doko on vacation, I'm not sure what his plan was there, so I didn't want to just sync the Debian gnat and get yelled at. :P
[06:52] <pitti> *nod*, thanks
[08:06] <apw> pitti, this was a whoe heap of them that had ended with qemu killed signal 15
[08:06] <apw> pitti, i think xnox retried them iirc, this was all on sysvinit
[08:08] <pitti> apw: "qemu killed signal 15" appears in every log (I should quiesce that somehow); the interesting line is usually the one above
[08:08] <apw> OK
[08:08] <apw> adt-run: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ tests done.
[08:09] <apw> not that that seems to carry much in the way of meaning
[08:09] <pitti> apw: could also be that the guys changed the jenkins/runners again, of course
[08:10] <pitti> apw: do you have a pointer to an example log?
[08:10] <apw> https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-apport/25/ARCH=amd64,label=adt/artifact/results/log
[08:11] <pitti> apw: yes, that's a regular test failure
[08:11] <pitti> ERROR: test_install_packages_versioned (__main__.T)
[08:11] <pitti> apw: (that's on my list for apport)
[08:13] <apw> pitti, any way we could get the framework to summarise its reasoning at the bottom, like 'test failure reported'
[10:00] <cjwatson> RAOF,infinity: I've improved sru-review a bit for copies now; it doesn't yet know how to get hold of diffs properly, but it now has a --no-diff option you can use to make it not try, and it now knows how to fetch the .changes file for copies so that it can at least deal with bugs
[10:01] <dbarth> ping? trying to get approval fo SRUs regarding webapps: webbrowser-app, unity-webapps-youtube, unity-webapps-livemail, unity-webapps-yahoomail
[10:01] <cjwatson> Still not great, but it's a bit more tolerable
[10:02] <cjwatson> dbarth: I was doing the sru-review work I just mentioned in part so that I could do that reasonably :-)
[10:02] <dbarth> ah cool
[10:03] <dbarth> so you can see that package diffs are small
[10:03] <cjwatson> Well, I can't yet, still downloading things
[10:03] <dbarth> the webbrowsr-app change is to ensure we stay inside the webapp container while authenticating to google apps
[10:03] <dbarth> ok, nw
[10:03] <dbarth> now i know it's on your radar
[10:04] <dbarth> ping me if anything
[10:06] <cjwatson> At some point it might be worth pretty-printing your manifest.json files in unity-webapps-*
[10:06] <cjwatson> Since the diffs there are unreadable
[10:06] <cjwatson> I'm sure it would make your own reviews easier too
[10:07] <cjwatson> dbarth: ^-
[10:08] <cjwatson> dbarth: unity-webapps-livemail has no bug in its changelog; that prevents SRU verification from working properly, so please re-prepare that with a fixed changelog
[10:10] <dbarth> manifest.json, it's a pain i agree; will ask alex the reason for that non-sense...
[10:11] <cjwatson> the others are fine, accepted
[10:16] <dbarth> cjwatson: thanks for the other packages
[10:16] <dbarth> cjwatson: for livemail though
[10:17] <dbarth> the bug ef. was missing in my branch, so i guess i need to go via ci again, to get the proper changelog update
[10:17] <dbarth> or i can update the merge proposal if that's legit
[10:26] <cjwatson> dbarth: I don't know exactly how to cause CI to put the right things in the changelog
[10:52] <dbarth> i've fixed the livemail package changelog and the new build is on its way now
[14:38] <shadeslayer> could someone accept homerun 1.2.3-0ubuntu0.2 ?  I have no idea how to fix the autopackage test issues.
[16:00] <xnox> rtg: we have a lot of autopkgtest issues getting resolved at the moment.
[16:01] <xnox> rtg: do you need sysvinit fix urgently in utopic?
[16:01] <rtg> xnox, ok, then I'll just leave it set until next week
[16:01] <rtg> its not urgent
[16:02] <xnox> rtg: you can see how much stuff is failing at the moment https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/ vs trusty which had far less failures https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/
[16:46] <shadeslayer> ScottK: could you also approve homerun, I made a insanely stupid mistake :/
[18:58] <SnowDust> hi all I want to get a .deb in universe
[18:58] <SnowDust> how to go ant it
[18:58] <SnowDust> about*
[18:59] <SnowDust> ny one ans this noob quest pizza
[19:00] <SnowDust> plz*
[19:00] <infinity> SnowDust: You want #ubuntu-motu
[19:01] <SnowDust> infinity: do u mean indeed to ask it thr
[19:01] <infinity> SnowDust: Yes.
[19:01] <SnowDust> thx infinity
[19:07] <robru> infinity, oh hey, we have another unity8 landing, can you bump the faux package please?
[19:07] <infinity> robru: Consider it done.
[19:08] <robru> infinity, thank you!
[19:08] <SnowDust> infinity: no one ans there in ubuntu-motu
[19:09] <SnowDust> can u :)
[19:14] <infinity> SnowDust: This is not a help channel.  Be patient in -motu, someone will answer eventually.
[19:14] <SnowDust> ok ok
[19:32] <saiarcot895> When does Quantal go EOL? Shouldn't it have been last month?
[19:35] <mdeslaur> saiarcot895: https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-April/002488.html
[19:36] <saiarcot895> mdeslaur: ah, ok
[22:41] <kees> http://changelogs.ubuntu.com/meta-release-lts lacks trusty?!
[22:41] <infinity> kees: Yes.
[22:42] <kees> why?
[22:42] <infinity> kees: We don't offer lts->lts upgrades until the point release is out.
[22:42] <infinity> kees: This isn't new. :P
[22:42] <kees> ah, I do remember that.
[22:42] <infinity> It's on http://changelogs.ubuntu.com/meta-release-lts-development for people who want to test early with -d
[22:42]  * kees considers. :)
[22:43] <kees> what's the rationale? more time for testing?
[22:43] <infinity> Yeah, more testing, and time to land more fixes/workaround from broken upgrade paths.