Actualización con FedUp. Espacio en las particiones

En este caso describo los problemas que he tenido en un portátil. Este ordenador tiene instalados Windows 7 y Fedora.

Debido a que ya tiene unos años, el disco duro es un TOSHIBA MK3263GSX de 320GB, dividido en 5 particiones. Las dos primeras sda1 y sda2 son las originales del sistema que venían de fábrica (sda1 NTFS de 500MB de reparación para Windows y sda2 donde viene instalado Windows 7). Sobre esa sda2 extraje un espacio vacío que he rellenado con una partición (sda3 NTFS) para datos de Windows, y la extendida sd5 (ext4) para /, sd7 (ext4) para /home y sd6 swap.
El problema generado en la actualización surgió del hecho de que sd5 / nació siendo de 14GB. Siempre fueron suficientes estos GB para sistema; sin embargo la carga de los paquees necesarios para actualizarse, más el espacio necesario para instalarlos antes de borrar los anteriores significo la falta absoluta de espacio, con el mensaje de que eran necesarios 2GB libres más en sd5. Es decir, los 34GB que se ven en la imagen fueron gestionados por gparted live, instalado a través de unetbootin en un dispositivo USB.
Conclusión: antes de empezar con FedUp, comprueben que tienen libres más de 5GB en /, por que si no tendrán que generarlos antes de la actualización.

PD. Sí, la alteración gráfica de las particiones no ha  sido perfecta y deja rastros, como esas zonas vacías sin uso. Sí, también en Windows, por que aproveché para aumentar c:\.

PDD. Si, llevo un rato bastante largo

Formatos propietarios imposibles de abrir. CPT

Con los programas comerciales hemos topado. En ocasiones he comentado los cientos (o miles, que no nos vamos a poner a contar ahora) de gráficas realizadas en Harvard Graphics hasta el año 1995 (y unas cuantas decenas de presentaciones en las últimas versiones) que somos incapaces de abrir hoy en día. En este caso no encontramos posibilidad alguna, ni siquiera en Windows y programas comerciales.
Bien, en esta última semana hemos encontrado un segundo caso de dependencias rotas. En la época de PhotoShop 2.5 (ya llovió y nevó) éramos incapaces de imprimir de forma adecuada las fotos editadas con ese software con el hardware del que disponíamos. Por esa razón comenzamos a utilizar PhotoPaint, del que disponíamos como añadido de Corel Draw 3 (lo incluían como un plus en el paquete). Ese inicio por necesidad se acabó convirtiendo en una costumbre, y como siempre venía añadido en el paquete Corel, seguimos usándolo hasta que nos pasamos a software libre (unos 17 años). Y esta pequeña introducción, ¿dónde nos lleva?
Nos lleva a cientos de fotos editadas en formato cpt que no somos capaces de abrir. En concreto esta semana he necesitado una y no he sido capaz de encontrar un paquete que sea capaz de abrir o importar un fichero cpt. La lista ha sido:
- GIMP
- convert de image magick en terminal
- image magick a través de gthumb (GUI)
- Krita
- irfanview a través de wine
- XnConvert, versión de Windows a través de wine, ya que la versión de linux mostró varios errores en su instalación y no pudo terminarse.

http://pixabay.com/en/chains-lock-doors-protection-23041/

No profundicé más, entre otras cosas por que no tenía tiempo, y preferí ir al material y hacerlas de nuevo. De todas maneras es una asignatura pendiente, por que como ya dije disponemos de mucho material en cpt. Obviamente, no estamos en un caso tan grave como Harvard Graphics. Llegado el caso sería posible adquirir una licencia de Paint Shop Pro a Corel o una versión de prueba y convertir las imágenes en una orden bash (o como sea posible) para recuperarlas, aunque está posibilidad no es segura (ver aquí) .

COROLARIO: el que con software propietario se acuesta...

Fedora 21 a través de FedUp. Solución para las "broken dependencies"

Como había señalado en la entrada anterior, la actualización por FedUp había funcionado "casi" perfectamente, y que en la propia actualización, antes de empezar la sustitución de paquetes, la aplicación avisaba de cuáles presentan dependencias rotas, con el desalentador aviso de que instalásemos bajo nuestra responsabilidad ("Continue with the upgrade at your own risk").
A pesar de ello, todo va como la seda... hasta que llamas a uno de esos paquetes, en mi caso R, que es parte intrínseca de mi trabajo. La respuesta es:

Es decir, hemos tropezado con la dependencia rota.

Para solucionarlo simplemento desinstalé a través de yumex (YumExtender) R (R-core, R-core-devel, R-devel, R-java-devel) y luego reinstalé con yum

su -c 'yum install R-core R-devel' # suficiente; los otros son dependencias

Y con eso ya funcionaba. Eso sí, en vez de ser la versión 3.1.2 "Pumpkin Helmet" que ya estaba instalada en Fedora 20, la que está ahora es la 3.1.1 "Sock it to Me".

Es decir, la preparación de Fedora 21 quedó congelada antes de alguna de las actualizaciones de Fedora 20 y hay alguna "regresión" de versión.

Este problema solo me ha aparecido en R, Virtual Manager (virt-manager) y HandBrake. Los dos primeros se han corregido de la misma manera (desinstalación y vuelta a instalar) y handbrake no lo he necesitado, así que no lo he vuelto a instalar (aun).

Y de todas maneras dos días después ya se ha actualizado R a 3.1.2. en Fedora 21.

Fedora 21. Actualizacion con FedUp

Aunque el trabajo no nos da tregua, aproveché unos milisegundos libres para actualizar Fedora a su versión 21. Hay razones varias, Gnome 3.14, Libreoffice 4.3 y muchas más, pero la más importante era comprobar que mi ordenador principal funcionaba correctamente con gnome y podía dejar KDE. Para acelerar las cosas y consumir el menor tiempo posible decidí usar fedup. Y esta vez, de lo más sencillo, siguiendo las recomendaciones de Fedora:

1. Actualización completa de sistema

su -c 'yum -y update'

2. Instalación de Fedup

su -c 'yum install fedup'

3. Comprobar que no queda nada sin actualizar

su -c 'yum update fedup fedora-release'

que en todos los casos ha dado que no quedaba nado por actualizar

4. Preparación de la actualización

sudo fedup --network 21 --product=workstation

En mi caso es workstation, aunque hay otras dos posibilidades, según sea la función del ordenador actualizado (server, cloud). Eso supone la bajada de los paquetes nuevos a actualizar (en mi caso, entre 2570 a 2685, según máquina, entre 2,4 a 2,5GB). En función de la red disponible, supone 8-15 minutos a varias horas.

Aquí llegan los avisos de posibles errores, por ejemplo en este ordenador en concreto fueron dependencias de handbrake-gui, icedtea-web y R-core

Lo mejor es el mensaje

Continue with the upgrade at your own risk

Una vez terminada la descarga, al reiniciar se ejecuta fedup y comienza la instalación de los nuevos paquetes y luego limpieza del sistema. Según la potencia del ordenador (de los que yo he probado), entre 30 minutos a 1 hora.
El resultado ha sido Fedora 21 funcionando, salvo algunos detalles que ya nos había avisado el sistema(R, handbrake).

Para terminar, habilitar el plugin "Gnome Shell Integration" de Firefox

para poder manipular las extensiones de Gnome shell y actualizarlas.

Finalmente nos queda el problema de que, de nuevo, no esta activo el repositorio de Dropbox, lo que impide la actualización del sistema.

Para solucionarlo, el arreglo que hacíamos siempre no ha funcionado, pero siguiendo las instrucciones de la página de los repositorios adicionales de Fedora hemos podido lograr que no tenga en cuenta el repositorio cuando no esta disponible y nos permita actualizar sin problemas. Para ello editamos dropbox.repo

su -c 'nano -$ /etc/yum.repos.d/dropbox.repo'

y añadimos las 3 últimas líneas

enabled=1
skip_if_unavailable=1
gpgcheck=1

Listo. Reinicio y Fedora 21 en marcha.

PD. Y sí, ¡gnome funciona en mi ordenador principal!

Nexus 4 y Android 5.0 Lollipop

Hablemos hoy de albañilería; sí, cuestión de cal y arena. Tengo que reconocer que mi móvil presenta una doble personalidad; desde que lo tengo, a veces ha sido Dr Jekyll, funcionando perfectamente como teléfono, con una pantalla de un tamaño lo suficientemente grande para poder leer libros y comics, pero suficientemente pequeño para llevarlo en el bolsillo del pantalón...

Sin embargo, en ocasiones saca su Mr Hyde; en primer lugar, debido a que no tiene una entrada para una micro SD y que internamente solo dispone de 8GB totales, de los que quedan libres para almacenamiento 5,8, de vez en cuando hay que liberar espacio, en general borrando fotos y vídeos. En segundo lugar, no es tan sólido como parece, y a veces su Gorila glass se hace "quebradizo".
Además, en un artículo de la revista Android Magazine nº 36 sobre Android 5 Lollipop aparecía la actualización del Nexus 4 solo como probable.

Teniendo en cuenta esta parte Mr Hyde dentro de sus características, y la posibilidad de que no se actualizara a Android 5 estaba pensando cambiar de terminal, poniendo como opciones LG G3 o MOTO X.

Sin embargo la tarde del 25 de noviembre apareció el mensaje de actualización. En principio debería descargar 394MB y eran precisos 500 MB libres. Sin embargo, solo admitió la descarga tras haber dejado libres más de 2GB. Después la descarga e instalación se hizo rápida y suavemente, un reinicio y... LISTO.
Por ahora todo bien, pero eso será otra historia.

Se acerca Fedora 21

Como se ve en el avisador de la derecha, se acerca Fedora 21; ¡qué son 19 días! La verdad es que el día 4 ya se había liberado la versión beta. De manera egoista, jamás he probado una versión beta, entre otras cosas por que Linux también es mi sistema en el trabajo, y en mi ordenador personal guardo la copia maestra de todo.  aun así, tengo ganas de que llegue la nueva versión, y ver también el nuevo gnome.
Es una semana de novedades; ya tenemos el kernel 3.17, acaba de actualizarse R a la versión 3.1.2 y se acerca Fedora 21. Perfecto.

Extracción de imágenes desde un vídeo mkv

Recordemos ese vídeo que extraímos hace unos días de un DVD y convertimos en mkv utilizando de Handbrake, y que luego recortamos mediante avidemux. De ese vídeo me han preguntado si era capaz de extraer unas imágenes en jpg para utilizarlas individualmente sin tener que incluir un vídeo. Por supuesto dije que sí. Luego estuve valorando las diferentes posibilidades.
Primera, avidemux, pero no descubrí la forma de extraer imágenes fuera de ir pidiendo de una en una (File -> Save image). Siempre es mejor sacar tiras completas para escoger la que nos de la mejor visualización.
Segunda opción por mi conocida; si disponemos de un vídeo con formato adecuado para él, VirtualDub nos convierte un vídeo en una tira de imágenes en milésimas de segundo. Aunque es una aplicación pensada para windows, podemos utilizarla en Linux, por que VirtualDub funciona perfectamente por wine. El problema es que nos exigiría una codificación más, ya que VirtualDub solo admite "Video for Windows (VFW) compatible codec..."

y es preferible evitarlo, ya que HandBrake ya lo ha recodificado una vez, y ahora otra más siempre genera pérdida de calidad; eso sin olvidar de que para convertirla a imagen JPG se va a recodificar otra.

Tercera, y más sencilla y adecuada, ffmpeg. En concreto en sus FAQ encontramos la instrucción básica

ffmpeg -i movie.mkv movie%d.jpg

Perfecto. El único problema es que el vídeo dura 1 hora y 5 minutos y solo se necesitan para lo que queremos 13 segundos. La orden directamente sobre el vídeo nos generaría 97500 imágenes (65minutos x 60 segundos x 25fps). Así que lo mejor es ejecutar solo sobre la porción menor posible del vídeo.
Podríamos volver a dividir mediante avidemux, pero genera diferentes problemas en función de la localización de los "keyframes", los fotogramas base sobre los que se marca la compresión de todos los siguientes. Sin embargo, la división mediante mkvmerge GUI no generó ningún problema y lo pudimos dejar en 13 segundos (primero en cortes de 20 minutos, luego 5 del que nos interesaba, luego 1 minuto y luego de 20 segundos, que el programa dejó en 13)

En la pestaña de Opciones generales, Modo de corte (Dividir según duración) y luego los segundos (formato horas:minutos:segundos).

Luego aplicamos la orden ffmpeg y se obtienen un lote completo de fotos. Ahora solo nos queda elegir las mejores y las podemos poner en una presentación, sin tener que cargar un vídeo.

PD. Por cierto, aplicaciones gráficas, pero al final, recurrimos al terminal

Softonic y la diferencia con el software libre

Estas noticias sobre los problemas de Softonic trae a mis recuerdos aquellas épocas oscuras en las que también me movía en los "pantanos" de descarga del software para mi sistema, que por orden fue MSDOS, Windows 3.1, Windows 95, Windows 98 y Windows XP. Y de ahí no pasé, por que cambié a Linux y se acabaron los problemas.
En mi caso nunca ha sido importante Softonic, ya que abandoné Windows antes de haber usado Softonic como antes había usado tucows. En aquellos lejanos y oscuros tiempos tucows nos daba a conocer que software disponíamos para hacer según que tareas, cual era freeware, cual era shareware y podíamos bajarlo con facilidad. Luego, por lo que dicen los sufridos usuarios de windows que me rodean, softonic ocupó ese lugar, al menos en España. Sin embargo, en las últimas limpiezas que he realizado en varios portátiles, creo que el malware había entrado en la descarga e instalación de aplicaciones a través de Softonic y su downloader (los usuarios de Windows son muy dados a clickear en cualquier sitio y decir que sí antes de pensar lo que puede pasar; y no nos olvidemos que lo hacen todo como administradores de equipos, sin palabra que introducir, dándole al ratón a un Sí que aparece ahí... Parece una película de terror).
Como recomendación, el uso de software libre. En general, todo cuanto necesito está disponible en los repositorios de mi distribución, y en lo casos muy raros en que no es así, recurrimos al código fuente, y listo. Rápido, seguro y limpio. Ah! y gratis, pero eso debería ser lo de menos.

https://upload.wikimedia.org/wikipedia/commons/1/1c/License_icon-gpl-4.svg 

By User:ZyMOS (Open Icon Library) [Public domain], via Wikimedia Commons

Eliminar principio y fin de un MKV

Como indicábamos en la entrada anterior, de un DVD de una cadena de televisión he extraído un fichero mkv para evitar tener que usar un disco óptico. El problema reside en que los productores del Dvd te lo dan con "restos" inútiles al principio (95 segundos de bandas de color y 30 segundos más de pantalla en negro)

y final (11 minutos y 48 segundos de otros programas codificados o lo que sea)

Así que para terminar nuestro trabajo, lo mejor es eliminar esos trozos. Primero quise ejecutar ffmpeg

ffmpeg -i 'video.mkv' -v:c copy -a:c copy -ss 02:05:00 -t 63:19:00 'video2.mkv'

pero como resultado generó una serie de errores que tengo aun que analizar:

Invalid loglevel "copy". Possible levels are numbers or:
"quiet"
"panic"
"fatal"
"error"
"warning"
"info"
"verbose"
"debug"

Revisando mkvmerge descubrí que realmente no puedes seleccionar un trozo en particular, sino que permite dividir en trozos idénticos según diferentes parámetros.

Eso nos obligaría a dividirlo en trozos con la duración del primero a eliminar, ajustar el último que queramos aprovechar dividiéndolo según el último trozo que quede para eliminar y finalmente unir los cortes válidos por orden. Demasiado trabajo.

Así que recurrí a avidemux.

Mediante los marcadores (1 y 2 en la imagen) se marcan las zonas a borrar, teniendo siempre cuidado de copiar directamente el audio (3) y vídeo (4) para no provocar una nueva recodificación y simplemente copiar la parte deseada directamente. Con el fin de no cambiar el formato del contenedor, se elige el mismo (5). Con esto y 3 segundos, listo. No se ha cambiado la resolución ni la calidad de la imagen y sonido y hemos eliminado casi 14 minutos de vídeo "basura".
En resumen, hemos utilizado una serie completa de aplicaciones de código abierto que nos ha permitido convertir un DVD óptico (técnica poco funcional en los días que corren) a un fichero MKV de alta calidad (vídeo avc1 h264 720x576; sonido AC3 382kbps) en 1,1GB, que entra en cualquier unidad USB, incluso en las que regalan.

Solo me falta saber que pasó con ffmpeg.

Linux y un codificador de DVD: Handbrake

Esta entrada nace de un cierto "desconocimiento" de la forma de ripear y codificar un DVD. Mi abandono de Windows, alrededor de 2007, supuso también un abandono de ripear y descodificar, por que encontré cosas mejores en las que divertirme. Pasado tanto tiempo, ni me acordaba como usaba antes Gordian Knot ni decenas de programas más. Sin embargo, unos comerciales me pasaron unos DVDs de publicidad, sin protección, para utilizar en clase. En esas circunstancias no siempre dispones de unidades ópticas para proyectar los DVDs, así que tenía la necesidad de extraer vídeos que pudiera llevar en un lápiz USB sin más historias. De los programas indicados en algunas páginas web (por ejemplo, ésta) para extraer vídeo de DVDs en linux, y aunque ya había usado Dvd::Rip, el que más me interesaba era Handbrake. Además, mucha gente también piensa así.
El primer problema es que no esta disponible en los repositorios de Fedora. Como se puede ver en la Web de HandBrake, parece que solo se hacen binarios para Debian/Ubuntu; sin embargo, rápidamente encontré una página para bajar un binario rpm e instalarlo.
Luego el ripeo fue sencillo, ya que no eran DVDs protegidos, y la conversión se hizo rápidamente. El contenedor, en vez de mp4 decidí escoger MKV y listo.

Por cierto, a pesar de usar un ordenador bastante antiguo, los dos DVDs de 40 y 20 minutos se ripearon y transformaron en unos 10 minutos.