headers
Matthew Woehlke | 1 Mar 2008 02:39
Picon
Gravatar

Re: Security risk in setting up $LD_LIBRARY_PATH by KDE script

Vlad wrote:
> The KDE script
> (http://techbase.kde.org/index.php?title=Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc)
> that developers are encouraged to place in their ~/.bashrc file
> contains the following line:
> 
> export LD_LIBRARY_PATH=$KDEDIR/lib:$QTDIR/lib:$LD_LIBRARY_PATH
> 
> If $LD_LIBRARY_PATH is empty before the above line is executed, then
> the $LD_LIBRARY_PATH after that line will end in a colon (:).
> 
> $ echo $LD_LIBRARY_PATH
> /home/kde-devel/qt-copy/lib:/home/kde-devel/kde/lib:
> 
> This causes files such as tls, i686, sse2, cmov and libc.so.6 to be
> searched for in the current directory (.). Wouldn't this be a security
> risk?

No one else thinks so?

FWIW, my kde4 environment script looks like this:

headCat() { [ -d "$2" ] && eval $1=\"$2\$\{$1:+':'\$$1\}\" ; }

... stuff ...

headCat PKG_CONFIG_PATH $KDEDIR/lib/pkgconfig
headCat LD_LIBRARY_PATH $KDEDIR/lib
headCat PATH $KDEDIR/bin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chusslove Illich | 1 Mar 2008 04:41
Picon

[PATCH] KAboutData: Static license name/text resolvers

License information can be contained, as a keyword, in
X-KDE-PluginInfo-License field of .desktop files. Possibly from other
sources too, e.g. Kate scripts/syntax stuff comes to mind. As it is now,
this information is presented as such to the user -- terse and unlocalized.

After some discussion on #kde-devel, we've come to the conclusion -- the way
I interpret it :) -- that it would be nice if KAboutData would provide
static methods which take a license keyword, and return license name/text,
for known licenses. The patch is attached.

The immediate users are KPluginInfo and Plasma::PackageMetadata (though the
latter may inherit from the former in the future). Also the patch to
KPluginInfo, for an example of usage.

--

-- 
Chusslove Illich (Часлав Илић)
Attachment (kaboutdata-license-statics-01.diff): text/x-diff, 10 KiB
Attachment (kplugininfo-licenses-01.diff): text/x-diff, 1629 bytes
Permalink | Reply | 2 comments |
headers
nf2 | 1 Mar 2008 12:21
Picon

Re: Proposal for a new KIO API: KMount/KMountModel

Aaron J. Seigo wrote:
> On Friday 29 February 2008, nf2 wrote:
>   
>> Also, it's difficult to display mounts/volumes in arbitrary locations in
>> the file-management hierarchy: You can set up ServiceMenues and custom
>> mimetypes to add the unmount action to such items (that's what i'm
>> currently doing in my remote:// implementation), but you still get
>> "delete" or "copy" entries in the context menu which don't make much
>> sense for mounts/volumes. This makes me believe that mounts are special
>> KFileItems, which have to be recognized appropriately (i.e with
>> KFileItem::isMount()).
>>     
>
> i understand the problem, but i'm not sure abstracting-the-abstraction-layer 
> is the best answer here as it means yet another layer of software.
>
> it would be great if one of the following were to happen:
>
> * the layers under Solid spoke this stuff (e.g. modify the HAL layer to report 
> on such "virtual" mounts)
> * barring that, the Solid backends for platforms that support things such as 
> FUSE were made aware of them.
>
> the downside of the second approach is that it does start to pervert Solid 
> from being a purely literal hardware system in this one case, but it is where 
> i would expect to find this stuff and will give us exactly one place to point 
> people to, instead of saying "well, if you want user space software mounts 
> too, then you need to use this other API as well as Solid, otherwise you can 
> just use Solid ..." that sounds really messy.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Jansen | 1 Mar 2008 15:28

Obsolete files

Hi

If noone objects i will remove all the files excluded from installation with the last change to
kdebase/runtime/kcontrol/menus/CMakeLists.txt from the repository. They belong to kcontrol and
that one is no more.

I think it would make sense to move the last 2 files standing to kinfocenter. X-KDE-information is mainly
used there.

Mike

--

-- 
Michael Jansen
Available for contract work ( Development / Configuration Management )
http://www.michael-jansen.biz
Permalink | Reply | 1 comment |
headers
Christian Ehrlicher | 1 Mar 2008 16:40
Picon
Picon

[Patch] Re: Ksycoca & QSharedMemory

Christian Ehrlicher schrieb:
> Hi,
> 
> To resolve our problems with the open file handle on ksycoca and the resulting problems on windows (file
can't be deleted) I would like to use QSharedMemory to share the ksycoca cache.
> Another idea would be to use QFile::map() but this doesn't work on windows too because we can't delete the
mapped file (only rename would work) :(
> 
> Therefore I would like to create a simple class derived from QIODevice. It would load (if needed) the file
into a QSharedMemory segment. There are two memory segments needed. One with the data and one for status informations.
> When the file content changes, the process needs to call a function update() which increases a counter in
the status information shm. After this it informs the other processes via dbus (like it's done now). They
reopen their file handle and attach to the new data shm segment. The old shm segment goeas away after the
last one detached from it.
> 
> If you don't like the idea for a general usage, I would use it for windows only.
> 
> Comments?
Ok, here the patch.
It introduces a new (currently internal) class KMemFile. This QIODevice 
is then used in ksycoca on windows.

It works fine for me and Ralf Habacker. I also tested it on Linux (not 
tested with kdelibs, only as standalone app).

Comments?
Christian
Attachment (kdelibs.patch): text/x-diff, 13 KiB
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rafael Fernández López | 1 Mar 2008 20:05
Picon
Favicon
Gravatar

kuiserver (JobViewServer spec implementation) close to be finished

Hi all,

I am pretty happy this is being finished. You can find preliminar patches at:

http://media.ereslibre.es/2008/03/kuiserver

There is only one remaining thing. On global.cpp at kdelibs/kio/kio, you see 
something like:

KJobTrackerInterface *KIO::getJobTracker()
{
    return globalJobTracker;
}

I have plans for changing this. I will probably be writing a new KCM (I don't 
know where we could place a config thing of this kind), for letting user 
select [ ] Show jobs in separate windows or [ ] Show jobs in the same window.

K_GLOBAL_STATIC(KWidgetJobTracker, globalJobTracker)
K_GLOBAL_STATIC(KUiServerJobTracker, uiServerJobTracker)

...

KJobTrackerInterface *KIO::getJobTracker()
{
    if ((qgetenv("KDE_FULL_SESSION") == QByteArray("true")) &&
        weWantSeparateWindows)
        return globalJobTracker;

    return uiServerJobTracker;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Ehrlicher | 1 Mar 2008 21:50
Picon
Picon

Re: Kate crash on exit - windows only?

Christian Ehrlicher schrieb:
> David Faure schrieb:
>> On Thursday 28 February 2008, Christian Ehrlicher wrote:
>>> Hi,
>>>
>>> Kate crashes on exit due to weird (?) unloading behaviour. I can see 
>>> that qt_call_post_routines() is already executed and 
>>> KServiceTypeFactory is destroyed. Later 
>>> QObjectCleanupHandler/KPluginFactory is destroyed and katepart lib 
>>> gets unloaded. During the unload, KatePartPluginManager dtor is executed
>>
>> This is a memory leak in the application. This the katepart 
>> pluginmanager should
>> be deleted much before QObjectCleanupHandler triggers.
>>
> Ok, thx for this information - I'll see how to fix it and post a patch
> 
Here a fix.
kdelibs_kate.patch is the important one - it destroys the KPluginFactory 
(and unloads libktexteditor) before Q(Core)Application is gone. This 
solves my crash on windows.

kdesdk.patch adds some delete statements to properly clean up some objects.

Christian
Attachment (kdelibs_kate.patch): text/x-diff, 926 bytes
Attachment (kdesdk.patch): text/x-diff, 921 bytes
Permalink | Reply | 3 comments |
headers
Roman Jarosz | 1 Mar 2008 22:12
Picon
Favicon

[PATCH] XMLGUI Crash Fix


Hi,

This patch fixes crash when applying toolbar changes in Kopete Chat View.

Kopete Chat View was crashing because ContainerNode for mainToolBar wasn't deleted but
KToolBar(mainToolBar) container was. So while the menu was regenerated the KXMLGUIBuilder
found the old ContainerNode but the ContainerNode was pointing to already deleted KToolBar.

So with this patch when we delete ContainerNodes we first save the state of container
(this is when client == state.guiClient) and after that if all clients and children are removed
we delete the ContainerNode. This is done for all KXMLGUIClients so all ContainerNodes should be deleted.

In previous implementation we could only remove the ContainerNode when client == state.guiClient and
all clients and children were removed. So if there were any non-removed clients when 
client == state.guiClient then the ContainerNode wasn't deleted.

So the crash is fixed, but there is still a bug because when the menu is regenerated some default
actions are missing. For instance the Tools menu in Kopete Chat View which contains history actions is
missing or the history actions aren't on mainToolBar.

I really don't know much about XMLGUI so can anybody look at this patch and the Kopete bug?

Thanks,
Roman Jarosz
Attachment (fixxmlguicrash.diff): application/octet-stream, 3414 bytes
Permalink | Reply | 1 comment |
headers
David Jarvie | 2 Mar 2008 03:40
Picon
Favicon

[PATCH] Set default Qt directory in startkde

Currently, startkde fails to start a KDE session when PATH doesn't contain the 
Qt bin directory. The startkde script uses the directory containing itself as 
the default for the KDE installation's bin directory, and adds that to PATH. 
But it doesn't set Qt's directory.

The attached patch fixes this failure by using kde4-config in startkde's 
directory to find Qt's location, and add it also to PATH. Okay to commit?

--

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm
Attachment (startkde.diff): text/x-diff, 561 bytes
Permalink | Reply | 10 comments |
headers
Christoph Cullmann | 2 Mar 2008 13:55
Picon

Re: Kate crash on exit - windows only?

Am Samstag 01 März 2008 21:50:40 schrieb Christian Ehrlicher:
> Here a fix.
> kdelibs_kate.patch is the important one - it destroys the KPluginFactory
> (and unloads libktexteditor) before Q(Core)Application is gone. This
> solves my crash on windows.
>
> kdesdk.patch adds some delete statements to properly clean up some objects.
Think that's ok, thx for the fix :) Please commit (if not already done)

cu
Christoph

--

-- 
Christoph Cullmann
KDE Developer, Kate Maintainer
http://babylon2k.de, cullmann <at> kde.org
Permalink | Reply | 0 comments |

Gmane