Re: Reading an old HDD

2024-10-03 Thread David Wright
On Thu 03 Oct 2024 at 20:26:55 (-0700), Will Mengarini wrote:
> The old HDD is mostly ext3; there was also an
> ext2 boot partition, and a swap partition.  But
> the new Debian shows nothing new in `df`.  Is
> there some other command I should use to probe for
> whether Debian knows there's a HDD connected by USB?

Take a look at /dev/disk/… where the names of the next level
of directories are self-explanatory. The files themselves
are all symlinks pointing to the kernel's device names.

Also /run/udev/data/b… where spinning rust disks are b8:N,
and N is a power of two for a disk, then N+1, N+2 etc for
the partitions. SSDs will be some other number like, say,
b259:0. The file contents are what udev has discovered.

Cheers,
David.



Re: Which subdirectory for a usedr-specific executable?

2024-10-03 Thread David Wright
On Thu 03 Oct 2024 at 08:31:08 (-0500), Richard Owlett wrote:
> On 10/03/2024 08:03 AM, Jerome BENOIT wrote:
> > On 03/10/2024 14:51, Richard Owlett wrote:
> > > Is there standard/recommended location for an executable to be
> > > used by only a one user?
> > > In my case it should be under /home/richard/ .
> > > But where?
> > 
> > the /etc/skel/.profile add to PATH ~/bin and ~/.local/bin if they exist.
> 
> That answers a slightly different question.
> For my specific case I wish to avoid the use of PATH.
> [adding details will only cause confusion]

Then obviously you should put it anywhere /except/ in one of those two
directories, so that it /won't/ be included in your PATH.

Cheers,
David.



Re: Finding/creating Debian documentation for an unserved audience

2024-09-26 Thread David Wright
On Mon 23 Sep 2024 at 06:31:21 (-0500), Richard Owlett wrote:
> A primary deficiency of Debian documentation is lack of indexes
> [despite having file titles of form index.html ].
> [q.v. 
> https://differencesfinder.com/index-vs-table-of-contents-key-differences-explained/
> ]

AIUI index.html is just a conventional name for the landing page
when you demand a domainname or directory without any filename.

As for indexes, well, that takes work, so who's going to do it?
People make a living as freelance indexers.

OTOH, logically, TOCs write themselves as part of the process of
designing a document, and physically, they should be easy to generate
from chapter/section headings, while it is processed for publication.

> My current goal to multi-boot my primary machine without clobbering
> existing valuable data (even if that data has been backed-up).
> 
> *A* current question is how to install a "dual-boot" or "multi-boot"
> system. Debian users make a strong distinction between the two.

I don't see any defining difference between the two terms (beyond
obviously not using the former where there are more than two
installations).

Cheers,
David.



Re: boot Debian Gnome, Debian KDE, and Mate, XFCE

2024-09-26 Thread David Wright
On Thu 26 Sep 2024 at 09:52:18 (+0100), Joe wrote:
> On Thu, 26 Sep 2024 07:19:26 +1000 George at Clug wrote:
> > On Wednesday, 25-09-2024 at 12:37 Max Nikulin wrote:
> > > On 25/09/2024 04:52, George at Clug wrote:  
> > > > An other example would be to boot Debian Gnome, Debian KDE, and
> > > > Debian Mate, Debian XFCE.  
> > > 
> 
> > 
> > > Display managers allow to 
> > > select session type before login (but some can not remember
> > > per-user preferences).  
> > 
> > Using a different display manager is not the same as using a
> > different installation.
> > 
> No, for that you need multi-boot.
> 
> But to compare Gnome, KDE etc. you would be staying within one
> installation and using the display manager to switch between desktop
> environments, which is what these things are. You could also compare
> with other environments such as window managers, but generally only
> heavy professional users find it convenient to eliminate the desktop
> environments, such as you mention (also LXDE and Cinnamon).
> 
> If you look around your login screen, it may not be obvious, but there
> should be a way to select different types of session. Even with a
> default Debian installation you should find a session control widget in
> the top right corner of the screen while the login box is shown, though
> it will only contain the desktop you selected on installation. But you
> can install others, and they will appear on this session menu.

Is it safe to assume that the environment a sole DE gives you is the
same as the environment when you've switched to that DE from running
several others, or even when other DEs are installed on the system?
Particularly (but sticking with Debian) in the context of:

> > > > For example if I could do this I would be able to test
> > > > various GUIs or distributions for applications/games
> > > > using the same hardware and gauge performance.

Also, do DEs ever disagree over how they use their dotfiles?

Cheers,
David.



Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

2024-09-22 Thread David Wright
On Sat 21 Sep 2024 at 07:03:58 (-0500), Richard Owlett wrote:
> On 09/20/2024 10:57 AM, David Wright wrote:
> > On Fri 20 Sep 2024 at 07:53:28 (-0500), Richard Owlett wrote:
> > > On 09/19/2024 10:04 AM, David Wright wrote:
> > > > On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:
> > > > > Is the AMD64 version of "Debian GNU/Linux Installation Guide"
> > > > > available as a single file.
> > > > > 
> > > > > I need it available when the network is not.
> > > > > 
> > > > > It would be convenient if a copy of the menus appearing when
> > > > > installing from DVD1 were available.
> > > > 
> > > > Have you tried googling:
> > > > 
> > > > debian stable installation guide pdf amd64
> > > > 
> > > > which should lead you to:
> > > > 
> > > > https://www.debian.org/releases/stable/amd64/install.en.pdf
> > > 
> > > No ;}
> > > For two primary  reasons:
> > > 1. due to vision/perception problems I avoid PDF in favor of HTML.
> > > SeaMonkey simplifies consistent font size across documents.
> > > 2. My work style uses tabs to group (and save across restarts)
> > > related references conveniently.
> > > 
> > > Secondarily, for those preferring PDF, in my use of SeaMonkey since
> > > days of Squeeze I never noticed mention of its documentation being
> > > available as PDF.
> > 
> > The PDF is ~650kB, but for ~17MB you can get all three formats
> > (PDF/text/HTML) as one file (in the sense it seems you mean) in
> > the Debian package installation-guide-amd64.
> 
> As you didn't give a URL, I went to
> https://html.duckduckgo.com/html?q=%22Debian%22%20%22package%22%20%22installation-guide-amd64%22

URLs aren't a sensible way to refer to Debian packages amongst Debian
users, as we all have the APT tools to locate/download/install them.

> That did not link to "all three formats (PDF/text/HTML) as one file"
> available to one who does not have Debian already installed.

If it linked to a .deb file, then technically that's not true, as .deb
files are just two compressed tar archives (.xz, formerly .gz IIRC)
in an ar archive. But I don't follow why that's of particular concern.

> 1st hit  of "Details of package installation-guide-amd64 in bullseye"
> prompted travel in right direction.
> 
> I've been using Debian since Squeeze. I have never been pointed to
> [ /usr/share/doc ] nor [ /usr/share/doc-base ]. The latter contains
> the "Installation Guide" as uncompressed HTML filed. PDF&text versions
> are there in compressed format.

Since ~woody, and taken here from squeeze's Installation Guide §7.3:

 "Documentation accompanying programs you have installed
  can be found in /usr/share/doc/, un-
  der a subdirectory named after the program (or, more
  precise, the Debian package that contains the
  program). However, more extensive documentation is
  often packaged separately in special documen-
  tation packages that are mostly not installed by
  default. For example, documentation about the pack-
  age management tool apt can be found in the
  packages apt-doc or apt-howto.

 "In addition, there are some special folders within
  the /usr/share/doc/ hierarchy. Linux HOWTOs
  are installed in .gz (compressed) format, in
  /usr/share/doc/HOWTO/en-txt/. After installing
  dhelp, you will find a browsable index of
  documentation in /usr/share/doc/HTML/index.html."

> > Using tabs isn't affected by whether the HTML code itself is in
> > a "single" file or a tree.
> 
> My mention of tabs was to point out why PDF was not useful.

I could expand my mention of tabs to include that you can have
multiple browser tabs showing different parts of one PDF file
in the same way as you can with an HTML file.

> > > Because I'm doing a "from scratch" install for the first time in
> > > several years, I said:
> > > > It would be convenient if a copy of the menus appearing when installing
> > > > from DVD1 were available.
> > 
> > Sorry, I would have thought you could recite them from memory by now :)
> 
> Tell me that with a straight face when you pass 80 ;)!
> [I haven't seen that set of screens in at least 5 years.]

I recalled a "SUCESSFUL INSTALL" [sic] status report from May 2022,
and also thought you had restarted installing about 3 months ago.
Perhaps I was assuming too much.

On Sun 22 Sep 2024 at 06:16:53 (-0500), Richard Owlett wrote:
> On 09/19/2024 09:16 AM, Richard Owlett wrote:
> > Is the A

Re: [SOLVED] Re: How add key of 3rd party repo?

2024-09-22 Thread David Wright
Am Sonntag, 22. September 2024, 19:05:35 CEST schrieb Charles Curley:
> When you do these things, *exactly* what results do you get? Copy and
> paste the entire command line, including the prompt, the results, and
> the next command line prompt.

[ … ]

On Sun 22 Sep 2024 at 20:01:02 (+0200), Hans wrote:
> But I found the reason! 
> 
> The eys are set "rw- --- ---", so they could not read.
> 
> This adds another problem: Looks like gpg or sq is setting wrong rights. 
> 
> Several minutes ago I discovered another issue: /usr/bin/dpkg was set 
> to "rwx r-- r--", what is also wrong. As I did not change this, it must have 
> been changed by some upgrade. Had this issue already in 2014 (with a 
> mediathekview problem, same reason), 
> 
> I suppose, we can safely close this. Thanks for your help, again laerned 
> something.

From the clues left dotted around, my bet is that you've messed up
your system with the way you become root, affecting its umask.

A couple of months ago (and back in 2020), you were exhorting Debian
to set a mask for users of at least 027, and I'm wondering whether,
in your case, it might have been changed to 077 since around one of
those times.

Back in 2014, you had the permissions on dpkg set to -rwxr-x---,
which would correspond to a umask of 027, so perhaps you had already
tightened your system from the Debian default, 022, to 027 by then.

So it now comes down to why system components are getting the user's
umask applied to them. For that, I looked back to 2014 when you seemed
to be a bit more forthcoming with pasting prompts into your posts.
Your first post in the thread¹ starts with:

| Ok, so let’s start as root:
| 
| su -p
| root@protheus2:~# LANG=C mediathekview 

Well, three cases of su are:

  ~$ umask
  0027← the securer default was set for this user.
  ~$ su
  Password: 
  /home/auser# umask
  0022← correct
  /home/auser# 
  exit
  ~$ su -
  Password: 
  ~# umask
  0022← correct
  ~# 
  logout
  ~$ su -p
  Password: 
  ~# umask
  0027← wrong for root
  ~# 
  exit
  ~$ 

So I'm guessing that you've been installing things after having become
root with -p. I don't know whether APT and dpkg can themselves modify
any excessively restrictive umask, and I'm unwilling to test that here.

¹ https://lists.debian.org/debian-user/2014/07/msg00053.html

Cheers,
David.



Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

2024-09-20 Thread David Wright
On Fri 20 Sep 2024 at 07:53:28 (-0500), Richard Owlett wrote:
> On 09/19/2024 10:04 AM, David Wright wrote:
> > On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:
> > > Is the AMD64 version of "Debian GNU/Linux Installation Guide"
> > > available as a single file.
> > > 
> > > I need it available when the network is not.
> > > 
> > > It would be convenient if a copy of the menus appearing when
> > > installing from DVD1 were available.
> > 
> > Have you tried googling:
> > 
> >debian stable installation guide pdf amd64
> > 
> > which should lead you to:
> > 
> >https://www.debian.org/releases/stable/amd64/install.en.pdf
> 
> No ;}
> For two primary  reasons:
> 1. due to vision/perception problems I avoid PDF in favor of HTML.
>SeaMonkey simplifies consistent font size across documents.
> 2. My work style uses tabs to group (and save across restarts)
>related references conveniently.
> 
> Secondarily, for those preferring PDF, in my use of SeaMonkey since
> days of Squeeze I never noticed mention of its documentation being
> available as PDF.

The PDF is ~650kB, but for ~17MB you can get all three formats
(PDF/text/HTML) as one file (in the sense it seems you mean) in
the Debian package installation-guide-amd64.

Using tabs isn't affected by whether the HTML code itself is in
a "single" file or a tree.

> Because I'm doing a "from scratch" install for the first time in
> several years, I said:
> > It would be convenient if a copy of the menus appearing when installing
> > from DVD1 were available.

Sorry, I would have thought you could recite them from memory by now :)

> I recall most of what has to be accomplished but am hazy on some
> details. So I went looking at https://www.debian.org/ from a "newbie"
> point of view. ~Nada:{
> Drilling down leads to https://www.debian.org/do_c/ which first points

FTR remove the "_".

> our possibly non-geek newbie to "Installation Guide" and "Debian
> GNU/Linux FAQ" which, though brimming with facts, are inconveniently
> organized.

Oh dear, I thought that was how the Installation Guide had been
organised since the days of yore.

> *HOWEVER* there is something _NEW_ on the page!
> Who, me, excited ;}
> There is now something called _The Debian Bookworm beginner’s
> handbook_ [
> https://debian-beginners-handbook.tuxfamily.org/index-en.html ].
> For reasons stated above I'll be using the HTML more than the PDF.
> 
> This resource should be linked to on https://www.debian.org/ or at
> most down only one level.

I don't think it makes sense to promote this above the two you've
already mentioned.

> I addresses some of my questions, though it only mentions others.
> I'll be doing a lot of reading this weekend.

If you like it. I prefer the detail of the other two, and it now
sounds as if you might.

> One question. There are two HTML versions. What's difference between
> the_beginners_handbook.html and the_beginners_handbook_night.html ?

It should be as clear as night and day from the very start of each,
but:

  $ diff -U0 the*/the* > diff (attached)

Cheers,
David.
--- the_beginners_handbook/the_beginners_handbook.html  2024-08-30 
11:57:09.0 -0500
+++ the_beginners_handbook/the_beginners_handbook_night.html2024-08-30 
11:57:09.0 -0500
@@ -15 +15 @@
-background-color: #fafafa;
+background-color: #2F343F;
@@ -22 +22 @@
-color: #222;
+color: #D4D4D4;
@@ -28 +28 @@
-color: #005885;
+color: #0077B4;
@@ -33 +33 @@
-border-bottom: 1px dotted #005885;
+border-bottom: 1px dotted #0077B4;
@@ -61 +61 @@
-figure img {box-shadow: 0 0 3px 1px rgba(0, 0, 0, .2);}
+figure img {box-shadow: 0 0 3px 1px rgba(255, 255, 255, .2);}
@@ -92,3 +92,3 @@
-color: #111;
-background-color: #f4fbff;
-border: 1px solid #333;
+color: #ccc;
+background-color: #000;
+border: 1px solid #ccc;
@@ -105 +105,2 @@
-background-color: #eee;
+border: 1px solid #ccc;
+background-color: #222;
@@ -147 +148 @@
-
+


Re: Copying installer ISO to USB Flash

2024-09-20 Thread David Wright
On Fri 20 Sep 2024 at 09:52:32 (-0500), Richard Owlett wrote:
> Having machines with different constraints I have downloaded DVD1 and
> Netinst ISO's. I have flash drives with obsolete ISO's. For reference
> I have [ https://www.debian.org/CD/faq/#write-usb ] available.
> 
> Questions:
> 1. Do the flash drives require any prep?
>[ Gparted gives warning messages on both. ]

(It wouldn't do to say what about, of course.)

No. If you're about to copy onto them, then only a decision that
want to trash their current contents.

Your preparation might include removing other plugins to reduce the
ambiguity of /dev/sdX.

> 2. I've casually followed recent discussion on appropriate dd options.
>What was the conclusion?
>What was the subject line {i have local copies}?

It contained "amd64-netinst.iso. That should add to your reading
this weekend :)
(How do you search your local copies?)

Conclusion: old school — dd, new school — cp.

> 3. Not having done a "from scratch" install recently, is there something
>I haven't thought to ask?

Doubtless you'll think of something after the weekend.

Cheers,
David.



Re: Availability of "Debian GNU/Linux Installation Guide" for OFFLINE use

2024-09-19 Thread David Wright
On Thu 19 Sep 2024 at 09:16:25 (-0500), Richard Owlett wrote:
> Is the AMD64 version of "Debian GNU/Linux Installation Guide"
> available as a single file.
> 
> I need it available when the network is not.
> 
> It would be convenient if a copy of the menus appearing when
> installing from DVD1 were available.

Have you tried googling:

  debian stable installation guide pdf amd64

which should lead you to:

  https://www.debian.org/releases/stable/amd64/install.en.pdf

Cheers,
David.



Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

2024-09-16 Thread David Wright
On Fri 13 Sep 2024 at 15:00:14 (+0300), Anssi Saari wrote:
> David Wright  writes:
> > On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
> 
> >> Why do you think that? Which part of the fsync manpage explicitly covers
> >> fsync's effect on device files? Share share, it's fair.
> 
> >  “fsync() transfers ("flushes") all modified in-core data of (i.e.,
> >   modified buffer cache pages for) the file referred to by the file
> >   descriptor fd to the disk device (or other permanent storage device)
> >   so that all changed information can be retrieved even after the
> >   system crashed or was rebooted. This includes writing through or
> >   flushing a disk cache if present. The call blocks until the device
> >   reports that the transfer has completed. It also flushes metadata
> >   information associated with the file (see stat(2)).”
> 
> You just parroted a man page I had already read. Why did you think
> that'd be helpful?

Um, because you asked me too, above.

> I asked the questions because the man page didn't
> answer my questions. As you are apparemntly unable I found for example
> https://unix.stackexchange.com/questions/473854/block-device-cache-v-s-a-filesystem

I see that I looked at that page back in May 2021 (the page has been
updated since then), when the list had a previous conversation on dd,
partly about blocksize, but in which we were told that we were only
meant to be using dd with tapes or when converting, say, EBCDIC to
ASCII, or whatever.

I've yet to find another tool that can give you progress when already
in progess.

I had landed on a different page from the above this time around,
  https://stackoverflow.com/questions/58276098/fsync-with-raw-device-fd
but I couldn't determine a definitive answer there. There still seems
to be some disagreement in this thread.

> and so arrived to the conclusion that the final close(2) call on a block
> device already flushes all buffers before returning. So the answer to
> the question "is running sync needed after dd to block device" is
> no. Someone else posted that too on this list recently, in another
> thread.

Well, if you knew that already, you could have just posted your view
rather than "Share share, it's fair".

Of course, we all know that the time it takes to add  ;sync
to a command line is hardly going to delay you more than a
suitably sized choice of blocksize, so much of this discussion
is moot in practical terms.

Cheers,
David.



Re: Really ancient debian images? (potato or older)

2024-09-16 Thread David Wright
On Sun 15 Sep 2024 at 12:08:29 (+0200), Anders Andersson wrote:
> On Sun, Sep 15, 2024 at 7:59 AM  wrote:
> > On Sat, Sep 14, 2024 at 10:27:01PM +0200, Christian Groessler wrote:
> >
> > [...]
> >
> > > Now for the main question: Why do you need ancient Debian?
> >
> > Was in the original post: "This is to build some ancient software."
> >
> > (I've been in a similar situation myself)
> 
> Just have to add a "me too". Often a piece of software that hasn't
> been maintained for 20 years or so fails to compile, or the support
> scripts are using tools no longer available etc. It's way easier to
> FIRST make it work on the environment it was designed for, and then
> gradually fix whatever prevents it from being built with modern tools.
> 
> I feel that this is one of the key strengths using free software.
> While you can probably easily find old CDs with Windows 2000, and MAY
> find old CDs with the popular development tools at the time, it may be
> very difficult getting it to run legally (if you care) and just pray
> that you don't need a non-existing dongle.

Or that you have the dongle, but now have to find a parallel port
to plug it into.

> I'm very happy that debian offers even really ancient versions.

Cheers,
David.



Re: BIOS unreadable at boot

2024-09-16 Thread David Wright
On Sun 15 Sep 2024 at 23:45:42 (-0700), Will Mengarini wrote:
> Felix Miata  [24-09/15=Sun 22:01 -0400]:
> > F12 should get you the Gigabyte BBS menu.
> 
> Something happens when I press , but I can't
> tell what, because I can't read the screen, because
> it is out of sync, using an unsupported resolution.

> I'm getting into BIOS setup but can't tell where to go from there
> because I can't read the monitor to tell what keys I should press.

The F12 menu might be a simple list, in which case you could try
typing blind:

  F12 wait Return
  F12 wait DownArrow Return
  F12 wait DownArrow DownArrow Return
  F12 wait DownArrow DownArrow DownArrow Return

etc., and in case the F12 screen does not point to the first item:

  F12 wait UpArrow Return

etc.

Cheers,
David.



Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

2024-09-10 Thread David Wright
On Tue 10 Sep 2024 at 11:56:25 (+0300), Anssi Saari wrote:
> David Wright  writes:
> > On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
> >> David Christensen  writes:
> >> 
> >> > 2.  sync(1) is unnecessary.
> >> 
> >> Does it even do anything wrt device files? sync(2) says "sync() causes
> >> all pending modifications to filesystem metadata and cached file data to
> >> be written to the underlying filesystems."
> >
> > I think you also need to read the other manpage, fsync(2).
> 
> Why do you think that? Which part of the fsync manpage explicitly covers
> fsync's effect on device files? Share share, it's fair.

 “fsync() transfers ("flushes") all modified in-core data of (i.e.,
  modified buffer cache pages for) the file referred to by the file
  descriptor fd to the disk device (or other permanent storage device)
  so that all changed information can be retrieved even after the
  system crashed or was rebooted. This includes writing through or
  flushing a disk cache if present. The call blocks until the device
  reports that the transfer has completed. It also flushes metadata
  information associated with the file (see stat(2)).”

as in fsync(2)'s Description, as opposed to sync(2)'s Bugs:

 “According to the standard specification (e.g., POSIX.1-2001), sync()
  schedules the writes, but may return before the actual writing is
  done. However, since version 1.3.20 Linux does actually wait. (This
  still does not guarantee data integrity: modern disks have large
  caches.)”

Cheers,
David.



Re: hibernate area

2024-09-10 Thread David Wright
On Tue 10 Sep 2024 at 19:14:54 (+), Andy Smith wrote:
> Hi,
> 
> On Tue, Sep 10, 2024 at 02:53:01PM -0400, Stefan Monnier wrote:
> > > I have an NVME drive as well as a spinning-rust drive.  I've got swap on 
> > > the
> > > spinning drive, but I'd like to put the hibernate area on the NVME.  Is 
> > > that
> > > possible, to have swap on one and hibernate on another?
> > 
> > Of course.  Just tell your hibernation about the partition you want to
> > use for it (it usually defaults to using the swap partition).
> > IIRC the relevant file is `/etc/suspend.conf`.
> 
> So, I think this just sets the resume= etc on the kernel command
> line and I had thought that this only tells the kernel where to
> resume *from*, not where to hibernate *to*. However I have not
> tested that, and it seems that it might indeed also set where it
> hibernates to as long as you first boot with that command line in
> place:
> 
> 
> https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Manually_specify_hibernate_location
> 
> Has anyone tried this?

No, but https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html
says that "resume=
[SWSUSP]
Specify the partition device for software suspend
 
Format:
{/dev/ | PARTUUID= | : | }"

Cheers,
David.



Re: tab completion being overenthusiastic

2024-09-09 Thread David Wright
On Sat 07 Sep 2024 at 09:58:32 (-0400), e...@gmx.us wrote:
> Got it.  It was in ~/.bash-vars which was sourced from ~/.bash_profile .  Is
> that a standard thing, or just some "brilliant" idea I had once upon a time?

If you mean the file itself, you might try   stat ~/.bash-vars
and looking at the Birth date; then you could check out your
Sent Mail folder and see whether you were discussing anything
relevant around that time. Other places that might help are
your browser's history, and the index for debian-user.

Cheers,
David.



Re: Disk drive zero-fill benchmarks for various synchronization methods and block sizes

2024-09-09 Thread David Wright
On Mon 09 Sep 2024 at 11:52:19 (+0300), Anssi Saari wrote:
> David Christensen  writes:
> 
> > 2.  sync(1) is unnecessary.
> 
> Does it even do anything wrt device files? sync(2) says "sync() causes
> all pending modifications to filesystem metadata and cached file data to
> be written to the underlying filesystems."

I think you also need to read the other manpage, fsync(2).

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-09-02 Thread David Wright
On Mon 02 Sep 2024 at 11:16:53 (-0400), Michael Stone wrote:
> On Sun, Sep 01, 2024 at 09:58:22AM -0500, David Wright wrote:
> > > On Sat, Aug 31, 2024 at 09:59:47PM -0500, David Wright wrote:
> > > > On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
> > > > > On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
> > > > > >
> > > > > > What does a "debian ... amd64-netinst.iso" do
> > > > > > with an .iso?
> > > > > >
> > > > > > Can it be coverted to a USB. How?
> > > > >
> > > > > https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
> > > > >
> > > > > # cp debian.iso /dev/sdX
> > > >
> > > > The disadvantage of this method is how to check the USB has a good copy.
> > > 
> > > I don't understand why it would be any harder or easier to check that
> > > there's a good copy with cp vs some other tool, so this seems like
> > > strange advice.
> > 
> > So your command line would read …
> 
> What are you even going on about?

Well, I might expect you to use a command something like:

  # dd bs=1M if=/dev/sdX of=/dev/stdout count=N | sha512sum

to check for a good copy. And yet you seem awfully keen to
avoid using dd because of its alleged "cargo cult voodoo",
whatever that is, and because apparently you can screw it up
with typos (what, in "dd", "bs", "if" and "of"?). But about the
only method I've seen to check the copy is good is to use dd.

If you've copied the file with dd, you don't even have to type
half of the checking command because of command history. And
you don't have to calculate the count of blocks to check
because dd has just told you that.

That's leaving aside the fact that if copying (or checking) is
taking a suspiciously long time, you can ascertain dd's progress
even when you didn't ask for progress in the command line.

Like you, I can't see the point of using dcfldd. Its man page
advertises that it can verify the target drive, but that doesn't
work for this particular application. And ddrescue seems to be
another program that's pointless for this use. As for cp, I don't
see any particular benefit, and a disadvantage is that it's mute.

Sorry if I tried your patience. (BTW I am subscribed.)

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-09-01 Thread David Wright
On Sun 01 Sep 2024 at 17:20:41 (+0200), Hans wrote:
> > So your command line would read …
> > 
> >   # … …
> 
> I believe, instead of using dd for copying to the usb-stick, one might want 
> to 
> use dcfldd for it.
> 
> dcfldd is en enhanced version of dd with hashsum check during copy. It was 
> created for forensic matters, where no data may have gone lost.

Same response: please write me a command line, but in this case
for writing the stick rather than just checking it.

  # … …

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-09-01 Thread David Wright
> On Sat, Aug 31, 2024 at 09:59:47PM -0500, David Wright wrote:
> > On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
> > > On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
> > > >
> > > > What does a "debian ... amd64-netinst.iso" do
> > > > with an .iso?
> > > >
> > > > Can it be coverted to a USB. How?
> > > 
> > > https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
> > > 
> > > # cp debian.iso /dev/sdX
> > 
> > The disadvantage of this method is how to check the USB has a good copy.
> 
> I don't understand why it would be any harder or easier to check that
> there's a good copy with cp vs some other tool, so this seems like
> strange advice.

So your command line would read …

  # … …

Cheers,
David.



Re: need help killing screen blanker

2024-09-01 Thread David Wright
On Sun 01 Sep 2024 at 01:05:21 (-0400), gene heskett wrote:
> On 8/31/24 22:58, David Wright wrote:
> > And so should we assume Gene's report that he needs to actually login
> > again after the screen locks itself is likely caused by confusing the
> > unlocking screen with a login screen? Being DE-less, I haven't seen
> > either screen, and am unable to make a judgment, but several webpages
> > mentioned that confusion.
> 
> Picking nits David, the effect is exactly the same, plus 2-4 seconds
> to actually restore the screen to the linuxcnc control gui. Presumably
> the pi has to pull the gui back out of swap or cache, which is
> potentially dangerous which is reason enough to disable it forever. I
> have not gotten around to moving that stuff to a much faster SSD on a
> USB3 interface. Even a 128GB u-sd is slower by far.

AIUI there's a range of behaviours that the Power Manager controls,
things like blanking, standby, screensaver programs, monitor-off and
locking, amongst others.

What I haven't seen unambiguously mentioned is forced logoff, and
I can't see a reason why there necessarily would be, because I think
of forced logoff as something used when a resource is in contention;
like when there were 1000+ dumb teminals in a university connected
to a front-end that could handle, say, 250 simultaneous logins.

So if the behaviour you report /is/ actually locking, and not logoff,
you are saved the business of wondering whether there's still a
feature that your Power Manager settings haven't allowed you to
control and that you've got to find.

When I was driving a travelling stage around, underneath a laser and an
optical microscope, I didn't worry about screen blanking because in an
emergency, I could hit any active key before I'd even noticed whether
the screen was black or not. Understand, the monitor was fully powered
up, but the phosphor wasn't glowing. Under normal conditions, I'd
unblank the screen with Ctrl, as that didn't send any action to the
programs running: these programs were completely unaware that the
screen was blanked.

Of course, you should test whether the same is true for the Power
Manager settings you choose, and retest after any upgrades, but
I understand that never blanking anything may be your preference.

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-08-31 Thread David Wright
On Sat 31 Aug 2024 at 15:20:46 (-0700), David Christensen wrote:
> On 8/30/24 20:48, John Conover wrote:
> > What does a "debian ... amd64-netinst.iso" do
> > with an .iso?
> 
> When I input that string into a computer running Debian, it produces
> an error message:
> 
> 2024-08-31 13:07:57 dpchrist@laalaa ~
> $ echo $PS1 ; cat /etc/debian_version ; uname -a
> \n\D{%Y-%m-%d %H:%M:%S} ${USER}@\h \w\n\$
> 11.10
> Linux laalaa 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10)
> x86_64 GNU/Linux
> 
> 2024-08-31 13:17:14 dpchrist@laalaa ~
> $ debian ... amd64-netinst.iso
> bash: debian: command not found

The string "..." is an ellipsis. This one stands for the version number
in any particular ISO file's name.

You can use "…" for an ellipsis in unicode, but it's tedious to insert
it unless you have a Compose sequence set up for it. I suspect most
people don't.

I define it as 'Compose..' myself, and use it a lot to save space.

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-08-31 Thread David Wright
On Sat 31 Aug 2024 at 14:09:45 (-0400), Lee wrote:
> On Sat, Aug 31, 2024 at 1:31 AM John Conover wrote:
> >
> > What does a "debian ... amd64-netinst.iso" do
> > with an .iso?
> >
> > Can it be coverted to a USB. How?
> 
> https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html
> 
> # cp debian.iso /dev/sdX

The disadvantage of this method is how to check the USB has a good copy.

Cheers,
David.



Re: need help killing screen blanker

2024-08-31 Thread David Wright
On Sat 31 Aug 2024 at 18:01:59 (+1000), George at Clug wrote:
> On Wednesday, 28-08-2024 at 11:31 Trish Fraser wrote:
> > >On 8/26/24 13:27, Trish Fraser wrote:
> > >> 
> > >>> S, what do I remove to absolutely, permanently disable the
> > >>> screen blanker? And I mean no chance it can ever do that to me
> > >>> again.
> > >> 
> > >> Seems like, in XFCE, you need to go into settings and disable the
> > >> screensaver.
> 
> If this helps anyone, my comment is:  I don't use screensavers
> either, so as described above, in XFCE's Power Manager, Display tab, I
> set 'Blank after' to 'Never', 'Put to sleep after' to 'Never', 'Switch
> off after' to 'Never, and then I select the "Display power management"
> slider to off.
> 
> In XFCE's Session and Startup, General tab, I unchecked "Lock screen
> before sleep".
> 
> I cannot remember making any other changes that are relevant to screen
> savers or power management.
> 
> I made these settings a year or so go, I have not had need to reapply
> these settings (after updates or power off/on), and my screen does not
> go blank while I am using my computer, my two monitors just continue
> to show my linux screens.

And so should we assume Gene's report that he needs to actually login
again after the screen locks itself is likely caused by confusing the
unlocking screen with a login screen? Being DE-less, I haven't seen
either screen, and am unable to make a judgment, but several webpages
mentioned that confusion.

Cheers,
David.



Re: Usage: "debian ... amd64-netinst.iso"

2024-08-30 Thread David Wright
On Fri 30 Aug 2024 at 20:48:38 (-0700), John Conover wrote:
> 
> What does a "debian ... amd64-netinst.iso" do
> with an .iso?
> 
> Can it be coverted to a USB. How?

I plug in a USB stick (which will get completely overwritten),
check from the logs what its device name is (/dev/sdX),
then, as root, execute:
  # dd bs=1M if=debian…amd64-netinst.iso of=/dev/sdX
  # sync
and wait for the prompt after the sync command.
I then remove the stick and reinsert it, so that the next
step can't cheat and read some cache. I now execute:
  # dd bs=1M if=/dev/sdX of=/dev/stdout count=N | sha512sum
where N is the number of blocks written by the first command.
The output should correspond to what's in the SHA512SUMS file
(found in the same directory as the .iso file) if it's a good copy.

The critical step is making sure that you write to the
correct device, of course.

Cheers,
David.



Re: need help killing screen blanker

2024-08-30 Thread David Wright
On Wed 28 Aug 2024 at 11:13:16 (-0400), gene heskett wrote⁰:
> On 8/27/24 21:03, David Wright wrote:
> > On Mon 26 Aug 2024 at 15:42:56 (-0400), Felix Miata wrote:
> > > David Wright composed on 2024-08-26 14:36 (UTC-0400):
> > > 
> > > > ¹ touch Ctrl, the key at the extreme bottom left of the keyboard,
> > > >to defeat it.
> > > Are you sure?
> > 
> > Well, all four of the laptops in this house, the previous two we
> > disposed of, and all the assorted keybords I've acquired over the
> > last twenty years or so
> 
> My last lappy was disposed of 10 years ago. The touchpad interface was
> the least of its problems.
> 
> > But finding the safest key to use may be irrelevant if Gene doesn't
> > trust even basic screen blanking to occur (see above).
> > 
> Sorry but you don't understand the problem David. I could be killed
> while trying to log back into it, and the 30 seconds it takes to login
> again, when I could stop it with one keypress w/o that damned blanker.

It's very difficult to communicate with you about the various screen
behaviours when you only seem able to use the one term, "blanker".

Blanking the screen is something that linux has done as far back as
I can remember. It has absolutely no effect on your pressing one key,
because unlike with Windows, that keystroke, which unblanks the screen,
is not thrown away, but treated as normal, as if the screen hadn't
been blank at all.

But, as I wrote above, I don't think you will even tolerate the screen
blanking in that, or any other manner, so discussion of an aside about
keyboard layout is not something I thought anyone would raise, nor
that you would want to engage in.

So cut to the chase: you're interested in preventing screen /locking/
and/or forced logout. And yet you entirely ignored the greater part
of my post, which was on that topic.

> > On Tue 27 Aug 2024 at 14:58:14 (-0400), gene heskett wrote:
> > > On 8/26/24 14:37, David Wright wrote:
> > > > On Mon 26 Aug 2024 at 10:29:10 (-0400), gene heskett wrote:
> > > > > xfce4 desktop, running linuxcnc, [ … ]
> > > > > came across a dangerous situation yesterday.
> > > > > 
> > > > > Basically using the lathe as a jig to hold a long piece I was tapping
> > > > > by hand, powered up but stopped. screen blanker came on and locked me
> > > > > out till I logged back in leaving linuxcnc live but hidden behind a
> > > > > black screen.  This is a dangerous condition if he wrong key is hit to
> > > > > wake it up.
> > > > 
> > > > Surely it's not screen /blanking/ that's your problem¹ but screen
> > > > /locking/. BTW were you really logging back in, or just unlocking
> > > > the session?
> > > 
> > > total login to get back to my session.
> > 
> > How did you distinguish between the two cases?
> > 
> > > > > That monitor AND the idling rpi4b draw about 22 watts, and is turned
> > > > > off only for maintenance.  UPS, standby generator, uptimes might be
> > > > > years.
> > > > > 
> > > > > Replacing a CRT power hungry monitor means the only reason to blank a
> > > > > screen
> > > > 
> > > > tomas mentioned xset, which should deal with that. You need to decide
> > > > on whether a couple of seconds is too long to wait for recovery from
> > > > anything more than simple blanking.
> > > If the machine starts, while trying to wake it up and log back in to
> > > get control back to me, its already 5 seconds too damned late. With
> > > the pi, wakeup time is 5 + seconds by which time a sleeve caught on a
> > > chuck jaw has already tried to rip an arm off.
> > 
> > Agreed, but my paragraph was distinguishing between simple blanking
> > and powersaving. (Of course you don't want to be typing a password.)
> > 
> > In the past, I found the instant recovery from blanking (with no
> > powersaving) was quite satisfactory, while preventing burn-in from
> > being run 24/7. (This was in a lab with restricted access.)
> > 
> > > > > and interpose a login is security against prying eyes in an
> > > > > office environment.
> > > > 
> > > > That's the troublesome one for you.
> > > 
> > > Absolutely. This is not an office environment. The path thru this
> > > garage is hardly wide enough for me, let alone company.
> > 
> > There are plenty of google hits on this topic, some posted by peopl

Re: Is anybody maintaining nedit?

2024-08-29 Thread David Wright
On Tue 27 Aug 2024 at 18:16:13 (-0700), Van Snyder wrote:
> On Tue, 2024-08-27 at 20:01 -0500, David Wright wrote:
> > Which key is Compose?
> 
> I've gone to KDE System Settings => Keyboard => Advanced => Position of
> compose key and selected the right-ALT key.
> 
> > In nedit, does it do whatever is engraved on it, or whatever the
> 
> Highlight something with left drag, then left-ALT middle drag exchanges
> them
> 
> Doing it with right-ALT just replaces the left-drag selection with the
> middle-drag selection

Might a different Compose key survive running nedit, for example
CapsLock or Pause, which are fairly useless keys. (I use CapsLock.)
I can't imagine nedit rebinding them.

Cheers,
David.



Re: tbird hot keys.

2024-08-29 Thread David Wright
On Sun 25 Aug 2024 at 10:10:21 (-0400), gene heskett wrote:

> > So "some" shortcuts can be [...] disabled, but it doesn't tell you
> > how. But maybe if there is a particular hotkey that's causing a
> > problem, someone else might have had the same problem and written
> > an add-on you can look for?
> 
> Well, i'll be typing along, have most assuredly not done a ctl+a, but
> all the text will high light, and the next keystroke deletes it all.
> Sometimes I can recover with some undo's.  Or the message goes away,
> and half an hour later I notice there is an unsent msg in the outbox,
> and it might be the disappeared msg, but not always. About 50% of the
> time it might be a resurrection/read msg dated months ago.  This
> problem has survived 3 keyboards(this particular one is wired [ … ]

One course of action would be to use an add-on like exteditor,
by which you can use an editor of choice for composing your emails.
Obviously an editor without this SelectAll hotkey facility would be
preferable, like emacs for example. I wonder whether it would let
you use gedit (emails are always small files) or geany, which
I think you've used in the past.

[PS to Gene: just wondered whether you meant to reply only to
me on the subject of screen locking, rather than to the list]

Cheers,
David.



Re: Which tool for upgrade in commandline?

2024-08-27 Thread David Wright
On Tue 27 Aug 2024 at 20:32:04 (+0100), Joe wrote:
> On Tue, 27 Aug 2024 21:03:02 +0200 Hans wrote:

> > First, we have the oldest, whcih is apt-get.
> > apt-get update, apt-get upgrade or apt-get full-upgrade does a good
> > job.

> > So, my question is: Which one is recommended, when updating and
> > upgrading is used in a script, so that it causes as little as
> > possible pain?
> > 
> > It means: When the script is not eecuted daily, but let us say, every
> > two weeks, and we have lots of packages.
> > 
> > At the moment I am using aptitude, this works great in short periods,
> > but after al longer time, it crashes, because some dependencies could
> > not resolve. 
> > 
> > Independent of my personal use: Which one is recommended?

For scripts, apt-get has the advantage that it doesn't get changed
from release to release, but always behaves the same way.

> I believe apt is currently recommended. Having said that, sometimes the
> upgrade notes for a new Stable recommend using a particular tool, and
> obviously you would go with that advice. I seem to recall that apt will
> not just use one of the earlier upgrade tools, but will do a bit of
> tidying up afterwards. With the earlier tools, the package cache has to
> be manually cleared periodically.

For upgrading one release to another, apt is currently recommended,
but I think it's assumed that you do this by typing the commands
rather than just running a script, so you can check for success at
each step.

> My experience of apt-get and aptitude is that aptitude has a better
> resolver and will often clear a medium-sized pile of packages when
> apt-get won't. However, it achieves this improved performance at the
> expense of speed and simplicity. If you run Unstable, especially, and
> leave upgrading too long, aptitude can be overwhelmed by several hundred
> packages to organise, and will apparently just hang. Aptitude should be
> fine on Stable, which should never have more than about a dozen
> packages upgradable, unless you leave it for many months. I'd still use
> apt.

With anything up to stable, I've never had a problem using apt-get.
For example, last week I upgraded a buster (oldoldstable) system that
was last upgraded in early March. A mere 171 packages with one command.

But sure, for testing and beyond, the quirks in the resolvers will
make a difference as there are more packages to upgrade and not even
a guarantee that the distribution is complete.

Cheers,
David.



Booting from USBs on old laptops, was Re: laptop installs

2024-08-27 Thread David Wright
On Tue 27 Aug 2024 at 21:42:22 (-0400), Roy J. Tellason, Sr. wrote:
> In the case of two of the three laptops I have here to play with,  it's 
> simply a matter of telling it to boot off the DVD drive and then inserting 
> the appropriate disc and going on from there.  In the case of this other one, 
>  things get a little weird.
> 
> On powerup I see messages referring to PXE,  which if I remember correctly 
> involves booting off a network connection?  There's "Media test failure, 
> check cable" followed by "Exiting PXE ROM" and then I get "No bootable device 
> -- insert boot disk and press any key.
> 
> The thing is,  this machine doesn't have a DVD drive.  What it does have is a 
> couple of USB ports (two different color connectors so I assume different 
> speeds?).  I am also assuming that simply putting an iso file on to a USB 
> stick won't quite do it.  No idea about how to implement anything to do with 
> PXE,  though I can probably safely assume that I have what I need on the LAN 
> here.
> 
> Any thoughts on how best to deal with this?

I assume your DVD drives are internal, so they're always present when
you boot up, and they're always selectable in the BIOS menus.

I have a laptop that only shows a USB stick as available in the menu
/if/ it's already plugged in before you turn on the power. If you
don't plug it in that early, you might be unaware that it could boot
from a USB stick at all: there's no mention of that in the specs, and
no hint in the extensive PhoenixBIOS documentation that you have to
expand the /Hard Drive/ item in the Boot menu to reveal the USB stick
under the actual hard drive. (You then have to promote the USB above
the hard drive in the two-item list.)

Cheers,
David.



Re: need help killing screen blanker

2024-08-27 Thread David Wright
On Tue 27 Aug 2024 at 14:58:14 (-0400), gene heskett wrote:
> On 8/26/24 14:37, David Wright wrote:
> > On Mon 26 Aug 2024 at 10:29:10 (-0400), gene heskett wrote:
> > > xfce4 desktop, running linuxcnc, [ … ]
> > > came across a dangerous situation yesterday.
> > > 
> > > Basically using the lathe as a jig to hold a long piece I was tapping
> > > by hand, powered up but stopped. screen blanker came on and locked me
> > > out till I logged back in leaving linuxcnc live but hidden behind a
> > > black screen.  This is a dangerous condition if he wrong key is hit to
> > > wake it up.
> > 
> > Surely it's not screen /blanking/ that's your problem¹ but screen
> > /locking/. BTW were you really logging back in, or just unlocking
> > the session?
> 
> total login to get back to my session.

How did you distinguish between the two cases?

> > > That monitor AND the idling rpi4b draw about 22 watts, and is turned
> > > off only for maintenance.  UPS, standby generator, uptimes might be
> > > years.
> > > 
> > > Replacing a CRT power hungry monitor means the only reason to blank a
> > > screen
> > 
> > tomas mentioned xset, which should deal with that. You need to decide
> > on whether a couple of seconds is too long to wait for recovery from
> > anything more than simple blanking.
> If the machine starts, while trying to wake it up and log back in to
> get control back to me, its already 5 seconds too damned late. With
> the pi, wakeup time is 5 + seconds by which time a sleeve caught on a
> chuck jaw has already tried to rip an arm off.

Agreed, but my paragraph was distinguishing between simple blanking
and powersaving. (Of course you don't want to be typing a password.)

In the past, I found the instant recovery from blanking (with no
powersaving) was quite satisfactory, while preventing burn-in from
being run 24/7. (This was in a lab with restricted access.)

> > > and interpose a login is security against prying eyes in an
> > > office environment.
> > 
> > That's the troublesome one for you.
> 
> Absolutely. This is not an office environment. The path thru this
> garage is hardly wide enough for me, let alone company.

There are plenty of google hits on this topic, some posted by people
who get fed up logging in over and over again in meetings. Various
OSes plus xfce.org itself. Have you made any progress yourself? I get
the impression 

> > > S, what do I remove to absolutely, permanently disable the screen
> > > blanker? And I mean no chance it can ever do that to me again.

There are odd reports of a very long timeout working better than Off.
Perhaps bear that in mind.

> > AFAICT you need to investigate XFCE's Power Manager. A quick google
> > turned up these:
> >    https://forum.manjaro.org/t/how-to-disable-auto-black-screen/127827/2
> >https://forum.xfce.org/viewtopic.php?id=13535
> >https://forum.manjaro.org/t/lock-screen-vs-login-screen/166644
> > but there may be better ones too.

On Mon 26 Aug 2024 at 15:42:56 (-0400), Felix Miata wrote:
> David Wright composed on 2024-08-26 14:36 (UTC-0400):
> 
> > ¹ touch Ctrl, the key at the extreme bottom left of the keyboard,
> >   to defeat it.
>  
> Are you sure? 

Well, all four of the laptops in this house, the previous two we
disposed of, and all the assorted keybords I've acquired over the
last twenty years or so.

But finding the safest key to use may be irrelevant if Gene doesn't
trust even basic screen blanking to occur (see above).

Cheers,
David.



Re: Is anybody maintaining nedit?

2024-08-27 Thread David Wright
On Tue 27 Aug 2024 at 17:16:07 (-0700), Van Snyder wrote:

> Although it claims to be built with locale en_US.UTF-8, it doesn't do
> anything with "compose" keystrokes such as "Compose" / O to make Ø. but
> it's perfectly happy to let me input them if I create them elsewhere,
> such as in this mailer.  Is there a way to use compose keys in nedit?

Which key is Compose?
In nedit, does it do whatever is engraved on it, or whatever the
nedit docs say it ought to do by default?
IOW, has it been grabbed by nedit?

It looks as though nedit uses X resources to set the key bindings,
as outlined in nedit.doc (perhaps worth a read). I haven't really
used the facility since the days of having to sort out Backspace/
Delete, with one exception that's transcribed from elsewhere.

Cheers,
David.



Re: need help killing screen blanker

2024-08-26 Thread David Wright
On Mon 26 Aug 2024 at 10:29:10 (-0400), gene heskett wrote:
> xfce4 desktop, running linuxcnc, [ … ]
> came across a dangerous situation yesterday.
> 
> Basically using the lathe as a jig to hold a long piece I was tapping
> by hand, powered up but stopped. screen blanker came on and locked me
> out till I logged back in leaving linuxcnc live but hidden behind a
> black screen.  This is a dangerous condition if he wrong key is hit to
> wake it up.

Surely it's not screen /blanking/ that's your problem¹ but screen
/locking/. BTW were you really logging back in, or just unlocking
the session?

> That monitor AND the idling rpi4b draw about 22 watts, and is turned
> off only for maintenance.  UPS, standby generator, uptimes might be
> years.
> 
> Replacing a CRT power hungry monitor means the only reason to blank a
> screen

tomas mentioned xset, which should deal with that. You need to decide
on whether a couple of seconds is too long to wait for recovery from
anything more than simple blanking.

> and interpose a login is security against prying eyes in an
> office environment.

That's the troublesome one for you.

> S, what do I remove to absolutely, permanently disable the screen
> blanker? And I mean no chance it can ever do that to me again.

AFAICT you need to investigate XFCE's Power Manager. A quick google
turned up these:
  https://forum.manjaro.org/t/how-to-disable-auto-black-screen/127827/2
  https://forum.xfce.org/viewtopic.php?id=13535
  https://forum.manjaro.org/t/lock-screen-vs-login-screen/166644
but there may be better ones too.

¹ touch Ctrl, the key at the extreme bottom left of the keyboard,
  to defeat it.

Cheers,
David.



Re: wait until swapoff is *actually* finished (it returns too early)?

2024-08-24 Thread David Wright
On Thu 22 Aug 2024 at 20:31:24 (-0700), Mike Castle wrote:
> On Thu, Aug 22, 2024 at 4:31 PM David Wright  wrote:
  ↑↑↑ odd time to pick

> > Irrespective of the time taken, that could trigger the OOM killer,
> > couldn't it. Very risky, unless you're using two swaps as mentioned.
> 
> I was actually surprised to see this happen in a test right now.  I
> *thought* that swapoff() would fail if reduce the available memory to
> below current usage.
> 
> But indeed, the OOM Killer not only killed my test program, it took
> out the swapoff command for good measure!

So in the case of the OP, it might well kill off the entire
swapoff/swapon script, leaving the system with no swap at all.
But as I said, I don't think a shortage of memory is the reason
for the OP having swap space here at all.

Cheers,
David.



Re: Cups problems adding printer Epson in new Debian install

2024-08-24 Thread David Wright
On Tue 20 Aug 2024 at 17:27:37 (+0200), sentini...@virgilio.it wrote:
> > Il 20/08/2024 04:53 CEST David Wright ha scritto:
> > 
> > What's the output from:
> > 
> >   $ driverless
> > 
> > (This is normally step one in configuring a printer.)
> 
> aldo@aldomaggi:~$ driverless
> ipps://EPSON%20ET-2810%20Series._ipps._tcp.local/

I looked for ET-2810 information on Epson's US website, but though it
claimed 47 matches for ET-2810 under support, the model was not there.

I found the model listed on this website:

  https://www.ldlc.com/en/product/PB00463030.html

and under Overview, it says "Key features: [ … ] Mobile and
cloud-based printing services: Epson Connect (iPrint, Email Print,
Remote Print Driver, Scan-to-Cloud), Apple AirPrint,
Google Cloud Print)"

However, under Specifications, it says "Mobile printing:
  Smartphone compatible Yes
  Google Cloud Print No"
and no mention of AirPrint. I have no idea what
"Smartphone compatible" means, and have never heard of
Epson Connect.

I then looked at the Epson UK website (I didn't know whether European
sites would be in English):

 
https://www.epson.co.uk/en_GB/products/printers/inkjet/consumer/ecotank-et-2810/p/30169#tech-specs

and I don't see any mention of AirPrint, just a list of Mac/Windows
OSes, and Epson Smart Panel App and Epson Connect (Email Print,
Remote Print Driver), whatever they are.

All this would lead me to give credence to the views expressed at:

  https://www.reddit.com/r/Epson/comments/11njqgh/airprint_not_working_et2810/

Cheers,
David.



Re: wait until swapoff is *actually* finished (it returns too early)?

2024-08-22 Thread David Wright
On Thu 22 Aug 2024 at 21:34:45 (+0200), to...@tuxteam.de wrote:
> On Thu, Aug 22, 2024 at 01:45:06PM -0500, David Wright wrote:
> > On Thu 22 Aug 2024 at 17:21:04 (+), Thorsten Glaser wrote:
> > > Mike Castle dixit:
> 
> [...]
> 
> > > >I suspect that the race is that, when the the swapoff() syscall
> > > >returns, the kernel has indeed moved all of the content off, so that
> > > >part is fine... but it has not yet released whatever kind of resources
> > > >is has on the backing store (akin to an open file handle).
> > > 
> > > My guess as well.
> > 
> > I'm not convinced. Finding out what needs copying back and locating
> > somewhere to put it is AIUI a slow process.
> 
> Actually, thinking about it: if the system hasn't enough discardable
> RAM, the process might take arbitrarily long, no?

Irrespective of the time taken, that could trigger the OOM killer,
couldn't it. Very risky, unless you're using two swaps as mentioned.

To be fair, I assume that people are using swapoff/swapon like this
when they have servers that are running for "ever". In which case,
swap may be there for speed rather than extending RAM.

Cheers,
David.



Re: wait until swapoff is *actually* finished (it returns too early)?

2024-08-22 Thread David Wright
On Thu 22 Aug 2024 at 17:21:04 (+), Thorsten Glaser wrote:
> Mike Castle dixit:
> 
> >Does cryptdisks have the ability to display what is in use at the
> >moment?  Maybe polling that before executing the stop?
> 
> That’s what I would like to ask and why I sent this eMail.

Is cryptdisks_stop failing an issue? If not, just repeating it
in a slow loop until it succeeds would be one strategy.

> >I suspect that the race is that, when the the swapoff() syscall
> >returns, the kernel has indeed moved all of the content off, so that
> >part is fine... but it has not yet released whatever kind of resources
> >is has on the backing store (akin to an open file handle).
> 
> My guess as well.

I'm not convinced. Finding out what needs copying back and locating
somewhere to put it is AIUI a slow process. What's much faster is
when processes themselves demand something be paged back in from
swap. I think there are "tricks" available to cause that to occur,
thus speeding up swapoff.

> >You could then control the timeout by looping no more than N times,
> >then failing a bit more gracefully than it is now.
> 
> That’d be a method of last resort, same category as the sleep,
> except even worse. I’d like to find a way to prevent that.

Presumably once you have executed swapoff, you're committed to
waiting, because otherwise cryptdisks_start on the same device
would fail.

Of course, if swap /size/ is not an issue, you could have two swap
areas, and start the second before you stop the first. That way,
swapoff speed is not an issue. Well now, you /do/ have two!

Cheers,
David.



Re: upgrade to bookworm causes breakage

2024-08-19 Thread David Wright
On Mon 19 Aug 2024 at 20:26:35 (-0400), Gary Dale wrote:
> On 2024-08-19 19:24, Mike wrote:
> > Bob Mroczka wrote:
> > > I attempted to upgrade my system from debian 11 to 12 following the
> > > instructions provided at
> > > https://www.cyberciti.biz/faq/update-upgrade-debian-11-to-debian-12-bookworm.
> > In the future, consider using https://www.debian.org/release/stable/ and
> > such.  cyberciti.biz usually just copies content from elsewhere, to sell ads
> > against it.  It may not be authoritative.
> > 
> > > Do you have any suggestions for further identifying the cause of this
> > > and/or resolving this without recovering from back up?
> > My only thought is that maybe, somehow, you're running a mix of incompatible
> > libraries and executables, some upgraded and some not.  You might go into
> > `aptitude`, if it runs, and see what it thinks.
> > 
> > The "rescue" option on the Debian image may be able to help you mount and
> > install a proper installation on your existing disks, since it runs its
> > own copy of Linux on a ramdisk.  But it's been a long time since I've used
> > it, so I forget the procedure.
> > 
> Further to Mike's suggestion, sometimes going back to apt-get instead
> of apt can work.
> 
> Also, since the full-upgrade step has failed, you should be able to
> reboot and try again. One of the kernels should be able to work.
> However, you can also boot to a command prompt, which might be safer.
> 
> To fix dpkg, I suspect that it's the tar package that needs to be
> fixed. That may just be a single binary that you can copy from another
> system.

It might be worth looking for any corruption with:

  # cd /
  # md5sum -c /var/lib/dpkg/info/{dpkg,gzip,tar}.md5sums

Or use a sledgehammer and check the whole lot:

  # md5sum -c /var/lib/dpkg/info/*.md5sums | grep -v ': OK$'

though expect some output from such things as diversions and some
empty foo.md5sums files. (I'm assuming that debsums hasn't been
installed.)

> Worst case scenario is to do a fresh install of bookworm. If your
> /home is in a separate partition, that should be easy and safe. Just
> don't let it reformat or erase /home. Use manual partitioning.
> 
> I personally don't like using sudo for everything. When I have more
> than one command, I just do a sudo bash and run them as root.
> 
> Looking at the cybercit.biz article, it's doing some stuff that I find
> a little strange. Step 3 should just ask you to run sed to replace
> bullseye with bookworm - less chance for errors.

To be fair, the long version (rather than the summary at the top)
does suggest this, and adds one reason for using an editor for this
particular upgrade: the addition of non-free-firmware.

> And I don't like step 5 at all. The difference between versions often
> includes packages being replaced. Upgrading without new packages seems
> like asking for trouble.

This step (which is labelled step 4 in the long version¹) corresponds
to   §4.4.5 Minimal system upgrade   in the bookworm Release Notes,
so like it or not, it's official.

¹ Step 4 in the summary is the last action in the long version's step 3.

Cheers,
David.



Re: Default partition mounts [ "Installation Guide" lacks index ]

2024-08-19 Thread David Wright
On Mon 19 Aug 2024 at 16:23:31 (-0600), Tom Dial wrote:
> On 8/19/24 05:19, Richard Owlett wrote:
> > I'm over 80 and doing first "from scratch" install since Squeeze ;}
> > Hardware is Lenovo R61 ThinkPad (64 bit).
> > I multi boot [Grub will have at least three options]:
> >    1. minimalist installation - primarily command line usage
> >    2. 64 bit Debian with maximum features
> >    3. 32 bit Debian - couple of applications require a 32 bit OS
> >    4. other installs with strong project dependencies
> > 
> > Today's question
> > At boot time, what determines which physical partition gets mounted as a 
> > specific directory ( /, /home, swap, and so forth )?
> 
> In most cases, mount actions are as described in /etc/fstab of the image 
> being booted.

AFAICT the /etc/fstab in the boot images of all my Debian systems
is empty. It's only when the root filesystem gets mounted that a
non-empty /etc/fstab becomes available.

OTOH a netinst installer's image does have a populated /etc/fstab,
but only with:

  devpts /dev/pts devpts  defaults0   0
  tmpfs  /run tmpfs   nosuid,size=10%,mode=7550   0
  proc   /procprocdefaults0   0
  sysfs  /sys sysfs   noauto  0   0

Cheers,
David.



Re: Cups problems adding printer Epson in new Debian install

2024-08-19 Thread David Wright
On Sun 18 Aug 2024 at 18:44:30 (+0200), sentini...@virgilio.it wrote:
[ … ]
> At the “connection” line it says: Connection: 
> ipps://EPSON%20ET-2810%20Series._ipps._tcp.local/
[ … ]
> in the next screen it tells me: "Unable to add printer: cups-driver failed to 
> get PPD file" - see error_log for details.
> This is what /var/log/cups/error_log says:
> E [18/Aug/2024:17:27:03 +0200] [CGI] Unable to create PPD file: Could not 
> poll sufficient capability info from the printer 
> (ipps://EPSON%20ET-2810%20Series._ipps._tcp .local/, 
> ipps://EPSON318F07.local:631/ipp/print) via IPP!
[ … ]
> I click on "Maintenance" and select "Print text Page":
> I get this line in the "Jobs" section:
> EPSON_ET-2810_Series_-14 Unknown Withheld 1k Unknown stopped
> and, in fact, nothing is printed.
> Since to print I have to transfer the documents to my mobile phone via 
> Whatsapp, I know that the printer works but a question arises 
> spontaneously, why on earth with Android (which is also Linux) printing works 
> immediately (with the app from Epson) and with Cups (which if I'm not 
> mistaken is, or at least once was, from Apple) do I have to go crazy like 
> this?

What's the output from:

  $ driverless

(This is normally step one in configuring a printer.)

Cheers,
David.



Re: PDF editor

2024-08-06 Thread David Wright
On Tue 06 Aug 2024 at 21:27:00 (-0400), Arbol One wrote:
> Anyone knows about a PDF editor for Debian?

Perhaps you could summarise what you learnt, and what you feel you
didn't learn, from the thread that you opened here six weeks ago.

  https://lists.debian.org/debian-user/2024/06/msg00667.html

Cheers,
David.



Re: nsswitch what should come first

2024-08-05 Thread David Wright
On Fri 02 Aug 2024 at 19:29:14 (-0400), Dan Ritter wrote:
> Lee wrote: 
> > On Thu, Aug 1, 2024 at 10:40 PM Jeffrey Walton wrote:
> > >
> > > I personally remove mDNS and Bonjour from my machines. mDNS is not the
> > > source of truth on my networks. Rather, DNS is the source of truth in
> > > my networks ...
> > 
> > Do you have any network printers?  That work without having mDNS enabled?
> 
> I do. If you assign an IP and a DNS name to the IP, all the
> network printers I am aware of will work just fine. (They don't
> care about the DNS name, either, but it's more convenient if you
> don't want to remember the IP.)

So when I set up my Brother laser printer, I followed the wiki at
  
https://wiki.debian.org/CUPSDriverlessPrinting#Creating_a_Driverless_Print_Queue_with_lpadmin_.28Short_Version.29
using the cups-filters PPD generator option (for reasons I do not
remember). The device has the name ipp://Brother…._ipp._tcp.local/
so I expect I'm using mDNS to print to it.

The printer has an IP name and address (in /etc/hosts) that I use
solely with ping. (A pingall function tells me which devices are
turned on, and need switching off before a thundestorm strikes.)
lpinfo also sees an lpd: ?device with what looks like a serial
number (but isn't AFAICT).

Which wiki method would I use to set up this printer through its
IP address rather than a .local address? There's a lot of material
in the Debian Printing wiki pages; so much of it is aimed at buster
and legacy printers that finding particular methods can be difficult.

I have a second, older printer whose printing engine is dead. (I use
it only as a scanner.) The driverless command also gives this printer
a .local device name (both ipp: and dnssd:), but I also see a
socket://192.168.1.11:9100 address that I understand is deprecated.
However, this is the only IP address given by lpinfo -v. In fact,
it's about the only IP address I've found in the CUPS configuration
files. I don't see 192.168.1.12 (the Brother's) anywhere.

Cheers,
David.



Re: dot internal and mDNS

2024-08-05 Thread David Wright
On Sat 03 Aug 2024 at 12:59:45 (+), Andy Smith wrote:
> On Sat, Aug 03, 2024 at 06:40:32PM +1000, George at Clug wrote:
> > I believe ICCAN are moving to possibly replacing .local, .home, .lan,
> > .corp, .mail, .localdomain, (and possibly others) with .internal ?
> 
> home.arpa was defined by IANA in 2018. If they go ahead with
> .internal then I can only imagine it will be in addition to, not
> instead of, home.arpa.
> 
> > How could this affect mDNS and the use of .local?
> 
> It won't. mDNS will continue using .local.
> 
> If you use .local for other things it can interfere with mDNS but
> picking almost anything else has very few repercussions (unless you
> are very silly about it), so I don't understand why this topic
> always generates so much debate on this list.

Possibly because people aren't warned against using it unless they're
on a network that is already using it for Microsoft servers. It would
be simple to add such a warning to the screen below, and perhaps some
advice on home.arpa etc at the same time.

  ┌─┤ [!!] Configure the network ├┐
  │   │
  │ The domain name is the part of your Internet address to the right of your │
  │ host name. It is often something that ends in .com, .net, .edu, or .org.  │
  │ If you are setting up a home network, you can make something up, but make │
  │ sure you use the same domain name on all your computers.  │
  │   │
  │ Domain name:  │
  │   │
  │ _ │
  │   │
  ││
  │   │
  └───┘

With any group of people for whom the second line is useful
information, I think a significant proportion would choose a name
like "local" after reading the third line.

BTW you can't /buy/ your own domain, only rent it—and prompt payment
is required to make sure you keep it.

Cheers,
David.



Re: What is the purpose of mDNS

2024-08-05 Thread David Wright
On Sat 03 Aug 2024 at 11:26:38 (+0200), to...@tuxteam.de wrote:
> On Sat, Aug 03, 2024 at 06:56:42PM +1000, George at Clug wrote:
> > What is the purpose of mDNS ? 
> > 
> >  It seems to be for multicast?  
> 
> It is not /for/ multicast IP, it /uses/ multicast for name resolution.
> In a nutshell [1], it sends a "DNS" request to the local network asking
> "who is called Fritz here?", and Fritz answers with its IP. So sys-non-
> admins don't have to set up a name server.
> 
> It is part of Microsoft's promise that  anyone can be sysadmin because
> no one is. And then you end up in The Cloud(TM), which doesn't work either.

Isn't that what modern networking is striving to attain?

 “It is not practical to expect home users to configure their networks.
  Thus, the assumption of this document is that the homenet is as far
  as possible self-organising and self-configuring, i.e., it should
  function without proactive management by the residential user.”

(RFC 7368)

 “Users and devices within a home network (hereafter referred to as
  "homenet") require devices and services to be identified by names
  that are unique within the boundaries of the homenet [RFC7368].  The
  naming mechanism needs to function without configuration from the
  user.  While it may be possible for a name to be delegated by an ISP,
  homenets must also function in the absence of such a delegation.
  This document reserves the name 'home.arpa.' to serve as the default
  name for this purpose, with a scope limited to each individual
  homenet.”

(RFC 8375)

Cheers,
David.



Re: nftables ssh Could not resolve service Servname not supported

2024-08-05 Thread David Wright
On Tue 06 Aug 2024 at 14:25:45 (+1000), George at Clug wrote:

> However I have one issue, my nftables is not recognising the label
> 'dns' for port 53, although it is recognising labels for other ports
> that I have been using (e.g. ssh, http, ntp, https).

My /etc/services uses the term "domain" rather than "dns" for 53.

Cheers,
David.



Re: can this iso be put on a micro-sd

2024-08-03 Thread David Wright
On Sat 03 Aug 2024 at 20:04:08 (-0400), gene heskett wrote:
> On 8/3/24 19:39, gene heskett wrote:
> > [ISO]    debian-12.6.0-arm64-DVD-1.iso
> > 
> Wrote it to /dev/sdl, won't mount on sdl or sdl1. gparted says sdl2 is
> the dos partition??

With amd64-netinst ISOs, all three of /dev/sdX{,1,2} should be
mountable. sdX and sdX1 will appear identical as they both start at
sector 0. sdX2 is FAT because it's the EFI partition.

Obviously arm64-DVD ISOs might differ somewhat, but my question is
whether, having written the ISO to sdl, did you try and boot from it,
or did you mystify yourself by trying to mount the partitions and
then abandon the process in favour of:

> Now writing it to /dev/sdl1.

which is an odd thing to do.

Cheers,
David.



Re: nsswitch what should come first

2024-08-02 Thread David Wright
On Fri 02 Aug 2024 at 14:37:08 (+1000), George at Clug wrote:

> > > What is best practice for a local LAN prefix? (I have never found 
> > > conclusive instruction).
> > 
> > home.arpa
> > see  https://www.rfc-editor.org/rfc/rfc8375.html
> 
> A fairly straight forward statement in this RFC, just not sure if I could get 
> used to using .arpa as a suffix. But seems like a great choice?

If you're heavily into DNS, then you've probably used the .arpa TLD
already, as in ….in-addr.arpa, which maps IPv4 addresses to domain
names, and ….ip6.arpa for IPv6. It's now a backronym standing for
Address and Routing Parameter Area, to decouple it from its original
coining.

> > > It is my belief that .local is a MS idea originating from the 
> > > configuration of their servers. Is this correct?
> > 
> > again, quoting from the .local wikipedia article
> >   Microsoft TechNet article 708159[7] suggested .local ...
> >   but later recommended against it
> 
> https://en.wikipedia.org/wiki/.local
> If you have *Macintosh client computers* that are running the Macintosh OS X 
> version 10.3 operating system or later, ... it is recommended that you do not 
> use the .local label for the full DNS name of your internal domain.

That TechNet article was written in 2008. I think .local was being
used by Apple in the previous decade (see RFC).

The cynic in me wonders whether this article is an attempt to lock in
MS customers. Look at the paragraph after the one you quoted:

 "• After you install Windows Small Business Server 2003, you cannot
change the settings specified in Full DNS name for internal domain
or NetBIOS domain name. These settings are used to configure
server applications during Setup. If you want to change these
names, you must reinstall Windows Small Business Server 2003."

Either they're trying to make things difficult should you go out and
buy any Apple kit, or they're relying on people not to read any of
the warnings, and go with their default.

Cheers,
David.



Re: nsswitch what should come first

2024-08-01 Thread David Wright
On Fri 02 Aug 2024 at 09:40:44 (+1000), George at Clug wrote:
> On Friday, 02-08-2024 at 00:48 David Wright wrote:
> > On Thu 01 Aug 2024 at 10:32:27 (-0400), Greg Wooledge wrote:
> > > On Thu, Aug 01, 2024 at 14:30:05 +, fxkl4...@protonmail.com wrote:
> > > > my nsswitch.conf is "hosts: files mdns4_minimal [NOTFOUND=return] dns"
> > > > i don't remenber changing it in the past few decades
> > > > i recently had a situation that made me question the ordering
> > > > my dns server is my primary router
> > > > should dns be first
> > > 
> > > It would be *extremely* unusual to want to consult DNS before /etc/hosts.
> > > I recommend leaving files first unless you have a *really* good reason
> > > to switch them.
> > > 
> > > I have no comment on mdns4_minimal because I don't really know what that
> > > is.
> > 
> > AIUI mdns4_minimal is for devices that configure themselves using
> > multicast DNS on .local. If you put dns first, then the names of any
> > .local devices will be leaked out of your LAN and on to the Internet's
> > DNS servers. [NOTFOUND=return] is what prevent that happening IF you
> > leave the order alone.

Can I tighten that up: names that resolve shouldn't leak; it's names
that don't resolve, which would be passed onwards for DNS to resolve,
that would leak.

> > (BTW don't use .local for your LAN domain name.)
> 
> Why is that? (recently I was starting to believe I should stop using the 
> domain names I had chosen, and start using (what I thought was) the standard 
> of .local)

  https://www.ietf.org/rfc/rfc6762.txt

explains what .local is for.

> Is it your personal preference, or a technical necessity?
> 
> What is best practice for a local LAN prefix? (I have never found conclusive 
> instruction).

I've been in the habit of using .corp after reading:

  https://www.icann.org/resources/board-material/resolutions-2018-02-04-en#2.c

but I don't think that decision is set in stone, and certainly
RFC 8375 now recommends .home.arpa for residences, so that's
a better bet.

> It is my belief that .local is a MS idea originating from the configuration 
> of their servers. Is this correct?

Most of what I've read has credited Apple with this, not Microsoft.

Cheers,
David.



Re: nsswitch what should come first

2024-08-01 Thread David Wright
On Thu 01 Aug 2024 at 10:32:27 (-0400), Greg Wooledge wrote:
> On Thu, Aug 01, 2024 at 14:30:05 +, fxkl4...@protonmail.com wrote:
> > my nsswitch.conf is "hosts: files mdns4_minimal [NOTFOUND=return] dns"
> > i don't remenber changing it in the past few decades
> > i recently had a situation that made me question the ordering
> > my dns server is my primary router
> > should dns be first
> 
> It would be *extremely* unusual to want to consult DNS before /etc/hosts.
> I recommend leaving files first unless you have a *really* good reason
> to switch them.
> 
> I have no comment on mdns4_minimal because I don't really know what that
> is.

AIUI mdns4_minimal is for devices that configure themselves using
multicast DNS on .local. If you put dns first, then the names of any
.local devices will be leaked out of your LAN and on to the Internet's
DNS servers. [NOTFOUND=return] is what prevent that happening IF you
leave the order alone. (BTW don't use .local for your LAN domain name.)

Cheers,
David.



Re: Upgrading systemd may silently break your Unstable/Sid system!

2024-07-28 Thread David Wright
On Sun 28 Jul 2024 at 09:45:44 (-0500), allan wrote:
> I've run Sid exclusively for years; the last time I broke it badly
> enough to justify a reinstall was in 2013 and that was for not paying
> attention during an upgrade  :)
> 
> My heartburn is I would have expected to see this change in a
> changelog and apt-listchanges didn't say a word about this.
> 
> As far as filing a bug report?  Since the symlink is now gone I'm not
> even sure there's a bug to file  :)

Well, yes, but IMHO not against systemd, but procps, for abandoning
its conffile. Otherwise this problem will occur in the future when
bookworm users with a modified conffile upgrade to Debian 13. The
file needs to migrate somehow.

Cheers,
David.



Re: info is not dead

2024-07-28 Thread David Wright
On Sun 28 Jul 2024 at 16:23:48 (+0200), Vincent Lefevre wrote:
> On 2024-07-28 00:08:51 -0500, David Wright wrote:
> > On Sun 28 Jul 2024 at 02:06:38 (+0200), Vincent Lefevre wrote:
> > > On 2024-07-23 11:13:47 -0500, Nate Bargmann wrote:
> > > > The GNU info documentation is really intended to be read in Emacs where
> > > > some nice formatting is done in the GUI Emacs version.  The stand alone
> > > > GNU info browser is rather obtuse.  I found a much better option to be
> > > > the independent pinfo (Debian package of the same name) browser which
> > > > provides navigation up and down through the document using Lynx style
> > > > key bindings.  If pinfo doesn't find an info document it will open a man
> > > > page when one is available.
> > > 
> > > But for searching, how can one get the previous match with pinfo?
> > > (info has { and } to navigate through the matches, Lynx has n and N,
> > > but what about pinfo?)
> > 
> > I think you define KEY_SEARCH_AGAIN_1 to whichever keystroke you want.
> > (AIUI it has no default already defined in /etc/.pinforc)
> 
> KEY_SEARCH_AGAIN_1 gives the *next* match, not the previous one.

Sorry, yes, I think it helps to be able to subconciously count (but
avoid being afflicted by OCD), and press Home and n-1 SearchAgains.
(Even more tedious than searching backwards and forwards in xpdf,
where you have to toggle a button.)

Wishlist bug?

Cheers,
David.



Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

2024-07-28 Thread David Wright
On Mon 29 Jul 2024 at 09:23:16 (+0700), Max Nikulin wrote:
> On 28/07/2024 20:08, Erwan David wrote:
> > I also have a 99-systcl.conf which is a copy of the former /etc/sysctl.conf
> 
> When you are going to replace a file provided by a package, check if
> it is a configuration file at first (e.g. dpkg -s). Despite most of
> files in /etc/ are marked as configuration files, some are not.

I think you meant to write conffiles, not configuration files.

Cheers,
David.



Re: systemd may silently break your system!

2024-07-28 Thread David Wright
On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:
> On 2024-07-28 00:07:56 -0500, David Wright wrote:
> > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote:
> > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:
> > 
> > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> > > > > The configuration got broken by a *systemd* upgrade:
> > > > > 
> > > > >   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> > > > > /etc/sysctl.conf (Closes: #1076190)
> > > > 
> > > > The systemd change was only done because of the procps change.  After
> > > > the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
> > > > provided by the systemd package was dangling/broken.  So the systemd
> > > > maintainer removed the symlink.
> > > 
> > > No, the /etc/sysctl.conf file has not been removed (yet) for
> > > existing installations.
> > > 
> > > If the goal were to fix the dangling symlink for new installations,
> > > then the solution should have been to no longer generate the
> > > /etc/sysctl.d/99-sysctl.conf symlink for new installations (and
> > > for existing installations, possibly remove it *only* if it was
> > > dangling).
> > 
> > It looks accidental to me that systemd did that tidying up before
> > procps had attempted to remove the file that it (procps) owned.
> 
> No, the breakage was done on purpose: my bug report specifically
> about this breakage by systemd was closed in a rather abrupt way:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184

I only wrote that the /order/ was accidental: upgrading systemd before
procps had removed its conffile. When the latter happens, you should
get asked about that conffile, and if not, then that's surely a bug
in procps, not systemd: procps owned the file, so procps disowned it.

In fact, here's procps disowning /etc/sysctl.conf:

  procps (2:4.0.4-5) unstable; urgency=medium

* Add Recommends: linux-sysctl-defaults Closes: #1074156
* Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better

(the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)

> > > > > > As it turns out, it's a combination of the two packages.  In 
> > > > > > bookworm,
> > > > > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > > > > the systemd package.
> > 
> > That symlink was suggested as legacy support for reading the conf file
> > over a decade ago. Bullseye's   man 8 sysctl   indicates it still reads
> > /etc/sysctl.conf with its --system option, but bookworm lacks that
    trixie
> > manpage, and instead its   man 5 sysctl.d   lists only files residing
> > in …/sysctl.d/ directories as being read; hence the legacy symlink.
> 
> No, I have a bookworm machine, and the sysctl.conf(5) man page is
> still there (in addition to the sysctl.d(5) man page).

Sorry, I meant to write trixie, not bookworm; stable and oldstable are
the same. Your complaint is with unstable.

> > > This is rather poor design, because
> > >   * there isn't a way to say that some default setting must be
> > > preserved;
> > 
> > There is: just add an empty comment line. Now you own that default.
> 
> No, this is not sufficient. During an upgrade, a package is allowed
> to do a merge of the new defaults (this occurs quite frequently).

That doesn't square with Policy, and this typical dialogue that
we've all seen:

  Configuration file `foo'
   ==> Modified (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** foo (Y/I/N/O/D/Z) [default=N] ? 

Might your merges apply to configuration files rather than conffiles?

> > >   * changes by a user must be respected by the package, but a package
> > > may decide that such a file is no longer read!
> > 
> > As I said, I think that happened by accident rather than design,
> > a consequence of refactorising two packages with two maintainers.
> 
> See my bug report above.

I would file a b

Re: systemd may silently break your system!

2024-07-27 Thread David Wright
On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote:
> On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:

> > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> > > The configuration got broken by a *systemd* upgrade:
> > > 
> > >   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> > > /etc/sysctl.conf (Closes: #1076190)
> > 
> > The systemd change was only done because of the procps change.  After
> > the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
> > provided by the systemd package was dangling/broken.  So the systemd
> > maintainer removed the symlink.
> 
> No, the /etc/sysctl.conf file has not been removed (yet) for
> existing installations.
> 
> If the goal were to fix the dangling symlink for new installations,
> then the solution should have been to no longer generate the
> /etc/sysctl.d/99-sysctl.conf symlink for new installations (and
> for existing installations, possibly remove it *only* if it was
> dangling).

It looks accidental to me that systemd did that tidying up before
procps had attempted to remove the file that it (procps) owned.

> > > > As it turns out, it's a combination of the two packages.  In bookworm,
> > > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > > the systemd package.

That symlink was suggested as legacy support for reading the conf file
over a decade ago. Bullseye's   man 8 sysctl   indicates it still reads
/etc/sysctl.conf with its --system option, but bookworm lacks that
manpage, and instead its   man 5 sysctl.d   lists only files residing
in …/sysctl.d/ directories as being read; hence the legacy symlink.

> > > What does a regular file make different compared to a conffile
> > > concerning its handling?
> > 
> > A conffile is user-managed, so any changes you make to a conffile must
> > be respected by the package.  It can't just overwrite your changes, or
> > restore a conffile if you've deleted it.
> 
> This is rather poor design, because
>   * there isn't a way to say that some default setting must be
> preserved;

There is: just add an empty comment line. Now you own that default.

>   * changes by a user must be respected by the package, but a package
> may decide that such a file is no longer read!

As I said, I think that happened by accident rather than design,
a consequence of refactorising two packages with two maintainers.

> A better design could be to provide Debian / vendor defaults (which
> may change) by some kind of include mechanism. This is more or less
> what fail2ban does, with .conf files and .local files (the .conf
> files are not meant to be changed by the user, so that /usr/lib
> might be a better place than /etc).

Um, isn't that what systemd provides as a matter of routine?

SYSCTL.D(5) sysctl.d SYSCTL.D(5)

NAME
sysctl.d - Configure kernel parameters at boot

SYNOPSIS
  /etc/sysctl.d/*.conf ← sysadmin's configuration overrides
  /run/sysctl.d/*.conf ← ephemeral overrides
  /usr/local/lib/sysctl.d/*.conf   ← local package's overrides
  /usr/lib/sysctl.d/*.conf ← Debian/systemd's default configuration

> > > > In unstable, apparently, *both* of them are gone.
> > > 
> > > No, /etc/sysctl.conf is not gone on existing installations.
> > > It is just no longer read.
> > 
> > It's... not?  Then what the hell does the procps change text mean?
> > 
> > > > while 
> > > > 
> > > >  says:
> > > > procps (2:4.0.4-5) unstable; urgency=medium
> > > > 
> > > >   * Add Recommends: linux-sysctl-defaults Closes: #1074156
> > > >   * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
> > > >   * Updated /etc/sysctld.d/README
> > 
> > That sure sounds like it's removed, to me.
> 
> The changelog is just wrong... or actually the intended behavior
> was to remove the file, but this is buggy:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352
> 
> But just removing the file is against the policy!

But two things:

. This [Policy] manual cannot and does not prohibit every
  possible bug or undesirable behaviour.

. The Release Team can, at their discretion, downgrade
  a Policy requirement to a Policy recommendation for
  a given release of the Debian distribution.

and, of course, unstable is never released.

> Still, it must be
> removed because systemd's decision to remove the symlink was done
> based on the assumption that /etc/sysctl.conf no longer exists.
> IMHO, the best solution would be to propose to move it into
> "/etc/sysctld.d".
> 
> > > only for *new* installations.
> > 
> > Well... it's a conffile.  If you made any changes to it, then the package
> > can't just remove it during an upgrade.

I don't think it would break Policy for a new empty configuration
file to be supplied. You would of c

Re: info is not dead

2024-07-27 Thread David Wright
On Sun 28 Jul 2024 at 02:06:38 (+0200), Vincent Lefevre wrote:
> On 2024-07-23 11:13:47 -0500, Nate Bargmann wrote:
> > The GNU info documentation is really intended to be read in Emacs where
> > some nice formatting is done in the GUI Emacs version.  The stand alone
> > GNU info browser is rather obtuse.  I found a much better option to be
> > the independent pinfo (Debian package of the same name) browser which
> > provides navigation up and down through the document using Lynx style
> > key bindings.  If pinfo doesn't find an info document it will open a man
> > page when one is available.
> 
> But for searching, how can one get the previous match with pinfo?
> (info has { and } to navigate through the matches, Lynx has n and N,
> but what about pinfo?)

I think you define KEY_SEARCH_AGAIN_1 to whichever keystroke you want.
(AIUI it has no default already defined in /etc/.pinforc)

Cheers,
David.



Re: switch users and still use display

2024-07-27 Thread David Wright
On Sat 27 Jul 2024 at 23:21:06 (+0200), Hans wrote:
> I never found an official documentation about "su -p", just found it myself, 
> but I read, "su -" shall do the same. It does not.

When you write something like this, can you accompany it with a
reference? The essential package util-linux's man page seems to
contradict whatever it was you found and read:

  -, -l, --login
   Start the shell as a login  shell  with  an  environment
   similar to a real login:

  [ … four bullet points … ]

  -m, -p, --preserve-environment
   Preserve  the entire environment, i.e., do not set HOME,
   SHELL, USER or LOGNAME.  This option is ignored  if  the
   option --login is specified.

Cheers,
David.



Re: systemd may silently break your system!

2024-07-27 Thread David Wright
On Sat 27 Jul 2024 at 09:26:49 (-0400), Greg Wooledge wrote:
> > On 2024-07-26, Vincent Lefevre wrote:
> > 
> > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed
> > > (currently in unstable) *without any announcement*, so that
> > > the /etc/sysctl.conf file (which is still documented, BTW)
> > > is no longer read.
> > >
> > > So, be careful if you have important settings there (security...).
> 
> I kept wondering: what does this have to do with the Subject
> header?  The files in question belong to the procps package, not
> to systemd, right?
> 
> As it turns out, it's a combination of the two packages.  In bookworm,
> /etc/sysctl.conf is a Conffile of the procps package, and
> /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> the systemd package.
> 
> In unstable, apparently, *both* of them are gone.
> 
> 
>  says:
>   [ Luca Boccassi ]
>   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> /etc/sysctl.conf (Closes: #1076190)
> 
> while 
> 
>  says:
> procps (2:4.0.4-5) unstable; urgency=medium
> 
>   * Add Recommends: linux-sysctl-defaults Closes: #1074156
>   * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
>   * Updated /etc/sysctld.d/README
> 
> So it seems to have been a removal performed at the whim of the procps
> maintainer.  Perhaps there was discussion somewhere amongst the developers
> that I'm not aware of.
> 
> It does seem like the sort of change that would belong in the NEWS
> file, but I don't see it in
> .

I'd agree (it's a NEWS bug), but the file is AFAICT functionless.
If you've added any functionality to it, then I'd expect upgrading
procps to give the usual dialogue whenever a conffile has been
modified.

But if you have installed systemd without procps in the past, did
that just result in a dangling symlink? As I have both systemd
and procps installed, I'm not sure what happens in this case.

As far as moving the file is concerned, I would have thought
this was just part of the evolution from big-file-under-/etc/
to individual-snippets-under-/etc/foo.d/ that's been happening
for years. And I can't find another instance on my system of
a /etc/foo.d/NN-bar → /etc/bar.conf where the symlink has a
sequence number. (IOW bar.conf doesn't "know" that it's part of
an ordered collection of configurations.)

Cheers,
David.



Re: Strange behavior of ifupdown package

2024-07-26 Thread David Wright
On Wed 24 Jul 2024 at 14:29:34 (+), MailGuard01 wrote:
> I am trying to complete the network configuration on Debian 12 using the 
> default
> installed `ifupdown` package. I have noticed some confusing behavior with
> `ifupdown` while following the manual pages.
> 
> Specifically, when I place `iface eno1 inet6 auto` with `privext 2` after 
> `iface
> inet eno1 dhcp` as instructed by the manual, the behavior becomes 
> unpredictable.
> Typically, the `privext` setting does not work as expected and has no effect
> when I initially boot into Debian 12 every time, even though the value of
> `/proc/sys/net/ipv6/conf/eno1/use_tempaddr` is correctly set to 2. No 
> temporary
> IPv6 address is assigned to the interface.
> 
> However, if I restart the networking service using `systemctl restart
> networking`, everything starts working correctly, and the temporary IPv6 
> address
> is assigned and displayed. Strangely, after multiple reboot of my Debian 12 
> PC,
> the temporary address occasionally appears without manually restarting the
> networking service. The behavior seems unstable and inconsistent.
> 
> When I accidentally placed `iface eno1 inet6 auto` with `privext 2` before
> `iface inet eno1 dhcp`, everything worked without any problem. All settings
> correctly applied, and there was no need to manually restart the networking
> service.
> 
> I have searched online but found nothing relevant, as if this is an isolated
> case. The manual also does not mention this behavior. I can reproduce this
> consistently from Debian 11 to Debian testing/unstable.
> 
> Is this behavior expected / considered a feature? Or is it an isolated case?
> Should I report this as a bug, and if so, where should I do that?

There is a bug report #960809, which seems related, and
might be worth adding your experience to, if you think so.

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

> Additionally, it would be helpful to mention this behavior in the manual pages
> if it's expected, perhaps in a known limitations section. It took me days to
> solve this issue, and I was stumble upon the solution by sheer luck.

I did wonder whether any of the randomness wrt reboots might be
time-related, as skim reading the RFC, it seems to allow for storing
a history of addresses used, and periodic generation of new ones
rather than a fresh one every reboot.

Cheers,
David.



Re: How to update environment variable output

2024-07-23 Thread David Wright
On Tue 23 Jul 2024 at 15:00:12 (-0400), Greg Wooledge wrote:
> On Tue, Jul 23, 2024 at 13:38:48 -0500, David Wright wrote:
> > On Tue 23 Jul 2024 at 09:31:36 (-0400), Greg Wooledge wrote:
> > > On Tue, Jul 23, 2024 at 23:22:52 +1000, Keith Bainbridge wrote:
> > > > The day# in my command prompt increments when I start in the morning. 
> > > > Maybe I need to press enter.
> > > 
> > > That makes it sound like you're setting the YEAR et al. variables in the
> > > PROMPT_COMMAND variable.
> > > 
> > > If that's the case, it's *less* wrong, but only a little bit.  You still
> > > have the issue that the date might change while you're sitting at a
> > > stale shell prompt from yesterday, with stale date/time variables.
> > 
> > Actually, that is what I do want (the time—the date not so much).
> > That tells you when the last command finished. Press Return before
> > you start a command and you get some idea of how long it takes
> > to run. For the current time, press Return.
> > 
> > I think putting the time±date in one's prompt is pretty popular,
> 
> Sure.  That's a completely different problem from what Keith is describing,
> though.
> 
> Putting date/time expansions into your PS1 (prompt) causes the system
> time to be retrieved when the prompt is displayed.  The date/time strings
> are rendered and displayed, and then not remembered by the shell.

Yes, I think I misinterpreted what you were criticising, sorry.

> What Keith is doing is storing components of the date/time in variables
> at shell startup, and then using them at some unspecified point in
> the future to create a directory.  This causes issues when the shell
> survives through a day transition (midnight).
> 
> Keith's workflow might work well if he rigorously logs out (or at least
> closes all shells) every night before midnight, and logs in (or re-opens
> his shells) in the morning.  But even then, it's still a questionable
> implementation.  Anything that relies on a human being to remember to
> do something is eventually going to fail.
> 
> A safer implementation would retrieve the current date at the moment
> when it's needed.  Your PS1 string does this.

Yes, he should be able to achieve his ends with no variables
at all (using bash), unless he wants to parameterise the
/mnt/data/keith/Documents/ part of the path. Something like:

  #!/bin/bash
  mkdir -p "/mnt/data/keith/Documents/copying-$(date --iso-8601)-dir" && cd "$_"
  cp whatever-files-are-to-be-copied ./

If that file is executable and called /path-to/copy-files,
then an entry like:

  */2 * * * * [ -x /path-to/copy-files ] && /path-to/copy-files

in his crontab should run it every couple of minutes (to test it).

Using --iso-8601, or a format like it, will make the directories
sort in the right order. Was using daynumber an attempt to skirt
round this issue? If so, the year had better come first.

Is this what the OP is after?

Cheers,
David.



Re: Debian Sid. General questions.

2024-07-23 Thread David Wright
On Tue 23 Jul 2024 at 09:44:02 (+), Michael Kjörling wrote:
> On 22 Jul 2024 21:20 -0500, from deb...@lionunicorn.co.uk (David Wright):
> > The machine I'm typing on is running bullseye and was installed with
> > linux-image-5.10.0-13-amd64. It's running linux-image-5.10.0-31-amd64
> > now, so that's 22 different versions over 27 months, and a lot of work
> > put in by the Debian Kernel Team, thanks. I think Kroah-Hartman's
> > praise still applies.
> 
> It is a lot of work.
> 
> Note that the -13- and -31- respectively refers to the ABI version of
> the build, which isn't necessarily the same thing as an updated
> kernel. It's not that uncommon for kernel updates to not increase the
> ABI version tag, so in practice your system has probably seen many
> more than 22 kernels over that period of time. (Without having
> checked, I wouldn't be surprised if the real number of kernel updates
> is on the order of 2-3 times the number of ABI bumps.)

Yes, I was only counting the versions that *stable users access, as
package upgrades. The corresponding number of versions, when you count
featuresets and flavours etc, that the developer/maintainer probably
sees, is far higher but not easily determined by us from APT's lists.

But my point was just that I'm not running a kernel that dates from
either August 2021 (bullseye release) or April 2022 (this installation),
which was implied by "Years between releases means software will get
stale and accumulate bugs that will lead to vulnerable and exploitable
hosts on the network."

Cheers,
David.



Re: How to update environment variable output

2024-07-23 Thread David Wright
On Tue 23 Jul 2024 at 09:31:36 (-0400), Greg Wooledge wrote:
> On Tue, Jul 23, 2024 at 23:22:52 +1000, Keith Bainbridge wrote:
> > The day# in my command prompt increments when I start in the morning. Maybe 
> > I need to press enter.
> 
> That makes it sound like you're setting the YEAR et al. variables in the
> PROMPT_COMMAND variable.
> 
> If that's the case, it's *less* wrong, but only a little bit.  You still
> have the issue that the date might change while you're sitting at a
> stale shell prompt from yesterday, with stale date/time variables.

Actually, that is what I do want (the time—the date not so much).
That tells you when the last command finished. Press Return before
you start a command and you get some idea of how long it takes
to run. For the current time, press Return.

I think putting the time±date in one's prompt is pretty popular,
judging by the number of ways of specifying it are listed in
man bash  under PROMPTING. As well as employing those special
characters for the time elements, you can use the format specifiers
from the date command if you prefer: just wrap then in the \D{…}
special "character".

I use both myself: just the 24-hour time in xterms (where I have
xclock showing "Tue 23" and a swissclock for good measure), but
in VCs I include Tue23 because there's no other calendar reminder.

  case "$TERM" in
*linux*)
PS1+='\H!\u \D{%a%d %T} \w\$ \['$(tput sgr0)'\]'
;;
*)
PS1+='\H!\u \t \w\$ \['$(tput sgr0)'\]'
;;
  esac

(Note: the += is because my PS1 already has colour and error code
information within it. Also, confusingly, %T and \t both yield
24-hour times in their respective positions.)

> Really, the fundamental problem here is that you should not be storing
> date/time information in long-lived variables, and then trying to use
> those variables at an indeterminate point in the future.
> 
> Anything that needs to act upon the current date should fetch the current
> date immediately before acting.

Cheers,
David.



Re: Debian Sid. General questions.

2024-07-22 Thread David Wright
On Mon 22 Jul 2024 at 18:10:24 (-0400), Jeffrey Walton wrote:
> On Mon, Jul 22, 2024 at 5:41 PM Andy Smith  wrote:
> > On Mon, Jul 22, 2024 at 01:38:07PM +0500, 타토카 wrote:
> > > [...]
> > > 4. As I know Debian Sid does not have some packages like Arch, why? They
> > > have rolling releases? I mean packages, for example, hyprland.
> >
> > Debian sid is not a rolling release. Debian does not have a rolling
> > release. Additionally, Debian sid isn't a release of any
> > description.
> >
> > You should not be using Debian sid.
> 
> I wish Debian had a rolling release. Years between releases means
> software will get stale and accumulate bugs that will lead to
> vulnerable and exploitable hosts on the network.
> 
> A perfect case on point is "TTY1 layer bug",
> .
> Folks thought it was benign, and did not patch it or port existing
> patches. It was one of those accumulated bugs that would get cleared
> at the next major release. Then, years after it was disclosed, someone
> figured out it was exploitable.
> 
> A rolling release of 6 months would have cleared the bug close to the
> time it became known. It would not have festered for years.
> 
> Fixing a bug close to when it becomes known is evidence of a [more]
> secure system. That's because most compromises happen three or six
> months after the bug was disclosed and patches were available. And the
> compromises continue for years afterwards. Confer,
> .

I'm not sure what your point is. This article was written in 2016,
at which time jessie was the stable release and wheezy was oldstable.
The kernel version in wheezy was 3.2. The article says:

 "However, running old kernel doesn’t mean it’s a bad thing. There are
  genuine reasons why people do run older kernels, and that is why
  Linux maintains LTS releases, updating them, largely thanks to
  Kroah-Hartman’s coordination work, with bug fixes long after the bulk
  of development work has moved on to newer versions of the kernel. But
  what good is fixing those older releases if companies are not pushing
  the patches to their Linux-dependent devices?

 "Over four years old, the 3.2 kernel is an LTS release and still is
  getting two fixes a day and being updated on a regular basis: Kernel
  developer Ben Hutchings is doing a release every other week. The
  Debian community is doing an excellent job at taking those patches
  and keeping it updated.

 "“A non-profit organization built of volunteer people is doing a
  better job than some of the largest Linux providers out there. That’s
  insane. That’s bad. Base yourself on Debian or update your kernel
  overtime,” Kroah-Hartman said."

The machine I'm typing on is running bullseye and was installed with
linux-image-5.10.0-13-amd64. It's running linux-image-5.10.0-31-amd64
now, so that's 22 different versions over 27 months, and a lot of work
put in by the Debian Kernel Team, thanks. I think Kroah-Hartman's
praise still applies.

Cheers,
David.



Re: update system periodically

2024-07-22 Thread David Wright
On Sun 21 Jul 2024 at 22:01:58 (-0600), Charles Curley wrote:
> On Sun, 21 Jul 2024 18:43:28 -0500
> David Wright  wrote:
> 
> > I run the following from root's crontab:
> > 
> >   apt-get -qq -o Acquire::http::Proxy="http://192.168.1.14:3142/";
> >   update && apt-get -qq -d -o
> > Acquire::http::Proxy="http://192.168.1.14:3142/"; dist-upgrade && find
> > /var/cache/apt/archives/ -name '*deb'
> > 
> > (That's all on one line.)
> 
> Suggestion: rather than have the
> "Acquire::http::Proxy="http://192.168.1.14:3142/"; in the command, use
> the package auto-apt-proxy to detect proxy servers for you.

I might have, had it existed at the time I wrote this. (My cron
line has been around for more than a couple of decades, as has
my use of proxies.)

> Suggestion: rather than run it from cron (or a systemd timer), look
> into unattended-upgrades.

For the OP, I would rather recommend cron-apt. I was a little guarded
in my previous advice as the OP has dabbled with ubuntu and might have
installed packages other than pure Debian 11, so automatic upgrades
themselves might be unwise. The OP is also learning to write scripts,
so a one-liner like mine might be attractive.

When an email has been generated, I use the following scripts to
perform the upgrades. (To complete the set of APT commands I run
as root, I include the fourth line. Each one is on a single line.)

# apt-get -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  update && apt-get -d -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  dist-upgrade; apt-get upgrade; read -p 'Ctrl-C to avoid clean' _;
  apt-get clean

# apt-get -d -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  dist-upgrade && apt-get dist-upgrade ; read -p 'Ctrl-C to avoid
  clean' _; apt-get clean

# apt-get --purge autoremove # take care as this can uninstall lots

# apt-get -s -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  install xxx

Call me old-school.

Cheers,
David.



Re: Debian Sid. General questions.

2024-07-22 Thread David Wright
On Tue 23 Jul 2024 at 00:25:27 (+0500), 타토카 wrote:
> I have read on the official Debian website about sid (in russian version):
> "Maybe. There was one real case where PAM broke. PAM checks all users, so
> without PAM no one can login, even as a root. If you work in a precarious
> environment, you must be able to handle such situations.".
> I don't know how to handle with this situation with PAM. How can I solve
> this problem, when it will be nessesary?
> 
> Hyprland is tilling window manager.
> 
> And what were the 2 times of problems, which you have faced for two
> decades? How did you solve them?

Google's top hit for   pam broken in sid   was:

  https://lists.debian.org/debian-user/2001/06/msg03589.html

One fix is in this post, another is in the follow-up. To run sid,
you ought to be able to think up and do receovery actions like
that, though bear in mind that sid is not an installable distribution
because packages go "missing" at times.

Were I running sid, I would not only keep backups of my own stuff,
but also of all the packages that I had installed. With stable,
I don't bother to backup packages, or even the OS itself except
for everything I've configured/changed.

Re: archlinux, from what I've read, I don't think you can make
comparisons with sid. One could make lists of similarities and
differences between it and testing. But Debian doesn't really
have a rolling release, partly because the attention of the
developers turns to bug-squashing the frozen testing before
its release, usually about every couple of years.

Cheers,
David.



Re: update system periodically

2024-07-21 Thread David Wright
On Mon 22 Jul 2024 at 05:47:58 (+0800), cor...@free.fr wrote:
> I have been running an old debian 11 for many days.
> is it safe to run 'apt upgrade' and 'apt update' periodically?
> for example put them into crontab.

I run the following from root's crontab:

  apt-get -qq -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  update && apt-get -qq -d -o Acquire::http::Proxy="http://192.168.1.14:3142/";
  dist-upgrade && find /var/cache/apt/archives/ -name '*deb'

(That's all on one line.)

If find lists any .deb files, it sends me an email. I use
apt-cacher-ng on one machine as a proxy, which you might not,
in which case omit both occurrences of:

  -o Acquire::http::Proxy="http://192.168.1.14:3142/";

> I ask this question because I am worried that some software updates
> may conflict with each other after running in this way, resulting in
> system unavailability.

They shouldn't do if you're actually running Debian 11. But I prefer
to see the upgrades themselves performed, so I'm happy for just the
downloads and consequent notification to be automated.

Cheers,
David.



Re: Switch boot entry by power-on reason

2024-07-21 Thread David Wright
On Sun 21 Jul 2024 at 10:45:59 (+), David wrote:
> On Sun, 21 Jul 2024 at 09:46, Thomas Schmitt  wrote:
> > hede wrote:
> 
> > > Technically it should be possible, as dmidecode can show the reason:
> > > Handle 0x0001, DMI type 1, 27 bytes
> > > System Information
> > > ...
> > > Wake-up Type: LAN Remote
> > > vs.
> > > Wake-up Type: Power Switch
> >
> > The statement in man dmidecode "DMI (some say SMBIOS)" caused me to search
> > for "GRUB SMBIOS" which yields:
> >   https://www.gnu.org/software/grub/manual/grub/html_node/smbios.html
> >
> > This looks like a low-level user interface to
> >   https://en.wikipedia.org/wiki/System_Management_BIOS
> >
> > Diving into
> >   https://codesearch.debian.net/search?q=package%3Admidecode+Wake-up+Type
> > leads me to
> >   https://sources.debian.org/src/dmidecode/3.6-1/dmidecode.c/?hl=4498#L4498
> > which lets me guess that your answer is in
> >   smbios --type 1 --get-byte 24
> > with the possible values told by function dmi_system_wake_up_type()
> >   https://sources.debian.org/src/dmidecode/3.6-1/dmidecode.c/?hl=513#L513
> >
> > Consider to explore this in the GRUB shell and (if needed) to find
> > somebody who can help to develop a smart configuration which makes use of
> > the result to offer different boot menus.
> 
> Hi, well it looks like Thomas has done most of the work and provided most of
> the solution. Assuming that is the case, I suggest that an easy way to 
> activate
> a different menu entry would be to use the value found by the above research 
> to
> change the value of 'default' in grub.cfg
> 
> So your manually written grub.cfg. would contain something like the below 
> lines
> in addition to whatever other content you need to boot the machine.
> 
> smbios --type 1 --get-byte 24 --set result
> if [ "${result}" == "REPLACEME" ] ; then
> default=1
> else
> default=2
> fi
> 
> Hopefully all that remains is to use the above information to figure out
> the actual value needed to replace my REPLACEME placeholder.
> And change '1' and '2' to match whatever menuentry you would like to
> activate.
> 
> Don't be discouraged by all the junk that the autogenerated grub.cfg
> contains these days, most of it is not necessary. I have never had any
> trouble ignoring it completely and just writing something simple in the style
> of grub1. That way you can take advantage of the very useful scripting
> language that grub2 provides, and hopefully make it do exactly what you want.

"All the junk" that you're ignoring will be the code that implements
properly what you're trying to do with Grub. Overall, it's a hack, but
you don't need to hack on top of the hack.

Edit /etc/default/grub and change:

  GRUB_DEFAULT=0

to:

  GRUB_DEFAULT=saved

and then regenerate your grub.cfg. Then type in:

  # grub-set-default 0

This will write a file /boot/grub/grubenv containing:

  # GRUB Environment Block
  saved_entry=0
  # … … …

padded out to 1024 bytes. By default, Grub will boot the first
entry in grub.cfg as it does now. That's all designed into the
Grub infrastructure.

The hack is booting Windows after starting via the power button.

. determine the reason as already outlined in the thread.
. if you now require windows instead, the commands to run are:

# grub-reboot 'foo'

  or:

# grub-reboot 'foo>bar'

  and then:

# reboot

  where foo is the $menuentry_id_option of a top-level menuentry,
  and bar is the $menuentry_id_option of a menuentry under a submenu.
  They are typically looong strings.

. if you require linux, you can either carry on running what you've
  got (linux), or reboot in a similar manner to some other implementation.

IIRC (it's been many many years) Grub generates Windows entries as
top-level rather than in submenus, with some ?16-digit UUID as the
$menuentry_id_option.

How it works: grub-reboot adds 'next_entry=foo>bar' into grubenv,
which gets read and enacted when you reboot (and erased, of course).

Cheers,
David.



Re: Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

2024-07-19 Thread David Wright
On Sat 20 Jul 2024 at 12:13:28 (+1200), Ash Joubert wrote:
> On 2024-07-20 03:39, Celejar wrote:
> > Thanks much!
> [...]
> > As per another message in this thread, I've already filed a bug against
> > linux-image-6.9.9-amd64, but I suppose I should update the report with
> > this information, indicating that it's not really a problem with that
> > package.
> 
> You are welcome! Please close your kernel bug report.
> 
> Hard to pin this on the firmware package either as the recommends is
> arguably the right behaviour to prevent missing firmware at boot time,
> but the recommends has this surprising side-effect for those with a
> /boot partition with insufficient free space for such a large firmware
> package. It is not dangerous because the old initrd is not removed
> until the new one is written successfully, but it is annoying!

According to Debian policy: "The Recommends field should
list packages that would be found together with this one
in all but unusual installations."
   -

So if my old Broadcom ethernet card requires firmware-misc-nonfree
(the package for "firmware blobs which are not individually large
enough to warrant a standalone package"), it would be /unusual/ for
the installation not to need some Nvidia firmware as well?

That doesn't seem to make any sense. Suggests might be a better
relationship, but even that seems a stretch to me.

 "Suggests […] is used to declare that one package may be more useful
  with one or more others. Using this field tells the packaging system
  and the user that the listed packages are related to this one and
  can perhaps enhance its usefulness, but that installing this one
  without them is perfectly reasonable."

Cheers,
David.



Listing packages installed on broken system, was systemd errors

2024-07-16 Thread David Wright
On Tue 16 Jul 2024 at 21:35:39 (+0100), mick.crane wrote:
> I installed on a fresh disk the nightly build of Trixie and it works a
> treat and it configured the monitor to it's highest resolution using
> the nouveau module thing.
> Unfortunately I broke my previous Trixie installation trying to get
> rid of the nvidia module.
> It still works with "startx" but the resolution is low.
> Apt let me install the 6.9.8 kernel whereas wouldn't dist-upgrade,
> probably as it had done that before.
> I saw on the net to "update-initrmfs -u" so I did that.
> So I think that earlier install has a kernel now free of the nvidia
> but there must be some systemd left referencing stuff I've deleted
> because there is some message at boot about can't find or load a
> module and X wont automatically start.
> I'd quite like to get that earlier install working cleanly to remind
> me of what was installed.

You don't need to be able to run a system merely to list what's
installed on it. Just mount the root filesystem somewhere, like
/mnt, and type:

  $ dpkg-query --admindir=/mnt/var/lib/dpkg -W --showformat 
'${Package}_${Version}\n' | less

Note the single quotes, to avoid the shell wiping out the format string.

Cheers,
David.



Re: stty permanently undef "start"

2024-07-10 Thread David Wright
On Wed 10 Jul 2024 at 16:00:48 (+0200), Nicolas George wrote:
> Greg Wooledge (12024-07-10):
> > You could -- but if you do so, you should definitely surround it with
> > a check for stdin being a terminal (test -t 0 or equivalent).
> 
> Does bash execute .bashrc when it is not interactive?

Someone might source .bashrc from a binary in order to
access functions that are defined within it.

> Does bash think it is interactive when its input is not a tty?

That would then be irrelevant.

Cheers,
David.



Re: [SOLVED] Re: Acer Aspire 5 A515-45 touchpad suddenly stopped working on debian 12.5

2024-07-06 Thread David Wright
On Sat 06 Jul 2024 at 08:39:57 (+0200), Steinar Bang wrote:
> > Steinar Bang :
> 
> > Sometime (a day or so maybe) before <2024-06-26 Wed 19:59> the touchpad
> > stopped working on my Acer Aspire 5 with a MATE desktop on debian 12.5.
> 
> > At the time the laptop had gone 50 days since the last reboot so I
> > figured something had gone wrong during the time and a reboot would fix
> > it.
> 
> > So in <2024-06-29 Sat 18:07> I did a reboot as a result of "apt
> > full-upgrade" to debian 12.5 and the touchpad still wasn't working.
> 
> > I have been thinking that the cause may be
> >  1. A hardware failure?
> >  2. I accidentially pressed a keyboard combination that disables the
> > touchpad?
> >  3. I have accidentially made some configuration change that disables
> > the touchpad?
> 
> The cause was number 2 and the key is F7 (without pressing the Fn key).
> 
> Pressing F7 gave me the touchpad back.
> 
> I decided to give this yet another try this morning and googled
> combinations of "acer aspire 5 fn key disable touchpad"
> 
> I was told that Fn+F6 and Fn+F7 is supposed to toggle the touchpad on
> many Acer laptops.  But pressing Fn+F6 or Fn+F7 had no more effect than
> anything else I had tried.
> 
> But one thing I discovered was that many people have had the
> disappearing touchpad problem on Acer laptopns, also on Windows, and
> have tried everything around upgrading drivers and even upgrading from
> Windows 10 to Windows 11.  So this is not a debian or GNU/linux specific
> issue. 
> 
> I am always reluctant to reboot but I decided I had to bite the bullet
> and boot into BIOS and see what I could find there.
> 
> But I always, before doing anything, I do a quick google to see what I
> can find, search string "acer aspire touchpad bios", and there I found
> this thread:
>  
> https://www.reddit.com/r/AcerOfficial/comments/ug3xks/touchpad_not_working_at_all_for_my_aspire_5_tried/
> 
> Specifically this posting:
>  
> https://www.reddit.com/r/AcerOfficial/comments/ug3xks/comment/l1iia93/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
> 
> So I tried F6 without Fn and the screen went black. One more press on F6
> and I had the desktop back.
> 
> Then I tried F7 without Fn... nd touchpad was back.
> 
> I fully supports the rants in the posting linked to above.
> 
> Couldn't said it better myself.

The advice I follow whever I acquire a "new" computer¹ (all mine are
cast-offs) is to download any manuals (quickstart, user, service etc)
I can find from sites like www.manualslib.com, check them out, and
archive them. (I also keep any reviews I find.)

These particular buttons have been around for years. The attached is
from the service manual for my Acer TravelMate 3201XCi, manufactured
and documented in 2004, but wrested from my partner in 2014 after
being our only working CorelDraw installation for a couple of years.

To answer the question in the rant, "why the f* does this button
exist": for the same reason that some people set a touchpad timeout
each time a key is struck, to prevent the cursor careering around the
screen when typing, thanks to the ball of the thumb rubbing the touchpad.

¹ or any other technology items or components.

Cheers,
David.


Re: How to get an email notification every time a package is updated

2024-06-30 Thread David Wright
On Sun 30 Jun 2024 at 02:31:28 (-0700), B wrote:
> Thanks for the suggestion, but unfortunately I already researched that
> and there are problems.

On Sat 29 Jun 2024 at 22:46:00 (-0700), B wrote:
> It seems crazy that in all the history of Debian, nobody said "There's
> a package I care about and I want to get immediately when a new
> version is released."

On Sat 29 Jun 2024 at 19:15:55 (-0700), B wrote:
> The packages I want to monitor are arbitrary and specific. The
> distribution and architecture must also be taken into account. For a
> given package, if I want to know about changes in unstable, then it
> must not generate notifications against stable, experimental, source,
> or some other architecture.

Can I ask why?

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-29 Thread David Wright
On Fri 28 Jun 2024 at 15:05:34 (-0500), John Hasler wrote:
> David writes:
> > With chrony, you can monitor the RTC over time and adjust the system
> > clock in accordance with its drift rate at boot time, without
> > correcting the RTC itself, or you can actually set the RTC from the
> > system clock periodically.
> 
> That leads to the probelem that started this thread: system time being
> set incorrectly at boot and then stepped later.
> 
> 
> > The particular problem at shutdown is that there were/are systems, as
> > you described, that write the system time to the RTC without
> > necessarily regarding how you might be running the clock otherwise.
> > That alteration is unknowable for chrony when it restarts after
> > booting.
> 
> Obviously you must make sure that only one process ever writes to the
> RTC.
> 
> Actually you need never write to the RTC at all: just track its offset
> and drift rate.  That would require hacking the boot process to make
> sure only your code ever reads it, though.

I think that's what I wrote in the first half of the sentence at the top.
I don't think you can avoid the kernel setting the system clock before
chrony does, but I don't see the problem with that: chrony just sets it
again when it runs.

So the problem may reduce to how to get resume to run chrony (as the
example) before any user processes run again. There are options to
make that more likely, like keeping chrony resident, and increasing
its scheduling priority, and I have already suggested a method that
might allow systemd to make it certain.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-29 Thread David Wright
On Sat 29 Jun 2024 at 06:53:48 (+0200), to...@tuxteam.de wrote:
> On Fri, Jun 28, 2024 at 02:05:48PM -0500, David Wright wrote:
> > On Fri 28 Jun 2024 at 11:14:34 (-0500), John Hasler wrote:
> > > David writes:
> > > > It's not clear to me which NTP (protocol) packages are set up to use
> > > > the util-linux stuff, assuming you're not rolling your own
> > > > startup/shutdown scripts. (That's the problem in the Subject line, in
> > > > a sense.)
> > > 
> > > Chrony can.  I don't know about Ntpsec.  But that doesn't get the
> > > adjustment made early enough.
> > 
> > By "use the util-linux stuff" I meant use /sbin/hwclock. Neither
> > chrony nor ntpsec can use hwclock by default as they don't list
> > util-linux as a dependency. They use their own binaries. IDK whether
> > you can deliberately configure them to use hwclock instead, or why
> > any one would do so.
> 
> Still they can set (and AFAIK discipline) the "hardware clock", via the
> Linux kernel -- if things are set up this way. See the notes on the Linux
> kernel's "11 minute mode" in the hwclock(8) man page.

I don't think that's a good idea for solving drift correction over
long periods of time. You should periodically check the RTC and
system clocks with NTP, and store the measurements of the RTC, in
order to refine its drift rate over a longer and longer time interval.
Every time you set the RTC, you invalidate any measurements you've
already collected.

Cheers,
David.



Re: How to get the *.deb file?

2024-06-29 Thread David Wright
On Sun 30 Jun 2024 at 06:10:17 (+0200), DdB wrote:
> Hi,
> 
> sometimes, i did fetch the deb file from https://packages.debian.org
> even for another OS than the one, i am running, just to inspect its details.
> 
> This time, i was unable to find/download the deb file for
> https://packages.debian.org/de/sid/parallel
> 
> Could someone more knowledgeable explain, why there seems to be none or
> hint me to a workaround?

Your URL is for the package description page, which lists the
dependencies etc and then the architectures. As parallel is
suitable for all architectures, you would click "All" and arrive at:

  https://packages.debian.org/de/sid/all/parallel/download

which is the page with links for around the world. I downloaded:

  
http://ftp.us.debian.org/debian/pool/main/p/parallel/parallel_20240222+ds-2_all.deb

successfully from the top left link. You would presumably use the
top right link for ftp.de.debian.org instead.

Cheers,
David.



Re: Need help with narroely focused use case of Emacs

2024-06-29 Thread David Wright
On Sat 29 Jun 2024 at 17:08:04 (+0200), Vincent Lefevre wrote:
> On 2024-06-28 20:53:50 +, Michael Kjörling wrote:
> > Yes, it almost certainly can be done with a single sed (or other
> > similar tool) invocation where the regular expression matches
> > precisely what you want it to match. But unless this is something you
> > will do very often, I tend to prefer readability over being clever,
> > even if the readable version is somewhat less performant.
> 
> To match a range inside a regexp, $(rgxg range 1 119) is readable. :)
> 
> rgxg is provided by the package of the same name.

Perhaps best to ignore the narrow focus on 119 in the OP.
For bible verses per chapter, the largest number is 176.
(An accidental choice of 119 might be explained by that
psalm having the most verses. Only Psalms requires three
digits as it happens; I think the runner-up has only about
half that.)

It would be tedious and error-prone to have to specify the
maximum range for each chapter. Different versions of the
bible don't even agree with each other on numbers of verses.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-28 Thread David Wright
On Fri 28 Jun 2024 at 17:03:47 (-0400), Stefan Monnier wrote:

> > David has said that chrony can do fancy things involving the hardware
> > clock.  Maybe you should investigate that solution path.
> 
> I'm trying to find out how to fix it Right, rather than how to work
> around the problem (I already know how to work around the problem).
> 
> Fixing it right requires changing the code that reads the RTC time
> upon wakeup.  In any case, thank you all for your help.
> Apparently none of you have the answer I'm looking for, but you did help
> me narrow down the scope and make more precise what I'm after.
> 
> Indeed I see now that the time is read from RTC to set system time
> directly by the kernel in `kernel/time/timekeeping.c` and
> `drivers/rtc/class.c`.
> So The Right Solution™ apparently involves changes to the kernel.

I can only suggest what you might investigate, as the concepts are
way above my paygrade.

All the user processes are in user.slice, as seen by:

  # systemd-cgls -u user.slice

There are commands shown in   man systemctl   called
freeze and thaw (its inverse):

  freeze PATTERN...
  Freeze one or more units specified on the command line using
  cgroup freezer

  Freezing the unit will cause all processes contained within
  the cgroup corresponding to the unit to be suspended. Being
  suspended means that unit's processes won't be scheduled to
  run on CPU until thawed. Note that this command is supported
  only on systems that use unified cgroup hierarchy. Unit is
  automatically thawed just before we execute a job against the
  unit, e.g. before the unit is stopped.

So could you suspend the system by invoking a system service to
freeze the control group the appropriate unit (user.slice) first?
When the system resumes, the thawing service would be set to run
after the service that steps the clock. (Don't use slewing.)

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-28 Thread David Wright
On Fri 28 Jun 2024 at 14:54:42 (-0400), Greg Wooledge wrote:
> > > It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need
> > > to adjust the HW clock time forward by X seconds because I know it runs
> > > a bit slow."  That information is not available to you.
> > 
> > It is if /etc/adjtime is set properly when you go to sleep.
> > See `hwclock(8)` or `adjtime_config(5)`.
> 
> Yeah, except... you're assuming a workflow that is not real or reliable.

That's why I wrote "It's not clear to me which NTP (protocol) packages
are set up to use the util-linux stuff, assuming you're not rolling
your own startup/shutdown scripts. (That's the problem in the Subject
line, in a sense.)"

Packages like chrony can set up a workflow that retains the clock
information and makes adjustments to the system clock (and, if
required, the RTC) as necessary.

> hobbit:~$ ls -l /etc/adjtime 
> -rw-r--r-- 1 root root 44 Mar  6 07:04 /etc/adjtime
> hobbit:~$ uptime
>  14:47:40 up 29 days,  2:54, 29 users,  load average: 1.58, 1.07, 1.15
> 
> Nothing writes to /etc/adjtime on a regular basis.  It's only written
> if you manually run an hwclock command, or if you change something
> (such as deciding to store your HW clock in UTC instead of local time,
> which is what I did on March 6 after learning that Debian had chosen
> local time when I installed).

Packages like chrony may have an upstream default to use /etc/adjtime,
but AIUI Debian's default is a private, often protected, file.

> > It is if /etc/adjtime is set properly when you go to sleep.
> 
> You cannot assume that adjtime was updated the last time your system
> stopped running, because your system might have stopped running due to
> a crash, instead of a controlled shutdown.
> 
> All of the arguments that are being constructed here are bogus.

You can track the system clock and RTC periodically, and keep the
statistics. Optionally you can also set the RTC at the same time,
but that's not necessary, and a separate decision.

> The *only* thing you know at boot time is what's in the HW clock, and
> if you're really lucky, you'll be able to figure out what time zone
> it's allegedly set to (after reading /etc/adjtime from disk).
> 
> hobbit:~$ cat /etc/adjtime
> 0.00 1708191089 0.00
> 1708191089
> UTC
> hobbit:~$ date -d @1708191089
> Sat Feb 17 12:31:29 EST 2024

I don't think you've mentioned which package(s) you're using to
control your system clock.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-28 Thread David Wright
On Fri 28 Jun 2024 at 11:14:34 (-0500), John Hasler wrote:
> David writes:
> > It's not clear to me which NTP (protocol) packages are set up to use
> > the util-linux stuff, assuming you're not rolling your own
> > startup/shutdown scripts. (That's the problem in the Subject line, in
> > a sense.)
> 
> Chrony can.  I don't know about Ntpsec.  But that doesn't get the
> adjustment made early enough.

By "use the util-linux stuff" I meant use /sbin/hwclock. Neither
chrony nor ntpsec can use hwclock by default as they don't list
util-linux as a dependency. They use their own binaries. IDK whether
you can deliberately configure them to use hwclock instead, or why
any one would do so.

> > The critical part of the whole operation AIUI is not what happens at
> > startup,
> 
> The tricky part, I think, is correcting the rtc before it is used to
> initialize the system time.  Otherwise you'll still have to step or slew
> the system time.
> 
> > but at shutdown: writing to the RTC, and the correct preservation of
> > its state.
> 
> You write to the rtc and to /etc/adjtime periodically at a rate
> determined by the computed hot drift rate and also during a controlled
> shutdown.

With chrony, you can monitor the RTC over time and adjust the system
clock in accordance with its drift rate at boot time, without
correcting the RTC itself, or you can actually set the RTC from the
system clock periodically.

The particular problem at shutdown is that there were/are systems, as
you described, that write the system time to the RTC without
necessarily regarding how you might be running the clock otherwise.
That alteration is unknowable for chrony when it restarts after booting.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-28 Thread David Wright
On Fri 28 Jun 2024 at 09:41:06 (-0500), John Hasler wrote:
> Stefan writes:
> > The question remains: how to make use of that info upon wakeup to
> > adjust the "initial" time before NTP takes over.
> 
> hwclock -a can do this.

Sure it can.

> If you use it be sure ntpsec isn't trying to do
> the same thing.

It's not clear to me which NTP (protocol) packages are set up to
use the util-linux stuff, assuming you're not rolling your own
startup/shutdown scripts. (That's the problem in the Subject
line, in a sense.)

Does ntpsec have this facility built in, or are you expected to
link it up to hwclock?

The critical part of the whole operation AIUI is not what happens
at startup, but at shutdown: writing to the RTC, and the correct
preservation of its state.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-28 Thread David Wright
On Fri 28 Jun 2024 at 10:06:23 (-0400), Greg Wooledge wrote:
> On Fri, Jun 28, 2024 at 09:48:12 -0400, Stefan Monnier wrote:
> > Oh, indeed, thanks.  I had computed it manually from
> > `journalctl | grep stepped` and it gave close enough results.
> > The question remains: how to make use of that info upon wakeup to adjust
> > the "initial" time before NTP takes over.
> 
> As I understand it, the drift is used to speed up or slow down the
> system clock, so that it more closely tracks real time, and needs
> fewer nudges by NTP.
> 
> As such, it really has nothing to do with how the system clock is
> initialized at boot time (or wake-from-suspend time? I don't do laptops).
> 
> At boot time, the system clock is initialized by reading the hardware
> clock, with the assumptions that the hardware clock is not very
> accurate, but is better than nothing.  The system clock will be
> adjusted by NTP once the network is up and once the NTP daemon has had
> a chance to communicate with its servers and figure out what time it
> actually is.
> 
> > Indeed, I could try and shorten the time before the NTP info takes
> > precedence over the RTC-derived initial approximation (I haven't found
> > any way to tell ntpsec to do that, short of limiting the maximum
> > interval between pollings or maybe killing&restarting the deamon, both
> > of which seem too crude for my sense of aesthetics), but I'm more
> > interested in improving the initial approximation.
> 
> I'm failing to understand your thought process here.
> 
> The hardware clock has a time, which is loaded into the system clock
> to initialize it.  That's it.  The only variable factor here is whether
> the hardware clock's time is in UTC or some local time zone.
> 
> You can't do anything with drift at this point, because you don't actually
> know how long you were asleep.  All you know is the current HW clock time.
> It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need
> to adjust the HW clock time forward by X seconds because I know it runs
> a bit slow."  That information is not available to you.

In chrony, you'd use its rtcfile directive, which saves the time
when it last made a correction. Here's an outline:

   rtcfile file
   The rtcfile directive defines the name of the file in which
   chronyd can save parameters associated with tracking the
   accuracy of the RTC.

   An example of the directive is:

   rtcfile /var/lib/chrony/rtc

   chronyd saves information in this file when it exits and when
   the writertc command is issued in chronyc. The information
   saved is the RTC’s error at some epoch, that epoch (in seconds
   since January 1 1970), and the rate at which the RTC gains or
   loses time.

   So far, the support for real-time clocks is limited; their
   code is even more system-specific than the rest of the
   software. You can only use the RTC facilities (the rtcfile
   directive and the -s command-line option to chronyd) if the
   following three conditions apply:

1. You are running Linux.

2. The kernel is compiled with extended real-time clock
   support (i.e. the /dev/rtc device is capable of doing
   useful things).

3. You do not have other applications that need to make use
   of /dev/rtc at all.

Perhaps ntpsec can do something similar.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-27 Thread David Wright
On Wed 26 Jun 2024 at 12:50:32 (-0400), Greg Wooledge wrote:
> On Wed, Jun 26, 2024 at 11:25:38 -0500, John Hasler wrote:
> > I wrote:
> > > 12 Noon and 12 Midnight works.
> > 
> > David Wright wrote:
> > >  Except that The Wanderer's "strictly correct" version, M for noon,
> > > is out there in some pre-2008 documents.
> > 
> > If you use M for noon you should use either AM or PM for midnight.

That was the case in 1984¹, when they used PM, which agrees with the
expression "midnight on Saturday", and with the terminology of
deadlines, both of which assume that midnight belongs to the end
of the day. But it's still somewhat arbitrary.

By the 2000 edition, they decided to eliminate M in favour of 12 AM,
presumably because of 12 PM being already established for midnight.

Then, in the 2008 edition, they swapped AM and PM around, without
so much as a footnote.

> Or... you could STOP confusing yourself and everyone around you, and
> use the correct, standard notation.
> 
> 12:00 AM = Midnight
> 12:00 PM = Noon
> 
> Like it or not, this is what people agreed on, decades or centuries ago.
> If you use this, you will be understood.  If you make up your own crazy
> crap, you will not be.  And then you risk polluting your mind with your
> made-up crap to the point where you can no longer remember what the
> correct versions are.

I don't think that adopting AM/PM at 12 o'clock is some centuries-old
tradition, with such a recent volte-face. The best idea is just to
avoid them both. As the Chicago Manual of Style online FAQ says:

 "Q. To me, 12:00 is either noon or midnight, never a.m. or p.m.
 I keep seeing copy that says “before 12 p.m.” and I can’t
 convince the copywriters that this is confusing. Can you cite any
 rule that would clarify this once and for all?

 "A. Yes. Please see CMOS 9.38: “Except in the twenty-four-hour system
 (see 9.39), numbers should never be used to express noon or
 midnight (except, informally, in an expression like twelve o'clock
 at night). Although noon can be expressed as 12:00 m. (m. =
 meridies), very few use that form. And the term 12:00 p.m. is
 ambiguous, if not illogical.”

I was taught that at school in the 1950s. It seems it got forgotten.

¹ various editions of US Government Printing Office Style Manual.

Cheers,
David.



Re: How to use /etc/adjtime

2024-06-27 Thread David Wright
On Thu 27 Jun 2024 at 12:48:03 (-0400), Stefan Monnier wrote:
> I have a machine whose RTC clock is drifting significantly and it is
> often suspended for several days.  I run NTP so the drift I see when
> I wake the machine up gets fixed by "stepping" the clock after a while,
> but that can take a while and I'd like to improve this
> intermediate situation.

Do you really run ntp? You might already be running ntpsec,
its replacement.

> The /etc/adjtime is supposed to be there for such purposes but it seems
> to be mostly unused: I assume its "UTC" setting is respected but the
> first and second lines indicate it has not been updated since 2015
> (i.e. when that Debian install was used in another machine).

You might find your clock drift in /var/lib/ntpsec/ntp.drift
or wherever /etc/ntpsec/ntp.conf specifies it.

> I have two questions:
> 
> - How can I get Debian to use this file when waking up the machine from
>   suspend (which would presumably change the file by updating the first
>   line's "last adjust time")?
> 
> - How can I get `ntpd` to adjust the first line's "drift factor" when it
>   steps the clock?
> 
> The second question is less important (I can write the drift factor by
> hand, e.g. in case `ntpd` is not being told when the clock is (re)set
> based on the RTC, making it impossible for it to compute a drift factor).

I don't know how to speed up correcting the clock as I use chrony,
but ntpsec may have similar directives available.

Cheers,
David.



Re: how2 format a flash drive

2024-06-25 Thread David Wright
Entire attribution and quote removed to avoid the mailing list
treating this post as spam.

I got the impression that Lee used windows in the past (and may
still), which is why I didn't suggest the same as Joe. (Lee did
write "on Debian").

And by devices, I was thinking more of TVs, printers, scanners,
set-top boxes, etc.

One of our six TVs can handle ext2/3; nothing else can.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-25 Thread David Wright
On Mon 24 Jun 2024 at 23:34:45 (+0800), Bret Busby wrote:
> On 24/6/24 21:41, Erwan David wrote:
> > Le 24/06/2024 à 22:38, Curt a écrit :

> > > When my mom came to visit one time in the nineties she requested I
> > > change my alarm clock to AM PM time (it is now 15:25 here in the Gallic
> > > regions, where the weather has finally turned summery after
> > > forty days and
> > > forty nights of rain).

> > AM/PM would not be so strange if between 11AM and 1 PM it was 12 AM ...
> > 
> The correct format for the 24 hour clock time, does not include a
> colon between the hours and the minutes - 10:30pm is 2230 in the 24
> hour clock format.

I have failed miserably to find a clock display in our house that
doesn't include a colon in the time display. So I thought Google's
Images page might have some and, indeed, there are one or two.

Where did you find this "correct" format? AFAICT, adding colons
to a string of digits is used as a self-documenting way of indicating
it's a time, whether time-of-day or an interval or period.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-25 Thread David Wright
On Mon 24 Jun 2024 at 17:12:18 (-0500), John Hasler wrote:
> The Wanderer writes:
> > (Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM,
> > where the standalone M would stand for "midnight". That does expose one
> > unfortunate weakness of this system: unless you introduce an additional
> > layer of complexity, e.g. using "00:00 M", the notations for noon and
> > midnight would be identical.)
> 
> 12 Noon and 12 Midnight works.

Except that The Wanderer's "strictly correct" version, M for noon,
is out there in some pre-2008 documents. We've been here before:

  https://lists.debian.org/debian-user/2019/09/msg00471.html

Cheers,
David.



Re: how2 format a flash drive

2024-06-25 Thread David Wright
On Tue 25 Jun 2024 at 16:23:16 (+0200), Thomas Schmitt wrote:
> Lee wrote:
> > My question is: how do I reformat the flash drive so it's usable as a
> > "normal" flash drive again?
> 
> You have to delete the partitions of the USB stick which came with
> the ISO.
> Then you create one or more partitions.
> Then you format them to a writable filesystem each.
> 
> If it shall serve for file exchange with MS-Windows or Macs, then you
> probably want just one partition with FAT as filesystem.
> 
> I would do the first and second step by program "fdisk" and the third
> step by program "mkfs.fat".
> If you prefer a GUI program, look for GParted or what your desktop
> offers for the tasks of partitioning and filesystem formatting.

Of course, we're not told what "normal" means, what was tried,
nor how normality was tested. It's possible that they need to
use, say, mkdosfs to get back to the state in which USB sticks
are typically bought, so it can be plugged into other devices.

Cheers,
David.



Re: Maximum size .bash_aliases file

2024-06-25 Thread David Wright
On Tue 25 Jun 2024 at 18:46:26 (+1000), Keith Bainbridge wrote:
> On 23/6/24 00:52, David Wright wrote:
> > > Excellent. Now how do we get our MUA to do that when replying to mail,
> > > which is where I saw what I thought was a system error - but in fact
> > > was a misinterpretation.
> > I don't see the point. The email has a "Date:" header.
> 
> Sounds like I'm the only one who mis-read the date format when I
> raised the query originally.
> 
> Is David writing at 00:52 or is that time UTC?

Why are you asking that? You're the person who caused the string:
  "On 23/6/24 00:52, David Wright wrote"
to be entered into this thread. If you want to know when I wrote
that post, then look at its Date: header. I can't say it any
clearer than that. It's here; look, I'll quote it:

✄✄✄✄

  Date: Sat, 22 Jun 2024 09:52:08 -0500 ←-- here!
  From: David Wright 
  Subject: Re: Maximum size .bash_aliases file
  X-Original-To: deb...@lionunicorn.co.uk
  X-Original-To: lists-debian-u...@bendel.debian.org
  Reply-To: debian-user@lists.debian.org
  
  On Sat 22 Jun 2024 at 18:35:34 (+1000), Keith Bainbridge wrote:
  > On 21/6/24 14:28, David Wright wrote:
  > > You could pronounce your time written above as:
  > >
  > >"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"
  >
  > Excellent. Now how do we get our MUA to do that when replying to mail,
  > which is where I saw what I thought was a system error - but in fact
  > was a misinterpretation.



That's as I see it. And on the web, attached.

Cheers,
David.


Re: Publishing Formats

2024-06-24 Thread David Wright
On Mon 24 Jun 2024 at 22:34:39 (+), Russell L. Harris wrote:
> Someone gave me an old SCEPTRE display with a screen 11.5 inch by 22
> inch.  I never before saw the usefulness of a wide screen.
> 
> A reader such as Atril can take advantage of the wide screen, allowing
> me to zoom in until the type size is comfortable, without the need to
> scroll left and right to read each line.

Scrolling side to side, particularly with a mouse, is very
frustrating, and up and down can be nearly as bad for
reading two-column pages.

But AFAICT, at the 150% magnification that the OP of the other
subthread¹ said was comfortable, the document in question,
TFP2021.pdf, should be just readable on a screen only 11" width,
with no side-to-side scrolling necessary except for the radar
plots (fig 2) and, of course, the landscape format appendix 3
tables.

This does rely, however, on the ability of the viewer to scroll
vertically, at will, without the horizontal position being disturbed,
as xpdf, for example, can do. (I've never seen atril.)

¹ "Needed tool for vision-impaired".

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-23 Thread David Wright
On Sun 23 Jun 2024 at 08:41:51 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 23:25:43 -0500, David Wright wrote:
> > creation of Pacific/Kiritimati (+14:00), which became a press
> > story at the start of the new millennium.
> > 
> > $ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
> > Sun Jun 23 04:24:54 Pacific 2024
> > Sun Jun 23 13:09:54 +0845 2024
> > $ 
> 
> Typo there; you misspelled "Kiritimati" in the command.
> 
> hobbit:~$ TZ=Pacific/Kiritimati date; TZ=Australia/Eucla date
> Mon Jun 24 02:39:17 +14 2024
> Sun Jun 23 21:24:17 +0845 2024

Yes, I corrected it, but then carelessly pasted the incorrect lines.

> The fact that date(1) treats any misspelled or otherwise incorrect TZ
> variable as if it were UTC, but then goes on to write the mispelled
> time zone name in its *output*, as if it were actually being recognized,
> has tripped me up in the past.  I really wish it would just throw an
> error... but it doesn't.

Yes, In the meantime, a function something like this might help:

  $ type whattime 
  whattime is a function
  whattime () 
  { 
  [ -z "$1" ] && msgerr "Usage:   ${FUNCNAME[0]} place
  prints the present time at place (a filename in the zoneinfo lists).
  For today's expiration (AoE), use the legacy name, GMT+12." && return 
1;
  local Where;
  find /usr/share/zoneinfo/ \( -type f -o -type l \) | sed -E 
's/^[^A-Z]+//;s/GMT\+12/AoE/' | grep -v [0-9] | sed -E 's/AoE/GMT\+12/' | sort 
-u | grep -i -e "^$1$" -e "/$1$" | while read Where; do
  printf '%s ' "$Where";
  TZ="$Where" date '+%Y-%m-%d %T %z %A';
  done
  }
  $ for j in kiritimati eucla comodrivadavia samoa gmt+12 factory; do whattime 
"$j"; done
  Pacific/Kiritimati 2024-06-24 13:54:22 +1400 Monday
  Australia/Eucla 2024-06-24 08:39:22 +0845 Monday
  America/Argentina/ComodRivadavia 2024-06-23 20:54:22 -0300 Sunday
  Pacific/Samoa 2024-06-23 12:54:22 -1100 Sunday
  US/Samoa 2024-06-23 12:54:22 -1100 Sunday
  Etc/GMT+12 2024-06-23 11:54:22 -1200 Sunday
  Factory 2024-06-23 23:54:22 - Sunday
  $ 

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Sat 22 Jun 2024 at 12:31:41 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 09:52:39 -0500, David Wright wrote:
> > On Fri 21 Jun 2024 at 07:15:32 (-0400), Greg Wooledge wrote:
> > > > If I boot up two computers
> > > > and they display different times, what term is appropriate in your
> > > > opinion to describe the time displayed?
> > > 
> > > They're out of sync.  Or, at least one of them is.
> > 
> > No, the kernel clocks are all in sync.
> 
> Then you were unclear.  You said "they display different times".  That
> means one of them is wrong.  The other one may be right, or they may
> both be wrong.

None of them is wrong. They're both showing the time appropriate for
the nationality of the passengers who are going to be directed to them.

> > > Or did you mean "the same time, but in two different time zones"?  If
> 
> The following are the same time, but in two different time zones:
> 
> 12:00:00 -0500
> 13:00:00 -0400
> 
> The following are different times:
> 
> 12:00:00 -0500
> 12:26:00 -0500
> 
> > Yes, they're set as desired.
> 
> So you meant "the same time, but in different time zones".  You should
> have said that.

That's how you and I see them, but a passenger from Bahrain, say,
sees things differently. They just want to be directed to a system
on Bahraini time, just like ones at home.

That expression caused consternation in some.

> Pick any damned word you want, then.  I'm done caring.

Yes, I picked "system", as in Operating System, and not Kernel.

Cheers,
David.



Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Sat 22 Jun 2024 at 12:26:05 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 09:51:32 -0500, David Wright wrote:
> > On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
> > > set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are 
> > > UTC%z"
> 
> > I think you need to set attribution, not date_format. For example,
> >   set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
> > is my own. The %{…} braces indicate using the sender's time zone.
> 
> The default value of attribution contains %d which references the
> date_format variable.  The "!" in the date_format variable says to
> use the C locale when writing the day-of-week and month abbreviations,
> rather than whatever your regular locale would call them.
> 
> I'm using this:
> 
> set date_format="!%a, %b %d, %Y at %H:%M:%S %z"

I didn't mean that it won't work.

The attribution format is designed for the benefit of recipients.
The date_format is designed to be available for constructing
strings like indexes and folder lists for the user, as well as
external-facing uses. You might want to add text like "where clocks
are" to the top of a message, but it would be tedious to have a
column of
  where clocks are
  where clocks are
  where clocks are
  where clocks are
in an index.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Sun 23 Jun 2024 at 12:52:55 (+1000), Keith Bainbridge wrote:

> Have you ever pondered why the 'international date line' is so convoluted?

Only on the odd occasion when an area decides to cross it, for
whatever reason. Like Samoa recently. And before that, the
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.

> As for odd time zones, we have a narrow one, somewhere between the
> West Australian border (with Sth Aust) and the first notable town on
> the road West - Norseman. It's 45 mins different from Sth Aust and the
> a further 45 mins to main stream West Aust.  There might be 10,000
> people live within it.

$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$ 

Cheers,
David.



Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Sat 22 Jun 2024 at 18:35:34 (+1000), Keith Bainbridge wrote:
> On 21/6/24 14:28, David Wright wrote:
> > You could pronounce your time written above as:
> > 
> >"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"
> 
> Excellent. Now how do we get our MUA to do that when replying to mail,
> which is where I saw what I thought was a system error - but in fact
> was a misinterpretation.

I don't see the point. The email has a "Date:" header.

Unless it's significant that your email is like a blog that's been
written over a period of time; chronicling current events, say.

> > if that's indeed your intention. But what you've done is invent
> > some notation of your own, which people will likely misunderstand.
> > 
> > I think it best to look up these references and follow them:
> > 
> >https://en.wikipedia.org/wiki/ISO_8601
> >https://www.ietf.org/rfc/rfc3339.txt
> 
> Will do
> > 
> > IMHO I think that email attributions are best presented in and with
> > the time zone of the sender, and not oneself.
> 
> Maybe that would be achieved if the replyer's MUA inserted the senders
> date/time more clearly.   I don't mean to harp on, but maybe the
> coders just haven't mis-read the dates they are inserting for us.

They write Date: in the same format, often called RFC822 format,
see RFC 2822.

Cheers,
David.



Re: dictd?

2024-06-22 Thread David Wright
On Thu 20 Jun 2024 at 09:04:29 (+0700), Max Nikulin wrote:
> On 20/06/2024 00:31, Greg Wooledge wrote:
> > On Wed, Jun 19, 2024 at 22:15:20 +0500, Stanislav Vlasov wrote:
> > > In my system mode bits on my home dir are `drwx--` so only my user
> > > have access to it.
> > 
> > Well, yeah.  That's not a default setting
> 
> 0700 is the current default. See /usr/share/doc/adduser/README.gz and
> /usr/share/doc/adduser/NEWS.Debian.gz

I think that's a recent change, with bookworm. And there was some
vacillation while that was testing.

ISTR that long ago, you got the setgid as well, ie r-s.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Fri 21 Jun 2024 at 06:45:58 (+0200), to...@tuxteam.de wrote:
> On Fri, Jun 21, 2024 at 09:32:10AM +0700, Max Nikulin wrote:
> > On 20/06/2024 11:52, to...@tuxteam.de wrote:
> > > "the system's
> > > time zone" (of which some, me included, say "there's no such thing",
> > > and others disagree 🙂
> > 
> > What term is appropriate in your opinion do describe the setting stored as
> > the /etc/localtime symlink? localtime(5)
> 
> The default time zone (i.e. that one which is used when some
> process calls for one and hasn't specified one itself).
> 
> > On 19/06/2024 11:37, to...@tuxteam.de wrote:
> > > Especially that bit with the "system timezone". Reminds me of some
> > > remote past, where a system actually had a timezone (and changed its
> > > clock twice a year). Back then we used to set all our networked
> > > Windows boxen to a time zone without summer time change (ISTR it
> > > was Monrovia/Liberia) to avoid having our Makefiles freaking out
> > > twice a year.
> > 
> > I recall a checkbox do disable DST in Windows 95 or Windows 98, so perhaps
> > searching for a timezone without DST was not necessary.
> 
> It's a log time ago, but we were a shop with a few pretty knowledgeable folks,
> so I guess we first tried something like that.

There was a Registry Key:
  HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
that you could set to 1 for UTC. I don't remember when it was
introduced. And, of course, it might have been present but
undocumented for years.

> > By the way,
> >  describes another style of
> > identifiers in the Microsoft TZ DB. At certain point I have realized that
> > "time zone" and "timezone" have a bit different meaning in the case of the
> > IANA database 
> 
> It's a complex matter, yes. Food for nerds :)

I'm not sure you can expect consistency in spelling beyond any
particular set of documents. Styles change: there's a tendency in
English to evolve towards compound words, sometimes with hyphenation
along the way.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Fri 21 Jun 2024 at 06:48:14 (+0200), to...@tuxteam.de wrote:
> On Thu, Jun 20, 2024 at 11:17:42PM -0500, David Wright wrote:
> > On Thu 20 Jun 2024 at 22:58:53 (-0400), Greg Wooledge wrote:
> > > On Fri, Jun 21, 2024 at 09:32:10 +0700, Max Nikulin wrote:
> > > > On 20/06/2024 11:52, to...@tuxteam.de wrote:
> 
> [...]
> 
> > Well, that's a mouthful. And what am I to call the time that a system
> > issues using that system default time zone? If I boot up two computers
> > and they display different times, what term is appropriate in your
> > opinion to describe the time displayed?
> 
> The first step would be to realize that it's not the "computers" doing
> the time display, but some processes running on them, and *those* are
> the ones with the time zone (either default or explicitly set).

Yes, I realise that. The times are being displayed by the gettys,
controlled by the /etc/issue format string. Jobs are being run
by cron, logs written by rsyslogd, and so on. And the term is … ?

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Fri 21 Jun 2024 at 07:15:32 (-0400), Greg Wooledge wrote:
> On Thu, Jun 20, 2024 at 23:17:42 -0500, David Wright wrote:
> > And what am I to call the time that a system
> > issues using that system default time zone?
> 
> If you mean the current time translated into that time zone, "local time"
> is the traditional name for it.

That might have worked when computers were big and heavy, but that's
no longer the case. When you travel with your laptop, there could be
two different local times, your one displayed by the computer, and
the real local time that tells you when "last orders" will be called
in the local pub.

> > If I boot up two computers
> > and they display different times, what term is appropriate in your
> > opinion to describe the time displayed?
> 
> They're out of sync.  Or, at least one of them is.

No, the kernel clocks are all in sync.

> Or did you mean "the same time, but in two different time zones"?  If
> you displayed these times by running "date", which respects both the
> TZ environment variable and the /etc/localtime symlink, then you figure
> out which of them is set to an undesired value.  And then you fix it.
> Or, if it's set how you *want* it, then you leave it alone.

Yes, they're set as desired. But now you've used 1.3k in your post,
and I still don't have my adjective. The computers issue different
times, because they're being used by different people for different
purposes like in an internet café. I need to tell these people what
time they're set to. I say to them "this system is on Dubai time, and
that one's on Bahrain time. They know exactly what I mean, but what's
the term for those times? (Other than system time, which is what I'd
call it.) And it's not "local time", because the ferry we're on is
about to leave Karachi, so clocks will be showing PKT.

Cheers,
David.



Re: Maximum size .bash_aliases file

2024-06-22 Thread David Wright
On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
> On Sat, Jun 22, 2024 at 18:35:34 +1000, Keith Bainbridge wrote:
> > On 21/6/24 14:28, David Wright wrote:
> > > You could pronounce your time written above as:
> > > 
> > >"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"
> > 
> > Excellent. Now how do we get our MUA to do that when replying to mail,
> 
> Depends on your MUA.  In mutt, it would be:
> 
> set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
> 
> except that this won't put a colon inside the timezone offset.  It
> would just end with "UTC+1000".
> 
> Of course, you probably don't want that exact wording, because it's
> used as *part* of the attribution.  If you used the above, then the
> attribution would come out looking like:
> 
> On It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+1000, 
> So-and-So wrote:
> 
> So, you'd either want to change the attribution variable as well, or
> alter that wording slightly.  I'd suggest removing "It's" and "here".

I think you need to set attribution, not date_format. For example,
  set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
is my own. The %{…} braces indicate using the sender's time zone.

Cheers,
David.



Re: Maximum size .bash_aliases file

2024-06-20 Thread David Wright
On Thu 20 Jun 2024 at 21:00:38 (+1000), Keith Bainbridge wrote:
> On 17/6/24 18:26, Keith Bainbridge wrote:
> > 
> > It was late afternoon on 16Jun2024 that I wrote this. Possibly
> > 18:13:36 when I pressed send. I'd reckon it would likely have been
> > 08:13:36 UTC   What's wrong with my system clock. I've not really
> > looked at the time on my originals before.  I'll try to remember
> > to enter my local time as I press send
> 
> Thanks for those responses. [ … ]
> 
> I reskon that they seem to indicate that the date/time in my original
> question are fine. the difficulty is more related to how we humans are
> interpreting the information we are reading.
> 
> https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html
> 
> is a list of place names for MANY parts of a date layout. I have set
> up the following code in my text substitution app:
> "%a %d%b%Y at %H:%M:%S =UTC %Z"
> 
> Triggering that give me
> Thu 20Jun2024 at 20:51:19 =UTC +10:00
> 
> Seems to me that if the code writers of our various MUA would add the
> +UTC to the line that prints the various dates, we'd understand what
> they mean better.
> 
> Meantime, we have to accept what we have.

You could pronounce your time written above as:

  "It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

if that's indeed your intention. But what you've done is invent
some notation of your own, which people will likely misunderstand.

I think it best to look up these references and follow them:

  https://en.wikipedia.org/wiki/ISO_8601
  https://www.ietf.org/rfc/rfc3339.txt

IMHO I think that email attributions are best presented in and with
the time zone of the sender, and not oneself.

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-20 Thread David Wright
On Thu 20 Jun 2024 at 22:58:53 (-0400), Greg Wooledge wrote:
> On Fri, Jun 21, 2024 at 09:32:10 +0700, Max Nikulin wrote:
> > On 20/06/2024 11:52, to...@tuxteam.de wrote:
> > > "the system's
> > > time zone" (of which some, me included, say "there's no such thing",
> > > and others disagree 🙂
> > 
> > What term is appropriate in your opinion do describe the setting stored as
> > the /etc/localtime symlink? localtime(5)
> 
> I've been using "system default time zone", for lack of a better phrase.
> I feel it's important to convey that this is *not* a global setting that
> affects "the system" in some universal way.  Like, for example, changing
> where /etc/localtime points will (probably) *not* change the behavior
> of any programs that are already running.  Nor will it change the behavior
> of any programs that have the TZ environment variable set, or any that
> simply ignore time zones and write everything in UTC or TAI64 or whatever.
> 
> It's just a default that many, but not all, programs may use when they run.

Well, that's a mouthful. And what am I to call the time that a system
issues using that system default time zone? If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

Cheers,
David.



Re: System time/timezone, was Re: Maximum size .bash_aliases file

2024-06-18 Thread David Wright
On Tue 18 Jun 2024 at 07:07:36 (-0400), Greg Wooledge wrote:
> On Mon, Jun 17, 2024 at 23:54:03 -0500, David Wright wrote:
> > What should I call the timezone of my computer when it's booted up and
> > no users are logged in?
> 
> Daemons will almost always use the system's default time zone (the one
> specified by /etc/localtime or /etc/timezone).
> 
> It's *theoretically* possible for some daemons to be configured to use
> a different time zone, or to be hard-coded to use UTC.  I've never seen
> this, but it could be done.

In view of that, I think it's reasonable to drop the "default",
and go with "system time zone", ie the time zone that the system
clock it set to.

> Usually a daemon's time zone will only affect log messages that it
> writes.  It's uncommon for a daemon process to use a time zone for
> anything other than timestamping messages.  Of course, it depends on
> the individual daemon.

Well, it's anything related to time, I suppose, like cron, systemd
timers, clock displays, and so on. I just don't understand the idea
of a computer not having a system time in a time zone.

(And I'm leaving aside any connected devices, filesystems, etc
that might handle times, but only in a single, local time.)

Cheers,
David.



  1   2   3   4   5   6   7   8   9   10   >