Re: default named.conf in bind ports and slaving from f-root

[Kevin Oberman]

On Sat, Apr 15, 2017 at 7:02 PM, George Mitchell 
wrote:

> On 04/14/17 08:37, Thomas Steen Rasmussen wrote:
> > Hello,
> >
> > Cloudflare deployed a bunch (74 apparently) of new f-root dns
> > servers, which do not permit AXFR like the other f-root instances
> > do.
> > [...]
> > A good alternative could be to change named.conf to use
> > lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
> > described in [2]. My named.conf now looks like this:
> > [...]
>
> Does this issue affect me if I use type "hint" for zone "." like this:
>
> zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
>
> -- George
>

It does not have anything to do with "normal" operations using a hints
file. This only has an impact on those who transfer zones from a root
server. Many of the root servers do not allow AXFRs to reduce load.
--
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"

Re: default named.conf in bind ports and slaving from f-root

[George Mitchell]

On 04/14/17 08:37, Thomas Steen Rasmussen wrote:
> Hello,
> 
> Cloudflare deployed a bunch (74 apparently) of new f-root dns
> servers, which do not permit AXFR like the other f-root instances
> do.
> [...]
> A good alternative could be to change named.conf to use
> lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
> described in [2]. My named.conf now looks like this:
> [...]

Does this issue affect me if I use type "hint" for zone "." like this:

zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };

-- George



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD Port: graphics/opencv -- Fails to compile

[Kevin Oberman]

On Sat, Apr 15, 2017 at 3:09 PM, Peter Smith  wrote:

> I am running
>
> # uname -a
> > FreeBSD red 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0: Wed Feb 22
> > 06:12:04 UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/
> src/sys/GENERIC
> > amd64
> >
>
>
> Having just refreshed my ports tree (portsnap fetch, etc), I'm rebuilding
> all my installed ports (portmaster -a). Alas, opencv-core won't build.
>
> When I go to the port and do a 'make' I get:
>
>
> root@red:/usr/ports/graphics/opencv-core # make
> ===>   NOTICE:
>
> The opencv port currently does not have a maintainer. As a result, it is
> more likely to have unresolved issues, not be up-to-date, or even be
> removed in
> the future. To volunteer to maintain this port, please create an issue at:
>
> https://bugs.freebsd.org/bugzilla
>
> More information about port maintainership is available at:
>
> https://www.freebsd.org/doc/en/articles/contributing/
> ports-contributing.html#maintain-port
>
> ===>  License BSD3CLAUSE accepted by the user
> ===>   opencv-core-2.4.13.1_1 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by opencv-core-2.4.13.1_1 for building
> ===>  Extracting for opencv-core-2.4.13.1_1
> => SHA256 Checksum OK for opencv-opencv-2.4.13.1_GH0.tar.gz.
> ===>  Patching for opencv-core-2.4.13.1_1
> ===>  Applying FreeBSD patches for opencv-core-2.4.13.1_1
> 1 out of 1 hunks failed--saving rejects to
> ./apps/traincascade/imagestorage.h.rej
> => FreeBSD patch patch-apps__traincascade__imagestorage.h failed to apply
> cleanly.
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/opencv-core
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/opencv-core
>
> The reject patch file looks like:
>
> root@red:/usr/ports/graphics/opencv-core/work/opencv-2.4.
> 13.1/apps/traincascade
> # cat imagestorage.h.rej
> @@ -1,6 +1,7 @@
>  #ifndef _OPENCV_IMAGESTORAGE_H_
>  #define _OPENCV_IMAGESTORAGE_H_
>
> +#include 
>  #include "highgui.h"
>
>  using namespace cv;
>
> But the original file looks like:
>
> root@red:/usr/ports/graphics/opencv-core/work/opencv-2.4.
> 13.1/apps/traincascade
> > # more imagestorage.h.orig
> >
> #ifndef _OPENCV_IMAGESTORAGE_H_
> #define _OPENCV_IMAGESTORAGE_H_
>
> #include 
> #include 
> #include 
> #include "highgui.h"
>
> class CvCascadeImageReader
>
>
> So, I can see why the patch fails. I just can't figure out where the file
> is that I need to tweak.
>
> I wonder if anyone else has seen anything like this before.
>
>
>
> Kind regards
>
> Peter Smith
>
> Department of Management and International Business
> Room 439, Level 4, Owen G. Glenn Building, 12 Grafton Road, AUCKLAND
> The University of Auckland Business School, Private Bag 92019, AUCKLAND
> Email: p.sm...@auckland.ac.nz, Phone: +64 9 923 7178
>

Somehow you seem to have an old patch file sitting in the ports tree.
patch-apps__traincascade__imagestorage.h no longer exists in the port.

Do you SVN your ports tree? If so, you can confirm the issue with "svn
status /usr/ports/graphics/opencv". Asssuming it is marked as unknown (?),
I suggest that you "rm /usr/ports/graphics/opencv/files/*" and then "svn up
/usr/ports/graphics/opencv". (Note: opencv-core is a slave port of opencv
and all patches are in the opencv directory.) Then it should patch
correctly.

If you don't use svn to update your ports tree, I'm a bit baffled as
portsnap should remove unknown files.
--
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"

FreeBSD Port: graphics/opencv -- Fails to compile

[Peter Smith]

I am running

# uname -a
> FreeBSD red 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #0: Wed Feb 22
> 06:12:04 UTC 2017 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> amd64
>


Having just refreshed my ports tree (portsnap fetch, etc), I'm rebuilding
all my installed ports (portmaster -a). Alas, opencv-core won't build.

When I go to the port and do a 'make' I get:


root@red:/usr/ports/graphics/opencv-core # make
===>   NOTICE:

The opencv port currently does not have a maintainer. As a result, it is
more likely to have unresolved issues, not be up-to-date, or even be
removed in
the future. To volunteer to maintain this port, please create an issue at:

https://bugs.freebsd.org/bugzilla

More information about port maintainership is available at:

https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port

===>  License BSD3CLAUSE accepted by the user
===>   opencv-core-2.4.13.1_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by opencv-core-2.4.13.1_1 for building
===>  Extracting for opencv-core-2.4.13.1_1
=> SHA256 Checksum OK for opencv-opencv-2.4.13.1_GH0.tar.gz.
===>  Patching for opencv-core-2.4.13.1_1
===>  Applying FreeBSD patches for opencv-core-2.4.13.1_1
1 out of 1 hunks failed--saving rejects to
./apps/traincascade/imagestorage.h.rej
=> FreeBSD patch patch-apps__traincascade__imagestorage.h failed to apply
cleanly.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/graphics/opencv-core
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/opencv-core

The reject patch file looks like:

root@red:/usr/ports/graphics/opencv-core/work/opencv-2.4.13.1/apps/traincascade
# cat imagestorage.h.rej
@@ -1,6 +1,7 @@
 #ifndef _OPENCV_IMAGESTORAGE_H_
 #define _OPENCV_IMAGESTORAGE_H_

+#include 
 #include "highgui.h"

 using namespace cv;

But the original file looks like:

root@red:/usr/ports/graphics/opencv-core/work/opencv-2.4.13.1/apps/traincascade
> # more imagestorage.h.orig
>
#ifndef _OPENCV_IMAGESTORAGE_H_
#define _OPENCV_IMAGESTORAGE_H_

#include 
#include 
#include 
#include "highgui.h"

class CvCascadeImageReader


So, I can see why the patch fails. I just can't figure out where the file
is that I need to tweak.

I wonder if anyone else has seen anything like this before.



Kind regards

Peter Smith

Department of Management and International Business
Room 439, Level 4, Owen G. Glenn Building, 12 Grafton Road, AUCKLAND
The University of Auckland Business School, Private Bag 92019, AUCKLAND
Email: p.sm...@auckland.ac.nz, Phone: +64 9 923 7178
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: LLVM port(s) take very long time to package

[Alexey Dokuchaev]

On Fri, Apr 14, 2017 at 04:42:35PM +0200, Michael Gmelin wrote:
> > On 14. Apr 2017, at 16:22, Alexey Dokuchaev  wrote:
> > On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote:
> >>> On 12. Apr 2017, at 11:37, Alexey Dokuchaev  wrote:
> >>> ...
> >>> Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz
> >>> (pkg-static create -f tbz ...), will play with that as well.
> >> 
> >> I don't think bzip will buy you much in terms of performance,
> > 
> > Surprisingly, it actually did:
> > 
> > $ time make package PKG_SUFX=.tbz
> > ===>  Building package for llvm40-4.0.0_2
> > 565.215u 5.316s 9:34.18 99.3%   7899+502k 1+3020io 0pf+0w
> > ^^^
> > Single-threaded bzip2 was faster than multi-threaded xz [...]
> > of larger package of course:
> 
> Interesting, I'll tried that on our high-frequency builders.

Cool, please share your numbers with us once you have them.

Meanwhile, I've patched my tinderbox to package with PKG_NOCOMPRESS=1 and
then use `archivers/pbzip2' to compress the file.  This cut down the time
to package `devel/llvm40' from previous ~50 minutes to just three without
touching any libarchive(3) or pkg(8) code.  I guess I can live with that
until libarchive(3) and/or pkg(8) gain proper support of multicore-aware
efficient modern compression algorithm(s).

./danfe
___
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: default named.conf in bind ports and slaving from f-root

[Bob Willcox]

On Fri, Apr 14, 2017 at 05:25:21PM +0200, Thomas Steen Rasmussen wrote:
> On 04/14/2017 04:51 PM, Mathieu Arnold wrote:
> > Hi,
> >
> > I'm busy right now, could you open a PR so that I don't loose and forget
> > this ?
> 
> Sure thing, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218656
> 
> /Thomas
> 

Thomas,

I am really glad you posted this to the mailing list. This morning I woke up
to a non-functioning named as it could no longer transfer data from
192.5.5.241 and my arpa/IN/internal-view expired at about midnight last night.
I suppose I should have noticed the transfer failure messages in my
/var/log/messages file over the past two weeks, but I didn't (or it didn't
occur to me how serious they were).

I was left with NO outside nameserver resolution at all. Looks like I need to
find a reliable backup nameserver that I can use should something like the
happen again.

Anyway, luckly my mail server had already received you message to
freebsd-ports describing the issue and what you did to correct it. I followed
your example and got my nameserver back to the working state.

Thank you!!
Bob


-- 
Bob Willcox| You're dead, Jim.
b...@immure.com |   -- McCoy, "The Tholian Web", stardate unknown
Austin, TX |
___
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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

Sorry Matthew, forgot to reply to this one.

On Wed, Apr 05, 2017 at 07:01:35PM +0200, Matthew Rezny wrote:
> On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote:
> > ...
> > Hmm, I don't quite get it: shouldn't static linking actually increase
> > the binaries (and thus the package) size?
> 
> I might have reversed static and shared somewhere in the linking
> explanation, or not properly described the situation. [...]

Understood, makes sense now.

> There was a brief period in which llvm39 was fully switched to dynamic
> linking, which made it considerably smaller but caused runtime problems
> (and was also likely to be slower).

That still sounds like the most sane way to go; provided those problems
are/would be fixed, I hope for that switch to happen again one day.  (I
somewhat doubt that "slower" was noticeable enough to worry about.)

> The best solution to cut rebuild time for LLVM is ccache.

Indeed, ccache helps greatly.  Now that I've managed to cut down package
times as well, situation with LLVM ports no longer looks as bad as I
originally saw it; thank you.

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

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Linimon]

On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
> I've seen material quoted from a exp-run that reported
> that about 54(?) ports were then blocked by lang/gcc6-aux
> not building.

Although the first is an older run (the last complete run IIUC), there
were 50 and 51 respectively as of:

http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default=423029
http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default=p437390_s316341

I think you're fairly deep into unexplored territory here.

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

RELRO breaks net/openmpi, was: net/openmpi fails to compile with default settings

[Grzegorz Junka]

Thanks Anton,

The compilation was broken because of

OPTIONS_FILE_SET+=RELRO

in

devel/binutils

After disabling RELRO net/openmpi can be compiled successfully. Not sure 
if this is a bug or expected behaviour.


Regards
Grzegorz


On 14/04/2017 11:26, Anton Shterenlikht wrote:

I don't know which ports default to MPICH. For me failed openmpi blocks
141 ports:

[00:05:53] >> [01][00:04:13] Finished build of net/openmpi: Failed:
build
[00:05:55] >> [01][00:04:15] Skipping build of graphics/ImageMagick:
Dependent port net/openmpi failed

This is strange. It shouldn't depend on openmpi:

$ pkg info -xd ImageMagick|grep mpi
$ pkg info -xr openmpi
openmpi-1.10.6_1:
openmpi2-2.0.2_4:
$

I have 723 packages installed,
including lots of ports from your list,
e.g. firefox, chromium, ImageMagick.
None require openmpi.
In fact the only reason I built openmpi is
to check the MPI performance against MPICH.

I mostly use pkg, with occasional use of the ports tree
directly, when I need non-default options.
Perhaps there is something different in poudriere.

I think you need somebody more experienced to advise.

Anton


___
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

[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
+-+
games/chessx| 1.3.2   | 1.4.6
+-+
graphics/opencv | 2.4.13.1| 3.2.0
+-+
graphics/opencv-core| 2.4.13.1| 3.2.0
+-+
graphics/opencv-java| 2.4.13.1| 3.2.0
+-+
graphics/py-opencv  | 2.4.13.1| 3.2.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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

Re: graphics/opencv2 orphaned. Where from here

[Herbert J. Skuhra]

Rainer Hurling skrev:
> 
> Am 15.04.2017 um 01:04 schrieb Kevin Oberman:
>> Thanks for the work on opencv, but PLEASE put something in UPDATING when
>> you make changes that impact large numbers of ports. I see opencv2 as
>> orphaned, so I can't stay there.
>> 
>> Do I reset the origin of opencv2 to opencv? Or will I need to delete all of
>> them and rebuild everything? Please put information in UPDATING to give us
>> poor users some idea of how to proceed. I really would rathe rnot have to
>> re-install all of those ports if there is no reason.
> 
> As a user of portmaster, all I had to do, was:
> 
> portmaster -o graphics/opencv-core opencv2-core-2.4.13.1_1

Hmm, I had to 'pkg delete opencv2-core' because of

pkg-static: opencv-core-2.4.13.1_1 conflicts with
opencv2-core-2.4.13.1_1 (installs files into the same place).
Problematic file: /usr/local/include/opencv2/core.hpp

and then run 'make install clean' in graphics/opencv-core.

--
Herbert
___
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: graphics/opencv2 orphaned. Where from here

[Rainer Hurling]

Am 15.04.2017 um 01:04 schrieb Kevin Oberman:
> Thanks for the work on opencv, but PLEASE put something in UPDATING when
> you make changes that impact large numbers of ports. I see opencv2 as
> orphaned, so I can't stay there.
> 
> Do I reset the origin of opencv2 to opencv? Or will I need to delete all of
> them and rebuild everything? Please put information in UPDATING to give us
> poor users some idea of how to proceed. I really would rathe rnot have to
> re-install all of those ports if there is no reason.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


As a user of portmaster, all I had to do, was:

portmaster -o graphics/opencv-core opencv2-core-2.4.13.1_1
portmaster -o graphics/opencv opencv2-2.4.13.1_6
portmaster -o graphics/py-opencv py27-opencv2-2.4.13.1_1
___
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"