Re: ToG Linux (first draft of a RFC) ...

[Albretch Mueller]

 Oh, well! "My paranoia" as Greg would say ;-)
 Yes, they removed it again! I have no effing idea why (other than
messing with me)
 You could hopefully see my back and forths with them:
 
https://wordpress.com/forums/topic/how-long-does-it-take-for-a-new-post-to-become-active/
 Let me resume fighting them to see if they allow my post (they
hadn't, then they did for a while, ...)
 I will keep you all posted. Given the options I hope our community
doesn't get too upset about us going about our initial brainstorming
here.
 lbrtchx

Re: Recommended simple PDF viewer to replace Evince

[Paul Scott]

On 12/6/23 9:06 PM, Bert Riding wrote:

On Tue, 05 Dec 2023 14:30:01 +0100, Eric S Fraga wrote:


I use zathura which is also quite light but I'm not sure if you can
print from it.  I tend to print directly using lp although very
infrequently in any case.

In zathura :print brings up the Gtk+ print dialog.

(So does ctrl-P).  And when I click on Preview the dialog box just 
closes.  Maybe any comments here will help me configure Preview which 
stopped working many versions of Zathura ago.  I've just been using 
"Print to File" for now to determine if the document will fit my paper.


TIA,

Paul

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[David Wright]

On Wed 06 Dec 2023 at 22:40:23 (+), Albretch Mueller wrote:
>  What I had been doing is use "depends" to get all dependencies

I did that.

> and
> then download each of them.

I did that too. Not all of them, of course, as I don't need or want
all those packages.

> I think that is why I was getting those
> repeated binary files.

You haven't posted what they look like or precisely when they appear:
at the depends stage or the download?

> I thought when you said "download" you just
> meant "download".

Well, yes, and I just posted it:   apt-get download acl2
Usually I just use   apt-get -d install acl2   but in the interests
of replication, I copied your "apt-get download" version.

My only guess, not knowing or seeing your system, is that your
packages cache /var/cache/apt/{src,}pkgcache.bin is screwed,
and so a new one has to be rebuilt every time.

Cheers,
David.

Re: packages listed vs. apt-rdepends --follow=Depends ...

[David Wright]

On Wed 06 Dec 2023 at 23:08:41 (+), Albretch Mueller wrote:
> On 12/2/23, Albretch Mueller  wrote:
> > On 12/2/23, Tom Furie  wrote:
> >> 'apt depends ' would list the direct dependencies without
> >> recursion.
> > $ apt depends wget 2>&1 | grep "  Depends: " | awk '{ print $2}'
> 
>  that didn't work,

Tom said it wouldn't, and went on to give a recursive version.

> dpkg would still demand dependencies,

(dependencies of dependencies)

> so I decided
> to change the strategy to:
>  1) using apt-get install ...
>  2) save the install log into a file (apt-get install reports to you
> the order of installation) from which you can then created a dpkg
> based script
>  3) move all packages from /var/cache/ ... to wherever is needed.

I don't remember ever having to worry about the order. I would just
transfer the package cache from the connected PC (at work) to the
unconnected one (at home), and tell dpkg to install the lot, in one
gulp. At worst, the commands   dpkg --configure -a   and
apt-get -f install   would clear any logjams.

> On 12/2/23, Darac Marjal  wrote:
> > There used to be "apt-zip" (no longer in Debian), which was
> > built around the idea of using ZIP disks for transferring files.
> > "apt-zip-list" would use the state of packages on the disconnected
> > system to product a "want list" of files to be downloaded. This "want
> > list" would be a shell script consisting of various wget or curl
> > commands. The script would be taken over to the connected system and
> > run, to pull the required packages onto a high-capacity removable medium
> > (such as a USB drive or ZIP drive). Back at the disconnected system,
> > "apt-zip-inst" would complete the process, installing the files from the
> > removable medium.
> 
>  Hmm! ... and the apt-zip functionality doesn't exist anymore in the
> same way that it rains and thunders when the Gods decide? When a
> package is removed or discontinued, is there a formal explanation as
> to why?

My guess would be that diminishing use with increasing broadband
availability led to no interest in maintaining it, particularly
through times when changes were made to APT.

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

Have you looked at apt-offline?

>  I don't know why and I decided to change my approach, but I tried to use the:
>  https://manpages.ubuntu.com/manpages/noble/en/man8/apt-get.8.html
>  -s, --simulate, --just-print, --dry-run, --recon, --no-act
>  functionality, but it didn't work:
>  "E: Command line option --dry-run is not understood in combination
> with the other options"
>  then I found confusing explanations about users being confused:
>  
> https://serverfault.com/questions/1074702/apt-get-update-dry-run-command-does-not-work-anymore
 ↑↑
As the reference says, they were trying to use -s with update, but
update doesn't involve packages, only the packages index. Well,
you know update is going to get you—just read your sources.list—so
what's the point of -s.

Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 20:44:29 (-0500), Pocket wrote:
> On 12/6/23 19:46, Greg Wooledge wrote:
> > On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
> > > On 12/6/23 19:26, Greg Wooledge wrote:
> > > > On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> > > > > On 12/6/23 19:12, Greg Wooledge wrote:
> > > > > > So, basically every reference I can find, and every reference I've 
> > > > > > *ever*
> > > > > > found, other than Pocket's email, has said that America/New_York is
> > > > > > correct for me.
> > > > > > 
> > > > > See my other post
> > > > [citation needed]
> > > > 
> > > See my other post
> > If you mean
> > there are zero URLs in your text.  "Someone named Pocket said so" is not a
> > strong enough assertion for me to reject every other source citation
> > I've found.
> > 
> Start Here
> 
> The *Standard Time Act* of 1918, also known as the *Calder Act*, was
> the first United States 
> federal law implementing Standard time
>  and
> Daylight saving time in the United States 
> .^[2]
>  It
> defined five time zones for the United States and authorized the
> Interstate Commerce Commission
>  to
> define the limits of each time zone.
> 
> The section concerning daylight saving time was repealed by the act
> titled /An Act For the repeal of the daylight-saving law/, Pub. L.
> Tooltip
> Public Law (United States) 66–40
> , 41 Stat.
>  280
> , enacted August 20, 1919, over
> President Woodrow Wilson
> 's veto.
> 
> Section 264 of the act mistakenly placed most of the state of Idaho
>  (south of the Salmon River
> ) in UTC−06:00
>  CST (Central
> Standard Time ),
> but was amended in 2007 by Congress to UTC−07:00
>  MST (Mountain
> Standard Time
> ).^[3]
> 
> MST was observed prior to the correction.

That's the idea—you have to go back to sources, and as you find them,
you check whether they actually took effect (newspaper archives being
a useful source here), and then you make "fixes and enhancements" to
the database, just as you quoted earlier.

As for the choice of "New York", perhaps easiest to quote the Wiki page:

 “Location is the name of a specific location within the area –
  usually a city or small island.

 “Country names are not normally used in this scheme, primarily
  because they would not be robust, owing to frequent political and
  boundary changes. The names of large cities tend to be more
  permanent. Usually the most populous city in a region is chosen
  to represent the entire time zone, although another city may be
  selected if it is more widely known, and another location, including
  a location other than a city, may be used if it results in a less
  ambiguous name. In the event that the name of the location used
  to represent the time zone changes, the convention is to create an
  alias in future editions so that both the old and new names
  refer to the same database entry.

 “In some cases the Location is itself represented as a compound name,
  for example the time zone "America/Indiana/Indianapolis". Three-level
  names include those under "America/Argentina/...",
  "America/Kentucky/...", "America/Indiana/...", and
  "America/North_Dakota/...".

 “The location selected is representative for the entire
  area. However, if there were differences within the area before 1970,
  the time zone rules only apply in the named location.”

Earlier, you wrote: "BTW there isn't any timezone called
America/New_York, it is or course the Eastern Standard Time Zone."

America/New_York is the name of a set of rules in the timezone
database, and we're discussing the relative merits of different sets
of rules, not the merits of the names.


Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 16:21:37 (-0500), James Cloos wrote:
> the current America/New_York equiv is:
> 
>   EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

That's as may be, but this discussion revolves around:

 "The M format is sufficient to describe many common daylight-savings
  transition laws. But note that none of these variants can deal with
  daylight-savings law changes, so in practice the historical data
  stored for named time zones (in the IANA time zone database) is
  necessary to interpret past time stamps correctly."

 (from some random POSIX Time Zone Specifications)

Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 18:16:42 (-0500), Pocket wrote:
> On 12/6/23 15:28, David Wright wrote:
> > Likely none for times present and future, unless Eric Adams should
> > pass a timezone bill. (In the 2010s, several U.S. states considered
> > legislation to move from the Eastern Time Zone to Atlantic Standard
> > Time, allegedly.)
> > 
> > But I've already posted an example in this thread where these
> > timezones give different answers:
> > 
> >https://lists.debian.org/debian-user/2023/12/msg00329.html
> > 
> Which BTW this whole discussion about timezones is just water over the dam.
> 
> The system should be set to UTC, the "timezone" issue is really just a
> "human" issue as the UTC clock is always correct

While I'm glad we're not discussing whether or not the RTC is set to
UTC or TAI or local time, I do want my computers to display to /me/ the
correct date and time corresponding to my location. And when I travel,
I expect my phone to switch its display automatically, using some
reasonably up-to-date tables.

Cheers,
David.

Re: ntpsec as server questions

[tomas]

On Wed, Dec 06, 2023 at 06:16:42PM -0500, Pocket wrote:
> 
> On 12/6/23 15:28, David Wright wrote:
> > Likely none for times present and future, unless Eric Adams should
> > pass a timezone bill [...]

> Which BTW this whole discussion about timezones is just water over the dam.

But still interesting and very much on-topic, because it invites us all to
question our incomplete and naive knowledge.

> The system should be set to UTC, the "timezone" issue is really just a
> "human" issue as the UTC clock is always correct

If we are picking nits, the system is set to UTX (aka "Unix time"), which
is, in itself, difficult to grasp and very near (but not equal) to UTC [1].

The closer you look the messier it gets. UTC, TAI, UT0, UT1... oh, my [2].

Cheers

[1] 
https://unix.stackexchange.com/questions/283164/unix-seconds-tai-si-seconds-leap-seconds-and-real-world-code
[2] http://www.stjarnhimlen.se/comp/time.html

-- 
t


signature.asc
Description: PGP signature

Re: Recommended simple PDF viewer to replace Evince

[Bert Riding]

On Tue, 05 Dec 2023 14:30:01 +0100, Eric S Fraga wrote:

> I use zathura which is also quite light but I'm not sure if you can
> print from it.  I tend to print directly using lp although very
> infrequently in any case.

In zathura :print brings up the Gtk+ print dialog.

Re: how to firefox settings

[The Wanderer]

On 2023-12-06 at 13:07, debian-u...@howorth.org.uk wrote:

> fxkl4...@protonmail.com wrote:
> 
>> on a page in firefox use tools -> page info -> permissions i notice
>> override keyboard shortcuts is set to allow where can i change the
>> defaults for this
> 
> Defaults are built-in; you can't change them (except by modifying
> the source and recompiling).
> 
> You can turn off the Use defaults button and then change Allow or
> Block as you wish. That's what the popup allows.

I parsed the question as asking: "how can I configure things so that on
a new profile for a new user, this comes up by default with a different
value?".

Depending on the details, that might be something that could be achieved
via Firefox policy templates; I haven't looked at trying to do this by
that mechanism, but it's the main thing that could potentially do it
AFAIK, short of (as you say) modifying the source and recompiling.

I don't have the link for the policy-templates site handy, but it should
be easily findable by searching for those terms.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: ntpsec as server questions

[Pocket]

On 12/6/23 19:46, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:

On 12/6/23 19:26, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:

On 12/6/23 19:12, Greg Wooledge wrote:

So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is
correct for me.


See my other post

[citation needed]


See my other post

If you mean
there are zero URLs in your text.  "Someone named Pocket said so" is not a
strong enough assertion for me to reject every other source citation
I've found.


Start Here

The *Standard Time Act* of 1918, also known as the *Calder Act*, was the 
first United States  
federal law implementing Standard time 
 and Daylight 
saving time in the United States 
.^[2] 
 It defined 
five time zones for the United States and authorized the Interstate 
Commerce Commission 
 to define 
the limits of each time zone.


The section concerning daylight saving time was repealed by the act 
titled /An Act For the repeal of the daylight-saving law/, Pub. L. 
Tooltip Public 
Law (United States) 66–40 
, 41 Stat. 
 280 
, enacted August 20, 1919, over 
President Woodrow Wilson 
's veto.


Section 264 of the act mistakenly placed most of the state of Idaho 
 (south of the Salmon River 
) in UTC−06:00 
 CST (Central Standard 
Time ), but was 
amended in 2007 by Congress to UTC−07:00 
 MST (Mountain Standard 
Time ).^[3] 
 MST 
was observed prior to the correction.




--
It's not easy to be me

Re: ToG Linux (first draft of a RFC) ...

[Andy Smith]

Hi,

On Wed, Dec 06, 2023 at 10:25:55PM +, Albretch Mueller wrote:
> You may ask me questions or suggest options on my wordpress page:
> 
> https://ergosumus.wordpress.com/2023/12/06/tog-touch-of-god-linux-first-draft-of-a-rfc/

This page doesn't seem to exist (yet?). I looked at the root of the
web site and the most recent post was from February 2022.

Thanks,
Andy

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

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 07:37:32PM -0500, Pocket wrote:
> 
> On 12/6/23 19:26, Greg Wooledge wrote:
> > On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> > > On 12/6/23 19:12, Greg Wooledge wrote:
> > > > So, basically every reference I can find, and every reference I've 
> > > > *ever*
> > > > found, other than Pocket's email, has said that America/New_York is
> > > > correct for me.
> > > > 
> > > See my other post
> > [citation needed]
> > 
> See my other post

If you mean 
there are zero URLs in your text.  "Someone named Pocket said so" is not a
strong enough assertion for me to reject every other source citation
I've found.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 19:26, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:

On 12/6/23 19:12, Greg Wooledge wrote:

So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is
correct for me.


See my other post

[citation needed]


See my other post

--
It's not easy to be me

Re: Load in minor time one page

[Dan Ritter]

William Torrez Corea wrote: 
> One page by means of firefox has a latency of 49.9 ms.
> 
> 
> *How can I improve the latency?*
> 
> I want a latency of 0 ms

Every page is different.

You can measure with the developer tools, in the performance
tab.

Things you can try:

- different network connections
- different DNS resolver
- remove ads with an adblocker (uBlock Origin is generally
  preferred)
- turn off JavaScript
- turn off graphics

If you have control of the page, on the other hand:

- remove JavaScript
- reduce graphics size
- simplify or eliminate CSS


0 ms is, of course, unobtainable. The browser needs to ask for
the page, receive the page, decode the page, and render the
content.

-dsr-

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 07:23:18PM -0500, Pocket wrote:
> On 12/6/23 19:12, Greg Wooledge wrote:
> > So, basically every reference I can find, and every reference I've *ever*
> > found, other than Pocket's email, has said that America/New_York is
> > correct for me.
> > 
> See my other post

[citation needed]

Re: ntpsec as server questions

[Pocket]

On 12/6/23 19:12, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 06:11:16PM -0500, Pocket wrote:

Because DST was not in force/usage except the metro NYC. Every where else
didn't use/have it.

That makes EST5DST correct except for NYC and America/New_York completely
incorrect except of course NYC.

(EST5EDT not EST5DST.)  Now this is interesting.  If the America/New_York
zone definition is *wrong* for me, then I'd like to use one that's less
wrong.  Is there an "Olson format" time zone definition that's actually
correct for cities like... Cleveland, just as a random example?

I found

which says that Cleveland is using America/New_York ... and basically
all the other web sites I've found either show just the current time
(gee thanks, I knew the *current* time), or they only have data back
to 1970, like .

Looking at the actual tzdata source, as present in Debian

I see the following comments:

# US eastern time, represented by New York

# Connecticut, Delaware, District of Columbia, most of Florida,
# Georgia, southeast Indiana (Dearborn and Ohio counties), eastern Kentucky
# (except America/Kentucky/Louisville below), Maine, Maryland, Massachusetts,
# New Hampshire, New Jersey, New York, North Carolina, Ohio,
# Pennsylvania, Rhode Island, South Carolina, eastern Tennessee,
# Vermont, Virginia, West Virginia

So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is
correct for me.


See my other post


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 06:11:16PM -0500, Pocket wrote:
> Because DST was not in force/usage except the metro NYC. Every where else
> didn't use/have it.
> 
> That makes EST5DST correct except for NYC and America/New_York completely
> incorrect except of course NYC.

(EST5EDT not EST5DST.)  Now this is interesting.  If the America/New_York
zone definition is *wrong* for me, then I'd like to use one that's less
wrong.  Is there an "Olson format" time zone definition that's actually
correct for cities like... Cleveland, just as a random example?

I found

which says that Cleveland is using America/New_York ... and basically
all the other web sites I've found either show just the current time
(gee thanks, I knew the *current* time), or they only have data back
to 1970, like .

Looking at the actual tzdata source, as present in Debian

I see the following comments:

# US eastern time, represented by New York

# Connecticut, Delaware, District of Columbia, most of Florida,
# Georgia, southeast Indiana (Dearborn and Ohio counties), eastern Kentucky
# (except America/Kentucky/Louisville below), Maine, Maryland, Massachusetts,
# New Hampshire, New Jersey, New York, North Carolina, Ohio,
# Pennsylvania, Rhode Island, South Carolina, eastern Tennessee,
# Vermont, Virginia, West Virginia

So, basically every reference I can find, and every reference I've *ever*
found, other than Pocket's email, has said that America/New_York is
correct for me.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 18:28, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 02:50:50PM -0500, Pocket wrote:

Well since I am not going to set any of my systems to a time in 1920, then I 
believe I am save from the time machines.

It's not just about your system's current time.  It's about timestamps
that you handle in any kind of software.  If you process dates and times
from the past, e.g. in a database application, and intend to display
them to humans, then you'll want to use a historically accurate timezone.

Which America/New_York is incorrect from 1918 to 1966, possibly into the 
1970s/80s depending upon your location in the Eastern Standard Time zone.



--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 02:50:50PM -0500, Pocket wrote:
> Well since I am not going to set any of my systems to a time in 1920, then I 
> believe I am save from the time machines.

It's not just about your system's current time.  It's about timestamps
that you handle in any kind of software.  If you process dates and times
from the past, e.g. in a database application, and intend to display
them to humans, then you'll want to use a historically accurate timezone.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 15:28, David Wright wrote:

Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered
legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)

But I've already posted an example in this thread where these
timezones give different answers:

   https://lists.debian.org/debian-user/2023/12/msg00329.html

Cheers,
David.


Which BTW this whole discussion about timezones is just water over the dam.

The system should be set to UTC, the "timezone" issue is really just a 
"human" issue as the UTC clock is always correct


--
It's not easy to be me

Re: ntpsec as server questions

[Pocket]

On 12/6/23 15:41, David Wright wrote:

On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:

TZ=POSIX;date
Wed Dec  6 18:00:38 POSIX 2023

"POSIX" is not a valid timezone name in Debian 12.  Therefore you're
just seeing UTC here.  Giving an invalid TZ always gives you UTC, but
with whatever crazy-ass name you used echoed back at you, to give you
the illusion that your name was valid.  It's a *huge* pitfall.  I've been
bit by this myself.


TZ=America/New_York;date
Wed Dec  6 13:00:21 EST 2023

TZ=EST5DST;date
Wed Dec  6 13:01:10 EST 2023

What is the problem?

Gods DAMN it.  I didn't want to have to dig through these stupid zone
dumps, but you're FORCING my hand.

unicorn:~$ zdump -v -c 1918,1950 EST5EDT
EST5EDT  -9223372036854775808 = NULL
EST5EDT  -9223372036854689408 = NULL




EST5EDT  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 
gmtoff=-18000




EST5EDT  Mon Feb  9 06:59:59 1942 UT = Mon Feb  9 01:59:59 1942 EST isdst=0 
gmtoff=-18000
EST5EDT  Mon Feb  9 07:00:00 1942 UT = Mon Feb  9 03:00:00 1942 EWT isdst=1 
gmtoff=-14400
EST5EDT  Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 
gmtoff=-14400
EST5EDT  Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 
gmtoff=-14400
EST5EDT  Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 
gmtoff=-14400
EST5EDT  Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 
gmtoff=-18000




EST5EDT  9223372036854689407 = NULL
EST5EDT  9223372036854775807 = NULL

OK?  There's dump number one.  Now let's compare to dump number two:

unicorn:~$ zdump -v -c 1918,1950 America/New_York
America/New_York  -9223372036854775808 = NULL
America/New_York  -9223372036854689408 = NULL
America/New_York  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST 
isdst=0 gmtoff=-18000
[...]

I'm truncating this one because it's much longer.  Apparently this one
shows every year, even if there are no DST rule changes that year.  What
does this mean?  Hell if I know.

Comparing zdump -v America/New_York | cut -b 19- > /tmp/a-ny
with  zdump -v EST5EDT | cut -b 10- > /tmp/e5e

shows that the former starts at 1883 (no changes then until 1918,
 above), and the latter omits the period 1920–1966, except
for War Time and Peace Time (between  and ).


Because DST was not in force/usage except the metro NYC. Every where 
else didn't use/have it.


That makes EST5DST correct except for NYC and America/New_York 
completely incorrect except of course NYC.


Which is why I prefer to use EST5DST


BTW there isn't any timezone called America/New_York, it is or course 
the Eastern Standard Time Zone.


America/New_your should actually be called America/Eastern.  The POSIX 
EST5DST is closer to being correct.





I've expanded my guesses as to why. I had thought that it might be
because the "Unix System V approach from New Jersey (insert
appropriate booing for best effect)" implied that NJ didn't observe
DST over that period, but perhaps it's just that there's no way to
determine single dates for changing the clocks.

  "Having rallied the general public's support, the Time Uniformity
  Committee'

Re: packages listed vs. apt-rdepends --follow=Depends ...

[Albretch Mueller]

On 12/2/23, Albretch Mueller  wrote:
> On 12/2/23, Tom Furie  wrote:
>> 'apt depends ' would list the direct dependencies without
>> recursion.
> $ apt depends wget 2>&1 | grep "  Depends: " | awk '{ print $2}'

 that didn't work, dpkg would still demand dependencies, so I decided
to change the strategy to:
 1) using apt-get install ...
 2) save the install log into a file (apt-get install reports to you
the order of installation) from which you can then created a dpkg
based script
 3) move all packages from /var/cache/ ... to wherever is needed.
~
On 12/2/23, Darac Marjal  wrote:
> There used to be "apt-zip" (no longer in Debian), which was
> built around the idea of using ZIP disks for transferring files.
> "apt-zip-list" would use the state of packages on the disconnected
> system to product a "want list" of files to be downloaded. This "want
> list" would be a shell script consisting of various wget or curl
> commands. The script would be taken over to the connected system and
> run, to pull the required packages onto a high-capacity removable medium
> (such as a USB drive or ZIP drive). Back at the disconnected system,
> "apt-zip-inst" would complete the process, installing the files from the
> removable medium.

 Hmm! ... and the apt-zip functionality doesn't exist anymore in the
same way that it rains and thunders when the Gods decide? When a
package is removed or discontinued, is there a formal explanation as
to why?

 I don't know why and I decided to change my approach, but I tried to use the:
 https://manpages.ubuntu.com/manpages/noble/en/man8/apt-get.8.html
 -s, --simulate, --just-print, --dry-run, --recon, --no-act
 functionality, but it didn't work:
 "E: Command line option --dry-run is not understood in combination
with the other options"
 then I found confusing explanations about users being confused:
 
https://serverfault.com/questions/1074702/apt-get-update-dry-run-command-does-not-work-anymore
~
On 12/3/23, Greg Wooledge  wrote:
> After that, it was revealed that the whole project is based on some
> paranoid fantasy.  The non-networked computer is non-networked only
> because the OP believes that "they" (that's literally the word which
> was used) are using "AI" to watch the OP "24/7".  This makes me less
> inclined to take the project seriously.

 Greg, quite honestly, I'd wish it would just be my "paranoid
fantasy", but, unfortunately, I will have disappoint you, with all the
streams of data "they" are collecting from everyone of us, "they" are
keeping a data Doppelgänger of everyone of us.

 lbrtchx

Re: ntpsec as server questions

[Pocket]


Sent from my iPad

> On Dec 6, 2023, at 1:28 PM, Greg Wooledge  wrote:
> 
> On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
>> TZ=POSIX;date
>> Wed Dec  6 18:00:38 POSIX 2023
> 
> "POSIX" is not a valid timezone name in Debian 12.  Therefore you're
> just seeing UTC here.  Giving an invalid TZ always gives you UTC, but
> with whatever crazy-ass name you used echoed back at you, to give you
> the illusion that your name was valid.  It's a *huge* pitfall.  I've been
> bit by this myself.
> 
>> TZ=America/New_York;date
>> Wed Dec  6 13:00:21 EST 2023
>> TZ=EST5DST;date
>> Wed Dec  6 13:01:10 EST 2023
>> What is the problem?
> 
> Gods DAMN it.  I didn't want to have to dig through these stupid zone
> dumps, but you're FORCING my hand.
> 
> unicorn:~$ zdump -v -c 1918,1950 EST5EDT
> EST5EDT  -9223372036854775808 = NULL
> EST5EDT  -9223372036854689408 = NULL
> EST5EDT  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Mon Feb  9 06:59:59 1942 UT = Mon Feb  9 01:59:59 1942 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Mon Feb  9 07:00:00 1942 UT = Mon Feb  9 03:00:00 1942 EWT isdst=1 
> gmtoff=-14400
> EST5EDT  Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 
> gmtoff=-14400
> EST5EDT  Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 
> gmtoff=-18000
> EST5EDT  9223372036854689407 = NULL
> EST5EDT  9223372036854775807 = NULL
> 
> OK?  There's dump number one.  Now let's compare to dump number two:
> 
> unicorn:~$ zdump -v -c 1918,1950 America/New_York
> America/New_York  -9223372036854775808 = NULL
> America/New_York  -9223372036854689408 = NULL
> America/New_York  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST 
> isdst=0 gmtoff=-18000
> [...]
> 
> I'm truncating this one because it's much longer.  Apparently this one
> shows every year, even if there are no DST rule changes that year.  What
> does this mean?  Hell if I know.  Let's pick a date that's in one of
> these dumps but not the other, shall we?
> 
> unicorn:~$ TZ=America/New_York date -d '1920-03-28 +4 hours'
> Sun Mar 28 05:00:00 EDT 1920
> unicorn:~$ TZ=EST5EDT date -d '1920-03-28 +4 hours'
> Sun Mar 28 04:00:00 EST 1920
> 
> There.  There's a timestamp where you get a different result.  I'm
> sure there are more.
> 
> If being wrong about times in 1920 (and probably other years as well)
> is not acceptable to you, then you should switch to America/New_York.
> 
> If the idea that you would ever CARE about the clock reading at various
> times during the 1920s is laughable to you, then do whatever you want,
> but please don't advocate that others follow your example.

Well since I am not going to set any of my systems to a time in 1920, then I 
believe I am save from the time machines.

I did not advocate setting the time zone to any particular one.  I think you 
read that into my posts.   Nor did I tell anyone to use a particular time zone 
file.  

What I did post was what I use, that is not adv

Re: Found a liar

[Arno Lehmann]

Hello yxcv,

by now, you got a few comments and questions. Which you did not bother 
replying to.


In the context of calling other parties liars in public, this is 
distasteful. It also reflects badly on you and probably brings you 
closer to a few block lists.





Sorry for spamming the whole list, but I was quite annoyed with this 
situation.


Arno


--
Arno Lehmann

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

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Albretch Mueller]

 What I had been doing is use "depends" to get all dependencies and
then download each of them. I think that is why I was getting those
repeated binary files. I thought when you said "download" you just
meant "download".
lbrtchx

ToG Linux (first draft of a RFC) ...

[Albretch Mueller]

ToG Linux ("Touch of God" (no blasphemy intended) a la Michelangelo's
"The Creation of Adam", with one of the poetic connotations being, to
make best use of what you know to be certain, what "you can touch"
(can exclusively reach with certainty), is readily available in your
immediacy (before the physical reality of fields was understood,
Leibniz made fun of Newton's "actions at a distance", of which Newton
himself admitted not to know its origin and nature ...))
This would be a first draft about what could be considered a poor-man
Debian Live air-gap running instance. I post it here because Debian is
definitely my favorite distro (and many other are based on it), the
deb live and blends mailing lists are mostly about specific changes to
their project and I am talking about general topics relating to
securing a Debian Linux running instance in a relatively straight
forward way based on options which are already available. No fanciness
or "conceptual demands"! Nothing new under the sun! It is more of a
„Deutsches Eck” kind of thing, making things confluent to make good of
them.
Some of the ideas have nothing to do with Debian per se, but
objectives which conceptual ecosystem aims at being able to use
computers with some of that thing they used to call "privacy", at the
very least less exposure. Most of the measures are procedural and
physical (involving hardware). Using just software would just be an
illusive waste of time.
~
0. Objectives:
0.1) even though by their very nature OSs', applications, network-
and/or IO-enabled computers can't possibly be secure, any malicious
software which manage to get in your system would be mindlessly erased
simply by a less than a minute reboot (only that would keep "hackers"
away, they need persistence and they know they would be exposing their
rear end to the four winds and that you won't have to spend your mind
on worries and/or your hard earned money on "virus scanners", "malware
detectors", ...);
0.2) you may be able to and should use the same computer in both:
exposed, and "air-gapped" mode;
0.3) ToG would require just some disciplined and prudent exercise of
your exposed activities, (if any) near to zero comma nada monetary
investment;
0.4) ToG would let its user base have -some- healthy and aware
tranquility of mind when it comes to safety and "privacy";
0.5) the use of a package extensions phase during the boot process,
makes blends unnecessary, since you would enhance the functionality of
your initial Debian Live DVD during boot up in whichever way you want
and even use other supported architecture*.
*:
0.5)* multi-session DVDs for various architectures?
0.5)* generally speaking people using certain applications (say
eclipse or Wazuh unified XDR and SIEM protection framework) would have
a better sense of where the configuration and work files are kept.
~
1) What you will need:
1.1) Debian Live on a DVD[-R|+R] write-once and finalize disk (you
can't physically write onto) (alternatively USB pen drives could be
used, but are not recommended, they are not simple "WYSWYG" things (a
USB pen drive can be a RF device in ways you can't simply tell apart
from regular ones) and most (all?) breaks into air-gap systems have
been through misuse of USB pen drives)*
1.2) a "package extensions" USB pen drive (where you would keep extra,
specific packages you need, not included in §1.1) and a lokal web
references file;
1.3) a computer, you own*, which:
1.3.1) BIOS doesn't include networking, is open source (could be
"trusted and checked") and which binaries you can linearize and dump
in full as a file*;
1.3.2) BIOS lets you choose the boot device;
1.3.3) is not powered, not connected to the Internet (either as part
of a wired or wireless network);
1.4) you will have a hard drive for your own your data which you never
connect to the Internet*.
*:
1.1)* an 8 cm (3.1 inches) DVD could be used which would easily fit in
your shirt's front pocket including the §1.2 USB pen drive, with the
most basic functionality.
1.3)* if you don't own the computer you are using, you will use the
Debian Live DVD as such without extra extensions automatic fanciness
and there will still be the option to update §1.2 for the new
architecture and Linux version/distribution, but it must be done on
the box you own which is the one with allows you access to the §1.2
strategy.
1.3.1)* Is there such a "safe BIOS"? Could you follow a physically
safe procedure around this? Could you: a) dump the BIOS data onto a
file? b) blank and reset the BIOS?, c) import a "new" binary and check
it?
1.4)* why aren't hard drives being produced with a physical/mechanical
switch to enable them to read data into or NOT?
1.4)* which HAL (Hardware AnaLyzer) techniques are used to check the
hardware inside hard disk drives and computers?
~
2) GRUB boot up Procedure (boot loaders' moment!):
2.1) insert Debian Live DVD;
2.2) power on computer;
2.3) select DVD as starting device;
2.4) as part of a secure boot procedure, at the grub sta

RE: time question, as in ntp?

[Bonno Bloksma]

Hi,

>> $ cat /etc/network/interfaces
[...]
>> # The primary network interface
>> allow-hotplug ens32
>> iface ens32 inet static

> Depending on what services your computer runs, you may wish to change 
> "allow-hotplug ens32" to "auto ens32". 
Thanks that one got by me when I created a new server. :-(

> Of course, if everything is working as you have it, then "don't touch it" is 
> a wise course.  
Of course but then, if we know it is not the best config, why wait for it to go 
wrong. ;-)

Bonno Bloksma

Re: ntpsec as server questions

[James Cloos]

the current America/New_York equiv is:

  EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 13:27:40 (-0500), Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
> > TZ=POSIX;date
> > Wed Dec  6 18:00:38 POSIX 2023
> 
> "POSIX" is not a valid timezone name in Debian 12.  Therefore you're
> just seeing UTC here.  Giving an invalid TZ always gives you UTC, but
> with whatever crazy-ass name you used echoed back at you, to give you
> the illusion that your name was valid.  It's a *huge* pitfall.  I've been
> bit by this myself.
> 
> > TZ=America/New_York;date
> > Wed Dec  6 13:00:21 EST 2023
> > 
> > TZ=EST5DST;date
> > Wed Dec  6 13:01:10 EST 2023
> > 
> > What is the problem?
> 
> Gods DAMN it.  I didn't want to have to dig through these stupid zone
> dumps, but you're FORCING my hand.
> 
> unicorn:~$ zdump -v -c 1918,1950 EST5EDT
> EST5EDT  -9223372036854775808 = NULL
> EST5EDT  -9223372036854689408 = NULL



> EST5EDT  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 
> gmtoff=-18000



> EST5EDT  Mon Feb  9 06:59:59 1942 UT = Mon Feb  9 01:59:59 1942 EST isdst=0 
> gmtoff=-18000
> EST5EDT  Mon Feb  9 07:00:00 1942 UT = Mon Feb  9 03:00:00 1942 EWT isdst=1 
> gmtoff=-14400
> EST5EDT  Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 
> gmtoff=-14400
> EST5EDT  Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 
> gmtoff=-14400
> EST5EDT  Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 
> gmtoff=-18000



> EST5EDT  9223372036854689407 = NULL
> EST5EDT  9223372036854775807 = NULL
> 
> OK?  There's dump number one.  Now let's compare to dump number two:
> 
> unicorn:~$ zdump -v -c 1918,1950 America/New_York
> America/New_York  -9223372036854775808 = NULL
> America/New_York  -9223372036854689408 = NULL
> America/New_York  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST 
> isdst=0 gmtoff=-18000
> America/New_York  Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT 
> isdst=1 gmtoff=-14400
> America/New_York  Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST 
> isdst=0 gmtoff=-18000
> [...]
> 
> I'm truncating this one because it's much longer.  Apparently this one
> shows every year, even if there are no DST rule changes that year.  What
> does this mean?  Hell if I know.

Comparing zdump -v America/New_York | cut -b 19- > /tmp/a-ny
with  zdump -v EST5EDT | cut -b 10- > /tmp/e5e

shows that the former starts at 1883 (no changes then until 1918,
 above), and the latter omits the period 1920–1966, except
for War Time and Peace Time (between  and ).

I've expanded my guesses as to why. I had thought that it might be
because the "Unix System V approach from New Jersey (insert
appropriate booing for best effect)" implied that NJ didn't observe
DST over that period, but perhaps it's just that there's no way to
determine single dates for changing the clocks.

 "Having rallied the general public's support, the Time Uniformity
 Committee's goal was accomplished, but only after discovering and
 disclosing that on the 35-mile stretch of highway (Route 2) between
 Moundsville, W.V., and Steubenville, Ohio, every bus driver and his
 passengers had to endure seven time changes!"

 https://www.webexhibits.org//daylightsaving/e.html

Cheers,
David.

Re: ntpsec as server questions

[David Wright]

On Wed 06 Dec 2023 at 12:06:04 (-0500), Pocket wrote:

> From the README
> 
> The information in the time zone data files is by no means authoritative;
> fixes and enhancements are welcome.  Please see the file CONTRIBUTING
> for details

Time zones are a civil and legal matter, so non-authoritative would
mean that the tz database would not be evidence in a court of law.

> I take that as chaos reins supreme and one zone is no better or worst
> that the other(s)
> 
> IE there is no "standard"

We all depend on there being a standard to live our daily lives.
It's only when you start compiling all the standards that have been
and will be used that it starts to resemble "chaos", particularly
in some parts of the world. (The US appears to have been one of
those areas in the not so distant past.)

Fixes and enhancements means that as changes are reported or
discovered, the database is corrected. There's a constant trickle
of future changes being made by governments. People also discover
historical inaccuracies from literature, like old legal documents
and newspaper archives. I respect their research.

On Wed 06 Dec 2023 at 13:02:45 (-0500), Pocket wrote:

> TZ=POSIX;date
> Wed Dec  6 18:00:38 POSIX 2023

You've got a choice of writing something like posix/America/New_York
or posixrules, though IDK where the last name came from. (I don't
think it can be New Jersey on this occasion.)

> TZ=America/New_York;date
> Wed Dec  6 13:00:21 EST 2023
> 
> TZ=EST5DST;date
> Wed Dec  6 13:01:10 EST 2023
> 
> What is the problem?

Likely none for times present and future, unless Eric Adams should
pass a timezone bill. (In the 2010s, several U.S. states considered
legislation to move from the Eastern Time Zone to Atlantic Standard
Time, allegedly.)

But I've already posted an example in this thread where these
timezones give different answers:

  https://lists.debian.org/debian-user/2023/12/msg00329.html

Cheers,
David.

mdam: email when re-syncing

[Franco Martelli]

Hi everybody,

I've mdadm that is running on Debian bookworm that it scans my RAID 5 
array. It happened that after a cycle of hard reboot due to system 
freeze, mdadm starts resync the array.


I noticed this looking at the red LED of the HDD activity almost always 
fired up and the "top" utility that it showed mdadm at 100% of cpu usage.


I dunno if all it's OK, here my /proc/mdstat output:

~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] 
[raid1] [raid10]

md0 : active raid5 sda1[0] sdc1[2] sdd1[3](S) sdb1[1]
  1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 
[3/3] [UUU]


unused devices: 

I was amazed that mdadm doesn't warn me of the re-syncing process had 
started via an email. If I run:


~# mdadm --monitor --scan --test --oneshot

I've the email test-message in my inbox regularly. So is it possible to 
be warned via email when an array resync process has started? Of which 
RAID array failures does mdadm warn the user by sending an email?


Thanks in advance
Cheers

--
Franco Martelli

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 01:02:45PM -0500, Pocket wrote:
> TZ=POSIX;date
> Wed Dec  6 18:00:38 POSIX 2023

"POSIX" is not a valid timezone name in Debian 12.  Therefore you're
just seeing UTC here.  Giving an invalid TZ always gives you UTC, but
with whatever crazy-ass name you used echoed back at you, to give you
the illusion that your name was valid.  It's a *huge* pitfall.  I've been
bit by this myself.

> TZ=America/New_York;date
> Wed Dec  6 13:00:21 EST 2023
> 
> TZ=EST5DST;date
> Wed Dec  6 13:01:10 EST 2023
> 
> What is the problem?

Gods DAMN it.  I didn't want to have to dig through these stupid zone
dumps, but you're FORCING my hand.

unicorn:~$ zdump -v -c 1918,1950 EST5EDT
EST5EDT  -9223372036854775808 = NULL
EST5EDT  -9223372036854689408 = NULL
EST5EDT  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST isdst=0 
gmtoff=-18000
EST5EDT  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT isdst=1 
gmtoff=-14400
EST5EDT  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST isdst=0 
gmtoff=-18000
EST5EDT  Mon Feb  9 06:59:59 1942 UT = Mon Feb  9 01:59:59 1942 EST isdst=0 
gmtoff=-18000
EST5EDT  Mon Feb  9 07:00:00 1942 UT = Mon Feb  9 03:00:00 1942 EWT isdst=1 
gmtoff=-14400
EST5EDT  Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 18:59:59 1945 EWT isdst=1 
gmtoff=-14400
EST5EDT  Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 19:00:00 1945 EPT isdst=1 
gmtoff=-14400
EST5EDT  Sun Sep 30 05:59:59 1945 UT = Sun Sep 30 01:59:59 1945 EPT isdst=1 
gmtoff=-14400
EST5EDT  Sun Sep 30 06:00:00 1945 UT = Sun Sep 30 01:00:00 1945 EST isdst=0 
gmtoff=-18000
EST5EDT  9223372036854689407 = NULL
EST5EDT  9223372036854775807 = NULL

OK?  There's dump number one.  Now let's compare to dump number two:

unicorn:~$ zdump -v -c 1918,1950 America/New_York
America/New_York  -9223372036854775808 = NULL
America/New_York  -9223372036854689408 = NULL
America/New_York  Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 30 06:59:59 1919 UT = Sun Mar 30 01:59:59 1919 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 30 07:00:00 1919 UT = Sun Mar 30 03:00:00 1919 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 26 05:59:59 1919 UT = Sun Oct 26 01:59:59 1919 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 26 06:00:00 1919 UT = Sun Oct 26 01:00:00 1919 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 28 06:59:59 1920 UT = Sun Mar 28 01:59:59 1920 EST 
isdst=0 gmtoff=-18000
America/New_York  Sun Mar 28 07:00:00 1920 UT = Sun Mar 28 03:00:00 1920 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 31 05:59:59 1920 UT = Sun Oct 31 01:59:59 1920 EDT 
isdst=1 gmtoff=-14400
America/New_York  Sun Oct 31 06:00:00 1920 UT = Sun Oct 31 01:00:00 1920 EST 
isdst=0 gmtoff=-18000
[...]

I'm truncating this one because it's much longer.  Apparently this one
shows every year, even if there are no DST rule changes that year.  What
does this mean?  Hell if I know.  Let's pick a date that's in one of
these dumps but not the other, shall we?

unicorn:~$ TZ=America/New_York date -d '1920-03-28 +4 hours'
Sun Mar 28 05:00:00 EDT 1920
unicorn:~$ TZ=EST5EDT date -d '1920-03-28 +4 hours'
Sun Mar 28 04:00:00 EST 1920

There.  There's a timestamp where you get a different result.  I'm
sure there are more.

If being wrong about times in 1920 (and probably other years as well)
is not acceptable to you, then you should switch to America/New_York.

If the idea that you would ever CARE about the clock reading at various
times during the 1920s is laughable to you, then do whatever you want,
but please don't advocate that others follow your example.

Re: how to firefox settings

[debian-user]

fxkl4...@protonmail.com wrote:
> on a page in firefox use tools -> page info -> permissions
> i notice override keyboard shortcuts is set to allow
> where can i change the defaults for this

Defaults are built-in; you can't change them (except by modifying the
source and recompiling).

You can turn off the Use defaults button and then change Allow or Block
as you wish. That's what the popup allows.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 12:55, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 05:40:00PM -, Curt wrote:

  POSIX format specification

  The POSIX time zone format is the traditionally used format for AIX systems 
and
  provides a slight performance advantage over the Olson time zone format.
  Example of a POSIX format is EST5EDT.

  The advantage of POSIX is that you can easily and explicitly specify the time
  zone and daylight saving time (DST) details manually, however you wish. The
  performance of applications that call time functions will be faster than using
  Olson specification. And whenever a nation's government decides to change its
  DST rules, the POSIX format is simpler because we can simply change the
  variable definition. There is no need to install any new patch to update time
  database files, as Olson requires.

Does this apply to "us?"

https://developer.ibm.com/articles/au-aix-posix/

This does *not* describe how Debian's EST5EDT, and similarly named
zones, work.  Debian's time zones use a database of DST transition
periods -- all of them, even EST5EDT.  It's just a different set of
transitions than America/New_York uses.

Also, you snipped the rest of that section:

   The disadvantage of this approach is that it cannot track the history
   of timezone-related changes and it is not easy to read as it looks
   cryptic. When a government changes the rules and you update your time
   zone (TZ) variable, it is assumed to be the same DST rule for all
   years past and future.

That's a fairly important paragraph.

Applying the same rules to a timestamp in 2023 and a timestamp in 2006
may give incorrect results, as the DST rules in the US changed in 2007.
That's why the method described by this AIX manual is no longer in
common use.


TZ=POSIX;date
Wed Dec  6 18:00:38 POSIX 2023

TZ=America/New_York;date
Wed Dec  6 13:00:21 EST 2023

TZ=EST5DST;date
Wed Dec  6 13:01:10 EST 2023

What is the problem?

--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 05:40:00PM -, Curt wrote:
>  POSIX format specification
> 
>  The POSIX time zone format is the traditionally used format for AIX systems 
> and
>  provides a slight performance advantage over the Olson time zone format.
>  Example of a POSIX format is EST5EDT.
> 
>  The advantage of POSIX is that you can easily and explicitly specify the time
>  zone and daylight saving time (DST) details manually, however you wish. The
>  performance of applications that call time functions will be faster than 
> using
>  Olson specification. And whenever a nation's government decides to change its
>  DST rules, the POSIX format is simpler because we can simply change the
>  variable definition. There is no need to install any new patch to update time
>  database files, as Olson requires.
> 
> Does this apply to "us?"
> 
> https://developer.ibm.com/articles/au-aix-posix/

This does *not* describe how Debian's EST5EDT, and similarly named
zones, work.  Debian's time zones use a database of DST transition
periods -- all of them, even EST5EDT.  It's just a different set of
transitions than America/New_York uses.

Also, you snipped the rest of that section:

  The disadvantage of this approach is that it cannot track the history
  of timezone-related changes and it is not easy to read as it looks
  cryptic. When a government changes the rules and you update your time
  zone (TZ) variable, it is assumed to be the same DST rule for all
  years past and future.

That's a fairly important paragraph.

Applying the same rules to a timestamp in 2023 and a timestamp in 2006
may give incorrect results, as the DST rules in the US changed in 2007.
That's why the method described by this AIX manual is no longer in
common use.

Re: ntpsec as server questions

[Curt]

On 2023-12-06, Max Nikulin  wrote:
>
> My reading of this document is that EST5EDT file in tzdata is a POSIX 
> extension, not "true" POSIX.
>

 POSIX format specification

 The POSIX time zone format is the traditionally used format for AIX systems and
 provides a slight performance advantage over the Olson time zone format.
 Example of a POSIX format is EST5EDT.

 The advantage of POSIX is that you can easily and explicitly specify the time
 zone and daylight saving time (DST) details manually, however you wish. The
 performance of applications that call time functions will be faster than using
 Olson specification. And whenever a nation's government decides to change its
 DST rules, the POSIX format is simpler because we can simply change the
 variable definition. There is no need to install any new patch to update time
 database files, as Olson requires.

Does this apply to "us?"

https://developer.ibm.com/articles/au-aix-posix/

Re: ntpsec as server questions

[Pocket]

On 12/6/23 12:24, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 12:06:04PM -0500, Pocket wrote:

 From the README

The information in the time zone data files is by no means authoritative;
fixes and enhancements are welcome.  Please see the file CONTRIBUTING
for details

I take that as chaos reins supreme and one zone is no better or worst that
the other(s)

IE there is no "standard"

The standards are determined by government entities.  The question is
how accurately a given time zone reflects the decisions made by the
government entities within a given political space.

If America/New_York more accurately describes the tracking of political
timekeeping within the Eastern part of the United States (with specific
exceptions, e.g. Kentucky) than EST5EDT does, then America/New_York
should be preferred for most purposes.


Well I have used EST5DST for many years, maybe decades and I have yet to have an issue 
with it, so I wouldn't want to "prefer" America/New_York over EST5DST.

I haven't found any thing to bump me into changing the time zone file.
Until I have issues with it I will continue to use it.

If it ain't broke don't fix it.


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 12:06:04PM -0500, Pocket wrote:
> From the README
> 
> The information in the time zone data files is by no means authoritative;
> fixes and enhancements are welcome.  Please see the file CONTRIBUTING
> for details
> 
> I take that as chaos reins supreme and one zone is no better or worst that
> the other(s)
> 
> IE there is no "standard"

The standards are determined by government entities.  The question is
how accurately a given time zone reflects the decisions made by the
government entities within a given political space.

If America/New_York more accurately describes the tracking of political
timekeeping within the Eastern part of the United States (with specific
exceptions, e.g. Kentucky) than EST5EDT does, then America/New_York
should be preferred for most purposes.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 11:42, Max Nikulin wrote:

On 06/12/2023 12:22, David Wright wrote:

On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:

I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.


During WWII they had War Time, just as Britain had Double Summer Time,
with Summer Time through the winters.


I was aware of special DST rules during WWII, but I did not expect 
that "EST5EDT" may include any historical data. Certainly it does not 
explicitly specify days when summer time is effective, just 
abbreviations "EST" and "EDT" with time offset of 5 hours behind UTC 
for "EST". Partial time transition history is new for me for these 
kind of time zones.


https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
is a long enough article.


I don't know who maintains the legacy EST5EDT zone, or for whom;
the quotation below suggests that it may just follow New Jersey.
For a long period after the war, it seems the timezones in the US
were all over the place.


https://data.iana.org/time-zones/theory.html :

Older versions of this package defined legacy names that are
incompatible with the first guideline of location names, but which are
still supported. These legacy names are mostly defined in the file
'etcetera'. Also, the file 'backward' defines the legacy names
'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0', 'GMT0', 'GMT-0' and 'GMT+0', and
the file 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
'MST7MDT', and 'PST8PDT'.

[...]

POSIX does not define the DST transitions for TZ values like "EST5EDT".
Traditionally the current US DST rules were used to interpret such
values, but this meant that the US DST rules were compiled into each
time conversion package, and when US time conversion rules changed (as
in the United States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated to ensure proper results.


My reading of this document is that EST5EDT file in tzdata is a POSIX 
extension, not "true" POSIX.


A lot of details concerning database contents are given if files like
https://github.com/eggert/tz/blob/main/northamerica

I have not noticed any America/* timezone that strictly follows EST5EDT.



From the README

The information in the time zone data files is by no means authoritative;
fixes and enhancements are welcome.  Please see the file CONTRIBUTING
for details

I take that as chaos reins supreme and one zone is no better or worst 
that the other(s)


IE there is no "standard"


--
It's not easy to be me

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 11:28:40AM -0500, Pocket wrote:
> diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York
> Binary files /usr/share/zoneinfo/EST5EDT and
> /usr/share/zoneinfo/America/New_York differ

unicorn:/usr/share/zoneinfo$ ls -l EST5EDT
-rw-r--r-- 1 root root 2310 May 28  2023 EST5EDT

unicorn:/usr/share/zoneinfo$ ls -l America/New_York 
-rw-r--r-- 1 root root 3552 May 28  2023 America/New_York

unicorn:/usr/share/zoneinfo$ file EST5EDT 
EST5EDT: timezone data (fat), version 2, 5 gmt time flags, 5 std time flags, no 
leap seconds, 149 transition times, 5 local time types, 16 abbreviation chars

unicorn:/usr/share/zoneinfo$ file America/New_York 
America/New_York: timezone data (fat), version 2, 6 gmt time flags, 6 std time 
flags, no leap seconds, 236 transition times, 6 local time types, 20 
abbreviation chars

OK, they are definitely not the same.  I don't feel like digging through
them to try to figure out *what* the differences are, but clearly there
must be *some* point(s) in time where they give different results.

If you wish to continue using the legacy time zone, knowing that it's
different from the proper one (but not precisely in what way), then on
your own head be it.

For comparison, this one is cleary safe to use:

unicorn:/usr/share/zoneinfo$ ls -l US/Eastern
lrwxrwxrwx 1 root root 19 May 28  2023 US/Eastern -> ../America/New_York

Re: ntpsec as server questions

[Max Nikulin]

On 06/12/2023 12:22, David Wright wrote:

On Tue 05 Dec 2023 at 23:37:31 (+0700), Max Nikulin wrote:

I am surprised that POSIX EST5EDT timezone has irregularities at least
as it is implemented in GNU libc. I believed that it specifies just
standard and summer time.


During WWII they had War Time, just as Britain had Double Summer Time,
with Summer Time through the winters.


I was aware of special DST rules during WWII, but I did not expect that 
"EST5EDT" may include any historical data. Certainly it does not 
explicitly specify days when summer time is effective, just 
abbreviations "EST" and "EDT" with time offset of 5 hours behind UTC for 
"EST". Partial time transition history is new for me for these kind of 
time zones.


https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
is a long enough article.


I don't know who maintains the legacy EST5EDT zone, or for whom;
the quotation below suggests that it may just follow New Jersey.
For a long period after the war, it seems the timezones in the US
were all over the place.


https://data.iana.org/time-zones/theory.html :

Older versions of this package defined legacy names that are
incompatible with the first guideline of location names, but which are
still supported. These legacy names are mostly defined in the file
'etcetera'. Also, the file 'backward' defines the legacy names
'Etc/GMT0', 'Etc/GMT-0', 'Etc/GMT+0', 'GMT0', 'GMT-0' and 'GMT+0', and
the file 'northamerica' defines the legacy names 'EST5EDT', 'CST6CDT',
'MST7MDT', and 'PST8PDT'.

[...]

POSIX does not define the DST transitions for TZ values like "EST5EDT".
Traditionally the current US DST rules were used to interpret such
values, but this meant that the US DST rules were compiled into each
time conversion package, and when US time conversion rules changed (as
in the United States in 1987 and again in 2007), all packages that
interpreted TZ values had to be updated to ensure proper results.


My reading of this document is that EST5EDT file in tzdata is a POSIX 
extension, not "true" POSIX.


A lot of details concerning database contents are given if files like
https://github.com/eggert/tz/blob/main/northamerica

I have not noticed any America/* timezone that strictly follows EST5EDT.

Re: ntpsec as server questions

[Curt]

On 2023-12-06, Greg Wooledge  wrote:
>
> Honestly, I don't see the appeal of using legacy time zone names.  Is
> it just for the sake of contrariness?
>

No lack of contrariness around here. There exists such a thing as putting too
fine a point on a thing, a notion which appears to escape some technical
mentalities.

In defence of time zones (they don't really need it, I guess):

 Why are the clocks in Urumqi, China, so far out of kilter with the cycles of
 the sun? Because of a legacy of Mao Zedong and the Communist Party’s desire for
 unified control. Though China is almost as wide as the continental United
 States, the whole country is officially in just one time zone — Beijing time.

 So when it’s 7 a.m. in the Forbidden City, it’s also officially 7 a.m. 2,000
 miles to the west in Urumqi, the capital of the Xinjiang region — even if the
 stars are still out there.

 That can lead to headaches — and lost sleep. “It’s hard to adjust,” says Gao
 Li, a sanitation worker in Urumqi. “I often think we must be the only people
 who eat dinner at midnight.”
 
 So schools, airports and train stations operate at odd hours; national exams
 are sometimes given in the dead of night; and restaurants stay open for dinner
 into the wee hours.

 The eccentricities of the clock also tend to divide people in Xinjiang by
 ethnicity. The Uighurs, Turkic-speaking Muslims who consider the region their
 homeland, tend to set their clocks two hours earlier, to more closely match the
 local day. But the Han Chinese who live there, members of China’s predominant
 ethnic group, generally follow Beijing time. The discrepancies can be a source
 of confusion and frustration, especially for younger people who frequently
 socialize across ethnic lines.

https://www.nytimes.com/2016/06/17/world/asia/china-single-time-zone.html

Re: ntpsec as server questions

[Pocket]

On 12/6/23 11:18, Greg Wooledge wrote:

On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote:

Well POSIX has worked for me since the days of Xenix and System V.

Well, most of the goofy time zone changes were all *before* that.  But
there's at least one that happened more recently

unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours'
Sun Mar 12 04:00:00 EST 2006

unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours'
Sun Mar 11 05:00:00 EDT 2007

So, OK, I guess the EST5EDT time zone in Debian 12 properly handles
the change to start of DST in the US in 2007 (and more specifically,
handles dates *older* than that using the historic rules instead of
the current rules).

Looking at other periods of interest from Wikipedia:

unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours'
Sun Apr  5 05:00:00 EDT 1987

unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours'
Sun Jan  6 05:00:00 EDT 1974

unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours'
Sun Apr 30 05:00:00 EDT 1967

I guess EST5EDT in Debian 12 is more like a synonym for America/New_York
than a real historical EST5EDT as described by Erik Naggum
.

If this is satisfactory, then you can continue using the legacy time
zone without running into problems.  At least on current Debian systems.
I wouldn't know how well-behaved that time zone is on other systems.



I used POSIX time zones on other systems including my custom scratch 
built ones.


The custom built systems was built using a cross compiler for the AMD64, 
aarch64 and armv7a platforms.


Never had an issue.

Don't see what the issue is here?




Honestly, I don't see the appeal of using legacy time zone names.  Is
it just for the sake of contrariness?


diff /usr/share/zoneinfo/EST5EDT /usr/share/zoneinfo/America/New_York
Binary files /usr/share/zoneinfo/EST5EDT and 
/usr/share/zoneinfo/America/New_York differ


Because I can ;}


--
It's not easy to be me

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Sven Joachim]

On 2023-12-06 15:24 +0100, Harald Dunkel wrote:

> I have tried to upgrade to 12.3, but apparently the dependencies
> of the new nvidia-kernel-dkms version cannot be fulfilled.
> firmware-nvidia-gsp (= 525.147.05) is missing. I tried several
> repositories.

Note that Debian 12.3 has not been released yet.

> Hopefully I am not too blind to find the bug report (the new
> version fixes a CVE, ie details might not have been disclosed),
> so I wonder what is the story here?

Maintainer uploads to (old)stable are staged in proposed-updates, so you
would have to enable bookworm-proposed-updates to install the new
version of firmware-nvidia-gsp.

Or wait until the actual release of Debian 12.3 next weekend.

Cheers,
   Sven

Re: ntpsec as server questions

[Greg Wooledge]

On Wed, Dec 06, 2023 at 10:44:42AM -0500, Pocket wrote:
> Well POSIX has worked for me since the days of Xenix and System V.

Well, most of the goofy time zone changes were all *before* that.  But
there's at least one that happened more recently

unicorn:~$ TZ=EST5EDT date -d '2006-03-12 +4 hours'
Sun Mar 12 04:00:00 EST 2006

unicorn:~$ TZ=EST5EDT date -d '2007-03-11 +4 hours'
Sun Mar 11 05:00:00 EDT 2007

So, OK, I guess the EST5EDT time zone in Debian 12 properly handles
the change to start of DST in the US in 2007 (and more specifically,
handles dates *older* than that using the historic rules instead of
the current rules).

Looking at other periods of interest from Wikipedia:

unicorn:~$ TZ=EST5EDT date -d '1987-04-05 +4 hours'
Sun Apr  5 05:00:00 EDT 1987

unicorn:~$ TZ=EST5EDT date -d '1974-01-06 +4 hours'
Sun Jan  6 05:00:00 EDT 1974

unicorn:~$ TZ=EST5EDT date -d '1967-04-30 +4 hours'
Sun Apr 30 05:00:00 EDT 1967

I guess EST5EDT in Debian 12 is more like a synonym for America/New_York
than a real historical EST5EDT as described by Erik Naggum
.

If this is satisfactory, then you can continue using the legacy time
zone without running into problems.  At least on current Debian systems.
I wouldn't know how well-behaved that time zone is on other systems.

Honestly, I don't see the appeal of using legacy time zone names.  Is
it just for the sake of contrariness?

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Roberto C . Sánchez]

On Wed, Dec 06, 2023 at 04:45:41PM +0100, Harald Dunkel wrote:
> On 2023-12-06 15:55:58, Michael Kjörling wrote:
> > 
> > Which ones?
> > 
> 
> ftp.de.debian.org
> ftp2.de.debian.org
> deb.debian.org
> 
> > That package is in the non-free-firmware component; are you bringing
> > that in?
> > 
> > https://packages.debian.org/bookworm/firmware-nvidia-gsp
> > 
> 
> There is still the old version 525.125.06-1~deb12u1 on this
> page. Expected is version 525.147.05.
> 
That version is available in testing and unstable:
https://packages.debian.org/search?keywords=firmware-nvidia-gsp

You won't get version 525.147.05 in stable (which is what 12.3 is).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Harald Dunkel]

On 2023-12-06 15:55:58, Michael Kjörling wrote:


Which ones?



ftp.de.debian.org
ftp2.de.debian.org
deb.debian.org


That package is in the non-free-firmware component; are you bringing
that in?

https://packages.debian.org/bookworm/firmware-nvidia-gsp



There is still the old version 525.125.06-1~deb12u1 on this
page. Expected is version 525.147.05.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 10:07, Max Nikulin wrote:

On 06/12/2023 20:08, Pocket wrote:

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.

[...]

I follow POSIX


There are enough oversights in various standards. When accurate time 
zone DB is unavailable, POSIX ones might be used (if risk to get wrong 
results is accepted). Otherwise, from my of view, it is a legacy to 
keep aside and a kind of cargo cult. That is why I asked concerning 
your reasons.



Well POSIX has worked for me since the days of Xenix and System V.





I introduced EST5DST to this by simply posted my configuration.


Maybe due to language barrier I perceived it as a recommendation for 
Gene. The same time zone appeared earlier in a Gene's message. Perhaps 
he still has it as the /etc/localtime link target. Of course, you are 
free to have whatever you want in your configuration. Please, be 
responsible suggesting anything to others.



I post what works for and the information I have found due to my research.

It doesn't mean what I use will work or solve others issues.

If it offends you then so be it.


Many times I will research an issue and NOT use what others posted as it 
doesn't work for me.


I may end up finding my own solution.




Do you really need TZ environment variable especially set to the 
value in system-wide configuration?

[...]
I doesn't hurt anything, What if I install some application that uses 
it and it is not set?


It may cause waste of time when you will need to change time zone. If 
not all occurrences are updated you may see wrong time. For me it is a 
reason to avoid unnecessary settings.



Which is why I use a script to change it





cat /etc/default/locale
LANG=POSIX


Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are 
enough subtle differences (sorting, etc.) from any en_* locale.





locale charmap
ANSI_X3.4-1968

--
It's not easy to be me

Re: Problem between kernel 6.5.0-5 (testing) and Realtek NICs ?

[Erwan David]

Le 06/12/2023 à 15:55, Erwan David a écrit :
After upgrade to 6.5.0-5 (a 6.5.13 kernel in testing), impossible to 
use the laptop when Realtek card present (in dock). it boots, sddm 
works but anything which tries to access networking (even the ip 
command) is then blocked


It could be the same problem as in 
https://discussion.fedoraproject.org/t/kernel-6-5-12-or-later-on-fedora-39-broken-network-on-lenovo-t570/97586/18


I'll try installing the realtek-formware package, but the fedora 
discussion does not give much hope...



Ok, it works with firmware-realtek package, from the non-free-firmware 
section (which should be added in /etc/apt/sources.list if not already 
present)


--
Erwan David

Re: what is a tasklet

[Darac Marjal]

On 06/12/2023 12:32, fxkl4...@protonmail.com wrote:

DI: DI: tasklet schedule cost 12ms.

this interesting  message started showing up in syslog a week or so ago
i've never noticed them before
any ideas whet this is


According to https://lwn.net/Articles/830964/, they were a way to defer 
the execution of some code (e.g. an interrupt handler). The intention 
(also documented at https://lwn.net/Articles/239633/) is that tasklets 
are deprecated, and will be replaced by other APIs.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ntpsec as server questions

[Max Nikulin]

On 06/12/2023 20:08, Pocket wrote:

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.

[...]

I follow POSIX


There are enough oversights in various standards. When accurate time 
zone DB is unavailable, POSIX ones might be used (if risk to get wrong 
results is accepted). Otherwise, from my of view, it is a legacy to keep 
aside and a kind of cargo cult. That is why I asked concerning your reasons.



I introduced EST5DST to this by simply posted my configuration.


Maybe due to language barrier I perceived it as a recommendation for 
Gene. The same time zone appeared earlier in a Gene's message. Perhaps 
he still has it as the /etc/localtime link target. Of course, you are 
free to have whatever you want in your configuration. Please, be 
responsible suggesting anything to others.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration?

[...]
I doesn't hurt anything, What if I install some application that uses it 
and it is not set?


It may cause waste of time when you will need to change time zone. If 
not all occurrences are updated you may see wrong time. For me it is a 
reason to avoid unnecessary settings.



cat /etc/default/locale
LANG=POSIX


Does it set UTF-8 encoding? Sometimes I use C.UTF-8. However there are 
enough subtle differences (sorting, etc.) from any en_* locale.

Re: Isolated Web Co Session crash Firefox-ESR

[tomas]

On Wed, Dec 06, 2023 at 09:27:06PM +0700, Max Nikulin wrote:
> On 06/12/2023 12:04, to...@tuxteam.de wrote:
> > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> > > 
> > > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > > 
> > > Sadly it looks like I'll need to do this daily,
> > 
> > See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things
> > persistent.
> 
> This particular one can not be made persistent. Writing to this file causes
> kernel action.

D'oh, thanks. Sorry for the confusion.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Michael Kjörling]

On 6 Dec 2023 15:24 +0100, from harald.dun...@aixigo.com (Harald Dunkel):
> I have tried to upgrade to 12.3, but apparently the dependencies
> of the new nvidia-kernel-dkms version cannot be fulfilled.
> firmware-nvidia-gsp (= 525.147.05) is missing. I tried several
> repositories.

Which ones?

That package is in the non-free-firmware component; are you bringing
that in?

https://packages.debian.org/bookworm/firmware-nvidia-gsp

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

Problem between kernel 6.5.0-5 (testing) and Realtek NICs ?

[Erwan David]

After upgrade to 6.5.0-5 (a 6.5.13 kernel in testing), impossible to use 
the laptop when Realtek card present (in dock). it boots, sddm works but 
anything which tries to access networking (even the ip command) is then 
blocked


It could be the same problem as in 
https://discussion.fedoraproject.org/t/kernel-6-5-12-or-later-on-fedora-39-broken-network-on-lenovo-t570/97586/18


I'll try installing the realtek-formware package, but the fedora 
discussion does not give much hope...



--
Erwan David

Upgrade to 12.3 fails due to missing nvidia firmware package

[Harald Dunkel]

Hi folks,

I have tried to upgrade to 12.3, but apparently the dependencies
of the new nvidia-kernel-dkms version cannot be fulfilled.
firmware-nvidia-gsp (= 525.147.05) is missing. I tried several
repositories.

Hopefully I am not too blind to find the bug report (the new
version fixes a CVE, ie details might not have been disclosed),
so I wonder what is the story here?


Regards

Harri

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 06/12/2023 01:42, jeremy ardley wrote:

I have discovered a magic bullet for solving running out of memory

sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Sadly it looks like I'll need to do this daily, simply for using Debian 
Bookworm with a variety of web browsers


Magic does not work. From my point of view, the scope of such command is 
benchmarking of cold start in some applications. It ensures that all 
files are read from disk, not taken from RAM caches.


The command certainly may change numbers presented by free(1) or top(1). 
Actually if it can increase amount of free memory then applications 
should not starve from insufficient RAM. Kernel should drop some caches 
in response to memory allocation request.


Probable negative consequence is that some files will be read again.

You mentioned that you have no swap on this machine (I remember, 
actually swap exists). Does it mean that you followed some guide trying 
to optimize system performance e.g. to minimize SSD wearing?


I suspect that changing some kernel tunables may degrade cache 
performance. I would try to start from clean state. Unfortunately my 
experience with such optimizing is negligible.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 06/12/2023 12:04, to...@tuxteam.de wrote:

On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:


sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Sadly it looks like I'll need to do this daily,


See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things
persistent.


This particular one can not be made persistent. Writing to this file 
causes kernel action.


https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#drop-caches

However I am in doubt if it may be useful for the issue with browsers.

Re: ntpsec as server questions

[Pocket]

On 12/6/23 07:22, Max Nikulin wrote:

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

On 05/12/2023 05:14, Pocket wrote:



For gene

[...]


 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences 
from EST5EDT)? Location-based time zones should be more precise for 
most of users.


I find it reasonable that "dpkg-reconfigure tzdata" forces users to 
set a timezone that should provide more accurate results for them.



I follow POSIX




I have seen America/New_York in a couple of Gene's messages including
https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6f...@shentel.net 

so I assume it is one that he should use. My impression is that 
EST5EDT appeared unintentionally.




I introduced EST5DST to this by simply posted my configuration.



I don't use KDE, I am using LXDE and systems without desktops.

Comment that part out of the shell script.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration? In the Gene's case I mentioned it for 
the case that some piece of software decided to set it, but I have not 
recommended to set it. It is a way to make debugging of a next issue 
harder.




I doesn't hurt anything, What if I install some application that uses it 
and it is not set?



Sorry, I do not have a VM with LXDE to check if TZ is actually set for 
applications. It may depend on display manager configuration and on 
the approach to launch applications: window manager children or 
systemd session.


Anyway I noticed "For gene" and I remember that he uses KDE that has a 
GUI for it. However I am unsure if KDE is installed to this 3d printer 
controller.



Which is why I use it.

/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to 
/usr/share/zoneinfo/EST5EDT


And it is rather confusing since arbitrary abbreviations may be used 
to specify POSIX time zones, e.g. ABC5DEF. From my point of view, it 
is just legacy since the time zone database is available.


It was painful when JavaScript (ECMAScript 5) had fixed DST rules 
based on current regulations. Chrome followed the standard, Firefox 
used accurate history of time transitions. I have not checked POSIX, 
but I see that GNU libc approach is something third in between.


Let's use time zones that allows to get accurate local time.


You use want works for you I will use what works for me.

Anyway I will use the timezone that I wish to use and that is EST5EDT.  
All my systems are set to POSIX standards.


cat /etc/default/locale
LANG=POSIX

how to firefox settings

[fxkl47BF]

on a page in firefox use tools -> page info -> permissions
i notice override keyboard shortcuts is set to allow
where can i change the defaults for this

what is a tasklet

[fxkl47BF]

DI: DI: tasklet schedule cost 12ms.

this interesting  message started showing up in syslog a week or so ago
i've never noticed them before
any ideas whet this is

Re: Recommended simple PDF viewer to replace Evince

[Max Nikulin]

On 06/12/2023 12:14, tomas wrote:

Debian Bullseye here. Xpdf links against libpoppler102, which has
GPLv2 or V3, same as xpdf.


Perhaps fact checking of the following is required. Gnome forked xpdf to 
have a library (poppler) for a PDF viewer (evince). For security reasons 
Debian maintainers are against of slightly different copies of the same 
code. Including xpdf-3, it was painful, but still manageable to adjust 
xpdf code for poppler. Since that time the upstream project released 
xpdf-4. It is packaged for Arch, but it is unlikely that it will appear 
in Debian since the code diverged even more making UI part hardly 
compatible with poppler.

Re: ntpsec as server questions

[Max Nikulin]

On 06/12/2023 00:03, Pocket wrote:

On 12/5/23 11:37, Max Nikulin wrote:

On 05/12/2023 05:14, Pocket wrote:



For gene

[...]


 dpkg-reconfigure tzdata


That does not work. Cannot set EST5EDT.  you have to do that manually.


Do you have reasons to prefer EST5EDT to IANA identifiers like 
America/Detroit, America/New_York, etc. (that have some differences from 
EST5EDT)? Location-based time zones should be more precise for most of 
users.


I find it reasonable that "dpkg-reconfigure tzdata" forces users to set 
a timezone that should provide more accurate results for them.


I have seen America/New_York in a couple of Gene's messages including
https://lists.debian.org/msgid-search/7ba9b8bc-2929-4a3d-8007-a1b5c7f6f...@shentel.net
so I assume it is one that he should use. My impression is that EST5EDT 
appeared unintentionally.



I don't use KDE, I am using LXDE and systems without desktops.

Comment that part out of the shell script.


Do you really need TZ environment variable especially set to the value 
in system-wide configuration? In the Gene's case I mentioned it for the 
case that some piece of software decided to set it, but I have not 
recommended to set it. It is a way to make debugging of a next issue harder.


Sorry, I do not have a VM with LXDE to check if TZ is actually set for 
applications. It may depend on display manager configuration and on the 
approach to launch applications: window manager children or systemd session.


Anyway I noticed "For gene" and I remember that he uses KDE that has a 
GUI for it. However I am unsure if KDE is installed to this 3d printer 
controller.



Which is why I use it.

/usr/share/zoneinfo/posix/EST5EDT is a symlilnk to 
/usr/share/zoneinfo/EST5EDT


And it is rather confusing since arbitrary abbreviations may be used to 
specify POSIX time zones, e.g. ABC5DEF. From my point of view, it is 
just legacy since the time zone database is available.


It was painful when JavaScript (ECMAScript 5) had fixed DST rules based 
on current regulations. Chrome followed the standard, Firefox used 
accurate history of time transitions. I have not checked POSIX, but I 
see that GNU libc approach is something third in between.


Let's use time zones that allows to get accurate local time.

Re: Isolated Web Co Session crash Firefox-ESR

[debian-user]

Karl Vogel  wrote:
> On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote:
> > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> >   
> > > I have discovered a magic bullet for solving running out of memory
> > >   sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > > Sadly it looks like I'll need to do this daily,  
> > 
> > It's the browsers eating your memory. That's what they do.  
> 
>   I've had problems with Firefox eating my swap on both Linux and
> FreeBSD. My fix has been to run the swap2ram script below hourly.

TBF FF has stopped eating memory & swap since it updated to 115.5.0 ESR

Re: Isolated Web Co Session crash Firefox-ESR

[Karl Vogel]

On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote:
> On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> 
> > I have discovered a magic bullet for solving running out of memory
> >   sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > Sadly it looks like I'll need to do this daily,
> 
> It's the browsers eating your memory. That's what they do.

  I've had problems with Firefox eating my swap on both Linux and FreeBSD.
  My fix has been to run the swap2ram script below hourly.

-- 
Karl Vogel  I don't speak for anyone but myself

Constipational carry.
  --NY Post 28 Nov "Suspect found hiding handgun in his rectum" comment #4

# --
#!/bin/ksh
# /dev/null
case "$?" in
0) ;;
*) die "You must be root to $action this." ;;
esac
}

# Make sure we have permission and a safe tempfile.
needroot
systype=$(uname -s | tr A-Z a-z)

tmp=$(mktemp -q "/tmp/$tag.XX")
case "$?" in
0)  test -f "$tmp" || die "$tmp: tempfile not created" ;;
*)  die "$tmp: mktemp failed" ;;
esac

# Real work starts here.  Check for OS-specific instructions.
case "$systype" in
freebsd)
( swapoff -a && swapon -a ) >> $tmp 2>&1
;;

linux)
mem=$(free  | awk '/Mem:/ {print $4}')
swap=$(free | awk '/Swap:/ {print $3}')

if test "$mem" -lt "$swap"; then
logmsg "not enough RAM to recover swap, nothing done"
else
( swapoff -a && swapon -a ) >> $tmp 2>&1
fi
;;
esac

# Cleanup.
test -s "$tmp" && logfile $tmp
rm $tmp
exit 0

Re: Recommended simple PDF viewer to replace Evince

[yxcv]

On Wed, 6 Dec 2023 06:14:00 +0100

  wrote:

On Tue, Dec 05, 2023 at 05:01:37PM -0500, Paul M Foster wrote:

[...]


I've used Xpdf from Arch, and it's an entirely different program. My
understanding was that the Arch version depended on poppler. I can 
only

imagine that the version in Debian is different because there is a
licensing issue with the poppler code. Just a guess.


Debian Bullseye here. Xpdf links against libpoppler102, which has
GPLv2 or V3, same as xpdf.

Cheers


Echt simpel die bei Raspian. Und winzig.- Und sogar bunt!