Re: Is IPV6 option still necessary?

2019-10-08 Thread Wolfgang Zenker
* Dave Horsfall  [191009 02:58]:
> On Wed, 9 Oct 2019, Wolfgang Zenker wrote:
>> So, you don't *need* IPv6. But you might *want* to have it anyway.

> In my 40+ years career I've only encountered one (1) client that ran IPv6 
> internally (oddly enough, a law firm) and that was by management decree, 
> not the tehchies' (come to think of it, I don't think they *had* a techie 
> department).  Roll the lawyer jokes...

It's a big and diverse planet out there. In my 40+ years career I've
used, implemented and deployed many different networking systems.
Most of them are gone now, just IP (v4 and v6) remains. And use is
slowly shifting from IPv4 to IPv6 now.

> [..]
> If you've ever tried to grok the IPv6 spec, your brain will explode...

Must have happened to me some 20 years ago then. Probably the reason why
I rarely get a head ache :-)

Wolfgang
___
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: Is IPV6 option still necessary?

2019-10-08 Thread Wolfgang Zenker
Hi,

* abi via freebsd-ports  [191008 21:16]:
> 07.10.2019 09:18, Yasuhiro KIMURA пишет:
>> On October 10, 2012 IPV6 option of all ports was enabled by
>> default. Commit message said "We are in 2012, it is time to activate
>> IPV6 options by default everywhere".

>> And now we are in 2019. IPv6 is more widely used than 2012. So I
>> wonder if IPV6 option is still necessary.

>> If you use official packages then you always use IPv6-enabled
>> binaries. And even if you build packages by yourself you still use
>> IPv6-enabled ones unless you disable IPV6 option. So I think at most
>> only a few people uses IPv6-disabled packages.

>> Are there anybody who still disables IPV6 option for some serious
>> reason such as working around IPv6-related problem? If there aren't
>> then I think it's time to remove IPV6 option from ports framework.

> I'm writing from 2019 and I build kernel and ports without IPv6. For all 
> this years I fail to understand why I need it.

> My home devices fit 10.0.0.0/16 nicely, I have faith in NAT and I 
> encountered no IPv6-only sites.

> But I saw CVEs in IPv6 stack.

If you connect from a typical end user site to a website on my company,
if you go via IPv4 your packets will go through NAT at your CPE, quite
possibly NATted to IPv6, going through another NAT at the exit routers
of your provider and arrive at an reverse proxy at my site being proxied
to IPv6 finally reaching the website which is running on a IPv6 only
jail. Thats because neither your typical DSL or mobile provider nor my
webhosting company has enough IPv4 addresses to hand out a globally
routable address to all nodes. An IPv6 connection would be end-to-end.

So, you don't *need* IPv6. But you might *want* to have it anyway.

Wolfgang
___
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: PHP version retirement

2019-08-12 Thread Wolfgang Zenker
* Kevin Oberman  [190812 01:50]:
> On Sun, Aug 11, 2019 at 4:23 PM Martin Waschbüsch 
> wrote:
>>> Am 11.08.2019 um 23:31 schrieb Wolfgang Zenker :
>>> * Martin Waschbüsch  [190811 20:41]:
>>>> [..]
>>>>> You could also have used the quarterly branch, which keeps software till
>>>>> the end of the quarter. In the case of php 5.6 it would have given you
>>>>> time until March 31st, and would have included version 5.6.40

>>>> 5.6.40 never made it into the main ports tree. Are you sure it was
>> available in the quarterly snapshot?

>>> I am sure. You can check for yourself using the svnweb interface at the
>>> FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th

>> Thanks, Wolfgang, for pointing that out.

>> Up to now I always thought of quarterly as a static snapshot of the main
>> ports tree made at a given point in time.

No, quarterly gets security fixes, just no "feature updates". That's why
we use it in production, so we have to handle potentially breaking
changes only once a quarter.

> OK. Where did 5.6.40 come from?

> I just looked at the ports repo and it was NEVER committed there. The very
> last commit to ports/head/lang/php56 was 5.6.39. Whil it has no impact on
> me, I find it very odd to find a package that never existed in ports. That
> makes it impossible for me to access the source for this package and
> recreate it for any reason. My gut feeling is that this is broken and
> should never happen.

It was committed on the 2019Q1 branch only, because HEAD didn't have the
php56 port anymore at that time.

Wolfgang
___
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: PHP version retirement

2019-08-11 Thread Wolfgang Zenker
* Martin Waschbüsch  [190811 20:41]:
> [..]
>> You could also have used the quarterly branch, which keeps software till
>> the end of the quarter. In the case of php 5.6 it would have given you
>> time until March 31st, and would have included version 5.6.40

> 5.6.40 never made it into the main ports tree. Are you sure it was available 
> in the quarterly snapshot?

I am sure. You can check for yourself using the svnweb interface at the
FreeBSD website; php 5.6.40 was added to the 2019Q1 branch on Jan 26th

Wolfgang
___
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: PHP version retirement

2019-08-10 Thread Wolfgang Zenker
* Martin Waschbüsch  [190811 00:47]:
>> Am 10.08.2019 um 20:18 schrieb Patrick Powell :
>> 
>> Umm this was just the kick in the pants that I needed to switch to PHP 7.
>> See https://www.glaver.org/blog/?p=1109 for a desperation 'I need PHP5.6' 
>> hack which I used during this update.

> Thank you, Patrick,
> that is a work-around I also came across. It helped me as well.

You could also have used the quarterly branch, which keeps software till
the end of the quarter. In the case of php 5.6 it would have given you
time until March 31st, and would have included version 5.6.40

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


vector-maps not working in firefox

2018-12-14 Thread Wolfgang Zenker
Hi,

not sure if this is a problem of firefox or one of the components used.
Vector-based maps display wrong in Firefox on FreeBSD (all of the
Firefox versions that I have tested in the last year at least, on
FreeBSD 10.x and 11.x). The same maps work fine in Firefox on Linux
and in Chromium on FreeBSD.
How would one identify the software that is actually at fault here?
Or maybe its just a problem on my FreeBSD installations?

A few example URLs:
https://www.qwant.com/maps/#map=14.80/46.4354087/-109.8376529
https://www.google.com/maps/@46.435512,-109.8343499,15z
https://duckduckgo.com/?q=harlowton+mt=v128-4__=web=about=about

Wolfgang
___
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: Portmaster rsyslog

2018-09-17 Thread Wolfgang Zenker
Hi,

* @lbutlr  [180917 22:51]:
> I am using MariaDB 10.0 on FreeBSD 11.3

> When trying to update rsyslogd via postmaster I get:

> checking for mysql_config... mysql_config
> checking for mysql_init in -lmysqlclient... no
> configure: error: in `/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0':
> configure: error: MySQL library is missing
> See `config.log' for more details
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to matt...@freebsd.org [maintainer] and attach the
> "/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0/config.log" including the
> output of the failure of your make command. Also, it might be a good idea to
> provide an overview of all packages installed on your system (e.g. a
> /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1

> Stop.
> make[1]: stopped in /usr/ports/sysutils/rsyslog8
> *** Error code 1

> I’ve disabled the MySQL output for now, but this disconnect between MySQL and 
> Maria seems to be happening with a lot of ports.

> Is there anything I can do to restore the MySQL output for rsylog?

maybe another side effect of PR #230839
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230839

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


databases/mariadb100-client: Could someone commit the patch from #230839 ?

2018-09-14 Thread Wolfgang Zenker
Hi,

there has be no reaction from the maintainer for 3 weeks now, I guess
Bernard is on a well-deserved vacation. Could someone have a look
at the patch in #230839 please?
I would really like to have it in the Q4 branch ...

Greetings,
Wolfgang
___
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: databases/py-mysqlclient and others fail to build after update of mariadb100-client

2018-08-23 Thread Wolfgang Zenker
Hi,

* Wolfgang Zenker  [180810 14:29]:
> the immediate reason for the build failure appears to be a weird option
> "-l-pthread" in the cc invocation:

> 
> -- snip ---
> building '_mysql' extension
> creating build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7
> cc -DNDEBUG -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing 
> -DLIBICONV_PLUG -fPIC -Dversion_info=(1,3,12,'final',0) -D__version__=1.3.12 
> -I/usr/local/include/mysql -I/usr/local/include/mysql/.. 
> -I/usr/local/include/python2.7 -c _mysql.c -o 
> build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.o
> cc -shared -fstack-protector -O2 -pipe -DLIBICONV_PLUG -fstack-protector 
> -fno-strict-aliasing -DLIBICONV_PLUG 
> build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.o -L/usr/local/lib/mysql 
> -L/usr/local/lib -L/usr/local/lib -lmysqlclient_r -l-pthread -lz -lm 
> -lexecinfo -lssl -lcrypto -lpython2.7 -o 
> build/lib.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.so
> /usr/bin/ld: cannot find -l-pthread
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> error: command 'cc' failed with exit status 1
> *** Error code 1
> 

> As the port itself has not changed for several weeks, the real problem
> must be somewhere else, probably in the mariadb port?
> Any idea where this weird lib parameter comes from and how / where to
> fix it?

the problem is in databases/mariadb100-client, which creates a
mysql_config script with the weird lib parameter.
I have filed PR #230839

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


databases/py-mysqlclient and others fail to build after update of mariadb100-client

2018-08-10 Thread Wolfgang Zenker
Hi,

the immediate reason for the build failure appears to be a weird option
"-l-pthread" in the cc invocation:


-- snip ---
building '_mysql' extension
creating build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7
cc -DNDEBUG -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing 
-DLIBICONV_PLUG -fPIC -Dversion_info=(1,3,12,'final',0) -D__version__=1.3.12 
-I/usr/local/include/mysql -I/usr/local/include/mysql/.. 
-I/usr/local/include/python2.7 -c _mysql.c -o 
build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.o
cc -shared -fstack-protector -O2 -pipe -DLIBICONV_PLUG -fstack-protector 
-fno-strict-aliasing -DLIBICONV_PLUG 
build/temp.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.o -L/usr/local/lib/mysql 
-L/usr/local/lib -L/usr/local/lib -lmysqlclient_r -l-pthread -lz -lm -lexecinfo 
-lssl -lcrypto -lpython2.7 -o 
build/lib.freebsd-11.1-RELEASE-p12-amd64-2.7/_mysql.so
/usr/bin/ld: cannot find -l-pthread
cc: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'cc' failed with exit status 1
*** Error code 1


As the port itself has not changed for several weeks, the real problem
must be somewhere else, probably in the mariadb port?
Any idea where this weird lib parameter comes from and how / where to
fix it?

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