Re: lang/go14 doesn't build without COMPAT11 in FREEBSD 12

[Lucas Nali de Magalhães]

> On Mar 23, 2019, at 8:16 PM, Eugene Grosbein  wrote:
> 
> 24.03.2019 1:38, Lucas Nali de Magalhães wrote:
> 
>> I found a few bugs since I started rebuilding my system.
>> Most of them are related with the lack of handling of CPUTYPE=native 
>> make.conf tunable.
> 
> Use CPUTYPE?=native instead of CPUTYPE=native.

The issue is better explained in the other thread, sorry.  CPUTYPE native means 
the system detects its own processor and I was informed that this detection 
isn't working well. qt5-gui suffers from this problem.

The old documentation allowed native but the new one doesn't mention it (so it 
doesn't allow its use).

Lc

-- 
rollingbits — 📧 rollingb...@gmail.com 📧 rollingb...@terra.com.br 📧 
rollingb...@yahoo.com 📧 rollingb...@globo.com 📧 rollingb...@icloud.com

___
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: Clang Import Breakage

[Jan Beich]

Sean Bruno  writes:

> On 3/23/19 5:57 PM, Dimitry Andric wrote:
>> This is fallout of ,
>> which enabled --no-allow-shlib-undefined by default.  See also
>> .  Executive summary: lots of programs
>> do not specify all their required libraries, a.k.a. "under-linking".
>> 
>> I haven't yet reverted lld's new default, since it seems that a lot of
>> under-linking fixes are now being made.  These problems will also occur
>> when linking with gold, for instance, so it is quite useful to solve
>> them once and for all.
>> 
>> -Dimitry
>
> Oh, hrm.  Ok.
>
> So, before the changes, my port succeeds in adding libogg to its LD list
> when doing its link.

LLD before and BFD linker didn't complain that your port bootlegged
libogg via libvorbis. For one, libvorbis may stop depending on libogg,
may bundle libogg as a static library or import libogg symbols with
LOCAL visibility.

Ditto for libssl bootlegging libcrypto.
___
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: Strange build error of graphics/cairo on latest 13-CURRENT

[Jan Beich]

Yasuhiro KIMURA  writes:

> Hello.
>
> Yesterday I updated my 13-CURRENT amd64 host to r345414 and now I'm 
> experiencing strange build error of graphics/cairo. If I build it with
> "cd /usr/ports/graphics/cairo; make install" it finishes
> successfully. But if I do it with portmaster it fails at configure
> phase as following.

Can you reproduce after https://svnweb.freebsd.org/changeset/base/345431 ?
___
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"

Warning in duplicity after py2-cryptograph update

[Xavier]

Hi everyone,

Since last update of python modules py27-cryprography and
py27-matplotlib, duplicity emits a warning :

> CryptographyDeprecationWarning: Support for unsafe construction of public 
> numbers from encoded data will be removed in a future version. Please use 
> EllipticCurvePublicKey.from_encoded_point

Should I file a PR ?

Cheers

Xavier

-- 
Xavier Humbert - sysadmin & network engineer



signature.asc
Description: OpenPGP digital signature

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
+-+
databases/postgresql-plv8js | 1.4.8   | v2.3.10
+-+
multimedia/minitube | 2.9 | 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

Thanks.
___
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: Clang Import Breakage

[Konstantin Belousov]

On Sun, Mar 24, 2019 at 07:03:11AM +0100, Jan Beich wrote:
> Sean Bruno  writes:
> 
> > On 3/23/19 5:57 PM, Dimitry Andric wrote:
> >> This is fallout of ,
> >> which enabled --no-allow-shlib-undefined by default.  See also
> >> .  Executive summary: lots of programs
> >> do not specify all their required libraries, a.k.a. "under-linking".
> >> 
> >> I haven't yet reverted lld's new default, since it seems that a lot of
> >> under-linking fixes are now being made.  These problems will also occur
> >> when linking with gold, for instance, so it is quite useful to solve
> >> them once and for all.
> >> 
> >> -Dimitry
> >
> > Oh, hrm.  Ok.
> >
> > So, before the changes, my port succeeds in adding libogg to its LD list
> > when doing its link.
> 
> LLD before and BFD linker didn't complain that your port bootlegged
> libogg via libvorbis. For one, libvorbis may stop depending on libogg,
> may bundle libogg as a static library or import libogg symbols with
> LOCAL visibility.
But in this case, you get the breakage even with the ld.bfd, and if
you get over the static linking stage, with runtime linker as well.
This is exactly the issue that disabling of underlinking uncovers:
if you use a symbol provided by a library, the library must appear in
DT_NEEDED.

> 
> Ditto for libssl bootlegging libcrypto.
> ___
> 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: lang/go14 doesn't build without COMPAT11 in FREEBSD 12

[Robert Huff]

=?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= writes:

>  The issue is better explained in the other thread, sorry.  CPUTYPE
>  native means the system detects its own processor and I was informed
>  that this detection isn't working well

If true, this sounds like an excellent project for Summer of Code.
Perhaps someone who knows how could add it to the porjects list?


Suggestively,


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"

Re: Strange build error of graphics/cairo on latest 13-CURRENT

[Yasuhiro KIMURA]

From: Jan Beich 
Subject: Re: Strange build error of graphics/cairo on latest 13-CURRENT
Date: Sun, 24 Mar 2019 07:36:03 +0100

>> Yesterday I updated my 13-CURRENT amd64 host to r345414 and now I'm 
>> experiencing strange build error of graphics/cairo. If I build it with
>> "cd /usr/ports/graphics/cairo; make install" it finishes
>> successfully. But if I do it with portmaster it fails at configure
>> phase as following.
> Can you reproduce after https://svnweb.freebsd.org/changeset/base/345431 ?

I updated host and jail to r345464 and now graphics/cairo can be built
with portmaster and poudriere. I wonder why build didn't fail with
simple "make install". But anyway problem is fixed.

Thank you for advice.

---
Yasuhiro KIMURA
___
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: lang/go14 doesn't build without COMPAT11 in FREEBSD 12

[Mark Millard via freebsd-ports]

Eugene Grosbein eugen at grosbein.net wrote on
Sat Mar 23 23:16:40 UTC 2019 :

24.03.2019 1:38, Lucas Nali de Magalhães wrote:
> > I found a few bugs since I started rebuilding my system.
> > Most of them are related with the lack of handling of CPUTYPE=native 
> > make.conf tunable.
> 
> Use CPUTYPE?=native instead of CPUTYPE=native.

# grep -r CPUTYPE Makefile* share/mk/ | grep -i native
#

There is no special handling of 'native'.

By contrast there is testing of specific values, used
to determine MACHINE_CPU 's list of features, not just
use of -march=${CPUTYPE} . I'll note that -march=native
or -mcpu=native for compilers does not work on all
architectures, only some. Others just report the lack
of support.

# grep -r '\' Makefile* share/mk/ | more
Makefile.inc1:TARGET_CPUTYPE?=${CPUTYPE}
Makefile.inc1:_CPUTYPE!=MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} 
-f /dev/null \
Makefile.inc1:  -m ${.CURDIR}/share/mk MK_AUTO_OBJ=no -V CPUTYPE
Makefile.inc1:.error CPUTYPE global should be set with ?=.
Makefile.inc1:  CPUTYPE=${TARGET_CPUTYPE}
Makefile.inc1:  @echo For ZSH you must run: export CPUTYPE=${TARGET_CPUTYPE}
Makefile.inc1:XDEV_CPUTYPE?=${CPUTYPE}
Makefile.inc1:  CPUTYPE=${XDEV_CPUTYPE}
Makefile.libcompat:LIBSOFTWMAKEENV= CPUTYPE=soft MACHINE=arm 
MACHINE_ARCH=${TARGET_ARCH}
. . . (omitting transforations to standardized CPUTYPE names) . . .
share/mk/bsd.cpu.mk:# after /etc/make.conf so it can react to the local value 
of CPUTYPE
share/mk/bsd.cpu.mk:.  if ${CPUTYPE} == "crusoe"
share/mk/bsd.cpu.mk:.  elif ${CPUTYPE} == "k5"
share/mk/bsd.cpu.mk:.  elif ${CPUTYPE} == "c7"
share/mk/bsd.cpu.mk:_CPUCFLAGS = -march=${CPUTYPE}
share/mk/bsd.cpu.mk:_CPUCFLAGS = -march=${CPUTYPE}
share/mk/bsd.cpu.mk:.  if ${CPUTYPE} == "xscale"
share/mk/bsd.cpu.mk:.  elif ${CPUTYPE:M*soft*} != ""
. . . (it is a long list of cases) . . .

Note that:

Taking a couple of examples from the cases (one for _CPUCFLAGS
and one for MACHINE_CPU):

. if ${MACHINE_CPUARCH} == "i386"
. . .
.  if ${CPUTYPE} == "crusoe"
_CPUCFLAGS = -march=i686 -falign-functions=0 -falign-jumps=0 -falign-loops=0
.  elif ${CPUTYPE} == "k5"
_CPUCFLAGS = -march=pentium
.  elif ${CPUTYPE} == "c7"
_CPUCFLAGS = -march=c3-2
.  else
_CPUCFLAGS = -march=${CPUTYPE}
.  endif
. . .
. elif ${MACHINE_ARCH} == "powerpc"
.  if ${CPUTYPE} == "e500"
_CPUCFLAGS = -Wa,-me500 -msoft-float
.  else
_CPUCFLAGS = -mcpu=${CPUTYPE} -mno-powerpc64
.  endif

and:

. elif ${MACHINE_CPUARCH} == "amd64"
. . .
.  elif ${CPUTYPE} == "goldmont" || ${CPUTYPE} == "westmere" || \
${CPUTYPE} == "nehalem" || ${CPUTYPE} == "silvermont"
MACHINE_CPU = sse42 sse41 ssse3 sse3

MACHINE_CPU ends up without such for 'native' as CPUTYPE as far
as I can tell.

To my knowledge, FreeBSD has never figured out the MACHINE_CPU
assignment for 'native' as CPUTYPE.

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

___
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: Warning in duplicity after py2-cryptograph update

[Kubilay Kocak]

On 24/03/2019 8:34 pm, Xavier wrote:

Hi everyone,

Since last update of python modules py27-cryprography and
py27-matplotlib, duplicity emits a warning :


CryptographyDeprecationWarning: Support for unsafe construction of public 
numbers from encoded data will be removed in a future version. Please use 
EllipticCurvePublicKey.from_encoded_point


Should I file a PR ?


A particular method was deprecated in the Python cryptography package, 
in 2.5. See the last entry in:


https://github.com/pyca/cryptography/blob/master/CHANGELOG.rst#25---2019-01-22

The issue is not related to matplotlib. sysutils/duplicity uses 
security/paramiko, which already has a bug reported for the issue:


https://github.com/paramiko/paramiko/issues/1369

./koobs
___
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"