Re: can not find repo

[Cindy Sue Causey]

On Sun, Apr 14, 2024 at 12:03 PM  wrote:
>
> i don't see an armel repo on any of the mirrors i checked
> it was there a week ago
> has it been deleted or am i just old and blind
>

Hi.. I just took a quick poke at this by using the following k/t debootstrap:

http://deb.debian.org/debian

By clicking through on dists/Debian12.5/, the following possibilities appeared:

http://ftp.debian.org/debian/dists/Debian12.5/main/installer-armel/

http://ftp.debian.org/debian/dists/Debian12.5/main/binary-armel/

Those are directly via Debian instead of mirrors. To help Debian
servers over the years,
I've had success by e.g. snipping from "dists/" on then searching on
that part plus
the name of whatever mirror I was favoring at the time. That worked about 95%
of the time and helps spread the server download wear-and-tear across the Net..

Hope that somehow helps.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

can not find repo

[fxkl47BF]

i don't see an armel repo on any of the mirrors i checked
it was there a week ago
has it been deleted or am i just old and blind

Re: Can't find informatin on passwdqc, pwqcheck or cracklib

[Loïc Grenié]

On Fri March. 22, 2024, at 03:39, NC wrote:

> I'm wanting to upgrade my security, and like to use some of the
> suggested tools. I've installed some of the tools, but can't find man
> pages on them.  Similarly there's no results to be had from googling.
> I must be missing something..
>

As far as I can tell, passwdqc package installs man pages for

pwqcheck
pwqfilter
pwqgen

Loïc

Re: Can't find informatin on passwdqc, pwqcheck or cracklib

[Michael Kjörling]

On 22 Mar 2024 13:16 +1100, from n...@linearg.com:
> I'm wanting to upgrade my security, and like to use some of the suggested
> tools. I've installed some of the tools, but can't find man pages on them.

You can see the files installed by a package by running:

$ dpkg -L 

For example:

$ dpkg -L coreutils

man pages will typically be under /usr/share/man:

$ dpkg -L coreutils | grep ^/usr/share/man/

dpkg -L == dpkg --listfiles

Note that this will not list files generated during installation (for
example a kernel module package that triggers a DKMS build would
likely show the source code but _not_ the built binaries) or
configuration files created later; but that shouldn't be an issue with
man pages.

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

Re: Can't find informatin on passwdqc, pwqcheck or cracklib

[tomas]

On Fri, Mar 22, 2024 at 01:16:13PM +1100, n...@linearg.com wrote:
> I'm wanting to upgrade my security, and like to use some of the suggested
> tools. I've installed some of the tools, but can't find man pages on them.
> Similarly there's no results to be had from googling.
> I must be missing something..

As far as I can see [1], cracklib comes with man pages...

Cheers

[1] https://packages.debian.org/bookworm/amd64/cracklib-runtime/filelist
-- 
t


signature.asc
Description: PGP signature

Re: Can't find informatin on passwdqc, pwqcheck or cracklib

[David]

On Fri, 2024-03-22 at 13:16 +1100, n...@linearg.com wrote:
> I'm wanting to upgrade my security, and like to use some of the  
> suggested tools. I've installed some of the tools, but can't find man  
> pages on them.  Similarly there's no results to be had from googling.  
> I must be missing something..

Information, basically.
What 'tools'?
Cheers!

Re: Can't find informatin on passwdqc, pwqcheck or cracklib

[David]

On Fri, 2024-03-22 at 13:16 +1100, n...@linearg.com wrote:
> I'm wanting to upgrade my security, and like to use some of the  
> suggested tools. I've installed some of the tools, but can't find man  
> pages on them.  Similarly there's no results to be had from googling.  
> I must be missing something..

In short: cracklib? cracklib2?
Not all pkgs are covered by man pages, but there are plenty of other information sources.
Cheers!

Can't find informatin on passwdqc, pwqcheck or cracklib

[n]

I'm wanting to upgrade my security, and like to use some of the 
suggested tools. I've installed some of the tools, but can't find man 
pages on them.  Similarly there's no results to be had from googling.

I must be missing something..

NC

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Andre Rodier]

On 21/02/2024 21:08, Michael Kjörling wrote:

On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):

- What is the best approach to check if there is any vulnerability in the
packages configuration ?
- Is there any service that could audit the deployment code or the
configuration files ?


My understanding is that both Lynis and Vuls are popular for
already-installed systems. If you have your configuration packaged as
Ansible scripts, then deploying that onto a disposable VM based on a
minimal Debian installation should be a reasonably practical way of
auditing the deployment process itself for vulnerabilities.
Thanks, I will try this approach, this is a good idea. Yes, using a VM 
is easy, that's the approach I used for the development.



A web search for something like "linux local vulnerability scanner"
will provide you with additional leads.
I tried the debsecan package, which is good as well. I will see if I can 
make this more readable and integrated with the distribution.



Note that any automated tool will use some kind of heuristics so (a)
may find things that are not actually vulnerabilities in your setup,
and (b) might not find something which _is_ a vulnerability in your
setup

Of course, as usual with this kind of tools.

Thanks for your insights.

André

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Timothy Butterworth]

On February 21, 2024, at 4:08 PM, Michael Kjörling <2695bd53d...@ewoof.net> 
wrote:

>On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):
>> - What is the best approach to check if there is any vulnerability in the
>> packages configuration ?
>> - Is there any service that could audit the deployment code or the
>> configuration files ?
>My understanding is that both Lynis and Vuls are popular for
>already-installed systems. If you have your configuration packaged as
>Ansible scripts, then deploying that onto a disposable VM based on a
>minimal Debian installation should be a reasonably practical way of
>auditing the deployment process itself for vulnerabilities.
>A web search for something like "linux local vulnerability scanner"
>will provide you with additional leads.
>Note that any automated tool will use some kind of heuristics so (a)
>may find things that are not actually vulnerabilities in your setup,
>and (b) might not find something which _is_ a vulnerability in your
>setup.
>-- 

You can install and run Tenable Nessus Vulnerability scanner. The free version 
can scan like 10 IPs. I use Nessus and it works well. 

Security Blanket is a Security hardening tool suite which is nice and not too 
expensive.


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

Re: How to find system configuration vulnerabilities; was: Thank you Debian

[Michael Kjörling]

On 21 Feb 2024 19:03 +, from an...@rodier.me (Andre Rodier):
> - What is the best approach to check if there is any vulnerability in the
> packages configuration ?
> - Is there any service that could audit the deployment code or the
> configuration files ?

My understanding is that both Lynis and Vuls are popular for
already-installed systems. If you have your configuration packaged as
Ansible scripts, then deploying that onto a disposable VM based on a
minimal Debian installation should be a reasonably practical way of
auditing the deployment process itself for vulnerabilities.

A web search for something like "linux local vulnerability scanner"
will provide you with additional leads.

Note that any automated tool will use some kind of heuristics so (a)
may find things that are not actually vulnerabilities in your setup,
and (b) might not find something which _is_ a vulnerability in your
setup.

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

Re: find and it uncommon syntax - grrrrrrrrr

[gene heskett]

On 2/10/24 16:07, Greg Wooledge wrote:

On Sat, Feb 10, 2024 at 02:58:24PM -0600, Nicholas Geovanis wrote:

On Sat, Feb 10, 2024, 2:46 PM gene heskett  wrote:


Greetings;

I have misplaced file someplace in /home/gene.
its name is bpim5*shelf.scad



Assuming that you are searching in the current working directory:
  find bpim*  -print | grep 'shelf.scad'


That's not correct.  The argument(s) that immediately follow find should
be the starting point(s) where it will begin its search.  Normally these
would be directories, especially the "." directory, which is actually
the default in GNU find (but not a default in POSIX find).

This command would only work if the file Gene's looking for happens to
be in his home directory, *or*, if the file he's looking for happens to
be underneath a *directory* whose name matches the bpim* glob.  This is
possible, but I wouldn't count on it.

Especially here. I resaved it, after a couple mods, in 
3dp-stf/genes-nas.  So searching thru all the children of "." should be 
the expected behavious. But finding that fraudulent pile of 2T disks was 
as bogus as a $3 bill, upsets my plans. The only usb-sata adapter I 
trust is StarTech, and its cable is 3x longer than I need. This bogus 
drive came sealed in a case that I had printed supports for that fit in 
2 shelf spaces, leaving room in the bottom of the care for a psu.  The 
sata package is bigger but would take 3 spaces for 6 of them, exiling 
the psu external to the cage.  So this job now printing is 4 more 
shelves, w/o the pi bolt pattern.  3dprinting is hard on memory, I've 
12G of 3dp.stf now.  Slicers and such are plain stupid, generating as 
much as 2 gigabytes for one complex part that takes 3 days to run. I've 
written 3 days jobs for a milling machine In 90 LOC because linuxcnc 
understands loops, none of the slicers or machines do, so the file you 
feed the printer is totally unrolled. And 10 to 30 times the size needed 
if the part file was converted from additive to subtractive.  It may get 
there, but probably after I miss roll call.


Thanks Greg.  Take care.

.


Cheers, Gene Heskett, CET.
--
"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

Re: find and it uncommon syntax - grrrrrrrrr

[Andy Smith]

Hello,

On Sat, Feb 10, 2024 at 06:03:39PM -0500, gene heskett wrote:
> On 2/10/24 15:55, Greg Wooledge wrote:
> > find . -iname 'bpim5*shelf.scad'
> 
> Thank you Greg, it worked and 4 more copies are under construction now, but
> why is this not in the man page? Mind boggling.

Why can Gene not locate "iname" when it's right there in the "find"
man page? Mind boggling.

Why can Gene not type "how do I use GNU find to find a file by
name" into a web search engine and read any of the several links on
the first page of results? Mind boggling.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: find and it uncommon syntax - grrrrrrrrr

[Andy Smith]

Hello,

On Sat, Feb 10, 2024 at 03:46:09PM -0500, gene heskett wrote:
> I have misplaced file someplace in /home/gene.
> its name is bpim5*shelf.scad
> As usual it outputs 100,000 filenames, none of which is the one I am looking
> for. How in heck do you shut this thing up so it only spits out
> /the/path/to/the/file its looking for it it even found it?

Gene and his inability as usual to show us what he has tried and the
output he got - gr

> And where do I put that as an alias, in my .bashrc?

find is an extremely flexible command that can do a lot of different
queries so to get any sort of meaningful answer to this you'd have
to show us what exactly you tried.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: find and it uncommon syntax - grrrrrrrrr

[gene heskett]

On 2/10/24 15:55, Greg Wooledge wrote:

find . -iname 'bpim5*shelf.scad'


Thank you Greg, it worked and 4 more copies are under construction now, 
but why is this not in the man page? Mind boggling.


Cheers, Gene Heskett, CET.
--
"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

Re: find and it uncommon syntax - grrrrrrrrr

[Greg Wooledge]

On Sat, Feb 10, 2024 at 02:58:24PM -0600, Nicholas Geovanis wrote:
> On Sat, Feb 10, 2024, 2:46 PM gene heskett  wrote:
> 
> > Greetings;
> >
> > I have misplaced file someplace in /home/gene.
> > its name is bpim5*shelf.scad
> >
> 
> Assuming that you are searching in the current working directory:
>  find bpim*  -print | grep 'shelf.scad'

That's not correct.  The argument(s) that immediately follow find should
be the starting point(s) where it will begin its search.  Normally these
would be directories, especially the "." directory, which is actually
the default in GNU find (but not a default in POSIX find).

This command would only work if the file Gene's looking for happens to
be in his home directory, *or*, if the file he's looking for happens to
be underneath a *directory* whose name matches the bpim* glob.  This is
possible, but I wouldn't count on it.

Re: find and it uncommon syntax - grrrrrrrrr

[Nicholas Geovanis]

On Sat, Feb 10, 2024, 2:46 PM gene heskett  wrote:

> Greetings;
>
> I have misplaced file someplace in /home/gene.
> its name is bpim5*shelf.scad
>

Assuming that you are searching in the current working directory:
 find bpim*  -print | grep 'shelf.scad'

As usual it outputs 100,000 filenames, none of which is the one I am
> looking for. How in heck do you shut this thing up so it only spits out
> /the/path/to/the/file its looking for it it even found it?
>
> And where do I put that as an alias, in my .bashrc?
>
> Cheers, Gene Heskett, CET.
> --
> "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
>
>

Re: find and it uncommon syntax - grrrrrrrrr

[Greg Wooledge]

On Sat, Feb 10, 2024 at 03:46:09PM -0500, gene heskett wrote:
> I have misplaced file someplace in /home/gene.
> its name is bpim5*shelf.scad
> As usual it outputs 100,000 filenames, none of which is the one I am looking

cd
find . -iname 'bpim5*shelf.scad'

find and it uncommon syntax - grrrrrrrrr

[gene heskett]

Greetings;

I have misplaced file someplace in /home/gene.
its name is bpim5*shelf.scad
As usual it outputs 100,000 filenames, none of which is the one I am 
looking for. How in heck do you shut this thing up so it only spits out 
/the/path/to/the/file its looking for it it even found it?


And where do I put that as an alias, in my .bashrc?

Cheers, Gene Heskett, CET.
--
"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

Re: find question

[Greg Wooledge]

On Sun, Jan 14, 2024 at 12:25:03AM +1300, Richard Hector wrote:
> Except that from the man page, -delete implies -depth. Maybe that's a
> GNUism; I don't know.

Oh, maybe that's new?  I'm not sure.  Anyway, yeah, -delete is a GNUism.
POSIX find doesn't have it at all.

> That leaves the question: When using -delete (and -depth), does the deletion
> of files within a directory update the mtime of that directory, thereby
> rendering the directory inelegible for deletion when it would have been
> before? Or is the mtime of that directory recorded before the contents are
> processed?
> 
> I just did a quick test (using -mmin -1 instead), and it did delete the
> whole lot.

I don't know the answer to that.  Even in the worst case, though, you'd
just have an empty directory sitting around until some future run of
the cleanup script.  It would eventually be removed.

On the other hand, it might Just Work as you desire.

> So I'm still unclear why sometimes the top-level directory (or a directory
> within it) gets left behind. I've just noticed that one of the directories
> (not the one in $dir) contains a '@' symbol; I don't know if that affects
> it?

find should not care about the characters in the directory name.

> I'm tempted to avoid the problem by only using find for the top-level
> directory, and exec'ing "rm -r(f)" on it. I'm sure you'll tell me there are
> problems with that, too :-)

You never said that was an allowed solution. ;-)  The only drawback
to that solution would be if you didn't *want* to remove the entire
directory recursively.  If a directory has a timestamp that makes it
eligible for cleanup, but some file down inside it does not, do you
want to remove that file anyway?  If so, then sure, -exec rm -rf {} +
will get it done.

Re: find question

[Richard Hector]

On 30/12/23 01:27, Greg Wooledge wrote:

On Fri, Dec 29, 2023 at 10:56:52PM +1300, Richard Hector wrote:

find $dir -mtime +7 -delete


"$dir" should be quoted.


Got it, thanks.


Will that fail to delete higher directories, because the deletion of files
updated the mtime?

Or does it get all the mtimes first, and use those?


It doesn't delete directories recursively.

unicorn:~$ mkdir -p /tmp/foo/bar
unicorn:~$ touch /tmp/foo/bar/file
unicorn:~$ find /tmp/foo -name bar -delete
find: cannot delete ‘/tmp/foo/bar’: Directory not empty


Understood.


But I suppose you're asking "What if it deletes both the file and the
directory, because they both qualify?"

In that case, you should use the -depth option, so that it deletes
the deepest items first.

unicorn:~$ find /tmp/foo -depth -delete
unicorn:~$ ls /tmp/foo
ls: cannot access '/tmp/foo': No such file or directory

Without -depth, it would try to delete the directory first, and that
would fail because the directory's not empty.

-depth must appear AFTER the pathnames, but BEFORE any other arguments
such as -mtime or -name.


Except that from the man page, -delete implies -depth. Maybe that's a 
GNUism; I don't know.



And how precise are those times? If I'm running a cron job that deletes
7-day-old directories then creates a new one less than a second later, will
that reliably get the stuff that's just turned 7 days old?


The POSIX documentation describes it pretty well:

-mtime n  The primary shall evaluate as true if the  file  modification
  time  subtracted  from  the  initialization  time, divided by
  86400 (with any remainder discarded), is n.

To qualify for -mtime +7, a file's age as calculated above must be at
least 8 days.  (+7 means more than 7.  It does not mean 7 or more.)


So 7 days and one second doesn't count as "more than 7 days"? It 
truncates the value to integer days before comparing?


Ah, yes, I see that now under -atime. Confusing. Thanks for pushing me 
to investigate :-)



It's not uncommon for the POSIX documentation of a command to be superior
to the GNU documentation of that same command, especially a GNU man page.
GNU info pages are often better, but GNU man pages tend to be lacking.


Understood, thanks. Though it might be less correct where GNUisms exist.

That leaves the question: When using -delete (and -depth), does the 
deletion of files within a directory update the mtime of that directory, 
thereby rendering the directory inelegible for deletion when it would 
have been before? Or is the mtime of that directory recorded before the 
contents are processed?


I just did a quick test (using -mmin -1 instead), and it did delete the 
whole lot.


So I'm still unclear why sometimes the top-level directory (or a 
directory within it) gets left behind. I've just noticed that one of the 
directories (not the one in $dir) contains a '@' symbol; I don't know if 
that affects it?


I'm tempted to avoid the problem by only using find for the top-level 
directory, and exec'ing "rm -r(f)" on it. I'm sure you'll tell me there 
are problems with that, too :-)


Apologies for the slow response - sometimes the depression kicks in and 
I don't get back to a problem for a while :-(


Cheers,
Richard

Re: find question

[Greg Wooledge]

On Fri, Dec 29, 2023 at 10:56:52PM +1300, Richard Hector wrote:
> find $dir -mtime +7 -delete

"$dir" should be quoted.

> Will that fail to delete higher directories, because the deletion of files
> updated the mtime?
> 
> Or does it get all the mtimes first, and use those?

It doesn't delete directories recursively.

unicorn:~$ mkdir -p /tmp/foo/bar
unicorn:~$ touch /tmp/foo/bar/file
unicorn:~$ find /tmp/foo -name bar -delete
find: cannot delete ‘/tmp/foo/bar’: Directory not empty

But I suppose you're asking "What if it deletes both the file and the
directory, because they both qualify?"

In that case, you should use the -depth option, so that it deletes
the deepest items first.

unicorn:~$ find /tmp/foo -depth -delete
unicorn:~$ ls /tmp/foo
ls: cannot access '/tmp/foo': No such file or directory

Without -depth, it would try to delete the directory first, and that
would fail because the directory's not empty.

-depth must appear AFTER the pathnames, but BEFORE any other arguments
such as -mtime or -name.

> And how precise are those times? If I'm running a cron job that deletes
> 7-day-old directories then creates a new one less than a second later, will
> that reliably get the stuff that's just turned 7 days old?

The POSIX documentation describes it pretty well:

   -mtime n  The primary shall evaluate as true if the  file  modification
 time  subtracted  from  the  initialization  time, divided by
 86400 (with any remainder discarded), is n.

To qualify for -mtime +7, a file's age as calculated above must be at
least 8 days.  (+7 means more than 7.  It does not mean 7 or more.)

It's not uncommon for the POSIX documentation of a command to be superior
to the GNU documentation of that same command, especially a GNU man page.
GNU info pages are often better, but GNU man pages tend to be lacking.

find question

[Richard Hector]

Hi all,

When using:

find $dir -mtime +7 -delete

Will that fail to delete higher directories, because the deletion of 
files updated the mtime?


Or does it get all the mtimes first, and use those?

And how precise are those times? If I'm running a cron job that deletes 
7-day-old directories then creates a new one less than a second later, 
will that reliably get the stuff that's just turned 7 days old? Or will 
there be a race condition depending on how quickly cron starts the 
script, which could be different each time?


Is there a better way to do this?

Cheers,
Richard

Re: apt upgrade can't find archive for virtualbox-7.0

[Michael Kjörling]

On 23 Dec 2023 09:22 -0500, from s.mol...@sbcglobal.net (Stephen P. Molnar):
>> If you don't want to run VirtualBox going forward, the easiest way
>> might be to just `apt purge virtualbox-7.0`.
> (base) comp@AbNormal:~$ sudo apt purge virtualbox-7.0
> [sudo] password for comp:
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: The package virtualbox-7.0 needs to be reinstalled, but I can't find an
> archive for it.
> (base) comp@AbNormal:~$
>> 
>> Depending on the current state of the package, you might need to
>> reinstall it before you can remove it.

Please re-read my post in full.

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

Re: apt upgrade can't find archive for virtualbox-7.0; was: Synaptic Problem

[Stephen P. Molnar]

Thanks fr the reply. Please see below:


On 12/23/2023 09:01 AM, Michael Kjörling wrote:

On 23 Dec 2023 08:34 -0500, from s.mol...@sbcglobal.net (Stephen P. Molnar):

However, I have a bit of a problem, when I attempt:

(base) comp@AbNormal:~$ sudo apt update
[sudo] password for comp:
Hit:1 http://security.debian.org/debian-security bookworm-security InRelease
Hit:2 http://debian.uchicago.edu/debian bookworm InRelease
Hit:3 http://debian.uchicago.edu/debian bookworm-updates InRelease
Hit:4 https://repo.skype.com/deb stable InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: https://repo.skype.com/deb/dists/stable/InRelease: Key is stored in
legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION
section in apt-key(8) for details.
(base) comp@AbNormal:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: The package virtualbox-7.0 needs to be reinstalled, but I can't find an
archive for it.
(base) comp@AbNormal:~$

Please advise.

VirtualBox isn't in the official Debian repositories, so you likely
used Oracle's repository to install it at some point and then removed
that repository from your apt configuration (possibly as a part of
installing VMWare; in general, having more than one hypervisor
installed on the same system is discouraged). Alternatively, you might
have installed VirtualBox using a manually downloaded .deb file.

Either re-add Oracle's repository per
https://www.virtualbox.org/wiki/Linux_Downloads#Debian-basedLinuxdistributions
and try `apt reinstall virtualbox-7.0` (this is probably the easiest
if you want to keep running VirtualBox).

Or reinstall the .deb using dpkg -i if you originally installed
VirtualBox that way.

Or you could try `apt remove virtualbox-7.0`.

If you don't want to run VirtualBox going forward, the easiest way
might be to just `apt purge virtualbox-7.0`.

(base) comp@AbNormal:~$ sudo apt purge virtualbox-7.0
[sudo] password for comp:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: The package virtualbox-7.0 needs to be reinstalled, but I can't find 
an archive for it.

(base) comp@AbNormal:~$


Depending on the current state of the package, you might need to
reinstall it before you can remove it.

After either remove or purge (see the apt man page for the difference
between the two) you should be able to reinstall it later if you want
to.

More generally, I agree with Andy's recommendation to check out
KVM/QEMU unless you have something in particular which depends on
using a specific other hypervisor. You may want to check out AQEMU as
a replacement for virt-manager; I haven't tried it myself, but based
on screenshots I have seen it looks like a closer match for
VirtualBox's GUI tooling, and you will still have access to the full
power of KVM through virsh if you want that.



--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1

Re: apt upgrade can't find archive for virtualbox-7.0; was: Synaptic Problem

[Michael Kjörling]

On 23 Dec 2023 08:34 -0500, from s.mol...@sbcglobal.net (Stephen P. Molnar):
> However, I have a bit of a problem, when I attempt:
> 
> (base) comp@AbNormal:~$ sudo apt update
> [sudo] password for comp:
> Hit:1 http://security.debian.org/debian-security bookworm-security InRelease
> Hit:2 http://debian.uchicago.edu/debian bookworm InRelease
> Hit:3 http://debian.uchicago.edu/debian bookworm-updates InRelease
> Hit:4 https://repo.skype.com/deb stable InRelease
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> All packages are up to date.
> W: https://repo.skype.com/deb/dists/stable/InRelease: Key is stored in
> legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION
> section in apt-key(8) for details.
> (base) comp@AbNormal:~$ sudo apt upgrade
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: The package virtualbox-7.0 needs to be reinstalled, but I can't find an
> archive for it.
> (base) comp@AbNormal:~$
> 
> Please advise.

VirtualBox isn't in the official Debian repositories, so you likely
used Oracle's repository to install it at some point and then removed
that repository from your apt configuration (possibly as a part of
installing VMWare; in general, having more than one hypervisor
installed on the same system is discouraged). Alternatively, you might
have installed VirtualBox using a manually downloaded .deb file.

Either re-add Oracle's repository per
https://www.virtualbox.org/wiki/Linux_Downloads#Debian-basedLinuxdistributions
and try `apt reinstall virtualbox-7.0` (this is probably the easiest
if you want to keep running VirtualBox).

Or reinstall the .deb using dpkg -i if you originally installed
VirtualBox that way.

Or you could try `apt remove virtualbox-7.0`.

If you don't want to run VirtualBox going forward, the easiest way
might be to just `apt purge virtualbox-7.0`.

Depending on the current state of the package, you might need to
reinstall it before you can remove it.

After either remove or purge (see the apt man page for the difference
between the two) you should be able to reinstall it later if you want
to.

More generally, I agree with Andy's recommendation to check out
KVM/QEMU unless you have something in particular which depends on
using a specific other hypervisor. You may want to check out AQEMU as
a replacement for virt-manager; I haven't tried it myself, but based
on screenshots I have seen it looks like a closer match for
VirtualBox's GUI tooling, and you will still have access to the full
power of KVM through virsh if you want that.

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

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 11:23 PM, John Hasler  
wrote:


> Mr. Turritopsis Dohrnii Teo En Ming writes:
> 
> > You managed to install OpenWRT on an Ubiquiti router?
> 
> 
> Yes. It was quite straightforward. Instructions on the OpenWRT site.
> --
> John Hasler
> j...@sugarbit.com
> Elmwood, WI USA

I have seen the web UI of OpenWRT. Quite impressive.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 11:23 PM, John Hasler  
wrote:


> Mr. Turritopsis Dohrnii Teo En Ming writes:
> 
> > You managed to install OpenWRT on an Ubiquiti router?
> 
> 
> Yes. It was quite straightforward. Instructions on the OpenWRT site.
> --
> John Hasler
> j...@sugarbit.com
> Elmwood, WI USA

It's interesting to know. Thank you.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[John Hasler]

Mr. Turritopsis Dohrnii Teo En Ming writes:
> You managed to install OpenWRT on an Ubiquiti router?

Yes. It was quite straightforward.  Instructions on the OpenWRT site.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 6:15 AM, John Hasler  wrote:


> Turritopsis Dohrnii Teo En Ming wrote:
> 
> > UDM Pro runs Debian 11 (bullseye)
> 
> 
> I have a Ubiquiti router. Before I installed OpenWRT I explored the OS.
> It uses packages from Bullseye but it is certainly not Debian. You
> couldn't find that file because it isn't there.
> --
> John Hasler
> j...@sugarbit.com
> Elmwood, WI USA

You managed to install OpenWRT on an Ubiquiti router?

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 6:08 AM, jeremy ardley 
 wrote:


> On 7/12/23 23:52, Turritopsis Dohrnii Teo En Ming wrote:
> 
> > Subject: Could not find interfaces configuration file 
> > /etc/network/interfaces in Debian Linux 11 (bullseye)
> 
> 
> 
> You should confirm that the device is actually using that file.
> 
> There are at least three different network configuration services in
> Debian - which are not completely mutually exclusive
> 
> what is the result of these commands?
> 
> sudo systemctl status networking
> 
> sudo systemctl status systemd-networkd
> 
> sudo systemctl status NetworkManager

I will run these commands next week.

Thank you for your reply.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 6:05 AM, Andy Smith  
wrote:


> Hello,
> 
> On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming 
> wrote:
> 
> > UDM Pro runs Debian 11 (bullseye)
> 
> 
> I don't think it does. Just because you found a file on the
> filesystem that says it does, is as trustworthy as the claims in
> your email that your client is called Henry Kissinger and your
> colleague Edward Snowden.
> 
> It might have started out as Debian 11, but Ubiquiti have made
> unknown changes to it.
> 
> > Linux United-States-Space-Command-Secret-Server 4.19.152-ui-alpine 
> > #4.19.152 SMP Thu Apr 6 21:41:48 CST 2023 aarch64 GNU/Linux
> 
> 
> This is also not a kernel supplied by Debian.
> 
> > But another problem cropped up. Now we could not access the web UI
> > of the UDM Pro.
> 
> 
> […]
> 
> > We could not putty (ssh) into the UDM Pro too.
> > 
> > May I know what the problem could be?
> 
> 
> Given that you're running an operating system supplied by Ubiquiti
> on hardware supplied by Ubiquiti using a web frontend written by
> Ubiquiti on top of a kernel supplied by Ubiquii, I think you need to
> ask Ubiquiti.
> 
> > Please advise.
> 
> 
> I think it's for your vendor to advise.
> 
> Thanks,
> Andy
> 
> PS It would also be advisable to get into the habit of using the
> "ip" suite of tools instead of deprecated ones like "ifconfig"
> and "route". The reason being that tools like ifconfig have not
> kept up changes in the Linux kernel and do not actually display
> all settings of the system any more. Most of the time the old
> ways will still work, but at some point you will encounter a
> situation where ifconfig etc is not showing you all of the
> settings. The diagnostic output can also be confusing to people
> born after the deprecation of ifconfig, for example.
> 
> Your bigger problem though is that Debian didn't supply this
> hardware or software.
> 
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting

Yes, I am going to ask Ubiquiti.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 12:19 AM, Dan Purgert  wrote:


> On Dec 07, 2023, to...@tuxteam.de wrote:
> 
> > On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming 
> > wrote:
> > 
> > [...]
> > 
> > > Problem
> > > =
> > > 
> > > On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> > > firmware updates automatically. Their UDM Pro was running UniFi OS 
> > > version 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 
> > > but couldn't.
> > > 
> > > UDM Pro runs Debian 11 (bullseye)
> > > 
> > 
> > Now I don't understand: is it running UniFi OS or Debian bullseye?
> 
> 
> "UniFi OS" (And EdgeOS on other lineups) is customized Debian Stable of
> some flavor or other.
> 
> > Or is Ubiquiti just cheapskating and sending their customers here
> > to save on customer support?
> 
> 
> I've never seen them direct customers anywhere other than their support
> forums...
> 
> --
> ||O||
> |||O| Github: https://github.com/dpurgert
> |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

What is EdgeOS?

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

On Friday, December 8th, 2023 at 12:12 AM, to...@tuxteam.de  
wrote:


> On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming 
> wrote:
> 
> [...]
> 
> > Problem
> > =
> > 
> > On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> > firmware updates automatically. Their UDM Pro was running UniFi OS version 
> > 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but 
> > couldn't.
> > 
> > UDM Pro runs Debian 11 (bullseye)
> > 
> 
> 
> Now I don't understand: is it running UniFi OS or Debian bullseye?
> 
> Or is Ubiquiti just cheapskating and sending their customers here
> to save on customer support?
> 
> Inquiring minds...
> 
> Cheers
> --
> t

It is an UniFi Dream Machine Pro running Debian 11 bullseye.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[John Hasler]

Turritopsis Dohrnii Teo En Ming wrote:
> UDM Pro runs Debian 11 (bullseye)

I have a Ubiquiti router.  Before I installed OpenWRT I explored the OS.
It uses packages from Bullseye but it is certainly not Debian.  You
couldn't find that file because it isn't there.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[jeremy ardley]

On 7/12/23 23:52, Turritopsis Dohrnii Teo En Ming wrote:

Subject: Could not find interfaces configuration file /etc/network/interfaces 
in Debian Linux 11 (bullseye)



You should confirm that the device is actually using that file.

There are at least three different network configuration services in 
Debian - which are not completely mutually exclusive


what is the result of these commands?

sudo systemctl status networking

sudo systemctl status systemd-networkd

sudo systemctl status NetworkManager

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Andy Smith]

Hello,

On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming wrote:
> UDM Pro runs Debian 11 (bullseye)

I don't think it does. Just because you found a file on the
filesystem that says it does, is as trustworthy as the claims in
your email that your client is called Henry Kissinger and your
colleague Edward Snowden.

It might have started out as Debian 11, but Ubiquiti have made
unknown changes to it.

> Linux United-States-Space-Command-Secret-Server 4.19.152-ui-alpine #4.19.152 
> SMP Thu Apr 6 21:41:48 CST 2023 aarch64 GNU/Linux

This is also not a kernel supplied by Debian.

> But another problem cropped up. Now we could not access the web UI
> of the UDM Pro.

[…]

> We could not putty (ssh) into the UDM Pro too.
> 
> May I know what the problem could be?

Given that you're running an operating system supplied by Ubiquiti
on hardware supplied by Ubiquiti using a web frontend written by
Ubiquiti on top of a kernel supplied by Ubiquii, I think you need to
ask Ubiquiti.

> Please advise.

I think it's for your vendor to advise.

Thanks,
Andy

PS It would also be advisable to get into the habit of using the
   "ip" suite of tools instead of deprecated ones like "ifconfig"
   and "route". The reason being that tools like ifconfig have not
   kept up changes in the Linux kernel and do not actually display
   all settings of the system any more. Most of the time the old
   ways will still work, but at some point you will encounter a
   situation where ifconfig etc is not showing you all of the
   settings. The diagnostic output can also be confusing to people
   born after the deprecation of ifconfig, for example.

   Your bigger problem though is that Debian didn't supply this
   hardware or software.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Dan Purgert]

On Dec 07, 2023, to...@tuxteam.de wrote:
> On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming 
> wrote:
> 
> [...]
> 
> > Problem
> > =
> > 
> > On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> > firmware updates automatically. Their UDM Pro was running UniFi OS version 
> > 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but 
> > couldn't.
> > 
> > UDM Pro runs Debian 11 (bullseye)
> > 
> 
> Now I don't understand: is it running UniFi OS or Debian bullseye?

"UniFi OS" (And EdgeOS on other lineups) is customized Debian Stable of
some flavor or other.

> 
> Or is Ubiquiti just cheapskating and sending their customers here
> to save on customer support?

I've never seen them direct customers anywhere other than their support
forums... 

-- 
|_|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: Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[tomas]

On Thu, Dec 07, 2023 at 03:52:20PM +, Turritopsis Dohrnii Teo En Ming wrote:

[...]

> Problem
> =
> 
> On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
> firmware updates automatically. Their UDM Pro was running UniFi OS version 
> 3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but 
> couldn't.
> 
> UDM Pro runs Debian 11 (bullseye)
> 

Now I don't understand: is it running UniFi OS or Debian bullseye?

Or is Ubiquiti just cheapskating and sending their customers here
to save on customer support?

Inquiring minds...

Cheers
-- 
t


signature.asc
Description: PGP signature

Could not find interfaces configuration file /etc/network/interfaces in Debian Linux 11 (bullseye)

[Turritopsis Dohrnii Teo En Ming]

Subject: Could not find interfaces configuration file /etc/network/interfaces 
in Debian Linux 11 (bullseye)

Good day from Singapore,

Background Information
===

Initially our client has a UniFi Dream Machine Pro (UDM Pro) acting as a 
firewall and router. Port 9 (WAN1) on the UDM Pro was connected to the ONT. 
Port 1 on the UDM Pro was connected to the LAN switch.

Then our client purchased Fortigate 80F firewall from us.

The date of the deployment of the Fortigate 80F firewall is 26 May 2023.

During the setup and installation, I had connected WAN1 on the Fortigate 80F 
firewall to the ONT. Then I need to convert UDM Pro to non-routing mode. RJ45 
cable to Port 9 (WAN1) on the UDM Pro was removed. I proceeded to connect Port 
1 on the UDM Pro to Port 1 on the Fortigate 80F firewall. As the Fortigate 80F 
firewall already had DHCP server configured, I disabled the DHCP server inside 
UDM Pro.

Everything (the network infrastructure) was working well for 6 months 11 days 
until 6 Dec 2023.

Problem
=

On 6 Dec 2023, our client discovered that their UDM Pro could not perform 
firmware updates automatically. Their UDM Pro was running UniFi OS version 
3.0.20. Client wants to upgrade firmware to latest version 3.1.16 but couldn't.

UDM Pro runs Debian 11 (bullseye)


When I putty (SSH) into the UDM Pro machine, I executed the command "cat 
/etc/os-release".

The output is:

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

The output of the "uname -a" command is:

Linux United-States-Space-Command-Secret-Server 4.19.152-ui-alpine #4.19.152 
SMP Thu Apr 6 21:41:48 CST 2023 aarch64 GNU/Linux

Troubleshooting


Troubleshooting date is 6 Dec 2023 Wednesday.

When I run "netstat -nr" or "route" commands in UDM Pro, the output shows that 
the default gateway for the 0.0.0.0/0.0.0.0 destination is 192.168.2.2. 
192.168.2.2 is the IP address of the Fortigate 80F firewall. This confirms that 
the gateway was correctly configured on the UDM Pro. The LAN IP address of the 
UDM Pro is 192.168.2.1.

The UDM Pro could reach the gateway 192.168.2.2, in this case the Fortigate 80F 
firewall.

I could ping the gateway 192.168.2.2 from within the UDM Pro CLI.

However, I could not ping 1.2.3.4 or 8.8.8.8.

Even with the gateway correctly configured on the UDM Pro, it could not reach 
the outside world.

When I run the command "ifconfig br0", the broadcast shows up as 0.0.0.0. I 
thought this is wrong. So I ran the following Linux command to correct it.

# ifconfig br0 broadcast 192.168.2.255

But it did not solve the problem.

My colleague Henry Kissinger told me that Port 9 (WAN1) on the UDM Pro must be 
connected (seems like a design flaw). I had wanted to configure the network 
interfaces using the /etc/network/interfaces file. But I could not find it 
anywhere in the terminal in Debian 11. Where can I find this file in Debian 11? 
It is missing!

I had no choice but to use the web UI of the UDM Pro to configure Port 9 
(WAN1). I had asked the client to connect Port 9 (WAN1) on the UDM Pro to Port 
5 (LAN) on the Fortigate firewall. Then I configure Port 9 (WAN1) on the UDM 
Pro with the following network parameters:

Static IPv4 address: 192.168.2.254
Subnet mask: 255.255.255.0
Default Gateway: 192.168.2.2

After configuring Port 9 (WAN1) on the UDM Pro, I could ping 8.8.8.8 from 
inside the UDM Pro already. However, I still could not ping www.google.com. 
That means DNS name resolution has failed. I had to edit /etc/resolv.conf.

# vi /etc/resolv.conf
nameserver 8.8.8.8

Now I could ping www.google.com from inside the UDM Pro. Name resolution is 
working after I have modified the /etc/resolv.conf file by hand.

My client Edward Joseph Snowden then initiated the firmware upgrade using the 
web UI. After the firmware upgrade, the UDM Pro rebooted. Yes, it did reboot. I 
can confirm. The LCD screen on the UDM Pro shows that the firmware has been 
successfully upgraded to version 3.1.16. We have the screenshots to show it.

Everything is working. All the UniFi wireless access points are working. All 
the laptops and mobile phones have internet access. But another problem cropped 
up. Now we could not access the web UI of the UDM Pro.

https://192.168.2.1 of the UDM Pro (LAN IP address) is now not accessible.
https://192.168.2.254 of the UDM Pro (Port 9 (WAN1)) is also not accessible.

We could not putty (ssh) into the UDM Pro too.

May I know what the problem could be? I think there's no choice now but to 
factory reset the UDM Pro and restore configuration from the most recent 
backup. Our client says their most recent backup

Re: Debian Bookworm cannot find Nvidia graphics card

[Charles Curley]

On Sun, 3 Dec 2023 00:04:23 +
tom cullen  wrote:

> Hi, I'm having considerable trouble finding a way of making my Debian
> Bookworm (laptop) installation locate and use my laptop's Nvidia
> graphics card.
> 
> There are several 'how-tos' available online, but having tried one
> which resulted in me needing to reinstall Debian Bookworm I am
> reluctant to try any others. I am new to the Linux way of doing
> things and like your operating system very much, and gaining use of
> my laptop's full graphical power would make using your OS complete.

Have you looked at the Debian wiki write-up?
https://wiki.debian.org/NvidiaGraphicsDrivers

There are also free drivers for Nvidia cards. Others will know more
about them than I do.

If you have more question, it will help us if you identify your card
exactly. To do this, open a terminal window (I gather from what you
said that you have some graphics capability, but not all you want), and
copy and paste the following command, and run it.

lspci -nn | egrep -i "3d|display|vga"

Then copy and paste the results from the first prompt to the trailing
prompt into your email. E.g.:

charles@jhegaala:~$ lspci -nn | egrep -i "3d|display|vga"
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
charles@jhegaala:~$ 





-- 
Does anybody read signatures any more?

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

Debian Bookworm cannot find Nvidia graphics card

[tom cullen]

Hi, I'm having considerable trouble finding a way of making my Debian Bookworm 
(laptop) installation locate and use my laptop's Nvidia graphics card.

There are several 'how-tos' available online, but having tried one which 
resulted in me needing to reinstall Debian Bookworm I am reluctant to try any 
others. I am new to the Linux way of doing things and like your operating 
system very much, and gaining use of my laptop's full graphical power would 
make using your OS complete.

I would be very grateful for any assistance at all that you can provide in 
getting my Nvidia card working.

Many thanks,
Tom Cullen

Re: Help to find the Debians repository

[Marco M.]

Am 08.11.2023 um 18:34:12 Uhr schrieb ARY SAYD SAULT:

> I am reaching out to you because the team and I need to analyze the
> evolution of Debian software over the years and correlate it with
> Lehman's laws.

The tracker gives you version information: https://tracker.debian.org/

On the archive mirrors you can find older software versions:
That server includes stuff from the late 90s.
http://mirror.mephi.ru/debian-archive/debian/dists/

Re: Help to find the Debians repository

[David Christensen]

On 11/8/23 13:34, ARY SAYD SAULT wrote:

Dear Debian's Team,

I hope this email finds you well. My name is Ary I am a software 
engineering student at Catholic University of Salvador. I am reaching

out to you because the team and I need to analyze the evolution of
Debian software over the years and correlate it with Lehman's laws.
Obviously, for this type of work, we would not need to analyze all
the software since its release, just the most recent versions.

I would greatly appreciate it if you could help me and my colleagues
to find a repository where we could do this kind of analysis. If you
need any additional information from me, please let me know.

Thank you for your time and consideration. I look forward to hearing
back from you soon.

Best regards, Ary



On 11/8/23 14:05, Greg Wooledge wrote:

<https://cdimage.debian.org/mirror/cdimage/archive/>  has most of
it.



If you want source code:

https://sources.debian.org/


David

Re: Help to find the Debians repository

[Greg Wooledge]

On Wed, Nov 08, 2023 at 06:34:12PM -0300, ARY SAYD SAULT wrote:
> software over the years and correlate it with Lehman's laws. Obviously, for
> this type of work, we would not need to analyze all the software since its
> release, just the most recent versions.

 has most of it.

Help to find the Debians repository

[ARY SAYD SAULT]

Dear Debian's Team,

I hope this email finds you well. My name is Ary I am a software
engineering student at Catholic University of Salvador. I am reaching out
to you because the team and I need to analyze the evolution of Debian
software over the years and correlate it with Lehman's laws. Obviously, for
this type of work, we would not need to analyze all the software since its
release, just the most recent versions.

I would greatly appreciate it if you could help me and my colleagues to
find a repository where we could do this kind of analysis. If you need any
additional information from me, please let me know.

Thank you for your time and consideration. I look forward to hearing back
from you soon.

Best regards,
Ary

Re: how to find libreoffice is built for architecture

[Marco M.]

Am 06.11.2023 um 13:51:47 Uhr schrieb జిందం వాఐి:

> > (please tell us the OS
> > you are using).  
> * debian bookworm
> 
> * not interested with backports
> [ 7.5.6 ] or stable [ 7.4.7 ]

Then you don't need to care about sid, unstable nor experimental, only
about stable/bookworm.

Re: how to find libreoffice is built for architecture

[జిందం వాఐి]

(please tell us the OS
you are using).

* debian bookworm

* not interested with backports
[ 7.5.6 ] or stable [ 7.4.7 ]

--
regards,
జిందం వాఐి [ jindam, vani ]
[matrix]_ @jindam.vani:oikei.net

Re: how to find libreoffice is built for architecture

[Marco M.]

Am 06.11.2023 um 06:42:41 Uhr schrieb జిందం వాఐి:

> * example_ libreoffice-writer 7.6.3~rc1-2
> is not available for architectures_
> armhf, mips64el, s390x [ 1 ]
> * how to find if libreoffice-writer 7.6.3
> is available for above missing
> architectures
> 
> [ 1 ] https://packages.debian.org/experimental/libreoffice-writer

https://packages.debian.org/search?keywords=libreoffice-writer=names=stable=all

It is available for those architectures (please tell us the OS you are
using).

Be aware that experimental is a special repo for builds that aren't
tested well, so use them with caution, even on sid.

For a stable operation, I recommend using Debian stable.

how to find libreoffice is built for architecture

[జిందం వాఐి]

* example_ libreoffice-writer 7.6.3~rc1-2
is not available for architectures_
armhf, mips64el, s390x [ 1 ]
* how to find if libreoffice-writer 7.6.3
is available for above missing
architectures

[ 1 ] https://packages.debian.org/experimental/libreoffice-writer

--
regards,
జిందం వాఐి [ jindam, vani ]
[matrix]_ @jindam.vani:oikei.net

Re: linux-image-amd64: kernel fails to find all nvme SSDs

[Jeffrey Mark Siskind]

Supermicro provided a workaround: boot with the kernel command line
parameter pci=realloc=off.

As an side, Rocky 9.2 does not have this issue even though it boots
without that kernel command line parameter.

Jeff (http://engineering.purdue.edu/~qobi)

Re: linux-image-amd64: kernel fails to find all nvme SSDs

[Andy Smith]

Hi Jeff,

On Sat, Oct 14, 2023 at 05:18:52PM -0400, Jeffrey Mark Siskind wrote:
> I purchased a new server: Supermicro AS-8125GS-TNHR. It has 17 NVME
> drives installed:
> 
> 1x Micron 7450
>12x Micron 9300
> 4x Micron 9400
> 
> Upon boot, /dev/nvme* only shows 10 drives: the Micron 7450, 8 of the
> Micron 9300s, and 1 of the Micron 9400s.

It is strange that you get SOME of all of these drives. If it were
some sort of missing driver issue I'd expect an entire class of
drive to be missing.

I'm wondering if it is worth contacting Supermicro for hardware
support over this.

As there is apparently no version of a packaged Debian kernel that
works for you here, it may be even more worth using the latest
upstream kernel. If things do not work there then I'd pursue matters
with the upstream kernel community rather than Debian, as it seems
likely that the problem exists upstream and will need to be solved
upstream (assuming no actual hardware limitation).

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

linux-image-amd64: kernel fails to find all nvme SSDs

[Jeffrey Mark Siskind]

I purchased a new server: Supermicro AS-8125GS-TNHR. It has 17 NVME
drives installed:

1x Micron 7450
   12x Micron 9300
4x Micron 9400

Upon boot, /dev/nvme* only shows 10 drives: the Micron 7450, 8 of the
Micron 9300s, and 1 of the Micron 9400s. Before I plugged in the 12x
Micron 9300, /dev/nvme* only showed 2 drives: the Micron 7450 and 1 of
the Micron 9400s.

I run bookworm stable. Upon first install, it ran kernel
6.1.0-12. After an apt upgrade it ran 6.1.0-13. I also installed
6.4.0-0-deb12.2 from bookworm backports. All 3 exhibit the same
issue. the only difference is that under 6.1.0-13 the 10 drives that do
appear appear as /de/nvme{0,1,2,3,4,5,6,7,8,9} while under 6.4.0-0-deb12.2
the 10 drives that do appear appear as different numbers with some missing.

The 1x 7450 has 3 partitions: EFI, / formatted as btrfs, and swap.
The 12x 9300s are all formatted with 1 partition. There are 6 pairs of
2, Each pair has a btrfs raid1 file system. The 9400s are not yet formatted.

lspci shows all 17 drives. But only 10 show up in hwinfo.

Thanks,
Jeff (http: //engineering.purdue.edu/~qobi)

Re: How can I find packages manually installed using "dpkg -i"?

[Greg Wooledge]

On Thu, Oct 05, 2023 at 03:00:20PM +0900, John Crawley wrote:
> On 05/10/2023 13:15, David Wright wrote:
> > On Tue 03 Oct 2023 at 19:58:57 (-0700), Mike Castle wrote:
> > > (apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
> > > dpkg-query --show --showformat='${Package}\n' | grep -v -F -f
> > > apt-thinks-you-installed.txt > rest.txt
> > (I've added the omitted -f.)
> > 
> > > The file "rest.txt" should have a list of packages installed that were
> > > NOT installed via apt.  With any luck, it is small enough to examine
> > > manually.
> > 
> > I don't think your grep will work correctly. apt-thinks-you-installed.txt
> > contains patterns, and some of those patterns are very short, for example:
> > an at bc dc di gv jq mc pv tk acl ant apt bbe cpp ftp git gpg gpm kbd
> > ...
> 
> Doesn't the -F option mean grep is treating each line in 
> apt-thinks-you-installed.txt as a fixed string, not as a pattern?

Correct.  You're probably looking for -x instead of adding anchors.

Re: How can I find packages manually installed using "dpkg -i"?

[John Crawley]

On 05/10/2023 13:15, David Wright wrote:

On Tue 03 Oct 2023 at 19:58:57 (-0700), Mike Castle wrote:

(apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
dpkg-query --show --showformat='${Package}\n' | grep -v -F -f
apt-thinks-you-installed.txt > rest.txt

(I've added the omitted -f.)


The file "rest.txt" should have a list of packages installed that were
NOT installed via apt.  With any luck, it is small enough to examine
manually.


I don't think your grep will work correctly. apt-thinks-you-installed.txt
contains patterns, and some of those patterns are very short, for example:
an at bc dc di gv jq mc pv tk acl ant apt bbe cpp ftp git gpg gpm kbd
...


Doesn't the -F option mean grep is treating each line in 
apt-thinks-you-installed.txt as a fixed string, not as a pattern?

However, running the above commands here results in a short (~10) list of 
packages none of which I have installed.
dpkg-query --show --showformat='${db:Status-Abbrev} ${Package}\n' outputs a few lines 
that don't start with  "ii" like all the installed packages. I guess they need 
to be filtered out?

--
John

Re: How can I find packages manually installed using "dpkg -i"?

[David Wright]

On Tue 03 Oct 2023 at 19:58:57 (-0700), Mike Castle wrote:
> Some tools I've been using lately are apt-mark and "dpkg-query --show".
> 
> The following UNTESTED commands (ran as a normal user):
> 
> (apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
> dpkg-query --show --showformat='${Package}\n' | grep -v -F -f
> apt-thinks-you-installed.txt > rest.txt

(I've added the omitted -f.)

> The file "rest.txt" should have a list of packages installed that were
> NOT installed via apt.  With any luck, it is small enough to examine
> manually.

I don't think your grep will work correctly. apt-thinks-you-installed.txt
contains patterns, and some of those patterns are very short, for example:
an at bc dc di gv jq mc pv tk acl ant apt bbe cpp ftp git gpg gpm kbd
lz4 mbr mpv mtr pia sed sox tar tcl ucf ufw ure vim w3m xli xxd zip.
These will match packages in the dpkg-query whose names don't actually
appear as complete strings in apt-thinks-you-installed.txt. For example,
pv is in mpv, bbe is in librubberband2. "an" and "at" occur in scores
of package names.

I think you need to enclose each pattern (ie each line of
apt-thinks-you-installed.txt) in the anchors, ^ and $. Ironically,
it would be trivial to add these characters to the output of
dpkg-query, but that's not where they're needed.

Cheers,
David.

Re: How can I find packages manually installed using "dpkg -i"?

[Max Nikulin]

On 04/10/2023 09:58, Mike Castle wrote:

The following UNTESTED commands (ran as a normal user):

(apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
dpkg-query --show --showformat='${Package}\n' | grep -v -F
apt-thinks-you-installed.txt > rest.txt

The file "rest.txt" should have a list of packages installed that were
NOT installed via apt.  With any luck, it is small enough to examine
manually.


My expectation is that rest.txt contains a list of broken or removed, 
but not purged packages and an alternative way to get a similar list is


  apt list '?config-files | ?broken'

or 'apt list '~c|~b'. I wonder what is the output of

  dpkg-query --show --showformat='${Status} ${Package}\n' PKG

for any package from rest.txt that is still installed.

Re: How can I find packages manually installed using "dpkg -i"?

[Mike Castle]

Oops.  The 'grep -v -F' should be 'grep -v -f'.  Well, 'grep -v -F -f'
would probably be appropriate as well.

mrc

On Tue, Oct 3, 2023 at 7:58 PM Mike Castle  wrote:
>
> Some tools I've been using lately are apt-mark and "dpkg-query --show".
>
> The following UNTESTED commands (ran as a normal user):
>
> (apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
> dpkg-query --show --showformat='${Package}\n' | grep -v -F
> apt-thinks-you-installed.txt > rest.txt
>
> The file "rest.txt" should have a list of packages installed that were
> NOT installed via apt.  With any luck, it is small enough to examine
> manually.
>
> You could do something like "apt list" to get a list of all packages
> known by apt and see if you'd prefer to use just use the Debian
> instead of Mint versions.  And anything not in that list *probably*
> came from other manual sources and you can do what you will with that
> information.
>
> You could poke around in /var/lib/apt/lists/ and see if the files from
> the mint repos you used in the past are still there (I don't know if
> they get cleaned up or not, might get lucky).
>
>
> Regarding the comment in the thread about packages that the installer
> added that show up as manual, you can do something like the following
> to at least make apt think they were auto:
>
> dpkg-query --show --showformat='${Package} ${Priority}\n' | awk '$2 ==
> required {print $1}' > required.txt
> sudo apt-mark auto $(apt-mark showmanual | grep -F required.txt)  #
> apt-mark will prompt, so you don't want to use xargs
>
> Again, the above is untested, so verify first!
>
> You might do the same for other priorities, like  standard or
> important.  If for no other reason than breaking the list of packages
> into smaller, digestible chunks that you can focus on.  For example,
> on my machine:
> $ dpkg-query --show --showformat='${Priority}\n' | sort | uniq -c | sort -n
>   5 extra
>  29 important
>  29 standard
>  33 required
>1472 optional
>
> I could probably handle going through those smaller collections to
> identify where they came from fairly easily.  But that big optional
> collection, not so much.  For something like that, I might add
> ${Section} to the --showformat option, and divide them up that way.
>
> Also, as a future project, you might consider creating metapackages to
> help organize your installation.  Again, for my machine:
> $ apt-mark showmanual | wc -l
> 1
> $ apt-mark showauto | wc -l
> 1563
>
> I have a handful of debian control files that I use (base, desktop,
> dev, serviceX, serviceY, machine1, machine2,...).  The machine ones
> depends on the services they host (NFS, LDAP, VMs), and whether they
> need a GUI (desktop), whether I build on them (dev), or play games,
> etc.  Then each machine, after a base install I do something like:
>
> apt-mark auto $(apt-mark showmanual)
> apt install machineN
> apt autoremove --purge
>
> Of course, I monitor that autoremove to make sure it doesn't do
> anything silly, and if it tries to remove a package I missed, I go add
> it to the appropriate control file.  My simple little way of doing
> this is:
>
> $ cat doit.sh
> #!/bin/bash
>
> for v in *.control; do
>   equivs-build $v > $v.log &
> done
>
> echo 'Waiting'
> wait
> echo 'Done waiting'
>
> OUTPUT=/srv/deb/packages
> rm -rf $OUTPUT
> mkdir -p $OUTPUT
> cp *.deb $OUTPUT
> cd $OUTPUT
>
> dpkg-scanpackages . > Packages
> $ cat /etc/apt/sources.list.d/mrc-home.list
> deb [trusted=yes] file:/srv/deb/packages ./
>
> And yes, I should do better than the [trusted=yes].
>
> Good luck on your upgrade!
> mrc

Re: How can I find packages manually installed using "dpkg -i"?

[Mike Castle]

Some tools I've been using lately are apt-mark and "dpkg-query --show".

The following UNTESTED commands (ran as a normal user):

(apt-mark showauto ; apt-mark showmanual) > apt-thinks-you-installed.txt
dpkg-query --show --showformat='${Package}\n' | grep -v -F
apt-thinks-you-installed.txt > rest.txt

The file "rest.txt" should have a list of packages installed that were
NOT installed via apt.  With any luck, it is small enough to examine
manually.

You could do something like "apt list" to get a list of all packages
known by apt and see if you'd prefer to use just use the Debian
instead of Mint versions.  And anything not in that list *probably*
came from other manual sources and you can do what you will with that
information.

You could poke around in /var/lib/apt/lists/ and see if the files from
the mint repos you used in the past are still there (I don't know if
they get cleaned up or not, might get lucky).


Regarding the comment in the thread about packages that the installer
added that show up as manual, you can do something like the following
to at least make apt think they were auto:

dpkg-query --show --showformat='${Package} ${Priority}\n' | awk '$2 ==
required {print $1}' > required.txt
sudo apt-mark auto $(apt-mark showmanual | grep -F required.txt)  #
apt-mark will prompt, so you don't want to use xargs

Again, the above is untested, so verify first!

You might do the same for other priorities, like  standard or
important.  If for no other reason than breaking the list of packages
into smaller, digestible chunks that you can focus on.  For example,
on my machine:
$ dpkg-query --show --showformat='${Priority}\n' | sort | uniq -c | sort -n
  5 extra
 29 important
 29 standard
 33 required
   1472 optional

I could probably handle going through those smaller collections to
identify where they came from fairly easily.  But that big optional
collection, not so much.  For something like that, I might add
${Section} to the --showformat option, and divide them up that way.

Also, as a future project, you might consider creating metapackages to
help organize your installation.  Again, for my machine:
$ apt-mark showmanual | wc -l
1
$ apt-mark showauto | wc -l
1563

I have a handful of debian control files that I use (base, desktop,
dev, serviceX, serviceY, machine1, machine2,...).  The machine ones
depends on the services they host (NFS, LDAP, VMs), and whether they
need a GUI (desktop), whether I build on them (dev), or play games,
etc.  Then each machine, after a base install I do something like:

apt-mark auto $(apt-mark showmanual)
apt install machineN
apt autoremove --purge

Of course, I monitor that autoremove to make sure it doesn't do
anything silly, and if it tries to remove a package I missed, I go add
it to the appropriate control file.  My simple little way of doing
this is:

$ cat doit.sh
#!/bin/bash

for v in *.control; do
  equivs-build $v > $v.log &
done

echo 'Waiting'
wait
echo 'Done waiting'

OUTPUT=/srv/deb/packages
rm -rf $OUTPUT
mkdir -p $OUTPUT
cp *.deb $OUTPUT
cd $OUTPUT

dpkg-scanpackages . > Packages
$ cat /etc/apt/sources.list.d/mrc-home.list
deb [trusted=yes] file:/srv/deb/packages ./

And yes, I should do better than the [trusted=yes].

Good luck on your upgrade!
mrc

Re: How can I find packages manually installed using "dpkg -i"?

[tomas]

On Mon, Oct 02, 2023 at 11:24:04PM -0500, David Wright wrote:

[...]

> If you have complete logs and try this, presumably coming up with a
> sorted list of apt-installed packages (remembering --unique) from its
> history, and a similar list from the ' install ' lines in dpkg.log*,
> bear in mind that you need to ignore the dpkg.log until about when
> locales is installed, as APT never sees a load of packages installed
> before that point.

[...]

Very good points you make, all of them. Thanks.
> 
> Also be careful if you're tempted to sort dpkg.log's install lines
> by time, instead of grepping the logs in the correct (non-collating)
> order, because for people in the western hemisphere, the packages you
> want to ignore will have UTC timestamps, placing them in the midst
> of packages installed after the d-i has finished. (The timestamps
> jump from UTC to localtime after locales is installed.)

Eek. And as I've seen they have no time offset indicators, so
the times even can be ambiguous (winter to summer transition).
I always thought it's a bad idea to use anything else than UTC
in logs.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How can I find packages manually installed using "dpkg -i"?

[David Wright]

On Mon 02 Oct 2023 at 16:00:57 (+0200), to...@tuxteam.de wrote:
> On Mon, Oct 02, 2023 at 09:52:39AM -0400, Greg Wooledge wrote:
> > On Mon, Oct 02, 2023 at 09:43:39AM -0400, The Wanderer wrote:
> > > On 2023-10-02 at 09:28, Ottavio Caruso wrote:
> > > > Yeah, the one for which I had to manually use "dpkg -i".
> > > 
> > > That information is not tracked.
> > > 
> > > What is tracked is "the package versions known to be available from each
> > > registered repository" and "the package versions which are installed".
> > 
> > There *is* tracking.  Packages can be marked as "automatically installed"
> > or not.  The problem is, the marking is not consistent with user
> > expectations.
> 
> But not if you use dpkg directly (dpkg doesn't even resolve dependencies,
> but just gives up when some aren't met). That's why I proposed comparing
> apt logs and dpkg logs -- things in the latter but not in the former were
> probably installed with straight dpkg.
> 
> It probably ain't straightforward, though. And the logs might have been
> rotated out anyway.

If you have complete logs and try this, presumably coming up with a
sorted list of apt-installed packages (remembering --unique) from its
history, and a similar list from the ' install ' lines in dpkg.log*,
bear in mind that you need to ignore the dpkg.log until about when
locales is installed, as APT never sees a load of packages installed
before that point.

Also be careful if you're tempted to sort dpkg.log's install lines
by time, instead of grepping the logs in the correct (non-collating)
order, because for people in the western hemisphere, the packages you
want to ignore will have UTC timestamps, placing them in the midst
of packages installed after the d-i has finished. (The timestamps
jump from UTC to localtime after locales is installed.)

To avoid all these complications in future, I would suggest that the
OP (and anybody else) modify their logrotate configuration files thus:

  $ grep rotate /etc/logrotate.d/{apt,dpkg}
  /etc/logrotate.d/apt:  rotate -1
  /etc/logrotate.d/apt:  rotate -1
  /etc/logrotate.d/dpkg:  rotate -1
  $ 

and jettison  dpkg -i  in favour of:  apt install /path/to/some.deb
where the /path/to/ is essential even if it's only ./some.deb.

With those changes, it will be easy to spot these particular packages
just by grepping .deb$ (strictly, \.deb$) in …/apt/history.log*.

Cheers,
David.

Re: How can I find packages manually installed using "dpkg -i"?

[The Wanderer]

On 2023-10-02 at 09:52, Greg Wooledge wrote:

> On Mon, Oct 02, 2023 at 09:43:39AM -0400, The Wanderer wrote:
> 
>> On 2023-10-02 at 09:28, Ottavio Caruso wrote:
>> 
>>> Yeah, the one for which I had to manually use "dpkg -i".
>> 
>> That information is not tracked.
>> 
>> What is tracked is "the package versions known to be available from
>> each registered repository" and "the package versions which are
>> installed".
> 
> There *is* tracking.  Packages can be marked as "automatically
> installed" or not.  The problem is, the marking is not consistent
> with user expectations.

That does exist, yes, but it tracks "explicitly selected for
installation" vs. "installed as a dependency" - and even beyond the
problems which you note, that isn't the distinction which Ottavio
appears to be interested in.

The distinction Ottavio is interested in appears to be "installed by
'dpkg -i' from a .deb file on the command line" vs. "installed via 'apt'
or 'apt-get' from a repository". (It's not clear how "installed via
'apt' from a .deb file on the command line" would be counted for this
purpose.)

As far as I'm aware, there is no tracking of where the package entered
the local system from, which is what would be necessary in order for
something to report the information Ottavio appears to be seeking.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: How can I find packages manually installed using "dpkg -i"?

[tomas]

On Mon, Oct 02, 2023 at 09:52:39AM -0400, Greg Wooledge wrote:
> On Mon, Oct 02, 2023 at 09:43:39AM -0400, The Wanderer wrote:
> > On 2023-10-02 at 09:28, Ottavio Caruso wrote:
> > > Yeah, the one for which I had to manually use "dpkg -i".
> > 
> > That information is not tracked.
> > 
> > What is tracked is "the package versions known to be available from each
> > registered repository" and "the package versions which are installed".
> 
> There *is* tracking.  Packages can be marked as "automatically installed"
> or not.  The problem is, the marking is not consistent with user
> expectations.

But not if you use dpkg directly (dpkg doesn't even resolve dependencies,
but just gives up when some aren't met). That's why I proposed comparing
apt logs and dpkg logs -- things in the latter but not in the former were
probably installed with straight dpkg.

It probably ain't straightforward, though. And the logs might have been
rotated out anyway.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How can I find packages manually installed using "dpkg -i"?

[Greg Wooledge]

On Mon, Oct 02, 2023 at 09:43:39AM -0400, The Wanderer wrote:
> On 2023-10-02 at 09:28, Ottavio Caruso wrote:
> > Yeah, the one for which I had to manually use "dpkg -i".
> 
> That information is not tracked.
> 
> What is tracked is "the package versions known to be available from each
> registered repository" and "the package versions which are installed".

There *is* tracking.  Packages can be marked as "automatically installed"
or not.  The problem is, the marking is not consistent with user
expectations.

>From apt-patterns(7):

   ?automatic, ~M
   Selects packages that were installed automatically.

[...]

EXAMPLES
[...]
   apt list '~i !~M (~slibs|~sperl|~spython)'
   List all manually-installed packages in sections matching libs,
   perl, or python.

But if you try this locally, you'll discover that a bunch of packages
are listed which you don't expect.

unicorn:~$ apt list '~i !~M'
Listing... Done
abcde/stable,stable,now 2.9.3-1 all [installed]
acl/stable,now 2.3.1-3 amd64 [installed]
adduser/stable,stable,now 3.134 all [installed]
alsa-utils/stable,now 1.2.8-1 amd64 [installed]
an/stable,now 1.2-7+b1 amd64 [installed]
apt-listchanges/stable,stable,now 3.24 all [installed]
apt-transport-https/stable,stable,now 2.6.1 all [installed]
apt-utils/stable,now 2.6.1 amd64 [installed]
apt/stable,now 2.6.1 amd64 [installed]
aptitude/stable,now 0.8.13-5 amd64 [installed]
at/stable,now 3.2.5-1+b1 amd64 [installed]
[...]

I didn't need to install "adduser" or "apt" manually, for example, and
yet they're listed here.  As it turns out, most (or all?) of the packages
that were installed by the installer *also* show up as manually installed.
This makes it unsuitable for most people's purposes.

Re: How can I find packages manually installed using "dpkg -i"?

[The Wanderer]

On 2023-10-02 at 09:28, Ottavio Caruso wrote:

> Am 02/10/2023 um 10:12 schrieb Marco M.:
> 
>> That means it cannot be found in the currently enables repos.
>> 
>> Do you want to list such packages
> 
> Yeah, the one for which I had to manually use "dpkg -i".

That information is not tracked.

What is tracked is "the package versions known to be available from each
registered repository" and "the package versions which are installed".
Whether the package version that is installed came from one of the
registered repositories, much less whether it was installed from that
repository, is not tracked.

Unless I'm much mistaken, if you installed one package manually (i.e.,
not as a dependency) from a repository and another package locally via
'dpkg -i', the installation state of those two packages will look the
same. The system does not track anything which would let it tell you
where the package came from; at most, if the installed version of a
package is available from a currently-registered repository, it may be
able to tell you where you could get that package from again.

It's entirely probable that there is no way to identify the set of
packages you're interested in, short of a combination of manual
archaeology in local log files (and the local apt package cache) and
relying on your own memory.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: How can I find packages manually installed using "dpkg -i"?

[Marco M.]

Am 02.10.2023 um 13:28:05 Uhr schrieb Ottavio Caruso:

> Yeah, the one for which I had to manually use "dpkg -i".

I don't know a way to only show them. Every package has the attribute
"automatically installed". Every package you manually installed doesn't
have that.

Re: How can I find packages manually installed using "dpkg -i"?

[Max Nikulin]

On 02/10/2023 17:05, Ottavio Caruso wrote:

Before you say:

$ apt list '?narrow(?installed, ?not(?origin(Debian)))'

The problem with that is there are packages that I added from the Linux 
Mint repos (not manually) and that I want to keep and they all have the 
tag "local". For example:


mintmenu/now 6.1.5 all [installed,local]
mintreport/now 1.3.5 all [installed,local]
mintsources/now 2.1.9 all [installed,local]


Apt does not store in its DB from which sources particular packages were 
installed. Filters are based on presence of packages in currently 
configured repositories. See apt-patterns(7) for various available 
options such as ~M for automatically installed packages. I would try


   apt list '~o!~M'

To get list of local manually installed packages. If the number of them 
is not high you may remove them and then run


apt autoremove --purge

Notice that packages from non-standard repositories may break upgrade 
due to their dependencies.

Re: How can I find packages manually installed using "dpkg -i"?

[tomas]

On Mon, Oct 02, 2023 at 10:05:46AM +, Ottavio Caruso wrote:
> I want to upgrade Bullseye to Bookworm and I want to remove all packages
> that I installed manually, downloading the .debs
>  and then using "dpkg -i".

[...]

If you're lucky, /var/log/dpkg.log in combination with one or both of
/var/log/apt/history.log and/or /var/log/apt/term.log and some elbow
grease (or some creative scripting) might help.

> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

How true. However, people who need to understand this are most
likely to not read that far :-(

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How can I find packages manually installed using "dpkg -i"?

[Marco M.]

Am 02.10.2023 um 10:05:46 Uhr schrieb Ottavio Caruso:

> Before you say:
> 
> $ apt list '?narrow(?installed, ?not(?origin(Debian)))'
> 
> The problem with that is there are packages that I added from the
> Linux Mint repos (not manually) and that I want to keep and they all
> have the tag "local". For example:
> 
> mintmenu/now 6.1.5 all [installed,local]
> mintreport/now 1.3.5 all [installed,local]
> mintsources/now 2.1.9 all [installed,local]

That means it cannot be found in the currently enables repos.

Do you want to list such packages or the packages that are listed as
manually installed (and not automatically because another package
depends on them)?

Re: dangling symlinks [ was: Re: "locate" easier to use than "find"]

[tomas]

On Sun, Aug 27, 2023 at 02:17:06PM -0400, Jeffrey Walton wrote:

[...]

> The symlink tool works great, too:
> 
> symlink -r / | grep dangling
> 
> You can also delete them, once you verify they are dangling:
> 
> symlink -r -d /
> 
> In fact, it is a recommended post-upgrade step for Fedora. See
> .
> 
> (I'm not arguing with you. I'm just responding to the title change).

Keep those arguments coming :-)

No, seriously. We're in here for learning. I didn't even know about
`symlink'. On the contrary: the more tools in the shop, the merrier.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: dangling symlinks [ was: Re: "locate" easier to use than "find"]

[Jeffrey Walton]

On Sun, Aug 27, 2023 at 1:10 PM Jörg-Volker Peetz  wrote:
>
> to...@tuxteam.de wrote on 24/08/2023 14:00:
> >
> > A couple of days ago I was searching for dangling symlinks.
> >
> >find . -follow -lname "*"
> >
> How about
> find -L . -type l

The symlink tool works great, too:

symlink -r / | grep dangling

You can also delete them, once you verify they are dangling:

symlink -r -d /

In fact, it is a recommended post-upgrade step for Fedora. See
<https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/#sect-clean-up-old-symlinks>.

(I'm not arguing with you. I'm just responding to the title change).

Jeff

Re: dangling symlinks [ was: Re: "locate" easier to use than "find"]

[tomas]

On Sun, Aug 27, 2023 at 07:09:36PM +0200, Jörg-Volker Peetz wrote:
> to...@tuxteam.de wrote on 24/08/2023 14:00:
> > 
> > A couple of days ago I was searching for dangling symlinks.
> > 
> >find . -follow -lname "*"
> > 
> How about
>find -L . -type l

Should work, too.

Cheers
-- 
t


signature.asc
Description: PGP signature

dangling symlinks [ was: Re: "locate" easier to use than "find"]

[Jörg-Volker Peetz]

to...@tuxteam.de wrote on 24/08/2023 14:00:


A couple of days ago I was searching for dangling symlinks.

   find . -follow -lname "*"


How about
   find -L . -type l

Regards,
Jörg.

Re: "locate" easier to use than "find"

[Greg Wooledge]

> > to...@tuxteam.de (12023-08-24):
> > > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > > grep" doesn't cover a fraction of its usefulness.
> > >
> > > A couple of days ago I was searching for dangling symlinks.
> > >
> > >   find . -follow -lname "*"

Wow... what a cryptic pair of options this is.  From the man page:

   -L Follow symbolic links.  When find examines or prints information
[...]
Using  -L  causes the -lname and -ilname
predicates always to return false.

And:

   The -follow option has a similar effect to -L, though it  takes  effect
   at  the  point where it appears (that is, if -L is not used but -follow
   is, any symbolic links appearing after -follow on the command line will
   be dereferenced, and those before it will not).

And:

   -follow
  Deprecated; use the -L  option  instead.   Dereference  symbolic
  links.   Implies -noleaf.  The -follow option affects only those
  tests which appear after it on the command line.  Unless the  -H
  or -L option has been specified, the position of the -follow op‐
  tion changes the behaviour of the -newer  predicate;  any  files
  listed  as  the  argument of -newer will be dereferenced if they
  are symbolic links.  The same consideration applies to -newerXY,
  -anewer and -cnewer.  Similarly, the -type predicate will always
  match against the type of the file that a symbolic  link  points
  to rather than the link itself.  Using -follow causes the -lname
  and -ilname predicates always to return false.

And:

   -lname pattern
  File is a symbolic link whose contents match shell pattern  pat‐
  tern.  The metacharacters do not treat `/' or `.' specially.  If
  the -L option or the -follow option is in effect, this test  re‐
  turns false unless the symbolic link is broken.

So that's two votes for "this can't possibly work" and one vote for
the opposite.  From within the same manual.  Yikes.

(And the POSIX manual doesn't help here, because -lname is a GNU extension.)

Re: "locate" easier to use than "find"

[Nicolas George]

Stanislav Vlasov (12023-08-24):
> Sometimes it's unexpected :-)

Then the shell prints an error and I try again. Still less time wasted
than these two mails.

Regards,

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[Stanislav Vlasov]

чт, 24 авг. 2023 г. в 18:17, Nicolas George :

> > With a really large amount of files there will be overflow of process
> > environment (or too large cmdline).

> If I expect a very large amount of files, I can use it another way.

Sometimes it's unexpected :-)

-- 
Stanislav

Re: "locate" easier to use than "find"

[tomas]

On Thu, Aug 24, 2023 at 02:05:48PM +0200, Nicolas George wrote:
> to...@tuxteam.de (12023-08-24):
> > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > grep" doesn't cover a fraction of its usefulness.
> > 
> > A couple of days ago I was searching for dangling symlinks.
> > 
> >   find . -follow -lname "*"
> 
> ls **/*(N@-@)
> 
> Zsh rulz.

Definitely. My point was rather to illustrate the kind of things
find can do that locate can't.

There is more than one way to do it (TM).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[Nicolas George]

Stanislav Vlasov (12023-08-24):
> With a really large amount of files there will be overflow of process
> environment (or too large cmdline).

If I expect a very large amount of files, I can use it another way.

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[Stanislav Vlasov]

чт, 24 авг. 2023 г. в 17:06, Nicolas George :
>
> to...@tuxteam.de (12023-08-24):
> > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > grep" doesn't cover a fraction of its usefulness.
> >
> > A couple of days ago I was searching for dangling symlinks.
> >
> >   find . -follow -lname "*"
>
> ls **/*(N@-@)

With a really large amount of files there will be overflow of process
environment (or too large cmdline).
locate and find does not store filenames in memory.

-- 
Stanislav

Re: "locate" easier to use than "find"

[Nicolas George]

to...@tuxteam.de (12023-08-24):
> Dunno. I use find nearly every day. Seeing it as "just a recursive
> grep" doesn't cover a fraction of its usefulness.
> 
> A couple of days ago I was searching for dangling symlinks.
> 
>   find . -follow -lname "*"

ls **/*(N@-@)

Zsh rulz.

Regards,

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[tomas]

On Thu, Aug 24, 2023 at 01:52:28PM +0200, Oliver Schoede wrote:

[...]

> Have basically stopped using traditional 'find' outside of scripts, as
> always thought I was about the last one [...]

Dunno. I use find nearly every day. Seeing it as "just a recursive
grep" doesn't cover a fraction of its usefulness.

A couple of days ago I was searching for dangling symlinks.

  find . -follow -lname "*"

did the trick.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[Oliver Schoede]

On Mon, 21 Aug 2023 15:56:11 +0200
 wrote:

>On Mon, Aug 21, 2023 at 03:19:19PM +0200, Roger Price wrote:
>> On Mon, 21 Aug 2023, Hans wrote:
>> 
>> > find .mozilla -name favicons.sqlite -ls
>> >  1512492   2144 -rw-r--r--   1 myusername myusernama  2195456 Aug
>> > 21 13:29 .mozilla/firefox/gs0gkgv2.default/favicons.sqlite 1515049
>> >    260 -rw-r--r--   1 myusername myusername   262144 Aug 18 22:36
>> > .mozilla/firefox/th3dv2jy.default-1461749950404/favicons.sqlite
>> 
>> For me command "locate" is easier to use than "find":
>
>They do different things. Locate is much faster, but it only looks
>into file names. Find can do nearly everything, like looking into
>file metadata ("show me all files younger than 12 days" or "owned
>by www-data"), running external programs (e.g. grep), yadda, yadda.
>
>To each job its tool.
>
>Cheers

Have basically stopped using traditional 'find' outside of scripts, as
always thought I was about the last one. Replaced with 'fd-find' which
really is simpler/more intuitive, sometimes actually faster. Quite
typical case where ~20% of the functionality will be doing the trick
90% of the time, in less time, and to me that already looks more like
99%. Especially on single user systems. I'm feeling rather more sorry
to say it's the same with 'ag', better known as the silversearcher,
another one of those long-serving workhorses that by the way is slated
for being dropped from Debian in just a couple of days: no longer
maintained, long dead upstream. I've used it for heavy grepping about
everywhere and for so many years. Most obvious replacement in this case
apparently 'ripgrep', also Rust of course. Has a few more edges I find
a little weird but got comfortable in a matter of a days anyhow. It's
all similar enough, about the hardest part is getting the actual
commands right: never a big fan of aliases I still regularly type
'find' instead of 'fd', it's muscle memory. ;)

Meanwhile traditional (m)locate got itself replaced with plocate, it
wasn't always that fast! Old things go, new arrive, I'm still using
bash though. Sorry for going off on another tangent. If anyone is still
using 'ag', just consider the options. And yes, GNU 'find' is
overcomplicated, I've long made do with a couple of shell functions
just to fight the repetition.


Oliver

Re: "locate" easier to use than "find"

[tomas]

On Mon, Aug 21, 2023 at 06:45:16PM +0100, Brian wrote:

[...]

> plocate-updatedb.service and plocate-updatedb.timer take care of
> that for me. :)

I admit to accepting some help from trusty cron :)

> > Tools, jobs and that :)
> 
> Indeed.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[mick.crane]

On 2023-08-21 17:21, to...@tuxteam.de wrote:

On Mon, Aug 21, 2023 at 02:50:07PM +, Michael Kjörling wrote:

On 21 Aug 2023 15:56 +0200, from to...@tuxteam.de:
>> For me command "locate" is easier to use than "find":
>
> They do different things. Locate is much faster, but it only looks
> into file names. Find can do nearly everything, like looking into
> file metadata ("show me all files younger than 12 days" or "owned
> by www-data"), running external programs (e.g. grep), yadda, yadda.

Another downside of locate is that it relies on its database being up
to date.

Depending on what you're trying to do, they may both be equally
useful, or one may be far more useful than the other.


Don't get me wrong. I /do/ use both, and take care that the locate
database is up-to-date.

Tools, jobs and that :)


When you imagine what it must be doing is amazing how quick updatedb is.

mick

Re: "locate" easier to use than "find"

[tomas]

On Mon, Aug 21, 2023 at 02:50:07PM +, Michael Kjörling wrote:
> On 21 Aug 2023 15:56 +0200, from to...@tuxteam.de:
> >> For me command "locate" is easier to use than "find":
> > 
> > They do different things. Locate is much faster, but it only looks
> > into file names. Find can do nearly everything, like looking into
> > file metadata ("show me all files younger than 12 days" or "owned
> > by www-data"), running external programs (e.g. grep), yadda, yadda.
> 
> Another downside of locate is that it relies on its database being up
> to date.
> 
> Depending on what you're trying to do, they may both be equally
> useful, or one may be far more useful than the other.

Don't get me wrong. I /do/ use both, and take care that the locate
database is up-to-date.

Tools, jobs and that :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[Michael Kjörling]

On 21 Aug 2023 15:56 +0200, from to...@tuxteam.de:
>> For me command "locate" is easier to use than "find":
> 
> They do different things. Locate is much faster, but it only looks
> into file names. Find can do nearly everything, like looking into
> file metadata ("show me all files younger than 12 days" or "owned
> by www-data"), running external programs (e.g. grep), yadda, yadda.

Another downside of locate is that it relies on its database being up
to date.

Depending on what you're trying to do, they may both be equally
useful, or one may be far more useful than the other.

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

Re: "locate" easier to use than "find"

[tomas]

On Mon, Aug 21, 2023 at 03:19:19PM +0200, Roger Price wrote:
> On Mon, 21 Aug 2023, Hans wrote:
> 
> > find .mozilla -name favicons.sqlite -ls
> >  1512492   2144 -rw-r--r--   1 myusername myusernama  2195456 Aug 21 13:29 
> > .mozilla/firefox/gs0gkgv2.default/favicons.sqlite
> >  1515049    260 -rw-r--r--   1 myusername myusername   262144 Aug 18 22:36 
> > .mozilla/firefox/th3dv2jy.default-1461749950404/favicons.sqlite
> 
> For me command "locate" is easier to use than "find":

They do different things. Locate is much faster, but it only looks
into file names. Find can do nearly everything, like looking into
file metadata ("show me all files younger than 12 days" or "owned
by www-data"), running external programs (e.g. grep), yadda, yadda.

To each job its tool.

Cheers
-- 
t


signature.asc
Description: PGP signature

"locate" easier to use than "find"

[Roger Price]

On Mon, 21 Aug 2023, Hans wrote:


find .mozilla -name favicons.sqlite -ls
 1512492   2144 -rw-r--r--   1 myusername myusernama  2195456 Aug 21 13:29 
.mozilla/firefox/gs0gkgv2.default/favicons.sqlite
 1515049    260 -rw-r--r--   1 myusername myusername   262144 Aug 18 22:36 
.mozilla/firefox/th3dv2jy.default-1461749950404/favicons.sqlite


For me command "locate" is easier to use than "find":

rprice@titan ~ locate favicons.sqlite
/mnt/home/rprice/.mozilla/firefox/60mahk24.default-esr/favicons.sqlite
/mnt/home/rprice/.mozilla/firefox/60mahk24.default-esr/favicons.sqlite-wal
/mnt/home/rprice/.mozilla/firefox/sehco4n9.default/favicons.sqlite
/mnt/home/rprice/.mozilla/firefox/sehco4n9.default/favicons.sqlite-shm
/mnt/home/rprice/.mozilla/firefox/sehco4n9.default/favicons.sqlite-wal
rprice@titan ~ inxi -S
System: Host: titan Kernel: 5.10.0-15-amd64 x86_64 bits: 64 Desktop: Xfce 
4.16.0 Distro: Debian GNU/Linux 11 (bullseye)

Roger

Re: how to find out regdomain/country of wifi network

[David Wright]

On Tue 16 May 2023 at 11:38:27 (+0200), Vincent Lefevre wrote:
> On 2023-05-15 23:14:30 -0500, David Wright wrote:
> > On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> > > On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > > > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > > > Under Debian/unstable, i.e. more much recent than stretch:
> > > > > 
> > > > > zira:~> dpkg -s net-tools
> > > > > Package: net-tools
> > > > > Status: install ok installed
> > > > > Priority: important
> > > > > [...]
> > > > > 
> > > > > This is still priority important!
> > > > 
> > > > Not at all; AFAICT, the /internal/ Priority of the package has never
> > > > changed.
> > > 
> > > But this is what the user sees.
> > > 
> > > > (Just guessing: if you installed it, you need it, and better
> > > > hang on to it.)
> > > 
> > > Wrong. It got installed automatically. I suppose that this is because
> > > this was like that in the past, when I installed the machine in 2015,
> > > thus before stretch was out.
> > 
> > Of course, how stupid of me—I should have known that from your post
> > about a system running sid (quoted above in its entirety).
> 
> Well, you should never try to guess, unless the guess is obvious.

Well, excuse me, but are you the moderator here? I shall answer
posts in the manner I find appropriate, if you don't mind (and
even if you do).

> BTW, I don't think that sid matters here; just the fact that the
> machine was installed before stretch and that there is a current
> dependency.

Neither of which was mentioned in your post. Does anything in your
post actually matter? It it does, wouldn't it be better to file a
bug against the net-tools control file, rather than spending your
time criticising the fact that I had the temerity to write this
aside in a post:

 "(Just guessing: if you installed it, you need it, and better hang on to it.)"

Cheers,
David.

Re: how to find out regdomain/country of wifi network

[Anssi Saari]

hl  writes:

> i try old  FreeBSD-12.4, accept default FCC/US though i am not in US,
> wifi scan succeeds

Is it out of the question to actually set the regulatory domain to match
the country you're in?

Re: how to find out regdomain/country of wifi network

[Vincent Lefevre]

On 2023-05-15 23:14:30 -0500, David Wright wrote:
> On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> > On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > > Under Debian/unstable, i.e. more much recent than stretch:
> > > > 
> > > > zira:~> dpkg -s net-tools
> > > > Package: net-tools
> > > > Status: install ok installed
> > > > Priority: important
> > > > [...]
> > > > 
> > > > This is still priority important!
> > > 
> > > Not at all; AFAICT, the /internal/ Priority of the package has never
> > > changed.
> > 
> > But this is what the user sees.
> > 
> > > (Just guessing: if you installed it, you need it, and better
> > > hang on to it.)
> > 
> > Wrong. It got installed automatically. I suppose that this is because
> > this was like that in the past, when I installed the machine in 2015,
> > thus before stretch was out.
> 
> Of course, how stupid of me—I should have known that from your post
> about a system running sid (quoted above in its entirety).

Well, you should never try to guess, unless the guess is obvious.
BTW, I don't think that sid matters here; just the fact that the
machine was installed before stretch and that there is a current
dependency.

> > I suspect that it wasn't removed because
> > of the remaining "Recommends" from pbuilder:
> > 
> > zira:~> aptitude why net-tools
> > i   pbuilder Recommends net-tools | iproute2
> > 
> > Note: iproute2 is installed too, but net-tools gets the preference.
> > This "Recommends" is rather strange if iproute2 is supposed to be
> > better!
> 
> That's a very odd recommendation: it's difficult to envisage someone
> building packages on a system that doesn't have all the packages with
> Priority important already installed.

I suppose that this may be useful in case the priority is lowered
in the future.

> And I haven't seen where any ranking should be understood from
> the ordering of Recommends alternatives.
> 
> And AIUI   aptitude why   picks an arbitrary choice from equally
> strong dependencies (sensu lato). There may be others present.

I don't know whether this lists all the dependencies (but the
man page uses the plural):

zira:~> deborphan net-tools
net-tools
  pbuilder

And this one should give all of them:

zira:~> apt list '?any-version(?installed?depends(?exact-name(net-tools)))'
Listing... Done
zira:~> apt list '?any-version(?installed?recommends(?exact-name(net-tools)))'
Listing... Done
pbuilder/stable,testing,unstable,now 0.231 all [installed]

> You say your system is pre-stretch, ie jessie.

Indeed, it was installed from

  
http://cdimage.debian.org/debian-cd/8.1.0/amd64/jigdo-dvd/debian-8.1.0-amd64-DVD-1.jigdo

with just "SSH server" and "standard system utilities" in the
installer choices. I upgraded to sid shortly after.

> That means that you will have had both iproute2 and net-tools
> installed, as in jessie they are both ranked important.

Yes, both were installed at install time.

> As far as net-tools's survival is concerned, that's up to you.
> Debian gives you some tools to help remove cruft, but aggressive
> removal from systems could lead to scripts breaking and so on,
> particularly where there are Recommends in play.

I used some net-tools utilities, mainly ifconfig, in the past (on
older machines), but I no longer have any script that depends on
them, and I don't think that this is an issue for pbuilder as the
other ORed recommends will be satisfied.

However, a comment in /etc/postfix/main.cf.proto still mentions
"ifconfig" only (it appears that the corresponding sentence in
the postconf(5) man page was updated, but not this file):

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

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

Re: how to find out regdomain/country of wifi network

[David Wright]

On Mon 15 May 2023 at 16:38:29 (+0200), Vincent Lefevre wrote:
> On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > On Mon 15 May 2023 at 12:51:55 (+0200), Vincent Lefevre wrote:
> > > Under Debian/unstable, i.e. more much recent than stretch:
> > > 
> > > zira:~> dpkg -s net-tools
> > > Package: net-tools
> > > Status: install ok installed
> > > Priority: important
> > > [...]
> > > 
> > > This is still priority important!
> > 
> > Not at all; AFAICT, the /internal/ Priority of the package has never
> > changed.
> 
> But this is what the user sees.
> 
> > (Just guessing: if you installed it, you need it, and better
> > hang on to it.)
> 
> Wrong. It got installed automatically. I suppose that this is because
> this was like that in the past, when I installed the machine in 2015,
> thus before stretch was out.

Of course, how stupid of me—I should have known that from your post
about a system running sid (quoted above in its entirety).

> I suspect that it wasn't removed because
> of the remaining "Recommends" from pbuilder:
> 
> zira:~> aptitude why net-tools
> i   pbuilder Recommends net-tools | iproute2
> 
> Note: iproute2 is installed too, but net-tools gets the preference.
> This "Recommends" is rather strange if iproute2 is supposed to be
> better!

That's a very odd recommendation: it's difficult to envisage someone
building packages on a system that doesn't have all the packages with
Priority important already installed.

And I haven't seen where any ranking should be understood from
the ordering of Recommends alternatives.

And AIUI   aptitude why   picks an arbitrary choice from equally
strong dependencies (sensu lato). There may be others present.

You say your system is pre-stretch, ie jessie. That means that you
will have had both iproute2 and net-tools installed, as in jessie
they are both ranked important. AFAICT iproute2 has never been
ranked lower than that, and its predecessor, iproute, was important
as far back as lenny. (Earlier than that, it could only be optional,
because you needed various options to have been compiled into the
kernel.)

As far as net-tools's survival is concerned, that's up to you.
Debian gives you some tools to help remove cruft, but aggressive
removal from systems could lead to scripts breaking and so on,
particularly where there are Recommends in play.

Cheers,
David.

Re: how to find out regdomain/country of wifi network

[Celejar]

On Sat, 13 May 2023 20:29:11 +0200
 wrote:

> On Sat, May 13, 2023 at 01:01:27PM -0500, Nicholas Geovanis wrote:
> > On Sat, May 13, 2023, 5:23 AM Jeremy Ardley  wrote:
> > 
> > >
> > > On 13/5/23 18:17, Nicolas George wrote:
> > > > This is your interpretation, not an official stance. It might as well be
> > > > that they considered polluting the completion namespace of users with a
> > > > command they rarely need was less convenient.
> > >
> > > The actual reason is they have deprecated it in favour of the ip command
> > > but left it available for now with a bit of searching.
> > >
> > 
> > Ifconfig has been deprecated in Debian for some years.
> 
> It is *not* deprecated. It is just optional, not essential. As is the
> Gnu C compiler or Lua or... you name it. If you need it, you install
> it. It is in stable (version 1.60), coming in testing (v 2.10) and is
> in unstable. It is not going away, folks!

We can quibble about the term "deprecated," but the official Debian
Reference Manual repeatedly calls it "obsolete":

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html

-- 
Celejar

Re: how to find out regdomain/country of wifi network

[Greg Wooledge]

On Mon, May 15, 2023 at 12:00:36PM -0400, gene heskett wrote:
> On 5/15/23 07:03, Greg Wooledge wrote:
> > On Mon, May 15, 2023 at 12:10:13AM -0500, David Wright wrote:
> > > I read somewhere that the recent tweaks (improvements?) to
> > > ifconfig's output were breaking scripts, which is hardly surprising.
> > 
> > I can personally confirm this as true.  Some of the machines at work
> > run a proprietary software product that uses a license key, tied to
> > the machine's ethernet interface's MAC address.  The vendor's script
> > runs ifconfig and tries to parse the output to get the MAC address.
> > This script fails on the recent versions of net-tools.
> > 
> > .
> One might be able to fix that with hexedit or a clone, by changing the
[...]

Thanks, but I don't require any assistance with this.  I simply told
the vendor what the correct IP address and MAC address are.  (They're
a small company, and we have direct contact with them.)

I was simply confirming that yes, the changes to net-tools did in fact
break some real-world scripts.

Re: how to find out regdomain/country of wifi network

[Jeffrey Walton]

On Mon, May 15, 2023 at 12:01 PM gene heskett  wrote:
> [...]
> The point is that what can be done in software, can also be undone.

I spent a lot of time on Fravia's site back in the 1990's. There was
no protection scheme we couldn't break. Or I don't recall one.

https://en.wikipedia.org/wiki/Fravia

Jeff

Re: how to find out regdomain/country of wifi network

[gene heskett]

On 5/15/23 07:03, Greg Wooledge wrote:

On Mon, May 15, 2023 at 12:10:13AM -0500, David Wright wrote:

I read somewhere that the recent tweaks (improvements?) to
ifconfig's output were breaking scripts, which is hardly surprising.


I can personally confirm this as true.  Some of the machines at work
run a proprietary software product that uses a license key, tied to
the machine's ethernet interface's MAC address.  The vendor's script
runs ifconfig and tries to parse the output to get the MAC address.
This script fails on the recent versions of net-tools.

.
One might be able to fix that with hexedit or a clone, by changing the 
string causing the error back to the original version? Fix the files crc 
of course.  Better yet, dl the src, find that string and change it back 
to the original, recompile and re-install. I note that today. neither 
tool calls the MAC address MAC, and that ip and ifconfig label it with 
different names. That s/b a std but insert the xckb reference to std's, 
old even wrong ones never die...


This method of software protection, from my experience as broadcast 
engineer, can be costly when it fails, and fixing what you paid good 
money for in the faith that it would work forever but fails regularly 
for whatever reason. And our copyright laws do not contain that I know 
of, a provision to allow the possession of a canceled check to be 
substituted for whatever scheme the vendor comes up with to enforce his 
copyright.  Disney got exactly what he asked for.


We at one time in the early 90's bought an editing system that had the 
key buried in the serial port adapter that was used to control the tape 
machines.  With a limited life. The outfit was able to supply a new 
adaptor, once, but had to drive the height of FL to get it from the 
author of the scheme.  And it was his only copy. Lasted about a month 
and once again we had $25,000 worth of disabled software.


In a tv stations production dept, that's a major income hit. At that 
time I knew a uni prof in germany who was pretty good at fixing buggy 
amiga software, so w/o naming names I told the vendor it was not going 
to be tuff excrement to us but to them, but that I would remove their 
broken key and continue to use the software we had paid good money for 6 
months earlier.  Lots of sputtering, I hung up in the middle of it and 
emailed the sw to the prof, had it back with a try this about 6 hours 
later but he missed a third check, so had to go back and search thru it 
again, finding the last check and nulling it out.  We used the hacked 
version for about a year, till we upgraded the editing machines and 
never heard from that vendor again. I heard later thru the grapevine 
that the vendor filed shortly after that.  The hacked copy never left 
the premises so as far as I was concerned the copyright was honored.


The point is that what can be done in software, can also be undone.

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 <http://geneslinuxbox.net:6309/>

Re: how to find out regdomain/country of wifi network

[Andy Smith]

Hello,

On Mon, May 15, 2023 at 05:15:58PM +0200, Vincent Lefevre wrote:
> On 2023-05-15 17:13:31 +0200, Vincent Lefevre wrote:
> > No, aptitude removes automatically installed packages for which
> > there are no longer any dependencies.
> 
> And there's also "apt autoremove", which I also use. The issue
> for net-tools is that there is still a dependency (Recommends)
> from pbuilder.

Ah okay, my mistake. I only ever use the "aptitude why" part of
aptitude.

"Recommends" are quite liberally used on Debian so I expect that
will account for net-tools being retained in a lot of cases.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: how to find out regdomain/country of wifi network

[Vincent Lefevre]

On 2023-05-15 17:13:31 +0200, Vincent Lefevre wrote:
> On 2023-05-15 15:09:24 +, Andy Smith wrote:
> > On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> > > Wrong. It got installed automatically. I suppose that this is because
> > > this was like that in the past, when I installed the machine in 2015,
> > > thus before stretch was out.
> > 
> > If you mean that it got installed automatically in an older install,
> > before the package was made optional, and then never removed, this
> > would make sense as things don't get removed on upgrades unless
> > there is a conflict. You even retain packages that are no longer in
> > Debian.
> 
> No, aptitude removes automatically installed packages for which
> there are no longer any dependencies.

And there's also "apt autoremove", which I also use. The issue
for net-tools is that there is still a dependency (Recommends)
from pbuilder.

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

Re: how to find out regdomain/country of wifi network

[Vincent Lefevre]

On 2023-05-15 15:09:24 +, Andy Smith wrote:
> On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> > Wrong. It got installed automatically. I suppose that this is because
> > this was like that in the past, when I installed the machine in 2015,
> > thus before stretch was out.
> 
> If you mean that it got installed automatically in an older install,
> before the package was made optional, and then never removed, this
> would make sense as things don't get removed on upgrades unless
> there is a conflict. You even retain packages that are no longer in
> Debian.

No, aptitude removes automatically installed packages for which
there are no longer any dependencies.

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

Re: how to find out regdomain/country of wifi network

[Andy Smith]

Hello,

On Mon, May 15, 2023 at 04:38:29PM +0200, Vincent Lefevre wrote:
> On 2023-05-15 08:36:41 -0500, David Wright wrote:
> > (Just guessing: if you installed it, you need it, and better
> > hang on to it.)
> 
> Wrong. It got installed automatically. I suppose that this is because
> this was like that in the past, when I installed the machine in 2015,
> thus before stretch was out.

If you mean that it got installed automatically in an older install,
before the package was made optional, and then never removed, this
would make sense as things don't get removed on upgrades unless
there is a conflict. You even retain packages that are no longer in
Debian.

Most of my long-upgraded systems still have it, but newer installs
don't.

Some of my third party (i.e. not on my own hypervisor) bullseye VMs
have it because they have cloud-init, which in bullseye depends on
net-tools. Even though I don't use cloud-init. I see that in
bookworm cloud-init no longer depends upon net-tools, so there's
another route to install gone.

I'm sure there's still a lot of cases where it's pulled in as a
possible dependency but never knowingly used.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting