Re: KDE Frameworks 5.29.0
On nedjelja, 4. prosinca 2016. 00:37:52 CET David Faure wrote: > Dear packagers, > > KDE Frameworks 5.29.0 has been uploaded to the usual place. > > New framework: prison > > Public release next Saturday. > > Thanks for the packaging work! kconfig (r129382) breaks compilation of kdevplatform: http://paste.opensuse.org/82016854 Cheers, Hrvoje
Re: KDE Frameworks 5.28.0
On Saturday 05 of November 2016 19:37:23 David Faure wrote: > Dear packagers, > > KDE Frameworks 5.28.0 has been uploaded to the usual place. > > New framework: > * syntax-highlighting >(which ktexteditor now depends upon) > > Prison was supposed to be released but it's not ready so it's not part of > this release at the moment. > > Public release next Saturday. > > Thanks for the packaging work! There seems to be a regression in kconfig. Oxygen fails to build against 5.28.0: [ 78s] CMake Warning at /usr/lib64/cmake/KF5Config/KF5ConfigMacros.cmake:75 (message): [ 78s] Couldn't read the "File" field in [ 78s] /home/abuild/rpmbuild/BUILD/oxygen-5.8.3/liboxygen/oxygenactiveshadowconfiguration.kcfgc [ 78s] Call Stack (most recent call first): [ 78s] liboxygen/CMakeLists.txt:43 (kconfig_add_kcfg_files) [ 78s] [ 78s] [ 78s] CMake Error at /usr/lib64/cmake/KF5Config/KF5ConfigMacros.cmake:87 (message): [ 78s] oxygenactiveshadowconfiguration.kcfg not found; tried in [ 78s] /home/abuild/rpmbuild/BUILD/oxygen-5.8.3/liboxygen and [ 78s] /home/abuild/rpmbuild/BUILD/oxygen-5.8.3/build/liboxygen [ 78s] Call Stack (most recent call first): [ 78s] liboxygen/CMakeLists.txt:43 (kconfig_add_kcfg_files)
Re: Odg: KDE Frameworks 5.25.0
On Monday 08 of August 2016 07:35:19 Martin Graesslin wrote: > On Monday, August 8, 2016 6:19:01 AM CEST hrvoje.sen...@gmail.com 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! > > > > There's a build cyrcle this release: kglobalaccel needs kio, kio needs > > kxmlgui, kxmlgui needs kglobalaccel… > > That should be fixed by b2375f1a8722632630f1e5d72d96c401c5675318 - the KIO > dependency was removed. Indeed, sorry for the noise. Git packaging hasn't been adjusted for that change, so the kio dep got sneaked into stable. Cheers, Hrvoje > Cheers > Martin
Re: Plasma 5.7.0 tars
On Thursday 30 of June 2016 16:14:18 David Edmundson wrote: > Plasma 5.7 tars are up on depot for packagers > > Release is due on Tuesday. > > David At least libkscreen and plasma-nm seem to come from Plasma/5.6 branch... Cheers, Hrvoje ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KActivities repository split
On Thursday 18 of February 2016 16:20:48 Ivan Čukić wrote: > Resending this to additional MLs. > > Hi everyone, > > As previously announced, KActivities has been split into a few > separate repositories. This mail is mostly intended to notify our dear > packagers of the change, and the plan for the transition period. > > KActivities framework 5.19 (as released a few days ago) contains > everything that it used to, this is about the next version - 5.20. > > This is the former setup: > -- > > Everything was contained in kde:kactivities, and distributions used to > split it into different packages. > > > This is the setup now: > --- > > - kde:kactivities - contains the framework and QML includes, it will > soon become a tier1 integration framework > - kde:kactivitymanagerd - contains the activities service and its plugins > - kde:kactivities-stats - the (first-to-be-released-with-5.20) > framework for getting the usage statistics collected by the activities > service > > - KIO module from kde:kactivities will be moved to kio-extras > - KCM module will be moved to plasma-desktop/kcms > - fileitem plugin will also need a new home (any ideas?) > > > The release schedules: > - > > kde:kactivities and kde:kactivities-stats will follow kde frameworks > release schedule, other components will follow Plasma's release > schedule. > > How to handle this transition is explained below. There is one case that doesn't seem to be covered. How to handle update of Plasma to 5.6 with latest KF5 release (5.19.0)? Kactivitymanagerd repo contains overlapping files/binary with kactivities framework. Plasma-desktop contains overlapping files/kcms/imports over kactivities framework. If we update kactivities to master, we then lose kio plugins. Even if downstream removes conflicting files, this effectively means plasma 5.6 needs to conflict (on a packaging level) with kactivities 5.19 (version which is AFAICS hard requirement). Or we should avoid packaging 5.6 until we have KF 5.20.0? Cheers, Hrvoje ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: thumbnailers in KDE Applications 15.12
On Monday 09 of November 2015 20:22:30 Albert Astals Cid wrote: > So Kai fixed ffmpegthumbs, i guess we're out of luck for the other 3 for > KDE Applications 15.12? > > No kdemultimedia nor kdegraphics nor kdesdk release team representative to > ask for help either, sad. Hi Albert, sorry i forgot about your mail, otherwise would fix the problem before. Mplayerthumbs is still in limbo though as that one isn't ported yet to frameworks... Cheers, Hrvoje > Cheers, > Albert > > El Thursday 05 November 2015, a les 00:21:36, Albert Astals Cid va escriure: > > ffmpegthumbs master > > kdegraphics-thumbnailers master > > kdesdk-thumbnailers master > > mplayerthumbs master > > > > Are still based in kdelibs4. > > > > Is anyone going to care enough and make master be based in KF5 so users > > of Dolphin actually get thumbnails? > > > > Remember the KDE Applications 15.12 feature freeze is in November 11, > > i.e. you have less than one week to do the port (if one does not exist), > > check it works and commit it to master. > > > > 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
Re: Qt 5.5 for Plasma 5.5
On Friday, October 16, 2015 02:41:49 PM Jonathan Riddell wrote: > Plasma is wanting to, and infact already is, depending on Qt 5.5, our > release is due in December, is this a problem for distros? Not a problem for openSUSE. Cheers, Hrvoje > Jonathan > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team 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: Kamoso and first Purpose release
On Monday, September 28, 2015 06:41:27 PM Rex Dieter wrote: > On 09/28/2015 11:32 AM, Jonathan Riddell wrote: > > Kubuntu packages are in wily ready for release in a month. > > > > It helps packagers to keep a sequential version number scheme e.g. > > 2.9.80, 2.9.90, 3.0.0 etc > > I'm also seeing an icon conflict between purpose-1.0 and > kdevplatform-1.7.x, they both provide > /usr/share/icons/hicolor/128x128/apps/reviewboard.png > /usr/share/icons/hicolor/16x16/apps/reviewboard.png > > How are others resolving this? We've just rm'ed them from purpose in openSUSE, as plugin is to be used with kdevelop anyway(?). At least commit that adds the plugin suggests this. Cheers, Hrvoje > -- Rex > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team 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: kservice v5.14.1 release
On Wednesday, September 16, 2015 10:57:31 PM David Faure wrote: > I made a bugfix release for kservice in order to fix an upgrade bug due to > a sycoca file format change. https://bugs.kde.org/show_bug.cgi?id=352756 Hi David, sftp access works fine, but seems public is not allowed to enter http://download.kde.org/stable/frameworks/5.14/ path. Cheers, Hrvoje > kservice v5.14.1 > cb25732e88f43cea8ae6d852d165d1dac2844f74 > 44fa7c3bd52470459cdc924b19393d6c39741c2749e87676126cb7071da9b203 > sources/kservice-5.14.1.tar.xz > > With thanks to Hrvoje Senjan for the fast report of the issue and his help > with the investigation. > > > > Another thing: if you try to compile kdesignerplugin-5.14.0 with Qt 5.4, > you'll get a compile error. In that case, grab commit 6cbf534. I can make > a new tarball if someone prefers, of course. 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.14.0
On Saturday, September 05, 2015 12:12:50 PM David Faure wrote: > Dear packagers, > > Here's KDE Frameworks 5.14.0. > > New frameworks: none this time. > > Public release on Friday. > > Thanks for the packaging work! Hi David, the SiC from review 124919 is still unresolved... I guess we need you to decide whether this kind of change is OK. Cheers, Hrvoje 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.4 beta out now
On Tuesday, August 11, 2015 12:20:29 PM Jonathan Riddell wrote:
9 days until final tag
https://www.kde.org/announcements/plasma-5.3.95.php
@distros
If you try to make the startplasmacompositor work, you'll need to disable OOM
protection in kinit package, somehow things go wrong with it on Wayland
session.
Cheers,
Hrvoje
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index c880604..35974f8 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -7,7 +7,7 @@ if (CMAKE_SYSTEM_NAME MATCHES Linux)
else()
message(STATUS kdeinit wrapper uses setuid-root to protect kdeinit from misguided Linux OOM killer)
endif()
-set(KDEINIT_OOM_PROTECT 1)
+set(KDEINIT_OOM_PROTECT 0)
endif ()
configure_file(config-kdeinit.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config-kdeinit.h)
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.13.0
On Tuesday, August 04, 2015 02:53:52 PM David Faure wrote:
Dear packagers,
Here's KDE Frameworks 5.13.0, with a bit of delay due to baloo.
New frameworks: kfilemetadata and baloo.
Hi David,
baloo is missing:
if (IS_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/po)
ki18n_install(po)
endif()
snippet in main CMakeLists.txt, hence the translations aren't installed.
Cheers,
Hrvoje
Public release on Saturday.
Thanks for the packaging work!
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.8
On Saturday 07 of March 2015 20:05:31 David Faure wrote: On Saturday 07 March 2015 19:59:09 David Faure wrote: On Saturday 07 March 2015 19:32:07 šumski wrote: On Saturday 07 of March 2015 17:24:17 David Faure wrote: Dear packagers, Here's KF 5.8.0 New frameworks: kpeople and kxmlrpcclient. A few things regarding kpeople: It requires Qt 5.3, rest of KF5 5.2; Fixed (although I don't have a way to test that it does compile with Qt 5.2) it uses strange version 0.5.0, rest of KF5 uses the same version as release; Fixed. it uses DATA_INSTALL_DIR/$wanted_dir, rest of KF5 uses KDE_INSTALL_DATADIR_KF5/$wanted_dir (this is not about variable name, but location on the filesystem) Hmm, KAuth still uses KF5_DATA_INSTALL_DIR... but yeah indeed. Fixed. New tarball: kpeople v5.8.0-rc2 fef9dcd47805fe15f044342fd3f5f271b5575806 5d4719cd6200fb636b8176eebfaac2436cf6ef358486328cbf64cdf020c88514 sources/kpeople-5.8.0.tar.xz Thanks for fixing! There is though one more issue with both two new frameworks. They contain the translations, but relevant cmake foo (ki18n_install) is missing ... Cheers, Hrvoje 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: 5.2.1 tars for packagers
On Thursday 19 of February 2015 18:00:59 Jonathan Riddell wrote: 5.2.1 tars are up on depot for packagers http://starsky.19inch.net/~jr/tmp/5.2.1-release-data Harald has been lovely and done a lot of work on releaseme which makes the tars, please check over for regressions. kdesu manpage from kde-cli-tools is somehow not getting installed. baloo and kfilemetadata have downgraded the version numbers from 5.6.0 to 5.2.1. all docs now go to en_US subdir instead of en, this is wanted behavior? Cheers, Hrvoje Release is due on Tuesday Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team 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.7.0 release
On Sunday 08 of February 2015 18:49:30 David Faure wrote: Dear packagers, Here is KDE Frameworks 5.7.0 Public release on Thursday. Main change affecting packagers: dependencies for kglobalaccel have changed a lot, due to integrating the daemon into it. Regarding this, looks like the framework is using Qt translation system, and daemon KI18n, but only ecm_install_po_files_as_qm is utilized in CMakeLists... Cheers, Hrvoje Changelog attached. 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.2 Beta Tars are up for packaging
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, (lib)bluedevil tars are Qt4/kdelibs4 based and sddm kcm is missing it seems... Cheers, Hrvoje Jonathan 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.6.0 release
On Saturday 03 of January 2015 14:12:19 David Faure wrote: Here's KDE Frameworks 5.5.0 Public release on Thursday. Two new frameworks in this release: KPackage and NetworkManagerQt Jan, Jonathan, would it be possible to create a plasma-nm hotfix release, as plasma-nm 5.1.2 doesn't build with NetworkManagerQt 5.6.0 ? Cheers, Hrvoje 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: Fwd: kdeedu-data
On Sunday 26 of October 2014 22:53:57 Jeremy Whiting wrote:
Sumski,
Yes, you're correct, that is an issue. We are considering a couple of
fixes for that as outlined below.
1. Merge khangman's frameworks branch to master, so it will be qt5/kf5
based for the upcoming release, This way khangman and kanagram (the
two applications that expect these files in kdeedu-data) will be able
to find them fine.
2. Make kdeedu-data install files into share/apps and modify
libkeduvocdocument to also look for the files there also. This way
whether 1 happens or not both applications will be able to find the
files just fine.
3. Install data with both libkdeedu and kdeedu-data; as i mentioned, the
locations won't overlap anyway ;-)
I'll make 2 happen now, then look at what's needed in khangman itself
to possibly do 1 above also by release, we'll see.
That also sounds good, thanks!
Cheers,
Hrvoje
thanks,
Jeremy
On Thu, Oct 23, 2014 at 12:08 PM, šumski hrvoje.sen...@gmail.com wrote:
On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
-- Forwarded message --
From: Jeremy Whiting jpwhit...@kde.org
Date: Thu, Oct 23, 2014 at 8:31 AM
Subject: kdeedu-data
To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org
Hey packagers,
A quick heads up about kdeedu-data strangeness.
The upcoming KDE Applications 14.12 release will have some
applications based on kdelibs4 and others based on kf5. Because some
applications that use libkdeedu/libkeduvocdocument are going to be
still based on kdelibs4 while others have already been ported to qt5
and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
released. Because both used to contain a handful of kvtml files, we
moved them out into kdeedu-data which both libkdeedu and
libkeduvocdocument should depend on (or at least khangman(kdelibs4)
and kanagram(libkeduvocdocument) should depend on in order to run.
Now kdeedu-data uses ecm instructions to build like other kf5 based
applications. Is that going to be a problem to make both khangman and
kanagram run time depend on these packages, while kdeedu-data at build
time requires ecm to build?
I'm open to other solutions, but this is the best we could come up
with at this time.
But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with
e-c-m language? IOW, by default, kde4's ${DATA_INSTALL_DIR} =
share/apps, with e- c-m it's share...
Cheers,
Hrvoje
thanks,
Jeremy
___
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
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
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: Fwd: kdeedu-data
On Sunday 26 of October 2014 22:53:57 Jeremy Whiting wrote:
Sumski,
Yes, you're correct, that is an issue. We are considering a couple of
fixes for that as outlined below.
1. Merge khangman's frameworks branch to master, so it will be qt5/kf5
based for the upcoming release, This way khangman and kanagram (the
two applications that expect these files in kdeedu-data) will be able
to find them fine.
2. Make kdeedu-data install files into share/apps and modify
libkeduvocdocument to also look for the files there also. This way
whether 1 happens or not both applications will be able to find the
files just fine.
I'll make 2 happen now, then look at what's needed in khangman itself
to possibly do 1 above also by release, we'll see.
Err, sorry, i think this will also cause problems, as some distros customize
apps dir to e.g. share/kde4/apps...
Cheers,
Hrvoje
thanks,
Jeremy
On Thu, Oct 23, 2014 at 12:08 PM, šumski hrvoje.sen...@gmail.com wrote:
On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
-- Forwarded message --
From: Jeremy Whiting jpwhit...@kde.org
Date: Thu, Oct 23, 2014 at 8:31 AM
Subject: kdeedu-data
To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org
Hey packagers,
A quick heads up about kdeedu-data strangeness.
The upcoming KDE Applications 14.12 release will have some
applications based on kdelibs4 and others based on kf5. Because some
applications that use libkdeedu/libkeduvocdocument are going to be
still based on kdelibs4 while others have already been ported to qt5
and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
released. Because both used to contain a handful of kvtml files, we
moved them out into kdeedu-data which both libkdeedu and
libkeduvocdocument should depend on (or at least khangman(kdelibs4)
and kanagram(libkeduvocdocument) should depend on in order to run.
Now kdeedu-data uses ecm instructions to build like other kf5 based
applications. Is that going to be a problem to make both khangman and
kanagram run time depend on these packages, while kdeedu-data at build
time requires ecm to build?
I'm open to other solutions, but this is the best we could come up
with at this time.
But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with
e-c-m language? IOW, by default, kde4's ${DATA_INSTALL_DIR} =
share/apps, with e- c-m it's share...
Cheers,
Hrvoje
thanks,
Jeremy
___
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
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
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: Fwd: kdeedu-data
On Sunday 26 of October 2014 23:18:47 Jeremy Whiting wrote:
Ugh, I saw that on fedora recently. Why do distros do that? I guess
those same distros also patch KStandardDirs to look for files there ?
Or set KDEHOME or something so it will look there?
Nope, it is enough to pass wanted DATA_INSTALL_DIR, then the value is used as
define in kstandarddirs...
At any rate, with 2 done and posted to reviewboard. If I set KDEHOME
to /usr/local (my kf5 prefix here) qt4 based khangman works fine here
using the files installed by kdeedu-data into
/usr/local/share/apps/kvtml/en . At any rate I'll do all I can to get
khangman's frameworks port ready by the wed freeze so that won't be an
issue anymore either.
thanks,
Jeremy
On Sun, Oct 26, 2014 at 4:04 PM, šumski hrvoje.sen...@gmail.com wrote:
On Sunday 26 of October 2014 22:53:57 Jeremy Whiting wrote:
Sumski,
Yes, you're correct, that is an issue. We are considering a couple of
fixes for that as outlined below.
1. Merge khangman's frameworks branch to master, so it will be qt5/kf5
based for the upcoming release, This way khangman and kanagram (the
two applications that expect these files in kdeedu-data) will be able
to find them fine.
2. Make kdeedu-data install files into share/apps and modify
libkeduvocdocument to also look for the files there also. This way
whether 1 happens or not both applications will be able to find the
files just fine.
I'll make 2 happen now, then look at what's needed in khangman itself
to possibly do 1 above also by release, we'll see.
Err, sorry, i think this will also cause problems, as some distros
customize apps dir to e.g. share/kde4/apps...
Cheers,
Hrvoje
thanks,
Jeremy
On Thu, Oct 23, 2014 at 12:08 PM, šumski hrvoje.sen...@gmail.com wrote:
On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
-- Forwarded message --
From: Jeremy Whiting jpwhit...@kde.org
Date: Thu, Oct 23, 2014 at 8:31 AM
Subject: kdeedu-data
To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org
Hey packagers,
A quick heads up about kdeedu-data strangeness.
The upcoming KDE Applications 14.12 release will have some
applications based on kdelibs4 and others based on kf5. Because some
applications that use libkdeedu/libkeduvocdocument are going to be
still based on kdelibs4 while others have already been ported to qt5
and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
released. Because both used to contain a handful of kvtml files, we
moved them out into kdeedu-data which both libkdeedu and
libkeduvocdocument should depend on (or at least khangman(kdelibs4)
and kanagram(libkeduvocdocument) should depend on in order to run.
Now kdeedu-data uses ecm instructions to build like other kf5 based
applications. Is that going to be a problem to make both khangman and
kanagram run time depend on these packages, while kdeedu-data at
build time requires ecm to build?
I'm open to other solutions, but this is the best we could come up
with at this time.
But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken
with e-c-m language? IOW, by default, kde4's ${DATA_INSTALL_DIR} =
share/apps, with e- c-m it's share...
Cheers,
Hrvoje
thanks,
Jeremy
___
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
___
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
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
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: Fwd: kdeedu-data
On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
-- Forwarded message --
From: Jeremy Whiting jpwhit...@kde.org
Date: Thu, Oct 23, 2014 at 8:31 AM
Subject: kdeedu-data
To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org
Hey packagers,
A quick heads up about kdeedu-data strangeness.
The upcoming KDE Applications 14.12 release will have some
applications based on kdelibs4 and others based on kf5. Because some
applications that use libkdeedu/libkeduvocdocument are going to be
still based on kdelibs4 while others have already been ported to qt5
and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
released. Because both used to contain a handful of kvtml files, we
moved them out into kdeedu-data which both libkdeedu and
libkeduvocdocument should depend on (or at least khangman(kdelibs4)
and kanagram(libkeduvocdocument) should depend on in order to run.
Now kdeedu-data uses ecm instructions to build like other kf5 based
applications. Is that going to be a problem to make both khangman and
kanagram run time depend on these packages, while kdeedu-data at build
time requires ecm to build?
I'm open to other solutions, but this is the best we could come up
with at this time.
But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with e-c-m
language? IOW, by default, kde4's ${DATA_INSTALL_DIR} = share/apps, with e-
c-m it's share...
Cheers,
Hrvoje
thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
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: Fwd: Plasma Framework problems
On Sunday 12 of October 2014 11:58:44 David Edmundson wrote: I'll report back when I've confirmed this and then we can work out how we proceed. Reverting a3932843386a29faa3c62bf2934a173a3781d56c does indeed make everything work. Assuming we don't have a time machine our options are: - revert this commit and release plasma-framework 5.3.1 really quickly Please go with this option... - communicate the breakage. Plasma 5.1 is out soon anyway IMO it is not at all relevant when release of one of p-f's consumers would be - unless you really want to move it to Workspace umbrella. Cheers, Hrvoje 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.0.1 tars
On Friday 08 of August 2014 17:44:39 Jonathan Riddell wrote: Tars are up now on starsky and coming soon to depot.kde.org http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/ http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/5.0.1-release-data Changelog: http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/ChangeLog-5.0.1 plus lots of translations Please check they are all sane and get packaging, release expected on Tuesday KFilemetadata tar comes from 4.x branch - haven't checked the rest yet. Cheers, Hrvoje Jonathan ___ Plasma-devel mailing list plasma-de...@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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.0.1 tars
On Friday 08 of August 2014 19:02:23 šumski wrote: On Friday 08 of August 2014 17:44:39 Jonathan Riddell wrote: Tars are up now on starsky and coming soon to depot.kde.org http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/ http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/5.0.1-release-data Changelog: http://starsky.19inch.net/~jr/tmp/plasma-5.0.1/ChangeLog-5.0.1 plus lots of translations Please check they are all sane and get packaging, release expected on Tuesday KFilemetadata tar comes from 4.x branch - haven't checked the rest yet. Same with Baloo and LibKScreen... Cheers, Hrvoje Jonathan ___ Plasma-devel mailing list plasma-de...@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 of April 2014 17:24:42 Àlex Fiestas wrote: ... So with frameworks I think we can compromise with something like last 5 releases and turn off auto reporting for anything older than that (this is just an example). This essentially means distros (non-rolling ones at least) would always be out of date. Since the distro freeze kicks, until the first update would be ready, it would already pass approximately time you mention. So distro's would be always catching up, at best 2 releases behind. And this best case scenario is only under the condition that distro's could get policies bypassed for the sake of KF5. Which i doubt. At least in openSUSE case, and from what i read Debian and Kubuntu also. Libraries are not Web Browser. While i understand what do you want and try to accomplish, and as Scott indicated, certainly distro's won't and can't say what you do with the software you write - i really think this release schedule is not suited at all for 'release' distro's and their users. Distros will try their best, but i also wonder how will bugzilla situation look. If we pull down bugfixes, w/o version updates (which is atm most likely scenario), how will devs know which patches did specific distro add? (additionally, DrKonqi is currently lacking bugzilla integration, so it decreases the options to even report bugs) Also, it would be possible that all the fixes between the version bumps are backported, but since the version is bellow accepted one, no dice for that user/report - users wont know which patches they have, they'll just see version number. If we do version updates, we need to update whole of KF5. Then the question of external dependencies arises. I can hardly believe that those wont be changed for the lifetime of KF5. (and i also wouldn't want frozen libraries for 5,6,7 years!) Then we also need to make sure e.g. that latest KCoreAddons don't trigger strange behavior in older release of Plasma. (i doubt that master KF5 user/contributor will use this combo) This is concern now when we only have one 'external' alpha release, consisting of few repos, which depends on KF5. When the Apps port, and hopefully, KF5 spreads more then kdelibs where spread, i can imagine even bigger headaches. Then we'll all really need to become rolling distros to have any relevance (even though i personally for my use-case wouldn't mind that ;-) our release managers would kick us out). From all the suggestions, imho having LTS release every X months would make things much easier to cope with. Cheers. Cheers, Hrvoje 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: KF5 alpha2
On Saturday 01 of March 2014 19:17:15 David Faure wrote: I just uploaded the tarballs for KF5 alpha2, numbered 4.97.0. Note: kprintutils is no more, kwallet-framework was renamed kwallet, and some new frameworks have been added. Somehow kactivities tar contains 4.96.0 ... (the rest built fine) Cheers, Hrvoje 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: KF5 alpha2
On Sunday 02 of March 2014 03:28:06 šumski wrote: On Saturday 01 of March 2014 19:17:15 David Faure wrote: I just uploaded the tarballs for KF5 alpha2, numbered 4.97.0. Note: kprintutils is no more, kwallet-framework was renamed kwallet, and some new frameworks have been added. Somehow kactivities tar contains 4.96.0 ... (the rest built fine) Hm, find_package (ECM 0.0.9 REQUIRED NO_MODULE) ... set(KF5_VERSION 4.96.0) but i see you bumped both in master. Maybe tar was created from frameworks branch? Cheers, Hrvoje 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: KF5 alpha 1
On Sunday 09 of February 2014 10:22:54 David Faure wrote: Here are two more modules, which we realized were missing :-) ... Ok, those also built ;-) There is one minor 'issue' with plasma framework, both PlasmaQuick and Plasma libraries have 'internal' versioning at 5.0, instead of relying on toplevel @KF5_VERSION@. This would be fine otherwise, but every other lib has SO# at 4. (I did notice the comment in CMakeLists about 'Plasma team taking care of the version') I don't know is that worth a respin... Cheers, Hrvoje 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: KF5 alpha 1
On Thursday 06 of February 2014 23:26:53 David Faure wrote: Hello dear packagers, I have uploaded KF5 alpha 1, also known as 4.96.0, to the usual location. The sha1s are in the attached email. The plan is to release Tuesday 11. Hi David, fwiw, everything built fine here at openSUSE =) Cheers, Hrvoje 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: ECM version changed (Re: KDE Frameworks 5 TP1 tarballs)
On Saturday 11 of January 2014 11:15:47 Michael Palimaka wrote: ... Any news on renaming the remaining binaries? Just to follow up on this - Jonathan has meanwhile been quite busy =) Attica is now adjusted so it can co-exist with Qt4 version, and we have 3 binaries left, which all have opened reviews for a rename. However, since the TP1, we have one new - kwalletd (and libkwalletbackend library). I've now slightly extended the wiki page (data and binaries sections) for interested parties ;-) Cheers, Hrvoje Best regards, Michael ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager 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 TP1 tarballs
On Tuesday 07 of January 2014 18:13:12 Kevin Kofler wrote: And also library symlinks, or do all the libraries have different unversioned names now? Libraries themselves are completely renamed: only attica's symlink and pc file are of the same name as Qt4 version (the so is bumped to 1.0.0 when built against Qt 5, and includedir can be 'constructed' via CMake ;-) and polkit- qt-1, where the libs have both the same name and version on both Qt4 and 5 case (though polkit-qt-1 is optional). Note that i haven't 100% checked about DATA stuff - it can also be put to a different dir - but that requires both buildtime and runtime export of XDG_DATA_DIRS... Cheers, Hrvoje 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 TP1 tarballs
On Tuesday 07 of January 2014 17:38:55 Jonathan Riddell wrote: Voila (for attica) https://git.reviewboard.kde.org/r/114899/ Great! =) Will try it ASAP, (needs also according changes in KNewStuff, and other indirect deps, yes?) Cheers, Hrvoje Jonathan ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager 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 TP1 tarballs
On Tuesday 07 of January 2014 19:08:39 Kevin Kofler wrote: Ouch, that really needs fixing! How many client modules will be affected by a rename? In Qt/KDE 4 land, from the stuff packaged in Fedora 18, I see kdelibs (KAuth), polkit-kde and razorqt- policykit-agent, but obviously we'd rename the Qt 5 version, not the Qt 4 one. Right now - just KAuth has an optional requirement. It builds fake/stub backend without polkit-qt-1. And remembered one more lib - which is required for KF5/Qt5 kde-workspace (for workspace it was already made clear it will not be adjusted for same-prefix- existence as kdelibs4/Qt4 version) - qimageblitz. That one is in the same situation as attica. Cheers, Hrvoje Kevin Kofler 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 TP1 tarballs
On Monday 06 of January 2014 16:54:13 Allen Winter wrote: rename then to kconfig_compiler5, kmailservice5, ktelnetservice5 ... ? Sounds good to me - as Kevin noted, would be much better to do that upstream, then to see all distros carry the same patches before the first release is even made ;-) This would leave KAuth's DBus configuration file + Solid's, KGlobalAccel's, KJobWidgets, KNotifications and KWallet DBus interface files left to adjust. (Yes, i'm aware of the https://community.kde.org/Frameworks/Coinstallability page - but libraries are either co-installable, or not, i.e. 'they are co- installable if you put certain files in package A, others in package B, then you conflict them, then...' is not a valid argument IMHO, especially for source based distros like Gentoo, or distros that don't split devel packages, like Arch) Cheers, Hrvoje 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 TP1 tarballs
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? Cheers, Hrvoje 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: Dependency cycle with nepomuk-core mobipocket
On Sunday 03 of November 2013 22:42:55 Albert Astals Cid wrote: No really, the only thing i can think of is moving the okular mobipocket plugin code over to the okular repo, that should untangle the loop. That sounds good :-) On top of that, qmobipocket is now installed as unversioned library. Fixed that. Thanks! 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
Dependency cycle with nepomuk-core mobipocket
Just a small heads up, since 4.12 beta is soon, and as it seems nobody yet noticed. With 4.12, as is the current state, there will be a cycle between two mentioned projects/packages, and that seems wrong to me ;-) qmobipocket is now (in master) an optional dep for nepomuk-core, but mobipocket itself requires Okular, which has optional KActivities build requirement, and KActivities have nepomuk-core as build requirement. A vicious circle ;-) On top of that, qmobipocket is now installed as unversioned library. 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: 4.9.1 tarballs available (for packagers)
On Monday 03 of September 2012 17:26:19 Raphael Kubo da Costa wrote: kactivities appears to have stopped installing the sqlite plugin. Looking at the build system, whether the sqlite, nepomuk, activityranking and dummy plugins should be built or not depends on the value of the KACTIVITIES_BUILD_*_PLUGIN properties, which are defined in service/CMakeLists.txt but are not set anywhere. Yes, this broke it: http://quickgit.kde.org/index.php?p=kactivities.gita=commith=26d8a08a032e9409906f4685d4d8bda791abec62 KACTIVITIES_BUILD_NEPOMUK_PLUGIN isn't anywhere set. 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
