Re: Adding functionality to a port

[Rob LA LAU]

Hi,

On 15/11/2021 10:21, Guido Falsi wrote:

You look too worried by the "functionality added" part.


Yes, I am worried. Of course I am.
When I first asked my question the day before yesterday, the first 
responses were in the line of "port maintainers can do whatever they 
want", accompanied by emoticons with sunglasses.
So that kind of makes me wonder how seriously FreeBSD takes itself, as 
an OS.


I understand very well that a startup script or similar stuff can be 
added without any problem.
But what worries me, is that apparently there are no limits or rules 
whatsoever. Even OpenBSD, if you want to keep it close to home, dictates 
that all patches, work-arounds and dependencies must be documented, and 
that all changes must be sent upstream to try and have them included in 
the original work. [1] (And when I say 'Even OpenBSD' I don't mean to 
say that OpenBSD is any less than FreeBSD, but just that it could be 
considered a small player, compared to FreeBSD or most other OSes.)


I run real servers, so as a sysadmin I want to be able to rely on the 
fact that the software I install does exactly what is advertised in the 
upstream documentation, no more and no less.
And that's not just from a point of view of security for just me. I run 
2 Tor relays, so it's potentially the security of many more people 
(where 'security' could mean a way bigger risk than just losing some files).
And yes, I am sure that Tor runs as advertised, because I verified that 
(as far as I could). But what if the port maintainer of some obscure 
library, that is installed through some bizarre chain of dependencies, 
managed to sneak in a backdoor that gives them root access to my server? 
Then the security of my Tor installation is no longer relevant, because 
an attacker can just gain root and compromise that installation.


And please don't tell me that that would be illegal, because the amount 
of attempts I receive on my servers every day tells me that not 
everybody is as law abiding as you apparently are.


Apart from that, triggered by this email conversation, I studied some 
open source licenses in the past days. And apart from the BSD licenses, 
MIT license and Mozilla Public License, most open source licenses 
require modifications to at least be well documented (GPLv2, article 
2.a; GPLv3, article 5.a; Apache License, article 4.2; LGPLv2, article 
2.b; CDDL-1.0, article 3.3). Which means that even the added startup 
scripts should carry a notice saying something like "This file is not 
part of the original distribution, but was added for FreeBSD -  
".
So if you want to talk about legal stuff: current practice may violate 
some licenses.


I really understand that not everything can be cast in stone. And I 
understand that there must be some freedom for port maintainers. And I 
don't want to be a Karen about it either. I am even rather pro-anarchy. 
But not on the servers that keep my data and that of others secure. I'm 
just looking for some guarantees for me and my users. I understand that 
100% guarantee is hard, if not impossible, but I would like it to be a 
bit more than "You just shouldn't do bad things.".


But I understand that I'm alone in this: only 3 or 4 people have 
responded, and they all seemed to be very much against any rules for 
port maintainers. So I won't insist any more.


Best,
  Rob


[1] https://www.openbsd.org/faq/ports/guide.html

--

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

Re: Adding functionality to a port

[Guido Falsi]

On 16/11/21 11:34, Rob LA LAU wrote:

Hi,

On 15/11/2021 10:21, Guido Falsi wrote:

You look too worried by the "functionality added" part.


Yes, I am worried. Of course I am.


Now I feel compelled to reply to all this rant of yours because you are 
replying to me, but I really have little more to say about this.


While the first reply you got was on the line of "anything goes" I 
argued there are some rules, and explained that it's difficult to create 
better rules. That they can be counter productive. The argument about 
requiring upstream patches has its problems, but I will not delve into it.


Please note that if a maintainer diverges significantly from upstream, 
committers will intervene, if committers diverge significantly, they 
will be addressed and the issue discussed. things like this have 
happened in the past. I personally have refused patches diverging from 
upstream in the past.


The FreeBSD ports collection is a volunteer effort at porting software, 
we do try to make it behave like upstream, but I don't think there is 
any way to warrant that. everything is open and there for you to review. 
there is no hidden patching.


Nothing forces you to use packages or ports. You can compile upstream 
software yourself. You can't expect many warranties from free work of 
others.


Our rules are available for all to see in the porter's handbook and the 
committer's handbook.


I am unable to invent better rules about this than what we already have 
and are doing. If you think you can write them and propose them. 
Expecting us to create a set of rules for your real servers with real 
data and do that for free is not very reasonable.


I think this thread has exhausted its usefulness.

NOTE I'm writing this from my @FreeBSD.org address so it does not bounce 
from the mailing list, but this is all my personal opinion.


--
Guido Falsi 

Re: Adding functionality to a port

[Kurt Jaeger]

Hi!

> On 15/11/2021 10:21, Guido Falsi wrote:
> > You look too worried by the "functionality added" part.
> 
> Yes, I am worried. Of course I am.
> When I first asked my question the day before yesterday, the first
> responses were in the line of "port maintainers can do whatever they
> want", accompanied by emoticons with sunglasses.

At least I did not understand your question as a topic on security,
but rather on: What are the rules for a port...

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

Re: Adding functionality to a port

[Guido Falsi]

On 16/11/21 11:56, Kurt Jaeger wrote:

Hi!


On 15/11/2021 10:21, Guido Falsi wrote:

You look too worried by the "functionality added" part.


Yes, I am worried. Of course I am.
When I first asked my question the day before yesterday, the first
responses were in the line of "port maintainers can do whatever they
want", accompanied by emoticons with sunglasses.


At least I did not understand your question as a topic on security,
but rather on: What are the rules for a port...



Security is important, but if security is at stake we need more detailed 
info, we need "actionable" information.


As I said startup and periodic scripts are and should be installed 
disabled, if he found a port/package installing a startup 
script/periodic script auto enabling itself, he should report that and 
it should be fixed.


If there is a broken script it should be fixed.

If there is some malicious script that should not happen, committers 
should and do review submissions to avoid such things. Mistakes can 
happen, please report and make it noticed and it will be discussed/fixed.


If there is some more obscure patch to some source code causing 
significant behaviour changes in some package, please report it, as 
usual make you noticed and it will be at least discussed, if it has 
security implications I'm sure also acted upon effectively. If no 
security implication is involved there is also less urgency.


If we're talking security there is no grey area, the concept is clearly 
defined and things will be acted upon, there is no need for new rules or 
philosophy.


--
Guido Falsi 

Re: Adding functionality to a port

[Gregory Byshenk]

On Tue, Nov 16, 2021 at 11:34:45AM +0100, Rob LA LAU wrote:
 
> Yes, I am worried. Of course I am.
> When I first asked my question the day before yesterday, the first 
> responses were in the line of "port maintainers can do whatever they 
> want", accompanied by emoticons with sunglasses.
> So that kind of makes me wonder how seriously FreeBSD takes itself, as 
> an OS.

I am just a user, but my understanding is that FreeBSD developers
take the OS very seriously, but do not take themselves too seriously.


> And yes, I am sure that Tor runs as advertised, because I verified that 
> (as far as I could). But what if the port maintainer of some obscure 
> library, that is installed through some bizarre chain of dependencies, 
> managed to sneak in a backdoor that gives them root access to my server? 
> Then the security of my Tor installation is no longer relevant, because 
> an attacker can just gain root and compromise that installation.

The question you need to answer is "what RULE would prevent this
from happening?" My proposed answer is "none can". The only thing
that can prevent malicious code injection is actual review of the
code, to ensure that it does what it says on the label. This is
(as I understand it) part of the job of reviewers and committers.

 
> I really understand that not everything can be cast in stone. And I 
> understand that there must be some freedom for port maintainers. And I 
> don't want to be a Karen about it either. I am even rather pro-anarchy. 
> But not on the servers that keep my data and that of others secure. I'm 
> just looking for some guarantees for me and my users. I understand that 
> 100% guarantee is hard, if not impossible, but I would like it to be a 
> bit more than "You just shouldn't do bad things.".

There are no guarantees in this world, especially when it comes to
sofware. You may have noticed that even commrecial software usually
includes explicit rejection of any 'guarantee'. More importantly, no 
"rule" can provide such a thing.

 
> But I understand that I'm alone in this: only 3 or 4 people have 
> responded, and they all seemed to be very much against any rules for 
> port maintainers. So I won't insist any more.

I think the majority of developers and users feel that the porting
guidelines are reasonable as they currently exist, when combined
with the judgment of commiters and portmgr. Trying to make things
more explicit just makes the process more complicated, and - as I
note above - doesn't actually solve any problem.

-- 
gregory byshenk  -  free...@byshenk.net  -  Leiden, NL

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

[Tijl Coosemans]

On Sun, 14 Nov 2021 17:57:23 -0800 Mark Millard 
wrote:
> 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.

That's a strange error.  Maybe try to rebuild m4 and autoconf packages.
On the FreeBSD package build cluster it builds fine.  Here's the log
from today:
http://ampere2.nyi.freebsd.org/data/main-arm64-default/latest-per-pkg/automake-1.16.4.log

Re: Adding functionality to a port

[Jose Quinteiro]

On 11/16/21 2:34 AM, Rob LA LAU wrote:
> ...Even OpenBSD, if you want to keep it close to home, dictates
> that all patches, work-arounds and dependencies must be documented, and
> that all changes must be sent upstream to try and have them included in
> the original work...

Openbsd packages come with the following caveat:

"The ports collection does not go through the same thorough security
audit that is performed on the OpenBSD base system. Although we strive
to keep the quality of the packages high, we just do not have enough
resources to ensure the same level of robustness and security."

https://www.openbsd.org/faq/faq15.html


Thanks,
Jose

Re: Adding functionality to a port

[Rob LA LAU]

On 16/11/2021 17:59, Jose Quinteiro wrote:

Openbsd packages come with the following caveat:

> [...]

Every operating system comes with this caveat; OpenBSD just says it out 
loud. No BSD, nor any Linux distro, has the resources to go through the 
source code of all ported software, to make sure it has no holes. This 
responsibility is left with the developers of the software in question. 
Which is one of the reasons why porters should make as little 
modifications as possible, and document the modifications they do make: 
so that it is clear where the developers' responsibilities end and the 
porters' responsibilities begin (and vice versa).


Rob

--

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

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

[Mark Millard via freebsd-ports]

On 2021-Nov-16, at 08:42, Tijl Coosemans  wrote:

> On Sun, 14 Nov 2021 17:57:23 -0800 Mark Millard 
> wrote:
>> 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.
> 
> That's a strange error.  Maybe try to rebuild m4 and autoconf packages.
> On the FreeBSD package build cluster it builds fine.  Here's the log
> from today:
> http://ampere2.nyi.freebsd.org/data/main-arm64-default/latest-per-pkg/automake-1.16.4.log

On the FreebSD vintage involved, I seem to be getting fairly
rare file corruptions during port builds in my aarch64 context.
No retry of building a port that contained the corrupted file
has produced a corruption in these cases. autoconf turned out
to not be the only example: there were two others. (I've did
multiple bulk -a runs back in October (for otehr reqsons)
without evidence of corruptions. But bulk -a is not something
I'd normally do and I did not keep the results. In this context
between 400 and 500 port were built in each of 3 poudriere
jails. 2 known corruptions in one jail's build, 1 in another,
and one with no known corruptions.)

So I got past the autoconf/automake problem but I've no clue
how to set up a reproducible context for isolating what leads
to having a corruption.

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

Re: Adding functionality to a port

[Dave Horsfall]

On Tue, 16 Nov 2021, Gregory Byshenk wrote:

I am just a user, but my understanding is that FreeBSD developers take 
the OS very seriously, but do not take themselves too seriously.


Best comment I've seen in this increasingly-sillier thread.

-- Dave

Re: Regarding port(s) you maintain in FreeBSD ports collection

[Daniel Engberg]

On 2021-11-16 07:14, Mikhail T. wrote:


On 13.11.21 15:51, Daniel Engberg wrote:


I agree that old doesn't necessarily mean it's useless


Noted!


however we do need to prune the ports from time to time


Why? Why do we need to "prune the ports from time to time"? I'm aware 
of one principle, under which a port can be deleted: the port remains 
broken for "too long". And even that principle is a little vague -- 
because "too long" is undetermined.


Not even having security problems is automatic grounds for removal -- 
or www/chromium would've been gone long ago :-) VuXML can (should!) 
flag the security flaw(s), but whether or not to use the port should be 
up to the user.


a lot of these eats resources simply because they're not maintained in 
our tree, upstream
Are you saying, resources are "eaten" because a port is not maintained 
upstream?! The worst resource-hogs currently are the LLVM, Rust (which, 
bizarrely, continues to build its own LLVM!), and webkits. All are 
actively maintained...


and/or arguably may be seen as bad practice (depending on port) and so 
on.
I haven't seen any argument suggesting a "bad practice"... What are you 
referring to?


Generally speaking it's also next to impossible to evaluate every 
single port for runtime testing and improve the situation doesn't 
improve when where are no "active" users.
This is difficult to parse, but you seem to mean, the ports you 
nominated for removal have no active ("active"?) users... How do you 
know this?


I fully understand that this may not be in agreement with everyone and 
we're open for discussion but simply hoarding ports / having a 
"software museum" has been deemed to be not the way to go in agreement 
with portmgr. It's a balancing act and I did look at other repos to 
get a better grasp of ports I'm not all that familiar with.


Here you're implying authority of a portmgr -- are you a member? 
(Apologies for my being behind the staff appointments.) Yet, even 
portmgr should not be removing ports based on such vague arguments, 
whatever they "deem to be not". That body maintains the ports framework 
-- for them to declare certain ports less equal than others is an 
overreach... Though their Charter [1] grants them fairly wide 
authority, their stated goal is "to ensure that the FreeBSD Ports 
Developer community provides a ports collection that is functional, 
stable, up-to-date and full-featured". Removing ports -- other than for 
failing to build -- does not serve any of the enumerated objectives. 
Indeed, such removals violate the "full featured" part!


Frankly, I don't see anything wrong with a "software museum" -- 
anything, which a human being has once ported to FreeBSD, should remain 
ported (unless it breaks irreparably). Newer versions may, of course, 
push out the older ones, but that's about it...


My reasoning regarding beecrypt was also based upon the fact that it's 
no longer a port of many repos
Why is this relevant? Is FreeBSD being driven -- governed! -- by other 
"repos" (whatever that term means)? Is games/bsdgames found in any of 
those?


There are no users except btcheck (optional and not enabled by 
default) in tree


I can't help, but notice your shifting of the goal posts here. After 
conceding, that "old does not mean useless", you changed the argument 
for removal of beecrypt from "it is old" to "it is not used by other 
ports". And this new one is not a valid argument either...


There are no users of www/firefox in tree. Why is this relevant? It is 
a library -- for all you know, there may be multiple users with their 
own projects, that uses that library, why remove it, if it is not 
broken?


Must a port providing a software library be used by other ports? I'm 
unaware of any rule mandating this, are you? If you're not, why did you 
bring this up?


Regarding www/websh its status is not going to change in agreement 
with portmgr,


Here you're once again channeling portmgr. "Its status is not going to 
change," -- this is a tone of ruler condescending to speak to a 
subject... Are you alluding to some unpublished policy of portmgr? 
Because nothing of the kind is listed among the published ones:



https://www.freebsd.org/portmgr/policies/



it's obsolete and marked as dead upstream.
First of all, once again, I don't consider "obsolete" and "dead 
upstream" to be sufficient reasons for removal of a port. But even if 
they were, this does not apply to websh.
The "obsolete" part is simply not true -- websh is just as good as it 
was, when the last release was made. Tcl-8.6 remains the last release 
of the interpreter, and the port builds against the latest Apache. It 
also works (nicely) -- I use it on my own server.


I intend to add patches to ensure, the port builds with Tcl-8.7 as 
well. Maybe, this will make me the new "upstream" -- I hope, you don't 
mind...



If you still want to keep obsolete software available as packages


In my opinion, people using packages should be using RP

Bringing back lang/python27 with few modules?

[Maxim Sobolev]

Hi,

I am still a bit concerned with the total removal of python 2.7 year ago
and its support, I think this was a somewhat swift decision that may need
to be re-considered. I understand the urge for portmgr to move base over to
a supported version, but also that caused few important packages to be
dropped out of the FreeBSD without any fix in sight. I am specifically
talking about the PyPy package, which needs 2.7 to bootstrap itself even
when compiled as a "Python3" version.

At the same time we still have a port of for example GCC 4.6, which is like
what, 15 years old? Also things in the tree like jython or micropython are
effectively python 2 implementations, so why are they allowed to be present
while not rock solid and field tried 2.7? In fact jython specifically
recommends using CPython2.7 to byte-compile some of the code that it cannot
chew by itself, so it's somewhat broken as well*.

Is there any chance to bring CPython2.7 at the very least as a NO_PACKAGE
build tool that could be used for such cases now that we have moved most of
the supported packages to 3.x land?

I had always considered FreeBSD to be about "tools not policy", but in this
particular case the policy seemingly took priority over tools and common
sense.

Sorry if I am beating a dead horse here, just wanted to gauge the position
of the project before I go and open yet another bug report.

Thanks!

-Max
*) Like the following:
java.lang.RuntimeException: java.lang.RuntimeException:
Encountered too large method code in
/usr/ports/lang/pypy/work/pypy3.8-v7.3.7-src/rpython/rlib/unicodedata/unicodedb_6_0_0.py

Please provide a CPython 2.7 bytecode file (.pyc) to proceed, e.g. run
python -m py_compile
/usr/ports/lang/pypy/work/pypy3.8-v7.3.7-src/rpython/rlib/unicodedata/unicodedb_6_0_0.py
and try again.

Alternatively provide proper CPython 2.7 execute command via
cpython_cmd property, e.g. call
jython -J-Dcpython_cmd=python
or if running pip on Jython:
pip install --global-option="-J-Dcpython_cmd=python" 
*** Error code 255