Re: New feature suggestion: print-gh-tuple: Print GH_TUPLE corresponding to submodules of a GitHub repository ${GH_ACCOUNT}/${GH_PROJECT}

[Mateusz Piotrowski]

On 4/16/20 6:56 PM, Yuri wrote:

I am suggesting a new feature: make print-gh-tuple


https://reviews.freebsd.org/D24231


It works when USE_GITHUB=yes is set.

When a GitHub repository has git submodules, that themselves can also 
have embedded submodules, it can traverse all of them and output the 
value of GH_TUPLE that would include all of them.


Great idea! I've done something similar for x11/ly. It's great to 
possibly have something more general and available through out the whole 
ports tree.


I'll try to take a look at the patch soon.

Cheers,

Mateusz

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: llvm-mingw Cross Compiler

[Theron]

On 2020-04-17 02:22, Russell Haley wrote:

Hello,

I found the most excellent llvm-mingw project by Martin Storsjo:
https://github.com/mstorsjo/llvm-mingw/

It uses shell scripts to build all the components. I'm currently using it
on FreeBSD 12 to cross build itself for Windows for i686 and amd64 (x86_64
to be exact).

Is there any interest in llvm-mingw as a port?

I use this as well, and submitted a port here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237213

Looks like I promised to bring it up on this mailing list but neglected 
to do so.


Now it might be a bit out of date, an update would be appreciated, since 
I won't be able to work on that in a timely manner.


Theron
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: libv4l-1.18.0 error upgrade

[Alex V. Petrov]

Making all in libdvbv5
gmake[4]: Entering directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0/lib/libdvbv5'


/bin/sh ../../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.
-I../..  -I../..  -I/usr/local/include  -pthread -I../../lib/include
-Wall -Wpointer-arith -D_GNU_SOURCE -I../../contrib/freebsd/include
-I/usr/local/include -DLIBICONV_PLUG  -O2 -pipe  -DLIBICONV_PLUG
-fstack-protector-strong -fno-strict-aliasing  -MT
libdvbv5_la-compat-soname.lo -MD -MP -MF
.deps/libdvbv5_la-compat-soname.Tpo -c -o libdvbv5_la-compat-soname.lo
`test -f 'compat-soname.c' || echo './'`compat-soname.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../.. -I../..
-I/usr/local/include -pthread -I../../lib/include -Wall -Wpointer-arith
-D_GNU_SOURCE -I../../contrib/freebsd/include -I/usr/local/include
-DLIBICONV_PLUG -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-fno-strict-aliasing -MT libdvbv5_la-compat-soname.lo -MD -MP -MF
.deps/libdvbv5_la-compat-soname.Tpo -c compat-soname.c  -fPIC -DPIC -o
.libs/libdvbv5_la-compat-soname.o
In file included from compat-soname.c:22:

../../lib/include/libdvbv5/dvb-dev.h:258:8: error: unknown type name
'dvb_logfunc_priv'; did you mean 'dvb_logfunc'?

 dvb_logfunc_priv logfunc, void *logpriv);

 ^~~~

 dvb_logfunc
/usr/local/include/libdvbv5/dvb-log.h:45:16: note: 'dvb_logfunc'
declared here

typedef void (*dvb_logfunc)(int level, const char *fmt, ...)
__attribute__ (( format( printf, 2, 3 )));

   ^
1 error generated.
gmake[4]: *** [Makefile:944: libdvbv5_la-compat-soname.lo] Error 1

gmake[4]: Leaving directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0/lib/libdvbv5'


gmake[3]: *** [Makefile:472: all-recursive] Error 1

gmake[3]: Leaving directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0/lib'


gmake[2]: *** [Makefile:590: all-recursive] Error 1

gmake[2]: Leaving directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0'


gmake[1]: *** [Makefile:517: all] Error 2

gmake[1]: Leaving directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0'


*** Error code 1

Stop.
make: stopped in /usr/ports/multimedia/libv4l
-- 
-
Alex.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: libv4l-1.18.0 error upgrade

[Christoph Moench-Tegeder]

## Alex V. Petrov (alexvpet...@gmail.com):

> ../../lib/include/libdvbv5/dvb-dev.h:258:8: error: unknown type name
> 'dvb_logfunc_priv'; did you mean 'dvb_logfunc'?
> 
>  dvb_logfunc_priv logfunc, void *logpriv);
> 
>  ^~~~
> 
>  dvb_logfunc
> /usr/local/include/libdvbv5/dvb-log.h:45:16: note: 'dvb_logfunc'
> declared here

There's your problem: it's picking up headers from the old version.
Remove the old version first (or better: use a clean environment for
building, just like poudriere provides). libv4l (yes, 1.18.0) built
just fine here in poudriere.

Regards,
Christoph

-- 
Spare Space
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: libv4l-1.18.0 error upgrade

[Hans Petter Selasky]

On 2020-04-17 12:52, Alex V. Petrov wrote:

Making all in libdvbv5
gmake[4]: Entering directory
'/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0/lib/libdvbv5'


You need to deinstall the libv4l package first. Only then it will build 
due to confliciting header file include order!


--HPS

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: libv4l-1.18.0 error upgrade

[Alex V. Petrov]

17.04.2020 18:05, Hans Petter Selasky пишет:
> On 2020-04-17 12:52, Alex V. Petrov wrote:
>> Making all in libdvbv5
>> gmake[4]: Entering directory
>> '/usr/ports/multimedia/libv4l/work/v4l-utils-1.18.0/lib/libdvbv5'
> 
> You need to deinstall the libv4l package first. Only then it will build
> due to confliciting header file include order!
> 
> --HPS
> 

Yes, It's worked.
Thank you.

-- 
-
Alex.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Dewayne Geraghty]

Its very confusing building ports at the moment.  At https://www.python.org/
there is a release candidate for 2.7.18, while our python 2.7 has been
marked as deprecated with an expiration date.  Can the Expiration Date of
2020-12-31 be retracted?

It appears that devel/scons, at least, requires python 2.7 to run; though
it builds with 3.7.
Regards, Dewayne.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Poudriere make.conf documentation question

[Jose Quinteiro]

Hello,

The Handbook says:
"The system make.conf and this new file are combined at build time to
create the make.conf used by the build jail."
https://www.freebsd.org/doc/handbook/ports-poudriere.html

The poudriere man page and Porter's Handbook do not mention
/etc/make.conf as a file that will get used.

My simple test did not work with /etc/make.conf, but I also suspect I
screwed something else up.

Does /etc/make.conf get "combined" into the effective make.conf for
Poudriere?

Thanks,
Jose
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: New feature suggestion: print-gh-tuple: Print GH_TUPLE corresponding to submodules of a GitHub repository ${GH_ACCOUNT}/${GH_PROJECT}

[Yuri]

On 2020-04-17 00:37, Mateusz Piotrowski wrote:
Great idea! I've done something similar for x11/ly. It's great to 
possibly have something more general and available through out the 
whole ports tree.


Thanks!


This particular project (ly) is a bad example because it uses some 
GitHub extension, git itself doesn't find submodules there: 'git 
submodule status' fails on it, and 'git clone --recurse-submodules' 
doesn't clone submodules.



Yuri


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Poudriere make.conf documentation question

[Brooks Davis]

On Fri, Apr 17, 2020 at 09:42:51AM -0700, Jose Quinteiro wrote:
> Hello,
> 
> The Handbook says:
> "The system make.conf and this new file are combined at build time to
> create the make.conf used by the build jail."
> https://www.freebsd.org/doc/handbook/ports-poudriere.html
> 
> The poudriere man page and Porter's Handbook do not mention
> /etc/make.conf as a file that will get used.
> 
> My simple test did not work with /etc/make.conf, but I also suspect I
> screwed something else up.
> 
> Does /etc/make.conf get "combined" into the effective make.conf for
> Poudriere?

I think that documentation is confusing as is the manpage.  I think
that the webpage is refering to the first one in the list below not
/etc/make.conf, but I could be wrong.  Here's the relevent bit of
the manpage:

   Create optional make.conf
 You can also specify a global make.conf which will be used for all the
 jails.  Any of the following are allowed and will all be used in the
 order shown:

   /usr/local/etc/poudriere.d/make.conf
   /usr/local/etc/poudriere.d/-make.conf
   /usr/local/etc/poudriere.d/-make.conf
   /usr/local/etc/poudriere.d/-make.conf
   /usr/local/etc/poudriere.d/--make.conf
   /usr/local/etc/poudriere.d/--make.conf
   /usr/local/etc/poudriere.d/--make.conf
   /usr/local/etc/poudriere.d/---make.conf
   /usr/local/etc/poudriere.d/hooks/plugins//make.conf

-- Brooks


signature.asc
Description: PGP signature

Re: Poudriere make.conf documentation question

[Adam Weinberger]

On Fri, Apr 17, 2020 at 10:54 AM Brooks Davis  wrote:
>
> On Fri, Apr 17, 2020 at 09:42:51AM -0700, Jose Quinteiro wrote:
> > Hello,
> >
> > The Handbook says:
> > "The system make.conf and this new file are combined at build time to
> > create the make.conf used by the build jail."
> > https://www.freebsd.org/doc/handbook/ports-poudriere.html
> >
> > The poudriere man page and Porter's Handbook do not mention
> > /etc/make.conf as a file that will get used.
> >
> > My simple test did not work with /etc/make.conf, but I also suspect I
> > screwed something else up.
> >
> > Does /etc/make.conf get "combined" into the effective make.conf for
> > Poudriere?
>
> I think that documentation is confusing as is the manpage.  I think
> that the webpage is refering to the first one in the list below not
> /etc/make.conf, but I could be wrong.  Here's the relevent bit of
> the manpage:
>
>Create optional make.conf
>  You can also specify a global make.conf which will be used for all the
>  jails.  Any of the following are allowed and will all be used in the
>  order shown:
>
>/usr/local/etc/poudriere.d/make.conf
>/usr/local/etc/poudriere.d/-make.conf
>/usr/local/etc/poudriere.d/-make.conf
>/usr/local/etc/poudriere.d/-make.conf
>/usr/local/etc/poudriere.d/--make.conf
>/usr/local/etc/poudriere.d/--make.conf
>/usr/local/etc/poudriere.d/--make.conf
>/usr/local/etc/poudriere.d/---make.conf
>/usr/local/etc/poudriere.d/hooks/plugins//make.conf

Wow, you and Jose are right, that wording is really confusing. Your
description is correct, Brooks. The system /etc/make.conf is not
exposed to poudriere at all.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

emulators/emu64: Looking for someone to review/commit bugfix

[Felix Palmen]

Hi all,

emulators/emu64 has a problem that could be fixed now, see PR #245395
.

So far, the reporter and the upstream author confirmed the patch to work
fine. As the port maintainer, I kindly ask for someone to review this,
so it could be committed soon.

The reason I'm asking here is that the port currently isn't usable for
anyone using OSS as the audio backend in SDL, and I assume that's the
majority of all users.

Thanks,
Felix

-- 
 Dipl.-Inform. Felix Palmen ,.//..
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key} http://palmen-it.de/pub.txt   //   """
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A


signature.asc
Description: PGP signature

Re: emulators/emu64: Looking for someone to review/commit bugfix

[Rodrigo Osorio]

On 4/17/20 11:35 PM, Felix Palmen wrote:

Hi all,

emulators/emu64 has a problem that could be fixed now, see PR #245395
.

So far, the reporter and the upstream author confirmed the patch to work
fine. As the port maintainer, I kindly ask for someone to review this,
so it could be committed soon.

The reason I'm asking here is that the port currently isn't usable for
anyone using OSS as the audio backend in SDL, and I assume that's the
majority of all users.

Thanks,
Felix


Hi Felix, I took it.

Regards
-- rodrigo


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Dimitry Andric]

On 17 Apr 2020, at 14:11, Dewayne Geraghty  wrote:
> 
> Its very confusing building ports at the moment.  At https://www.python.org/
> there is a release candidate for 2.7.18, while our python 2.7 has been
> marked as deprecated with an expiration date.  Can the Expiration Date of
> 2020-12-31 be retracted?
> 
> It appears that devel/scons, at least, requires python 2.7 to run; though
> it builds with 3.7.

See https://www.python.org/dev/peps/pep-0373/; python 2.x is now really
dead, and has been since 2020-01-01.

But it is unfortunately terribly confusing for end-users that they're
apparently still planning on shipping another "really final final"
2.7.18 version. A petition against this bad idea is here:

https://discuss.python.org/t/petition-abandon-plans-to-ship-a-2-7-18-in-april/2946

But basically, expect all python 2.x using ports to go away, unless they
get fixed to use python 3.x, or no python at all.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Robert Huff]

Dimitry Andric writes:

>  But basically, expect all python 2.x using ports to go away, unless
>  they get fixed to use python 3.x, or no python at all.

Is there a method whereby - given a list of installed ports using
python 2 - one might determine which can and which cannot be upgraded
to pythin 3?


Respectfully,


Robert "110 candidates" Huff


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[George Mitchell]

On 2020-04-17 20:19, Robert Huff wrote:
> 
> Dimitry Andric writes:
> 
>>  But basically, expect all python 2.x using ports to go away, unless
>>  they get fixed to use python 3.x, or no python at all.
> 
>   Is there a method whereby - given a list of installed ports using
> python 2 - one might determine which can and which cannot be upgraded
> to pythin 3?
> [...]

There's a heuristic method: run the python program "2to3" on the
file you want to asses.  It will try to replace 2.x usages with
their 3.x equivalents.  Success is not guaranteed.  (2to3 is part
of python27.)-- George



signature.asc
Description: OpenPGP digital signature

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Dima Pasechnik]

On Sat, Apr 18, 2020 at 8:20 AM Robert Huff  wrote:
>
>
> Dimitry Andric writes:
>
> >  But basically, expect all python 2.x using ports to go away, unless
> >  they get fixed to use python 3.x, or no python at all.
>
> Is there a method whereby - given a list of installed ports using
> python 2 - one might determine which can and which cannot be upgraded
> to pythin 3?

typically, if a package is Python 2-only, without an upstream effort
to port it to Python 3 already complete, or almost complete,
this means it's a basically a dead project.

Several projects switched to Python 3 quite a while ago, e.g. ipython,
meaning that the Python 2 version has been
lagging behind Python 3 for long time already. (in case of ipython,
Python 2 support stopped at 6.0, and the current ipython,
Python 3 only, is 7.13)

That is, the best way it to check the upstream for updates.

HTH
Dima

>
>
> Respectfully,
>
>
> Robert "110 candidates" Huff
>
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: editors/atom: build error on 13.0-CURRENT

[Vidar Karlsen]

On 4/17/20 7:24 AM, Hiroki Tagato wrote:


Can you apply a patch at https://github.com/nodejs/node/pull/29541 and 
try to build again? If it goes well, I will update the port to include 
the patch.


Thanks,
Hiroki


It passes the configure phase with that change to the regex, but it 
fails later.


Running 'make' in /usr/ports/editors/atom:
[...]
  c++ '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=0' 
'-DV8_TARGET_ARCH_X64' '-DV8_EMBEDDER_STRING="-node.8"' 
'-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT' 
'-Dv8_promise_internal_field_count' '-DV8_INTL_SUPPORT' 
'-DV8_CONCURRENT_MARKING' '-DDISABLE_UNTRUSTED_CODE_MITIGATIONS' 
-I../deps/v8 -I../deps/v8/include  -pthread -Wall -Wextra 
-Wno-unused-parameter -m64 -D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 
-fno-strict-aliasing -I/usr/local/include -fdata-sections 
-ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti 
-fno-exceptions -std=gnu++1y -MMD -MF 
/usr/ports/editors/atom/work/node-v10.2.1/out/Release/.deps//usr/ports/editors/atom/work/node-v10.2.1/out/Release/obj.target/v8_init/deps/v8/src/setup-isolate-full.o.d.raw 
-isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing  -isystem /usr/local/include  -c 
-o 
/usr/ports/editors/atom/work/node-v10.2.1/out/Release/obj.target/v8_init/deps/v8/src/setup-isolate-full.o 
../deps/v8/src/setup-isolate-full.cc

In file included from ../deps/v8/src/setup-isolate-full.cc:7:
In file included from ../deps/v8/src/base/logging.h:8:
In file included from /usr/include/c++/v1/cstring:59:
/usr/include/c++/v1/__config:122:2: error: 
"_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported.use 
_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR instead

#error "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported. \
 ^
  c++ '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=0' 
'-DV8_TARGET_ARCH_X64' '-DV8_EMBEDDER_STRING="-node.8"' 
'-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT' 
'-Dv8_promise_internal_field_count' '-DV8_INTL_SUPPORT' 
'-DV8_CONCURRENT_MARKING' '-DDISABLE_UNTRUSTED_CODE_MITIGATIONS' 
-I../deps/v8  -pthread -Wall -Wextra -Wno-unused-parameter -m64 
-D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 -fno-strict-aliasing 
-I/usr/local/include -fdata-sections -ffunction-sections -O3 -O3 
-fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++1y -MMD -MF 
/usr/ports/editors/atom/work/node-v10.2.1/out/Release/.deps//usr/ports/editors/atom/work/node-v10.2.1/out/Release/obj.target/v8_libbase/deps/v8/src/base/bits.o.d.raw 
-isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing  -isystem /usr/local/include  -c 
-o 
/usr/ports/editors/atom/work/node-v10.2.1/out/Release/obj.target/v8_libbase/deps/v8/src/base/bits.o 
../deps/v8/src/base/bits.cc

In file included from ../deps/v8/src/base/bits.cc:5:
In file included from ../deps/v8/src/base/bits.h:8:
In file included from /usr/include/c++/v1/stdint.h:106:
/usr/include/c++/v1/__config:122:2: error: 
"_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported.use 
_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR instead

#error "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported. \
 ^
1 error generated.
gmake[3]: *** [deps/v8/gypfiles/v8_libbase.target.mk:131: 
/usr/ports/editors/atom/work/node-v10.2.1/out/Release/obj.target/v8_libbase/deps/v8/src/base/bits.o] 
Error 1

gmake[3]: *** Waiting for unfinished jobs
[...]

I have uploaded the full output to https://bsd.to/oh4e

It builds fine when I give it --openssl-no-asm, and I also noticed that 
www/node10 also does exactly this.


--
Vidar
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Robert Huff]

George Mitchell writes:

>  >>  But basically, expect all python 2.x using ports to go away, unless
>  >>  they get fixed to use python 3.x, or no python at all.
>  > 
>  >Is there a method whereby - given a list of installed ports using
>  > python 2 - one might determine which can and which cannot be upgraded
>  > to pythin 3?
>  > [...]
>  
>  There's a heuristic method: run the python program "2to3" on the
>  file you want to asses.  It will try to replace 2.x usages with
>  their 3.x equivalents.  Success is not guaranteed.  (2to3 is part
>  of python27.)-- George

Let me be more precise.
I have a list of 110 installed ports flavored "py27-".
For each port I want to know:

a) according to the Makefile, is it possible to build this with
python-37?  (Or even -36?) 
b) will doing so break any port for which this port is a dependency?

I understand the only way to answer (b) may be by trial-and-error;
fair enough.  But if I can identify all those with no dependants
... that would be a start.


Respectfully,


Robert Huff

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

rspamd configuration is broken, apparently

[Russell L. Carter]

Greetings,

rspamd novice here, but right from the beginning postfix +
spamassassin + all those other things for 25 years.

12-stable, completely current /usr/ports/mail/rspamd install

I've been through the source code of rspamd, and worn out google,
and I am completely defeated by the default ports rspamd install
producing this very very basic error:

root@h2> rspamadm configdump -m
2020-04-17 21:02:46 #0(main) ; cfg; rspamd_init_filters: 
requested unknown module spf
2020-04-17 21:02:46 #0(main) ; cfg; rspamd_init_filters: 
requested unknown module arc
2020-04-17 21:02:46 #0(main) ; lua; arc.lua:34: cannot enable 
arc plugin: dkim is disabled


Any ideas, pointers, better google search strings, very much
appreciated.

I suppose I could add the contents of /usr/local/share/rspamd/plugins,
mention that I tried various possibilities of merge/override in
~/local.d etc. etc.

Many thanks,
Russell

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"