Re: QtWebKit in Qt5.6+ in Debian
On Thursday, 2015-06-25, 18:45:52, Florian Bruhin wrote: * Kevin Krammer kevin.kram...@gmx.at [2015-06-25 18:35:41 +0200]: On Thursday, 2015-06-25, 15:56:22, Florian Bruhin wrote: I still have some hope - I think Qt will still apply at least security fixes for QtWebKit until Qt 6, which still should be a while away. I would also be surprised if they would knowingly ship insecure code. I wouldn't call it *knowingly* - but chances are slim that someone will take care of security issues until there's a bug report - and even then, I guess it depends on the ressources Qt is willing to allocate to QtWebKit (which seems to be dropping at a fast rate the past few months). Hmm, I would think that there are people monitoring webkti related security lists, the new engine is webkit based as well. Also there might be commercial entities currently using QtWebKit who would want to get such update either as part of existing service agreements with one of the companies providing such services or through new agreements specifically set up for this. The open nature of Qt makes resource allocation basically driven by demand. E.g. all the code contributed by KDE developers was created because KDE applications needed it. Cheers, Kevin signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt 5.4 and QtWebEngine
On Friday, 2014-10-10, 00:19:51, Lisandro Damián Nicanor Pérez Meyer wrote: So my *personal* plan for Jessie+1 is this: not loose a single second on QtWebEngine. Of course I won't stop anyone in trying to ship it. But if no one steps up to maintain it I will not hesitate in simply ignoring it as much as possible, even at the point of not shipping stuff that depends on it. Since this is the web engine of Qt, is then plan not to ship Qt at all or not to ship this specific module? Assuming the latter, wouldn't that mean that each application will have to ship its locally bundled version, resulting in dozends or hundrets of per- package copies of the module of significant size? Cheers, Kevin signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: qt4-x11 Kubuntu Debian diff
On Tuesday, 2009-05-12, Jonathan Riddell wrote: Phonon is built from Qt. This seems like the only sensible way to build it to avoid a circular dependency although I don't know of any other distro doing it (and apps fail to compile since a header isn't installed by Qt's build system for phonon, they're easily patched). Another option seems to be to patch Qt. Upstream did it this way: http://qt.gitorious.org/qt/qt/commit/5299240db14579960358edeebfc72fcef905af13 Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
Re: Bug#523899: Stop providing KDE 3 support
On Monday 13 April 2009, Sune Vuorela wrote: On Monday 13 April 2009 15:35:08 Ana Guerrero wrote: about -kde is supposed to show it integrated with kde4/qt4 and if that is working (i have not checked), it will be kde3/qt3 and you have to install kdelibs from kde3 that some users might have ride of already. I agree that kde3 integration is not relevant in a kde4 environment. Using Qt3 dialogs sticks just as much out as being wrong as GTK or fltk dialogs. the kab parts might still be usable, I don't think they *yet* have changed the storage format, but it is just a matter of time. We will provide compatibility adaptors though, the KABC API is part of kdepimlibs until KDE5. However it is likely that at some point any integration efforts will probably switch to the new API. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
KDE4 and the KDEHOME problem
Hi there, Sune asked me to state my opinion regarding this issue. I am in favor of keeping the upstream default, $HOME/.kde This is what application developers assume and has therefore the highest chance of doing what the users expect. KDE3 - KDE4 is the most common scenario, be it now or at the Lenny -Squeeze transition. There is a good chance that neither configs nor data of applications has changed at all making an application upgrade similar to a 3.x - 3.x+1 move. Copying .kde to .kde4 at the first KDE start assumes that this is actually possible in terms of disk space. People with recent clean installation of KDE3 can have quite some quantities of data in .kde, e.g. mails. That approach also has the problem of relying on startkde being used or some lowlevel KDE code being patched (libs or runtime services like kdeinit4, kded). Of course the downside is that it potentially removes the way back for people who find they don't like KDE4 (yet). But since we are mainly talking about unstable users here, what are the chances that they don't have backups or do upgrades without checking how it would affect their system (which packages would get removed, etc). Addtionallly. Debian is unvoluntarily in the fortunate situation that it didn't ship earlier KDE4 release which quite often got rejected. The number of reports of people downgrading from 4.2 have been significantly lower. Cheers, Kevin P.S.: I am now also subscribed, so no need to CC me -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
