Re: mariadb10* ports broken on 9.x since last commit

2016-09-01 Thread Doug Barton 
September 1, 2016 2:43 PM, "Konstantin Belousov"  wrote:
> On Thu, Sep 01, 2016 at 10:50:18PM +0200, Dimitry Andric wrote:

>> It is probably easier to work around this by configuring the binutils
>> port so it does not emit .init_array/.fini_array sections.
> 
> It was already done in ports r421193.

I just upgraded to the latest binutils and rebuilt mariadb* and things do seem 
to be working properly now. 

Thanks folks,

Doug
___
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: armv6 specific std::async crash from g++6 built a.out [stable/11 -r304943 context; /usr/ports -r421001 context]

2016-09-01 Thread Mark Millard 
Another top post because I should have kept going with the reductions: the 
following ~10 line program also shows the SIGSEGV behavior on armv6 (an rpi2) 
for running ./a.out after compiling via g++6.

> # more g++6_build_crashes.cpp 
>   
> #include// 
> future, async, launch::async
>  
> static void f() {}
>  
> int main(int, const char* [])
> {
> auto a0{ std::async( std::launch::async, f ) };
> a0.get();
> return 0;
> }

It only takes one std::async use to have the problem. So far the above (and the 
earlier variants) always crash with SIGSEGV on the rpi2 when the g++6 compiler 
is used.

As for the compile commands used:

> g++6 -g -v -std=c++14 -Wpedantic -Wall -O2 -pthread 
> -Wl,-rpath=/usr/local/lib/gcc6 -mcpu=cortex-a7 g++6_build_crashes.cpp


Omitting the -mcpu=cortex-a7 still get the problem.

Using -O0 instead of -O2 still gets the problem.

But I'll note that my stable/11 -r304943 build and my ports builds (usr/ports 
-r421001 vintage) were/are based on using -mcpu=cortex-a7 . Also the system 
clang 3.8.0 was used to build g++6:

> GNU C++14 (FreeBSD Ports Collection) version 6.2.0 (armv6-portbld-freebsd11.0)
> compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 
> (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.4-p1, 
> MPC version 1.0.3, isl version none

> # more /etc/make.conf 
> DEFAULT_VERSIONS+=perl5=5.22
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> MALLOC_PRODUCTION=
> #
> #system clang 3.8 (gcc6 rejects -march=armv7a):
> #CFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #CXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #CPPFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #
> #lang/gcc6's xgcc stage considers the above conflicting so use just:
> CFLAGS+= -mcpu=cortex-a7
> CXXFLAGS+= -mcpu=cortex-a7
> CPPFLAGS+= -mcpu=cortex-a7


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

On 2016-Sep-1, at 4:09 PM, Mark Millard  wrote:

> This is a top post of an even shorter variant (~14 lines) that gives little 
> hint of the original program structure but shows the SIGSEGV behavior:
> 
>> # more g++6_build_crashes.cpp
>>  
>>   
>> #include// future, async, launch::async
>> 
>> static void f() {}
>> 
>> int main(int, const char* [])
>> {
>>auto a0{ std::async( std::launch::async, f ) };
>>auto a1{ std::async( std::launch::async, f ) };
>> 
>>a0.get();
>>a1.get();
>> 
>>return 0;
>> }
> 
> 
> The backtraces of the 3 threads look like:
> 
>> (gdb) info threads
>>  Id   Target Id Frame 
>>  1LWP 100265 of process 13188 0x in ?? ()
>> * 2LWP 100269 of process 13188 0x in ?? ()
>>  3LWP 100270 of process 13188 thread_start (curthread=0x20812600) at 
>> /usr/src/lib/libthr/thread/thr_create.c:253
> 
>> (gdb) thread 1
>> [Switching to thread 1 (LWP 100265 of process 13188)]
>> #0  0x in ?? ()
>> (gdb) bt
>> #0  0x in ?? ()
>> #1  0x200b1acc in _pthread_once (once_control=, 
>> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
>> #2  0x00011d1c in __gthread_once (__func=, __once=0x20824030) 
>> at 
>> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
>> #3  std::call_once(std::once_flag&, 
>> void (std::thread::*&&)(), std::thread*&&) (__f=, __once=...) 
>> at /usr/local/lib/gcc6/include/c++/mutex:619
>> #4  std::__future_base::_Async_state_commonV2::_M_join (this=0x2082400c) at 
>> /usr/local/lib/gcc6/include/c++/future:1644
>> #5  std::__future_base::_Async_state_commonV2::_M_complete_async 
>> (this=0x2082400c) at /usr/local/lib/gcc6/include/c++/future:1642
>> #6  0x00012d4c in std::__future_base::_State_baseV2::wait (this=0x2082400c) 
>> at /usr/local/lib/gcc6/include/c++/future:325
>> #7  std::__basic_future::_M_get_result (this=0xbfbfed38) at 
>> /usr/local/lib/gcc6/include/c++/future:687
>> #8  std::future::get (this=this@entry=0xbfbfed38) at 
>> /usr/local/lib/gcc6/include/c++/future:852
>> #9  0x000115a4 in main () at g++6_build_crashes.cpp:10
> 
>> (gdb) thread 2
>> [Switching to thread 2 (LWP 100269 of process 13188)]
>> #0  0x in ?? ()
>> (gdb) bt
>> #0  0x in ?? ()
>> #1  0x200b1acc in _pthread_once (once_control=, 
>> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
>> #2  0x00012960 in __gthread_once (__func=, __once=0x20824024) 
>> at 
>> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
>> #3  std::call_once> (std::__future_base::_State_baseV2::*)(std::function>  std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_b
>> ase::_State_baseV2*, 
>>

Re: armv6 specific std::async crash from g++6 built a.out [stable/11 -r304943 context; /usr/ports -r421001 context]

2016-09-01 Thread Mark Millard 
This is a top post of an even shorter variant (~14 lines) that gives little 
hint of the original program structure but shows the SIGSEGV behavior:

> # more g++6_build_crashes.cpp 
>   
> 
> #include// future, async, launch::async
>  
> static void f() {}
>  
> int main(int, const char* [])
> {
> auto a0{ std::async( std::launch::async, f ) };
> auto a1{ std::async( std::launch::async, f ) };
>  
> a0.get();
> a1.get();
>  
> return 0;
> }


The backtraces of the 3 threads look like:

> (gdb) info threads
>   Id   Target Id Frame 
>   1LWP 100265 of process 13188 0x in ?? ()
> * 2LWP 100269 of process 13188 0x in ?? ()
>   3LWP 100270 of process 13188 thread_start (curthread=0x20812600) at 
> /usr/src/lib/libthr/thread/thr_create.c:253

> (gdb) thread 1
> [Switching to thread 1 (LWP 100265 of process 13188)]
> #0  0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0x200b1acc in _pthread_once (once_control=, 
> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
> #2  0x00011d1c in __gthread_once (__func=, __once=0x20824030) 
> at 
> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
> #3  std::call_once(std::once_flag&, 
> void (std::thread::*&&)(), std::thread*&&) (__f=, __once=...) 
> at /usr/local/lib/gcc6/include/c++/mutex:619
> #4  std::__future_base::_Async_state_commonV2::_M_join (this=0x2082400c) at 
> /usr/local/lib/gcc6/include/c++/future:1644
> #5  std::__future_base::_Async_state_commonV2::_M_complete_async 
> (this=0x2082400c) at /usr/local/lib/gcc6/include/c++/future:1642
> #6  0x00012d4c in std::__future_base::_State_baseV2::wait (this=0x2082400c) 
> at /usr/local/lib/gcc6/include/c++/future:325
> #7  std::__basic_future::_M_get_result (this=0xbfbfed38) at 
> /usr/local/lib/gcc6/include/c++/future:687
> #8  std::future::get (this=this@entry=0xbfbfed38) at 
> /usr/local/lib/gcc6/include/c++/future:852
> #9  0x000115a4 in main () at g++6_build_crashes.cpp:10

> (gdb) thread 2
> [Switching to thread 2 (LWP 100269 of process 13188)]
> #0  0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0x200b1acc in _pthread_once (once_control=, 
> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
> #2  0x00012960 in __gthread_once (__func=, __once=0x20824024) 
> at 
> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
> #3  std::call_once (std::__future_base::_State_baseV2::*)(std::function  std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_b
> ase::_State_baseV2*, 
> std::function std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, 
> void (std::__future_base::_State_baseV2::
> *&&)(std::function std::__future_base::_Result_base::_Deleter> ()>*, bool*), 
> std::__future_base::_State_baseV2*&&, std::function 
> ()>*&&, bool*&&) (__f=, __once=...) at 
> /usr/local/lib/gcc6/include/c++/mutex:619
> #4  
> std::__future_base::_State_baseV2::_M_set_result(std::function  std::__future_base::_Result_base::_Deleter> ()>, bool) 
> (__ignore_failure=false, 
> __res=..., this=0x2082400c) at /usr/local/lib/gcc6/include/c++/future:393
> #5  std::__future_base::_Async_state_impl void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1}::operator()() const (__closure=0x2082500c)
> at /usr/local/lib/gcc6/include/c++/future:1664
> #6  
> std::_Bind_simple, void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1} ()>::_M_invoke<>(std::_Index_tupl
> e<>) (this=0x2082500c) at /usr/local/lib/gcc6/include/c++/functional:1400
> #7  
> std::_Bind_simple, void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1} ()>::operator()() (
> this=0x2082500c) at /usr/local/lib/gcc6/include/c++/functional:1389
> #8  
> std::thread::_State_impl, void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1} ()> >::_
> M_run() (this=0x20825008) at /usr/local/lib/gcc6/include/c++/thread:196
> #9  0x201ac464 in std::execute_native_thread_routine (__p=0x20825008) at 
> /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libstdc++-v3/src/c++11/thread.cc:83
> #10 0x200a8fd4 in thread_start (curthread=) at 
> /usr/src/lib/libthr/thread/thr_create.c:289
> #11 0x200a8a90 in _pthread_create

Re: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Matthias Fechner 
Am 01.09.2016 um 20:11 schrieb Kurt Jaeger:
> Yes, please attach that diff to the PR.

ok, here we go:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212313
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201455

The index data will be stored in /var/db/solr

Log file will go to /var/log/solr

Solr is running now as user solr and not as root anymore.

All other files are in /usr/local/solr.

Any comment is welcome.


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

___
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: mariadb10* ports broken on 9.x since last commit

2016-09-01 Thread Konstantin Belousov 
On Thu, Sep 01, 2016 at 10:50:18PM +0200, Dimitry Andric wrote:
> I don't know.  I understood from Kostik that it would need r232832, but
> apparently this breaks the ABI?
Yes, kind of.  I considered it not appropriate to change the interaction
between csu and rtld for long-lived stable branch.  Also, it might cause
problems for other language translators which provide their own runtimes.

That were the reasonings several years ago, when initializers were reworked,
and definitely I do not want to disturb the branch near EOL.
> 
> It is probably easier to work around this by configuring the binutils
> port so it does not emit .init_array/.fini_array sections.
It was already done in ports r421193.

> 
> -Dimitry
> 
> [1] https://svnweb.freebsd.org/base?view=revision=232832
> 


___
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: codecvt and libc++ on FreeBSD 9.x

2016-09-01 Thread Dimitry Andric 
On 01 Sep 2016, at 20:39, Ben Lavery  wrote:
...
> In file included from /root/bunnysay/work/bunnysay-1.0/src/BunnySay.cpp:22:0:
> /root/bunnysay/work/bunnysay-1.0/src/BunnySay.h:33:19: fatal error: codecvt: 
> No such file or directory
> #include 
...
> On the submission (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212278) 
> CPM has said of the issue "Second it seems that codecvt is missing, so it 
> needs libc++ support" - but I'm not sure how to add this.  I've tried adding 
> the following which I found in multiple threads on the forums, but to no 
> avail:
> 
> CC=clang
> CXX=clang++
> CPP=clang-cpp
> WITH_LIBCPLUSPLUS=yes

Putting this in your make.conf, then rebuilding world and installing it,
will install libc++ headers and libraries into your base system.  That
is step one.

Step two is to add -stdlib=libc++ to your clang command line.  On 9.x
and earlier, clang uses libstdc++ by default, so you have to actively
tell it to use libc++.


> I *think* this is because clang is too old on FreeBSD 9.3?

FreeBSD 9.3 has clang 3.4.1, which should be new enough, but libc++ is
not installed by default.

> But I'm not sure if I can/should reference a newer version from ports (and 
> how to go about this in the proper way), and how to make this apply to 
> FreeBSD 9.x only as it works fine "as is" on FreeBSD 10.

You could make it depend on the devel/libc++ port, as some other ports
do.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: mariadb10* ports broken on 9.x since last commit

2016-09-01 Thread Dimitry Andric 
On 01 Sep 2016, at 20:37, Bernard Spil  wrote:
> 
> On 2016-09-01 11:07, Dimitry Andric wrote:
> > On 31 Aug 2016, at 19:03, Doug Barton  wrote:
...
> > Bisecting showed this was introduced in binutils commit 26e3a0c [1],
> > which turns on .init_array/.fini_array support by default.  It makes
> > most C++ executables crash at startup, on 9.x, since support for this
> > was not fully merged back to stable/9.
> >
> > I think Baptiste is working on a fix.  It is probably best to configure
> > binutils on 9.x with --disable-initfini-array.
...
> Thanks for the explanation. I thought that it was fixed from your
> earlier mail.

Eh, which one?


> So it is still broken at runtime on 9.x...
> 
> Is there a PR on bugs.freebsd.org already documenting this?

I don't know.  I understood from Kostik that it would need r232832, but
apparently this breaks the ABI?

It is probably easier to work around this by configuring the binutils
port so it does not emit .init_array/.fini_array sections.

-Dimitry

[1] https://svnweb.freebsd.org/base?view=revision=232832



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: codecvt and libc++ on FreeBSD 9.x

2016-09-01 Thread Ben Lavery 

On 09/01/16 20:59, Michelle Sullivan wrote:

Ben Lavery wrote:



On the submission
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212278) CPM has
said of the issue "Second it seems that codecvt is missing, so it
needs libc++ support" - but I'm not sure how to add this.  I've tried
adding the following which I found in multiple threads on the forums,
but to no avail:

CC=clang
CXX=clang++
CPP=clang-cpp
WITH_LIBCPLUSPLUS=yes

I *think* this is because clang is too old on FreeBSD 9.3?  But I'm
not sure if I can/should reference a newer version from ports (and how
to go about this in the proper way), and how to make this apply to
FreeBSD 9.x only as it works fine "as is" on FreeBSD 10.


Did you go with the base compiler or use the clang in ports?

You might want to do that - you can also probably use GCC which is also
available in ports.

Regards,

Michelle


Yes I did am using the base compiler, I know I can do a "BUILD_DEPENDS" 
to ensure a port (e.g. lang/clang35 would do, I think) is available at 
build time, but I'm unsure:

a) if that will indeed solve my issue
b) how to ensure this doesn't affect FreeBSD 10 and above builds - if 
there some kind of ".if FreeBSd 9"?
c) how to ensure cmake uses the ports version of clang rather than base 
- would I modify the variables I mentioned in my original post?


Many thanks,
Ben

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

codecvt and libc++ on FreeBSD 9.x

2016-09-01 Thread Ben Lavery 

Good evening all,

Fairly new to porting and I've tried porting what I thought would be a 
trivial program, bunnysay.  Written in C++ I've patched the code to work 
on FreeBSD 10, however it doesn't work on FreeBSD 9 because I've 
included codecvt.


It fails with the following error and I'm feeling a little out of my depth:

===>  Building for bunnysay-1.0
[ 50%] Building CXX object CMakeFiles/bunnysay.dir/src/BunnySay.cpp.o
In file included from 
/root/bunnysay/work/bunnysay-1.0/src/BunnySay.cpp:22:0:
/root/bunnysay/work/bunnysay-1.0/src/BunnySay.h:33:19: fatal error: 
codecvt: No such file or directory

 #include 
   ^
compilation terminated.
*** [CMakeFiles/bunnysay.dir/src/BunnySay.cpp.o] Error code 1
1 error
*** [CMakeFiles/bunnysay.dir/all] Error code 2
1 error
*** [all] Error code 2
1 error
*** [do-build] Error code 2

Stop in /root/bunnysay.



On the submission 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212278) CPM has said 
of the issue "Second it seems that codecvt is missing, so it needs 
libc++ support" - but I'm not sure how to add this.  I've tried adding 
the following which I found in multiple threads on the forums, but to no 
avail:


CC=clang
CXX=clang++
CPP=clang-cpp
WITH_LIBCPLUSPLUS=yes

I *think* this is because clang is too old on FreeBSD 9.3?  But I'm not 
sure if I can/should reference a newer version from ports (and how to go 
about this in the proper way), and how to make this apply to FreeBSD 9.x 
only as it works fine "as is" on FreeBSD 10.


Many thanks for any advice and words of wisdom.

Ben

___
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: mariadb10* ports broken on 9.x since last commit

2016-09-01 Thread Bernard Spil 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2016-09-01 11:07, Dimitry Andric wrote:
> On 31 Aug 2016, at 19:03, Doug Barton  wrote:
>> 
>> August 31, 2016 12:37 AM, "Bernard Spil"  wrote:
>>> On 2016-08-30 17:45, Doug Barton wrote:
>>> 
 Since the last commit to the mariadb10* ports the resulting binaries
 dump core on 9.3-RELEASE-p43, even for a simple --help option. I am
 assuming that is not the intended result 
 Doug
>>> 
>>> Hi Doug,
>>> 
>>> Nope, that is not intended. Assume this is the 10.0.27 update? I did build 
>>> them on 9.3 but have not
>>> checked the resulting binaries... Will need some time to investigate!
>>> 
>>> https://brnrd.eu/poudriere/build.html?mastername=93amd64-svn=2016-08-29_20h14m28s
>> 
>> Thanks Bernard.
>> 
>> It turns out that the actual problem was binutils. I backed up several 
>> revisions of mariadb, past the previous working version, and had the same 
>> symptoms. Then I started on the deps that had changed at the same time, and 
>> fortunately I guessed right on the first one.
>> 
>> Backing up to -r{2016-08-25} on binutils got mariadb working with the latest 
>> version.
> 
> Bisecting showed this was introduced in binutils commit 26e3a0c [1],
> which turns on .init_array/.fini_array support by default.  It makes
> most C++ executables crash at startup, on 9.x, since support for this
> was not fully merged back to stable/9.
> 
> I think Baptiste is working on a fix.  It is probably best to configure
> binutils on 9.x with --disable-initfini-array.
> 
> -Dimitry
> 
> [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=26e3a0c9ba4a8376fdf9f898637919d144d8b1d8

Hi Dimitry,

Thanks for the explanation. I thought that it was fixed from your
earlier mail. So it is still broken at runtime on 9.x...

Is there a PR on bugs.freebsd.org already documenting this?

Thanks!

Bernard.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJXyHVqAAoJEHT7/r+FArC0UpcP/3widk9T8lhFl2u875b5Mx+g
FM2ByY20fZGtoU7PDq3iTdFV0TIkiZJvtXb/Ez3Fc01yYpotjnbBJk6eGXOfNNLc
K+4fboQVd8oQvUbc5GU4j5ebdguLNl0xHldmq2rdFtMbHDSKmn23yqnOt9Uan/kS
TxesugnKDZ5zrJJ6J3XEYmskwJY4e8RaT86O8DPqcLzJ8nEdYGxxMuGL0/4ZOww0
bVoMlSJt7EH8DTZlqUCv/iyD9BSIR0mXVhG0CkiOOxIOiIiUve3h0Ex6bio30CR+
+PdXjrYuJK+yDFaipjAiKv3em4IxQOwL6l/vYex7zknwLHdN4ClWNcmXbGCdLfoG
a4Xxm4038kABjFHnUkpgZTtkTas5tGP6xQkMe0bkenr2zw9+yJlYbkwdknbDaL4h
4DeQ5uCFx1I+x/ml71545u4RrxLFXdHPyuDNrZC3I1IxIPRohsJEemaFn5ogdLHg
NF2GxAUQIkSZfdtSoYU5QhhhwniCj7hCjoUtlQwrCpf1yUSe8nxWzkgKlypmvgdM
3FQ0xxxu7OlHduGD2+WMeX2VRIoZu93Jw0Ze4jFUXy1qV8SofzH0bC2D7nDaUMbl
y3a7Aw1NBMgUL9kjiUpPkCap10onyEiT/1xl9oFtt3mvqLsWKJKr879tH+R6LcRF
2GbB0nEoJEHRBqsDPMeb
=jG6O
-END PGP SIGNATURE-
___
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: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Kurt Jaeger 
Hi!

> Am 01.09.2016 um 17:28 schrieb Matthias Fechner:
> > I started with the port and have it running.
> > The current version can be found here:
> > https://github.com/idefix6/freebsd-apache-solr/tree/6.2.0
> >
> 
> I have now an updated version ready.
> I can start, stop and status the running solr installation with server
> solr start|stop|status.
> 
> 
> I have now an instance running and have a drupal site connected to solr.
> Everything work perfectly fine.
> 
> If it is fine, I would create a diff and would attach it to PR 201455.

Yes, please attach that diff to the PR.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Matthias Fechner 
Am 01.09.2016 um 19:08 schrieb Matthias Fechner:
> If it is fine, I would create a diff and would attach it to PR 201455. 

the poudiere build log is here:
https://pkg.fechner.net/data/103amd64-default/2016-09-01_19h00m20s/logs/apache-solr-6.2.0.log


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

___
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: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Matthias Fechner 
Am 01.09.2016 um 17:28 schrieb Matthias Fechner:
> I started with the port and have it running.
> The current version can be found here:
> https://github.com/idefix6/freebsd-apache-solr/tree/6.2.0
>

I have now an updated version ready.
I can start, stop and status the running solr installation with server
solr start|stop|status.


I have now an instance running and have a drupal site connected to solr.
Everything work perfectly fine.


If it is fine, I would create a diff and would attach it to PR 201455.

Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

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

Need help debugging rc script

2016-09-01 Thread Ultima 
 Hello, I'm dealing with an odd issue with an rc script working pre-11. The
change that is causing the prog to fail seems to be the new limits feature,
$name_login_class. After commenting out the limits command in rc.subr, the
script starts as expected. Adding limits directly in the rc script with the
daemon class will also start the script as expected (with limits commented
out in rc.subr). For some reason that I cannot fathom it will just not
start correctly with limits in rc.subr.

 So as the topic suggests, are they're better way to debug this? I'll also
provide the scripts used in case someone may see something I'v missed. The
jail is running on current, however this exists in 11 as well.

12.0-CURRENT FreeBSD 12.0-CURRENT #21 r304105
audio/teamspeak3-server

# cat /usr/local/etc/rc.d/teamspeak
#!/bin/sh

# $FreeBSD$
#
# PROVIDE: teamspeak
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# teamspeak_enable (bool):   Set to NO by default.
#   Set it to YES to enable teamspeak server.
#

. /etc/rc.subr

name="teamspeak"
rcvar=teamspeak_enable

db_dir=/var/db/teamspeak
log_dir=/var/log/teamspeak

pidfile=/var/db/teamspeak/teamspeak_server.pid
procname=/usr/local/libexec/ts3server
command=/usr/sbin/daemon
command_args="-fp $pidfile -u teamspeak /usr/local/libexec/ts3server
dbsqlpath=/usr/local/share/teamspeak/server/sql/
inifile=/usr/local/etc/teamspeak/ts3server.ini
licensepath=/usr/local/etc/teamspeak/ logpath=$log_dir"
teamspeak_chdir=$db_dir
required_dirs="$db_dir $log_dir"

load_rc_config $name

: ${teamspeak_enable="NO"}

LD_LIBRARY_PATH=/usr/local/lib/teamspeak/server:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

run_rc_command "$1"



This script causes an error,
2016-09-01 16:53:09.510292|ERROR   |DatabaseQuery |   |db_connect() failed
unable to open database file
2016-09-01 16:53:09.510352|CRITICAL|ServerLibPriv |   |Server()
DatabaseError out of memory


Commenting line 1075 in /etc/rc.subr, the program starts successfully

Keeping line 1075 commented, change rc script to this.

# cat /usr/local/etc/rc.d/teamspeak
#!/bin/sh

# $FreeBSD$
#
# PROVIDE: teamspeak
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# teamspeak_enable (bool):   Set to NO by default.
#   Set it to YES to enable teamspeak server.
#

. /etc/rc.subr

name="teamspeak"
rcvar=teamspeak_enable

db_dir=/var/db/teamspeak
log_dir=/var/log/teamspeak

pidfile=/var/db/teamspeak/teamspeak_server.pid
procname=/usr/local/libexec/ts3server
command=/usr/bin/limits
command_args="-C daemon /usr/sbin/daemon -fp $pidfile -u teamspeak
/usr/local/libexec/ts3server
dbsqlpath=/usr/local/share/teamspeak/server/sql/
inifile=/usr/local/etc/teamspeak/ts3server.ini
licensepath=/usr/local/etc/teamspeak/ logpath=$log_dir"
teamspeak_chdir=$db_dir
required_dirs="$db_dir $log_dir"

load_rc_config $name

: ${teamspeak_enable="NO"}

LD_LIBRARY_PATH=/usr/local/lib/teamspeak/server:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

run_rc_command "$1"


This is also start successfully.
___
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: nano-2.4.3

2016-09-01 Thread Danilo Egêa Gondolfo 
On 09/01/2016 12:49 PM, Dutchman01 wrote:

> Hi, thanks for good work!
>
>  
>
> Can you please upgrade this port to newer release 2.7.0?
>
> It has some fixes.
>
>  
>
> Regards,
>
> Dutchman
>
I will. Thank you!
___
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: nano-2.4.3

2016-09-01 Thread Dutchman01 
Hi, thanks for good work!

 

Can you please upgrade this port to newer release 2.7.0?

It has some fixes.

 

Regards,

Dutchman

___
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: armv6 specific std::async crash from g++6 built a.out [stable/11 -r304943 context; /usr/ports -r421001 context]

2016-09-01 Thread Mark Millard 
On 2016-Sep-1, at 7:46 AM, Mark Millard  wrote:

> [I've only compared armv6 and amd64 behavior for this. amd64 did not get the 
> problem.]
> 
> The program is under 40 lines and is shown below:
> (It is a simplification of the context of the original discovery.)
> 
>> # more g++6_build_crashes.cpp 
>> #include// vector
>> #include// future, async, launch::async
>> #include// thread::hardware_concurrency
>> 
>> decltype(std::thread::hardware_concurrency()) static parallel_count{0u};
>> 
>> static void take_time_measurements() {}
>> 
>> int main(int, const char* [])
>> {
>>parallel_count = std::thread::hardware_concurrency();
>>// Do not presume more threads than this are possible.
>> 
>>if (1 < parallel_count)
>>{
>>--parallel_count; // leave room for main's thread.
>> 
>>std::vector parallels{};
>>parallels.reserve(parallel_count);
>> 
>>parallels.emplace_back
>>( std::async( std::launch::async, take_time_measurements ) );
>> 
>>parallels.emplace_back
>>( std::async( std::launch::async, take_time_measurements ) );
>> 
>>for (auto const& at : parallels)
>>{ at.wait(); }
>> 
>>for (auto& at : parallels)
>>{ at.get(); }
>>}
>>return 0;
>> }

The rpi2 gets 4==std::thread::hardware_concurrency().

So the typo in the if test is not involved: 2 < parallel_count should have been 
in place. Changing it does not change the observed rpi2 SIGSEGV behavior.

I'll note that it is the second std::async's call chain that gets the SIGSEGV.

> I do not know if the problem is a bad interaction between FreeBSD's -pthread 
> and g++6's library code vs. if this is strictly a g++6 library problem 
> somehow specific to armv6.
> 
> g++6 based builds run fine in my amd64 context (FreeBSD stable/11 under 
> VirtualBox under Mac OS X).
> 
> The clang++ 3.8.0 system compiler based build works fine on both amd64 and 
> armv6 (an rpi2).
> 
> Builds via g++6 on the rpi2 produce an a.out that fails as shown below 
> (SIGSEGV):
> 
>> # /usr/local/bin/gdb ./a.out
>> GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> License GPLv3+: 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.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "armv6-portbld-freebsd11.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from ./a.out...done.
>> (gdb) run
>> Starting program: /root/c_tests/a.out 
>> [New LWP 100255 of process 12266]
>> 
>> Thread 2 received signal SIGSEGV, Segmentation fault.
>> [Switching to LWP 100255 of process 12266]
>> 0x in ?? ()
>> (gdb) bt
>> #0  0x in ?? ()
>> #1  0x200b2acc in _pthread_once (once_control=, 
>> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
>> #2  0x0001312c in __gthread_once (__func=, __once=0x20824024) 
>> at 
>> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
>> #3  std::call_once> (std::__future_base::_State_baseV2::*)(std::function>  std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_b
>> ase::_State_baseV2*, 
>> std::function> std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, 
>> void (std::__future_base::_State_baseV2::
>> *&&)(std::function> std::__future_base::_Result_base::_Deleter> ()>*, bool*), 
>> std::__future_base::_State_baseV2*&&, std::function __future_base::_Result_base, std::__future_base::_Result_base::_Deleter> 
>> ()>*&&, bool*&&) (__f=, __once=...) at 
>> /usr/local/lib/gcc6/include/c++/mutex:619
>> #4  
>> std::__future_base::_State_baseV2::_M_set_result(std::function>  std::__future_base::_Result_base::_Deleter> ()>, bool) 
>> (__ignore_failure=false, 
>>__res=..., this=0x2082400c) at /usr/local/lib/gcc6/include/c++/future:393
>> #5  std::__future_base::_Async_state_impl> void>::_Async_state_impl(std::_Bind_simple> (*())()>&&)::{lambda()#1}::operator()() const (__closure=0x2082500c)
>>at /usr/local/lib/gcc6/include/c++/future:1664
>> #6  
>> std::_Bind_simple  (*())()>, void>::_Async_state_impl(std::_Bind_simple> (*())()>&&)::{lambda()#1}

Re: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Matthias Fechner 
Hi,

Am 01.09.2016 um 15:29 schrieb Kurt Jaeger:
> Yes, please. It was me who messed up that port, sorry for that.
> The startup and config is still messy, it does not look easy.
>

I started with the port and have it running.
The current version can be found here:
https://github.com/idefix6/freebsd-apache-solr/tree/6.2.0

Upstream was a lot changed and I'm not sure how to tackle this:

- directory structure was changed completely (currently I have
everything under /usr/local/solr which does not respect hier but for the
first step it should be fine)
- solr uses now its own startup script and I see no reason to write this
script again -> so I will use the bash script to start solr

I changed the current startup script that it can start a solr instance
without problems.
But the startup script does not return the PID and I'm not sure how to
handle, so stopping the solr instance via FreeBSD startup script is not
possible.

What is here best practise?


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook


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

armv6 specific std::async crash from g++6 built a.out [stable/11 -r304943 context; /usr/ports -r421001 context]

2016-09-01 Thread Mark Millard 
[I've only compared armv6 and amd64 behavior for this. amd64 did not get the 
problem.]

The program is under 40 lines and is shown below:
(It is a simplification of the context of the original discovery.)

> # more g++6_build_crashes.cpp 
> #include// vector
> #include// future, async, launch::async
> #include// thread::hardware_concurrency
>  
> decltype(std::thread::hardware_concurrency()) static parallel_count{0u};
>   
> static void take_time_measurements() {}
>  
> int main(int, const char* [])
> {
> parallel_count = std::thread::hardware_concurrency();
> // Do not presume more threads than this are possible.
> 
> if (1 < parallel_count)
> {
> --parallel_count; // leave room for main's thread.
>  
> std::vector parallels{};
> parallels.reserve(parallel_count);
>  
> parallels.emplace_back
> ( std::async( std::launch::async, take_time_measurements ) );
>  
> parallels.emplace_back
> ( std::async( std::launch::async, take_time_measurements ) );
>  
> for (auto const& at : parallels)
> { at.wait(); }
>  
> for (auto& at : parallels)
> { at.get(); }
> }
> return 0;
> }

I do not know if the problem is a bad interaction between FreeBSD's -pthread 
and g++6's library code vs. if this is strictly a g++6 library problem somehow 
specific to armv6.

g++6 based builds run fine in my amd64 context (FreeBSD stable/11 under 
VirtualBox under Mac OS X).

The clang++ 3.8.0 system compiler based build works fine on both amd64 and 
armv6 (an rpi2).

Builds via g++6 on the rpi2 produce an a.out that fails as shown below 
(SIGSEGV):

> # /usr/local/bin/gdb ./a.out
> GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: 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.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "armv6-portbld-freebsd11.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /root/c_tests/a.out 
> [New LWP 100255 of process 12266]
>  
> Thread 2 received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 100255 of process 12266]
> 0x in ?? ()
> (gdb) bt
> #0  0x in ?? ()
> #1  0x200b2acc in _pthread_once (once_control=, 
> init_routine=) at /usr/src/lib/libthr/thread/thr_once.c:95
> #2  0x0001312c in __gthread_once (__func=, __once=0x20824024) 
> at 
> /usr/local/lib/gcc6/include/c++/armv6-portbld-freebsd11.0/bits/gthr-default.h:699
> #3  std::call_once (std::__future_base::_State_baseV2::*)(std::function  std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_b
> ase::_State_baseV2*, 
> std::function std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, 
> void (std::__future_base::_State_baseV2::
> *&&)(std::function std::__future_base::_Result_base::_Deleter> ()>*, bool*), 
> std::__future_base::_State_baseV2*&&, std::function 
> ()>*&&, bool*&&) (__f=, __once=...) at 
> /usr/local/lib/gcc6/include/c++/mutex:619
> #4  
> std::__future_base::_State_baseV2::_M_set_result(std::function  std::__future_base::_Result_base::_Deleter> ()>, bool) 
> (__ignore_failure=false, 
> __res=..., this=0x2082400c) at /usr/local/lib/gcc6/include/c++/future:393
> #5  std::__future_base::_Async_state_impl void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1}::operator()() const (__closure=0x2082500c)
> at /usr/local/lib/gcc6/include/c++/future:1664
> #6  
> std::_Bind_simple, void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1} ()>::_M_invoke<>(std::_Index_tupl
> e<>) (this=0x2082500c) at /usr/local/lib/gcc6/include/c++/functional:1400
> #7  
> std::_Bind_simple, void>::_Async_state_impl(std::_Bind_simple (*())()>&&)::{lambda()#1} ()>::operator()() (
> this=0x2082500c) at /usr/local/lib/gcc6/include/c++/functional:1389
> #8  
>

Re: FreeBSD Port: noip-2.1.9_3

2016-09-01 Thread Marko Cupać 
On Wed, 31 Aug 2016 12:17:43 +0100
"James A. McGuire"  wrote:

> Hi there,
> 
> Since no-ip introduced their policy to remove non-updated subdomains
> every 30 days.  I have to manually go to the no-ip website and
> confirm that I wish to keep my subdomain.  I believe the reason for
> this is that my ISP is only updating my dynamic IP address every
> 60-90 days, and I believe that the no-ip client is therefore not
> sending updates to no-ip.

"Free Dynamic DNS hosts must be confirmed every 30 days or they will be
deleted. This policy helps keep our network free of unused hostnames.

To avoid your hostname going into pending deletion, you can do any of
the below:
 - Manually Confirm Your Hostname (...) Simply login to your
   No-IP account and click Dynamic DNS on the left navigation. Next,
   click Confirm next to the hostname you would like to confirm (...)
 - Upgrade to Enhanced Dynamic DNS or Plus Managed DNS"

http://www.noip.com/support/knowledgebase/why-is-my-hostname-pending-deletion/

As far as I'm aware, confirmation has nothing to do with IP updates.
One of my .noip.me hosts changes IP address on an hourly basis, yet I
still have to click confirmation link every 30 days in order to keep it
active.

Regards,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
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: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Kurt Jaeger 
Hi!

> Am 31.08.2016 um 12:38 schrieb Matthias Fechner:
> > As the new version was broken, I installed the old 4.x version and
> > locked the package.
> >
> > I just downloaded manually the 6.2 version into /usr/local/src and
> > started it from there (it works perfectly fine after defining the
> > JAVA_HOME=/usr/local/openjdk8/jre/).
> > Today I have a little time to look into this issue and upgraded to
> > version 5.5.2 which is now in ports.

> if it is ok, I would create a patch file to correct this port (doing
> also an update to version 6.2 in this step)

Yes, please. It was me who messed up that port, sorry for that.

The startup and config is still messy, it does not look easy.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: apache-solr PR: 201455 (I think 212104 blocks usage of apache-solr)

2016-09-01 Thread Matthias Fechner 
Am 31.08.2016 um 12:38 schrieb Matthias Fechner:
> As the new version was broken, I installed the old 4.x version and
> locked the package.
>
> I just downloaded manually the 6.2 version into /usr/local/src and
> started it from there (it works perfectly fine after defining the
> JAVA_HOME=/usr/local/openjdk8/jre/).
> Today I have a little time to look into this issue and upgraded to
> version 5.5.2 which is now in ports.
>

if it is ok, I would create a patch file to correct this port (doing
also an update to version 6.2 in this step)


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

___
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: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

2016-09-01 Thread Rainer Hurling 
Am 01.09.2016 um 13:17 schrieb Mathieu Arnold:
> Le 01/09/2016 à 12:29, Konstantin Belousov a écrit :
>> On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
>>> I am the maintainer of databases/postgis-jdbc. For some days now I get
>>> mails like to one further down, for HEAD i386 and HEAD amd64.
>>>
>>> The FreeBSD package build server complains about a problem with untaring
>>> the jar distfile.
>>>
>>> This worked fine before, and as far as I can see, the distfile is ok. On
>>> Windows, I am also able to open the jar distfile and use it.
>>>
>>> I think, the port and the distfile are ok, and there is something odd
>>> with base tar, used by the port system.
>>>
>>> Any idea, what's going on here?
>>>
>>> Thanks for any help in advance.
>> Probably related to the libarchive updates, in particular r304869,
>> r304988, r304989.
>>
>> But I am not sure which version of the userspace the poudriere jail runs.
>> I see mention of r305036, which might be userspace, but also might be
>> just the kernel version.
> 
> On the package cluster, the pkgproduce script will always update a jail
> before building from it, for the releases, it does so using
> freebsd-update, for HEAD, it will rebuild the whole jail.  So if it says
> r305036, it is using that :-)
> The host, itself, is updated about once a month, at the same revision
> the rest of the cluster is, unless someone breaks the KBI, in which case
> it is updated early :-)
> 
> Right now, the box running the HEAD amd64 builds' host is running
> r304967 and the jail is "12.0-CURRENT r305036".
> 

Thanks for the clarification. I read this a little bit to late, so
answered kib@ a minute before ...
___
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: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

2016-09-01 Thread Rainer Hurling 
Am 01.09.2016 um 12:29 schrieb Konstantin Belousov:
> On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
>> I am the maintainer of databases/postgis-jdbc. For some days now I get
>> mails like to one further down, for HEAD i386 and HEAD amd64.
>>
>> The FreeBSD package build server complains about a problem with untaring
>> the jar distfile.
>>
>> This worked fine before, and as far as I can see, the distfile is ok. On
>> Windows, I am also able to open the jar distfile and use it.
>>
>> I think, the port and the distfile are ok, and there is something odd
>> with base tar, used by the port system.
>>
>> Any idea, what's going on here?
>>
>> Thanks for any help in advance.
> Probably related to the libarchive updates, in particular r304869,
> r304988, r304989.
> 
> But I am not sure which version of the userspace the poudriere jail runs.
> I see mention of r305036, which might be userspace, but also might be
> just the kernel version.

Thanks for the answer, really appreciated!

I investigated a little bit more on the ports side and it turns out,
that adding USES=zip:infozip should do the trick :)

Now I am testing in poudriere, if there would be any side effects with
my patch to databases/postgis-jdbc ...

Nevertheless, it is likely that we found an edge condition for the
libarchive updates in r304989.

BTW: I did not understand, why r305036 is relevant here?

> 
>>
>> Regards,
>> Rainer Hurling
>>
>>
>>  Weitergeleitete Nachricht 
>> Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
>> for postgis-jdbc-2.1.7 in extract
>> Datum: Thu, 1 Sep 2016 09:11:11 +
>> Von: pkg-fall...@freebsd.org
>> An: rhur...@gwdg.de
>> Kopie (CC): pkg-fall...@freebsd.org
>>
>> You are receiving this mail as a port that you maintain
>> is failing to build on the FreeBSD package build server.
>> Please investigate the failure and submit a PR to fix
>> build.
>>
>> Maintainer: rhur...@gwdg.de
>> Last committer: m...@freebsd.org
>> Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
>> 2016-04-01 14:00:51Z mat $
>> Log URL:
>> http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
>> Build URL:
>> http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
>> Log:
>>
>> >> Building databases/postgis-jdbc
>> build started at Thu Sep  1 09:11:08 UTC 2016
>> port directory: /usr/ports/databases/postgis-jdbc
>> building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
>> 12.0-CURRENT r305036 amd64
>> maintained by: rhur...@gwdg.de
>> Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
>> 412346 2016-04-01 14:00:51Z mat $
>> Poudriere version: 3.1.14
>> Host OSVERSION: 125
>> Jail OSVERSION: 125
>>
>> ---Begin Environment---
>> SHELL=/bin/csh
>> UNAME_v=FreeBSD 12.0-CURRENT r305036
>> UNAME_r=12.0-CURRENT
>> BLOCKSIZE=K
>> MAIL=/var/mail/root
>> STATUS=1
>> OPSYS=FreeBSD
>> ARCH=amd64
>> SAVED_TERM=
>> MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
>> UID=0
>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
>> _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
>> POUDRIERE_BUILD_TYPE=bulk
>> PKGNAME=postgis-jdbc-2.1.7
>> OSREL=12.0
>> _OSRELEASE=12.0-CURRENT
>> PYTHONBASE=/usr/local
>> OLDPWD=/
>> _SMP_CPUS=24
>> PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
>> HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
>> MASTERNAME=head-amd64-default
>> SCRIPTPREFIX=/usr/local/share/poudriere
>> _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
>> USER=root
>> HOME=/root
>> POUDRIERE_VERSION=3.1.14
>> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
>> CONFIGURE_MAX_CMD_LEN=262144
>> LIBEXECPREFIX=/usr/local/libexec/poudriere
>> LOCALBASE=/usr/local
>> PACKAGE_BUILDING=yes
>> _JAVA_OS_LIST_REGEXP=native\|linux
>> OSVERSION=125
>> ---End Environment---
>>
>> ---Begin OPTIONS List---
>> ---End OPTIONS List---
>>
>> --CONFIGURE_ARGS--
>>
>> --End CONFIGURE_ARGS--
>>
>> --CONFIGURE_ENV--
>> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
>> SHELL=/bin/sh CONFIG_SHELL=/bin/sh
>> --End CONFIGURE_ENV--
>>
>> --MAKE_ENV--
>> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
>> NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
>> NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
>> CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
>> CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
>> CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
>> MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
>> BSD_INSTALL_LIB="install  -s -m

Re: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

2016-09-01 Thread Mathieu Arnold 
Le 01/09/2016 à 12:29, Konstantin Belousov a écrit :
> On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
>> I am the maintainer of databases/postgis-jdbc. For some days now I get
>> mails like to one further down, for HEAD i386 and HEAD amd64.
>>
>> The FreeBSD package build server complains about a problem with untaring
>> the jar distfile.
>>
>> This worked fine before, and as far as I can see, the distfile is ok. On
>> Windows, I am also able to open the jar distfile and use it.
>>
>> I think, the port and the distfile are ok, and there is something odd
>> with base tar, used by the port system.
>>
>> Any idea, what's going on here?
>>
>> Thanks for any help in advance.
> Probably related to the libarchive updates, in particular r304869,
> r304988, r304989.
>
> But I am not sure which version of the userspace the poudriere jail runs.
> I see mention of r305036, which might be userspace, but also might be
> just the kernel version.

On the package cluster, the pkgproduce script will always update a jail
before building from it, for the releases, it does so using
freebsd-update, for HEAD, it will rebuild the whole jail.  So if it says
r305036, it is using that :-)
The host, itself, is updated about once a month, at the same revision
the rest of the cluster is, unless someone breaks the KBI, in which case
it is updated early :-)

Right now, the box running the HEAD amd64 builds' host is running
r304967 and the jail is "12.0-CURRENT r305036".

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

2016-09-01 Thread Konstantin Belousov 
On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
> I am the maintainer of databases/postgis-jdbc. For some days now I get
> mails like to one further down, for HEAD i386 and HEAD amd64.
> 
> The FreeBSD package build server complains about a problem with untaring
> the jar distfile.
> 
> This worked fine before, and as far as I can see, the distfile is ok. On
> Windows, I am also able to open the jar distfile and use it.
> 
> I think, the port and the distfile are ok, and there is something odd
> with base tar, used by the port system.
> 
> Any idea, what's going on here?
> 
> Thanks for any help in advance.
Probably related to the libarchive updates, in particular r304869,
r304988, r304989.

But I am not sure which version of the userspace the poudriere jail runs.
I see mention of r305036, which might be userspace, but also might be
just the kernel version.

> 
> Regards,
> Rainer Hurling
> 
> 
>  Weitergeleitete Nachricht 
> Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
> for postgis-jdbc-2.1.7 in extract
> Datum: Thu, 1 Sep 2016 09:11:11 +
> Von: pkg-fall...@freebsd.org
> An: rhur...@gwdg.de
> Kopie (CC): pkg-fall...@freebsd.org
> 
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
> 
> Maintainer: rhur...@gwdg.de
> Last committer: m...@freebsd.org
> Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
> 2016-04-01 14:00:51Z mat $
> Log URL:
> http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
> Build URL:
> http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
> Log:
> 
> >> Building databases/postgis-jdbc
> build started at Thu Sep  1 09:11:08 UTC 2016
> port directory: /usr/ports/databases/postgis-jdbc
> building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
> 12.0-CURRENT r305036 amd64
> maintained by: rhur...@gwdg.de
> Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
> 412346 2016-04-01 14:00:51Z mat $
> Poudriere version: 3.1.14
> Host OSVERSION: 125
> Jail OSVERSION: 125
> 
> ---Begin Environment---
> SHELL=/bin/csh
> UNAME_v=FreeBSD 12.0-CURRENT r305036
> UNAME_r=12.0-CURRENT
> BLOCKSIZE=K
> MAIL=/var/mail/root
> STATUS=1
> OPSYS=FreeBSD
> ARCH=amd64
> SAVED_TERM=
> MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
> UID=0
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
> _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
> POUDRIERE_BUILD_TYPE=bulk
> PKGNAME=postgis-jdbc-2.1.7
> OSREL=12.0
> _OSRELEASE=12.0-CURRENT
> PYTHONBASE=/usr/local
> OLDPWD=/
> _SMP_CPUS=24
> PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
> HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
> MASTERNAME=head-amd64-default
> SCRIPTPREFIX=/usr/local/share/poudriere
> _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
> USER=root
> HOME=/root
> POUDRIERE_VERSION=3.1.14
> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
> CONFIGURE_MAX_CMD_LEN=262144
> LIBEXECPREFIX=/usr/local/libexec/poudriere
> LOCALBASE=/usr/local
> PACKAGE_BUILDING=yes
> _JAVA_OS_LIST_REGEXP=native\|linux
> OSVERSION=125
> ---End Environment---
> 
> ---Begin OPTIONS List---
> ---End OPTIONS List---
> 
> --CONFIGURE_ARGS--
> 
> --End CONFIGURE_ARGS--
> 
> --CONFIGURE_ENV--
> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
> SHELL=/bin/sh CONFIG_SHELL=/bin/sh
> --End CONFIGURE_ENV--
> 
> --MAKE_ENV--
> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
> NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
> NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
> CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
> CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
> CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
> MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
> BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m
> 555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
> --End MAKE_ENV--
> 
> --PLIST_SUB--
> JAVASHAREDIR="share/java"
> JAVAJARDIR="share/java/classes"
> OSREL=12.0
> PREFIX=%D
> LOCALBASE=/usr/local
> RESETPREFIX=/usr/local
> PORTDOCS=""
> PORTEXAMPLES=""
> LIB32DIR=lib
> DOCSDIR="share/doc/postgis-jdbc"
> EXAMPLESDIR="share/examples/postgis-jdbc"
> DATADIR="share/postgis-jdbc"
> WWWDIR="www/postgis-jdbc"
> ETCDIR="etc/postgis-jdbc"
> --End PLIST_SUB--
> 
> --SUB_LIST--
> JAVASHAREDIR="/usr/local/share/java"
>

Re: Maintainership Status for PHP 5.6

2016-09-01 Thread Martin Waschbüsch 

> Am 31.08.2016 um 15:03 schrieb Torsten Zuehlsdorff 
> :
> 
> On 26.08.2016 21:38, Kurt Jaeger wrote:
>> Hi!
>> 
 About resetting the maintainer, I'll ask around.
>> 
>>> The rules are pretty clear:
>>> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html
>> 
>> It's more about: Who's willing to do it ?
> 
> As talked in private: i could/will do, since i already take over 
> maintainership for lang/php70.
> Currently creation of an php@ group is discussed (which should take over the 
> port than?).

Torsten,

once a php@ group exists, can you please add me to it? I'll be happy to 
contribute.

Thanks,

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

Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

2016-09-01 Thread Rainer Hurling 
I am the maintainer of databases/postgis-jdbc. For some days now I get
mails like to one further down, for HEAD i386 and HEAD amd64.

The FreeBSD package build server complains about a problem with untaring
the jar distfile.

This worked fine before, and as far as I can see, the distfile is ok. On
Windows, I am also able to open the jar distfile and use it.

I think, the port and the distfile are ok, and there is something odd
with base tar, used by the port system.

Any idea, what's going on here?

Thanks for any help in advance.

Regards,
Rainer Hurling


 Weitergeleitete Nachricht 
Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
for postgis-jdbc-2.1.7 in extract
Datum: Thu, 1 Sep 2016 09:11:11 +
Von: pkg-fall...@freebsd.org
An: rhur...@gwdg.de
Kopie (CC): pkg-fall...@freebsd.org

You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: rhur...@gwdg.de
Last committer: m...@freebsd.org
Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
2016-04-01 14:00:51Z mat $
Log URL:
http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
Build URL:
http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
Log:

>> Building databases/postgis-jdbc
build started at Thu Sep  1 09:11:08 UTC 2016
port directory: /usr/ports/databases/postgis-jdbc
building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
12.0-CURRENT r305036 amd64
maintained by: rhur...@gwdg.de
Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
412346 2016-04-01 14:00:51Z mat $
Poudriere version: 3.1.14
Host OSVERSION: 125
Jail OSVERSION: 125

---Begin Environment---
SHELL=/bin/csh
UNAME_v=FreeBSD 12.0-CURRENT r305036
UNAME_r=12.0-CURRENT
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
OPSYS=FreeBSD
ARCH=amd64
SAVED_TERM=
MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
UID=0
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=postgis-jdbc-2.1.7
OSREL=12.0
_OSRELEASE=12.0-CURRENT
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=24
PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
MASTERNAME=head-amd64-default
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=125
---End Environment---

---Begin OPTIONS List---
---End OPTIONS List---

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
SHELL=/bin/sh CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m
555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
JAVASHAREDIR="share/java"
JAVAJARDIR="share/java/classes"
OSREL=12.0
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/postgis-jdbc"
EXAMPLESDIR="share/examples/postgis-jdbc"
DATADIR="share/postgis-jdbc"
WWWDIR="www/postgis-jdbc"
ETCDIR="etc/postgis-jdbc"
--End PLIST_SUB--

--SUB_LIST--
JAVASHAREDIR="/usr/local/share/java"
JAVAJARDIR="/usr/local/share/java/classes"
JAVALIBDIR="/usr/local/share/java/classes"
JAVA_VERSION="1.6+"
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/postgis-jdbc
DOCSDIR=/usr/local/share/doc/postgis-jdbc
EXAMPLESDIR=/usr/local/share/examples/postgis-jdbc
WWWDIR=/usr/local/www/postgis-jdbc
ETCDIR=/usr/local/etc/postgis-jdbc
--End SUB_LIST--

---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/make.conf 
# XXX: We really need this but cannot use it while 'make checksum' does not
#

Re: mariadb10* ports broken on 9.x since last commit

2016-09-01 Thread Dimitry Andric 
On 31 Aug 2016, at 19:03, Doug Barton  wrote:
> 
> August 31, 2016 12:37 AM, "Bernard Spil"  wrote:
>> On 2016-08-30 17:45, Doug Barton wrote:
>> 
>>> Since the last commit to the mariadb10* ports the resulting binaries
>>> dump core on 9.3-RELEASE-p43, even for a simple --help option. I am
>>> assuming that is not the intended result 
>>> Doug
>> 
>> Hi Doug,
>> 
>> Nope, that is not intended. Assume this is the 10.0.27 update? I did build 
>> them on 9.3 but have not
>> checked the resulting binaries... Will need some time to investigate!
>> 
>> https://brnrd.eu/poudriere/build.html?mastername=93amd64-svn=2016-08-29_20h14m28s
> 
> Thanks Bernard.
> 
> It turns out that the actual problem was binutils. I backed up several 
> revisions of mariadb, past the previous working version, and had the same 
> symptoms. Then I started on the deps that had changed at the same time, and 
> fortunately I guessed right on the first one.
> 
> Backing up to -r{2016-08-25} on binutils got mariadb working with the latest 
> version.

Bisecting showed this was introduced in binutils commit 26e3a0c [1],
which turns on .init_array/.fini_array support by default.  It makes
most C++ executables crash at startup, on 9.x, since support for this
was not fully merged back to stable/9.

I think Baptiste is working on a fix.  It is probably best to configure
binutils on 9.x with --disable-initfini-array.

-Dimitry

[1] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=26e3a0c9ba4a8376fdf9f898637919d144d8b1d8



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD Port: noip-2.1.9_3

2016-09-01 Thread James A. McGuire 
Ok will do.  Many thanks for the support.

James

On Wed, Aug 31, 2016 at 4:38 PM, olli hauer  wrote:

> On 2016-08-31 17:30, Stanislaw Halik wrote:
> > On 2016-08-31 Wed 17:21, olli hauer wrote:
> >> I think this will work for you.
> >>
> >> The update interval can be adjusted (default is 30 days).
> >> In the patch example I've chosen half of the interval, so there is time
> left in case you are offline for an unforeseen reason
> >>
> >> Index: Makefile
> >> ===
> >> --- Makefile(revision 421168)
> >> +++ Makefile(working copy)
> >> @@ -25,6 +25,12 @@
> >>
> >>  OPTIONS_DEFINE=DOCS
> >>
> >> +FORCE_INTERVAL=14  # days until IP update is forced
> >> +
> >> +post-patch:
> >> +   ${REINPLACE_CMD} -e '/define 
> >> FORCE_INTERVAL/s/30/${FORCE_INTERVAL}/g'
> \
> >> +   ${WRKSRC}/noip2.c
> >> +
> >>  do-install:
> >> ${INSTALL_PROGRAM} ${WRKSRC}/noip2 ${STAGEDIR}${PREFIX}/bin
> >> ${MKDIR} ${STAGEDIR}${DOCSDIR}
> >
> > Hey,
> >
> > Please send this as a PR.
> >
> > I'd personally choose a value of 7 days but this is okay.
> >
> > sh
>
> I don't use the tool myself (having a static assigned network) and I'm
> even not sure if it will work.
>
> So I suggest James can test it (suspecting there is a ways to see the last
> update time on the noip portal) and if it works for him he can submit the
> patch as PR
>
> --
> olli
>
___
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"