megasync: error while loading shared libraries: libicuuc.so.74 - [SOLVED] Manjaro - ArchLinux

Icu is now 75 version, this error is common in the last 4 days in Arch and derivatives.

Solution is NOT compile megasync and delete megasync-bin, is install icu74 using yay or paru.

yay / paru -S icu74 and voilá!

Mate Weather don't show the weather libmateweather is unable to retrieve weather data

Since 16 October 2023, mate weather is unable to retrieve weather data

The problem is that the Mate Team has changed the URL source for the weather and (genius - irony) they didn't do a redirect from old URL to new URL.

The suggestion in github is "edit libmateweather.so file"

Well, does not work and is a nasty way.

I did this in Arch but work for Manjaro and others (Ubuntu https://bugs.launchpad.net/ubuntu-mate/+bug/2039494) using the compilation way of Debian.

1.- Download the source $ wget https://pub.mate-desktop.org/releases/1.27/libmateweather-1.27.0.tar.xz

2.- $ tar xvf libmateweather-1.27.0.tar.xz

3.- edit libmateweather-1.27.0/libmateweather/weather-metar.c line 553 and replace

https://www.xviationweather.gov/adds/dataserver_current/httpparam

with

https://www.xviationweather.gov/cgi-bin/data/dataserver.php

Save and exit (use nano, vim, etc)

Download the PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/libmateweather/-/raw/main/PKGBUILD

edit the PKGBUILD and replace the line:

source=("https://pub.mate-desktop.org/releases/${pkgver%.*}/${pkgname}-${pkgver}.tar.xz")

with

source=("libmateweather-1.27.tar.xz")

In the same directory compress again the edited source code:

$ tar cfJ libmateweather-1.27.0.tar.xz libmateweather-1.27.0

Make the package:

$ makepkg -s --skippgpcheck --skipchecksums

$ sudo pacman -U libmateweather-1.27.0-1-x86_64.pkg.tar.zst

Done, weather is working again.

Lenovo L340 teclado inglés convertido a español, símbolo < > less greater | Lenovo L340-15API us to la-latin1 fix less greater symbol

Con el teclado US standard keyboard viene:

 

Al pasarlo a latam mediante stickers (los detalles en amarillo) queda así:

Si poseen una Lenovo L340-15API con teclado US convertido a español (latam) habrán notado que si bien en X11 con altgr (el alt derecho) + shift + X o Z obtienen < >, en una consola tty no y deben usar "loadkeys us" alternado con "loadkeys la-latin1".

Se puede mapear dichos símbolos modificando el teclado la-latin1 que es el adecuado en consola para este teclado, modificando las siguientes líneas.

En /usr/share/kbd/keymaps/i386/qwerty/ vamos a encontrar la-latin1.map.gz

Creamos mkdir -p /usr/local/share/kbd/keymaps y ahí copiamos la-latin1.map.gz, hacemos gunzip la-latin1.map.gz y editamos el la-latin1.map con vim.

En la línea que tiene "keycode  86 = less             greater" (línea 61 que no funciona), borramos la misma y colocamos:

 

    altgr   keycode  51 = less
    altgr   keycode  52 = greater
 

Grabamos y salimos. Renombramos el archivo a personal.map con el comando mv y luego lo pasamos a .gz con gzip personal.map que lo comprime y pasa a llamar personal.map.gz

Ahora lo copiamos a /usr/share/kbd/keymaps/i386/qwerty/

Usamos localectl para setearlo de esta manera:

localectl set-keymap personal personal

Ya tenemos el alt derecho (altgr) para usar la ubicación original del símbolo <> en la posición que posee el teclado que es < sobre la , y el > sobre el . en consola tty sin tener que pasar a us.

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.

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.

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.

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/

Una implementación en TCP sobre ICMP permite bypassear Firewalls usando Echo Reply

Una implementación programada en Go, permite usar TCP para transferir datos, sobre ICMP usando echo reply y así bypassear firewalls. Así que ya saben, no permitir pings ;)

Clonar disco VPS y crear nueva NIC

Hace un tiempo vimos como restaurar un VPS desde un archivo de imagen conservando la red y ahora vamos a ver como clonar un VPS.

Motorola Moto E2 o segunda generación usa snapdragon 410 pero corre en 32 bit

Este aparato usa Snapdragon 410, un CPU de 64 bit, todos pensariamos que aprovecha mejor las caracteristicas de Android 5.x pero no es asi. De hecho es lo mismo que usar un 400 de 32 bit.