FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
net/remotebox   | 2.7 | 3.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!

Adding functionality to a port

[Rob LA LAU]

Hello list,

I'm wondering what the rules/guidelines are for adding functionality to 
a port, that is not in the upstream package. I can't find anything about 
this in the porters' documentation.


Background:
I'm not a porter myself (planning to be one, but that's irrelevant for 
my current question).
I ran into a buggy `periodic' script. And when looking for the port 
maintainer to report the bug, I found that this script is not part of 
the upstream package, but was added to the port by the port maintainer.
So I'm wondering now whether I should report the bug in the `periodic' 
script, or ask the maintainer to remove the script from the port (and 
maybe submit it as a separate port).


And in more general it would be interesting to know when changes made to 
a port are considered too drastic, and when port maintainers should be 
asked to join the upstream development team instead of (or in addition 
to) maintaining the port.


Thanks for any and all replies.

Cheers,
  Rob

--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Kurt Jaeger]

Hello,

> I'm wondering what the rules/guidelines are for adding functionality to a
> port, that is not in the upstream package. I can't find anything about
> this in the porters' documentation.
> 
> Background:
> I'm not a porter myself (planning to be one, but that's irrelevant for my
> current question).
> I ran into a buggy `periodic' script. And when looking for the port
> maintainer to report the bug, I found that this script is not part of the
> upstream package, but was added to the port by the port maintainer.
> So I'm wondering now whether I should report the bug in the `periodic'
> script, or ask the maintainer to remove the script from the port (and
> maybe submit it as a separate port).

Please submit a problem report via bugs.freebsd.org for the
port in question. If you provide a patch for the periodic script
upstream, that would probably be fine as well, if they accept it.

The maintainer can decide what should happen to the buggy script...

> And in more general it would be interesting to know when changes made to
> a port are considered too drastic, and when port maintainers should be
> asked to join the upstream development team instead of (or in addition
> to) maintaining the port.

You can ask the maintainer if he wants to join upstream, but
if there's no interest, there's no need to pressure one into upstream 8-)

-- 
p...@opsec.eu+49 171 3101372Now what ?

Re: Adding functionality to a port

[Ronald Klop via freebsd-ports]

On Sun, 14 Nov 2021 16:26:23 +0100, Rob LA LAU  wrote:


Hello list,

I'm wondering what the rules/guidelines are for adding functionality to  
a port, that is not in the upstream package. I can't find anything about  
this in the porters' documentation.


Background:
I'm not a porter myself (planning to be one, but that's irrelevant for  
my current question).
I ran into a buggy `periodic' script. And when looking for the port  
maintainer to report the bug, I found that this script is not part of  
the upstream package, but was added to the port by the port maintainer.
So I'm wondering now whether I should report the bug in the `periodic'  
script, or ask the maintainer to remove the script from the port (and  
maybe submit it as a separate port).


And in more general it would be interesting to know when changes made to  
a port are considered too drastic, and when port maintainers should be  
asked to join the upstream development team instead of (or in addition  
to) maintaining the port.


Thanks for any and all replies.

Cheers,
   Rob



You can file a bug report on https://bugs.freebsd.org/ . If you use a  
summary like 'www/firefox: Unable to use microphone with ALSA backend' it  
is automatically assigned to the maintainer of the port. So 'portname>: short description of bug'. You can also upload a patch if you  
have it.


If a bug report is not possible you can also just mail the maintainer and  
see what the reaction is.


Regards,
Ronald.

Re: Adding functionality to a port

[Rob LA LAU]

Hi Kurt,

On 14/11/2021 16:34, Kurt Jaeger wrote:

You can ask the maintainer if he wants to join upstream, but
if there's no interest, there's no need to pressure one into upstream 8-)


Don't worry: I don't want to pressure anyone into doing anything. :)

But I would like to know how much functionality a port maintainer can 
add to a package before it is considered too much.
At some point the port will no longer represent the upstream package, 
and I'd really like to know where this limit is.


Rob

--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> On 14/11/2021 16:34, Kurt Jaeger wrote:
> > You can ask the maintainer if he wants to join upstream, but
> > if there's no interest, there's no need to pressure one into upstream 8-)
> 
> Don't worry: I don't want to pressure anyone into doing anything. :)
> 
> But I would like to know how much functionality a port maintainer can add
> to a package before it is considered too much.

There's no rule that limits it.

Upstream can also hunt for functional changes 8-) and integrate
them 8-)

> At some point the port will no longer represent the upstream package, and
> I'd really like to know where this limit is.

There are two aspects:

- If the changes are useful, upstream can integrate them...
- If the changes collide with upstream ideas, who's to judge,
  as long as no license issues are created ?

Maybe it makes it easier to understand if you tell us the port
in question ?

-- 
p...@freebsd.org +49 171 3101372  Now what ?

Re: Adding functionality to a port

[Rob LA LAU]

Thanks Ronald. But I'm not asking how or where to report bugs.

Allow me to rephrase my question.

If and when I am a FreeBSD port maintainer, can I just add any scripts 
or other files to the port I maintain if I think they may be practical, 
even if those files are not part of the upstream project?


Thanks,
  Rob


On 14/11/2021 16:40, Ronald Klop via freebsd-ports wrote:

On Sun, 14 Nov 2021 16:26:23 +0100, Rob LA LAU  wrote:


Hello list,

I'm wondering what the rules/guidelines are for adding functionality 
to a port, that is not in the upstream package. I can't find anything 
about this in the porters' documentation.


Background:
I'm not a porter myself (planning to be one, but that's irrelevant for 
my current question).
I ran into a buggy `periodic' script. And when looking for the port 
maintainer to report the bug, I found that this script is not part of 
the upstream package, but was added to the port by the port maintainer.
So I'm wondering now whether I should report the bug in the `periodic' 
script, or ask the maintainer to remove the script from the port (and 
maybe submit it as a separate port).


And in more general it would be interesting to know when changes made 
to a port are considered too drastic, and when port maintainers should 
be asked to join the upstream development team instead of (or in 
addition to) maintaining the port.


Thanks for any and all replies.

Cheers,
   Rob



You can file a bug report on https://bugs.freebsd.org/ . If you use a 
summary like 'www/firefox: Unable to use microphone with ALSA backend' 
it is automatically assigned to the maintainer of the port. So 'portname>: short description of bug'. You can also upload a patch if you 
have it.


If a bug report is not possible you can also just mail the maintainer 
and see what the reaction is.


Regards,
Ronald.



--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Rob LA LAU]

Hi,

On 14/11/2021 16:54, Kurt Jaeger wrote:

Maybe it makes it easier to understand if you tell us the port
in question ?


It won't actually, because I don't want to focus on this 1 buggy script 
I found.


My question is not about a single bug in a single script. It's about 
FreeBSD policy, trust, security and reliability.


As a port maintainer, can I just modify the functionality of the ports I 
maintain without any limits?


And as a software developer, can I be sure that the package that is 
installed on FreeBSD systems, and that carries my name and URL, is 
actually still the package that I developed, with the functionality I 
intended?


And as a sysadmin or user, can I be sure that the port I installed 
actually does what is advertised on the upstream website?


I honestly think that these are very important questions...
The internet is no longer this friendly place it was 30 years ago. 
People with malicious intent have infiltrated software repositories 
before, and they will keep doing so.


Rob

--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> As a port maintainer, can I just modify the functionality of the ports I
> maintain without any limits?

Like modifiying a port that does xyz to actually do the reverse ?

No, that would be crazy. Upstream and port users would probably
freak out, and rightly so.

> And as a software developer, can I be sure that the package that is
> installed on FreeBSD systems, and that carries my name and URL, is
> actually still the package that I developed, with the functionality I
> intended?

Non-trivial problem. Read the famous paper on trusting trust:

https://dl.acm.org/doi/10.1145/358198.358210

> And as a sysadmin or user, can I be sure that the port I installed
> actually does what is advertised on the upstream website?

See above.

> I honestly think that these are very important questions...

Yes, but those are unsolvable problems in the framework of a policy.

Don't do crazy things is a generic given in most societies I know of 8-)

> The internet is no longer this friendly place it was 30 years ago. People
> with malicious intent have infiltrated software repositories before, and
> they will keep doing so.

Yes, sure. So that's why there are reviews etc. And still, bad things
happen, and we find out and clean up afterwards.

-- 
p...@freebsd.org +49 171 3101372  Now what ?

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> It is also not correct to "commandeer" a port to force users on design
> choices in conflict with the upstream project.

Is there a section in the ports maintainers guide or somewhere
else that mandates this ?

-- 
p...@freebsd.org +49 171 3101372  Now what ?

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> > > It is also not correct to "commandeer" a port to force users on design
> > > choices in conflict with the upstream project.

> > Is there a section in the ports maintainers guide or somewhere
> > else that mandates this ?

> Sorry, my fault I did not make me clear maybe, this is all my own opinion.
> So is what follows.
> 
> Anyway I don't see it as a good beahviour to take a port of some upstream
> software and move it in a contrasting direction than the upstream.

I agree. The problem is that this is very difficult to codify
into some policy.

[...]
> The name "ports" implies it is not the place for original development. I
> also agree we often have a disconnection on how things are named and what
> they actually are or behave, so I would not have any strong reply if you
> were to state the the name cannot be held as a reason for policy.

So some sort of rule might be: If the functionality varies from
the upstream-project in a major way, please use a derived or different
name for the port.

-- 
p...@freebsd.org +49 171 3101372  Now what ?

Re: Adding functionality to a port

[Guido Falsi]

NOTE replying with my FreeBSD.org address to make the reply reach the 
mailing list, sorry my previous messages on this thread bounced.


On 14/11/21 19:37, Kurt Jaeger wrote:

Hi!


It is also not correct to "commandeer" a port to force users on design
choices in conflict with the upstream project.



Is there a section in the ports maintainers guide or somewhere
else that mandates this ?



Sorry, my fault I did not make me clear maybe, this is all my own opinion.
So is what follows.

Anyway I don't see it as a good beahviour to take a port of some upstream
software and move it in a contrasting direction than the upstream.


I agree. The problem is that this is very difficult to codify
into some policy.


Very difficult, and I'd really would like to avoid to make the FreeBSD 
project documents some kind of legal codex.




[...]

The name "ports" implies it is not the place for original development. I
also agree we often have a disconnection on how things are named and what
they actually are or behave, so I would not have any strong reply if you
were to state the the name cannot be held as a reason for policy.


So some sort of rule might be: If the functionality varies from
the upstream-project in a major way, please use a derived or different
name for the port.



As I stated in another (provate message) I just realized that this is at 
least partly covered by "POLA". IN fact I would very astonished if some 
port (say firefox for example) started behaving very differently than it 
does on other OSes for no good technical reason.


OTOH a valid technical reason could be dropping some functionality 
depending on some API not available on FreeBSD, just to make an example 
from the top of my head.


--
Guido Falsi 

Re: Adding functionality to a port

[Rob LA LAU]

Hi again,

On 14/11/2021 19:37, Kurt Jaeger wrote:

I agree. The problem is that this is very difficult to codify
into some policy.


I've done some digging. And actually, Fedora only needs a few words:

"All patches should have an upstream bug link or comment" [1]

This assures that packages stay close to their upstream projects.

Another rule could be

"Patches should only be applied to make the software run as intended by 
its developer. All additional functionality should be integrated 
upstream first or, if that's not possible or desirable, should be 
developed as a separate project which can then be ported alongside the 
first port."


Having rules for these situations means that tools can be created to 
verify and enforce those rules.


Not having these rules is an invitation to people with malicious intent 
to integrate backdoors, keyloggers, and what not into the ports. IMHO.


Rob

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_all_patches_should_have_an_upstream_bug_link_or_comment




--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Rob LA LAU]

And hi again,

On 14/11/2021 19:42, Guido Falsi wrote:
> IN fact I would very astonished if some port (say firefox for 
example) started behaving very differently than it does on other OSes 
for no good technical reason.


True.
But what if we're not talking about 'behaving very differently'. How 
about we patch a browser to send the user's passwords to a server we 
own, while - apart from that - the browser continues to work as expected?


> OTOH a valid technical reason could be dropping some functionality 
depending on some API not available on FreeBSD, just to make an example 
from the top of my head.


Dropping something because it is impossible to implement is different. 
Sometimes you don't have a choice.


My initial question was about a script that was added by the port 
maintainer, which is not quite the same. Patching software to log 
keystrokes, or to open a backdoor is also different.


Clearly you can't solve all these problems by creating some guidelines 
and rules. But I don't think that a serious software project can 
continue without rules. Just like we need passwords and keys.


And preferably those rules would be very clear and simple, so that the 
compliance can be verified (largely) in an automated fashion.


Rob


--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> On 14/11/2021 19:37, Kurt Jaeger wrote:
> > I agree. The problem is that this is very difficult to codify
> > into some policy.
> 
> I've done some digging. And actually, Fedora only needs a few words:
> 
> "All patches should have an upstream bug link or comment" [1]
> 
> This assures that packages stay close to their upstream projects.

As FreeBSD's not Linux, we often have the problem that
bugs reported upstream are not accepted, discarded or ignored 8-}

But in general, this sounds like a useful rule, if we do not
enforce it too rigidly.

> Another rule could be
> 
> "Patches should only be applied to make the software run as intended by
> its developer. All additional functionality should be integrated upstream
> first or, if that's not possible or desirable, should be developed as a
> separate project which can then be ported alongside the first port."

This would lead to a lot of additional ports, because of above...

> Not having these rules is an invitation to people with malicious intent
> to integrate backdoors, keyloggers, and what not into the ports. IMHO.

In general, patches and modifications are not submitted/committed
with malicious intent. And, as far as I understand, open source project
do not write rules to protect against the worst possible
case/attacker, because that might slow other contributors.

The workflow should include checks to protect. If checks against
worst-cases can be automated, wonderful. But should the
rules really assume the worst from its contributors ?

-- 
p...@opsec.eu+49 171 3101372Now what ?

Re: Adding functionality to a port

[Guido Falsi]

On 14/11/21 20:32, Rob LA LAU wrote:

And hi again,

On 14/11/2021 19:42, Guido Falsi wrote:
 > IN fact I would very astonished if some port (say firefox for 
example) started behaving very differently than it does on other OSes 
for no good technical reason.


True.
But what if we're not talking about 'behaving very differently'. How 
about we patch a browser to send the user's passwords to a server we 
own, while - apart from that - the browser continues to work as expected?




I'd argue that adding such a behaviour is a significant change in behaviour.

Apart from that such a change would be criminal in most jurisdictions 
too. And I'd add that the juridical system would simply persecute 
whoever owns the server the information is being sent too.


My opinion about allowed changes is also guided by avoiding this kind of 
risks.


 > OTOH a valid technical reason could be dropping some functionality 
depending on some API not available on FreeBSD, just to make an example 
from the top of my head. >
Dropping something because it is impossible to implement is different. 
Sometimes you don't have a choice.


Exactly, so an acceptable change.

My initial question was about a script that was added by the port 
maintainer, which is not quite the same. Patching software to log 
keystrokes, or to open a backdoor is also different.


I did not reply directly to your original question because I don't have 
a final solution.


You talk about "adding a periodic script". That is not even a real 
modification to the upstream software IMHO. Just adding some glue code 
for FreeBSD. If the script does what it advertises, and has no malicious 
intent I see nothing wrong with it. If it is broken fixing it is the 
logical thing to do.


Again, this is my personal opinion though.

Clearly you can't solve all these problems by creating some guidelines 
and rules. But I don't think that a serious software project can 
continue without rules. Just like we need passwords and keys.


And preferably those rules would be very clear and simple, so that the 
compliance can be verified (largely) in an automated fashion.
Being a son of two lawyers, and having a lot of friends who are lawyers, 
and also clients who are law firms, my informed (by having had a lot of 
arguments with all these people about this very subject) opinion is that 
there is no such thing in the world as a "clear and simple" set of rules.


I think I could simplify this in an aphorism like this:

About rules and laws: Simple, clear and useful, you can't have all 
three, pick two.


--
Guido Falsi 

Re: Adding functionality to a port

[Rob LA LAU]

Hi,


"Patches should only be applied to make the software run as intended by
its developer. All additional functionality should be integrated upstream
first or, if that's not possible or desirable, should be developed as a
separate project which can then be ported alongside the first port."


This would lead to a lot of additional ports, because of above...


But since those additional ports would also be closer to their upstream, 
each individual port would need less patches and be easier to maintain. 
So even if the ports tree would be larger, it would also be cleaner.



In general, patches and modifications are not submitted/committed
with malicious intent.


I'm sure that that is true, But nevertheless, several colleagues have 
had their repositories compromised, so if this hasn't happened to 
FreeBSD yet, and FreeBSD doesn't have any measures put in place, it is 
probably just a matter of time. [1][2][3][4][...]



The workflow should include checks to protect. If checks against
worst-cases can be automated, wonderful. But should the
rules really assume the worst from its contributors ?


No, it should assume the best. And be prepared for the worst.

Why should you only marry with a prenup? Because it's not in the way if 
things go well, and it's good to have organized everything beforehand if 
things do not go well.


If the porters really care for FreeBSD, they will understand and agree 
that it must be protected against people who care a bit less.
If their ego cannot take some simple rules that will undoubtedly reduce 
the risk of the ports tree getting compromised, then maybe they don't 
care as much for FreeBSD as they say. IMHO, of course.


Rob


[1] https://www.securityweek.com/arch-linux-aur-repository-compromised
[2] 
https://www.securityweek.com/hackers-plant-malicious-code-gentoo-linux-github-page
[3] 
https://blog.gridinsoft.com/more-than-700-malicious-libraries-detected-in-rubygems-repository/
[4] 
https://www.bleepingcomputer.com/news/security/malicious-pypi-packages-hijack-dev-devices-to-mine-cryptocurrency/


--

 https://www.librobert.net/
 https://www.ohreally.nl/category/nerd-stuff/

Re: Adding functionality to a port

[George Mitchell]

On 11/14/21 13:42, Guido Falsi wrote:

[...]
As I stated in another (provate message) I just realized that this is at 
least partly covered by "POLA". [...]


Perhaps I'm naïve, but to me the Principle of Least Amazement really
does completely cover the issues being raised here.  Is it necessary
to complicate the situation any more than that?  -- George

Re: Adding functionality to a port

[Miroslav Lachman]

On 14/11/2021 16:56, Rob LA LAU wrote:

Thanks Ronald. But I'm not asking how or where to report bugs.

Allow me to rephrase my question.

If and when I am a FreeBSD port maintainer, can I just add any scripts 
or other files to the port I maintain if I think they may be practical, 
even if those files are not part of the upstream project?


If you want simple answer, then YES.
Almost all SW in ports are developed without FreeBSD in mind and does 
not contain FreeBSD compatible rc script to start the service so the 
maintainer needs to write some. And periodic scripts are again very 
FreeBSD specific, not included in the upstream. Both (rc and periodic) 
scripts are in maintainer's hands.

Some ports without these additional scripts will be almost useless.
But if you are asking if maintainer can add any malicious code then the 
answer is NO and port committers are doing their best to not commit it.


Miroslav Lachman

Re: Adding functionality to a port

[Dave Horsfall]

On Sun, 14 Nov 2021, George Mitchell wrote:

Perhaps I'm naïve, but to me the Principle of Least Amazement really 
does completely cover the issues being raised here.  Is it necessary to 
complicate the situation any more than that?  -- George


First time I've heard POLA called that; I knew it as "... astonishment" 
some decades ago (by Dr. John Lions; for all I know he could've coined 
it).


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

-- Dave

Re: Adding functionality to a port

[George Mitchell]

On 11/14/21 16:50, Dave Horsfall wrote:

[...]
First time I've heard POLA called that; I knew it as "... astonishment" 
some decades ago (by Dr. John Lions; for all I know he could've coined it).

[...]

So I'm a decrepit old codger and my memory is going ...  -- George

automake config failure for autoconf test failure (poudriere based build activity)

[Mark Millard via freebsd-ports]

poudriere output:

[00:24:23] [09] [00:01:20] Saved devel/automake | automake-1.16.4 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/13_0R-CA72-default/default/automake-1.16.4.tbz
[00:24:23] [09] [00:01:20] Finished devel/automake | automake-1.16.4: Failed: 
configure
. . .

logs/errors/automake-1.16.4.log :

. . .
checking whether autoconf is installed... yes
checking whether autoconf works... no
configure: error: The installed version of autoconf does not work.
Please check config.log for error messages before this one.
===>  Script "configure" failed unexpectedly.
Please report the problem to t...@freebsd.org [maintainer] and attach the
"/wrkdirs/usr/ports/devel/automake/work/automake-1.16.4/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/automake
=>> Cleaning up wrkdir
===>  Cleaning for automake-1.16.4
build of devel/automake | automake-1.16.4 ended at Sun Nov 14 17:01:21 PST 2021
build time: 00:01:09
!!! build failure encountered !!!


work/automake-1.16.4/config.log :

. . .
configure:3650: checking whether autoconf is installed
configure:3656: autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
configure:3659: $? = 0
configure:3667: result: yes
configure:3674: checking whether autoconf works
configure:3684: cd conftest && autoconf -o /dev/null conftest.ac
gm4:/usr/local/share/autoconf-2.69/autoconf/autoconf.m4f:1: expecting character 
`V' in frozen file
autom4te-2.69: /usr/local/bin/gm4 failed with exit status: 1
configure:3687: $? = 1
configure:3696: result: no
configure:3700: error: The installed version of autoconf does not work.
Please check config.log for error messages before this one.
. . .


For reference:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 
main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1400042 1400042

# cd /usr/ports/
# ~/fbsd-based-on-what-commit.sh 
branch: main
merge-base: 057c0c3c0645c0b237bb2a96dda440e0426ca983
merge-base: CommitDate: 2021-11-14 23:41:22 +
057c0c3c0645 (HEAD -> main, freebsd/main, freebsd/HEAD) [NEW] 
security/snowflake-tor: Pluggable Transport using WebRTC inspired by Flashproxy
n566061 (--first-parent --count for merge-base)


Note(s):

My amd64 FreeBSD context using the same sources (by content) did not
have this problem.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)