Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 01:03:44PM -0800, David Christensen wrote: > On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: > > Greg Wooledge wrote: > > > > > Shred will determine the size of the file, then write data to the > > > file, rewind, write data again, etc. On a traditional hard drive, >

Re: usrmerge on root NFS will not be run automatically

Very unimpressed with the so called "fix" for #842145 of just blocking running the script on nfs mount rather than fixing the script to work properly with nfs. The problem with the script is that it does not ignore the .nfs* files. An explanation of these files is available here:

Re: Does "LC_ALL=C" work on all shells?

On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote: > This is from a script installed by a package that does a > dpkg-reconfigure locales to set the locale on the machine. What package? What script? > BTW where is LANGUAGE defined in the "standards/conventions"? It's a GNUism.

Re: Does "LC_ALL=C" work on all shells?

On 2/13/24 21:22, Max Nikulin wrote: On 14/02/2024 07:56, Gremlin wrote: Gremlin (12024-02-13): cat /etc/default/locale #  File generated by update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 Found this in a shell script: LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC

Re: Does "LC_ALL=C" work on all shells?

On 14/02/2024 07:56, Gremlin wrote: Gremlin (12024-02-13): cat /etc/default/locale #  File generated by update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 Found this in a shell script: LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC LANGUAGE=$LOC Do not do it for

Re: grub-pc error when upgrading from buster to bullseye

On 2024-02-12 15:14, Greg Wooledge wrote: According to it uses debconf's database. That page includes instructions for viewing the device and changing it. I had just

Re: Does "LC_ALL=C" work on all shells?

On Tue, Feb 13, 2024 at 07:56:46PM -0500, Gremlin wrote: > Found this in a shell script: > > LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC > LANGUAGE=$LOC In *what* shell script?

Re: Does "LC_ALL=C" work on all shells?

On 2/13/24 19:29, Gremlin wrote: On 2/13/24 17:48, Nicolas George wrote: Gremlin (12024-02-13): Oh like debian does? cat /etc/default/locale #  File generated by update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 I do not observe this, even after “sudo dpkg-reconfigure

Re: Does "LC_ALL=C" work on all shells?

Hi, On Tue, Feb 13, 2024 at 07:29:37PM -0500, Gremlin wrote: > Upon investigation, I can not determine which package > /etc/default/locale belongs too. dpkg -S and apt-file will only find files that are actually shipped in packages. Files that are created or used by maintainer scripts but not

Re: Does "LC_ALL=C" work on all shells?

On 2/13/24 17:48, Nicolas George wrote: Gremlin (12024-02-13): Oh like debian does? cat /etc/default/locale # File generated by update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 I do not observe this, even after “sudo dpkg-reconfigure locales”. Can you explain how you

Re: Does "LC_ALL=C" work on all shells?

On Tue, Feb 13, 2024 at 11:48:04PM +0100, Nicolas George wrote: > Gremlin (12024-02-13): > > Oh like debian does? > > > > cat /etc/default/locale > > # File generated by update-locale > > LANG=en_US.UTF-8 > > LANGUAGE=en_US.UTF-8 > > LC_ALL=en_US.UTF-8 > > I do not observe this, even after

Re: Does "LC_ALL=C" work on all shells?

Gremlin (12024-02-13): > Oh like debian does? > > cat /etc/default/locale > # File generated by update-locale > LANG=en_US.UTF-8 > LANGUAGE=en_US.UTF-8 > LC_ALL=en_US.UTF-8 I do not observe this, even after “sudo dpkg-reconfigure locales”. Can you explain how you reached this state? --

Re: Does "LC_ALL=C" work on all shells?

On 2/13/24 16:45, Greg Wooledge wrote: On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote: egrep ALL .bashrc LC_ALL=C This has gone pretty far off the rails, but here we are. Let's address this. DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible

Re: Debian Mobile cont'd from about 10 yeaes ago furey2310....

On Tue, Feb 13, 2024 at 4:27 PM Patrick Furey wrote: > > Can it be downloaded to usb, SD and installed at boot options via ADB? > > I did successfully install the code via termux on 2 phones but that termux > wasnt rooted i believe and my charging was subsequently ruined on my android >

Re: Does "LC_ALL=C" work on all shells?

Will Mengarini (12024-02-13): > * Greg Wooledge [24-02/13=Tu 15:59 -0500]: > > In csh, you need to use env. Like this: > What Greg posted also works, because it's an > invocation of the 'env' command, not csh syntax. Yes. What made Greg's statement false was not the fact

Re: Does "LC_ALL=C" work on all shells?

> On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote: >> ~# LC_ALL=C apt install >> [... works on ...] all shells other than bash? csh, korn, dash, zsh ... * Greg Wooledge [24-02/13=Tu 15:59 -0500]: > [...] all the Bourne family shells [...] > > In csh, you need to use env. Like

Re: Does "LC_ALL=C" work on all shells?

On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote: > egrep ALL .bashrc > LC_ALL=C This has gone pretty far off the rails, but here we are. Let's address this. DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible idea. LC_ALL should only be used in

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 16:00, David Christensen wrote: On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive.  I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 =

Re: Does "LC_ALL=C" work on all shells?

John Conover (12024-02-13): > > variable LC_ALL to "C" inline of the command e.g.: ^ > egrep ALL .bashrc > LC_ALL=C > > set | egrep ALL > LC_ALL=C > > dash > set | egrep ALL You missed part of the question, what you are

Re: Does "LC_ALL=C" work on all shells?

Franco Martelli writes: > > If I want English output of an application I set the environment > variable LC_ALL to "C" inline of the command e.g.: > . . . > > So the question is: does anybody know if this syntax works on all shells > other than bash? csh, korn, dash, zsh … > Hi Franco.

Re: Does "LC_ALL=C" work on all shells?

Greg Wooledge (12024-02-13): > This syntax works in all the Bourne family shells, which is all of the > above *except* csh. > > In csh, you need to use env. No, ( setenv var something ; command ) works with csh. > % env LC_ALL=C apt install > > This works in all shells, at the cost of

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 09:40, debian-u...@howorth.org.uk wrote: Greg Wooledge wrote: Shred will determine the size of the file, then write data to the file, rewind, write data again, etc. On a traditional hard drive, that will overwrite the original private information. On modern devices, it may not.

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 11:31, gene heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When they & the startech usb3 adapters arrive.  I'll get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = $198.96 each set?

Re: Does "LC_ALL=C" work on all shells?

On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote: > ~# LC_ALL=C apt install > So the question is: does anybody know if this syntax works on all shells > other than bash? csh, korn, dash, zsh … This syntax works in all the Bourne family shells, which is all of the above *except*

Re: Does "LC_ALL=C" work on all shells?

Franco Martelli (12024-02-13): > This is useful when it's needed to submit a bug report or to speak with > other people in one international mailing list like this :) (apropos sorry > for my English). Your English does not look bad. And therefore you would probably be better making this the

Does "LC_ALL=C" work on all shells?

Hi, If I want English output of an application I set the environment variable LC_ALL to "C" inline of the command e.g.: ~# LC_ALL=C apt install Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 14:44, Thomas Schmitt wrote: Hi, Gene Heskett wrote: Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. I'll have to admit it has

Re: shred bug? [was: Unidentified subject!]

Hi, Gene Heskett wrote: > Next experiment is a pair of 4T Silicon Power SSD's When f3 has (hopefully) given its OK, the topic of a full write-and-read test will come up again. I'm looking forward to all the spin-off topics. Have a nice day :) Thomas

Re: shred bug? [was: Unidentified subject!]

Hi, Greg Wooledge wrote: > Heh. Don't forget your own attempts to use a shredder as a PRNG stream. My original idea was to watch a minimal shred run by teeing its work into a checksummer. But then topic drift came in. So we got a farm show of random generators and a discussion about what

Re: shred bug? [was: Unidentified subject!]

On 2/13/24 12:56, Thomas Schmitt wrote: Hi, Greg Wooledge wrote: Let me write out the example again, but with the bug fixed, and then explain what each line does, [... lecture about advanced shell programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 06:54:58PM +0100, Thomas Schmitt wrote: > Greg Wooledge wrote: > > Let me write out the example again, but with the bug fixed, and then > > explain what each line does, [... lecture about advanced shell > > programming ...] > > And this all because Gene Heskett was

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

On Tuesday 13 February 2024 18:34:04 Bernard S. wrote: > Hallo Wache, > Es tut mir leid, maintenant, il suffit de supprimer les noyaux anciens > à la main pour que tout rentre dans l'ordre... Encore une fois, c'est qui "Wache" et pourquoi ce début en prose germanique ? Comme bien exprimé

Debian Mobile cont'd from about 10 yeaes ago furey2310....

Can it be downloaded to usb, SD  and installed  at boot options via ADB? I did successfully install the code via termux on 2 phones but that termux wasnt rooted i believe and my charging was subsequently ruined on my android o/s The code is there on termux (terminal) Regards Patrick Shaun

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

On 13 Feb 2024 18:22, ajh-valmer wrote: Errors were encountered while processing: linux-image-6.1.0-18-amd64 linux-image-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Sans logs, c'est "ma voiture a un bruit, c'est quoi ?" ;) Télécharge manuellement le nouveau kernel et

Re: shred bug? [was: Unidentified subject!]

Hi, Greg Wooledge wrote: > Let me write out the example again, but with the bug fixed, and then > explain what each line does, [... lecture about advanced shell > programming ...] And this all because Gene Heskett was adventurous enough to buy a cheap fake USB disk. :)) Have a nice day :)

Re: Re: Problemas con el controlador no libre de NVidia en la 12.5

Buenas noches En el hilo relacionado con los problemas de un usb-c mostraba los log de apt y mostraba, entre otras cosas, lo siguiente: ___ Start-Date: 2024-02-11 17:52:08 Commandline: apt upgrade Requested-By: joe (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date:

Re: debian-cd baking process

On Tue, Feb 13, 2024 at 06:12:47PM +0100, Kevin Price wrote: >Dear Steve: > >Am 18.01.24 um 00:37 schrieb Steve McIntyre: >> Kevin Price wrote: >>> I'm not quite sure where to address this to, > >> Argh, that's my code in the debian-cd package. "reportbug debian-cd" >> should do the right thing...

Re: shred bug? [was: Unidentified subject!]

Greg Wooledge wrote: > Shred will determine the size of the file, then write data to the > file, rewind, write data again, etc. On a traditional hard drive, > that will overwrite the original private information. On modern > devices, it may not. Thanks for the excellent explanation :) One

Re: Fast Random Data Generation (Was: Re: Unidentified subject!)

David Christensen writes: On 2/12/24 08:30, Linux-Fan wrote: David Christensen writes: On 2/11/24 02:26, Linux-Fan wrote: I wrote a program to automatically generate random bytes in multiple threads: https://masysma.net/32/big4.xhtml What algorithm did you implement? I copied the

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

Hallo Wache, Es tut mir leid, maintenant, il suffit de supprimer les noyaux anciens à la main pour que tout rentre dans l'ordre... Merci @+ Bernard - Mail original - De: "ajh-valmer" À: debian-user-french@lists.debian.org Envoyé: Mardi 13 Février 2024 18:22:49 Objet: Re: Erreur

Re: simple virt-manager setup

On 13 Feb 2024 18:10 +0100, from fnat...@gmx.net (Felix Natter): > regarding virt-manager (qemu/kvm): > > Can I safely choose the "NAT" network type for a new VM > in virt-manager (Debian12): Yes. Doing so should create a new network interface named virbr[0-9] and assign an IPv4 address range

Re: Erreur nvidia suite upgrade noyau 6.1.0-18

On Monday 12 February 2024 20:14:04 ajh-valmer wrote: > Avant, j'ai purgé nvidia depuis le noyau 6.1.0-17, > pour faire un upgrade => noyau 6.1.0-18 et tenter à nouveau : > # apt update > # apt upgrade > Errors were encountered while processing: > linux-image-6.1.0-18-amd64 > linux-image-amd64 >

Re: debian-cd baking process

Dear Steve: Am 18.01.24 um 00:37 schrieb Steve McIntyre: > Kevin Price wrote: >> I'm not quite sure where to address this to, > Argh, that's my code in the debian-cd package. "reportbug debian-cd" > should do the right thing... Thank you for your help, I should have known. So I've now filed

simple virt-manager setup

Dear debian users, regarding virt-manager (qemu/kvm): Can I safely choose the "NAT" network type for a new VM in virt-manager (Debian12): Can I safely say yes to "Do you want to bring it up?"? (is it undoable?) If I choose NAT, can multiple VMs connect to each other and with the host? If not,

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

On 13 Feb 2024 10:31, Hugues MORIN-TRENEULE wrote: @zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de Stretch à Buster ;-) Tant mieux ;) C'est toujours bon de préciser pour les futurs lecteurs ! Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver le PID

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 09:35:11AM -0600, David Wright wrote: > On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > > unlikely that anyone is

Re: shred bug? [was: Unidentified subject!]

On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > unlikely that anyone is going to use >&1 in the manner of the example. > > Standard output

Re: shred bug? [was: Unidentified subject!]

Hi, "info shred" says: > > > i=$(mktemp) > > > exec 3<>"$i" > > > rm -- "$i" > > > echo "Hello, world" >&3 > > > shred - >&3 > > > exec 3>- Greg Wooledge wrote: > In fact, that last line is > written incorrectly. It should say "exec 3>&-" and what that does >

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 07:36:14AM -0500, Greg Wooledge wrote: > On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > > This is an obvious bug in the info page. I wonder how many years > > this has gone unnoticed. > > I've filed Bug#1063837 for it.

Re: shred bug? [was: Unidentified subject!]

On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote: > This is an obvious bug in the info page. I wonder how many years > this has gone unnoticed. I've filed Bug#1063837 for it.

Re: shred bug? [was: Unidentified subject!]

On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > unlikely that anyone is going to use >&1 in the manner of the example. Standard output means "whatever file descriptor 1 points to". That could be a file, a

Fix for boot failure with testing stream and 6.6.13-amd64 kernel

This is a post meant to help anyone who finds his/her system unbootable - as I did - after updating to the latest version of the testing stream which comes with a 6.6.13-amd64 kernel. When I updated last week, my system refused to boot. Checking revealed that the system-load-modules service

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

Bonjour Merci à tous pour votre aide :) @zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de Stretch à Buster ;-) Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver le PID d'apt - killall -9 "PID d'apt" - dpkg-reconfigure - apt upgrade --without-new-pkgs (=>

Re: Combining Distro DVD's

Good evening All I know some people just like a challenge. Who will use the result, though I wonder if ventoy would achieve a similar result There is a 32MB partition for efi; and the rest, which for me at present is: ls /media/keith/Ventoy/ apps linuxmint-21.3-cinnamon-64bit-beta.iso

Re: Combining Distro DVD's

On Tue, Feb 13, 2024 at 09:24:47AM +0100, hw wrote: > On Mon, 2024-02-12 at 13:41 -0500, Steve Matzura wrote: > > I thought it'd be a nice idea to combine any and all distribution media > > for a release into a single medium--a USB drive, of course. I'd start by > > creating my USB drive by

Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade

Le 12 février 2024 Hugues MORIN-TRENEULE a écrit : > Avec le recul, aujourd'hui, je ne ferai que des partitions pour /home, /var > et /opt. /home et /opt il faut voir selon tes applis. Mais si /var est saturé ça bloque tout le système à cause des logs qui ne peuvent plus se faire. > Est ce que

Re: Combining Distro DVD's

On Mon, 2024-02-12 at 13:41 -0500, Steve Matzura wrote: > I thought it'd be a nice idea to combine any and all distribution media > for a release into a single medium--a USB drive, of course. I'd start by > creating my USB drive by extracting the first DVD to it, thereby > ensuring the boot