Dear Tumbleweed users and hackers,

Xmas is upon us – at least in some areas of the world. This means quitea lot of people are away from their computers and the number of submissions is getting a bit lower. Tumbleweed is not stopping though – it just rolls at the pace contributors create submissions. For week 2020/52 this means a total of 3 snapshots that were published. Saddest of this all is that the new kernel 5.10 is not behaving very nicely when the iwlwifi module is being loaded. The three snapshots published were 1218, 1221 and 1223, containing those changes:

• KDE Applications 20.12.0
• Poppler 20.12.1
• Linux kernel 5.10.1: as noted in the intro, there is an issue with iwlwifi. Unfortunately i was informed about that too late. The earlier reported amdgpu issue had been fixed in time though. Upstream bug reference: https://bugzilla.kernel.org/show_bug.cgi?id=210733
• Systemd 246.9

The staging projects are still filled up and a few more snapshots are likely to be released this year. Some of the changes that might become ready include:

• Mozilla Firefox 84.0
• icu 68.1: breaks a few things like postgresql. Staging:I
• Ruby 3.0: final release is staged. It will be added short term as additional version, with the default, used by r.g YaST, pinned to version 2.7
• Multiple python 3 versions parallel installable. Adding to python 3.8, version 3.6 week be reintroduced. Python modules will be built for both versions.
• RPM 4.16: all build issues in Staging:A have been fixed, but on upgrades, rpm seems to segfault in some cases.
• brp-check-suse: a bug fix in how it detected dangling symlinks (it detected them, but did not fail as it was supposed to)
• permissions package: prepares for easier listing, while supporting a full /usr merge
• Rpmlint 2.0: experiments ongoing in Staging:M
• openssl 3: not much progress, Staging:O still showing a lot of errors.

今年も openSUSE Advent Calendar に参加頂きありがとうございました。

最終日は今年1年を振り返っていきたいと思います。

今年最初のイベントは1月3日の京都での新年会&もくもく会でした。続いて4日に東京での新年会でした。このときはこんな状況になるとも知らず、オフラインでの開催でした。

新年会以降、国内でも COVID-19 の感染者数が増え始め、今年のイベントはストップ。9年ぶりに都内に戻るはずだった OSC 東京も中止になってしまいました。

4月は OSC Online/Spring に参加。2月のOSCで発表予定だった Snapper を有効にしたファイルサーバーの話をしました。初のオンラインイベントにもかかわらず、Remo を使ったバーチャル展示にも挑戦しましたが（枠は XDDC）、こちらはちょっと時代がまだ追いついていない感じでした。

5月は OSC Nagoya/Online に出展。川上さんが「Dockerで始めるネットワーク実験入門」について話してくれました。

openSUSE Leap 15.2 の Release Party はなんとかオンライン開催しました。昼間から乾杯して、15.2のリリース情報を眺めて、修太さんがセキュアブートの話をしてくれました。

8月の OSC 京都は「あつまれ！openSUSEユーザーの森」。京都でこのタイトルは流石に事務局に何か言われるんじゃないだろうかと言う声もありましたが、このままのタイトルになりました。ユーザー会のメンバーがどのように openSUSE を使っているかを紹介するという新しいスタイルのセミナーでした。

うちだけではないようですが、OSC のブースはユーザ会の出展モチベーションの大きな割合を占めていて、展示がないことで OSC 東京はスキップしてしまいました。このまま今年の OSC はおしまいとなりそうでしたが、12月、ODC は XDDC として春に開催予定であったディストリビューション大集合を開催し、openSUSEも参加しました。

来年に向けて

今年は1年間を通して Geeko Magazine を出しませんでした。コミケも2回ともなくなってしまいましたし、技術書典や OSC などのオフラインでの頒布機会もありませんでした。

来年は GW に開催される予定の C99 に申し込んでいます。もしスペースを確保できれば、久しぶりの新刊を出すことができそうです。

イベントは当面オンラインになるかと思います。ユーザ会の単独イベントはどれくらい行うかは決めていませんが、メンバーは OSC はもちろん、小江戸らぐなどオンラインイベントにも出没していますので、ぜひ、参加してみて下さい。

Con el lanzamiento de Plasma 5.8 de enero de 2017 llegó una funcionalidad llamada Look and Feel que nos permitía mediante un simple click de cambiar todo Plasma: sus temas, esquema de colores, cursores del ratón, conmutador de ventanas, pantalla de bloqueo, etc. Esta funcionalidad ha ido creciendo en número de aportaciones en la Store de KDE (que lleva un año de continuos cambios), e incluso ha cambio el nombre a Global Theme, siendo en estos momentos más de 265 los temas elegibles (casi el doble de hace un año). Entre ellos se encuentra XMas un tema global navideño ideal para estas fechas que me complace compartir con vosotros.

XMaS, un tema global navideño para Plasma

De la mano de x-varlesh-x nos llegan un Tema Global (antes conocido como Look & Feel) para Plasma llamado XMaS que nos personaliza nuestro escritorio con un tema navideño oscuro, con un degradado de color del violeta al azul muy adecuado para estas fechas.

En realidad el Tema Global XMaS se compone e instala los siguientes módulos:

• XMaS, Kvantum
• XMaS, Aurorae
• XMaS, esquema de color
• XMaS, tema de plasma

Más información: Xmas

Y como siempre digo, si os gustan estos Temas Globales (ex-Look & Feel) para Plasma podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

In April, we announced the Modernizing AutoYaST initiative. The idea was not to rewrite AutoYaST but just introduce a few new features, remove some limitations and improve the code quality.

Although they were not set in stone, we had some ideas about what changes we wanted to introduce. However, as soon as we started to work, it became clear that we needed to adapt our roadmap. So if you compare our initial announcement with the result, you can spot many differences.

This article describes the most relevant changes. If you want to try any of these features, they are already available in openSUSE Tumbleweed.

Reducing profiles size

When AutoYaST generates a profile from an existing system, it includes a lot of information to reproduce the installation. As a consequence, those profiles are rather long, which makes working with them quite annoying.

However, it is not always clear when it is safe to omit some information from the profile without compromising the final result. To address this problem, we decided to introduce the concept of target. Thus, when generating a profile, you can ask AutoYaST to generate a more compact profile.

# yast2 clone_system modules target=compact filename=autoinst-compact.xml

In my current machine, the size of the profile is reduced from 2201 lines to just 834. But which information is omitted? Let’s enumerate a few items:

• System users and groups.
• Not modified firewall zones.
• System services which preset has not been changed.
• Printer settings if the cups service is disabled.

Note that not all YaST modules implement support for this flag. Actually, in some cases, it does not make any sense.

Making easier to write dynamic profiles

When dealing with the installation of multiple systems, it might be useful to use a single profile that adapts to the system being installed at runtime. AutoYaST already offered two mechanisms to implement this behavior: rules and classes and pre-install scripts.

However, we though that it might be easier if you could embed Ruby (ERB) code in your profiles. The idea is to provide a set of helper functions that you can use to inspect the system and adjust the profile by setting values, adding or skipping sections, etc. It sounds cool, right? Let’s see a simple example.

The code below finds the largest disk by sorting them size and sets the value of the device element.

<partitioning t="list">
  <drive>
    <% disk = disks.sort_by { |d| d[:size] }.last %> <!-- find the largest disk -->
    <device><%= disk[:device] %></device> <!-- print the disk device name -->
    <initialize t="boolean">true</initialize>
    <use>all</use>
  </drive>
</partitioning>

Of course, apart from a set of helpers (disks, network_cards, os_release or hardware), you have the power of Ruby in your fingertips. What about retrieving a whole section from a remote location? At some extent, it could replace the classes and rules feature.

<bootloader>
  <% require "open-uri" %>
  <%= URI.open("http://192.168.1.1/profiles/bootloader-common.xml").read %>
</bootloader>

Unfortunately, the documentation of this feature is still a work in progress. However, we expect to have it ready in the upcoming weeks.

Improved scripting support

Apart from introducing support for ERB, as described in the previous section, we improved script handling. Until now, Shell, Perl and Python were the only supported scripting languages. We removed this limitation and now you can use any interpreter available at installation time. Moreover, it is possible to pass custom options to the interpreter.

<intepreter>/usr/bin/bash -x</interpreter>

Additionally, we fixed a few issues and extended the error handling to inform the user when the script did not run successfully.

Validating the profile

Building and tweaking your profile can be a time-consuming task. AutoYaST offers XML-based validation, but the sort of errors you can detect is rather limited.

To make your life easier, we introduced these new features to leverage profile validation:

• Automatic profile validation at runtime.
• A new check-profile command to detect errors without running the installer.

When AutoYaST fetches the profile, it automatically performs the XML-based validation, reporting any error found. It works even if you are using features like Rules and classes or Dynamic profiles. However, it can be easily disabled by setting the YAST_SKIP_XML_VALIDATION parameter to 1 when booting the installer.

Regarding the check-profile, it basically uses part of the code that runs during AutoYaST initialization. It includes:

• Profile fetching (even from a remote location).
• XML-based validation.
• Support for dynamic profiles: rules and classes, ERB and pre-installation scripts (optional).
• Optionally, detection of problems during profile import.

Needlessly to say that you should run this command with caution. Bear in mind that ERB and pre-installation scripts can run any arbitrary code. In fact, we are working with our security experts to make this command safer. See bsc#1177123 for further details.

Reducing the second stage

Unlike a normal installation, AutoYaST still uses two phases, which are known as stages. The first stage is responsible for most of the installation tasks: partitioning, registration, software installation, network configuration, etc. Depending on the content of the profile, the second stage comes into play after the first reboot. It takes care of additional configuration processes, like setting the firewall rules, enabling/disabling services, etc.

To reduce the need for a second stage, we moved the processing of several sections to the first stage. At this point, these sections are processed during this stage: bootloader, configuration_management, files, firewall, host, kdump, keyboard, language, networking, partitioning, runlevel, scripts (except post-scripts and init-scripts, which are processed during the second stage), security, services-manager, software, ssh_import, suse_register, timezone and users. Thus if your profile does not contain any other section, you can happily disable the second stage.

<general>
  <mode>
    <second_stage t="boolean">false</second_stage>
  </mode>
 </general>

A better UI to define the partitioning section

The user interface offered by AutoYaST to define the partitioning section was confusing, buggy and rather limited. Therefore we took the chance to, basically, rewrite the whole thing.

It is still a work in progress, but it is already much better than the old one. For instance, in addition to disks and LVM, it supports defining sections for RAID, bcache and multi-device Btrfs file systems.

It should be noted that these changes are already available in openSUSE 15.2 and SUSE Linux Enterprise 15 SP2, so you do not need to wait until 15.3 or SP3 to enjoy them.

Conclusion

New features and bug fixes are the most visible changes. However, as part of this process, we refactored a lot of code, improved code coverage, extended the documentation, etc. In general, we feel that we improved AutoYaST quality in a sensible way. And we hope you have that impression too in the future.

Bienvenidos al Podcast 07×03 Software libre y KDE en entornos profesionales: abogacía donde estudiamos si es posible el uso de proyectos libre en esta profesión.

Podcast 07×03 Software libre y KDE en entornos profesionales: abogacía

Tercer podcast de la temporada con el que se cierra el año y en el que tenemos como invitadas a Marelisa Blanco, autora de un cómic sobre licencias de software, «La jungla del software» y abogada en Nolegaltech y María Cerviño, experta en contratos y en dar soluciones creativas, también de Nolegaltech.

Con este podcast empezamos esta temporada una serie sobre el uso de software libre en los entornos profesionales, en los oficios y profesiones. Os pedimos colaboración para localizar a profesionales no relacionados con la informática que conozcáis que estén usando software libre y Gnu/Linux como su entorno principal de trabajo: desde electricistas hasta carpinteros pasando por ingenieros, gestorías, veterinarios…

Otros integrantes del podcast fueron

• Rubén Gómez: miembro de KDE España, de HackLab Almería y de Document Foundation en la labor de presentador.
• Mari Carmen, aka Maika, miembro de KDE España que hizo su presencia inicialmente pero que tuvo problemas técnicos y tuvo que dejar el podcast.
• Baltasar Ortega (un servidor): editor de KDE Blog, secretario de KDE España, miembro de GNU/Linux València y de KDE e.V, que hizo las funciones de presentador de noticias y de presentar información adicional visual. No os perdáis el vídeo que creo que vale la pena, aunque seguro que hay coasa a mejorar.
• 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 20 minuto, uno de los podcast más cortos de los últimos tiempos.

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.

Veamos cómo hacer que dos (o más) ventanas se sincronicen cuando hagamos “scroll” en una de ellas.

El otro día mientras seguí mi traducción del libro sobre Vim que estoy realizando, hice una división de la ventana y abrí el original en inglés para comparar unas modificaciones.

Y en cierto momento pensé, estaría bien que mientras desplazo el texto de mi traducción haciendo “scroll” también estubiera sincronizada la otra ventana y se desplazara para comparar todo el texto sin necesidad de desplazarme y hacer “scroll” también en esa ventana.

¡Y dicho y hecho, el editor Vim ofrece esa posibilidad! No para de sorprenderme esta gran herramienta para editar textos de manera eficiente y rápida. Veamos cómo.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Veamos el escenario principal. Tengo el editor con la vista dividida en dos de manera vertical (me gusta más de esa manera) editando/traduciendo en una ventana un texto y en la otra tengo el original.

Sitúo el cursor en ambas en la primera línea del archivo con el comandos gg y ahora hago que se sincronicen el desplazamiento de texto ejecutando en ambas ventanas el comando:

:set scrollbind

O de manera reducida también puedes ejecutar:

:set scb

Ahora cuando me desplace en una ventana, en la otra el texto se desplazará automáticamente de manera similar.

Por supuesto, no es necesario que esté el cursor en la primera línea, simplemente en mi caso lo estaba revisando desde la primera línea y quería que ambos se sincronizasen desde esa línea.

Y también decir, que podemos tener dos o más divisiones en la ventana y ejecutar en todas ellas el comando, y en todas las ventanas que lo ejecutamos, estarán sincronizadas.

Para dejar que estén sincronizadas, ejecutaremos el mismo comando (el largo o el corto) pero ahora añadiendo al final del comando el símbolo !

:set scb!

Si quieres más información sobre este comando, ejecuta en Vim la ayuda para leer más al respecto:

:help scrollbind

La Raspberry Pi 4 es una computadora del tamaño de una tarjeta de crédito que se conecta a una pantalla de tv y un teclado. Es una pequeña PC que puede usarse para muchas de las cosas que se realizan en una PC de escritorio, como hojas de cálculo, procesamiento de texto y juegos. También reproduce videos de alta definición. 

Datos Técnicos

• Broadcom BCM2711 SoC
  • 4x ARM Cortex-A72 CPU @ 1.5GHz.
• RAM: 1 - 8 GB LPDDR4-2400 SDRAM (dependiedo del modelo)
• Gigabit Ethernet
• WiFi – 2.4 GHz y 5.0 GHz IEEE 802.11ac wireless
• Bluetooth 5.0, BLE
• USB: 2x puertos USB 3.0; 2x puertos USB 2.
• Conector 40-pines

openSUSE en Raspberry Pi 4

Escribir una imagen de disco en una memoria USB o una tarjeta SD

1. Descargamos la imagen que se desea (Leap es estable, Tumbleweed es cambios continuos) desde aquí. Elejimos los escritorios:

JeOS: sistema operativo suficiente: un sistema muy básico, sin escritorio gráfico
E20 - Escritorio Enlightenment
XFCE: Escritorio XFCE
KDE - Escritorio KDE
LXQT - Escritorio LXQT
X11 - Sistema básico X11 

Version: Tumbleweed

 Imagen JeOS Imagen E20 Imagen XFCE Imagen LXQT Imagen KDE Imagen X11

Version:  Leap-15.2

 Imagen JeOS Imagen E20 Imagen XFCE Imagen LXQT Imagen KDE Imagen X11

Directorio de descarga general de las imágenes ISO 

2. Como root, extraemos la imagen en la tarjeta SD (reemplazamos sdX con el nombre del dispositivo de nuestra tarjeta SD).
ADVERTENCIA: se perderán todos los datos anteriores de la tarjeta SD. ¡Comprobaos primero si el dispositivo que se ha seleccionado es realmente nuestra tarjeta SD!  

 xzcat [image].raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress; sync

3. Insertamos la tarjeta SD con la imagen de openSUSE en la placa (Raspberry Pi).
 

4. Conectamos la placa a la PC a través del puerto serie (opcional, pero útil para la depuración; se necesita un cable serie USB-TTL).
 

5. Conectamos la placa al monitor (a través de DVI / HDMI).
 

6. Encendemos la Raspberry Pi.
 

7. Seguimos los primeros pasos del arranque.

8. La Ethernet está configurado para solicitar una IP a través de DHCP, verificamos si el servidor DHCP está asignando la IP a la Raspberry Pi.
 

9. ¡Listo. Diviértete mucho...!

El inicio de sesión predeterminado es usuario: root, contraseña: linux. Esta configuración funciona en la consola serial a través de ssh y en el entorno gráficode usuario (GUI).

諸事情で、MicroOSのルートにbtrfsの機能でディスクを追加したのですが、balasceを実行しようとすると「read onlyだよ」と警告が。

ユーザ会slackに投げてみた所、武山さんから「transactional-update shellの中ならいけるのでは？」との助言を頂きました。

結論

成功

コマンド

transactional-update shell

transactional-updateそのもののアップデートが行われた後、独自のシェルに移行しました。

transactional update #

この状態で書き込み可能になります。書き込み後、シェルを抜けてrebootすれば反映されるしくみですね。

btrfs balance /

前後の状態を撮り損ねてしまったのですが、無事にbalanceされてました。

transactional-updateの真価はまだ味わえてないので、ロールバック等含め、近いうちにまとめて検証してみたいですね。

そもそも、transactional-update shellが一体何をどうしているのかも追えていない・・・