Hi, just finished creating the KDE 4.8 RC1 tarballs. as usual please report blocking issues directly to release-team <at> kde.org and/or kde-packager <at> kd.eorg. Release is supposed to be ASAP, as soon as we confirmed that they build successfully. kde-l10n generation is still running, will upload them later today. Thanks, Dirk
--- Dirk Mueller escribió: > Hi, > > just finished creating the KDE 4.8 RC1 tarballs. as usual > please report > blocking issues directly to release-team <at> kde.org > and/or kde-packager <at> kd.eorg. There is no ksecrets tarball, and there is no ksecrets KDE/4.8 branch either, as far as I remember Valentin asked for it to be included in 4.8 and it passed review correctly. (adding Valentin just to confirm) Albert > > > Release is supposed to be ASAP, as soon as we confirmed > that they build > successfully. > > kde-l10n generation is still running, will upload them > later today. > > Thanks, > Dirk > _______________________________________________ > release-team mailing list > release-team <at> kde.org > https://mail.kde.org/mailman/listinfo/release-team >(Continue reading)
On Wednesday 21 December 2011, Albert Astals Cid wrote: > There is no ksecrets tarball, and there is no ksecrets KDE/4.8 branch > either, as far as I remember Valentin asked for it to be included in 4.8 > and it passed review correctly. (adding Valentin just to confirm) Hi, as far as I can see, the discussion on release-team was inconclusive. Do you suggest to include it as a seperate tarball, but not include the kde-runtime ksecretservicesd ? The suggestion was around including it in regular kdelibs and kde-runtime, which is why I stopped thinking about it further.. I think now that the KDE/4.8 branches exist, it would be better to merge the daemon into kde-runtime and add ksecrets as a dependency for kde-runtime. Let me know if I should include ksecrets as a seperate tarball. Thanks, Dirk
On Wednesday 21 December 2011, Albert Astals Cid wrote: > There is no ksecrets tarball, and there is no ksecrets KDE/4.8 branch > either, as far as I remember Valentin asked for it to be included in 4.8 > and it passed review correctly. (adding Valentin just to confirm) http://lists.kde.org/?l=kde-utils-devel&m=131847823604336&w=2 It looks like neither the kdelibs things are in nor the is the branch ksecretsservice from kwallet merged. I don't see that it makes sense to include the ksecrets tarball for now. As the discussion was inconclusive on k-c-d, I think we should reconsider it for the next milestone. Thanks, Dirk
--- Dirk Mueller escribió: > On Wednesday 21 December 2011, Albert > Astals Cid wrote: > > > There is no ksecrets tarball, and there is no ksecrets > KDE/4.8 branch > > either, as far as I remember Valentin asked for it to > be included in 4.8 > > and it passed review correctly. (adding Valentin just > to confirm) > > > http://lists.kde.org/?l=kde-utils-devel&m=131847823604336&w=2 > > It looks like neither the kdelibs things are in nor the is > the branch > ksecretsservice from kwallet merged. I don't see that it > makes sense to > include the ksecrets tarball for now. I'm not an expert in the matter, but as far as I know: * the kdelibs thing does need to be in, it's part of the ksecrets repo now via some plugin or something similar * the kwallet branch does not need to be in, ksecretservice has it's own gui for handling this stuff > As the discussion was inconclusive on k-c-d, I think we > should reconsider it > for the next milestone. That's far from what i remember, as far as I remember there were lots of changes asked for and Valentin met them all.(Continue reading)
On Wednesday, December 21, 2011 10:39:45 Albert Astals Cid wrote: > * the kdelibs thing does need to be in, it's part of the ksecrets repo now > via some plugin or something similar it is supposed to happen with a plugin, yes. that has not yet been implemented. what is in the branch right now is code that can be built if ksecretservice is available. which means right now to make it work one needs to build kdelibs, ksecreteservice, then kdelibs again. not great, but i believe at least one major distro is planning on doing this. in 4.9 this should be resolved using the plugin approach mentioned. > * the kwallet branch does not need to > be in, ksecretservice has it's own gui for handling this stuff that is correct. > > As the discussion was inconclusive on k-c-d, I think we > > should reconsider it > > for the next milestone. > > That's far from what i remember, as far as I remember there were lots of > changes asked for and Valentin met them all. also correct. it would be a shame to see his efforts miss another release. -- -- Aaron J. Seigo humru othro a kohnu se(Continue reading)
On Wednesday 21 December 2011, Aaron J. Seigo wrote: > it is supposed to happen with a plugin, yes. that has not yet been > implemented. what is in the branch right now is code that can be built if > ksecretservice is available. which means right now to make it work one > needs to build kdelibs, ksecreteservice, then kdelibs again. Ugh, build cycles are a bad idea. what needs to be done to get it out the buildcycle? can we include it in kdelibs/experimental perhaps? Thanks, Dirk
On Wednesday 21 December 2011, Albert Astals Cid wrote: > > As the discussion was inconclusive on k-c-d, I think we > > should reconsider it > > for the next milestone. > That's far from what i remember, as far as I remember there were lots of > changes asked for and Valentin met them all. Ok, then I created the ksecrets tarball. we can anyway reconsider this for RC2 if it should not be included. Thanks, Dirk
Hello, Sorry for the late reply - I was at work. On 12/21/2011 04:02 PM, Dirk Mueller wrote: > On Wednesday 21 December 2011, Albert Astals Cid wrote: > >>> As the discussion was inconclusive on k-c-d, I think we >>> should reconsider it >>> for the next milestone. >> That's far from what i remember, as far as I remember there were lots of >> changes asked for and Valentin met them all. > Ok, then I created the ksecrets tarball. we can anyway reconsider this for RC2 > if it should not be included. I suppose you took the contents of the ksecrets repository. If I'm correct, then you got the right tarball. This repo has all the ksecretsservice components and as Aron explained kdelibs will load these components using a plug-in logic. That logic is not yet implemented though. Cheers, -- -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
On Wednesday 21 December 2011, Valentin Rusu wrote: > I suppose you took the contents of the ksecrets repository. If I'm > correct, then you got the right tarball. Yes, I branched master into KDE/4.8 and took that branch. > This repo has all the ksecretsservice components and as Aron explained > kdelibs will load these components using a plug-in logic. That logic is > not yet implemented though. Okay, still some time left over vacation season?Greetings, Dirk
Hi, On Wednesday 21 December 2011, Dirk Mueller wrote: > just finished creating the KDE 4.8 RC1 tarballs. as usual please report > blocking issues directly to release-team <at> kde.org and/or > kde-packager <at> kd.eorg. > > Release is supposed to be ASAP, as soon as we confirmed that they build > successfully. I realize it's late because the RC was already announced, but we ran into at least 2 build issues with this in Fedora: 1. kde-l10n doesn't build! http://koji.fedoraproject.org/koji/buildinfo?buildID=279668 (Warning: The builds are parallel builds, so the log has unrelated stuff interspersed.) warning: failed to load external entity "fundamentals.docbook" index.docbook:121: parser error : Failure to process entity fundamentals-chapter &fundamentals-chapter; ^ index.docbook:121: parser error : Entity 'fundamentals-chapter' not defined &fundamentals-chapter; make[2]: *** [docs/kde-baseapps/kwrite/index.cache.bz2] Error 1 make[1]: *** [docs/kde-baseapps/kwrite/CMakeFiles/kwrite-handbook.dir/all] Error 2 in kde-l10n-sv (if I picked the right context out of the parallel build log). 2. The released version of KDevelop doesn't build against the new okteta headers. Not sure whether that's intentional, but it breaks things in any case. If the incompatibility is intentional, we need an updated KDevelop.(Continue reading)
Am Freitag, 23. Dezember 2011, 02:54:00 schrieb Kevin Kofler: > Hi, > > On Wednesday 21 December 2011, Dirk Mueller wrote: > > just finished creating the KDE 4.8 RC1 tarballs. as usual please report > > blocking issues directly to release-team <at> kde.org and/or > > kde-packager <at> kd.eorg. > > > > Release is supposed to be ASAP, as soon as we confirmed that they build > > successfully. > > I realize it's late because the RC was already announced, but we ran into > at least 2 build issues with this in Fedora: > > 1. kde-l10n doesn't build! > http://koji.fedoraproject.org/koji/buildinfo?buildID=279668 > (Warning: The builds are parallel builds, so the log has unrelated stuff > interspersed.) > warning: failed to load external entity "fundamentals.docbook" > index.docbook:121: parser error : Failure to process entity > fundamentals-chapter &fundamentals-chapter; > ^ > index.docbook:121: parser error : Entity 'fundamentals-chapter' not defined > &fundamentals-chapter; > make[2]: *** [docs/kde-baseapps/kwrite/index.cache.bz2] Error 1 > make[1]: *** [docs/kde-baseapps/kwrite/CMakeFiles/kwrite-handbook.dir/all] > Error 2 in kde-l10n-sv (if I picked the right context out of the parallel > build log). > Either do(Continue reading)
On 23.12.11 02:54:00, Kevin Kofler wrote: > 2. The released version of KDevelop doesn't build against the new okteta > headers. Not sure whether that's intentional, but it breaks things in any > case. If the incompatibility is intentional, we need an updated KDevelop. Yes, okteta changed its API and the released KDevelop does not build against that. KDevelop master does build against current okteta afaik (didn't try myself). I don't quite see what that has to do with KDE 4.8, KDevelop is not released as part of the SC and has its own schedule. There's a new KDevelop release planned in the not-too-distant future, but no fixed dates yet (its in feature freeze now though). If everything went correctly with the okteta libs then they should have update SONAMES and hence should be co-installable with the old versions keeping both the released kdevelop and new okteta running. Andreas
On 23.12.11 10:49:11, Andreas Pakulat wrote: > On 23.12.11 02:54:00, Kevin Kofler wrote: > > 2. The released version of KDevelop doesn't build against the new okteta > > headers. Not sure whether that's intentional, but it breaks things in any > > case. If the incompatibility is intentional, we need an updated KDevelop. > > Yes, okteta changed its API and the released KDevelop does not build > against that. KDevelop master does build against current okteta afaik > (didn't try myself). > > I don't quite see what that has to do with KDE 4.8, KDevelop is not > released as part of the SC and has its own schedule. There's a new > KDevelop release planned in the not-too-distant future, but no fixed > dates yet (its in feature freeze now though). Need to correct myself: The 4.2 branch of KDevelop was also changed by Friedrich, so distributions can take the patch from the branch: http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/041913.html AFAIK there's not going to be another 4.2.x release of KDevelop, the developers concentrate on 4.3 already. Andreas
On Friday, December 23, 2011 02:54:00 Kevin Kofler wrote: > 2. The released version of KDevelop doesn't build against the new okteta > headers. Not sure whether that's intentional, but it breaks things in any > case. If the incompatibility is intentional, we need an updated KDevelop. Please make sure Okteta and KDevelop authors know about this. -- -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
On 23.12.11 10:55:42, Sebastian Kügler wrote: > On Friday, December 23, 2011 02:54:00 Kevin Kofler wrote: > > 2. The released version of KDevelop doesn't build against the new okteta > > headers. Not sure whether that's intentional, but it breaks things in any > > case. If the incompatibility is intentional, we need an updated KDevelop. > > Please make sure Okteta and KDevelop authors know about this. They are, in fact Friedrich already fixed. And differently than I said before, its also in the 4.2 branch. So distro's can easily pull the patch: http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/041913.html There's not going to be another 4.2.x release afaik. Andreas
Vendredi, le 23 décembre 2011, à 13:46, Andreas Pakulat a écrit: > On 23.12.11 10:55:42, Sebastian Kügler wrote: > > On Friday, December 23, 2011 02:54:00 Kevin Kofler wrote: > > > 2. The released version of KDevelop doesn't build against the new > > > okteta headers. Not sure whether that's intentional, but it breaks > > > things in any case. If the incompatibility is intentional, we need an > > > updated KDevelop. > > > > Please make sure Okteta and KDevelop authors know about this. > > They are, in fact Friedrich already fixed. And differently than I said > before, its also in the 4.2 branch. So distro's can easily pull the > patch: > > http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/0419 > 13.html Right, thanks Andreas for pointing out :) Only pushed the needed commits a few days ago to have the Okteta plugin for KDevelop to also support the upcoming version of Okteta, both for master/4.3 and 4.2, but did forget to notify you packagers, pardon me. For 4.2 it is commit https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/revisions/1a0aeb55ff099d31fd6fe4f7e02c70f8c5f122ea If there are any problems, please just ping me by email so I could see to fix them, I should be able to spare time away for any issues also the next days. > There's not going to be another 4.2.x release afaik.(Continue reading)
On Friday 23 December 2011, Friedrich W. H. Kossebau wrote: > Right, thanks Andreas for pointing out :) Only pushed the needed commits a > few days ago to have the Okteta plugin for KDevelop to also support the > upcoming version of Okteta, both for master/4.3 and 4.2, but did forget to > notify you packagers, pardon me. > > For 4.2 it is commit > https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/re > visions/1a0aeb55ff099d31fd6fe4f7e02c70f8c5f122ea Here's a version which actually applies against 4.2.3: http://pkgs.fedoraproject.org/gitweb/?p=kdevelop.git;a=blob_plain;f=kdevelop-4.2.3-okteta08.patch;hb=HEAD (The commit http://commits.kde.org/kdevelop/1a0aeb55ff099d31fd6fe4f7e02c70f8c5f122ea needs to be applied on top of your previous commits: http://commits.kde.org/kdevelop/2d77d88856c78bd34690cae57042e7a314f446bf http://commits.kde.org/kdevelop/14e0929d07b51b7bbccf802ef0a8502c9266140e http://commits.kde.org/kdevelop/7b20bf4845ea5f85cb7ac8d24d30971f9b862d1d .) Kevin Kofler
On Friday 23 December 2011, Kevin Kofler wrote: > 1. kde-l10n doesn't build! > http://koji.fedoraproject.org/koji/buildinfo?buildID=279668 > (Warning: The builds are parallel builds, so the log has unrelated stuff > interspersed.) > warning: failed to load external entity "fundamentals.docbook" > index.docbook:121: parser error : Failure to process entity > fundamentals-chapter &fundamentals-chapter; > ^ > index.docbook:121: parser error : Entity 'fundamentals-chapter' not defined > &fundamentals-chapter; > make[2]: *** [docs/kde-baseapps/kwrite/index.cache.bz2] Error 1 > make[1]: *** [docs/kde-baseapps/kwrite/CMakeFiles/kwrite-handbook.dir/all] > Error 2 in kde-l10n-sv (if I picked the right context out of the parallel > build log). This one is fixed by: http://websvn.kde.org/?view=revision&revision=1270166 but now it fails during install of kde-l10n-es: CMake Error at data/kdegames/ktuberling/cmake_install.cmake:38 (FILE): file INSTALL cannot find "/builddir/build/BUILD/kde-l10n-4.7.95/kde-l10n-es-4.7.95/data/kdegames/ktuberling/cigarro.wav". Albert, in your commit: http://websvn.kde.org/?view=revision&revision=1267107 you removed the files without updating CMakeLists.txt. Kevin Kofler
El Dissabte, 24 de desembre de 2011, a les 02:42:52, Kevin Kofler va escriure: > On Friday 23 December 2011, Kevin Kofler wrote: > > 1. kde-l10n doesn't build! > > http://koji.fedoraproject.org/koji/buildinfo?buildID=279668 > > (Warning: The builds are parallel builds, so the log has unrelated stuff > > interspersed.) > > warning: failed to load external entity "fundamentals.docbook" > > index.docbook:121: parser error : Failure to process entity > > fundamentals-chapter &fundamentals-chapter; > > > > ^ > > > > index.docbook:121: parser error : Entity 'fundamentals-chapter' not > > defined &fundamentals-chapter; > > make[2]: *** [docs/kde-baseapps/kwrite/index.cache.bz2] Error 1 > > make[1]: *** > > [docs/kde-baseapps/kwrite/CMakeFiles/kwrite-handbook.dir/all] Error 2 > > in kde-l10n-sv (if I picked the right context out of the parallel build > > log). > > This one is fixed by: > http://websvn.kde.org/?view=revision&revision=1270166 > but now it fails during install of kde-l10n-es: > CMake Error at data/kdegames/ktuberling/cmake_install.cmake:38 (FILE): > file INSTALL cannot find > > "/builddir/build/BUILD/kde-l10n-4.7.95/kde-l10n-es-4.7.95/data/kdegames/ktu > berling/cigarro.wav". > > Albert, in your commit:(Continue reading)
KDE has some issues with qt-4.8.0. One of it is regarding QUrl.toLocalfile: https://bugzilla.redhat.com/show_bug.cgi?id=749213 Patching qt with followed patch fixes it: qt-everywhere-opensource-src-4.8.0-QUrl_toLocalFile.patch Does anybody else has issues with KDE 4.7.95 build against qt-4.8.0 or would it be better to build the next RC against qt-4.7.4 again?
diff -up qt-everywhere-opensource-src-4.8.0/src/corelib/io/qurl.cpp.toLocalFile qt-everywhere-opensource-src-4.8.0/src/corelib/io/qurl.cpp
--- qt-everywhere-opensource-src-4.8.0/src/corelib/io/qurl.cpp.toLocalFile 2011-10-03
22:44:32.000000000 -0500
+++ qt-everywhere-opensource-src-4.8.0/src/corelib/io/qurl.cpp 2011-10-27 12:58:35.706815049 -0500
@@ -6158,7 +6158,8 @@ QUrl QUrl::fromLocalFile(const QString &
QString QUrl::toLocalFile() const
{
// the call to isLocalFile() also ensures that we're parsed
- if (!isLocalFile())
+ // Treat URLs with no scheme as local for backward compatibility
+ if (!isLocalFile() && (!d || !d->scheme.isEmpty()))
return QString();
QString tmp;
|
Hi, I've built kde 4.7.95 against qt 4.8 and haven't had any issues. Infact, it ran a little faster and a lot more reliably when built against 4.8 than it ever did for me against 4.7.4. I didn't use any patches either. I wasn't aware that there was one, let alone that it was needed. Good luck. --- On Mon, 12/26/11, Phil Miller <philm <at> chakra-project.org> wrote:
|
May I ask what distro you are using? We have several issues with QT 4.8 and discussing that in our mailing-list: http://groups.google.com/group/chakra- devel/browse_thread/thread/db11f92846e962f Am Montag, 26. Dezember 2011, 13:20:52 schrieb Harry Miller: > Hi, > > I've built kde 4.7.95 against qt 4.8 and haven't had any issues. Infact, it > ran a little faster and a lot more reliably when built against 4.8 than it > ever did for me against 4.7.4. I didn't use any patches either. I wasn't > aware that there was one, let alone that it was needed. > > Good luck.
|
Hello again I read through the Chakra thread. Very interesting. I've not experienced any of those bugs. I have two boxes with qt 4.8. As for the distro, I have one multilib Gentoo install and one LFS no multilib. Feel free to ask if you have any more questions. Harry --- On Mon, 12/26/11, Phil Miller <philm <at> chakra-project.org> wrote:
|
Phil Miller wrote: > KDE has some issues with qt-4.8.0. > > One of it is regarding QUrl.toLocalfile: > > https://bugzilla.redhat.com/show_bug.cgi?id=749213 probably of more interest is following these, https://bugreports.qt.nokia.com//browse/QTBUG-22382 and it's impact on kde: http://bugs.kde.org/show_bug.cgi?id=285028 > Patching qt with followed patch fixes it: > > qt-everywhere-opensource-src-4.8.0-QUrl_toLocalFile.patch Not exactly "fix", but more of a workaround to restore qt47 behavior in the meantime. -- rex
On Monday 26 December 2011 19:42:17 Rex Dieter wrote: > Phil Miller wrote: > > KDE has some issues with qt-4.8.0. > > > > One of it is regarding QUrl.toLocalfile: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=749213 > > probably of more interest is following these, > https://bugreports.qt.nokia.com//browse/QTBUG-22382 > and it's impact on kde: > http://bugs.kde.org/show_bug.cgi?id=285028 > > > Patching qt with followed patch fixes it: > > > > qt-everywhere-opensource-src-4.8.0-QUrl_toLocalFile.patch > > Not exactly "fix", but more of a workaround to restore qt47 behavior in the > meantime. Right. The real fix is to fix knotify, which was doing this rather wrong ("if isRelative then call toLocalFile"). Actually the guilty commit is probably the one which replaced most calls to path() by calls to toLocalFile() in order to fix local file paths on Windows. So a solution could be to just put path() back. An alternative is the patch I now posted to bug 285028. Can you test either one (should be equivalent) and apply that if it works? I don't think patching Qt is a good idea at all, it makes qt-4.8 different from qt-4.8 depending on the system, which creates a support hell. And to reassure you, the amount of toLocalFile() calls over all doesn't matter, 99.99% of the urls used in KDE are absolute, not relative. -- -- David Faure, faure <at> kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Chakra GNU/Linux uses your patch now David. We are back to the unpatched qt
package.
> Right. The real fix is to fix knotify, which was doing this rather wrong
> ("if isRelative then call toLocalFile").
>
> Actually the guilty commit is probably the one which replaced most calls to
> path() by calls to toLocalFile() in order to fix local file paths on
> Windows.
>
> So a solution could be to just put path() back.
> An alternative is the patch I now posted to bug 285028.
> Can you test either one (should be equivalent) and apply that if it works?
>
> I don't think patching Qt is a good idea at all, it makes qt-4.8 different
> from qt-4.8 depending on the system, which creates a support hell.
>
> And to reassure you, the amount of toLocalFile() calls over all doesn't
> matter, 99.99% of the urls used in KDE are absolute, not relative.
Might be some different stuff but kmail misbehaves lately. When I sent an email
it goes as normal in my outbox but stays there, even after knotify told me
that it was sent. Never moves to the sent folder.
It was actually sent and received by those people I sent my emails to. Kmail
claims about dbus-issues. Here is a terminal output which uses some QUrl
calls:
[phil <at> chakra-pc ~]$ kmail
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.
kmail2(2317)/kdepimlibs (mailtransport)
MailTransport::TransportManagerPrivate::fillTypes: Found Akonadi type "Dummy
MailTransport-Ressource"
kmail2(2317)/kdepimlibs (mailtransport)
MailTransport::TransportManagerPrivate::fillTypes: Have SMTP, Sendmail, and 1
Akonadi types.
kmail2(2317)/kdepimlibs (mailtransport) MailTransport::Transport::Transport:
"803483917"
kmail2(2317)/kdepimlibs (mailtransport)
MailTransport::Transport::usrReadConfig: type 0
kmail2(2317)/kdepimlibs (mailtransport) MailTransport::Transport::Transport:
"1122665913"
kmail2(2317)/kdepimlibs (mailtransport)
MailTransport::Transport::usrReadConfig: type 0
kmail2(2317)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open
ksycoca from "/var/tmp/kdecache-phil/ksycoca4"
kmail2(2317)/kdeui (Wallet) KWallet::Wallet::openWallet: Pass a valid window
to KWallet::Wallet::openWallet().
kmail2(2317)/kdeui (Wallet) KWallet::Wallet::openWallet: Pass a valid window
to KWallet::Wallet::openWallet().
kmail2(2317)/nepomuk (library) {anonymous}::GlobalModelContainer::init:
Connecting to local socket "/tmp/ksocket-phil/nepomuk-socket"
kmail2(2317)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl(
"file:///" ) , type: 5 , frame: QWebFrame(0x863f990)
kmail2(2317)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl(
"file:///" ) , type: 5 , frame: QWebFrame(0x863f990)
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdepimlibs (mailtransport): Could not access Outbox.
[phil <at> chakra-pc ~]$ kmail2(2317)/libkdepim Akonadi::PluginLoader::scan:
registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_kalarm.desktop"
for ("application/x-vnd.kde.alarm", "application/x-vnd.kde.alarm.active",
"application/x-vnd.kde.alarm.archived", "application/x-
vnd.kde.alarm.template") @ ("default", "KAlarmCal::KAEvent")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_contactgroup.desktop"
for ("application/x-vnd.kde.contactgroup") @ ("legacy", "default",
"KABC::ContactGroup")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_bookmark.desktop"
for ("application/x-xbel") @ ("legacy", "default", "KBookmark")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_addressee.desktop"
for ("text/vcard", "text/directory") @ ("legacy", "default",
"KABC::Addressee")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_kcalcore.desktop"
for ("text/calendar", "application/x-vnd.akonadi.note", "application/x-
vnd.kde.notes") @ ("default", "KCalCore::Incidence*")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_microblog.desktop"
for ("application/x-vnd.kde.microblog") @ ("legacy", "default",
"Microblog::StatusItem")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_kcal.desktop"
for ("text/calendar", "application/x-vnd.akonadi.note", "application/x-
vnd.kde.notes") @ ("legacy", "KCal::Incidence*")
kmail2(2317)/libkdepim Akonadi::PluginLoader::scan: registering Desktop file
"/usr/share/apps/akonadi/plugins/serializer/akonadi_serializer_mail.desktop"
for ("message/rfc822", "message/news", "text/x-vnd.akonadi.note") @ ("legacy",
"default", "KMime::Message*")
kmail2(2317)/kdepimlibs (kpgp) Kpgp::Module::checkForPGP: Kpgp: gpg found
kmail2(2317)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl(
"file:///" ) , type: 5 , frame: QWebFrame(0x863f990)
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::doJob:
KIO::SimpleJob(0x8ae0e28)
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::protoQ: creating
ProtoQueue instance for "data"
kmail2(2317)/kio (Scheduler) KIO::ProtoQueue::ProtoQueue:
m_maxConnectionsTotal: 1 m_maxConnectionsPerHost: 1
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::doJob:
KIO::SimpleJob(0x8b62b68)
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::protoQ: creating
ProtoQueue instance for "file"
kmail2(2317)/kio (Scheduler) KIO::ProtoQueue::ProtoQueue:
m_maxConnectionsTotal: 5 m_maxConnectionsPerHost: 5
kmail2(2317)/kio (Slave) KIO::Slave::createSlave: createSlave "data" for
KUrl("data:image/PNG;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAABCAMAAADpTH4XAAAAA3NCSVQICAjb4U/gAAAASFBMVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///+qqqoAAAD2cKDYAAAAGHRSTlMAAAAAAAAAAAAAAAAAAAAAAAAAAAD//wCysdQaAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAC0lEQVQImWMQxQIAEU8BpQ0ofWgAAAAASUVORK5CYII=")
kmail2(2317)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote:
Listening on "local:/tmp/ksocket-phil/kmail2cF2317.slave-socket"
kmail2(2317)/kio (Slave) KIO::Slave::createSlave: createSlave "file" for
KUrl("file:///usr/share/emoticons/kde4/wink.png")
kmail2(2317)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote:
Listening on "local:/tmp/ksocket-phil/kmail2nt2317.slave-socket"
kmail2(2317)/kio (KIOJob) KIO::TransferJob::slotFinished:
KUrl("data:image/PNG;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAABCAMAAADpTH4XAAAAA3NCSVQICAjb4U/gAAAASFBMVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///+qqqoAAAD2cKDYAAAAGHRSTlMAAAAAAAAAAAAAAAAAAAAAAAAAAAD//wCysdQaAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAC0lEQVQImWMQxQIAEU8BpQ0ofWgAAAAASUVORK5CYII=")
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished:
KIO::TransferJob(0x8ae0e28) KIO::DataSlave(0x8ba5380)
kmail2(2317)/kio (AccessManager)
KDEPrivate::AccessManagerReply::readHttpResponseHeaders: changed content-type
to "image/PNG ; charset=us-ascii"
kmail2(2317)/kio (KIOJob) KIO::TransferJob::slotFinished:
KUrl("file:///usr/share/emoticons/kde4/wink.png")
kmail2(2317)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished:
KIO::TransferJob(0x8b62b68) KIO::Slave(0x8b61848)
kmail2(2317)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl(
"file:///" ) , type: 5 , frame: QWebFrame(0x863f990)
kmail2(2317)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::instance:
instance(): ... initialised
kmail2(2317)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readConfig:
readConfig(): local zone= "Europe/Berlin"
kmail2(2317)/kdecore (K*TimeZone*) KSystemTimeZonesPrivate::readZoneTab:
readZoneTab( "/usr/share/zoneinfo/zone.tab" )
kmail2(2317)/kdewebkit KWebPage::acceptNavigationRequest: url: QUrl(
"file:///" ) , type: 5 , frame: QWebFrame(0x863f990)
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
kmail2(2317)/kio (Slave) KIO::Slave::kill: killing slave pid 0 ( "data://" )
kmail2(2317)/kio (Slave) KIO::Slave::kill: killing slave pid 2213 ( "file://" )
David, your fix didn't fix it completely. Seems it only happens if you have QT 4.8.0 or higher installed. On a plain QT 4.7.4 install this bug don't happen at all. You can now play sounds in systemsettings/notifications but you don't hear them when the actual notification comes. Only as text-notification as usual. Seems we have to dig a little deeper into this situation. What else can we try to fix this issue with knotify and qt 4.8?
RSS Feed