[00:04] are we putting docs in /usr/lib/kde4 as well? I thought I seen with kdelibs or something some of them going into /usr/share [00:04] should be /usr/lib/kde4 [00:05] roger [00:12] Riddell: want debdiffs or do you want me to go ahead and upload? [00:15] nixternal: just go ahead and upload [00:15] well [00:15] they should get stuck in New, I can let them through when toma releases them [00:15] roger [00:15] actually, plasma won't get stuck in new [00:16] nixternal: wait with that then [00:16] ya [00:16] I will post a debdiff for you [00:16] I have a new version waiting on the kdebase-* to compile anyway [00:16] roger [00:16] we have to wait a week? [00:17] release on 11th, we can let them through a day or two before I guess to get it into backports [00:18] groovy [00:18] and when that happens, my laptop gets its first wipe in almost 2 years [00:20] seele: going to SCALE? [00:20] nite. [00:20] hopefully I am, but I think she is, she has blogged it a few times :) [00:20] k'nite fdoving [00:25] what is stopping Oo.o from updating? it is in a constant "remove" state [00:37] wow.... huge review here http://www.mandrake.tips.4.free.fr/ubuntubeyondthehype.html [00:37] just a bit about kubuntu [00:38] Riddell: should kdelibs5-dev Conflicts: kdelibs4-dev ? [00:38] stdin: no, does it? [00:39] yeah [00:39] I remember the last sync from debian did that too [00:41] stdin: well spotted, up goes ubuntu5 [00:41] well other than that the new package update from RC2 (base install) just fine :) [00:43] great [00:46] stdin: I've the rest to upload too but I think I'll wait until a buildd admin can give back kdebase-* so it actually gets compiled [00:47] * Riddell sleeps [00:47] ok, good night [00:47] ahhh, that explains why I just almost removed kdelibs-kde3 stuff :) [00:48] gonna grab a bite to eat, back in a bit [02:00] wow.... hardy looks nice :) (this is nosrednaekim BTW) [02:01] no0by name [02:01] ;P [02:01] I know <_< .... I think i'm going to install this... [02:03] * ScottK waits for his hard drive to catch fire. [02:03] lol [02:04] you know what? they got rid of glxinfo off the liveCD. [02:10] hmmm is it known that dolphin in hard displays two context menus on the right hand side? [02:12] *in hardy [05:24] http://media.libsyn.com/media/dsyates/lottalinuxlinks_59.mp3 [05:24] if you want a good laugh, there is my interview podcast from today [05:26] later.. === danimo_ is now known as danimo === Lure is now known as Lure_ === Lure_ is now known as Lure [09:43] Morgen. [09:45] yuriy: poke. === Lure_ is now known as Lure [11:22] Riddell: do you understand why kdebase-workspace was published, but not kdebase-kde4, while both have built successfully? [11:22] kdebase-kde4 is still 3.97 in archive [11:22] build was successful: http://launchpadlibrarian.net/11161818/buildlog_ubuntu-hardy-i386.kdebase-kde4_4%3A3.98.0%7Esvn755919-1ubuntu1_FULLYBUILT.txt.gz === \sh_away is now known as \sh [11:24] kdebase-runtime is also fine, just kdebase-kde4 is strange [11:24] * Hobbsee will hedge a guess at a launchpad bug. [11:24] Lure: hardy? ppa? what? [11:24] Hobbsee: hardy [11:25] Lure: new queue/ [11:26] # libkonq5-templates_3.98.0~svn755919-1ubuntu1_all.deb (38.4 KiB) NEW [11:27] Hobbsee: can you fix that? [11:27] Hobbsee: it is anyway just moving files around [11:27] Lure: kdebase-kde4 is stuck in new for a new binary [11:27] Riddell: can you fix that? ;-) [11:27] Riddell: would have to fix my fixing, if i did. [11:27] Hobbsee: lol [11:28] Hobbsee: you can test how go he is in that ;-) [11:28] btw, what is URL for new queue [11:28] I forgot it since I did not need it for long [11:29] got it, is logical ;-) [11:29] ubuntu/hardy/+queue [11:29] https://edge.launchpad.net/ubuntu/hardy/+queue?batch=500 [11:29] Hobbsee: thanks, that batch thing is useful [11:31] freed [11:35] Riddell: thanks - I expect I need to wait until nexty publisher run, right? [11:36] Lure: yes [11:37] Hobbsee: can you give-back kdeedu-kde4? [11:38] done [11:38] Hobbsee: thanks [11:41] Pondery-ponder. [11:42] I think I can rape the editor debconf frontend. [11:43] By supplying a right EDITOR that would tell adept what to edit and wait for it. Hmh. [11:43] mornfall: sounds narferous [11:43] Parse error. [11:45] devious [11:45] Hm. [11:46] It should actually work fairly well. Probably better than having a custom debconf frontend for that. [11:47] I am just wondering if it is going to be easier to use dbus somehow, or a usual unix fifo... [11:49] debconf over dbus? [11:50] Nono, I just need this: [11:51] My adept-debconf-editor would (possibly over dbus or over a fifo) notify the running adept instance that debconf is waiting for answers and that the file that has the quetions is under /tmp/foobar [11:51] dbus is nice. [11:52] Then it (to emulate the way editors work) wait till the user clicks Ok/Next whatever in adept and then exit (and adept itself would edit the file). [11:52] But. [11:52] speaking of debconf and Adept, I think there's a debconf bug that causes Adept to crash: bug 119243 [11:52] Launchpad bug 119243 in adept "adept manager & license agreement issue (dup-of: 108185)" [Medium,Confirmed] https://launchpad.net/bugs/119243 [11:52] Launchpad bug 108185 in adept "Adept crashes if Java license agreement is not accepted" [Medium,Confirmed] https://launchpad.net/bugs/108185 [11:53] Well, yeah. [11:53] Will be fixed in new codebase I suppose. [11:53] dbus is also a breeze to implement. [11:53] fdoving: Well, how? : - ) [11:54] there is a techbase page about it. [11:54] I need to put something into environment (variables) for a shell script to be able to call through it. [11:54] Into adept. And I somehow doubt that the shell script is able to wait for a dbus signal or anything. [11:55] So a pure dbus solution doesn't really sound all that plausible? Dunno. [11:55] what will the shellscript do? [11:55] See above. [11:55] (The adept-debconf-editor thing.) [11:56] adept-debconf-editor would be a shellscript notifying adept that it's waiting? [11:56] Just like emacsclient, if you know that. But it uses sockets or such. [11:56] then it needs something back, right? [11:56] fdoving: Right. [11:56] (Well, something ~ just an ACK that the user is done.) [11:56] dbus calls can return something, as they really are regular functions. [11:57] can't you put the answer in the return reply? [11:57] Can I have a dbus call take 10 minutes eg.? [11:57] not sure, but i guess so. why not? [11:57] fdoving: That's sort of useless. [11:57] (Since debconf anyway wants the answer in a file, and it is easier to put it there with adept.) [11:59] I'll just use kill(1). Easy and POSIX. [12:02] elegant :) [12:04] And all I need that way is PID in say $ADEPT_PID and in the script wait for a timestamp change or such. [12:26] nixternal: fancy submitting this to the dot? http://arstechnica.com/journals/linux.ars/2008/01/04/kde-4-0-0-tagged-in-preparation-for-release [12:27] Another possibility is a passthrough frontend that seems to handle unix sockets. Hm. [12:38] morning [12:50] Riddell: what is the KDE4 plan, are we going to ship in Hardy KDE4.0.0 as it is now or some svn checkout from the KDE4.0.X branch? [13:13] mhb: latest 4.0.x branch [13:24] Riddell: shouldn't kdm-kde4 install /etc/init.d/kdm4 ? [13:24] Lure: yes, I havn't looked at kdm-kde4 at all [13:25] dbg packages are also broken [13:26] Riddell: will look into kdm startup, as I do not want kde3 kdm or gdm [13:34] Riddell: should kdm4 be coexistant with kdm3? [13:40] Riddell: and I expect we add -kde4.* files in debian and leaving debian's intact? [13:40] Lure: yes ideally, although it's not the most important issue for it [13:41] Riddell: problem is that we just rename package names in debian/control, but did not rename also .postrm/.postinst/... files [13:42] so they are not picked up by cdbs [13:42] if that's the only problem, can't be too hard :) [13:43] Riddell: that + fixing paths/names in scripts [13:44] Riddell: should I duplicate debian's or rename debian's (so having both kdm-kde4.* and kdm.*, only the later being used) [13:44] Lure: rename [13:44] looking at other .install, I would say rename [13:44] ok [13:51] Riddell: I suspect /var and /etc are not in /usr/lib/kde4, right? [13:56] Lure: they can be [13:57] Riddell: at least for /var that is not really acceptable, as /usr can be read-only (in theory) [14:02] true [14:11] I can't apt-get build-deps kde4base without downloading most of gnome [14:14] It seems to be because of libxine plugins having a hard dependancy on xine-plugins-gnome in gutsy. Can this please be changed? The package was updated with this bug months ago. [14:15] Riddell: I will leave kdm config/options/logs in /etc and /var, just rename it from kwin.* to kwin-kde4.* [14:16] Lure: Are you a kubuntu dev? [14:17] steveire: yep (even though not core-dev) [14:18] steveire: I am not sure if we can solve build-deps as you would like [14:18] it's fixed in hardy [14:18] are you able/authd to change libxine1-plugins dependancy on libxine-gnome (which depends on a lot of gnome) to a suggest instead? This is already the case in hardy, and is the result of an update during the gutsy cycle [14:19] Riddell: Hardy isn't released. This bug was introduced with an update to gutsy afaik. Can it not now be fixed? [14:20] steveire: where did the update come from? [14:21] Riddell: I'm not sure. Seems to be in gutsy backports [14:22] http://rafb.net/p/Wstxim77.html [14:23] Getting a compile-able kde4 should be as simple as get build-deps for wanted modules, svn co and cmake. === bobesponja is now known as bobesponja_ === bobesponja_ is now known as bobe_sponja [14:26] Hmmm, the libxine1-plugins in universe also has the hard dependancy on gnome [14:32] Actually I don't know where all the gnome stuff is coming from. I was sure before it was from the plugins, but they don't look like hard dependancies in there anymore. [14:32] http://rafb.net/p/XR278u74.html [14:36] Oh yeah. libxine depends on the plugins meta-package depends on the gnome-plugins package, but in hardy it is only a suggests. http://packages.ubuntu.com/hardy/libs/libxine1-plugins [14:37] The change seems to be making libxine1 depend on the plugins package. [14:38] Riddell: Could you let me know if this is not going to be changed so that I can give up? [14:44] libxine1 did not depend on the plugins in feisty. I'm not sure when that was changed [14:51] steveire: if it's from backports we could backport the newer version [14:51] Riddell: [14:52] Riddell: Cool. How would that happen/How long would it take? [14:52] steveire: file a request bug on launchpad.net/gutsy-backports [14:52] compile the hardy version on gutsy and make sure it works and report on that bug [14:52] poke ScottK to confirm it [14:52] Also, while things are being backported it might make sense to do libsoprano4 as well. the gutsy version is too old to complie kde4 [14:53] good idea [14:53] Riddell: How do I get the hardy version? [14:53] do I just dl and dpkg -i it? [14:53] steveire: yes [14:53] put hardy deb-src in sources.list [14:53] apt-get source xine-lib [14:54] debuild [14:54] well cd xine-lib-; debuild [14:54] debuild is from devscripts [14:54] * Riddell out === uga is now known as uga|awayu === uga|awayu is now known as uga|away [14:57] Riddell: more that I think, less I like binaries with -kde4 name [14:58] Riddell: will this at all work if the code does findExe() - it will not find appropriate binary [14:58] Alright, cheers. You really mean xine-lib or libxine1? Or -plugins? [14:58] Riddell: and I am sure we habe plenty of executions of kde binaries in the code... [14:58] Lure: are the binaries renamed? - i thought there were just links. [14:58] fdoving: wrappers are named /usr/bin/-kde4 [14:59] yeah, and the real binaries are in /usr/lib/kde4/bin/konqueror - for example? [14:59] Riddell: or will we patch findExe(), or am I missing something [14:59] fdoving: right [15:00] well, i don't use the packages, and i belive coexistance will become a bug-magnet. sorry to be pesimistic. === bobe_sponja is now known as bobesponja [15:00] Lure: does the wrappers change the environment for those apps too? [15:00] fdoving: yep, but we cannot leave without it, as important programs (like kdepim) are missing [15:01] Lure: that way around isn't a problem. the other way is harder. [15:01] fdoving: yes, so actually it might work then (kde4 app would probably findExe then on KDEDIRS) [15:01] running kde3 apps from within kde4 will probably be more or less painless. [15:01] as long as you don't use both versions with the same environment set. conflicting configfiles etc. [15:02] the problem, as i see it, will be running kde4 apps from within kde3, without breaking the configs. that is you need to change the $KDEHOME to make the -kde4 apps write their configs to ~/.kde4 [15:04] i (think) kde4 apps will cope with converting the kde3 configs to new versions. the other way around, i'm more sceptical about. [15:04] fdoving: that should work if 1) you use .desktop files or 2) use /usr/bin/name-kde4 [15:05] i atleast, broke my ~/.kde because i started a full kde4 session with the ~/.kde $KDEHOME. [15:05] fdoving: so kde4 apps will always have condig in ~/.kde4 [15:05] does the wrappers change the environment? [15:05] the -kde4 ones? [15:05] fdoving: yes [15:05] good. [15:06] then one just have to make it hard to execute the /usr/lib/kde4/bin binaries from within kde3, directly. [15:07] not having it in the path, only desktop files etc. [15:07] also, for kde3 apps to work correctly, with their own configs, from within kde4. [15:07] they need to be started with the kde3 $KDEHOME. [15:07] fdoving: yep, /usr/lib/kde4 is not in path [15:07] so, one would need wrappers for kde3 apps too. :) [15:08] i was playing with the idea to patch KDE4 to look for $KDE4HOME before $KDEHOME [15:08] that way we don't have the one conflicting environment variable. [15:09] as we have separate ones for kde3apps and kde4apps. [15:09] would fix loads of issues. [15:10] fdoving: that is interesting idea [15:10] it also is pretty simple. [15:10] as it only affects kdelibs. [15:10] I like it. I assumed that would happen anyway. [15:11] then one can throw the wrappers out the window. [15:11] Riddell: ^^^ that would be really safer than re-using KDEHOME [15:11] Riddell: problem is that kde3 app started in kde4 session would write config to ~/.kde4 (as they do not override config to ~/.kde) [15:12] in my case, they won't. [15:12] as we won't set $KDEHOME to ~/.kde4. [15:12] we only set $KDE4HOME to ~/.kde4 [15:14] why dose systemsettings still need dependency on python-dev? [15:17] Lure: hardcoding kde4 to only look for $KDE4HOME and ignore $KDEHOME is very simple. adding a '4' in one file. then we need to add one line to bin/startkde, to set the new variable to ~/.kde4 [15:18] i guess we will need to stick to ~/.kde4 for kde4 in the future too, right? [15:19] fdoving: not sure what are future plans, better ask Riddell [15:19] i guess that would make sense, as moving configs in the users homedir isn't sane at all. [15:19] anybody knows db_input/db_go commands used in pre/postrm? [15:23] ok, got it, configured in .config gile [15:23] file [15:23] got a link to the kde4 packages? [15:23] i'll make a proposed patch for my idea. [15:24] Riddell: how come that kdebase-workspace package I have downloaded with apt-get source does not have Ubuntu maintainer, even thougt it has ubuntu version? [15:24] Riddell: are we setting mail to ubuntu-devel-discuss or kubuntu-devel for kde4 packages? [15:26] Riddell: or ubuntu-motu as it is still in universe? [15:33] bbl, dinner. [16:21] mornfall: pong === Lure_ is now known as Lure [16:26] yuriy: Hi. Have you tried the send? [16:27] mornfall: i sent it yesterday morning and pinged you [16:28] yuriy: Sent where? [16:28] Yesterday morning? [16:28] *confusion* [16:28] mornfall: meaning about 24 hours ago [16:28] mornfall: i just did darcs send, i think it did me at mornfall dot net [16:29] Hm, what timezone are you in? [16:29] @time New York [16:29] Current time in America/New_York: January 05 2008, 11:29:27 - Next meeting: Edubuntu meeting in 4 days [16:29] Ah. [16:29] Probably explaints the morning bit. [16:30] However, does not explain why nothing arrived. [16:30] yuriy: What should I grep mail logs for? [16:32] hmm i don't remember what the subject i put on it was. is there a way to get darcs to tell me? [16:32] or would patch names show up or something? [16:32] They should. Probably best to try again. [16:33] mornfall: k. i'd moved the packagelist stuff into a separate file so it'll probably conflict with your latest change [16:34] Well, likely. [16:35] But I wanted to test the send mechanics nevertheless. [16:35] i was intrigued by darcs idea of only having conflicts when you edit the exact same line, but quickly found a use case where that doesn't quite work [16:35] (And I can always re-do the patch from the diff.) [16:36] oh i guess it doesn't ask for a subject. anyways, sent [16:36] Okey, I am sitting on the mail log... [16:37] (Btw., are you sure the sendmail(1) on your machine works right?) Or whatever darcs uses for sending mail. [16:40] yuriy: I get patches in the mailbox when running darcs send on a university machine. [16:40] nope, haven't tested it actually. will do [16:40] Creating patch to "http://anna.fi.muni.cz/~xrockai/ept-work"... [16:40] Patch bundle will be sent to: Petr Rockai [16:42] hmm good point sendmail doesn't seem to be working [16:43] : - \ [16:43] Somewhat un-unixy of that sendmail... : - ) [17:48] Riddell: story added from ars technica - review and push if you would like [17:57] * yuriy gives up on sendmail [18:00] yuriy: fetch nullmailer and point it to your smtp. [18:01] fdoving: i think i tried that already. what if my smtp needs authentication? [18:02] yuriy: then i have no clue. postfix is also very nice. === czessi_ is now known as Czessi [18:04] yuriy: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg145592.html [18:05] mornfall: saved to file and emailed [18:11] Riddell: kubuntu.org patch sent === neversfelde_ is now known as neversfelde [18:22] Riddell: is it possible to do some "stub" for KDE4 systemsettings that would open the old unported config tools (guidance) in a new window? [18:22] Riddell: because users would like to access the guidance tools the old way [18:22] and there's little chance someone is going to port them all in time [18:26] full kde4 session time : ) [18:26] drawing is pretty bad.. were there some tricks around for nvidia? [18:27] oh and icons aren't showing up for most kde programs in the menu [18:27] s/kde/kde4 [18:35] yuriy: Okey, thanks. I will show up tomorrow again. --> other room (no network) [18:35] (Yes, it has arrived.) [18:44] iijm or is everything huge in kde4? fonts? [18:48] ooh forcing 96dpi worked nicely [18:51] though i had to log out for it to take effect [19:02] yuriy: same as in kde3.. [19:03] but in gnome all font settings takes place immediately after 'apply' [19:03] iRon: i know, and in both it says that it'll take effect for newly started applications, which is not true [19:04] now how to get the gtk apps to not look so ugly.. [19:05] yuriy: on hardy ? [19:05] iRon: on gutsy, with kde4 from ppa full session [19:07] yuriy: hm.. $ ln -s /usr/share/themes/Clearlooks/gtk-2.0/gtkrc ~/.gtkrc-2.0 [19:07] or whatever theme you like [19:08] yuriy: there is a gtk port of Oxygen theme [19:10] yuriy: http://kims-area.com/?q=node/8 (search for Oxygen keyword) [19:10] damn, I need an archive admin === \sh is now known as \sh_away [19:32] can't get the oxygnome theme to take effect.. oh well [19:32] oxygnome? [19:32] is that a gtk theme i probably want? [19:35] looks like it [19:37] fdoving: yep, iRon's link above [19:38] if there is no gtk-engines-qt for qt4 it might even be something to include if it's any good [19:42] is there like a common place where gnome stores the gtk themes in users homedirs? [19:42] fdoving: ~/.themes [19:43] ah, that wasn't so hard :) [19:43] thanks. [19:48] doesn't seem to pickup my changes, i've symlinked ~/.gtkrc-2.0 to the gtkrc of the theme.. anything else i need to do nowdays? [19:53] fdoving: same here.. [19:53] fdoving: this works for me on hardy.. on kde3 :) [19:53] are we missing an engine or something? [19:53] on kde3.. sigh :) [19:53] fdoving: will try now on kde4 :) [19:54] it says: [19:54] · engine "pixmap" [19:54] in the gtkrc [20:01] stdin: newer kdegraphics and multimedia, etc coming to ppa? [20:03] yuriy: aha, GTK2_RC_FILES=:/home/frode/.kde4/share/config/gtkrc-2.0 [20:03] yuriy: pribably the same at your place i guess. [20:10] fdoving: oxygnome works fine for me on kde4 too [20:10] iRon: oh [20:11] did you install it to ~/.themes ? [20:11] i tried gtk-chtheme it didn't even appear there. [20:11] fdoving: i put it in /usr/share/themes/ [20:11] now i made it load the .gtkrc-2.0 but it can't find the rest of the files to include. [20:11] ah. [20:12] fdoving: from /usr/share/themes it works fine [20:12] * fdoving copies. [20:13] iRon: did you symlink to ~/.gtkrc-2.0 ? [20:13] fdoving: i've a symlink to my ~/.gtkrc-2.0-kde :) [20:14] fdoving: which includes "/usr/share/themes/oxygnome..." [20:17] fdoving: my ~/.gtkrc-2.0-kde: http://pastebin.com/d2c49ef8f [20:18] nixternal: ping :) [20:18] yo [20:22] iRon: i didn't have that second line. got it to work, but -kde didn't work after i unset those gtk environment variables. [20:22] brb, kid woke up. === wolfger_ is now known as wolfger [20:27] iRon: do you have a hover-color in the menus? - i don't. [20:29] fdoving: i have.. but oxygnome is far away from original oxygen theme.. [20:29] fdoving: i did ln -s /usr/share/themes/oxygnome/gtk-2.0/gtkrc ~/.kde4/share/config/.gtkrc-2.0 but it doesn't seem to have helped [20:30] yuriy: you need to include the /usr/share/themes/oxygnome/gtk-2.0/gtkrc [20:30] for paths to match. [20:30] yuriy: have a look at irons paste http://pastebin.com/d2c49ef8f [20:34] fdoving: oh nice that did it. i have the same problem with the colors though. either the theme is buggy or it's based on an old version of oxygen that had that problem [20:34] yuriy: hover issues in the menus? [20:35] fdoving: yeah.. but actually i think it only did the colors. scrollbars are still default gtk [20:35] k. [20:35] i have no clue. haven't been playing with gtk themes since gtk-1.2 back when i used gnome and blackbox. [20:35] years ago. [20:38] fdoving: yuriy: oh.. this theme depends on murrine gtk engine. so: apt-get install gtk2-engines-murrine :) [20:39] i did that. [20:41] also try to start firefox from konsole. and if there will be gtk theme errors -- you'll see them in console output [20:41] i have a bunch of gdkpixbuf issues. [20:42] when browsing menus.. [20:42] (gecko:22600): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion `pixbuf != NULL' failed [20:42] probably related to the issues with hover. [20:42] fdoving: hm.. strange [20:42] can you md5sum your oxygnome.tar.gz ? [20:43] fdoving: have you tryed to install `gtk2-engines-pixbuf' too? [20:43] yep, it's in. [20:45] fdoving: md5 -- 0f7b9349c91f93e31e3535a66ee9e838 [20:45] 0f7b9349c91f93e31e3535a66ee9e838 [20:45] that looks like a match to me. [20:45] fdoving: i'm on hardy [20:46] i'm on gutsy. [20:46] do you have any gnome things installed? [20:49] .../gtk2-engines-pixbuf_2.12.0-1ubuntu3_i386.deb [20:49] is your version higher? [20:50] i'll fetch the hardy version. [20:50] fdoving: i've one from hardy.. it is 2.12.3-2 [20:52] i get lots of: (firefox-bin:20989): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", [20:52] yuriy: then you need gtk2-engines-pixbuf [20:52] once you get it you'll get new fancy errors, like me. [20:52] gtk2-engines-pixbuf is part of gtk+2.0 [20:53] so i won't recompile that for gutsy. [20:55] fdoving: i installed that and it actually works now, menus too. doesn't look anything like current oxygen though. probably based off a previous incarnation [20:55] gah, so i'm the only one with the problem. [20:55] yuriy: looks better than default gtk, right? [20:56] fdoving: certainly [20:56] yuriy: are you on hardy too? [21:09] fdoving: no, i'm on gutsy [21:11] somehow my kde4 tries to overrride the gtk theme, but fails. [21:14] needed to use the kde3 colors kcmmodule to uncheck the "apply colors to non-kde apps" box. now kde4 doesn't override my gtk things anymore. === nivek_ is now known as nivek [21:24] anybody around who knows about the kubuntu-members-kde4 PPA? [21:26] LaserJock hmm? [21:26] I noticed some new packages [21:27] mm hmm [21:27] however it looks like the uploads aren't all finished yet as a dist-upgrade wants to get rid of a lot of previous kde4 packages [21:27] Riddell: the new stuff is 3.98 [21:29] looks like kdelibs and kdebase 3.98 but rest is 3.97 [21:40] stdin: new kde 4 packages to backport [21:43] Riddell: so everything is ok, I just need to wait? [21:44] LaserJock: yes [21:44]