Microarchitecture rpm macros

During Hackweek 20 at SUSE I created some rpm macros to create packages easily that use the glibc-hwcaps feature. There’s a post with the journal from the hackweek in case you want to read it. Here I’ll just explain how to use the new macros I created.

The package definition

First you have to add a BuildRequires to use the macros:

BuildRequires:  microarch-rpm-macros

Then before the %description section, you have to add a line like:

%microarch_subpackage -n %{libname}

The %microarch_subpackage macro is used to generate the subpackage sections. It’s important that the parameter passed to it is the same as the parameter passed to the %package section that defines the library package. It’ll also generate the %files section with the same contents as the %files section in the library package but with the directory adapted to the microarchitecture of each subpackage.

The %build section

Let’s consider the following code in the build section:

autoreconf -fiv
%configure \
   --with-pic \
   --disable-static
make %{?_smp_mflags} CFLAGS="%{optflags}"

We will replace that with:

autoreconf -fiv
%{microarch_build %$configure \
  --with-pic \
  --disable-static
  make %{?_smp_mflags} CFLAGS="%{$optflags}"
}

The %microarch_build macro will take care of executing 4 times the code within to build the baseline version of the package and then the x86-64-v2, x86-64-v3 and x86-64-v4 versions, each in a different directory and with different %optflags values which include the respective -march and -mtune parameters in each case as well as different %_libdir values so the library is installed to the right place later in %install.

Note that %configure was replaced with %$configure and %{optflags} was replaced with %{$optflags}. This is done so that they’re not expanded before passing the arguments to %microarch_build .

Also note that the autoreconf execution was left out of the macro. This is so that the configure script is generated in the root source directory. Then the %microarch_build macro can generate build.x86-64-vN directories and put there the build files.

In my test with the bzip2 package I had a special case. If the %do_profiling boolean is set then code is built, the tests are executed and then the code is built again with the generated profiling information. The %build section used was:

%configure \
  --with-pic \
  --disable-static
%if 0%{?do_profiling}
  make %{?_smp_mflags} CFLAGS="%{optflags} %{cflags_profile_generate}"
  make %{?_smp_mflags} CFLAGS="%{optflags} %{cflags_profile_generate}" test
  make %{?_smp_mflags} clean
  make %{?_smp_mflags} CFLAGS="%{optflags} %{cflags_profile_feedback}"
%else
  make %{?_smp_mflags} CFLAGS="%{optflags}"
%endif

And I replaced that with:

%{microarch_build %$configure \
  --with-pic \
  --disable-static
%if 0%{?do_profiling} && "%{$microarch_current_flavor}" == "x86-64"
  make %{?_smp_mflags} CFLAGS="%{$optflags} %{cflags_profile_generate}"
  make %{?_smp_mflags} CFLAGS="%{$optflags} %{cflags_profile_generate}" test
  make %{?_smp_mflags} clean
  make %{?_smp_mflags} CFLAGS="%{$optflags} %{cflags_profile_feedback}"
%else
  make %{?_smp_mflags} CFLAGS="%{$optflags}"
%endif
}

Note that here again I used a $ within %{$microarch_current_flavor} so it can be replaced in each flavor with the right value.

The %install section

%install sections usually consist on running something like %make_install and then maybe installing some files manually. In this case, we would replace this:

%make_install pkgconfigdir=%{_libdir}/pkgconfig
install -Dpm 0755 foo %{buildroot}%{_bindir}/foo
install -m 0644 %{SOURCE2} %{buildroot}%{_mandir}/man1

with:

%microarch_install %make_install pkgconfigdir=%{_libdir}/pkgconfig
install -Dpm 0755 foo %{buildroot}%{_bindir}/foo
install -m 0644 %{SOURCE2} %{buildroot}%{_mandir}/man1

%microarch_install will run the argument passed to it 4 times but first it’ll run the microarch flavors and the baseline flavor will be run last.

Note that after the flavors are installed and before the baseline installation is done, it’ll remove all *.so files within the glibc-hwcaps directories since we don’t want development files in there.

The %check section

In the %check section packages usually run the generated binaries to test they work as expected. Note that we can’t do that for all flavors since we may not have a recent enough CPU to run them. Because of this, I opted to just check the baseline flavor.

Just replace

make %{?_smp_mflags} test

or anything you have to run from the build directory in %check with:

pushd %microarch_baseline_builddir
make %{?_smp_mflags} test
popd

And that should be enough for the simple case of bzip2 and similar packages.

Please note that this is work in progress and currently using the macros with %cmake or %meson will fail and is not supported yet. Check the conclusions on the previous post for information about what’s still missing.

Firmas digitales con autofirma/@firma/clienteafirma en openSUSE

This post explains how to install the Spanish government official tool to generate digital signatures and the web applet used in the Spanish government web sites to sign documents that the user needs to upload. If enough people request it, I’ll write also an English version, but for now, as it’s mainly useful for Spanish openSUSE/SUSE users, I’ll write the rest of the post in Spanish.

En este post voy a explicar cómo instalar AutoFirma (también llamada @firma o clienteafirma en distintas versiones) en openSUSE Leap (15 y 42.3), openSUSE Tumbleweed y SUSE Linux Enterprise.

El método fácil y rápido

Para instalar AutoFirma en openSUSE, basta usar la instalación en 1 click, pulsando en el siguiente botón:

El método alternativo

Si se prefiere usar la línea de comandos, se puede añadir mi repositorio de paquetes estables que todavía no están en la distribución e instalar el paquete autofirma desde ahí. En este repositorio intento mantener versiones estables de paquetes que creo que pueden ser interesantes o que personalmente me resultan interesantes así que debería ser seguro añadirlo a los repositorios del sistema. Además, si en algún momento arreglo algún problema o actualizo la versión empaquetada a una más reciente, se obtendrán las mejoras automaticamente al actualizar el sistema. El repositorio es home:alarrosa:packages y para añadirlo hay que usar:

En openSUSE Tumbleweed:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/openSUSE_Tumbleweed/home:alarrosa:packages.repo

En openSUSE Leap 15:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/openSUSE_Leap_15.0/home:alarrosa:packages.repo

En SLE 15:

sudo zypper ar -f https://download.opensuse.org/repositories/home:/alarrosa:/packages/SLE_15/home:alarrosa:packages.repo

Y para instalar el paquete:

sudo zypper in autofirma

Cómo usar autofirma

La forma más fácil es añadir el certificado que se haya descargado de la página de la FNMT al almacén de certificados de Firefox (en Preferencias / Privacidad y Seguridad / Certificados). La mayoría de las acciones también permiten usar ficheros PKCS #12 (.p12) directamente.

Las aplicaciones AutoFirma y Cliente @firma aparecerán en el apartado de Oficina del menú de aplicaciones.

AutoFirma

AutoFirma permite firmar documentos muy facilmente.

Diálogo para seleccionar el rectángulo donde se generará una firma visual.

No hace falta modificar las opciones por defecto.


Mensaje de documento correctamente firmado.

Cliente @firma


Cliente @firma da más opciones de firma.

Selección del certificado con el que firmar.

Con cliente @firma se puede validar si una firma es correcta.

Mensaje de firma validada correctamente.

Sobre el paquete autofirma

La última versión oficial distribuida (en el momento en que escribo estas lineas, es la 1.6.3 para Windows y la 1.6.2 para Linux) no permite leer correctamente el almacén de certificados de Firefox, razón por la cual decidí empaquetar la versión en desarrollo de github. Además, hice algunos cambios para que encuentre las librerías del sistema y de Firefox correctamente en openSUSE. También he añadido ficheros .desktop para integrar mejor clienteafirma/autofirma en el escritorio.

Para finalizar, sólo comentar que me llevé una grata sorpresa al ver que el código fuente de autofirma estaba disponible en github con una licencia libre (GPL 2.0 y EUPL 1.1). Desde aquí me gustaría agradecer a los desarrolladores de autofirma por su compromiso con el software libre. En las próximas semanas intentaré enviarles los cambios que he realizado para que los introduzcan en las versiones oficiales por si le son útiles a otras distribuciones.

Actualización: Añadidas instrucciones para SLE 15