Re: virt-manager guest does not start anymore after upgrade to bookworm / opengl is not available

[zithro]

On 07 May 2023 16:41, Rainer Dorsch wrote:

Hello,

after upgrading to bookworm, my windows guest does not start anymore, but
throws an error message:

Fehler beim Starten der Domain: internal error: qemu unexpectedly closed the
monitor: 2023-05-07T14:27:35.862395Z qemu-system-x86_64: -device
{"driver":"virtio-vga-gl","id":"video0","max_outputs":1,"bus":"pcie.
0","addr":"0x1"}: opengl is not available

>

[snip]

>

I configured a virtio video device, if I remove 3D acceleration, the guest
starts w/o a problem.

Can anybody tell what broke in the 3D acceleration during the upgrade?

Any hint or advice is welcome :-)


I'm no QEMU/openGL expert, but are you sure the "virtio-vga-gl" device 
is still supported ? Maybe you need another one ?
(I vaguely remember having a problem with an audio device which wasn't 
supported anymore).

Re: relevance of packages in repositories

[zithro]

On 07 May 2023 12:14, Дмитрий wrote:


the stable version of Neodim 9.0 in debian 12 is the SEVENTH version, and in 
order to get the current version, you need to drag something like Homebrew, it 
really pisses you off and pushes you away from using the distribution


Ahah this post ! ^^
For future posters, this is a perfect example of how NOT to post !
He's lucky others have answered.

An evasive subject.
No politeness.
An wrong/approximate package name.
No real question, just ranting.

In short, zero time taken.
Please fart once before posting next time, you may feel better, and less 
look like a fool ...


I think I found OP's problem, he's infected with the PEBCAK virus.

Re: AW: Was it a good idea to buy an Epson printer?

[Max Nikulin]

On 03/05/2023 16:34, Nicolas George wrote:

Schwibinger Michael (12023-05-03):

What do I do wrong?

...> - Using 0x65 0x57 0x3A 0x20 instead of 0x52 0x65 0x3A 0x20 as a reply

   marker in the subject.


I do not think it has any significance. It may be tricky to configure 
locale of mail client per sender. "AW" instead of "Re" in subject line 
is common enough in mails sent by German users to not bother.

Re: User is not in the sudoers file

[황병희]

On Mon, 2023-05-08 at 17:08 -0600, Charles Curley wrote:
> On Mon, 8 May 2023 17:27:24 +0200
>  wrote:
> 
> >  (2) add your user to the sudo group. I'd prefer (2).
> 
> usermod -a -G sudo 

Oh Good! Thanks for tip!


Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: User is not in the sudoers file

[Charles Curley]

On Mon, 8 May 2023 19:41:35 -0400
Greg Wooledge  wrote:

> Wanna be lazier?

Nah. I'm too lazy to edit my script. :-)

-- 
Does anybody read signatures any more?

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

Re: Debian et cartes graphique Intel ARC ?

[Gaëtan Perrier]

Le lundi 08 mai 2023 à 09:51 +0200, Basile Starynkevitch a écrit :
> 
> On 5/8/23 06:13, Bernard Schoenacker wrote:
> > 
> > - Mail original -
> > De: "Gaëtan Perrier" 
> > À: "debian-user-french" 
> > Envoyé: Lundi 8 Mai 2023 02:46:12
> > Objet: Debian et cartes graphique Intel ARC ?
> > 
> > Bonjour,
> > 
> > Est-ce que les cartes graphiques Intel ARC, notamment ARC 750/770 sont bien
> > supportées sur les debian ?
> > Par rapport aux Nvidia/AMD avez-vous des retours d'expériences ?
> > 
> > A+
> > 
> > Gaëtan
> > 
> > 
> > Bonjour,
> > 
> > Avec G.. , il faut décapsuler pour que son esprit s'éveille, les données
> > sont
> > disponibles chez Intel avec la procédure d'installation pour les paquets
> > Deb
> > même si c'est inscrit pour Ubuntu...
> 
> 
> 
> Bonjour,
> 
> 
> Je n'ai pas de carte Intel ARC.
> 
> J'ai entendu dire que pour l'affichage elles sont bien supportées par 
> Linux. Je l'ai lu sur 
> https://www.phoronix.com/review/intel-a750-a770-arc-linux
> 
> Par contre, les cartes graphiques haut de gamme peuvent aussi être 
> utilisées pour du calcul matriciel spécialisé. NVIDIA propose 
> https://developer.nvidia.com/cuda-toolkit (gratuit mais pas libre), et 
> AMD propose OpenCL https://fr.wikipedia.org/wiki/OpenCL (j'ai comprise 
> que c'est plus du logiciel en partie libre, et pas seulement gratuit).
> 
> 
> J'ignore quelles sont les possibilités de calcul vectoriel déporté sur 
> carte Intel ARC.
> 
> Si on veut faire du calcul scientifique intensif, ça a son importance!
> 
> Pour info, les compilateurs GCC récents proposent 
> https://gcc.gnu.org/wiki/OpenACC
> 

Niveau OpenCL ça semble pas mal: 
https://www.phoronix.com/review/arc-graphics-compute-q1

Niveau usages je vise Darktable/Rawtherapee et Flightgear.

A+

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: User is not in the sudoers file

[Greg Wooledge]

On Mon, May 08, 2023 at 05:08:44PM -0600, Charles Curley wrote:
> On Mon, 8 May 2023 17:27:24 +0200
>  wrote:
> 
> >  (2) add your user to the sudo group. I'd prefer (2).
> 
> usermod -a -G sudo 
> 
> I'm lazy. I have that in a script.

Wanna be lazier?  In Debian, you can do it this way:

adduser  sudo

Re: User is not in the sudoers file

[Charles Curley]

On Mon, 8 May 2023 17:27:24 +0200
 wrote:

>  (2) add your user to the sudo group. I'd prefer (2).

usermod -a -G sudo 

I'm lazy. I have that in a script.

-- 
Does anybody read signatures any more?

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

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/8/23 16:57, gene heskett wrote:

On 5/8/23 07:49, Brian wrote:

On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:


On 5/7/23 12:48, Brian wrote:


[...]


Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.

gene@bpi51:~$ lpstat -t
scheduler is running
system default destination: PDF
device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
device for PDF: cups-pdf:/


Thanks.

'lpstat -t' only ever shows *local* printers. That is, printers that have
been set up (manually in this case) on the local machine. It will never
discover and  show printers on the network. This was mentioned earlier in
this thread, but you do not appear to appreciate its significance.

To be clear: HLL2320D-RAW and PDF are local printers. We set up 
HLL2320D-RAW
(which is a working printer) togetger. Should you wish to see *all* 
devices

(local and on the network) us

   lpstat -e
   lpstat -l -e

Aha! now the two bpi's see all shares, + add the pdf generator if its 
installed. The HLL2320D as seen by -t, is the result of our earlier 
test, it actually added the printer to the local lp world. But not to cups.


I'll update bpi51 when the current part is finished, probably about an 
hour yet.


And that updated 77 pkgs, but did not require a reboot.  And no pkg 
changed anything about the cups blank printers discovered screen at 
localhost:631.


And its back to making another part. Busy till around 2am local

Thanks Brian.



The second command was explained earlier in the thread.

[...]


gene@bpi54:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL-L2320D_series:
usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for Brother_MFC-J6920DW_photo:
usb://Brother/MFC-J6920DW?serial=BROG5F229909
device for HLL2320D: 
usb://Brother/HL-L2320D%20series?serial=U63877H0N346913

device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909


These are the local printers on bpi54. All connected by USB. All set 
up by

you and all working

Summary: Everything is as it should be.

Your first mail has:

   > All of my bullseye machines are locked out, printer screen at
   > localhost:631 is empty, and no printers can be found and added.


You are missing the point, lpstat is seeing them, but cups is not.
That it seems to me, s/b where we should be concentrating our discovery 
efforts. FWIW reinstalling cups and cups-browsed has been done, made no 
difference that I could detect. Is there something I could put at the 
top of /etc/cups/cupsd.conf to make any failures or rejects generate 
meaningful msgs in /var/log/cups/error_log?





   > But open a shell, and type "lpstat -t" and it gets the full list of
   > available printers on that same bullseye machine whose cups 
output is

   > empty.

The facts as expressed are OK. Your interpretation of them is 
sub-optimal.

A lack of understanding about what localhost:631 and 'lpstat -t' show is
the root of problem and colours everything you have written here..

[...]
Apple ceased any involvement with CUPS development and parted 
company with
its Chief Printing Engineer a number of years ago. Debian CUPS is 
produced
by a team led by the creator of CUPS. Your requested fix is in place 
:).


If so, (this is the first I've heard of it, and I've only known Michael
since the late 1980's when we were both heavily involved in the os9
development, a mini unix that ran of the trs-80 color computers) 
where do I

email now to be assured Michael will see it? Is there a new cups mailing
list?


Please see our wiki.

Do you have any idea if that fix will be released for arm64 bullseye? 
I just
checked bpi54, no updates available since the Friday update. Ditto 
for the
intel busters here, but they're busters, so don't need the fix, they 
Just

Work.


I haven't a clue about arm64. I am not even sure that CUPS is the 
issue. You
have a classical local printer set up. It works. There are three other 
printers
that could be set up with the same technique. Remenber - you are the 
one who

does not want a New Architecture setup.


The big inkjet is well over 5 years old, and among other things the New 
Architecture does not recognize is it has two trays for paper source, 
always using the $0.12 a sheet glossy photo from the top tray.


Imagine what it would cost me to print all 1330 some pages of the 
current linuxcnc user docs. Not to mention I'd have to reload that 
smaller tray about 14 times. Tain't gonna happen.


And my ISP is having email probs its Monday.


Took them till close to noon to find it.

Thanks Brian.

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 

OpenCL, boinc, and systemd resource limits

[Arno Lehmann]

Hi all,

back to trying to get OpenCL-based boinc workloads running.

It appears that the AMD-provided OpenCL stack works to some extent under 
Debian 12. However, I have some problems with OpenCL-Using boinc-managed 
PrimeGrid programs.


I do get an error that seems to indicate some resource limit being involved:

Error: opencl error: CL_OUT_OF_HOST_MEMORY

when I run the boinc client through systemd.

If the boinc client is run from the shell, for example as

sudo -u boinc boinc

in its proper working directory, everything behaves correctly.

Given the circumstances I suspect some sort of limit on memory.

I just have no idea how I can diagnose this further, or even how to fix 
it. An attempt with a unit file override with


[Service]
LimitMEMLOCK=1073741824
LimitMEMLOCKSoft=1073741824

was not successful.

Does anybody have an idea, or can share recommendation where to ask for 
more advice? (Debian project, i.e. here because this might be 
integration / packaging related, freedesktop.org for systemd, boinc 
project, perhaps -- trying to get assistance at PrimeGrid did so far not 
result in anything helpful.)



Thanks,

Arno

--
Arno Lehmann

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

Re: relevance of packages in repositories

[John Hasler]

Jeff writes:
> Unstable does not get security updates by the Debian Security Team. If
> you want timely security updates, then you have to look elsewhere.

In practice Unstable almost always gets security updates as quickly or
more quickly than Stable does.  Upstream usually only patches their
current release (or puts out a new release with the fix).  The Debian
maintainer then packages that and uploads it to Unstable while the
security team is backporting the fix to the version in stable.  
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Brad Rogers]

On Mon, 8 May 2023 12:37:35 -0400
chris  wrote:

Hello chris,

>Are we at the point yet where this has enough attention it would have
>been cheaper to crowd fund a new printer?? 藍藍

(smiley noted)

I'm betting even that wouldn't work;  At this point, I'm of the opinion
(after a quick glance through some of the earlier posts in this thread)
that the OP may have installed the driver from Debian but has not fired
up CUPS to actually make use of it.

Given their obvious difficulties with English (not their native tongue,
so entirely understandable) help from this point would have most likely
have to take the form of paying them a visit.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
I'm spending all my money and it's going up my nose
Teenage Depression - Eddie & The Hot Rods


pgphWZtkfPjsE.pgp
Description: OpenPGP digital signature

Re: relevance of packages in repositories

[Jeffrey Walton]

On Sun, May 7, 2023 at 3:10 PM Brian  wrote:
>
> On Sun 07 May 2023 at 14:57:32 -0400, Lee wrote:
>
> > On 5/7/23, Jeffrey Walton wrote:
> > > On Sun, May 7, 2023 at 7:30 AM Дмитрий wrote:
> > >>
> > >> the stable version of Neodim 9.0 in debian 12 is the SEVENTH version, and
> > >> in order to get the current version, you need to drag something like
> > >> Homebrew, it really pisses you off and pushes you away from using the
> > >> distribution
> > >
> > > You might give Fedora a try. Its release cadence is every 6 months. At
> > > each release, Fedora typically supplies the most current version of a
> > > package.
> > >
> > > You may find Fedora aligns better with your requirements.
> >
> > How about Arch linux?
> >
> > https://en.wikipedia.org/wiki/Arch_Linux
> >   Arch Linux is an independently developed, x86-64 general-purpose
> > Linux distribution that strives to provide the latest stable versions
> > of most software by following a rolling-release model.
>
> That sounds like a good description of Debian unstable :).

Ustable does not get security updates by the Debian Security Team. If
you want timely security updates, then you have to look elsewhere.
https://wiki.debian.org/DebianInstall#Unstable .

But if Unstable works for him, then great.

Jeff

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/8/23 07:49, Brian wrote:

On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:


On 5/7/23 12:48, Brian wrote:


[...]


Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.
  

gene@bpi51:~$ lpstat -t
scheduler is running
system default destination: PDF
device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
device for PDF: cups-pdf:/


Thanks.

'lpstat -t' only ever shows *local* printers. That is, printers that have
been set up (manually in this case) on the local machine. It will never
discover and  show printers on the network. This was mentioned earlier in
this thread, but you do not appear to appreciate its significance.

To be clear: HLL2320D-RAW and PDF are local printers. We set up HLL2320D-RAW
(which is a working printer) togetger. Should you wish to see *all* devices
(local and on the network) us

   lpstat -e
   lpstat -l -e

Aha! now the two bpi's see all shares, + add the pdf generator if its 
installed. The HLL2320D as seen by -t, is the result of our earlier 
test, it actually added the printer to the local lp world. But not to cups.


I'll update bpi51 when the current part is finished, probably about an 
hour yet.


Thanks Brian.


The second command was explained earlier in the thread.

[...]


gene@bpi54:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL-L2320D_series:
usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for Brother_MFC-J6920DW_photo:
usb://Brother/MFC-J6920DW?serial=BROG5F229909
device for HLL2320D: usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909


These are the local printers on bpi54. All connected by USB. All set up by
you and all working

Summary: Everything is as it should be.

Your first mail has:

   > All of my bullseye machines are locked out, printer screen at
   > localhost:631 is empty, and no printers can be found and added.
   >
   > But open a shell, and type "lpstat -t" and it gets the full list of
   > available printers on that same bullseye machine whose cups output is
   > empty.

The facts as expressed are OK. Your interpretation of them is sub-optimal.
A lack of understanding about what localhost:631 and 'lpstat -t' show is
the root of problem and colours everything you have written here..

[...]
  

Apple ceased any involvement with CUPS development and parted company with
its Chief Printing Engineer a number of years ago. Debian CUPS is produced
by a team led by the creator of CUPS. Your requested fix is in place :).


If so, (this is the first I've heard of it, and I've only known Michael
since the late 1980's when we were both heavily involved in the os9
development, a mini unix that ran of the trs-80 color computers) where do I
email now to be assured Michael will see it? Is there a new cups mailing
list?


Please see our wiki.


Do you have any idea if that fix will be released for arm64 bullseye? I just
checked bpi54, no updates available since the Friday update. Ditto for the
intel busters here, but they're busters, so don't need the fix, they Just
Work.


I haven't a clue about arm64. I am not even sure that CUPS is the issue. You
have a classical local printer set up. It works. There are three other printers
that could be set up with the same technique. Remenber - you are the one who
does not want a New Architecture setup.


The big inkjet is well over 5 years old, and among other things the New 
Architecture does not recognize is it has two trays for paper source, 
always using the $0.12 a sheet glossy photo from the top tray.


Imagine what it would cost me to print all 1330 some pages of the 
current linuxcnc user docs. Not to mention I'd have to reload that 
smaller tray about 14 times. Tain't gonna happen.


And my ISP is having email probs its Monday.




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: User is not in the sudoers file

[tomas]

On Mon, May 08, 2023 at 11:26:48AM -0400, Dan Purgert wrote:
> On May 08, 2023, Igor Korot wrote:
> > Hi, ALL,
> > Is there a reason for the default install
> > I immediately get the error in the subj?
> 
> You likely created a root account during the initial setup.  Doing that
> skips over adding the first user (created during install) to sudoers
> (i.e. "the operator created root, the operator will 'su root' when they
> want to be root").
> 
> As I recall, the installer asks if you want to create root, or use sudo.

Nitpick: root is always there. The question is whether it is
given a password at installation or not.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: User is not in the sudoers file

[tomas]

On Mon, May 08, 2023 at 11:20:17AM -0400, Dan Ritter wrote:
> Igor Korot wrote: 
> > Hi, ALL,
> > Is there a reason for the default install
> > I immediately get the error in the subj?
> > 
> > Basically trying to run:
> > 
> > [code]
> > sudo apt-get install 
> > [/code]
> 
> 
> Depending on the choices you made during installation, either:
> 
> - root has a password and sudo is not installed
> - root does not have a password and sudo is installed
> 
> https://wiki.debian.org/DebianInstall
> Check out "Post-Install Tips"

Given the error message (see Subject), sudo seems to be installed.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[chris]

Are we at the point yet where this has enough attention it would have been
cheaper to crowd fund a new printer?? 藍藍

On Mon, May 8, 2023, 12:03 PM Curt  wrote:

> On 2023-05-08, Will Mengarini  wrote:
> >
> > However, when I removed that space by hand, I still got "not found":
> > 
> > debian/pts/3 bash3 ~ 17:03 0$HEAD
> https://download3.ebz.epson.net/dsc/f/03/00/14/48/15/1d37501ad39bd2b5753cce3b2715b3e2fef557/epson-inkjet-printer-escpr_1.7.26-1lsb3.2_amd64.deb
> > 404 Not Found
> > Connection: close
>
>
>
> http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=EN==144815=7d1f9cb6b55d10182962d13f26948e0052707a37
>
> It's on the page, after clicking Accept. I can't seem to derive the direct
> link to the file from that page.
>
>

Re: disk usage for /usr/lib on bullseye

[Lee]

On 5/2/23, Greg Wooledge wrote:
> On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
>> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
>> > man apt
>>
>> Which doesn't say what 'apt purge' does without a package name. It says
>> 'Performs the requested action on one or more packages specified via
>> regex(7), glob(7) or exact match'. It doesn't go on to say what happens
>> if you leave that blank.
>
> Maybe I can experiment?  Let's see if "apt purge" is a syntax error:
>
> unicorn:~$ apt purge
> E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
> Permission denied)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend),
> are you root?
>
> Rats!  No luck here.  Either "apt purge" is not an error, or the argument
> processing and validation happens only after acquiring the lock.
>
> Now we have to tread dangerous waters to find out more information.
>
> unicorn:~$ sudo apt --dry-run
> [sudo] password for greg:
> E: Command line option --dry-run is not understood in combination with the
> other options
>
> OK... that's progress.  It looks like the --dry-run option exists.
> So maybe we can use that to avoid destroying our system by trying commands
> as root.
>
> unicorn:~$ sudo apt --dry-run purge
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

you're a better sysadmin?  I get

$ sudo apt --dry-run purge
[sudo] password for lee:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-image-5.10.0-19-amd64 linux-image-5.10.0-20-amd64
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Regards
Lee

Re: Debian et cartes graphique Intel ARC ?

[didier gaumet]

Le 08/05/2023 à 14:37, Gaëtan Perrier a écrit :


Oui j'avais vu mais ubuntu n'étant pas debian je me méfie des nuances qu'il
peut y avoir niveau noyau ou du côté des dépendances graphiques (mesa, opengl,
etc.). D'où ma question spécifiquement axée debian. ;-)


Ce qui suit sous toutes réserves :-)

si dans les grandes lignes le pilote proposé par Intel doit 
vraisemblablement marcher sous Debian, il est sage d'envisager une 
possibilité que ça puisse causer des problèmes. D'ailleurs Intel comme 
AMD proposent généralement des pilotes pour toutes les grosses distribs 
commerciales ou à support commercial (RHEL/SUSE/Ubuntu), or là, Intel ne 
garantit le fonctionnement que sous Ubuntu, et particulièrement la 22.04...


Il semblerait que, quelle que soit la distribution Linux, ce qui compte 
c'est que:
- le noyau soit patché, ou qu'on lui passe un paramètre précis, ou il 
soit de version au moins égale à 6.2

- Mesa soit en version 22.2 ou supérieure
- les firmwares soient suffisamment récents pour incorporer le matériel ARC
(a priori les pilotes Intel actuels ne font que ça: fournir des versions 
plus récentes que celles empaquetées dans les distribs, mais ça reste du 
libre)

cf:
https://www.phoronix.com/review/intel-arc-nov
https://wiki.archlinux.org/title/Intel_graphics#Arc_GPU_hardware_video_acceleration

Donc dans ton cas pour Debian Testing, Debian a des chances d'être 
compatible Intel ARC sans besoin de toucher à quoi que ce soit, dans 
quelques temps (semaines, mois) après la sortie de Bookworm, le temps 
que les versions recommencent à monter (hors freeze) dans Unstable et 
Testing


Pour la compatibilité OpenCL soulevée par Basile, comme Intel a l'air de 
dire que ses pilotes gèrent ça, je *suppose* qu'une version suffisamment 
récente du paquet Debian intel-opencl-icd (ICD Intel pour les GPU de 
générations 8 et ultérieures) doit permettre d'utiliser OpenCL avec ces 
cartes ARC

cf https://wiki.archlinux.org/title/GPGPU#Intel

Re: WiFi Not Working After System Reinstallation

[Lee]

On 5/8/23, Marko Randjelovic  wrote:
> Both systems are fully updated Bullseye on a laptop. I have two access
> points, let's call them A and B. When I connect to A, DHCP does not
> work. When I connect to B, DHCP works, laptop gets an IP address and
> internet works without problems. On the other hand, my mobile phone
> can successfully connect to both. Both APs have enabled DHCP server
> and I made sure the IP ranges do not overlap.

Does access point A have mac-address security enabled?
OpenWRT calls it mac address filter and gives you the choice of
 - disabledallows anyone to connect
 - allow listed only   list of mac addresses that are allowed to
connect to the AP
 - allow all except listed   why one would pick this instead of allow
listed only??

Does the AP have any logging that you could look at?  (dhcp)?diagnostics?

Regards
Lee

Re: disk usage for /usr/lib on bullseye

[David Wright]

On Mon 08 May 2023 at 08:27:52 (+), Bonno Bloksma wrote:

> > "apt autoremove" will remove (not purge) packages
> []
> Thanks for the better explanation, that is what I understood as well.

I doubt that.

> > One imagines that if you simply purged all of the kernel packages that had 
> > been autoremoved, this would clean up the modules. 
> Yes, that would seem to be prudent but I also do not understand why the 
> modules would be left behind? As far as I understand they are the module part 
> of the kernel. Without the kernel they are useless. Why not treat them as 
> part of the kernel. When I remove the kernel, remove the modules.

In your linams system, used as the example below, you removed, but did
not purge, versions 7 through 16. We assume (because you haven't shown
us) that the kernel/initrd/config/systemmap have all gone, and we can
see that the *modules have also been deleted*. That's why each of those
/lib/modules/5.10.0-NN-amd64/ directories only occupies 4.7MB of space
rather than 309MB (as listed in your OP).

> > But I'm not 100% sure about that.  If you've got modules that were built by 
> > dkms for example, I don't know whether those would be removed.
> As I use the apt and (apt-get) exclusively for package management I would 
> like them to clean up what I do not need when I tell it to clean it up.

For the sake of brevity, I'm going to assume that you're not compiling
custom kernel modules, and so we can put on one side the fact that
even purge would not delete them.

As for "cleaning up", apt(-get) does just what you instruct it to do.

> > It would be nice to know whether you had to do this "rm -r" because the 
> > "dpkg --purge linux-image-5.10.0-16-amd64" failed to remove the modules, or 
> > whether you simply did not KNOW to try the dpkg --purge first.
> 
> Look here:

Yes, look /carefully/ (at the number of links. That's the number
between permissions and owner).

> ---
> xx:~# cd /usr/lib/modules
> xx:/usr/lib/modules# ll
> total 56
> drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-10-amd64
> drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-11-amd64
> drwxr-xr-x 2 root root 4096 Jun 17  2022 5.10.0-12-amd64
> drwxr-xr-x 2 root root 4096 Jul 29  2022 5.10.0-13-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
> drwxr-xr-x 3 root root 4096 Sep 17  2022 5.10.0-18-amd64
> drwxr-xr-x 3 root root 4096 Nov  2  2022 5.10.0-19-amd64
> drwxr-xr-x 3 root root 4096 Jan  3 16:51 5.10.0-20-amd64
> drwxr-xr-x 3 root root 4096 Mar  3 09:40 5.10.0-21-amd64
> drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
> drwxr-xr-x 2 root root 4096 Dec 13  2021 5.10.0-7-amd64
> drwxr-xr-x 2 root root 4096 Jan 24  2022 5.10.0-8-amd64
> drwxr-xr-x 2 root root 4096 Mar 11  2022 5.10.0-9-amd64
> xx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-7-amd64
> (Reading database ... 57231 files and directories currently installed.)
> Purging configuration files for linux-image-5.10.0-7-amd64 (5.10.40-1) ...
> xx:/usr/lib/modules# ll
> total 52
> drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-10-amd64
> drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-11-amd64
> drwxr-xr-x 2 root root 4096 Jun 17  2022 5.10.0-12-amd64
> drwxr-xr-x 2 root root 4096 Jul 29  2022 5.10.0-13-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
> drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
> drwxr-xr-x 3 root root 4096 Sep 17  2022 5.10.0-18-amd64
> drwxr-xr-x 3 root root 4096 Nov  2  2022 5.10.0-19-amd64
> drwxr-xr-x 3 root root 4096 Jan  3 16:51 5.10.0-20-amd64
> drwxr-xr-x 3 root root 4096 Mar  3 09:40 5.10.0-21-amd64
> drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
> drwxr-xr-x 2 root root 4096 Jan 24  2022 5.10.0-8-amd64
> drwxr-xr-x 2 root root 4096 Mar 11  2022 5.10.0-9-amd64
> xx:/usr/lib/modules#
> 
> ---
> 
> So it seems using the dpkg --purge against the removed kernel version is the 
> proper way(?) to get rid of the kernels.

If you want your 4.7MB (×8) of space back, yes.

> But I still think this should be part of the apt autoremove for kernels. 

No, that's not policy. If "remove" purges, then why bother with
having a --purge option at all?

> I understand there are circumstances where not al modules assigned to a 
> kernel version are part of the kernel. But... would they be of any use when 
> that kernel version is no longer installed?

I've already explained exactly what is not deleted by "remove",
but requires "purge" as well or instead. I listed the actual
files, about ten of them:

https://lists.debian.org/debian-user/2023/05/msg00275.html

In the listing above, you have removed versions 7 through 16,
and then purged 7, as quoted above. The remaining 8 through 16
contain no modules, and the evidence is shown in your listing
above: there can be no kernel/ directory in any of them.

Debian has put in place some protections for 

Re: Debian Bookworm RC 1 installer- a Bug?

[David Wright]

On Fri 05 May 2023 at 06:50:27 (-0700), Peter Ehlert wrote:
> On 4/23/23 05:52, Peter Ehlert wrote:
> > On 4/17/23 21:43, David Wright wrote:
> > > On Mon 17 Apr 2023 at 08:47:30 (-0700), Peter Ehlert wrote:
> > > > On 4/16/23 09:29, David Wright wrote:
> > > > > On Sun 16 Apr 2023 at 07:19:18 (-0700), Peter Ehlert wrote:
> > > > > > On 4/9/23 08:57, David Wright wrote:
> > > > > > > On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote:
> > > > > > > > Debian Bookworm RC 1 installer
> > > > > > > > Damned nice, the improvements are appreciated.
> > > > > > > I ran rc1 in my usual manner, and the only difference I noticed 
> > > > > > > was
> > > > > > > the one extra question about non-free firmware, to which I replied
> > > > > > > yes. (There may well be improvements under the hood, so to speak.)
> > > > > > > Oh, and the initrd is somewhat larger, as per usual.
> > > > > > > 
> > > > > > > > using the new debian-bookworm-DI-rc1-amd64-netinst.iso
> > > > > > > > Legacy install, GPT partition
> > > > > > > I assume Legacy means BIOS booting. Same here, but only one disk.
> > > > > > correct. different term, same thing. Not UEFI
> > > > > > > > graphic install, manual partitioning
> > > > > > > > Mate Desktop (others were deselected)
> > > > > > > Non-graphical here, a suitable partition existed, and only
> > > > > > > standard and SSH server software was installed.
> > > > > > > 
> > > > > > > > WiFi firmware:
> > > > > > > Untested as this machine is a 2006-vintage mini-tower lacking 
> > > > > > > wifi.
> > > > > > > 
> > > > > > > [ snipped narrative of later network-switching ]
> > > > > > > 
> > > > > > > > Boot Loader:
> > > > > > > > all disk drives were detected, however the one with the 
> > > > > > > > bios_grub
> > > > > > > > partition was highlighted
> > > > > > > I can't recall seeing anything other than the first item 
> > > > > > > highlighted,
> > > > > > > ie "Enter device manually", at least with the non-graphical 
> > > > > > > installer
> > > > > > > in expert mode. I selected the (sole) hard drive, item 2. The only
> > > > > > > remaining item was the USB stick containing the installer ISO.
> > > > > > > 
> > > > > > > As expected nowadays, when the machine rebooted, the Grub menu
> > > > > > > had only two lines, both pointing to the newly installed system.
> > > > > > > (I hadn't made any attempt to counteract GRUB_DISABLE_OS_PROBER
> > > > > > > during my installation.) So Grub was correctly installed in the
> > > > > > > MBR, and the rest of Grub occupied d400 bytes of /dev/sda1 (the
> > > > > > > 3MB BIOS boot partition on the single disk).
> > > > > > > 
> > > > > > > > =
> > > > > > > > second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso
> > > > > > > > same machine and again Legacy install, GPT partition
> > > > > > > > however I did NOT install from the live session:
> > > > > > > > I chose to go directly to install rather than the Calamares 
> > > > > > > > installer
> > > > > > > > then manual partitioning
> > > > > > > > 
> > > > > > > > Boot Loader:
> > > > > > > > all drives were detected, however the one with the bios_grub 
> > > > > > > > partition
> > > > > > > > was NOT highlighted, but I did select it.
> > > > > > > > GRUB was Not properly installed, my former grub menu was still 
> > > > > > > > active.
> > > > > > > How did you determine that it was the previous menu. Wouldn't it 
> > > > > > > look
> > > > > > > just the same?
> > > > > > I enable GRUB_DISABLE_OS_PROBER so that the various other operating
> > > > > > systems are shown
> > > > > > if the new GRUB is properly installed I get the "new" one item only
> > > > > > GRUB display.
> > > > > > then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER 
> > > > > > and
> > > > > > update GRUB
> > > > > > > > *** I tried a second time, same as above being super careful, 
> > > > > > > > same result.
> > > > > > > > 
> > > > > > > > I then booted with my default system, ran grub-install /dev/sde 
> > > > > > > > &&
> > > > > > > > update-grub
> > > > > > > > then "new" system was on my boot menu.
> > > > > > > > then booted and it ran as expected.
> > > > > So you installed Grub on /dev/sde.
> > > > > 
> > > > > > > Which method did you use to boot the "default" system (which I 
> > > > > > > assume
> > > > > > > is bullseye, in a different partition on one or other of the 
> > > > > > > disks),
> > > > > > > in view of the rather sparse menu from grub.cfg on the new system?
> > > > > > I boot with the "old" GRUB menu as explained above...it has Several
> > > > > > operating systems listed, my old default OS is still at the top of 
> > > > > > the
> > > > > > list.
> > > > > > > > back to the WiFi dongle, again the obscure firmware was 
> > > > > > > > properly installed
> > > > > > > > 
> > > > > > > > Is this a Bug or a user/hardware issue?
> > > > > > > Presumably we are now back to talking about Grub.
> > > > > > > 
> > > > > > > If you still have access to the 

Re: EPSON ET M 1120 new printer: If You can read this, you are using the wrong driver

[Curt]

On 2023-05-08, Will Mengarini  wrote:
>
> However, when I removed that space by hand, I still got "not found":
> 
> debian/pts/3 bash3 ~ 17:03 0$HEAD 
> https://download3.ebz.epson.net/dsc/f/03/00/14/48/15/1d37501ad39bd2b5753cce3b2715b3e2fef557/epson-inkjet-printer-escpr_1.7.26-1lsb3.2_amd64.deb
> 404 Not Found
> Connection: close


http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=EN==144815=7d1f9cb6b55d10182962d13f26948e0052707a37

It's on the page, after clicking Accept. I can't seem to derive the direct
link to the file from that page.

Re: User is not in the sudoers file

[Dan Ritter]

Igor Korot wrote: 
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
> 
> Basically trying to run:
> 
> [code]
> sudo apt-get install 
> [/code]


Depending on the choices you made during installation, either:

- root has a password and sudo is not installed
- root does not have a password and sudo is installed

https://wiki.debian.org/DebianInstall
Check out "Post-Install Tips"

-dsr-

Re: User is not in the sudoers file

[Dan Purgert]

On May 08, 2023, Igor Korot wrote:
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?

You likely created a root account during the initial setup.  Doing that
skips over adding the first user (created during install) to sudoers
(i.e. "the operator created root, the operator will 'su root' when they
want to be root").

As I recall, the installer asks if you want to create root, or use sudo.


-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: User is not in the sudoers file

[Joe]

On Mon, 8 May 2023 10:16:33 -0500
Igor Korot  wrote:

> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
> 
> Basically trying to run:
> 
> [code]
> sudo apt-get install 
> [/code]
> 
> Thank you.
> 

Sudi itself requires configuration as it does not by default allow
privileges for any user.

Here's the quick way in Debian:
https://documentation.arcserve.com/Arcserve-UDP/Available/V6.5/ENU/Bookshelf_Files/HTML/Agent%20Online%20Help%20Linux/Content/AgentforLinuxUserGuide/udpl_config_sudo_debian.htm

Here's more information about sudo, allowing much more flexibility than
using the sudo group:
https://wiki.archlinux.org/title/sudo

The Arch Linux site is generally very useful for Debian users.

-- 
Joe

Re: User is not in the sudoers file

[tomas]

On Mon, May 08, 2023 at 10:16:33AM -0500, Igor Korot wrote:
> Hi, ALL,
> Is there a reason for the default install
> I immediately get the error in the subj?
> 
> Basically trying to run:
> 
> [code]
> sudo apt-get install 
> [/code]

See https://wiki.debian.org/sudo

It seems you gave root a password. Now you have to become root once,
the "traditional" way and either (1) edit the sudoers file to add
your user, or (2) add your user to the sudo group. I'd prefer (2).

Cheers
-- 
t


signature.asc
Description: PGP signature

User is not in the sudoers file

[Igor Korot]

Hi, ALL,
Is there a reason for the default install
I immediately get the error in the subj?

Basically trying to run:

[code]
sudo apt-get install 
[/code]

Thank you.

Re: WiFi Not Working After System Reinstallation

[debian-user]

Marko Randjelovic  wrote:
> Both systems are fully updated Bullseye on a laptop. I have two
> access points, let's call them A and B. When I connect to A, DHCP
> does not work. When I connect to B, DHCP works, laptop gets an IP
> address and internet works without problems. On the other hand, my
> mobile phone can successfully connect to both. Both APs have enabled
> DHCP server and I made sure the IP ranges do not overlap.
> 

what does 

$ journalctl | grep dhcp

show when it should be connecting to A?

Re: WiFi Not Working After System Reinstallation

[Marko Randjelovic]

Both systems are fully updated Bullseye on a laptop. I have two access  
points, let's call them A and B. When I connect to A, DHCP does not  
work. When I connect to B, DHCP works, laptop gets an IP address and  
internet works without problems. On the other hand, my mobile phone  
can successfully connect to both. Both APs have enabled DHCP server  
and I made sure the IP ranges do not overlap.

Re: Fetchmail in Bullseye?

[Gregory Seidman]

Fetchmail continues to retrieve my email successfully. Could your clock
possibly be skewed enough to affect TLS negotiation?

--Gregory

On Mon, May 08, 2023 at 01:39:14AM -0700, John Conover wrote:
> 
> My fetchmail, (from the repository,) has started timing out with a
> SOCKET error on connections I've used for years. Both fetchmail and
> openssl are from the repository.
> 
> fetchmail: 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5
> openssl: 1.1.1n  15 Mar 2022
> 
> Anyone else having similar problems?
> 
> Thanks,
> 
> John
> 
> -- 
> 
> John Conover, cono...@panix.com, http://www.johncon.com/
> 
> 

Re: Debian et cartes graphique Intel ARC ?

[Gaëtan Perrier]

Le lundi 08 mai 2023 à 06:13 +0200, Bernard Schoenacker a écrit :
> 
> 
> - Mail original -
> De: "Gaëtan Perrier" 
> À: "debian-user-french" 
> Envoyé: Lundi 8 Mai 2023 02:46:12
> Objet: Debian et cartes graphique Intel ARC ?
> 
> Bonjour,
> 
> Est-ce que les cartes graphiques Intel ARC, notamment ARC 750/770 sont bien
> supportées sur les debian ?
> Par rapport aux Nvidia/AMD avez-vous des retours d'expériences ?
> 
> A+
> 
> Gaëtan
> 
> 
> Bonjour,
> 
> Avec G.. , il faut décapsuler pour que son esprit s'éveille, les données sont

Jeu de d'esprit Maître Capello :-)

> disponibles chez Intel avec la procédure d'installation pour les paquets Deb
> même si c'est inscrit pour Ubuntu...
> 
> https://dgpu-docs.intel.com/installation-guides/ubuntu/ubuntu-jammy-arc.html
> 

Oui j'avais vu mais ubuntu n'étant pas debian je me méfie des nuances qu'il
peut y avoir niveau noyau ou du côté des dépendances graphiques (mesa, opengl,
etc.). D'où ma question spécifiquement axée debian. ;-)

A+

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: repeat of previous question that has gone unansweredseveraltimes.

[Brian]

On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:

> On 5/7/23 12:48, Brian wrote:

[...]

> > Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.
 
> gene@bpi51:~$ lpstat -t
> scheduler is running
> system default destination: PDF
> device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
> device for PDF: cups-pdf:/

Thanks.

'lpstat -t' only ever shows *local* printers. That is, printers that have
been set up (manually in this case) on the local machine. It will never
discover and  show printers on the network. This was mentioned earlier in
this thread, but you do not appear to appreciate its significance.

To be clear: HLL2320D-RAW and PDF are local printers. We set up HLL2320D-RAW
(which is a working printer) togetger. Should you wish to see *all* devices
(local and on the network) us

  lpstat -e
  lpstat -l -e

The second command was explained earlier in the thread.

[...]

> gene@bpi54:~$ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_HL-L2320D_series:
> usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
> device for Brother_MFC-J6920DW_photo:
> usb://Brother/MFC-J6920DW?serial=BROG5F229909
> device for HLL2320D: usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
> device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909

These are the local printers on bpi54. All connected by USB. All set up by
you and all working

Summary: Everything is as it should be.

Your first mail has:

  > All of my bullseye machines are locked out, printer screen at
  > localhost:631 is empty, and no printers can be found and added.
  >
  > But open a shell, and type "lpstat -t" and it gets the full list of
  > available printers on that same bullseye machine whose cups output is
  > empty.

The facts as expressed are OK. Your interpretation of them is sub-optimal.
A lack of understanding about what localhost:631 and 'lpstat -t' show is
the root of problem and colours everything you have written here..

[...]
 
> > Apple ceased any involvement with CUPS development and parted company with
> > its Chief Printing Engineer a number of years ago. Debian CUPS is produced
> > by a team led by the creator of CUPS. Your requested fix is in place :).
> 
> If so, (this is the first I've heard of it, and I've only known Michael
> since the late 1980's when we were both heavily involved in the os9
> development, a mini unix that ran of the trs-80 color computers) where do I
> email now to be assured Michael will see it? Is there a new cups mailing
> list?

Please see our wiki.

> Do you have any idea if that fix will be released for arm64 bullseye? I just
> checked bpi54, no updates available since the Friday update. Ditto for the
> intel busters here, but they're busters, so don't need the fix, they Just
> Work.

I haven't a clue about arm64. I am not even sure that CUPS is the issue. You
have a classical local printer set up. It works. There are three other printers
that could be set up with the same technique. Remenber - you are the one who
does not want a New Architecture setup.

-- 
Brian.

Re: OpenCL with Radeon GPU

[Arno Lehmann]

Thanks for pointing me there... I tried the suite myself, and got 
results that at least confirmed some stuff works :-)


Cheers,

Arno

--
Arno Lehmann

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

Re: bind9 and dns forward

[Michel Verdier]

Le 8 mai 2023 Bonno Bloksma a écrit :

> I also do not understand this difference when querying the internal dns 
> server directly.
> Why does the +trace +cd not show an answer but when I leave them out I get a
> correct answer. Is that because +trace forces it to start at the root which is
> irrelevant when trying to get an answer from an internal dns server?

yes

> What does +cd do? I was unable to find it in the man page.

it disable dnssec checks, was just in case of real dnssec problem

can you give full /etc/resolv.conf
from your result you should have 127.0.0.1 in it but just to be sure

and also :

dig tio.nl NS
dig @172.16.208.10 tio.nl NS

Re: AW: Was it a good idea to buy an Epson printer?

[Nicolas George]

Schwibinger Michael (12023-05-08):
> Thank You

Do not thank and at the same time rudely ignore the advice given to you.

-- 
  Nicolas George


signature.asc
Description: PGP signature

AW: AW: Was it a good idea to buy an Epson printer?

[Schwibinger Michael]

Good morning

Thank You

What does mean:

- Using 0x65 0x57 0x3A 0x20

Regards
Sophie






Von: Nicolas George 
Gesendet: Mittwoch, 3. Mai 2023 09:34
An: debian-user@lists.debian.org 
Betreff: Re: AW: Was it a good idea to buy an Epson printer?

Schwibinger Michael (12023-05-03):
> What do I do wrong?

Among other things, what you are doing wrong:

- Top posting.

- Using 0x65 0x57 0x3A 0x20 instead of 0x52 0x65 0x3A 0x20 as a reply
  marker in the subject.

--
  Nicolas George

WiFy Not Working After System Reinstallation

[Marko Randjelovic]

Hi all,

my wireless network interface is not working after system  
reinstallation. Before it was working perfectly. It cannot get an IP  
address from DHCP. Also, when I assign to it and IP address manualy,  
it's not working. The wired interface is working perfectly. Itried  
with both ordinary and backported versons of the driver available in  
Debian repos (broadcom-sta-dkms).


I hope someone will have an idea on what's going on.

# dmesg | grep firmware
[   12.664390] platform regulatory.0: firmware: direct-loading  
firmware regulatory.db
[   12.686687] platform regulatory.0: firmware: direct-loading  
firmware regulatory.db.p7s
[   15.764398] bluetooth hci0: firmware: failed to load  
brcm/BCM43142A0-04ca-2006.hcd (-2)
[   15.764770] firmware_class: See https://wiki.debian.org/Firmware  
for information about missing firmware
[   15.765299] bluetooth hci0: firmware: failed to load  
brcm/BCM-04ca-2006.hcd (-2)

[   15.765623] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
[   23.512863] r8169 :02:00.2: firmware: direct-loading firmware  
rtl_nic/rtl8402-1.fw


# dpkg -l ifupdown iproute2 wpasupplicant iw wireless-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==>
ii  ifupdown   0.8.36   amd64high level tools to  
configure netw>
ii  iproute2   5.10.0-4 amd64networking and traffic  
control too>
ii  iw 5.9-3amd64tool for configuring  
Linux wireles>
ii  wireless-tools 30~pre9-13.1 amd64Tools for manipulating  
Linux Wirel>
ii  wpasupplicant  2:2.9.0-21   amd64client support for WPA  
and WPA2 (I>


# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN  
group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp2s0f2:  mtu 1500 qdisc  
pfifo_fast state UP group default qlen 1000

link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.1.152/24 brd 192.168.1.255 scope global dynamic enp2s0f2
   valid_lft 863375sec preferred_lft 863375sec
inet6 fe80::f279:59ff:fe31:6502/64 scope link
   valid_lft forever preferred_lft forever
3: wlp3s0:  mtu 1500 qdisc  
pfifo_fast state DORMANT group default qlen 1000

link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff
inet 169.254.12.207/16 brd 169.254.255.255 scope link wlp3s0:avahi
   valid_lft forever preferred_lft forever
inet6 fe80::aeb5:7dff:fe78:dd58/64 scope link
   valid_lft forever preferred_lft forever

# iw dev
phy#0
Interface wlp3s0
ifindex 3
wdev 0x1
addr yy:yy:yy:yy:yy:yy
type managed
txpower 23.00 dBm

# ip link set wlp2s0 up

# iwlist scan
loInterface doesn't support scanning.

enp2s0f2  Interface doesn't support scanning.

wlp3s0Scan completed :
  Cell 01 - Address: zz:zz:zz:zz:zz:zz
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=43/70  Signal level=-67 dBm
Encryption key:on
ESSID:"tt"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
  24 Mb/s; 36 Mb/s; 54 Mb/s
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
Mode:Master
Extra:tsf=
Extra: Last beacon: 44ms ago
IE: Unknown: 0006444338393044
IE: Unknown: 010882848B962430486C
IE: Unknown: 030101
IE: Unknown: 0706444520010D14
IE: Unknown: 200100
IE: Unknown: 23020F00
IE: Unknown: 2A0100
IE: Unknown: 32040C121860
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
IE: Unknown: 0B052B
IE: Unknown: 4605720801
IE: Unknown:  
2D1ABC091B00
IE: Unknown:  
3D160108

IE: Unknown: 7F0804000840
IE: Unknown:  

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

>> linbobo:/etc/bind# cat named.conf.local
> 
> You have only zone blocks in this file, right ?
Yes, 

> And you don't use views ?
I have no idea what they would do, but no. The word view is not in that file.

> Why does it first go to the public dns and then run into the dnssec problem? 
> There is a direct definition for the tio.nl zone in my config file. 

The public dns don't answer at all, so dnssec problem is only a consequence. 
The main problem seems to be the broken forwarding.
Do you restart or flush your bind before the queries ? I suppose you do but... 
:)

Just did a flush and then a query. It still seems to query the public dns and 
not (exclusively) forward the request.


linbobo:/etc/bind# dig einsccmdp-01.tio.nl +trace +cd

; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd
;; global options: +cmd
.   279702  IN  NS  c.root-servers.net.
.   279702  IN  NS  m.root-servers.net.
.   279702  IN  NS  k.root-servers.net.
.   279702  IN  NS  a.root-servers.net.
.   279702  IN  NS  b.root-servers.net.
.   279702  IN  NS  i.root-servers.net.
.   279702  IN  NS  e.root-servers.net.
.   279702  IN  NS  g.root-servers.net.
.   279702  IN  NS  d.root-servers.net.
.   279702  IN  NS  h.root-servers.net.
.   279702  IN  NS  j.root-servers.net.
.   279702  IN  NS  f.root-servers.net.
.   279702  IN  NS  l.root-servers.net.
.   279702  IN  RRSIG   NS 8 0 518400 2023051805 
2023050504 60955 . Yz1mgXTG4kStmPrjvxu3iQsekhdLfu3KeyZT26ebRPDeUnRUz/ajenhi 
jNj4FA6krNnCI1hfU0htq/10iADDnc35NTtGA6PodoTa8qf75l9UZ/Cc 
59FRaH7sEDgjXcvts0X2R85aHofogRRcp77ufoetwSS0KZRsbJ5vBbq2 
J4UIbKNHCZP0anl8+qmDmiMNy3VJYcUwePT6qDUBMe2fhktmU6w1RLSe 
3xGV1dIFONSdZJeQxsJkWBXa5HnBN1Vl8iw6eDKauJDw6LL41fd8XzSk 
CYfl79f92z2tVv5q3l1G8fN3C+KJ33J1Y/hivBSe2FmVuwRkbr1mddH0 4m4LLw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

nl. 172800  IN  NS  ns1.dns.nl.
nl. 172800  IN  NS  ns3.dns.nl.
nl. 172800  IN  NS  ns4.dns.nl.
nl. 86400   IN  DS  34112 8 2 
3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22
nl. 86400   IN  RRSIG   DS 8 1 86400 2023052105 
2023050804 60955 . ORTn1H1ik3trq8VJQAVQ1nx4rrVZNEpoy9JZ/23pOjysRe9BWlXcCIK4 
9LO3olfaXGFMDMWT3RtlSO3XFc7gPw38y2yfSRN8LWMkY0LzmOoLNxLO 
owY9dqQDfrvZK++EsWWmen0db3u/G07/cVWgb3IO0W9OVioQqko6ryes 
S9rlwbZY7lrPcohjWbUQ/uKBnhyN9yQs0sU8b+v3EbIudSzAa2zz5Bep 
ZA/XcnP+I9KNHqOREEfAuUG8moCP3VYFwarIkAgQeg/pE/typQZuxHUS 
QYY6LEfUpZVVO6i0NAHmqRlOZe2LmIHPWO7FBjK6YZtxyLbNkjyWjjvr kf4bVg==
;; Received 573 bytes from 192.58.128.30#53(j.root-servers.net) in 92 ms

tio.nl. 3600IN  NS  ns3.argewebhosting.nl.
tio.nl. 3600IN  NS  ns1.argewebhosting.eu.
tio.nl. 3600IN  NS  ns2.argewebhosting.com.
tio.nl. 3600IN  DS  33829 8 2 
81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3
tio.nl. 3600IN  RRSIG   DS 8 2 3600 20230522040659 
20230508070836 50076 nl. 
kTSEJYjimMe4Kvdl6kc4gPF2OLn04nhuGDp4ppYbfxwPKZEzXb3GSY68 
3SPqHYTuOvwTeDnGQ1brG7l9N6EJRdgy9rG69/Irj1/aUZT27M5BBN3h 
r9y7dZQAfdZVDSy7zXUgAYy9AdOf+JeLhIeVhrbxD+NYBXaJOe9r3gtj F6s=
;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms

tio.nl. 3600IN  SOA ns1.argewebhosting.eu. 
hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600
tio.nl. 3600IN  RRSIG   SOA 8 2 3600 2023051800 
2023042700 11454 tio.nl. 
JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A 
lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE 
JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0=
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB 
KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk 
ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs 
+XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg=
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB 
OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi 
Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS 

RE: disk usage for /usr/lib on bullseye

[Bonno Bloksma]

Hi,

As we have seen some modules directories are larger than others. I was just 
cleaning up some old stuff and this is what I noticed.

---
xxx:/usr/lib/modules# du * -sh
4.7M5.10.0-16-amd64
309M5.10.0-18-amd64
309M5.10.0-19-amd64
309M5.10.0-20-amd64
309M5.10.0-21-amd64
309M5.10.0-22-amd64

xxx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-16-amd64
(Reading database ... 57223 files and directories currently installed.)
Purging configuration files for linux-image-5.10.0-16-amd64 (5.10.127-2) ...

xxx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-17-amd64
dpkg: warning: ignoring request to remove linux-image-5.10.0-17-amd64 which 
isn't installed

xxx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-18-amd64
(Reading database ... 57222 files and directories currently installed.)
Removing linux-image-5.10.0-18-amd64 (5.10.140-1) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-5.10.0-18-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-22-amd64
Found initrd image: /boot/initrd.img-5.10.0-22-amd64
Found linux image: /boot/vmlinuz-5.10.0-21-amd64
Found initrd image: /boot/initrd.img-5.10.0-21-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Found linux image: /boot/vmlinuz-5.10.0-19-amd64
Found initrd image: /boot/initrd.img-5.10.0-19-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot 
entries.
done
Purging configuration files for linux-image-5.10.0-18-amd64 (5.10.140-1) ...
xxx:/usr/lib/modules# 
---

So kernel 16 was removed before the step but there was some stuff left in the 
modules folder.
Kernel 17 was never on the system it seems.
Purging kernel 18 removed a still installed kernel. :-(

Rebooting the machine still gave me a working server so whatever it removed of 
18 which caused it to rebuild the grub config did not cause any problems.
It seems lately there are more older kernels kept on the system, not just the 
last and the previous one. However, keeping 5 kernels seems a bit overkill (18, 
19, 20, 21 and 22)
Although, I have no idea where it says how many kernels to keep

---
# cat /etc/apt/apt.conf.d/01autoremove
APT
{
  NeverAutoRemove
  {
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
  };

  VersionedKernelPackages
  {
# kernels
"linux-.*";
"kfreebsd-.*";
"gnumach-.*";
# (out-of-tree) modules
".*-modules";
".*-kernel";
  };

[]
---

Even wierder, on other systems I only have the last 2 kernels, 21 and 22.  
On the one that is not running all that long, as of Nov 2022, it seems it 
started with kernel 13, then 19, 20, 21 and 22. 
Those are also the 5 modules folders on that system, but in /boot there are 
only 21 and 22.

I am going to clean up older kernels so I have only the last 2 and see where 
things go from there. 
>From now on I am going to keep better track on the number of kernels on the 
>system. 

Bonno Bloksma

Re: relevance of packages in repositories

[Brad Rogers]

On Mon, 8 May 2023 07:12:12 +0200
Oliver Schoede  wrote:

Hello Oliver,

>It was already concluded we're supposed to be talking about Neovim, the

Not really.  OP hasn't been back to clarify, but version numbers appear
to support the hypothesis.  However, that's not a guarantee of accuracy.

Another conclusion would be that the OP was simply indulging in drive-by
griping.  Available evidence currently supports this, but future events
may render the conclusion false. 

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
We are the chosen
Changed - Judgement Centre


pgpLqmt89uTXV.pgp
Description: OpenPGP digital signature

Fetchmail in Bullseye?

[John Conover]

My fetchmail, (from the repository,) has started timing out with a
SOCKET error on connections I've used for years. Both fetchmail and
openssl are from the repository.

fetchmail: 6.4.16+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5
openssl: 1.1.1n  15 Mar 2022

Anyone else having similar problems?

Thanks,

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

RE: disk usage for /usr/lib on bullseye

[Bonno Bloksma]

Hi Greg,

>> Just created a snapshot of my servers and then did:
>> apt autoremove
>> apt purge
>> apt clean
>> and I still have a working system so it will not just get rid of all 
>> installed packages. :-) But... I still also have all those folders in 
>> /usr/lib/modules

> It seems like you're just trying random commands without understanding what 
> they do.
Oh, I pretty much understood what they would do. ;-) Which is why I had no 
problem trying them just to see if they indeed did what I expected. And also to 
prove to all the others nothing earth shattering would happen. :-)

> "apt autoremove" will remove (not purge) packages
[]
Thanks for the better explanation, that is what I understood as well.

> One imagines that if you simply purged all of the kernel packages that had 
> been autoremoved, this would clean up the modules. 
Yes, that would seem to be prudent but I also do not understand why the modules 
would be left behind? As far as I understand they are the module part of the 
kernel. Without the kernel they are useless. Why not treat them as part of the 
kernel. When I remove the kernel, remove the modules.

> But I'm not 100% sure about that.  If you've got modules that were built by 
> dkms for example, I don't know whether those would be removed.
As I use the apt and (apt-get) exclusively for package management I would like 
them to clean up what I do not need when I tell it to clean it up.

> It would be nice to know whether you had to do this "rm -r" because the "dpkg 
> --purge linux-image-5.10.0-16-amd64" failed to remove the modules, or whether 
> you simply did not KNOW to try the dpkg --purge first.

Look here:
---
xx:~# cd /usr/lib/modules
xx:/usr/lib/modules# ll
total 56
drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-10-amd64
drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-11-amd64
drwxr-xr-x 2 root root 4096 Jun 17  2022 5.10.0-12-amd64
drwxr-xr-x 2 root root 4096 Jul 29  2022 5.10.0-13-amd64
drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
drwxr-xr-x 3 root root 4096 Sep 17  2022 5.10.0-18-amd64
drwxr-xr-x 3 root root 4096 Nov  2  2022 5.10.0-19-amd64
drwxr-xr-x 3 root root 4096 Jan  3 16:51 5.10.0-20-amd64
drwxr-xr-x 3 root root 4096 Mar  3 09:40 5.10.0-21-amd64
drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
drwxr-xr-x 2 root root 4096 Dec 13  2021 5.10.0-7-amd64
drwxr-xr-x 2 root root 4096 Jan 24  2022 5.10.0-8-amd64
drwxr-xr-x 2 root root 4096 Mar 11  2022 5.10.0-9-amd64
xx:/usr/lib/modules# dpkg --purge linux-image-5.10.0-7-amd64
(Reading database ... 57231 files and directories currently installed.)
Purging configuration files for linux-image-5.10.0-7-amd64 (5.10.40-1) ...
xx:/usr/lib/modules# ll
total 52
drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-10-amd64
drwxr-xr-x 2 root root 4096 Apr 19  2022 5.10.0-11-amd64
drwxr-xr-x 2 root root 4096 Jun 17  2022 5.10.0-12-amd64
drwxr-xr-x 2 root root 4096 Jul 29  2022 5.10.0-13-amd64
drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-15-amd64
drwxr-xr-x 2 root root 4096 Dec 12 07:40 5.10.0-16-amd64
drwxr-xr-x 3 root root 4096 Sep 17  2022 5.10.0-18-amd64
drwxr-xr-x 3 root root 4096 Nov  2  2022 5.10.0-19-amd64
drwxr-xr-x 3 root root 4096 Jan  3 16:51 5.10.0-20-amd64
drwxr-xr-x 3 root root 4096 Mar  3 09:40 5.10.0-21-amd64
drwxr-xr-x 3 root root 4096 Apr 29 13:18 5.10.0-22-amd64
drwxr-xr-x 2 root root 4096 Jan 24  2022 5.10.0-8-amd64
drwxr-xr-x 2 root root 4096 Mar 11  2022 5.10.0-9-amd64
xx:/usr/lib/modules#

---

So it seems using the dpkg --purge against the removed kernel version is the 
proper way(?) to get rid of the kernels.

But I still think this should be part of the apt autoremove for kernels. 
I understand there are circumstances where not al modules assigned to a kernel 
version are part of the kernel. But... would they be of any use when that 
kernel version is no longer installed?

Bonno Bloksma

Re: Debian et cartes graphique Intel ARC ?

[Basile Starynkevitch]

On 5/8/23 06:13, Bernard Schoenacker wrote:


- Mail original -
De: "Gaëtan Perrier" 
À: "debian-user-french" 
Envoyé: Lundi 8 Mai 2023 02:46:12
Objet: Debian et cartes graphique Intel ARC ?

Bonjour,

Est-ce que les cartes graphiques Intel ARC, notamment ARC 750/770 sont bien
supportées sur les debian ?
Par rapport aux Nvidia/AMD avez-vous des retours d'expériences ?

A+

Gaëtan


Bonjour,

Avec G.. , il faut décapsuler pour que son esprit s'éveille, les données sont
disponibles chez Intel avec la procédure d'installation pour les paquets Deb
même si c'est inscrit pour Ubuntu...




Bonjour,


Je n'ai pas de carte Intel ARC.

J'ai entendu dire que pour l'affichage elles sont bien supportées par 
Linux. Je l'ai lu sur 
https://www.phoronix.com/review/intel-a750-a770-arc-linux


Par contre, les cartes graphiques haut de gamme peuvent aussi être 
utilisées pour du calcul matriciel spécialisé. NVIDIA propose 
https://developer.nvidia.com/cuda-toolkit (gratuit mais pas libre), et 
AMD propose OpenCL https://fr.wikipedia.org/wiki/OpenCL (j'ai comprise 
que c'est plus du logiciel en partie libre, et pas seulement gratuit).



J'ignore quelles sont les possibilités de calcul vectoriel déporté sur 
carte Intel ARC.


Si on veut faire du calcul scientifique intensif, ça a son importance!

Pour info, les compilateurs GCC récents proposent 
https://gcc.gnu.org/wiki/OpenACC


Librement




--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/