Re: Desmontar carpetas muertas

[Emilio Lazo Zaia]

Intenta lsof -n porque quizás se queda resolviendo el nombre, cosa que
evitas con -n.

Me resulta extraño que no se pueda con umount -f ni -l, ya que las
operaciones que se quedan colgadas de esa forma que no responden ante kill
o killall -9 son aquellas que están esperando I/O y quedan como
ininterrumpibles (visible como una D con ps o top). Como se ve con ps o con
top esos procesos de umount o fuser cuando se cuelga?
El jul 11, 2016 10:05 p.m., "Paynalton"  escribió:

> Hola chicos, tengo un problema. En un servidor tengo varios montajes a
> carpetas cifs. El problema es que a veces esos servidores pierden
> comunicación y las carpetas se cuelgan.
>
> el montaje lo tengo así:
>
>
> //1.1.1.1/carpeta /mnt/carpeta cifs
> user=usuario,password=password,auto,user,ro 0 0
>
> He intentado lo siguiente:
>
> umount /mnt/carpeta
> umount -fl /mnt/carpeta
> umount -fr /mnt/carpeta
> umount -l /mnt/carpeta
>
> y comandos como estos también se quedan colgados:
>
> fuser /mnt/carpeta
> df
> cd /mnt/carpeta
>
> Si reinicio el servidor también se queda colgado, la única forma de
> desbloquear es desconectar el servidor y esperar a que encienda de nuevo.
>
> Saben de que manera puedo reestablecer una conexión en estos casos???
>
>
>
>
> --
> 
>  ___
> / Al amigo y al caballo, no hay que \
> \ cansarlos./
>  ---
> \   ^__^
>  \  (oo)\___
> (__)\   )\/\
> ||w |
> || ||
>  __
> < Mi extensión es 2273 >
>  --
>\
> \
> .--.
>|o_o |
>|:_/ |
>   //   \ \
>  (| | )
> /'\_   _/`\
> \___)=(___/
>
>
>
>
>

Re: Cambio repentino de archivo de texto normal a archivo binario

[Emilio Lazo Zaia]

Hola

On 29/04/16 22:22, Debianero wrote:

On Fri, Apr 29, 2016 at 10:22:23PM +0200, Santiago Vila wrote:

egrep -i texto-a-buscar archivo-texto
Coincidencia en el fichero binario archivo-texto

Usa la opción -a:

grep -a -i texto-a-buscar archivo-texto

o si lo prefieres:

grep -ai texto-a-buscar archivo-texto

¡¡¡Genial, si funciona!!!. Con esto resuelvo parte del problema inmediato. Pero 
agradezco muchisimo. Ahora a buscar el ¿Porque se convierte en binario? ¿Con 
que simbolo?.
Sí, con "-a" funciona... tambíen si usas el comando "strings"; allí 
descarta lo binario y muestra texto; luego de eso puedes usar grep, pero 
como dices: queda el problema principal sin resolverse. Veo que en el 
script te faltó "echo" en la línea que dice:


$ $agregartexto >> miarchivo.txt

Debería ser

$ echo $agregartexto >> miarchivo.txt

Pero supongo que no hay problema con eso porque fue una ejemplificación 
para el correo a la lista y no que esté siendo ejecutado de esa forma, 
porque no añadiría las líneas.


Adjunta un fragmento de varias líneas con "cat -A" sobre el archivo si 
te está diciendo en este momento lo de que es binario... intenta 
conseguir un archivo mínimo que haga que diga que es binario sin que lo sea.


¿Ese archivo sólo es escribible de esa forma? o sea, ¿agregando líneas 
al final desde la consola? recuerdo que lo editaban con emacs, entonces 
¿no será que emacs está trabajando en otra codificación y lo modifica 
así? no conozco emacs como para ver eso.


¿Eso de agregar líneas lo hacen remotamente también? es decir, por ssh 
por ejemplo desde máquinas distintas donde tal vez el emulador de 
terminal no esté bajo UTF-8 y el archivo a veces tiene líneas escritas 
bajo UTF-8 y las remotas bajo, por ejemplo iso8859-1. En ese caso, grep 
dice que es binario si se agregan diacríticos al archivo bajo distintas 
codificaciones.


Por ejemplo (asumiendo que usas UTF-8):

$ echo aá > archivo-texto
$ echo bá | iconv -t latin1 >> archivo-texto
$ grep a archivo-texto
$ grep b archivo-texto

Con la última línea verás cómo dice que hay coincidencia en el archivo 
binario, porque la línea que tiene la letra "b" tiene al lado una "á" 
(a, acentuada) que está bajo iso8859-1 (latin1) y es el byte E1 en 
hexadecimal, que no representa nada en UTF-8 sino *quizá* el primer byte 
de un caracter de 2, 3 o 4 bytes, que es como funciona UTF-8. Cuando te 
tiene que mostrar la línea que tiene la "b" va a mostrar un byte que en 
hexadecimal es E1, y que en UTF-8 no corresponde con nada; allí dice que 
es binario porque no tendría nada que mostrar.


¿Cuál es el contenido de la variable $TERM y de la variable $LANG?

Re: Guión medio color azul en emacs

[Emilio Lazo Zaia]

Va entre líneas.

El 28 de abril de 2016, 20:38, Debianero <debian...@openmailbox.org>
escribió:

> On Thu, Apr 28, 2016 at 01:56:03AM -0430, Emilio Lazo Zaia wrote:
> > ¿No estará el archivo en UTF-16? prueba con el comando "file" a ver qué
> > codificación detecta, después puedes usar "iconv" para convertirlo a la
> que
> > desees, probablemente UTF-8.
> >
> >
> > Si con "cat" no ves nada extraño, entonces prueba con "cat -A"; si
> aparece
> > "^@" entre cada carácter, entonces es UTF-16.
>
> Tambien he de comentar que el simbolo de interrogacion "¿" viene como con
> codificacion y viene en letras azules "\302\277" siendo que antes esto no
> aparecia.
>
> El signo de exclamacion "!" trae el codigo "\302\241" en letras azules.
>
> La letra "é" trae el codigo "\303\251" en letras azules.
>

Aquí tenemos más información: Estos caracteres que citas están codificados
bajo UTF-8, aunque supongo que la exclamación es "¡" y no "!".

Esa nomenclatura es octal. Puedes probarlo así:

$ echo -n é | od -b

Eso significa que por lo menos esos caracteres están en UTF-8; habrá que
ver si hay otros que están bajo otra codificación (e.g. iso8859-1) que
entonces emacs lo detecta como una mezcla de codificaciones y te lo muestra
un poco más "binario" dándote los códigos en octal de todo lo que no sea
ASCII. No sé si emacs hace eso, en realidad... Lo extraño es que sea
detectado como "data" por file; eso significa algo así como "binario
desconocido" y no un simple texto en UTF-8. Si pones un fragmento ayudaría
más. ¿Esto fue un cambio súbito que nadie hizo y de pronto se empezó a ver
así el archivo?



El 28 de abril de 2016, 20:38, Debianero <debian...@openmailbox.org>
escribió:

> On Thu, Apr 28, 2016 at 01:56:03AM -0430, Emilio Lazo Zaia wrote:
> > ¿No estará el archivo en UTF-16? prueba con el comando "file" a ver qué
> > codificación detecta, después puedes usar "iconv" para convertirlo a la
> que
> > desees, probablemente UTF-8.
> >
> >
> > Si con "cat" no ves nada extraño, entonces prueba con "cat -A"; si
> aparece
> > "^@" entre cada carácter, entonces es UTF-16.
>
> Tambien he de comentar que el simbolo de interrogacion "¿" viene como con
> codificacion y viene en letras azules "\302\277" siendo que antes esto no
> aparecia.
>
> El signo de exclamacion "!" trae el codigo "\302\241" en letras azules.
>
> La letra "é" trae el codigo "\303\251" en letras azules.
>
> >
> >
> > On 27/04/16 23:53, Debianero wrote:
> > >>Seguro que los guiones son guiones dentro del documento o son solo una
> forma de emacs para representar algún caracter no imprimible? Puedes
> intentar abrir el archivo con algún editor hexadecimal y editarlo ahí.
> > >>Con vim puedes usar `:%!xxd` para convertir tu archivo a hexadecimal,
> editarlo y usar `:%!xxd -r` para regresar antes de guardar.
> > >Ya lo hice, pero no reemplaza ni con hexadecimal.
> > >
> > >Creo que tiene que ver con los Caracteres de Control como dice Camaleon.
> > >
> > >Buscare mas sobre esa informacion.
> > >
> > >Gracias
> > >
> > >Debianero
> > >
> > >
> >
>
>


-- 
Emilio Lazo Zaia <emiliolazoz...@gmail.com>

Re: Guión medio color azul en emacs

[Emilio Lazo Zaia]

Hola, ¿pero verse perfectamente significa que lees el texto?

¿Entre cat y cat -A no ves diferencia? Con cat -A verás un resultado que
será texto ASCII siempre, es decir que los caracteres de control -si
existieran- son transformados a una forma en texto con nomenclatura de
caracteres de control (^), y lo que esté fuera de ASCII (en cualquier
codificación) te lo muestra también en una forma de texto... Verás los
saltos de línea con un "$". Con eso podrás hacer un análisis de lo que está
pasando y a qué codificación fue convertido, si es que pasó eso.

Podrás poner acá por lo menos un fragmento de cada resultado a ver qué se
puede saber...


PD: Disculpa que antes te respondí privadamente nada más.

El 28 de abril de 2016, 19:52, Debianero <debian...@openmailbox.org>
escribió:

> On Thu, Apr 28, 2016 at 01:56:03AM -0430, Emilio Lazo Zaia wrote:
> > ¿No estará el archivo en UTF-16? prueba con el comando "file" a ver qué
> > codificación detecta, después puedes usar "iconv" para convertirlo a la
> que
> > desees, probablemente UTF-8.
>
> # Ejecutando el comando file me arroja el siguiente resultado.
> $ file miarchivo.txt
> miarchivo.txt: data
>
> >
> >
> > Si con "cat" no ves nada extraño, entonces prueba con "cat -A"; si
> aparece
> > "^@" entre cada carácter, entonces es UTF-16.
>
> # Ejecutando el comando siguiente se ve perfectamente el archivo.
> $ cat miarchivo.txt
>
> # Ejecutando el comando siguiente se ve perfectamente el archivo.
> $ cat -A miarchivo.txt
>
>
> >
> >
> > On 27/04/16 23:53, Debianero wrote:
> > >>Seguro que los guiones son guiones dentro del documento o son solo una
> forma de emacs para representar algún caracter no imprimible? Puedes
> intentar abrir el archivo con algún editor hexadecimal y editarlo ahí.
> > >>Con vim puedes usar `:%!xxd` para convertir tu archivo a hexadecimal,
> editarlo y usar `:%!xxd -r` para regresar antes de guardar.
> > >Ya lo hice, pero no reemplaza ni con hexadecimal.
> > >
> > >Creo que tiene que ver con los Caracteres de Control como dice Camaleon.
> > >
> > >Buscare mas sobre esa informacion.
> > >
> > >Gracias
> > >
> > >Debianero
> > >
> > >
> >
>
>


-- 
Emilio Lazo Zaia <emiliolazoz...@gmail.com>

Re: Guión medio color azul en emacs

[Emilio Lazo Zaia]

¿No estará el archivo en UTF-16? prueba con el comando "file" a ver qué 
codificación detecta, después puedes usar "iconv" para convertirlo a la 
que desees, probablemente UTF-8.



Si con "cat" no ves nada extraño, entonces prueba con "cat -A"; si 
aparece "^@" entre cada carácter, entonces es UTF-16.



On 27/04/16 23:53, Debianero wrote:

Seguro que los guiones son guiones dentro del documento o son solo una forma de 
emacs para representar algún caracter no imprimible? Puedes intentar abrir el 
archivo con algún editor hexadecimal y editarlo ahí.
Con vim puedes usar `:%!xxd` para convertir tu archivo a hexadecimal, editarlo 
y usar `:%!xxd -r` para regresar antes de guardar.

Ya lo hice, pero no reemplaza ni con hexadecimal.

Creo que tiene que ver con los Caracteres de Control como dice Camaleon.

Buscare mas sobre esa informacion.

Gracias

Debianero

Re: Bug en utileria ifupdown 0.7.50 instalar la version 0.7.51

[Emilio Lazo Zaia]

On 26/04/16 09:07, Camaleón wrote:

El Mon, 25 Apr 2016 18:21:44 -0500, Debia Linux escribió:


2016-04-22 8:46 GMT-05:00 Camaleón :

(...)


Y no puedo hacerlo, lo resolvi a base "bonga monga" y martillazos...
al estilo del Capitan Cavernicola.

Y por "bonga monga" te refieres ¿a qué, exactamente? Capaz de haber
reinstalado el sistema :-P

Exacto, elimine todo el sistema de un solo "zapatazo" (gonga monga) y
listo... Capitn  Caverncolaaa... e hij.
El propósito del hilo debe haber sido terminar diciendo algo así como 
esto, dos veces.


No sé cómo es tomado en serio por algunos usuarios, luego de estupideces 
como
esta, como el último correo sobre el orgullo "Debia", y decir también 
que cuando

tenga tiempo prueba porque recordemos que tiene mucho trabajo. Además de
pedir ayuda y después "resolver" todo a los trancazos, reinstalando y 
aplicando

scripts que no entiende. Para mí que todas son situaciones imaginarias.

Re: ¿Existen aun repositorios oficiales para ALSA?

[Emilio Lazo Zaia]

Uno que nos cuenta todo su calvario instalando "Debia" en una laptop; 
tiene problemas con la red, cree que encontró un bug pero también quiere 
instalar ALSA; sin saber qué es eso busca los repositorios de ALSA (?) y 
cree que los encontró, pero se trata de un espejo oficial de Debian 
(para él: "Debia")... A lo mejor está burlándose.



Luego dos se guindan con una discusión de quinceañeros que uno terminó 
bloqueando al otro, y además anuncia que lo va a bloquear para que se 
deprima. Es patético todo esto. ¿Tienen más de 16 años? Si fuera así, 
pues están mal. Ahora también seré bloqueado, pero podré vivir con eso.




On 20/04/16 15:43, Santiago José López Borrazás wrote:

El 20/04/16 a las 22:05, Jose Maldonado escribió:

Mira, la has cagado, vas al filtro definitivamente, no vuelvo a ver
cualquier otra cosa que sea tuyo. Lo siento.

Re: Problema tras actualizar

[Emilio Lazo Zaia]

Sin querer te respondi privadamente...

Bueno, es extraño que haya quedado libc-bin en estado "rc" al hacer una
actualización que se interrumpió.. Ese estado corresponde a haber quitado
el paquete a mano o de forma automática.

Ese paquete es el responsable de ldconfig, que es lo que te está fallando.
Yo intentaría instalarlo a mano de lo que se descargó para la actualización
o descargándolo si ese paquete no formaba parte de la actualización que se
estuvo haciendo.

El mar 14, 2016 10:11 p.m., "Lacho" <marcoscapel...@gmail.com> escribió:

>
>
> El 03/14/16 a las 23:27, Emilio Lazo Zaia escribió:
> > Exactamente qué errores aparecen cuando ejecutas dpkg --configure
> --pending?
> > El mar 14, 2016 9:36 p.m., "Lacho" <marcoscapel...@gmail.com> escribió:
> >
> >>
> >>
> >> El 03/14/16 a las 22:45, Emilio Lazo Zaia escribió:
> >>> Ejecuta
> >>>
> >>> # dpkg --configure --pending
> >>>
> >>> Allí cosas quedaron sin terminarse de instalar, como libc6.
> >>>
> >>> Si el sistema en su estado actual no es suficiente para iniciar, que
> veo
> >>> que no es el caso, hay que iniciar desde un livecd y luego de montar
> todo
> >>> lo necesario (incluyendo /dev, /de/pts, /proc y /sys) y luego hacer
> >> chroot
> >>> a ese directorio y arreglar desde allí por ejemplo con dpkg.
> >>> El mar 14, 2016 7:58 p.m., "Lacho" <marcoscapel...@gmail.com>
> escribió:
> >>>
> >>>> Hola,
> >>>>
> >>>> Estaba actualizando el SO, cuando se corto la luz y el ups no me ayudo
> >>>> esta vez. Cuando el sistema inicia nuevamente me propongo a restaurar
> la
> >>>> descarga de las actualizaciones y para mi sorpresa pasa lo siguiente:
> >>>>
> >>>>
> >>>> -- Can't set locale; make sure $LC_* and $LANG are correct!
> >>>> perl: warning: Setting locale failed.
> >>>> perl: warning: Please check that your locale settings:
> >>>> LANGUAGE = "es_AR:es",
> >>>> LC_ALL = (unset),
> >>>> LANG = "es_AR.UTF-8"
> >>>> are supported and installed on your system.
> >>>> perl: warning: Falling back to the standard locale ("C").
> >>>> Can't exec "locale": No such file or directory at
> >>>> /usr/share/perl5/Debconf/Encoding.pm line 16.
> >>>> Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp
> >>>> at /usr/share/perl5/Debconf/Encoding.pm line 17.
> >>>> Extracting templates from packages: 100%
> >>>> Preconfiguring packages ...
> >>>> dpkg: warning: 'ldconfig' not found in PATH or not executable
> >>>> dpkg: error: 1 expected program not found in PATH or not executable
> >>>> Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
> and
> >>>> /sbin
> >>>> E: Sub-process /usr/bin/dpkg returned an error code (2)
> >>>> A package failed to install.  Trying to recover:
> >>>> dpkg: warning: 'ldconfig' not found in PATH or not executable
> >>>> dpkg: error: 1 expected program not found in PATH or not executable
> >>>> Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
> and
> >>>> /sbin
> >>>>
> >>>> He probado algunas cosas que vi en foros y no he podido dar con el
> tema.
> >>>>
> >>>> A alguien le ha pasado algo similar ?
> >>>>
> >>>> Enviado desde mi nokia 1100
> >>>> Lacho:~#
> >>>>
> >>>>
> >>>
> >> Hola Emilio,
> >>
> >> Mira lo de las tareas en pending también lo hice y tengo el mismo error.
> >> Con respecto al chroot y el live-cd lo quiero dejar para cuando no tenga
> >> mas opciones. Gracias por las respuestas.
> >> Abrazo
> >>
> >>
> >> --
> >> Enviado desde mi nokia 1100
> >> Lacho:~#
> >>
> >>
> >
> Emilio,
>
> El error es el siguiente:
>
>
> dpkg: warning: 'ldconfig' not found in PATH or not executable
> dpkg: error: 1 expected program not found in PATH or not executable
> Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and
> /sbin
>
> --
> Enviado desde mi nokia 1100
> Lacho:~#
>
>

Re: Problema tras actualizar

[Emilio Lazo Zaia]

Ejecuta

# dpkg --configure --pending

Allí cosas quedaron sin terminarse de instalar, como libc6.

Si el sistema en su estado actual no es suficiente para iniciar, que veo
que no es el caso, hay que iniciar desde un livecd y luego de montar todo
lo necesario (incluyendo /dev, /de/pts, /proc y /sys) y luego hacer chroot
a ese directorio y arreglar desde allí por ejemplo con dpkg.
El mar 14, 2016 7:58 p.m., "Lacho"  escribió:

> Hola,
>
> Estaba actualizando el SO, cuando se corto la luz y el ups no me ayudo
> esta vez. Cuando el sistema inicia nuevamente me propongo a restaurar la
> descarga de las actualizaciones y para mi sorpresa pasa lo siguiente:
>
>
> -- Can't set locale; make sure $LC_* and $LANG are correct!
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = "es_AR:es",
> LC_ALL = (unset),
> LANG = "es_AR.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> Can't exec "locale": No such file or directory at
> /usr/share/perl5/Debconf/Encoding.pm line 16.
> Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp
> at /usr/share/perl5/Debconf/Encoding.pm line 17.
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> dpkg: warning: 'ldconfig' not found in PATH or not executable
> dpkg: error: 1 expected program not found in PATH or not executable
> Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and
> /sbin
> E: Sub-process /usr/bin/dpkg returned an error code (2)
> A package failed to install.  Trying to recover:
> dpkg: warning: 'ldconfig' not found in PATH or not executable
> dpkg: error: 1 expected program not found in PATH or not executable
> Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and
> /sbin
>
> He probado algunas cosas que vi en foros y no he podido dar con el tema.
>
> A alguien le ha pasado algo similar ?
>
> Enviado desde mi nokia 1100
> Lacho:~#
>
>

Re: Modificaciones persistentes en xkb/rules

[Emilio Lazo Zaia]

Hola

On 14/12/15 10:42, Camaleón wrote:

El Sun, 13 Dec 2015 14:36:06 -0430, Emilio Lazo Zaia escribió:


On 12/12/15 12:13, Camaleón wrote:

(...)
Creo que no me has entendido. La estructura la tienes que crear tú, es
decir, lo que tengas bajo "/usr/share/X11/xkb/rules/evdev*" lo pones en
"/
etc/X11/xkb/rules/evdev*" y listo.

Si te fijas, el archivo "/usr/share/X11/xorg.conf.d/50-synaptics.conf"
dice:

# DO NOT EDIT THIS FILE, your distribution will likely overwrite # it
when updating. Copy (and rename) this file into # /etc/X11/xorg.conf.d
first.

Lo que me da a entender que el servidor X tiene en cuenta ambos
directorios.

Entendí, y así tengo mi estructura en /etc/X11/xkb creada por mí pero no
funciona... para que funcione tengo que poner symbols/* en
/usr/share/X11/xkb/symbols, y modificar evdev, evdev.lst y evdev.xml
directamente en /usr/share/X11/xkb/rules/

Ah, vale, entonces eso es distinto porque si no funciona es que ese
directorio para los símbolos no es viable.

Pues en la documentación oficial de Debian no encuentro nada relevante ("/
usr/share/doc/xkb-data/Debian.README") por lo que quizá este apartado no
sea modular y tengas que asegurarte manualmente de que las nuevas
combinaciones y mapeos que generes para el teclado persistan tras las
actualizaciones :-(

Mmm... echa un ojo a este bug donde hablaban del tema:

xkb-data: package overwrite user-modified files without notice
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438940

¡¡Gracias!! Eso no lo había visto; parece que decantaron por lo que dicen
allí, es decir, quitaron /etc/X11/xkb y ya no se puede personalizar nada
allí; el argumento parece ser que no son archivos de configuración y dicen
ellos que algunos paquetes instalaban archivos en /etc/X11/xkb y otros en
/usr/share/X11, y quisieron evitar eso. Mi problema es más bien con los
evdev*, que también necesariamente tienen que estar en /usr y no veo
forma de que lea otro archivo en otra ubicación y lo procese también,
al estilo de lo que pasa con /etc/X11/xorg.conf.d, que procesa el de /usr
y le concatena los de /etc para procesar el resultado final. Eso es lo que
me gustaría pero no parece posible.

Saludos

Re: Modificaciones persistentes en xkb/rules

[Emilio Lazo Zaia]

On 12/12/15 12:13, Camaleón wrote:

(...)
Creo que no me has entendido. La estructura la tienes que crear tú, es
decir, lo que tengas bajo "/usr/share/X11/xkb/rules/evdev*" lo pones en "/
etc/X11/xkb/rules/evdev*" y listo.

Si te fijas, el archivo "/usr/share/X11/xorg.conf.d/50-synaptics.conf"
dice:

# DO NOT EDIT THIS FILE, your distribution will likely overwrite
# it when updating. Copy (and rename) this file into
# /etc/X11/xorg.conf.d first.

Lo que me da a entender que el servidor X tiene en cuenta ambos
directorios.

Entendí, y así tengo mi estructura en /etc/X11/xkb creada por mí pero no
funciona... para que funcione tengo que poner symbols/* en
/usr/share/X11/xkb/symbols, y modificar evdev, evdev.lst y evdev.xml
directamente en /usr/share/X11/xkb/rules/

Re: Modificaciones persistentes en xkb/rules

[Emilio Lazo Zaia]

Hola

On 11/12/15 11:16, Camaleón wrote:

El Thu, 10 Dec 2015 17:06:17 -0430, Emilio Lazo Zaia escribió:

(...)
Te iba a decir precisamente que la estructura de /etc/X11 parece la misma
que la de /usr/share/X11 así que yo empezaría por ahí, es decir, añadir los
archivos que necesites dentro de /etc/X11 (de hecho en algunos archivos de
configuración que hay en /usr/share/X11/* así lo indican).

No he encontrado documentación oficial de Debian respecto a esto pero te
puede servir esta página:

Creating custom keyboard layouts for X11 using XKB
http://michal.kosmulski.org/computing/articles/custom-keyboard-layouts-xkb.html

Y la documentación de X:

The XKB Configuration Guide
http://www.x.org/releases/X11R7.6/doc/xorg-docs/input/XKB-Config.html

Saludos,

Creo que el primer enlace fue el que me ayudó a construir mis archivos 
personalizados de símbolos,
y los archivos evdev*; esa parte ya está lista, ahora el problema es, 
como decía en el primer correo,
la integración a Debian. Actualmente aplico un parche mío a 
/usr/share/X11/xkb/rules/evdev* pero
cuando se actualiza el paquete dueño de ese archivo, pierdo las 
modificaciones y tengo que aplicar

otra vez el parche.

Lo ideal sería que hubiera alguna forma de tener una estructura paralela 
en /etc/X11/xkb tal cual
como es /etc/X11 respecto a /usr/share/X11 como lo indicas, pero eso 
requeriría de más cosas. Creo

que no existe eso todavía.

Otra cosa sería que haga un paquete .deb que contenga esos símbolos y 
que modifique esos archivos
evdev*, pero luego fallaría la verificación MD5 de esos archivos si 
aplicamos debsums a xkb-data que es
a quien le pertenecen esos archivos, entonces se podría cambiar el 
archivo md5
/var/lib/dpkg/info/xkb-data.md5sums para que no falle... no me gusta 
mucho eso tampoco. Si no un

"trigger" que haga esas cosas.

Gracias
Saludos

Modificaciones persistentes en xkb/rules

[Emilio Lazo Zaia]

Hola a todas y todos.

Les planteo un asunto que hace más de tres años quise resolver de forma 
definitiva:


Tengo varias modificaciones en la distribución del teclado, por ejemplo para
agregar los números en supraíndices en las teclas de los números normales
pero con Meta-Shift, también el carácter "∕" que no es el mismo que "/", así
como las comillas tipográficas “ ” „ y otros símbolos más.

Para eso agregué varios archivos de símbolos en /usr/share/X11/xkb/symbols,
y modifiqué /usr/share/X11/xkb/rules/evdev{,.lst,.xml}. Al hacer esto puedo
seleccionar cuándo agregar estas modificaciones en el teclado desde el menú
del teclado de mi escritorio o manejador de ventanas, así como puedo
manejarlo con setxkbmap, todo transparente.

Lo malo de esto es que estoy modificando archivos en /usr y no por ejemplo
en /etc; ya de por sí eso no está bien porque esos son los archivos de los
paquetes, además de que cuando un paquete como xkb-data se actualice,
va a quitar todas mis modificaciones en evdev* y tendré que hacerlas de
nuevo, para lo cual hice un archivo .diff que aplico cuando me doy cuenta
de que no sirven mis personalizaciones del teclado.

Me gustaría saber si Debian cuenta con un lugar para hacer estas 
modificaciones

sin hacerlo de la forma como lo estoy haciendo, y si no existe aún la forma,
propongo que se pueda modificar el teclado en /etc/X11/xkb, cuya estructura
puede ser igual a /usr/share/X11/xkb pero sería modificable por el 
usuario. Los

archivos evdev* que sean leídos de ambos sitios. ¿Esto es posible? ¿Debian
provee otra alternativa para personalizaciones en el teclado sin romper 
con las

políticas propias para no modificar /usr?

Saludos.
Emilio

Re: Modificaciones persistentes en xkb/rules

[Emilio Lazo Zaia]

Hola Gonzalo

On 10/12/15 19:44, Gonzalo Rivero wrote:

El jue, 10-12-2015 a las 17:06 -0430, Emilio Lazo Zaia escribió:

no es /exactamente/ lo mismo, pero en su momento yo cambié algunas
teclas de mi netbook, que tiene teclado en inglés (anulé la ç y la
tecla win para tener < >), pero lo cambié con xmodmap, entonces al
.xinitrc le agregué un comando xmodmap .xmodmaprc


Lo malo es que así creo que cuando se cambia a una cónsola de texto 
(alt-fn) se

pierde la configuración y hay que volver a ejecutar xmodmap.

Lo bueno de modificar las reglas es que es posible poner y quitar las 
modificaciones
desde donde se cambia la configuración del teclado y aparecen las 
personalizaciones
así como las que vienen ya en el sistema como la posición de la tecla 
Ctrl, el
comportamiento de Bloq Mayús, la secuencia para matar el servidor X, y 
demás.
Nuestras modificaciones si les agregamos descripciones como yo las tengo 
aparecen

en el menú del teclado que provea el escritorio o el manejador de ventanas.