Re: kdelibs, kdebase moving to Git this Saturday
On Wednesday 26 January 2011, Ian Monroe wrote: The basic schedule will be that sometime on Saturday the repos listed in the subject will be made read-only, we'll make the conversion and upload them to git.kde.org. The subversion directories will be emptied and replaced with a README. *Both* the 4.6 and trunk branches are moving. For up to one week if someone finds a major problem in the history a re-push will be considered. After that we'll just live with it. ...but far better would be for any problem to be found now. Please note that the repo names are not the final ones (they will be konsole, kde-baseapps, kde-workspace, kde-runtime, kdelibs). git://anongit.kde.org/scratch/nalvarez/kdelibs-convtest git://anongit.kde.org/scratch/ianmonroe/kdebase-apps git://anongit.kde.org/scratch/ianmonroe/kdebase-runtime git://anongit.kde.org/scratch/ianmonroe/kdebase-workspace git://anongit.kde.org/scratch/ianmonroe/konsole in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. Cheers, Marco Martin
Re: kdelibs, kdebase moving to Git this Saturday
On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. -- Best regards, Eike Hein
Re: kdelibs, kdebase moving to Git this Saturday
On Sunday 30 January 2011 13:17:01 Marco Martin wrote: On Wednesday 26 January 2011, Ian Monroe wrote: The basic schedule will be that sometime on Saturday the repos listed in the subject will be made read-only, we'll make the conversion and upload them to git.kde.org. The subversion directories will be emptied and replaced with a README. *Both* the 4.6 and trunk branches are moving. For up to one week if someone finds a major problem in the history a re-push will be considered. After that we'll just live with it. ...but far better would be for any problem to be found now. Please note that the repo names are not the final ones (they will be konsole, kde-baseapps, kde-workspace, kde-runtime, kdelibs). git://anongit.kde.org/scratch/nalvarez/kdelibs-convtest git://anongit.kde.org/scratch/ianmonroe/kdebase-apps git://anongit.kde.org/scratch/ianmonroe/kdebase-runtime git://anongit.kde.org/scratch/ianmonroe/kdebase-workspace git://anongit.kde.org/scratch/ianmonroe/konsole in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. Found more beasties like that in other repos as well. Fixing them as I go, but kde-runtime is read-only (asked on #kde-sysadmin the conversion of that one might have issues they're looking into it) so I can't push my fixes for that one. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: kdelibs, kdebase moving to Git this Saturday
We've allowed Kevin to push two commits to the repo that fix the build failure to minimize interruptions, but the repo otherwise remains read-only for now until the his- tory conversion problems are dealt with. -- Best regards, Eike Hein
Re: Please test: [CMake] CMake 2.8.4-rc1 ready for testing!
On Saturday 29 January 2011, Christophe Giboudeaux wrote: Hi, On Tuesday 18 January 2011 21:58:24 Alexander Neundorf wrote: So please, give this release candidate a good try, and let me know if something fails. Quick feedback. Thanks for finally turning off the verbose makefile when using the codeblock generator. I didn't notice any regression but an unexpected behaviour with the graphviz generator. With kdepimlibs, I use --graphviz=kdepimlibs_graph.dot. Previously, this was generating only one file for the whole module. Now it seems a graph is also generated for *every* target: # ls kdepimlibs_graph.dot* kdepimlibs_graph.dot kdepimlibs_graph.dot.kabc_file kdepimlibs_graph.dot.testattendee kdepimlibs_graph.dot.abort kdepimlibs_graph.dot.kabc_file_core kdepimlibs_graph.dot.testblogcomment kdepimlibs_graph.dot.actionstatemanagertest kdepimlibs_graph.dot.kabcformat_binary kdepimlibs_graph.dot.testblogger1 kdepimlibs_graph.dot.addresseetest kdepimlibs_graph.dot.kabc_ldapkio etc... Yes. That's a feature. The dot-file generation before was buggy and incomplete. E.g. when running it on kdelibs it produced a file where dependencies were missing and also targets were missing. And if all that was in one file correctly, then the produced dot-file is too big to be usable. At least I didn't find a way to view it in a way that I can actually see something. So now there is one dot-file for every target. You can also put a file named CMakeGraphVizOptions.cmake in CMAKE_SOURCE_DIR or CMAKE_BINARY_DIR. This can be used to set option for the dot-file generator. GRAPHVIZ_EXECUTABLES : boolean GRAPHVIZ_STATIC_LIBS: boolean GRAPHVIZ_SHARED_LIBS: boolean GRAPHVIZ_MODULE_LIBS: boolean GRAPHVIZ_TARGET_IGNORE_REGEX: regex for target names which should be skipped GRAPHVIZ_IGNORE_TARGETS: list of targets which should be skipped e.g. set(GRAPHVIZ_TARGET_IGNORE_REGEX .+test) to exclude all tests. Yes, this is currently completely undocumented. Alex
Re: kdelibs, kdebase moving to Git this Saturday
- Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. I'ld like to ask everyone to check the repo's NOW, so the conversion people can have a full list of problems and we don't have to repush 3 times this week, but only once. Best, -- Tom Albers KDE Sysadmin
Re: kdelibs, kdebase moving to Git this Saturday
On Sunday 30 January 2011 14.38.17 Tom Albers wrote: - Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. I'ld like to ask everyone to check the repo's NOW, so the conversion people can have a full list of problems and we don't have to repush 3 times this week, but only once. enterprise branches missing from kdelibs /Regards Torgny
Re: kdelibs, kdebase moving to Git this Saturday
On Sunday 30 January 2011, Tom Albers wrote: - Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. actually, doesn't seem a missing file. the file in question is oxygenhelper.h in workspace/libs/oxygen included by workspace/kwin/clients/oxygen/oxygendecohelper.h but even if existing the file is not found, while building from svn that file is found fine. Cheers, Marco Martin
Re: kdelibs, kdebase moving to Git this Saturday
2011/1/30 Marco Martin: On Sunday 30 January 2011, Tom Albers wrote: - Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. actually, doesn't seem a missing file. the file in question is oxygenhelper.h in workspace/libs/oxygen included by workspace/kwin/clients/oxygen/oxygendecohelper.h but even if existing the file is not found, while building from svn that file is found fine. The file oxygenhelper.h is actually in kde-workspace/libs/oxygen/, it seems that it's not found properly at that location. Could it be that noone noticed that problem before the git migration because the very recent commit http://websvn.kde.org/?view=revisionrevision=1217934 added oxygendecohelper.cpp as a source file for the new build target oxygen-shadow-demo? Maybe the reason why the error didn't appear earlier is that oxygendecohelper.cpp was never compiled before that commit, so noone noticed that the missing header isn't there...
Re: kdelibs, kdebase moving to Git this Saturday
On Sunday 30 January 2011 15:06:53 Marco Martin wrote: On Sunday 30 January 2011, Tom Albers wrote: - Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. actually, doesn't seem a missing file. the file in question is oxygenhelper.h in workspace/libs/oxygen included by workspace/kwin/clients/oxygen/oxygendecohelper.h but even if existing the file is not found, while building from svn that file is found fine. I fixed both issues already, pushed like an hour or two ago. One looked like a missing commit indeed, the other one is because in that module we used KDEBASE_WORKSPACE_SOURCE_DIR everywhere, but nothing is setting it anymore after the split. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Initial support for kde_projects.xml in kdesrc-build
Hi all, Just a quick email as I'm already late getting to bed, but I just wanted to let you know (in case you're interested) that I've just committed initial support for the kde_projects.xml database to kdesrc-build (in git; xml-support branch). It requires using a use-xml-modules option in a module-set (where you'd use the existing use-modules option). e.g. module-set use-xml-modules kdebindings krita-extensions konsole end module-set since the repository information for an XML module is encoded as part of the XML there's really not much else to configure as far as finding the git repositories goes. Other options can still be set as normal. If a module doesn't show up where you expect in your kdesrc-build --pretend output, make sure you didn't already have it buried somewhere :P (e.g. that konsole example I gave doesn't show up on my system, since it was already being built earlier). Whatever identifier you give is searched in the XML tags module, component and project, and repositories are recursively found from there. One exception is that if the component or module contains both its own repo, and other children with repos, the repo which is a direct child is preferred, and the childrens' repos are all ignored. (I think this is desired behavior with calligra, unless the calligra repo is essentially empty, I haven't had time to delve into that). There is no dependency tracking. There is a repo setup for that kind of metadata so it will work well enough someday, but until then modules are built in the order that they show up in the XML. I also haven't coded in warnings for module identifiers that are not unique in the XML. If there are non-unique identifiers and you try to build it, your guess on the module that actually gets built is probably as good as mine. If this makes you wary, you should be able to specify a full path just fine (e.g. kde/kdebindings, extragear/utils/kdesrc-build, etc.) My roadmap such as it is, is that when this all works well enough, to move effectively all defaults regarding what modules to build to the build-setup repo I was referring to earlier, and then changing the defaults there should in theory continuously update the defaults for deployed kdesrc-builds. There would also be some mechanism to instead have an exact configuration like you can do now. Like I said, xml-support branch on kdesrc-build git. If you want to give it a shot I'd appreciate it, if not that's fine too. Do keep in mind that I will be once again extraordinarily busy over the working week so if I horribly broke something I may not be able to fix it til the weekend. Happy building! Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
