In this sprint, the YaST Team has been working on a wide range of topics. You can find more details in this list that we have prepared for you:

• Support for nested items in LibYUI tables. If you are interested in the gory details of the ncurses based implementation, you might find the libyui-ncurses: The Scary Widgets rather interesting and informative.
• Document and improve the detection of unsupported scenarios in yast2-sudo. We have also been discussing the future of the module: some of its features could be integrated into other modules (like yast2-users), instead of keeping a dedicated one.
• Allow vendor change when migrating from openSUSE Leap to SUSE Linux Enterprise (and vice versa) or from Leap to Jump. This feature required the team to adapt several packages: yast2-update, yast2-pkg-bindings, yast2-installation-control and skelcd-control-openSUSE.
• Preliminary work on supporting subvolumes quotas, including the design of the API.
• Prevent the user to accidentally disable the SSH access when SSH key-based authentication is configured.
• Better handling of the hostname when it is set via DHCP.
• Do not try to install the xorg-x11 package anymore, as it is an empty package. It fixes a problem when trying to install the system using VNC.

As usual, we are already working on the following sprint. We will publish another report, including some interesting details in roughly two weeks. Until now, stay tuned and have a lot of fun!

Nos ha costado volver pero al final hemos conseguido volver con los podcast de KDE España. Bienvenidos al Podcast 07×01 Convergencia Libre – UBPorts con Joan donde hablamos sobre el estado de esta tecnología que está llamando con fuerza e insistencia desde hace mucho tiempo a nuestra puerta.

Podcast 07×01 Convergencia Libre – UBPorts con Joan

Me complace presentaros el podcast de KDE España dedicado a la convergencia en el que tratamos este más que interesante tema.

Y es que desde que aparecieron los móviles con capacidades más avanzadas, el desarrollo de aplicaciones que pudieran adaptarse a las distintas pantallas se encuentra bajo el foco de atención.

Recordemos que Canonical, entre otros grandes, hace unos años ya intentó sin éxito avanzar por ese camino. No obstante, el software libre también afronta la convergencia y, poco a poco, parece que sigue adelante con paso firme. ¿Es la convergencia el futuro? ¿Podrá el software libre resolver los retos que propone?

Los integrantes del podcast fueron

• Joan @cybersheep, miembro de UBPorts y una fuente de conocimiento y sabiduria.
• Rubén Gómez: miembro de KDE España, de HackLab Almería y de Document Foundation.
• Baltasar Ortega: editor de KDE Blog, secretario de KDE España, miembro de GNU/Linux València y de KDE e.V.
• Jorge Lama: Diseñador sonoro/productor de podcasting: Coruña Dixital https://spoti.fi/34vr6Ve Bricolabs Podcast http://bit.ly/2KhYBnW NOlegaltech Radio http://goo.gl/GZ2gT3 y, ahora,  productor del podcast de KDE España.

Y no os entretengo más, os dejo con el vídeo que dura su hora y 45 minutos (es que ya no nos salen podcast cortos)

Espero que os haya gustado, si es así ya sabéis: “Manita arriba“, compartid y no olvidéis visitar y suscribiros al canal de Youtube de KDE España.

Como siempre, esperamos vuestros comentarios que os aseguro que son muy valiosos para los desarrolladores, aunque sean críticas constructivas (las otras nunca son buenas para nadie). Así mismo, también nos gustaría saber los temas sobre los que gustaría que hablásemos en los próximos podcast.

Boletín de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Además de tratar de difundir la filosofía del software libre, y de crear licencias que permitan la difusión de obras y conservando los derechos de autorías, también llevan a cabo diversas campañas de concienciación y para proteger derechos de los usuarios frentes a aquellos que quieren poner restricciones abusivas en cuestiones tecnológicas.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2020/october
• Y traducido en español en este enlace: https://www.fsf.org/free-software-supporter/2020/octubre

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

Después de muchos años colaborando en la traducción al español del boletín, desde inicios de este año 2020 he decidido tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿Te gustaría aportar tu ayuda en la traducción? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de septiembre de 2020

La pandemia no es excusa para vigilar a los estudiantes

Del 4 de septiembre por Zeynep Tufekci

En Michigan, una pequeña facultad de arte está requiriendo que sus estudiantes instalen una aplicación llamada Aura, que rastrea su ubicación en tiempo real, antes de que lleguen al campus. La Universidad de Oakland, también en Michigan, anunció una aplicación obligatoria que rastrearía síntomas, pero, ante una petición de los estudiantes, dijo que sería opcional.

La Universidad de Missouri, también, tiene una aplicación que rastrea cuando los estudiantes entran y salen de las aulas. Esta práctica se está extendiendo: En un intento de abrir durante la pandemia, muchas universidades y facultades de todo el país están obligando a los estudiantes a descargar aplicaciones de rastreo de ubicación, a veces como condición para la matrícula.

Muchas de estas aplicaciones funcionan a través de sensores Bluetooth o redes Wi-Fi. Cuando los estudiantes entran a un aula, su teléfono informa a un sensor que se ha instalado en la clase, o la aplicación revisa las redes Wi-Fi cercanas para determinar la ubicación del teléfono.

La FSF lamenta esta constante vigilancia obligatoria en la vida de los estudiantes, con la consiguiente violación de sus derechos a la privacidad y a la libertad del software. Por favor, únete a nosotros en la condena de estos programas firmando nuestra petición por la libertad en el aula, y haznos saber si podemos ayudarte a luchar contra estas injusticias en tu propia escuela.

• https://www.theatlantic.com/technology/archive/2020/09/pandemic-no-excuse-colleges-surveil-students/616015/

¿Qué tiene de malo YouTube?

Del 20 de septiembre por Richard Stallman

YouTube es un caso peculiar. A partir de septiembre de 2020, es posible ver videos de YouTube sin ejecutar ningún software no libre, incluso entrando a través de Tor, a través de algunos de los sitios intermediarios “Envidiosos.” Este artículo detalla cuáles son los problemas relacionados con la libertad en YouTube, da instrucciones para ver los vídeos de YouTube sin poner en peligro tu libertad, explica cómo compartir vídeos sin dirigir a otros a software que violaría su libertad, y advierte a los usuarios sobre posibles problemas futuros.

• https://www.gnu.org/philosophy/whats-wrong-with-youtube.html

Portado Parabola GNU / Linux a la tablet reMarkable

Del 6 de septiembre por Nate Hoffelder

El hacker Davis Remmel ha portado la distribución Parábola GNU/Linux respaldada por la FSF a la tablet reMarkable, abriendo en gran medida las posibilidades de lo que se puede hacer en el dispositivo, que antes se limitaba a una interfaz de usuario de tableta y un número selecto de aplicaciones.

¡Ahora puedes aplicar los beneficios del papel electrónico a una amplia gama de tareas informáticas!

• https://the-digital-reader.com/2020/09/06/parabola-linux-has-been-ported-to-the-remarkable-tablet-video/

Las empresas pueden rastrear los movimientos de tu teléfono para orientar los anuncios

Del 10 de septiembre por Sidney Fussell

A medida que los gigantes de la tecnología se mueven para suministrar “protecciones de privacidad” cosméticas (que no se pueden controlar ni verificar, debido a la naturaleza propietaria de su software), las empresas buscan formas aún más disimuladas y extrañas para catalogar a los usuarios y adaptar el contenido de sus anunciantes.

Los inicios de la “inteligencia contextual” deducen la actividad del usuario basándose en los datos de los sensores de su teléfono inteligente: si está corriendo o sentado, cerca de un parque o museo, conduciendo o en un tren.

• https://www.wired.com/story/companies-track-phones-movements-target-ads/

Amazon revela el dron que graba dentro de tu casa. ¿Qué podría salir mal?

Del 24 de septiembre por Kellen Browning

Cuando el director ejecutivo de Amazon, Jeff Bezos, prometió en 2013 que los drones pronto estarían volando por todas partes entregando paquetes, una cámara en miniatura zumbando por las casas y grabando vídeo probablemente no era lo que la gente imaginaba (aunque en retrospectiva, esto parece obvio).

Pero el jueves, la división de Ring de Amazon reveló la cámara del Ring Always Home Cam de 249 dólares, un pequeño dron que zumba mientras vuela por las casas filmando todo, aparentemente por motivos de seguridad. Afortunadamente, parece que la recepción de este artículo no ha sido particularmente cálida. Esperamos que continúes advirtiendo a tus amigos y familiares que los electrodomésticos conectados a “Internet de las cosas” son poco más que dispositivos de espionaje traídos a su casa.

• https://www.nytimes.com/2020/09/24/technology/amazon-ring-drone.html

Gana dinero contribuyendo en GNU

Del 17 de septiembre por Joshua Branson

Los colaboradores de GNU Joshua y Jeremy han decidido que “odian tener dinero,” y han “decidido deshacerse de parte de él” de la mejor manera posible: ¡pagando a los nuevos contribuyentes de software libre por su primera contribución!

No es una tonelada de dinero, pero podemos asegurarte que cada contribución a la expansión del software libre da enormes dividendos en la satisfacción de saber que formas parte de un movimiento global de tremenda importancia, y que tu primer paso es trascendental.

Estamos agradecidos a estos dos por su idea creativa y divertida de atraer a más gente al movimiento de software libre, y si también descubres que odias tener dinero y quieres deshacerse de él, la FSF le aliviará gustosamente y llevará esta desagradable carga responsablemente.

• https://gnucode.me/make-money-contributing-to-gnu.html

Estas son solo algunas de las noticias recogidas este mes, pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2020/octubre

Y todos los números del “supporter” o boletín de noticias de 2020 aquí:

• http://www.fsf.org/free-software-supporter/2020/

—————————————————————

openSUSE Kubic is Certified Kubernetes distribution & container-related technologies built by the openSUSE community. There is specific iso for openSUSE Kubic.

But sadly. As I am a cloud provider user. There are not many cloud provider who have feature upload ISO Image if I want to upload openSUSE Kubic ISO. And next problem, there is very limited kind cloud provider who have openSUSE distribution for image flavor when launch Virtual Machine. Cloud like AWS and GCP only provide SLES version.

Fortunately, Alibaba Cloud have openSUSE Leap distribution. Alibaba Cloud have openSUSE Leap 42.3, 15.1 and 15.2 beside SLES version. It is help me lot of.

Prepare Virtual Machine for Master and Node

I created two virtual machine with spec:

• 2 VM openSUSE Leap 15.2 (hostname: master-01,node-01)
• 2 Core, 2 GB RAM | ecs.t5-c1m1.large
• Security Group (open port TCP: 22,80,443,6443,30000)

Upgrade to openSUSE Tumbleweed

After created vm, ssh to each server, run upgrade to tumbleweed:

ssh root@ip-server
mkdir /etc/zypp/repos.d/old
mv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/old
zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/oss repo-oss
zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/non-oss repo-non-oss
zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/debug repo-debug
zypper ar -f -c http://download.opensuse.org/update/tumbleweed/ repo-update
zypper dup

Install Kubernetes Stuff

This step will be doing and each virtual machine.
After upgrade, do power off and power on. Then lets start install Kubernetes stuff:

1. Config network option
2. Add config to /etc/sysctl.conf and reload
3. Install kubeadm, cri-o and podman

modprobe overlay
modprobe br_netfilter
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf 
echo "net.ipv4.conf.all.forwarding = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p
zypper in cri-o cri-tools kubernetes-kubeadm kubernetes-client podman
systemctl enable kubelet
systemctl start kubelet

Initialize Kubernetes Cluster on master-01

After done install Kubernetes stuff, lets start initialize Kubernetes cluster:

kubeadm config images pull
kubeadm init

This process will create cluster. Save output command for join cluster. We need this token for next step. And copy kubeconfig for Kubernetes Client.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Setup Network Plugins on master-01

I using project calico for network plugins. It is more better then weave for me.

curl https://docs.projectcalico.org/manifests/calico.yaml -O
kubectl apply -f calico.yaml

Join Cluster on node-01

After created cluster, now we configure node-01 to join cluster. We use command from output kubeadm init at previous command.

kubeadm join 172.31.167.254:6443 --token jqeu4g.34rglub8wkgb9i5x \
    --discovery-token-ca-cert-hash sha256:5d2cbc7a79287228b90b188b4c99626f461a57d13b7a006dfe2265da0d0a9356

Verify Kubernetes Cluster

Do this command on master-01 after node-01 joined cluster.

kubectl get nodes
kubectl get pods --all-namespaces

Create Simple Deployment

I testing cluster using simple app nginx, and service using node port. Here the snippet for nginx-dpy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 2
  template:
    metadata:
      labels:
        app: hello
        env: staging
    spec:
      containers:
        - name: hello
          image: tuanpembual/hello
          imagePullPolicy: Always
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: hello-service
  labels:
    app: hello
spec:
  type: NodePort
  selector:
    app: hello
  ports:
    - name: http
      nodePort: 30000
      port: 80
      targetPort: 80
---

Then deploy this yaml:

kubectl apply -f nginx-dpy.yaml
curl localhost:30000

The apps can be access to using master_01_ip_public:30000/. That all from me.

References

• https://tuanpembual.wordpress.com/2019/12/23/high-availability-kubernetes-cluster-di-alibaba-cloud/
• https://nugi.abdiansyah.com/how-to-kubernetes-in-opensuse-leap-15-1-hardest-way/
• https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri-o
• https://en.opensuse.org/Kubic:kubeadm

I hope it will give you more idea. Thank you
Estu~

Una vez finalizada la Akademy y en con la vista puesta en Akademy-es 2020 me complace en anunciar la actualización de las aplicaciones de KDE de octubre de 2020, una pequeña actualización con resolución de errores, mejoras en las traducciones y la presentación (o recuerdo) de algunas aplicaciones.

Actualización de las aplicaciones de KDE de octubre de 2020

Es complicado llevar al unísono todo el ecosistema que representa el proyecto KDE. No obstante creo que la Comunidad lo lleva bastante bien al dividir su trabajo en tres ramas diferenciadas: entorno de desarrollo KDE Frameworks, escritorio Plasma y aplicaciones KDE.

Esta estructura de trabajo parece funcionar bastante bien desde hace mucho tiempo (concretamente desde el lanzamiento de Plasma 5) siendo la última rama de ellas, el de las aplicaciones KDE, la que más problemas puede dar ya que es complicado que todas las aplicaciones sigan el mismo ritmo de desarrollo. No obstante hay que destacar que la mayor parte de ellas siguen el ritmo que se espera de ellas.

De esta forma, los meses de abril, agosto y diciembre son los meses seleccionados para realizar las grandes actualizaciones y deja el resto de meses para las pequeñas que sirven para afinar los lanzamientos principales y presentar/recordar algunas aplicaciones.

Así que las actualizaciones destacadas de KDE de este octubre 2020 son:

• digiKam 7.1, el gestor de imágenes fotográficas de la Comunidad KDE.
• Labplot 2.8, la aplicación de KDE para gráficos interactivos y análisis de datos científicos.
• KDevelop 5.6, el IDE de desarrollo de software compatible con decenas de lenguajes de programación-
• Calindori, la aplicación de calendario para móviles.
• id3, la aplicación de etiquetado de archivos musicales.

Más información: KDE

Veamos cómo podemos hacer que una máquina remota a la que accedemos mediante ssh nos muestre un mensaje o “banner” antes de acceder

OpenSSH tiene una configuración propia llamada Banner. Con esta opción el contenido del archivo especificado es enviado al usuario remoto antes de autentificarse.

Si la opción Banner está configurada a none entonces no se muestra ninguna información al utilizar el comando ssh. De manera predeterminada esta opción está inhabilitada. Pero vemos cómo podemos activarla y configurarla a nuestro gusto o necesidades.

Esto son los pasos a seguir para configurar la máquina remota para que muestre un mensaje o un “banner” al usuario antes de que se conecte.

• Inicia sesión en tu máquina remota (servidor de GNU/Linux, una Raspberry Pi, etc)
• Abre con derechos de superusuario el archivo /etc/ssh/sshd_config
• Añade o edita la opción de configuración. Por ejemplo, vamos a mostrar el contenido del archivo mi_mensaje en el banner: Banner /etc/ssh/mi_mensaje
• Guardamos y cerramos el archivo
• Debemos asegurarnos que existe el archivo que hemos configurado en la ruta: /etc/ssh/mi_mensaje
• Reiniciamos la máquina o simplemente los servicios mediante: sudo systemctl reload ssh.service

Ahora en el archivo mi_mensaje en la ruta especificada lo adaptamos a nuestro gusto. Podemos incluir un texto de aclaración, bienvenida, o una amenaza!!

O podemos incluir un banner Ascii con el software figlet para darle más vistosidad. O un poco de arte con Ascii. Por ejemplo algo así:

                                                                 #####
                                                                #######
                   #                                            ##O#O##
  ######          ###                                           #VVVVV#
    ##             #                                          ##  VVV  ##
    ##         ###    ### ####   ###    ###  ##### #####     #          ##
    ##        #  ##    ###    ##  ##     ##    ##   ##      #            ##
    ##       #   ##    ##     ##  ##     ##      ###        #            ###
    ##          ###    ##     ##  ##     ##      ###       QQ#           ##Q
    ##       # ###     ##     ##  ##     ##     ## ##    QQQQQQ#       #QQQQQQ
    ##      ## ### #   ##     ##  ###   ###    ##   ##   QQQQQQQ#     #QQQQQQQ
  ############  ###   ####   ####   #### ### ##### #####   QQQQQ#######QQQQQ

U otro texto que te ayude a identificar la máquina remota a la que accedes antes de hacerlo. Si tienes varias máquinas remotas, esto puede ayudarte a no equivocarte antes de acceder a ellas. Yo ya lo he aplicado en mi Raspberry Pi con NextCloud.

Este es una traducción/adaptación de un artículo en inglés escrito por Vivek Gite para la web ciberciti.biz que puedes encontrar en este enlace:

https://www.cyberciti.biz/howto/quick-tip-display-banner-message-before-openssh-authentication/

The openSUSE + LibreOffice Conference organizers are thrilled to begin the conference and hope everyone has a great time.

To get attendees more accustomed to the event, we are publishing some resources and info that will help people joining this year’s conference.

Registration for the conference began yesterday on oslo.gonogo.live.

The Schedule for the event can be viewed on events.opensuse.org. The opening session begins at 10:00 UTC. All talks are scheduled in UTC time. The rooms of all the talks will open five minutes before the talk begins. Collabora’s Michael Meeks will deliver a keynote at 10:30 UTC. Another keynote from SUSE’s Markus Noga about the Powering of Jump will be at 14:30 UTC.

Registration

After registering, it is IMPORTANT to check your email (check spam) for a link to activate your account. Then login to the system using your full email address and password. If you get a 500 error, it’s likely your password will need to be a strong password.

Most users will default to an all sessions area after logging in where they will be able to “add” the sessions they would like to view. The sessions are listed in Alphabetical order. You will only be able to view sessions that you joined.

The events.opensuse.org site and oslo.gonogo.live site are not connected, which could be confusing. The good new is we have people at on a telegram channel and #LiboCon channel on IRC that can help people who are having an difficulties with signing up and logging in to the platform. There is also a tour option located in the upper left menu. Please take the time to go through the tour.

Join Session

After selecting the session, navigate to EVENT HOME and scroll over the presentation area. There you will see a “little green door” in the bottom left of the presentation area that will have a join session appear. This can be seen in this screenshot Join Session.

All users enter in mute. Please keep muted unless you are one of the speakers. A RED microphone means you have a hot/open mic. You can share your camera if you would like.

Leave Session

To join another session, users must leave session the session you’re in. Click on the same “little green door”, which should be yellow when you are in a session.

##Fedora and openSUSE Users Make sure you have the media codecs needed on your system. Chrome is a good browser for this for those who are using non-Linux systems. If you’re using Fedora and the conference doesn’t show video for you, set things up as described at https://fedoraproject.org/wiki/OpenH264. For openSUSE systems, check https://en.opensuse.org/SDB:Install_Packman_codecs.

LibreOffice has made a simple list of resources for the conference. Enjoy the conference and we look forward to seeing you wherever you are throughout the world and please don’t forget to use hashtag oSLO2020!

Puntual como siempre ha sido lanzado Plasma 5.20, la nueva versión del escritorio de la Comunidad KDE que nos llega cargada de novedades y con un anuncio de lanzamiento mejorado, perfecto para estos nuevos tiempos. Es el momento de hablar de sus novedades y esperar que esté disponible pronto en las distribuciones.

Lanzado Plasma 5.20, más y mejor

El tiempo pasa rápido y de forma constante, y eso es lo que parece que entendieron hace unos años la Comunidad KDE cuando decidió dar su quinto salto de versión principal de forma suave y natural, con pocos cambios estéticos pero muchos «bajo el capó» que hicieron incluso perder funcionalidades que poco a poco se fueron recuperando.

Convencidos de su producto, Plasma ha ido mejorando poco a poco, de forma gradual pero sin perder nunca el objetivo de convertirse en el mejor escritorio que puede estar en tu ordenador.

Es por ello que hoy 13 de octubre de 2020 me congratulo en compartir que ha sido lanzado Plasma 5.20, otro paso más en la evolución constante de este entorno de trabajo que enamora a quien le da la oportunidad.

Y además en esta ocasión el equipo de KDE Promo se han lucido con la página del anuncio que empieza con la siguiente frase:

«Una tremenda publicación que contiene mejoras en docenas de componentes, en los widgets y en el comportamiento general del escritorio.»

Y que continua con un maravilloso repaso a buena parte de lo que nos ofrece de nuevo con un diseño espectacular… no os lo perdáis.

Un vistazo previo a las novedades de Plasma 5.20

A lo largo de los próximo días es posible que le dedique artículos más extensos pero para abrir boca os dejo las novedades más destacada son:

• La barra de tareas por defecto será la de Solo Iconos, y además será un poco más ancho (una de las primeras cosas que suelo cambiar cuando configuro mi escritorio)
• Las visualizaciones en pantalla (OSD) que aparecen al cambiar el volumen o el brillo de la pantalla (por ejemplo) se han rediseñado para ser menos intrusivas.
• Ahora se notifica cuando el sistema está a punto de agotar el espacio incluso si el directorio personal es a una partición diferente.
• Ahora se pueden componer mosaicos con las esquinas de las ventanas combinando los atajos de mosaico izquierda/derecha/arriba/abajo. Por ejemplo, pulsando Meta+flecha arriba y después la flecha izquierda para hacer el mosaico de una ventana a la esquina superior izquierda.
• Las páginas de Configuración de Inicio automático, Bluetooth, y Gestión de usuarios se han rediseñado según los estándares modernos de interfaz de usuario y se han reescrito desde cero.
• Notificaciones de monitorización y fallo de discos S.M.A.R.T

If you are interested in openSUSE, sooner or later you will probably learn how packages and specfiles work. But packaging is not static knowledge that you learn once and are good to go. The rules change over time, new macros are created and old ones are erased from history, new file paths are used and the old ones are forgotten. So how can one keep up with these changes?

In this article, we will serve you with all recent news and important changes in openSUSE packaging on a silver platter. Whether you are a pro package maintainer or just a casual packager who wants to catch up, you will definitely find something you didn’t know here. We promise.

Table of contents

• openSUSE macros
  • %_libexecdir
  • systemd macros
  • Cross-distribution macros
  • Deprecated macros
    • Database/cache updating macros
    • %make_jobs
• Paths and Tags
  • Configuration files in /etc and /usr/etc
  • Group: tag
• News in RPM
  • File Triggers
  • %autopatch and %autosetup
  • %patchlist and %sourcelist
  • %elif
  • Boolean dependencies
  • %license
• OBS
  • New osc options
    • osc maintained –version
    • osc request –incoming
    • osc browse
    • Delete requests for entire projects
    • Real names in changelogs
    • rdiff and diff enhancements
    • osc blame
    • osc comment
    • Examining workers and constraints
      • osc checkconstraints
      • osc workerinfo
  • Multibuild
• Oldies
  • PreReq → Requires(pre)
  • /var/run → /run
  • /usr Merge
  • SysV is dead
• Automatic tools for cleaning
  • spec-cleaner
  • rpmlint
• Acknowledgment

openSUSE macros

%_libexecdir

TL;DR

• %_libexecdir macro expands to /usr/libexec now (not /usr/lib)

We will start with the most recent change, which is the %_libexecdir macro. In the past, it was a standard practice to store binaries that are not intended to be executed directly by users or shell scripts in the /usr/lib directory. This has been changed with a release of FHS 3.0 that now defines that applications should store these internal binaries in the /usr/libexec directory.

In openSUSE, the first discussions about changing the %_libexecdir macro from /usr/lib to /usr/libexec appeared in fall 2019 but it took several months for all affected packages to be fixed and the change to be adopted. It was fully merged in TW 0825 in August 2020.

Please note, openSUSE Leap distributions, including upcoming Leap 15.3, still expand %_libexecdir to the old /usr/lib.

systemd macros

TL;DR

• Use %{?systemd_ordering} instead of %{?systemd_requires}
• Use pkgconfig(libsystemd) instead of pkgconfig(systemd-devel)
• BuildRequires: systemd-rpm-macros is not needed

In the past, you’ve been told that if your package uses systemd, you should just add the following lines to your spec file and you are good to go:

BuildRequires: systemd-rpm-macros
%{?systemd_requires}

Times are changing, though, and modern times require a bit of a different approach, especially if you want your package to be ready for inclusion inside a container. To explain it, we need to know what the %{?systemd_requires} macro looks like:

$ rpm --eval %{?systemd_requires}

Requires(pre): systemd 
Requires(post): systemd 
Requires(preun): systemd 
Requires(postun): systemd 

This creates a hard dependency on systemd. In the case of containers, this can be counterproductive as we don’t want to force systemd to be included when it’s not needed. That’s why the %{?systemd_ordering} macro started being used instead:

$ rpm --eval %{?systemd_ordering}

OrderWithRequires(post): systemd 
OrderWithRequires(preun): systemd 
OrderWithRequires(postun): systemd 

OrderWithRequires is similar to the Requires tag but it doesn’t generate actual dependencies. It just supplies ordering hints for calculating the transaction order, but only if the package is present in the same transaction. In the case of systemd it means that if you need systemd to be installed early in the transaction (e.g. creating an installation), this will ensure that it’s ordered early.

Unless you need to explicitly call the systemctl command from the specfile (which you probably don’t because of the %service_* macros that can deal with it), you shouldn’t use %{?systemd_requires} anymore.

Also note, that systemd-rpm-macros has been required by the rpm package for some time, so it’s not necessary to explicitly require it. You can safely omit it unless you are afraid that rpm will drop it in the future, which is highly unlikely.

The last is the BuildRequires, this is needed in cases where your package needs to link against systemd libraries. In this case, you should use:

BuildRequires: pkgconfig(libsystemd)

instead of the older

BuildRequires: pkgconfig(systemd-devel)

as the new variant can help to shorten the build chain in OBS.

Cross-distribution macros

TL;DR

• %leap_version macro is deprecated
• See this table for all distribution macros and their values for specific distros

Commonly, you want to build your package for multiple target distributions. But if you want to support both bleeding-edge Tumbleweed and Leap or SLE, you need to adjust your specfile accordingly. That is why you need to know the distribution version macros.

The best source of information is the table on the openSUSE wiki that will show you the values of these distribution macros for every SLE/openSUSE version. If you want examples on how to identify a specific distro, see this table.

The biggest change between Leap 42 (SLE-12) and Leap 15 (SLE-15) is that %leap_version macro is deprecated. If you want to address e.g. openSUSE Leap 15.2, you should use:

%if 0%{?sle_version} == 150200 && 0%{?is_opensuse}

As you can see, to distinguish specific Leap minor versions, the %sle_version macro is used. The value of %sle_version is %nil in Tumbleweed as it’s not based on SLE.

If you want to identify SLE-15-SP2, you just negate the %is_opensuse macro:

%if 0%{?sle_version} == 150200 && !0%{?is_opensuse}

The current Tumbleweed release (which is changing, obviously) can be identified via:

%if 0%{?suse_version} > 1500

In general, if you want to show the value of these macros on your system, you can do it via rpm --eval macro:

$ rpm --eval %suse_version 
1550

Deprecated macros

TL;DR

These macros are deprecated

• %install_info / %install_info_delete
• %desktop_database_post / %desktop_database_postun
• %icon_theme_cache_post / %icon_theme_cache_postun
• %glib2_gsettings_schema
• %make_jobs (is now known as %cmake_build or %make_build)

If you have been interested in packaging for some time, you probably learned a lot of macros. The bad thing is that some of them shouldn’t be used anymore. In this section, we will cover the most common of them.

Database/cache updating macros

The biggest group of deprecated macros is probably those that called commands for updating databases and caches when new files appeared in specific directory:

• %install_info / %install_info_delete
  • update info/dir entries
• %desktop_database_post / %desktop_database_postun
  • update desktop database cache when .desktop files is added/removed to/from /usr/share/applications
• %icon_theme_cache_post / %icon_theme_cache_postun
  • update the icon cache when icon is added to /usr/share/icons
• %glib2_gsettings_schema
  • compile schemas installed to /usr/share/glib-2.0/schemas

For example, in the past whenever you installed a new .desktop file in your package, you should have called:

%post
%desktop_database_post

%postun
%desktop_database_postun

Since 2017, these macros have started being replaced with file triggers, which is a new feature of RPM 4.13. See File triggers section for more info.

%make_jobs

The %make_jobs macro was initially used in cmake packaging, but was later adopted in a number of other packages, confusingly sometimes with a slightly different definition. To make matters more confusing it also ended up being more complex than the expected /usr/bin/make -jX. Because of this and to bring the macro more inline with other macros such as meson’s, %make_jobs has been replaced with %cmake_build when using cmake and %make_build for all other usages.

In the past, you called: %cmake, %make_jobs, and %cmake_install.

Now it’s more coherent and you call: %cmake, %cmake_build, and %cmake_install when using cmake and just replace %make_jobs with %make_build in other cases.

For completeness, we will add that the naming is also nicely aligned with the meson and automake macros, that are:

%meson, %meson_build, and %meson_install

or

%configure, %make_build, and %make_install.

The %make_jobs macro is still provided by KDE Framework kf5-filesystem package and is used by about 250 Factory packages, but its use is being phased out.

Paths and Tags

Configuration files in /etc and /usr/etc

TL;DR

• /usr/etc will be the new directory for the distribution provided configuration files
• /etc directory will contain configuration files changed by an administrator

Historically, configuration files were always installed in the /etc directory. Then if you edited this configuration file and updated the package, you often ended up with .rpmsave or .rpmnew extra files that you had to solve manually.

Due to this suboptimal situation and mainly because of the need to fulfill new requirements of transactional updates (atomic updates), the handling of configuration files had to be changed.

The new solution is to separate distribution provided configuration (/usr/etc) that is not modifiable and host-specific configuration changed by admins (/etc).

This change of course requires a lot of work. First, the applications per se need to be adjusted to read the configuration from multiple locations rather than just good old /etc and there are of course a lot of packaging changes needed as well. There are 3 variants of how to implement the change within packaging and you as a packager should choose one that fits the best for your package.

Also, there is a new RPM macro that refers to the /usr/etc location:

%_distconfdir  /usr/etc

Group: tag

TL;DR

• Group: tag is optional now

Maybe you noticed a wild discussion about removing Group: tag that hit the opensuse-factory mailing list in Fall 2019. It aroused emotions to such an extent that the openSUSE Board had to step in and helped to resolve this conflict.

They decided that including groups in spec files should be optional with the final decision resting with the maintainer.

News in RPM

RPM minor version updates are released approximately once every two years and they always bring lots of interesting news that will make packaging even easier. Sometimes it’s a little harder to put some of these changes into practice as it can mean a lot of work or hundreds of packages or dealing with backward compatibility issues. This is why you should find more information about their current adoption status in openSUSE before you use new features in your packages.

Current SUSE and openSUSE status of rpm package is as follows:

The following paragraphs present a couple of the most interesting features introduced in recent RPM versions.

File Triggers

TL;DR

• File trigger is a scriptlet that gets executed whenever a package installs/removes a file in a specific location
• Used e.g. in Factory for texinfo, glib schemas, mime, icons, and desktop files, so your package doesn’t have to call database/cache updating macros anymore
• Currently (Nov, 2020), zypper doesn’t handle transfiletrigger properly.

RPM 4.13 introduced file triggers, rpm scriptlets that get executed whenever a package installs or removes a file in a specific location (and also if a package with the trigger gets installed/removed).

The main advantage of this concept is that a single package introduces a file trigger and it is then automatically applied to all newly installed/reinstalled packages. So, instead of each package carrying a macro for certain post-processing, the code resides in the package implementing the file trigger and is transparently run everywhere.

The trigger types are:

• filetrigger{in, un, postun}
• transfiletrigger{in, un, postun}

The *in/*un/*postun scriptlets are executed similarly to regular rpm scriptlets, before package installation/uninstallation/after uninstallation, depending on the variant.

The trans* variants get executed once per transaction, after all the packages with files matching the trigger get processed.

Example (Factory shared-mime-info):

%filetriggerin -- %{_datadir}/mime                                                                                                                                              
export PKGSYSTEM_ENABLE_FSYNC=0
%{_bindir}/update-mime-database "%{_datadir}/mime"

This file trigger will update the mime database right after the installation of a package that contains a file under /usr/share/mime. The file trigger will be executed once for each package (no matter how many files in the package match).

File triggers can easily replace database/cache updating macros (like e.g. %icon_theme_cache_post). This approach has been used in Factory since 2017. File triggers are used for processing icons, mime and desktop files, glib schemas, and others.

You probably haven’t noticed this change at all, as in general having these database/cache updating macros in your specfile doesn’t harm anything now. The change has been made in corresponding packages (texinfo, shared-mime-info, desktop-file-utils, glib2) by adding a file trigger while all these old macros are now expanded to command without action. So you can safely remove them from your specfiles.

! IMPORTANT ! Currently (Nov, 2020), zypper doesn’t handle transfiletrigger properly. If there is a %transfiletrigger and a %post scriptlet in the transaction, then zypper will only call the scriptlet and not your %transfiletrigger. See more information in Bug#1041742.

%autopatch and %autosetup

TL;DR

• Use %autopatch to automatically apply all patches in the spec file
• Use %autosetup to automatically run %setup and %autopatch

The old and classic way to apply patches was:

Patch1:     	openssl-1.1.0-no-html.patch
Patch2:     	openssl-truststore.patch
Patch3:     	openssl-pkgconfig.patch

%prep
%setup -q
%patch1 -p1
%patch2 -p1
%patch3 -p1

With the recent RPM, you can use %autosetup and %autopatch macros to automate source unpacking and patch application. There is no need to specify each patch by name.

%autopatch applies all patches from the spec. The disadvantage is that it’s not natively usable with conditional patches or patches with differing fuzz levels.

Example (Factory openssl-1_1.spec):

Patch1:     	openssl-1.1.0-no-html.patch
Patch2:     	openssl-truststore.patch
Patch3:     	openssl-pkgconfig.patch

%prep
%setup -q
%autopatch -p1 

The -p option controls the patch level passed to the patch program.

The most powerful is the %autosetup macro that combines %setup and %autopatch so that it can unpack the tarball and apply the patchset in one command.

%autosetup accepts virtually the same arguments as %setup except for:

• -v for verbose source unpacking, the quiet mode is the default, so -q is not applicable
• -N disables automatic patch application. The patches can be later applied manually using %patch or with %autopatch. It comes in handy in cases where some kind of preprocessing is needed on the upstream sources before applying the patches.
• -S specifies a VCS to use in the build directory. Supported are for example git, hg, or quilt. The default is patch, where the patches are simply applied in the directory using patch. Setting git will create a git repository within the build directory with each patch represented as a git commit, which can be useful e.g. for bisecting the patches

So the simplest patch application using %autosetup will look like this.

Example (Factory openssl-1_1):

Patch1:     	openssl-1.1.0-no-html.patch
Patch2:     	openssl-truststore.patch
Patch3:     	openssl-pkgconfig.patch

%prep
%autosetup -p1

%patchlist and %sourcelist

TL;DR

• Use %patchlist section directive for marking a plain list of patches
• Use %sourcelist section directive for marking a plain list of sources
• Then use %autosetup instead of %setup and %patch<number>

These are new spec file sections for declaring patches and sources with minimal boilerplate. They’re intended to be used in conjunction with %autopatch or %autosetup.

Example - normal way (Factory openssl-1_1):

Source:     	https://www.%{_rname}.org/source/%{_rname}-%{version}.tar.gz
Source2:    	baselibs.conf
Source3:    	https://www.%{_rname}.org/source/%{_rname}-%{version}.tar.gz.asc
Source4:    	%{_rname}.keyring
Source5:    	showciphers.c

Patch1:     	openssl-1.1.0-no-html.patch
Patch2:     	openssl-truststore.patch
Patch3:     	openssl-pkgconfig.patch

%prep
%autosetup -p1

The files need to be tagged with numbers, so adding a patch in the middle of a series requires renumbering all the consecutive tags.

Example - with %sourcelist/%patchlist:

%sourcelist
https://www.%{_rname}.org/source/%{_rname}-%{version}.tar.gz
baselibs.conf
https://www.%{_rname}.org/source/%{_rname}-%{version}.tar.gz.asc
%{_rname}.keyring
showciphers.c

%patchlist
openssl-1.1.0-no-html.patch
openssl-truststore.patch
openssl-pkgconfig.patch

%prep
%autosetup -p1

Here the source files don’t need any tagging. The patches are then applied by %autopatch in the same order as listed in the section. The disadvantage is that it’s not possible to refer to the sources by %{SOURCE} macros or to apply the patches conditionally.

%elif

TL;DR

• RPM now supports %elif, %elifos and %elifarch

After 22 years of development, RPM 4.15 finally implemented %elif. It’s now possible to simplify conditions which were only possible with another %if and %else pair.

Example Using %if and %else only (Java:packages/ant):

%if %{with junit}                                                                                                                                                               	 
%description 
This package contains optional JUnit tasks for Apache Ant.

%else
  %if %{with junit5}

%description
This package contains optional JUnit5 tasks for Apache Ant.

  %else

%description
Apache Ant is a Java-based build tool.

  %endif
%endif

Example Using %elif:

%if %{with junit}                                                                                                                                                               	 
%description
This package contains optional JUnit tasks for Apache Ant.

%elif %{with junit5}

%description
This package contains optional JUnit5 tasks for Apache Ant.

%else

%description
Apache Ant is a Java-based build tool.

%endif

The else if versions were implemented also for %ifos (%elifos) and %ifarch (%elifarch).

Boolean dependencies

TL;DR

• Factory now supports boolean dependency operators that allow rich dependencies
• Example: Requires: (sles-release or openSUSE-release)

RPM 4.13 introduced support for boolean dependencies (also called “rich dependencies”). These expressions are usable in all dependency tags except Provides. This includes Requires, Recommends, Suggests, Supplements, Enhances, and Conflicts. Boolean expressions are always enclosed with parentheses. The dependency string can contain package names, comparison, and version description.

How does it help? It greatly simplifies conditional dependencies.

Practical example:

Your package needs either of two packages pack1 or pack2 to work. Until recently, there wasn’t an elegant way to express this kind of dependency in RPM.

The idiomatic way was to introduce a new capability, which both pack1 and pack2 would provide, and which can then be required from your package.

Both pack1 and pack2 packages would need adding:

Provides:    pack-capability 	

And your package would require this capability:

Requires:    pack-capability 	

So in order to require one of a set of packages, you had to modify each of them to introduce the new capability. That was a lot of extra effort and might not have always been possible.

Nowadays, using boolean dependencies, you can just simply add

Requires:    (pack1 or pack2)                                                                                                                                                        

to your package and everything will work as expected, no need to touch any other package.

The following boolean operators were introduced in RPM 4.13. Any set of available packages can match the requirements.

• and
  • all operands must be met
  • Conflicts: (pack1 >= 1.1 and pack2)
• or
  • one of the operands must be met
  • Requires: (sles-release or openSUSE-release)
  • The package requires (at least one of) sles-release, openSUSE-release
• if
  • the first operand must be met if the second is fulfilled
  • Requires: (grub2-snapper-plugin if snapper)
• if-else
  • same as if above, plus requires the third operand to be met if the second one isn’t fulfilled
  • Requires: (subpack1 if pack1 else pack2)

RPM 4.14 added operators that work on single packages. Unlike the operators above, there must be a single package that fulfills all the operands

• with
  • similar to and, both conditions need to be met
  • BuildRequires: (python3-prometheus_client >= 0.4.0 with python3-prometheus_client < 0.9.0)
  • The python3-prometheus_client must be in the range <0.4.0, 0.9.0)
• without
  • the first operand needs to be met, the second must not
  • Conflicts: (python2 without python2_split_startup)
• unless
  • the first operand must be met if the second is not
  • Conflicts: (pack1 unless pack2)
• unless-else
  • same as unless above, plus requires the third operand to be met if the second isn’t fulfilled
  • Conflicts: (pack1 unless pack2 else pack3)

The operands can be nested. They need to be surrounded by parentheses, except for chains of and or or operators.

Examples:

Recommends: (gdm or lightdm or sddm)
Requires: ((pack1) or (pack2 without func2))

Until recently, Factory only allowed boolean dependencies in Recommends/Suggests (aka soft dependencies), as it would have otherwise caused issues when doing zypper dup from older distros. Now all operators above are supported.

%license

TL;DR

• Pack license files via %license directive, not %doc

A %license directive was added to RPM in 4.11.0 (2013) but openSUSE and other distributions adopted it later, in 2016. The main reason for it is to allow easy separation of licenses from normal documentation. Before this directive, license texts used to be marked with the %doc directive, that managed copying of the license to the %_defaultdocdir (/usr/share/doc/packages). With %license, it’s nicely separated as is copied to %_defaultlicensedir (/usr/share/licenses).

That’s also useful for limited systems (e.g. containers), which are built without doc files, but still need to ship package licenses for legal reasons.

Example:

%files
%license LICENSE COPYING
%doc NEWS README.SUSE

The license files are annotated in the rpm, which allows a search for the license files of a specific package:

$ rpm -qL sudo
/usr/share/licenses/sudo/LICENSE

OBS

New osc options

The osc command-line tool received several new features as well. Let’s have a quick look at the most interesting changes.

osc maintained –version

New --version option prints versions of the maintained package in each codestream, which is very useful e.g. when you want to find out which codestreams are affected by a specific issue. The only problem is that it’s not very reliable yet - sometimes it prints just “unknown”.

$ osc maintained --version sudo
openSUSE:Leap:15.1:Update/sudo (version: unknown)
openSUSE:Leap:15.2:Update/sudo (version: 1.8.22)

osc request –incoming

New --incoming option for request command shows only requests/reviews where the project is the target.

Example List all incoming request in the new or review state for Base:System project:

$ osc request list Base:System --incoming -s new,review

osc browse

Sometimes it’s just easier to watch the build status or build log in OBS GUI than via osc. With this new option, you can easily open specific packages in your browser. Just run:

$ osc browse [PROJECT [PACKAGE]

If you run it without any parameters, it will open the package in your current working directory.

Delete requests for entire projects

This is not something you want to call every day. But if you need to delete the entire project with all packages inside, you can just call:

$ osc deletereq PROJECT --all

Real names in changelogs

This is a change you probably noticed. If you create a changelog entry via osc vc, it adds not just your email to the changelog entry header but also your full name.

rdiff and diff enhancements

Also, the rdiff subcommand comes with new options. Probably the most useful is rdiff --issues-only that instead of printing the whole diff, shows just a list of fixed (mentioned really) issues (bugs, CVEs, Jiras):

Example osc rdiff --issues-only:

# osc rdiff -c 124 --issues-only openSUSE:Factory/gnutls      
CVE-2020-13777
boo#1171565
boo#1172461
boo#1172506
boo#1172663

More new options were added for the osc diff command. The first is --unexpand that performs a local diff, ignoring linked package sources. The second is diff --meta that performs a diff only on meta files.

osc blame

osc finally comes with a blame command that you probably know from git. It shows who last modified each line of a tracked file.

It uses the same invocation as osc cat:

$ osc blame <file>
$ osc blame <project> <package> <file>

The drawback is that it shows the user who checked in the revision, such as the person who accepted the submission, not its actual author. But it also shows the revision number in the first column, so you can easily show the specific revision with the original author.

Example:

# osc blame openssl-fips-DH_selftest_shared_secret_KAT.patch
[...]
   2 (jsikes       2020-09-17 10:51:27    62) +
   5 (jsikes       2020-09-22 19:07:01    63) +    if ((len = DH_compute_key(shared_secret, dh->pub_key, dh)) == -1)
   2 (jsikes       2020-09-17 10:51:27    64) +        goto err;
   2 (jsikes       2020-09-17 10:51:27    65) +
[...]

Let’s say we’re interested in line 63, where DH_compute_key() is called. It was last changed in revision 5, so we’ll examine that revision:

> osc log -r 5
----------------------------------------------------------------------------
r5 | jsikes | 2020-09-22 17:07:01 | 16a582f1397aa14674261a54c74056ce | unknown | rq227064

Fix a porting bug in openssl-fips-DH_selftest_shared_secret_KAT.patch
----------------------------------------------------------------------------

The change was created by request 227064, so we can finally find the author of the actual code:

$ osc rq show -b 227064
227064  State:accepted   By:jsikes       When:2020-09-22T17:07:07
        submit:          
        From: Request created: vitezslav_cizek -> Request got accepted: jsikes
        Descr: Fix a porting bug in openssl-fips-
               DH_selftest_shared_secret_KAT.patch

You can also blame the meta files and show the author of each line of the meta file, where it shows the author, as the metadata is edited directly.

$ osc meta pkg <project> <package> --blame

Please note that it works on project and package metadata but it doesn’t work on attributes.

osc comment

osc allows you to work with comments on projects, packages, and requests from the command line. That’s particularly useful for writing bots and other automatic handling.

• osc comment list
  • Prints comments for a project, package, or a request.
• osc comment create
  • Adds a new top-level comment, or using the -p option, a reply to an existing one.
• osc comment delete
  • Removes a comment with the given ID.

Examining workers and constraints

osc checkconstraints

When you have a package that has special build constraints, you might be curious about how many OBS workers are able to build it. osc checkconstraints does exactly that.

It can either print the list of matching workers

$ osc checkconstraints LibreOffice:Factory libreoffice openSUSE_Tumbleweed x86_64
Worker     	 
------     	 
x86_64:cloud137:1
x86_64:cloud138:1
x86_64:goat01:1
x86_64:goat01:2
[...]

or even a per-repo summary (when called from a package checkout):

$ osc checkconstraints
Repository            	Arch                  	Worker
----------            	----                  	------
openSUSE_Tumbleweed   	x86_64                	94
openSUSE_Factory_zSystems  s390x                   	18
[...]

osc workerinfo

This command prints out detailed information about the worker’s hardware, which can be useful when searching for proper build constraints.

Example:

$ osc workerinfo x86_64:goat01:1

It will print lamb51's kernel version, CPU flags, amount of CPUs, and available memory and disk space.

Multibuild

TL;DR

• Multibuild is an OBS feature that allows you to build the same spec file with different flavors (e.g. once with GUI and then without GUI)

multibuild is an OBS feature introduced in OBS 2.8 (2017) that offers the ability to build the same source in the same repo with different flavors. Such a spec file is easier to maintain than separate spec files for each flavor.

The flavors are defined in a _multibuild xml file in the package source directory. In addition to the normal package, each of the specified flavors will be built for each repository and architecture.

Example of a _multibuild file (from Factory python-pbr):

<multibuild>
  <package>test</package>
</multibuild>

Here OBS will build the regular python-pbr package and additionally the test flavored RPM. Users can then distinguish the different flavors in spec using and perform corresponding actions (adjusting BuildRequires, package names/descriptions, turning on additional build switches, etc.).

Here we can see, that an additional flavor is getting built:

$ osc r -r standard -a x86_64
standard         	x86_64 	python-pbr                 	succeeded
standard         	x86_64 	python-pbr:test            	succeeded

Example of spec file usage (python-pbr again):

%global flavor @BUILD_FLAVOR@%{nil}
%if "%{flavor}" == "test"
%define psuffix -test
%bcond_without test
%else
%define psuffix %{nil}
%bcond_with test
%endif
Name:       	python-pbr%{psuffix}

First, the spec defines a flavor macro as the value it got from OBS. Then it branches the spec depending on the flavor value. It sets a name suffix for the test flavor and defines a build conditional for easier further handling in the build and install sections.

If you need inspiration for your package, you can have a look at the following packages:

python39, libssh, python-pbr, or glibc.

Oldies

TL;DR

• PreReq is now Requires(pre)
• Use /run, not /var/run
• /bin, /sbin, /lib and /lib64 were merged into their counterpart directories under /usr
• SysV is dead, use systemd

We realize that the changes described below are very, very, VERY old. But we put this section here anyway as we are still seeing it in some spec files from time to time. So let’s take it quickly.

PreReq → Requires(pre)

PreReq is not used anymore, it was deprecated and remapped to Requires(pre) in RPM 4.8.0 (2010).

/var/run → /run

Since openSUSE 12.2 (2012), /run directory was top-leveled as it was agreed across the distributions, that it doesn’t belong under /var. It’s still symlinked for backward compatibility but you should definitely use /run (%_rundir macro).

/usr Merge

/usr Merge was a big step in the history of all Linux distributions that helped to improve compatibility with other Unixes/Linuxes, GNU build systems or general upstream development.

In short, it aimed to merge and move content from /bin, /sbin, /lib and /lib64 into their counterpart directories under /usr (and creating backward compatibility symbolic links of course). In openSUSE it happened around 2012.

SysV is dead

The only excuse for missing the fact that SysV is dead is just that you’ve been in cryogenic hibernation for the last 10 years. If yes, then it’s the year 2020 and since openSUSE 12.3 (2013) we use systemd.

Automatic tools for cleaning

TL;DR

• Call spec-cleaner -i mypackage.spec to clean your specfile according to the openSUSE style guide.
• Call rpmlint mypackage.rpm or inspect the rpmlint report generated after the OBS build for common packaging errors/warnings.

If you read as far as here, you are probably a bit overwhelmed with all these new things in packaging. Maybe you ask yourself how you should remember all of it or more importantly, how you should keep all your maintained packages consistent with all these changes. We have good news for you. There are automated tools for it.

spec-cleaner

spec-cleaner is a tool that cleans the RPM spec file according to the style guide. It can put the lines in the right order, transform hardcoded paths with the correct macros, and mainly replace all old macros with new ones. And it can do much more.

It’s also very easy to use it, just call

$ spec-cleaner -i mypackage.spec

for applying all changes inline directly to your spec file.

If you just want to watch the diff of the changes that spec-cleaner would make, call:

$ spec-cleaner -d mypackage.spec 

rpmlint

Another tool that will help you keep your package in a good shape is rpmlint. It checks common errors in RPM packages and specfiles. It can find file duplicates, check that binaries are in the proper location, keep an eye on correct libraries, systemd, tmpfiles packaging and much more. Inspecting your package from top to bottom, it reports any error or warning.

rpmlint runs automatically during the OBS build so it can fail the whole build if there are serious problems. It works as a tool for enforcing specific standards in packages built within OBS. If you want to run it on your own, call:

$ rpmlint mypackage.rpm

Both spec-cleaner and rpmlint implement the new packaging changes and new rules as soon as possible. But it’s possible that maintainers may miss something. In that case, feel free to report it as an issue on their github.

Acknowledgment

Thanks, Simon Lees, Tomáš Chvátal, and Dominique Leuenberger for suggestions, corrections, and proofreading.