19 mar 2022

Arch Linux endeavouros Manjaro CachyOS - Teclado inglés convertido a español con símbolo < > less greater en tty | English keyboard to la-latin1 / latam in tty console fix

If you bought a laptop with an English keyboard and you're going to use it in Latin America/Spain, you'll lose the greater and lesser keys on the keyboard; this will solve that.

The US standard keyboard comes with:


 


If you have a laptop with a US keyboard converted to Latin American Spanish (Latin America), you may have noticed that while in X11 / Wayland you can type < > using AltGr (the right Alt key) + Shift + X or Z (with latam keyboard 104 keys), you can't in a tty console and must use "loadkeys us" alternating with "loadkeys la-latin1".

You can map these symbols by modifying the la-latin1 keyboard layout, which is the correct layout for this keyboard in the console, by modifying the following lines.


HOW TO:

in /usr/share/kbd/keymaps/i386/qwerty/ you will find la-latin1.map.gz.

Create the file /usr/local/share/kbd/keymaps using mkdir -p and copy la-latin1.map.gz there. Then, run gunzip la-latin1.map.gz and edit the la-latin1.map file with Vim.


On the line containing "keycode 86 = less greater" (line 61, which isn't working), delete entire line and add the next in the same place and below:

altgr keycode 51 = less

altgr keycode 52 = greater

Save and exit.

Rename the file to personal.map using the mv command, then convert it to a .gz file using gzip personal.map, which compresses it and renames it to personal.map.gz.

Now copy it to /usr/share/kbd/keymaps/i386/qwerty/.

Use localectl to set it like this:

localectl set-keymap personal personal


Now you have the right Alt key (AltGr) to use the original location of the <> symbol in the keyboard position (< above the comma, and > above the period) in the tty console without having to use loadkeys us.

Add keyboard latam to X11 / Wayland DE because now, the DE It won't recognize the map and will use the one on the keyboard, which is in English ANSI, so add latam/es if you haven't already.


And now you have latam with < > in X11 / Wayland and latam with < > in tty using the original keys.

13 feb 2022

El clickbait de Wayland en muylinux y la pelotudez de la comunidad millenial

 Espero que como en otros tiempos, no digan que hago una entrada sobre ellos para ganar tráfico, ya que mis lectores, o eso pretendo, son muy diferentes a los suyos.

Por empezar, no diría nunca que es más válida una encuesta de la mejor distro, hecha en mi blog (con 3000 votos) que en distrowatch, solo porque "la de distrowatch, se basa en los click en las páginas", como si eso fuera poco indicativo.

Armaron un artículo que es una pataleta, sobre que ellos (los tarados) aún no tienen Wayland.

No consultaron fuentes, programadores ni gente calificada, y todo para generar visitas.

Luego sale Eduardo Medina en Youtube diciendo lo contrario a lo que publicó su colega en muylinux, donde trabaja, bajando los ánimos, total, ya habían conseguido las visitas para ese entonces.

A diferencia de los palurdos de muylinux, me puse a charlar con un programador sobre la cuestión de Wayland, para entender el tema, ya que no soy programador y no conozco los detalles del asunto. Estés o no metido en el desarrollo de wayland, si sos programador de entornos Linux, sabés de qué va la cosa.

Primeras desinformaciones de Muylinux: Afirman que hace 14 años Wayland está en desarrollo.

Falso, no hace 14 años que está sin estar listo, desde 2013 Tizen lo usa de forma estable: https://www.phoronix.com/scan.php?page=news_item&px=MTUxMTE

Incluso ya antes estaba listo, se empezó en 2008, así que aunque hubiera sido en 2013, no me parece tanto 5 años para una pila gráfica.

Wayland se pensó para seguridad y entornos productivos, jamás para que fuera como Xorg, no es que (como dicen en muylinux), se pensó mal o no existía screencasting (wtf!) en 2008 (lo repite Medina en youtube).

No se puede tener todo, y me refiero a seguridad + flexibilidad. No leo usuarios de OpenBSD quejándose de Xenocara, porque saben y admiten que todo no es posible. Es como tener 123 de password root, porque sos de olvidarte, y a la vez exigir seguridad en tu PC.

Deberían agradecer que Red Hat y otros, están hace años, sí 14, añadiendo cosas alrededor de Wayland para que tenga algunas de las que posee Xorg, y probablemente nunca las tenga todas, porque usar pipewire para reemplazar funcionalidades perdidas, es un arreglo sucio, como capa sobre capa como xwayland.

Entonces, no es cierto que hace 14 años esperan nada, está listo desde al menos 2013 y antes también. No es cierto que "se diseñó mal", sino que se diseñó con otros objetivos y fué justo con el que salió en su versión estable.

Tampoco existe una conspiración entre Canonical y los "usuarios conservadores" para detener Wayland y aunque la hubiera, cómo es que los usuarios esos dentendrían el desarrollo de software en manos de una empresa? no pudieron (pudimos) con systemd, menos con esto. Es ridículo.

Las pelotucedes que dicen en ese blog no tienen límite, pero lo peor es que desinforman y generan discordia sin explicar, tirando su nivel aún más al de una comunidad de Taringa. Un /r de reddit tiene más nivel.

¿Quieren grabar el porno que ven o hacer streaming de su pene a su amigo/a? usen Xorg, ¿quieren seguridad? usen Wayland. Los pedidos de los nenes caprichosos jugones (ay los FPS) son los que demoran wayland, no los "usuarios conservadores".

¿Qué más querría un conservador de Linux (Slackware? Gentoo?) que un servidor gráfico y compositor seguro? no conozco ningún conservador old school contra eso, y si fué y es aún en contra de systemd, es porque de seguro no tiene nada y de KISS menos.

El error de Red Hat posiblemente fué no aclarar de entrada las limitaciones y decir "quieren todo? usen Xorg, quieren una sesión segura para usar su banca móvil? usen Wayland" y fin del asunto.

La demora es porque están metiendo funciones de Xorg en Weston, cosa que ni estaba pensada, y todo eso sin volverlo una cagada, que podría pasar.

Lo que deberían es dejar de joder con pedirle a Wayland HDR, VR, etc, etc, es Linux no Windows. Realmente la comunidad está cada día más pelotuda. Linux no compite con Apple o con Windows como dicen en algunos lados, es como decir que yo compito con el blog dedoimedo, una imbecilidad absoluta.

Empezaron usando Linux por libre, seguro y estable y terminan pidiendo HDR, realidad virtual, grabar la pantalla y stremear en twitch. Mejor se replantean qué OS es para ustedes.

Saludos.

9 feb 2022

Stremio libmpv.so.2: cannot open shared object file: No such file or directory Arch Linux / Manjaro

Si bien en la web oficial de Stremio hay una descarga para Arch / Manjaro, esta nos envía a AUR, para instalarlo usando paru o yay.


Pero existe un problema y es que originalmente, este software fué hecho para Debian / Ubuntu, y como se sabe, a Debian y sus hijos les encanta renombrar los paquetes y sus librerías.

En algunos casos esto no se presenta porque el paquete instalado de mpv de AUR o bien de repo, tiene ya el enlace simbólico, ejempllo de mpv-amd-full-git:

lrwxrwxrwx 1 root root 15 feb  9 20:52 libmpv.so.2 -> libmpv.so.2.0.0

La librería real es: 2,7M -rwxr-xr-x 1 root root 2,7M feb  9 20:52 /usr/lib/libmpv.so.2.0.0

Entonces, la solución a esto es tan simple como:


1) su - root

2) cd /usr/lib/

3) ln -s /usr/lib/libmpv.so.1.109.0 libmpv.so.2

 

Sino, instalen mpv de AUR, en version git.

Solucionado.

3 feb 2022

LibreOffice 7.3.0.3 Developer branch langpack ES PKGBUILD ArchLinux / Manjaro

 Si usan Arch o derivados, Manjaro como es mi caso, habrán notado que en AUR se encuentra la rama desarrollo de libreoffice, que mejora la compatibilidad con MS-Office.

El -dev-bin que se instala, mediante yay, es el paquete clásico, el otro, el de idioma si notan el PKGBUILD contiene todos los idiomas y a la hora de descargar y armarlo, no solo demora mas de 1 hora porque los repos de libreoffice son lentos (500kb promedio) sino que además llena muchísimo el disco para armar algo que no vamos a usar.

Bajé y modifiqué el PKGBUILD de libreoffice para que cree e instale el langpack (no el helppack) de -es. Son apenas 3.7MB.


Resultado del paquete instalado: 

 

pacman -Qi libreoffice-dev-bin-langpack-es
Nombre                    : libreoffice-dev-bin-langpack-es
Versión                   : 7.3.0.3-1
Descripción               : LibreOffice development branch
Arquitectura              : x86_64
URL                       : https://www.libreoffice.org/
Licencias                 : LGPL3
Grupos                    : Nada
Provee                    : libreoffice  libreoffice-es-ES
Depende de                : gtk3  lpsolve  neon  curl
Dependencias opcionales   : java-runtime: adds java support [instalado]
                            java-environment: required by extension-wiki-publisher and extension-nlpsolver
                            coin-or-mp: required by the Calc solver
                            kio: for Qt5 integration
Exigido por               : Nada
Opcional para             : Nada
En conflicto con          : Nada
Remplaza a                : Nada
Tamaño de la instalación  : 26,81 MiB
Encargado                 : Unknown Packager
Fecha de creación         : jue 03 feb 2022 04:31:55
Fecha de instalación      : jue 03 feb 2022 04:34:06
Motivo de la instalación  : Instalado explícitamente
Guion de instalación      : No
Validado por              : Nada

El PKGBUILD es el siguiente:

_pkgnamefmt=LibreOffice
_pkgname=libreoffice
pkgname=${_pkgname}-dev-bin-langpack-es
_LOver=7.3.0.3
pkgver=7.3.0.3
#_basever=$( cut -f1-2 -d'.' <<< ${_LOver} )
pkgrel=1
arch=('x86_64')
license=('LGPL3')
url="https://www.libreoffice.org/"
pkgdesc="LibreOffice langpack-es development branch"
depends=('gtk3' 'lpsolve' 'neon' 'curl')
optdepends=('java-runtime:          adds java support'
            'java-environment:      required by extension-wiki-publisher and extension-nlpsolver'
            'coin-or-mp:            required by the Calc solver'
            'kio:                   for Qt5 integration')
provides=('libreoffice-dev-bin-langpack-es')

source=("https://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/${_pkgnamefmt}_${_LOver}_Linux_x86-64_rpm_langpack_es.tar.gz")
sha256sums=('SKIP')

package() {
	find "${srcdir}/${_pkgnamefmt}_${_LOver}"*/RPMS/*rpm -exec bsdtar -x -f '{}' -C "${pkgdir}" \;
}

Crean un archivo PKGBUILD con el contenido, hacen makepkg -s y eso va a crear un paquete local pkg.tar.zst, el cual instalan con sudo pacman -U.


Espero que les sirva.

30 ene 2022

De nuevo Fedora, o mejor dicho, Red Hat

Ya hace muchos años, cuando era usuario de Fedora, tuve que pasar por varias situaciones, para darme cuenta que no era una comunidad, sino una aparente comunidad manejada y controlada por Red Hat, porque al fín y al cabo, Fedora no es algo más que la segunda etapa en el control de calidad y creación de RHEL.

Comienza con Fedora rawhide, sigue con Fedora en sus alfa, beta, etc, Fedora final, luego CentOS Stream (antes no lo tenían y es un paso más que añaden a mejorar la distro) y finalmente RHEL.

Más allá de las cuestiones técnicas de si es buena o no, que veo se debate demasiado seguido en muylinux, la cuestión es política y es algo que no se da muy bien en los ambientes de IT. Política no es solamente a quién votan para presidente o son de izquierda, centro o derecha.

Red Hat aprovecha esta cuestión para hacer algo similar a lo que hacen las empresas, llamado "engagement empresarial". De esta manera logran que mucha gente colabore de forma gratuita con Red Hat y Fedora, a cambio de ser reconocidos, formar parte de algo, y claro, poder sumar eso eventualmente a un curriculum.

Por tanto, tenemos una falsa comunidad, ya que si mañana absolutamente todos los colaboradores de Fedora, se van a Debian o Ubuntu, Red Hat en pocos días crea otra Fedora, porque es parte de su workflow y porque realmente Fedora no existe sin Red Hat ni Red Hat sin Fedora. No olvidemos que el equivalente en SLES de SUSE es OpenSUSE y está bien que así sea, la cuestión es cuando no se es claro y se dice cosas como que vos sos igual a cualquier otro porque es una comunidad, y se habla de horizontalidad, cuando no es tal.

Debian por ejemplo, tiene una comunidad, y sus controles de calidad pasan por su debian experimental (fedora rawhide), unstable (Fedora testing), testing (Fedora) y finalmente la stable (RHEL). Más allá de la burocracia y el esquema verticalista de Debian, más que menos es una comunidad.

Hace algunos años, me pasó que Red Hat me robó y borró un bug report /aporte sin reconocimiento alguno y sinceramente no le di mayor importancia porque era gastar tiempo para no obtener resultados, además, debo admitir que lo dejé pasar también un poco por idiota.

Hace poco, el colega sincorchetes, antes Netsys, del blogroll, tuvo un incidente similar con un PR en Fedora.

A Lyude le pagan, su @ es redhat, a Álvaro no le paga nadie y su única ganancia en esto es tener algún reconocimiento y eventualmente ponerlo en su curriculum o donde mejor le guste.

Se ve que Lyude estaba muy apurada (risas) y le resultó más rápido (risas) cerrar un PR, abrir otro, copiar el código, que simplemente añadirlo como estaba y no colocarse en el changelog. Sucede que cuando sos empleado, tenés que cuidar el trabajo y parte de eso es hacer lo que tenés que hacer, porque si lo hace otro, no estás haciendo tu trabajo. No creo que Lyude no sepa o no quiera poner ese parche, sino que alguien de la comunidad, hizo lo que debería haber hecho eso, y en medio de la adquisición de Red Hat por parte de IBM, no es menor "hacer buena letra". Lo podemos ver en su cuenta de twitter:


Sin mucho más que decir, les dejo el enlace a quien cuenta en primer persona lo que le sucedió: https://echemosunbitstazo.es/posts/es-realmente-comunitaria-fedora-project/