Re: QtWebKit in Qt5.6+ in Debian
On Thursday, 2015-06-25, 18:45:52, Florian Bruhin wrote: > * Kevin Krammer [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: QtWebKit in Qt5.6+ in Debian
On Thursday, 2015-06-25, 15:56:22, Florian Bruhin wrote: > * Lisandro Damián Nicanor Pérez Meyer [2015-06-25 09:49:29 -0300]: > > On Thursday 25 June 2015 14:13:59 Florian Bruhin wrote: > > > Seeing that Qt removes QtWebKit from their source- > > > > Actually they are not going to update it anymore, maybe except for > > security > > bugfixes. The source will remain there and should be able to keep building > > with Qt5.6+ > > I'm not entirely sure it will, unfortunately. > > From [1]: > > * We’d still remove the deprecated modules from our Qt 5.6 release > (maybe with the exception of Qt Script). > > I also remember reading somewhere explicitely that it won't be > included in the qt-everywhere-opensource-... archive - sadly I can't > find the mail anymore. I would be surprised if it got removed from anything other than the binary packages. It might be something that one has to opt-in to at configure time, but I don't see any gain in basically breaking the compatibility guarantee. The whole point of "deprecated" is to mark something for future removal instead of removing it. And as far as I know no Qt API, let alone a whole module, has ever been removed in a point release. Only major releases do that if at all. > 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. 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: KDE plans for the squeeze cycle
I mostly agree with Ana's comments, but I think I have a couple of additions. I can't be certain but I would bet that KDE 4.4 will not depend on Qt4.6 unless there is at least a release candiate of 4.6 at the time of KDE soft feature freeze (actually that would have to be very soon, it would probably be hard to remove 4.6 dependencies). Personally I like the idea of going for a very late patch release of a KDE release, e.g. the latest 4.3 because 4.4 will very likely introduce a lot of new stuff. Speaking as a KDEPIM developer, 4.4 is the release we are currently targeting or addressbook and calendar porting to Akonadi [1]. This is very nice for us as developers, however there are still issues for certain types of deployment, mainly because non of the embedded style database backends (SQLite, MySQL/Embedded) qualify for being our (Akonadi's) default yet. Cheers, Kevin [1] Some functionality might even depend on Nepomuk -- 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: get akonadiconsole out of kdepim-runtime
On Wednesday, 2009-07-22, Tom Albers wrote: > Op Wednesday 22 July 2009 23:32 schreef u: > > > 2) Split akonadiconsole into its own package > > > > Maybe we could ask upstream to move it to back kdepim(libs)? Debugging > > tools do not really belong to -runtime packages, do they? In my opinion, > > if to split off akonadiconsole, then invent another package name like > > kdepim-runtime-dev- tools (similar to qt4-dev-tools) or something. > > We can not move it to kdepimlibs as it depends on kdepim-runtime. Depending > on -runtime at build time, kind of defeats the purpose ;-). At least not for now. AFAIK the plan is to move it out to kdepim once the dependency issues are resolved, e.g. libraries currently in kdepim-runtime become public API and move to kdepimlibs. I would recommend to leave it in kdepim-runtime for now, also because it is a really helpful for diagnosing Akonadi setup related problems. Akonadi is currently mainly interesting for users which want to try new technologies, e.g. for testing purposes, and at this point they can give more valuable feedback when having access to akonadiconsole. 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: 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
