[12:58] <allee> kdevelop3: when one create a new project (rb or c++) has only custom lisenze (aka none ;) but not GPL LPGL as a choice.  When I first played with kdevelop long ago they were selectable.
[06:50] <freeflying>  build Linux  1 - 2 Windows  Linux ... 10/28 
[07:05] <Tm_T> ok?
[07:07] <Tm_T> freeflying: hmm, I have no idea what you're saying, 2w1121please try to use english
[07:07] <Tm_T> whoops
[07:07] <freeflying> Tm_t: sorry for paste chinese here
[07:08] <Tm_T> :)
[07:08] <Tm_T> freeflying: np but propably noone here knows it ;)
[08:30] <pef> hello
[09:32] <mornfall> wobble
[09:33] <mornfall> i have updated the adept 2.0 feature list on http://web.ekhis.org/adept.html -- comments?
[09:44] <Tm_T> mornfall: following that level3 episode
[09:44] <Tm_T> ?
[09:45] <mornfall> hmmh?
[09:45] <Tm_T> big part of network is down
[10:07] <mornfall> how is that related? :)
[10:09] <Tm_T> is it?
[10:10] <Tm_T> just thought
[10:10] <Tm_T> seems to be quite funny
[10:10] <Tm_T> and less funny
[10:10] <mornfall> oh well
[10:10] <Tm_T> :)
[10:11] <Tm_T> good idea
[10:11] <Tm_T> more coffee to me
[10:23] <Tm_T> mornfall: ok, looks good, just remember to show konsole part as default
[10:23] <Tm_T> hide only as option ;)
[06:05] <cmvo> Riddell: Hi Jonathan
[06:06] <Riddell> hi cmvo 
[06:07] <cmvo> On the GUIAPP admin mode problem. I noticed that admin mode worked after an update until the next reboot.
[06:08] <cmvo> and did some "tests". It seems it you install a kde package the admin mode works until shutdown.
[06:08] <cmvo> sri, it=if :-)
[06:13] <cmvo> Riddell: Hm, do I need the Riddell prefix for the text to reach you?
[06:14] <Riddell> it helps :0
[06:14] <Riddell> :)
[06:14] <Riddell> there's no pattern at all that I can see in the admin problem
[06:15] <Riddell> well, it working again after update is a pattern but there's no reason why that should make any difference
[06:16] <cmvo> I don't know why, but it is so here. reboot: no admin, aptitude reinstall kdebase-data, admin works
[06:17] <cmvo> I tried reinstalling kdebase-data, kdebase-bin, ksysguard and kscreensaver and in all 4 cases it restore admin mode. reinstalling a non kde package zip did not...
[06:29] <Riddell> ok, so that makes half sense
[06:29] <Riddell> but why should rebooting then break it again?
[06:29] <Riddell> it's insane I tell you
[06:33] <cmvo> Riddell: It is really strange. What changes in the system during the reboot that cause it to break?
[06:35] <Riddell> permissions on sockets and the like are the mose likely culprit
[06:39] <cmvo> Riddell: That's what I think too. I'm staring at /tmp right now. But its cleared during reboot...
[06:40] <cmvo> Riddell: The reinstall works even in a konsole window, a shutdown of kde is not needed.
[06:41] <Riddell> yeah, it's all rather random and evil
[06:43] <cmvo> Riddell: But what is the diference between the kscreensaver and zip debs to make it work for one and not the other..
[06:44] <cmvo> Riddell: For me it has been the same for hoary and breezy. But I have yet to try the reinstall trick on hoary.
[06:45] <Riddell> I don't think anything has changed
[06:46] <allee> cmvo: When you install KDE pkgs dirs/files that are what by kded(?) are rescanned
[06:46] <allee> cmvo: that's no explanation just one diff between installing a kde and not kde e.g. zip pkg
[06:47] <allee> s/what/watched/ by kde ...
[06:49] <cmvo> allee: I don't know (maybe yet :-) As it is so strange, I'm clinging to every straw...
[06:51] <allee> I had a look at ksysguard postinst: may run update-menu; update-desktop-database and ldconfig.
[06:51] <allee> cmvo: you may try to run these instead of a kde pkg installation
[06:52] <allee> cmvo: rerunning kbuildsyscoca is another possibility (but I still can imaging how this is related to admin mode problem)
[06:53] <cmvo> allee: kscreensaver doesn't even have a postinst.
[06:55] <allee> cmvo: even better. so only kbuildsyscoca left ;)  Another try is:  touch `dpkg -L ksysguard`
[06:56] <cmvo> allee: time for another reboot...
[06:56] <allee> cmvo: see you later ;)
[06:58] <cmvo> allee: Aha! kbuildsycoca it seems to be.
[06:59] <Riddell> running kbuildsycoca temporarily fixes it?
[06:59] <cmvo> allee: After running kbuildsycoca admin mode works.
[06:59] <Riddell> until reboot?
[07:00] <allee> cmvo: whao!  Mhmm, afair kbuildsyscoca keeps stuff in /var/tmp/kdecache-tmp  this is not cleared during reboot
[07:01] <cmvo> Ridell: Yup, kbscc fixes it, just doing the reboot to verify.
[07:02] <cmvo> allee: Have to do a look a /var/tmp after the reboot.
[07:02] <allee> I'm not sure but isn't on startup kbuildsyscoca only run in incremental mode????  Maybe theres a difference
[07:02] <cmvo> Riddell: After the reboot its broken again.
[07:18] <cmvo> allee: Strange, strange, strange. kbscc complains about /var/tmp/kdecache-<uid> and /tmp/kde-<uid> not beeing owned by root. But changing it does not help.
[07:19] <allee> cmvo: uh, those dirs where never owned by root.  Can it be that your tmp dirs are not mode 1777?
[07:19] <Riddell> they should be owned by the user I'm sure
[07:23] <cmvo> running kbscc only helps when run via sudo, not from a root shell.
[07:23] <Riddell> don't run kbuildsycoca with sudo
[07:23] <cmvo> Should both /tmp and /var/tmp be mode 1777?
[07:24] <Riddell> yes
[07:26] <cmvo> ok, both are. kdecache-<uid> subdirs are 700.
[07:34] <cmvo> holmes
[07:34] <cmvo> sri, wrong keyboard :-)
[07:36] <Riddell> wrong keyboard?  that's a new one :)
[07:38] <cmvo> I had to run kbscc sudo because the ksycoca is owned by root. I don't if this is from my fiddlings, but i change it and try again.
[07:39] <allee> cmvo: to run a prog one need execute access, one has not to own the file
[07:40] <allee> -rwxr-xr-x  1 root root 2904 2005-10-09 10:19 /usr/bin/kbuildsycoca
[07:41] <cmvo> I mean the ksycoca database file in /var/tmp/kdecache-<uid>, its mode 644 and owned by root.
[07:43] <Riddell> /var/tmp/kdecache-jr should be owned by user
[07:44] <Riddell> cmvo: sudo chown -R foo.foo /var/tmp/kdecache-foo
[07:44] <Riddell> does that fix the problem permanently?
[07:44] <cmvo> already done so, just rebooting
[07:45] <Riddell> the weird thing is that kdesu in general keeps working with this problem, it's just admin mode in control centre that breaks
[07:46] <cmvo> grr, nope. but i can run kbuildsycoca as user and it fixes it...
[07:51] <cmvo> I got both kdecache-<uid> and kdecache-<uid>M8sFG1 subdirs, both containing ksycoca database files. is this ok?
[07:54] <Riddell> no too sure what that means
[07:58] <cmvo> I deleted kdecache-<uid>M8sFG1 from recovery mode and it get recreated presumably during kde startup and now admin mode works without running kbuildsycoca.
[07:58] <Riddell> even after reboot?
[07:58] <cmvo> yup
[07:59] <Riddell> well that's a start at least
[08:00] <Riddell> it's also impossible to recreate, no idea what sets it off
[08:00] <Riddell> although it'll be some evil sudo stuff
[08:00] <cmvo> Strangely it gets recreated with the same cryptic suffix. I though it was a tmp suffix and would be different.
[08:01] <Riddell> hmm, spooky
[08:03] <cmvo> I believe those many long hours...
[08:05] <cmvo> Is it just a kubuntu problem or also a kde problem?
[08:06] <Riddell> it's been reported by non-kubuntu users but we get it more so I think it's a kde problem that's increased by our sudo patches
[08:09] <cmvo> Hm, the kdesu_:0 socket in /tmp/ksocket-<uid> it owned by <uid>:nogroup all other sockets are owned by <uid>:<uid>.
[08:11] <allee> cmvo: check ~/.kde where the link points to.  Maybe when kdecache-<you> was not writeable for you it created other links?
[08:11] <Sime> hey
[08:12] <allee> if yes logout kde and remove the links in .kde and login  again
[08:13] <allee> Sime: hey.  Read backlog: looks like cmvo will be the kubuntu hero of the year (at least mine) ;)
[08:14] <Riddell> cmvo: I have nogroup too, I think kdesu does that on purpose
[08:16] <cmvo> allee: tnx, but only if the real reason is found :-)
[08:16] <allee> cmvo: I trust you!
[08:17] <allee> cmvo: about the links in ~kde/ do they explain the strange  M8sFG1?
[08:18] <allee> you can remove everything in /var/cache/kde*<me> when you are logged out of KDE
[08:18] <cmvo> yup, it was the links in .kde that caused the second kdecache-<uid> to be created. I guess ksycoca was not writable at 19:06 so the second dir was created.
[08:24] <cmvo> do you know when kbuildsycoca is run during the kde startup? it does not seem to be in startkde
[08:25] <Riddell> I don't actually
[08:26] <cmvo> hm, ksycoca is binary. do you know of a dumptool for it?
[08:29] <Riddell> cat /var/tmp/kdecache-jr/ksycoca
[08:29] <Riddell> I guess
[08:30] <cmvo> does not help much as it is binary.
[08:30] <allee> cmvo: ksyscoca is a binary form of application, services, protocol desktop files to speed up startup and access time
[08:31] <allee> cmvo: no KDE really read the desktop files.  the all as access the ksyscoco db
[08:31] <allee> s/no KDE/no KDE app/
[08:32] <cmvo> i know what it is, but would like to compare its contents before and after a reboot
[08:34] <cmvo> seems to be time for a look a the sources...
[08:35] <allee> show about rsync -a kdecache-$USER  to another dir run kbuildsyscoca then check what files changes.  with xdelta you should be able to do a diff
[08:37] <cmvo> the is no difference. ksycoca is not touched during kde startup.
[08:39] <allee> and after running kbuildsyscoca?
[08:40] <cmvo> it is, but i can tell what changed
[08:46] <cmvo> xdelta does not help much. but it changed very little.
[08:46] <allee> cmp and xdelta?  does it change the same way (offset, same size of xdelta) when you run kbuildsyscoca once more?
[08:47] <allee> cmvo: maybe best ask #kde-devel how to dump it.  Maybe there someone has even an idea why running kbuildsyscoca influenced the admin mode
[08:49] <cmvo> thats my idea too. but it'll have to wait. i have to go, i'm very late already.
[08:49] <cmvo> to=too :-)
[08:50] <allee> same prob here!
[08:51] <cmvo> ok, depending on where in the world everybody is. have a nice day/evening/night and see you all tomorrow.
[08:52] <allee> bye cmvo and thx!
[08:52] <cmvo> you're welcome, hope we can find the real reason.
[08:55] <cmvo> Riddell: Good night 2u2. I think you are in Scottland. Hope you didn't mind me trying for so long.
[08:56] <Riddell> cmvo: thanks for looking at it
[08:57] <cmvo> Riddell: Thanks, cu!
[09:11] <jjesse> Riddell: can you please apply the KDE Stylesheet to the Kquickguide doc please, don't know how you did it for the other docs
[09:14] <jjesse> thanks
[09:14] <Riddell> actually there was a reason I didn't do that
[09:14] <Riddell> it didn't work with xsltproc or something
[09:15] <Riddell> and I couldn't get meinproc to output except as one large file
[09:15] <Riddell> I think
[09:15] <Sime> oh, allee is gone. I was going to explain to him how all I want is a *graphical* keyboard configuration module....
[10:29] <Riddell> hello raj 
[10:29] <Riddell> hello olwin too
[10:29] <Tm_T> sir Riddell, I presume
[10:29] <Tm_T> ;)
[10:31] <raj> hello Riddell
[10:51] <lippel> hi
[10:52] <lippel> some users reported problems with akregator from kubuntu 3.5 beta2 packages
[10:52] <Tm_T> many users
[10:52] <lippel> metakit plugin seems missing
[10:52] <Tm_T> https://wiki.ubuntu.com/KubuntuKDE35BetaKnownProblems
[10:52] <Tm_T> ;)
[10:52] <Tm_T> and hi lippel 
[10:53] <Tm_T> it's well known issue
[10:53] <Tm_T> at least widely reported
[10:54] <Tm_T> to me, no problems, using kdepim from 3.5 branch
[10:54] <Tm_T> some advantages when compiling stuff myself
[10:57] <lippel> Tm_T: looks like kbuildsycoca fuckup or something
[10:57] <lippel> hmm, i hear that the plugin is not installed at all
[11:22] <Tm_T> hm hm
[11:22] <Tm_T> lippel: anyway, I don't know what the problem is
[11:23] <lippel> Tm_T: libakregator_mk4storage_plugin.la/so is missing
[11:23] <Tm_T> ah
[11:24] <Tm_T> sounds like broken package