[00:06]  * yofel is fairly certain now that kubuntu_42_fix_icon_themes.diff in qt4-x11 is what causes those BadWindows
[00:06] <yofel> more debugging tomorrow
[00:49] <yofel> ok, one more thing before I go to bed: The X errors are caused by kile and have been there already, but that patch seems to pull KDE apps into a gtk context where those errors are fatal, in kde they're not unless KDE_FATAL_X_ERROR is set
[01:06] <apachelogger> yofel: the world is cruel like that
[01:07] <apachelogger> yofel: also there appeared a gdk error thread on kde-core-devel today
[01:07] <apachelogger> will recover kubotu tomorrow
[01:07] <apachelogger> ENOKEYS
[01:09] <apachelogger> yofel: upstream reports are to like 95% related to ubuntu
[01:09] <apachelogger> (the other 5% are listed as source compiled, which of course does not say much about qt...)
[01:10] <apachelogger> so I'll pretty much agree that it is a patch that is causing it
[01:10] <apachelogger> -> bed
[02:04] <smartboyhw> The first PM I received today is a stranger directing foul languages at me:O
[03:35] <manchicken> JontheEchidna: Hey man, I'm on. Are you on?
[03:35] <JontheEchidna> manchicken: for a little bit, yup
[03:35] <manchicken> JontheEchidna: So I added some debug code into what I believe dbus is calling from the libqapt
[03:36] <manchicken> bool WorkerDaemon::writeFileToDisk(const QString &contents, const QString &path)
[03:36] <manchicken> That one.
[03:36] <JontheEchidna> uh huh
[03:36] <manchicken> I added some qDebug() prints and they're not coming up, so I'm thinking that the dbus calls aren't happening.
[03:37] <manchicken> Unless dbus calls end up in a different place :)
[03:37] <JontheEchidna> That is indeed what should end up being called
[03:37] <manchicken> I didn't think linking kdebug stuff in was worth the trouble since you didn't have it linking in.
[03:37] <JontheEchidna> heh, yeah
[03:38] <manchicken> So I'm wondering if you have a moment to help me troubleshoot this.
[03:38] <JontheEchidna> I do
[03:38] <JontheEchidna> I'm wondering if qaptworker2 ever gets started
[03:38] <manchicken> How do I test for that?
[03:39] <JontheEchidna> top maybe? It should come up in the process list when you call a function in libqapt that requires the worker daemon
[03:39] <JontheEchidna> dbus starts it automatically when the dbus call is made
[03:40] <manchicken> Let me put htop up and see if I can watch it in my chroot while it's running.
[03:41] <manchicken> I think it's very possible that I'm just missing something in my chroot.
[03:41] <JontheEchidna> probably. the issue you're having seems to be a very... fundamental error, heh
[03:42] <manchicken> Yeah... so I htop while the program is running and I don't see qaptworker2 going at all.
[03:43] <manchicken> Do you know which package it's in?
[03:44] <JontheEchidna> manchicken: libqapt2-runtime
[03:44] <JontheEchidna> manchicken: though it should be installed if you're running libqapt git
[03:44] <manchicken> Okay, I do have it installed, but it's not running.
[03:45] <JontheEchidna> It could  be that the dbus service file isn't being installed in a place where the chroot's dbus can see it
[03:45] <manchicken> I think I saw a build warning about that, let me rebuild libqapt and see if that pops out.
[03:46] <JontheEchidna> org.kubuntu.qaptworker2.service is the file
[03:48] <manchicken> So dbus is sort of an RPC service then?
[03:48] <JontheEchidna> yes, inter-process too
[03:48] <JontheEchidna> like dcop back in the day
[03:48] <manchicken> WARNING: Installation prefix does not match PolicyKit install prefixes. You probably will need to move files installed in POLICY_FILES_INSTALL_DIR and by dbus_add_activation_system_service to the /usr prefix
[03:49] <manchicken> That's what I get when I `cmake .` in the libapt source root.
[03:49] <manchicken> The toplevel of the git repo
[03:50] <JontheEchidna> it seems that that's causing problems
[03:50] <manchicken> -- Up-to-date: /usr/local/share/dbus-1/system-services/org.kubuntu.qaptworker2.service
[03:50] <manchicken> So I think this may be a polkit issue then/
[03:51] <JontheEchidna> On a live system it's in /usr/share/dbus-1/system-services/org.kubuntu.qaptworker2.service
[03:51] <manchicken> Ah, so I need to get cmake not to use /usr/local then
[03:51] <JontheEchidna> I live life on the edge and do qapt/muon development against my live system :P
[03:53] <JontheEchidna> I always pass -DCMAKE_INSTALL_PREFIX=/usr to cmake at the top level
[03:53] <manchicken> Yeah, it's going now.
[03:53] <manchicken> That is living on the edge.
[03:54] <JontheEchidna> it's fairly safe. I can always fall back to apt-get if things get too horribly broken in Muon Land at any given time
[03:54] <manchicken> That's true.
[03:55] <manchicken> I usually use aptitude anyway.
[03:56] <ScottK> manchicken: You should use apt-get.  Things have changed while you were away and the apt resolver is generally considered better these days.
[03:57] <JontheEchidna> Did they ever get MultiArch support sorted for aptitude?
[03:58] <JontheEchidna> I assume they must have at least rudimentarily, since it's Debian's default package manager
[04:00] <manchicken> JontheEchidna: Fixed the prefix, killed polkit, restarted it and then ran again. Still won't write the file.
[04:00] <JontheEchidna> :(
[04:01] <JontheEchidna> manchicken: I have to shuffle off to bed now; sorta getting up early tomorrow
[04:02] <JontheEchidna> hit me up tomorrow though if you're still having issues.
[04:02] <manchicken> JontheEchidna: No worries. I'll keep plugging away at it, I'm gonna be headed to bed in an hour or two myself.
[04:03] <manchicken> QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
[04:03] <manchicken> I get that when I start /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
[04:04] <manchicken> I'm gonna google
[04:06] <manchicken> I'm wondering if I need to start qdbus in some way before I fire this off. I wonder if my chroot not having a full session is causing this.
[04:14] <manchicken> shadeslayer_: You around?
[04:19] <manchicken> That's an interesting bug... when apt-get asks if you want to continue using fr localization, it says [O|n] instead of [Y|n]. If you type o for "oui," then it aborts. It wants 'y', even though it is acting in fr locale and even prompted for o/n.
[04:27] <manchicken> Okay, taking a crack at lxc, I'll see if that makes life easier :)
[04:50] <manchicken> JontheEchidna: I don't think this is it, I can't get this to play nice even in my normal box.
[04:51] <manchicken> I'm gonna head to bed. This isn't moving anywhere fast...
[04:51] <manchicken> Later.
[07:29] <lordievader> Good morning.
[10:07] <smartboyhw> Riddell, ping
[10:24] <BluesKaj> Hiyas all
[10:51] <soee> good morning
[10:52] <BluesKaj> 'morning soee
[12:22] <manchicken> Anybody got an idea why a qDebug() call that I added to libqapt for debugging wouldn't be printing from the calling program? I'm wondering if there's something akin to kdebugdialog involved as well.
[13:13] <manchicken> JontheEchidna: This whole thing was totally my fault.
[16:49] <tester56> yofel: Adding "Option "TripleBuffer" "True"" and "Option "CoolBits" "1" " to /etc/X11/xorg.conf reduces Cpu consupmtion massively for me 
[16:50] <tester56> (under "Section "Device"")
[16:51] <tester56> if feel like trying out, I would be very happy if you could report back if it helps for you too!
[16:54] <tester56> yofel: Cpu consumption of kwin, as we talked about lately
[16:55] <mikecb> tester56: what driver are you running?
[16:55] <tester56> nvidia-325 
[16:56] <tester56> mikecb: are you experiencing the high cpu consumption too?
[16:57] <mikecb> kwin runs consistently at a few percent, but nothing to make the fans go crazy
[16:57] <mikecb> also 325.08
[16:58] <tester56> mikecb: but much more than it used to be in kde 4.10 ?
[16:58] <tester56> mikecb: what vsync option are you using?
[16:58] <mikecb> default. I haven't added anything.
[16:58] <tester56> okay that should mean Automatic
[16:59] <tester56> mikecb, but can you confirm that there is higher cpu consumption than in kde 4.10?
[17:00] <mikecb> I don't know. I never really looked.
[17:01] <tester56> mikecb: play a video, do nothing else and watch top kwin cpu usage
[17:01] <mikecb> jumps to 30% on an old avi in dragon
[17:02] <tester56> mikecb: that means high
[17:02] <mikecb> yup
[17:02] <mikecb> want me to try the tripbuf and coolbits and see if it does anything?
[17:03] <tester56> would be very nice as I am in talk with a kwin developer 
[17:03] <tester56> remember to restart x :D
[17:03] <mikecb> yup
[17:05] <mikecb> brb
[17:08] <tester56> now try to watch the video again ... in my case kwin dropped to a third or less 
[17:09] <mikecb> yeah, now between 5-6%
[17:09] <mikecb> that's excellent
[17:10] <tester56> thing is the developer i am in talk with does not yet know the reason of the problem
[17:10] <tester56> but it is nice for me to see the issue confirmed by someone else ... 
[17:11] <tester56> mikecb: thank you very much!
[17:11] <mikecb> yw. let me know if you need any logs or anything.
[17:15] <tester56> mikecb: are you a member of the kde mailing list?
[17:15] <mikecb> nope
[17:35] <yofel> tester56: checking (I only have 319 though)
[17:36] <tester56> yofel: that should not matter, I had 319 until yesterday too
[17:50] <yofel> tester56: TripleBuffer seems to help, CoolBits has no noticible effect
[17:50] <tester56> yofel: is it significantly better for you?
[17:51] <tester56> yofel: thank you very much for testing btw.
[17:51] <yofel> well, it is better in the sense that disabling VSync doesn't seem to change much now
[17:52] <yofel> it's hard to measure a ~5% difference
[17:52] <tester56> have you tried watching a video in idle?
[17:52] <tester56> and comparing cpu usage?
[17:53] <tester56> there is a second issue though: if you restart kwin, watch a video you will notice kwin cpu usage raising if you have vsync to reuse or full scene repaint
[17:54] <tester56> it will raise after a minute or so (sometimes even faster, despite doing nothin else but watching)
[17:54] <yofel> I have no idea what it was before, but now my kwin cpu usage while watching a movie is ~20%
[17:54] <yofel> which is a bit high indeed :/
[17:55] <mikecb> yofel: mine went from 30% without the options to 5% with
[17:55] <tester56> yofel: yeah ... what vsync option?
[17:56] <yofel> well, here it's using ~20% with "Automatic" and "None", so that's not it
[17:56] <tester56> yofel: could you also check if it is raising for you during watching a video instantly after a kwin restart  (you need vblank reuse or full scene repaint)?
[17:57] <yofel> kwin restart? i.e. killing it?
[17:57] <tester56> kwin --replace & 
[17:58] <yofel> hm, now it's ~11%
[17:59] <tester56> yeah and raises after some time 
[18:00] <tester56> does it? (it shoudl remain constant then)
[18:03] <yofel> uh, it stayed at 11 for a while, now jumped to 18 and is staying there again
[18:03] <yofel> this is with vblank reuse
[18:04] <tester56> yeah ... i am seeing the same issue
[18:10] <yofel> tester56: hm, this is not constant actually. it went from 11 to 18, then to 16, stayed for a while on 24, now it's on 11 again.
[18:10] <yofel> so I don't think it actually rises because of the video
[18:10] <tester56> are doing anything else during watching the video?
[18:10] <tester56> even moving the cursor has an impact
[18:11] <tester56> in my case it rises because of the video, as there is nothing else on my desktop and I am not even moving the cursor, just watching video and top
[18:11] <yofel> well, I think the quassel notification when you pinged me had an effect
[18:11] <yofel> otherwise no
[18:12] <yofel> I now fetched my EeePC so I can write somewhere else ^^
[18:12] <yofel> ok, now it's again on 18 - for no obvious reason
[18:13] <tester56> restarting kwin should show you the minimum again
[18:13] <yofel> 11