Re: Fwd: KDE Frameworks Release Cycle
On Wednesday, May 21, 2014 16:12:50 Kevin Ottens wrote: On Wednesday 21 May 2014 11:28:45 Aaron J. Seigo wrote: On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote: ... This type of branch got actually discussed before making the initial proposal, it's not that we don't like the idea at all, it's that we don't feel confident to make it work at that point in time. Even with a single stable branch owner? Yes, that's the exact option we thought about, but you need someone willing to do the job. shouldn't in theory each library in frameworks have a maintainer, who is responsible for that library, and wouldn't this be the obvious person who maintains also the stable branch of the library ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks Release Cycle
On Thursday, May 08, 2014 22:08:06 David Faure wrote: [Taking k-c-d out, too much cross-posting] On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote: If we have more than 50 libraries, do all of them need a full new release every month ? Not doing that leads to 1) a huge mess of versioning. The latest available version for each framework would be different, so how do you make sure you have the latest of each? And the min required version in each find_package would have to be increased manually, since it would no longer be the same everywhere. In a year we'd be at KArchive 5.3, KIO 5.7 required by KParts 5.1 required by KTextEditor 5.4, etc. etc. This seems extremely messy to deal with, for everyone. We decided long ago against this, for these very reasons. Yes, I know, I see it exactly the same way. That's the situation you have if you have a number of separate libraries. IMO it would be the correct thing if each of these libraries would actually specify the exact version of the other libraries they actually need... dependency hell. OTOH this would mean I could update one or a set of the frameworks libraries if I see the need to, without having to update them all, just because they all require for simplicity the same version of all libraries. That's why I still think we may have gone a bit too far with the splitting. 2) more work for me: every month, for each of the 61 frameworks, I'd have to decide which ones need to be released and which one shouldn't Well, if we say we have 61 independent frameworks libraries, ideally each should have a maintainer who takes care of releases, required dependencies etc., i.e. not one single person doing it for all. I know we don't have enough maintainers in real life. Just my 2c. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Frameworks Release Cycle
On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote: Kevin Ottens ha scritto: So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, David, Rohan and myself. We juggled with several options, trying to address the following constraints: * We don't have many contributors; * We don't have enough testing in the stable branches, developers tend to have a hard time to dog food those; * We don't have enough contributions coming from the application developers because it takes a lot of time for them to benefit from their changes so they tend to workaround instead and consider kdelibs more and more as a black box; going forward we don't want that for KDE Frameworks. So, I've seen no discussion about this (not on this list, I think it's going on somewhere else) but I would like to rise my concerns with this decision. It can increase the balkanization of the version shipped by distribution. This is going in the opposite direction of the advocated give users a real KDE experience. With no stable branches, distributions will have to randomly choose one branch to stabilize and the risk is that based on their schedule, they will choose different versions, heavily patching them (_more_ than what happens today, where there are few synchronization points). Other big projects with frequent releases, like the Linux kernel or Firefox have stable branches too; not all of the releases, but some of them. Firefox had to provide a esr version (long support, one year) because it's not really possible to update an entire stack in long-term supported distributions. And Firefox is mostly a leaf in the dependency tree (with the exception of libnss and libnspr, which can break and broke in the past from one esr to another); here we have an entire bunch of core libraries (as in Linux with its long-term branches). I understand that the big concern was about the testing: stable branches did not receive the same attention, but I think that killing them is not the solution; solutions include an increase number of automated tests (unit, integration, scenario) as first step, and a bit of time invested in the rest (manual) testing, with contribution of distributions but not only them. We had a lot of coding sprint, we can organize test sprints as well (which benefits also the main master branch, of course!) I also think that many frameworks will stabilize after the initial rush, so it will. I suspect (just a feeling, not backed by any fact) that Tier1 will stabilize sooner, Tier3 will have more moving part (please note that this is not about ABI/API, which I'm sure will keep the compatibility as it was before). If this is true, it could help in creating naturally stable branches; KDocTools is a good example, it's unlikely to have new important changes too frequently, but I guess it will be the same for KI18n and others. Minor point: the original statement of three releases for Porting Aids should be fixed to be time based (I guess at least 6 is not 9 months). So, my proposal(s). I think that some kind of long term branch branch is needed. It could be an yearly release (and we could do a testing sprint for that, solving the problem for the love), or a bit more frequent, like twice a year (no more!); still at least one release could benefit from a sprint. Collaboration from distribution is needed, so that they can coordinate. In case of yearly releases, if few distributions want to have an official stabilization branch (like in Linux) they will able to create and manage a special branch (with some input from developers). After the initial rush, revise the release schedule in the light of the stable frameworks, maybe they can be naturally on a stable branch (because no big changes will land in them). Maybe this should be considered seriously ? If we have more than 50 libraries, do all of them need a full new release every month ? As Luigi says, some of the smaller libraries may not see many changes at all, and maybe only old style patch level releases for them would be good enough ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Wednesday, April 30, 2014 10:17:23 Sune Vuorela wrote: On Tuesday 29 April 2014 23:20:21 Lisandro Damián Nicanor Pérez Meyer wrote: The result will be that we will need to freeze at some point and do our best to keep up with patches for stable releases. Or maybe even drop KF5 for stable releases :-/ While I don't share the fatalistic point of Lisandro, I do agree that it brings potential problems. I do also expect a Debian to ship with a very patched-up set of KF5 packages. At freeze/stabilization point in at least Debian it is a time of 'bugfixes only, no new dependencies and features'. For a large collection of software on many architectures, a longer stabilization period is needed. Especially with all the KF5 bits is versioned bound to each others (so that to fix a bug in one component, you need to update *everything* - are you assuming that or is this indeed the case ? Do all frameworks depend on the same version of all other frameworks, or do they have specific required versions ? Alex ___ 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, April 30, 2014 15:51:56 Àlex Fiestas wrote: On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote: So, you will not simply update to 4.14.X but instead do cherry-picking of the bug fixes? Because that would be the same with Frameworks. You got that one wrong :) We push the 4.14.x release as a full maintenance update. So if 13.2 is shipped with 4.14.0, then 4.14.1 is pushed as maintenance update as soon as it becomes available. This is no longer possible with Frameworks. It is, you (as in opensuse) just have to get over the drama of having small features in on each release. Let's try to analyze a bit why some distros have this panic to new versions containing features (when it comes to KDE). For the longest amount of time in KDE4 has been releasing as a whole doing a big release every 6 months. This had the following impact of how things were developed: -People would develop super big features, some times even new apps. -People would push last minutes features to avoid the freeze (if you don't get in then you had to wait up to 8 months for next release). -People would merge things that are not ready because if something is wrong a bit was not a big deal (you had months to amend it). -Each release contained a lot of code changed. Just my POV as a developer: I disagree strongly. Having a stable branch where everybody (users, distributors, developers) can be sure only safe bugfixes went in, is a good thing. It can make quite sure regressions are avoided. This is the big thing: a bug fix (patch) release should at all costs not introduce regressions. For a bug-fix branch, sometimes a hack is acceptable if it safely in some way avoids the bug, and makes sure it doesn't introduce regressions. The proper fix for a bug may be more involved, and may have some risk of introducing unexpected regressions. So, IMO, this is not drama of having small features. This is the serious wish to avoid being yelled at by users if anything broke in a bug fix release. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote: On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: For non-rolling distros, at some point you have to stop and release. A mix of new features and bug fixes aren't going to be allowed in. We (Kubuntu) have been delivering KDE SC point releases as post-release updates to our users for most (maybe all) KDE4 releases. That's over with KF5. We'll, I guess, have to settle for cherry picking fixes and doing our best. You might not know this but most developers don't do proper testing in the stable branches because the cost of having master and stable environments and doing testing in both branches for each fix is too much, we simply don't have the manpower for that. History has shown this mny times, we have done point releases that were horrible quality-wise because nobody was testing them. The stable branches have virtually no users. maybe not among developers... But all normal users who just install KDE from some distro are users of the stable branches. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Packaging scripts for frameworks
On Saturday 21 December 2013, Nicolás Alvarez wrote: 2013/12/21 Kevin Ottens er...@kde.org: On Saturday 21 December 2013 12:38:17 Albert Astals Cid wrote: Now, the hard part, how's versioning going to go now and in the future? I see you want to do a 5.0 of two frameworks and unstable of the others, so let's say 5.0.0 for karchive/threadweaver and 4.9.50 for the others. Let's keep it simple and make it 4.9.50 for all of them. We can't exclude that karchive or threadweaver won't see some changes between now and the 5.0. Is that the right number to use? 4.9.50 is less than 4.12... Probably 4.95.0 ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Dependency to unreleased versions
On Sunday 20 October 2013, Torgny Nyblom wrote: Hi, What is the policy of depending on unreleased libraries? And is that written down somewhere? Reason I'm asking is this commit http://build.kde.org/view/FAILED/job/libkdcraw_master/83/changes#detail1 It introduces a dependency to libraw 0.16 witch is not released. IMO it's a pain to depend on unreleased versions of anything. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Exception for Nepomuk Ebook Indexers
On Thursday 20 June 2013, Vishesh Handa wrote: On Thu, Jun 20, 2013 at 7:32 PM, Mario Fux KDE ML kde...@unormal.org wrote: Am Donnerstag 20 Juni 2013, 14.51:38 schrieb Vishesh Handa: Hey guys Morning I wanted Nepomuk to have some ebook indexers for this release, but I never got around to implementing them. I was hoping someone else would implement them, since they are so simple, but that never happened. Anyway, I spent some time today and implemented both epub and mobi analyzers. The epub analyzer uses the libepub library, and for the mobipocket analyzers I've just copied the code from kdegraphics-mobipocket. I'm not so happy about this part copied the code. Is it not possible to just use it without duplicating the code? I couldn't see a way this late into the release. Ideally, kdegraphics-mobipocket should be creating a library and installing it. It currently does not do that. One could make it install the library and the headers, but then there are issues of binary compatibility. Copying code is not good. OTOH, making code part of a shared library also comes with a cost. So I'd say it's probably ok to have the code copied, at least for now. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday 26 April 2013, Sebastian Kügler wrote: Hi, tldr Let's make 4.11 the last feature release for platform and workspace in the 4 series, make 4.11 a long term maintainance release. /tldr IMO this is not about handling releases, but about the mid-term development strategy of KDE. I think setting the direction for KDE is not task of the release team. I think this should be discussed more public, i.e. on k-c-d. Beside that, trying to get KF5 more into a working-towards-a-release development mode seems like a good idea to me. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Tuesday 18 December 2012, Albert Astals Cid wrote: El Dilluns, 17 de desembre de 2012, a les 18:37:59, Alexander Neundorf va escriure: On Sunday 16 December 2012, Antonis Tsiapaliokas wrote: Hello, Attached, can somebody give it a try ? Alex I have test the attached patch with 2.8.8 cmake and it doesn't work. With the 2.8.9 cmake, the issues is solved, without the attached patch needed. The attached patch should work. It's not nice, but should work (works at least for me). I tried this patch and boost was still listed amongst the non found packages in the summary, Yes, but the config step only failed if it was actually not found. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Monday 17 December 2012, Laszlo Papp wrote: On Sun, Dec 16, 2012 at 11:07 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 17 de desembre de 2012, a les 00:03:38, Luigi Toscano va escriure: Albert Astals Cid wrote: El Diumenge, 16 de desembre de 2012, a les 23:53:23, Antonis Tsiapaliokas va escriure: Hello, Attached, can somebody give it a try ? Alex I have test the attached patch with 2.8.8 cmake and it doesn't work. With the 2.8.9 cmake, the issues is solved, without the attached patch needed. So let's go for the cmake increase? Anyone against it? (I will need an answer before RC1 tag on tuesday night) I am all for it. On a side note, I have never understood the objection against 2.8.9 before as that is what was also required for framework. Hence, it would somewhat lower the barrier for the framework contribution, too. Not really. For the frameworks branch the most current cmake is required, which is 2.8.10.1 currently. We will stay there with the most current until we get somewhat stable. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Boost vs cmake 2.8.8 vs kdepimlibs master
On Saturday 15 December 2012, Albert Astals Cid wrote:
El Dissabte, 15 de desembre de 2012, a les 15:41:37, Alexander Neundorf va
escriure:
On Saturday 15 December 2012, Albert Astals Cid wrote:
There seems to be various reports of kdepimlibs master not working with
cmake 2.8.8
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7589
http://mail.kde.org/pipermail/release-team/2012-December/006566.html
But cmake 2.8.8 is what we are requiring at the global kdelibs level.
Should we:
a) Require cmake 2.8.9 at the kdelibs level
b) Require cmake 2.8.9 at the kdepimlibs level
c) Don't change requirement, bring back FindBoost.cmake to kdelibs and
keep working with 2.8.8
I don't have a strong feeling but i guess that b would actually imply
a
on 99.99% case of the packagers, so probaly just go with a?
Comments?
There would be also option
d) don't mark the package as REQUIRED in the summary, but simply do
find_package(Boost REQUIRED)
This should make it work too.
Interesting, if that works and saves us from increasing the dependency,
might be worth a shot, can you provide a patch so people with cmake 2.8.8
can give it a try?
Attached, can somebody give it a try ?
Alex
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0aea59c..332f4cf 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -66,8 +66,8 @@ configure_file(${CMAKE_SOURCE_DIR}/CTestCustom.cmake ${CMAKE_BINARY_DIR}/CTestCu
### Find the stuff we need ###
set(Boost_MINIMUM_VERSION 1.34.0)
-find_package(Boost ${Boost_MINIMUM_VERSION} COMPONENTS graph)
-set_package_properties(Boost PROPERTIES DESCRIPTION Boost C++ Libraries URL http://www.boost.org; TYPE REQUIRED PURPOSE Boost must include the boost-graph library)
+find_package(Boost ${Boost_MINIMUM_VERSION} REQUIRED COMPONENTS graph)
+set_package_properties(Boost PROPERTIES DESCRIPTION Boost C++ Libraries URL http://www.boost.org; TYPE OPTIONAL PURPOSE Boost must include the boost-graph library)
#FindGpgme.cmake already handles the log message but we must ensure it is required.
find_package(Gpgme REQUIRED)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Boost vs cmake 2.8.8 vs kdepimlibs master
On Saturday 15 December 2012, Albert Astals Cid wrote: There seems to be various reports of kdepimlibs master not working with cmake 2.8.8 http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7589 http://mail.kde.org/pipermail/release-team/2012-December/006566.html But cmake 2.8.8 is what we are requiring at the global kdelibs level. Should we: a) Require cmake 2.8.9 at the kdelibs level b) Require cmake 2.8.9 at the kdepimlibs level c) Don't change requirement, bring back FindBoost.cmake to kdelibs and keep working with 2.8.8 I don't have a strong feeling but i guess that b would actually imply a on 99.99% case of the packagers, so probaly just go with a? Comments? There would be also option d) don't mark the package as REQUIRED in the summary, but simply do find_package(Boost REQUIRED) This should make it work too. I vote for a) or d) It was a bug in cmake which was fixed in 2.8.9. I'm against c), I don't want to have to maintain a copy of this file. Would it actually help ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday 12 July 2012, Michael Jansen wrote: On Thursday, July 12, 2012 07:21:40 PM Albert Astals Cid wrote: El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: On Monday, June 25, 2012 01:05:49 PM David Faure wrote: On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: If we really want to decouple our releases and be more flexible with doing them i consider this change a requirement for any decision in that regard. Each and every module has to have its own version number build in. I guess with the frameworks branch much of kdelibs already got that change (no idea really, anyone with input?). But we have to do the same with the rest of our modules. No idea about frameworks. David? Kevin? This is partly still under discussion. However the currently implemented solution is that each framework has a versions number, but that version number can be upgraded in all frameworks at the same time, using a script. A future framework on top of all others, could provide the version number for all apps, much like the current kdeversion.h. Basically it would be the SC number, and not the version number of the libs themselves, as is currently the case. But that SC number would be a lie. Because you only assume all modules are installed in the versions that were release as SC X.Y . You have no idea if the user or distro uses older or newer versions for some libraries, modules or apps. So that number has no information value. Perhaps some marketing value. But in bug reports it is useless. Do we release kdelibs as ONE package. Or do we plan to release many small packages? Many small packages, but all at the same time. So based on KDE Frameworks 5.0.1 will have some value in bug reports. However you're right, apps themselves should have their own version number, maybe we can solve the same way as we do for the frameworks: by running a script that updates the toplevel CMakeLists.txt in all modules before releasing. If each library gets released standalone. What if whe make the kde sc release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6 because stuff is pretty stable by now (7th update). Do we still release ALL libs or only those that got changed? All libs, obviously. Who would take the time to run a diff and make really sure that nothing changed? This is additional work for nothing and makes everything more complex. Just like right now, we release kdeadmin or kdetoys with every KDE SC release, even if nothing changed. The same naturally goes for stuff like kdeedu now that it split. What if some application got no commits since the last minor release. Make a release anyway or skip it? For major releases i guess making a package anyway makes sense. Or not? I can't decide there, that's for the release team to decide, but IMHO if it's all scripted and done all at once (KDE SC release), then it's simpler to just re-release everything. I agree with David here, just release everything, it's easier for everyone. No it is not. It is a waste of bandwidth, resources and time for all involved. Do you really think forcing an update of unchanged modules for our convenience will help those of us trying to use plasma for mobile devices? Do you really think splitting up kdelibs and then releasing it more or less as one big blog is really helpful? Will it help people consider kde a more lightweight dependency? I will implement the ability to skip release for unchanged modules (fully automated) and would ask everyone here to really think twice before asking the release team to keep the current practice of releasing everything. I think I mostly agree. It sounds like the correct thing to do. I'm aware that this may somewhat contradict my posts to the versioning discussions on kde-frameworks... But basically, if a library has not changed, I agree that it's version number should also not change. Still all can be released again, so you can get everything at once if you need. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Wednesday 13 June 2012, Michael Pyne wrote: Hi all, Bug 301419 has been reported against kdelibs due to a build failure when KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform even more sanity checking in the KSharedDataCache. These commits use exceptions (as are already used in khtml) since they are actually the right tool in the context of where they are used, and because refactoring everything to use error codes everywhere (ECE) would have risked introducing more bugs. In order to minimize the changes to kdecore I only added the CMake magic to enable exceptions for only kshareddatacache.cpp. This doesn't work when KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that case. The Mageia devs have a proposed patch [1] to enable exceptions for all of kdecore, which fixes the issue. Is it acceptable for me to go this route? The only real alternative this late in the game is to back out the sanity checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL will not work for this tarball although it worked for 4.8.3, both of which I consider less desirable. But I don't want to make the change if there are good reasons to avoid it. Longer term (for frameworks) KSharedDataCache could be split into its own tier if necessary (it only really depends on Qt and KStandardDirs, which is now also in Qt...). In KDE frameworks, i.e. next gen kdelibs, ENABLE_FINAL will not be supported anymore at all. AFAIK gcc now actually has a mode to do interobject optimizations, so with this mode enabled (which we currently don't), ENABLE_FINAL should not be necessary anymore. So, personally I do not really care much about ENABLE_FINAL. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Time to Dump kdewebdev and kdetoys?
On Tuesday 22 May 2012, Martin Schlander wrote: Lørdag den 19. maj 2012 10:17:18 Burkhard Lück skrev: Am Freitag, 18. Mai 2012, 22:06:19 schrieb Allen Winter: kdewebdev has had zero love and attention for a long time now. Wrong, kfilereplace, kimagemapeditor, klinkstatus have an up to date documentation since 4.7, see http://techbase.kde.org/Projects/Documentation/KDE4_(health_table)#kdeweb dev Speaking from a user perspective. I use kfilereplace and klinkstatus, and they work fine. Don't see any reason to dump them unless there'd be security issues. Could they maybe move to kdeutils (does this still exist actually) ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Stepping down as release coordinator for KDE 4.9+
On Friday 30 March 2012, Dirk Mueller wrote: Hi, Well, the day had to come. I realize that my focus is meanwhile on many other tasks, and I don't have enough time and attention to follow KDE 4.9.x development. Thanks a lot for all the time and work you have put into this over the years ! Really ! :-) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git workflow draft
On Wednesday, August 31, 2011 01:00:56 PM Sebastian Kügler wrote: On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote: Was this decided upon at some point? I got conflicting stories from sysadmin and other developers. Yesterday after migrating kdeaccessibility to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I think concensus and consistency are important here. Was there a decision that the official branches should be named X.Y? My vote goes to KDE/X.Y, it is clearer what it means. When the frameworks get split out into multiple repos, will they still use branch names KDE/5.0? What will that mean? Or will we come up with another scheme then? I think they should, here's my reasoning: Including the 5 ? http://vizzzion.org/blog/2011/06/there-is-no-kde5/ ;-) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git workflow draft
On Monday 22 August 2011, Jeremy Whiting wrote: On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo ase...@kde.org wrote: hi all so after the meeting on Sunday, here is where we are in terms of a draft workflow. more complete meeting minutes can be seen here: http://titanpad.com/SnJwFW2iXL the goal of the meeting was to come up with a draft of a mutually agreeable git workflow for kdelibs and kde-runtime. the hope is that this can become a template for the rest of the SC modules (kde-workspace will follow the kdelibs workflow, for instance), as well as as many other KDE projects as possible. this is to help ensure a general continuity to how we work across KDE. Topic Branches = All new development should happen in a branch. Git makes branches very cheap and they can be local or remote. There are few if any really good reasons not to use branches, so development directly in master should be generally discouraged. Topic / feature branches should be public and pushed to the main repository where they are easy for others to find and collaborate on. They should start as a branch off of master. We do not want git to become, even unintentionally, a road to segregated, private development at the expense of our collaboration as a community. With public branches in a shared repository, even a git pull will inform of new development that is happening. Git then becomes an important piece of our development communication with each other: a new branch means new activity. Only features / topics that are intended from the state to be merged with master should end up in the main repository, however. More experimental and/or long term efforts (an example presented was the kconfig refactor leading up to 4.0) should start in a personal clone, and when/if the work crosses the border into this is realistically going to be merged with master it can be moved into a branch in the main repository. After merge with master, topic branches should be deleted from the main repository. Branch Naming: if a branch is specific to a subproject, e.g. solid, specify it in the branch name such as solid/udevbackend. This will make it easier to use git branch listings (along with grep, etc) to pick out branches of interest based on the project in question. If there is not a sepcific subproject that it belongs to, give it a good descriptive name such as pluggable-kconfig. No branches should be prefixed with KDE; we consider that a reserved name. Nor topic should branches be numeric in nature (such as a version number) as those are reserved for actual release branches. (Sys admin at the meeting indicated that it is likely they will eventually put a push hook in place that prevents such incorrectly named branches.) Was this decided upon at some point? I got conflicting stories from sysadmin and other developers. Yesterday after migrating kdeaccessibility to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I think concensus and consistency are important here. Was there a decision that the official branches should be named X.Y? My vote goes to KDE/X.Y, it is clearer what it means. Is that documented somewhere (I spent some time looking, but didn't find it). If not we should reach concensus Fully agree. and also fix the repositories that are not following this standard sooner than later imo. Fully agree. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Friday 19 August 2011, Jeremy Whiting wrote: I'm looking to migrate kdeaccessibility this weekend also. It's mostly ready, just polishing it a bit in svn first (making each application build on its own or part of kdeaccessibility). I'll backport these changes to the 4.7 branch when it's in git. I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did kdeedu before it split) that we are wondering where to keep also, besides the top CMakeLists.txt for the released tarball. I agree a git repo for each module makes sense rather than putting this stuff into superbuild (which I discussed with Allen the other night). So it would be something like this: kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox) -- jovie.git --kaccessible.git --kmag.git --kmousetool.git --kmouth.git with similar setups for kdeedu, kdegraphics, etc. On the other hand if Dirk is going to use superbuild to do the release tarballs we could just dump this non-superbuild stuff into there Mainpage.dox, any top level README, etc. since we need to have module specific CMakeLists.txt in there anyway for superbuild to work. thoughts? What I gathered from the Buildsystem BoF at the Desktop Summit: * Dirk will not use Superbuild * the distros, including Slackware, are ok with fine-grained source tarballs * but, if we break big tarballs into smaller ones, this should be done in a way that the packagers are informed about the situation, and if possible it should not be done in a patch level release. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
Hi Dirk, On Wednesday 27 July 2011, Dirk Mueller wrote: On Sunday 17 July 2011, Alexander Neundorf wrote: It's still in the early phase, but it should work already. With these superbuilds, you can create e.g. a standalone source package for all of e.g. kdegraphics. When creating such a source package, you can/have to enter the git tag e.g. via cmake-gui, then the source package will be for this tag. Or, you can build all of kdegraphics in one go directly from git. The documentation here: https://projects.kde.org/projects/kde/superbuild should be up-to-date and mostly complete. how does that work? I set SB_PACKAGE_VERSION_NUMBER to v4.7.0, but it still checked out git master, which is completely wrong. how do I tell it to check out a specific tag instead? Set the SB_GIT_TAG variable in the cmake cache. also, why are the subdirectory names completely different (capitalized instead of lower case like the fine grained tarballs)? No special reason. In the beginning I thought it looks nicer. But now I think it would be probably a better idea to name them consistently like the git repository. We can change that. why is there a Source/ subdir where the main subdir does not have a CMakeLists.txt, so that the usual cmake ; make; make install workflow does not work? The Source/ directory is just a container for the checked out projects. The toplevel CMakeLists.txt is the one in the checkout out superbuild directory. So you can do cmake; make there. is there a way to tell it to not run make install after every module? No. And I think this is impossible. Let's say there is a library libfoo and an application using it names KBar. KBar will have a find_package(foo) in its CMakeLists.txt. The find-module used by KBar at cmake time can only work if libfoo has already been installed at this time. So libfoo must already have been built and installed, so it can be found by KBar. That's why installing is done during building. And libfoo must be installed already with its final and correct CMAKE_INSTALL_PREFIX, otherwise several things can go wrong, e.g. would KBar get wrong RPATHs (if RPATHs are used), which would point to the intermediate location, or maybe it would grep for something in a header installed by libfoo to find some path, which could be dependent on the install location, and would get a wrong result then if libfoo would not have been installed to the final location. It is possible to use DESTDIR, so the package are not installed to the system directory, but into DESTDIR. If this is used, then RPATH must be completely disabled, because the automatically calculated RPATH of KBar would point into the DESTDIR install location of libfoo. for packagers, the step of make and make install must be completely seperate. Sune (from Debian) said that the approach with Superbuild is different from normal behaviour, but it could be handled for packaging (as long as DESTDIR works). So, after cmake ...; make all the stuff is installed already in DESTDIR. Why do make and make install have to be completey separate in your case ? In this state I don't see that I can create monolithic tarballs from that method, I would prefer to run the old setup-kde*.sh scripts (from /trunk/KDE/kde-common/release). Anything I'm doing wrong here? I might have not grasped every part of the README. Any help appreciated. Thanks for giving it a try :-) I'd be happy if we can get it into a state where it works for you. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Sunday 17 July 2011, todd rme wrote: On Fri, Jul 15, 2011 at 8:04 PM, Rex Dieter rdie...@math.unl.edu wrote: Sebastian Kügler wrote: Let me dump my brain and add how I see release management going forward from here: = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) I would welcome this immensely, even if a bit late. I know a couple distros (fedora, kubuntu at least) had serious complaints about the the current tarball splitting, but have begrudingly been putting in a lot of effort to adapt anyway for lack of repreive. -- rex On the other hand distros like Arch and openSUSE are already using split tarballs and have been for some time. Going back would probably make things harder for them. I am not sure about Fedora, but my impression is that Kubuntu has already pretty much finished the work doing the conversion. Did you have a look at the superbuilds for KDE ? Docs are here, mostly complete: https://projects.kde.org/projects/kde/superbuild It's still in the early phase, but it should work already. With these superbuilds, you can create e.g. a standalone source package for all of e.g. kdegraphics. When creating such a source package, you can/have to enter the git tag e.g. via cmake-gui, then the source package will be for this tag. Or, you can build all of kdegraphics in one go directly from git. I plan to create such files for all of KDE, and maybe even one for complete KDE, with fine-grained dependencies. With the switch to KDE frameworks some kind of help for building KDE will be absolutely necessary IMO, i.e. either the superbuilds or kdesrc-build. IMO CMake superbuild has the advantage that it is not an additionally tool, and that it can create tagged standalone source packages. It'd be nice if you could give it a try and let me know what you think. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.5 tarballs (try#1) uploaded
On Tuesday 05 July 2011, Albert Astals Cid wrote: A Monday, July 04, 2011, Sebastian Kügler va escriure: On Monday, July 04, 2011 20:11:45 Albert Astals Cid wrote: A Monday, July 04, 2011, Sebastian Kügler va escriure: On Saturday, July 02, 2011 19:27:54 Albert Astals Cid wrote: A Friday, July 01, 2011, Dirk Mueller va escriure: just uploaded KDE 4.6.5 tarballs.. Release time should be early next week, if no problems are found. I always wondered what is the point in release team getting these kind of email if the tarballs are just hidden for us. It's a suitable reminder for those that are doing parts of the release process :) I personally find it very handy, as it gives me a few days advance notice when I don't check the schedule. But it is kind of useless for those of us that for example want to make sure the tarballs contents are not from kde 4.6.1 era. Subscribe to kde-packagers, then? I'm not a packager so i have no business there I'm also neither a packager nor a release and joined both lists recently, since I learned that sometimes things are discussed there which I feel like I should know about. And, if you want to check something in the release tarballs, this kind of makes you some kind of packager, at least a person dealing with packages ;-) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [okular/4.6] /: bump version to 0.12.5
On Sunday 03 July 2011, Albert Astals Cid wrote: A Saturday, July 02, 2011, Alexander Neundorf va escriure: On Saturday 02 July 2011, Stephen Kelly wrote: Albert Astals Cid wrote: A Saturday, July 02, 2011, Max Brazhnikov va escriure: On Sat, 2 Jul 2011 14:22:57 +0200, Dirk Mueller wrote: On Thursday 30 June 2011, Pino Toscano wrote: Git commit 5ad1dd2761a26acdd2576c6451356fec856d5793 by Pino Toscano. Committed on 30/06/2011 at 23:52. Pushed by pino into branch '4.6'. bump version to 0.12.5 Hi, I recreated kdegraphics tarball to include the right version of okular: 9054b67c661847e7b41c57a19492ade8 sources/kdegraphics-4.6.5.tar.bz2 kdegraphics has circular dependency on itself, namely mobipocket depends on okular. At the first run: Anyone knows where the CMakeLists.txt for kdegraphics itself comes from? Obviously it does not come from kde:kdegraphics repo (since this one is broken and does not even know about the existance of the mobipocket folder). But then again since we do not have access to the tarballs it's just speculating for the fun of it. It's in the superbuild repository. git clone kde:superbuild ...but if the one from superbuild is used, Mobipocket should find Okular. Doesn't it ? No idea, how is one supposed to use the superbuild thing to get the 4.6 tarballs like Dirk did? The currently existing documentation is here: https://projects.kde.org/projects/kde/superbuild I don't know whether something changed in the structure between 4.6 and 4.7, but basically: git clone superbuild, this brings a CMakeLists.txt for kdegraphics. Then run cmake on it, and then build make UpdateAll, which just fetches the sources. Then make package, which creates a source package from these sources including a top-level CMakeLists.txt. This source package should be buildable everywhere. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Monday 27 June 2011, Rex Dieter wrote: On 06/27/2011 02:49 PM, Alexander Neundorf wrote: On Friday 24 June 2011, Nicolas Alvarez wrote: ... I tried an ExternalProject-based approach before for kdeedu. The main inherent and unavoidable disadvantage is that 'make' alone will *install* the subprojects. Yes, that's unavoidable. Serious question: is this a problem ? You can still use DESTDIR. A little, but I suppose it'll be a little less bad as long as: rm -rf $DESTDIR make install DESTDIR=$DESTDIR still works (later). Almost. Since installing happens at buildtime (so depending projects can find their dependencies), it's more like: $ export DESTDIR=/some/path# - must be absolute path $ cmake -DCMAKE_SKIP_RPATH=TRUE . # DESTDIR must be also set at cmake # time, so the dependencies are found in DESTDIR # and RPATH has to be disabled completely, because I think # there is no way to get a correct RPATH with using DESTDIR $ make# - builds and installs into DESTDIR And it will complain * if DESTDIR is set, but not an absolute path * if it changes from cmake-time to build-time and later on * if DESTDIR is set but RPATH is not disabled Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Thursday 23 June 2011, Nicolas Alvarez wrote: Rex Dieter wrote: On 06/21/2011 06:41 AM, Will Stephenson wrote: So you want the fine grained tarballs, if I understand correctly ? Just looking at how the openSUSE buildservice is set up, they seem to use fine-grained tarballs as well, although I don't know how closely those match to the breakdown you are using. We're using them, and the consensus among the team so far is that they allow faster builds (broader dependency tree instead of deeper) and isolate failures better. These are the kde.org tarballs; is anyone using their own?? Fwiw, in fedora, we hacked the 4.6.80 kde.org tarballs and build-process to be as-close-to-monolithic as possible. I had to do many changes to the buildsystem of every kdeedu app in 4.6 to let them build both monolithic and split. If you need to continue with a monolithic build, (and preferably if fedora is not the *only* distro that needs it), I'm willing to forward-port the changes to the master branch. However, IMHO, KDE shouldn't officially release both sets of tarballs. That would be a mess. Please have a look at the Superbuild CMakeLists.txt I did for kdegraphics. It can build all-in-one, but then internally each repository is included as a cmake ExternalProject, i.e. it still builds as if it was independent (but controlled by the super-CMakeLists.txt): https://projects.kde.org/projects/kde/superbuild And you can not only do that, you could also write such a super-CMakeLists.txt for the whole KDE SC, enable only e.g. potato guy, and it will iteratively tell you which additional subprojects you need to enable to have all dependencies satisfied. Then you can build exactly that. Or you could create a source package consisting of exactly those subprojects needed for potato guy. I haven't done this for whole KDE SC yet, but I tested it on kdegraphics and kdesupport so far and it works. I'm basically waiting for more feedback especially from packagers. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7 RC1 tarballs uploaded (try #1)
On Thursday 23 June 2011, Dirk Mueller wrote: Hi, just finished uploading the first set of KDE 4.7 RC1 (4.6.90) tarballs, not well tested yet so far. this is the split build, and the l10n tarballs are still bulding. I'll spend some time on the superbuilds, or the consolidated tarballs tomorrow. I added support for different git tags per repository, for building one big tarball or one tarball per directory, and for setting additional cmake arguments for the subprojects. I did not yet write documentation, so the git log must suffice for the beginning: http://quickgit.kde.org/?p=superbuild.gita=summary You can now use separate git tags for each subproject if you want to by setting SB_GIT_TAG_ProjectName: http://quickgit.kde.org/?p=superbuild.gita=commitdiffh=f253c791f12fdf27cc364f22e40157618318835d You can now set additional cmake arguments for all subprojects, and also per- subproject by setting SB_CMAKE_ARGS and SB_CMAKE_ARGS_ProjectName: http://quickgit.kde.org/?p=superbuild.gita=commitdiffh=7455e606c967cc37d968d0ad1b4af0a1286a0825 You can create one big source tarball or one for each repository by setting SB_ONE_PACKAGE_PER_PROJECT: http://quickgit.kde.org/?p=superbuild.gita=commitdiffh=d07d965f89d39d1884896135379a8b75606febe3 Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Wednesday 22 June 2011, Dirk Mueller wrote: On Tuesday 21 June 2011, Rex Dieter wrote: Fwiw, in fedora, we hacked the 4.6.80 kde.org tarballs and build-process to be as-close-to-monolithic as possible. and do you continue to do that or would you rather see KDE providing those monolithic tarballs? Personally, I don't see how we can continue releasing both monolithic and split tarballs over a longer time, mostly due to work load reasons, unless I find a way to script this together (which I doubt..). Can you please explain what you need exactly ? Have you seen my announcement for KDE SuperBuilds ? https://projects.kde.org/projects/kde/superbuild You can use them e.g. to build the complete kdegraphics (similar to kdesrc- build) and you can also use it to create just a kdegraphics source tarball: make UpdateAll make package, which can then be unpacked anywhere and compiled. Right now there is only a CMakeLists.txt for kdegraphics, because I'd like to get more feedback before putting more work into it. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
On Tuesday 21 June 2011, Maciej Mrozowski wrote:
On Tuesday 21 of June 2011 02:46:13 Frederik Schwarzer wrote:
Hi,
because of all the trouble the moving migration caused so far,
As of now, Dirk had to ask before every release, what he should release
from where.
I thought it might be a good idea to make things more ... written-down.
http://techbase.kde.org/Projects/MovetoGit/Progress
I hope I got the current status correctly. If not, feel free to comment
here, make changes directly or hit me on IRC (icwiener).
What I am especially interested in is feedback from you, Dirk,
on how helpful this might be if properly maintained.
Excellent, thanks!
A small question to release-team here (and repo maintainers), would it be
doable to have the same branch names for all packages released under KDE
SC umbrella?
Yes, please.
Currently, while KDE/${major}.${minor} is obviously the most popular one,
variations exist.
Sounds good IMO.
I believe it doesn't help from packager point of view wrt
scripting the process - and certainly makes things a bit more complex from
distro packager point of view (hunting down all branching/tagging variants
from all project repos,
Sure it applies mostly to distros that track code from repositories - not
just when tarballs are released - which is minority I believe.
${major}.${minor} branch names can be also confusing (for newcomers but
still) in case of apps that provide own versioning as well, for instance
Okular in 4.6 branch reports itself as Okular 0.12.4, analogy with Marble
(randomly picked examples here, no strings attached).
Adding 'KDE/' prefix to branch names would without doubt denote that this
particular branch is to be used for fetching and tagging for KDE SC
distribution (when certain application is released so probably tagged
individually as well).
I understand however that consistency on this field and on tag names
imposes certain KDE workflow (to natively use KDE/${major}.${minor}
branch names) on apps that aim to sell themselves on their own
Should they maybe be in extragear then ?
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Monday 20 June 2011, Dirk Mueller wrote: On Friday 10 June 2011, Alexander Neundorf wrote: Yes, sure, but I'm away from this noon until Sunday evening. Is this needed already now for 4.7 ? I was hoping to have some more weeks to give it more testing and finish it. (it being the Superbuild CMakeLists.txt, which provide builds in old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. Alex, can I make use of that now? I would like to tag RC1 tomorrow. Please give it a try, and let me know how it goes, what is missing, etc. I guess a way to give additional cmake argument to the subprojects is at least necessary, right ? The currently existing documentation is this: https://projects.kde.org/projects/kde/superbuild Or, in other words, I do not yet have any feedback from packagers, except the early feedback from Sune in Randa, which is incorporated now, but no fresh feedback yet. So, I'd say you can try it and see whether creating the source packages and building them later on works ok, but simply using it to create the source packages and then hope they work for all packagers might be a bit much. For which modules is this right now ? kdesupport, kdegraphics, more ? kdeedu as well, kde-baseapps and kde-runtime. If you look at the superbuild CMakeLists.txt, you'll see the files are basically trivial :-) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Monday 20 June 2011, Manuel Tortosa wrote: El Monday, 20 of June de 2011, a les 22:39:40, Alexander Neundorf va escriure: Or, in other words, I do not yet have any feedback from packagers, except the early feedback from Sune in Randa, which is incorporated now, but no fresh feedback yet. Well in our case in Chakra we switched our buildsystem already for match the new separated tarballs.as in fact. our start was KDEMod, a modular KDE set of packages, so the new way is the natural way for us, even more monolithic tarballs makes hard simple things like get the kate perl bindings compiling only each tarball once. So you want the fine grained tarballs, if I understand correctly ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Friday 10 June 2011, Sebastian Kügler wrote: Hey Tom, :) On Thursday, June 09, 2011 22:21:01 Tom Albers wrote: I think we have to respond to the current problems with the beta 1 release. The adaption among distro's wasn't what we are used to due to our unclear message about if this layout is going to be final. Yeah, I think we've created quite a mess, and we need to make our releases backwards compatible for our downstreams, those that consume it. I suggest that we also add monolithic tarballs, starting from beta 2. This way we have split and combined tarballs. And I suggest that we continue to do this for the whole 4.7 cycle. And we need to discuss this again for 4.8. Yep, the layout of the tarballs should be the same as for the 4.6.0 release. On top of that, I suggest not changing the layout for 4.8. See below :) The big problem here is that the release-team has no resources to generate these monolithic tarballs. If we were to decide this, we need help from the buildsystem to adapt our scripts to generate them. The question to the buildsystem guys is, if anyone wants to stand up and help with this. I'm all for it. And I volunteer Alex! ;-) Yes, sure, but I'm away from this noon until Sunday evening. Is this needed already now for 4.7 ? I was hoping to have some more weeks to give it more testing and finish it. (it being the Superbuild CMakeLists.txt, which provide builds in old-style KDE modules or in the future maybe even an all-in-one build using CMakes ExternalProject feature). In git there is a repository superbuild now, but it's not yet done. What still needs to be done: - add special handling DESTDIR - add handling for tags - maybe some work on the implementation of ExternalProject in cmake For which modules is this right now ? kdesupport, kdegraphics, more ? Let me dump my brain and add how I see release management going forward from here: = KDE SC 4.x = * monolithic tarballs, layout like 4.6.0 release * no disruption in packages * git migration should not have effect on released tarball layout to keep packagers' lives easy * optional split tarballs (split/ subdirectory?) = 5.x = There is no 5 ;-) * KDE SC releases ship latest stable of everything * Apps require KDE Frameworks version = 5.x * Independent version numbering of apps * Plasma Desktop, Netbook, Active as separate apps * Apps can do intermittent releases, or skip cycles * KDE Frameworks 5.x ** Mostly source compatible to 4.x ** Strong backwards compatibility commitment, automatic tests if possible ** split out tarballs for KDE Qt Addons and Solutions (see discussion on kde- core-devel) ** monolithic tarballs for easier packaging ** high level git integration tool(s) to make the lives of those who build from source easier = Notes = * precise layout for split frameworks to be decided on k-c-d * first frameworks release aimed at as soon as possible after Qt 5.0 * everything else up to k-c-d * code is released from master branches, which should always be stable (see git workflow thread on k-c-d) * target groups for frameworks are specifically: distros, app developers, 3rd party developers * more frequent releases? The above provides a rough plan that is in line with the results from the Platform11 sprint in Randa. I've deliberately spared many details, to give us back some high-level overview. discuss =) 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 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 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)
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)
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: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Dirk Mueller wrote: On Wednesday 19 January 2011, Dirk Mueller wrote: so the general consensus seems to be against slipping the schedule and inserting a RC3. This means that we need to solve bug 246678. Given that there seems to be no fix in sight (no comment in the last 14 days), can we mitigate it. is there a way to disable whatever causes the problem by default? what would be the patch for that? Hi, I think the attached patch should make the services be disabled by default, thereby avoiding kde bug 246678. I'm asking for a review and a comment whether we can go ahead with this workaround for KDE 4.6.0. As the general consensus was (previously) already against slipping the schedule, I need a solution NOW to be able to release 4.6.0 in time. Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? If not, please do so. There has been a relatively significant change in it wrt to how include() and find_package() find their files (now when a file which is part of cmake calls include() or find_package() it first looks in CMAKE_ROOT/share/cmake/Modules/ instead of first looking in CMAKE_MODULE_PATH). I didn't have a lot of time since mid of December, so I didn't get around to give it a try. Also today I won't have the time and then there's already weekend, and I won't return before late Sunday. If it breaks (should error out somewhere related to FindPackageHandleStandardArgs), please let me know. Setting cmake policy CMP0017 to NEW should fix this breakage if it occurs. This would have to be done at the top of FindKDE4Internal.cmake where the other policies are set too, inside a if(POLICY CMP0017) guard. IMO if this breakge occurs, this is something which we *must* fix before the 4.6.0 release. I spent basically months of arguing and testing about this issue with the cmake devs to get this new behaviour (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way round, depending on how you see it) into cmake. Alex -- Forwarded Message -- Subject: [CMake] CMake 2.8.4-rc1 ready for testing! Date: Thursday 13 January 2011 From: David Cole david.c...@kitware.com To: cm...@cmake.org I am happy to announce that CMake 2.8.4 has entered the release candidate stage! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Following is the list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Happy building! -Dave ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf neund...@kde.org wrote: On Thursday 20 January 2011, Dirk Mueller wrote: On Wednesday 19 January 2011, Dirk Mueller wrote: so the general consensus seems to be against slipping the schedule and inserting a RC3. This means that we need to solve bug 246678. Given that there seems to be no fix in sight (no comment in the last 14 days), can we mitigate it. is there a way to disable whatever causes the problem by default? what would be the patch for that? Hi, I think the attached patch should make the services be disabled by default, thereby avoiding kde bug 246678. I'm asking for a review and a comment whether we can go ahead with this workaround for KDE 4.6.0. As the general consensus was (previously) already against slipping the schedule, I need a solution NOW to be able to release 4.6.0 in time. Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? If not, please do so. There has been a relatively significant change in it wrt to how include() and find_package() find their files (now when a file which is part of cmake calls include() or find_package() it first looks in CMAKE_ROOT/share/cmake/Modules/ instead of first looking in CMAKE_MODULE_PATH). I didn't have a lot of time since mid of December, so I didn't get around to give it a try. Also today I won't have the time and then there's already weekend, and I won't return before late Sunday. If it breaks (should error out somewhere related to FindPackageHandleStandardArgs), please let me know. Setting cmake policy CMP0017 to NEW should fix this breakage if it occurs. This would have to be done at the top of FindKDE4Internal.cmake where the other policies are set too, inside a if(POLICY CMP0017) guard. IMO if this breakge occurs, this is something which we *must* fix before the 4.6.0 release. I spent basically months of arguing and testing about this issue with the cmake devs to get this new behaviour (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way round, depending on how you see it) into cmake. Delaying 4.6.0 at this point due to a cmake that barely any distros are using seems quite foolish to me (assuming it is an issue). No, this is not foolish. All distros will use cmake = 2.8.4 in the future. It would mean that KDE 4.6.0 will forever be unbuildable with any cmake = 2.8.4. This is the code which would have to go into FindKDE4Internal.cmake in case of breakage: if(POLICY CMP0017) cmake_policy(SET CMP0011 NEW) endif(POLICY CMP0017) And I think the breakage is there. I was 2 weeks on vacation over the holidays, and just today I finally catched up with email. The respective patch was merged into cmake master early January. For testing whether KDE 4.6 branch builds with cmake 2.8.4rc1 I don't have time tonight, and then we are already visiting people until late Sunday. So please, as release coordinators, make sure this release builds with current cmake. If it doesn't, the patch above should fix it. I was working hard on this more or less constantly since last September, to come to a solution of the problem in cmake which is suitable for KDE. It took me many many hours, sweat, ... to get this, so please don't ship a KDE which does not build. And there's an easy way to fix it (see above). Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Rex Dieter wrote: On 01/20/2011 02:05 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 12:20, Alexander Neundorfneund...@kde.org wrote: On Thursday 20 January 2011, Dirk Mueller wrote: On Wednesday 19 January 2011, Dirk Mueller wrote: so the general consensus seems to be against slipping the schedule and inserting a RC3. This means that we need to solve bug 246678. Given that there seems to be no fix in sight (no comment in the last 14 days), can we mitigate it. is there a way to disable whatever causes the problem by default? what would be the patch for that? Hi, I think the attached patch should make the services be disabled by default, thereby avoiding kde bug 246678. I'm asking for a review and a comment whether we can go ahead with this workaround for KDE 4.6.0. As the general consensus was (previously) already against slipping the schedule, I need a solution NOW to be able to release 4.6.0 in time. Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ? If not, please do so. There has been a relatively significant change in it wrt to how include() and find_package() find their files (now when a file which is part of cmake calls include() or find_package() it first looks in CMAKE_ROOT/share/cmake/Modules/ instead of first looking in CMAKE_MODULE_PATH). I didn't have a lot of time since mid of December, so I didn't get around to give it a try. Also today I won't have the time and then there's already weekend, and I won't return before late Sunday. If it breaks (should error out somewhere related to FindPackageHandleStandardArgs), please let me know. Setting cmake policy CMP0017 to NEW should fix this breakage if it occurs. This would have to be done at the top of FindKDE4Internal.cmake where the other policies are set too, inside a if(POLICY CMP0017) guard. IMO if this breakge occurs, this is something which we *must* fix before the 4.6.0 release. I spent basically months of arguing and testing about this issue with the cmake devs to get this new behaviour (without the new behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way round, depending on how you see it) into cmake. Delaying 4.6.0 at this point due to a cmake that barely any distros are using seems quite foolish to me (assuming it is an issue). No, this is not foolish. All distros will use cmake= 2.8.4 in the future. It would mean that KDE 4.6.0 will forever be unbuildable with any cmake= 2.8.4. This is the code which would have to go into FindKDE4Internal.cmake in case of breakage: Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 yesterday (is that a good enough test?). Hmm, not necessarily. Were there warnings about files being shadowed, mentioning CMP0017 issued by cmake ? kdelibs would be good. Make sure all packages which are found with 2.8.3 are also found with 2.8.4rc1. There should be a FindPackageLog.txt file be created in the build directory which lists the found and not found packages. If not, try again with the patch. Thanks Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thursday 20 January 2011, Ian Monroe wrote: On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf neund...@kde.org wrote: On Thursday 20 January 2011, Ian Monroe wrote: ... Delaying 4.6.0 at this point due to a cmake that barely any distros are using seems quite foolish to me (assuming it is an issue). No, this is not foolish. All distros will use cmake = 2.8.4 in the future. There aren't too many distros in the future that will be building 4.6.0. They will be building 4.6.1 and 4.6.2. That was my point. If a distro with an aggressive cmake-upgrade policy does hit the problem they can patch it at that point. 4.6.0 is going to be tagged tonight hopefully. So, for what it's worth, here's my definitive and serious veto to that. Make sure it works properly with CMake 2.8.4rc1, if not, use the patch. Due to real life (and not having KDE as my payed job), I don't have time to check that myself before Sunday night, probably Monday night. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0 and cmake-2.8.4-rc1
On Thursday 20 January 2011, Rex Dieter wrote: On 01/20/2011 02:20 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Rex Dieter wrote: This is the code which would have to go into FindKDE4Internal.cmake in case of breakage: Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 yesterday (is that a good enough test?). Hmm, not necessarily. Were there warnings about files being shadowed, mentioning CMP0017 issued by cmake ? Yes there were lots of warnings. :( For gory details, http://kojipkgs.fedoraproject.org/packages/kdebase-runtime/4.5.95/3.fc15/da ta/logs/i686/build.log CMake Warning (dev) at /usr/share/cmake/Modules/FindThreads.cmake:156 (INCLUDE): File /usr/share/cmake/Modules/FindThreads.cmake includes /usr/share/kde4/apps/cmake/modules/FindPackageHandleStandardArgs.cmake (found via CMAKE_MODULE_PATH) which shadows /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake. This may cause errors later on . Policy CMP0017 is not set: Prefer files from the CMake module directory when including from there. Run cmake --help-policy CMP0017 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Yes, that's it exactly. FindThreads.cmake from CMake includes FindPackageHandleStandardArgs.cmake (short FPHSA.cmake) from kdelibs, while it expects to include FPHSA.cmake from cmake. This can cause breakage if the using module (FindThreads.cmake) uses new features of FPHSA.cmake, which are not yet there in the KDE-version of FPHSA.cmake. This problem is fixed by setting CMP0017 to NEW. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0 and cmake-2.8.4-rc1
On Thursday 20 January 2011, Rex Dieter wrote: On 01/20/2011 02:20 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Rex Dieter wrote: This is the code which would have to go into FindKDE4Internal.cmake in case of breakage: Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 yesterday (is that a good enough test?). Hmm, not necessarily. Were there warnings about files being shadowed, mentioning CMP0017 issued by cmake ? Yes there were lots of warnings. :( The warnings are good. They show a problem which existed before, but we were not aware of it. In CMake you can add new stuff to modules in a fully backward compatible way. This new feature, e.g. in Foo.cmake, may be used by other modules shipped with cmake. If some project, e.g. KDE, happens to ship a slightly modified version of Foo.cmake, which does not yet have that new feature, can shadow the cmake version of Foo.cmake via CMAKE_MODULE_PATH, so a module from cmake, which include()s Foo.cmake, gets the old version from KDE, and not the new version from CMake (which has the feature), and so stuff breaks. The warning about CMP0017 appears in such cases. The new behaviour in this regard is that a project can not anymore shadow files from CMake via CMAKE_MODULE_PATH for modules shipped with CMake. You can think of this like an RPATH built into the modules shipped with CMake, and CMAKE_MODULE_PATH being only LD_LIBRARY_PATH. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded
On Monday 22 November 2010, Kevin Kofler wrote: On Friday 19 November 2010, Dirk Mueller wrote: Please let me know of urgent fixes/compile issues in those tar balls. Various pieces are missing for various reasons: * The Python script engine is not being built in kdebase-workspace. We need commit 1199366 merged into the tag. (Commit 1199438 is also needed, to fix a syntax error in the Python code, but that one has already been applied to the tag.) * The Marble wallpaper support in kdeplasma-addons doesn't get built because kdeedu doesn't install FindMarble.cmake. This is fixed by revision 1198993. * kdebindings doesn't build Okular bindings because FindOkular.cmake was removed by http://websvn.kde.org/?view=revisionrevision=1179984 I see how OkularConfig.cmake is the right this to use internally, but IMHO there should still be a FindOkular.cmake installed, shouldn't there? No, there shouldn't. The purpose of a FindFoo.cmake file is to help with determining whether Foo is installed or not. It doesn't make sense that package Foo installs FindFoo.cmake along with its other files. Because then, if Foo is not installed, FindFoo.cmake, which should tell you that it's not installed, is not installed, so you'll get a cmake error that it couldn't find some file. Also, if Foo would install FindFoo.cmake, the point of FindFoo.cmake would be void, since finding FindFoo.cmake basically means that Foo has been found. Nothing new is broken if package Foo installed FindFoo.cmake before and doesn't install it anymore. It didn't handle the case that Foo was not installed properly before, and it still doesn't handle it properly if FindFoo.cmake is not installed anymore. So, either a package which uses Foo has its own FindFoo.cmake (or cmake has a FindFoo.cmake) or a FindFoo.cmake is installed with kdelibs (e.g. FindKDE4.cmake comes with cmake, and is not installed with kdelibs). What a package can do is to install a FooConfig.cmake into a cmake-specific directory (see the find_package() documentation in the cmake man page), e.g. PREFIX/lib/cmake/package/ This is done with OkularConfig.cmake: http://websvn.kde.org/trunk/KDE/kdegraphics/okular/CMakeLists.txt?r1=1179984r2=1179983pathrev=1179984 When you now do a find_package(Okular), cmake searches in a set of directories for a FooConfig.cmake, and should find and load it. Does that make it more clear ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded
On Monday 22 November 2010, Kevin Kofler wrote:
...
This is wrong on 64-bit Fedora. Should be:
${_okularBaseDir}/lib${LIB_SUFFIX}
Hardcoded paths + NO_DEFAULT_PATH are NOT a portable way to find things.
While correct in general, here this is not true.
By finding OkularConfig.cmake, the package has already been found.
There should be no need for any further searching. This is not a
FindOkular.cmake which has been found, and which can then search for Okular,
but it is a file which has been installed with this specific installation of
Okular and which contains information for this specific installation. If this
information is wrong, it needs to be fixed.
KDE allows overriding the install locations for things. You cannot rely on
everything being installed to the upstream default path.
So what needs to be done is to record the correct install locations in the
(completely installation-specific) OkularConfig.cmake.
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Keeping binary compatibility
On Friday 01 October 2010, Andreas Pakulat wrote: On 01.10.10 15:32:41, Lubos Lunak wrote: - WTH does e.g. ksysguard install libraries .so and .h files for something that looks a lot like its internal libraries? In case this is about libprocess/libprocessui they are not internal. They're useful for apps that want to present a widget with a list of processes in a nice way. KDevelop uses that to select a process to attach gdb to it. They were supposed to move to kdelibs at some point, but that didn't happen yet unfortunately. Having said that, I generally agree that there's too little information and awareness (among developers) about BC. In particular there's no place that clearly says for each module which libs should keep BC and which don't. Its apparently also pretty unknown to developers that when BC is broken the soname needs to be changed. So part of the problem is more of informational than a technical one (maybe even social) to make developers aware of their responsibility when installing shared libs. What about source compatibility ? At least for kdelibs we try to guarantee source compatiblity of the cmake files. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
On Sunday 11 July 2010, Sebastian Kügler wrote: On Thu July 8 2010 17:36:09 Maciej Mrozowski wrote: Hello From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications provided by libdbusmenu-qt to control what to draw in system tray. And apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' notifications not to be delivered - as a result causing system tray regressions - application icons not disappearing. https://bugs.kde.org/show_bug.cgi?id=232915 https://bugs.kde.org/show_bug.cgi?id=195998 https://bugs.kde.org/show_bug.cgi?id=241248 and similar reports. Because it's quite visually exposed and obvious bug (confirmed to be solved with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0). We need to communicate clearly that we really require the latest Qt for our software to work well, that's something we'll add to the release notes Hmm. Compile time vs. run time dependency, ok. But here you say we *really* require the latest Qt and that we have to communicate that clearly. IMHO the clearest and most obvious way to communicate this is to increase the minimum version of Qt to 4.6.3. Even if this version is not necessary to build, but only to make KDE run better. I know, people can still build against 4.6.3 and then run against 4.6.0, but this would be more or less intentionally violating what we recommended. I know that packagers don't like putting things in the build requirements which are in strcitly speaking runtime requirements, but at least when I build from sources I would prefer that the software tells me at build time whether my versions are ok or not. I would expect that if I have met the minimum required versions of a software, that it will work properly once it has been built successfully. So, basically, I would favour blacklisting bad (but compatible) versions. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: polkit-1 in 4.4 branch
On Monday 01 February 2010, Yury G. Kudryashov wrote: Hi! I've compiled 4.3.95 with polkit-1 kauth backend but KDE4_INSTALL_AUTH_ACTION installs action files into policykit-0 actions dir (see below). The problems seems to be fixed in trunk but there are many changes in kauth-related cmake code. Is it possible to backport these changes, or this is too large change for RC3? Dario is taking care of it. It should be working then. This will then still go into 4.4.0 ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Saturday 23 January 2010, Arno Rehn wrote:
On Friday 22 January 2010 17:52:12 Alexander Neundorf wrote:
Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
/usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
I used this:
include (HandleImportedTargetsInCMakeRequiredLibraries)
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH}
${QT_INCLUDE_DIR}) set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY}
${QT_QTDBUS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY}
${QT_QTOPENGL_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIB
RA RI ES) message(${_CMAKE_REQUIRED_LIBRARIES})
What are linkInterfaceLibs? Wouldn't it be better if they weren't added
to the list if they don't exist?
Sure, that's what the patch mentioned above should do.
If it doesn't let's fix it.
Ok, the macro works fine now. Next problem is the following:
Linking CXX shared library ../../lib/libsmokekdecore.so
/usr/bin/ld: cannot find -lQt4__QTDBUS
collect2: ld returned 1 exit status
You're kdelibs are not current, please update them e.g. to at least rev.
1076826 from the 4.4 branch.
Let me know if yu then still have this problem (the names of the imported
targets changed from Qt4__QTFOO to Qt4::QtFoo, this needed to be done before
4.4.0)
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Friday 22 January 2010, Arno Rehn wrote:
On Thursday 21 January 2010 23:31:32 Alexander Neundorf wrote:
On Thursday 21 January 2010, Arno Rehn wrote:
On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
...
HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't
depend on any other additional KDE-specific cmake modules.
I didn't try them because I thought they probably suffer from the same
bug. Since I also was too lazy to look at their code, I didn't
recognize that they work around it.
Now that it doesn't seem to be a problem for the macros, I think we'll
go with CheckCXXSourceCompiles.cmake.
Let me know (tomorrow) if it doesn't work.
So I just tried to make it work with
HandleImportedTargetsInCMakeRequiredLibraries only. It fails with many of
the following errors:
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
_linkInterfaceLibs
linked by target cmTryCompileExec in directory
/home/pumphaus/dev/KDE/kdebindings-build2/smoke/qt/test-
QT_NO_DEBUG/CMakeFiles/CMakeTmp
Is this with a current HandleImportedTargetsInCMakeRequiredLibraries.cmake
i.e. at least 1073213 ? This commit on January 11th should have fixed that.
http://websvn.kde.org/?view=revisionrevision=1073213
Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
/usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
I used this:
include (HandleImportedTargetsInCMakeRequiredLibraries)
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH} ${QT_INCLUDE_DIR})
set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY}
${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY} ${QT_QTOPENGL_LIBRARY}
${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRARI
ES) message(${_CMAKE_REQUIRED_LIBRARIES})
What are linkInterfaceLibs? Wouldn't it be better if they weren't added to
the list if they don't exist?
Sure, that's what the patch mentioned above should do.
If it doesn't let's fix it.
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 January 2010, Arno Rehn wrote: ... Sorry, I was a bit busy in the last two weeks. After doing a clean build I saw that the QtGuess.txt file returned [defined] for every QT_NO_FOO define, i.e. that compilation failed for every test (so it also defines QT_NO_PRINTDIALOG, even though that's wrong). Digging through the cmake files, I found that FindQt4.cmake was changed between KDE 4.3 and 4.4. It now uses aliases for the Qt4 libs by importing them as targets (as Qt4__QTCORE, Qt4_QTGUI, etc.). Unfortunately, this completely screws QtGuess.txt, because TRY_COMPILE (built- in cmake command) can't handle imported targets. We can only use normal paths here. A workaround would be to resolve all imported targets, but that doesn't seem like the perfect solution to me. I'm CC'ing Alexander Neundorf, as he seems to be the guy who implemented the imported targets. If there are problems with building, don't hesitate to send a mail to kde-buildsys...@kde.org. I'd say this is usually a better idea for build problems than kde-packager or kde-release-team. Alexander, can you shed some light on why this was done and how to solve this issue best? On demand of developers. We have our own copy of FindQt4.cmake, which with the time went relatively far away from the shipping with CMake. We had several issues there. Developers complained that our FindQt4.cmake didn't have all the features of the one shipping with cmake (some libs not supported etc.). Our FindQt4.cmake was not working properly with Qt as frameworks on OSX. There was a lot of unnecessary special casing for Windows in our copy. Getting too faw away from each other also means that we might become incompatible, which also breaks applications. So I took the time and merged most of the changes from both side into each other. Which also meant to always check for both release and debug versions. This lead to the effect that QT_QTFOO_LIBRARY now could be optimized libQtFoo.so debug libQtFood.so. Now this change broke some places. This way of specifying which lib is for release builds and which is for debug builds is not good (which build types are considered debug, which optimized ?) and is syntax-wise also a hack (from the POV of the cmake devs). So, what is the best way to fix this. It's to introduce imported targets for the various Qt libraries. Then there exist library targets, which can be referenced. They can be assigned different locations (file paths) for different buildtypes. Dependencies can be tracked. I tried to get this in as compatible as possible, there cannot be much left now. Why are you using TRY_COMPILE() directly ? This is quite low-level, and I would always advice against it directly. There are the check_cxx_source_compiles() and check_cxx_source_runs() macros installed with kdelibs (CheckCXXSourceCompiles.cmake and CheckCXXSourceRuns.cmake), which both handle imported targets. What is speaking against using these macros ? Both do check if a library is an imported target and if so retrieve the path, this is implemented in HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't depend on any other additional KDE-specific cmake modules. Also, I actually would be happy if you could file this as a bug report in the cmake bugtracker (http://public.kitware.com/Bugs) that try_compile() doesn't handle imported targets. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 January 2010, Arno Rehn wrote: On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote: ... HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't depend on any other additional KDE-specific cmake modules. I didn't try them because I thought they probably suffer from the same bug. Since I also was too lazy to look at their code, I didn't recognize that they work around it. Now that it doesn't seem to be a problem for the macros, I think we'll go with CheckCXXSourceCompiles.cmake. Let me know (tomorrow) if it doesn't work. Also, I actually would be happy if you could file this as a bug report in the cmake bugtracker (http://public.kitware.com/Bugs) that try_compile() doesn't handle imported targets. You've already done that yourself, nearly one year ago ;) http://public.kitware.com/Bug/view.php?id=8761 Oh, indeed. I remembered that discussion but I thought it was via email. The bug's still open, though. Yes, I know. Feel free to add a comment in the bug report. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Thursday 07 January 2010, Raphael Kubo da Costa wrote: On Thu, Jan 7, 2010 at 3:53 PM, Alexander Neundorf neund...@kde.org wrote: SVN commit 1071192 by neundorf: we require CMake 2.6.2 or KDE, nothing else has been announced, discussed or even suggested Alex CCMAIL: kde-buildsys...@kde.org CCMAIL: muel...@kde.org M +1 -1 FindKDE4Internal.cmake --- trunk/KDE/kdelibs/cmake/modules/FindKDE4Internal.cmake #1071191:1071192 @@ -275,7 +275,7 @@ # this is required now by cmake 2.6 and so must not be skipped by if(KDE4_FOUND) below -cmake_minimum_required(VERSION 2.6.3 FATAL_ERROR) +cmake_minimum_required(VERSION 2.6.2 FATAL_ERROR) # set the cmake policies to the 2.4.x compatibility settings (may change for KDE 4.3) cmake_policy(VERSION 2.4.5) Short note: the discussion seems to be taking place in the release-team and kde-packager mailing lists: CCing them... In case there are problems with the buildsystem, please post to kde-buildsys...@kde.org, or k-c-d. At least CC me. Increasing the required version of CMake for kdelibs without asking what the problem is, discussing it and announcing it a few weeks before the switch then actually happens is an absolute no-go. apparently CMake 2.6.3 isn't able to find SharedDesktopOntologies correctly on some systems. So, what's not working ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE/kdelibs/cmake/modules
SVN commit 1071218 by neundorf:
-make cmake 2.6.2 find SDO 0.2
This didn't work since SDO 0.2 installs its files into share/cmake/SDO/, which
is supported
by cmake = 2.6.3, but not by 2.6.2, which KDE requires.
It would be nice if SDO would install it into share/SDO/ or share/SDO/cmake,
then it would be
found automatically by cmake 2.6.2 and also 2.6.3 and all newer versions.
Alex
CCMAIL: kde-buildsys...@kde.org
CCMAIL: muel...@kde.org
CCMAIL: release-team@kde.org
CCMAIL: tr...@kde.org
CCMAIL: kde-packag...@kde.org
M +8 -1 FindSharedDesktopOntologies.cmake
--- trunk/KDE/kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake
#1071217:1071218
@@ -21,8 +21,15 @@
# First try the SharedDesktopOntologiesConfig.cmake from
shared-desktop-ontologies 0.2 and newer
-find_package(SharedDesktopOntologies ${SharedDesktopOntologies_FIND_VERSION}
QUIET NO_MODULE)
+# This is to make it work with cmake 2.6.2, since SDO 0.2 installs its config
file into
+# the 2.6.3 compatible location only ( share/cmake/SDO/ instead
share/SDO/[cmake/] )
+if( ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
VERSION_LESS 2.6.3)
+ find_path(_SDO_CONFIG_DIR SharedDesktopOntologiesConfig.cmake PATH_SUFFIXES
share/cmake/SharedDesktopOntologies/ )
+endif( ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
VERSION_LESS 2.6.3)
+
+find_package(SharedDesktopOntologies ${SharedDesktopOntologies_FIND_VERSION}
QUIET NO_MODULE HINTS ${_SDO_CONFIG_DIR} )
+
if (SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
mark_as_advanced(SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
endif (SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
branches/KDE/4.4/kdelibs/cmake/modules
SVN commit 1071246 by neundorf:
-we require 2.6.2, nothing else, we can discuss a higher version for 4.5, not
for 4.4.x.
How can you change like the most important property of our buildsystem while
branching for the release without even letting kde-buildsystem or the
maintainer (me) know ???
Alex
CCMAIL: release-team@kde.org
M +1 -1 FindKDE4Internal.cmake
M +8 -1 FindSharedDesktopOntologies.cmake
--- branches/KDE/4.4/kdelibs/cmake/modules/FindKDE4Internal.cmake
#1071245:1071246
@@ -275,7 +275,7 @@
# this is required now by cmake 2.6 and so must not be skipped by
if(KDE4_FOUND) below
-cmake_minimum_required(VERSION 2.6.3 FATAL_ERROR)
+cmake_minimum_required(VERSION 2.6.2 FATAL_ERROR)
# set the cmake policies to the 2.4.x compatibility settings (may change for
KDE 4.3)
cmake_policy(VERSION 2.4.5)
--- branches/KDE/4.4/kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake
#1071245:1071246
@@ -21,8 +21,15 @@
# First try the SharedDesktopOntologiesConfig.cmake from
shared-desktop-ontologies 0.2 and newer
-find_package(SharedDesktopOntologies ${SharedDesktopOntologies_FIND_VERSION}
QUIET NO_MODULE)
+# This is to make it work with cmake 2.6.2, since SDO 0.2 installs its config
file into
+# the 2.6.3 compatible location only ( share/cmake/SDO/ instead
share/SDO/[cmake/] )
+if( ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
VERSION_LESS 2.6.3)
+ find_path(_SDO_CONFIG_DIR SharedDesktopOntologiesConfig.cmake PATH_SUFFIXES
share/cmake/SharedDesktopOntologies/ )
+endif( ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
VERSION_LESS 2.6.3)
+
+find_package(SharedDesktopOntologies ${SharedDesktopOntologies_FIND_VERSION}
QUIET NO_MODULE HINTS ${_SDO_CONFIG_DIR} )
+
if (SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
mark_as_advanced(SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
endif (SHAREDDESKTOPONTOLOGIES_ROOT_DIR)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Moving LibAttica to kdesupport
Hi Frederik, On Tuesday 17 November 2009, Frederik Gladhorn wrote: Hi, I'd like to move libattica to kdesupport (it has spent its two weeks in review now), so that it can be released with KDE 4.4. This will allow great improvements in the Get Hot New Stuff, things like the new Social About Dialog that Amarok has and big improvements in the OpenDesktop/Social plasma applets. It would be great if the release team could take care of the tagging and tarballing. Anything else that needs to be done from my side? Right now there are I just noticed that you added a cmake module FindAttica.cmake to kdelibs/cmake/modules/, which is also installed. When working with the cmake modules in kdelibs, the commit policy should be followed: http://techbase.kde.org/Policies/CMake_Commit_Policy (first rule there says new files must be sent to kde-buildsys...@kde.org for review. They may only be added after an explicit Ok.) You did not do that and from you emails about moving it to kdereview it also was not obvious that it involves the cmake modules for kdelibs. Why is that important... Adding a module to kdelibs which is also installed means you add a part of the public API which must be kept compatible for all of KDE 4. So installing such a file comes with a cost. I had a look at the file as it is now, and it is not good. It does not work at all on Windows, it used pkg-config in a bad and documented as such) way. It cannot stay as it is now. Please have a look e.g. at FindLibXml2.cmake for a proper example how to use pkg-config in a cmake module. Next question: is this module actually necessary at all ? Who are the users of it ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Moving LibAttica to kdesupport
On Tuesday 17 November 2009, Téo Mrnjavac wrote: On Tue, Nov 17, 2009 at 20:18, Alexander Neundorf neund...@kde.org wrote: Hi Frederik, Next question: is this module actually necessary at all ? Who are the users of it ? Alex Hello We already use LibAttica in Amarok, currently it's just crudely copied inside our codebase until it lands in kdesupport, we look forward to this so we can have a clean solution. Also I plan to port Amarok's social about dialog to kdelibs for 4.5 and I would need LibAttica for that. So currently it is used in amarok (which is not in trunk/KDE/) and in the future it will be used in kdelibs. Are these the only users of libattica right now ? (btw. how abpout renaming FindAttica.cmake to FindLibAttica.cmake ?) If so, I think kdelibs should not have and install FindAttica.cmake. I mean, installing a cmake module is like installing a public header. And kdelibs is not the place to put things which are required by software somewhere else, i.e. outside trunk/KDE/. For moving code/libraries to kdelibs there is the rule that there must be at least two users of that library in trunk/KDE/, I think this should apply also to cmake modules. If you install a (Lib)AtticaConfig.cmake alongside with libattica, find_package() will even find it automatically without requiring a Find(Lib)Attica.cmake, for details see the config-mode of find_package() in the cmake documentation. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
Hi,
we have a patch regarding Soprano. It's already in trunk, and by still getting
this into 4.3.0 we can hopefully avoid compatiblity issues later on.
CMakeLists.txt using soprano right now do
include(SopranoAddOntology.cmake)
so that file must be somewhere in CMAKE_MODULE_PATH, and stay there, and also
with that name. The patch makes that unnecessary and moves the include to
FindSoprano.cmake, so it is nicely encapsulated and can potentially be
changed later on.
On Thursday 30 July 2009, Sebastian Trüg wrote:
On Wednesday 29 July 2009 22:36:17 Alexander Neundorf wrote:
Hi Sebastian,
--- trunk/KDE/kdelibs/cmake/modules/FindSoprano.cmake #1004263:1004264
@@ -47,18 +47,6 @@
${KDE4_INCLUDE_DIR}
)
- # find the cmake macro file installed by soprano, relative to the
include dir - get_filename_component(_SOPRANO_PREFIX
${SOPRANO_INCLUDE_DIR} PATH) - # first check in
prefix/share/soprano/cmake, if it's not found there, check in
prefix/share/apps/cmake/modules - # find_file(_SOPRANO_MACRO_FILE
NAMES SopranoAddOntology.cmake HINTS
${_SOPRANO_PREFIX}/share/soprano/cmake ) -
find_file(_SOPRANO_MACRO_FILE NAMES SopranoAddOntology.cmake HINTS
${_SOPRANO_PREFIX}/share/apps/cmake/modules ) -
- # since which version of soprano is this file installed ?
- # we should fail if the file is not found but SOPRANO_MIN_VERSION is
bigger than this version. - if(_SOPRANO_MACRO_FILE)
-include(${_SOPRANO_MACRO_FILE})
- endif(_SOPRANO_MACRO_FILE)
-
find_library_with_debug(SOPRANO_INDEX_LIBRARIES
WIN32_DEBUG_POSTFIX d
NAMES
@@ -186,6 +174,23 @@
set(_plugins ${_plugins} virtuosobackend)
endif(EXISTS ${SOPRANO_PLUGIN_DIR}/virtuosobackend.desktop)
+# make sure the Soprano cmake macros are found
+# We also include it directly for convinience
+get_filename_component(_SOPRANO_PREFIX ${SOPRANO_INCLUDE_DIR}
PATH) +find_file(_SOPRANO_MACRO_FILE NAMES SopranoAddOntology.cmake
HINTS ${_SOPRANO_PREFIX}/share/soprano/cmake ) +
if(_SOPRANO_MACRO_FILE) + # new Soprano 2.3.0 location
+ include(${_SOPRANO_MACRO_FILE})
+ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
${_SOPRANO_PREFIX}/share/soprano/cmake) +else(_SOPRANO_MACRO_FILE)
+ # the old Soprano 2.3.0 location
+ find_file(_SOPRANO_MACRO_FILE_OLD NAMES SopranoAddOntology.cmake
HINTS ${_SOPRANO_PREFIX}/share/apps/cmake/modules ) +
if(_SOPRANO_MACRO_FILE_OLD)
+include(${_SOPRANO_MACRO_FILE_OLD})
+set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
${_SOPRANO_PREFIX}/share/apps/cmake/modules) +
endif(_SOPRANO_MACRO_FILE_OLD)
+endif(_SOPRANO_MACRO_FILE)
+
endif(Soprano_FOUND)
if(Soprano_FOUND)
I think this looks good.
Although it's a bit ugly to add that directory to CMAKE_MODULE_PATH, it's
probably necessary.
yes, I think so, too. The only other possibility would be to include the
macro in KDE.
You mean FindSoprano.cmake could actually just include the macro ?
I wouldn't object.
Can you still add the include()-commands to the FindSoprano.cmake to the
4.3 branch and remove the extra, now unnecessary include()-commands in
the CMakeLists.txt of soprano-using apps there ?
Sure, I can do that. :)
I thought it would be better to only do that in trunk and leave 4.3 as much
unchanged as possible.
Yes, sure, but it would be even nicer if we would have 4.3.0 without these
include()s.
Can you try to get the 4.3.0 tag moved for these files ?
It is already tagged? Hm, I would not know how to do that except maybe
commiting the changes to the tag, too.
I guess we'd have to contact the release team.
Do you know if there are users outside svn KDE/ ?
I don't know.
If not, and if these issues can still be fixed in time, is the
modification of CMAKE_MODULE_PATH actually necessary ?
Well, I mostly wanted it to work in 4.3 and did not see the big issue with
modifying the module path.
Changing CMAKE_MODULE_PATH can change which files are found, also which
directories are preferred before others. So changing this can lead to
compatibility problems (as we are seeing right now).
I still think changing CMAKE_MODULE_PATH for the modules installed by kdelibs
is ok, but in general we should try to avoid such things.
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2 branched
On Wednesday 07 January 2009, you wrote: On Tuesday 06 January 2009, Alexander Neundorf wrote: Is it ok to make all modules in the 4.2 branch require at least version 4.1.96 of kdelibs ? Yes, please do that, and document the steps in kde-common/release/RELEASE- CHECKLIST so that I can do them myself next time :) I don't have time to do it today, I could do it tomorrow. That's what you have to do: either (should work, haven't tested it for some time): set(KDE_MIN_VERSION 4.1.96) find_package(KDE4 REQUIRED) or (tested recently in kdepimlibs): find_package(KDE4 4.1.96 REQUIRED) Or should they stay working with trunk from e.g. last week ? Should we increase the version in trunk now to 4.2.80 or something ? did so already before reading your email, sorry. So I don't have to do it :-) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2 branched
On Tuesday 06 January 2009, Dirk Mueller wrote: Hi, on our road towards KDE 4.2 RC1 tagging (tonight), I've just branched KDE 4.2 into /branches/KDE/4.2 from trunk/KDE svn revision 906698 (yes, I couldn't wait for 906700). Is it ok to make all modules in the 4.2 branch require at least version 4.1.96 of kdelibs ? Or should they stay working with trunk from e.g. last week ? Should we increase the version in trunk now to 4.2.80 or something ? I'll do that if you agree. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: tags/kdesupport-for-4.2
On Saturday 03 January 2009, Tom Albers wrote: Hi, In preparation of the release of 4.2.0, I've created the tags/kdesupport-for-4.2. This tag of kdesupport should be used when you compile the 4.2 branch in the future. Trunk's version of kdesupport should be used to compile KDE trunk (which would be KDE 4.3.0). At least Akonadi will probably commit some KDE 4.2.x incompatible changes in kdesupport trunk as soon as KDE 4.2 is branched. Request to all kdesupport maintainers: add the version of your software into that tag soon please. Toma Another request to all kdesupport maintainers: KDE 4.2 will require CMake 2.6.2. The different projects in kdesupport require different versions of CMake: CMake 2.4.5: qca kdewin-installer akonadi automoc eigen2/bench/btl/ CMake 2.6.2: kdewin32 All others require CMake 2.6.0. It would make it easier for us, if all the projects in kdesupport also would require CMake 2.6.2, then the same features we can use in KDE can be used also in kdesupport. Right now this is harder, since one always has to take care in which project of kdesupport you are editing and if you are allowed to use cmake 2.6 feature there or not. This will probably also introduce breakges from time to time if somebody adds something which requires 2.6.2 while the project says the minimum version is 2.4.5. So, if you think it's a good idea, please upgrade your minimum required version to 2.6.2. My guess is that it might be ok for the 2.6.0 projects to upgrade to 2.6.2, but I think the respective maintainers have to do this. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[REMINDER] next monday cmake 2.6.2 will be required
Hi, in case you didn't update yet to cmake 2.6.2, please do so soon, next monday it will be required, as announced two weeks ago. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: automoc in kdesupport-issue
On Tuesday 22 July 2008, Dirk Mueller wrote: On Saturday 19 July 2008, Matthias Kretz wrote: That's not entirely right. For the last beta I asked dirk to do the automoc4 0.9.83 tarball. You can find it on ftp.kde.org. unstable/support/automoc4 I need an automoc4 0.9.84 release as soon as possible, though. (I already released one package on kde-apps.org that needs 0.9.84 when using cmake 2.6) which svn revision should we use for the new release? note that I don't like the %_libdir dependency (it doesn't make sense to install a .cmake file which is platform independent under /lib/ anyway). The installed .cmake file is platform dependent, potentially architecture dependent. The purpose of these files is to contain information about the installed package, created by the installed package, so the Find-module doesn't have to guess but can simply include that file. This can contain e.g. paths to libraries, compiler or linker flags, etc., i.e. very platform dependent information. Currently for automoc4 the information isn't platform dependent, but I don't want to guarantee that it never will be, so I'd prefer to keep that in lib/ instead of share/. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
automoc in kdesupport-issue
Hi, several weeks ago we (me and Matthias) moved automoc from kdelibs to kdesupport so that the automoc-functionality ( #include foo.moc and all the rest happens magically) can be used also by non-KDE apps, as e.g. phonon, akonadi, etc.. This works so far, but we kept automoc in kdelibs so it could be used optionally in case kdesupport wasn't current. We made automoc from kdesupport mandatory a few weeks ago, so the first release which requires automoc from kdesupport was 4.1RC1. It seems this didn't go very smoothly. There are some complaints from people who couldn't build KDE because they didn't have automoc (from kdesupport). We haven't done an official separate automoc release yet. How should this be handled ? (I would like if kdesupport would be released together with the rest of KDE, or at least be tagged, so later on it is easier to find a matching version) Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-cvs-announce] KDE 4.0 Release Branch
On Friday 04 January 2008, Dirk Mueller wrote: Hi, a KDE 4.0 Release branch has been created: svn+ssh|https://svn.kde.org/home/kde/branches/KDE/4.0 The translations for 4.0 are currently served from /trunk/l10n-kde4. The (hopefully) final tarball set will be created from this branch. if your change is not in there then its not going to be in 4.0. /trunk/KDE is targetting 4.1 now, but please remember to focus your attention on /branches/KDE/4.0. Would it make sense to also tag/branch kdesupport together with the rest of KDE ? I always found it a bit hard to get a matching version of kdesupport when building an older version of KDE. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Thursday 03 January 2008, Luboš Luňák wrote:
SVN commit 756696 by lunakl:
Consistent naming for xf86misc - include and flag are xf86misc, lib is
Xxf86misc.
I'm not sure this change is good:
This is a source incompatible change.
Somebody may use these variables and now they don't exist anymore, so his
build may fail.
We are at the day of the tagging, IMO too late for such changes.
It makes our FindX11.cmake incompatible to the one in CMake, which makes it
harder for us to use the CMake version, since it requires more changes once
we do that (after merging differences etc.).
Did you intentionally leave the name X11_Xxf86misc_LIB as it is ?
I feel like reverting this patch both for 4.1 and 4.0 would be the best thing
to do. Since I don't know in which other places you had to commit changes to
use these new names I don't feel like doing that myself.
Alex
M +9 -9 FindX11.cmake
--- trunk/KDE/kdelibs/cmake/modules/FindX11.cmake #756695:756696
@@ -17,8 +17,8 @@
#X11_dpms_INCLUDE_PATH, (in X11_Xext_LIB),
X11_dpms_FOUND #X11_XShm_INCLUDE_PATH, (in
X11_Xext_LIB), X11_XShm_FOUND #X11_Xshape_INCLUDE_PATH,
(in X11_Xext_LIB), X11_Xshape_FOUND -#
X11_Xf86misc_INCLUDE_PATH, X11_Xxf86misc_LIB, X11_Xf86misc_FOUND -#
X11_xf86vmode_INCLUDE_PATH,
X11_Xf86vmode_FOUND +#X11_xf86misc_INCLUDE_PATH,
X11_Xxf86misc_LIB, X11_xf86misc_FOUND +#
X11_xf86vmode_INCLUDE_PATH,X11_xf86vmode_FOUND #
X11_Xfixes_INCLUDE_PATH, X11_Xfixes_LIB,
X11_Xfixes_FOUND #X11_Xft_INCLUDE_PATH,
X11_Xft_LIB,X11_Xft_FOUND #
X11_Xinerama_INCLUDE_PATH, X11_Xinerama_LIB, X11_Xinerama_FOUND @@
-80,7 +80,7 @@
FIND_PATH(X11_Xdamage_INCLUDE_PATH X11/extensions/Xdamage.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_Xdmcp_INCLUDE_PATH X11/Xdmcp.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_dpms_INCLUDE_PATH
X11/extensions/dpms.h ${X11_INC_SEARCH_PATH}) -
FIND_PATH(X11_Xf86misc_INCLUDE_PATH X11/extensions/xf86misc.h
${X11_INC_SEARCH_PATH}) + FIND_PATH(X11_xf86misc_INCLUDE_PATH
X11/extensions/xf86misc.h ${X11_INC_SEARCH_PATH})
FIND_PATH(X11_xf86vmode_INCLUDE_PATH X11/extensions/xf86vmode.h
${X11_INC_SEARCH_PATH}) FIND_PATH(X11_Xfixes_INCLUDE_PATH
X11/extensions/Xfixes.h ${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xft_INCLUDE_PATH X11/Xft/Xft.h
${X11_INC_SEARCH_PATH}) @@ -236,10 +236,10 @@
SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xrandr_INCLUDE_PATH})
ENDIF (X11_Xrandr_INCLUDE_PATH AND X11_Xrandr_LIB)
- IF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
- SET(X11_Xxf86misc_FOUND TRUE)
- SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xxf86misc_INCLUDE_PATH})
- ENDIF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
+ IF (X11_xf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
+ SET(X11_xf86misc_FOUND TRUE)
+ SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_xf86misc_INCLUDE_PATH})
+ ENDIF (X11_xf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB)
IF (X11_xf86vmode_INCLUDE_PATH)
SET(X11_xf86vmode_FOUND TRUE)
@@ -399,7 +399,7 @@
X11_Xrender_LIB
X11_Xrender_INCLUDE_PATH
X11_Xxf86misc_LIB
-X11_Xxf86misc_INCLUDE_PATH
+X11_xf86misc_INCLUDE_PATH
X11_xf86vmode_INCLUDE_PATH
X11_Xinerama_LIB
X11_Xinerama_INCLUDE_PATH
@@ -415,7 +415,7 @@
X11_Xaccessrules_INCLUDE_PATH
X11_Xaccessstr_INCLUDE_PATH
X11_Xdmcp_INCLUDE_PATH
-X11_Xf86misc_INCLUDE_PATH
+X11_xf86misc_INCLUDE_PATH
X11_Xkb_INCLUDE_PATH
X11_Xkblib_INCLUDE_PATH
X11_Xkbfile_INCLUDE_PATH
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: On Thursday 03 January 2008, Luboš Luňák wrote: SVN commit 756696 by lunakl: Consistent naming for xf86misc - include and flag are xf86misc, lib is Xxf86misc. I'm not sure this change is good: This is a source incompatible change. Somebody may use these variables and now they don't exist anymore, so his build may fail. It will at most not detect the feature, but even then that's very unlikely, as xf86misc is only very special functionality. Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. I mean, it was that way since February 23rd, 2006, and you changed it now after almost two years only hours before tagging 4.0.0 without sending a patch first. Although unlikely, this was a source incompatible change. We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. So the fix would have been to fix that single file. Now I have to deal with that in CMake and *hope* nobody has used this already and complains that CMake constantly breaks compatibility :-/ Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: ... In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. You're wrong, there was actually an error inside FindX11.cmake, and you fixed it :-) Here it was spelled wrong: IF (X11_Xxf86misc_INCLUDE_PATH AND X11_Xxf86misc_LIB) I think this is good enough as argument to keep your change and fix/change it in cmake instead. Bye Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. I mean, it was that way since February 23rd, 2006, and you changed it now after almost two years only hours before tagging 4.0.0 without sending a patch first. Although unlikely, this was a source incompatible change. Change it back if it's so. What's the current state of 4.0.0 tagging/packaging ? Sorry, I didn't realize we have a copy of large portion of CMake in our SVN. We have a bunch of own cmake modules (which don't exist in CMake) and we have some modified copies of CMake modules there. My goal has been to sync from time to time with cmake, so that later on we can remove some of our own modules and rely on the ones which come with cmake. FindX11.cmake is one of them. Does that mean we shouldn't touch anything under cmake/ ? No, I'm actually happy that there are so many people working on the stuff there :-) Developers just need to be aware that changing things in cmake can also mean source incompatible changes. This also means we have to make sure they stay compatible for all KDE 4.x.y just the same way as we do for the actual sources. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 January 2008, Lubos Lunak wrote: On Friday 04 of January 2008, Alexander Neundorf wrote: ... What's the current state of 4.0.0 tagging/packaging ? I'm not sure, but I think 4.0.0 really doesn't matter that much. Can I have that signed and written on paper, please ? ;-) This xf86misc stuff is _very_ obscure, even I barely know what it is. If this gets changed for 4.1 and 4.0.1 in any way, I don't think anybody will notice. Does that mean we shouldn't touch anything under cmake/ ? No, I'm actually happy that there are so many people working on the stuff there :-) Beside that, I tried to keep an eye on the commits to the files there, which cannot have worked 100%, but I hope for a significant part of the commits. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: disabling kdenetwork/lanbrowsing for 4.0.0
On Wednesday 02 January 2008 16.22:25 Tom Albers wrote: Hi, Thanks for informing this list. Do you plan to work on it in the future? If not, I think it is better to move it to /tags/unmaintained/4 If you do, we might consider moving it to playground for now. What do you think? How is the state of lanbrowsing? Does it basically work (I see that it at least compiles...)? If it does not work, I fully agree with Tom. I didn't actually test it (I don't have a use for it anymore since basically 5 years and more than enough other things to do), but since the lisa daemon doesn't use Qt nor KDE libs, it should work. Because of the above (I don't have a use for it anymore) I don't plan to really work on it (beside that, it is basically feature-complete, except configuration/setup). I wanted to put a call-for-maintainer somewhere since a long time already, but didn't get around to do it. It should be moved to one of the above listed places. Alex, please decide ;) So, I guess moving it to unmaintained sounds like the right thing to do. Can you please do that ? Thanks Alex P.S. please CC me, I'm not subscribed ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
disabling kdenetwork/lanbrowsing for 4.0.0
Hi, in kdenetwork there is lanbrowsing/, which consists of: -the lisa daemon, a daemon which basically scans the local network for IP addresses which respond to ping packets, and which cooperates with other lisa daemons in the network -the lan:/ ioslave, which queries the lisa daemon, and which check (on demand) the samba, nfs, http, and ssh ports on a host to offer these services of a host as directories via kio -a control module for all that I wrote that in KDE 2 times, and more or less since end of 2002 I didn't really work on it, especially not for KDE 4. In the meantime there are technologies like Zeroconf, which should be able to do the same job, just better. Therefor I'd like to disable lanbrowsing from kdenetwork for the 4.0.0 release, patch attached. Ok ? Alex Index: CMakeLists.txt === --- CMakeLists.txt (revision 755977) +++ CMakeLists.txt (working copy) @@ -69,7 +69,8 @@ macro_optional_add_subdirectory(kget) macro_optional_add_subdirectory(kopete) macro_optional_add_subdirectory(krdc) -macro_optional_add_subdirectory(lanbrowsing) +# disable lanbropwsing for now, it's basically unmaintained and zeroconf should do the job better: +# macro_optional_add_subdirectory(lanbrowsing) if(Q_WS_X11) macro_optional_add_subdirectory(kppp) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
