Dropping kdepim-apps-libs from release service 20.12
Hi all, please remove kdepim-apps-libs from the release service 20.12 - the code there has been removed or dissolved to more appropriate PIM repositories and as such I asked the sysadmins to move the repository to unmaintained and archive it. Thanks, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: KDE Applications 19.04.3 packages available for packagers
On Friday, 12 July 2019 14:26:42 CEST Jonathan Riddell wrote: > A moved socket for akonadi's mysqld access broke akonadi on our setup > because of apparmor rules. > > https://packaging.neon.kde.org/kde/akonadi.git/commit/?h=Neon/release-lts > > This shouldn't be done in a bugfix release Sorry about this, I had no idea this change would affect Apparmor. This was a bugfix for MacOS where the socket path was simply too long. At the same time, you cannot assume all maintainers know about all such 3rd party software and know what changes might or might not affect it. Maybe if the Apparmor config file for Akonadi was in the Akonadi repo and I knew about it, it would hit a bell in my head while doing the codereview for this change. But this way, even if I knew Apparmor would be affected by this change, I have no clue where to look for...whatever I have to look for in order to do or ask for the adjustments. IMO since this is something you do in your packaging and is outside of upstream control, it's something you should check before pushing the package to your users, not blaming upstream for breaking your distro "patches". - Dan > > Jonathan > > On Tue, 9 Jul 2019 at 01:58, Christoph Feck wrote: > > Hello packagers, > > > > *.tar.xz files are available at the usual "stable" location. > > > > Please report issues, release is Thursday. > > > > REVISIONS_AND_HASHES at https://phabricator.kde.org/P428 > > > > Preliminary changelog v19.04.2..v19.04.3: > > > > https://www.kde.org/announcements/fulllog_applications-aether.php?version= > > 19.04.3 > > > > My public key at > > > > http://pgp.mit.edu/pks/lookup?op=get=0xF23275E4BF10AFC1DF6914A6DBD2 > > CE893E2D1C87 > > > > Thanks, > > Christoph Feck -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Possible issue with the dependency freeze for 19.04
On Thursday, March 28, 2019 6:51:49 PM CET Heiko Becker wrote: > Hi, > > I wondered why korganizer and mailcommon suddenly moved from phonon to > qtmultimedia and I tried to get some information about it (Turns out the > commit messages don't help one bit, e.g. "Clean up"). Anyway, this happened > on 21 March, a week after dependency freeze and it was suggested to me to > bring this to the attention of this mailing list. I have reverted the change in both KOrganizer and mailcommon now. > Cheers, > Heiko > > [1] https://community.kde.org/Schedules/Applications/19.04_Release_Schedule -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Possible issue with the dependency freeze for 19.04
On Friday, March 29, 2019 12:34:14 PM CET laurent Montel wrote: > Le vendredi 29 mars 2019, 12:20:45 CET Daniel Vrátil a écrit : > > On Friday, March 29, 2019 11:42:03 AM CET laurent Montel wrote: > > > Le vendredi 29 mars 2019, 10:43:57 CET Daniel Vrátil a écrit : > > > > On Thursday, March 28, 2019 6:51:49 PM CET Heiko Becker wrote: > > > > > Hi, > > > > > > > > > > I wondered why korganizer and mailcommon suddenly moved from phonon > > > > > to > > > > > qtmultimedia and I tried to get some information about it (Turns out > > > > > the > > > > > commit messages don't help one bit, e.g. "Clean up"). Anyway, this > > > > > happened > > > > > on 21 March, a week after dependency freeze and it was suggested to > > > > > me > > > > > to > > > > > bring this to the attention of this mailing list. > > > > > > > > I think we should revert this - QtMultimedia is not integrated with > > > > KDE > > > > the > > > > way Phonon is - we should use Phonon in KDE apps to provide consistent > > > > experience. > > > > > > > > Laurent, what was the motivation for the switch? > > > > > > Just for reducing extra lib. > > > Just for playing a song (when a message arrives) I don't see why we need > > > to > > > add this dependency. > > > > You literally only replaced one dependency by another. Absolutely nothing > > was gained herethe entire PIM already depends on Phonon, > > Just the 2 area which I ported. > Not other phonon references. > > > everything in > > KDE depends on Phonon, all you achieved by this is, that the app no longer > > follows user's KDE-wide audio settings. > > Ok so you can revert it. Also in the future, please be more descriptive in the commit messages, "Clean up" is so generic it could mean anything. Why not say "Switch from Phonon to QtMultimedia"? Thanks, Dan > > > > > Dan > > > > > > > > > Cheers, > > > > > Heiko > > > > > > > > > > [1] > > > > > https://community.kde.org/Schedules/Applications/19.04_Release_Sched > > > > > ul > > > > > e -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Possible issue with the dependency freeze for 19.04
On Friday, March 29, 2019 11:42:03 AM CET laurent Montel wrote: > Le vendredi 29 mars 2019, 10:43:57 CET Daniel Vrátil a écrit : > > On Thursday, March 28, 2019 6:51:49 PM CET Heiko Becker wrote: > > > Hi, > > > > > > I wondered why korganizer and mailcommon suddenly moved from phonon to > > > qtmultimedia and I tried to get some information about it (Turns out the > > > commit messages don't help one bit, e.g. "Clean up"). Anyway, this > > > happened > > > on 21 March, a week after dependency freeze and it was suggested to me > > > to > > > bring this to the attention of this mailing list. > > > > I think we should revert this - QtMultimedia is not integrated with KDE > > the > > way Phonon is - we should use Phonon in KDE apps to provide consistent > > experience. > > > > Laurent, what was the motivation for the switch? > > Just for reducing extra lib. > Just for playing a song (when a message arrives) I don't see why we need to > add this dependency. You literally only replaced one dependency by another. Absolutely nothing was gained herethe entire PIM already depends on Phonon, everything in KDE depends on Phonon, all you achieved by this is, that the app no longer follows user's KDE-wide audio settings. > > > Dan > > > > > Cheers, > > > Heiko > > > > > > [1] > > > https://community.kde.org/Schedules/Applications/19.04_Release_Schedule -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Possible issue with the dependency freeze for 19.04
On Thursday, March 28, 2019 6:51:49 PM CET Heiko Becker wrote: > Hi, > > I wondered why korganizer and mailcommon suddenly moved from phonon to > qtmultimedia and I tried to get some information about it (Turns out the > commit messages don't help one bit, e.g. "Clean up"). Anyway, this happened > on 21 March, a week after dependency freeze and it was suggested to me to > bring this to the attention of this mailing list. I think we should revert this - QtMultimedia is not integrated with KDE the way Phonon is - we should use Phonon in KDE apps to provide consistent experience. Laurent, what was the motivation for the switch? Dan > > Cheers, > Heiko > > [1] https://community.kde.org/Schedules/Applications/19.04_Release_Schedule -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: [akonadi/Applications/19.04] src/core: Fix a regression when updating attributes
Sorry for the delay. It is OK to do a release, the fix is a hack, but it will do for 19.04. Proper fix is more invasive, so we will do it on master for 19.08. Dan On Thursday, March 21, 2019 6:13:09 PM CET Christoph Feck wrote: > On 03/21/19 15:51, Daniel Vrátil wrote: > > On Thursday, March 21, 2019 2:06:09 PM CET David Faure wrote: > >> I'll look at the const fixing that you suggest so that we can do this > >> properly. > > > > I have a patch for Akonadi itself, I'll put it on Phab. Before applying > > tat we need to fix all components that use this API otherwise it won't > > build. > Does this mean we cannot create tarballs today from the 19.04 branch for > the beta release? > > https://community.kde.org/Schedules/Applications/19.04_Release_Schedule > > Please reply to release-team if additional time is needed. -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: [akonadi/Applications/19.04] src/core: Fix a regression when updating attributes
You can release. The fix is a bit of a hack, but it will do for 19.04 just fine. Proper fix requires touching almost all PIM components and can wait till 19.08. Dan On Thursday, 21 March 2019, Christoph Feck wrote: > On 03/21/19 15:51, Daniel Vrátil wrote: > > On Thursday, March 21, 2019 2:06:09 PM CET David Faure wrote: > >> I'll look at the const fixing that you suggest so that we can do this > >> properly. > > > > I have a patch for Akonadi itself, I'll put it on Phab. Before applying tat > > we > > need to fix all components that use this API otherwise it won't build. > > Does this mean we cannot create tarballs today from the 19.04 branch for > the beta release? > > https://community.kde.org/Schedules/Applications/19.04_Release_Schedule > > Please reply to release-team if additional time is needed. > > -- > Christoph Feck > KDE Release Team > > -- Sent from my Sailfish device
Re: Test execution for all of PIM
On Sunday, February 3, 2019 6:37:49 PM CET David Faure wrote: > On vendredi 4 janvier 2019 20:26:53 CET Ben Cooksley wrote: > > Once again, akonadi_knut_resource had failed to exit as it should. > > I just had an idea about this. How about I make the knut resource commit > suicide, 30 minutes after starting? We never need it for that long anyway. I'm pretty sure you can go lower than 30 minutes (even 10 minutes is generous). Ideally make be configurable through an env variable. The question is how to make sure the test is failed when the resource gets stuck. > If I implement that, do you agree to re-enabling CI for kdepim? > It smells a bit like a workaround, but better than no CI. signature.asc Description: This is a digitally signed message part.
Re: Test execution for all of PIM
On Tuesday, 15 January 2019 10:44:33 CET Ben Cooksley wrote: > On Tue, Jan 15, 2019 at 10:53 AM Albert Astals Cid wrote: > > Is no one from PIM world really going to answer to this? > > > > Or did release-team just got dropped from the answers? > > I've not seen any answers to this unfortunately, so unless the > responses only went to kde-pim, there hasn't been a response at this > stage. > *sad face* > > > Cheers, > > > > Albert Sorry, I just briefly read Ben's email and thought it has already been disabled...so just disable the tests for now on CI. I don't currently have much time for KDE so unless someone else steps up to do it, it won't be fixed any time soon. Dan > > Regards, > Ben > > > El divendres, 4 de gener de 2019, a les 20:26:53 CET, Ben Cooksley va escriure: > > > Hi PIM Developers, > > > > > > A few months back I reported an issue surrounding tests in various > > > parts of PIM which rely on Akonadi failing to cleanup after > > > themselves, and thus causing indefinite hangs on the CI system as they > > > wait for processes to exit which aren't going to exit by themselves. > > > > > > This issue is still very much active unfortunately, and is > > > particularly problematic for the FreeBSD and Windows builders (as > > > there is a limited number of them). This morning, all FreeBSD builds > > > were blocked by two PIM jobs just sitting there. > > > > > > Once again, akonadi_knut_resource had failed to exit as it should. > > > > > > This is a situation which cannot continue, as PIM is harming the > > > service all other KDE projects receive from the CI system through > > > these broken tests. It also requires manual Sysadmin intervention to > > > restore service when this occurs. > > > > > > I therefore suggest that you disable on your side, all tests that > > > depend on or make use of the 'akonaditest' runner framework across all > > > PIM repositories. The alternative is that all test execution for PIM > > > be disabled. > > > > > > Thoughts? > > > > > > Regards, > > > Ben -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Outdated GPG signing keys info on website
Hola! looking for GPG keys for Applications tarballs signatures, Google has lead me to https://kde.org/download/signature.php which contains a pair of fairly outdated GPG keys - I don't know if this site is linked from anywhere, but IMO it should either be updated with keys of people who do sign our tarballs these days or removed completely - it would certainly improve the trustworthiness of the signatures :-) Cheers, Daniel -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9r9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: 18.08 respin
On Thursday, 16 August 2018 15:07:17 CEST Christoph Feck wrote: > On 16.08.2018 14:59, David Faure wrote: > > On jeudi 16 août 2018 14:51:58 CEST Christoph Feck wrote: > >> Hi packagers, > >> > >> here is the respin for 18.08.0 tarball: > >> > >> akonadi Applications/18.08 > >> 404429689be019c8671c83970ad10488a8ffc55c > >> 5439a9c1cb698bf1b960c644980297d528f539a303062ffb9fe2b820782dc4e6 > >> sources/akonadi-18.08.0.tar.xz > > > > Wait, we really need 5a5d3ee27 (from akonadi git repo) in 18.08 as well, > > to avoid a data loss in at least one non-KDE application based on Akonadi > > [and possibly in korganizer/kaddressbook/etc. as well, I didn't check]. > > Any more critical bugs in the pipeline? Should we postpone release to > tomorrow or next week in case more fixes are made? Hi Christoph, as far as I know this was the last issue we had fixed that would've broken PIM for many users. No doubt there will be more fixes after Akademy, that nothing critical is left in pipeline are think (IOW David can read and send emails and use FatCRM). I'm really sorry for the late fixes, I haven't realized the release was *this* close and Akademy was a perfect place to sit down with people who can actually reproduce theses issues and debug them. I think you can go forth with the release (including 5a5d3ee27 from akonadi) . Dan -- Daniel Vrátil www.dvratil.cz | m...@dvratil.cz facebook.com/danvratil | @danvratil | +DanVrátil GPG Key: 0x3A850307F5065B61 Fingerprint: 76C92F085D0D6F9E5AD42BFD3A850307F5065B61 signature.asc Description: This is a digitally signed message part.
Re: Move blogilo to unmaintain
+1 - if it's broken and we can't afford to maintain it, we should drop it from releases rather than continue to embarass ourselves with broken software. If anyone wants, they can pick it up and take over maintaining it. Cheers, Daniel On Sunday, 24 September 2017 22:52:47 CET laurent Montel wrote: > Le dimanche 24 septembre 2017, 19:53:28 CEST Albert Astals Cid a écrit : > > El dissabte, 23 de setembre de 2017, a les 21:33:12 CEST, laurent Montel > > va > > > > escriure: > > > Hi, > > > I would like to exclude blogilo from 17.12 as it's not maintain, totally > > > broken and for sure I will not work on it as nobody reported bugs from > > > very > > > long time (and nobody reported that blogilo was broken from 17.04) > > > > Can you please describe what is broken? > > You can't write html code for example. > After porting to qwebengine 8 months ago no progress was done. > So we can't use it. > > But after that we can continue to release it :) > Regards > > > Also according to https://community.kde.org/Release_Team Sandro Knauß is > > the kdepim+release-team coordinator, i'd appreciate his input in this > > regard. > > > > Cheers, > > > > Albert > > > > > Is it a problem for you to exclude it ? > > > > > > Regards -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: PIM versioning and dependencies
On Saturday, August 26, 2017 11:02:21 PM CEST Ben Cooksley wrote: > Hi all, > > We have a little bit of an issue in PIM at the moment. It can be > broken down into 3 separate issues, but overall from my perspective > the PIM team is violating established practice in the community. > > The first issue concerns the dependency bump to Qt 5.8. This has not > announced or discussed on any community wide list, either prior or > after the bump was made. As a consequence of this, a series of > Extragear applications which previously could be built on FreeBSD can > no longer be built. Are the CI requirements for each platform documented somewhere? Where can we see which versions of which dependencies we can use on each platform? > The second issue concerns maintenance of our internal metadata files, > which define the dependencies between various bits of KDE software. > These files are used by the CI system to provision dependencies, and > kdesrc-build to sequence items to be built. > > Since the last release was branched the PIM developers have added a > new dependency to kdepim-runtime. This change happened well over a > week ago, and they have yet to update the metadata files accordingly. > While this may seem minor, if someone is trying to build a single > application and it's corresponding dependencies they'll run into > problems because neither the CI system or kdesrc-build will know about > this new dependency they've added. My bad, I was convinced we were already building kdepim-runtime with libkgapi. I have corrected it now. > The third issue concerns the practice of version management within > PIM. Currently the master branch of PIM is broken because it appears > that one or more repositories have been missed in the latest round of > bumping. All master versions are >= 5.6.40. I see KBlog and Akregator build failed due missing Syndication dependency. Looks like the Syndication build was triggered after KBlog and Akregator, triggering a new build of those two should fix it. Looks like I lost the rights to manually trigger builds on CI after the upgrade, so I can't fix it until we make a commit. Dan > > Can the PIM developers please provide an explanation for these various > breakages which they've made? > > Cheers, > Ben -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
kdepim-runtime-17.04.0 - Gmail login hotfix
Hi all, if you are shipping KDE Application 17.04, please include the following patch in your packages: https://cgit.kde.org/kdepim-runtime.git/commit/?h=Applications/ 17.04=c9ae16363e68d6958db0cd835cb0180b340594b5 It fixes authentication with Gmail (so it can potentially affect many users). In 17.04 we switched to using the native XOAUTH2 authentication for Gmail (authenticates via web interface with 2FA support, no need for application- specific password anymore), but a bug sneaked into the final release that causes the new authentication configuration to not be migrated so the IMAP resource cannot log in and thus receive any emails. Thanks a lot and sorry for the inconvenience, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
LibKGAPI moved to KDE Applications
Hi all, a short announcement: LibKGAPI has been moved from extragear to become part of KDE Applications release. LibKGAPI is a library that implements various Google services APIs like Contacts, Calendars, Drive etc. It is primarily used by some KDE PIM components and by KIO GDrive. It will be included in KDE Applications 17.04 release. The library is now part of the KDE PIM suite, because that's the primary user of it. That means that starting in April there will be a jump in versioning. The current version is 5.3.1, the next version will internally be 5.5.0 (to follow the versioning of other KDE PIM modules) and publicly 17.4.0 Most importantly, the name of the binaries have changed: previously the binaries were called libKF5GAPI*.so, starting with KDE Applications 17.04 release the libraries will be called libKPimGAPI*.so to reflect that LibKGAPI is not a Framework (yet). For developers, the name of the CMake config files have changed too, so you should use find_package(KPimGAPI) instead of find_package(KF5GAPI), although the latter will work for several more releases (CMake will print a deprecation warning though). Cheers, Daniel -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Moving LibKGAPI do KDE Applications
On Monday, February 6, 2017 4:45:21 PM CET Daniel Vrátil wrote: > On Monday, February 6, 2017 4:14:57 PM CET Heiko Becker wrote: > > Hi, > > > > On 02/06/17 16:00, Daniel Vrátil wrote: > > >> LibKGAPI is currently a "library with an independent release schedule > > >> (aka > > >> extragear-libs). > > > > > > Yup, we are already extragear. > > > > > >> Just as reference, who are the current users? > > > > > > In PIM (and Applications) it's kdepim-runtime, blogilo and pim-storage- > > > service-manager. > > > > > > > > > Outside of KDE Applications it's kio-gdrive. > > > > any reason not to make it a framework? There are already users from > > Applications and Extragear and it also has a 'KF5' prefix (like so many > > other non frameworks, who IMHO shouldn't). > > It depends on KCalCore and KContacts which are not frameworks. Once those > are moved to Frameworks, I will consider moving KGAPI too. > > Good point with the KF5 prefix, I will change it to "KPim", which we already > did for KDAV library and eventually want to do for all our PIM libraries to > solve the has-KF5-prefix-but-is-not-a-framework problem. This has now been implemented in master. It still provides KF5GAPI for backwards compatibility (so that existing dependees don't break), but that will eventually be removed in the future. Any more questions/objections, or can we proceed with the move? Cheers, Dan > > Dan > > > Regards, > > Heiko -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Moving LibKGAPI do KDE Applications
On Monday, February 6, 2017 4:14:57 PM CET Heiko Becker wrote: > Hi, > > On 02/06/17 16:00, Daniel Vrátil wrote: > >> LibKGAPI is currently a "library with an independent release schedule > >> (aka > >> extragear-libs). > > > > Yup, we are already extragear. > > > >> Just as reference, who are the current users? > > > > In PIM (and Applications) it's kdepim-runtime, blogilo and pim-storage- > > service-manager. > > > > > > Outside of KDE Applications it's kio-gdrive. > > any reason not to make it a framework? There are already users from > Applications and Extragear and it also has a 'KF5' prefix (like so many > other non frameworks, who IMHO shouldn't). It depends on KCalCore and KContacts which are not frameworks. Once those are moved to Frameworks, I will consider moving KGAPI too. Good point with the KF5 prefix, I will change it to "KPim", which we already did for KDAV library and eventually want to do for all our PIM libraries to solve the has-KF5-prefix-but-is-not-a-framework problem. Dan > > Regards, > Heiko -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: Moving LibKGAPI do KDE Applications
On Monday, February 6, 2017 12:53:41 PM CET Luigi Toscano wrote: > On Monday, 6 February 2017 12:34:00 CET Harald Sitter wrote: > > On Sun, Feb 5, 2017 at 9:24 PM, Daniel Vrátil <dvra...@kde.org> wrote: > > > Any objections? > > > > Elevation from playground requires going through kdereview. > > > > HS > > LibKGAPI is currently a "library with an independent release schedule (aka > extragear-libs). Yup, we are already extragear. > > Just as reference, who are the current users? In PIM (and Applications) it's kdepim-runtime, blogilo and pim-storage- service-manager. Outside of KDE Applications it's kio-gdrive. Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Moving LibKGAPI do KDE Applications
Hi, I'd like to move LibKGAPI, the library which implements various Google APIs, from extragear to kde/pim namespace and include it in next KDE Applications release. LibKGAPI is already used by some KDE PIM components, so it would be cool if it could be included in KDE Applications to ensure common release cycle and possibly better exposure among other developers/public. Any objections? Cheers, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part.
Re: blogilo depends on unreleased libkgapi
Hi, On Saturday, November 19, 2016 12:40:35 PM CET Sandro Knauß wrote: > Hi Dan, > > I thought kgapi is included in KDE Applications 16.08 already. I read your > mail form 30.7. like that. But it looks like it is not included right now. Indeed my plan is to eventually move LibKGAPI to KDE Applications, I just somehow keep missing the deadlines. I'll try not to forget next time:-) > @montel: Are there any api changes, why we need gapi > 5.3.1, or is it > simply your script update? That looks like an update error to me, 16.12 should depend on 5.3.1, AFAICT there was no update to the Blogger API in LibKGAPI between 5.3.1 and 5.3.80, but I'll let Laurent confirm. > > Best Regards, > > sandro > > -- > > Am Samstag, 19. November 2016, 09:23:28 CET schrieb Antonio Rojas: > > Hi, > > > > Blogilo 16.12 beta depends on an unreleased version of libkgapi > > > > CMake Warning at CMakeLists.txt:68 (find_package): > > Could not find a configuration file for package "KF5GAPI" that is > > compatible with requested version "5.3.80". > > > > Can we have a new release, please? -- -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part.
Missing Kirigami tarball?
Hi, trying to build Plasma 5.7.95 for Fedora I noticed that plasma-sdk requires KF5Kirigami 5.26, but Kirigami was not part of KF5 5.26 release and I don't see Kirigami tarball in unstable/plasma/5.7.95 either. Was it not released at all or is the tarball hiding in some other place? Thanks, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks 5.25.0
On Sunday, August 7, 2016 9:12:18 PM CEST David Faure wrote: > Dear packagers, > > KDE Frameworks 5.25.0 has been uploaded to the usual place. > > New frameworks: none this time. > > Public release next Saturday. > > Thanks for the packaging work! Juts a heads-up to fellow packagers: Solid fails to compile with flex 2.6.0 in C90 mode (which is enforced by KDECompilerSettings in ECM). This is due to a bug in flex 2.6.0 which generates a C code with C++-style comments. The bug has been fixed in flex 2.6.1, but if your distro ships flex 2.6.0 you will need to patch CMakeLists.txt to append -std=c99 to CMAKE_C_FLAGS (unfortunatelly CFLAGS envvar is ignored by KDECompilerSettings). Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] release libkgapi
On Sunday, July 24, 2016 11:19:51 AM CEST David Faure wrote: > On samedi 23 juillet 2016 14:27:35 CEST Sandro Knauß wrote: > > Hey Dan, > > > > libkgapi is not part of KDE Applications, so you need to release it > > separately. libkgapi 5.3.0 has been released now, sorry for the delay. > > Shouldn't we make it part of the KDE Applications release instead ? Makes sense, I'll work on having it included in KDE Applications 16.12 release. Dan > > This would make things much simpler for compiling KDEPIM. > > The fact that it's separate also just gave me an issue when trying to switch > all modules defined in kf5-kdepim-build-include to Applications/16.08. That > one module doesn't have such a branch, breaking my build (OK prison doesn't > either but for that one we have a plan, moving it to KF5). > > IMHO extragear is stuff that is "on top" of KF5 + KDE Applications. > Having KDE Applications depend on extragear seems circular (or at least > wrong layering) to me. Unless maybe I'm missing recent developments about > extragear's role, everything above KF5 is a bit of a blur to me ;) -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[Kde-pim] kdepimlibs.git split
(CCing the correct mailing lists the time) Hello, we have finally finished splitting of kdepimlibs.git repository. There are three new repositories now: kde/pim/akonadi-contacts.git kde/pim/akonadi-notes.git kde/pim/akonadi-mime.git New features should be contributed to the newly created repositories. Bugfixes for current stable release (Applications 16.04) should go to Applications/ 16.04 branch in kdepimlibs.git and be backported to master branch in respective split repository. I will remove all files from kdepimlibs.git master and ask sysadmins to lock the branch down once we get the new repositories added to CI (sysadmin ticket filed) and first builds are available. Translations have been moved and kde-build-metadata were adjusted. @release-team: please exclude kdepimlibs from KDE Applications 16.08 and include akonadi-contacts, akonadi-notes and akonadi-mime instead. Thanks, Daniel -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Unannounced dependency bump?
On Wednesday, June 29, 2016 12:24:10 PM CEST laurent Montel wrote: > Le mercredi 29 juin 2016, 21:02:24 CEST Ben Cooksley a écrit : > > Hi all, > > > > It would appear that PIM has bumped it's Grantlee dependency without > > any announcement. > > > > Failing that, commits are missing from one or more of the PIM family > > of repositories, the build metadata is out of date, or the CMake > > infrastructure of the PIM repositories is insufficient to work within > > the CI environment. > > > > Please see > > https://build.kde.org/view/FAILED/job/messagelib%20master%20kf5-qt5/325/PL > > A > > TFORM=Linux,compiler=gcc/console > > > > Please correct this and provide an explanation for the issue. > > The problem is a grantleetheme problem. It was a bad commit. > It's fixed. Note that GrantleeTheme is our internal library. > > > PIM buildability continues to be an ongoing and major issue - Excluding honest mistakes like this one, our only issue is with build order due to API changes across modules. If I break API in one module and push a fix to another module that depends on the new API, it will break if it finishes before the first one. If I wait with pushing the API adjustment in the other module but someone else triggers the build anyway, we have the same problem. We cannot prevent this easily unless the CI can ensure build order > > at this > > point i'm considering whether we need to expel PIM from the mainline > > release modules to playground. I'd like to point out that Plasma 5.7 is currently way more broken than our stable release on the CI. Should we consider moving Plasma to playground as well? > I think that we don't make error when we don't work! > So yep there is some CI error but we fix them. > > If you want to remove it from CI not a problem for me. Yeah, let's not do that. We need the CI to catch problems like this one and run our tests... ...speaking of which, Qt on the CI is broken: Cannot mix incompatible Qt library (version 0x50601) with this library (version 0x50602) https://build.kde.org/view/KDE-PIM/job/messagelib%20master%20kf5-qt5/327/ PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/ akonadi_sqlite_followupreminderselectdatedialogtest/ Cheers, Dan > > Regards > > > Regards, > > Ben > > ___ > > KDE PIM mailing list kde-...@kde.org > > https://mail.kde.org/mailman/listinfo/kde-pim > > KDE PIM home page at http://pim.kde.org/ > > ___ > KDE PIM mailing list kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks 5.20.0
On Sunday, March 20, 2016 10:58:00 AM CET David Faure wrote: > On Tuesday 15 March 2016 01:13:32 Daniel Vrátil wrote: > > On Saturday, March 5, 2016 9:33:01 PM CET David Faure wrote: > > > Dear packagers, > > > > > > KDE Frameworks 5.20.0 has been uploaded to the usual place. > > > > > > New frameworks: none this time. > > > > > > Public release next Saturday. > > > > > > Thanks for the packaging work! > > > > Hi, > > > > I'm getting the following error when building KTextEditor on Fedora > > rawhide: > > > > Error FODC0002 in > > file:///builddir/build/BUILD/ktexteditor-5.20.0/src/syntax/ data/gap.xml, > > at line 1, column 44: Encoding ISO-8859-15 is unsupported > > > > I haven't seen this error in 5.19, so I assume it must be something new. > > Am I missing a new dependency or something? CMake says everything's OK? > > I'm building against Qt 5.6. > > This has been fixed in commit e6b6e7c633882ef00c1bd0b301259286e5a123cd > (review request 127406). > > Do you need a 5.20.1 tarball ? I manually pulled the patch into our packaging and it builds again. Since it only seems to have affected Fedora (and only its development branch) I don't think we need a new tarball. Cheers, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks 5.20.0
On Saturday, March 5, 2016 9:33:01 PM CET David Faure wrote: > Dear packagers, > > KDE Frameworks 5.20.0 has been uploaded to the usual place. > > New frameworks: none this time. > > Public release next Saturday. > > Thanks for the packaging work! Hi, I'm getting the following error when building KTextEditor on Fedora rawhide: Error FODC0002 in file:///builddir/build/BUILD/ktexteditor-5.20.0/src/syntax/ data/gap.xml, at line 1, column 44: Encoding ISO-8859-15 is unsupported I haven't seen this error in 5.19, so I assume it must be something new. Am I missing a new dependency or something? CMake says everything's OK? I'm building against Qt 5.6. I can compile locally on my Fedora 23 machine with Qt 5.5, but I can't tell what part of my local environment makes it compile. Cheers, Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepim-runtime seems to depend on unreleased versions of libkgapi and libkolabxml - was - Re: www/sites/www
On Sunday, November 22, 2015 12:44:10 AM CET Albert Astals Cid wrote: > El Saturday 21 November 2015, a les 09:51:05, Antonio Rojas va escriure: > > kdepim-runtime seems to depend on unreleased versions of libkgapi and > > libkolabxml > > Sandro can you confirm that? > > If so this has to be fixed immediately either those dependencies on libkgapi > and libkolabxml reverted back to normal or you must convince whoever > releases that dependencies to release them ASAP, the dependency freeze was > weeks ago. Ah crap, I made a typo in LibKGAPI version, the current (unreleased) version is 5.40.0 instead of 5.0.40 (last release was 5.0.0)., but it's already set in kdepim-runtime as min required version. I guess I can't just change the requirement in kdepim-runtime down to 5.0.40 anymore? Cheers, Dan > > Cheers, > Albert > > > ___ > > release-team mailing list > > release-team@kde.org > > https://mail.kde.org/mailman/listinfo/release-team > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdepim-runtime seems to depend on unreleased versions of libkgapi and libkolabxml - was - Re: www/sites/www
On Sunday, November 22, 2015 12:52:05 AM CET Daniel Vrátil wrote: > On Sunday, November 22, 2015 12:44:10 AM CET Albert Astals Cid wrote: > > El Saturday 21 November 2015, a les 09:51:05, Antonio Rojas va escriure: > > > kdepim-runtime seems to depend on unreleased versions of libkgapi and > > > libkolabxml > > > > Sandro can you confirm that? > > > > If so this has to be fixed immediately either those dependencies on > > libkgapi and libkolabxml reverted back to normal or you must convince > > whoever releases that dependencies to release them ASAP, the dependency > > freeze was weeks ago. > > Ah crap, I made a typo in LibKGAPI version, the current (unreleased) version > is 5.40.0 instead of 5.0.40 (last release was 5.0.0)., but it's already set > in kdepim-runtime as min required version. I guess I can't just change the > requirement in kdepim-runtime down to 5.0.40 anymore? Sorry about the previous panicky email, things have been cleared up and libkgapi-5.1.0 has been released, currently awaiting sysadmins to move it to download.kde.org. Dan > > > Cheers, > Dan > > > Cheers, > > > > Albert > > > > > ___ > > > release-team mailing list > > > release-team@kde.org > > > https://mail.kde.org/mailman/listinfo/release-team > > > > ___ > > release-team mailing list > > release-team@kde.org > > https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma 5.5 alpha
On 2015-11-06 13:28, Jonathan Riddell wrote: It was suggested to celebrate repo freeze I make alpha tars of Plasma 5.5 just to check we know what's being released so here's some tars, please check it includes all the tars you expect and if you're incharge of a new tar then check it contains the right stuff. No release is planned, beta is due in 2 weeks. https://www.kde.org/info/source-plasma-5.4.90.inc http://embra.edinburghlinux.co.uk/~jr/tmp/unstable/plasma/5.4.90/ Hi, looks like the plasma-workspace-wallpaper tarball has been accidentally released from SVN instead of GIT :) Dan Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 125565: KMail: Fix scrolling up/down on the message viewer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125565/#review86544 --- Ship it! Ship it! Oh gods, YES! Thank you! If you can sneak it into .2, that would be really great! - Daniel Vrátil On Oct. 9, 2015, 2:39 a.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125565/ > --- > > (Updated Oct. 9, 2015, 2:39 a.m.) > > > Review request for KDEPIM and Release Team. > > > Repository: kdepim > > > Description > --- > > The new style connection for signals does not support default arguments so > > connect(mScrollUpAction, ::triggered, > q, ::slotScrollUp); > > Connects the version of triggered(bool) with slotScrollUp meaning that > slotScrollUp always gets a 0 since the action is never checked. > > This breaks the API but the widget is only used internally so i think it's > something we can live on. > > Release-team can we sneak this onto 15.0.8.2 since it's relatively critical? > > kdepim guys is there a bug number for this? > > > Diffs > - > > messageviewer/viewer/viewer.h 150c24b > messageviewer/viewer/viewer.cpp ea4fa75 > > Diff: https://git.reviewboard.kde.org/r/125565/diff/ > > > Testing > --- > > WORKS > > > Thanks, > > Albert Astals Cid > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: minified javascript in telepathy-qt
On Monday, September 7, 2015 9:34:15 AM CEST Jonathan Riddell wrote: > On Mon, Sep 07, 2015 at 11:30:14AM +0200, David Edmundson wrote: > > On Mon, Sep 7, 2015 at 11:01 AM, Jonathan Riddell <j...@jriddell.org> wrote: > > On Fri, Sep 04, 2015 at 03:25:55PM +0100, David Edmundson wrote: > > > It's not an issue. > > > > > > That file is not part of the source code for Telepathy-qt. > > > > Yes it is > > > > telepathy-qt-0.9.6.1.tar.gz > > telepathy-qt-0.9.6.1/doc/html/jquery.js > > > > It's not preferred modifiable form and can't be distributed in Ubuntu > > or > > other free software linux distros. > > > > It is in a tarball which also contains the source code for Telepathy-Qt, > > it is not part of the source code *for* TelepathyQt. > > Right. So the tar can't be distributed in free software linux > distributions, it would help us distributions a lot if we got tars > which could be distributed. +1 > > Jonathan > _______ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.0 available for packagers
On Tuesday, August 25, 2015 8:38:01 PM CEST Eric Hameleers wrote: On Tue, 25 Aug 2015, Daniel Vrátil wrote: On Tuesday, August 25, 2015 3:02:54 AM CEST Eric Hameleers wrote: On Tue, 18 Aug 2015, Antonio Rojas wrote: Subject: Re: KDE Applications 15.08.0 available for packagers I seem to be unable to compile kdepim after all the other new kdepim related packages have been built successfully. I have grantlee 5.0.0 installed, and it is found by cmake: ... * Qt5OpenGL * Qt5 * Qt5Gui * Grantlee5 (required version = 5.0) * Gpgme , The GnuPG Made Easy (GPGME) library) , http://www.gnupg.org/related_software/gpgme * Gettext ... But I get a linker error like this: [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/printing/grantleeprint.cpp.o [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/kaddressbookgrantlee_automoc.cpp.o Linking CXX shared library libkaddressbookgrantlee.so CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cp p.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::GrantleeContactFormatter ()' : grantleecontactformatter.cpp:(.text+0x2bc): undefined reference to `Grantlee::FileSystemTemplateLoader::FileSystemTemplateLoader()' CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cp p.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::setGrantleeTheme(Grantle eTh eme::Theme const)': grantleecontactformatter.cpp:(.text+0x543): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x564): undefined reference to `Grantlee::TemplateImpl::errorString()' grantleecontactformatter.cpp:(.text+0x645): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x729): undefined reference to `Grantlee::TemplateImpl::errorString()' ...etc. I have no idea how to troubleshoot or fix this. I do want to ship the new kdepim with my next batch of Slackware updates. I think I've seen similar problem when having both Qt 4 and Qt 5 Grantlee installed. Could you try without Qt4 Grantlee installed? Dan Hi Dan, Indeed I had both grantlee Qt4 and Qt5 interfaces installed, and after removing the old Qt4 based version and adding /usr/include/grantlee-qt5 to the include path (that is where I installed the Qt5 version in order to not make it clash) I no longer get the aforementione errors, but instead I get this new one twice: the first time around 2% of the compilation: That means automoc did not find the includes. I am not sure how to pass the adjusted include_directories from CMake to automoc, maybe someone else might know? Dan [ 2%] Automatic moc for target grantlee_messageheaderfilters Generating moc_messageheadergrantleefilters.cpp /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messagehe ader grantleefilters.h:31: Error: Undefined interface AUTOGEN: error: process for /tmp/kde-build/kdepim/kdepim-15.08.0/build/messagevi ewer/grantleefilters/moc_messageheadergrantleefilters.cpp failed: /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messagehe ader grantleefilters.h:31: Error: Undefined interface moc failed... make[2]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_auto moc] Error 1 make[1]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_auto moc.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Generating moc_kwatchgnupgconfig.cpp And then the compilation runs for a long time until it hits the same spot again: [ 51%] Automatic moc for target grantlee_messageheaderfilters Generating moc_messageheadergrantleefilters.cpp /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messagehe adergrantleefilters.h:31: Error: Undefined interface AUTOGEN: error: process for /tmp/kde-build/kdepim/kdepim-15.08.0/build/messageviewer/grantleefilters/moc _messageheadergrantleefilters.cpp failed: /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messagehe adergrantleefilters.h:31: Error: Undefined interface moc failed... make[2]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_auto moc] Error 1 make[1]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_auto moc.dir/all] Error 2 make: *** [all] Error 2 I am at a loss. Cheers, Eric -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.0 available for packagers
On Tuesday, August 25, 2015 3:02:54 AM CEST Eric Hameleers wrote: On Tue, 18 Aug 2015, Antonio Rojas wrote: Subject: Re: KDE Applications 15.08.0 available for packagers I seem to be unable to compile kdepim after all the other new kdepim related packages have been built successfully. I have grantlee 5.0.0 installed, and it is found by cmake: ... * Qt5OpenGL * Qt5 * Qt5Gui * Grantlee5 (required version = 5.0) * Gpgme , The GnuPG Made Easy (GPGME) library) , http://www.gnupg.org/related_software/gpgme * Gettext ... But I get a linker error like this: [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/printing/grantleeprint.cpp.o [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/kaddressbookgrantlee_automoc.cpp.o Linking CXX shared library libkaddressbookgrantlee.so CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::GrantleeContactFormatter()' : grantleecontactformatter.cpp:(.text+0x2bc): undefined reference to `Grantlee::FileSystemTemplateLoader::FileSystemTemplateLoader()' CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::setGrantleeTheme(GrantleeTh eme::Theme const)': grantleecontactformatter.cpp:(.text+0x543): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x564): undefined reference to `Grantlee::TemplateImpl::errorString()' grantleecontactformatter.cpp:(.text+0x645): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x729): undefined reference to `Grantlee::TemplateImpl::errorString()' ...etc. I have no idea how to troubleshoot or fix this. I do want to ship the new kdepim with my next batch of Slackware updates. I think I've seen similar problem when having both Qt 4 and Qt 5 Grantlee installed. Could you try without Qt4 Grantlee installed? Dan Cheers, Eric -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kopete and kdepimlibs in apps 15.08
On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote: Hellos, So, I just noticed that kopete has: CMakeLists.txt:find_package(KdepimLibs REQUIRED) we do however not have a kdepimlibs (qt4) in Applications 15.08 so that requirement cannot really be met anymore. What's worse: kdepimlibs (qt4) in fact has file overlap with kdepimlibs (qt5); namely at least: - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml - usr/share/mime/packages/kdepimlibs-mime.xml so they are not co-installable without tweaking by every distro first. kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5, because that's what it contains. For the socialutil we could have x- vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP. However that's not the biggest problem. The biggest problem is that you can only compile kdepimlibs4 against Akonadi = 1.13, which is not co-installable with the version of Akonadi required by kdepimlibs5. The one thing that kdepimlibs4 needs from Akonadi is libakonadiprotocolinternals.so (that's what kdepimlibs4 link against). If Kopete does not need to actually access KDE PIM data stored in Akonadi, then the Akonadi(qt4) server or any other binary are not needed. We can publish some sort of manual for distributions how to deal with this, but I'm afraid distros will have to figure out the packaging magic to handle that on their own. Dan Now looking at the source kdepimlibs is used for two things in kopete: 1) kpimidentities is used in the bonjour protocol as a fallback to kuser to obtain the users's name and email address for account default values (this is required, although I am not sure it should be) 2) gpgmepp is used by the crypto plugin for crypto things (this is optional, although I am not sure it should be :P) Given that we have no kde4pimlibs source what is the intended solution to this? Cripple kopete and make bonjour optional using a patch, if so why not do that in the repo directly? Or perhaps have every distro figure out which parts of the old kdepimlibs are now defunct with akonadi moved to kf5 and package the rest for compat? (CC'd Pali and Dan; not sure they are subbed) HS -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Associate Software Engineer KDE Desktop Team, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kopete and kdepimlibs in apps 15.08
On Tuesday, August 18, 2015 12:40:21 PM CEST Pali Rohár wrote: On Tuesday 18 August 2015 11:41:04 Daniel Vrátil wrote: On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote: Hellos, So, I just noticed that kopete has: CMakeLists.txt:find_package(KdepimLibs REQUIRED) we do however not have a kdepimlibs (qt4) in Applications 15.08 so that requirement cannot really be met anymore. What's worse: kdepimlibs (qt4) in fact has file overlap with kdepimlibs (qt5); namely at least: - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml - usr/share/mime/packages/kdepimlibs-mime.xml so they are not co-installable without tweaking by every distro first. kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5, because that's what it contains. For the socialutil we could have x- vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP. Ok, then conflicting files are solved. However that's not the biggest problem. The biggest problem is that you can only compile kdepimlibs4 against Akonadi = 1.13, which is not co-installable with the version of Akonadi required by kdepimlibs5. The one thing that kdepimlibs4 needs from Akonadi is libakonadiprotocolinternals.so (that's what kdepimlibs4 link against). If Kopete does not need to actually access KDE PIM data stored in Akonadi, then the Akonadi(qt4) server or any other binary are not needed. We can publish some sort of manual for distributions how to deal with this, but I'm afraid distros will have to figure out the packaging magic to handle that on their own. Kopete does not depend nor does not use Akonadi. It uses old KABC resources. So it does not need Akonadi client or server. But I'm not happy with such dependency problems. Why there are those problems? I do not understand these decisions. Nobody was thinking about problems with coexistence of older application? Or everybody did not care about that before KF5 relase? Is KDE again going to have with KF5 same fuck-up as with first KDE4 version? We somewhat expected that all kdepimlibs4 users have only optional deps or that they will switch to KF5 as well. Yes, we screwed up (again). Writing manual for distribution is bad idea. It means that software collection (KDE4, KF5) is broken by design. So why kdepimlibs4 cannot be compiled with same version of akonadi as kdepimlibs5? I think this is biggest problem which causing this, right? There is this tiny library called libakonadiprotocolinternals.so which Akonadi server and kdepimlibs share. It contains some utility classes and macros related to the communication protocol. The protocol has changed substantially in Qt5-based Akonadi, thus the library API is no longer compatible with the old one. However the library is called libKF5AkonadiPrivate.so in Akonadi 5, so it's possible to co-install those two libraries. It's not possible to however co-install the rest of Akonadi (akonadiserver, akonadictl, ). With my packager hat on, we will probably end up doing something like this in Fedora: akonadi-server-15.08 (whatever is in akonadi-15.08 tarball) akonadi-server-devel-15.08 (headers for ^^) akonadi-15.08 (whatever is kdepimlibs, Requires: akonadi-server) akonadi-devel-15.08 (headers for ^^) akonadi-server-compat-libs-1.13 (libakonadiprotocolinternals.so from akonadi-1.13 tarball) akonadi-server-compat-libs-devel-1.13 (headers for ^^) akonadi-server-compat-1.13 (the rest of akonadi-1.13 tarball, Requires: akonadi-server-compat-libs, Conflicts: akonadi-server = 15.08) kdepimlibs-4.14 (Requires: akonadi-server-compat-libs-devel = 1.13) Dan Dan Now looking at the source kdepimlibs is used for two things in kopete: 1) kpimidentities is used in the bonjour protocol as a fallback to kuser to obtain the users's name and email address for account default values (this is required, although I am not sure it should be) 2) gpgmepp is used by the crypto plugin for crypto things (this is optional, although I am not sure it should be :P) Given that we have no kde4pimlibs source what is the intended solution to this? Cripple kopete and make bonjour optional using a patch, if so why not do that in the repo directly? Or perhaps have every distro figure out which parts of the old kdepimlibs are now defunct with akonadi moved to kf5 and package the rest for compat? (CC'd Pali and Dan; not sure they are subbed) HS -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kopete and kdepimlibs in apps 15.08
. This is not easy for non-akonadi developers. It would have been great if KDE developers though about it before... (PS: I'm not akonadi developer, user or so... I just proposing general solutions for such software problems.) Dan Dan Now looking at the source kdepimlibs is used for two things in kopete: 1) kpimidentities is used in the bonjour protocol as a fallback to kuser to obtain the users's name and email address for account default values (this is required, although I am not sure it should be) 2) gpgmepp is used by the crypto plugin for crypto things (this is optional, although I am not sure it should be :P) Given that we have no kde4pimlibs source what is the intended solution to this? Cripple kopete and make bonjour optional using a patch, if so why not do that in the repo directly? Or perhaps have every distro figure out which parts of the old kdepimlibs are now defunct with akonadi moved to kf5 and package the rest for compat? (CC'd Pali and Dan; not sure they are subbed) HS -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kopete and kdepimlibs in apps 15.08
On Tuesday, August 18, 2015 1:25:56 PM CEST you wrote: On Tuesday 18 August 2015 13:06:20 Daniel Vrátil wrote: On Tuesday, August 18, 2015 12:40:21 PM CEST Pali Rohár wrote: On Tuesday 18 August 2015 11:41:04 Daniel Vrátil wrote: On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote: Hellos, So, I just noticed that kopete has: CMakeLists.txt:find_package(KdepimLibs REQUIRED) we do however not have a kdepimlibs (qt4) in Applications 15.08 so that requirement cannot really be met anymore. What's worse: kdepimlibs (qt4) in fact has file overlap with kdepimlibs (qt5); namely at least: - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml - usr/share/mime/packages/kdepimlibs-mime.xml so they are not co-installable without tweaking by every distro first. kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5, because that's what it contains. For the socialutil we could have x- vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP. Ok, then conflicting files are solved. However that's not the biggest problem. The biggest problem is that you can only compile kdepimlibs4 against Akonadi = 1.13, which is not co-installable with the version of Akonadi required by kdepimlibs5. The one thing that kdepimlibs4 needs from Akonadi is libakonadiprotocolinternals.so (that's what kdepimlibs4 link against). If Kopete does not need to actually access KDE PIM data stored in Akonadi, then the Akonadi(qt4) server or any other binary are not needed. We can publish some sort of manual for distributions how to deal with this, but I'm afraid distros will have to figure out the packaging magic to handle that on their own. Kopete does not depend nor does not use Akonadi. It uses old KABC resources. So it does not need Akonadi client or server. But I'm not happy with such dependency problems. Why there are those problems? I do not understand these decisions. Nobody was thinking about problems with coexistence of older application? Or everybody did not care about that before KF5 relase? Is KDE again going to have with KF5 same fuck-up as with first KDE4 version? We somewhat expected that all kdepimlibs4 users have only optional deps or that they will switch to KF5 as well. Yes, we screwed up (again). To prevent any other such situation, what about asking maintainers (or on mailing list) of all kde apps? I'm sure if somebody asked me or on kopete-devel year (or two!) ago if kdepimlibs is really required to build kopete, answer will be there! What is the plan with Kopete? Are you guys switching to KF5 in 15.12? Writing manual for distribution is bad idea. It means that software collection (KDE4, KF5) is broken by design. So why kdepimlibs4 cannot be compiled with same version of akonadi as kdepimlibs5? I think this is biggest problem which causing this, right? There is this tiny library called libakonadiprotocolinternals.so which Akonadi server and kdepimlibs share. It contains some utility classes and macros related to the communication protocol. The protocol has changed substantially in Qt5-based Akonadi, thus the library API is no longer compatible with the old one. However the library is called libKF5AkonadiPrivate.so in Akonadi 5, so it's possible to co-install those two libraries. It's not possible to however co-install the rest of Akonadi (akonadiserver, akonadictl, ). With my packager hat on, we will probably end up doing something like this in Fedora: akonadi-server-15.08 (whatever is in akonadi-15.08 tarball) akonadi-server-devel-15.08 (headers for ^^) akonadi-15.08 (whatever is kdepimlibs, Requires: akonadi-server) akonadi-devel-15.08 (headers for ^^) akonadi-server-compat-libs-1.13 (libakonadiprotocolinternals.so from akonadi-1.13 tarball) akonadi-server-compat-libs-devel-1.13 (headers for ^^) akonadi-server-compat-1.13 (the rest of akonadi-1.13 tarball, Requires: akonadi-server-compat-libs, Conflicts: akonadi-server = 15.08) kdepimlibs-4.14 (Requires: akonadi-server-compat-libs-devel = 1.13) Good. But there is problem. KDE tarball packages have same name for akonadi-server and akonadi-server-compat. Does not matter. Akonadi 1.13 tarball has been released a year or so ago and most distributions already ship it, so it's just about renaming the actual package (if they decide to go with the solution I outlined). There won't be any new releases of Qt4-based Akonadi, so the tarball name conflict is not a problem. Similar like with many distributions shipping compat versions of libpng. Renaming akonadi-server (v 1.13) to akonadi-server-compat is insane. Not insane at all, it's a very normal practice in distribution packaging. If you are introducing
Re: kopete and kdepimlibs in apps 15.08
On Tuesday, August 18, 2015 4:26:37 PM CEST Nicolas Lécureuil wrote: Le 2015-08-18 13:06, Daniel Vrátil a écrit : On Tuesday, August 18, 2015 12:40:21 PM CEST Pali Rohár wrote: On Tuesday 18 August 2015 11:41:04 Daniel Vrátil wrote: On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote: Hellos, So, I just noticed that kopete has: CMakeLists.txt:find_package(KdepimLibs REQUIRED) we do however not have a kdepimlibs (qt4) in Applications 15.08 so that requirement cannot really be met anymore. What's worse: kdepimlibs (qt4) in fact has file overlap with kdepimlibs (qt5); namely at least: - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml - usr/share/mime/packages/kdepimlibs-mime.xml so they are not co-installable without tweaking by every distro first. kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5, because that's what it contains. For the socialutil we could have x- vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP. Hi, i see an other conflict between kde4 kdepimlibs and kdepimlibs , which is / usr/bin/akonadi2xml That is just a testing/developer utility, so it should be in a -dev subpackage or something like that. It can safely be omitted from one or the other. Dan -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kopete and kdepimlibs in apps 15.08
On Tuesday, August 18, 2015 11:41:04 AM CEST Daniel Vrátil wrote: On Tuesday, August 18, 2015 9:53:44 AM CEST Harald Sitter wrote: Hellos, So, I just noticed that kopete has: CMakeLists.txt:find_package(KdepimLibs REQUIRED) we do however not have a kdepimlibs (qt4) in Applications 15.08 so that requirement cannot really be met anymore. What's worse: kdepimlibs (qt4) in fact has file overlap with kdepimlibs (qt5); namely at least: - usr/share/mime/packages/x-vnd.akonadi.socialfeeditem.xml - usr/share/mime/packages/kdepimlibs-mime.xml so they are not co-installable without tweaking by every distro first. kdepimlibs-mime.xml could be renamed to x-vnd.kde.contactgroup.xml in KF5, because that's what it contains. For the socialutil we could have x- vnd.akonadi5.socialfeeditem.xml in KF5 version... I'll fix that ASAP. Fixed in Applications/15.08 branch of kdepimlibs. Could we pretty please get a respin of kdepimlibs tarball? However that's not the biggest problem. The biggest problem is that you can only compile kdepimlibs4 against Akonadi = 1.13, which is not co-installable with the version of Akonadi required by kdepimlibs5. The one thing that kdepimlibs4 needs from Akonadi is libakonadiprotocolinternals.so (that's what kdepimlibs4 link against). If Kopete does not need to actually access KDE PIM data stored in Akonadi, then the Akonadi(qt4) server or any other binary are not needed. We can publish some sort of manual for distributions how to deal with this, but I'm afraid distros will have to figure out the packaging magic to handle that on their own. Dan Now looking at the source kdepimlibs is used for two things in kopete: 1) kpimidentities is used in the bonjour protocol as a fallback to kuser to obtain the users's name and email address for account default values (this is required, although I am not sure it should be) 2) gpgmepp is used by the crypto plugin for crypto things (this is optional, although I am not sure it should be :P) Given that we have no kde4pimlibs source what is the intended solution to this? Cripple kopete and make bonjour optional using a patch, if so why not do that in the repo directly? Or perhaps have every distro figure out which parts of the old kdepimlibs are now defunct with akonadi moved to kf5 and package the rest for compat? (CC'd Pali and Dan; not sure they are subbed) HS -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Your New KDEPIM Release Coordinator
On Thursday, July 30, 2015 11:35:17 PM Jonathan Riddell wrote: Well done Sandro. It's a long shot and I know it's come up before but can I suggest renaming kdepim to Kontact everywhere? Kontact Suite please. Kontact is just the application. Jonathan On Thu, Jul 30, 2015 at 07:29:25PM -0400, Allen Winter wrote: Howdy, Please welcome Sandro Knauß as the new release dude for KDEPIM. I already updated the coordinator list on the techbase wiki page. I'll still be hanging around, trying to help out in my small way as I much as I can. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Fwd: KDE PIM 15.08 releases
Hi all, the remaining KDE PIM modules have been moved by the sysadmins to the requested paths, so KDE PIM should now be releasable. I kindly ask you to include the following repositories in KDE Applications 15.08 release: kde/pim/akonadi kde/pim/akonadi-search kde/pim/gpgmepp kde/pim/kalarmcal kde/pim/kblog kde/pim/kcalcore kde/pim/kcalutils kde/pim/kcontacts kde/pim/kholidays kde/pim/kidentitymanagement kde/pim/kimap kde/pim/kldap kde/pim/kmailtransport kde/pim/kmbox kde/pim/kmime kde/pim/kontactinterface kde/pim/kpimtextedit kde/pim/ktnef kde/pim/syndication kde/pim/akonadi-calendar kde/kdepim kde/kdepimlibs kde/kdepim-runtime Thanks and we are really really sorry about the delay and problems we've caused. Cheers, Daniel -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks·5.11.0
On Sunday, June 07, 2015 01:14:32 AM Antonio Rojas wrote: David Faure wrote: New framework: BluezQt. Qt wrapper for BlueZ 5 DBus API What's the plan wrt bluedevil? Is the 5.3 branch going to be ported to bluez-qt 5.11 or do we have to wait until 5.4? Alternatively would it be possible to provide list of bluedevil commits needed to make it work properly against kf5-bluez-qt 5.11, so that distributions can patch their bluedevil 5.3 to work with the latest Frameworks? Dan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks·5.11.0
On Tuesday, June 09, 2015 03:24:00 PM David Rosca wrote: Hi, On Tue, Jun 9, 2015 at 3:19 PM, Daniel Vrátil dvra...@kde.org wrote: On Sunday, June 07, 2015 01:14:32 AM Antonio Rojas wrote: David Faure wrote: New framework: BluezQt. Qt wrapper for BlueZ 5 DBus API What's the plan wrt bluedevil? Is the 5.3 branch going to be ported to bluez-qt 5.11 or do we have to wait until 5.4? Alternatively would it be possible to provide list of bluedevil commits needed to make it work properly against kf5-bluez-qt 5.11, so that distributions can patch their bluedevil 5.3 to work with the latest Frameworks? Dan Here is a patch for bluedevil 5.3 with bluez-qt 5.11: https://paste.kde.org/pbwfdvuwe Great, thank you! Dan David ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Future frameworks releases
On Monday, June 08, 2015 10:48:42 AM Rex Dieter wrote: David Faure wrote: Hello packagers, The thread Versioning of Frameworks on kde-frameworks-devel has led to the idea that some future frameworks (coming from the kdepim world) would not be part of every Frameworks release, and would have their own versioning scheme. This is at the request of their maintainer, Christian, CC'ed. For example: KF 5.12 would contain KImap 2.1 KF 5.13 would not contain a KImap release KF 5.14 would contain KImap 2.1.1 KF 5.15 would contain KImap 2.2 Would that work for you guys? A little conventional, but ok with me (with fedora packager hat on). We could just easilly ignore the internal version of the library and keep the versioning of our packages to actually match the version of the Frameworks releases (i.e. 5.X). This would avoid user confusion (KDE Frameworks 5.12 update with 5.12, 2.3, 3.4 and 4.5 libraries), as well as keep our tooling simple. Dan -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil Email: dvra...@kde.org Jabber: dan.vra...@kdetalk.net IRC: dvratil on Freenode (#kde, #kontact, #akonadi) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma 5.2 Beta Tars are up for packaging
On Thursday, January 08, 2015 09:59:32 PM šumski wrote: On Thursday 08 of January 2015 18:24:59 Jonathan Riddell wrote: Up now on depot.kde.org in unstable/plasma/5.1.95 sha256sums and tags at http://starsky.19inch.net/~jr/tmp/plasma-5.1.95/5.1.95-release-data New in this release is: muon kde-gtk-config user-manager bluedevil and libbluedevil kscreen kcm-touchpad ksshaskpass sddm-kcm We retain baloo and kfilemetadata which tried to escape to frameworks but got stuck on a GPL requirement. They however change their version number to 5.5.95 in the hope of becoming a Framework when they grow up. user-manager probably won't get a stable release this time, it's features overlap a bit with Account Details https://bugs.kde.org/342631 fixes welcome kcm-touchpad probably won't get a stable release this time, it overlaps with ktouchpadenabler from plasma-workspace, fixes welcome https://bugs.kde.org/342629 kscreen and libkscreen have had their frameworks branches merged into master bluedevil and libbluedevil have not yet been merged into master as there is ongoing work in the kdelibs4 versions of these, please do check if it's sane to release the kf5 versions Some modules are still moving translations around. I'm not sure if baloo and kfilemetadata have correct translations. Happy packaging, release due on Tuesday Some tars have a problem, e.g. plasma-desktop's doc/ cmake foo is wrong, it adds non-existent dirs, Same with khelpcenter: CMake Error at doc/it/CMakeLists.txt:1 (add_subdirectory): add_subdirectory given source khelpcenter which is not an existing directory. ... (lib)bluedevil tars are Qt4/kdelibs4 based and sddm kcm is missing it seems... Cheers, Hrvoje Jonathan -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KF 5.0.0
On Tuesday 01 of July 2014 23:06:56 David Faure wrote: As planned, here's KDE Frameworks 5.0.0. Congratulations I plan on releasing publically on Monday 7. Let me know of any problems. KRunner frameworks is missing a LICENSE or COPYING file with license text. (Sorry I haven't noticed that earlier). Dan BTW the release schedule for the next releases is up at http://techbase.kde.org/Schedules/Frameworks -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: PIM is not good. Would adding an extra RC help?
Hi Albert, On Saturday 05 of April 2014 16:40:24 Albert Astals Cid wrote: ** Please CC me and r-t list, i'm not subscribed to pim list. ** Hello guys, as I hope you all know this Wednesday we are supposed to tag the final release for 4.13. I am sending this email to ask for opinions on the value of adding an extra RC and delaying the 4.13.0 release for at least a week. I'm going to explain why I'd like this to happen. Since the update to 4.13 Beta I've been having lots of CPU and I/O problems in pim related stuff, most notably akonadi_baloo_indexer, akonadi_maildir_resource friends. On every release i've complained on IRC to be told oh yes, we just fixed this thing and will be available on the next release. But here I am, using 4.13 RC and with even KMail closed mysqld+akonadiserver+akonadi_maildir_resource are using 100% of one of my CPU cores and writing/reading around 10MB/s to my slow disks. I find this unacceptable. So yesterday I complained again on IRC, and was told again oh yes, we just fixed this thing and will be available on the next release. Just that this is the last bullet we have for fixing stuff, if it turns out it's like all the previous 3 times i've been told that sentence, we'll end up with a bad 4.13 pim release, and even it may not linked to it (or it may, i have no clue), people will blame Baloo, and developers will get sad and will be less motivated to be on stuff and bugs will be fixed more slowly, you know that, down spiral of sadness for everyone. So I am going to ask: * Are you guys really sure this problem is fixed with the current git code? If so please tell me the repos I have to recompile and I will try seeing if it fixes my problems So you complain about this maildir problem and when I told you the problem was fixed after Akonadi 1.12 was released, you didn't even go and try the fixes, yet you still complain that you have a problem ? Please run Akonadi from latest .12 branch. If the problem is gone, there's no need to delay any release. If you still have the problem, I'm 99% sure it's a problem in Akonadi server and can be fixed in couple days before I do 1.12.1 release which we need to anyway in order to ship top-notch KDE PIM experience in 4.13. If everything is fine on your side, I'll do 1.12.1 on Monday. Cheers, Dan * Do you guys think this is just my problem and I can be just ignored? I can take that too, if you feel like everybody is using kmail 4.13 without any problems and i'm just an outlier with problems I am willing to accept that I'm unlucky and do the release as planned. * Do you guys think adding an extra RC would help? Of course you know where I am if you need me compiling something or giving you extra information about my setup. Cheers, Albert P.S: No, I haven't opened a bug, the reason is that every time i complained i've been told that it had already been fixed, so it seemed not necessary. ** Please CC me and r-t list, i'm not subscribed to pim list. ** ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [kde-release-team] Re: KDE Frameworks 5 TP1 tarballs
On Monday 06 of January 2014 23:13:22 Jonathan Riddell wrote: On Sun, Jan 05, 2014 at 08:43:14PM +0100, šumski wrote: On Sunday 05 of January 2014 12:40:05 David Faure wrote: ... You can find it in kde-build-metadata/dependency-data-kf5-qt5, attached here for convenience. Great, just a few questions ;-) 1) Is it expected that extra-cmake-modules and attica have the versioning scheme as other frameworks? i.e. are they considered as part of KF5 in future? 2) Wrt. co-installability: atm KF5 cannot be installed side by kdelibs4 in same prefix due to file conflicts (e.g. kconfig_compiler, kmailservice, ktelnetservice, some DBus interface files) - is this also longer term plan, or it just hasn't yet been 100% tackled? kmailservice and ktelnetservice are interchangeable binaries, you can use them from either kdelibs of kf5, they work the same. They are interchangeable *now*. This could change in future and break kdelibs. And distributions would still have to solve the packaging problem to have the binaries installed when kdelibs are installed but KF5 not, when KF5 is installed but kdelibs not and to prevent conflict when both are installed. So I'd vote for the 5 suffix here, too. kconfig_compiler and the dbus interface file are developer files which can be mutually exclusive but I think many distro prefer not to do this so they should be renamed. Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Daniel Vrátil KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] kdepimlibs 4.12 versioning problem
On Tuesday 10 of December 2013 19:52:16 Ben Cooksley wrote: Hi everyone, Hi, It would appear that the CMakeLists.txt in kdepimlibs for KDE/4.12 currently has it's version set to 4.12.43, which is totally wrong. More concerningly, it means master has been merged into KDE/4.12 at some point. My checks reveal the commit in question which did this is probably ca3a3857b5ab80497b3318659a7b07bb21560ede. Can someone please verify this is the case? yes, the merge had a conflict in root CMakeLists.txt, probably due to the versions. If it is the case, what action do we need to take? Should we force rewind it back to the last good commit - b299b86fb5e0a7f57d5828297703b9aa676ca5f9 and cherry pick the needed patches? Or just patch up the version number and any other issues it has? gitk shows some mess (commits from 2006-2013 on top of the commit list), so I think it would be better to rewind back to the last good commit and cherry pick the good commits from master. From my kde-commits ML folder (which I don't guarantee is complete on my side, but should be) it looks like there were following commits done into 4.12 after the bad merge: 2d2045de8b6d7e859c18e00be7afa05fdb077381 8089df4bf309f56e17c94e4d3bfe8b8e905e9895 b8e0f33bb3e17d3b24fcd05827243a9f9feec244 Dan Thanks, Ben ___ KDE PIM mailing list kde-...@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ -- Daniel Vrátil KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
