El coronavirus o COVID-19 nos ha modificado nuestro día a día. Personas que sufren, personas que luchan y personas que nos toca resignarnos, pero ¿podemos hacer algo para luchar contra este virus?

La respuesta es sí. Podemos aportar nuestro granito de arena a intentar ayudar a frenar esta pandemia y este virus. Podemos ayudar a los científicos a encontrar soluciones para este virus (y otros campos de la ciencia)

Podemos “donar” capacidad de cálculo de nuestros equipos informáticos (PC’s, portátiles, etc) ayudando a la ciencia a realizar los cálculos complicados y costosos (en lo que se refiere a tiempo y proceso) que necesita para luchar contra el COVID-19.

La idea es que en los ratos en los que nuestros equipos (o si tenemos varios, dedicar uno a esta tarea) no estén haciendo nada o no les estemos utilizando, hacer que realicen complicados cálculos que los científicos necesitan para sus experimentos y sus descubrimientos.

En resumen, instalamos en nuestro equipo un software, este se conecta a un servidor central, descarga un paquete de operaciones que necesitan hacerse, el software utiliza nuestro equipo para realizarlas y devuelve los resultados al servidor central.

Y así volveríamos a descargar más paquetes si hubiera pendientes, repitiéndose la tarea. Normalmente los científicos utilizan supercomputadoras con capacidad de sobra para esos cálculos, pero el alquiler de esos equipos supongo que sea caro, y siempre está bien distribuir la carga del trabajo a realizar.

Folding@home

En este caso el proyecto Folding@home se dedica a distribuir esa carga de trabajo entre los voluntarios, para realizar los cálculos y simulaciones que necesitan los científicos para su lucha contra el COVID-19.

En la página de Red Hat nos explican cómo contribuir con nuestro equipo al proyecto Folding@home en nuestro sistema GNU/Linux. Hay paquetes .deb y .rpm que podremos instalar en nuestro sistema (dependiendo del sistema de paquetería que utilice)

Existen 3 paquetes a instalar:

• Un cliente que es el que ejecuta las simulaciones y se comunica con el servidor central de Folding@home
• Un control del cliente, que es utilizado para gestionar el procesado del cliente y configurar diversos aspectos de configuración del cliente
• Un visor que sirve para poder visualizar ciertos aspectos del proyecto

En la página de Red Hat están los enlaces a los paquetes a descargar y las instrucciones (en inglés) de cómo participar en el proyecto y aportar con nuestros equipos a la lucha contra el COVID-19 y la investigación científica.

Rosetta@home

Al igual que el anterior proyecto, Rosetta@home, funciona de una forma similar y debido a la crisis de la pandemia del coronavirus, pues también se han puesto “manos a la obra” a realizar simulaciones y realizar cálculos para ayudar a la ciencia sobre cómo parar el COVID-19.

En mi openSUSE, el folding@home no funcionaba, había dependencias que requerían unos paquetes que no están disponibles en openSUSE. Pero sí funciona Rosetta@home

Para ayudar en el proyecto Rosetta@home debes instalarte el software Boinc, algo sobre lo que ya escribió el amigo David aka ochobits en su blog:

• https://www.ochobitshacenunbyte.com/2018/08/13/comparte-el-computo-de-tu-computadora-con-boinc/

En este caso, en vez de escoger la opción del SETI, sería escoger el proyecto Rosetta y crearnos una cuenta y esperar a que el programa reciba datos con los que contribuir.

Yo lo instalé ayer por la noche y dejé el portátil funcionando toda la noche. El equipo sigue funcionando y puedes configurar la cantidad de CPU y de memoria que utilice o decirle cuando puede entrar en funcionamiento.

En mi openSUSE, no terminaba de funcionar, porque no se conectaba con el servidor central, así que explico qué tuve que hacer, suponiendo que ya todo el software está instalado.

1. Comprobar el estado de la tarea con:  systemctl status boinc-client
2. Si está parada, arrancarla con:  systemctl start boinc-client
3. Ir a la ruta /var/lib/boinc
4. Ver el contenido del archivo: sudo cat gui_rpc_auth.cfg
5. Copiar esa clave
6. Abrir el cliente Boinc desde nuestro lanzador de aplicaciones
7. Seleccionar ordenador y en la ventana poner: localhost y en la clave el contenido del archivo gui_rpc_auth.cfg que hemos copiado antes
8. Ya nos dejará abrir un proyecto. Seleccionar Rosetta. Y crear una cuenta con usuario y contraseña.
9. Esperar a que se descargue datos
10. Nuestro equipo realizará los cálculos subiéndolos cuando acabe.
11. Podemos participar en otros proyectos si queremos

Así de simple. Podemos arrancar esta tarea por la noche y dejar nuestro equipo funcionando, o podemos invertir capacidad de proceso de otros equipos que tengamos en casa.

Podemos aportar con nuestro sistema GNU/Linux a la lucha contra este virus.

Y ya sabes, podemos aportar frenando la curva de contagio e impidiendo colapsar la sanidad quedándote en casa, tomando precauciones al salir de casa si no queda más remedio, lavándonos las manos y no apoyando a partidos políticos que quieren desmantelar la sanidad pública y universal, o la educación… como ya hicieron con otros sectores en el pasado.

Abrazos a quienes lo están pasando mal, no por estar en casa, si no por que esta circunstancia les ha tocado más de cerca a seres queridos, o porque ha agravado más su ya difícil situación.

Y por favor, respeta a tus vecinos. No pongas la música a todo volúmen para todo el vecindario, entiende que puede haber personas enfermas, mascotas, u otras circunstancias en las que tu música a todo volúmen sea una gran molestia.

El tiempo pasa y voy poniendo las cosas en orden. Ya he hablado de algunos de los temas pendientes a lo largo de la semana: último y penúltimo podcast de KDE España, del aniversario del blog, la broma del april’s fool day o del nuevo número de SoloLinux. Y al llegar el domingo vuelvo a tener ganas de hablar del último gran proyecto de la Comunidad KDE. Hoy quiero compartir un nuevo vídeo de Plasma Bigscreen, la forma de tener Software KDE en tu televisor.

Nuevo vídeo de Plasma Bigscreen, KDE en tu TV

Al parecer, los desarrolladores le tienen muchas ganas a este Plasma Bigscreen. El lunes de esta semana ya compartí un vídeo de este proyecto pero es que no dejan de aparecer otros que complementan y amplían lo que sabemos del proyecto.

En esta ocasión os comparto un vídeo de LinuxDevHUB donde nos muestra desde la construcción de Plasma Bigscreen a partir de sus componentes, básicamente una Raspberry Pi 4, un micrófono y un teclado/ratón inalábrico, y el Software creado para ello, hasta la configuración del mismo. Evidentemente, se ven imágenes de su funcinamiento.

 

¿Qué es Plasma Bigscreen?

Para resumir, el proyecto tangible de Plasma Bigscreen (y digo tangible porque ya lo puedes tener en tu televisor) es la unión de varias tecnologías libres:

• Las increíbles Raspberry Pi, un proyecto que proporciona el hardware necesario para que funcione el resto del Software. Con menos de 50 € puedes tener tu pequeño PC con el que trastear y conectar donde quieras: un monitor, una pequeña pantalla, un televisor moderno e, incluso, con un televisor con entrada RCA.
• El proyecto MyCroft AI, un software que convierte tu pequeña Raspberry Pi en un asistente de personal controlado por tu voz.
• El Software de la Comunidad, que con su concepción camaleónica y sus propiedades de escalibilidad, se puede adaptar a nuevos formatos de visualización y control.

Oprekan kali ini bermula dari lokasi proyek rumah yang kemalingan. Saat awal bangun, kemalingan genset, berikutnya beberapa minggu lalu, para tukang kemalingan handphone.

Saya memiliki cctv yang ada di rumah, subsidi dari Pak Bos yang memiliki perusahaan penjualan cctv. Yang sudah dipakai, sangat mudah dioperasikan. Just work. Namun kali ini sejak pandemi, saya kepikir untuk memanage cctv tersebut dengan linux, entah raspi atau pakai komputer-komputer spek rendah.

Sebelumnya, saya sama sekali tidak mengerti teknologi cctv beserta perabotannya. Namun sejak ngoprek ini, pengetahuan jadi bertambah. Awalnya hanya tau/nemu Shinobi Video saja, setelah itu bingung, harus bagaimana? cara koneksinya ke cctv bagaimana?

Dinamakan IP Cam, tentunya memiliki IP, umumnya, dari pabrikan diatur menjadi dhcp client. Sehingga dapat IP otomatis dari router/server dhcp. Saya dipinjami IP Cam oleh Pak Iwan Tahari. Dalam kardusnya tidak ada informasi apapun (buku manual juga tidak ada). Merek/Pabrikan pembuatnya juga tidak tahu. Jadi dengan coba-coba colokin aja ke router/modem yang ada di rumah, lalu diintip dapat IP berapa, nah itu dia tinggal dipanggil IPnya di peramban.

Setelah sukses dapat IP, saya punya 1 komputer yang rencananya jadi server cctv dan sudah ada dhcp servernya, saya sambungkan IP Cam tersebut ke komputer . Dapat IP 10.42.0.151. Tinggal dipanggil di peramban dan muncul antar muka web si kamera.

Hal utama yang perlu dilakukan adala mengatur zona waktu/waktu, agar nantinya saat dipakai, timestamp yang ditampilkan sesuai. Hal berikutnya adalah pengaturan kualitas gambar. Kamera ini sanggup merekam video/gambar dengan codec H265 dan H264, juga bisa merekam audio serta pengaturan fps dan kualitas. Saya mengatur kualitas medium dan codec H264 (karena H265, rata-rata browser tidak mulus menampilkannya).

Selanjutnya, bagaimana cara menguji bahwa kamera tersebut bisa digunakan? Saya cukup bingung dengan pertanyaan sendiri. Mencari-cari, akhirnya menemukan jawaban, bahwa bisa menguji dengan menggunakan VLC. Tinggal memasukkan url rtp/udp melalui menu Open Network. Nah bagaimana mendapatkan urlnya? macem-macem jawabnya dan bingung. Namun saya menemukan aplikasi pembantu, yang bisa memandu kita.

Aplikasinya bernama iSpy, opensource, adanya di OS Windows saja. Cara penggunaannya cukup mudah, bisa mencari berdasarkan IP yang kita masukkan atau dia mencari melalui jaringan yang ada. Setelah itu dia akan memberikan info ke kita daftar url yang bisa digunakan.

Ada beberapa format yang perlu diperhatikan:

• ONVIF, ini format standar IP Cam, jika bisa ini, dengan Shinobi bisa otomatis dalam pendeteksiannya.
• RTSP, catat url rtsp yang diberikan, di atas contohnya rtsp://ip:8554/live/ch00_0

Setelah sukses tampil di VLC, kita bisa melanjutkan pemasangan Shinobi Video.

He estado dudando sobre hacer esta entrada o no. Y es que en realidad esta efeméride ocurrió en pleno inicio del confinamiento por el COVID-19 y uno estaba pendiente de otras cosas.  Pero al final, la parte metódica de mi cerebro se ha impuesto y ha pensado que estaría feo perder la costumbre de ir celebrando cosas positivas. El pasado 24 de marzo de 2020 KDE Blog cumplió 12 años y no me acordé de comentarlo hasta unos días después. Es hora de enmendar este despiste.

KDE Blog cumplió 12 años

Hace más de una 10 años decidí que una parte de mi vida se iba a dedicar a intentar ayudar a los demás en su camino hacía el Software Libre. No sabía programar y me venía muy grande el diseño o la traducción, así que decidí que haría lo mejor que sabía hacer: enseñar.

Para ello pensé que escribir un blog donde explicaría mis vicisitudes en este nuevo escritorio GNU/Linux… en mi cabeza el concepto de Comunidad no estaba ni en pensamiento, los conceptos de distribución, kernel, aplicación, Comunidad, Release Candidate, Beta y cientos  más se mezclaban en mi cabeza, de tal forma que los errores que cometí fueron apoteósicos, … pero nadie murió por ello y me sirvió para ir creciendo y aprendiendo.

En un momento puntual me ayudaron muchas personas, pero recuerdo con mucho cariño el capote que me ofreció maslinux cuando cometí un desliz sin mala intenciones y se me echó encima toda una comunidad de usuarios de una web potente de la época. Muchas gracias Pedro.

Como es habitual, me gusta recordar la declaración de intenciones de KDE Blog:

[24 de marzo de 2008]
«Hola a todos y todas: Hoy se inaugura KDE Blog un nuevo blog en el inmenso e infinito mundo de los blogs. El objetivo de este blog es múltiple: ayudar a los principiantes en el mundo Linux, informar sobre el mundo KDE, (el entorno de escritorio bajo Linux) y fomentar el uso del Software Libre.»

A pesar de la doce años pasados, la idea principal sigue válida aunque los artículos van cambiando de temática porque cada vez es más difícil hacer entradas explicando cómo hacer las cosas o solucionar problemas.

Y es que cada vez más gente utiliza GNU/Linux y el Software Libre cada vez tiene una alta calidad (está a la altura del privativo en muchos aspectos) aunque sigo opinando que el gran salto solo se dará cuando los dispositivos que compre la gente ofrezcan GNU/Linux por defecto.

Mientras tanto, el KDE Blog blog seguirá siendo mi granito de arena en la promoción del Software Libre y de la Comunidad KDE. No quisiera acabar esta parte sin dar las gracias públicamente a Victorhck que nada más enterarse de que el blog estaba de aniversario decidió dedicarme un artículo en su gran blog: Victorhck in the Free World. Estas cosas son el verdadero combustible del blog.

Los años siguen siendo complicados pero se mantienen las entradas diarias

Igual que el año pasado, mis obligaciones familiares, académicas y laborales me dejan poco tiempos para poder dedicarlo al blog. Por tanto debo estar muy atento a todo el tiempo que dispongo para poder publicar de forma diaria.

En otras palabras, debo pensar qué momento dispondré a lo largo del día para poder escribir artículos y, si algún día me encuentro más libre, dejar algunos en la recámara por los días en los que no los tendré.

No obstante, aunque sigo publicando de forma diaria sin demasiadas dificultades he debido sacrificar mis otras labores adquiridas con el mundo del Software Libre.

• Sigo en la junta de KDE España como secretario.
• Gracias a cambios de última hora, he vuelto a participar en los podcast de KDE España de forma directa, y sigo encargado de anunciarlos y preparar los directos, aunque pronto tendremos ayuda para mejorarlos.
• Sigo atento en el Grupo de Telegram de Cañas y Bravas (en el que hemos perdido algo de presencia por limpieza de bots que se colaron. ¡Somos más de 500  pero sigues faltando tú!).
• Y me encargo, con menor intensidad de la deseada, de las redes sociales de la organización.

 

A lo largo de estos 12 años he ido publicando entradas conmemorativas que podéis seguir en la siguiente etiqueta, en las cuales se resumen muy bien los sentimientos y la historia del blog, y como este año no tengo tiempo y apenas han cambiado os invito a leer para no repetirlo.

Renovación de votos

Los votos no cambian, al parecer he llegado a un momento de estabilidad, y mi compromisos con la Comunidad KDE se mantienen:

• KDE Blog sigue teniendo cuerda para muchos años,
• Sigo estando ilusionado con el proyecto KDE y en su difusión.
  
• Sigo abierto a todo tipo de colaboraciones (¿quieres ayudar a publicar en el blog? ¿Encargarte de la parte social? ¿Mejorar las entradas? Mándame un correo [bortega@kde_espana.org] y hablamos)
• Y para finalizar decir que me siento orgulloso de pertenecer a un movimiento cuyo objetivo es compartir su conocimiento en pro de una evolución más rápida de la humanidad, que se concreta en pertenecer a una Asociación de Software Libre como KDE España.

Así que:

¡Muchísimas gracias a todos por seguirme!

Another four openSUSE Tumbleweed snapshots were released this week.

A notable package updated this week is a new major version of gucharmap. Plus several python package updates, nano, mesa, git and Xfce packages also had new minor updates.

The most recent snapshot, 202000331 is trending well with a stable rating of 99 on the Tumbleweed snapshot reviewer. The GNOME Character Map, gucharmap, updated to version 13.0.0, but no changelog was provided. An update for glib2 2.62.6 is expected to be the final release of the stable 2.62.x series; maintenance efforts will be shifted to the newer 2.64.x series. The updated glib2 package fixed SOCKS5 username/password authentication. The 2.34 binutils package added and removed a few patches. GTK3 3.24.16 fixed problems with clipboard handling and fixed a crash in the Wayland input method. The package for creating business diagrams, kdiagram 2.6.2 fixed printing issue. The Linux Kernel updated to 5.5.13. A handful of Advanced Linux Sound Architecture changes were made in the kernel update. The 5.6.x kernel is expected to be released in a Tumbleweed snapshot soon. The libstorage-ng 4.2.71 package simplified combining disks with different block sizes into RAID. The programming language vala 0.46.7 made verious improvements and bug fixes and properly set CodeNode.error when reporting an error. Several xfce4 packages were updated and xfce4-pulseaudio-plugin 0.4.3 fixed various memory leaks and warnings and xterm 353 was updated. The yast2-firewall 4.2.4 packaged was updated and forces a reset of the firewalld API instance after modifying the service state and yast2-storage-ng 4.2.104 extended and improved the Application Programming Interface to get udev names for a block device

The package to improve audio and video under Linux pipewire 0.3.1 switched the license to MIT and added fdupes BuildRequires and pass fdupes macro while removing duplicate files, which came in snapshot 20200326. The 1.1.9 spec-cleaner package drop travis and tox and now uses github actions. Several python arrived in this snapshot. Python-packaging 20.3 fixed a bug that caused a 32-bit OS that runs on a 64-bit ARM CPU (e.g. ARM-v8, aarch64), to report the wrong bitness and python-SQLAlchemy 1.3.15 fixed regression in 1.3.14. The Xfce file manager package, thunar 1.8.14 updated translations and reverted a bug that introduced a regression. The snapshot recorded a stable rating of 99.

A stable rating of 97 was recorded for snapshot 20200325. The snapshot updated ImageMagick to version 7.0.10.2 and fixed another sizing issue with the label coder when pointsize is set. Mesa 20.0.2 provided several fixes for the code base. Bluetooth issues were fixed with the class UUID matches before connecting the profile in the bluez 5.54 package. Git 2.26.0 improved the handling of sparse checkouts. Text editor nano 4.9 made the new paragraph and the succeeding one get the appropriate first-line indent when justifying a selection. The latest stable version of the in-memory database redis 5.0.8 uses the tmpfiles macros instead of calling systemd-tempfiles direct and build wrong macro paths and the sssd 2.2.3 package brought new features like a “soft_ocsp” and “soft_crl” options that were added to make the checks for revoked certificates more flexible if the system is offline.

The 20200324 snapshot recorded a stable 93 rating. The snapshot also had an update for ImageMagick and an updated version of Mozilla Thunderbird 68.6.0. The email client adds a new popup display window when starting up on a new profile. A fix for the linker version script was made in FUSE (Filesystem in Userspace) 3.9.1, which provides a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. The lensfun package jumped from version 0.3.2 to 0.3.95 and provides support for several next cameras and lenses. Other packages updated in the snapshot were mercurial 5.3.1, php7 7.4.4 and zypper 1.14.35.

Systemd 245 is expected to arrive in a snapshot in the coming days.

Announcement

The Kubic Project is proud to announce that Snapshot 20200331 has been released containing Kubernetes 1.18.0.

Release Notes are avaialble HERE.

Upgrade Steps

All newly deployed Kubic clusters will automatically be Kubernetes 1.18.0 from this point.

For existing clusters, please follow our new documentation our wiki HERE

Thanks and have a lot of fun!

The Kubic Team

Hora de promocionarlo un poco y leerla con detenimiento. Me congratula compartir que ya está disponible el decimocarto número d la revista digital SoloLinux,  suma y sigue con este interesante proyecto ¿alguien se anima a hacer lo mismo con KDE Blog?

Disponible el decimocuarto número de la revista digital SoloLinux

Hubo un tiempo en que las revistas sobre Linux digitales estuvieron de moda en el blog. Tenemos todavía a Atix, que continua con sus publicaciones (lo cual me alegra) y Full Circle Magazine (en inglés, gracias Vampiro Nocturno), y antes teníamos a Linux+, Papirux, Begins o TuxInfo, por citar algunas discontinuadas.

Desde hace un tiempo una revista digital SoloLinux tiene su entrada mensual en el blog, tener todas las alternativas posibles para compartir conocimiento es algo que caracteriza al Conocimiento Libre.

Este número, como no podía ser de otra forma, viene con unas palabras de sus creadores que me gustaría transmitir:

«Día uno de abril del 2020 ya estamos aquí otra vez. A pesar de la grave crisis mundial por culpa de la pandemia COVID-19, no podíamos fallar a nuestros lectores.

Ahora menos que nunca, ya que muchos permanecéis confinados en vuestras casas, por lo menos tratamos entre todos de mantenernos activos mentalmente.

[…]

Lamentablemente, la mayoría de nuestros proyectos los hemos tenido que paralizar. Demasiadas preocupaciones por nuestras familias, en fin… todos sabemos cómo está el tema ahora mismo. Cuando esto pase, porque seguro que pasará, retomaremos los nuevos proyectos. Antes de presentar la revista una recomendación, por favor proteger a nuestros mayores, somos lo que somos gracias a ellos.»

Así que, ya tenemos disponible el decimocuarto número de la revistas digital SoloLinux, el cual llega cargado de contenidos y con el siguiente índice.

La revista puede ser descargada o simplemente visualizarla en línea, ya que se cuelga en diferente servicios como Calameo. A continuación os dejo los enlaces de descarga y visualización directa de los cuatro primeros números.

Además, recordar que desde el número anterior se ha abierto el canal oficial sololinux.es de Telegram: https://t.me/sololinux_es

Evidentemente, este proyecto no se centra en exclusivo a los contenidos de su web y está abierto a colaboraciones de todo tipo. De esta forma si estas interesado en insertar publicidad en nuestra revista, o quieres que publiquemos algún articulo que hayas escrito tu mismo, puedes contactar con «Adrián» por correo electrónico.

Muchos ánimos en este nuevo proyecto ya que facilita la difusión del Software Libre de una forma que ya no es tan habitual en estos tiempos pero que es igual de válida.

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• http://dominique.leuenberger.net/blog/2020/04/opensuse-tumbleweed-review-of-the-week-2020-14/

La semana empezó con problemas dentro de openSUSE Tumbleweed distribution, aunque fueron vistos a tiempo por openQA, por lo que no hay que preocuparse. Y acaba todavía peor: hay ciertos problemas en openQA desde el jueves y muchos test están fallando.

Los fallos parece que están más relacionados con la propia infraestructura de openQA y no con openSUSE Tumbleweed. Sin embargo no publicaremos nuevas “snapshots” hasta que openQA se comporte de nuevo de manera estable.

Durante esta semana se han publicado únicamente dos “snapshots”: 0326 y 0331.

Algunas de las actualizaciones más reseñables son:

• Kubernetes 1.18.0
• Linux kernel 5.5.13
• Rust 1.41.1
• XFCE 4.14.2

Y como siempre hay muchas más cosas interesantes que próximamente llegarán a los repositorios

• KDE Plasma 5.18.4.1
• Linux kernel 5.6.0
• Systemd 245: homed no estará habilitado/ofrecido
• Poppler 0.86.1
• GNOME 3.34.5: la última versión estable de la rama 3.34 branch; esto supuestamente todavía está en Leap 15.2 (via SLE). Después de esto, el equipo puede centrar sus esfuerzos en GNOME 3.36.x;
• GNU Make 4.3
• Guile 3.0.2
• LLVM 10
• Qt 5.15.0
• Ruby 2.7: posiblemente junto con la eliminación de Ruby 2.6
• GCC 10 como compilador de la distro
• Eliminación de Python 2

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

The week started with problems inside the openSUSE Tumbleweed distribution (caught by QA, so no worries) and ended even worse: we have some trouble on openQA since Thursday and many tests are failing. The failures seem more to be related to openQA’s infrastructure though, and not to openSUSE Tumbleweed. Nevertheless, we will not publish new snapshots until QA is stable again. During this week we have thus only released two snapshots: 0326 and 0331 (promised, no joke).

The snapshots contained these updates:

• Kubernetes 1.18.0
• Linux kernel 5.5.13
• Rust 1.41.1
• XFCE 4.14.2

The things being worked on are

• KDE Plasma 5.18.4.1
• Linux kernel 5.6.0
• Systemd 245: homed will not be enabled/offered just yet
• Poppler 0.86.1
• GNOME 3.34.5: last stable version from the 3.34 branch; this supposedly still gets into Leap 15.2 (via SLE). After this, the team can start focusing on GNOME 3.36.x; a maintained mozjs68 package is the main blocker on this path though
• GNU Make 4.3: missing only a fix for daps
• Guile 3.0.2: breaks gnutls’ test suite on i586
• LLVM 10
• Qt 5.15.0 (currently beta2 being tested)
• Ruby 2.7 – possibly paired with the removal of Ruby 2.6
• GCC 10 as the default compiler
• Removal of Python 2: quite some progress done, but not fully there yet

Sometimes error messages can result in more scared than they are, especially those strictly related to the boot loading. In that situation, when the error message is not much clear, we wrongly assume that a clean reinstallation is the only solution.