Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #260853 > unrolled thread

Crosshairs in gimp 2.10.22 in Debian 11.7.

Back to article view | Back to linux.debian.user

Contents

  Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 04:00 +0200
    Re: Crosshairs in gimp 2.10.22 in Debian 11.7. Dan Ritter <dsr@randomstring.org> - 2023-08-12 13:10 +0200
      Re: Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 15:50 +0200
      Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 11:30 +0200
        Re: random number generator missing after upgrade David Wright <deblis@lionunicorn.co.uk> - 2023-08-14 15:30 +0200
          Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 21:00 +0200
            Re: random number generator missing after upgrade davidson <davidson@freevolt.org> - 2023-08-14 22:30 +0200
              Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-15 07:50 +0200
      Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 05:30 +0200
        Re: upgrade to bookworm broke phpmyadmin Stefan Monnier <monnier@iro.umontreal.ca> - 2023-08-24 16:00 +0200
          Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 23:40 +0200
      Re: Please verify Gnome and KDE wiki articles for correctness Jeffrey Walton <noloader@gmail.com> - 2023-08-26 16:30 +0200
        Re: Please verify Gnome and KDE wiki articles for correctness <tomas@tuxteam.de> - 2023-08-26 16:50 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 19:10 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
      Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
      Re: Debian, Git server, Nginx, Fcgiwrap, and git push can not create  remote object directory David Mehler <dave.mehler@gmail.com> - 2023-09-10 03:30 +0200
      Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-10 18:50 +0200
        Re: usrmerge on root NFS will not be run automatically Javier Barroso <javibarroso@gmail.com> - 2023-09-11 17:30 +0200
      Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 16:30 +0200
        Re: usrmerge on root NFS will not be run automatically Dan Ritter <dsr@randomstring.org> - 2023-09-14 17:20 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 18:10 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 20:30 +0200
            Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-14 23:00 +0200
              Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
                Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-15 15:30 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 22:20 +0200
            Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-10-03 13:50 +0200
          Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
            Re: usrmerge on root NFS will not be run automatically Andy Smith <andy@strugglers.net> - 2023-09-15 20:00 +0200
              Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 23:40 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:40 +0200
            Re: sata driver compataility Q Andy Smith <andy@strugglers.net> - 2023-09-16 00:00 +0200
              Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 01:30 +0200
            Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 12:10 +0200
              Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 13:50 +0200
                Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 14:10 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:50 +0200
          Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-19 03:40 +0200
            Amanda (was: sata driver compataility Q) Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-19 15:00 +0200
              Re: Amanda (was: sata driver compataility Q) gene heskett <gheskett@shentel.net> - 2023-09-19 17:20 +0200
                Re: Amanda (was: sata driver compataility Q) Glenn <ve9gj@napan.com> - 2023-09-19 19:00 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 19:30 +0200
            When a random string is not random (was Re: PATH revisited: one PATH  to "rule the [Debian] World") Max Nikulin <manikulin@gmail.com> - 2023-09-25 05:20 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 21:50 +0200
            Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 22:00 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 22:50 +0200
                Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 23:00 +0200
                  Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 23:30 +0200
          Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian]  World" David Wright <deblis@lionunicorn.co.uk> - 2023-09-25 05:20 +0200
            Re: Message IDs, was Re: PATH revisited: one PATH to "rule the  [Debian] World" Dan Ritter <dsr@randomstring.org> - 2023-09-25 13:10 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#261762 — Re: Amanda (was: sata driver compataility Q)

On 9/19/23 08:59, Stefan Monnier wrote:
>> Compared to the setup required for amanda, that sounds very inviting. Amanda
>> has a very steep learning curve just because it is so versatile I'm still
>> waiting on stuff, so no more actual progress.
> 
> I used Amanda many years ago and was quite pleased with it, but I must
> say I'm having a hard time imagining it in my current world where tapes
> don't make much sense for backups.
> 
Thats where vtapes come in, A vtape is nothing more than a directory on 
the backup medium, which for me was a BIG hard drive with in my case, 60 
suddirs, used as tapes. Each contained individual files identified as to 
backup level which was a way ti differentiate a full copy, or what had 
ben changed since the last full, or what had been changed since the last 
level 1, wash rinse repeat for ever deeper levels. And with or w/o 
compression. Executables generally aren't worth the time to compress. 
Ditto for a dir full if pictures or pdf's. They are not very 
compressible.  In the days of tapes, a buffer drive was used to build up 
each entry as a big file that was then copied to the tape w/o any 
shoe-shining of the tapedrive, saveibg the huge wear and tear of the 
tape if it had to stop and wait for data from the compressor. Then back 
uo a few feet, back forward to begin a fresh write at the end of the 
previous track. But since spinning rust is random access, amd so is the 
vtape, I don't think the anti-shoeshine has much if any advantage whrn 
using vtapes. With some filesystems it might reduce fragmentation but 
that was never a problem with ext4. I ran with that buffer drive for 
about 17 yeas, starting out with a 4 tape seagate dds4 tape drive but it 
was by far, the least dependable thing in that whole chain. I was then 
backing up 3 cnc machines and this ones predecessor, but the drive 
needed a months vacation in Oklahoma city about 2x a year for a new head 
drum that seagate would not sell me, a CET with extensive experience 
replacing even smaller, more precise and damn sure more expensive at 
$3500 a copy dvc-pro broadcast vcr heads.  So I tried vtapes, first on a 
220G drive but soon opted for a bigger one as they became available, and 
had just graduated to a pair of seagates first 2T's, both of which just 
disapeared off the sata buss in the middle of the night. the main drive 
for this machine and the amanda drive. They were about 2 weeks old. So I 
rebuilt this machine using a 500G Samsung SSD. I was out of the amanda 
business and lost everything with those 2 failures, whih upset me so 
much I never tried to warranty them. I was done with spinning rust.

Some of the loss was the only pix of my first wife who had a stroke and 
died in '68 at 34. Left me with 3 children to raise, but the big C and a 
bottle of scotch has since eliminated them. And my personal email 
archive that went back to '98 when I built my first linux machine using 
a 400 mhz k6 cpu. Put RedHat 5.0 on it.  And I was in hog heaven, I 
never owned a windows machine until I needed one for the road after I 
retired in 2002 and became a consultant, going around to other tv 
stations putting out engineering fires created by wannabe engineers. The 
windows xp on it lasted about 2 weeks that it took me to find out 
windows xp had no drivers for the radio in it, but mandrake did.

Amanda keeps a database, so if something gets erased you need later, it 
could be recovered as long as in my case 60 days later before the vtape 
has been reused.

One of the things my wrapper did was append that database to the end of 
that vtape when amanda was finished from its nightly run, thereby making 
it possible to do a bare metal recovery to the state that existed during 
the run. Without that, you lost the most recent run because the database 
you backed up was yesterdays.

So AFAIAC, amanda was the king. Then amanda was handed over to Zmanda, 
who eventually went bust and sold it to betsol, who has done zip for it 
in several years.  Community support from other users is all thats left.
Not the end of it of course, but somebody who actually cares needs to 
fork it and become its new leader. 95% of the work on amanda has been 
driven by changes in tar over the last decade+.

> What are the use cases where Amanda still beats the pants down of
> competitors like Borg or Bup?

I know nothing about either of those. This thread ought to have input 
from their users so people can make more informed decisions as to which 
is best for their situation.
> 
> 
>          Stefan
Take care & stay well, Stefan, and other readers.
> 
> .

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

[toc] | [prev] | [next] | [standalone]

#261763 — Re: Amanda (was: sata driver compataility Q)

[Multipart message — attachments visible in raw view] — view raw

My all time fav for file level backups is BackupPC. De-duplicates files in the compressed pool.

Glenn 

On September 19, 2023 12:18:36 p.m. ADT, gene heskett <gheskett@shentel.net> wrote:
>On 9/19/23 08:59, Stefan Monnier wrote:
>>> Compared to the setup required for amanda, that sounds very inviting. Amanda
>>> has a very steep learning curve just because it is so versatile I'm still
>>> waiting on stuff, so no more actual progress.
>> 
>> I used Amanda many years ago and was quite pleased with it, but I must
>> say I'm having a hard time imagining it in my current world where tapes
>> don't make much sense for backups.
>> 
>Thats where vtapes come in, A vtape is nothing more than a directory on the backup medium, which for me was a BIG hard drive with in my case, 60 suddirs, used as tapes. Each contained individual files identified as to backup level which was a way ti differentiate a full copy, or what had ben changed since the last full, or what had been changed since the last level 1, wash rinse repeat for ever deeper levels. And with or w/o compression. Executables generally aren't worth the time to compress. Ditto for a dir full if pictures or pdf's. They are not very compressible.  In the days of tapes, a buffer drive was used to build up each entry as a big file that was then copied to the tape w/o any shoe-shining of the tapedrive, saveibg the huge wear and tear of the tape if it had to stop and wait for data from the compressor. Then back uo a few feet, back forward to begin a fresh write at the end of the previous track. But since spinning rust is random access, amd so is the vtape, I don't think the anti-shoeshine has much if any advantage whrn using vtapes. With some filesystems it might reduce fragmentation but that was never a problem with ext4. I ran with that buffer drive for about 17 yeas, starting out with a 4 tape seagate dds4 tape drive but it was by far, the least dependable thing in that whole chain. I was then backing up 3 cnc machines and this ones predecessor, but the drive needed a months vacation in Oklahoma city about 2x a year for a new head drum that seagate would not sell me, a CET with extensive experience replacing even smaller, more precise and damn sure more expensive at $3500 a copy dvc-pro broadcast vcr heads.  So I tried vtapes, first on a 220G drive but soon opted for a bigger one as they became available, and had just graduated to a pair of seagates first 2T's, both of which just disapeared off the sata buss in the middle of the night. the main drive for this machine and the amanda drive. They were about 2 weeks old. So I rebuilt this machine using a 500G Samsung SSD. I was out of the amanda business and lost everything with those 2 failures, whih upset me so much I never tried to warranty them. I was done with spinning rust.
>
>Some of the loss was the only pix of my first wife who had a stroke and died in '68 at 34. Left me with 3 children to raise, but the big C and a bottle of scotch has since eliminated them. And my personal email archive that went back to '98 when I built my first linux machine using a 400 mhz k6 cpu. Put RedHat 5.0 on it.  And I was in hog heaven, I never owned a windows machine until I needed one for the road after I retired in 2002 and became a consultant, going around to other tv stations putting out engineering fires created by wannabe engineers. The windows xp on it lasted about 2 weeks that it took me to find out windows xp had no drivers for the radio in it, but mandrake did.
>
>Amanda keeps a database, so if something gets erased you need later, it could be recovered as long as in my case 60 days later before the vtape has been reused.
>
>One of the things my wrapper did was append that database to the end of that vtape when amanda was finished from its nightly run, thereby making it possible to do a bare metal recovery to the state that existed during the run. Without that, you lost the most recent run because the database you backed up was yesterdays.
>
>So AFAIAC, amanda was the king. Then amanda was handed over to Zmanda, who eventually went bust and sold it to betsol, who has done zip for it in several years.  Community support from other users is all thats left.
>Not the end of it of course, but somebody who actually cares needs to fork it and become its new leader. 95% of the work on amanda has been driven by changes in tar over the last decade+.
>
>> What are the use cases where Amanda still beats the pants down of
>> competitors like Borg or Bup?
>
>I know nothing about either of those. This thread ought to have input from their users so people can make more informed decisions as to which is best for their situation.
>> 
>> 
>>          Stefan
>Take care & stay well, Stefan, and other readers.
>> 
>> .
>
>Cheers, Gene Heskett.
>-- 
>"There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
>-Ed Howdershelt (Author, 1940)
>If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
>Genes Web page <http://geneslinuxbox.net:6309/>
>

[toc] | [prev] | [next] | [standalone]

#261855 — Re: PATH revisited: one PATH to "rule the [Debian] World"

On Sun, Sep 24, 2023 at 01:05:32PM -0400, Dan Ritter wrote:
> Tom Browder wrote: 
> > Every time I set up a new host, I have to jump through the hoops trying to
> > get the same PATH for ordinary users as well as root, regardless of how
> > they log in. Reading the man pages doesn't help my old brain with all the
> > caveats.
> 
> 
> Set it in /etc/profile, which probably has this in it:
> 
> if [ "$(id -u)" -eq 0 ]; then
>   PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> else
>   PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
> fi
> export PATH

This file is only read by certain login methods.  The whole point of Tom's
request was to find something that works for *all* login methods.  Sadly,
no such thing exists.

[toc] | [prev] | [next] | [standalone]

#261880 — When a random string is not random (was Re: PATH revisited: one PATH to "rule the [Debian] World")

On 25/09/2023 00:27, Greg Wooledge wrote:
> On Sun, Sep 24, 2023 at 01:05:32PM -0400, Dan Ritter wrote:
>> Tom Browder wrote:
>>> Every time I set up a new host, I have to jump through the hoops trying to
>>> get the same PATH for ordinary users as well as root, regardless of how
>>> they log in. Reading the man pages doesn't help my old brain with all the
>>> caveats.

I see the message from Dan Ritter neither on lists.debian.org nor on 
news.gmane.io. It seems, the person sends messages with fixed 
Message-ID: <3a6b048e-84db-4a47-969c-b62c826e0cdd@randomstring.org>. At 
first I thought it is a mailer bug, but the host name is quite specific.

Look at

https://lists.debian.org/debian-user/2023/09/threads.html#00175

It is a real mess of unrelated subjects merged into single thread. I 
suspected that it is Gene who may start a discussion unrelated to 
original thread, but this case the cause is different.

The message from Greg:
https://lists.debian.org/debian-user/2023/09/msg00491.html
Notice

References:
Re: usrmerge on root NFS will not be run automatically
     From: Dan Ritter

Due to the In-Reply-To header. Certainly Greg replied to another 
message, but it was dropped by archivers.

So if you see that somebody posted a message to a wrong thread, it is 
not necessary their fault.

[toc] | [prev] | [next] | [standalone]

#261859 — Re: PATH revisited: one PATH to "rule the [Debian] World"

On 24 Sep 2023 13:05 -0400, from dsr@randomstring.org (Dan Ritter):
> Set it in /etc/profile, which probably has this in it:

I would rather suggest a separate script in /etc/profile.d to either
add to or replace the contents of $PATH. If I'm reading /etc/profile
right, *.sh in that directory are executed in lexicographic order
right at the end.

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

[toc] | [prev] | [next] | [standalone]

#261861 — Re: PATH revisited: one PATH to "rule the [Debian] World"

On Sun, Sep 24, 2023 at 07:42:32PM +0000, Michael Kjörling wrote:
> On 24 Sep 2023 13:05 -0400, from dsr@randomstring.org (Dan Ritter):
> > Set it in /etc/profile, which probably has this in it:
> 
> I would rather suggest a separate script in /etc/profile.d to either
> add to or replace the contents of $PATH. If I'm reading /etc/profile
> right, *.sh in that directory are executed in lexicographic order
> right at the end.

All of which is a red herring, because /etc/profile and the things
dotted in from it are only applicable to login mechanisms that involve
a shell.

In the case of an X session consisting of a window manager, executed
directly from a display manager, there is no login shell at any time,
and therefore nothing reads /etc/profile.

One may configure such an X session by editing ~/.xsession or other
files of that nature, and that will indeed configure your environment
as desired -- for X sessions.  But you'll have a different environment
if you login on a text console and don't do "startx", or if you login
by ssh.

There is NO configuration mechanism that works for all logins.  None.
I've been up and down this road for 30 years.  It doesn't exist.  I
would have found it by now.

All you can do is put your desired configuration changes in ALL of
the applicable places for all of the login types that are possible on
your system.  That's it.  There is no other way.

[toc] | [prev] | [next] | [standalone]

#261865 — Re: PATH revisited: one PATH to "rule the [Debian] World"

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 24, 2023 at 14:52 Greg Wooledge <greg@wooledge.org> wrote:
...

> All you can do is put your desired configuration changes in ALL of
> the applicable places for all of the login types that are possible on
> your system.  That's it.  There is no other way.

...

Bummer, unfortunately, that's the answer I expected. Now if I can find a
clean way to do that consistently.

Thanks, Greg.

-Tom

[toc] | [prev] | [next] | [standalone]

#261868 — Re: PATH revisited: one PATH to "rule the [Debian] World"

On 24 Sep 2023 15:45 -0500, from tom.browder@gmail.com (Tom Browder):
> Bummer, unfortunately, that's the answer I expected. Now if I can find a
> clean way to do that consistently.

Well, I still think the gist of my suggestion stands: make a script to
set up $PATH the way you want it (for both root and non-root users
respectively); put that script somewhere, anywhere really; and invoke
it from where you need $PATH set up.

That way, if you miss some path (no pun intended), all you need is to
figure out how to execute or source a script through there in such a
way that it affects the resultant environment; and if you want to make
adjustments later, you can do that in _one_ location.

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

[toc] | [prev] | [next] | [standalone]

#261871 — Re: PATH revisited: one PATH to "rule the [Debian] World"

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 24, 2023 at 15:55 Michael Kjörling <2695bd53d63c@ewoof.net>
wrote:

> On 24 Sep 2023 15:45 -0500, from tom.browder@gmail.com (Tom Browder):
> > Bummer, unfortunately, that's the answer I expected. Now if I can find a
> > clean way to do that consistently.
>
> Well, I still think the gist of my suggestion stands: make a script to
> set up $PATH the way you want it (for both root and non-root users
> respectively); put that script somewhere, anywhere really; and invoke
> it from where you need $PATH set up.
>
> That way, if you miss some path (no pun intended), all you need is to
> figure out how to execute or source a script through there in such a
> way that it affects the resultant environment; and if you want to make
> adjustments later, you can do that in _one_ location.


In effect, I will doing that. I'm in the process of automating non-package
installation of Raku on modern Debian hosts. That was the genesis of my
question, and I will be inserting the required PATH info at the approriate
place for any login type as pointed out by Greg and the Debian docs.

Thanks, Michael and Greg.

-Tom

[toc] | [prev] | [next] | [standalone]

#261881 — Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World"

On Sun 24 Sep 2023 at 13:05:32 (-0400), Dan Ritter wrote:
> Tom Browder wrote: 
> > Every time I set up a new host, I have to jump through the hoops trying to
> > get the same PATH for ordinary users as well as root, regardless of how
> > they log in. Reading the man pages doesn't help my old brain with all the
> > caveats.
> 
> 
> Set it in /etc/profile, which probably has this in it:
  [ … etc … ]

Dan, could you check the configuration of your (?new since early
August) MUA, because you seem to have been able to post your reply
dated Sun, 24 Sep 2023 13:05:32 -0400 using a Message-ID ¹ identical
to your post dated Thu, 14 Sep 2023 11:00:17 -0400 entitled "Re:
usrmerge on root NFS will not be run automatically".

A word of explanation to people who read debian-user from the web
rather than being subscribed: it would appear that Dan's message
will not appear on https://lists.debian.org/debian-user/2023/09/
because of its duplicate Message-ID.

Looking back at some other threads, I notice that your first post
to gene in the thread "raid10 access problem" has a Message-ID ²
that appears to have been used subsequently (check the References at
https://lists.debian.org/debian-user/2023/09/msg00179.html
in gene's reply).

And if you look at the References in Marco's post at
https://lists.debian.org/debian-user/2023/09/msg00310.html
it appears that there has been a conversation between you
and Marco (on-list or off-list?) during 14–15th Sep, in which
the Message-ID shown at ¹ has been used to identify four
different posts of yours.

¹ <3a6b048e-84db-4a47-969c-b62c826e0cdd@randomstring.org>

² <34dbc5be-529a-4f47-9a51-3b09040197e2@randomstring.org>

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#261893 — Re: Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World"

David Wright wrote: 
> On Sun 24 Sep 2023 at 13:05:32 (-0400), Dan Ritter wrote:
> > Set it in /etc/profile, which probably has this in it:
> 
> Dan, could you check the configuration of your (?new since early
> August) MUA, because you seem to have been able to post your reply
> dated Sun, 24 Sep 2023 13:05:32 -0400 using a Message-ID ?? identical
> to your post dated Thu, 14 Sep 2023 11:00:17 -0400 entitled "Re:
> usrmerge on root NFS will not be run automatically".

Thank you! This should be solved now.


-dsr-

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.debian.user

csiph-web