openSUSE Tumbleweed revisión semana 49 de 2016

openSUSE Tumbleweed es una distribución “Rolling Release” en desarrollo continuo. Aqui puedes estar al tanto de las últimas novedades.

Tumbleweed

Hoy viernes y a punto de empezar el fin de semana de nuevo puedes leer una nueva revisión de lo que ha acontecido esta semana en openSUSE Tumbleweed la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, en este enlace:

Las ISO’s son instalables, pero si ya estás disfrutando de openSUSE Tumbleweed en tu equipo, simplemente deberás actualizarlo mediante “zypper up” para disfrutar de esas actualizaciones.

Tumbleweed se supera cada día más. Si la semana pasada se publicaron 7 snapshots, en esta han batido su propio récord y se han publicado 8 snapshots. Veremos en este repaso las actualizaciones más importantes en las snapshots que van desde la 1201 hasta la 1208. Empezamos.

  • Linux Kernel 4.8.12
  • Kernel Firmware 20161130
  • Mesa 13.0.2
  • Más controladores actualizados para X.org 1.19.0
  • Emacs 25.1 – ahora con soporte para webkit
  • Preparativos para systemd 232 GTK 4

Además de todo esta para las próximas publicaciones se está preparando lo siguiente:

  • X.org 1.19.0 – Hay algunos problemas a la hora de cambiar entre texto e interfaz gráfica
  • Systemd 232
  • GTK 4.0 (3.89.0).
  • krb5 1.15
  • Linux Kernel 4.8.13 (or o más actual)
  • KDE Applications 16.12.0

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

Geeko_ascii

——————————–

21 pensamientos en “openSUSE Tumbleweed revisión semana 49 de 2016

  1. Buenas Victor. Cuando nos dices que si hemos detectado algún problema lo pongamos en conocimiento de Suse ¿donde exactamente?. Es que los dos últimos kernels de la Tumbleweed me dan el mismo problema, y sigo con el 4.8.10 que no me lo da.

    Lo comento por si a alguien mas le pasa:
    Yo uso los drivers propietarios de Nvidia (tengo una GT440). Siempre que hay alguna actualización del kernel, Xorg o Mesa el equipo “pierde” el entorno gráfico y se inicia en consola.
    Nada grave, normalmente, entro como root y vuelvo a instalar el driver. Pero en los dos últimos kernels al quedarse en modo consola se queda con el foco intermitente… es como si perdiera el foco, así que cuando intento entrar como root directamente no soy capaz siquiera de escribir ‘root’. Y las pocas veces que lo consigo, como para poner la contraseña con esas “perdidas del foco” que hacen que no sepa si la tecla pulsada ha sido “recogida” por el sistema. Así que me dice que la contraseña es incorrecta, seguramente porque no ha registrado todas las pulsaciones.

    En fin, espero que en el próximo kernel no me pase. Por ahora me pasa con el 4.8.11 y el 4.8.12.

    • Hola!
      Habría que reportar esos errores en la lista de correo de factory, o quizás abrir un bug en bugzilla.
      Yo empezaría por lo primero, la leen muchos desarrolladores y empaquetadores de openSUSE y quizás puedan aconsejarte o decirte cual es el problema…

      No entiendo bien eso de “perder el foco” y veo que es un problema molesto y grave…
      Los drivers privativos y Tumbleweed no se llevan muy bien (creo…)

      Espero que se resuelva pronto tu problema…

      Saludos.

    • Se me ocurre que desde el menú de boteo le pases el parametro para que inicie en el runlevel 3; luego recompilas el driver como venias haciendo y reiniciar.
      Saludos.

      • Al no tener los drivers gráficos operativos, al iniciarse el sistema se queda en level 3. El problema es que la consola se queda “intermitente”. He probado con otras consolas y en todas pasa lo mismo. La pantalla parpadea, pero no solo es eso, es que no capta las pulsaciones de teclado.

      • Feliz de haber contribuido con la solución; también es válido para leap 42.2 cuando sabes que viene con xorg 1.18 pero por testarudo le activas igual el repositorio fglrx esperando el milagro que te funcionen los drivers privativos de AMD; luego de reiniciar ocurre lo mismo jajaja.
        Saludos.

    • Me paso lo mismo hace unas semanas con los drivers privativos de una GeForce 9800 de una de las pc de mi casa; y así lo solucione; pero me daba pereza estar recompilando cuando se actualiza el kernel así que esa pc la deje con leap 42.2; el “cambio de foco” es que en realidad el sistema intenta entrar en el runlevel 5; encuentra problemas vuelve al 3 luego intenta nuevamente; por eso te digo que desde el menú de boteo presiones f2 o la letra e no lo recuerdo bien y edites para que entre en en el 3.
      Saludos.

      • Ok. Voy a probar ahora mismo. En breve digo si era eso lo que me pasaba. Muchas gracias (cruzando los dedos…)

      • Efectivamente, minipunto o gallifante para ti cuoco. Era eso. Lo curioso del caso es que antes no actuaba así, si no podía cargar las X tras algún intento, pues no las cargaba y punto. Ahora entra en un bucle infinito de reintentos por cargarlas bloqueando el equipo. Pero sabiendo lo que es, la solución es la que me das, decirle en el arranque que no las cargue. Es con la letra ‘e’ como también indicas. Muchas gracias.

      • Vaya me alegro que el blog sea punto de encuentro y de resolución de problemas con openSUSE!! 🙂
        Adjudicado el minipunto o gallifante (somos ya mayores para haber conocido eso… 😉 ) para Cuoco!! 😉

  2. Tengo un ssd, lo quiero para la instalación de Tumbleweed.
    He leído en algunos blogs sobre la conveniencia de tener la carpeta de archivos temporales (TEMP) en un hdd para extender su vida útil.
    Como soy newbie en esto de opensuse y otras yerbas,
    pregunto si en este sistema operativo hay una carpeta con iguales características
    y como hacerlo. Gracias.

    • Hola!
      No tengo discos SSD así que no me he preocupado de leer al respecto.
      Lo que sí me suena es eso que dices, claro que en openSUSE existe una carpeta /tmp
      No sabría qué más recomendaciones darte….

      Saludos.

  3. Estoy viendo que el cambio a Ruby en YaST ha traído un cantidad enorme de errores. Quizá fuera necesario reescribir este apartado de la distribución para adaptarlo a las nuevas tecnologías pero, cosas tan simples como gestionar la red se ha vuelto imposible y este tipo de cosas que debería funcionar con normalidad y así lo hacía en el pasado, le hacen un feo tremendo al camaleón.

    • Hola!
      Yo no he notado errores en YaST, después de cambio a Ruby… Además el cambio se produjo ya hace tiempo, y últimamente los desarrolladores de YaST están haciendo muchas mejoras.
      YaST es también una herramienta de SUSE, por lo que no creo que permitan errores en la herramienta por excelencia que distribuyen en sus versiones empresariales…
      ¿A qué errores te refieres exactamente?

      Saludos!

  4. Si no te has topado con errores en YaST puede que sea porque no te has movido fuera de la configuración por defecto. Simplemente, no podía configurar la IP estática durante días; hoy ya ha llegado el parche.
    Son cosas demasiado básicas para que fallen. Exactamente, por el hecho de que ya tiene tiempo el paso a Ruby me sorprende este tipo de errores y dudo legítimamente sobre la calidad de openQA. Too big to fail. Demasiado grande para no darse cuenta. Lo mismo para la versión ncurses: inutilizable. Me quedo con el culo torcido.

    Un ejemplo:

    https://bugzilla.suse.com/buglist.cgi?no_redirect=1&quicksearch=description%3ALanItems.rb+status%3Asolved

    What’s a pitty.

    Regards!

    • Los errores que mencionas en yast2-network no tienen nada que ver con el cambio a Ruby. Tienen que ver con cambios que se han realizado posteriormente.

      Desgraciadamente, algunas partes de yast2-network son bastante frágiles. En su día (aún en los tiempos de YCP) los desarrolladores originales no hicieron el mejor trabajo del mundo asegurando que el impacto de los cambios futuros fuera local. Eso está más relacionado con la estructura del código que con el lenguaje. Actualmente se está evaluando si vale la pena reescribir toda esa parte de forma que cada cambio en A no rompa B.

      En cualquier caso, lo dicho: hubiera pasado igual con o sin la conversión. Es una cuestión de “deuda tecnológica”. 🙂 La única forma de no romper esa parte a día de hoy es no tocarla… y eso no es la mejor opción.

      • Parece que se borraron algunos comentarios así que hago una breve misiva volviendo a agradecer a Ancor su paso por aquí a explicar la situación y añadir un voto de confianza a openQA pues. 😉

      • Borré un comentario repetido de Ancor… (creo no haber borrado algo más!)
        Es una suerte contar con desarrolladores de primera mano que hablen español!! 🙂
        Saludos.

  5. Muchas gracias Ancor por aportar información de primera mano con esto (es uno de los desarrolladores que trabajan en YaST, y muchos otros proyectos, dentro de SUSE)

    Saludos!! 😉

  6. Hi Ancor!

    Entiendo la situación y sin ser experto en Ruby, el error “undefined method empty for nil:NilClass” en LanItems.rb parecía totalmente un error de codificación. De cualquier manera estos errores son bastante indeseables en algo que ya funcionaba. Esperemos que todo sea para mejor.

    Gracias por arrojar luz sobre el asunto. :^)

Me gustaría saber tu opinión. Deja un comentario (Puedes usar MarkDown)

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s