Outreach, Survey Extension Addressed in Second Meetup
The second session of the openSUSE Project’s meetup regarding the End of the Year Survey Results on Jan. 30 led to some changes with regard to future surveys and contributors are looking to enhance outreach.
The two-hour meetup took place on openSUSE’s Jitsi instance and several community members around the globe provided input on the results and how to improve the project’s diversity as well as global use.
The group spent time discussing the projects’ weaknesses and strengths based on the survey results and commonly understood areas members hope to improve.
The previous meetup session laid some groundwork with the introduction of monthly web development sprints to address feedback provided by attendees in both sessions. One of the areas mentioned were highlighting communication entry points so new users can be welcomed to the community and introduced to the project’s distributions and tools.
Attendees also discussed how to address users switching to openSUSE from Windows or other Linux distributions like Ubuntu, Debian, CentOS, Arch, etc. The meetup also included a discussion about marketing strategies and ways to increase visibility for the projects’ projects and distributions. A marketing workgroup for the release of openSUSE Leap 15.3 was an idea brought up in the discussion and is moving forward with establishing a team.
Another topic resulted in a decision to extend future EOY surveys to be run for 30 days, which will run from mid-November to mid-December, rather than being open for two weeks like last year’s survey.
The attendees continued the discussion in the openSUSE Bar, which currently doesn’t have it’s opening hours posted.
Resumen 2020 y expectativas 2021 en GNU/Linux y FLOSS en Compilando Podcast #52
Con 24H24L me está costando ponerme al día con todos los podcast de Software lIbre que hay, pero debo reconocer que cuando sale uno de Compilando Podcast lo subo rápidamente al principio de las lista. Así que, con conocimiento de causa hoy os quiero recomendar el episodio #52 Resumen 2020 y expectativas 2021 en GNU/Linux y FLOSS de Compilando Podcast, un audio que llega a un mes de este inicio convulso de año.
Resumen 2020 y expectativas 2021 en GNU/Linux y FLOSS en Compilando Podcast #52
En palabras del gran Paco Estrada que sirven de introducción del episodio 52 de Compilando Podcast:
Como cada año, durante el primer mes de estos nuevos 365 días, repasamos en Compilando Podcast, lo que ha dado de si el 2020 y las expectativas para el recién llegado 2021.

El año que hace unas semanas hemos cerrado ha sido duro por, en primer lugar, las vidas y la salud que se ha llevado por delante la maldita pandemia del coronavirus. En el que se acaba de abrir,hace unos días, depositamos esperanzas de que podamos superar esta crisis con el menor costo posible en vidas, salud y sustento.
Pero en medio de la Covid-19 el FLOSS (Free, Libre y Open Source Software) ha seguido adelante revelándose, en muchos casos como una herramienta de primer orden para la sociedad mundial.
Es habitual en Compilando Podcast invitar a una serie de colegas en el mundo FLOSS con cuyas certeras opiniones nos hacemos una idea de lo que ha sido el pasado año y de lo que esperamos para el recién estrenado 2021, en software libre y open source. Colegas que son referentes en este mundo y a los que agradecemos enormemente su colaboración con Compilando, cada mes de Enero.
Contaremos con las opiniones de Yoyo Fernández, Arantxa Serantes, Eloy García, Atareao (Lorenzo Carbonell), Gustavo Ibáñez, Samuel Iglesias, Ernesto Acosta, Eduardo Collado, JoseGDF, Ritxi, Juan Febles, Paul Brown, Ricardo Fabara Camino, Miguel A. Bouzada y un servidor, Baltasar Ortega
En resumen, un podcast más que interesante por que nos muestra el crisol de proyectos libres que es el mundo del Software Libre, donde vuelven a demostrar lo viva que está la Comunidad y que nadie puede conocer al 100% todo lo que se crea a su alrededor.
Como siempre os invito a escuchar el podcast completo y compartirlo con vuestro entorno cercano y en vuestras redes sociales.
Más información: #52 Resumen 2020 y expectativas 2021 en GNU/Linux y FLOSS
¿Qué es Compilando Podcast?
Dentro del mundo de los audios de Software Libre, que los hay muchos y de calidad, destaca uno por la profesionalidad de la voz que lo lleva, el gran Paco Estrada, y por el mimo con el que está hecho. No es por nada que ganó el Open Awards’18 al mejor medio, un reconocimiento al trabajo realizado por la promoción .
A modo de resumen, Compilando Podcast es un proyecto personal de su locutor Paco Estrada que aúna sus pasiones y que además, nos ofrece una voz prodigiosa y una dicción perfecta.
Más información: Compilando Podcast
Install the latest version of VirtualBox on openSUSE
The main openSUSE repository does not feature the latest version of VirtualBox. To obtain the latest version of the software, one may use VirtualBox's own repo for openSUSE. Details are available on the virtualbox.org project website. However, I am reproducing them here for a quick reference & also to address some quirks that you might encounter if you simply add the repo & install VirtualBox.
Step 1
We add the VirtualBox repository by creating the /etc/zypp/repos.d/virtualbox.repo file with the below content.
[virtualbox]
name=VirtualBox for openSUSE 15.0 - $basearch
enabled=1
autorefresh=1
baseurl=http://download.virtualbox.org/virtualbox/rpm/opensuse/15.0/$basearch
priority=120
gpgcheck=1
gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc
keeppackages=0
VirtualBox does not have a separate repository for Leap 15.1, 15.2, etc. The repo for Leap 15.0 should work just fine.
Step 2
Refresh the repositories and search for the latest version of VirtualBox.
sudo zypper ref && zypper se virtualboxThe output of the command is shown below.
S | Name | Summary | Type
--+--------------------------------+--------------------------------------------------+-----------
| VirtualBox-5.2 | Oracle VM VirtualBox | package
| VirtualBox-6.0 | Oracle VM VirtualBox | package
| VirtualBox-6.1 | Oracle VM VirtualBox | package
| python3-virtualbox | Python bindings for virtualbox | package
| virtualbox | VirtualBox is an Emulator | package
| virtualbox | VirtualBox is an Emulator | srcpackage
| virtualbox-devel | Devel files for virtualbox | package
| virtualbox-guest-desktop-icons | Icons for guest desktop files | package
| virtualbox-guest-source | Source files for virtualbox guest kernel modules | package
| virtualbox-guest-tools | VirtualBox guest tools | package
| virtualbox-guest-x11 | VirtualBox X11 drivers for mouse and video | package
| virtualbox-host-source | Source files for virtualbox host kernel modules | package
| virtualbox-kmp | Kernel modules for VirtualBox | srcpackage
| virtualbox-kmp-default | Kernel modules for VirtualBox | package
| virtualbox-kmp-preempt | Kernel modules for VirtualBox | package
| virtualbox-qt | Qt GUI part for virtualbox | package
| virtualbox-vnc | VNC desktop sharing | package
| virtualbox-websrv | WebService GUI part for virtualbox | package
Step 3
We pick the latest version, in this case VirtualBox 6.1, and install it as follows:
sudo zypper in gcc kernel-default-devel VirtualBox-6.1Notice that we installed the GCC compiler and the Kernel development files which will be required by VirtualBox to compile and install driver modules into the system kernel. Unless these driver modules are installed we won't be able to create virtual machines or we might create the virtual machines but not be able to start them.

Once all commands have completed successfully, we can run VirtualBox 6.1.
If you would like to expertiment on openSUSE using VirtualBox, you should know that you can grab the openSUSE Leap 15.2, Tumbleweed and MicroOS images for VirtualBox.
Getting a package from openSUSE to SLE
I was looking forward to updating a package (enchant) with a backported patch from upstream and wanted it to be included in both SLE offerings and openSUSE. I’m used to working within the community from the past, so even though I’m a SUSE employee I wanted to contribute without using anything internal.
I filed a bug and did a request to first get the patch into Tumbleweed via GNOME:Factory. That was easy, but then I looked on how to get the same patch into the stable releases. Since openSUSE and SUSE are now coming closer, I found documentationa about the Jump and mailing lists described some documents for example that there either is or is going to be a new redirector service, and suggestion was to target openSUSE:Jump:15.2 at one point.
Eventually I found out that since 15.3 is when SLE & openSUSE really closes the leap gap, Jump is already history and currently the best target is to use openSUSE:Leap:15.3. I was actually told by someone that it wouldn’t work, but… it did!
In practice my Leap request (I really submitted it to openSUSE:Leap:15.3!) was automatically detected to be about a package that openSUSE inherits from SLE, so the target was switched to SLE 15-SP2 on the fly. Secondly, after some time a person managing these kind of requests copied over my public request to be usable inside SLE process, and then an official SLE 15-SP2 update request was created automatically. It passed QA in the beginning of January, and was made available to 15-SP2 users! Luckily 15-SP3 has no deviation for this package from 15-SP2, so it’s automatically also there, and that means openSUSE Leap 15.3 is going to have the patched package automatically as well.
Finally, also without my manual intervention there was a request to get it to Leap 15.2 as well, finalizing fixing all relevant releases (15.1 is not affected by the bug).
All in all, even though it feels the documentation is a bit lacking and there could be more feedback or clearer visibility on a higher level, the functionality of the process was really good. Now that I know a bit more, I can try to improve the wiki a bit.
Resumo da 4ª Semana de 2021do openSUSE Tumbleweed
O openSUSE Tumbleweed é a versão de "lançamento contínuo" da distribuição GNU / Linux openSUSE.
Neste resumo vamos ver as principais atualizações que chegaram aos repositórios nesta 4 semana.
O anúncio original pode ser lido no blog de Dominique Leuenberger, no link abaixo:
http://dominique.leuenberger.net/blog/2021/01/opensuse-tumbleweed-review-of-the-week-2021-04/
Devido a alguns problemas no OpenQA, esta semana foram os publicados 3 instantâneos esta semana 0126, 0127 e 0128.
Foram realizadas as seguintes atualizações, entre muitas outras:
- Automake 1.16.3
- findutils 4.8.0
- Kernel Linux 5.10.9
- libvirt 7.0.0
- Sudo 1.9.5p2 (CVE-2021-3156)
E em breve poderemos contar com as atualizações no openSUSE Tumbleweed:
- Mozilla Firefox 85.0
- Kernel Linux 5.10.11
- util-linux 2.36.1
- Rust 1.49.0
- Postfix: mude o banco de dados padrão de lmdb para BerkleyDB.
- Bison 3.7.5
- Firewalld 0.9.3
- Pulseaudio 14.2
- Bind 9.16.11
- KDE Plasma 5.21
- openssl 1.1.1i
Se você deseja estar atualizado com o software testado e atualizado, use o openSUSE Tumbleweed, a opção de lançamento contínuo da distribuição openSUSE GNU / Linux.
Fique atualizado e você sabe: Divirta-se muito !!
#openSUSE Leap 15.1 llega a su fin de soporte oficial
openSUSE Leap 15.1 dejará de tener soporte oficial desde este 31 de enero de 2021

Tal como se anunció en la lista de correo hace un tiempo. Este 31 de enero de 2021 SUSE dejará de dar soporte oficial a SUSE Linux Enterprise 15 service pack 1.
Y como openSUSE Leap 15.1, está basada en esta versión, también la versión comunitaria dejará de tener soporte oficial y por tanto quedará discontinuada.
Ya no habrá actualizaciones de paquetes ni parches de seguridad, por lo tanto se recomienda actualizar a la versión 15.2 de openSUSE Leap.
openSUSE Leap 15.1 se publicó un 22 de mayo de 2019. Lo que hace un ciclo de más de 1 año y medio o concretamente 620 días de soporte oficial.
openSUSE Leap 15.2, la segunda versión menor o service pack de la serie 15 de openSUSE Leap se publicó el pasado 1 de junio de 2020.
Y de igual manera tendrá un periodo de vida de 1 año + 6 meses. Normalmente son 6 meses desde la publicación de la siguiente versión Leap 15.3 que está previsto que se publique el 7 de julio de este 2021.
Por tanto, si usas openSUSE Leap 15.1 lo mejor es que te actualices a Leap 15.2 para seguir disfrutando de un sistema estable, seguro y actualizado.
Yo actualizo de esta manera entre versiones menores:
¡Larga vida a openSUSE Leap!
Enlaces de interés
- https://kamarada.github.io/en/2021/01/31/opensuse-leap-151-and-linux-kamarada-151-reach-end-of-life-today/
- https://software.opensuse.org/distributions/leap

Spack is now available in openSUSE Tumbleweed
The configurable Python-based HPC package manager Spack is now an Official package in openSUSE Tumbleweed, which currently has the 0.16.0 version of Spack.
If you work with scientific software, you probably know about spack.
Spack is a package manager for HPC that allows to install scientific software using provided recipes. You can easily use multiple compilers and compiler versions. And different versions of the same software can coexist peacefully.
Spack is used with environment-modules or lmod to make easier for users to choose the software stack for their projects.
However, how does this work with zypper? Spack is totally independent of zypper. When you install something with the spack provided by the openSUSE package, everything is built and installed locally for the user under the directory ~/spack.
You have the option of building all the libraries required by the spack recipe or to use some of the libraries already installed on your openSUSE system.
While spack can be used directly after a git clone, it was package to give users the possibility of having it better integrated with openSUSE. After installation, spack will look for all the libraries used in your system and will create a file /etc/spack/packages.yaml
This step takes a bit of time, and you have the option of avoiding it if you create a file /etc/spack/no_rpm_trigger in your system before installing spack.
How to use spack
Installing spack is very easy, just type:
# zypper install spack
spack will pull a few packages widely used, however is a good idea to install a few more packages used by the spack recipes:
# zypper install patch pcre2-devel gcc-c++
If everything went fine, just typing spack, you’ll get a list of subcommands. You can get a list of the available spack recipes with:
$ spack list
And building and installing a package is straightforward:
$ spack install fdupes
Output will be something like this:
ana@localhost:~> spack install fdupes
==> Warning: Missing a source id for ncurses@6.1.20180317
[+] /usr (external ncurses-6.1.20180317-c4tkkuqm2rejq5ecbotrezyowmtinhtm)
==> Installing fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs
==> No binary for fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs found: installing from source
==> Using cached archive: /var/tmp/ana/spack-cache/_source-cache/archive/cd/cd5cb53b6d898cf20f19b57b81114a5b263cc1149cd0da3104578b083b2837bd.tar.gz
==> fdupes: Executing phase: 'autoreconf'
==> fdupes: Executing phase: 'configure'
==> fdupes: Executing phase: 'build'
==> fdupes: Executing phase: 'install'
[+] /home/ana/spack/packages/linux-opensuse_leap15-skylake/gcc-7.5.0/fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs
Spack will create and install all the files under ~/spack. There will be two directories:
-
modulescontaining the module files to be used with environment-modules or lmod -
packagescontaining
Using the module files with lmod requires updating MODULEPATH like this:
$ export MODULEPATH=$MODULEPATH:~/spack/modules/linux-opensuse_leap15-skylake
$ module available
The second command will show the modules available and it should list all the modules produced by spack in addition to the ones already available in the system. Check the exact path after ~spack to be used in your system.
These modules can be only used by the user who created them. There is the possibility of having all the users from the system able to access and use the module files.
For this, the user who builds the packages, must be able to write a global spack directory under /usr/lib/spack/. This can only be done if the user belongs
to the group spack. You can add the user to this group with the following command:
# usermod -a -G spack <user_login>
then change the setting for install_tree: to the global spack directory in the
configuration ~/.spack/config.yaml for this user.
Finally, an important note. Tumbleweed is a rolling release, do not be surprised if a recipe that works perfectly today doesn’t work in two weeks!
This is a first integration of spack in openSUSE. We aim to improve with your feedback and expand its usage in openSUSE in this wiki page.
Camino a Plasma 5.21 (VI): Plasma Mobile
Finalizo la serie de artículos que nos van a ir informando de las novedades que nos esperan en la nueva versión del escritorio Plasma de la Comunidad KDE. Así que bienvenidos a «Camino a Plasma 5.21 (VI): P(VI): Plasma Mobile» donde hablaremos de las novedades del teléfono móvil con Plasma.
Camino a Plasma 5.21 (VI): Plasma Mobile
Ya ha pasado tiempo desde que el 21 de enero fue lanzado la beta de Plasma 5.21, una versión no apta todavía para el usuario domésticos, y que se libera para ir solucionando errores.
En el artículo del presentación ya hablé por encima de sus novedades pero hoy quiero comentaros más a fondo los progresos del teléfono móvil con Plasma y algunas mejoras en los plasmoides.
Hay que recordar que el escritorio Plasma siempre se ha diseñado para ser flexible con el factor de forma, es decir, adaptable a todo tipo de pantallas. De esta forma puede funcionar en un escritorio, aunque también se adapta fácilmente para trabajar en un dispositivo móvil.

La Comunidad KDE se complace en anunciar que la edición de su PinePhone ya está disponible y comenta que están añadiendo dos nuevos componentes para dispositivos móviles en el lanzamiento oficial de Plasma 5.21.
- Los componentes de teléfono de Plasma contienen la «shell» móvil, pero también «widgets» específicos de Plasma adaptados para Plasma Mobile.
- El estilo QQC2 Brisa es un estilo puro de «Qt Quick Controls 2». Se adapta visualmente al tema Brisa del escritorio basado en «widgets» y se ha optimizado para un menor uso de RAM y de GPU.
Más información: KDE.org
Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.
Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 5.21 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.
Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.
Dementia Friendly Media Player, Arduino Powered
