Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Wednesday 25 May 2011, Will Stephenson wrote: Please report any important packaging issues or must-fix bugs to the release- t...@kde.org mailinglist. kdepim needs 6b44080e, compile fix. Hi Will, sorry, your email came too late. Will be included in beta2. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26-05-2011 02:02, Jorge Manuel B. S. Vicetto wrote: Hi again Dirk. On 25-05-2011 09:23, Dirk Mueller wrote: On Tuesday 24 May 2011, Jorge Manuel B. S. Vicetto wrote: I'm sending this email again as I didn't hear back from anyone and the tarballs were published. Thanks for letting me know, I've added it to the uploaded directory now. While bumping the packages here (I'm still half way through), I've now come across krosspython. Looking at our live ebuild and at the kdebindings tarball, I think you may not be aware it was moved to a new repo - git://anongit.kde.org/kross-interpreters Can you please create the krosspython tarball? We need it to be able to bump superkaramba and complete kdeutils. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5K08AAoJEC8ZTXQF1qEPffEP/3u+NxnZnx2Gl8Nj22LHd3lF uhnVf0NA816jbHm0/bDx1gTy2O4AWHYnDlmLNkYfWRqHh4IyUf5dbSLD7vibkZEn TzqSFHl4Mgo+0jtEchs/VSsMECAKOOkixkA5A9LznCDtIgysM8mfUth88iy1SQZ6 A5Kc4nam7CNo+pZ9E2LuJwgcVAeXxfR4Duicd8OTYhR2jwtR3xEozzUx0eG7at4R hftoFR/SE31cumpJs359S1+4ejv9Ztp8Vgxhn+RTqhpjLtEkQrPZzDK2GJwFRvdP BKTumzXuLB8BFnJokKGYeN0UPr/MJ46tNCbaWGjF53Iop4dBDGBGfVPiYrxbpEct NLvgbKqLCBml6RCZIkYoMiQ4pQRbWYu+x+lx7S1cIA8L84FF3LXCtCsS2bhIUEiO xb1+ZlwZGbhYDMGMUiLVutMEgppEnIIQmEfX8i5vXbk+/b7NoT8yWpb0RKav2s96 9vW9wVL7b5azWPZcelfAbQ6pWspPKQH+RtVIin3K3mGQZluyqNARIpijkKt+i2Uk WesUoqdrNH+n8NJMAHVWNLNEL9N8EPUamHk6tAAxkksXeNmN3G+iYctoKsVeiSuz zr+41XZWb+f/QEBVScBTPmKTDjPp4+gpRHK3Wjho5z0D/7bfZvNC/XI+lXDrAOA9 ao0vmntBr7bdzESCVex4 =jzj1 -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31-05-2011 08:56, Jorge Manuel B. S. Vicetto wrote: On 26-05-2011 02:02, Jorge Manuel B. S. Vicetto wrote: Hi again Dirk. On 25-05-2011 09:23, Dirk Mueller wrote: On Tuesday 24 May 2011, Jorge Manuel B. S. Vicetto wrote: I'm sending this email again as I didn't hear back from anyone and the tarballs were published. Thanks for letting me know, I've added it to the uploaded directory now. While bumping the packages here (I'm still half way through), I've now come across krosspython. Looking at our live ebuild and at the kdebindings tarball, I think you may not be aware it was moved to a new repo - git://anongit.kde.org/kross-interpreters Can you please create the krosspython tarball? We need it to be able to bump superkaramba and complete kdeutils. I'm sorry for poking again, but can we please have a status check on the kdebindings module? I was just poked about it and noticed that there seems not to be any tarballs for csharp, krossjava and ruby, besides krosspython. I also noticed that smoke seems to have been split in 3 tarballs (smokegen, smokekde and smokeqt) and perl on 2 tarballs (perlkde and perlqt). Are the latter 2 meant to be split or should each be a single tarball? Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5LHXAAoJEC8ZTXQF1qEPJoUQAKgsVeobusBoCIuaoD3GtgH6 J7Xli2k9CdIUAq5CK1MAkgZawyFoXPfv7hXXjuPAx8q0lIqGcU95V1ap3anwpGL6 jSbpr+940PAyeWrw0+Fk+2FooIKAliczNTxBKwj7r7/5HcMtjUWlPXOTF9LSprTz NOGxvIbeZoSJOiX9khMxZAPar79EFmQ2FzOpm8FGrcuMNrJqNudmambIAjx+nKFy rZi3uJT0pjV1aBiLMHusL+DpdEnNwSGIyh0668xGNZE1lm4nVUk14tMQbD/+g8Ot w5HkjY0CjMJk1I39XcYs4oJWG4aF4CQzEaOPfjcO1/oQCR6KfcacaYkHDXsRsM3T 79PpJbrwrjPLdgZb6dftKmf0xS/mR2oCj77/aU4Bq8atNGVAPfs2o6cG3KiZ2v75 ykIQR4lo2tzOh5UllygENhB5oaNgzy+LqDfza3b3/rXxAd6MQaHkFMyxfZkISiOW hfi8JhXQ+lbGEI6WmMEEdiFuY1q8JI4AcxrCndCvnemZWkvpPOmEXbjnIvbL9oOh TMYDiWHUV/jx0dPpoVa0hdimEe7+xg0wgG+TIHCi9WXxb+6YlHQdjS67V4TYC69r VgCQHPFLyKF2xGiTcAEHMptl6TtZ7wFj9Fc8wGpHRs8X+pFeAAjXL3IWlVdizLvf 2XTwF0eS5f8PdOpDw8z3 =dCSE -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Wednesday 25 May 2011, Alexander Neundorf wrote:
On Wednesday 25 May 2011, Eric Hameleers wrote:
On Tue, 24 May 2011, Alexander Neundorf wrote:
On Sunday 22 May 2011, Alexander Neundorf wrote:
On Sunday 22 May 2011, Kevin Kofler wrote:
On Sunday 22 May 2011, Alexander Neundorf wrote:
So, what I'm doing right now for kdesupport is to create one
CMakeLists.txt, which contains all the contained projects (automoc4,
phonon, attica, akonadi, ...) via the externalproject()-feature from
CMake.
What it does, is it gets and updates all the sources from git,
configures, builds and installs them.
So it feels almost like it did before.
Unfortunately, this is of no use for us packagers because we are
banned by policy (and at least in Fedora, this is enforced by the
build system) from downloading stuff during build. We can only work
from tarballs. (If we want to package a snapshot, we have to check
it out, tar it, then package the resulting tarball.)
I'll see whether I can do something for this.
Alex
Looks good :-)
I have here now a CMakeLists.txt for kdesupport, which downloads
everything from git and builds it.
But on make package, it creates basically a package of the downloaded
sources together with a matching CMakeLists.txt (which then doesn't
download, but just uses the already present sources).
I.e.
you could do cmake srcdir , then make package (or maybe some
custom target), and then you'd have a tgz of kdesupport which you can
unpack and build anywhere.
Would that help your case ?
Alex
Hi Alex
Absolutely!
I have no issues with creating a comprehensive tarball myself. In
fact, if this allows me to build a single monolithic kdesupport
package again, then you provide what I need.
I think so.
There may be issues with installing the built stuff, we'll see.
(currently it is installed during the build, so you need write permissions
for the install directory, which is probably ok for developers, who have
their system probably anyway set up in such a way that they can install as
normal user, not sure for packagers).
Where should I put that stuff ?
git, svn, somewhere else ?
Attached is what I have so far for kdesupport.
There are still issues because some of the projects in kdesupport try to
install outside CMAKE_INSTALL_PREFIX by default, those projects have to be
fixed.
The file uses the ExternalProject-support from cmake to gather all the
projects into one superproject.
If you simply build it (cmake; make), it will download, configure and build
them all.
During building it will also install them to their install location.
If you just want to have a source package which you can build, there is a
custom target UpdateAll provided, which just gets all the sources.
To get a package from that, use the package target.
I.e.
$ make UpdateAll
$ make package
gives you a KDESupport-1.2.3.tgz, which you can unpack anywhere and configure
there (for all of the included projects at once).
Alex
cmake_minimum_required(VERSION 2.8.4)
project(KDESupport)
find_package(Qt4 REQUIRED)
add_custom_target(UpdateAll)
include(ExternalProject)
include(CMakeParseArguments)
macro(kde4_add_project _name )
option(BUILD_${_name} Build subproject ${_name} TRUE)
set(oneValueArgs CVS_REPOSITORY GIT_REPOSITORY SVN_REPOSITORY SOURCE_DIR )
cmake_parse_arguments(_KAP ${oneValueArgs} ${ARGN})
if(EXISTS ${CMAKE_SOURCE_DIR}/${_name}/src/ ) # we are building an installed version of the source package
set(GET_SOURCES_ARGS SOURCE_DIR ${CMAKE_SOURCE_DIR}/${_name}/src/${_name}
DOWNLOAD_COMMAND )
else()
set(GET_SOURCES_ARGS DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/${_name}/ )
if(_KAP_CVS_REPOSITORY)
set(GET_SOURCES_ARGS ${GET_SOURCES_ARGS} CVS_REPOSITORY ${_KAP_CVS_REPOSITORY} )
elseif(_KAP_GIT_REPOSITORY)
set(GET_SOURCES_ARGS ${GET_SOURCES_ARGS} GIT_REPOSITORY ${_KAP_GIT_REPOSITORY} )
elseif(_KAP_SVN_REPOSITORY)
set(GET_SOURCES_ARGS ${GET_SOURCES_ARGS} SVN_REPOSITORY ${_KAP_SVN_REPOSITORY} )
elseif(_KAP_SOURCE_DIR)
set(GET_SOURCES_ARGS ${GET_SOURCES_ARGS} SOURCE_DIR ${_KAP_SOURCE_DIR} )
endif()
endif()
if (BUILD_${_name})
externalproject_add(${_name}
# ${_KAP_UNPARSED_ARGUMENTS}
PREFIX ${_name}
${GET_SOURCES_ARGS}
TMP_DIR ${CMAKE_BINARY_DIR}/${_name}/tmpfiles
STAMP_DIR ${CMAKE_BINARY_DIR}/${_name}/stampfiles
BINARY_DIR ${CMAKE_BINARY_DIR}/${_name}/build
INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
#INSTALL_COMMAND ${CMAKE_MAKE_PROGRAM} -C${CMAKE_BINARY_DIR}/${_name}/build install DESTDIR=${CMAKE_BINARY_DIR}/Install
CMAKE_ARGS -DQT_QMAKE_EXECUTABLE=${QT_QMAKE_EXECUTABLE} -DCMAKE_PREFIX_PATH=${CMAKE_INSTALL_PREFIX}
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Tue, 24 May 2011, Alexander Neundorf wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: On Sunday 22 May 2011, Kevin Kofler wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. Unfortunately, this is of no use for us packagers because we are banned by policy (and at least in Fedora, this is enforced by the build system) from downloading stuff during build. We can only work from tarballs. (If we want to package a snapshot, we have to check it out, tar it, then package the resulting tarball.) I'll see whether I can do something for this. Alex Looks good :-) I have here now a CMakeLists.txt for kdesupport, which downloads everything from git and builds it. But on make package, it creates basically a package of the downloaded sources together with a matching CMakeLists.txt (which then doesn't download, but just uses the already present sources). I.e. you could do cmake srcdir , then make package (or maybe some custom target), and then you'd have a tgz of kdesupport which you can unpack and build anywhere. Would that help your case ? Alex Hi Alex Absolutely! I have no issues with creating a comprehensive tarball myself. In fact, if this allows me to build a single monolithic kdesupport package again, then you provide what I need. The resulting kdesupport source tarball will then of course also be available to other interested parties, since Slackware (and/or my own test repository) will provide this source tarball along with the binary Slackware package. I think it would be awesome if this should be repeated for the other tarballs which got split (kdeedu, and I think kdebase too but I have not yet looked closer). Cheers, Eric -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011 02:00:44 Dirk Mueller wrote: just finished creating the first set of tarballs for Beta1. compiling started to look good, but I'm not yet through all of them. Please report any important packaging issues or must-fix bugs to the release- t...@kde.org mailinglist. kdepim needs 6b44080e, compile fix. Will ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again Dirk. On 25-05-2011 09:23, Dirk Mueller wrote: On Tuesday 24 May 2011, Jorge Manuel B. S. Vicetto wrote: I'm sending this email again as I didn't hear back from anyone and the tarballs were published. Thanks for letting me know, I've added it to the uploaded directory now. While bumping the packages here (I'm still half way through), I've now come across krosspython. Looking at our live ebuild and at the kdebindings tarball, I think you may not be aware it was moved to a new repo - git://anongit.kde.org/kross-interpreters Greetings, Dirk - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN3bS8AAoJEC8ZTXQF1qEPB0wP/21bHEFBHZiRrF1LWVJOTfbj 3TASr3VtX0m2fY6XPeil+i3VemPXvY2X+HgefgRe1ImtSri58Wrf+OcVEtFaD+Ki QbbD5VQWKYHjbTqS5ciBmkR3yWMPrl2aWmKBG+K8p8Adka3BmSoBcOzEDjOoQBN3 MSpmHa7jY0+MOfkW1tb3RfvLSe/9P8v7dFz6QzKnN+qEQyNhRqY8PCd4DJ3U/9y3 kAjbDt8xnAJnHC++WvT/QxmUcOXR53/mxxQD7DBAacy9eSslOrlT0GyKbIDGbp6b k0zFMu1MXKkhsVwiGknhkc+RR0gUHm8A04DWIVXEigr5nRgUV32qal/WSYwAYg43 6OMxvqs7MFWcgtFt9yzflE/lJsLiB5mxvLSVHPgmxwhKPDdcfQTMHcX2T7oPCO/k pOgQooWmK5/0TBW9DEFR685Bz9pZVfseugTtLCaaZFhHwNnwlYLZCmHsYqSdiI+x JYMK/Xhj0Xm2hQelXHd1GE/so5DwUKV2cElud36QUzhR0hpVK1d9hOYcjdAqyZQg osjcDA3OJhOY67d0MHJrmvJkAhBOsxxpNKk2XdCZCsyUZc0+pjoOJC9bw8rwmtxL 2hpljvsjq5xJAJlKlUcRePKvtzoI9N1W6UBxLIi5zoadrTwnhnIX0Fj6vo/TEgHW 4BsBHxJMZWWArKU55CZf =EJUS -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Sunday 22 May 2011, Alexander Neundorf wrote: On Sunday 22 May 2011, Kevin Kofler wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. Unfortunately, this is of no use for us packagers because we are banned by policy (and at least in Fedora, this is enforced by the build system) from downloading stuff during build. We can only work from tarballs. (If we want to package a snapshot, we have to check it out, tar it, then package the resulting tarball.) I'll see whether I can do something for this. Alex Looks good :-) I have here now a CMakeLists.txt for kdesupport, which downloads everything from git and builds it. But on make package, it creates basically a package of the downloaded sources together with a matching CMakeLists.txt (which then doesn't download, but just uses the already present sources). I.e. you could do cmake srcdir , then make package (or maybe some custom target), and then you'd have a tgz of kdesupport which you can unpack and build anywhere. Would that help your case ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-05-2011 18:42, Jorge Manuel B. S. Vicetto wrote: On Sat, 21 May 2011, Dirk Mueller wrote: On Saturday 21 May 2011, Eric Hameleers wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Yes, I started to resemble the git layout in the tarballs, given that I had a pain in the ass of work to do with reverting the git splitting for the 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. Dirk, I've been looking for the kde-wallpapers tarball, but I can't find it. Might you have forgot to create one? We recently added an ebuild in Gentoo to get it from svn://anonsvn.kde.org/home/kde/trunk/KDE/kde-wallpapers I'm sending this email again as I didn't hear back from anyone and the tarballs were published. Greetings, Dirk Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN3CQPAAoJEC8ZTXQF1qEPr04QALX954QF8UsOMB4TZFo0HdZF wdMB/u1I+QWFAZINbKp/zpxHwigjP6YG7yJfwjRVElsxyca+N9nVHioCz1+7gvV2 I0gaIVqxWPeouFoRMQJj6XRz/BPynyclDgwPHAOWSqFoXzLmSO7M03NyZ5Wq69hD Cm9DXp5b+Xbn9x2T/e1UTfEv39v+a+obX/QIaTM+CYcggiN/4z2jFMgbPK1s4ZdR occM/qiWFOBBYwydngIi4KrcQwjLl3xslwxYaF3t7beayvZfwyisfIwzsAUlD4z1 VGNfjp9Y9K6QVY8sYRe07+N3apEzbTKAKkTqEQ1ARWS+N3f9dmvvjdJYv2+d8StV VFzg1KneMbKiT0GPd0rIZ/iNMPA8i6GiPKR6XGdeuVwklvBLyviWvvkGA/B2jgQd V0Bw8h7YnXk9JuIInzCLPK+MLbCGf33EYd1/lbTyeLcAokdHHQgnXzq3eEVDRZRM a6kp71Od0dLnVqiY05eYeOqFOkXcwchOmV5tgklWg0MwafZpBS4MvdhX4aBe3N8w dCiCSxcupuDZ3Q7C2inJX1bGpCdR9yazDIEFm0k6/714A20s3u3iyZnUtJyUI+3s jBeREl1EU/Q4Tol7TbDVk12CE9hryxeNNTEyarPGIGS7raZ+pm/Y4ex0ry96tLbK d86KrjjMFyX2add7ZoQR =ERSR -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Sat, 21 May 2011, Dirk Mueller wrote: On Saturday 21 May 2011, Eric Hameleers wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Yes, I started to resemble the git layout in the tarballs, given that I had a pain in the ass of work to do with reverting the git splitting for the 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. Dirk, I've been looking for the kde-wallpapers tarball, but I can't find it. Might you have forgot to create one? We recently added an ebuild in Gentoo to get it from svn://anonsvn.kde.org/home/kde/trunk/KDE/kde-wallpapers Greetings, Dirk Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011 02:00:44 Dirk Mueller wrote: Please report any important packaging issues or must-fix bugs to the release- t...@kde.org mailinglist. Build fails for both pykde4 and smokekde; I reported the bugs here[1] and here[2]. However, the second seems related to kdelibs. [1] https://bugs.kde.org/show_bug.cgi?id=273963 [2] https://bugs.kde.org/show_bug.cgi?id=273985 -- Andrea ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011, Dirk Mueller wrote: On Saturday 21 May 2011, Eric Hameleers wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Yes, I started to resemble the git layout in the tarballs, given that I had a pain in the ass of work to do with reverting the git splitting for the 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. For kdesupport ( I guess it's the same issue there) previously I checked out one module and built it, now it's 10 or 15 different git repositories. This is quite inconvinient. Probably similar for kde e.g. kdegames etc. So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. It's mostly working already. But I'm not sure where to put that CMakeLists.txt, since there is no kdesupport anymore. Interested in this ? Where do you think should I put this ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
2011/5/22 Dirk Mueller muel...@kde.org: On Saturday 21 May 2011, Eric Hameleers wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Yes, I started to resemble the git layout in the tarballs, given that I had a pain in the ass of work to do with reverting the git splitting for the 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. The script used by LXR and the EBN may be of help here in reassembling the directory tree layout. All you'd have to do then is throw in some minimal CMake glue to add the modules in the right order. No idea how much they'd like building like this however. They may try to find() various items (like edu apps try to find libkdeedu) which might cause that approach to fail. Dirk, are instructions available on how to re-assemble sources back to the original set? Or else, are instructions available on how to compile the bigger all-comprising packages where the separated applications and libraries are included again, like was the case all the time up to 4.7? I don't have those available at the moment. I used scripts to reassemble them to original tarballs, but I haven't properly pushed this into KDE git back yet. Can I get the opinion of the other distro packagers as well please? Personally I was much more happy with the previous module-based layout, though I can cope reasonable with the current situation as well. Any other opinon? Eric, thanks for sharing your thoughts. I hope we can find a solution that suits your needs as well. If all else fails, I'm willing to give maintaining those reassembling-scripts a try, but it is an extra effort, given that the tarballs are much different from how developers build it, so regressions in the build system are likely. Greetings, Dirk ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager Regards, Ben ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011 23:29:43 Dirk Mueller wrote: Can I get the opinion of the other distro packagers as well please? Personally I was much more happy with the previous module-based layout, though I can cope reasonable with the current situation as well. Any other opinon? Here in Arch Linux we have no problem with the splitted layout. As Raphael said we have to spend some time to adjust our PKGBUILD, but it's fine. Anyway, both layouts are fine. -- Andrea ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Sunday 22 May 2011, Alexander Neundorf wrote: So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. Unfortunately, this is of no use for us packagers because we are banned by policy (and at least in Fedora, this is enforced by the build system) from downloading stuff during build. We can only work from tarballs. (If we want to package a snapshot, we have to check it out, tar it, then package the resulting tarball.) Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Sunday 22 May 2011, Kevin Kofler wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. Unfortunately, this is of no use for us packagers because we are banned by policy (and at least in Fedora, this is enforced by the build system) from downloading stuff during build. We can only work from tarballs. (If we want to package a snapshot, we have to check it out, tar it, then package the resulting tarball.) I'll see whether I can do something for this. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011, Dirk Mueller wrote: Please report any important packaging issues or must-fix bugs to the release- t...@kde.org mailinglist. I found several myself already: 9b0d645e5276f2a1ca49f12fbfd6cac1 kdelibs-4.6.80.tar.bz2 f41ed3db5ed14087bb1a746967b33248 kdelibs-experimental-4.6.80.tar.bz2 Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011, Dirk Mueller wrote: I found several myself already: And as I found out, kdelibs now depends on kdelibs-experimental, so I had to remove the splitting for now: 890d551e6332baea19b9bcb0655fce0c kdelibs-4.6.80.tar.bz2 Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 21 May 2011, Dirk Mueller wrote: On Saturday 21 May 2011, Dirk Mueller wrote: I found several myself already: And as I found out, kdelibs now depends on kdelibs-experimental, so I had to remove the splitting for now: 890d551e6332baea19b9bcb0655fce0c kdelibs-4.6.80.tar.bz2 Thanks, Dirk Oh boy. The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Dirk, are instructions available on how to re-assemble sources back to the original set? Or else, are instructions available on how to compile the bigger all-comprising packages where the separated applications and libraries are included again, like was the case all the time up to 4.7? It would be nice if there would at least be scripts available for distro packagers that allow to checkout bundled source tarballs from the repository. In the presence of such scripts, I would be able to generate old-style source tarballs and make them available for other packagers, if the KDE release team decided against making those available on the ftp site. Why am I proposing this? I am afraid that for Slackware, the bloat in KDE packages is not acceptible from a maintenance point of view. I do not speak _for_ Patrick Volkerding, but I spoke _with_ him, and since I also do a lot of the work with regard to researching and packaging KDE for Slackware, I have to say this on the matter: If there are no ways around this, then we are seriously considering the removal of KDE from the Slackware distribution and turning support over to willing third parties. This will go the way of GNOME which was abandoned by Slackware for the same reasons - we refuse to participate in a maintenance hell. Cheers (but not really), Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3X92EACgkQXlaqr6dcvaDoyQCgpdZ+6W2wIfbL/wRAOwkYhgtm FrAAn2VKLO1H9FUWMY1hq3k98ZrTlKAj =ZBu3 -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
On Saturday 21 May 2011, Eric Hameleers wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Yes, I started to resemble the git layout in the tarballs, given that I had a pain in the ass of work to do with reverting the git splitting for the 4.6 branch releases. I'll attach them for reference, but those scripts are ugly. I'm not aware of a better solution though, unless we use git submodules or maintain those scripts in the SVN. Dirk, are instructions available on how to re-assemble sources back to the original set? Or else, are instructions available on how to compile the bigger all-comprising packages where the separated applications and libraries are included again, like was the case all the time up to 4.7? I don't have those available at the moment. I used scripts to reassemble them to original tarballs, but I haven't properly pushed this into KDE git back yet. Can I get the opinion of the other distro packagers as well please? Personally I was much more happy with the previous module-based layout, though I can cope reasonable with the current situation as well. Any other opinon? Eric, thanks for sharing your thoughts. I hope we can find a solution that suits your needs as well. If all else fails, I'm willing to give maintaining those reassembling-scripts a try, but it is an extra effort, given that the tarballs are much different from how developers build it, so regressions in the build system are likely. Greetings, Dirk setup-kdeedu.sh Description: application/shellscript setup-kdegraphics.sh Description: application/shellscript ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. I strongly disagree. Splitting KDE SC up more is a step in the right direction as it allows for easier control about what to install. I am afraid that for Slackware, the bloat in KDE packages is not acceptible from a maintenance point of view. Again, I disagree. Yes, it's a bit more work but it reduces the bloat for users in the end. Most people don't need everything KDE SC has to offer and, thus, it's well worth some effort. If there are no ways around this, then we are seriously considering the removal of KDE from the Slackware distribution and turning support over to willing third parties. This will go the way of GNOME which was abandoned by Slackware for the same reasons - we refuse to participate in a maintenance hell. I suppose you've gotten rid of X.org, too? :-) Best regards, Wulf 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 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
Dirk Mueller muel...@kde.org writes: Can I get the opinion of the other distro packagers as well please? Personally I was much more happy with the previous module-based layout, though I can cope reasonable with the current situation as well. Any other opinon? On the FreeBSD side, we will just have to spend some time adjusting our ports, as we will probably create a separate port for each application that has been split. Other than, we're fine with either layout. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
Hello, On sekmadienis 22 Gegužė 2011 00:29:10 Wulf C. Krueger wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. I strongly disagree. Splitting KDE SC up more is a step in the right direction as it allows for easier control about what to install. Since unrelated or slightly related applications are no longer bundled in the same source package, each package is faster to build and links fewer system components together. In the end, users can freely choose what to install and maintainers what and how to package. I am afraid that for Slackware, the bloat in KDE packages is not acceptible from a maintenance point of view. Again, I disagree. Yes, it's a bit more work but it reduces the bloat for users in the end. Most people don't need everything KDE SC has to offer and, thus, it's well worth some effort. The split does not bloat KDE SC since it has been bloated for a long time already. On the contrary, the split allows to ignore applications which are not that important for the distro (but used to be shipped in the bundle next to important applications). Also more people can work in parallel and responsibilities can be split according to the maintainer/user interest in the applications themselves. Therefore I also welcome the split very much and please continue the work in this direction. -- Modestas Vainius mo...@debian.org 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
