x11-toolkits/qt5-gui vs. arm.armv6 build via poudriere cross build: fails (undefined references) and odd mix of "clang++" vs. "/nxb-bin/usr/bin/c++"

2017-09-05 Thread Mark Millard 
This is a bit odd so I give it in stages. The context
is based on:

poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M 
/usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v 12.0-CURRENT

poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt

(More details given later.)

First there is some unexpected use of (for example)
clang++ instead of /nxb-bin/usr/bin/c++ . Then later
I show some undefined references that make the build
fail.

For the clang++ vs. /nxb-bin/usr/bin/c++ there was
(for example):

--CONFIGURE_ENV--
QMAKESPEC="/usr/local/lib/qt5/mkspecs/freebsd-$(ccver="$(/nxb-bin/usr/bin/c++ 
--version)"; case "$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)" 
MAKE="make" QT_SELECT=qt5 PKG_CONFIG=pkgconf 
XDG_DATA_HOME=/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work  
HOME=/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work TMPDIR="/tmp" SHELL=/bin/sh 
CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

Note the expected use of /nxb-bin/usr/bin/c++ . There is also the later:

---Begin make.nxb.conf---
CC=/nxb-bin/usr/bin/cc
CPP=/nxb-bin/usr/bin/cpp
CXX=/nxb-bin/usr/bin/c++
AS=/nxb-bin/usr/bin/as
NM=/nxb-bin/usr/bin/nm
LD=/nxb-bin/usr/bin/ld
OBJCOPY=/nxb-bin/usr/bin/objcopy
SIZE=/nxb-bin/usr/bin/size
STRIPBIN=/nxb-bin/usr/bin/strip
SED=/nxb-bin/usr/bin/sed
READELF=/nxb-bin/usr/bin/readelf
RANLIB=/nxb-bin/usr/bin/ranlib
YACC=/nxb-bin/usr/bin/yacc
MAKE=/nxb-bin/usr/bin/make
STRINGS=/nxb-bin/usr/bin/strings
AWK=/nxb-bin/usr/bin/awk
FLEX=/nxb-bin/usr/bin/flex
---End make.nxb.conf---


Yet for some reason x11-toolkits/qt5-gui reports using
clang++ commands in config activity instead. For example:

Running configuration tests...
Determining architecture... ()
clang++ -c -pipe -g -Wall -W -fPIC  -I. -I/usr/local/include 
-I/usr/local/lib/qt5/mkspecs/freebsd-clang -o arch.o arch.cpp
clang++  -o arch arch.o   -L/usr/local/lib
Found architecture in binary
CFG_ARCH="arm"
CFG_CPUFEATURES=""
System architecture: 'arm'
Host architecture: 'arm'
clang++ -c -fvisibility=hidden fvisibility.c
clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
Symbol visibility control enabled.
clang++ -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC 
bsymbolic_functions.c
clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
bsymbolic_functions.c:2:2: error: "Symbolic function binding on this 
architecture may be broken, disabling it (see QTBUG-36129)."
#error "Symbolic function binding on this architecture may be broken, disabling 
it (see QTBUG-36129)."
 ^
1 error generated.
Symbolic function binding disabled.

(I omit a lot more such "clang++" lines in the config stages of output.
I did not see any /nxb-bin/usr/bin/c++ in that area.)

Still it later reports:

   Configure summary

Build type:/usr/local/lib/qt5/mkspecs/freebsd-clang (arm, CPU features: 
none detected)

qmake vars .. QMAKE_CC = /nxb-bin/usr/bin/cc QMAKE_CXX = 
/nxb-bin/usr/bin/c++ . . .


It later uses the /nxb-bin/usr/bin/c* commands in the actual
build.



As for the build failure itself. . .


--- ../../lib/libQt5Gui.so.5.7.1 ---
rm -f libQt5Gui.so.5.7.1 libQt5Gui.so libQt5Gui.so.5 libQt5Gui.so.5.7
/nxb-bin/usr/bin/c++ -Wl,--as-needed -Wl,--no-undefined 
-Wl,--version-script,QtGui.version -Wl,--enable-new-dtags -pthread 
-Wl,-rpath,/usr/local/lib/qt5 -shared -Wl,-soname,libQt5Gui.so.5 -o 
libQt5Gui.so.5.7.1 .obj/qaccessible.o . . .

fails with:

.obj/qimage.o: In function `_ZL10qt_memfillIjEvPT_S0_i':
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/src/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:803:
 undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)'
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/src/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:803:
 undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)'
.obj/qimage_conversions.o:(.data+0x524): undefined reference to 
`convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, 
QFlags)'
.obj/qimage_conversions.o:(.data+0x528): undefined reference to 
`convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, 
QFlags)'
.obj/qimage_conversions.o:(.data+0x52c): undefined reference to 
`convert_RGB888_to_RGB32_neon(QImageData*, QImageData const*, 
QFlags)'
.obj/qcompositionfunctions.o: In function `_ZL10qt_memfillIjEvPT_S0_i':
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/src/gui/../../include/QtGui/5.7.1/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:803:
 undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)'
. . .

(I've omitted a lot more such notices of undefined references.)


The context for all the above is from a

Re: PR looking for committer

2017-09-05 Thread Greg 'groggy' Lehey 
On Tuesday,  5 September 2017 at 15:56:12 +0200, Fernando Apesteguía wrote:
> Hi,
>
> Can a committer have a look at this? It blocks another port update
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222001

Probably.  In fact, you've probably caused several committers to look
at it, but possibly not the correct one.  If you say what it refers
to, you have a better chance to get something done about it.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like

2017-09-05 Thread Mark Millard 
On 2017-Sep-5, at 1:33 PM, Mark Millard  wrote:

> On 2017-Sep-5, at 1:13 PM, Jan Beich  wrote:
> 
>> Mark Millard  writes:
>> 
>>> In an experiment with building some arm ports via poudriere
>>> cross building on amd64 I got the following. It appears that
>>> clang does not handle all the assembler notation and a
>>> different assembler might need to be used for x11/pixman .
>>> (The x11/pixman usage is indirect from having specified
>>> x11/lumina and x11/xscreensaver ).
>>> 
>>> --- pixman-arm-simd-asm.lo ---
>>> /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H  
>>> -I. -I..   -mcpu=cortex-a7   -O2 -pipe -mcpu=cortex-a7  -g 
>>> -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF 
>>> .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo 
>>> pixman-arm-simd-asm.S
>>> libtool: compile:  /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. 
>>> -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT 
>>> pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c 
>>> pixman-arm-simd-asm.S  -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o
>>> :1:1: error: unknown directive
>>> . . .
>>> --- pixman-arm-simd-asm.lo ---
>>> .func fname
>>> ^
>> 
>> Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 
>> ?
> 
> . . .
> This is based on /usr/ports having -r449313 . (I updated based on
> your question.)
> . . .

The rebuild of the ports rebuilt x11/pixman earlier in the sequence
than I had guessed so it took less time to get to that point:

[00:51:26] [03] [00:00:00] Building x11/pixman | pixman-0.34.0
. . .
[00:54:15] [03] [00:02:49] Finished x11/pixman | pixman-0.34.0: Success

So -r449285 has avoided using clang's internal assembler.

===
Mark Millard
markmi at dsl-only.net

___
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: Tcl/Tk 8.4 deprecation

2017-09-05 Thread Pietro Cerutti 

> On 5 Sep 2017, at 22:01, Kevin Oberman  wrote:
> 
>> On Tue, Sep 5, 2017 at 5:03 AM, Pietro Cerutti  wrote:
>> 
>> Hi all,
>> 
>> I'll be shorty deprecating Tcl/Tk 8.4 in our ports tree. The latest
>> release of this series was 8.4.20 (June 2013).
>> Tcl/Tk series 8.5 and 8.6 are fully supported, and 8.7 is coming
>> soon-ish.
>> 
>> Thus, I will soon mark the following ports as DEPRECATED, with expiry
>> date sometimes this fall. If you care for any of them, please try to
>> upgrade them to a newer version (if any) or make them work with Tcl 8.6,
>> which is the current default version. If you need any support in the
>> process, please let me know and I'll be glad to help.
>> 
>> lang/fpc-tcl
>> lang/itcl
>> lang/smalltalk
>> lang/tcl84
>> multimedia/nxtvepg
>> games/scid
>> games/polypuzzle
>> graphics/ocaml-lablgl
>> graphics/gdtclft
>> databases/pgaccess
>> math/R
>> math/maxima
>> editors/tpad
>> x11-toolkits/ocaml-labltk
>> x11-toolkits/tk84
>> devel/vtcl
>> x11-clocks/tktz
>> net/xpvm
>> x11/tkXwin
>> 
>> Best,
>> 
>> --
>> Pietro Cerutti
>> The FreeBSD Project
>> g...@freebsd.org
>> 
> 
> I have submitted tickets for the following ports to remove references to
> tcl/tk84.
> math/R
> math/maxima
> graphics/ocaml-lablgl
> x11-toolkits/ocaml-labltk
> lang/itcl
> games/scid
> graphics/gdtclft
> databases/pgaccess
> x11-clocks/tktz
> 
> These are all trivial patched to replace "84+" with "85+" or "84,85" with
> "85". All also bump PORTREVISION so the package build system will rebuild
> them. I am uncertain that this is required, though.

Thanks Kevin,

I'd change "tcl:84+" to just "tcl", since they're picking up 86 anyway in the 
default case. Bumping PORTREVISION is indeed needed, as the runtime 
dependencies are being modified.

Thanks for your help!

-- 
Pietro Cerutti
g...@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: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like

2017-09-05 Thread Mark Millard 
On 2017-Sep-5, at 1:13 PM, Jan Beich  wrote:

> Mark Millard  writes:
> 
>> In an experiment with building some arm ports via poudriere
>> cross building on amd64 I got the following. It appears that
>> clang does not handle all the assembler notation and a
>> different assembler might need to be used for x11/pixman .
>> (The x11/pixman usage is indirect from having specified
>> x11/lumina and x11/xscreensaver ).
>> 
>> --- pixman-arm-simd-asm.lo ---
>> /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H  
>> -I. -I..   -mcpu=cortex-a7   -O2 -pipe -mcpu=cortex-a7  -g 
>> -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF 
>> .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo 
>> pixman-arm-simd-asm.S
>> libtool: compile:  /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. 
>> -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT 
>> pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c 
>> pixman-arm-simd-asm.S  -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o
>> :1:1: error: unknown directive
>> . . .
>> --- pixman-arm-simd-asm.lo ---
>> .func fname
>> ^
> 
> Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 ?

I'll let you know. But it will be a while for the results: I just
started another build experiment with:

poudriere bulk -j zrFBSDx64CjailArmV7 -w -c -f ~/armv7-origins.txt

This is based on /usr/ports having -r449313 . (I updated based on
your question.)

It will likely take 2-4 hours to get that far in the 338
packages it is attempting to build.

(I'm more experimenting with building than using the
results currently. Previously my port builds were
all native and via portmaster .)

===
Mark Millard
markmi at dsl-only.net

___
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: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like

2017-09-05 Thread Jan Beich 
Mark Millard  writes:

> In an experiment with building some arm ports via poudriere
> cross building on amd64 I got the following. It appears that
> clang does not handle all the assembler notation and a
> different assembler might need to be used for x11/pixman .
> (The x11/pixman usage is indirect from having specified
> x11/lumina and x11/xscreensaver ).
>
> --- pixman-arm-simd-asm.lo ---
> /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H  
> -I. -I..   -mcpu=cortex-a7   -O2 -pipe -mcpu=cortex-a7  -g 
> -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF 
> .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo 
> pixman-arm-simd-asm.S
> libtool: compile:  /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. 
> -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT 
> pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c 
> pixman-arm-simd-asm.S  -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o
> :1:1: error: unknown directive
> . . .
> --- pixman-arm-simd-asm.lo ---
> .func fname
> ^

Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 ?
___
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: Tcl/Tk 8.4 deprecation

2017-09-05 Thread Kevin Oberman 
On Tue, Sep 5, 2017 at 5:03 AM, Pietro Cerutti  wrote:

> Hi all,
>
> I'll be shorty deprecating Tcl/Tk 8.4 in our ports tree. The latest
> release of this series was 8.4.20 (June 2013).
> Tcl/Tk series 8.5 and 8.6 are fully supported, and 8.7 is coming
> soon-ish.
>
> Thus, I will soon mark the following ports as DEPRECATED, with expiry
> date sometimes this fall. If you care for any of them, please try to
> upgrade them to a newer version (if any) or make them work with Tcl 8.6,
> which is the current default version. If you need any support in the
> process, please let me know and I'll be glad to help.
>
> lang/fpc-tcl
> lang/itcl
> lang/smalltalk
> lang/tcl84
> multimedia/nxtvepg
> games/scid
> games/polypuzzle
> graphics/ocaml-lablgl
> graphics/gdtclft
> databases/pgaccess
> math/R
> math/maxima
> editors/tpad
> x11-toolkits/ocaml-labltk
> x11-toolkits/tk84
> devel/vtcl
> x11-clocks/tktz
> net/xpvm
> x11/tkXwin
>
> Best,
>
> --
> Pietro Cerutti
> The FreeBSD Project
> g...@freebsd.org
>

I have submitted tickets for the following ports to remove references to
tcl/tk84.
math/R
math/maxima
graphics/ocaml-lablgl
x11-toolkits/ocaml-labltk
lang/itcl
games/scid
graphics/gdtclft
databases/pgaccess
x11-clocks/tktz

These are all trivial patched to replace "84+" with "85+" or "84,85" with
"85". All also bump PORTREVISION so the package build system will rebuild
them. I am uncertain that this is required, though.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like

2017-09-05 Thread Mark Millard 
In an experiment with building some arm ports via poudriere
cross building on amd64 I got the following. It appears that
clang does not handle all the assembler notation and a
different assembler might need to be used for x11/pixman .
(The x11/pixman usage is indirect from having specified
x11/lumina and x11/xscreensaver ).

--- pixman-arm-simd-asm.lo ---
/bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H  -I. 
-I..   -mcpu=cortex-a7   -O2 -pipe -mcpu=cortex-a7  -g -fno-strict-aliasing -MT 
pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c -o 
pixman-arm-simd-asm.lo pixman-arm-simd-asm.S
libtool: compile:  /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 
-O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT pixman-arm-simd-asm.lo 
-MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c pixman-arm-simd-asm.S  -fPIC -DPIC 
-o .libs/pixman-arm-simd-asm.o
:1:1: error: unknown directive
. . .
--- pixman-arm-simd-asm.lo ---
.func fname
^
./pixman-arm-simd-asm.h:599:5: note: while in macro instantiation
pixman_asm_function fname
^
/tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro instantiation
generate_composite_function pixman_composite_src___asm_armv6, 32, 0, 
32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | FLAG_SPILL_LINE_VARS_WIDE | 
FLAG_PROCESS_PRESERVES_SCRATCH, 4, blit_init, nop_macro, nop_macro, 
blit_process_head, nop_macro, blit_inner_loop
^
./pixman-arm-simd-asm.h:614:6: error: expected absolute expression
 .if prefetch_distance == 0
 ^
/tmp/pixman-arm-simd-asm-b59328.s:910:1: note: while in macro instantiation
generate_composite_function pixman_composite_src___asm_armv6, 32, 0, 
32, FLAG_DST_WRITEONLY | FLAG_COND_EXEC | FLAG_SPILL_LINE_VARS_WIDE | 
FLAG_PROCESS_PRESERVES_SCRATCH, 4, blit_init, nop_macro, nop_macro, 
blit_process_head, nop_macro, blit_inner_loop
^
./pixman-arm-simd-asm.h:620:6: error: expected absolute expression
 .if src_bpp == 32
 ^
. . .

(I've omitted much later material continuing to reject notation.)
(A variant build without the -mcpu=cortex-a7 usage got the same.)


The context for the above is from a
poudriere/qemu-user-static/native_xtools based cross build from
amd64:

poudriere jail -c -j zrFBSDx64CjailArmV7 -a arm.armv6 -x -m null -M 
/usr/obj/DESTDIRs/clang-armv7-installworld-poud -S /usr/src -v 12.0-CURRENT

poudriere bulk -j zrFBSDx64CjailArmV7 -w -f /root/armv7-origins.txt

The -x use was enabled for -m null via:

/usr/local/share/poudriere/jail.sh having a "build_native_xtools"
added:

   null)
   JAILFS=none
   FCT=build_native_xtools
   ;;


# uname -apKU
FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT  r323147M  amd64 amd64 
1200043 1200043

/usr/obj/DESTDIRs/clang-armv7-installworld-poud is from an arm/armv6
build of the same sources using -mcpu=cortex-a7 , installed via
installworld distrib-dirs distribution DB_FROM_SRC=1 DESTDIR=. . . :

# more ~/src.configs/src.conf.armv7-clang-bootstrap.amd64-host 
TO_TYPE=armv6
#
KERNCONF=GENERIC-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
#CPUTYPE=soft
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
#
# Linking lldb fails for armv6(/v7)
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
WITHOUT_LIBSOFT=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
XCFLAGS+= -mcpu=cortex-a7
XCXXFLAGS+= -mcpu=cortex-a7
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.


The source variations are almost all for powerpc family
explorations:

# svnlite status /usr/src/ | sort
?   /usr/src/sys/amd64/conf/GENERIC-DBG
?   /usr/src/sys/amd64/conf/GENERIC-NODBG
?   /usr/src/sys/arm/conf/GENERIC-DBG
?   /usr/src/sys/arm/conf/GENERIC-NODBG
?   /usr/src/sys/arm64/conf/GENERIC-DBG
?   /usr/src/sys/arm64/conf/GENERIC-NODBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M   /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M   /usr/src/crypto/openssl/crypto/armcap.c
M   /usr/src/lib/Makefile
M   /usr/src/lib/libkvm/kvm_powerpc.c
M   /usr/src/lib/libkvm/kvm_private.c
M   /usr/src/sys/boot/ofw/Makefile.inc
M   /usr/src/sys/boot/powerpc/Makefile.inc
M   /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
M   /usr/src/sys/boot/powerpc/kboot/Makefile
M   /usr/src/sys/boot/uboot/Makefile.inc
M   /usr/src/sys/conf/kmod.mk
M   /usr/src/sys/conf/ldscript.powerpc
M   /usr/src/sys/kern/subr_pcpu.c
M

Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

2017-09-05 Thread Russell Haley 
On Tue, Sep 5, 2017 at 11:52 AM, David Naylor  wrote:
> On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
>> See https://www.youtube.com/watch?v=NHllisWOCpU and
>> https://twitter.com/GeoffreyHuntley/status/904227946084294656
>
> Hi Geoffrey
>
> It is great to hear there is more interest in finishing the port of .NET Core
> to FreeBSD (and, I hope, to have ports living in the Port's Collection).
>
> Would it be possible for you to put me (and the mono@ mailing list) in touch
> with Karel and Tomas - I'm not on Twitter.
>
> I'll reply to this email (dropping ports@ and advocacy@) with more technical
> details.
>
> Regards
>
> David

Just an FYI: I found Karel's email address and dropped him a private
message for more information (I also don't use twitter). I wanted to
wait for permission before publishing any information on the mono
mailing list (including his email address etc).

I had the DotNet CORE and CLR running on FreeBSD using the
instructions posted way back when. I also asked about more information
a few months back on the DotNet forums but I can't find the message.
The response was that "nothing was happening at the time".
http://forums.dotnetfoundation.org/


Cheers,

Russ
___
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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

2017-09-05 Thread David Naylor 
On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
> See https://www.youtube.com/watch?v=NHllisWOCpU and
> https://twitter.com/GeoffreyHuntley/status/904227946084294656

Hi Geoffrey

It is great to hear there is more interest in finishing the port of .NET Core 
to FreeBSD (and, I hope, to have ports living in the Port's Collection).  

Would it be possible for you to put me (and the mono@ mailing list) in touch 
with Karel and Tomas - I'm not on Twitter.  

I'll reply to this email (dropping ports@ and advocacy@) with more technical 
details.

Regards

David


signature.asc
Description: This is a digitally signed message part.

Re: USES pgsql:plpython?

2017-09-05 Thread Lbartoletti 
Yes sorry. I wrote too fast :)
My patch is near to be ready. Just some tests to be sure.

Thanks.

Envoyé de mon smartphone BlackBerry 10.
  Message d'origine  
De: Chris Rees
Envoyé: mardi 5 septembre 2017 20:44
À: L.Bartoletti; po...@freebsd.org
Cc: pg...@freebsd.org
Objet: Re: USES pgsql:plpython?

By the way, the syntax is:

USES= pgsql
WANT_PGSQL= plpython

The argument to USES is for version selection.

Chris

On 5 September 2017 19:33:53 BST, Chris Rees  wrote:
>Hey,
>
>No reason at all... I just missed it out when I wrote that bit of
>pgsql.mk :)
>
>If you feel up to patching Mk/Uses/pgsql.mk (have a look at line 135,
>add plpython and make another line below it to match the others). 
>Please alphabetise the list while you're at it!
>
>If you can't get it to work, I'll do it.
>
>Cheers,
>
>Chris
>
>On 5 September 2017 19:25:41 BST, "L.Bartoletti"
> wrote:
>>Hi,
>>
>>I prepare a port which needs plpython. Is there any reason that we
>>don't 
>>have the choice to write in our Makefile "USES pgsql:plpython"?
>>
>>Only because there are no ports dependent upon this port? Can I add it
>
>>to my diff?
>>
>>Regards
>>
>>Loïc Bartoletti.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: USES pgsql:plpython?

2017-09-05 Thread Chris Rees 
By the way, the syntax is:

USES=  pgsql
WANT_PGSQL=  plpython

The argument to USES is for version selection.

Chris

On 5 September 2017 19:33:53 BST, Chris Rees  wrote:
>Hey,
>
>No reason at all...  I just missed it out when I wrote that bit of
>pgsql.mk :)
>
>If you feel up to patching Mk/Uses/pgsql.mk (have a look at line 135,
>add plpython and make another line below it to match the others). 
>Please alphabetise the list while you're at it!
>
>If you can't get it to work, I'll do it.
>
>Cheers,
>
>Chris
>
>On 5 September 2017 19:25:41 BST, "L.Bartoletti"
> wrote:
>>Hi,
>>
>>I prepare a port which needs plpython. Is there any reason that we
>>don't 
>>have the choice to write in our Makefile "USES pgsql:plpython"?
>>
>>Only because there are no ports dependent upon this port? Can I add it
>
>>to my diff?
>>
>>Regards
>>
>>Loïc Bartoletti.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: USES pgsql:plpython?

2017-09-05 Thread Chris Rees 
Hey,

No reason at all...  I just missed it out when I wrote that bit of pgsql.mk :)

If you feel up to patching Mk/Uses/pgsql.mk (have a look at line 135, add 
plpython and make another line below it to match the others).  Please 
alphabetise the list while you're at it!

If you can't get it to work, I'll do it.

Cheers,

Chris

On 5 September 2017 19:25:41 BST, "L.Bartoletti"  
wrote:
>Hi,
>
>I prepare a port which needs plpython. Is there any reason that we
>don't 
>have the choice to write in our Makefile "USES pgsql:plpython"?
>
>Only because there are no ports dependent upon this port? Can I add it 
>to my diff?
>
>Regards
>
>Loïc Bartoletti.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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"

USES pgsql:plpython?

2017-09-05 Thread L.Bartoletti 

Hi,

I prepare a port which needs plpython. Is there any reason that we don't 
have the choice to write in our Makefile "USES pgsql:plpython"?


Only because there are no ports dependent upon this port? Can I add it 
to my diff?


Regards

Loïc Bartoletti.

___
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: Tcl/Tk 8.4 deprecation

2017-09-05 Thread Kevin Oberman 
On Tue, Sep 5, 2017 at 5:03 AM, Pietro Cerutti  wrote:

> Hi all,
>
> I'll be shorty deprecating Tcl/Tk 8.4 in our ports tree. The latest
> release of this series was 8.4.20 (June 2013).
> Tcl/Tk series 8.5 and 8.6 are fully supported, and 8.7 is coming
> soon-ish.
>
> Thus, I will soon mark the following ports as DEPRECATED, with expiry
> date sometimes this fall. If you care for any of them, please try to
> upgrade them to a newer version (if any) or make them work with Tcl 8.6,
> which is the current default version. If you need any support in the
> process, please let me know and I'll be glad to help.
>
> lang/fpc-tcl
> lang/itcl
> lang/smalltalk
> lang/tcl84
> multimedia/nxtvepg
> games/scid
> games/polypuzzle
> graphics/ocaml-lablgl
> graphics/gdtclft
> databases/pgaccess
> math/R
> math/maxima
> editors/tpad
> x11-toolkits/ocaml-labltk
> x11-toolkits/tk84
> devel/vtcl
> x11-clocks/tktz
> net/xpvm
> x11/tkXwin
>
> Best,
>
> --
> Pietro Cerutti
> The FreeBSD Project
> g...@freebsd.org
>

Pietro,

I have both graphics/ocaml-lablgl and x11-toolkits/ocaml-labltk installed
using 8.5 with no issues. The Makefiles expressly list 84 and 85 as usable.
math/R simply requires 8.4 or higher.

I suspect most/all of the listed ports already work with supported
versions. So should these just be patched to change 84+ or 84,85 to just
85? If so, I can submit some later today, but removing 84 won't break most
(all?) whether the ports are patched or not.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

Tele-communication Mailing List

2017-09-05 Thread Kathy Wiley 
Hi, Good Day



I'm writing to check if you would be interested to acquire the newly released 
200,000+ "Tele-communication Executive" Leads with verified business emails and 
complete contact information.



Data Fields: Contact name, Title, Company name, Size, Any Location, Opt-In 
Email address, Phone & Fax numbers and etc.



Data Guarantees: 85-90% Deliver ability on emails and 98% accuracy on other 
contact information



Please let me know your target market:



Target Industry_ Target title___ Target Geography: 




Let me know your thoughts or pass on the message to the right person in your 
company.



Regards,

Kathy

Marketing Manager | Accurate Business Leads |



If you do not wish to receive further emails, please respond with "Leave Out" 
or "Unsubscribe".



___
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"

PR looking for committer

2017-09-05 Thread Fernando Apesteguía 
Hi,

Can a committer have a look at this? It blocks another port update

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222001

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: Poudreiere auto-track quarterly ports?

2017-09-05 Thread Mathieu Arnold 
Le 05/09/2017 à 03:50, Dan Mahoney a écrit :
> Hey there All,
>
> Is there an easy way to have poudriere auto-track the latest quarterly 
> ports build tree, without having to manually reset it to a specific 
> branch?
>
> Poudriere knows how to portsnap the latest ports/head, but not the latest 
> quarterly.

poudriere cannot do this by itself, it does not know how to move from
one repository to another.

This can, however, easily be done with a simple subversion command that
you can run in the script you use to build your ports.

# svn info /poudriere/ports/quarterly/|grep ^URL
URL: https://svn.freebsd.org/ports/branches/2017Q2
# svn switch ^/branches/$(svn ls
https://svn.freebsd.org/ports/branches/|sed -ne '/^2.*Q./s|/$||p'|tail
-1) /poudriere/ports/quarterly/
D    ports/quarterly/graphics/dri
...
# svn info /poudriere/ports/quarterly/|grep ^URL
URL: https://svn.freebsd.org/ports/branches/2017Q3


The svn switch command can be run each time, it will not break. (The svn
ls trick is taken from the bit I wrote for ports/Tools/scripts/mfh.)


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Tcl/Tk 8.4 deprecation

2017-09-05 Thread Pietro Cerutti 
Hi all,

I'll be shorty deprecating Tcl/Tk 8.4 in our ports tree. The latest
release of this series was 8.4.20 (June 2013).
Tcl/Tk series 8.5 and 8.6 are fully supported, and 8.7 is coming
soon-ish.

Thus, I will soon mark the following ports as DEPRECATED, with expiry
date sometimes this fall. If you care for any of them, please try to
upgrade them to a newer version (if any) or make them work with Tcl 8.6,
which is the current default version. If you need any support in the
process, please let me know and I'll be glad to help.

lang/fpc-tcl
lang/itcl
lang/smalltalk
lang/tcl84
multimedia/nxtvepg
games/scid
games/polypuzzle
graphics/ocaml-lablgl
graphics/gdtclft
databases/pgaccess
math/R
math/maxima
editors/tpad
x11-toolkits/ocaml-labltk
x11-toolkits/tk84
devel/vtcl
x11-clocks/tktz
net/xpvm
x11/tkXwin

Best,

-- 
Pietro Cerutti
The FreeBSD Project
g...@freebsd.org


signature.asc
Description: PGP signature

Re: Poudreiere auto-track quarterly ports?

2017-09-05 Thread Baho Utot 


On 09/04/17 21:50, Dan Mahoney wrote:

Hey there All,

Is there an easy way to have poudriere auto-track the latest quarterly
ports build tree, without having to manually reset it to a specific
branch?

Poudriere knows how to portsnap the latest ports/head, but not the latest
quarterly.

Example: Currently, I can't build ports due to a failure in -HEAD for one
of my dependencies (xerces-c3-3.2.0) which causes several other ports to
fail as well.

Presumably, this port is more stable in the quarterly branch, which is
where me (and I think most people) would like to do most of our building
with -- for those of us that are only building custom ports to get new
options, not those of us that need the latest-greatest code.

However, that means that four times a year, one needs to manually do
surgery on our repos, not only to pull in the new quarterly branch, but
also to re-point pkg at the new build location.

It would work better if poudriere were either aware of the way the
quarterly branches are named, OR if there was a tag that always pointed a
the current quarterly, same as in pkg.

Is this possible?

-Dan Mahoney
___


I use synth and I have some bourne scripts that do what you are asking.
I pull the source for ports using svnlite and then run synth.

Maybe you can script what you want to do but use poudriere.  BTW I think 
synth is easier to use than poudriere, just my preference.


___
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 you maintain which are out of date

2017-09-05 Thread 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
+-+
devel/py-spyder | 2.3.7   | v3.2.2
+-+
net/yaz | 5.21.1  | 5.23.1
+-+
shells/sparforte| 2.0.2   | v2.1
+-+


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: Poudreiere auto-track quarterly ports?

2017-09-05 Thread Romain Tartière 
Hi

On Tue, Sep 05, 2017 at 01:50:06AM +, Dan Mahoney wrote:
> Is there an easy way to have poudriere auto-track the latest quarterly 
> ports build tree, without having to manually reset it to a specific 
> branch?
> 
> Poudriere knows how to portsnap the latest ports/head, but not the latest 
> quarterly.

I guess the -B flag of poudriere(8) is designed for this, never used it
though…

Have you tried it?

poudriere -c -m svn -B branches/2017Q3 [other flags]

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature