So why am I so happy? It resolves a nasty bug the gnome-team was trying to chase, namely the fact that keyboard shortcuts stopped working a while back. Once the issue was identified (the obvious switch from XInput to XInput2 by gnome upstream), there were two solutions: revert XInput2 usage in gnome or get X up-to-date and live happily ever after.

Needless to say, we chose the hard way and started working on the X.org packages.Now, they were solid, but packaging wise everything bug in good shape. A lot of patches applied, many of them not part of the upstream codebase, never sent upstream, or simply not interesting for upstream.

Vincent did a great job in cleaning up the packages, splitting the huge collection in small and manageable pieces (and enabled the awesomeness osc collab offers: upstream version tracking). I took the liberty to work on updating the packages to their latest versions afterward and reworking the main package a bit, especially after having run into issue with xorg being updated, but I forgot the driver packs… boring details, nothing to worry about.

So, you want to test it?
That’s a bit trickier.. most of this work already went back to obs://X11:XOrg (the package cleanup and split) but the updates are so far only available in my bracnh (obs://home:dimstar:branches:X11:XOrg). Not all driver packs were updated (namely: nouveau is still missing), as I focused on my virtual machine.

Yet, after having completed these steps, I’m sure to get the needed boost in motivation again to finish it and to move those packages forward to Factory. Only that we reach Milestone 4 already; wish this would have happened earlier.

So long! Happy testing and machine breaking!

For the openSUSE 12.2 release cycle we have to push this a little further: As the typelib namespace and version does not grow linear together with the shared library name, we have to split the *.typelib files out of the shared library package.

An example why the typelib files need to be split out from the libraries:
Clutter: the library was renamed from libclutter-glx-1.0.so.0 to libclutter-1.0.so.0, the typelib remained Clutter-1.0.typelib. The upgrade process is slightly ‘messy’ in this case and a bunch of problems could be avoided by splitting the typelib files out.

But by doing so, this typelib package would really only have some typelib()-style provides, and no dependencies at all, other than the one the packager specifies manually. And there’s the catch: I’m by far to lazy to find/add the dependencies manually. Besides that: experience shows that this anyhow would be only done initially when a package is created and then ‘forgotten’ until a problem arises. Not what we need and want.

So, I took some time yesterday, wrote a g-ir-dep-tool which loads a specific .typelib and checks for its dependencies. It catches other typelib style ones and also the shared library the tyeplib provides the binding for. Rather nifty and cool.

I already integrated this into my GNOME:Factory branch, doing some final tests and cleanups. Once entered in GNOME:Factory nothing is going to stop us from splitting the typelib files out.

And all this just to improve the quality of our packages and their dependencies.

(All this work of course is not meant to be just for us, but has been submitted for review and inclusion to the gobject-introspection maintainers. So if all goes right, this will show up in some future release)

The VideoLAN Repository will get through some minor changes. Mainly affected are current users of the vlc-beta packages, BUT there is important news for all of you:

The VideoLAN Project moved the VLC Player sources into the future. For this reason, vlc-beta packages as of now will only be built with full capabilities for openSUSE 11.4 and Factory (and future releases).
Currently, on 11.3 I had to drop v4l2 features, as the kernel is considered too old to be supported by the latest VLC snapshots (See this mail thread)

the existing 1.1.x packages are of course not affected, but there are plans to have 1.2 tree to become the ‘main’ tree for VLC! This would be some big news and changes coming down our way! Yay!

Enjoy !

ChangeLog:

* Support/require xulrunner 2.0+
* Support linking againgst libwebkit-gtk3 (-DWITH_WEBKIT3=ON)
* Port to gsettings for gnome3. (-DWITH_GNOME3=ON[default])
* Issues closed:
– #149: always test for the right python noarch module path
– #155: Cannot compile with Firefox 4
– #156: libproxy should build against webkitgtk-3.0
– #158: Won’t compile w/ xulrunner 2.0 final
– #159: libproxy fails with autoconfiguration “http://proxy.domain.com”
– #131: GSettings-based GNOME plugin
– #150: SUSE sysconfig/proxy config support

Packages for opoenSUSE Factory are already in their works and have been submitted for inclusion. That means that we will finally get all the apps supporting libproxy read the gnome3 proxy settings for us again.

A common scenario could have been (It was luckily not that common, but was possible to happen):
- The game “lightsoff” was installed. It did not have dependencies on various libraries. rpm was not able to identify any requirements, as the game is written in JavaScript and uses seed as its interpreter. But of course it makes full use of gobject-introspection based bindings of a good part of gnome libraries (GTK, Clutter, GConf, just to name a few).

Now, those libraries all offer a .typelib which is a bindings file, created with object-introspection and we used this knowledge to make dependencies between the packages.

The provides part is rather simple: every .typelib file is one Provides for rpm, the name itself can be split in all needed parts.
The file “Gtk-3.0.typelib” for example represents a “Provides: typelib(Gtk) = 3.0″ in the rpm package.

This part has now been pushed to Factory (review pending) and all libraries offering those bindings will hopefully shortly start to advertise this in their rpm metadata..

What needs to be done to achieve this?
If your package contains a .typelib file together with the library (it should be packaged in the shared library package), then you should make sure to add gobject-introspection BuildRequires in your .spec file. This installs the needed hooks for rpm to know how to scan those files and creates the Provides.

What next?
Once we get a full Factory build with those provides, we will evaluate on how much is going to break when we enable the Requires parser as well (it is already enabled in GNOME:Factory, with a bunch of failures for now).
Generally, the checks have been well tested and for all current failures in G:F we know that it is simply missing the build in Factory, as it’s libraries not provided by Gnome (PolKit for example).

So hopefully not too far in the future, we will push the Requires parser as well and not break too much.

So, just like before, we have a look at the error, including the specific code parts raising the errors:

I: Statement might be overflowing a buffer in strncat. Common mistake:
BAD: strncat(buffer,charptr,sizeof(buffer)) is wrong, it takes the left over size as 3rd argument
GOOD: strncat(buffer,charptr,sizeof(buffer)-strlen(buffer)-1)

Ok, so the error is very helpful with even telling us what is a bad use of strncat and what a good use of it would look like. For completeness, let’s see what the compiler itself reports on this error:

In function ‘strncat’,
inlined from ‘gtkui_icmp_redir’ at ec_gtk_mitm.c:173:14:
/usr/include/bits/string3.h:152:3: warning: call to __builtin___strncat_chk might overflow destination buffer [enabled by default]

Let’s see what man 3 strncat tells us about the usage of strncat.

Synopsis

#include
char *strcat(char *dest, const char *src);
char *strncat(char *dest, const char *src, size_t n);

Description
The strcat() function appends the src string to the dest string overwriting the ‘\0′ character at the end of dest, and then adds a terminating ‘\0′ character. The strings may not overlap, and the dest string must have enough space for the result.

The strncat() function is similar, except that it will use at most n characters from src. Since the result is always terminated with ‘\0′, at most n+1 characters are written.

The package suggested by Malcolm contains this code (snipped together):

#define PARAMS_LEN 50
static char params[PARAMS_LEN];

strncat(params, gtk_entry_get_text(GTK_ENTRY(entry1)), PARAMS_LEN);
strncat(params, "/", PARAMS_LEN);
strncat(params, gtk_entry_get_text(GTK_ENTRY(entry2)), PARAMS_LEN);

This is not an uncommon error at all. We create a buffer, 50 chars long, we concatenate text into the buffer and specify a max length of PARAMS_LEN. What is not taken into account here is that the string in params is getting longer, and we do not account for this when adding text to it. And additionally the leading \0 is ignored as well.

Translating the BRP Result’s suggestion stating how we should write this code, we will result in this:
#define PARAMS_LEN 50
static char params[PARAMS_LEN];

strncat(params, gtk_entry_get_text(GTK_ENTRY(entry1)), sizeof(params)-strlen(params)-1);
strncat(params, "/", sizeof(params)-strlen(params)-1);
strncat(params, gtk_entry_get_text(GTK_ENTRY(entry2)), sizeof(params)-strlen(params)-1);

sizeof(params) is what we had there before, and equals to PARAMS_LEN. But we now also take into account that we already do have some characters stored in params and also account for a trailing NULL byte.

And with this simple fix, the error vanished.

I: Program causes undefined operation
(likely same variable used twice and post/pre incremented in the same expression).
e.g. x = x++; Split it in two operations.

This is currently informational only and is not failing the build, but you might want to address them together with upstream.

I assume you do know what “a++” means in C (otherwise, you should start reading C-books), so we just try to reproduce this error in a simple c test case:
#include <stdio.h>

int main() {
int i=5;
i = i++ * ++i;
printf("The current value of i is %d\n", i);
return 0;
}


When building this using gcc -Wall test.c, we get this compiler warning (which in turn is what brp translates to the information we’re discussing here)

> gcc -Wall test2.c
test.c: In function ‘main’:
test.c:5:5: warning: operation on ‘i’ may be undefined

So, let’s first see for ourselves what we would expect this to be? Hmm.. already for us, this looks not logic (and I surely hope nobody would write this code).
Let’s just see what starting this executable gives shall we?

The current value of i is 37

Now, is this surprising? We multiplied, assigned it to i and as a result we get a prime number? By closely analyzing the line you will likely understand what the compiler did. But was this expected? If this is actually what the programmer intended, the code should just be rewritten to be more logical, like:
i = (i+1) ^2 + 1;
This is understandable for all of us and does not yield the surprise of what is going on.

And that is actually all this warning is about: it requests the programmer to write code that can be understood and does not depend on what the compiler interprets. It might even very well be that the different optimization levels or the usage of different compilers might end up in different results.

If you want to read some more about this topic, I suggest to have a look at:
Wikipedia
http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html

Interested in it? So welcome to part #1 (this issue). The “series” is not really fledged out, but I will try to write post for various errors / topics, as they come along. Just drop me a note with an error you have seen / experienced in OBS while building a package.

So what does it mean, if OBS tells you this:
Expression compares a char* pointer with a string literal. Usually a strcmp() was intended by the programmer

Let’s have a look at a very simple C program, to show the issue:
#include <stdio.h>

int main() {
char *mytext;
mytext = "Help";
if (mytext == "Help") {
printf("This should raise a warning");
}
return 0;
}Trying to compile this very simple C program, which on first sight many would probably say this is correct, will result in this:

$ gcc test1.c -Wall
test1.c: In function ‘main’:
test1.c:6:14: warning: comparison with string literal results in unspecified behavior

So, even though we had such an easy program, line 6 seems to be an issue for us:

if (mytext == “Help”) {

The issue, as simple as it may sound, is the comparison of a pointer (char *) with a literal (“Help”).

So how do we fix it? It involves changing the code, thus writing a patch (there are many good helps around for this… I won’t dive into patching here).. Of course, after having written a patch, be a good downstream, send it upstream!
What you want to do here is to replace this comparison with strcmp (just as OBS’ error message implied).
Look at this code now:
#include <stdio.h>
#include <string.h>

int main() {
char *mytext;
mytext = "Help";
if (strcmp(mytext,"Help")==0) {
printf("No warning here\n");
}
return 0;
}I changed “mytext == “Help” to strcmp(mtext,”Help”)==0 (man 3 strcmp will explain you why… 0 means the texts are equal, or ’0 difference detected’ can help you remember that). As the code was too simple and strcmp was not yet defined (this of course can also happen in packages you patch), I had to add an additional #include <string.h>.

Not too hard, is it?

So what do you think? Such a series of “how to fix my typical brp / lint warnings” useful?

For this reason I’m hereby announcing that the 11.0 repositories will be removed from the videolan download infrastructure by March 1st 2011 ! If you rely on having the packages available for your personal installations, please make sure to create a local copy of the FTP tree.

On the bright side though: the 11.4 repository has just been uploaded. It is built against the latest snapshot of 11.4, which is somewhat between RC1 and RC2. Most likely not much is changing that would affect stability of the VLC packages. And like always of course: Factory package keep on existing. But they did for a long time already.

Today I hear that version 1.0.0 of the core libraries have been released. Reason enough to actually look into this again. So 1 hour, many build failures and successes later, I have the entire core-stack built in my obs repository home:dimstar:Enlightenment. The window manager Enlightenment itself is not yet released as full release, but the latest snapshot can be found in my repo as well.

But that’s it so far: all core libraries are built. Nothing more. I did not even have time to test them yet.

If you feel adventurous, go, add the repository obs://home:dimstar:Enlightenment to your system (published for openSUSE 11.3 and Factory) and start playing with all of the things, starting with the window manager, which should generally pull in the rest.

What should be required (as root)
zypper ar obs://home:dimstar:Enlightenment Enlightenment
zypper in enlightenment

This will add my home repository to your catalog list and install enlightenment including dependencies. One logout later, you should see Enlightenment as a new session type in your *DM.

Have a lot of fun and share your experiences… I will test it after I get some sleep.