Re: ⚠ No actualicéis a Debian 12.3 ⚠

[Javier Barroso]

Buenos días

El lun., 11 dic. 2023 23:11, Javier Silva  escribió:

> El lun, 11 dic 2023, 11:37, Camaleón  escribió:
> >
> > El 2023-12-10 a las 21:13 +0100, Parodper escribió:
> >
> > > O 10/12/23 ás 10:15, Camaleón escribiu:
> > > > Hola,
> > > >
> > > > Pues eso, acabo de leer que se retrasa por problemas con un bug de
> ext4
> > > > (corrupción de archivos) y en Debian recomiendan PAUSAR las
> actualizaciones,
> > > > sobre todo en sistemas que tienen configuradas las actualizaciones
> > > > desatendidas.
> > > >
> > > > Debian 12.3 image release delayed
> > > > https://www.debian.org/News/2023/2023120902
> > > >
> > > > P.S. El asunto se inicia y finaliza con dos símbolos unicode con la
> > > > señal de peligro (⚠) a ver cómo se renderiza :-)
> > > >
> > >
> > > Por desgracia justo se me ocurrió actualizar sin mirar el correo. Creo
> que
> > > llevo ya un día en esa versión, pero por suerte no he notado nada
> fuera de
> > > lo normal.
> > >
> > > La verdad es que el Discover de KDE debería avisar antes de actualizar
> a una
> > > nueva versión. Me suena que Ubuntu lo hacía.
> >
> > Mira a ver si tienes la 12.3 o la 12.4, la acaban de anunciar:
> >
> > Debian 12.4 to supersede Debian 12.3
> > https://www.debian.org/News/2023/2023121002
> >
> > Más que nada, la versión del paquete afectado (el núcleo) que debe ser
> > la versión «6.1.66+1» donde ya se corrige el fallo.
> >
> > sm01@stt008:~$ uname -a
> > Linux stt008 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
> x86_64 GNU/Linux
> >^^
> >
> >
> Hola!
> Me parece que los problemas no acabarán con ext4, esta mañana he
> actualizado a la versión 12.4 (kernel 66) en 2 equipos, uno sobremesa
> que lo tengo conectado por cable y otro portátil conectado por wifi.
>
> El sobremesa funciona aparentemente sin problemas que haya podido
> detectar, pero el portátil sin embargo, me ha dejado de funcionar la
> wifi, lo cual hace lo siguiente:
>
> Intenta conectar por wifi y tras un rato, devuelve error que no ha
> podido conectarse, una vez que ha dado error lanzo sudo journalctl -b
> para ver qué ha ocurrido y no pide contraseña y se queda la terminal
> colgada sin mostrar nada.
>

Creo que es lo mismo que el siguiente bug

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057967

Saludos

On file systems [was: Image handling in mutt]

[tomas]

On Tue, Dec 12, 2023 at 06:04:04AM +0800, jeremy ardley wrote:

[...]

> If you look at the NTFS file system [...]

> Underneath the hood of a NTFS file is alternate data streams (ADS). That is
> a single file can contain main different 'sub files' of completely different
> content type. Each ADS has metadata describing the stream.

I think the idea "was in the air" back then (mid-1980s), covering a wide
field between "rich file metadata" and several "streams" per file, cf.
Apple's HFS, which evolved into HFS+; NTFS is itself an evolution of
OS2's HPFs, etc, etc.

You also see, back then, increasing use of B and B+ trees in different
roles in file systems.

After all, designers moved from company to company and carried with them
ideas and teams. Companies were aggressively hiring people off other
companies.

It's actually risky to say "so and so had first this feature" without
deep research. Where do you put the limit between "file metadata" and
"file substream"? 65K? 4T? HP/UX implemented a file stream mechanism
on top of its Unix file system (those were directories which looked
like files), explicitly to support multi-architecture binaries. Remember
Apple's "fat binaries", which contained a binary for 68K and another
for PowerPC? Those were made with "forks", which was Apple's variant
of "several streams in one file". And so on.

Interesting times :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ⚠ No actualicéis a Debian 12.3 ⚠

[N4ch0]

qn Mon Dec 11, 2023 at 4:42 PM -03, Javier Silva wrote:
> El lun, 11 dic 2023, 11:37, Camaleón  escribió:
> >
> > El 2023-12-10 a las 21:13 +0100, Parodper escribió:
> >
> > > O 10/12/23 ás 10:15, Camaleón escribiu:
> > > > Hola,
> > > >
> > > > Pues eso, acabo de leer que se retrasa por problemas con un bug de ext4
> > > > (corrupción de archivos) y en Debian recomiendan PAUSAR las 
> > > > actualizaciones,
> > > > sobre todo en sistemas que tienen configuradas las actualizaciones
> > > > desatendidas.
> > > >
> > > > Debian 12.3 image release delayed
> > > > https://www.debian.org/News/2023/2023120902
> > > >
> > > > P.S. El asunto se inicia y finaliza con dos símbolos unicode con la
> > > > señal de peligro (⚠) a ver cómo se renderiza :-)
> > > >
> > >
> > > Por desgracia justo se me ocurrió actualizar sin mirar el correo. Creo que
> > > llevo ya un día en esa versión, pero por suerte no he notado nada fuera de
> > > lo normal.
> > >
> > > La verdad es que el Discover de KDE debería avisar antes de actualizar a 
> > > una
> > > nueva versión. Me suena que Ubuntu lo hacía.
> >
> > Mira a ver si tienes la 12.3 o la 12.4, la acaban de anunciar:
> >
> > Debian 12.4 to supersede Debian 12.3
> > https://www.debian.org/News/2023/2023121002
> >
> > Más que nada, la versión del paquete afectado (el núcleo) que debe ser
> > la versión «6.1.66+1» donde ya se corrige el fallo.
> >
> > sm01@stt008:~$ uname -a
> > Linux stt008 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 
> > GNU/Linux
> >^^
> >
> >
> Hola!
> Me parece que los problemas no acabarán con ext4, esta mañana he
> actualizado a la versión 12.4 (kernel 66) en 2 equipos, uno sobremesa
> que lo tengo conectado por cable y otro portátil conectado por wifi.
>
> El sobremesa funciona aparentemente sin problemas que haya podido
> detectar, pero el portátil sin embargo, me ha dejado de funcionar la
> wifi, lo cual hace lo siguiente:
>
> Intenta conectar por wifi y tras un rato, devuelve error que no ha
> podido conectarse, una vez que ha dado error lanzo sudo journalctl -b
> para ver qué ha ocurrido y no pide contraseña y se queda la terminal
> colgada sin mostrar nada.
>
> Intento apagar el equipo y está cómo bloqueado, finalmente pulso el
> botón para apagar, comienza a apagar y se queda esperando a finalizar
> los procesos de cups y packagekit que no acaban, por lo que acabo
> realizando un apagado completo usando el botón físico.
>
> Tras iniciar de nuevo el equipo y antes de que devuelva el error de
> conexión wifi, al ejecutar sudo lo que sea, lo lanzo, entonces pide
> contraseña y funciona, hasta el momento que devuelve el error la wifi.
>
> Regresando al kernel anterior que tenía (no el malo de la 12.3, si no
> el anterior), todo funciona con normalidad, la wifi conecta y sudo
> funciona, el equipo apaga con normalidad.
>
> Cómo mi equipo de sobremesa es el principal, no he tenido tiempo de
> ver en profundidad qué ocurre en el portátil, pero creo que algo no ha
> ido correctamente con éste kernel, además del problema con ext4.
>
> Saludos,
> Javier

Bueno será esperar para el server que se solucioné, mientras en la
portatil ocupo testing, y ya va por el kernel 6.5.0

Espero lo solucionen pronto!

Gracias por la info!

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Charles Curley]

On Tue, 12 Dec 2023 04:15:33 +
Tom Furie  wrote:

> Do we know yet which wifi drivers are "troublesome"? I haven't seen
> anything concrete yet anywhere.

You can read the gory details at Mr. Price's bug report.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057967

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Tom Furie]

Kevin Price  writes:

> 6.1.0-15 brought not only the ext4-bugfix, but along with it introduced
> a terrible new bug: Most computers work fine with -15, except for some
> of those that have wifi, depending upon the driver. There was a certain
> change in Linux's cfg80211 kernel module, which controls wifi. This very
> change was adopted in debian's hastily released 6.1.0-15. Whichever
> computer is affected, then not only loses wifi, but becomes virtually
> unusable, unable to perform simple tasks, such as even to properly shut
> down. So -15 is useless for a number of users. Expect blogposts about
> that as well.

Do we know yet which wifi drivers are "troublesome"? I haven't seen
anything concrete yet anywhere.

Cheers,
Tom

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Kevin Price]

Hey Stella, hey all:

Am 11.12.23 um 19:38 schrieb Stella Ashburne:
> Thank goodness it only happens once in a blue moon.

May I please clarify some basic (mis-)conceptions?

There's "linux-image-amd64". This is a metapackage that contains nothing
but a constructed dependency upon the latest kernel package, such as now
"linux-image-6.1.0-15-amd64". If any debian package A has a dependency
upon B, then installing A will make apt install B as well. If you then
try to uninstall B, either dpkg will refuse, or apt will offer to
uninstall A beforehand. That's the single one purpose metapackages exist
for: to make sure you have another package installed.[1]

Why does debian provide the metapackage "linux-image-amd64"? That's
because every now and then your real kernel package, such as
"linux-image-6.1.0-12-amd64" should be updated to
"linux-image-6.1.0-13-amd64", or so on. Those are not two versions of
the same linux package, but rather they're two seperate packages that
may be installed simultaneously, which apt itself will not "update" from
one to the other. The best way for debian to ensure everyone has current
kernel versions, is to provide a metapackage with a name that doesn't
change, such as "linux-image-amd64". That metapackage, when updated, apt
will recognize as depending upon (requiring) a previously not installed
package, such as "linux-image-6.1.0-13-amd64"

Metapackage "linux-image-amd64" version...
6.1.52-1 depends on linux-image-6.1.0-12-amd64
6.1.55-1 depends on linux-image-6.1.0-13-amd64
6.1.64-1 depends on linux-image-6.1.0-14-amd64 (nasty!)
6.1.66-1 depends on linux-image-6.1.0-15-amd64

Also there are similar "dependencies" in place and in sync with the
kernel one, such as another metapackage "linux-headers-amd64".

Also there might be other mechnisms (autoremove) in place for the
purpose of uninstalling your outdated kernels for disk space, but they
spare the current one as well as its one predecessor as your backup boot
option, just in case any update might go bad. (blue moon) Everything
will be fine. (fingers crossed)

If you happened to update bookworm last weekend, you might have caught
"linux-image-amd64" in version 6.1.64-1. That would have intentionally
pulled and installed the accidentally very dangerous
"linux-image-6.1.0-14-amd64". Let's call it "nasty". Please make very
sure to never boot that. It is known to possibly fry your ext4,
potentially destroying all your data. That's why debian interrupted the
12.3 point-release process very quickly. Unprecedented? I'm certain
there're plenty blog posts and maybe official statements about that to
come, about this one-in-a-IDK-glitch. (Andy had suggested a decade, that
seems about correct.) Could anyone have installed, or even booted nasty
6.1.0-14 in the meantime? Yes. I have, for instance. By chance it didn't
hurt me this time, but I'm not betting again.

Re your situation: To make sure, I highly recommend uninstalling nasty
"linux-image-6.1.0-14-amd64", provided that you have another functioning
kernel version. But if your metapackage "linux-image-amd64" is still
version 6.1.64-1, that would get uninstalled as well. Result: You'd no
longer receive automatic kernel updates, very bad. So maybe better first
update the entire debian, including all the metapackages, and as of now
you'll get linux-image-amd64 in version 6.1.66-1. That no longer
"depends" upon nasty linux-image-6.1.0-14-amd64, but rathermore -15.

(Wait, please read on first!)

That's what might happen once in a blue moon at the very most, and hurt
noone, hopefully. And then debian rectified it in the middle of the
point-release process, by hastily cancelling release 12.3 and replacing
it with 12.4. New kernel version is now 6.1.0-15, no more ext4 frying.
What could possibly go wrong by hastily releasing a debian kernel?

()brace for impact()

6.1.0-15 brought not only the ext4-bugfix, but along with it introduced
a terrible new bug: Most computers work fine with -15, except for some
of those that have wifi, depending upon the driver. There was a certain
change in Linux's cfg80211 kernel module, which controls wifi. This very
change was adopted in debian's hastily released 6.1.0-15. Whichever
computer is affected, then not only loses wifi, but becomes virtually
unusable, unable to perform simple tasks, such as even to properly shut
down. So -15 is useless for a number of users. Expect blogposts about
that as well.

An unusable kernel (-15) once in a blue moon is no big deal, since you
can always boot back into... the... previous... one... Oh, wait. Can you
see where this is getting to? Oh no, not -14? So if you're fortunate
enough for -15 to be working for you, lucky you, maybe just keep -13 as
a backup. I happen to be among a few users who need to run -13 and keep
-12 as backup, just to be careful. Always have one extra, really. This
weekend that little extra carefulness paid for me. Another time, it will
for you.

Given all the above, in conjunction with autoremove, this 

Re: Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[Xavier De Yzaguirre i Maura]

Bona nit gent,
Avui he fet un apt upgrade.
A mi m’ha fallat la wifi amb la 12.4, he seguit treballant amb eth, a veure
si es soluciona aviat.

Xavier De Yzaguirre
Gmail per a mòbil
xdeyzaguirre(at)gmail(dot)com

Re: Image handling in mutt

[jeremy ardley]

On 12/12/23 01:49, Jeremy Nicoll wrote:

There's no concept of filetype in file systems used for the MVS side
of z/OS systems.  (These days there's also Unix/Linux environments
& of course they do have more familiar file naming structures.)



If you look at the NTFS file system - supported by most O/S including 
Debian, the file extension is only of use to user programs to help users 
select they type of files they want e.g. .jpg. It has no meaning at all 
to the applcations that use them.


Underneath the hood of a NTFS file is alternate data streams (ADS). That 
is a single file can contain main different 'sub files' of completely 
different content type. Each ADS has metadata describing the stream.


ADS were first conceived to provide say different language versions of a 
text file, but that is only an example. An ADS in a file could contain 
an executable as well as a text file. Theoretically you could also have 
a video stream and a subtitle stream and multiple audio streams, but 
that is usually better provides by container formats like ogg vorbis


In unixland file systems like ZFS have extended attributes but nothing 
like ADS

Re: zfs load-key on boot randomly reports wrong password if I type too fast

[cen]

That is a good pointer, I will start experimenting with kdbrate and see 
if anything improves.


I did come up with the following contraption which helps at least seeing 
what is going on and so far


it seems that the password is 1 char short on invalid attempt and it is 
usually the last char that seems to be missing.


I will probably figure it out through testing eventually.

#!/bin/bash

MAX_ATTEMPTS=3
attempt=0

while [ "$attempt" -lt "$MAX_ATTEMPTS" ]; do
   printf "ZFS load-key password (attempt $((attempt + 1)) of 
$MAX_ATTEMPTS): "

   PASSWORD=""

   while true; do
   char=$(dd bs=1 count=1 2>/dev/null)

   if [ -z "$char" ] || [ "$char" = "$(printf '\n')" ]; then
   break
   fi

   printf "*"

   PASSWORD="${PASSWORD}${char}"
   done

   echo "$PASSWORD" | /usr/sbin/zfs load-key -a

   if [ $? -eq 0 ]; then
   echo "Password accepted. Exiting."
   exit 0
   else
   echo "Incorrect password. Please try again."
   FIRST="${PASSWORD:0:1}"
   LAST="${PASSWORD: -1}"
   LEN=${#PASSWORD}
   echo "Got $FIRST ... $LAST, length $LEN"
   attempt=$((attempt + 1))
   sleep 3
   fi
done

echo "Maximum attempts reached. Exiting."



On 12/8/23 21:53, David wrote:

On Fri, 8 Dec 2023 at 20:22, cen  wrote:


I have a very weird issue that.. if I type too fast the password is wrong. I 
know this sounds weird but it's true..

I can type the same password fast and it is wrong, then I type it very slowly 
the third time and it works.

I feel like it must be some weird thing with the boot terminal input rate or 
key detection but I have no clue where to start looking.

[...]


Any clues welcome

Hi,

I have experienced something similar, so it does not sound weird to me.
So my solution to my similar problem, might be a useful clue for you :)

I have a Toshiba Satellite Pro laptop [1] whose default keyboard rate settings
cause manual typing of the cryptsetup password entry in the initrd environment
to fail more often than not. A very annoying situation.

I fix this situation by causing /sbin/kbdrate to run inside the initrd
environment,
before the cryptsetup password entry occurs.

A while ago I wrote an email message about how I do that here:
   https://lists.debian.org/debian-user/2022/01/msg00105.html
   https://lists.debian.org/debian-user/2022/01/msg00106.html

Maybe this method can help you with your encrypted ZFS password entry,
I don't know.

[1] Toshiba Satellite Pro C665 Model No PSC2FA-002002

Stuck Key?

[Charles Curley]

I see this sort of message while booting and it continues to show up in
dmesg after booting and after XFCE is up and running:

[  414.569532] atkbd serio0: Unknown key pressed (translated set 2,
code 0xbe on isa0060/serio0). [  414.569560] atkbd serio0: Use
'setkeycodes e03e ' to make it known. [  414.574626] atkbd
serio0: Unknown key released (translated set 2, code 0xbe on
isa0060/serio0). [  414.574661] atkbd serio0: Use 'setkeycodes e03e
' to make it known. [  415.580218] atkbd serio0: Unknown key
pressed (translated set 2, code 0xbe on isa0060/serio0). [  415.580247]
atkbd serio0: Use 'setkeycodes e03e ' to make it known. [
415.585267] atkbd serio0: Unknown key released (translated set 2, code
0xbe on isa0060/serio0). [  415.585295] atkbd serio0: Use 'setkeycodes
e03e ' to make it known. [  416.607258] atkbd serio0: Unknown
key pressed (translated set 2, code 0xbe on isa0060/serio0). [
416.607286] atkbd serio0: Use 'setkeycodes e03e ' to make it
known. [  416.612178] atkbd serio0: Unknown key released (translated
set 2, code 0xbe on isa0060/serio0). [  416.612206] atkbd serio0: Use
'setkeycodes e03e ' to make it known. [  417.617158] atkbd
serio0: Unknown key pressed (translated set 2, code 0xbe on
isa0060/serio0).

How do I determine which key is problematic? Or do I have a defective
keyboard?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Image handling in mutt

[songbird]

debian-u...@howorth.org.uk wrote:
> songbird  wrote:
>>  wrote:
>> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:  
>> >>  wrote:  
>> 
>>   there is rarely a need to e-mail me directly.
>> 
>> >> ...  
>> >> > That's why I cringe when people name executables "foo.sh". What
>> >> > do you do when you decide to rewrite the thing in C (or Rust, or
>> >> > whatever)?
>> >> >
>> >> > Do you go over all calling sites and change the caller's code?  
>> >> 
>> >>   no, i would just consider it a transition or a change
>> >> in versions.  :)  
>> >
>> > Again. You have one script, say /usr/local/bin/ring-the-bells.sh
>> > You use it in several other scripts. If you now re-implement it
>> > in your favourite Pascal as ring-the-bells.pas or something, you
>> > go over all your executables and fix that?
>> >
>> > IMO an executable name should indicate /what/ an executable does,
>> > not /how/.  
>> 
>>   i'm fine with that, but i'm also capable enough to know
>> how to search through a code base to find all the strings
>> i might need to change.
>
> You make the anti-heroic assumption that your code is never used
> outside of your control (or specifically, outside of your code base).

  if someone else uses it then they can do what
they want with it.  i can only control my own local
system and that is all i am concerned about.

  in actual programming with libraries there are
these things called APIs and ABIs and both are 
usually documented and defined if it is important
enough and used enough.  IMO most of my code does
not reach that level of use.


>>   i just scanned a few of my projects and noted i do not
>> use the .sh extension much at all for the binaries/executables,
>> but parts of the code may have that extension.
>
> That's a fine choice, as long as none of the internals will be exposed
> externally, IMHO. Though I confess I do often add a .pl extension to
> filenames :(

  not something i'm worried about for sure.


> PS I suspect tomas sent mail to you for the same reason I nearly did,
> namely that you or your mailer explicitly asked for it with a reply-to
> header. Certainly my claws MUA interprets that as meaning you want a
> copy too.

  correct, so if you are going to reply to me personally
that is the right address to use, but since i interact
with this list via gmane and usenet a followup to me should
go to the list and not to me personally.

  i would assume that group reply is one that everyone
should be using automatically for mail list participation
using a mail client unless the person mentions they are
not subscribed and would like personal replies.


  songbird

Re: ⚠ No actualicéis a Debian 12.3 ⚠

[Javier Silva]

El lun, 11 dic 2023, 11:37, Camaleón  escribió:
>
> El 2023-12-10 a las 21:13 +0100, Parodper escribió:
>
> > O 10/12/23 ás 10:15, Camaleón escribiu:
> > > Hola,
> > >
> > > Pues eso, acabo de leer que se retrasa por problemas con un bug de ext4
> > > (corrupción de archivos) y en Debian recomiendan PAUSAR las 
> > > actualizaciones,
> > > sobre todo en sistemas que tienen configuradas las actualizaciones
> > > desatendidas.
> > >
> > > Debian 12.3 image release delayed
> > > https://www.debian.org/News/2023/2023120902
> > >
> > > P.S. El asunto se inicia y finaliza con dos símbolos unicode con la
> > > señal de peligro (⚠) a ver cómo se renderiza :-)
> > >
> >
> > Por desgracia justo se me ocurrió actualizar sin mirar el correo. Creo que
> > llevo ya un día en esa versión, pero por suerte no he notado nada fuera de
> > lo normal.
> >
> > La verdad es que el Discover de KDE debería avisar antes de actualizar a una
> > nueva versión. Me suena que Ubuntu lo hacía.
>
> Mira a ver si tienes la 12.3 o la 12.4, la acaban de anunciar:
>
> Debian 12.4 to supersede Debian 12.3
> https://www.debian.org/News/2023/2023121002
>
> Más que nada, la versión del paquete afectado (el núcleo) que debe ser
> la versión «6.1.66+1» donde ya se corrige el fallo.
>
> sm01@stt008:~$ uname -a
> Linux stt008 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 
> GNU/Linux
>^^
>
>
Hola!
Me parece que los problemas no acabarán con ext4, esta mañana he
actualizado a la versión 12.4 (kernel 66) en 2 equipos, uno sobremesa
que lo tengo conectado por cable y otro portátil conectado por wifi.

El sobremesa funciona aparentemente sin problemas que haya podido
detectar, pero el portátil sin embargo, me ha dejado de funcionar la
wifi, lo cual hace lo siguiente:

Intenta conectar por wifi y tras un rato, devuelve error que no ha
podido conectarse, una vez que ha dado error lanzo sudo journalctl -b
para ver qué ha ocurrido y no pide contraseña y se queda la terminal
colgada sin mostrar nada.

Intento apagar el equipo y está cómo bloqueado, finalmente pulso el
botón para apagar, comienza a apagar y se queda esperando a finalizar
los procesos de cups y packagekit que no acaban, por lo que acabo
realizando un apagado completo usando el botón físico.

Tras iniciar de nuevo el equipo y antes de que devuelva el error de
conexión wifi, al ejecutar sudo lo que sea, lo lanzo, entonces pide
contraseña y funciona, hasta el momento que devuelve el error la wifi.

Regresando al kernel anterior que tenía (no el malo de la 12.3, si no
el anterior), todo funciona con normalidad, la wifi conecta y sudo
funciona, el equipo apaga con normalidad.

Cómo mi equipo de sobremesa es el principal, no he tenido tiempo de
ver en profundidad qué ocurre en el portátil, pero creo que algo no ha
ido correctamente con éste kernel, además del problema con ext4.

Saludos,
Javier

Re: Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[Lluís Gras]

>Què tal vosaltres?
Avui he pogut actualitzar i reinstal·lar unattended-upgrades

Tot en màquines de pobres, mini-pc, etc ... ;-)

Missatge de Àlex  del dia dl., 11 de des. 2023 a les
20:16:

> Bona nit,
>
>
> Els que treballeu amb Debian estable i aneu actualitzant cada dia, us
> heu trobat situacions estranyes en el pas de Debian 12.2 a Debian 12.4
> les últimes 24 hores?
>
>
> Abans d'ahir Debian estable s'actualitzava de Debian 12.2 a Debian 12.3
>
> Però per un error al nucli que portava, linux-image-6.1.0-14, van
> enrederir l'actualització un dia.
>
> Ahir a la nit ja es podia actualitzar a Debian 12.4 amb un nucli
> linux-image-6.1.0-15
>
> Però en actualitzar ordinadors a casa i a la feina, els PC han continuat
> funcionant, però els iMac i macMini s'han quedat sense xarxa, i tampoc
> apaguen bé per tot una sèrie de processos que no es tanquen bé:
> wpasuplicant, avahi, que deixen al systemd esperant eternament.
>
> Si els Mac actualitzats a Debian 12.4 els arrenco amb l'anterior nucli
> 6.1.0-13 tornen a funcionar bé, així que suposo que el problema està al
> nou nucli 6.1.0-15.
>
>
> Què tal vosaltres?
>
>
> Gràcies
>
>
>  Àlex
>
>
>

Re: Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[tictacbum]

Així no reiniciaré el portàtil fins que surti l'actualització,
gràcies per avisar!

Missatge de Àlex  del dia dl., 11 de des. 2023 a les
20:23:

> Sí, definitivament és just el problema que estava patint:
>
> https://www.phoronix.com/news/Linux-6.6.6-Released
>
>

Re: Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[Àlex]

Sí, definitivament és just el problema que estava patint:

   https://www.phoronix.com/news/Linux-6.6.6-Released

Re: Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[Àlex]

Ara trobo que fa unes hores que han solucionat un problema a aquest 
kernel amb la wifi. Potser és el problema que he patit als Mac. A veure 
si el paquet Debian surt en breu:



Greg Kroah-Hartman has announced the release of the 6.6.6 
 and 6.1.67 
 stable kernels. Both contain a single 
reversion of the "wifi: cfg80211: fix CQM for non-range use" patch.



https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=db46c77f3d51d24402731ea181b2a591e7dd1ac3

Us ha fallat l'actualització d'ahir de Debian 12.2 a Debian 12.4 ?

[Àlex]

Bona nit,


Els que treballeu amb Debian estable i aneu actualitzant cada dia, us 
heu trobat situacions estranyes en el pas de Debian 12.2 a Debian 12.4 
les últimes 24 hores?



Abans d'ahir Debian estable s'actualitzava de Debian 12.2 a Debian 12.3

Però per un error al nucli que portava, linux-image-6.1.0-14, van 
enrederir l'actualització un dia.


Ahir a la nit ja es podia actualitzar a Debian 12.4 amb un nucli 
linux-image-6.1.0-15


Però en actualitzar ordinadors a casa i a la feina, els PC han continuat 
funcionant, però els iMac i macMini s'han quedat sense xarxa, i tampoc 
apaguen bé per tot una sèrie de processos que no es tanquen bé: 
wpasuplicant, avahi, que deixen al systemd esperant eternament.


Si els Mac actualitzats a Debian 12.4 els arrenco amb l'anterior nucli 
6.1.0-13 tornen a funcionar bé, així que suposo que el problema està al 
nou nucli 6.1.0-15.



Què tal vosaltres?


Gràcies


    Àlex

Re: Thinkpad x13 AMD Ryzen microphone not working in Debian Bookworm

[Jiri Kanicky]

I found out that when I plugin a headset the microphone works. So it 
seems that this is related only to the internal microphone.


*-multimedia:2
   description: Audio device
   product: Family 17h/19h HD Audio Controller
   vendor: Advanced Micro Devices, Inc. [AMD]
   physical id: 0.6
   bus info: pci@:c3:00.6
   logical name: card1
   logical name: /dev/snd/controlC1
   logical name: /dev/snd/hwC1D0
   logical name: /dev/snd/pcmC1D0c
   logical name: /dev/snd/pcmC1D0p
   version: 00
   width: 32 bits
   clock: 33MHz
   capabilities: bus_master cap_list
   configuration: driver=snd_hda_intel latency=0
   resources: irq:107 memory:905c-905c7fff
 *-input:0
  product: HDA Digital PCBeep
  physical id: 0
  logical name: input15
  logical name: /dev/input/event13
  capabilities: pci
 *-input:1
  product: HD-AudioGeneric Mic
  physical id: 1
  logical name: input19
  logical name: /dev/input/event14
 *-input:2
  product: HD-AudioGeneric Headphone
  physical id: 2
  logical name: input20
  logical name: /dev/input/event15

Jiri
--

On 10/12/23 20:30, Jiri Kanicky wrote:


I have installed Debian Bookworm on X13 with AMD Ryzen 7840U and 
microphone is not working. It shows inactive.


I use KDE and installed pipewire. The mic did not work since base install.

Any advise?

$ inxi -A Audio: Device-1: AMD Rembrandt Radeon High Definition Audio 
driver: snd_hda_intel Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor 
driver: N/A Device-3: AMD Family 17h/19h HD Audio driver: 
snd_hda_intel API: ALSA v: k6.5.0-0.deb12.1-amd64 status: kernel-api 
Server-1: PipeWire v: 0.3.65 status: active $ inxi CPU: 8-core AMD 
Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (-MT MCP-) speed/min/max: 
1337/400/5132:6076:5605:5289:5447:5760:5918 MHz Kernel: 
6.5.0-0.deb12.1-amd64 x86_64 Up: 6m Mem: 4206.1/30781.0 MiB (13.7%) 
Storage: 476.94 GiB (3.3% used) Procs: 370 Shell: Bash inxi: 3.3.26

$ pactl list cards
Card #44
     Name: alsa_card.pci-_c3_00.1
     Driver: alsa
     Owner Module: n/a
     Properties:
     api.acp.auto-port = "false"
     api.acp.auto-profile = "false"
     api.alsa.card = "0"
     api.alsa.card.longname = "HD-Audio Generic at 0x905c8000 irq 
106"
     api.alsa.card.name = "HD-Audio Generic"
     api.alsa.path = "hw:0"
     api.alsa.use-acp = "true"
     api.dbus.ReserveDevice1 = "Audio0"
     device.api = "alsa"
     device.bus = "pci"
     device.bus_path = "pci-:c3:00.1"
     device.description = "Rembrandt Radeon High Definition Audio 
Controller"
     device.enum.api = "udev"
     device.icon_name = "audio-card-analog-pci"
     device.name = "alsa_card.pci-_c3_00.1"
     device.nick = "HD-Audio Generic"
     device.plugged.usec = "5163628"
     device.product.id = "0x1640"
     device.product.name = "Rembrandt Radeon High Definition Audio 
Controller"
     device.subsystem = "sound"
     sysfs.path = 
"/devices/pci:00/:00:08.1/:c3:00.1/sound/card0"
     device.vendor.id = "0x1002"
     device.vendor.name = "Advanced Micro Devices, Inc. [AMD/ATI]"
     media.class = "Audio/Device"
     factory.id = "14"
     client.id = "34"
     object.id = "44"
     object.serial = "44"
     object.path = "alsa:pcm:0"
     alsa.card = "0"
     alsa.card_name = "HD-Audio Generic"
     alsa.long_card_name = "HD-Audio Generic at 0x905c8000 irq 106"
     alsa.driver_name = "snd_hda_intel"
     device.string = "0"
     Profiles:
     off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
     output:hdmi-stereo: Digital Stereo (HDMI) Output (sinks: 1, 
sources: 0, priority: 5900, available: no)
     output:hdmi-stereo-extra1: Digital Stereo (HDMI 2) Output 
(sinks: 1, sources: 0, priority: 5700, available: no)
     output:hdmi-stereo-extra2: Digital Stereo (HDMI 3) Output 
(sinks: 1, sources: 0, priority: 5700, available: no)
     output:hdmi-stereo-extra3: Digital Stereo (HDMI 4) Output 
(sinks: 1, sources: 0, priority: 5700, available: no)
     output:hdmi-surround: Digital Surround 5.1 (HDMI) Output 
(sinks: 1, sources: 0, priority: 800, available: no)
     

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Albretch Mueller]

On 12/11/23, Greg Wooledge  wrote:
> 1) Many implementations of echo will interpret parts of their argument(s),
>in addition to processing options like -n.  If you want to print a
>variable's contents to standard output without *any* interpretation,
>use printf.
>
> printf %s "$myvar"
> printf '%s\n' "$myvar"
>

 I will use "printf ..." from now on.

> 2) As tomas already told you, the square brackets in
>
> tr -c -s '[A-Za-z0-9.]' _
>
>are literal.  You're using a command which will keep left and right
>square brackets in the input, *not* replacing them with underscores.
>This may not be what you want.

 My mistake, even though it didn't get in the way of what I was trying
to do. I replaced :alnum: by what I thought it meant and left the
brackets.

> 3) In locales other than C or POSIX, ranges like A-Z are *not* necessarily
>synonyms for [:upper:].  As I've already mentioned, GNU tr is known to
>contain bugs, so you're getting lucky here.  The bugs in GNU tr happen
>to work the way you're expecting, so that A-Z is treated like [:upper:]
>when it should not be.  If at some point in the future GNU tr is fixed
>to conform to POSIX, your script may break.
>
>The correct tr command you should be using if you want to retain
>accented letters (as defined in your locale) is:
>
> tr -c -s '[:alnum:].' _
>
>If you want to discard accented letters, then either of these is OK:
>
> LC_COLLATE=C tr -c -s '[:alnum:].' _
> LC_COLLATE=C tr -c -s 'A-Za-z0-9.' _
>

 I like your second one liner much better (LC_COLLATE=C tr -c -s 'A-Za-z0-9.' _)

 I tend to avoid '[:alnum:].' because the intended meaning of
"ALphabetic et NUMeric" characters, even though it depends on the
locale has a strong ASCII accent to it.

> Thus, we come full circle.

 Yes, we did. Thank you, lbrtchx

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Greg Wooledge]

On Mon, Dec 11, 2023 at 07:38:02PM +0100, Stella Ashburne wrote:
> Please see Greg's reply to my other post (URL: 
> https://lists.debian.org/debian-user/2023/12/msg00640.html).
> 
> For your convenience, I quote a section of his reply (see below):
> 
> "Yes, because linux-image-amd64 *right now* depends on 
> linux-image-6.1.0-15-amd64.  Removing linux-image-6.1.0-15-amd64 will 
> therefore remove linux-image-amd64."
> 
> Removing the buggy linux-image-6.1.0-14-amd64 will also remove the 
> metapackage linux-image-amd64.

This is incorrect.  I'm not even sure how you came up with this idea.

If you have linux-image-amd64 version 6.1.66-1, it depends on
linux-image-6.1.0-15-amd64 and NOT on linux-image-6.1.0-14-amd64.

In this situation, nothing depends on linux-image-6.1.0-14-amd64 so
you may remove it without worry.  It's no different from removing any
other old kernel images.  So long as they're not the current one, they
can be removed freely.

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Stella Ashburne]

Hi Andy

> Sent: Monday, December 11, 2023 at 11:25 PM
> From: "Andrew M.A. Cater" 
> To: debian-user@lists.debian.org
> Subject: Re: From which kernel should I upgrade my installed Debian to 
> linux-image-6.1.0-15-amd64?
>
>
> If you're not currently booted into the erroneous 6.1.0-14 - don't boot into
> it and you can safely apt-get remove it (or equivalent).
>
Your above statement implies strongly that one boots up their device using 
linux-image-6.1.0-13-amd64

> If you also install linux-image-amd64 if you removed it - you should end
> up with 6.1.0-15 and 6.1.0-13 available to you.
>
Please see Greg's reply to my other post (URL: 
https://lists.debian.org/debian-user/2023/12/msg00640.html).

For your convenience, I quote a section of his reply (see below):

"Yes, because linux-image-amd64 *right now* depends on 
linux-image-6.1.0-15-amd64.  Removing linux-image-6.1.0-15-amd64 will therefore 
remove linux-image-amd64."

Removing the buggy linux-image-6.1.0-14-amd64 will also remove the metapackage 
linux-image-amd64.

> This isn't something that happens often - ideally not more than once a
> decade - so we haven't had a lot of practice at this.

Thank goodness it only happens once in a blue moon.

Someone might wish to add to Debian's wiki on how to deal with the situation of 
having a buggy kernel made available via the official repos, a few hours later 
a warning against upgrading to it and the release team failing to pull it out 
of the official repos.

Best wishes.

Stella

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[debian-user]

Albretch Mueller  wrote:
> echo "abc123" > file.txt
> ftype=$(file --brief file.txt)
> echo "// __ \$ftype: |${ftype}|"
> ftypelen=${#ftype}
> echo "// __ \$ftypelen: |${ftypelen}|"
> 
> # removing spaces ...
> ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
> '[A-Za-z0-9.]' '_');
> echo "// __ \$ftype2: |${ftype2}|"
> ftype2len=${#ftype2}
> echo "// __ \$ftype2len: |${ftype2len}|"
> 
> lbrtchx

Short answer. tr doesn't append anything. echo does output a linefeed
at the end of the string, unless you stop it. tr dutifully translates
that to an underscore.

Re: Image handling in mutt

[Jeremy Nicoll]

On Mon, 11 Dec 2023, at 13:16, Greg Wooledge wrote:

> 4) File extensions are used by programs on every operating system.

Certainly on many OSes, but not all.

They're not present on native RISC OS systems (as in ex-Acorn micros).
Filetype data IS stored, but it is in files' metadata.



There's no concept of filetype in file systems used for the MVS side
of z/OS systems.  (These days there's also Unix/Linux environments
& of course they do have more familiar file naming structures.)

By convention collections of separate files might all be kept in a set
very vaguely analagous to a directory - though with no parent
directory nor child sub-directories), known as a "PDS".  The name
of a PDS is fairly arbitrary (subject to installation conventions & 
security restrictions) & the names of files within ("members") also
have no real meaning unless an application chooses to interpret
their names in some special way.

One refers to a PDS as a whole by its name, eg "MY.SAMPLE.PDS"
& to a member within it, eg the file named "FRED", as
"MY.SAMPLE.PDS(FRED)".

While there are conventions for names of these PDSes, there's no
requirement that every file within, say "MY.SAMPLE.ASM" would
contain assembler source.  Often only some of the files would do
with others containing notes etc.

If a PDS's name looks like it might contain binary executables AND
it is actually used in a place where that would be expected, then you
can infer that it does do; you wouldn't find plain text notes, sample
data etc alongside the executables (because other characteristics
of those file sets allow them only to hold executables).

You cannot tell from a file's name whether it's held on disk or 
(virtual) tape or real tape, nor which device it's currently on.

-- 
Jeremy Nicoll - my opinions are my own.

Re: "echo" literally in sh scripts (was: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...)

[Greg Wooledge]

On Mon, Dec 11, 2023 at 10:16:35AM -0500, Stefan Monnier wrote:
> > 1) Many implementations of echo will interpret parts of their argument(s),
> >in addition to processing options like -n.  If you want to print a
> >variable's contents to standard output without *any* interpretation,
> >use printf.
> >
> > printf %s "$myvar"
> > printf '%s\n' "$myvar"
> 
> Interesting.  I used the following instead:
> 
> bugit_echo () {
> # POSIX `echo` has all kinds of "features" we don't want, such as
> # handling of \c and -n.
> cat < $*
> ENDDOC
> }

That requires an external command (one fork), plus whatever overhead is
used by the << implementation (temp file or pipe, depending on shell and
version).  It's not wrong, but an implementation using nothing but
builtins is usually preferable.

echo() { printf '%s\n' "$*"; }

It's also worth mentioning that both of these rely on the expansion of $*
with a default or nearly-default IFS variable.  If you want it to work
when IFS may have been altered, you can do this in bash:

echo() { local IFS=' '; printf '%s\n' "$*"; }

In sh, you'd need to fork a subshell:

echo() { (IFS=' '; printf '%s\n' "$*"); }

Or if you're a golfer:

echo() (IFS=' '; printf '%s\n' "$*")

I *really* dislike that syntax, but that's just me.  Some people use it.

Re: EIO error - I/O error

[Michael Kjörling]

On 11 Dec 2023 15:46 +0100, from rachid.oub...@elum-energy.com (Rachid Oubelk):
> Dear support team,

A clarification; this mailing list is not a "support team". It's a
group of people, many of which who share little more than the fact
that they use Debian to varying degree, and with varying levels of
experience and expertise.

You should treat any response you get from this list accordingly, and
know that nobody here is under any obligation. If you are running
mission-critical applications on Debian, you may want to investigate
paid support through some company which provides that service.

_That said,_


> Please, we are using Debian GNU/Linux 9.13 (stretch) installed on a
> UC-8112-LX controller version 3.4,

I am not familiar with the UC-8112-LX controller. Also note that
Debian 9 receives very limited updates by now, being on ELTS since
mid-2022.

> and it shows the error EIO  ( IO error
> ).
>
> Could you please help us understand the cause of this error? Very urgent.

_Usually_ an I/O error is caused by a storage-level problem such as a
sector read error from which the storage device could not recover by
using the error-correcting data stored on it. You should see more
detailed information in the kernel logs; check /var/log/syslog (exact
locations can vary depending on your syslogd configuration) and the
output of dmesg (may have been rotated out, especially if the system
has been rebooted) for a period around the time of the error.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: IMPORTANT: do NOT upgrade to new stable point release

[Махно]

I upgraded all machines to 6.1.0-15-amd64 (6.1.66-1). Works great and
no problems!

2023-12-11, pr, 18:47 Махно  rašė:
>
> I upgraded all machines to 6.1.0-15-amd64 (6.1.66-1). Works great and
> no problems!
>
>
> 2023-12-11, pr, 18:40 Michael Kjörling <2695bd53d...@ewoof.net> rašė:
> >
> > On 11 Dec 2023 11:34 -0500, from g...@extremeground.com (Gary Dale):
> > > Pleased to note that 6.1.0-15 seems to have hit the mirrors now. I assume
> > > this is the fixed version.
> >
> > It certainly should be, but some people have reported other issues
> > with the new 12.4 upgrade. See other recent posts to this list.
> >
> > --
> > Michael Kjörling  https://michael.kjorling.se
> > “Remember when, on the Internet, nobody cared that you were a dog?”
> >

Re: IMPORTANT: do NOT upgrade to new stable point release

[Махно]

I upgraded all machines to 6.1.0-15-amd64 (6.1.66-1). Works great and
no problems!


2023-12-11, pr, 18:40 Michael Kjörling <2695bd53d...@ewoof.net> rašė:
>
> On 11 Dec 2023 11:34 -0500, from g...@extremeground.com (Gary Dale):
> > Pleased to note that 6.1.0-15 seems to have hit the mirrors now. I assume
> > this is the fixed version.
>
> It certainly should be, but some people have reported other issues
> with the new 12.4 upgrade. See other recent posts to this list.
>
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>

Re: IMPORTANT: do NOT upgrade to new stable point release

[Michael Kjörling]

On 11 Dec 2023 11:34 -0500, from g...@extremeground.com (Gary Dale):
> Pleased to note that 6.1.0-15 seems to have hit the mirrors now. I assume
> this is the fixed version.

It certainly should be, but some people have reported other issues
with the new 12.4 upgrade. See other recent posts to this list.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: IMPORTANT: do NOT upgrade to new stable point release

[Gary Dale]

On 2023-12-09 13:09, Dan Ritter wrote:


https://fulda.social/@Ganneff/111551628003050712

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

The new kernel release is reported to contain an ext4 data
corruption bug. It's prudent not to upgrade, or if you have
started to upgrade, not to reboot, until a new kernel release
is prepared.


-dsr-

Pleased to note that 6.1.0-15 seems to have hit the mirrors now. I 
assume this is the fixed version.

Re: Image handling in mutt

[David Wright]

On Mon 11 Dec 2023 at 10:03:38 (-0500), Pocket wrote:
> On 12/11/23 09:52, David Wright wrote:
> > On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
> > > > On Dec 10, 2023, at 3:05 PM, David Wright wrote:
> > > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> > > > > > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > > > > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > > > > > > I'm on Debian bookworm, using neomutt for email. Where there is 
> > > > > > > an image to
> > > > > > > view, viewing it in neomutt calls up one of the ImageMagick 
> > > > > > > programs. I've set
> > > > > > > the mailcap_path variable in my neomutt config to point to 
> > > > > > > ~/.mailcap,
> > > > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
> > > > a specially crafted subset of /etc/mailcap with a few additions
> > > > (like converting webp to a jpeg rather than opening in gimp,
> > > > and playing midi files the way I want).
> > > > 
> > > > > > > and
> > > > > > > set an entry in there for image/jpg to point to /usr/bin/feh. 
> > > > > > > I've even set
> > > > > >   ↑↑↑ try jpeg
> > > > > > 
> > > > > > > the "display" alternative to feh with update-alternatives. Still, 
> > > > > > > mutt is
> > > > > > > calling an imagemagick program to display jpgs.
> > > > > > > 
> > > > > > > First, if alternatives doesn't point to the imagemagick program, 
> > > > > > > and the
> > > > > > > mailcap file doesn't point to it, and there's nothing in the 
> > > > > > > neomutt config
> > > > > > > pointing to the imagemagick program, then where the heck is it 
> > > > > > > getting that
> > > > > > > as the program to use to display images?
> > > > An email would contain headers with the attachment.
> > > > 
> > > > ↓
> > > >   Content-Type: image/jpeg
> > > >   Content-Disposition: attachment; filename="don.jpg"
> > > >   Content-Transfer-Encoding: base64
> > > > 
> > > > By default, mutt searches six directories for a mailcap file. When
> > > > found, the line in the mailcap starting with image/jpeg selects the
> > > > program to run.
> > > > 
> > > > If you see an extension in a mailcap field like   nametemplate=%s.jpg
> > > > that's to show that a filename matching that pattern should be given
> > > > to a copy of the attachment to satisfy the program that's going to
> > > > read it. But it's the attachment /content type/ that selects the
> > > > program, not the extension¹.
> > > > 
> > > > > > > Second, how do I fix this so that mutt uses feh to display images?
> > > > > I can't believe that worked. The /etc/mailcap has both (jpg and 
> > > > > jpeg), and
> > > > > the files I was looking at had a "jpg" extension.
> > > > > 
> > > > > But thanks for the tip.
> > > > A couple of programs in my /etc/mailcap (gpicview and gm) have
> > > > image/jpg lines, duplicating the image/jpeg entries, perhaps
> > > > as a "catch-all" for malformed emails containing image/jpg.
> > > > I don't know whether image/jpg is an official legacy type/iana-token.
> > > > 
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > >   term is clearly appropriate, as a glance at /etc/mime.types
> > > >   demonstrates. The literature is full of the term.
> > > > 
> > > >   I wouldn't want to use "suffix" myself, as it's too general:
> > > >   anything stuck on the end is a suffix, but not necessarily
> > > >   a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > > File names in Linux are a character string of 255 chars.  Again there are 
> > > not file extensions in a Linux file name.
> > > 
> > > People are conflating the issue.
> > > 
> > > Read the code, code good.
> > So you've said five or six times already. The trouble is that it's
> > difficult to square this with documentation not only of the OS in
> > the widest sense, but also the linux kernel itself, which uses the
> > term extension.
> > 
> > It's often stated, and has been in this thread, that the kernel uses
> > magic numbers at the start of executables rather than filename
> > extensions, and while this is true, it's not the only method.
> > 
> > Take a look, for example, at this file (choose your version):
> > 
> >linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst
> > [ … ]
> > 
> Where exactly is the variable defined in  the kernel source that a
> file extension is defined
> 
> filename is defined as a char "string" of 255 chars, so where is
> extension defined?

In fs/binfmt_misc.c (extracts below are from 5.10, which I happen to
have installed here):

  // SPDX-License-Identifier: GPL-2.0-only
  /*
   * binfmt_misc.c
   *
   * Copyright (C) 1997 Richard Günther
   *
   * binfmt_misc detects binaries via a magic or filename extension and invokes
   * a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for 
more details.
   */

  typedef struct {
  struct 

Re: EIO error - I/O error

[Marco Moock]

Am 11.12.2023 um 16:39:47 Uhr schrieb Rachid Oubelk:

> We received this message from our software based on the errno utility
> (Linux Errors). The Debian used is installed on a controller that has
> two serial ports (RTU) and two LAN ports (TCP). When we test these
> two serial ports, we notice this error.

Can you connect the serial port to a computer and rund minicom to see
the tty?
Does that work?

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 10:10:31AM -0500, Stefan Monnier wrote:

[...]

> I think what you're saying is that it would make sense to use
> a dedicated extension for executables, like, say, `.exe`,
> since "all users rely on it being" executable.

I'd prefer ".com", but hey ;-)

> FWIW, I agree, but this ship sailed a long time ago.
> 
> 
> Stefan "who likes types"

Yes, but I know your style well enough to know you'd never encode
the type in the variable name ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Andrew M.A. Cater]

On Mon, Dec 11, 2023 at 02:25:23PM +0100, Kevin Price wrote:
> Am 11.12.23 um 14:16 schrieb Stella Ashburne:
> > Suppose I wish to upgrade to linux-image-6.1.0-15-amd64.
> 
> If that were the case, or maybe better to a newer one.
> 
> > Should I do it after booting my device into
> > (1) linux-image-6.1.0-14-amd64 (the problematic kernel)
> 
> NO. Don't ever boot that as it might then toast your ext4.
> 
> > (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one)
> 
> Yes.
> 
> > (3) doesn't matter which kernel to upgrade from
> 
> Yes, it largely doesn't matter, apart from the exception above.
> 
> HTH
> -- 
> Kevin Price
>

If, this afternoon (UK timezone), you do a full upgrade - you'll get
6.1.0-15 and that's fine.

If you're not currently booted into the erroneous 6.1.0-14 - don't boot into
it and you can safely apt-get remove it (or equivalent).

If you also install linux-image-amd64 if you removed it - you should end
up with 6.1.0-15 and 6.1.0-13 available to you.

This isn't something that happens often - ideally not more than once a 
decade - so we haven't had a lot of practice at this. On average, it's
OK to just upgrade to the next sequentially numbered kernel and reboot.
This once, it isn't.

All the very best, as ever,

Andy Cater
[amaca...@debian.org] 

Re: Image handling in mutt

[David Wright]

On Mon 11 Dec 2023 at 10:07:28 (+1100), Zenaan Harkness wrote:
> > Second, how do I fix this so that mutt uses feh to display images?
> 
> Here is my mailcap entry, which works for me - had to deal with
> annoying filename munging by mutt, and getting the "close the viewer"
> bit working - this is quite a few years ago and now I can't even
> remember why the ; test=test -n "$DISPLAY" or the sleep are needed,
> but they were - heuristics annoy, but sometimes they are necessary:

I'm not familiar with the mutt filename munging problem etc. As for
test=test -n "$DISPLAY", I presume it's there to prevent trying to
run graphical commands on a text terminal, where DISPLAY is unset.

> image/*; (mv %s %s-\; feh -Z %s-\; rm -f %s-)& sleep 0.2s; test=test
> -n "$DISPLAY"

I've never trusted feh since the time when its default slideshow mode
had the astonishing behaviour of modifying the source file if you,
say, rotated the display of the image. They may have fixed it, but
I've stuck with alternatives.

I use:

  image/jpeg; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=JPEG Image
  image/png; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=PNG Image
  image/gif; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=GIF Image
  image/webp; convert webp:- jpeg:- | /usr/bin/xli -quiet stdin; test=test -n 
"$DISPLAY"; description=WEBP Image
  image/tiff; convert tiff:- jpeg:- | /usr/bin/xli -quiet stdin; test=test -n 
"$DISPLAY"; description=TIFF Image

> Similarly my mailcap entry for pdf files:
> 
> application/pdf; (mv %s %s-.pdf\; evince %s-.pdf 2\>\&1 \; rm -f
> %s-.pdf)& sleep 0.2s; test=test -n "$DISPLAY"
> image/pdf; /usr/bin/display-im6 %s; test=test -n "$DISPLAY"

Does evince need a mouse click to exit, and is that what you're
referring to with ‘getting the "close the viewer" bit working’?
That would rule it out for me.

I use:

  application/pdf; /usr/bin/xpdf -fullscreen %s; test=test -n "$DISPLAY"; 
description=Portable Document Format; nametemplate=%s.pdf

> Finally, occasionally I need to cleanly dump html, this one seems a bit 
> simpler:
> 
> text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s

I prefer to navigate any structure, with:

  text/html; /usr/bin/lynx -force-html -localhost -stdin

and I find this useful very occasionally:

  text/markdown; /usr/bin/pandoc %s | /usr/bin/lynx -localhost -stdin

Adding -localhost prevents any external links from working.

Cheers,
David.

Re: Image handling in mutt

[debian-user]

songbird  wrote:
>  wrote:
> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:  
> >>  wrote:  
> 
>   there is rarely a need to e-mail me directly.
> 
> >> ...  
> >> > That's why I cringe when people name executables "foo.sh". What
> >> > do you do when you decide to rewrite the thing in C (or Rust, or
> >> > whatever)?
> >> >
> >> > Do you go over all calling sites and change the caller's code?  
> >> 
> >>   no, i would just consider it a transition or a change
> >> in versions.  :)  
> >
> > Again. You have one script, say /usr/local/bin/ring-the-bells.sh
> > You use it in several other scripts. If you now re-implement it
> > in your favourite Pascal as ring-the-bells.pas or something, you
> > go over all your executables and fix that?
> >
> > IMO an executable name should indicate /what/ an executable does,
> > not /how/.  
> 
>   i'm fine with that, but i'm also capable enough to know
> how to search through a code base to find all the strings
> i might need to change.

You make the anti-heroic assumption that your code is never used
outside of your control (or specifically, outside of your code base).

>   i just scanned a few of my projects and noted i do not
> use the .sh extension much at all for the binaries/executables,
> but parts of the code may have that extension.

That's a fine choice, as long as none of the internals will be exposed
externally, IMHO. Though I confess I do often add a .pl extension to
filenames :(

PS I suspect tomas sent mail to you for the same reason I nearly did,
namely that you or your mailer explicitly asked for it with a reply-to
header. Certainly my claws MUA interprets that as meaning you want a
copy too.

"echo" literally in sh scripts (was: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...)

[Stefan Monnier]

> 1) Many implementations of echo will interpret parts of their argument(s),
>in addition to processing options like -n.  If you want to print a
>variable's contents to standard output without *any* interpretation,
>use printf.
>
> printf %s "$myvar"
> printf '%s\n' "$myvar"

Interesting.  I used the following instead:

bugit_echo () {
# POSIX `echo` has all kinds of "features" we don't want, such as
# handling of \c and -n.
cat <

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 09:34:09 -0500, Pocket wrote:
> On 12/11/23 09:04, Vincent Lefevre wrote:
> > On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> > > 2) When *receiving* email, mutt will use the sender's MIME type label
> > > to decide how to deal with the attachment.
> > But the notion of filename extension is even used in this context too.
> > Quoting the Mutt manual:
> > 
> > 
> > nametemplate=
> >This field specifies the format for the file denoted by %s in
> >the command fields. Certain programs will require a certain
> >file extension, for instance, to correctly view a file. For
> >instance, lynx will only interpret a file as text/html if the
> >file ends in .html. So, you would specify lynx as a text/html
> >viewer with a line in the mailcap file like:
> > 
> > text/html; lynx %s; nametemplate=%s.html
> > 
> > 
> > This is due to
> > 
> > > 3) Many other programs besides mutt will also use file extensions to
 
> > > determine how to deal with input files.
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct 
> filename {
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct
>  filename, iname) % sizeof(long) == 0);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> file *file_open_name(struct filename *, int, umode_t);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_flags(const char __user *, int, int *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_uflags(const char __user *, int);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname(const char __user *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_kernel(const char *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void 
> putname(struct filename *name);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:  
> struct filename *name;
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chdir(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chroot(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chown(const char *filename, uid_t user, gid_t group, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chmod(const char *filename, umode_t mode);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_eaccess(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_stat(const char *filename, struct kstat *stat, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_mknod(const char *filename, umode_t mode, unsigned int dev);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_utimes(char *filename, struct timespec64 *ts);
> 
> I must be blind as I don't see extension anywhere

We're talking about programs (Mutt and others). You're quoting things
from the Linux kernel.

You probably won't see anything about the filename extensions either
in the low-level part of the MS Windows code either.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Stefan Monnier]

> (Note that I'd even make a difference: where the implementation matters,
> e.g. some shell code to be sourced in, I'd be more lenient in calling
> the thing ".sh": after all, its users rely on it being shell code. When
> you can change the implementation without changing the function, e.g.
> a shell script/executable -- I am decidedly against slapping a suffix
> on the name.

I think what you're saying is that it would make sense to use
a dedicated extension for executables, like, say, `.exe`,
since "all users rely on it being" executable.

FWIW, I agree, but this ship sailed a long time ago.


Stefan "who likes types"

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[tomas]

On Mon, Dec 11, 2023 at 09:55:54AM -0500, Greg Wooledge wrote:

[...]

Greg, your analyses are always impressive. And enjoyable.

Thanks for this

cheers
-- 
t


signature.asc
Description: PGP signature

Re: EIO error - I/O error

[Marco Moock]

Am 11.12.2023 um 15:46:03 Uhr schrieb Rachid Oubelk:

> Please, we are using Debian GNU/Linux 9.13 (stretch) installed on a
> UC-8112-LX controller version 3.4, and it shows the error EIO  ( IO
> error ).

Where does that error message appear?
In which application?

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:52, David Wright wrote:

On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:

On Dec 10, 2023, at 3:05 PM, David Wright wrote:
On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:

On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:

I'm on Debian bookworm, using neomutt for email. Where there is an image to
view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
the mailcap_path variable in my neomutt config to point to ~/.mailcap,

Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
a specially crafted subset of /etc/mailcap with a few additions
(like converting webp to a jpeg rather than opening in gimp,
and playing midi files the way I want).


and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set

  ↑↑↑ try jpeg


the "display" alternative to feh with update-alternatives. Still, mutt is
calling an imagemagick program to display jpgs.

First, if alternatives doesn't point to the imagemagick program, and the
mailcap file doesn't point to it, and there's nothing in the neomutt config
pointing to the imagemagick program, then where the heck is it getting that
as the program to use to display images?

An email would contain headers with the attachment.

↓
  Content-Type: image/jpeg
  Content-Disposition: attachment; filename="don.jpg"
  Content-Transfer-Encoding: base64

By default, mutt searches six directories for a mailcap file. When
found, the line in the mailcap starting with image/jpeg selects the
program to run.

If you see an extension in a mailcap field like   nametemplate=%s.jpg
that's to show that a filename matching that pattern should be given
to a copy of the attachment to satisfy the program that's going to
read it. But it's the attachment /content type/ that selects the
program, not the extension¹.


Second, how do I fix this so that mutt uses feh to display images?

I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
the files I was looking at had a "jpg" extension.

But thanks for the tip.

A couple of programs in my /etc/mailcap (gpicview and gm) have
image/jpg lines, duplicating the image/jpeg entries, perhaps
as a "catch-all" for malformed emails containing image/jpg.
I don't know whether image/jpg is an official legacy type/iana-token.

¹ Re the argument raging in this thread about "extension", the
  term is clearly appropriate, as a glance at /etc/mime.types
  demonstrates. The literature is full of the term.

  I wouldn't want to use "suffix" myself, as it's too general:
  anything stuck on the end is a suffix, but not necessarily
  a filename extension. Suffixes are used for other purposes.

Suffix is the correct term.
File names in Linux are a character string of 255 chars.  Again there are not 
file extensions in a Linux file name.

People are conflating the issue.

Read the code, code good.

So you've said five or six times already. The trouble is that it's
difficult to square this with documentation not only of the OS in
the widest sense, but also the linux kernel itself, which uses the
term extension.

It's often stated, and has been in this thread, that the kernel uses
magic numbers at the start of executables rather than filename
extensions, and while this is true, it's not the only method.

Take a look, for example, at this file (choose your version):

   linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst

   Kernel Support for miscellaneous Binary Formats (binfmt_misc)
   =

   This Kernel feature allows you to invoke almost (for restrictions
   see below) every program by simply typing its name in the shell.
   This includes for example compiled Java(TM), Python or Emacs programs.

   To achieve this you must tell binfmt_misc which interpreter has to
   be invoked with which binary. Binfmt_misc recognises the binary-type
   by matching some bytes at the beginning of the file with a magic
   byte sequence (masking out specified bits) you have supplied.
   Binfmt_misc can also recognise a filename extension aka ``.com``
   or ``.exe``.

   [ … ]

   ``magic``
   is the byte sequence binfmt_misc is matching for. The magic string
   may contain hex-encoded characters like ``\x0a`` or ``\xA4``. Note
   that you must escape any NUL bytes; parsing halts at the first one.
   In a shell environment you might have to write ``\\x0a`` to prevent
   the shell from eating your ``\``.
   If you chose filename extension matching, this is the extension to be
   recognised (without the ``.``, the ``\x0a`` specials are not allowed).
   Extension matching is case sensitive, and slashes ``/`` are not allowed!

Cheers,
David.



Where exactly is the variable defined in  the kernel source that a file 
extension is defined


filename is defined as a char "string" of 255 chars, so where is 

EIO error - I/O error

[Rachid Oubelk]

Dear support team,


Please, we are using Debian GNU/Linux 9.13 (stretch) installed on a
UC-8112-LX controller version 3.4, and it shows the error EIO  ( IO error
).

Could you please help us understand the cause of this error? Very urgent.

Best regards,



Rachid OUBELK

Technical Support Engineer

Customer Service

Elum Energy

rachid.oub...@elum-energy.com

21 Rue Bapaume, Casablanca, Morocco

elum-energy.com

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 08:52:37AM -0600, David Wright wrote:
> On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:

[...]

> > File names in Linux are a character string of 255 chars.  Again there are 
> > not file extensions in a Linux file name.
> > 
> > People are conflating the issue.
> > 
> > Read the code, code good.
> 
> So you've said five or six times already. The trouble is that it's
> difficult to square this with documentation not only of the OS in
> the widest sense, but also the linux kernel itself, which uses the
> term extension.

:-)

I'd tend to the maxim "all generalizations suck".

I do agree that encoding file type in the file name is an antipattern
(and tend to avoid that whenever possible). That said, it's true that
there are more than enough user space applications (and as you showed,
even kernel space ones) where that antipattern crept in.

I think it's there to stay. But it is good to put some counterpressure.

(Note that I'd even make a difference: where the implementation matters,
e.g. some shell code to be sourced in, I'd be more lenient in calling
the thing ".sh": after all, its users rely on it being shell code. When
you can change the implementation without changing the function, e.g.
a shell script/executable -- I am decidedly against slapping a suffix
on the name.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Greg Wooledge]

On Mon, Dec 11, 2023 at 02:00:49PM +, Albretch Mueller wrote:
>  Ach, yes! I forgot echo by default appends a new line character at
> the end of every string it spits out. In order to suppress it you need
> to use the "n" option: "echo -n ..."
> 
> _FL_TYPE="   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡ §
> ASCII  ä ö ü ß Ä Ö Ü Text"
> echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"
> _FL_TYPE=$(echo "${_FL_TYPE}" | xargs)
> echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"
> _FL_TYPE=$(echo -n "${_FL_TYPE}" |  tr --complement --squeeze-repeats
> '[A-Za-z0-9.]' '_');
> echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"
> 
> // __ $_FL_TYPE: |   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere
> ¿ ¡ § ASCII  ä ö ü ß Ä Ö Ü Text|
> // __ $_FL_TYPE: |abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡
> § ASCII ä ö ü ß Ä Ö Ü Text|
> // __ $_FL_TYPE: |abc_123_birdie_here_ASCII_Text|

OK.  Tomas's analysis was better than mine in this case.  Looks like CR
was not the issue this time around.  I do have some comments, though.

1) Many implementations of echo will interpret parts of their argument(s),
   in addition to processing options like -n.  If you want to print a
   variable's contents to standard output without *any* interpretation,
   use printf.

printf %s "$myvar"
printf '%s\n' "$myvar"

2) As tomas already told you, the square brackets in

tr -c -s '[A-Za-z0-9.]' _

   are literal.  You're using a command which will keep left and right
   square brackets in the input, *not* replacing them with underscores.
   This may not be what you want.

3) In locales other than C or POSIX, ranges like A-Z are *not* necessarily
   synonyms for [:upper:].  As I've already mentioned, GNU tr is known to
   contain bugs, so you're getting lucky here.  The bugs in GNU tr happen
   to work the way you're expecting, so that A-Z is treated like [:upper:]
   when it should not be.  If at some point in the future GNU tr is fixed
   to conform to POSIX, your script may break.

   The correct tr command you should be using if you want to retain
   accented letters (as defined in your locale) is:

tr -c -s '[:alnum:].' _

   If you want to discard accented letters, then either of these is OK:

LC_COLLATE=C tr -c -s '[:alnum:].' _
LC_COLLATE=C tr -c -s 'A-Za-z0-9.' _

4) The xargs command, which you used above, uses quotation mark characters
   as well as whitespace to define input words.  Your example worked only
   because your input does not contain any single or double quotes.

Here's a demonstration of A-Z not equating to [:upper:] using GNU sed,
which is behaving correctly:

unicorn:~$ x='   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ '
unicorn:~$ printf '%s\n' "$x" | sed 's/[A-Z]//g'
   abc  á é í ó ú ü ñ123 birdiehere ¿ 
unicorn:~$ printf '%s\n' "$x" | LC_COLLATE=C sed 's/[A-Z]//g'
   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ 

The meaning of [A-Z] in the sed command depends on the locale.  In my
locale, which is en_US.utf8, characters like Á are part of the A-Z range.
In the C locale, they aren't, as seen in the last command above.

The use of [A-Z] in regular expressions and globs is a *very* heavily
debated topic, and I'm only scratching the surface here.  Honestly, you
really should avoid using it.  It's just too unpredictable.

Here's an example of xargs failing when its input contains a quote:

unicorn:~$ echo 'foo "bar' | xargs
xargs: unmatched double quote; by default quotes are special to xargs 
unless you use the -0 option
foo

You can't use xargs to normalize whitespace safely.  In fact, the proper
way to normalize whitespace is...

unicorn:~$ printf 'foo "bar \t\t \t  baz  \n' | tr -s ' \t' ' '
foo "bar baz 

Thus, we come full circle.

Re: Image handling in mutt

[David Wright]

On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
> > On Dec 10, 2023, at 3:05 PM, David Wright wrote:
> > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> >>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> >>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
>  
>  I'm on Debian bookworm, using neomutt for email. Where there is an image 
>  to
>  view, viewing it in neomutt calls up one of the ImageMagick programs. 
>  I've set
>  the mailcap_path variable in my neomutt config to point to ~/.mailcap,
> > 
> > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
> > a specially crafted subset of /etc/mailcap with a few additions
> > (like converting webp to a jpeg rather than opening in gimp,
> > and playing midi files the way I want).
> > 
>  and
>  set an entry in there for image/jpg to point to /usr/bin/feh. I've even 
>  set
> >>>  ↑↑↑ try jpeg
> >>> 
>  the "display" alternative to feh with update-alternatives. Still, mutt is
>  calling an imagemagick program to display jpgs.
>  
>  First, if alternatives doesn't point to the imagemagick program, and the
>  mailcap file doesn't point to it, and there's nothing in the neomutt 
>  config
>  pointing to the imagemagick program, then where the heck is it getting 
>  that
>  as the program to use to display images?
> > 
> > An email would contain headers with the attachment.
> > 
> >↓
> >  Content-Type: image/jpeg
> >  Content-Disposition: attachment; filename="don.jpg"
> >  Content-Transfer-Encoding: base64
> > 
> > By default, mutt searches six directories for a mailcap file. When
> > found, the line in the mailcap starting with image/jpeg selects the
> > program to run.
> > 
> > If you see an extension in a mailcap field like   nametemplate=%s.jpg
> > that's to show that a filename matching that pattern should be given
> > to a copy of the attachment to satisfy the program that's going to
> > read it. But it's the attachment /content type/ that selects the
> > program, not the extension¹.
> > 
>  Second, how do I fix this so that mutt uses feh to display images?
> >> 
> >> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> >> the files I was looking at had a "jpg" extension.
> >> 
> >> But thanks for the tip.
> > 
> > A couple of programs in my /etc/mailcap (gpicview and gm) have
> > image/jpg lines, duplicating the image/jpeg entries, perhaps
> > as a "catch-all" for malformed emails containing image/jpg.
> > I don't know whether image/jpg is an official legacy type/iana-token.
> > 
> > ¹ Re the argument raging in this thread about "extension", the
> >  term is clearly appropriate, as a glance at /etc/mime.types
> >  demonstrates. The literature is full of the term.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 
> File names in Linux are a character string of 255 chars.  Again there are not 
> file extensions in a Linux file name.
> 
> People are conflating the issue.
> 
> Read the code, code good.

So you've said five or six times already. The trouble is that it's
difficult to square this with documentation not only of the OS in
the widest sense, but also the linux kernel itself, which uses the
term extension.

It's often stated, and has been in this thread, that the kernel uses
magic numbers at the start of executables rather than filename
extensions, and while this is true, it's not the only method.

Take a look, for example, at this file (choose your version):

  linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst

  Kernel Support for miscellaneous Binary Formats (binfmt_misc)
  =

  This Kernel feature allows you to invoke almost (for restrictions
  see below) every program by simply typing its name in the shell.
  This includes for example compiled Java(TM), Python or Emacs programs.

  To achieve this you must tell binfmt_misc which interpreter has to
  be invoked with which binary. Binfmt_misc recognises the binary-type
  by matching some bytes at the beginning of the file with a magic
  byte sequence (masking out specified bits) you have supplied.
  Binfmt_misc can also recognise a filename extension aka ``.com``
  or ``.exe``.

  [ … ]

  ``magic``
  is the byte sequence binfmt_misc is matching for. The magic string
  may contain hex-encoded characters like ``\x0a`` or ``\xA4``. Note
  that you must escape any NUL bytes; parsing halts at the first one.
  In a shell environment you might have to write ``\\x0a`` to prevent
  the shell from eating your ``\``.
  If you chose filename extension matching, this is the extension to be
  recognised (without the ``.``, the ``\x0a`` 

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Max Nikulin]

On 11/12/2023 21:00, Albretch Mueller wrote:

// __ $_FL_TYPE: |abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡
§ ASCII ä ö ü ß Ä Ö Ü Text|
// __ $_FL_TYPE:|abc_123_birdie_here_ASCII_Text|


https://pypi.org/project/Unidecode/
should be more friendly to languages other than English.

Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

[Stella Ashburne]

Hi Greg

Thank you for taking the time to explain in detail.

> Sent: Monday, December 11, 2023 at 10:16 PM
> From: "Greg Wooledge" 
> To: debian-user@lists.debian.org
> Subject: Re: Release process notes [WAS  Need clarifications about how to 
> deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 
> (6.1.64-1)]
>
*snip* *snip*
>
>
> If you removed linux-image-6.1.0-14-amd64 and linux-image-amd64 as I'm
> sure many people did, then in order to get back to normalcy, you would
> have to reinstall the linux-image-amd64 metapackage.  But the question is
> *when* to do this.  If you did it right away, it would just reinstall
> the buggy kernel, so that's no good.  You had to wait.  But... how long?
> It makes sense to wait until we have a confirmed good kernel version
> available; otherwise, we just have to repeat this cycle all over again.
>
May I refer you to my other post titled "From which kernel should I upgrade my 
installed Debian to linux-image-6.1.0-15-amd64?" (URL: 
https://lists.debian.org/debian-user/2023/12/msg00632.html).

Based on your above statements, I should boot my installed Debian using the 
kernel named linux-image-6.1.0-13-amd64 (the version prior to the buggy one).

Next in a terminal I should either

(1a) sudo apt remove linux-image-6.1.0-14-amd64

or

(1b) sudo apt purge linux-image-6.1.0-14-amd64

(1a) or (1b) will remove the metapackage linux-image-amd64, yes/no?

(2) sudo update-grub

(3) sudo shutdown -r now

Upon reboot, the GRUB menu will automatically boot using 
linux-image-6.1.0-13-amd64 as the buggy kernel named linux-image-6.1.0-14-amd64 
has been removed in either (1a) or (1b), am I right?

Next in a terminal I typed the following commands:

sudo apt update && apt upgrade

(Note: The name of the metapackage, linux-image-amd64, will be listed in the 
terminal.)

After upgrading and rebooting my device, my installed Debian will have 
linux-image-6.1.0-15-amd64 as the latest kernel. Am I right?

Best wishes.

Stella

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:34, Vincent Lefevre wrote:

On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:

On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:

I do not care about the "microsoft world", and I doubt that this is
required there at the low level (what would be the equivalent of the
Linux kernel) [...]

This depends: the FAT file system (which still is the lowest common
denominator) actually reserves 8 chars for the file name and three
for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

This is unrelated to the OS. The FAT file system may be used also
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.



So you are implying that you can discard file extensions with MS-DOS 6.22?

That is false, from before Win7 MS operating systems REQUIRED a file 
extension to determine file type.


Linux has no such requirement.

--
It's not easy to be me

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 03:34:28PM +0100, Vincent Lefevre wrote:
> On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:
> > On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:
> > > I do not care about the "microsoft world", and I doubt that this is
> > > required there at the low level (what would be the equivalent of the
> > > Linux kernel) [...]
> > 
> > This depends: the FAT file system (which still is the lowest common
> > denominator) actually reserves 8 chars for the file name and three
> > for the --ahem-- extension. The dot isn't encoded explicitly on-disk.
> 
> This is unrelated to the OS. The FAT file system may be used also
> under Linux (e.g. because this is what some memory sticks have),
> and there are the same limitations.

You conveniently snipped the OS part. Of course this (and the absence
of hard links) is a limitation of the file system.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:
> On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:
> > I do not care about the "microsoft world", and I doubt that this is
> > required there at the low level (what would be the equivalent of the
> > Linux kernel) [...]
> 
> This depends: the FAT file system (which still is the lowest common
> denominator) actually reserves 8 chars for the file name and three
> for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

This is unrelated to the OS. The FAT file system may be used also
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:04, Vincent Lefevre wrote:

On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:

2) When *receiving* email, mutt will use the sender's MIME type label
to decide how to deal with the attachment.

But the notion of filename extension is even used in this context too.
Quoting the Mutt manual:


nametemplate=
   This field specifies the format for the file denoted by %s in
   the command fields. Certain programs will require a certain
   file extension, for instance, to correctly view a file. For
   instance, lynx will only interpret a file as text/html if the
   file ends in .html. So, you would specify lynx as a text/html
   viewer with a line in the mailcap file like:

text/html; lynx %s; nametemplate=%s.html


This is due to


3) Many other programs besides mutt will also use file extensions to
determine how to deal with input files.


/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct filename 
{
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct
 filename, iname) % sizeof(long) == 0);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
file *file_open_name(struct filename *, int, umode_t);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_flags(const char __user *, int, int *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_uflags(const char __user *, int);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname(const char __user *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_kernel(const char *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void 
putname(struct filename *name);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:
struct filename *name;

/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chdir(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chroot(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chown(const char *filename, uid_t user, gid_t group, int flags);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chmod(const char *filename, umode_t mode);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_eaccess(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_stat(const char *filename, struct kstat *stat, int flags);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_mknod(const char *filename, umode_t mode, unsigned int dev);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_utimes(char *filename, struct timespec64 *ts);


I must be blind as I don't see extension anywhere


--
It's not easy to be me

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:

[...]

> I do not care about the "microsoft world", and I doubt that this is
> required there at the low level (what would be the equivalent of the
> Linux kernel) [...]

This depends: the FAT file system (which still is the lowest common
denominator) actually reserves 8 chars for the file name and three
for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

DOS itself treats some extensions especially (.BAT, .COM, .EXE);
since Windows > 3.1 I (luckily!) lost track of whatever shenanigans
Microsoft has been up to.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

[Greg Wooledge]

On Mon, Dec 11, 2023 at 02:35:07PM +0100, Stella Ashburne wrote:
> Suppose linux-image-6.1.0-15-amd64 is installed successfully and I reboot my 
> device.
> 
> A few days from now, I decide to remove linux-image-6.1.0-15-amd64 because it 
> is buggy and so in a terminal, I type the commands:
> 
> sudo apt remove linux-image-6.1.0-15-amd64
> 
> or
> 
> sudo apt purge linux-image-6.1.0-15-amd64
> 
> sudo update-grub
> 
> sudo shutdown -r now
> 
> Based on the above commands, I have some questions for you. They are:
> 
> (1) Is it a "hard" or "soft" removal of linux-image-6.1.0-15-amd64?

I don't know what you mean by "hard removal" or "soft removal".

The other day, I used the phrase "hard dependency" to describe the
relationship between linux-image-amd64 and linux-image-SOME-VERSION-amd64.
The metapackage has a "Depends: ..." line which names the other kernel
package.  You *cannot* install linux-image-amd64 without also bringing
in the versioned kernel that it depends on.

This is different from "Suggests:" or "Recommends:" which are optional
dependencies.

> (2) Is the metapackage linux-image-amd64 removed?

Yes, because linux-image-amd64 *right now* depends on
linux-image-6.1.0-15-amd64.  Removing linux-image-6.1.0-15-amd64 will
therefore remove linux-image-amd64.

> (3) What do you mean by your statement "prevents you from updating to the 
> buggy kernel but you have to do some tidying up afterwards"?

You have to go back in time, to when linux-image-amd64 depended on
the buggy linux-image-6.1.0-14-amd64 package.  At that time, removing
linux-image-6.1.0-14-amd64 would have removed linux-image-amd64 because
*back then* that's how the dependency was.

If you removed linux-image-6.1.0-14-amd64 and linux-image-amd64 as I'm
sure many people did, then in order to get back to normalcy, you would
have to reinstall the linux-image-amd64 metapackage.  But the question is
*when* to do this.  If you did it right away, it would just reinstall
the buggy kernel, so that's no good.  You had to wait.  But... how long?
It makes sense to wait until we have a confirmed good kernel version
available; otherwise, we just have to repeat this cycle all over again.

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Albretch Mueller]

 Ach, yes! I forgot echo by default appends a new line character at
the end of every string it spits out. In order to suppress it you need
to use the "n" option: "echo -n ..."

_FL_TYPE="   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡ §
ASCII  ä ö ü ß Ä Ö Ü Text"
echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"
_FL_TYPE=$(echo "${_FL_TYPE}" | xargs)
echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"
_FL_TYPE=$(echo -n "${_FL_TYPE}" |  tr --complement --squeeze-repeats
'[A-Za-z0-9.]' '_');
echo "// __ \$_FL_TYPE: |${_FL_TYPE}|"

// __ $_FL_TYPE: |   abc  á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere
¿ ¡ § ASCII  ä ö ü ß Ä Ö Ü Text|
// __ $_FL_TYPE: |abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡
§ ASCII ä ö ü ß Ä Ö Ü Text|
// __ $_FL_TYPE: |abc_123_birdie_here_ASCII_Text|

 Thank you,
 lbrtchx

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> 2) When *receiving* email, mutt will use the sender's MIME type label
>to decide how to deal with the attachment.

But the notion of filename extension is even used in this context too.
Quoting the Mutt manual:


   nametemplate=
  This field specifies the format for the file denoted by %s in
  the command fields. Certain programs will require a certain
  file extension, for instance, to correctly view a file. For
  instance, lynx will only interpret a file as text/html if the
  file ends in .html. So, you would specify lynx as a text/html
  viewer with a line in the mailcap file like:

text/html; lynx %s; nametemplate=%s.html


This is due to

> 3) Many other programs besides mutt will also use file extensions to
>determine how to deal with input files.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 07:32:30 -0500, Pocket wrote:
> 
> On 12/11/23 07:12, Vincent Lefevre wrote:
> > On 2023-12-10 15:51:02 -0500, Pocket wrote:
> > > On Dec 10, 2023, at 3:05 PM, David Wright  
> > > wrote:
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > >   term is clearly appropriate, as a glance at /etc/mime.types
> > > >   demonstrates. The literature is full of the term.
> > > > 
> > > >   I wouldn't want to use "suffix" myself, as it's too general:
> > > >   anything stuck on the end is a suffix, but not necessarily
> > > >   a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > A filename extension is a suffix, but a suffix (e.g. as in POSIX)
> > is not necessarily a filename extension.
> 
> Not in the microsoft world, it is REQUIRED and that is what the OS
> needs to tell what kind of file it is dealing with.  Unix/Linux has
> no resrictions.

I do not care about the "microsoft world", and I doubt that this is
required there at the low level (what would be the equivalent of the
Linux kernel). The filename extension matters at a high level, e.g.
to select which application should be run, but similar choices are
also done under Linux, where this is implemented by utilities,
libraries, or applications themselves. There are other methods under
Linux, such as content sniffing (the method used by "file"), which
has advantages, but also drawbacks (the file needs to be readable,
and mainly for the various text formats, sniffing is unreliable;
good luck with the diff and json formats, for instance).

And even when the application is known, e.g. when the file type is
given by a MIME type, a filename extension may be necessary. See
the various "nametemplate" fields in /etc/mailcap, for instance.

> > For instance:
> > 
> > $ basename foobar bar
> > foo
> > 
> > Here, "bar" is a suffix, but it does not have the form of a
> > filename extension.
> 
> No bar is part of the filespec

No, read the POSIX standard:

  SYNOPSIS
basename string [suffix]

This is explicitly called suffix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Release process notes [WAS Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]

[Stella Ashburne]

Hi Andy

> Sent: Monday, December 11, 2023 at 3:13 PM
> From: "Andrew M.A. Cater" 
> To: debian-user@lists.debian.org
> Subject: Release process notes [WAS Re: Need clarifications about how to deal 
> with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)]
>
>
> linux-image-[foo]-amd64 always points to the latest available kernel image
> for amd64 (and the same for other architectures). It's a metapackage
> that pulls in other packages
>
I thought the metapackage doesn't have the notation linux-image-[foo]-amd64. It 
is simply called linux-image-amd64 (as an example, please click the following 
link: https://packages.debian.org/bookworm/linux-image-amd64)

> When you first install, I suspect it's that package that makes sure your
> kernel version is up to date. When you update between point releases
> likewise.
>
> Hard removing the latest kernel _and_ the metapackage prevents you
> from updating to the buggy kernel but you have to do some tidying up
> afterwards. :)

I'm sorry but you lost me there.

Let's use linux-image-6.1.0-15-amd64 as an example for me to understand what 
you wrote above.

The metapackage of linux-image-6.1.0-15-amd64 is called linux-image-amd64 (cf. 
https://packages.debian.org/bookworm/linux-image-amd64)

I remember that when I upgrade packages, including kernels, in a terminal, the 
results of

sudo apt update

will always list

linux-image-amd64

Suppose linux-image-6.1.0-15-amd64 is installed successfully and I reboot my 
device.

A few days from now, I decide to remove linux-image-6.1.0-15-amd64 because it 
is buggy and so in a terminal, I type the commands:

sudo apt remove linux-image-6.1.0-15-amd64

or

sudo apt purge linux-image-6.1.0-15-amd64

sudo update-grub

sudo shutdown -r now

Based on the above commands, I have some questions for you. They are:

(1) Is it a "hard" or "soft" removal of linux-image-6.1.0-15-amd64?

(2) Is the metapackage linux-image-amd64 removed?

(3) What do you mean by your statement "prevents you from updating to the buggy 
kernel but you have to do some tidying up afterwards"?

Thanks, Andy for taking the time and effort to clarify my doubts.

Best regards.

Stella

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Kevin Price]

Am 11.12.23 um 14:16 schrieb Stella Ashburne:
> Suppose I wish to upgrade to linux-image-6.1.0-15-amd64.

If that were the case, or maybe better to a newer one.

> Should I do it after booting my device into
> (1) linux-image-6.1.0-14-amd64 (the problematic kernel)

NO. Don't ever boot that as it might then toast your ext4.

> (2) linux-image-6.1.0-13-amd64 (which precedes the buggy one)

Yes.

> (3) doesn't matter which kernel to upgrade from

Yes, it largely doesn't matter, apart from the exception above.

HTH
-- 
Kevin Price

Re: From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Greg Wooledge]

On Mon, Dec 11, 2023 at 02:16:39PM +0100, Stella Ashburne wrote:
> (3) doesn't matter which kernel to upgrade from

That.

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Greg Wooledge]

On Mon, Dec 11, 2023 at 02:11:46PM +0100, to...@tuxteam.de wrote:
> On Mon, Dec 11, 2023 at 07:42:10AM -0500, Greg Wooledge wrote:
> > Looks like GNU tr in Debian 12 still doesn't handle multibyte characters
> > correctly:
> > 
> > unicorn:~$ echo 'mañana' | tr ñ X
> > maXXana
> 
> Hey, you just gave us a handy way to count how many encoding units
> a character takes:
> 
>   tomas@trotzki:~$ echo 'birdiehere' | tr -c 'a-z' X
>   birdiehereX

Cute as that is, there are better ways.

unicorn:~$ x=ñ; (echo "${#x}"; LC_ALL=C; echo "${#x}")
1
2

From which kernel should I upgrade my installed Debian to linux-image-6.1.0-15-amd64?

[Stella Ashburne]

Hi

As of now, I'm quite hesistant to upgrade my installed Debian Bookworm to 
linux-image-6.1.0-15-amd64 as there are two users who reported they have 
problems with it (cf. 
https://lists.debian.org/debian-user/2023/12/msg00570.html and 
https://lists.debian.org/debian-user/2023/12/msg00607.html)

However..

Suppose I wish to upgrade to linux-image-6.1.0-15-amd64.

Should I do it after booting my device into

(1) linux-image-6.1.0-14-amd64 (the problematic kernel)

or

(2) linux-image-6.1.0-13-amd64 (which precedes the buggy one)

or

(3) doesn't matter which kernel to upgrade from

I welcome your expert opinions and the reasons for your choice.

Best regards.

Stella

P.S.: I'm sorry to have to ask the above question because this is the first 
time I have ever encountered the problem of having to upgrade a defective 
kernel within the space of a day, literally.

Re: Image handling in mutt

[Greg Wooledge]

On Mon, Dec 11, 2023 at 01:41:09PM +0100, Arno Lehmann wrote:
> I do not see the relevance of the discussion about file name extensions,
> types, suffixes for Debian. Even more so as you are at the stage of
> repeating statements without bringing new value. In fact, there seems to be
> no goal with this thread.
> 
> 
> I would ask you to continue this discussion elsewhere.

It's on topic, so there's no call to ask for the discussion to be
discontinued here.

The facts are pretty simple:

1) When *sending* email, mutt uses the file's extension to decide which
   MIME type label to give the attached file.

2) When *receiving* email, mutt will use the sender's MIME type label
   to decide how to deal with the attachment.

3) Many other programs besides mutt will also use file extensions to
   determine how to deal with input files.

4) File extensions are used by programs on every operating system.  This
   has been the case since before MS-DOS existed; it continues to this
   day; and it will continue for the foreseeable future.

5) Kernels don't know or care about filename extensions.  However,
   confusing a kernel with a whole operating system is a mistake.
   Programs such as file managers are part of the operating system,
   and file managers almost always care about file extensions.

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[tomas]

On Mon, Dec 11, 2023 at 07:42:10AM -0500, Greg Wooledge wrote:
> On Mon, Dec 11, 2023 at 09:37:42AM +0100, to...@tuxteam.de wrote:
> >  2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
> >think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
> >']'. I guess you want to say 'A-Za-z0-9.'
> 
> Well spotted.
> 
> >  3. As a convenience, tr has char classes. Perhaps [:alnum:] is for
> >you. No idea whether this is a GNU extension
> 
> It's POSIX.  100% portable, as long as you ignore any bugs in GNU tr.
> 
> Looks like GNU tr in Debian 12 still doesn't handle multibyte characters
> correctly:
> 
> unicorn:~$ echo 'mañana' | tr ñ X
> maXXana
> 
> So... as long as you're working in the C locale, where [:alnum:] is
> just the ASCII capital and lowercase letters and digits, you should be
> fine.

Hey, you just gave us a handy way to count how many encoding units
a character takes:

  tomas@trotzki:~$ echo 'birdiehere' | tr -c 'a-z' X
  birdiehereX

;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debian 12.3 image release delayed

[Kevin Price]

Am 11.12.23 um 04:36 schrieb Stella Ashburne:
> As for me, I won't be upgrading to the latest kernel just yet because a user, 
> Kevin Price, reported problems with the latest kernel version (cf. 
> https://lists.debian.org/debian-user/2023/12/msg00570.html)

That _might_ be a good idea. Currently the prime suspect is cfg80211
(WiFi). So there _might_ be a debian 12.4.1 coming up, who knows.

I'd _not_ universally recommend 12.4.0, which uses the faulty kernel
6.1.0-15. For now I'm holding on to 6.1.0-13 for general use, as well as
6.1.0-12 as a functioning backup. YMMV.

See https://bugs.debian.org/1057967 for Follow-up, and possibly
https://bugs.debian.org/1057967, which _might_ be the same bug, in which
case they'll be merged.

Time will tell.
-- 
Kevin Price

Re: Image handling in mutt

[Loris Bennett]

David  writes:

> Hi, the filename extension is usually irrelevant on Linux, because
> Linux tools typically
> use the standard 'file' command to inspect the content of the
> fileinstead of relying on
> the filename to indicate content.

It is very often not irrelevant for files that you might want to edit.
Emacs (and I assume many editors) can provide a great deal of support
for specific types of file and, by default, uses the extension (the
term used in the Emacs documentation) to determine the file type.

Cheers,

Loris
  
-- 
This signature is currently under constuction.

Re: Image handling in mutt

[Eric S Fraga]

On Monday, 11 Dec 2023 at 07:32, Pocket wrote:
> No it is microsoft non sense

I'm not an MS fanboi but please stop blaming MS for something they did
not invent!

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Greg Wooledge]

On Mon, Dec 11, 2023 at 09:37:42AM +0100, to...@tuxteam.de wrote:
>  2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
>think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
>']'. I guess you want to say 'A-Za-z0-9.'

Well spotted.

>  3. As a convenience, tr has char classes. Perhaps [:alnum:] is for
>you. No idea whether this is a GNU extension

It's POSIX.  100% portable, as long as you ignore any bugs in GNU tr.

Looks like GNU tr in Debian 12 still doesn't handle multibyte characters
correctly:

unicorn:~$ echo 'mañana' | tr ñ X
maXXana

So... as long as you're working in the C locale, where [:alnum:] is
just the ASCII capital and lowercase letters and digits, you should be
fine.

Re: Image handling in mutt

[Arno Lehmann]

All,

I do not see the relevance of the discussion about file name extensions, 
types, suffixes for Debian. Even more so as you are at the stage of 
repeating statements without bringing new value. In fact, there seems to 
be no goal with this thread.



I would ask you to continue this discussion elsewhere.

Thanks,

Arno


--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Greg Wooledge]

On Mon, Dec 11, 2023 at 11:25:13AM +, Albretch Mueller wrote:
> In the case of: "ASCII text"
>  what should come out of it is: "ASCII_text"
>  not: "ASCII_text_"
>  no underscore at the end. That is the question I have.

OK, here's my guess.

The lines of code that you showed us are not actually in a script.
They're just in a FILE, and you're running a command like this:

sh myfile

Furthermore, I am guessing that the lines of code in this file have
Microsoft CR+LF line endings.  Therefore, when you do a variable
assignment like

ftype=$(file --brief "$whatever")

you end up with a Carriage Return character at the end of the variable's
content (because there is one at the end of this command).

Since you never actually SHOWED US the command you ran, or the output that
was produced, which could have made this really, really obvious, we're
forced to guess.  My guess might be right, or wrong.  But it's the best
guess I have with the limited information you've chosen to share with us.

What I mean by "obvious" is this.  Here's part of your code:

echo "abc123" > file.txt
ftype=$(file --brief file.txt)
echo "// __ \$ftype: |${ftype}|"

If my guess is correct, you got output that looks like this:

|/ __ $ftype: |ASCII text

Showing this would have made it immediately clear that a CR is involved.

Re: Image handling in mutt

[Pocket]

On 12/11/23 07:12, Vincent Lefevre wrote:

On 2023-12-10 15:51:02 -0500, Pocket wrote:

On Dec 10, 2023, at 3:05 PM, David Wright  wrote:

¹ Re the argument raging in this thread about "extension", the
  term is clearly appropriate, as a glance at /etc/mime.types
  demonstrates. The literature is full of the term.

  I wouldn't want to use "suffix" myself, as it's too general:
  anything stuck on the end is a suffix, but not necessarily
  a filename extension. Suffixes are used for other purposes.

Suffix is the correct term.

A filename extension is a suffix, but a suffix (e.g. as in POSIX)
is not necessarily a filename extension.


Not in the microsoft world, it is REQUIRED and that is what the OS needs 
to tell what kind of file it is dealing with.  Unix/Linux has no 
resrictions.




For instance:

$ basename foobar bar
foo

Here, "bar" is a suffix, but it does not have the form of a
filename extension.


No bar is part of the filespec




So the notion of "filename extension" is more specific


No it is microsoft non sense

https://www.man7.org/linux/man-pages/man4/magic.4.html

https://www.geeksforgeeks.org/working-with-magic-numbers-in-linux/

https://www.darwinsys.com/file/

Re: Image handling in mutt

[Pocket]

On 12/11/23 06:39, Vincent Lefevre wrote:

On 2023-12-08 17:06:15 -0500, Pocket wrote:

On 12/8/23 16:53, David wrote:

Hi, the filename extension is usually irrelevant on Linux, because
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.

In Unix and Linux there isn't a file extension, that is a microsoft
invention.

More and more applications under Linux, like atril and lynx, care
about the file extension.


It is a suffix not extension.

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-10 15:51:02 -0500, Pocket wrote:
> On Dec 10, 2023, at 3:05 PM, David Wright  wrote:
> > ¹ Re the argument raging in this thread about "extension", the
> >  term is clearly appropriate, as a glance at /etc/mime.types
> >  demonstrates. The literature is full of the term.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 

A filename extension is a suffix, but a suffix (e.g. as in POSIX)
is not necessarily a filename extension.

For instance:

$ basename foobar bar
foo

Here, "bar" is a suffix, but it does not have the form of a
filename extension.

So the notion of "filename extension" is more specific.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[tomas]

On Mon, Dec 11, 2023 at 11:25:13AM +, Albretch Mueller wrote:
>  "tr --complement --squeeze-repeats ..." makes sure that the replaced
> characters only appear once (that it doesn't immediately repeat). Say
> you have something like "  " (two spaces) or "?$|" (three characters)
> which will be replaced by just an underscore.

...which would change the length, as I wrote.

> In the case of: "ASCII text"
>  what should come out of it is: "ASCII_text"
>  not: "ASCII_text_"
>  no underscore at the end. That is the question I have.

That depends on whether your "ASCII text" has some thingy at the end
which you don't see. A newline, perchance?

>  I use such constructs as: "[A-Za-z0-9.]" to make explicit to myself
> and other people what I mean. I work in corpora research dealing with
> text based various alphabets not just in ASCII so I avoid any kinds of
> linguistic/cultural shortcuts and abbreviations.

What has this to do with how tr works? It will treat [ and ] as characters
not to substitute. I pointed that out, because it might have been unintended:

  echo -n 'This is a  text with [some brackets] in   it' | tr -cs 
"[A-Za-z0-9.]" "_"
  This_is_a_text_with_[some_brackets]_in_it

(Note this "-n" on the echo, btw? Without it, I'd be getting a "_" at the
end, the transliterated newline).

Do whatever you want :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: 12.4.0 point release published

[piorunz]

On 11/12/2023 01:17, Steve McIntyre wrote:

Hi folks,

The new 12.4.0 point release is now out. It contains the needed fixes
for the ext4 data corruption bug (https://bugs.debian.org/1057843).

It's now safe to upgrade as normal, panic over.

Many thanks to all the people who spent all of their weekend making
this happen...



Great news, thank you Debian team. All my machines with unattended
upgrades have been rebooted now and are running new, fixed kernel and
Debian 12.4 release.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-08 17:06:15 -0500, Pocket wrote:
> On 12/8/23 16:53, David wrote:
> > Hi, the filename extension is usually irrelevant on Linux, because
> > Linux tools typically
> > use the standard 'file' command to inspect the content of the
> > fileinstead of relying on
> > the filename to indicate content.
> 
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

More and more applications under Linux, like atril and lynx, care
about the file extension.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Albretch Mueller]

 "tr --complement --squeeze-repeats ..." makes sure that the replaced
characters only appear once (that it doesn't immediately repeat). Say
you have something like "  " (two spaces) or "?$|" (three characters)
which will be replaced by just an underscore.

In the case of: "ASCII text"
 what should come out of it is: "ASCII_text"
 not: "ASCII_text_"
 no underscore at the end. That is the question I have.

 I use such constructs as: "[A-Za-z0-9.]" to make explicit to myself
and other people what I mean. I work in corpora research dealing with
text based various alphabets not just in ASCII so I avoid any kinds of
linguistic/cultural shortcuts and abbreviations.

 lbrtchx

On 12/11/23, to...@tuxteam.de  wrote:
> On Mon, Dec 11, 2023 at 08:04:06AM +, Albretch Mueller wrote:
>> On 12/11/23, Greg Wooledge  wrote:
>> > Please tell us ...
>>
>>  OK, here is what I did as a t-table
>
> [...]
>
> Your style is confusing, to say the least. Why not play with minimal
> examples and work your way up from that?
>
>> the two strings are not the same length even though your are just
>> replacing ASCII characters, why did:
>> echo "${ftype}" | tr --complement --squeeze-repeats '[A-Za-z0-9.]' '_'
>> place a character at the end?
>
> Two things stick out:
>
>  1. with --squeeze-repeats you are challenging tr to output less
>characters than the input has:
>
>trotzki:~$ echo -n "this is a #   string ###" | tr -cs 'a-z' '_'
>=> this_is_a_string_
>
>(I allowed myself to simplify things a bit) See? tr is squeezing
>repeats (repeated matches), the space-plus-three-hashes at the
>end gets squeezed to just one _, thus changing the length.
>If your strings contain more than one non-alphanumeric (something
>I don't feel like even trying a guess at), this is bound to happen.
>You ordered it.
>
>  2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
>think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
>']'. I guess you want to say 'A-Za-z0-9.'
>
>  3. As a convenience, tr has char classes. Perhaps [:alnum:] is for
>you. No idea whether this is a GNU extension
>
>  4. In case of doubt, read the man page :)
>
> Cheers
> --
> t
>

Re: 6.1.0-15/6.1.66-1 broken too?

[Kevin Price]

Please see https://bugs.debian.org/1057967 for follow-up.

Am 11.12.23 um 06:21 schrieb Stephan Verbücheln:
[...]
> My hardware is a 2014 Macbook Pro (Intel CPU and graphics).

Stephan and all, would you please post your information there? TIA
-- 
Kevin Price

Re: RE: GDM et utilisateurs enregistrés

[didier gaumet]

Le 11/12/2023 à 11:27, David BERCOT a écrit :

En parlant d'erreur de frappe, le répertoire en question est :
- /var/lib/AccountsService/ (et pas /var/lib/AccounstService)


décidément j'ai pas les yeux en face des trous aujourd'hui (comme 
souvent). Bref:


didier@hp-notebook14:~$ sudo cat /var/lib/AccountsService/users/didier
[User]
Session=gnome-classic
Icon=/home/didier/.face
SystemAccount=false

par contre

didier@hp-notebook14:~$ sudo ls -al /var/lib/AccountsService/icons
total 8
drwxrwxr-x 2 root root 4096 18 févr.  2023 .
drwxrwxr-x 4 root root 4096  3 déc.  13:55 ..

donc il se pourrait que ce soit l'icône 
(Icon=/var/lib/AccountsService/icons/monUser) qui ait disparu dans ta 
config et qui ait posé problème


Ayant refait une fresh install ce week-end (Debian 12 puis bascule en 
SID), je pense que la configuration en place est "standard".

Mais je ferai le test à l'occasion...


L'essentiel est que tu aies résolu ton souci :-)

Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)

[Stella Ashburne]

Hi Andy

> Sent: Monday, December 11, 2023 at 3:20 PM
> From: "Andrew M.A. Cater" 
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed 
> problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)


> dpkg is low level: it will work to install one .deb, usually this has to be
> one in the same directory. Apt will install more than one because it also
> keeps tabs on dependencies.

Noted.

>
> Please ask OpenVPN to set up an apt repository :)
>
Many, many Debian users who also use OpenVPN have asked OpenVPN to do just that.

Based on my recollection, OpenVPN claimed that they were unable to accede to 
the request to set up an official repo for Debian. It appears that it's onerous 
on the part of OpenVPN's developers to conform to Debian's strict requirements 
and polices.

Best wishes.

Stella

P.S.: It doesn't matter to me the location of the official *deb files for 
OpenVPN as long as they are provided by OpenVPN.

RE: GDM et utilisateurs enregistrés

[David BERCOT]

En parlant d'erreur de frappe, le répertoire en question est :
- /var/lib/AccountsService/ (et pas /var/lib/AccounstService)

Ayant refait une fresh install ce week-end (Debian 12 puis bascule en 
SID), je pense que la configuration en place est "standard".

Mais je ferai le test à l'occasion...

David.

 Message d'origine 
Objet : GDM et utilisateurs enregistrés
Date : lundi 11 décembre 2023 à 10:27 UTC+1
De : didier gaumet 
Pour : debian-user-french@lists.debian.org

Le 11/12/2023 à 10:13, David BERCOT a écrit :

Bonjour,

Normalement, pas de souci de ce côté-là :
- l'ID de mon user est bien 1000
- le fichier /var/lib/AccounstService/users/monUser contient :
 [User]
 Session=
 Icon=/var/lib/AccountsService/icons/monUser
 SystemAccount=false

Ce qui est bizarre, c'est que je n'ai aucun souvenir d'avoir changé 
quoi que ce soit...


David.


Sur mon PC (Debian 12, DE Gnome) le répertoire /var/lib/AccounstService 
n'existe pas, donc je suspecte que dans ton ca, bien que SystemAccount 
soit positionné à false, l'existence même du fichier pose problème


Je serais toi je tenterais un:
$ sudo mv -v /var/lib/AccounstService/users/monUser 
/home/monuser/conf_gdm_a _probleme


puis je vérifierais si ça marche mieux.

Dans l'affirmative, destruction du fichier /home/monuser/conf_gdm_a 
_probleme.


Dans la négative, pour remettre le système à l'état précédent:
$ sudo mv -v /home/monuser/conf_gdm_a _probleme 
/var/lib/AccounstService/users/monUser
auquel cas tu ne sais toujours pas d'où vient le problème mais au moins 
tu es revenu à l'état d'où tu as commencé ton enquête.

Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)

[Stella Ashburne]

Hi Greg

> Sent: Monday, December 11, 2023 at 11:40 AM
> From: "Greg Wooledge" 
> To: debian-user@lists.debian.org
> Subject: Re: Need clarifications about how to deal with the installed 
> problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)
>
> On Mon, Dec 11, 2023 at 04:31:22AM +0100, Stella Ashburne wrote:
> > Someone on a social media platform stated that there are only two 
> > "canonical" [sic] ways to verify the version of Debian installed on a 
> > system. They are:
> >
> > uname -a
> >
> > /proc/version
> >
> > Do you agree with the above statement?
>
> The second one isn't even a command.

Sorry. The command should be:

cat /proc/version

> Neither one of them tells you what version of Debian is installed, even
> if you fix the second one.  All these tell you is which kernel is
> running.

You're right.

>
> To see the version of Debian, the correct command is:
>
> cat /etc/debian_version
>
> This works for any *release* version of Debian.  It will not differentiate
> among various pre-releases, including testing and unstable.  For those,
> you'll need to go deeper.  "apt policy" and "cat /etc/apt/sources.list"
> and "tail -n+1 /etc/apt/sources.list.d/*" would be good starts for that.
>
Thanks.

Best wishes.

Stella

Re: RE: GDM et utilisateurs enregistrés

[didier gaumet]

Le 11/12/2023 à 10:27, didier gaumet a écrit :
[...]
$ sudo mv -v /var/lib/AccounstService/users/monUser 
/home/monuser/conf_gdm_a _probleme


faute de frappe, lire plutôt:
$ sudo mv -v /var/lib/AccounstService/users/monUser 
/home/monuser/conf_gdm_a_probleme


[...]
$ sudo mv -v /home/monuser/conf_gdm_a _probleme 
/var/lib/AccounstService/users/monUser

[...]
pareil, erreur répétée par copier/coller. Lire plutôt:
$ sudo mv -v /home/monuser/conf_gdm_a_probleme 
/var/lib/AccounstService/users/monUser


desolé

Re: RE: GDM et utilisateurs enregistrés

[didier gaumet]

Le 11/12/2023 à 10:13, David BERCOT a écrit :

Bonjour,

Normalement, pas de souci de ce côté-là :
- l'ID de mon user est bien 1000
- le fichier /var/lib/AccounstService/users/monUser contient :
 [User]
 Session=
 Icon=/var/lib/AccountsService/icons/monUser
 SystemAccount=false

Ce qui est bizarre, c'est que je n'ai aucun souvenir d'avoir changé quoi 
que ce soit...


David.


Sur mon PC (Debian 12, DE Gnome) le répertoire /var/lib/AccounstService 
n'existe pas, donc je suspecte que dans ton ca, bien que SystemAccount 
soit positionné à false, l'existence même du fichier pose problème


Je serais toi je tenterais un:
$ sudo mv -v /var/lib/AccounstService/users/monUser 
/home/monuser/conf_gdm_a _probleme


puis je vérifierais si ça marche mieux.

Dans l'affirmative, destruction du fichier /home/monuser/conf_gdm_a 
_probleme.


Dans la négative, pour remettre le système à l'état précédent:
$ sudo mv -v /home/monuser/conf_gdm_a _probleme 
/var/lib/AccounstService/users/monUser
auquel cas tu ne sais toujours pas d'où vient le problème mais au moins 
tu es revenu à l'état d'où tu as commencé ton enquête.

Re: 12.4.0 point release published

[Andreas]

Hi,

On Mon, Dec 11, 2023 at 01:17:19AM +, Steve McIntyre wrote:
> Hi folks,
> 
> The new 12.4.0 point release is now out. It contains the needed fixes
> for the ext4 data corruption bug (https://bugs.debian.org/1057843).
> 
> It's now safe to upgrade as normal, panic over.
> 
> Many thanks to all the people who spent all of their weekend making
> this happen...

Thanks to you and the team for the great work as always!

-- 
Regards,
Andreas


signature.asc
Description: PGP signature

RE: GDM et utilisateurs enregistrés

[David BERCOT]

Bonjour,

Normalement, pas de souci de ce côté-là :
- l'ID de mon user est bien 1000
- le fichier /var/lib/AccounstService/users/monUser contient :
[User]
Session=
Icon=/var/lib/AccountsService/icons/monUser
SystemAccount=false

Ce qui est bizarre, c'est que je n'ai aucun souvenir d'avoir changé quoi 
que ce soit...


David.

 Message d'origine 
Objet : GDM et utilisateurs enregistrés
Date : lundi 11 décembre 2023 à 09:48 UTC+1
De : didier gaumet 
Pour : debian-user-french@lists.debian.org

Le 11/12/2023 à 09:10, David BERCOT a écrit :

Bonjour,

Jusqu'à récemment (quelques semaines, peut-être quelques mois), au 
démarrage de mon ordinateur, la mire GDM affichait mon utilisateur :

https://screenshots.debian.net/shrine/screenshot/19331/simage/large-466822c88dc9a9add6912bb28a3447d4.png

Maintenant, je n'ai plus rien et je dois d'abord saisir mon 
identifiant avant de mettre mon mot de passe.


Est-ce lié à un changement de configuration par défaut ?
Y a-t-il une autre raison potentielle ?

Merci d'avance pour vos... indices.

David.


Bonjour,

apparemment (d'après le wiki archlinux) les utilisateurs qui sont cachés 
de la liste apparaissant sur l'écran d'accueil gdm sont dans un fichier. 
Donc peut être supprimer ce fichier:

https://wiki.archlinux.org/title/GDM#Hide_user_from_login_list
ou remettre un UID>1000 à ton utilisateur si tu lui as manuellement 
attribué un UID<1000

Re: GDM et utilisateurs enregistrés

[didier gaumet]

Le 11/12/2023 à 09:10, David BERCOT a écrit :

Bonjour,

Jusqu'à récemment (quelques semaines, peut-être quelques mois), au 
démarrage de mon ordinateur, la mire GDM affichait mon utilisateur :

https://screenshots.debian.net/shrine/screenshot/19331/simage/large-466822c88dc9a9add6912bb28a3447d4.png

Maintenant, je n'ai plus rien et je dois d'abord saisir mon identifiant 
avant de mettre mon mot de passe.


Est-ce lié à un changement de configuration par défaut ?
Y a-t-il une autre raison potentielle ?

Merci d'avance pour vos... indices.

David.


Bonjour,

apparemment (d'après le wiki archlinux) les utilisateurs qui sont cachés 
de la liste apparaissant sur l'écran d'accueil gdm sont dans un fichier. 
Donc peut être supprimer ce fichier:

https://wiki.archlinux.org/title/GDM#Hide_user_from_login_list
ou remettre un UID>1000 à ton utilisateur si tu lui as manuellement 
attribué un UID<1000

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[tomas]

On Mon, Dec 11, 2023 at 08:04:06AM +, Albretch Mueller wrote:
> On 12/11/23, Greg Wooledge  wrote:
> > Please tell us ...
> 
>  OK, here is what I did as a t-table

[...]

Your style is confusing, to say the least. Why not play with minimal
examples and work your way up from that?

> the two strings are not the same length even though your are just
> replacing ASCII characters, why did:
> echo "${ftype}" | tr --complement --squeeze-repeats '[A-Za-z0-9.]' '_'
> place a character at the end?

Two things stick out:

 1. with --squeeze-repeats you are challenging tr to output less
   characters than the input has:

   trotzki:~$ echo -n "this is a #   string ###" | tr -cs 'a-z' '_'
   => this_is_a_string_

   (I allowed myself to simplify things a bit) See? tr is squeezing
   repeats (repeated matches), the space-plus-three-hashes at the
   end gets squeezed to just one _, thus changing the length.
   If your strings contain more than one non-alphanumeric (something
   I don't feel like even trying a guess at), this is bound to happen.
   You ordered it.

 2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
   think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
   ']'. I guess you want to say 'A-Za-z0-9.'

 3. As a convenience, tr has char classes. Perhaps [:alnum:] is for
   you. No idea whether this is a GNU extension

 4. In case of doubt, read the man page :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Need clarifications about how to deal with the installed problematic kernel, linux-image-6.1.0-14-amd64 (6.1.64-1)

[Michael Kjörling]

On 11 Dec 2023 04:31 +0100, from rewe...@gmx.com (Stella Ashburne):
> Someone on a social media platform stated that there are only two
> "canonical" [sic] ways to verify the version of Debian installed on
> a system. They are:
> 
> uname -a
> 
> /proc/version
> 
> Do you agree with the above statement?

No.

Running `uname -a` or looking at the contents of `/proc/version` will
only tell you about the _currently running_ _kernel_. There is no
guarantee that a given kernel version maps exactly to any given Debian
release or point-in-time state.

If you want to specify the installation state of a Debian system, you
should specify the point release you're on (from /etc/debian_version
on any modern Debian) and the full _package_ version of any relevant
packages (as reported by e.g. dpkg -l). Note that the package version
may be different from the version reported by a program itself.

A lot of the time, something like "current up-to-date Bookworm" or
"Bookworm per " is sufficiently precise, as long as you
have confirmed that this is actually the case.


>>> sudo dpkg -i linux-image-6.1.0-13-amd64
>>> [...]
>>> Is the above the correct way to install kernels that are not in the 
>>> official repos?
>> 
>> Not quite, because dpkg -i wants a file path, not a package name
>> (that's for apt/apt-get).
> 
> 2. sudo dpkg -i openvpn_2.6.8-bookworm0_amd64.deb

linux-image-6.1.0-13-amd64 is a package name. (You can check this with
apt-cache show.)

openvpn_2.6.8-bookworm0_amd64.deb is presumably a file name.

"File path" does not necessarily require specifying a directory
component of the path; a bare file name is also a (relative) path.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

GDM et utilisateurs enregistrés

[David BERCOT]

Bonjour,

Jusqu'à récemment (quelques semaines, peut-être quelques mois), au 
démarrage de mon ordinateur, la mire GDM affichait mon utilisateur :

https://screenshots.debian.net/shrine/screenshot/19331/simage/large-466822c88dc9a9add6912bb28a3447d4.png

Maintenant, je n'ai plus rien et je dois d'abord saisir mon identifiant 
avant de mettre mon mot de passe.


Est-ce lié à un changement de configuration par défaut ?
Y a-t-il une autre raison potentielle ?

Merci d'avance pour vos... indices.

David.

Re: ⚠ No actualicéis a Debian 12.3 ⚠

[Camaleón]

El 2023-12-10 a las 21:13 +0100, Parodper escribió:

> O 10/12/23 ás 10:15, Camaleón escribiu:
> > Hola,
> > 
> > Pues eso, acabo de leer que se retrasa por problemas con un bug de ext4
> > (corrupción de archivos) y en Debian recomiendan PAUSAR las actualizaciones,
> > sobre todo en sistemas que tienen configuradas las actualizaciones
> > desatendidas.
> > 
> > Debian 12.3 image release delayed
> > https://www.debian.org/News/2023/2023120902
> > 
> > P.S. El asunto se inicia y finaliza con dos símbolos unicode con la
> > señal de peligro (⚠) a ver cómo se renderiza :-)
> > 
> 
> Por desgracia justo se me ocurrió actualizar sin mirar el correo. Creo que
> llevo ya un día en esa versión, pero por suerte no he notado nada fuera de
> lo normal.
> 
> La verdad es que el Discover de KDE debería avisar antes de actualizar a una
> nueva versión. Me suena que Ubuntu lo hacía.

Mira a ver si tienes la 12.3 o la 12.4, la acaban de anunciar:

Debian 12.4 to supersede Debian 12.3
https://www.debian.org/News/2023/2023121002

Más que nada, la versión del paquete afectado (el núcleo) que debe ser 
la versión «6.1.66+1» donde ya se corrige el fallo.

sm01@stt008:~$ uname -a
Linux stt008 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 
GNU/Linux
   ^^

Saludos,

-- 
Camaleón 

Re: why would "tr --complement --squeeze-repeats ..." append the substitution char once more? ...

[Albretch Mueller]

On 12/11/23, Greg Wooledge  wrote:
> Please tell us ...

 OK, here is what I did as a t-table

echo "abc123" > file.txt  # obvious text file
ftype=$(file --brief file.txt)  # got its type as reported by the "file" utility
echo "// __ \$ftype: |${ftype}|"
ftypelen=${#ftype}  # length of the string containing the file type
echo "// __ \$ftypelen: |${ftypelen}|"

# removing spaces et any other char which is not '[A-Za-z0-9.]'
replacing with underscores ...
# here is what I think to be an error happened instead of just
replacing ... by underscores
# it adds an underscore at the end?
ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
'[A-Za-z0-9.]' '_');
echo "// __ \$ftype2: |${ftype2}|"
ftype2len=${#ftype2}
echo "// __ \$ftype2len: |${ftype2len}|"

the two strings are not the same length even though your are just
replacing ASCII characters, why did:
echo "${ftype}" | tr --complement --squeeze-repeats '[A-Za-z0-9.]' '_'
place a character at the end?
Probably echo and tr are not dancing well together. echo might be
tailgating an end of string character which tr then replaces with an
underscore.
which option do I use with echo for that not to happen?
SHould I probably play with IFS ...?

lbrtchx


On 12/11/23, Greg Wooledge  wrote:
> On Mon, Dec 11, 2023 at 02:53:07AM +, Albretch Mueller wrote:
>> echo "abc123" > file.txt
>> ftype=$(file --brief file.txt)
>> echo "// __ \$ftype: |${ftype}|"
>> ftypelen=${#ftype}
>> echo "// __ \$ftypelen: |${ftypelen}|"
>>
>> # removing spaces ...
>> ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
>> '[A-Za-z0-9.]' '_');
>> echo "// __ \$ftype2: |${ftype2}|"
>> ftype2len=${#ftype2}
>> echo "// __ \$ftype2len: |${ftype2len}|"
>
> Please tell us:
>
>  * What you are trying to do.
>
>  * What you did (is the previous code all in a script?  if so, this is a
>good answer for this part).
>
>  * What result you got.
>
>  * What you expected to get.