Re: Newer KDEPIM for Jessie
Am Sonntag, 3. Mai 2015, 21:11:27 schrieb Markus Raab: > Hello, > > Martin Steigerwald wrote: > > I think it would be good to have a newer KDEPIM + Akonadi into Jessie. > > > > Why? The current akonadi 1.13 master branch together with kdepim, > > kdepimlibs, kdepim-runtime from 4.14 branches (as of 4.14.6/7) here runs > > better than ever before, including my most annoying bug > > > > [Akonadi] [Bug 343114] gets stuck on one request that times out, kmail > > and akonadiconsole do not display any mail payloads anymore, stuck > > waiting https://bugs.kde.org/show_bug.cgi?id=343114 > > > > gone for good as well. > > > > [...] > > > > I think for the experience of the stable users it would be highly > > beneficial. > > Thanks for the encouraging information. > > I would highly appreciate any improvement of kmail2 compared as to it is > in jessie, especially through backports. Are there any plans to upload a > newer kmail2 into jessie-backports? > > kmail2 is currently unusable for me. A "Could not create collection" > error, maybe 305987, prevents kmail to do the initial sync of > disconnected imap. > > @Martin: Have you tried to build the latest kdepim as debian package (e.g. > by copying the debian folder of kdepim as in jessie)? Would be good to > have a (temporary) kmail2 solution w/o /usr/local installation. Which > packages did you rebuild? I presume akonadi, KDEPIMLIBS, KDEPIM-RUNTIME > and KDEPIM? (and not kdelibs soprano strigi nepomuk-core nepomuk-widgets > kactivities kde-runtime) Nope, I just compile the stuff myself, but I think Maxy made some 4.14.6/7 packages for KDEPIM related stuff already, its just not yet build. More and more of his new stuff arrives in experimental. It just takes time. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1789651.qBOImFe5gH@merkaba
Re: Newer KDEPIM for Jessie
Hello, Rainer Dorsch wrote: > are there any cons of having 4.14.7 in one of the next point releases and > KDE5 via backports for jessie? > > I understand that in general new upstream releases are not supposed to > pushed in in point releases. In this case it makes perfect sense for me > though and there are other examples which do it as well, e.g. chromium > pushes even bigger changes into point releases If webkit could get security support again, that would be a huge benefit! So basically KDE has the same justification as chromium. But I would be happy with a backport, too. best regards, Markus -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mj3528$v0f$1...@news.albasani.net
Re: Newer KDEPIM for Jessie
Hi, On Wednesday 13 May 2015 09:31:57 Lisandro Damián Nicanor Pérez Meyer wrote: > > I might try to build 4.14.7 packages for Jessie myself. I've been > > following the discussion for a while, and my understanding is > > that supplying 4.14.7 packages with jessie-backports would block > > the backports on KDE4, while someone might want to get KDE5 into > > it, which would then be impossible. > > Right. are there any cons of having 4.14.7 in one of the next point releases and KDE5 via backports for jessie? I understand that in general new upstream releases are not supposed to pushed in in point releases. In this case it makes perfect sense for me though and there are other examples which do it as well, e.g. chromium pushes even bigger changes into point releases rd@blackbox:~$ rmadison chromium|grep jessie|grep " amd64" chromium | 41.0.2272.118-1| jessie | amd64, i386 chromium | 42.0.2311.135-1~deb8u1 | jessie-p-u | amd64, i386 chromium | 42.0.2311.135-1~deb8u1 | jessie-security | amd64, i386 rd@blackbox:~$ Rainer -- Rainer Dorsch Lärchenstr. 6 72135 Dettenhausen 07157/734133
Re: Newer KDEPIM for Jessie
Hello, Jimmy Johnson wrote: > "KDE updated in Debian, here's how. In this guide we will see how to > have KDE in Debian constantly updated thanks to third-party repositories > KDEbian." > http://media-opensource.blogspot.com/2014/09/kde-updated-in-debian-heres- how.html The article is only talking about sid. So the repo does not really help with Jessie. best regards, Markus -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mj09eg$bnq$1...@news.albasani.net
Re: Newer KDEPIM for Jessie
Hey, well very interesting, what you found :) The kolab team for the desktop team has two members christian and me. And am the only one you is reponsible for debian builds. But I never known about thiis https://ftp.kolab.org :) Thanks for this information, I'll check internally why these 3.5.X versions are (still) available. > Okay, there's the sources and the DSC files etc... I guess my > search was too specific. And to be honest, really, I had no idea > searching for 4.13. :) Yeah not a very happy time to start a stable branch. And the kolab version is as you see still in development, that's why there is no blog post about it. > I guess so. :-) Searching for success stories, most of the > related postings mention KDE 4.14 and Akonadi 1.13 (which is also > true for the OP's initial writings in [2]). So I think I would > not have gone for Akonadi 1.12.42.1, which is what I can find on > OBS (following your link), if you had not mentioned it. The version number for kolab is not that exact what it inside it :P There are many more features added, that we need and also backported bugfixes + own developed ones etc. But well the version we will ship, will be supported for some years and is going to customors the upcomming months. So I think we will have a stable solution and it is a though to use our version, if you fit into the usecases (imap, kolab resource,... ). Regads, sandro signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Hi Sandro, Am Mittwoch 13 Mai 2015, 16:58:48 schrieb Sandro Knauß: > Hi, > > > > (No kidding: the Kolab people do package their own > > > enterprise > > > version of KDE, and they *do* ship KDEPIM 3.5.10 with > > > it...). > > well as one of the kdepim/kolab devs i can say: you are wrong! > > There is a enterprise version of kontact (4.13.0.X) [0]. As you > can see from the version number this is based on 4.13.0. Well > actually the feauteres+bugfixes will go directly into the > upcomming kf5 version. But for sure we don't ship kdepim 3.X > anymore. Hum, since I was out for deb packages for Jessie, some digging turned up [1], which I parsed as "Enterprise 3.5.10 (a.k.a E35), recently built for Jessie". I guess this then means "is available", as opposed to "gets shipped as enterprise version", right? At least, my searches did not turn up any deb packages for 4.14.7, other than that rogue PPA I found. > There are also packages built: > https://obs.kolabsys.com/project/show/Kontact:4.13:Development Okay, there's the sources and the DSC files etc... I guess my search was too specific. And to be honest, really, I had no idea searching for 4.13. :) > but because we release 4.13.0.X version, you have to make a > downgrade, what is a little bit tricky. I guess so. :-) Searching for success stories, most of the related postings mention KDE 4.14 and Akonadi 1.13 (which is also true for the OP's initial writings in [2]). So I think I would not have gone for Akonadi 1.12.42.1, which is what I can find on OBS (following your link), if you had not mentioned it. Considering the numerous bits & bytes I've gathered about the issue, I think I need to meditate and see how to proceed from here. > regards, > sandro Kind regards, Christian > [0] https://git.kolab.org/diffusion/KP/kdepim.git branch > kolab/integration/4.13.0 and you need also others packages: > kdepimlibs, kdepim-runtime, akonadi. [1] https://ftp.kolab.org/apt/releases/dists/jessie/experimental/binary-amd64/kdepim/ [2] https://lists.debian.org/debian-kde/2015/03/msg9.html -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Hi, > > (No kidding: the Kolab people do package their own enterprise > > version of KDE, and they *do* ship KDEPIM 3.5.10 with it...). well as one of the kdepim/kolab devs i can say: you are wrong! There is a enterprise version of kontact (4.13.0.X) [0]. As you can see from the version number this is based on 4.13.0. Well actually the feauteres+bugfixes will go directly into the upcomming kf5 version. But for sure we don't ship kdepim 3.X anymore. There are also packages built: https://obs.kolabsys.com/project/show/Kontact:4.13:Development but because we release 4.13.0.X version, you have to make a downgrade, what is a little bit tricky. regards, sandro [0] https://git.kolab.org/diffusion/KP/kdepim.git branch kolab/integration/4.13.0 and you need also others packages: kdepimlibs, kdepim-runtime, akonadi. -- Sandro Knauß Software Developer Kolab Systems AG Zürich, Switzerland e: kna...@kolabsystems.com t: +41 43 501 66 91 w: https://kolabsystems.com pgp: CE81539E Sandro Knauß signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
On Wednesday 13 May 2015 09:07:19 you wrote: > Hi Lisandro, > > Am Dienstag 12 Mai 2015, 17:26:33 schrieb Lisandro Damián Nicanor > > Pérez Meyer: > > Don't mix external packages. That's all. > > Well, that's good advice. However, the Debian team in all its > wisdom (no sarcasm!) decided to stuff the latest known-working > version of KMail (it is one of the last releases of the 1.x > series) into Wheezy. This provided for a working KDEPIM in > Wheezy, especially in the Kolab groupware environment, which I'm > running. > > I fully understand a stunt like this was not feasible for Jessie, > which I'm running on a few non-critical machines. But the sad > part is that for the production machines, I am pinned to Wheezy. > KDEPIM as packaged in Jessie is a vast improvement over the > sadness in 4.6/4.7, but there are still some bugs in > 4.14.1/4.14.2 which do prevent a production-class deployment of > it. (No kidding: the Kolab people do package their own enterprise > version of KDE, and they *do* ship KDEPIM 3.5.10 with it...). We know this and we had only two solutions: ship what was there (which we took) or not shipping KDEPIM at all. > I might try to build 4.14.7 packages for Jessie myself. I've been > following the discussion for a while, and my understanding is > that supplying 4.14.7 packages with jessie-backports would block > the backports on KDE4, while someone might want to get KDE5 into > it, which would then be impossible. Right. > Honestly, I was hoping for life to be easier, but then, nobody > promised. ;-) Right :) > PS.: Since you replied off-list, I did the same. =) My fault, I should stop using my phone to reply to mailing lists. Replying to the ML this time :) -- Moore's Law: The speed of processors will double every 18 months. Gate's Law: The speed of software will halve every 18 months. Mysticalfruit en Slashdot Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Am Mittwoch 13 Mai 2015, 08:35:00 schrieb Alejandro Exojo: > El Tuesday 12 May 2015, Jimmy Johnson escribió: > > Christian this is what I get after running the upgrade: > (...) > > > I was a little concerned with ruby being removed so I did not > > complete the upgrade. > > I think that you are missing the point. Christian's concern > wasn't how to do the installation, or if something might not > be 100% smooth. The point is that this is random software > found on the web, and if you install it without even knowing > the nickname of the person who did the packaging, you are > doing a huge leap of faith. You are installing plenty of > untrusted programs. Plus running maintainer scripts with root > permissions. Exactly. And this is why Alejandro advised to read the sources in order to ensure nobody messed with them. (To be really sure, one would still need to build the binary packages from the audited sources on a trusted machine - it is all about trust here.) Anyway, thanks again, guys. I guess I will not be doing that huge leap of faith, this time. :) Regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
El Tuesday 12 May 2015, Jimmy Johnson escribió: > Christian this is what I get after running the upgrade: (...) > I was a little concerned with ruby being removed so I did not complete > the upgrade. I think that you are missing the point. Christian's concern wasn't how to do the installation, or if something might not be 100% smooth. The point is that this is random software found on the web, and if you install it without even knowing the nickname of the person who did the packaging, you are doing a huge leap of faith. You are installing plenty of untrusted programs. Plus running maintainer scripts with root permissions. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505130835.00730@badopi.org
Re: Newer KDEPIM for Jessie
Hi Jimmy, Am Dienstag 12 Mai 2015, 07:53:12 schrieb Jimmy Johnson: > [...] > Christian this is what I get after running the upgrade: > jimmy# upgrade-system > 1) Updating package lists: > I: Package lists updated. > 2) Checking for upgradable packages: > I: Installing upgradable packages... > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... The following packages were > automatically installed and are no longer required: > [...] > plasma-scriptengine-ruby ruby-kde4 ruby-plasma ruby-qt4 >ruby-qt4-webkit > Use 'apt-get autoremove' to remove them. > Done > The following packages will be REMOVED: >libmarblewidget19* libnepomuk4* libnepomukquery4a* > libnepomukutils4* The following NEW packages will be > installed: >baloo-utils baloo4 libakonadi-socialutils4 libatasmart-bin > [...] > 191 upgraded, 12 newly installed, 4 to remove and 0 not > upgraded. Need to get 249 MB of archives. > After this operation, 14.4 MB of additional disk space will be > used. Do you want to continue? [Y/n] > > I was a little concerned with ruby being removed so I did not > complete the upgrade. Check the output of APT closely, it reveals what will actually happen: There's "The following packages will be REMOVED" section, which lists packages which will indeed be removed if you choose to continue the upgrade. Then, there's "The following packages were automatically installed and are no longer required", which lists packages to which, after the upgrade, no dependencies could be found. Under this category, some Ruby packages are listed. They will not be automatically removed. APT tells you how to get rid of them, if you choose to. Moreover, it is not Ruby itself, but some KDE packages with ruby stuff. These are no longer needed after the upgrade, either since the newer KDE does not make use of Ruby any more, or since there's some optional support for some stuff in KDE which needs Ruby, but which the package creator did not switch on. HTH, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
On 05/12/2015 07:34 AM, Christian Hilberg wrote: Hi Jimmy, Am Dienstag 12 Mai 2015, 07:02:04 schrieb Jimmy Johnson: On 05/12/2015 02:02 AM, Christian Hilberg wrote: Hi all, seeking for a less-painful-than-self-compile way to get KDEPIM 4.14.7 into Debian/Jessie (for much the same reasons as pointed out by the OP), I stumbled across http://kdebian.org/ppa/ Christian, this may help you: "KDE updated in Debian, here's how. In this guide we will see how to have KDE in Debian constantly updated thanks to third-party repositories KDEbian." http://media-opensource.blogspot.com/2014/09/kde-updated-in-deb ian-heres-how.html Thanks for the hint. This is one of the above-mentioned blogs linking to http://kdebian.org/. I'm still somewhat reluctant to use this repo, for no other reason than the creator of the PPA hiding. Undoubtedly, there may be good reasons to do so. But it gives me a hard time trusting in it. Sure, I can always read the sources, as has been suggested in another reply. :-) I did not do that for the packages I've got from Debian, because the fact that they do not even try to hide who they are makes me feel I can trust them. This is not the case for http://kdebian.org/. However, thanks dear Debian folks, thanks dear Debian community. You're great. Christian this is what I get after running the upgrade: jimmy# upgrade-system 1) Updating package lists: I: Package lists updated. 2) Checking for upgradable packages: I: Installing upgradable packages... Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... The following packages were automatically installed and are no longer required: libkactivities-models1 libnepomukcore4 libokularcore5 libparted-fs-resize0 libqtruby4shared2 libsmokekdecore4-3 libsmokekdeui4-3 libsmokekfile3 libsmokekhtml3 libsmokekio3 libsmokeknewstuff2-3 libsmokeknewstuff3-3 libsmokekparts3 libsmokektexteditor3 libsmokekutils3 libsmokeplasma3 libsmokeqtopengl4-3 nepomuk-core-data plasma-scriptengine-ruby ruby-kde4 ruby-plasma ruby-qt4 ruby-qt4-webkit Use 'apt-get autoremove' to remove them. Done The following packages will be REMOVED: libmarblewidget19* libnepomuk4* libnepomukquery4a* libnepomukutils4* The following NEW packages will be installed: baloo-utils baloo4 libakonadi-socialutils4 libatasmart-bin libjs-underscore libkfbapi1 libmarblewidget20 libmygpo-qt1 libnatspec0 libokularcore6 libqtcurve-utils1 libqzeitgeist1 The following packages will be upgraded: akonadi-backend-mysql akonadi-server amarok amarok-common amarok-utils ark dolphin freespacenotifier gtk2-engines-qtcurve gwenview kate-data katepart kcalc kde-base-artwork kde-baseapps kde-baseapps-bin kde-baseapps-data kde-plasma-desktop kde-runtime kde-runtime-data kde-style-oxygen kde-style-qtcurve kde-wallpapers kde-wallpapers-default kde-window-manager kde-workspace kde-workspace-bin kde-workspace-data kde-workspace-kgreet-plugins kde-workspace-randr kdegames-card-data kdelibs-bin kdelibs5-data kdelibs5-plugins kdepasswd kdepim-runtime kdepimlibs-kio-plugins kdf kdm kdoctools kfind kget khelpcenter4 kinfocenter kio-audiocd klipper kmenuedit kmix konq-plugins konqueror konqueror-nsplugins konsole konversation konversation-data kpartsplugin kpat ksysguard ksysguardd ksystemlog ktorrent ktorrent-data kwin-style-crystal kwin-style-qtcurve kwrite libakonadi-calendar4 libakonadi-contact4 libakonadi-kabc4 libakonadi-kcal4 libakonadi-kde4 libakonadi-kmime4 libakonadi-notes4 libakonadiprotocolinternals1 libastro1 libbaloocore4 libbaloofiles4 libbalooqueryparser4 libbaloowidgets4 libbalooxapian4 libdbusmenu-qt2 libgpgme++2 libkabc4 libkactivities-bin libkactivities6 libkalarmcal2 libkatepartinterfaces4 libkcal4 libkcalcore4 libkcalutils4 libkcddb4 libkcmutils4 libkcompactdisc4 libkdcraw-data libkdcraw23 libkde3support4 libkdeclarative5 libkdecorations4abi2 libkdecore5 libkdegames6abi1 libkdesu5 libkdeui5 libkdewebkit5 libkdnssd4 libkemoticons4 libkephal4abi1 libkexiv2-11 libkexiv2-data libkfile4 libkfilemetadata4 libkholidays4 libkhtml5 libkidletime4 libkimap4 libkio5 libkipi-data libkipi11 libkjsapi4 libkjsembed4 libkldap4 libkmbox4 libkmediaplayer4 libkmime4 libknewstuff2-4 libknewstuff3-4 libknotifyconfig4 libkntlm4 libkonq-common libkonq5-templates libkonq5abi1 libkonqsidebarplugin4a libkparts4 libkpimidentities4 libkpimtextedit4 libkpimutils4 libkprintutils4 libkpty4 libkresources4 libkrosscore4 libkscreensaver5 libksgrd4 libksignalplotter4 libktexteditor4 libkunitconversion4 libkutils4 libkwineffects1abi5 libkwinglesutils1 libkwinglutils1abi2 libkworkspace4abi2 libkxmlrpcclient4 libmailtransport4 libmicroblog4 libphonon4 libplasma-geolocation-interface4 libplasma3 libplasmaclock4abi4 libplasmagenericshell4 libpolkit-qt-1-1 libprocesscore4abi1 libprocessui4a libqca2 libqgpgme1 libqmobipocket1 libsolid4 libsyndication4 libtaskmanager4abi4 libth
Re: Newer KDEPIM for Jessie
Hi Jimmy, Am Dienstag 12 Mai 2015, 07:02:04 schrieb Jimmy Johnson: > On 05/12/2015 02:02 AM, Christian Hilberg wrote: > > Hi all, > > > > seeking for a less-painful-than-self-compile way to get > > KDEPIM > > 4.14.7 into Debian/Jessie (for much the same reasons as > > pointed out by the OP), I stumbled across > > > > http://kdebian.org/ppa/ > > > > While this repo seems to have all of the packages I'm after, > > I do not really know to make heads or tails of it. > > > > There site does not mention any maintainer. The owner of the > > domain hides behind some privacy service. There seems to be > > some connection to a live.ru account, but that does not > > necessarily mean anything. > > > > Other than being referred to from some blog posts, I did not > > find any information as to whether or not this PPA can be > > trusted. I for one do *not* trust, because of missing > > information about who's behind that PPA, but maybe there is > > some info about this site I missed? > > > > Anyway, the DSC files from that repo might be worth a look > > when trying to set up some trustworthy alternative to it, > > which would surely be of a great relief to Debian/Jessie > > KDEPIM users. > Christian, this may help you: > "KDE updated in Debian, here's how. In this guide we will see > how to have KDE in Debian constantly updated thanks to > third-party repositories KDEbian." > http://media-opensource.blogspot.com/2014/09/kde-updated-in-deb > ian-heres-how.html Thanks for the hint. This is one of the above-mentioned blogs linking to http://kdebian.org/. I'm still somewhat reluctant to use this repo, for no other reason than the creator of the PPA hiding. Undoubtedly, there may be good reasons to do so. But it gives me a hard time trusting in it. Sure, I can always read the sources, as has been suggested in another reply. :-) I did not do that for the packages I've got from Debian, because the fact that they do not even try to hide who they are makes me feel I can trust them. This is not the case for http://kdebian.org/. However, thanks dear Debian folks, thanks dear Debian community. You're great. Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
On 05/12/2015 02:02 AM, Christian Hilberg wrote: Hi all, seeking for a less-painful-than-self-compile way to get KDEPIM 4.14.7 into Debian/Jessie (for much the same reasons as pointed out by the OP), I stumbled across http://kdebian.org/ppa/ While this repo seems to have all of the packages I'm after, I do not really know to make heads or tails of it. There site does not mention any maintainer. The owner of the domain hides behind some privacy service. There seems to be some connection to a live.ru account, but that does not necessarily mean anything. Other than being referred to from some blog posts, I did not find any information as to whether or not this PPA can be trusted. I for one do *not* trust, because of missing information about who's behind that PPA, but maybe there is some info about this site I missed? Anyway, the DSC files from that repo might be worth a look when trying to set up some trustworthy alternative to it, which would surely be of a great relief to Debian/Jessie KDEPIM users. Christian, this may help you: "KDE updated in Debian, here's how. In this guide we will see how to have KDE in Debian constantly updated thanks to third-party repositories KDEbian." http://media-opensource.blogspot.com/2014/09/kde-updated-in-debian-heres-how.html -- Jimmy Johnson Debian Sid - KDE 4.14.2 - AMD64 - EXT4 at sda14 Registered Linux User #380263 -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555207dc.9000...@gmail.com
Re: Newer KDEPIM for Jessie
El Tuesday 12 May 2015, Christian Hilberg escribió: > Hi all, > > seeking for a less-painful-than-self-compile way to get KDEPIM > 4.14.7 into Debian/Jessie (for much the same reasons as pointed > out by the OP), I stumbled across > > http://kdebian.org/ppa/ > > While this repo seems to have all of the packages I'm after, I do > not really know to make heads or tails of it. > > There site does not mention any maintainer. The owner of the > domain hides behind some privacy service. There seems to be some > connection to a live.ru account, but that does not necessarily > mean anything. Opened the akonadi package (first one alphabetically), and the author of the latest changelog entry is Nikolay Romanov > Other than being referred to from some blog posts, I did not find > any information as to whether or not this PPA can be trusted. I > for one do *not* trust, because of missing information about > who's behind that PPA, but maybe there is some info about this > site I missed? The sources. :) > Anyway, the DSC files from that repo might be worth a look when > trying to set up some trustworthy alternative to it, which would > surely be of a great relief to Debian/Jessie KDEPIM users. I haven't inspected all of them, just akonadi. But for it, there are sources (and I haven't inspected que quality). That doesn't mean the work done for those packages can be reused. Making a quick and dirty package for yourself can be done in minutes if for your use case some things are irrelevant. But that is not normally the case of official packages. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505121514.20963@badopi.org
Re: Re: Newer KDEPIM for Jessie
Hi all, seeking for a less-painful-than-self-compile way to get KDEPIM 4.14.7 into Debian/Jessie (for much the same reasons as pointed out by the OP), I stumbled across http://kdebian.org/ppa/ While this repo seems to have all of the packages I'm after, I do not really know to make heads or tails of it. There site does not mention any maintainer. The owner of the domain hides behind some privacy service. There seems to be some connection to a live.ru account, but that does not necessarily mean anything. Other than being referred to from some blog posts, I did not find any information as to whether or not this PPA can be trusted. I for one do *not* trust, because of missing information about who's behind that PPA, but maybe there is some info about this site I missed? Anyway, the DSC files from that repo might be worth a look when trying to set up some trustworthy alternative to it, which would surely be of a great relief to Debian/Jessie KDEPIM users. Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Hello, Martin Steigerwald wrote: > I think it would be good to have a newer KDEPIM + Akonadi into Jessie. > > Why? The current akonadi 1.13 master branch together with kdepim, > kdepimlibs, kdepim-runtime from 4.14 branches (as of 4.14.6/7) here runs > better than ever before, including my most annoying bug > > [Akonadi] [Bug 343114] gets stuck on one request that times out, kmail and > akonadiconsole do not display any mail payloads anymore, stuck waiting > https://bugs.kde.org/show_bug.cgi?id=343114 > > gone for good as well. > > [...] > > I think for the experience of the stable users it would be highly > beneficial. Thanks for the encouraging information. I would highly appreciate any improvement of kmail2 compared as to it is in jessie, especially through backports. Are there any plans to upload a newer kmail2 into jessie-backports? kmail2 is currently unusable for me. A "Could not create collection" error, maybe 305987, prevents kmail to do the initial sync of disconnected imap. @Martin: Have you tried to build the latest kdepim as debian package (e.g. by copying the debian folder of kdepim as in jessie)? Would be good to have a (temporary) kmail2 solution w/o /usr/local installation. Which packages did you rebuild? I presume akonadi, KDEPIMLIBS, KDEPIM-RUNTIME and KDEPIM? (and not kdelibs soprano strigi nepomuk-core nepomuk-widgets kactivities kde-runtime) best regards, Markus -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mi5rt0$9sn$1...@news.albasani.net
Re: Newer KDEPIM for Jessie
Am Samstag, 18. April 2015, 14:25:35 schrieb Sandro Knauß:
> Hey,
>
> > I do not want a separate dev environment, but I want to compile
> > selected components of KDE for production use – and maybe also some
> > developing some time. So I want Alt-F2 (or with Plasma 5 Alt-Space)
> > to pick up my self- compiled kmail, while everything else from
> > packaged KDE still working as before, so I do not have to compile all
> > of KDE just to try out a few components in a newer version.
>
> yeah it is little bit another focus with separating data, but other than
> that the focus is the same. Running apps on top of installed kde/kdepim
> packages.
>
> The only thing I wanted to point out, that there are more ENV to adjust
> things and you need them :) It also takes a while I found, that this
> and that small thing is loaded incorrectly (desktop files, other data).
> If it works for you at the moment great :) I think because 4.14 is only
> in in bug fixing mode, not so much is changed, and a more minimal
> appoch also works.
> I also started with a more minimal approch and than things got broken,
> so I adjusted the scripts...
Ah, I see, as you wrote already, it is
#Sets all kde related variables (and also resets them"
function setKDEEnv {
envName="$1"
setEnv $envName
export KDEDIR="$GLOBAL_INSTALL_DIR/$envName"
export KDEDIRS=$KDEDIR
export KDEHOME="$GLOBAL_HOME_DIR/.$envName"
export KDETMP="$GLOBAL_TMP_DIR/$envName-$USER"
export KDEVARTMP="$GLOBAL_VARTMP_DIR/$envName-$USER"
export XDG_DATA_DIRS="$GLOBAL_INSTALL_DIR/$envName/share"
mkdir -p $KDETMP
mkdir -p $KDEVARTMP
export QT_PLUGIN_PATH=$KDEDIR/lib/kde4/plugins:
$KDEDIR/lib/plugins/sqldrivers
export
KDE4_AUTH_POLICY_FILES_INSTALL_DIR=$KDEDIR/usr/share/polkit-1/actions
export XDG_CONFIG_HOME=$KDEHOME/.config
export XDG_DATA_HOME=$KDEHOME/.local/share
}
you talk about.
And well… I see mostly that XDG stuff missing? But, no… they just point to
locations I want to keep.
Frankly I don´t see what is missing. Except maybe
"$KDEDIR/lib/plugins/sqldrivers" for QT_PLUGIN_PATH.
I do not want to change config or tmp paths.
Okay, and maybe:
export
KDE4_AUTH_POLICY_FILES_INSTALL_DIR=$KDEDIR/usr/share/polkit-1/actions
but I do not see anything in there, that would affect KDEPIM, except for
some nepomuk stuff that is deprecated I bet.
So, I just still do not get, what I am missing.
$XDG_DATA_DIRS maybe? For icons? Hmmm, okay and desktop files and default
config files. I think for my slight version change, all that does not really
matter, but it may be good to include that for completeness.
I just want to know exactly what is missing for my usecase to add *just*
that. :)
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
signature.asc
Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Hey, > I do not want a separate dev environment, but I want to compile selected > components of KDE for production use – and maybe also some developing some > time. So I want Alt-F2 (or with Plasma 5 Alt-Space) to pick up my self- > compiled kmail, while everything else from packaged KDE still working as > before, so I do not have to compile all of KDE just to try out a few > components in a newer version. yeah it is little bit another focus with separating data, but other than that the focus is the same. Running apps on top of installed kde/kdepim packages. The only thing I wanted to point out, that there are more ENV to adjust things and you need them :) It also takes a while I found, that this and that small thing is loaded incorrectly (desktop files, other data). If it works for you at the moment great :) I think because 4.14 is only in in bug fixing mode, not so much is changed, and a more minimal appoch also works. I also started with a more minimal approch and than things got broken, so I adjusted the scripts... Regards, sandro signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Am Samstag, 18. April 2015, 11:54:46 schrieb Martin Steigerwald: > > after running the script you have to do something like: > > > > > > setKDEEnv master > > > > > > > > Okay it additionally also makes sure that you have different home dirs > > etc. > > > > > > > > In your case the folling env variables should be enough to set: > > > > > > XDG_DATA_DIRS - needed for akonadi resources > > LD_LIBRARY_PATH - to find libs > > KDEDIRS > > KDEDIR > > KDEHOME > > PATH > > QT_PLUGIN_PATH > > I have seen such scripts, but they do a lot, a lot more than I usually > want, and I think the version from /usr/local is used with my minimal > script already. > > I don´t start with a full blown vim configuration either. But just > change what I need. > > And as to far as I have seen, this minimal approach just works for me: Well okay, I think its just different goals. I do not want a separate dev environment, but I want to compile selected components of KDE for production use – and maybe also some developing some time. So I want Alt-F2 (or with Plasma 5 Alt-Space) to pick up my self- compiled kmail, while everything else from packaged KDE still working as before, so I do not have to compile all of KDE just to try out a few components in a newer version. Thats why I placed the script in ~/.kde/env and thats why I want it not to mess more than is needed. For someone who wants to have a different development enviroment and only start applications from a certain shell from it and also use a separate config, more is needed. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Newer KDEPIM for Jessie
Am Dienstag, 14. April 2015, 13:17:56 schrieb Sandro Knauß:
> Hi,
>
> > I use default /usr/local location and do as little customization of
> > the
> > build process as possible. Then I tell my KDE sessions to use
> > /usr/local
> > stuff as well like this:
> This does not touch all relevant env variables (see attached script). It
> is configured to have
> ~/kde/src//kdepim - source
> ~/kde/build//kdepim - build
> ~/kde/inst/ - install dir
I just have ~/KDE/Dev, git clone what I need, do mkdir build, cmake ..,
make -j4, sudo make install on what I need. I know all manual, but
> after running the script you have to do something like:
>
> setKDEEnv master
>
> Okay it additionally also makes sure that you have different home dirs
> etc.
>
> In your case the folling env variables should be enough to set:
>
> XDG_DATA_DIRS - needed for akonadi resources
> LD_LIBRARY_PATH - to find libs
> KDEDIRS
> KDEDIR
> KDEHOME
> PATH
> QT_PLUGIN_PATH
I have seen such scripts, but they do a lot, a lot more than I usually
want, and I think the version from /usr/local is used with my minimal
script already.
I don´t start with a full blown vim configuration either. But just change
what I need.
And as to far as I have seen, this minimal approach just works for me:
martin@merkaba:~> akonadictl status
Akonadi Control: running
Akonadi Server: running
search paths: ("/usr/local/lib/kde4",
"/home/martin/.kde/lib/kde4/plugins/", "/usr/local/lib/kde4/plugins/",
"/usr/lib/kde4/plugins/", "/usr/local/lib/plugins/", "/usr/lib/x86_64-
linux-gnu/qt4/plugins", "/usr/local/bin", "/usr/local/lib/kde4/plugins",
"/usr/lib/kde4/plugins", "/usr/local/lib/plugins",
"/home/martin/.kde/lib/kde4/", "/usr/local/lib/kde4/", "/usr/lib/kde4/")
[…]
martin@merkaba:~> ps -eo cmd | grep akonadi | cut -c1-60
/usr/bin/akonaditray -session 10cec7d36b0001360492129002
/usr/local/bin/akonadi_control
akonadiserver
/usr/sbin/mysqld --defaults-file=/home/martin/.local/share/a
/usr/local/bin/akonadi_agent_launcher akonadi_akonotes_resou
/usr/local/bin/akonadi_agent_launcher akonadi_akonotes_resou
/usr/local/bin/akonadi_archivemail_agent --identifier akonad
/usr/bin/akonadi_baloo_indexer --identifier akonadi_baloo_in
/usr/local/bin/akonadi_birthdays_resource --identifier akona
/usr/local/bin/akonadi_agent_launcher akonadi_contacts_resou
/usr/local/bin/akonadi_followupreminder_agent --identifier a
/usr/local/bin/akonadi_icaldir_resource --identifier akonadi
/usr/local/bin/akonadi_imap_resource --identifier akonadi_im
/usr/local/bin/akonadi_agent_launcher akonadi_maildir_resour
/usr/local/bin/akonadi_maildispatcher_agent --identifier ako
/usr/local/bin/akonadi_mailfilter_agent --identifier akonadi
/usr/local/bin/akonadi_migration_agent --identifier akonadi_
/usr/local/bin/akonadi_newmailnotifier_agent --identifier ak
/usr/local/bin/akonadi_notes_agent --identifier akonadi_note
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_pop3_resource --identifier akonadi_po
/usr/local/bin/akonadi_sendlater_agent --identifier akonadi_
All local. Except Baloo, which I do not build at the moment, but use the
packaged one. And well akonaditray, but it comes from kdepim-runtime,
hmmm, okay, don´t know why it doesn´t pick it up, ok, thats one omission.
merkaba:~> which -a akonaditray
/usr/local/bin/akonaditray
/usr/bin/akonaditray
May be do it it being started from Plasma and Plasma needing another part?
I don´t care that much for it tough, cause I don´t need it newer than
whats packaged.
martin@merkaba:~> ldd /usr/local/bin/kmail | tr -d "\t" | cut -c 1-70 |
head -20
linux-vdso.so.1 (0x7ffe741fc000)
libkdeui.so.5 => /usr/lib/libkdeui.so.5 (0x7f2092143000)
libkdecore.so.5 => /usr/lib/libkdecore.so.5 (0x7f2091c54000)
libkontactinterface.so.4 => /usr/local/lib/libkontactinterface.so.4 (0
libkmailprivate.so.4 => /usr/local/lib/libkmailprivate.so.4 (0x7f2
libkdepim.so.4 => /usr/local/lib/libkdepim.so.4 (0x7f20912cd000)
libQtScript.so.4 => /usr/lib/x86_64-linux-gnu/libQtScript.so.4 (0x
libkldap.so.4 => /usr/local/lib/libkldap.so.4 (0x7f2090bdd000)
libkpimidentities.so.4 => /usr/local/lib/libkpimidentities.so.4 (0x000
libkpimtextedit.so.4 => /usr/local/lib/libkpimtextedit.so.4 (0x7f2
libakonadi-contact.so.4 => /usr/local/lib/libakonadi-contact.so.4 (0x0
libkpimutils.so.4 => /usr/local/lib/libkpimutils.so.4 (0x7f2090272
libkcalcore.so.4 => /usr/local/lib/libkcalcore.so.4 (0x7f208ffa200
libphonon.so.4 => /usr/lib/x86_64-linux-gnu/libphonon.so.4 (0x7f20
libkabc.so.4 => /usr/local/lib/libkabc.so.4 (0x7f208fa74000)
libkresources.so.4 => /usr/local/lib/libkresources.so.4 (0x7f208f8
libakonadi-kde.so.4 => /usr/local/lib/libakonadi-kde.so.4
Re: Newer KDEPIM for Jessie
Hi,
> I use default /usr/local location and do as little customization of the
> build process as possible. Then I tell my KDE sessions to use /usr/local
> stuff as well like this:
This does not touch all relevant env variables (see attached script). It is
configured to have
~/kde/src//kdepim - source
~/kde/build//kdepim - build
~/kde/inst/ - install dir
after running the script you have to do something like:
setKDEEnv master
Okay it additionally also makes sure that you have different home dirs etc.
In your case the folling env variables should be enough to set:
XDG_DATA_DIRS - needed for akonadi resources
LD_LIBRARY_PATH - to find libs
KDEDIRS
KDEDIR
KDEHOME
PATH
QT_PLUGIN_PATH
> > If somebody would spend the work to provide patches for Jessie, would
> > there be a way to continuously update the packages in the Debian
> > infrastructure? Or would that only work with an external repo?
It can't be done inside Jessie main repo, because debian does allow updates of
packages only for security fixes or fatal issues. Well I may be arguable, that
there are fatal issues, but the work is not worth that need to be done to
extratct the patches. The easier approch is to upload the newer packages to
backports.debian.org. But this also is work, that needs to be done, so if you
step into that, feel welcome! Keep in mind you have to support packages that
are in backports till the end of jessie, so this is not an fire & forget.
Regards,
sandro
--
#! /bin/bash
## A script to setup some needed variables and functions for KDE 4
development.
# Otheng kde3 seems to be in /usr/bin so /usr/sbin seems okay to leave in.
#export PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Qt
# only set Qt related variables if you compiled Qt on your own
# (which is discouraged). if you use the distro provided Qt, skip
# this section. Comment it if necessary.
#export QTDIR=$HOME/qt4
#prepend PATH $QTDIR/bin
#prepend LD_LIBRARY_PATH $QTDIR/lib
#prepend PKG_CONFIG_PATH $QTDIR/lib/pkgconfig
export BASEDIR=/home/kdetest/kde
export GLOBAL_BUILD_DIR=$BASEDIR/build
export GLOBAL_INSTALL_DIR=$BASEDIR/inst
export GLOBAL_HOME_DIR=$BASEDIR/home
export GLOBAL_TMP_DIR=/tmp
export GLOBAL_VARTMP_DIR=/var/tmp
export KDE_SRC=$BASEDIR/src
if [ -z "$ORIGINAL_PATH" ]; then
export ORIGINAL_PATH=$PATH
fi
# KDE
export KDESYCOCA=/var/tmp/kdesycoca-custom
# XDG
unset XDG_DATA_DIRS # to avoid seeing kde3 files from /usr
unset XDG_CONFIG_DIRS
# Use makeobj instead of make, to automatically switch to the build dir.
# If you don't have makeobj, install the package named kdesdk-scripts or
# kdesdk, or check out kdesdk/scripts from svn.
alias make='nice makeobj -j3'
function printKDEenv {
echo "KDEHOME: $KDEHOME"
echo "KDEDIR: $KDEDIR"
echo "KDEDIRS: $KDEDIRS"
echo "BUILD_DIR: $BUILD_DIR"
echo "PATH: $PATH"
echo "LD_LIBRARY_PATH: $LD_LIBRARY_PATH"
echo "PKG_CONFIG_PATH: $PKG_CONFIG_PATH"
echo "QT_PLUGIN_PATH: $QT_PLUGIN_PATH"
echo "CMAKE_PREFIX_PATH: $CMAKE_PREFIX_PATH"
echo "CMAKE_LIBRARY_PATH: $CMAKE_LIBRARY_PATH"
echo "CMAKE_INCLUDE_PATH: $CMAKE_INCLUDE_PATH"
echo "CMAKE_INSTALL_PREFIX: $CMAKE_INSTALL_PREFIX"
echo "XDG_DATA_DIRS: $XDG_DATA_DIRS"
}
function resetCMakePaths {
unset CMAKE_PREFIX_PATH
unset CMAKE_LIBRARY_PATH
unset CMAKE_INCLUDE_PATH
unset CMAKE_MODULE_PATH
unset CMAKE_INSTALL_PREFIX
}
function setCMakePrefixPath {
prefixPath="$1"
export CMAKE_PREFIX_PATH=$prefixPath
export CMAKE_LIBRARY_PATH=$prefixPath/lib:$CMAKE_LIBRARY_PATH
export CMAKE_INCLUDE_PATH=$prefixPath/include:$prefixPath/include/KDE:
$CMAKE_INCLUDE_PATH
export CMAKE_MODULE_PATH=$prefixPath/share/apps/cmake/modules:
$CMAKE_MODULE_PATH
export CMAKE_INSTALL_PREFIX=$prefixPath
}
#Sets all kde related variables (and also resets them"
function setKDEEnv {
envName="$1"
setEnv $envName
export KDEDIR="$GLOBAL_INSTALL_DIR/$envName"
export KDEDIRS=$KDEDIR
export KDEHOME="$GLOBAL_HOME_DIR/.$envName"
export KDETMP="$GLOBAL_TMP_DIR/$envName-$USER"
export KDEVARTMP="$GLOBAL_VARTMP_DIR/$envName-$USER"
export XDG_DATA_DIRS="$GLOBAL_INSTALL_DIR/$envName/share"
mkdir -p $KDETMP
mkdir -p $KDEVARTMP
export QT_PLUGIN_PATH=$KDEDIR/lib/kde4/plugins:
$KDEDIR/lib/plugins/sqldrivers
export
KDE4_AUTH_POLICY_FILES_INSTALL_DIR=$KDEDIR/usr/share/polkit-1/actions
export XDG_CONFIG_HOME=$KDEHOME/.config
export XDG_DATA_HOME=$KDEHOME/.local/share
}
#Sets all kde related variables (and also resets them"
function setEnv {
envName="$1"
echo "Setting env $envName"
export TARGETDIR="$GLOBAL_INSTALL_DIR/$envName"
export PATH=$TARGETDIR/bin:$ORIGINAL_PATH
export LD_LIBRARY_PATH=$TARGETDIR/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=$TARGETDIR/lib/pkgconfig:$PKG_CONFIG_PATH
export QT_PLUGIN_PATH=$TARGETDIR/lib/kde4:$TARGETDIR/lib/kde4/plugins
setCMakePrefixPath "$TARGETDIR"
export SRC_DIR=$KDE_SRC
Re: Newer KDEPIM for Jessie
Am Donnerstag, 26. März 2015, 14:49:35 schrieb Rainer Dorsch: > Hi Martin, Hi Rainer, > thanks for sharing your positive experience. I agree, getting these kind > of KDEPIM fixes through backports would be a great enhancement for > Jessie KDE users. > > Do you compile to /opt or do you build proper Debian packages of the > upstream akonadi and kdepim? I use default /usr/local location and do as little customization of the build process as possible. Then I tell my KDE sessions to use /usr/local stuff as well like this: martin@merkaba:~> cat .kde/env/kdedirs.sh #!/bin/bash if [ -z $KDEDIRS ]; then export KDEDIRS="/usr/local/" else export KDEDIRS="/usr/local/:$KDEDIRS" fi if [ -z $QT_PLUGIN_PATH ]; then export QT_PLUGIN_PATH="/usr/local/lib/kde4" else export QT_PLUGIN_PATH="/usr/local/lib/kde4:$QT_PLUGIN_PATH" fi > Though having the backports path after the Jessie release open for > additional fixes (or security updates?) would mean that no newer > packages can go into sid. > > > If somebody would spend the work to provide patches for Jessie, would > there be a way to continuously update the packages in the Debian > infrastructure? Or would that only work with an external repo? I have no idea. I use sid, so for me personally it isn´t a concern. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2548757.gZWE8omAk3@merkaba
Re: Newer KDEPIM for Jessie
Hi Martin, thanks for sharing your positive experience. I agree, getting these kind of KDEPIM fixes through backports would be a great enhancement for Jessie KDE users. Do you compile to /opt or do you build proper Debian packages of the upstream akonadi and kdepim? Though having the backports path after the Jessie release open for additional fixes (or security updates?) would mean that no newer packages can go into sid. If somebody would spend the work to provide patches for Jessie, would there be a way to continuously update the packages in the Debian infrastructure? Or would that only work with an external repo? Thanks again Rainer On Thursday 26 March 2015 13:06:40 Martin Steigerwald wrote: > Hi! > > I think it would be good to have a newer KDEPIM + Akonadi into Jessie. > > Why? The current akonadi 1.13 master branch together with kdepim, > kdepimlibs, kdepim-runtime from 4.14 branches (as of 4.14.6/7) here runs > better than *ever* before, including my most annoying bug > > [Akonadi] [Bug 343114] gets stuck on one request that times out, kmail and > akonadiconsole do not display any mail payloads anymore, stuck waiting > https://bugs.kde.org/show_bug.cgi?id=343114 > > gone for good as well. > > For the first time in years (!) I didn´t have to restart either Akonadi or > KMail just to keep it running with *both* my private huge POP3 and smaller > IMAP and my huge work IMAP setup with crappy IMAP server (Exchange) for a > week or so (okay, with using the work IMAP for as most as long as a work > day without logout/login). That said, I have no idea whatsoever what > commit may contain the fix. But as the mentioned branches are for fixes > anyway, they shouldn´t contain any major breakage. I didn´t see any > regression at all so far, and I think I use quite a subset of KDEPIM > functionality. > > Also due to the MySQL performance improvements, the load on the machine is > way lower. Not perfect yet, but *much* better. > > Compared with current akonadi 1.13 and kdepim 4.14.2 versions currently in > sid, this is a *huge* improvement. > > > I personally will just self-compile things until newer stuff is available > via unstable and experimental. But for all the users of KDEPIM in stable > it would be highly beneficial to have the newer versions in the archive. > And yes, I know, likely the only way at this late stage would be to > retrofit them via backports. > > I think for the experience of the stable users it would be highly > beneficial. > > Thanks, -- Rainer Dorsch http://bokomoko.de/
Re: Newer KDEPIM for Jessie
On Thursday 26 March 2015 13:06:40 Martin Steigerwald wrote: > Hi! > > I think it would be good to have a newer KDEPIM + Akonadi into Jessie. > > Why? The current akonadi 1.13 master branch together with kdepim, > kdepimlibs, kdepim-runtime from 4.14 branches (as of 4.14.6/7) here runs > better than *ever* before, including my most annoying bug While I agree it would be cool, it's sadly impossible right now. We are in deep freeze. The only thing we can try to do is backport whatever patches are needed in a point release, as long as they are not so intrusive. [snip] > Also due to the MySQL performance improvements, the load on the machine is > way lower. Not perfect yet, but *much* better. > > Compared with current akonadi 1.13 and kdepim 4.14.2 versions currently in > sid, this is a *huge* improvement. That's really really good to read :D -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
