Glibc 2.17 on the finishing line

In the next few days David Miller as GNU C Library (glibc) 2.17 release manager will call a freeze for glibc development and I've packaged glibc for openSUSE and compiled the whole distribution with it - and it looks fine.
For those curious, what's in the new glibc, here's an incomplete list of the major changes. For the full list, see ChangeLog file and the NEWS file. The list comes from the current NEWS file and I've only copied entries relevant to openSUSE:

• Port to ARM AArch64 contributed by Linaro.
• The new function secure_getenv allows secure access to the environment, returning NULL if running in a SUID/SGID process.  This function replaces  the internal function __secure_getenv.
• SystemTap static probes have been added into the dynamic linker. Implemented by Gary Benson.
• Optimizations of string functions strstr, strcasestr and memmem. Implemented by Maxim Kuvyrkov.
• The ttyname and ttyname_r functions on Linux now fall back to searching for the tty file descriptor in /dev/pts or /dev if /proc is not available.  This allows creation of chroots without the procfs mounted on /proc.
• The `crypt' function now fails if passed salt bytes that violate the  specification for those values.  On Linux, the `crypt' function will consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is enabled, and fail on encrypted strings using the MD5 or DES algorithm when the mode is enabled.
• The `clock_*' suite of functions (declared in <time.h>) is now available directly in the main C library.  Previously it was necessary to link with -lrt to use these functions.  This change has the effect that a single-threaded program that uses a function such as `clock_gettime' (and is not linked with -lrt) will no longer implicitly load the pthreads library at runtime and so will not suffer the overheads associated with multi-thread support in other code such as the C++ runtime library.

Also, 125 bugreports have been marked as fixed, a couple of changes from eglibc got merged (especially for cross-testing) and some cleanups of the code were done.

With the current git development version packaged as rpm, the openSUSE Build Service compiled the whole distribution on x86-64. There were three different kind of problems in packages which showed up as build errors:

1. Some packages had missing includes (e.g. signal.h or stdint.h). Those are easily fixed by including the header defining the missing types.
2. The functions setfsgid() and setfsuid() produce warnings when the return value is not checked and thus fail to when -Werror is used. The proper fix is to check whether these functions have a return value less than 0.
3. clock_gettime() was moved from librt to libc. Some configure scripts check only whether clock_gettime is in librt and assume that other functions like mq_gettattr() are in the same library. So, the configure check for clock_gettime() in librt needs to be extended to look for other functions as well.

I did not noticed directly any problems in glibc itself, just these three kind of problems in packages - and had to fix around 10 packages at all.
This was all done with the git version from the 9th of November, I've updated now to the current git version and will retest.
My plan is to push the current glibc package soon to the openSUSE development tree called openSUSE Factory.

Updates to openSUSE Packaging Guidelines

On the opensuse-packaging mailing list, we've recently formed a team that will take care of the packaging guidelines and introduced a small process to change them.

As part of that process, we're announcing regularly the changes to the packaging guidelines. Since this is a first such announcement, it is not a complete change but just points out a few things from the past few months. In the future, we will send out this email once a month.

The Packaging guidelines can be found in the openSUSE wiki at http://en.opensuse.org/openSUSE:Packaging_guidelines.


The list of changes that I'd like to mention are:

• New Lua Guidelines
• Reworked font guidelines
• Documenting changes in packages
• Teams involved

New Lua Guidelines

We now have guidelines for lua at http://en.opensuse.org/openSUSE:Packaging_Lua.

Reworked font guidelines

The packaging of fonts has been completely changed, and is documented at http://en.opensuse.org/openSUSE:Packaging_Fonts.

Documenting changes in packages

The openSUSE review team is now also enforcing proper documenting
changes in packages:

First, the .changes entry (rpm changelog) surves two purposes:

• News for the user
• History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixes).

Information about updates

A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed.
 
Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will.

Documenting patch life cycle

The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .

Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed).

The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the openSUSE Factory Review team:

The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that...

Note: The review team is not enforcing the usage of patch markup unless the package already follows this convention.

Teams involved, contact

I mentioned two teams previously, these are the openSUSE review team
and the team taking care of the guidelines. You can reach both via the opensuse-packaging mailing list.

Changing my responsibilities @ SUSE

As you already know, during the last few months, SUSE has reorganized responsibilities and resources around openSUSE. As a result of this new strategy, the openSUSE Team has been created (with Agustin as team lead), formed by those SUSE employees who work full time in the community project.

I've worked with the openSUSE team to hand over my openSUSE related responsibilities to them and now it's time for me to formally take over some new responsibilities inside SUSE:

I'll continue to be part of the SUSE Product Management team - now as product manager - and continue driving SUSE Linux Enterprise 12 efforts with the other product managers and engineering.
openSUSE is the upstream of SUSE Linux Enterprise and with my help driving development and keeping SUSE a good partner in the openSUSE ecosystem, I'll continue to be involved.  Also, I will continue to contribute to openSUSE with packaging and reviewing of packages.

As SUSE product manager I'm also joining the efforts around cloud, e.g. SUSE Cloud, and SUSE Studio and will also take product management ownership for the toolchain (compiler, debugger, C library, ...).