demà Debian fa 30 anys

2023-08-14 Thread Àlex

felicitats!


https://wiki.debian.org/DebianDay/2023



Re: random number generator missing after upgrade

2023-08-14 Thread Björn Persson
davidson wrote:
>  Debian Bug #1041007
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041007#10

Yes, that seems to be exactly my problem. So it's not intentionally
disabled. Then I can hope that it may be fixed some day. Thanks for
your help.

Björn Persson


pgpRmFKPdRagm.pgp
Description: OpenPGP digital signatur


Re: why would ping and traceroute give you different IP addresses?

2023-08-14 Thread Geert Stappers
On Tue, Aug 15, 2023 at 05:02:49AM +, Albretch Mueller wrote:
> site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> 
> $ site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> Mon 14 Aug 2023 11:54:19 PM UTC
> PING s3-website.us-east-1.amazonaws.com (54.231.134.85) 56(84) bytes of data.
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=1 
> ttl=242 time=47.8 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=2 
> ttl=242 time=54.9 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=3 
> ttl=242 time=46.2 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=4 
> ttl=242 time=48.1 ms
> 
> --- s3-website.us-east-1.amazonaws.com ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3004ms
> rtt min/avg/max/mdev = 46.246/49.253/54.875/3.320 ms
> 
> real  0m3.186s
> user  0m0.005s
> sys   0m0.000s
> 
> traceroute to download.gluonhq.com (52.216.228.138), 30 hops max, 60
> byte packets
>  1  _gateway (192.168.68.1)  9.267 ms  9.223 ms  8.035 ms
>  2  dsldevice.attlocal.net (192.168.1.254)  10.349 ms  10.333 ms  10.319 ms
>  3  99-178-252-1.lightspeed.stlsmo.sbcglobal.net (99.178.252.1) 33.434 ms  
> 33.420 ms  33.406 ms
>  4  71.154.70.113 (71.154.70.113)  34.515 ms  33.379 ms  38.092 ms 5  * * *
>  6  32.130.88.131 (32.130.88.131)  50.165 ms  42.200 ms  35.492 ms
>  7  * * *
   
> 22  * * *
> 23  s3-website-us-east-1.amazonaws.com (52.216.228.138)  50.960 ms
> 50.902 ms  53.215 ms
> 
> real  0m15.213s
> user  0m0.009s
> sys   0m0.000s
> $
> 

$ host download.gluonhq.com
download.gluonhq.com is an alias for 
download.gluonhq.com.s3-website-us-east-1.amazonaws.com.
download.gluonhq.com.s3-website-us-east-1.amazonaws.com is an alias for 
s3-website.us-east-1.amazonaws.com.
s3-website.us-east-1.amazonaws.com has address 52.217.163.181
s3-website.us-east-1.amazonaws.com has address 52.217.83.203
s3-website.us-east-1.amazonaws.com has address 52.217.206.181
s3-website.us-east-1.amazonaws.com has address 52.217.98.51
s3-website.us-east-1.amazonaws.com has address 16.182.72.93
s3-website.us-east-1.amazonaws.com has address 52.216.227.162
s3-website.us-east-1.amazonaws.com has address 52.216.212.237
s3-website.us-east-1.amazonaws.com has address 52.217.83.179
$ host download.gluonhq.com
download.gluonhq.com is an alias for 
download.gluonhq.com.s3-website-us-east-1.amazonaws.com.
download.gluonhq.com.s3-website-us-east-1.amazonaws.com is an alias for 
s3-website.us-east-1.amazonaws.com.
s3-website.us-east-1.amazonaws.com has address 52.217.163.181
s3-website.us-east-1.amazonaws.com has address 52.217.83.203
s3-website.us-east-1.amazonaws.com has address 52.217.206.181
s3-website.us-east-1.amazonaws.com has address 52.217.98.51
s3-website.us-east-1.amazonaws.com has address 16.182.72.93
s3-website.us-east-1.amazonaws.com has address 52.216.227.162
s3-website.us-east-1.amazonaws.com has address 52.216.212.237
s3-website.us-east-1.amazonaws.com has address 52.217.83.179
$
 

Groeten
Geert Stappers
-- 
Silence is hard to parse



why would ping and traceroute give you different IP addresses?

2023-08-14 Thread Albretch Mueller
site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"

$ site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"
Mon 14 Aug 2023 11:54:19 PM UTC
PING s3-website.us-east-1.amazonaws.com (54.231.134.85) 56(84) bytes of data.
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=1 ttl=242 time=47.8 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=2 ttl=242 time=54.9 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=3 ttl=242 time=46.2 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=4 ttl=242 time=48.1 ms

--- s3-website.us-east-1.amazonaws.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 46.246/49.253/54.875/3.320 ms

real0m3.186s
user0m0.005s
sys 0m0.000s

traceroute to download.gluonhq.com (52.216.228.138), 30 hops max, 60
byte packets
 1  _gateway (192.168.68.1)  9.267 ms  9.223 ms  8.035 ms
 2  dsldevice.attlocal.net (192.168.1.254)  10.349 ms  10.333 ms  10.319 ms
 3  99-178-252-1.lightspeed.stlsmo.sbcglobal.net (99.178.252.1)
33.434 ms  33.420 ms  33.406 ms
 4  71.154.70.113 (71.154.70.113)  34.515 ms  33.379 ms  38.092 ms
 5  * * *
 6  32.130.88.131 (32.130.88.131)  50.165 ms  42.200 ms  35.492 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  s3-website-us-east-1.amazonaws.com (52.216.228.138)  50.960 ms
50.902 ms  53.215 ms

real0m15.213s
user0m0.009s
sys 0m0.000s
$



Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

2023-08-14 Thread Max Nikulin

On 15/08/2023 04:56, kjohn...@eclypse.org wrote:

I have done additional research, and it now appears that programs that
do extensive disk writes run much slower (3-6x) in Bookworm than they
did in Bullseye.


Have you compared kernel IO schedulers? May it be a case of SSD vs HDD 
optimizing?


grep '' /sys/block/*/queue/scheduler



Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

2023-08-14 Thread Max Nikulin

On 14/08/2023 07:30, Nate Bargmann wrote:

I have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.


I do not know how it is arranged in Gnome, but I hope my observations 
still might be helpful.



systems on my LAN and was greeted with a password prompt for the
corresponding public key


To be precise, it is the passphrase do decrypt your *private* key. A 
public key may be known to anybody. Private key is a secret that allows 
to prove that you have it without disclosing of this private key. 
Encryption using a passphrase is a means to mitigate consequences if the 
private key is stolen.


An ssh agent opens a socket and exposes its location through an 
environment variable (perhaps using "systemctl set-environment", but I 
am not sure). Try


env | grep SSH

There are multiple implementations of SSH agents: openssh, gpg, 
keepassxc(?), perhaps gnome has more (seahorse? I am unsure concerning 
the role of secrets service). It may happen that in your case multiple 
instances are running:


/usr/lib/systemd/user/ssh-agent.service
/usr/lib/systemd/user/gpg-agent-ssh.socket
/etc/X11/Xsession.d/90x11-common_ssh-agent

GUI prompt may be just a proxy to an actual ssh agent. It just listens 
its socket and displaying a password prompt on demand and passing other 
messages literally.



Now, while typing this email all keyring PIDs have vanished!


It may be a way to minimize RAM usage. The agent may be a 
socket-activated process.


systemctl --user list-sockets

Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue 
what is really happening in your case.


I suggest you to add "f" option to "ps" to see process tree. It may help 
to find details concerning starting of particular agent.


   ps xwwf

P.S. At certain moment gnome designers decided that password prompt must 
be a modal dialog completely blocking interaction with any other 
applications (including 3rd party password manager). For me it was 
another reason to avoid gnome. I am aware that X11 protocol allows to 
sniff keyboard events and a measure against it is grabbing input. 
However I believe mouse still may be a way to call an external password 
manager. After all, there are may be an option to temporary suspend 
keyboard grabbing. I learned about multiple ways to start a ssh agent 
during initialization of user session when I was trying to figure out 
which way GUI prompt is implemented and if a more flexible dialog could 
be used instead.




Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

2023-08-14 Thread Stefan Monnier
> I have done additional research, and it now appears that programs that do
> extensive disk writes run much slower (3-6x) in Bookworm than they did in
> Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting
> an SQL backup of a Bacula database from Postgresql (backup file about 3 GB).
> Operations that perform extensive reads (a Bacula backup operation to
> magnetic tape, 600 GB) seem to run at the same speed as before.
>
> At the moment, this is a 32-bit PAE system.  I don't know of an obvious
> reason why that would matter.  At the time of the upgrade, the system memory
> was enlarged from 16 to 32GB, in anticipation of converting the system from
> i386 to amd64.

FWIW, I've had very serious write performance issues on my Thinkpad T61
(8GB RAM + SSD) when using a 32bit PAE kernel (occasionally below 1MB/s,
tho not reliably reproducible, e.g. not right after boot).

Those problems disappeared when I switched to an amd64 kernel (while
keeping the userland 32bit).

https://serverfault.com/questions/996495/writes-throttled-to-500kb-s

Your symptoms seem quite different, but with 16GB of RAN, I'd strongly
suggest you try an amd64 kernel, just in case.


Stefan



Re : FFMPEG ?

2023-08-14 Thread k6dedijon
Bonjour Ptitlou,
Je ne sais pas pour FFMPEG, mais tu parles aussi de format RAW pour Canon.

Pour ce point UFRAW existe soit en plugin pour GIMP, soit en utilitaire 
indépendant.
L'interface indépendante permet de tirer le meilleur des fichiers RAW.
Cela demande un peu d'apprentissage par essais de manipulation mais on obtient 
de très bons résultats.
Liste des appareils pris en charge par UFRAW :
https://ufraw.sourceforge.net/Cameras.html

Pour ma part, je préfère passer par l'interface indépendante UFRAW, puis une 
fois le résultat obtenu, je bascule sur GIMP.
Site officiel :
https://ufraw.sourceforge.net/
didacticiel plugin :
http://gimpfr.org/document/document_22/

Voili, voilou ma contribution
Cassis
 


- Mail d'origine -
De: ptilou 
À: debian-user-french@lists.debian.org
Envoyé: Wed, 09 Aug 2023 12:19:12 +0200 (CEST)
Objet: FFMPEG ?

Bonjour,

Je lis :
ffmpeg est un convertisseur vidéo et audio très rapide qui peut également 
récupérer à partir d'un fichier audio/vidéo en direct
la source. Il peut également convertir entre des taux d'échantillonnage 
arbitraires et redimensionner la vidéo à la volée
avec un filtre polyphasé de haute qualité.

sur un site qui propose d'executer style AWS, une distribution Linux , 
quelqu'un connait une avec Debian ?
(onworks[dot]net/fr/programs/ffmpeg-all-online?amp=0)

Et en plus comme pour Canon, le rendu image/video donne quoi ? 
Y a t'il une amélioration concrete ?

J'ai une IA qui me veillit les personnes donc améliorer la qualité c'est pas 
plus facile sous Debian ?
( Je ne sais pas si l'IA est libre ?)

Sinon en proposition d'amelioration je vien de me rendre comptze que les 
panorama, si les images ne se suivent pas , çà ne le fait pas automatiquement ( 
j'en ai deja parlé il me semble), je viens de me rendre compte que le timers 
des images est trés proche, donc peut etre ameliorer de ce cote la creation par 
"IA" de panorama de façon auto ?

merci

-- 
Ptilou




Re: Cannot install Debian 12.1 on VirtualBox

2023-08-14 Thread Piscium
On Mon, 14 Aug 2023 at 12:47, Andrey Dogadkin  wrote:

> Should you specifically need UEFI next time, an alternative solution
> can be to temporarily disable KVM paravirtualization (default for
> Linux-based guests). It can be reenabled back after you are done with
> installation. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036310

Thanks for that! I think I had searched the bug list but somehow did
not find that bug. Glad to know that it has already been reported.
There is plenty of detail in there so no need for me to add to it. I
did a quick test a few minutes ago and can confirm that disabling
paravirtualization fixes the issue, as stated in the last comment in
the bug report. So it is good that there are two workarounds, and this
one is better than disabling EFI in some use cases.



Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

2023-08-14 Thread kjohnson
I have done additional research, and it now appears that programs that do 
extensive disk writes run much slower (3-6x) in Bookworm than they did in 
Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting an 
SQL backup of a Bacula database from Postgresql (backup file about 3 GB).  
Operations that perform extensive reads (a Bacula backup operation to magnetic 
tape, 600 GB) seem to run at the same speed as before.

At the moment, this is a 32-bit PAE system.  I don't know of an obvious reason 
why that would matter.  At the time of the upgrade, the system memory was 
enlarged from 16 to 32GB, in anticipation of converting the system from i386 to 
amd64.

Suggestions for tracking this down would be welcome.

Ken


Sent: Thursday, August 10, 2023 12:04 PM
To: 'debian-user@lists.debian.org'
Subject: svnadmin dump much slower in Bookworm

A set of svnadmin dump commands that run as part of a backup procedure seem to 
be _much_ slower in Bookworm than in Bullseye.  Prior to the upgrade to 
Bullseye, these commands took slightly less than one hour.  After the upgrade, 
similar commands (dumping a few more revisions) require more than six hours.  
The script that performs these commands has not been changed.  Has anyone else 
seen this problem?

Thanks,

Ken
 
 




Please could we calm down? [WAS List administrators - request]

2023-08-14 Thread Andrew M.A. Cater
People,

I'm not claiming any huge authority here: I'm a volunteer here and a reader
and contributor.

Recent threads have got out of hand, at least in part.

It is *really helpful* to be constructive and to try and put yourself in
someone else's place. There have been long rambling threads, some degree
of discontent and personal attacks. 

These don't help those reading this list for the first time. They don't help
the reputation of this list for long rambling threads that don't go anywhere.
They don't help people who actually come here seeking help for a Debian
problem.

Can I ask people to reconsider immediate responses to threads if you can
avoid it - sit on your hands for six hours or so and see if anyone else
jumps in before adding more UNLESS you can help someone immediately.

I post the FAQ every month in an effort to explain how this list might work.
Debian is odd because we still use mailing lists. Not everyone knows
to avoid top-posting, how to formulate a clear reply.

The Code of Conduct applies here as elsewhere in Debian: try and make this
a welcoming, useful place. You never know who you might help or who might
be driven away by someone's bad attitude.

Can we try this for a couple of days, please? If you can't add help 
immediately,maybe wait?

With thanks for your consideration

Andy

Andy Cater



Re: Lenteur au boot

2023-08-14 Thread Gaëtan Perrier
Hello,

Regardes du côté des montages. Moi j'avais un problème d'uuid avec le swap et 
ça me faisait pareil.

Gaëtan 

Le 14 août 2023 23:13:23 GMT+02:00, ajh-valmer  a écrit :
>Hello,
>Depuis la migration de mon portable à Bookworm,
>le boot se bloque environ 10 secondes avec un tiret en haut à gauche.
>Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity.
>Après, tout semble stable.
>Que se passe t-il pour avoir une première étape de boot si longue ?
>Merci.
>A. Valmer
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Debian 30 anos! 14 a 18 de agosto de 2023

2023-08-14 Thread Ricardo Marliere
On Mon, Aug 14, 2023 at 05:30:44PM -0300, Paulo Henrique de Lima Santana wrote:
> Olá pessoal.
> 
> Hoje começa a transmissão das palestras que faremos durante toda a semana
> para celebrar os 30 anos do Projeto Debian!

Obrigado pelo lembrete, estarei acompanhando pelo youtube!


-- 
Ricardo Marliere
030A 8E9E 424E E3C0 6557
87E1 C90B 8A7C 6386 58A6


signature.asc
Description: PGP signature


Lenteur au boot

2023-08-14 Thread ajh-valmer
Hello,
Depuis la migration de mon portable à Bookworm,
le boot se bloque environ 10 secondes avec un tiret en haut à gauche.
Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity.
Après, tout semble stable.
Que se passe t-il pour avoir une première étape de boot si longue ?
Merci.
A. Valmer



Re: por favor

2023-08-14 Thread Lucas Castro

Para sair da lista envie um e-mail para

debian-user-portuguese-requ...@lists.debian.org

 com assunto: unsubscribe


informações retiradas do cabeçalho do email.


List-Unsubscribe:

Em 14/08/2023 17:54, Michel Bdec escreveu:

por favor pode tirar meu email da lista
mxlb...@gmail.com



Obrigado.

Lucas Castro.



OpenPGP_signature
Description: OpenPGP digital signature


por favor

2023-08-14 Thread Michel Bdec
por favor pode tirar meu email da lista
mxlb...@gmail.com


por favor

2023-08-14 Thread Michel Bdec
por favor pode tirar meu email da lista?


Re: Résolu: [bookworm] Gnome et scaling

2023-08-14 Thread Gaëtan Perrier
Plutôt contourné que résolu ... ;)

Le lundi 14 août 2023 à 10:59 +0200, Jean-Marc a écrit :
> Cool de savoir que ce problème est résolu.
> 
> Le 13/08/23 à 23:23, Gaëtan Perrier a écrit :
> > Oui effectivement pour l'instant je suis arrivé dans un état
> > satisfaisant.
> > 
> > Gaëtan
> > 
> 
> -- 
> Jean-Marc



Re: Debian 30 anos! 14 a 18 de agosto de 2023

2023-08-14 Thread Paulo Henrique de Lima Santana

Olá pessoal.

Hoje começa a transmissão das palestras que faremos durante toda a 
semana para celebrar os 30 anos do Projeto Debian!


19:00
Nova geração: uma entrevista com iniciantes no projeto Debian
Palestrantes: Antonio Terceiro, Thais Araujo e Aquila Macedo

20:30
Instalação personalizada e automatizada do Debian com preseed
Palestrante: Eriberto Mota

https://www.youtube.com/watch?v=hTXZ0Oe8fGU

O programação completa pode ser vista em:
http://deb.li/30anos

Abraços,

Em 01/08/2023 21:11, Paulo Henrique de Lima Santana escreveu:

Olá pessoal,

Todos os anos no dia 16 de agosto (ou no sábado mais próximo) 
comunidades ao redor do mundo organizam nas suas cidades o Debian Day 
com o objetivo de celebar o aniversário do Debian, sendo um dia 
totalmente dedicado a divulgação e contribuições ao Projeto.


Mas em 2023 o Projeto Debian completerá 30 anos!

Para celebrar esta data especial, a comunidade Debian Brasil realizará 
não apenas um dia de atividades, e sim uma semana inteira de palestras 
online com pessoas que contribuem para o Debian :-)


O evento chamado de "Debian 30 anos" acontecerá de 14 a 18 de agosto 
(segunda a sexta) das 19h às 22h, com transmissão pelo nosso canal do 
YouTube:

https://www.youtube.com/DebianBrasilOficial

Para ver a programação completa do evento, acesse:
https://deb.li/30anos

Ah, e várias comunidades realizarão atividades nos dias próximos a 16 de 
agosto. Para ver o que as outras cidades estão programando, acesse:

https://wiki.debian.org/DebianDay/2023

Abraços,



--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


OpenPGP_signature
Description: OpenPGP digital signature


Re: random number generator missing after upgrade

2023-08-14 Thread davidson

On Mon, 14 Aug 2023 Björn Persson wrote:

David Wright wrote:

On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:

Other functions in the same source file create /dev/tpm0, and it looks
like the random number generator should get registered together with
the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
the value of that option?


$ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
/boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
$


Thanks. And look at that:

# grep CONFIG_HW_RANDOM_TPM /boot/config-*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
# grep CONFIG_HW_RANDOM_TPM /boot/config-6.1.0-11-amd64 ; echo $?
1

So apparently randomness from a TPM is completely disabled in Debian 12
regardless of manufacturer. Next question: Why?


Debian Bug #1041007
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041007#10

 Message #10
 From: Vincent Blut
 [...]
 Subject: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG 
support (CONFIG_HW_RANDOM_TPM)
 Date: Sat, 29 Jul 2023 00:33:35 +0200

 [...]
 Indeed, this regression compared to the kernel provided in bullseye
 is due to a configuration issue.
 For HW_RANDOM_TPM to be enabled, the TCG_TPM and HW_RANDOM config
 symbols are required but there is a subtlety in the way they have to
 be built. If TCG_TPM is built-in then HW_RANDOM must not be loadable
 (built as a module).

 If we take a look at the kernel configuration files prior being
 constructed, we can see that both TCG_TPM and HW_RANDOM config
 symbols should be built as modules:

 $ grep -Er "TCG_TPM|HW_RANDOM="
 arm64/config:CONFIG_TCG_TPM=m
 kernelarch-x86/config:CONFIG_TCG_TPM=m
 config:CONFIG_HW_RANDOM=m
 config.cloud:CONFIG_TCG_TPM=m

 However after these files have been constructed, the TCG_TPM config
 symbol is no longer provided as module but built-in:

 $ grep TCG_TPM /boot/config-6.3.0-1-amd64
 CONFIG_TCG_TPM=y

 This change is what causes HW_RANDOM_TPM to be disabled and is
 probably due to

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=644f17412f5acf01a19af9d04a92193
 [...]

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Mailing list unsubscription requests and identificatio

2023-08-14 Thread gene heskett

On 8/14/23 12:24, zithro wrote:

On 12 Aug 2023 04:39, gene heskett wrote:

On 8/11/23 21:10, Larry Martell wrote:
Larry, whom I've known for 20 years, is only echoing.
  Are you really an engineer ?!


No, I am not an EE, but I am a Certified Electronics Technician, a 
much rarer breed of cat than your run of the mill EE.  We teach EE's 
how to get their hands dirty in the real world. Teaching them things 
their tenured by mistake prof's didn't.


Ok, so you should follow specs and best practices, right ?

Who is a random person to you? You’re new to this list, so you have 
no clue who is who here.


Thanks Larry. Take care & stay well, both of you.


The list is public since the start.

But I admit my post was misleading, lacking some transition between my 
objections to Gene and the remainder.


Gene is far from the random people I ranted about, and it doesn't take 
long to know he's rather a top poster, respectful and polite.


Gene, if you took it personnaly, I sincerely apologize.
That was really NOT my intent.

And I didn't take it that way, but I did try to fix the missing 
attribution.  NP IOW, take care & stay well.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 



Re: setting up network with a hosts file, but your way

2023-08-14 Thread gene heskett

On 8/14/23 12:04, zithro wrote:

On 12 Aug 2023 20:49, gene heskett wrote:

ipv6:
There is no ipv6 service within 100 miles, so I should set a /proc 
command to kill ipv6, so whats the official syntax? for that.


I don't know if there is another method, I'll give you mine, which 
consists in telling the kernel to completely disable IPv6, in the kernel 
command line.


Edit "/etc/default/grub", on the line "GRUB_CMDLINE_LINUX" (or 
"GRUB_CMDLINE_LINUX_DEFAULT", depending on your config), add :


   ipv6.disable=1

Don't forget to run "update-grub", then reboot.

If it worked, you will find in the syslog :
"IPv6: Loaded, but administratively disabled, reboot required to enable".

If you're not using GRUB, you will have to find where kernel options 
should be entered (also called kernel command line).


Thanks zithro, but it appears that it is no longer needed, just follow 
Gregs recipe and it works.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 



Re: Cannot install Debian 12.1 on VirtualBox

2023-08-14 Thread Andrey Dogadkin
On Sat, 2023-08-12 at 23:26 +0100, Piscium wrote:

> That was it, EFI! Normally when I install an OS on VB for the first
> time, if it does not work with EFI I disable it, or vice versa.
> However in this case I created this VM long ago, so it never occurred
> to be that it would go backwards, so to speak, from working with EFI
> to not working! Oh well, in hindsight it is obvious. Sometimes one
> misses what is in front of one's nose! One reason I missed it is
> because in my past experience if it does not boot due to EFI or not
> EFI, it stops at the very beginning, unlike in this case where I got
> to the first screen that has the menu for graphical install, etc.

Should you specifically need UEFI next time, an alternative solution
can be to temporarily disable KVM paravirtualization (default for
Linux-based guests). It can be reenabled back after you are done with
installation. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036310



Re: random number generator missing after upgrade

2023-08-14 Thread Björn Persson
David Wright wrote:
> On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:
> > Other functions in the same source file create /dev/tpm0, and it looks
> > like the random number generator should get registered together with
> > the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
> > the value of that option?  
> 
> $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
> /boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
> /boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
> $ 

Thanks. And look at that:

# grep CONFIG_HW_RANDOM_TPM /boot/config-*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
# grep CONFIG_HW_RANDOM_TPM /boot/config-6.1.0-11-amd64 ; echo $?
1

So apparently randomness from a TPM is completely disabled in Debian 12
regardless of manufacturer. Next question: Why?

Björn Persson


pgppuJfr4uqri.pgp
Description: OpenPGP digital signatur


Re: List administrators - request for intervention - was - Re: Mailing list unsubscription requests and identificatio

2023-08-14 Thread davidson

On Mon, 14 Aug 2023 Bret Busby wrote:

On 14/8/23 03:36, davidson wrote:

On Sun, 13 Aug 2023 Andy Smith wrote:

Hello,

On Sun, Aug 13, 2023 at 12:12:49AM +, davidson wrote:

The foregoing demonstration is meant to show how, using alpine's
threaded mode, I minimise my irritation with threads that I find
irrelevant to my interests


Unfortunately no matter how advanced your MUA is, it doesn't help
against prolific posters who derail nearly every thread with
copious amounts of irrelevance and outright false information.


This is a higher bar than merely neutralising the disruption (to
one's own use of the list) caused by a popular thread that one has
little interest in.

And here, my instincts are screaming "Leave it here. Stop
now. Leave well enough alone for the sake of all that is holy!"

However, and speaking only for myself, I'll bite:

Being able to see a thread's messages structured as a tree of
message headers (author, subject) can indeed help me infer quite a
bit about what's going on, before I bother to dig in and actually
read any of the messages' content.

For example, let P and Q be two regularly prolific participants, P
with exceptionally high signal-to-noise contributions, and Q a hot
willfully clueless mess. If there is a branch of the tree that is
just a chain of back-and-forth between P and Q --Q.P.Q.P.Q...--
then I know what's going on in there and so some OTHER branch will
be my first destination, unless I'm in the mood for a laugh.


You can easily see from looking at most of the large threads here,
the points at which they go off the rails and the common factors
involved there.


I can indeed. Without seeing the tree structure, I do not think it
would be so easy to see.


It is a difficult problem to solve as mailing lists like this tend
to promote a volume-wins approach,


You may be correct, but this isn't clear to me. (Unless the object
of the game is to annoy the greatest number of participants.)


and the baseline user will not have an advanced MUA nor necessarily
the experience to know that they're reading nonsense.


When I conquer the world, you will know because /etc/motd will
contain something like this:

   Don't enter commands you don't understand, and you won't
   understand the commands unless you read the manual. If you read
   the manual, you STILL may not understand the
   commands. Nevertheless, keep trying, Curious Human. We are
   rooting for you!


Things get easier when you use an advanced MUA, so people should
invest the time to do so, but let's not pretend that this will avoid
a mega-thread next time some outlandish thread hijack by one of the
usual suspects happens.


My point was simply this: threads I've lost interest in (regardless
of size) are a single line in my mailbox, provided I do not delete
its initial message.


Does this particular thread go much better if you assume that
everyone participating (except the OP, who doesn't know how to
unsubscribe, or how to spell it) is fully competent at efficiently
managing email but still posts as they posted?


Funnily enough, if you look carefully, you can see some utterly
slapstick confusion of that very nature in this thread, over who is to
blame for posting a red-herring link to the Alpine Linux distro
mailing list:

%<---
 18159 Thursday   glenn green(6K) . UNUBSCRIBE
 ...   ............
[1] 18192 Yesterday  fjd (7K) .   |  \-Alpine was
[2] 18193 Yesterday  Bret Busby  (8K) .   ||-Re: Alpi
[6] 18194  5:55  fjd (7K) || |-Re: Al
[7] 18195  6:11  fjd (8K) || \-Re: Al
[3] 18196 Yesterday  Jeffrey Walton  (7K) .   |\-Re: Alpi
[4] 18197 Yesterday  Greg Wooledge   (5K) .   |  \-Re: Al
[5] 18198  2:41  Bret Busby  (9K) .   |\-Re:
 18199 Yesterday  David Wright   (6K) |  \-Re

--->%

Somebody requests a link to an alpine MUA forum or mailing list.
  [1] https://lists.debian.org/debian-user/2023/08/msg00333.html

Somebody posts a link to an alpine MUA mailing list.
  [2] https://lists.debian.org/debian-user/2023/08/msg00341.html

Somebody else posts a red-herring link, to a mailing list concerning
the linux distro called Alpine Linux.
  [3] https://lists.debian.org/debian-user/2023/08/msg00355.html

Then Greg points out, in reply to the red-herring poster, that they
have posted a red herring. <-- Here is where the tree structure view
is illuminating.
  [4] https://lists.debian.org/debian-user/2023/08/msg00356.html

And then the person who had posted the CORRECT link in the first
place apologises for posting the wrong one, and posts the very same
correct link once again. <-- This 

issue after Kernel upgrade

2023-08-14 Thread Tim McConnell
Hi List, 
I upgraded my Kernel and now after restarting my computer I have to go
into /proc/sys/user/max_*_namespaces and modify the value to something
other than 0 (zero). Where do I file a bug? 
I'm on Debian Stable with Kernel version 6.1.0-11-amd64 if it helps
any. 
Thanks! 
-- 
Tim McConnell 



Re: List administrators - request for intervention - was - Re: Mailing list unsubscription requests and identificatio

2023-08-14 Thread davidson

On Sun, 13 Aug 2023 Jeffrey Walton wrote:

On Sun, Aug 13, 2023 at 4:33 PM davidson  wrote:

[...]
Somebody else posts a red-herring link, to a mailing list concerning
the linux distro called Alpine Linux.
 [3] https://lists.debian.org/debian-user/2023/08/msg00355.html

Then Greg points out, in reply to the red-herring poster, that they
have posted a red herring. <-- Here is where the tree structure view
is illuminating.
 [4] https://lists.debian.org/debian-user/2023/08/msg00356.html
[...]
(The person who really HAD posted the red herring says nothing.)


What would you have me say? Greg made the correction.


I laid out the details of the process leading to the three-car
miscommunication pileup because it serves as a handy illustrative
example, in response to a question about whether knowledge of thread
structure could affect participant decisions.

Description, not prescription. I'm not here to tell consenting adults
what to do.


Do you really need more fodder from me?


Nope. For my part I am fully up to speed.

But have you noticed the other fellow in this thread, who is now
calling me a malicious liar for giving you all the credit, and openly
fantasising about how underground debian justice-league ninjas are
about to break into my house, delete my account, and swap the taps in
my shower?

Looks like I'm in for a real Amélie Poulain job, it does. But the
joke's on him; I get the taps confused every time anyways, so at worst
I won't notice a thing.


But I'll give you what you want...


I'm not a priest. And, just for the record since you seem to have read
me otherwise, I happen to think everyone's behavior so far has been
pretty normal human behavior, given reasonable assumptions about what
each knew at the time of their respective contributions.

The sheer normality of it is what makes it a good example, and perfect
comedy.


I sincerely apologize for posting an incorrect link to an Alpine
mailing list.  I am so sorry I troubled you for it.  I hope you can
find it in your heart to forgive me for the transgression, and the
inconvenience I caused to all members of the list.


I welcome your evident sarcasm here as a sign that we both agree that
the miscommunication event in question was a very normal one.

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Mailing list unsubscription requests and identificatio

2023-08-14 Thread zithro

On 12 Aug 2023 04:39, gene heskett wrote:

On 8/11/23 21:10, Larry Martell wrote:
Larry, whom I've known for 20 years, is only echoing.
  Are you really an engineer ?!


No, I am not an EE, but I am a Certified Electronics Technician, a much 
rarer breed of cat than your run of the mill EE.  We teach EE's how to 
get their hands dirty in the real world. Teaching them things their 
tenured by mistake prof's didn't.


Ok, so you should follow specs and best practices, right ?

Who is a random person to you? You’re new to this list, so you have no 
clue who is who here.


Thanks Larry. Take care & stay well, both of you.


The list is public since the start.

But I admit my post was misleading, lacking some transition between my 
objections to Gene and the remainder.


Gene is far from the random people I ranted about, and it doesn't take 
long to know he's rather a top poster, respectful and polite.


Gene, if you took it personnaly, I sincerely apologize.
That was really NOT my intent.

--
++
zithro / Cyril



Re: setting up network with a hosts file, but your way

2023-08-14 Thread zithro

On 12 Aug 2023 20:49, gene heskett wrote:

ipv6:
There is no ipv6 service within 100 miles, so I should set a /proc 
command to kill ipv6, so whats the official syntax? for that.


I don't know if there is another method, I'll give you mine, which 
consists in telling the kernel to completely disable IPv6, in the kernel 
command line.


Edit "/etc/default/grub", on the line "GRUB_CMDLINE_LINUX" (or 
"GRUB_CMDLINE_LINUX_DEFAULT", depending on your config), add :


  ipv6.disable=1

Don't forget to run "update-grub", then reboot.

If it worked, you will find in the syslog :
"IPv6: Loaded, but administratively disabled, reboot required to enable".

If you're not using GRUB, you will have to find where kernel options 
should be entered (also called kernel command line).


--
++
zithro / Cyril



Captive Portal Linux Debian

2023-08-14 Thread Marcelo
Bom dia Pessoal,

Alguém usando um Captive portal Linux?

Tenho usado o pfsense atualmente mas sempre quero usar um dentro do Debian
mesmo.

Alguma sugestão de projeto?


Muito Obrigado,
Marcelo


Re: random number generator missing after upgrade

2023-08-14 Thread David Wright
On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:

> Other functions in the same source file create /dev/tpm0, and it looks
> like the random number generator should get registered together with
> the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
> the value of that option?

$ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
/boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
$ 

Cheers,
David.



Re: [bookworm] Gnome et scaling

2023-08-14 Thread Fabien R

On 13/08/2023 20:48, Gaëtan Perrier wrote:


Oui c'est plus ça ce que je cherche. Mon portable à un écran 12,5" je
crois et le FHD sur cette surface ça fait des caractères très petit...

La commande suivante ne ferait-elle pas l'affaire ?
xrandr --scale-from

-
Fabien



Re: random number generator missing after upgrade

2023-08-14 Thread Björn Persson
Anders Andersson wrote:
> On Sun, Aug 13, 2023 at 11:09 PM Björn Persson  wrote:
> > Jeffrey Walton wrote:  
> > > Maybe related to 
> > > https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs  
> >
> > Not likely. That article is about a firmware TPM that comes with newer
> > Ryzen processors. Older Ryzens supposedly don't have it. The processor
> > in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete
> > chip from Infineon. The change in question is supposed to disable the
> > random number generator only if the TPM lists AMD as its manufacturer.  
> 
> I agree that the patch looks ok, but I remember being hit by a kernel
> change that inadvertently changed the behavior on other systems too
> (ECC RAM background scrubbing), but nobody really noticed because it
> was not in much use.
> 
> I suspect that the case of having an external TPM on an AMD system is
> such an unusual case, and I couldn't trace exactly where that patch
> checked the AMD string, so perhaps it's picking up the AMD string
> earlier on, and decides to disable all TPM on the AMD system. At least
> the timing of the problem and the patch is suspicious.

I see the 6.1 branch contains the first attempt at working around the
stutter problem, which disables randomness only from certain known
broken firmware versions:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=linux-6.1.y#n510

It's supposed to log a warning when it takes effect:
"AMD fTPM version 0x%llx causes system stutter; hwrng disabled\n"
That message does not appear in my logs.

The new workaround, which disables randomness from all AMD firmware TPUs
and doesn't log, can be in effect only if it has been backported to
Debian's kernel very recently. That does not seem to be the case, if
this is the right way to look for backports:
https://salsa.debian.org/kernel-team/linux/-/commits/bookworm/

I'll check what the manufacturer number is on my system, if I can
figure out how to get at it.

Björn Persson


pgp1FtuqAK5To.pgp
Description: OpenPGP digital signatur


Re: random number generator missing after upgrade

2023-08-14 Thread Björn Persson
Dan Ritter wrote:
> OK, either boot to the old kernel and look for an rng kernel
> module,

The only loaded module with "rng" in its name is "rng_core". That one
is present in both kernels, but four TPM-related modules are absent
from Linux 6.1:

# uname -v
#1 SMP Debian 5.10.179-3 (2023-07-27)
# lsmod | egrep -i 'rng|tpm'
tpm_crb20480  0
tpm_tis16384  0
tpm_tis_core   28672  1 tpm_tis
tpm73728  3 tpm_tis,tpm_crb,tpm_tis_core
rng_core   16384  3 ccp,tpm

# uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.38-3 (2023-08-07)
# lsmod | egrep -i 'rng|tpm'
rng_core   20480  1 ccp

And yet /dev/tpm0 exists in both kernels, but disappears when I
physically remove the TPM, so the TPM is recognized to some degree even
without those modules.

Those four TPM-related modules are also present as files under
/lib/modules in Linux 5.10, but absent in Linux 6.1. The corresponding
source files still exist in the source tree. Have they been disabled in
Debian 12? Have they been moved to some "extra modules" package that I
haven't found? Or are they just not modules because they're statically
built-in?

> or identify the rng hardware a little better

As I wrote in my first email, it seems to be an Infineon SLB 9665TT2.0.
It says "SLB9665TT20" on the chip package.

These characters are also written on the package. They mean nothing to
me, but maybe they can be used to identify the hardware better:
G1946KIV
51ZA947148IA1
(It's extremely difficult to tell I from 1 though.)

> and look
> for it in the kernel sources at 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random

In that directory I don't see anything that looks relevant.

The identifier "tpm-rng-0" comes from tpm_add_hwrng in
drivers/char/tpm/tpm-chip.c, which is still there:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=v6.1=830b3c68c1fb1e9176028d02ef86f3cf76aa2476#n517

Other functions in the same source file create /dev/tpm0, and it looks
like the random number generator should get registered together with
the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
the value of that option?

Björn Persson


pgperdoICnD28.pgp
Description: OpenPGP digital signatur


Résolu: [bookworm] Gnome et scaling

2023-08-14 Thread Jean-Marc

Cool de savoir que ce problème est résolu.

Le 13/08/23 à 23:23, Gaëtan Perrier a écrit :

Oui effectivement pour l'instant je suis arrivé dans un état
satisfaisant.

Gaëtan



--
Jean-Marc


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer

2023-08-14 Thread Thomas Schmitt
Hi,

please reply to the list in order to keep all readers informed.
(It would be ok to Cc my mail address, but it is not necessary.)

- Forwarded message from Sakkra Billa  -
Date: Mon, 14 Aug 2023 09:32:37 +0530
From: Sakkra Billa 
To: Thomas Schmitt 
Subject: Re: Bootloader error grub minimal bash "load the kernel first"
after installing my live image via calamares installer

Thanks for the reply. I tried debian di too but wasn't successful in that
either it said that the kernel version for live and installer were not the
same.

- End forwarded message -

The problem is out of my range of experience and probably out of the
experience of the other participants here.

So you will have to ask the Debian Installer experts what goes wrong.

  https://wiki.debian.org/DebianInstaller
proposes
  Email: debian-b...@lists.debian.org
  IRC: #debian-boot

To improve your chances for helpful replies you should give them tangible
information. At least:
- The possibile configuration of the installer,
- the commands used to bring it into the directory tree which later
  becomes the ISO content,
- the exact error messages you get from the attempt to use the installer.
  (Even if this means that you have to manually toggle them into your
   mail.)


Have a nice day :)

Thomas



Re: random number generator missing after upgrade

2023-08-14 Thread Anders Andersson
On Sun, Aug 13, 2023 at 11:09 PM Björn Persson  wrote:
>
> Jeffrey Walton wrote:
> > Maybe related to https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs
>
> Not likely. That article is about a firmware TPM that comes with newer
> Ryzen processors. Older Ryzens supposedly don't have it. The processor
> in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete
> chip from Infineon. The change in question is supposed to disable the
> random number generator only if the TPM lists AMD as its manufacturer.

I agree that the patch looks ok, but I remember being hit by a kernel
change that inadvertently changed the behavior on other systems too
(ECC RAM background scrubbing), but nobody really noticed because it
was not in much use.

I suspect that the case of having an external TPM on an AMD system is
such an unusual case, and I couldn't trace exactly where that patch
checked the AMD string, so perhaps it's picking up the AMD string
earlier on, and decides to disable all TPM on the AMD system. At least
the timing of the problem and the patch is suspicious.