www.michael-jansen.biz

I released Version 0.5.5 of build-tool to rubygems. The version is just a bugfix release and some small enhancements. Hang on for the changelog

Update: Seems my long offline time made me rusty. v0.5.7 is now what 0.5.5 was supposed to be. 0.5.5 and 0.5.6 should be ignored. Even if they should work they are not what i intended to release.

I just pushed the changes necessary to build kdeutils after it was moved to git and splitted.

Update the recipe and then remove the old kdeutils checkout and its build directory. Then rebuild kdeutils with kde-build build -u kdeutils/. This applies naturally only if you have the feature utils activated.

Mike

As recently announced in kde-core-devel mailing list kdelibs master is now frozen. Development will happen in the branches

frameworks

The modularization effort for kdelibs

KDE/4.7

Bugfixes for the 4.7 branch

Since this is not about announcing this change but the implications for build-tool users i won't go into details here. I made the following changes to the build-tool recipe for your convenience:

I just pushed the next bugfix release of build-tool to rubygems. Hang on for the changelog.

If you use build-tool to compile kde from sources you most likely encountered the current confusion around soprano and its dependencies. It requires a fairly recent raptor version which is not yet packaged for many distros. And it needs recent rasqal and redland version too. If you need to compile the from sources use the following snippet. Add it to your recipe override file.

Dear KDE

I guess this is the proper opening here since kde is now the community. And i want to address the community. All of you. Whenever you feel the need to move your application from one source code repository to the next, which these days is mostly from our subversion repository to git.kde.org, please be nice to your users. Which are developers too in this case. Source code users. So be nice to your fellow developers. Or if you need it more personal. Be nice to me.

Do not just remove the old repository and let me find out the hard way you moved. Getting a subversion error message when trying to update something is not nice. And did you now git-svn just fails silently if you remove the cloned subversion directory? I did not know either. But thanks to you i found out. It spits out something about not seeing source files at the path and about trying harder. But obviously it does not try hard enough! It does not succeed in finding your moved sources so it just returns zero. Most likely in shame over its failure. It does not want to confess it. Poor tool. And my build script thinks that means the update was successful. I built for month the same version over and over again. Silly, isn't it? I mean my build script naturally. I have written it myself so i should have guessed.

So after i eventually found out something isn't right i tried to follow you. You didn't move to get rid of me? See i obviously missed the announcement on kde-devel or kde-core-devel about the move. My attention span is really short. You did inform the mailing list about your move i am sure. Especially where you moved the sources. And i need that info. But since i missed that announcement anyway it would have been a nice touch - just to show you care - to NOT remove your root directory we are used to checkout. Instead just delete all sources in it. Add a README file with the new repositories url. For people like me who miss the announcements. Others did it too!

But you didn't. So i went to search your project on git.kde.org. But it was not there. This is a nice touch. Every time before this happened i would find the sources there. But you guys love to surprise me. I hate it when things get predictable and boring. So i applaud your effort. With a bit of googling i found your sources. On gitorious, or was it github? I forgot. Wherver it was, i could have guessed.

Living in the kde community. Where we all strive to make live a bit more unpredictable.

Mike

I just pushed version 0.5.3 to gemcutter. Only small changes. See below.

News on the kde recipe front:

• shared-desktop-ontologies was fixed. It is again possible to build pykde4 against git master.
• kdeedu is in preparation and not buildable currently. I won't invest time to fix that. It will be back after the git migration.
• Same goes for kdegraphics. But they made a real mess. We will see when the dust settles.

V0.5.3 Changelog

- Feature
  - Errors during a make call are both printed to the logfile and stdout even without verbose
    mode. Currently lines with "error:" and "ld:" are considered as errors. Report more. If the
    progressbar was active it is stopped.
  - Git: Check for a dirty index if asked for rebase. No automatic stashing (Yet?). Build-tool
    will bail out with an error message if you have uncommited changes. This step will be done
    before asking for the ssh key.
- Enhancements
  - Do not print the classname for BuildTool Error classes. Only the message.
  - First fetch and rebase, then clean out the build-dir. If the fetch rebase fails you still have
    your old build to sort out the problems.
  - Improve the error message if --resume-from is given an invalid/ambiguous module name.
- Bugfix
  - Fix ssh key handling. Now build-tool will stop if ssh-add fails.
  - Fix the progressbar for build-system not giving progress information(like qmake)

I have just pushed version 0.5.2 to gemcutter. This release bring the 0.5 version up to feature parity with the 0.4 version. The archive build-system was missing. It is now possible again to compile pykde4 and its dependencies sip, pyqt4 against trunk (see the notes below).

Since it is not possible anymore to clone from git.kde.org since some time i will switch the kde recipe development back to the master branch.

We had some discussions on kde-buildsystem about the level of knowledge that is required to build and run kde trunk. Build-tool currently has a total of 127 modules available for you to build. And the needed support to run them. I am using it (and its predecessor) to run trunk since a short time BEFORE kde 4.0. If you finally got it successfully compiled and setup you do not experience major problems most of the time. The problem is compiling it and setting it up. Not many people seem to run completly from trunk and seem to have some misconceptions about it. It is more difficult to setup than most people think, and it is more stable if you got it running than most people think.

Therefore i would like to blog more about the difficulties one can experience when trying to build and run kde trunk.

Running trunk means you are the first one to notice the small problems recently introduced into the build system. Most of the time there aren't many but with the current git migration and module splitting those problems increased. Just for you information a list of the problems i noticed in the last week.

The Strigi Build Problem

 bash : 1039 ] $ ls /kde/trunk/support/lib64/libstrigi*
/kde/trunk/support/lib64/libstrigihtmlgui.so -> libstrigihtmlgui.so.SOVERSION*
/kde/trunk/support/lib64/libstrigihtmlgui.so.SOVERSION*
/kde/trunk/support/lib64/libstrigiqtdbusclient.so -> libstrigiqtdbusclient.so.SOVERSION*
/kde/trunk/support/lib64/libstrigiqtdbusclient.so.SOVERSION*

With strigi splitting up but still wanting to appear as one module that problem was introduced. Michael Pyne of kdesrc-build fame was so kind to enter a bug in strigis bug tracker.

The Phonon Build Problem

Phonon recently added support for a feature for a currently unreleased qmake feature. Which breaks the build in two ways. First it tries to install that file qt_phonon.pri into the QTDIR path ignoring whatever you set the installation prefix of phonon to. Which needs root rights most of us do not use when compiling kde from sources. To change that one has to set PHONON_MKSPECS_DIR to the dir we would like to install it to. That the wrong way. By default install everything into the prefix the user specified. Always. Since kde does not depend on that unreleased version there is currently no way to pick that file up. Build-tool forces it into the specified prefix now and ignores it there.

The Shared Desktop Ontologies Problem

Build-tool since the time it was recommended uses shared-desktop ontologies from trunk. But recently i found out that version is incompatible to the last officially released version 0.5 from 05/2010. Pykde4 won't build against it. I will try to figure that out in the next days. Some attribute in the nuao ontology was renamed from duration to end. That is the not the only problem preventing build-tool to compile pykde4 against trunk.

Pykde4 Build Problem

Pykde does not compile anymore without KDE3_SUPPORT. It does so since mid of november. I am currently trying to sort that out too.

This list is just to showcase why it is a good idea to use a tool to compile your sources from trunk. If everyone of use had to find out that informations by himself that would be really unproductive. So really it is time now to pick your tool.

Mike

I just pushed Version 0.5.0 to rubygems(UPDATE: 0.5.1 because the previous version had a bug. There is also 0.4.5 because 0.4.4 had the same bug.). The versions main feature is support for having differing fetch and push urls for git. The feature was needed to follow our admins preferred way of using the git infrastructure in kde land. The asked us to fetch from anongit.kde.org and use git.kde.org only to push. Their wish is my command. But i DO wish i knew about that git feature a bit earlier.

A nice side effect of the change is that fetching no longer needs an ssh-key. Of the main modules only oxygen-icons is still in svn so kde developer must still insert their passphrase when fetching from it. All other modules no longer need it. Yay.

The changes from 0.4.4 are - naturally - part of this release. If you decide to upgrade to this version you have to switch your kde recipe manually to the new 0.5-dev branch ~/.build-tool/recipes/kde. I will support both revisions a short time in parallel.

It is possible your local override file is not compatible with this revision. The reason is a changed syntax to declare repositories. Until now a repository was declared independent of a vcs declaration. That has changed. Previsously it was:

module "KDE/kdepim" < "kde-core"
    description "Personal Information Management suite."
    repository pim-kdepim
        use server "git.kde.org"
        path     "kdepim.git"
    end
    use vcs          git
    remote-path "master"
end

Now it is:

server "anongit.gitorious.org"
    host "git://gitorious.org"
end
 
server "git.gitorious.org"
    host "git@gitorious.org"
end
 
module "pim/kdepim"              < kde
    description "Personal Information Management suite."
    vcs git
        # "anongit.kde.org" is a server definition. Why? Because you can add a ssh-key to the server if needed.
        url     "anongit.kde.org" "kdepim"
        push    "git.kde.org"     "kdepim"
    end
end
# Or 
module "pim/kdepim"              < kde
    description "Personal Information Management suite."
    vcs git
        # You can't add a sshkey here but if it is not necessary.
        url     "git://anongit.kde.org/kdepim"
        push    "ssh://git@git.kde.org/kdepim"
    end
end

Why should you need to add a sshkey in the recipe? You can add it with clever use of ~/.ssh/config too, but if build-tool builds a module needing a key to build you will not be asked for the key at the beginning. Only when it is really needed you will be asked to enter the passphrase. Which is annoying when in happens after 20 minutes of a 60 minute build.

For svn it look like that now.

# You can add the ssh-key here
server "svn.kde.org"
    protocol    "svn"
    host        "anonsvn.kde.org"
    path        "home/kde"
   # use ssh-key "user(at)example.com"
end
 
# You can add the ssh-key here
repository "kde"
    use server "svn.kde.org"
    path "trunk"
   # use ssh-key "user(at)example.com"
end
 
module "kdesupport/oxygen-icons" < kdesupport
    # It's part part of KDE and it's not. That's why i put it here for now.
    # Don't use a KDE/ prefix before it is not necessary to update it very
    # often.
    vcs svn
        remote-path "kdesupport/oxygen-icons"
        use repository "kde"
    end
end
 
# or
module "kdesupport/oxygen-icons" < kdesupport
    # It's part part of KDE and it's not. That's why i put it here for now.
    # Don't use a KDE/ prefix before it is not necessary to update it very
    # often.
    vcs svn
        remote-path "kdesupport/oxygen-icons"
        # Make sure you use a unique name here. We don't want to overwrite
        # the repo of a different module!
        repository "kde-oxygen-icons"
            use server "svn.kde.org"
            path "trunk"
        end
    end
end

The kdepim modules moved from the KDE/ namespace to their own pim/ namespace. If you already have checkouts from git move them to the new location (from bld/KDE/kdepim[-runtime] to bld/KDE/pim/kdepim[-runtime]). The recipe build kdepim from trunk now btw. It is more or less stable. During the migration take some hours off. Or cleanup your emails before migrating.

If you notice problems ping me at kde (at) michael-jansen.biz

I just pushed the version 0.4.4 to rubygems. This is mostly a polishing release. Changelog:

- Enhancements
  - More ways to specify a module on the command line.
    - foo matches any module foo disregarding namespaces as long as only one matching module is
      found. ( kdelibs -> KDE/kdelibs )
    - foo/ matches any module that has foo/ as a namespace part. 
      ( kdebase/ -> kdebase/(runtime, workspace, apps )
  - Implement kdesrc-builds --resume-from feature. Skips all modules before the module specified is
    found.
    - kde-build build --resume-from kdebase/runtime KDE/
    - kde-build build --resume-from runtime KDE/
  - Build System Qt: Print a message when running bin/synqt after each rebase.
  - Build System Autotools: Try autoconf to bootstrap. May fail.
  - Build System Package: Be more verbose about what we do.
  - CMD: build - If a module is not checked out ignore it when --update is not given on the command line.
- Bugfix
  - The command "environment set [env] did set a wrong shell var to the name of the environment
    set. Use the documented BUILD_TOOL_ENV instead.

This is hopefully the last version that uses git.kde.org to fetch git repositories. I will release Version 0.5.0 later. That version supports configuring a pushUrl for git repos that is different from the fetch url. That version is a bit experimental and needs manual migration of config files too. So if you are cautious stay with this version for a while.