Freedom is about contributions

The most annoying thing about Fedora is that it breaks from time to time. Failures vary in their scope. Sometimes they're really subtle (false security alerts) and sometimes I really want to check if my laptop is as shock resistant as manufacturer claims.

That's the cost of being at the bleeding edge. People experiment, do constant changes, improvements, and introduce new bugs. One may even say that the number of newly fixed bugs could be used to measure  software vitality ;-).

On the other hand, some things that I really, really love make up for everything:

• Freedom - usually it means that you can do what you want with your software. For example, compile KDE with transparency support:

  

  Can you see the orange button through the KCalc?

  Many folks tends to forget about the most important aspect of freedom - which is fixing bugs that annoy you, for yours and others convenience! Remember, complaining is a really bad habit. Don't complain. Report it, fix it or live with it! That's why there is so many Linux distributions. Each one fixes something :-)

• People. If you are ready to invest into a community, the community will invest back into you! This is very strongly related to the previous bullet!

 But what if you can't code? There's plenty of things you can do:

• document problems you have solved. 
• report bugs (seriously, bug which has not been reported is a bug that does not exist).

It's not that you have to. But hey, don't complain!

I got inspired to write this post and remember those obvious obviousnesses by the creator of my beloved game, which he wrote during his studies, and gave up development due to his PhD and company he runs. But recently - community funded a new game release! That's the power of community (even if it is not open source one)!

Eclipse Platform CBI build just hit Fedora!

I think that by now almost everyone had heard of Tycho - a maven-like approach for building OSGi bundles, and the CBI initiative, which is about making Eclipse builds as easy as possible.

I'm proud to announce that the early adopter of everything, Fedora Rawhide, has just received an Eclipse built with Tycho.

The adoption was rather painful, and there's still a lot of work to be done, but hey, that's the first Eclipse Platform CBI adoption*!

If you dare, test it.

sudo yum --enablerepo="rawhide" install eclipse

All bugs should be reported to RedHat bugzilla, because they will cover packaging issues, not issues with Eclipse itself.
*That I am aware of.

Creating noarch packages with arch-specific dependencies.

If you look at Eclipse package, you will notice that despite being written mostly in Java, it is arch-specific, and therefore it is installed either into /usr/lib/eclipse/ or /usr/lib64/eclipse/. This is because Eclipse contains a few platform specific libraries  - and SWT is the most important of them. Don't get me wrong - SWT is not just the platform specific library, it is also a common JAVA API to create application that look like native on Windows, Linux and MacOs despite using the same code base.

This is very problematic for Fedora packaging, because any Eclipse plugin depending on SWT and not containing any native code is a noarch plugin, and it should be located in a noarch directory (/usr/share/eclipse).

There is no problem during runtime, because when you start an arch-specific eclipse, it can always locate the noarch directory and load all plugins that are there.

But compilation is a problem, because in many cases you just need the SWT API on classpath to compile Eclipse plugin and two most important arch-specifc macros, %{_libdir} and %{_isa}, are banned from being used in noarch packages, and they will not point you to the right SWT installation?


There are three possible solutions:

• Use Tycho. Tycho is a wonderful Maven extension that makes building of Eclipse plugins easy. 
• Use eclipse-pdebuild script. This script is located in %{_bin} folder and it automagically discovers where is Eclipse (and SWT) installed.

• At this point you should go back and reconsider the two previous bullets. I do not recommend any other build system (especially pure ant) for building Eclipse plugins. However, if you have to, you can always use a magic command ${build-classpath swt}, which will locate the swt.jar, instead of hardcoding a path to it.

Warning:
You should be very very careful when you are using any arch-specific things in a noarch package, especially if you don't know the build system by heart. The risk is that some arch specific path may find its way into the code as a constant, search path or something similar, while the package will be installed as a noarch one. As a result, it will work only on one architecture, and debugging will be very difficult.

This blogpost is based on a clarification request regarding the use of %{_libdir} in noarch packages.

Debugging Fedora builds with mock

The problem that every build engineer faces sooner or later is: what packages introduces dependency to foo to our build?

The commonly used build tool amongst Fedora packages is fedpkg, which allow for building a package in a mocked configuration, without need to install any unwanted packages.

fedpkg mockbuild creates a mock system, install everything what's needed there, and performs a build. Then deletes the mock location afterwards.

What should you do if your build has unwanted dependencies?

Abandon fedpkg in favour of mock command.

The typicall build command may then look like:

mock --no-cleanup-after --rebuild $SRPM --resultdir=$RESULT -r fedora-rawhide-x86_64 

where --no-clean-after option means that mock will not delete anything after the build. This allows us for calling:

mock -r fedora-rawhide-x86_64 --shell 

, which will open a shell that runs inside our mock system. At this point we can use regular rpm to find what packages require "foo".

rpm -q --whatrequires foo

It's that simple!