From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 05:33:58 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F0641C0 for ; Sun, 8 Mar 2015 05:33:58 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15A9ACE4 for ; Sun, 8 Mar 2015 05:33:57 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 35030160282; Sat, 7 Mar 2015 22:28:03 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 437A016014C for ; Sat, 7 Mar 2015 22:28:00 -0700 (MST) Message-ID: <54FBDDE0.6090806@pinyon.org> Date: Sat, 07 Mar 2015 22:28:00 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Single worst bug for ports: lang/gcc* doesn't support c++11 References: <54FB8656.8060502@rawbw.com> In-Reply-To: <54FB8656.8060502@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 05:33:58 -0000 On 03/07/15 16:14, Yuri wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193528 > > Many packages still don't build with clang (in part because Linux didn't > adopt it as much as FreeBSD did), and at the same time they are changing > code to be c++11. > As a result, many such packages can't be updated any more. > In two days I hit this problem twice. I would like to understand better the problem here, because I use c++11 features heavily with lang/gcc49 on a daily basis with zero problems. gcc5 is still buggy, but gcc49 is a pleasure to work with. I must be missing something, because if you want to support c++11, why wouldn't you require gcc49? What am I missing? I'm just trying to learn the ports philosophy here better. Best, Russell > Yuri > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 06:22:56 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ECEE530 for ; Sun, 8 Mar 2015 06:22:56 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B785B178 for ; Sun, 8 Mar 2015 06:22:54 +0000 (UTC) Received: (qmail 30861 invoked from network); 8 Mar 2015 06:16:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Mar 2015 06:16:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 01:16:13 -0500 (EST) Received: (qmail 22529 invoked from network); 8 Mar 2015 06:16:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2015 06:16:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id EE4F41C43A2; Sat, 7 Mar 2015 22:15:58 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py Message-Id: Date: Sat, 7 Mar 2015 22:16:03 -0800 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 06:22:56 -0000 powerpc64 context (more details are listed later): $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, = and x11-wm/xfce4 are all blocked from building by sysutils/polkit = failing to build because of a broken pipe with a subprocess... ... gmake all-am gmake[6]: Entering directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' CC libpolkit_gobject_1_la-polkitenumtypes.lo CC libpolkit_gobject_1_la-polkitactiondescription.lo CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo CC libpolkit_gobject_1_la-polkitdetails.lo CC libpolkit_gobject_1_la-polkitauthority.lo CC libpolkit_gobject_1_la-polkiterror.lo CC libpolkit_gobject_1_la-polkitsubject.lo CC libpolkit_gobject_1_la-polkitunixprocess.lo CC libpolkit_gobject_1_la-polkitsystembusname.lo CC libpolkit_gobject_1_la-polkitidentity.lo CC libpolkit_gobject_1_la-polkitunixuser.lo CC libpolkit_gobject_1_la-polkitunixgroup.lo CC libpolkit_gobject_1_la-polkitunixnetgroup.lo CC libpolkit_gobject_1_la-polkitauthorizationresult.lo CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo CC libpolkit_gobject_1_la-polkitpermission.lo CC libpolkit_gobject_1_la-polkitunixsession.lo CCLD libpolkit-gobject-1.la GISCAN Polkit-1.0.gir Traceback (most recent call last): File "/usr/local/bin/g-ir-scanner", line 55, in sys.exit(scanner_main(sys.argv)) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 517, in scanner_main ss =3D create_source_scanner(options, args) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 430, in create_source_scanner ss.parse_files(filenames) File = "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line = 256, in parse_files self._parse(headers) File = "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line = 302, in _parse proc.stdin.write('#ifndef %s\n' % (define, )) IOError: [Errno 32] Broken pipe /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: = recipe for target 'Polkit-1.0.gir' failed gmake[6]: *** [Polkit-1.0.gir] Error 1 gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:444: recipe for target 'all' failed gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:326: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' Makefile:374: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' Makefile:305: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/polkit *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/polkit =3D=3D=3D>>> make build failed for sysutils/polkit =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster sysutils/polkit=20 The relevant = /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code = being... def _parse(self, filenames): if not filenames: return =20 defines =3D ['__GI_SCANNER__'] undefs =3D [] cpp_args =3D os.environ.get('CC', 'cc').split() # support = CC=3D"ccache gcc" if 'cl' in cpp_args: # The Microsoft compiler/preprocessor (cl) does not accept # source input from stdin (the '-' flag), so we need # some help from gcc from MinGW/Cygwin or so. # Note that the generated dumper program is # still built and linked by Visual C++. cpp_args =3D ['gcc'] cpp_args +=3D os.environ.get('CPPFLAGS', '').split() cpp_args +=3D os.environ.get('CFLAGS', '').split() cpp_args +=3D ['-E', '-C', '-I.', '-'] cpp_args +=3D self._cpp_options proc =3D subprocess.Popen(cpp_args, stdin=3Dsubprocess.PIPE, stdout=3Dsubprocess.PIPE) for define in defines: proc.stdin.write('#ifndef %s\n' % (define, )) proc.stdin.write('# define %s\n' % (define, )) proc.stdin.write('#endif\n') ... For my context the overall environment has (but ports might force other = ports as alternatives to): # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D # more /etc/src.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG # which cc /usr/bin/cc # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ cd /usr/ports $ svnlite info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 380683 Node Kind: directory Schedule: normal Last Changed Author: demon Last Changed Rev: 380683 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) $ svnlite st --no-ignore ? .snap I distfiles M graphics/libGL/bsd.mesalib.mk I packages ? restoresymtable $ svnlite diff graphics/libGL/bsd.mesalib.mk Index: graphics/libGL/bsd.mesalib.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- graphics/libGL/bsd.mesalib.mk (revision 380683) +++ graphics/libGL/bsd.mesalib.mk (working copy) @@ -136,6 +136,10 @@ CONFIGURE_ARGS+=3D--enable-vdpau .endif =20 +.if ${ARCH} =3D=3D powerpc64 +CFLAGS+=3D -mminimal-toc +.endif + post-patch: @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ ${WRKSRC}/configure $ cd /usr/src $ svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279507 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 279507 Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) $ svnlite st --no-ignore ? .snap ? restoresymtable M sys/ddb/db_main.c M sys/ddb/db_script.c I sys/powerpc/conf/GENERIC64vtsc I sys/powerpc/conf/GENERICvtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powerpc/dump_machdep.c sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid = intermittent boot problems. sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 06:36:52 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1366C676 for ; Sun, 8 Mar 2015 06:36:52 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id D6DE8243 for ; Sun, 8 Mar 2015 06:36:51 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t286aoJF093899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 7 Mar 2015 22:36:50 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <54FBEE00.6060501@rawbw.com> Date: Sat, 07 Mar 2015 22:36:48 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Russell L. Carter" , freebsd-ports@freebsd.org Subject: Re: Single worst bug for ports: lang/gcc* doesn't support c++11 References: <54FB8656.8060502@rawbw.com> <54FBDDE0.6090806@pinyon.org> In-Reply-To: <54FBDDE0.6090806@pinyon.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 06:36:52 -0000 On 03/07/2015 21:28, Russell L. Carter wrote: > > I would like to understand better the problem here, because I use c++11 > features heavily with lang/gcc49 on a daily basis with zero problems. No, gcc-4.9.3 fails in the same way. Specific missing feature: std::snprintf error: 'snprintf' is not a member of 'std' Yuri From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 06:56:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EB688F0 for ; Sun, 8 Mar 2015 06:56:34 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29C14613 for ; Sun, 8 Mar 2015 06:56:33 +0000 (UTC) Received: (qmail 10640 invoked from network); 8 Mar 2015 06:56:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Mar 2015 06:56:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 01:56:32 -0500 (EST) Received: (qmail 13323 invoked from network); 8 Mar 2015 06:56:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2015 06:56:32 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id CCA9F1C43A2; Sat, 7 Mar 2015 22:56:24 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it Message-Id: Date: Sat, 7 Mar 2015 22:56:30 -0800 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 06:56:34 -0000 powerpc64 context (more details are listed much later): $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... When png-1.6.16 has PNGTEST enabled (default and "recommended") it tries = to use cmake's /usr/local/bin/ctest. But in my context ctest is broken, = trying to reserve 2305843009213693952 Hashtable_node<...>*'s [see #8's = ...::reserve (..., __n=3D...) below] when _M_initialize_buckets(..., = __n=3D100) in #9. (Note: 2305843009213693952 =3D=3D 0x2000000000000000.) = I have yet to figure out how that magic number is becoming involved. See = below from one of the crash dumps: #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 [New Thread 51c06400 (LWP 100091/ctest)] (gdb) bt #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 #3 0x00000000514c9ae0 in ._ZN9__gnu_cxx27__verbose_terminate_handlerEv = () from /usr/lib/libsupc++.so.1 #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, __n=3D100,= __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 #16 0x00000000100224dc in cmCTest::Initialize (this=3D0xffffffffffffcf50, = binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 #19 0x000000001000fc9c in ._start () #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 The specific Makefile code to invoke ctest is... # Special rule for the target test test: @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan = "Running tests..." /usr/local/bin/ctest --force-new-ctest-process $(ARGS) .PHONY : test =20 # Special rule for the target test test/fast: test .PHONY : test/fast which because of ctest's problem leads to... ... Linking C executable pngvalid [100%] Built target pngvalid (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"install -o root -g wheel -m 444" /usr/bin/make -f = Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) Running tests... terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort trap (core dumped) *** [test] Error code 134 make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 1 error make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 [: xTry: unexpected operator *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/png *** Error code 1 Stop. make: stopped in /usr/ports/graphics/png Even just ctest as a command gets the vector::reserve size problem from = the large magic number: $ ctest ********************************* No test configuration file found! ********************************* terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort trap (core dumped) [So far I've only sidestepped having graphic/png run ctest to allow some = things that depend on graphics/png to not be blocked by this.] For my context the overall environment has (but ports might force other = ports as alternatives to): # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D # more /etc/src.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG # which cc /usr/bin/cc # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ cd /usr/ports $ svnlite info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 380683 Node Kind: directory Schedule: normal Last Changed Author: demon Last Changed Rev: 380683 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) $ svnlite st --no-ignore ? .snap I distfiles M graphics/libGL/bsd.mesalib.mk I packages ? restoresymtable $ svnlite diff graphics/libGL/bsd.mesalib.mk Index: graphics/libGL/bsd.mesalib.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- graphics/libGL/bsd.mesalib.mk (revision 380683) +++ graphics/libGL/bsd.mesalib.mk (working copy) @@ -136,6 +136,10 @@ CONFIGURE_ARGS+=3D--enable-vdpau .endif +.if ${ARCH} =3D=3D powerpc64 +CFLAGS+=3D -mminimal-toc +.endif + post-patch: @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ ${WRKSRC}/configure $ cd /usr/src $ svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279507 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 279507 Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) $ svnlite st --no-ignore ? .snap ? restoresymtable M sys/ddb/db_main.c M sys/ddb/db_script.c I sys/powerpc/conf/GENERIC64vtsc I sys/powerpc/conf/GENERICvtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powerpc/dump_machdep.c sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid = intermittent boot problems. sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 09:40:29 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 076AFC52; Sun, 8 Mar 2015 09:40:29 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C9B3638; Sun, 8 Mar 2015 09:40:28 +0000 (UTC) Received: by wesx3 with SMTP id x3so14728216wes.1; Sun, 08 Mar 2015 01:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9+kwyvGh/46bi6Wsvh3Lssspo9mZNJaLdh3hFuXePAQ=; b=JQMj4tNMVku/i7ydkpDUZ+A9LFfDfn1fdfffzBQH85R+of+u+uzj+rPDvoqZQllKQo ljBdVG5BNPoMMP9gaB3sJeyww8bcNZ2XbHnYDhvhO7TTtX0+RtWoqzBOnkYqRhntvxE1 KMwmWTS38ExQgKP2p/KI0xSwtswJBp4mLHUNkat/2EjghlspLLmT01xqoFLBilMve88O rendE211MFmVjGZuG0L8lyRqMBRAgoX8fMXgjacp2EKac9GKdlnncSMQUZk6w8QANIT6 p32tsgVIX3DD/+O4Q8XwpJSH9YFOjkSZV+iyeKe50YN2o15Ez4jBhayNeciEXvNZ2ya7 IDJQ== MIME-Version: 1.0 X-Received: by 10.195.13.104 with SMTP id ex8mr46223929wjd.12.1425807627025; Sun, 08 Mar 2015 01:40:27 -0800 (PST) Received: by 10.194.124.35 with HTTP; Sun, 8 Mar 2015 01:40:26 -0800 (PST) In-Reply-To: References: <54FB7119.4030208@FreeBSD.org> Date: Sun, 8 Mar 2015 17:40:26 +0800 Message-ID: Subject: Re: How could I increase "runaway" timer for package build cluster? From: Ben Woods To: "lev@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 09:40:29 -0000 Actually, taking a look at my /usr/local/etc/poudriere.conf configuration file, I see these settings have indeed been exposed for configuration there without having to touch the poudriere code itself. The appropriate settings are: # This defines the max time (in seconds) that a command may run for a build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=86400 # This defines the time (in seconds) before a command is considered to # be in a runaway state for having no output on stdout. Default: 7200 #NOHANG_TIME=7200 Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com On 8 March 2015 at 07:00, Ben Woods wrote: > > You can increase the max_execution_time in /usr/local/share/common.sh (default 3600 seconds). There are individual timeout values for extract, install, package and deinstall. These are the maximum values for each stage (with or without output being produced). > > But more likely, you need to look at the NOHANG_TIME value in the same common.sh file (default 7200 seconds). This is the one related to having no output produced (aka "runaway build"). > > Someone has previously spoken about exposing these kinds of values for tweaking in the poudriere configuration files, but I'm not sure it ever progressed: > https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097757.html > > Regards, > Ben > > > On Sunday, March 8, 2015, Lev Serebryakov wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> >> One of my ports (devel/gcc-arm-embedded) doesn't produce much output >> on build (output is redirected to log files), but takes severa hours >> to be built. >> >> Looks like pkg building cluster doesn't like such behavior. >> >> Could I notify build cluster (poudrere?) that this package takes a >> lot of time without output? >> >> - -- >> // Lev Serebryakov AKA Black Lion From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 12:36:20 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0462882 for ; Sun, 8 Mar 2015 12:36:20 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F21A9CC for ; Sun, 8 Mar 2015 12:36:20 +0000 (UTC) Received: by qcxm20 with SMTP id m20so60805369qcx.0 for ; Sun, 08 Mar 2015 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TmNgDxfUuMnXg04PNNwd+YhbRtZy34Hx2Q7IgRQh1Mk=; b=INVhbkcXFRMZQ4z0YdNxKUzXrVc3WCJNiwIQWPdMXbGXWG7KzV/nFUCRd2PWVwd+bw xiIoDhRCb2zeqXQHkca2utZ8aMTu0HZTvIW5tKLqpnahen10XnWDbIQ/ImMonQHWciVN 5uXfoQW8LbG410dvNPs0zw6H/rvmJTO+3UPAiZOyPuVYn3Qhvs3EEl/7oJ3gKNMiYyid v8nTNMauq/kzzr/GM3mdyZd4A8r7i+b5pdzCQUTnWy7ZpZHn9CWfyNzAb3A6GdsQZcNn PnrICJdWxH5yZz6lV9MdfcyjPfAt18ECq4/vZQoCs/O6XhZv8EU0XI/NuvetIQ361rtU M78A== MIME-Version: 1.0 X-Received: by 10.140.231.151 with SMTP id b145mr29830516qhc.22.1425818179587; Sun, 08 Mar 2015 05:36:19 -0700 (PDT) Received: by 10.96.158.137 with HTTP; Sun, 8 Mar 2015 05:36:19 -0700 (PDT) In-Reply-To: <54FBEE00.6060501@rawbw.com> References: <54FB8656.8060502@rawbw.com> <54FBDDE0.6090806@pinyon.org> <54FBEE00.6060501@rawbw.com> Date: Sun, 8 Mar 2015 14:36:19 +0200 Message-ID: Subject: Re: Single worst bug for ports: lang/gcc* doesn't support c++11 From: Kimmo Paasiala To: Yuri Content-Type: text/plain; charset=UTF-8 Cc: "Russell L. Carter" , freebsd-ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 12:36:20 -0000 On Sun, Mar 8, 2015 at 8:36 AM, Yuri wrote: > On 03/07/2015 21:28, Russell L. Carter wrote: >> >> >> I would like to understand better the problem here, because I use c++11 >> features heavily with lang/gcc49 on a daily basis with zero problems. > > > No, gcc-4.9.3 fails in the same way. Specific missing feature: std::snprintf > > error: 'snprintf' is not a member of 'std' > > > Yuri Post an example of the offending code. I suspect that the real problem is that the code is not using an explicit 'using std::snprintf' when it should, this is a very common problem in C++ code that has been written at a time when including a header file was enough to bring the std:: namespace names in that header to the global namespace. This is no longer the case afaik on standard conformining implementations. -Kimmo From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 12:42:20 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9544B97E for ; Sun, 8 Mar 2015 12:42:20 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57796A85 for ; Sun, 8 Mar 2015 12:42:20 +0000 (UTC) Received: by qcvx3 with SMTP id x3so60813103qcv.5 for ; Sun, 08 Mar 2015 05:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FDxwyqyRFCl+h8oZ6T22ARyl/MyLdwj0V137OTXHvzc=; b=rgL4m1czz39guMzBaUKbrb81GZBj/Y3+UeO0WkUgs1nlVP3qZOk5YvzgnLifm7tJT4 iV1sth7Jep1slpe5kOUZ0df7n7c1tNI6n8Dimxp/xsxMHhQTDZKJyZDhX+H+LPynbr5I iUjN/MAHZR2wEl5ARHk/c0V9iguT5Xbz1ItjGeg+5HleCvmhuaQLhMH9T8NwFBNPYOv3 ZlDPuHz+od2seUulEPsNTIzQSU013mCzciM+DE5uI+7qZ1JAfKaToQ4Rx1M5d+ReCptV ACwQt5BFYPyWhiECHsM5rZG2uMyEdBZQPN1Gwtoar7cLTvxwclE4OYI4997ur+qeJlin RNMg== MIME-Version: 1.0 X-Received: by 10.140.233.84 with SMTP id e81mr31279351qhc.94.1425818539494; Sun, 08 Mar 2015 05:42:19 -0700 (PDT) Received: by 10.96.158.137 with HTTP; Sun, 8 Mar 2015 05:42:19 -0700 (PDT) In-Reply-To: References: <54FB8656.8060502@rawbw.com> <54FBDDE0.6090806@pinyon.org> <54FBEE00.6060501@rawbw.com> Date: Sun, 8 Mar 2015 14:42:19 +0200 Message-ID: Subject: Re: Single worst bug for ports: lang/gcc* doesn't support c++11 From: Kimmo Paasiala To: Yuri Content-Type: text/plain; charset=UTF-8 Cc: "Russell L. Carter" , freebsd-ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 12:42:20 -0000 On Sun, Mar 8, 2015 at 2:36 PM, Kimmo Paasiala wrote: > On Sun, Mar 8, 2015 at 8:36 AM, Yuri wrote: >> On 03/07/2015 21:28, Russell L. Carter wrote: >>> >>> >>> I would like to understand better the problem here, because I use c++11 >>> features heavily with lang/gcc49 on a daily basis with zero problems. >> >> >> No, gcc-4.9.3 fails in the same way. Specific missing feature: std::snprintf >> >> error: 'snprintf' is not a member of 'std' >> >> >> Yuri > > Post an example of the offending code. I suspect that the real problem > is that the code is not using an explicit 'using std::snprintf' when > it should, this is a very common problem in C++ code that has been > written at a time when including a header file was enough to bring the > std:: namespace names in that header to the global namespace. This is > no longer the case afaik on standard conformining implementations. > > -Kimmo Well, scratch that sorry. I just learned that std::snprintf is indeed a c++11 only feature... -Kimmo From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 13:20:23 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CC0CECE for ; Sun, 8 Mar 2015 13:20:23 +0000 (UTC) Received: from cicero4.cybercity.dk (cicero-fbr1.cybercity.dk [212.242.40.5]) by mx1.freebsd.org (Postfix) with ESMTP id B6834D51 for ; Sun, 8 Mar 2015 13:20:21 +0000 (UTC) Received: from cicero3.cybercity.dk (cicero3.cybercity.dk [212.242.43.248]) by cicero4.cybercity.dk (Postfix) with ESMTP id 144364F546D for ; Sun, 8 Mar 2015 13:46:36 +0100 (CET) Received: from mail.flipmode.dk (0x5e9159bc.adsl.cybercity.dk [94.145.89.188]) by cicero3.cybercity.dk (Postfix) with ESMTP id 96A3A10885D for ; Sun, 8 Mar 2015 13:46:29 +0100 (CET) Received: from ns1.flipmode.dk (unknown [127.0.0.1]) by mail.flipmode.dk (Postfix) with ESMTP id 447BA1F10607 for ; Sun, 8 Mar 2015 13:46:29 +0100 (CET) X-Virus-Scanned: amavisd-new at flipmode.dk Received: from mail.flipmode.dk ([127.0.0.1]) by ns1.flipmode.dk (ns1.flipmode.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tybI8zRZlRw0 for ; Sun, 8 Mar 2015 13:46:28 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.4.168]) by mail.flipmode.dk (Postfix) with ESMTPSA id 482EE1F10606 for ; Sun, 8 Mar 2015 13:46:28 +0100 (CET) Message-ID: <54FC44A4.7050707@tomse.dk> Date: Sun, 08 Mar 2015 13:46:28 +0100 From: Carsten Jensen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "freebsd-ports@freebsd.org" Subject: pkgng deviates from defaults? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150308-0, 08-03-2015), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:20:23 -0000 It seems that pkgng deviates from installing the defaults. one of the culprits seems to be phpMyAdmin, as trying to upgrade this only it wants php56 deleting phpMyAdmin just shows I have other packages needing php56 in my system. is this a bug? and how can I prevent upgrading to the non-default php56? cheers Carsten root@myhost ~:>uname -a FreeBSD myhost 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0: Tue Jan 27 08:52:50 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 root@myhost ~:>pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (70 candidates): 77% mod_php5 has no direct installation candidates, change it to mod_php5? [Y/n]: Checking for upgrades (70 candidates): 100% Processing candidates (70 candidates): 4% php5-5.4.38 is locked and may not be modified dovecot-1.2.17_5 is locked and may not be modified apache22-2.2.29_2 is locked and may not be modified Processing candidates (70 candidates): 100% The following 88 packages will be affected (of 0 checked): New packages to be INSTALLED: php56-session: 5.6.6 php56: 5.6.6 php56-xmlrpc: 5.6.6 php56-xml: 5.6.6 php56-mysql: 5.6.6 php56-mbstring: 5.6.6 php56-ctype: 5.6.6 php56-openssl: 5.6.6 php56-mcrypt: 5.6.6_1 php56-filter: 5.6.6 php56-gd: 5.6.6 php56-json: 5.6.6 php56-mysqli: 5.6.6 php56-zlib: 5.6.6 php56-zip: 5.6.6 libzip: 0.11.2_1 php56-bz2: 5.6.6 p5-CPAN-Meta: 2.143240_1 p5-Parse-CPAN-Meta: 1.44.14_1 p5-CPAN-Meta-YAML: 0.012_1 php56-simplexml: 5.6.6 php56-tokenizer: 5.6.6 php56-gettext: 5.6.6 php56-iconv: 5.6.6 Installed packages to be UPGRADED: phpMyAdmin: 4.3.9 -> 4.3.10 php5-xsl: 5.4.37 -> 5.4.38 php5-xmlrpc: 5.4.37 -> 5.4.38 php5-xmlreader: 5.4.37 -> 5.4.38 php5-xml: 5.4.37 -> 5.4.38 php5-wddx: 5.4.37 -> 5.4.38 php5-tokenizer: 5.4.37 -> 5.4.38 php5-simplexml: 5.4.37 -> 5.4.38 php5-session: 5.4.37 -> 5.4.38 From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 13:41:49 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB596263 for ; Sun, 8 Mar 2015 13:41:49 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37F22F6C for ; Sun, 8 Mar 2015 13:41:49 +0000 (UTC) Received: by widfb4 with SMTP id fb4so3408147wid.0 for ; Sun, 08 Mar 2015 06:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XUUgacWGdfIAEyhwuGGiyu8uJOPhsTdtMZBT+yoHoHE=; b=hIY2+J72/WZpF6uyN6a/agMgejoYD2tldcdgmDZj3nK2Ww87DvXMzOHkSH2xO6FZ1z pErpQRosc3+zbln2ruudk/jr7bv6WZ3JiBLuXM4ZdXrZXBQyEWf42HaNB/fmQ0MFADXF VVJ/4G7Ly0t0/gDh/sb2KWLojblzbJFtr6uYzXBcrp0grKLGLCk/XZcQLxCFiLTvA0fT Un8YHm3A9wlTKalO1ETn9H462hPos8ccoLz2TPMXRYbbwRErsWudi0v3uByjyuE0trbn r0bDQ0LCYnPAoNczbeDsvJpUFp4eaObH5ZQ4Rpc4RGYoDw/VqCdf+BW7Cclbmivu3p8L /xoQ== X-Received: by 10.180.126.98 with SMTP id mx2mr93312267wib.18.1425822107616; Sun, 08 Mar 2015 06:41:47 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fu1sm11141649wic.2.2015.03.08.06.41.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2015 06:41:46 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 8 Mar 2015 14:41:44 +0100 From: Baptiste Daroussin To: Carsten Jensen Subject: Re: pkgng deviates from defaults? Message-ID: <20150308134144.GB69925@ivaldir.etoilebsd.net> References: <54FC44A4.7050707@tomse.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <54FC44A4.7050707@tomse.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:41:49 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >=20 > It seems that pkgng deviates from installing the defaults. > one of the culprits seems to be phpMyAdmin, as trying to upgrade this > only it wants php56 > deleting phpMyAdmin just shows I have other packages needing php56 in my > system. >=20 > is this a bug? and how can I prevent upgrading to the non-default php56? The default settings are a ports tree setting not a pkg setting. for now the ports are hardcoding the required version into the packages, this is a lega= cy of the old system, noone has yet been working on this. so beside building your= own packages with poudriere (which will define the default you want) righ now t= here is no way to avoid that. The php case but not only php will require small changes in pkg(8) to activ= ate smart dependencies: depend on a>1<=3D2.10 and also adding provides/requires= (this is not very hard to be added in pkg.) and it should also require heavy chan= ges on the port side! As far as I know noone has been working on those changes in the port side. = the pkg(8) changes are mostly pending for real use cases in the port side. Mean= ing both should be coordinated. Best regards, Bapt --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlT8UZgACgkQ8kTtMUmk6Eys5ACgsOAshFVLLpF9vJ459zued2Hr nS4AnA6mmtp/ps4hOTOkcepDSMXxBxHv =96Zg -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 16:42:17 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3DD7CAB for ; Sun, 8 Mar 2015 16:42:17 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A921D23A for ; Sun, 8 Mar 2015 16:42:17 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 2F99E160275; Sun, 8 Mar 2015 09:42:16 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id C4B1016014C for ; Sun, 8 Mar 2015 09:42:13 -0700 (MST) Message-ID: <54FC7BE5.7010106@pinyon.org> Date: Sun, 08 Mar 2015 09:42:13 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Single worst bug for ports: lang/gcc* doesn't support c++11 References: <54FB8656.8060502@rawbw.com> <54FBDDE0.6090806@pinyon.org> <54FBEE00.6060501@rawbw.com> In-Reply-To: <54FBEE00.6060501@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:42:17 -0000 On 03/07/15 23:36, Yuri wrote: > On 03/07/2015 21:28, Russell L. Carter wrote: >> >> I would like to understand better the problem here, because I use c++11 >> features heavily with lang/gcc49 on a daily basis with zero problems. > > No, gcc-4.9.3 fails in the same way. Specific missing feature: > std::snprintf > > error: 'snprintf' is not a member of 'std' Ok, I can confirm missing std::to_string in lang/g++49, fixed with -D_GLIBCXX_USE_C99. In /usr/local/lib/gcc49/include/c++/bits/basic_string.h std::to_string() and company are convenience wrappers for the c conversion functions, and according to: https://gcc.gnu.org/ml/libstdc++/2013-10/msg00246.html this would seem like a bug in the process the gnu c and c++ people use to manage "newlib" development versioning. Lots of other folk (netbsd, cygwin, arm) are complaining too. I can understand the porting aggravation but I'm not sure that there are no bugs lurking in any of that code protected by the #ifdef, so just eliding it doesn't seem zero-risk. Russell > Yuri > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 16:49:33 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8E04E16; Sun, 8 Mar 2015 16:49:33 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C25E276; Sun, 8 Mar 2015 16:49:33 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t28GnMs3007588 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2015 09:49:23 -0700 Message-ID: <54FC7D92.3010405@freebsd.org> Date: Sun, 08 Mar 2015 09:49:22 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Millard , freebsd-ports@freebsd.org, FreeBSD PowerPC ML Subject: Re: powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Sonic-CAuth: UmFuZG9tSVbK0E+jwd3Zn/SJMDljKko7INoP5NuObMFbdZTJFJse+sf9IriLn6fET45q0b0Mv0Sz+lCuRnnjJF2RiqFONk7MXdMTqzBMYus= X-Sonic-ID: C;PIFJErPF5BGmQO8Jj30JFw== M;MPG3ErPF5BGmQO8Jj30JFw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:49:33 -0000 This works fine for me. Are you sure you don't have some weird=20 configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): > > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc > > Ports Revision 380683 via svnlite update. I've been using portmaster. > > > The problem (which I've not figured out yet)... > > When png-1.6.16 has PNGTEST enabled (default and "recommended") it trie= s to use cmake's /usr/local/bin/ctest. But in my context ctest is broken,= trying to reserve 2305843009213693952 Hashtable_node<...>*'s [see #8's .= =2E.::reserve (..., __n=3D...) below] when _M_initialize_buckets(..., __n= =3D100) in #9. (Note: 2305843009213693952 =3D=3D 0x2000000000000000.) I h= ave yet to figure out how that magic number is becoming involved. See bel= ow from one of the crash dumps: > > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in ._ZN9__gnu_cxx27__verbose_terminate_handlerEv= () from /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from /usr/lib/l= ibsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from /usr/lib/libsupc++.s= o.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from /usr/l= ib/libstdc++.so.6 > #8 0x000000001024659c in std::vector >*, std::allocator >*> >::reserve (= this=3D0xffffffffffffb108, __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, cmsys::hash_= select1st, std::equal_to, std::allocator >::_M_initialize_buckets (this=3D0xffffffffffff= b100, __n=3D100) at hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, __n=3D1= 00, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, __a=3D@0xfff= fffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at hash_= map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, par= ent=3D0x0) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/S= ource/cmDefinitions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at /usr/obj/po= rtswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefile.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator (this=3D= 0x51c3f480, gg=3D0xffffffffffffc138) at /usr/obj/portswork/usr/ports/deve= l/cmake/work/cmake-3.1.3/Source/cmLocalGenerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator (this= =3D0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/c= make-3.1.3/Source/cmGlobalGenerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize (this=3D0xffffffffffffcf5= 0, binary_dir=3D0x51c890f8 "/usr/obj/portswork/usr/ports/graphics/png/wor= k/libpng-1.6.16", command=3D0x0) > at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Sourc= e/cmCTest.cxx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, args= =3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at /usr/obj/portswor= k/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at /usr/ob= j/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx:189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 > > The specific Makefile code to invoke ctest is... > > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cy= an "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > =20 > # Special rule for the target test > test/fast: test > .PHONY : test/fast > > which because of ctest's problem leads to... > > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/wo= rk XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work HOM= E=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" XDG_DA= TA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work XDG_CONFIG_HOME= =3D/usr/obj/portswork/usr/ports/graphics/png/work HOME=3D/usr/obj/portsw= ork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" DONTSTRIP=3Dyes NO_PIE=3D= yes SHELL=3D/bin/sh NO_LINT=3DYES PREFIX=3D/usr/local LOCALBASE=3D/usr/l= ocal LIBDIR=3D"/usr/lib" CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-alia= sing" CPP=3D"cpp" CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXX= FLAGS=3D"-pipe -g -fno-strict-aliasing " MANPREFIX=3D"/usr/local" BSD_IN= STALL_PROGRAM=3D"install -o root -g wheel -m 555" BSD_INSTALL_LIB=3D"i= nstall -o root -g wheel -m 444" BSD_INSTALL_SCRIPT=3D"install -o root= -g wheel -m 555" BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644"= BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 DESTDIR=3D/usr/obj/p= ortswork/usr/ports/graphics/png/work/stage test; then if [ x !=3D xTry t= o set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to = the maintainer. ] ; then echo "=3D=3D=3D> Compilation failed unexpectedl= y."; (echo Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reportin= g the failure to the maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi= ) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 > > make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libp= ng-1.6.16 > 1 error > > make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libp= ng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 > > Stop. > make: stopped in /usr/ports/graphics/png > > > Even just ctest as a command gets the vector::reserve size problem from= the large magic number: > > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > > > [So far I've only sidestepped having graphic/png run ctest to allow som= e things that depend on graphics/png to not be blocked by this.] > > > > > For my context the overall environment has (but ports might force other= ports as alternatives to): > > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D > > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG > > # which cc > /usr/bin/cc > > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is= NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURP= OSE. > > # which clang > /usr/bin/clang > > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 2014051= 2 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix > > > > > > Other context details: > > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) > > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable > > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif > > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|= ' \ > ${WRKSRC}/configure > > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) > > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c > > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoi= d intermittent boot problems. > > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evi= dence if I do end up with another early-boot failure. DDB and GDB are lis= ted in sys/powerpc/conf/GENERIC64vtsc for the same reason. > > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a DM= A request size. > > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both v= t and sc. It includes the standard GENERIC64. > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 16:51:07 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AA5569; Sun, 8 Mar 2015 16:51:07 +0000 (UTC) Received: from a27-38.smtp-out.us-west-2.amazonses.com (a27-38.smtp-out.us-west-2.amazonses.com [54.240.27.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC9E0289; Sun, 8 Mar 2015 16:51:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=hsbnp7p3ensaochzwyq5wwmceodymuwv; d=amazonses.com; t=1425832700; h=References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To:Feedback-ID; bh=MZnXMb+nxbLFkihR9a2FPPQUH37TKnEtZ+9heJ097FQ=; b=jCyG9G/JrH8mLYOILYZFxcRc4LfjvomjToRNJCTF5M76vv6HK8eIls7/O7MhG/ul MWfA5IuWKmDlUi2+Ltp3wcCpFH62hvkXcgDwpTvc0mXeVNnWWONa+hMOobFy1Yl2nhE lBikAXhbr5UldJT+8T90ogzGeulJvADNLKjd8pgI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=7iuvfuckmdjngkit3px46zmjutqvp75o; d=vmeta.jp; t=1425832700; h=References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; bh=MZnXMb+nxbLFkihR9a2FPPQUH37TKnEtZ+9heJ097FQ=; b=eVV2ASNlB8p/IHdbdYEZXXEEB084t3IuUJA1u9AX4qVK3mbV27zAgLG5Rg+DRqxu tskjl3EubCv3AGnZj1Iuja7kiWWM64sQaiQnd3J33eSPBO2oUawSwm6dPs64doXAHFI 2Ldtd/lqU/1C77k1jkK2nDHgpvPHujw5EZ0wcq+M= References: <0000014bc67d7e70-7e53f2f6-3f62-4eb2-a1ac-22bc8f082a63-000000@us-west-2.amazonses.com> <0000014be94141b2-60d1f70b-ffcb-40dc-9b0f-3c9e0001b436-000000@us-west-2.amazonses.com> <20150305142416.GA18371@mouf.net> Mime-Version: 1.0 (1.0) In-Reply-To: <20150305142416.GA18371@mouf.net> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <0000014bfa406944-0cf8abb8-f456-4565-893b-4d3c52e2a7ea-000000@us-west-2.amazonses.com> X-Mailer: iPhone Mail (12B466) From: kiwao Subject: Re: rubygems not working with ruby 2.2? Date: Sun, 8 Mar 2015 16:38:20 +0000 To: Steve Wills X-SES-Outgoing: 2015.03.08-54.240.27.38 Feedback-ID: 1.us-west-2.ngRt4x2U/cWqug8pbfjwMxB6pcDw1fmN73bGmMLYyRI=:AmazonSES Cc: "ports@freebsd.org" , "ruby@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:51:07 -0000 Hi, Steve Thanks for your work and information. I'm waiting it'll be committed. 2015/03/05 23:24$B!"(BSteve Wills $B$N%a%C%;!<%8(B: > Hi, > > Yep, I'm aware, there's an update to devel/ruby-gems pending, see: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197083 > > Steve > >> On Thu, Mar 05, 2015 at 09:25:43AM +0000, Koichiro IWAO wrote: >> Reproduced in clean environment. >> >> I think devel/ruby-gems is too old and needs updating. >> ports version is 1.8.30 and the latest rubygems release is 2.4.6[1]. >> >> [1] https://github.com/rubygems/rubygems/releases >> >> # confirm default ruby version is set to 2.2 >> grep DEFAULT_VERSIONS /etc/make.conf >> DEFAULT_VERSIONS= ruby=2.2 perl5=5.20 >> >> # remove all pkgs >> pkg remove -fa >> >> # update ports tree >> portsnap fetch update >> >> # install ruby and some rubygem- ports >> make -C /usr/ports/lang/ruby22 >> make -C /usr/ports/devel/rubygem-rake >> (snip) >> ===> rubygem-rake-10.4.2 depends on file: /usr/local/bin/gem22 - found >> ===> rubygem-rake-10.4.2 depends on file: /usr/local/bin/ruby22 - >> found >> ===> Configuring for rubygem-rake-10.4.2 >> ===> Building for rubygem-rake-10.4.2 >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1960:in >> `block (2 levels) in to_yaml': stack level too deep (SystemStackError) >> from /usr/local/lib/ruby/2.2/psych/coder.rb:36:in `map' >> from >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1959:in >> `block in to_yaml' >> from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `call' >> from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `block in >> quick_emit' >> from >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1960:in >> `block (2 levels) in to_yaml' >> from /usr/local/lib/ruby/2.2/psych/coder.rb:36:in `map' >> from >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1959:in >> `block in to_yaml' >> from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `call' >> ... 9619 levels... >> from >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/command_manager.rb:147:in >> `process_args' >> from >> /usr/local/lib/ruby/site_ruby/2.2/rubygems/command_manager.rb:117:in >> `run' >> from /usr/local/lib/ruby/site_ruby/2.2/rubygems/gem_runner.rb:65:in >> `run' >> from /usr/local/bin/gem22:30:in `
' >> ===> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure >> to >> the maintainer. >> *** Error code 1 >> >> -- >> `whois vmeta.jp | nkf -w` >> meta >> _______________________________________________ >> freebsd-ruby@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ruby >> To unsubscribe, send any mail to "freebsd-ruby-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 16:53:11 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10007151; Sun, 8 Mar 2015 16:53:11 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E706E34E; Sun, 8 Mar 2015 16:53:10 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t28Gr7PN009329 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2015 09:53:07 -0700 Message-ID: <54FC7E73.4040205@freebsd.org> Date: Sun, 08 Mar 2015 09:53:07 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Millard , freebsd-ports@freebsd.org, FreeBSD PowerPC ML Subject: Re: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYaSoLZHX0ZO4lybtuPGLfiw28PPFjc5VYjQgyLz9tBg7qZzK+vm0kvfUxF2oNUhdQzicKuZx06Es3SpyOVrVc30DMkH5EMJAQ= X-Sonic-ID: C;XsJLmLPF5BG3NL5YxQPdhw== M;SH2ImLPF5BG3NL5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:53:11 -0000 This builds without issue for me, both on a G5 system and on a POWER8. -Nathan On 03/07/15 22:16, Mark Millard wrote: > powerpc64 context (more details are listed later): > > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc > > Ports Revision 380683 via svnlite update. I've been using portmaster. > > > The problem (which I've not figured out yet)... > > x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, and x11-wm/xfce4 are all blocked from building by sysutils/polkit failing to build because of a broken pipe with a subprocess... > > ... > gmake all-am > gmake[6]: Entering directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > CC libpolkit_gobject_1_la-polkitenumtypes.lo > CC libpolkit_gobject_1_la-polkitactiondescription.lo > CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo > CC libpolkit_gobject_1_la-polkitdetails.lo > CC libpolkit_gobject_1_la-polkitauthority.lo > CC libpolkit_gobject_1_la-polkiterror.lo > CC libpolkit_gobject_1_la-polkitsubject.lo > CC libpolkit_gobject_1_la-polkitunixprocess.lo > CC libpolkit_gobject_1_la-polkitsystembusname.lo > CC libpolkit_gobject_1_la-polkitidentity.lo > CC libpolkit_gobject_1_la-polkitunixuser.lo > CC libpolkit_gobject_1_la-polkitunixgroup.lo > CC libpolkit_gobject_1_la-polkitunixnetgroup.lo > CC libpolkit_gobject_1_la-polkitauthorizationresult.lo > CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo > CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo > CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo > CC libpolkit_gobject_1_la-polkitpermission.lo > CC libpolkit_gobject_1_la-polkitunixsession.lo > CCLD libpolkit-gobject-1.la > GISCAN Polkit-1.0.gir > Traceback (most recent call last): > File "/usr/local/bin/g-ir-scanner", line 55, in > sys.exit(scanner_main(sys.argv)) > File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", line 517, in scanner_main > ss = create_source_scanner(options, args) > File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", line 430, in create_source_scanner > ss.parse_files(filenames) > File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line 256, in parse_files > self._parse(headers) > File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line 302, in _parse > proc.stdin.write('#ifndef %s\n' % (define, )) > IOError: [Errno 32] Broken pipe > /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: recipe for target 'Polkit-1.0.gir' failed > gmake[6]: *** [Polkit-1.0.gir] Error 1 > gmake[6]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > Makefile:444: recipe for target 'all' failed > gmake[5]: *** [all] Error 2 > gmake[5]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > Makefile:326: recipe for target 'all-recursive' failed > gmake[4]: *** [all-recursive] Error 1 > gmake[4]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' > Makefile:374: recipe for target 'all-recursive' failed > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' > Makefile:305: recipe for target 'all' failed > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/sysutils/polkit > *** Error code 1 > > Stop. > make: stopped in /usr/ports/sysutils/polkit > > ===>>> make build failed for sysutils/polkit > ===>>> Aborting update > > > ===>>> You can restart from the point of failure with this command line: > portmaster sysutils/polkit > > The relevant /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code being... > > def _parse(self, filenames): > if not filenames: > return > > defines = ['__GI_SCANNER__'] > undefs = [] > cpp_args = os.environ.get('CC', 'cc').split() # support CC="ccache gcc" > if 'cl' in cpp_args: > # The Microsoft compiler/preprocessor (cl) does not accept > # source input from stdin (the '-' flag), so we need > # some help from gcc from MinGW/Cygwin or so. > # Note that the generated dumper program is > # still built and linked by Visual C++. > cpp_args = ['gcc'] > cpp_args += os.environ.get('CPPFLAGS', '').split() > cpp_args += os.environ.get('CFLAGS', '').split() > cpp_args += ['-E', '-C', '-I.', '-'] > cpp_args += self._cpp_options > > proc = subprocess.Popen(cpp_args, > stdin=subprocess.PIPE, > stdout=subprocess.PIPE) > > for define in defines: > proc.stdin.write('#ifndef %s\n' % (define, )) > proc.stdin.write('# define %s\n' % (define, )) > proc.stdin.write('#endif\n') > ... > > For my context the overall environment has (but ports might force other ports as alternatives to): > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > MALLOC_PRODUCTION= > > # more /etc/src.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > #CFLAGS+=-DELF_VERBOSE > #WITH_DEBUG_FILES= > #WITHOUT_CLANG > > # which cc > /usr/bin/cc > > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > # which clang > /usr/bin/clang > > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix > > > > > > Other context details: > > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) > > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable > > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =================================================================== > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=--enable-vdpau > .endif > > +.if ${ARCH} == powerpc64 > +CFLAGS+= -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|' \ > ${WRKSRC}/configure > > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) > > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c > > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid intermittent boot problems. > > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evidence if I do end up with another early-boot failure. DDB and GDB are listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. > > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer size for dumps to be small enough not to be rejected as too large of a DMA request size. > > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 19:02:41 2015 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E90B2A; Sun, 8 Mar 2015 19:02:41 +0000 (UTC) Received: from smtp.kn-bremen.de (gruenbaer.kn-bremen.de [148.251.8.79]) by mx1.freebsd.org (Postfix) with ESMTP id BADB76E3; Sun, 8 Mar 2015 19:02:40 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 8D5FE3DE0E12; Sun, 8 Mar 2015 20:02:33 +0100 (CET) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id t28J1FBT096085; Sun, 8 Mar 2015 20:01:15 +0100 (CET) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id t28J1D0Y096084; Sun, 8 Mar 2015 20:01:13 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sun, 8 Mar 2015 20:01:13 +0100 To: freebsd-multimedia@FreeBSD.org, freebsd-ports@FreeBSD.org Subject: CFT: vlc 2.2.0 Message-ID: <20150308190113.GA96042@enceladus10.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:02:41 -0000 Hi! I just saw vlc 2.2.0 is out and updated the port, please test: https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch I had to remove one dvb ioctl because of a missing #define (v4l_compat too old, the update of that btw, https://reviews.freebsd.org/D1482 is stuck because is breaks firefox etc), so if someone could confirm dvb-t still does something in vlc that would be useful for example... Thanx! :) Juergen From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 19:24:19 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2953AF23 for ; Sun, 8 Mar 2015 19:24:19 +0000 (UTC) Received: from apnoea.adamw.org (apnoea.adamw.org [204.109.59.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "adamw.org", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD9C3954 for ; Sun, 8 Mar 2015 19:24:18 +0000 (UTC) Received: by apnoea.adamw.org (OpenSMTPD) with ESMTPSA id e520ff6b; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; for ; Sun, 8 Mar 2015 13:24:10 -0600 (MDT) From: Adam Weinberger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WITH_OPENSSL_PORT documentation Message-Id: Date: Sun, 8 Mar 2015 13:24:09 -0600 To: ports@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:24:19 -0000 Can somebody please write something---anything, even 2 sentences---for = the PHB about how to use WITH_OPENSSL_PORT? What users should set it to = to get LibreSSL for example, and what porters are supposed to put in the = Makefile to support it? The text at the top of bsd.openssl.mk just shows WITH_OPENSSL_PORT=3Dyes. = A few sentences would be a big help, and I'm sure the doc people would = be happy to take care of all the markup and formatting for you. # Adam --=20 Adam Weinberger adamw@adamw.org http://www.adamw.org From owner-freebsd-ports@FreeBSD.ORG Sun Mar 8 20:14:39 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76C72259 for ; Sun, 8 Mar 2015 20:14:39 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3716DF20 for ; Sun, 8 Mar 2015 20:14:39 +0000 (UTC) Received: by iery20 with SMTP id y20so4712225ier.0 for ; Sun, 08 Mar 2015 13:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cz/lrrgehEdww1+Q3F8akvMLAqhP7CwkWK1pzGoq9S8=; b=B68fh9gIVVxLu426w5/jXH0Qxul92q4HOal8cCVWz7Bjp+k8YrQSbnmTRKBZqPQgvG bKz8vT0hlKH0HC6ySaF6IisnkStWhrzVFXQYDo+efQjvaYGRh5UkIjflGpYy3xz47t8c STbIHWGm4Sl4PsAp9YJ5PzflBmRWoxmpnM5nzlfDU2/Gs0TFZuL+0TjCZvQzYaUeQBVj Kge2O9ycoTPZS0alDwQi2KHL474sL5trC8kjVwFvwBs+34fRVg0urqZWrp8xdWxVWgpb lpTiPloitMwJ13O2KalTkhkxmiK5Yoo1iHM3MnAQyjGg0zXGJbe2UvtIkzbYR/Wasz2m fgPw== MIME-Version: 1.0 X-Received: by 10.42.120.2 with SMTP id d2mr21978062icr.5.1425845678555; Sun, 08 Mar 2015 13:14:38 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Sun, 8 Mar 2015 13:14:38 -0700 (PDT) In-Reply-To: <20150306083910.01816db8@rsbsd.rsb> References: <20141213202855.3a7c3dd9@rsbsd.rsb> <20141214102218.10c8447b@X220.alogt.com> <20150302165721.23f224e2@rsbsd.rsb> <20150305182852.0fc8a31f@rsbsd.rsb> <20150306083910.01816db8@rsbsd.rsb> Date: Sun, 8 Mar 2015 13:14:38 -0700 X-Google-Sender-Auth: 4fQlj_fMnZzK74QPJ0xrjdqjyIQ Message-ID: Subject: Re: devel/dbus no longer starts at system poweron From: Kevin Oberman To: Beeblebrox Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 20:14:39 -0000 On Thu, Mar 5, 2015 at 10:39 PM, Beeblebrox wrote: > > Just to let you know, I have not forgotten your issue. Just have not > > gotten to it > > No worries. As you saw on the thread on current, this is really the least > of my woes with X.org. > > > The output you provided will at least get me started, but I really > > need the full rcorder output. > > > https://drive.google.com/file/d/0Bxs_eepbMt6qRkQ3YmJlR2FkcVk/view?usp=sharing > > I can attempt to sort through parts of it if you give me some idea of > howto / what to look for. > > Regards. > -- > FreeBSD_amd64_11-Current_RadeonKMS > Please CC my email when responding, mail from list is not delivered. > Someone found it before it did. Looks like the issue is most likely devd which requires ldconfig or no obvious reason. (It's static.) Take a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198429. I am not entirely convinced that there are not some other issues that are causing this type of error, but this is at least one of them. Most are probably port issues, but this one is in the base system. Ouch! From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 01:19:03 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDAAB5CC for ; Mon, 9 Mar 2015 01:19:03 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1821F5 for ; Mon, 9 Mar 2015 01:19:02 +0000 (UTC) Received: from ppp118-210-136-81.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.136.81]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Mar 2015 11:43:53 +1030 Message-ID: <54FCF3CB.2010301@ShaneWare.Biz> Date: Mon, 09 Mar 2015 11:43:47 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adam Weinberger , ports@FreeBSD.org Subject: Re: WITH_OPENSSL_PORT documentation References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 01:19:03 -0000 On 09/03/2015 05:54, Adam Weinberger wrote: > Can somebody please write something---anything, even 2 > sentences---for the PHB about how to use WITH_OPENSSL_PORT? What > users should set it to to get LibreSSL for example, and what porters > are supposed to put in the Makefile to support it? > > The text at the top of bsd.openssl.mk just shows > WITH_OPENSSL_PORT=yes. A few sentences would be a big help, and I'm > sure the doc people would be happy to take care of all the markup and > formatting for you. > > # Adam I looked at it a few of days ago and didn't think there was an issue. bsd.openssl.mk has - # Use of 'USE_OPENSSL=yes' includes this Makefile after bsd.ports.pre.mk # # the user/port can now set this options in the makefiles. # # WITH_OPENSSL_BASE=yes - Use the version in the base system. # WITH_OPENSSL_PORT=yes - Use the OpenSSL port, even if base is up to date # # USE_OPENSSL_RPATH=yes - Pass RFLAGS options in CFLAGS, # needed for ports who don't use LDFLAGS # # Overrideable defaults: # # OPENSSL_SHLIBVER= 8 # OPENSSL_PORT= security/openssl If you specifically want to use the base or port ssl you set either WITH_OPENSSL_BASE=yes or WITH_OPENSSL_PORT=yes. If you want a specific ssl variation you can set OPENSSL_PORT to the port you want to use. The default is security/openssl So if you want to use libressl then you set WITH_OPENSSL_PORT=yes and OPENSSL_PORT=security/libressl Porters should put USE_OPENSSL=yes in their Makefile, other settings should only be added if necessary, leave the other options to the user. -- FreeBSD - the place to B...Securing Domains Shane Ambler From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 01:35:11 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F9DB891 for ; Mon, 9 Mar 2015 01:35:11 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02AB23E3 for ; Mon, 9 Mar 2015 01:35:10 +0000 (UTC) Received: (qmail 2023 invoked from network); 9 Mar 2015 01:35:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 01:35:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 21:35:08 -0400 (EDT) Received: (qmail 17845 invoked from network); 9 Mar 2015 01:35:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 01:35:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 67FEF1C405E; Sun, 8 Mar 2015 18:34:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: <54FC7D92.3010405@freebsd.org> Date: Sun, 8 Mar 2015 18:35:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FC7D92.3010405@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 01:35:11 -0000 Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) = --cyan "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 03:23:37 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 298F370A for ; Mon, 9 Mar 2015 03:23:37 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D269019C for ; Mon, 9 Mar 2015 03:23:36 +0000 (UTC) Received: (qmail 8570 invoked from network); 9 Mar 2015 03:23:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 03:23:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 23:23:35 -0400 (EDT) Received: (qmail 10037 invoked from network); 9 Mar 2015 03:23:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 03:23:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 4FD6A1C43A2; Sun, 8 Mar 2015 20:23:28 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc (non-64) 10.1-STABLE context: CXXLD mesa_dri_drivers.la gets c++: Internal error: Segmentation fault (program ld) Message-Id: <55D5E445-4018-488D-B776-9CA5A062A904@dsl-only.net> Date: Sun, 8 Mar 2015 20:23:32 -0700 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 03:23:37 -0000 Basic context information (more details later): # freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG4S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Sun Mar 8 = 14:09:34 PDT 2015 = root@FBSDG4S0:/usr/obj/powerpc.powerpc/usr/src/sys/GENERICvtsc powerpc This variant of powerpc GENERIC (not GENERIC64) was running on a = PowerMac G5 Quad-Core, not that I expect that matters for the below. The problem: For the above powerpc port-build context graphics/dri failed to build = because of a segmentation fault during a CXXLD mesa_dri_drivers.la . ... =3D=3D=3D>>> Launching child to install graphics/dri =3D=3D=3D>>> x11/xorg 13/16 >> graphics/dri (1/212) portmaster: x11/xorg 13/16 >> graphics/dri (1/212) =3D=3D=3D>>> Port directory: /usr/ports/graphics/dri =3D=3D=3D>>> Starting check for all dependencies =3D=3D=3D>>> Gathering dependency list for graphics/dri from ports =3D=3D=3D>>> Dependency check complete for graphics/dri =3D=3D=3D>>> x11/xorg 13/16 >> graphics/dri (1/212) portmaster: x11/xorg 13/16 >> graphics/dri (1/12) =3D=3D=3D> Cleaning for dri-10.4.5,2 ... CC swrast.lo CCLD libswrast_dri.la gmake[7]: Leaving directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri/swrast' gmake[7]: Entering directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri' cd ../../../.. && gmake am--refresh cd ../../../.. && gmake am--refresh CXXLD mesa_dri_drivers.la c++: Internal error: Segmentation fault (program ld) Please submit a full bug report. See for instructions. Makefile:651: recipe for target 'mesa_dri_drivers.la' failed gmake[7]: *** [mesa_dri_drivers.la] Error 1 gmake[7]: Leaving directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri' Makefile:737: recipe for target 'all-recursive' failed gmake[6]: *** [all-recursive] Error 1 ... Other context details: $ cd /usr/src $ svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279507 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 279507 Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) $ svnlite st --no-ignore ? .snap ? restoresymtable M sys/ddb/db_main.c M sys/ddb/db_script.c I sys/powerpc/conf/GENERIC64vtsc I sys/powerpc/conf/GENERICvtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powerpc/dump_machdep.c sys/powerpc/ofw/ofw_machdep.c has a powerpc64 PowerMac G5 specific = change to avoid intermittent boot problems. For powerpc the #if = structure avoids the change. sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. But here = ofwcall64.S was not in use and I've not yet put such an addition into = ofwcall.S . DDB and GDB are listed in sys/powerpc/conf/GENERICvtsc for = the same reason. sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. sys/powerpc/conf/GENERICvtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC. # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D # more /etc/src.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc-unknown-freebsd10.1 Thread model: posix There is no port-based gcc/g++ or clang present. $ cd /usr/ports $ svnlite info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 380683 Node Kind: directory Schedule: normal Last Changed Author: demon Last Changed Rev: 380683 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) $ svnlite st --no-ignore ? .snap I distfiles M graphics/libGL/bsd.mesalib.mk I packages ? restoresymtable $ svnlite diff graphics/libGL/bsd.mesalib.mk Index: graphics/libGL/bsd.mesalib.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- graphics/libGL/bsd.mesalib.mk (revision 380683) +++ graphics/libGL/bsd.mesalib.mk (working copy) @@ -136,6 +136,10 @@ CONFIGURE_ARGS+=3D--enable-vdpau .endif +.if ${ARCH} =3D=3D powerpc64 +CFLAGS+=3D -mminimal-toc +.endif + post-patch: @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ ${WRKSRC}/configure =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 06:44:51 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9014DEB9 for ; Mon, 9 Mar 2015 06:44:51 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 424F7850 for ; Mon, 9 Mar 2015 06:44:50 +0000 (UTC) Received: (qmail 31089 invoked from network); 9 Mar 2015 06:44:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 06:44:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Mar 2015 02:44:43 -0400 (EDT) Received: (qmail 22274 invoked from network); 9 Mar 2015 06:44:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 06:44:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 0ABE21C43A2; Sun, 8 Mar 2015 23:44:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py From: Mark Millard In-Reply-To: Date: Sun, 8 Mar 2015 23:44:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML , Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 06:44:51 -0000 Nathan W. wrote: > This builds without issue for me, both on a G5 system and on a POWER8. > -Nathan I decided to "pkg delete '*'", check /usr/local/... and /var/db/pkg/..., = and start a rebuild of all my ports to see what happens. The sysutils/polkit problem was gone. Other notes: I still had to configure graphics/png to not run its tests that make use = of cmake'c ctest. (This is just for powerpc64 builds: ctest works fine = for my powerpc builds.) powerpc64's ctest builds but crashes when run. graphics/libGL/bsd.mesalib.mk needed the powerpc64 patch that I included = in my context notes. The result built and using a PowerMac G5 with video hardware that was = historically supported and the same xorg.conf from long ago for that = same context basically worked for startxfce4. I could control-option Fn to get to a console but by the time I tried to = get back after that Xorg had died/quit. This was true for both vt and = sc. My X11 related powerpc (non-64) builds were stopped by... "CXXLD mesa_dri_drivers.la" gets "c++: Internal error: Segmentation = fault (program ld)" =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-7, at 10:16 PM, Mark Millard wrote: powerpc64 context (more details are listed later): $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, = and x11-wm/xfce4 are all blocked from building by sysutils/polkit = failing to build because of a broken pipe with a subprocess... ... gmake all-am gmake[6]: Entering directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' CC libpolkit_gobject_1_la-polkitenumtypes.lo CC libpolkit_gobject_1_la-polkitactiondescription.lo CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo CC libpolkit_gobject_1_la-polkitdetails.lo CC libpolkit_gobject_1_la-polkitauthority.lo CC libpolkit_gobject_1_la-polkiterror.lo CC libpolkit_gobject_1_la-polkitsubject.lo CC libpolkit_gobject_1_la-polkitunixprocess.lo CC libpolkit_gobject_1_la-polkitsystembusname.lo CC libpolkit_gobject_1_la-polkitidentity.lo CC libpolkit_gobject_1_la-polkitunixuser.lo CC libpolkit_gobject_1_la-polkitunixgroup.lo CC libpolkit_gobject_1_la-polkitunixnetgroup.lo CC libpolkit_gobject_1_la-polkitauthorizationresult.lo CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo CC libpolkit_gobject_1_la-polkitpermission.lo CC libpolkit_gobject_1_la-polkitunixsession.lo CCLD libpolkit-gobject-1.la GISCAN Polkit-1.0.gir Traceback (most recent call last): File "/usr/local/bin/g-ir-scanner", line 55, in sys.exit(scanner_main(sys.argv)) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 517, in scanner_main ss =3D create_source_scanner(options, args) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 430, in create_source_scanner ss.parse_files(filenames) File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", = line 256, in parse_files self._parse(headers) File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", = line 302, in _parse proc.stdin.write('#ifndef %s\n' % (define, )) IOError: [Errno 32] Broken pipe /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: = recipe for target 'Polkit-1.0.gir' failed gmake[6]: *** [Polkit-1.0.gir] Error 1 gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:444: recipe for target 'all' failed gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:326: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' Makefile:374: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' Makefile:305: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/polkit *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/polkit =3D=3D=3D>>> make build failed for sysutils/polkit =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster sysutils/polkit=20 The relevant = /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code = being... def _parse(self, filenames): if not filenames: return defines =3D ['__GI_SCANNER__'] undefs =3D [] cpp_args =3D os.environ.get('CC', 'cc').split() # support = CC=3D"ccache gcc" if 'cl' in cpp_args: # The Microsoft compiler/preprocessor (cl) does not accept # source input from stdin (the '-' flag), so we need # some help from gcc from MinGW/Cygwin or so. # Note that the generated dumper program is # still built and linked by Visual C++. cpp_args =3D ['gcc'] cpp_args +=3D os.environ.get('CPPFLAGS', '').split() cpp_args +=3D os.environ.get('CFLAGS', '').split() cpp_args +=3D ['-E', '-C', '-I.', '-'] cpp_args +=3D self._cpp_options proc =3D subprocess.Popen(cpp_args, stdin=3Dsubprocess.PIPE, stdout=3Dsubprocess.PIPE) for define in defines: proc.stdin.write('#ifndef %s\n' % (define, )) proc.stdin.write('# define %s\n' % (define, )) proc.stdin.write('#endif\n') ... For my context the overall environment has (but ports might force other = ports as alternatives to): # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D # more /etc/src.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG # which cc /usr/bin/cc # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ cd /usr/ports $ svnlite info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 380683 Node Kind: directory Schedule: normal Last Changed Author: demon Last Changed Rev: 380683 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) $ svnlite st --no-ignore ? .snap I distfiles M graphics/libGL/bsd.mesalib.mk I packages ? restoresymtable $ svnlite diff graphics/libGL/bsd.mesalib.mk Index: graphics/libGL/bsd.mesalib.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- graphics/libGL/bsd.mesalib.mk (revision 380683) +++ graphics/libGL/bsd.mesalib.mk (working copy) @@ -136,6 +136,10 @@ CONFIGURE_ARGS+=3D--enable-vdpau .endif +.if ${ARCH} =3D=3D powerpc64 +CFLAGS+=3D -mminimal-toc +.endif + post-patch: @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ ${WRKSRC}/configure $ cd /usr/src $ svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279507 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 279507 Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) $ svnlite st --no-ignore ? .snap ? restoresymtable M sys/ddb/db_main.c M sys/ddb/db_script.c I sys/powerpc/conf/GENERIC64vtsc I sys/powerpc/conf/GENERICvtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powerpc/dump_machdep.c sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid = intermittent boot problems. sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 10:08:04 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5AA6CD4 for ; Mon, 9 Mar 2015 10:08:04 +0000 (UTC) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9D97CF1C for ; Mon, 9 Mar 2015 10:08:04 +0000 (UTC) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 28C6E57C38; Mon, 9 Mar 2015 09:43:24 +0000 (UTC) Date: Mon, 9 Mar 2015 09:43:24 +0000 From: heasley To: freebsd-ports@freebsd.org Subject: Overriding binary package with local build Message-ID: <20150309094324.GA23245@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.23 (2014-03-12) Cc: heasley X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 10:08:04 -0000 If one builds a package from ports in order to use different options, for example building with postgres support instead of mysql, or builds a specific version, but otherwise utilizes binary packages, how is this indicated to 'pkg upgrade'? For example. On this system I've built gld with postgres instead of mysql and postfix with another option. The mysql dependency is coming from the binary gld with the default options. And, in theory postfix has different options, but also needs an update. So, is it possible to tell pkg(8) about the different options/local built, but still complain when a version update is necessary? # pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. ... New packages to be INSTALLED: mysql56-client: 5.6.23 Installed packages to be UPGRADED: postgresql94-server: 9.4.0 -> 9.4.1 postgresql94-client: 9.4.0 -> 9.4.1_1 postfix: 2.11.3_4,1 -> 2.11.4,1 Installed packages to be REINSTALLED: gld-1.8_2 (options changed) ... From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 10:22:39 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A516BED3 for ; Mon, 9 Mar 2015 10:22:39 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (imap.infracaninophile.co.uk [81.2.117.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 460A517E for ; Mon, 9 Mar 2015 10:22:39 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t29AL633024799 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 9 Mar 2015 10:21:14 GMT (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t29AL633024799 Authentication-Results: smtp.infracaninophile.co.uk/t29AL633024799; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <54FD740A.1000509@freebsd.org> Date: Mon, 09 Mar 2015 10:20:58 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Overriding binary package with local build References: <20150309094324.GA23245@shrubbery.net> In-Reply-To: <20150309094324.GA23245@shrubbery.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TtQQUslHbrEXQuA252fg3ottubrBqTlec" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 10:22:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TtQQUslHbrEXQuA252fg3ottubrBqTlec Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/09/15 09:43, heasley wrote: > If one builds a package from ports in order to use different options, f= or > example building with postgres support instead of mysql, or builds a > specific version, but otherwise utilizes binary packages, how is this > indicated to 'pkg upgrade'? >=20 > For example. On this system I've built gld with postgres instead of my= sql > and postfix with another option. The mysql dependency is coming from t= he > binary gld with the default options. And, in theory postfix has differ= ent > options, but also needs an update. >=20 > So, is it possible to tell pkg(8) about the different options/local bui= lt, > but still complain when a version update is necessary? >=20 > # pkg upgrade > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > ... >=20 > New packages to be INSTALLED: > mysql56-client: 5.6.23 >=20 > Installed packages to be UPGRADED: > postgresql94-server: 9.4.0 -> 9.4.1 > postgresql94-client: 9.4.0 -> 9.4.1_1 > postfix: 2.11.3_4,1 -> 2.11.4,1 >=20 > Installed packages to be REINSTALLED: > gld-1.8_2 (options changed) The best way I've found of doing this is to set up a local poudriere instance to build the packages you want to customize, plus anything that depends directly on them. You can then set your local pkgrepo as higher priority than the main FreeBSD repo in /usr/local/etc/pkg/repos/foo.conf. You might also want 'CONSERVATIVE_UPGRADE=3Dyes' in /usr/local/etc/pkg.conf A poudriere setup for building just a few packages doesn't need a whole lot of system resources. You'll need to tune poudriere.conf so it doesn't try and max out usage of everything -- maybe limit it to a single builder. You can serve the packages it builds either by HTTP, or if everything is all on the same machine, you can just use a file:///.... URL in your repo conf. Cheers, Matthew --TtQQUslHbrEXQuA252fg3ottubrBqTlec Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJU/XQLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTn8ZQQAKL/IvQeo+p5gwIDJQ7FBgK8 DjOPl/Fr0yZhjDSL/UkAegJn2c0er7XJZvEM4NuLhMbEY81MJRDI9RmyD96mENoJ zMeDFqz92/SDX826ygMTlE8iYSBYkY9fK957d5flcrfav4jVCFovymaP0Rua6BcF 9jeyWeNyUfBIKldzz6hYeeSYpfwVFAq48PLe1gdxkqsndkGvnUtEOW1Sl5eGxzuA KPGS4LOHB1v28ZJ7609pTYc45pIw/yZ/Bb3+38UWWRgZ854vJ/puYHMfu8weExb9 R0dprILk5wwkqk+KoEhd+WHsvqwI8KGZWqBMZbcWEaEmTmEE2XRdr9Ea6S3OysT2 +aKt5L4IEXhOgyapCMc0h0bbFDucDJMAKvs6MHw1KeH9DkX4vCUS9lPmtv8VbNI9 c3trGgCEZgDUWc2TN5C08K6ljluRwwzsdze+QkjJiewEKD2SNleugZ+ZkjZbMcOj fD7tU7ayfbh7MYRI1aVD+qDPWzvHe+op/fTgyDUqNsWMIKDjQ8YGgPxb+pFyskF6 XFEQUeABJhB54aAgPw4+n4K+jikpFmt4PcWwqVb0HDwDGH17Lor2bZfvQFc5zr2l z7PA5LVCeH2OA4FTvscK1i5YgQidSzP0rPlukJdu4jibzLl0UCIbJn/KGoxa9NRb 7qgfZphMCjhdFLziboj0 =0JX6 -----END PGP SIGNATURE----- --TtQQUslHbrEXQuA252fg3ottubrBqTlec-- From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 11:11:53 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B340C50E for ; Mon, 9 Mar 2015 11:11:53 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 741AD8B9 for ; Mon, 9 Mar 2015 11:11:53 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 3049356400; Mon, 9 Mar 2015 14:11:42 +0300 (MSK) Message-ID: <54FD7FEC.5080500@FreeBSD.org> Date: Mon, 09 Mar 2015 14:11:40 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Woods Subject: Re: How could I increase "runaway" timer for package build cluster? References: <54FB7119.4030208@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 11:11:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08.03.2015 12:40, Ben Woods wrote: > Actually, taking a look at my /usr/local/etc/poudriere.conf > configuration file, I see these settings have indeed been exposed > for configuration there without having to touch the poudriere code > itself. The appropriate settings are: > > # This defines the max time (in seconds) that a command may run for > a build # before it is killed for taking too long. Default: 86400 > #MAX_EXECUTION_TIME=86400 > > # This defines the time (in seconds) before a command is considered > to # be in a runaway state for having no output on stdout. Default: > 7200 #NOHANG_TIME=7200 The problem is, it is not my cluster, but FreeBSD official cluster. I could not change configs of it, I could only edit Makefile of my port. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU/X/sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTfEP/RZ+mpm4KR3ThMQsal/Aifgg d3iPz4mud6eFOeZkLzJCQplB7yWRDz12FUXY7VXx3gAqvbaNL9uEwYLhuOg7UKpS F3VeIZEl8GrBj3gO6ZtuVT+Gg4TUVMggmWuy64u73M/n+xLrsKjCKM17kyv4DpKq hYLEvJTLwWMox0l38c0/ETp6CVSqtAv5r+PE+gQZMTgH+RDufdv71Dsy3pbkJL2z M09dy9MLLa7FbfirCNh2kVSv6BHBMPxuuWntCHbs2vw619mvpf8OlNil/tt5/mip bpU0b154aNcFrXpGAZcfmFaZRBwS4XEaD70tRbnJZjleOJoDbYIRJp6Fg17ABjxs 43YumxZlwHYEABbpR4DQnUHxSeykpf3D8fcRSMD/29nHbESHcpJoscO7wvz3nP8Q Vi7pYkAJodGdhSWpHpgu/KfVGexoZgngkQPQ7/2FKR6D7Pm+wC3ilxhSRNDAJlkd F/smVWCJNrd61a64d8BTA21xeQCRQch/YXS6YpAdhSR1Y10uZuqhvugVzzv8J9S9 JRGC1PD3DoV2FjY1GK6ncP229OG06QOnqrvPp+Yg+rhlnLseNpqVh6e3Ja/rJWZ1 AWvecKGcAwSh6dhugBZ5BoPaZ8sRlF9ZD2QXW6nXDO1+EpoZK/rLTq1Z6pHL6/mD 5HYU5/UWCzoaLaIQBlwg =v5fn -----END PGP SIGNATURE----- From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 11:24:48 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C25B0663 for ; Mon, 9 Mar 2015 11:24:48 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (imap.infracaninophile.co.uk [81.2.117.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CB499B1 for ; Mon, 9 Mar 2015 11:24:47 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t29BNKhb026020 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 9 Mar 2015 11:23:20 GMT (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t29BNKhb026020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1425900200; bh=7vh6dWSqGo7n5XxpRTfpd3AJNqE/BHIv47z+75ANnig=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Mon,=2009=20Mar=202015=2011:23:19=20+0000|From:=20Matthew =20Seaman=20|To:=20freebsd-ports@ freebsd.org|Subject:=20Re:=20How=20could=20I=20increase=20"runaway "=20timer=20for=20package=20build=20cluster?|References:=20<54FB71 19.4030208@FreeBSD.org>=09=20=20<54FD7FEC.5080500@FreeBSD.or g>|In-Reply-To:=20<54FD7FEC.5080500@FreeBSD.org>; b=LBJeiuvtx4fQIReVFdIYbSfJczEIlYEYBHuFqVWacgzf3JsPcnp5Y2c5S/A1t928+ //kO/yPTdHS5OC6KphUIXUJByuaWwu9pFAaMMrbUaK4XODB+E0SFWj/HA/lINzLFVr Tyx4Gi+7SRT0grdxK9235rigehLhdKvCUPZD4uHg= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <54FD82A7.6040905@infracaninophile.co.uk> Date: Mon, 09 Mar 2015 11:23:19 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: How could I increase "runaway" timer for package build cluster? References: <54FB7119.4030208@FreeBSD.org> <54FD7FEC.5080500@FreeBSD.org> In-Reply-To: <54FD7FEC.5080500@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WJC6wOWEgbhn5Tq2pat24R0qMHxSJRaC5" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 11:24:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WJC6wOWEgbhn5Tq2pat24R0qMHxSJRaC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/09/15 11:11, Lev Serebryakov wrote: > On 08.03.2015 12:40, Ben Woods wrote: >> Actually, taking a look at my /usr/local/etc/poudriere.conf=20 >> configuration file, I see these settings have indeed been exposed >> for configuration there without having to touch the poudriere code >> itself. The appropriate settings are: >=20 >> # This defines the max time (in seconds) that a command may run for >> a build # before it is killed for taking too long. Default: 86400=20 >> #MAX_EXECUTION_TIME=3D86400 >=20 >> # This defines the time (in seconds) before a command is considered >> to # be in a runaway state for having no output on stdout. Default: >> 7200 #NOHANG_TIME=3D7200 >=20 > The problem is, it is not my cluster, but FreeBSD official cluster. I > could not change configs of it, I could only edit Makefile of my port. I added a small change to make 'pkg create' emit a progress bar which will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to enable it though. With this change I've managed to avoid poudriere timeouts while packaging stuff with large numbers of files -- texlive-texmf being a classic example. You can try it now by installing net-mgmt/pkg-devel, but beware that will eventually cause all your client machines to end up running pkg-devel too. Cheers, Matthew --WJC6wOWEgbhn5Tq2pat24R0qMHxSJRaC5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJU/YKoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnuRUQAJP/kXBE5OqTPKmL07DHvXiY tljtgqKR+aYZybX8UUjJWhuybqCxrG0LHbK/xPz0+3IOhYozJmAErQ09/lu/Crb+ UgDIzAF5YMvUe2jPjUycdxku6GOK1YorFIssvjQZPfXlr8AE/GF097tcek411Eye 8qumHTvcvb0SvRgQplCnLZ6ywkswdXYfZZJKN/4A6D8UIfIkCd+IqELIv00NB1OT gXIqY6qjg4jsfPiKLTAFuyI+PHJDbf5T6oFgav4+atq39HhnpUYedQ7tMgLCe0Q8 5hzOz60mi/Fm5ubsWgRQp7lA2AjddaBge/IbHUzSdcPGhVEyCZL7Hfndbon6oF5T 2+5aXuaG1M2OK4XCLH+Q+PK+a0Q1xjkAsp4kTaa8wiZ9wBhpAJdZjqchLCtEE1YL BQ3m6bqLXiCIfqqPLimL/qH1HVSw92L8gGZvXI7f78wGiYsvdaNjPypUsw8ZpLQY 2yQveTQm2WNvDurpNpDQpSjtNv+4FiVYf8PrRYOaJjUIr4qf3401SrjE6f15Yw+6 EG1DqbpI+CLXxDw+TgVjBQA/iKW85RzG1JVqeOEbG6SwA3okavQYdkMiFHjA+jlB IAl7L+RtAlZ19vRK42cKYv5zEIuOsFxyw/gna3Zjwq0l5aAYCq2SHDP1gNyCMBrs XaHDXE5lSxcuNDbi1eu7 =ZYF3 -----END PGP SIGNATURE----- --WJC6wOWEgbhn5Tq2pat24R0qMHxSJRaC5-- From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 11:33:09 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E772E76F for ; Mon, 9 Mar 2015 11:33:09 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69706A82 for ; Mon, 9 Mar 2015 11:33:09 +0000 (UTC) Received: by lbjb6 with SMTP id b6so34979741lbj.9 for ; Mon, 09 Mar 2015 04:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IG4po+H1NloRPowgsDjKt27sseLNoOvtE1UbpnhRkBk=; b=kiiYEV/Brh4AooqS2WV3XkGJQyvaUKmM2tNSRmW+tyhq9D7CkJd0lFKtu3LqaHrBnE KDAU5VHWr+hv2f5RvDnzh39OSOJe3Okz9rL6tyMhuI4xBDxThck/It3RMIIuZxVbs2Qv xYH0XxElSEL+BrFLmq45EmfQg1MRcaiGtarLfD/JZt7WDU0tNPVbC9mIXAkeS89ZHvQc 4n9/R/WCrKW3lwGYgJ+Fs7uIH0/7Ptx9996z6vzk8MjFtxMKQjlxqYE753w9IvDfxu+w PqlbNhhR2AH0Fgb6mWnEADo+x1urjSL9Xs+TQz4tQkvCJRS4B7NrLwCzKFRDXV8paYuB OP0g== MIME-Version: 1.0 X-Received: by 10.112.150.73 with SMTP id ug9mr25495266lbb.31.1425900787581; Mon, 09 Mar 2015 04:33:07 -0700 (PDT) Received: by 10.152.90.100 with HTTP; Mon, 9 Mar 2015 04:33:07 -0700 (PDT) Date: Mon, 9 Mar 2015 13:33:07 +0200 Message-ID: Subject: Maven 3.2.5 From: Alexander Yerenkow To: Ports FreeBSD Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 11:33:10 -0000 Could someone from committers take a look at port? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110 Thanks. -- Regards, Alexander Yerenkow From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 12:12:33 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3126124D for ; Mon, 9 Mar 2015 12:12:33 +0000 (UTC) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B0D9FEEB for ; Mon, 9 Mar 2015 12:12:31 +0000 (UTC) Received: from curlew.milibyte.co.uk ([84.92.153.232]) by avasout08 with smtp id 1Q9H1q009516WCc01Q9J3e; Mon, 09 Mar 2015 12:09:20 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KrfD2AmN c=1 sm=1 tr=0 a=lfSX4pPLp9EkufIcToJk/A==:117 a=lfSX4pPLp9EkufIcToJk/A==:17 a=D7rCoLxHAAAA:8 a=0Bzu9jTXAAAA:8 a=kj9zAlcOel0A:10 a=emO1SXQWCLwA:10 a=jfPoo7UsAAAA:8 a=AqGt406qXIJOzoXxTjcA:9 a=CjuIK1q_8ugA:10 Received: from curlew.lan ([192.168.1.13]) by curlew.milibyte.co.uk with esmtp (Exim 4.85) (envelope-from ) id 1YUwUm-0001AX-O3; Mon, 09 Mar 2015 12:09:17 +0000 Date: Mon, 9 Mar 2015 12:09:16 +0000 From: Mike Clarke To: heasley Message-ID: <20150309120916.16413dd5@curlew.lan> In-Reply-To: <20150309094324.GA23245@shrubbery.net> References: <20150309094324.GA23245@shrubbery.net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.13 X-SA-Exim-Mail-From: jmc-freebsd2@milibyte.co.uk X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on curlew.lan X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: Overriding binary package with local build Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on curlew.milibyte.co.uk) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:12:33 -0000 On Mon, 9 Mar 2015 09:43:24 +0000 heasley wrote: > For example. On this system I've built gld with postgres instead of mysql > and postfix with another option. The mysql dependency is coming from the > binary gld with the default options. And, in theory postfix has > different options, but also needs an update. pkg lock gld This will prevent gld from being updated by pkg but it will also prevent you from installing it when you rebuild it so you will need to unlock it for the duration while you're building it. See pkg-lock(8). -- Mike Clarke From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 12:14:40 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCF30369 for ; Mon, 9 Mar 2015 12:14:40 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id B7064F0A for ; Mon, 9 Mar 2015 12:14:40 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t29CEcDm082791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 9 Mar 2015 05:14:38 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <54FD8EAC.1060101@rawbw.com> Date: Mon, 09 Mar 2015 05:14:36 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ports@freebsd.org" Subject: [SUGGESTED FEATURE] USE_SVNREPO allows to build the port using only subversion repository URL Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:14:40 -0000 I came across one package which doesn't distribute source tarballs, and only offers subversion URL. I implemented the new feature USE_SVNREPO that allows to build the port in such setup. Here is what it does: * exports source from the subversion repository for specified URL/revision * resets the timestamp of every file and directory to 1970-01-01 for reproducibility * creates tarball Patch adding this feature is attached to this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198449 Yuri From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 12:23:16 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D25884AC for ; Mon, 9 Mar 2015 12:23:16 +0000 (UTC) Received: from cicero3.cybercity.dk (cicero3.cybercity.dk [212.242.43.248]) by mx1.freebsd.org (Postfix) with ESMTP id 89BBAFDD for ; Mon, 9 Mar 2015 12:23:15 +0000 (UTC) Received: from mail.flipmode.dk (0x5e9159bc.adsl.cybercity.dk [94.145.89.188]) by cicero3.cybercity.dk (Postfix) with ESMTP id 0EB8D108959 for ; Mon, 9 Mar 2015 13:23:13 +0100 (CET) Received: from ns1.flipmode.dk (unknown [127.0.0.1]) by mail.flipmode.dk (Postfix) with ESMTP id CFA0A1F10607 for ; Mon, 9 Mar 2015 13:23:12 +0100 (CET) X-Virus-Scanned: amavisd-new at flipmode.dk Received: from mail.flipmode.dk ([127.0.0.1]) by ns1.flipmode.dk (ns1.flipmode.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceEfvN4FKpAE for ; Mon, 9 Mar 2015 13:23:11 +0100 (CET) Received: from [192.168.1.211] (unknown [62.243.124.37]) by mail.flipmode.dk (Postfix) with ESMTPSA id C325C1F10606 for ; Mon, 9 Mar 2015 13:23:11 +0100 (CET) Message-ID: <54FD90AF.1030008@tomse.dk> Date: Mon, 09 Mar 2015 13:23:11 +0100 From: Carsten Jensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkgng deviates from defaults? References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> In-Reply-To: <20150308134144.GB69925@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:23:16 -0000 On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: > On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >> >> It seems that pkgng deviates from installing the defaults. >> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >> only it wants php56 >> deleting phpMyAdmin just shows I have other packages needing php56 in my >> system. >> >> is this a bug? and how can I prevent upgrading to the non-default php56? > > The default settings are a ports tree setting not a pkg setting. for now the > ports are hardcoding the required version into the packages, this is a legacy of > the old system, noone has yet been working on this. so beside building your own > packages with poudriere (which will define the default you want) righ now there > is no way to avoid that. > > The php case but not only php will require small changes in pkg(8) to activate > smart dependencies: depend on a>1<=2.10 and also adding provides/requires (this > is not very hard to be added in pkg.) and it should also require heavy changes > on the port side! > > As far as I know noone has been working on those changes in the port side. the > pkg(8) changes are mostly pending for real use cases in the port side. Meaning > both should be coordinated. > > Best regards, > Bapt > Sorry I don't think I was clear. Some applications wants php5 and some applications wants php56 when upgrading using pkg-ng. Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web based application due to this conflict. So while the upgrade happens to upgrade to php56 it also removes the other web application, as it only wants php5. Most of the applications on the server is maintained by pkg-ng, and it conflicts itself. Basically there are now 2 "default" php versions used by pkg-ng meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also tries to upgrade php5. I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin I don't know if this is expressed better, I hope so atleast. Cheers Carsten From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 14:03:02 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4736B8D9 for ; Mon, 9 Mar 2015 14:03:02 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17FB6D15 for ; Mon, 9 Mar 2015 14:03:01 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t29E4UrT043520 for ; Mon, 9 Mar 2015 07:04:30 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <54FD90AF.1030008@tomse.dk> References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net>, <54FD90AF.1030008@tomse.dk> From: "Chris H" Subject: Re: pkgng deviates from defaults? Date: Mon, 09 Mar 2015 07:04:30 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <5b05148435ae02019e0ccae218cecce5@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 14:03:02 -0000 On Mon, 09 Mar 2015 13:23:11 +0100 Carsten Jensen wrote > On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: > > On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: > >> > >> It seems that pkgng deviates from installing the defaults. > >> one of the culprits seems to be phpMyAdmin, as trying to upgrade this > >> only it wants php56 > >> deleting phpMyAdmin just shows I have other packages needing php56 in my > >> system. > >> > >> is this a bug? and how can I prevent upgrading to the non-default php56? > > > > The default settings are a ports tree setting not a pkg setting. for now > > the ports are hardcoding the required version into the packages, this is a > > legacy of the old system, noone has yet been working on this. so beside > > building your own packages with poudriere (which will define the default > > you want) righ now there is no way to avoid that. > > > > The php case but not only php will require small changes in pkg(8) to > > activate smart dependencies: depend on a>1<=2.10 and also adding > > provides/requires (this is not very hard to be added in pkg.) and it should > > also require heavy changes on the port side! > > > > As far as I know noone has been working on those changes in the port side. > > the pkg(8) changes are mostly pending for real use cases in the port side. > > Meaning both should be coordinated. > > > > Best regards, > > Bapt > > > > Sorry I don't think I was clear. > Some applications wants php5 and some applications wants php56 when > upgrading using pkg-ng. > Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web > based application due to this conflict. > > So while the upgrade happens to upgrade to php56 it also removes the > other web application, as it only wants php5. > > Most of the applications on the server is maintained by pkg-ng, and it > conflicts itself. > > Basically there are now 2 "default" php versions used by pkg-ng > meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also > tries to upgrade php5. > > I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin > > I don't know if this is expressed better, I hope so atleast. You might be able to avoid the issue you're having, by using: DEFAULT_VERSIONS+=php=5.5 in your make.conf(5) (/etc/make.conf) file. Check to see if you already have a DEFAULT_VERSIONS line there. If not simply add DEFAULT_VERSIONS+=php=5.5 you your make.conf file. If the line already exists, it is a space separated list. So simply append it to the list thusly DEFAULT_VERSIONS+=mysql=5.5 php=5.5 assuming that the entry mysql=5.5 was already listed. HTH --Chris > > > Cheers > Carsten > > > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 15:01:25 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD3C4ECE for ; Mon, 9 Mar 2015 15:01:25 +0000 (UTC) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D20C656 for ; Mon, 9 Mar 2015 15:01:25 +0000 (UTC) Received: from [78.35.140.232] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YUyx5-0005Lk-Id for freebsd-ports@freebsd.org; Mon, 09 Mar 2015 15:46:39 +0100 Date: Mon, 9 Mar 2015 15:46:39 +0100 From: Fabian Keil To: freebsd-ports@freebsd.org Subject: Re: CFT: vlc 2.2.0 Message-ID: <2d36b48f.6288711f@fabiankeil.de> In-Reply-To: <20150308190113.GA96042@enceladus10.kn-bremen.de> References: <20150308190113.GA96042@enceladus10.kn-bremen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/jp1lD98vg5F8a=Mn+M4zbXk"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:01:25 -0000 --Sig_/jp1lD98vg5F8a=Mn+M4zbXk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Juergen Lock wrote: > I just saw vlc 2.2.0 is out and updated the port, please test: >=20 > https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch Thanks for the update. I get a couple of warnings at build time: configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, = --disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, --wi= th-qt-libraries, --with-extra-includes, --with-extra-libs [...] =3D=3D=3D=3D> Running Q/A tests (stage-qa) Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consid= er trying INSTALL_TARGET=3Dinstall-strip or using ${STRIP_CMD} [... same message for the other plugins ....] The installed binary seems to mostly work as expected. The only regression I noticed so far is that vlc doesn't get the final wind= ow size right when it's started with a video file specified on the command lin= e: https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-fl= aw.jpg After going to fullscreen and back again (for example by hitting f twice) vlc uses the expected window size. Moving the window around has the same ef= fect. Loading the video through the GUI seems to work around the problem as well. I'm using a tiling window manager (i3) which could be part of the problem and I wouldn't be surprised if the problem was OS-independent. Fabian --Sig_/jp1lD98vg5F8a=Mn+M4zbXk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT9sk8ACgkQBYqIVf93VJ1/CwCfcRDSQbw+uzcM3946oZczBSq4 crgAoLYwLW+rWUfTW+8X3bTGuEcFDFKA =wt5B -----END PGP SIGNATURE----- --Sig_/jp1lD98vg5F8a=Mn+M4zbXk-- From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 15:07:53 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 198571DC for ; Mon, 9 Mar 2015 15:07:53 +0000 (UTC) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E1DB6B8 for ; Mon, 9 Mar 2015 15:07:51 +0000 (UTC) Received: from curlew.milibyte.co.uk ([84.92.153.232]) by avasout07 with smtp id 1T7h1q003516WCc01T7iUK; Mon, 09 Mar 2015 15:07:42 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=J50k7WXS c=1 sm=1 tr=0 a=lfSX4pPLp9EkufIcToJk/A==:117 a=lfSX4pPLp9EkufIcToJk/A==:17 a=D7rCoLxHAAAA:8 a=0Bzu9jTXAAAA:8 a=kj9zAlcOel0A:10 a=emO1SXQWCLwA:10 a=MbzN_Ju4AAAA:8 a=6I5d2MoRAAAA:8 a=7-BZE6Jmvrpt35C6p7IA:9 a=CjuIK1q_8ugA:10 a=AJbfRpbbn0YA:10 Received: from curlew.lan ([192.168.1.13]) by curlew.milibyte.co.uk with esmtp (Exim 4.85) (envelope-from ) id 1YUzHQ-0001W2-1C; Mon, 09 Mar 2015 15:07:40 +0000 Date: Mon, 9 Mar 2015 15:07:39 +0000 From: Mike Clarke To: Message-ID: <20150309150739.545fdec0@curlew.lan> In-Reply-To: <5b05148435ae02019e0ccae218cecce5@ultimatedns.net> References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <5b05148435ae02019e0ccae218cecce5@ultimatedns.net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.13 X-SA-Exim-Mail-From: jmc-freebsd2@milibyte.co.uk X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on curlew.lan X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: pkgng deviates from defaults? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on curlew.milibyte.co.uk) Cc: Chris H , Carsten Jensen X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:07:53 -0000 On Mon, 09 Mar 2015 07:04:30 -0700 "Chris H" wrote: > You might be able to avoid the issue you're having, by using: > DEFAULT_VERSIONS+=php=5.5 > in your make.conf(5) (/etc/make.conf) file. As far as I know this won't have any effect on pkg. If the OP wishes to use pkg then the only option is to switch to using php5.6. This will involve uninstalling all the php5.5 packages and reinstalling default php5.6 versions. I went through this process recently and described the steps involved in questions@ -- Mike Clarke From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 15:09:19 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FB8029A for ; Mon, 9 Mar 2015 15:09:19 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14F326D6 for ; Mon, 9 Mar 2015 15:09:19 +0000 (UTC) Received: (qmail 21819 invoked from network); 9 Mar 2015 15:09:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 15:09:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Mar 2015 11:09:10 -0400 (EDT) Received: (qmail 9129 invoked from network); 9 Mar 2015 15:09:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 15:09:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 3C613B1E002; Mon, 9 Mar 2015 08:09:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: Date: Mon, 9 Mar 2015 08:09:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> References: <54FC7D92.3010405@freebsd.org> To: Nathan Whitehorn , freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:09:19 -0000 I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) = --cyan "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 15:44:03 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0C2FEBD for ; Mon, 9 Mar 2015 15:44:03 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id B8081B75 for ; Mon, 9 Mar 2015 15:44:03 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 71E112E4EC for ; Mon, 9 Mar 2015 11:44:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctex4h0YbbM7 for ; Mon, 9 Mar 2015 11:44:01 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <54FDBFC0.1090403@egr.msu.edu> Date: Mon, 09 Mar 2015 11:44:00 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkgng deviates from defaults? References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> In-Reply-To: <54FD90AF.1030008@tomse.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:44:04 -0000 On 03/09/2015 08:23, Carsten Jensen wrote: > On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>> >>> It seems that pkgng deviates from installing the defaults. >>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>> only it wants php56 >>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>> system. >>> >>> is this a bug? and how can I prevent upgrading to the non-default php56? >> >> The default settings are a ports tree setting not a pkg setting. for >> now the >> ports are hardcoding the required version into the packages, this is a >> legacy of >> the old system, noone has yet been working on this. so beside building >> your own >> packages with poudriere (which will define the default you want) righ >> now there >> is no way to avoid that. >> >> The php case but not only php will require small changes in pkg(8) to >> activate >> smart dependencies: depend on a>1<=2.10 and also adding >> provides/requires (this >> is not very hard to be added in pkg.) and it should also require heavy >> changes >> on the port side! >> >> As far as I know noone has been working on those changes in the port >> side. the >> pkg(8) changes are mostly pending for real use cases in the port side. >> Meaning >> both should be coordinated. >> >> Best regards, >> Bapt >> > > Sorry I don't think I was clear. > Some applications wants php5 and some applications wants php56 when > upgrading using pkg-ng. > Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web > based application due to this conflict. > > So while the upgrade happens to upgrade to php56 it also removes the > other web application, as it only wants php5. > > Most of the applications on the server is maintained by pkg-ng, and it > conflicts itself. > > Basically there are now 2 "default" php versions used by pkg-ng > meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also > tries to upgrade php5. > > I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin > > I don't know if this is expressed better, I hope so atleast. > > > Cheers > Carsten > I think there is some confusion because the default PHP version in ports recently changed to 5.6, and now the official packages are pulling in 5.6: https://svnweb.freebsd.org/ports?view=revision&revision=379433 pkg sometimes tries to remove conflicting packages (like ones that need 5.5) unless you "pkg upgrade" without specifying a package and then it has better information on what to reinstall so packages might not get removed. From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 16:05:59 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60E94800 for ; Mon, 9 Mar 2015 16:05:59 +0000 (UTC) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20F86DC8 for ; Mon, 9 Mar 2015 16:05:59 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id D3BECBDC2E; Mon, 9 Mar 2015 17:05:55 +0100 (CET) Received: from gw.in.absolight.net (gw-ecl.in.absolight.net [79.143.241.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (not verified)) by prod2.absolight.net (Postfix) with ESMTPSA id CF01BBDC25; Mon, 9 Mar 2015 17:05:55 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by gw.in.absolight.net (Postfix) with ESMTP id B7F856145; Mon, 9 Mar 2015 17:05:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id 3007F7E93B99; Mon, 9 Mar 2015 17:05:53 +0100 (CET) Date: Mon, 09 Mar 2015 17:05:52 +0100 From: Mathieu Arnold To: Adam Weinberger , ports@FreeBSD.org Subject: Re: WITH_OPENSSL_PORT documentation Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:05:59 -0000 +--On 8 mars 2015 13:24:09 -0600 Adam Weinberger wrote: | Can somebody please write something---anything, even 2 sentences---for | the PHB about how to use WITH_OPENSSL_PORT? What users should set it to | to get LibreSSL for example, and what porters are supposed to put in the | Makefile to support it? | | The text at the top of bsd.openssl.mk just shows WITH_OPENSSL_PORT=yes. A | few sentences would be a big help, and I'm sure the doc people would be | happy to take care of all the markup and formatting for you. It'll soon be a moot point, WITH_OPENSSL_PORT will be the only option :-) -- Mathieu Arnold From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 16:34:25 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A04F2A04 for ; Mon, 9 Mar 2015 16:34:25 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 627111E5 for ; Mon, 9 Mar 2015 16:34:25 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so36780208iec.10 for ; Mon, 09 Mar 2015 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a4xyW8ISIQ6Y5JCEVOA81v56fN1l350vh9rCD+slChc=; b=thPWLPrVg35MyJ6DPcdpvhjnFOU9C0U3GNkH1zTqx0L2UANmJnEPo+u/WBMHQR/SPR A5u/6t/WhSNkynJRBjei+CuL1/memi8FMlXbU3iu/iaMWumFV32k0fvkG7+NgwmLEpOH JifMTYdqvA/m3klUY80xDyQh4usOMoRChKczjIHumEJBzs6+xc/oy3QKbjKoEcz8WEbn SLPp8NMUqrbhmgn3ctHTB0f24qgoFTJ/sHDpy+tEy0cj9oU8eREQO8u9mcDzsBhDzPah p7xpuC0z0d7shcjo9bHIkrykVQKleoNuNL0QoAqjYO29b2npMRbMs13YV0ck1g5dhtPn YoTA== X-Received: by 10.43.35.198 with SMTP id sx6mr22657300icb.25.1425918864767; Mon, 09 Mar 2015 09:34:24 -0700 (PDT) Received: from [10.0.1.155] (d205-206-84-235.abhsia.telus.net. [205.206.84.235]) by mx.google.com with ESMTPSA id b137sm2264392ioe.36.2015.03.09.09.34.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 09:34:24 -0700 (PDT) Message-ID: <54FDCB8D.7030906@gmail.com> Date: Mon, 09 Mar 2015 10:34:21 -0600 From: Scott Furry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Fabian Keil , freebsd-ports@freebsd.org Subject: Re: CFT: vlc 2.2.0 References: <20150308190113.GA96042@enceladus10.kn-bremen.de> <2d36b48f.6288711f@fabiankeil.de> In-Reply-To: <2d36b48f.6288711f@fabiankeil.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:34:25 -0000 On 09/03/2015 08:46, Fabian Keil wrote: > Juergen Lock wrote: > >> I just saw vlc 2.2.0 is out and updated the port, please test: >> >> https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch > Thanks for the update. > > I get a couple of warnings at build time: > > configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, --disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, --with-qt-libraries, --with-extra-includes, --with-extra-libs > [...] > ====> Running Q/A tests (stage-qa) > Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} > [... same message for the other plugins ....] > > The installed binary seems to mostly work as expected. > > The only regression I noticed so far is that vlc doesn't get the final window > size right when it's started with a video file specified on the command line: > https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg > > After going to fullscreen and back again (for example by hitting f twice) > vlc uses the expected window size. Moving the window around has the same effect. > Loading the video through the GUI seems to work around the problem as well. > > I'm using a tiling window manager (i3) which could be part of the problem > and I wouldn't be surprised if the problem was OS-independent. > > Fabian There is also a vlc preference setting to control video sizing. So, if you have the window not maximized, the window will be seen to adjust "automatically" to the video size. This can be changed in tools->preferneces->interface->"Resize Interface to video size". I believe the default for this sitting is "checked". S From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 16:34:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DD73A93 for ; Mon, 9 Mar 2015 16:34:34 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9E891E9 for ; Mon, 9 Mar 2015 16:34:33 +0000 (UTC) Received: by qcxr5 with SMTP id r5so7993984qcx.4 for ; Mon, 09 Mar 2015 09:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ki7Ipn8eoaCfsGx08ZCqOP6NhU39zsTiAO9T6pqeA/g=; b=G/yq0dG7Jg7Jk6xwCvI5Mll8XOpTBKHqaGTAGdJA4npU6fkM37YSYcTRkjoUkDFcT6 HU7Aiya/N9wBqLVgC5boh/4q1+3awYa8MgxycuG8GCYk8iKzTuzS+5cmIGj9Ox8fUHAY xzjkLXFCVXiDwazFYqZ4lQZOO3E2onpunCWTNd/GZRyABm280aX5I2xovtbcYhykh27T pun5l7ABWrdjV5Vln0vrWA9nLrsidYZHUxD7OF3ixhLP39yGg7Shqamt2aAMeDylKSRV G2ovR5H12rfFSnkn/nRXjADNe0oJNrlpipwBZ27os2O+ahiDNflxNGhkncbPTZp4Utlb ViLA== MIME-Version: 1.0 X-Received: by 10.55.53.79 with SMTP id c76mr56881684qka.45.1425918872809; Mon, 09 Mar 2015 09:34:32 -0700 (PDT) Received: by 10.96.158.137 with HTTP; Mon, 9 Mar 2015 09:34:32 -0700 (PDT) In-Reply-To: <54FDBFC0.1090403@egr.msu.edu> References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <54FDBFC0.1090403@egr.msu.edu> Date: Mon, 9 Mar 2015 18:34:32 +0200 Message-ID: Subject: Re: pkgng deviates from defaults? From: Kimmo Paasiala To: Adam McDougall Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:34:34 -0000 On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall wrote: > On 03/09/2015 08:23, Carsten Jensen wrote: >> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>>> >>>> It seems that pkgng deviates from installing the defaults. >>>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>>> only it wants php56 >>>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>>> system. >>>> >>>> is this a bug? and how can I prevent upgrading to the non-default php56? >>> >>> The default settings are a ports tree setting not a pkg setting. for >>> now the >>> ports are hardcoding the required version into the packages, this is a >>> legacy of >>> the old system, noone has yet been working on this. so beside building >>> your own >>> packages with poudriere (which will define the default you want) righ >>> now there >>> is no way to avoid that. >>> >>> The php case but not only php will require small changes in pkg(8) to >>> activate >>> smart dependencies: depend on a>1<=2.10 and also adding >>> provides/requires (this >>> is not very hard to be added in pkg.) and it should also require heavy >>> changes >>> on the port side! >>> >>> As far as I know noone has been working on those changes in the port >>> side. the >>> pkg(8) changes are mostly pending for real use cases in the port side. >>> Meaning >>> both should be coordinated. >>> >>> Best regards, >>> Bapt >>> >> >> Sorry I don't think I was clear. >> Some applications wants php5 and some applications wants php56 when >> upgrading using pkg-ng. >> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web >> based application due to this conflict. >> >> So while the upgrade happens to upgrade to php56 it also removes the >> other web application, as it only wants php5. >> >> Most of the applications on the server is maintained by pkg-ng, and it >> conflicts itself. >> >> Basically there are now 2 "default" php versions used by pkg-ng >> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also >> tries to upgrade php5. >> >> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin >> >> I don't know if this is expressed better, I hope so atleast. >> >> >> Cheers >> Carsten >> > > I think there is some confusion because the default PHP version in ports > recently changed to 5.6, and now the official packages are pulling in 5.6: > > https://svnweb.freebsd.org/ports?view=revision&revision=379433 > > pkg sometimes tries to remove conflicting packages (like ones that need > 5.5) unless you "pkg upgrade" without specifying a package and then it > has better information on what to reinstall so packages might not get > removed. In fact pkg(8) will not allow conflicting packages to be installed at all. The result is that if you want to install a package that would introduce a conflict in the installed package database the conflict has to be resolved one way or another. The only solution at the moment is to remove the offending packages from the existing installed packages. This is not a pkg(8) limitation but the consequence of how ports(7) system deals with conflicts and lack of infrastructure to properly allow multiple versions of the same software to co-exist. -Kimmo From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 17:10:47 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1A7E70A; Mon, 9 Mar 2015 17:10:47 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64BF5892; Mon, 9 Mar 2015 17:10:46 +0000 (UTC) Received: from [109.42.3.97] by msvc021.dlan.cinetic.de (via HTTP); Mon, 9 Mar 2015 18:10:41 +0100 Message-ID: From: "Olli Hauer" To: "Mathieu Arnold" , "Adam Weinberger" , ports@FreeBSD.org Subject: Re: Re: WITH_OPENSSL_PORT documentation Date: Mon, 9 Mar 2015 18:10:41 +0100 X-Provags-ID: V03:K0:qyijHDr8QZ+y6WjUZKajzkSKggEHZp+XW366Bi8B9DM 8EH/69ZJzgD2rUr+xOz7xkGgAHKfDerM64L3zkJBtyUv/aX29u Gje84RLsmikDvCjlDM7egR4GxF9esbZ5A3QRFMLbgTke4W8SfW zVY0CburnhH5rucT1nClWS3GWr8z+tu22kZWDMPag0x7OTtL4o i1w2G9RmzL889sWpMw+lWB29ZWZ0KaqvQFwahpfo4wULOSKrqT l7LHAoOk1G5I18unsZQ2aMI7paEcvpzySB5oMKKkwhjIqaE9lP WVRf7c= X-UI-Out-Filterresults: notjunk:1; MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:10:47 -0000 Hi Mathieu, what is the target timeframe for."soon",.e.g. for.8.x and.9.x having an older openssl in base. Is there wip. to hide the base ssl libs ? -- Sent from my Android phone with GMX Mail. Please excuse my brevity. Mathieu Arnold wrote: +--On 8 mars 2015 13:24:09 -0600 Adam Weinberger wrote: | Can somebody please write something---anything, even 2 sentences---for | the PHB about how to use WITH_OPENSSL_PORT? What users should set it to | to get LibreSSL for example, and what porters are supposed to put in the | Makefile to support it? | | The text at the top of bsd.openssl.mk just shows WITH_OPENSSL_PORT=yes. A | few sentences would be a big help, and I'm sure the doc people would be | happy to take care of all the markup and formatting for you. It'll soon be a moot point, WITH_OPENSSL_PORT will be the only option :-) -- Mathieu Arnold _______________________________________________ freebsd-ports@freebsd.org mailing list [1]http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" References 1. http://lists.freebsd.org/mailman/listinfo/freebsd-ports From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 18:15:16 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA697B40 for ; Mon, 9 Mar 2015 18:15:16 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DCD413E for ; Mon, 9 Mar 2015 18:15:16 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t29IGjs4067219 for ; Mon, 9 Mar 2015 11:16:45 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20150309150739.545fdec0@curlew.lan> References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <5b05148435ae02019e0ccae218cecce5@ultimatedns.net>, <20150309150739.545fdec0@curlew.lan> From: "Chris H" Subject: Re: pkgng deviates from defaults? Date: Mon, 09 Mar 2015 11:16:45 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <445c3e3814d67f7fd056cb5501f5338c@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:15:16 -0000 On Mon, 9 Mar 2015 15:07:39 +0000 Mike Clarke wrote > On Mon, 09 Mar 2015 07:04:30 -0700 > "Chris H" wrote: > > > You might be able to avoid the issue you're having, by using: > > DEFAULT_VERSIONS+=php=5.5 > > in your make.conf(5) (/etc/make.conf) file. > > As far as I know this won't have any effect on pkg. Bummer. Sorry to hear that. Seems like there *should* be a way in pkg(8) to honor DEFAULT_VERSIONS not that there is a way now. But that there *should* be a way, in the (near?) future. :-) Thanks for the heads up, Mike. --Chris > > If the OP wishes to use pkg then the only option is to switch to using > php5.6. This will involve uninstalling all the php5.5 packages and > reinstalling default php5.6 versions. I went through this process > recently and described the steps involved in questions@ > > > > -- > Mike Clarke > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 18:48:56 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFE385B1 for ; Mon, 9 Mar 2015 18:48:56 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E2B7A4 for ; Mon, 9 Mar 2015 18:48:56 +0000 (UTC) Received: by iebtr6 with SMTP id tr6so32750554ieb.4 for ; Mon, 09 Mar 2015 11:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=I74rkDGTq9EH8G8OTp3lmHyOVaJLjF2ZIMTb9XYlaos=; b=YSrteyVayFqdI9O7JWEWaLXjx3ldtor/VvBHIWXn2uleamD+MW6gfn3mtMbK0LkR7w aInVN1Rcw7GjrlwUtdffxDBAJiUX99LHF2eb3M8U4rwvfB7Gvgu95RyZxyoc7JIKbR+y HbM0aQfdJzqgZAHgdHAQd9cqaD3v2q9fZ/mcs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=I74rkDGTq9EH8G8OTp3lmHyOVaJLjF2ZIMTb9XYlaos=; b=ZwkdPHA1FV6R/Q63eSoBRdY7DEm89tX8H+BtuRWRTx1Rte1wqUj9fHkWFYtIZB2oms 9iSMJYFGQ79Dv7AwPsWJTGIcyQRbhZ98P2kneGNZ/kX8o5U8DprRDMSyxuZWVgN+LfdN MCSx/xHqlQHcIw9nsGZhYtx30KHZr4ay4Dcs560kGm8lRqx5L4kenJj0NdYs/Mrl3ov0 Mw8j4l5Hznwpgn/8B0StwcAIHPJTv9iyA+eOAMi9gwsXpio9KeGXa1CcNcEVZKfJLDrK SsYNVNxecDn2+PYRx+B2G5BqkGWlDe23uzj+QfNrQ796kv6gZUEX3Hp4jm6nr9T05n8f 3fWA== X-Gm-Message-State: ALoCoQlUITQtD8yF7R4rHrJzo9NW4Jt66/BhkecF/ajH/9UtUW+tDtUPuzpUlsJBAp51yy1w8HBe X-Received: by 10.50.79.230 with SMTP id m6mr49655775igx.33.1425926935837; Mon, 09 Mar 2015 11:48:55 -0700 (PDT) Received: from rsbsd.rsb ([31.200.21.83]) by mx.google.com with ESMTPSA id 192sm12595312ioo.38.2015.03.09.11.48.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 11:48:55 -0700 (PDT) Date: Mon, 9 Mar 2015 20:48:52 +0200 From: "Raif S. Berent" To: Subject: Re: graphics/freeglut build fail Message-ID: <20150309204852.24553054@rsbsd.rsb> In-Reply-To: <20150220091220.57374e6b@rsbsd.rsb> References: <20150219104534.5fb8b9b0@rsbsd.rsb> <20150220091220.57374e6b@rsbsd.rsb> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:48:57 -0000 I would not give this problem a second thought, since 40 to 50 ports regula= rly break during poudriere runs. The exception for this port is that many d= ownstream ports (>370 for me) depend on it. Then, a "# make package" from h= ost gets accepted by the poudriere queue. ccache has no relevance to the problem, and building with GCC works. Can we= place a conditional in the Makefile {if version > trillion ; use GCC}? I know, I suck at coding. I'm gonna get there some day... poudriere build log: https://drive.google.com/file/d/0Bxs_eepbMt6qMVp0aGFZUklmTW8/view?usp=3Dsha= ring > I got the port to build with USE_GCC=3DANY. > poudriere accepted (did not delete) the binary created by host so the > full build now continues :)) From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 19:05:29 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B679C8DD for ; Mon, 9 Mar 2015 19:05:29 +0000 (UTC) Received: from cicero4.cybercity.dk (cicero-fbr1.cybercity.dk [212.242.40.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF5798A for ; Mon, 9 Mar 2015 19:05:28 +0000 (UTC) Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53]) by cicero4.cybercity.dk (Postfix) with ESMTP id 04C954F4F0D for ; Mon, 9 Mar 2015 20:05:20 +0100 (CET) Received: from mail.flipmode.dk (0x5e9159bc.adsl.cybercity.dk [94.145.89.188]) by cicero2.cybercity.dk (Postfix) with ESMTP id E519D10881E for ; Mon, 9 Mar 2015 20:05:13 +0100 (CET) Received: from ns1.flipmode.dk (unknown [127.0.0.1]) by mail.flipmode.dk (Postfix) with ESMTP id 627501F10607 for ; Mon, 9 Mar 2015 20:05:10 +0100 (CET) X-Virus-Scanned: amavisd-new at flipmode.dk Received: from mail.flipmode.dk ([127.0.0.1]) by ns1.flipmode.dk (ns1.flipmode.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXJ-OpxtpJPI for ; Mon, 9 Mar 2015 20:05:09 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.4.168]) by mail.flipmode.dk (Postfix) with ESMTPSA id 428981F10606 for ; Mon, 9 Mar 2015 20:05:09 +0100 (CET) Message-ID: <54FDEEE5.4000606@tomse.dk> Date: Mon, 09 Mar 2015 20:05:09 +0100 From: Carsten Jensen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkgng deviates from defaults? References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <54FDBFC0.1090403@egr.msu.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150309-0, 09-03-2015), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:05:29 -0000 On 09-03-2015 17:34, Kimmo Paasiala wrote: > On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall wrote: >> On 03/09/2015 08:23, Carsten Jensen wrote: >>> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >>>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>>>> It seems that pkgng deviates from installing the defaults. >>>>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>>>> only it wants php56 >>>>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>>>> system. >>>>> >>>>> is this a bug? and how can I prevent upgrading to the non-default php56? >>>> The default settings are a ports tree setting not a pkg setting. for >>>> now the >>>> ports are hardcoding the required version into the packages, this is a >>>> legacy of >>>> the old system, noone has yet been working on this. so beside building >>>> your own >>>> packages with poudriere (which will define the default you want) righ >>>> now there >>>> is no way to avoid that. >>>> >>>> The php case but not only php will require small changes in pkg(8) to >>>> activate >>>> smart dependencies: depend on a>1<=2.10 and also adding >>>> provides/requires (this >>>> is not very hard to be added in pkg.) and it should also require heavy >>>> changes >>>> on the port side! >>>> >>>> As far as I know noone has been working on those changes in the port >>>> side. the >>>> pkg(8) changes are mostly pending for real use cases in the port side. >>>> Meaning >>>> both should be coordinated. >>>> >>>> Best regards, >>>> Bapt >>>> >>> Sorry I don't think I was clear. >>> Some applications wants php5 and some applications wants php56 when >>> upgrading using pkg-ng. >>> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web >>> based application due to this conflict. >>> >>> So while the upgrade happens to upgrade to php56 it also removes the >>> other web application, as it only wants php5. >>> >>> Most of the applications on the server is maintained by pkg-ng, and it >>> conflicts itself. >>> >>> Basically there are now 2 "default" php versions used by pkg-ng >>> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also >>> tries to upgrade php5. >>> >>> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin >>> >>> I don't know if this is expressed better, I hope so atleast. >>> >>> >>> Cheers >>> Carsten >>> >> I think there is some confusion because the default PHP version in ports >> recently changed to 5.6, and now the official packages are pulling in 5.6: >> >> https://svnweb.freebsd.org/ports?view=revision&revision=379433 >> >> pkg sometimes tries to remove conflicting packages (like ones that need >> 5.5) unless you "pkg upgrade" without specifying a package and then it >> has better information on what to reinstall so packages might not get >> removed. > In fact pkg(8) will not allow conflicting packages to be installed at > all. The result is that if you want to install a package that would > introduce a conflict in the installed package database the conflict > has to be resolved one way or another. The only solution at the moment > is to remove the offending packages from the existing installed > packages. This is not a pkg(8) limitation but the consequence of how > ports(7) system deals with conflicts and lack of infrastructure to > properly allow multiple versions of the same software to co-exist. > > -Kimmo > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" Lots of good answers, thank you :-) I can understand that php 5.6 is now the default, I did major upgrades a few weeks back, and it was 5.4 that was the default then. Thats not a problem for me as long as the upgrade process isn't troublesome. But I'm wondering why pkg-ng wants to remove other packages rather than just upgrading or reinstalling due to dependencies have changed. Shouldn't these applications have been built using the new defaults? The problems occured during the simple: pkg upgrade oh, and I've seen a couple of lines similar to this: mod_php5 has no direct installation candidates, change it to mod_php5? [Y/n]: no matter what I've chosen it does nothing than exiting to the shell, trying to run pkg upgrade again and it asks the same question. Carsten From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 21:16:24 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AE4EAA5 for ; Mon, 9 Mar 2015 21:16:24 +0000 (UTC) Received: from smtp.kn-bremen.de (gruenbaer.kn-bremen.de [148.251.8.79]) by mx1.freebsd.org (Postfix) with ESMTP id ED559EC7 for ; Mon, 9 Mar 2015 21:16:23 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 94DB63DE0E19; Mon, 9 Mar 2015 22:16:15 +0100 (CET) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id t29LF4Zt042911; Mon, 9 Mar 2015 22:15:04 +0100 (CET) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id t29LF44v042910; Mon, 9 Mar 2015 22:15:04 +0100 (CET) (envelope-from nox) Date: Mon, 9 Mar 2015 22:15:04 +0100 (CET) From: Juergen Lock Message-Id: <201503092115.t29LF44v042910@enceladus10.kn-bremen.de> To: freebsd-listen@fabiankeil.de Subject: Re: CFT: vlc 2.2.0 X-Newsgroups: local.list.freebsd.ports In-Reply-To: <2d36b48f.6288711f@fabiankeil.de> References: <20150308190113.GA96042@enceladus10.kn-bremen.de> Organization: home Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:16:24 -0000 In article <2d36b48f.6288711f@fabiankeil.de> you write: >Juergen Lock wrote: > >> I just saw vlc 2.2.0 is out and updated the port, please test: >>=20 >> https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch > >Thanks for the update. > >I get a couple of warnings at build time: > >configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, --disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, --with-qt-libraries, --with-extra-includes, --with-extra-libs >[...] Yeah probably not important. >====> Running Q/A tests (stage-qa) >Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} >[... same message for the other plugins ....] > Not sure plugins should be stripped... >The installed binary seems to mostly work as expected. > >The only regression I noticed so far is that vlc doesn't get the final window >size right when it's started with a video file specified on the command line: >https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg > >After going to fullscreen and back again (for example by hitting f twice) >vlc uses the expected window size. Moving the window around has the same effect. >Loading the video through the GUI seems to work around the problem as well. > >I'm using a tiling window manager (i3) which could be part of the problem Possibly, I don't see this on lxde here. (which isn't tiling) >and I wouldn't be surprised if the problem was OS-independent. > Right. Thanx for testing! :) Juergen From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 23:11:31 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E97BEA7 for ; Mon, 9 Mar 2015 23:11:31 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E3871EA for ; Mon, 9 Mar 2015 23:11:31 +0000 (UTC) Received: by iecrl12 with SMTP id rl12so25132856iec.5 for ; Mon, 09 Mar 2015 16:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rUEctxPjFkBH28I2nOhjeu2hGhJAuFV6sFzKicW7g9U=; b=bqpFlu5BSLxrBBeuGPcPTvWIs7tftqeMag13CJAL9BlmBHAfyEjaA0HZxx17UeOWx0 CYzw7/jLenjAPRwyl7gzm9WDm3o4D68bKOJpE+I/wDRurWhZ3klkwQ76Wj7hP79nB23B O0O5SYxndOTF4z4Pp2psaGpY1W2J4+vygivd4eKOv8G612zj/MuINsQ7JP42Dpejwt/b IeiOljkWSFao3ZT9IuTPVLGnylrqdl5teYMTbw+o/u3YTAiVlkfMs4+tIpQYik0AxxRY GCoMuwi+d4avSEzG9CyZqrYzgx67EvGFAkt4t+RcprTGlinqLi8JH6xD33FIKanuWP6F cjhg== MIME-Version: 1.0 X-Received: by 10.107.41.83 with SMTP id p80mr51578157iop.54.1425942690444; Mon, 09 Mar 2015 16:11:30 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Mon, 9 Mar 2015 16:11:30 -0700 (PDT) In-Reply-To: <54FD82A7.6040905@infracaninophile.co.uk> References: <54FB7119.4030208@FreeBSD.org> <54FD7FEC.5080500@FreeBSD.org> <54FD82A7.6040905@infracaninophile.co.uk> Date: Mon, 9 Mar 2015 16:11:30 -0700 X-Google-Sender-Auth: NlqGyB2cATalF48hsoe6VoTZByM Message-ID: Subject: Re: How could I increase "runaway" timer for package build cluster? From: Kevin Oberman To: Matthew Seaman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:11:31 -0000 On Mon, Mar 9, 2015 at 4:23 AM, Matthew Seaman < m.seaman@infracaninophile.co.uk> wrote: > On 03/09/15 11:11, Lev Serebryakov wrote: > > On 08.03.2015 12:40, Ben Woods wrote: > >> Actually, taking a look at my /usr/local/etc/poudriere.conf > >> configuration file, I see these settings have indeed been exposed > >> for configuration there without having to touch the poudriere code > >> itself. The appropriate settings are: > > > >> # This defines the max time (in seconds) that a command may run for > >> a build # before it is killed for taking too long. Default: 86400 > >> #MAX_EXECUTION_TIME=86400 > > > >> # This defines the time (in seconds) before a command is considered > >> to # be in a runaway state for having no output on stdout. Default: > >> 7200 #NOHANG_TIME=7200 > > > > The problem is, it is not my cluster, but FreeBSD official cluster. I > > could not change configs of it, I could only edit Makefile of my port. > > I added a small change to make 'pkg create' emit a progress bar which > will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to > enable it though. With this change I've managed to avoid poudriere > timeouts while packaging stuff with large numbers of files -- > texlive-texmf being a classic example. You can try it now by installing > net-mgmt/pkg-devel, but beware that will eventually cause all your > client machines to end up running pkg-devel too. > > Just slightly confused. Do you mean pkg-1.4.15 (now on 1.4.12) or pkg-1.5? Any idea on time-frame? -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 23:19:40 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F5996F for ; Mon, 9 Mar 2015 23:19:40 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id 53D94254 for ; Mon, 9 Mar 2015 23:19:39 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id CB2DF3ED3B for ; Mon, 9 Mar 2015 19:19:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUmzG270HWaw for ; Mon, 9 Mar 2015 19:19:37 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <54FE2A88.5000004@egr.msu.edu> Date: Mon, 09 Mar 2015 19:19:36 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkgng deviates from defaults? References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <54FDBFC0.1090403@egr.msu.edu> <54FDEEE5.4000606@tomse.dk> In-Reply-To: <54FDEEE5.4000606@tomse.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:19:40 -0000 On 03/09/2015 15:05, Carsten Jensen wrote: > On 09-03-2015 17:34, Kimmo Paasiala wrote: >> On Mon, Mar 9, 2015 at 5:44 PM, Adam McDougall wrote: >>> On 03/09/2015 08:23, Carsten Jensen wrote: >>>> On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: >>>>> On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: >>>>>> It seems that pkgng deviates from installing the defaults. >>>>>> one of the culprits seems to be phpMyAdmin, as trying to upgrade this >>>>>> only it wants php56 >>>>>> deleting phpMyAdmin just shows I have other packages needing php56 in my >>>>>> system. >>>>>> >>>>>> is this a bug? and how can I prevent upgrading to the non-default php56? >>>>> The default settings are a ports tree setting not a pkg setting. for >>>>> now the >>>>> ports are hardcoding the required version into the packages, this is a >>>>> legacy of >>>>> the old system, noone has yet been working on this. so beside building >>>>> your own >>>>> packages with poudriere (which will define the default you want) righ >>>>> now there >>>>> is no way to avoid that. >>>>> >>>>> The php case but not only php will require small changes in pkg(8) to >>>>> activate >>>>> smart dependencies: depend on a>1<=2.10 and also adding >>>>> provides/requires (this >>>>> is not very hard to be added in pkg.) and it should also require heavy >>>>> changes >>>>> on the port side! >>>>> >>>>> As far as I know noone has been working on those changes in the port >>>>> side. the >>>>> pkg(8) changes are mostly pending for real use cases in the port side. >>>>> Meaning >>>>> both should be coordinated. >>>>> >>>>> Best regards, >>>>> Bapt >>>>> >>>> Sorry I don't think I was clear. >>>> Some applications wants php5 and some applications wants php56 when >>>> upgrading using pkg-ng. >>>> Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web >>>> based application due to this conflict. >>>> >>>> So while the upgrade happens to upgrade to php56 it also removes the >>>> other web application, as it only wants php5. >>>> >>>> Most of the applications on the server is maintained by pkg-ng, and it >>>> conflicts itself. >>>> >>>> Basically there are now 2 "default" php versions used by pkg-ng >>>> meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also >>>> tries to upgrade php5. >>>> >>>> I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin >>>> >>>> I don't know if this is expressed better, I hope so atleast. >>>> >>>> >>>> Cheers >>>> Carsten >>>> >>> I think there is some confusion because the default PHP version in ports >>> recently changed to 5.6, and now the official packages are pulling in 5.6: >>> >>> https://svnweb.freebsd.org/ports?view=revision&revision=379433 >>> >>> pkg sometimes tries to remove conflicting packages (like ones that need >>> 5.5) unless you "pkg upgrade" without specifying a package and then it >>> has better information on what to reinstall so packages might not get >>> removed. >> In fact pkg(8) will not allow conflicting packages to be installed at >> all. The result is that if you want to install a package that would >> introduce a conflict in the installed package database the conflict >> has to be resolved one way or another. The only solution at the moment >> is to remove the offending packages from the existing installed >> packages. This is not a pkg(8) limitation but the consequence of how >> ports(7) system deals with conflicts and lack of infrastructure to >> properly allow multiple versions of the same software to co-exist. >> >> -Kimmo >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > Lots of good answers, thank you :-) > > I can understand that php 5.6 is now the default, I did major upgrades a > few weeks back, > and it was 5.4 that was the default then. Thats not a problem for me as > long as the upgrade > process isn't troublesome. > > But I'm wondering why pkg-ng wants to remove other packages rather than > just upgrading > or reinstalling due to dependencies have changed. > Shouldn't these applications have been built using the new defaults? > > The problems occured during the simple: > pkg upgrade > > oh, and I've seen a couple of lines similar to this: > mod_php5 has no direct installation candidates, change it to mod_php5? > [Y/n]: > > no matter what I've chosen it does nothing than exiting to the shell, > trying to run pkg upgrade > again and it asks the same question. > > Carsten > > Sorry, I meant "pkg upgrade -f" may give you better results because it will pull down all rebuilt packages and have more information to resolve the problem, at least in my experience. It doesn't seem like it should be necessary though. From owner-freebsd-ports@FreeBSD.ORG Mon Mar 9 23:21:13 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5B1C12E for ; Mon, 9 Mar 2015 23:21:12 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F02A315 for ; Mon, 9 Mar 2015 23:21:12 +0000 (UTC) Received: by wesx3 with SMTP id x3so32477177wes.4 for ; Mon, 09 Mar 2015 16:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=w8+UZ0yebbpB8pATlnxr2otiO+wn7AV2BuapT0AxZ50=; b=qoxCCmlokHwOYgk0JD3T8xEwJ5gqWapAOpr/zJFoJiEUZ9v8+hB8KdC32wkpFyXpLD Y1t84Pmh5jwdiSnMTHeVosOSzXk6KkDNRWAsZChlR/1a5bfqUntJHWI3WoaSOEQ7QWH4 U19/rpR9zCT7Xmos+rZxEv4ZC/1WeagYjRYT7fJH0sTtHCh8vk8K+35u6xP3pf9m+Phr qjm7xQBESiP2Co3vKkzxufB7qClswBPkqB1GBEODchW58FukkNGH6Uo8tQwm4Y9yWj9/ 38kJnINBLnDooBs7LaEWEr1aLd4ml7eEu2Vncx0WjZOmY87W2NlQZa/n5Xv7R82JaoNm We2Q== X-Received: by 10.194.185.68 with SMTP id fa4mr61161578wjc.111.1425943270867; Mon, 09 Mar 2015 16:21:10 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id p1sm1216609wib.23.2015.03.09.16.21.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 16:21:09 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 10 Mar 2015 00:21:07 +0100 From: Baptiste Daroussin To: Juergen Lock Subject: Re: CFT: vlc 2.2.0 Message-ID: <20150309232107.GA33487@ivaldir.etoilebsd.net> References: <20150308190113.GA96042@enceladus10.kn-bremen.de> <201503092115.t29LF44v042910@enceladus10.kn-bremen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <201503092115.t29LF44v042910@enceladus10.kn-bremen.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:21:13 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 09, 2015 at 10:15:04PM +0100, Juergen Lock wrote: > In article <2d36b48f.6288711f@fabiankeil.de> you write: > >Juergen Lock wrote: > > > >> I just saw vlc 2.2.0 is out and updated the port, please test: > >>=3D20 > >> https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch > > > >Thanks for the update. > > > >I get a couple of warnings at build time: > > > >configure: WARNING: unrecognized options: --disable-egl, --disable-libvn= c, --disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, -= -with-qt-libraries, --with-extra-includes, --with-extra-libs > >[...] >=20 > Yeah probably not important. >=20 > >=3D=3D=3D=3D> Running Q/A tests (stage-qa) > >Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped con= sider trying INSTALL_TARGET=3Dinstall-strip or using ${STRIP_CMD} > >[... same message for the other plugins ....] > > > Not sure plugins should be stripped... They should at least no reason not to strip them >=20 > >The installed binary seems to mostly work as expected. > > > >The only regression I noticed so far is that vlc doesn't get the final w= indow > >size right when it's started with a video file specified on the command = line: > >https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering= -flaw.jpg > > > >After going to fullscreen and back again (for example by hitting f twice) > >vlc uses the expected window size. Moving the window around has the same= effect. > >Loading the video through the GUI seems to work around the problem as we= ll. > > > >I'm using a tiling window manager (i3) which could be part of the problem >=20 > Possibly, I don't see this on lxde here. (which isn't tiling) >=20 > >and I wouldn't be surprised if the problem was OS-independent. > > > Right. >=20 > Thanx for testing! :) > Juergen > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlT+KuMACgkQ8kTtMUmk6Ey7dACfaLXnIHjX8m1Mt2qa27dz7Ny5 B2sAoJ3PJo4T9faN9LjbbaizNgq7GdN8 =2hDV -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 02:47:50 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78810FF6; Tue, 10 Mar 2015 02:47:50 +0000 (UTC) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B8F0CCE; Tue, 10 Mar 2015 02:47:50 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id t2A2ldWL042304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Mar 2015 02:47:44 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id t2A2ldEr042303; Tue, 10 Mar 2015 02:47:39 GMT (envelope-from swills) Date: Tue, 10 Mar 2015 02:47:39 +0000 From: Steve Wills To: Don Lewis Subject: Re: proper DOXYGEN option default value Message-ID: <20150310024736.GB30716@mouf.net> References: <201503042241.t24Mfmmn060556@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503042241.t24Mfmmn060556@gw.catspoiler.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Tue, 10 Mar 2015 02:47:44 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=HEADER_FROM_DIFFERENT_DOMAINS autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mouf.net Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 02:47:50 -0000 On Wed, Mar 04, 2015 at 02:41:48PM -0800, Don Lewis wrote: > I maintain a number of ports that use doxygen to generate their > documentation. They all list DOXYGEN in OPTIONS_DEFAULT so that > the packages will include documentation. > > I recently received a PR for one of those ports that mentioned that most > users don't require the documentation and pointed out that anyone > building the port will find it is very painful because of the amount of > time it takes to build doxygen and all of its dependencies (primarily > all the TeX stuff). > > It's been my experience that there is enough churn in the dependencies > that the whole mess needs to get rebuilt fairly frequently. > > As I see it, the pros and cons of listing DOXYGEN in OPTIONS_DEFAULT > are: > Pros: > * Users who need the documentation can use the binary packages if > they desire > * This option gets regular exercise on the build cluster > Cons: > * A bit of extra load on the ports build cluster to install > doxygen and its dependencies as a BUILD_DEPENDS for each > supported OS version and architecture > * The packages are a bit larger > * A bit more space is consumed on the user's machine because > documentation is installed, even if they don't need it > * Users building from ports have to build and install doxygen > and it's dependencies unless they take measures to avoid it, > either by disabling the option for each port or adding > OPTIONS_UNSET=DOXYGEN to their /etc/make.conf to do this > globally > > The pros and cons of removing DOXYGEN from OPTIONS_DEFAULT: > Pros: > * Less load on the ports build cluster > * Smaller packages > * Less space consumed on most user machines > * Users building from ports who do not need the documentation don't > pay the doxygen penalty without taking any special measures > Cons: > * Anyone who does need the documentation has to build from the > port and pay the cost of building and installing doxygen and its > dependencies. > * The DOXYGEN option would not get regular testing and could be > subject to bit rot. > > Ideally, the documentation could be built and packaged separately. It > could even be NO_ARCH. Unfortunately, at this time this would require > adding a bunch of new ports just for the documentation. > > Since these ports only generate HTML documentation, it might be helpful > to have a doxygen-lite port that has GRAPHVIZ and LATEX disabled, and > use that as a BUILD_DEPENDS. That introduces the problem of conflicts > between doxygen and doxygen-lite if someone who builds from ports needs > the full featured doxygen for other purposes. > > Since we have neither of the above, should I leave my ports as-is, or > should I disable DOXYGEN by default? Personally I would tend to lean towards leaving DOXYGEN off by default, especially if there is other accompanying documentation. This is the case for lang/ruby* for example. But beward that this may mean it is more likely that the DOXYGEN parts of the plist may become outdated when the doxygen port is updated. So keep testing that option. Steve From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 06:42:30 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B32781F for ; Tue, 10 Mar 2015 06:42:30 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9701383B for ; Tue, 10 Mar 2015 06:42:29 +0000 (UTC) Received: from seedling.local (wifi.infracaninophile.co.uk [81.2.117.98]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t2A6gL7h051436 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 Mar 2015 06:42:22 GMT (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t2A6gL7h051436 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1425969742; bh=JnSPT88QJnaUTmzT9ZjUEqEICqfnE0kJfPYfi4b6Wic=; h=Date:From:To:CC:Subject:References:In-Reply-To; z=Date:=20Tue,=2010=20Mar=202015=2006:42:04=20+0000|From:=20Matthew =20Seaman=20|To:=20Kevin=20Oberma n=20|CC:=20FreeBSD=20Ports=20ML=20|Subject:=20Re:=20How=20could=20I=20increase=20"ru naway"=20timer=20for=20package=20build=20cluster?|References:=20<5 4FB7119.4030208@FreeBSD.org>=09=09=09<54FD7FEC.5080500@FreeB SD.org>=09<54FD82A7.6040905@infracaninophile.co.uk>=20|In-Reply- To:=20; b=KbAizrWywkd0uKwxMvQz4V9wmOTl9CJEoY0YRB3ThJw5Kv2H2kKh0357UWQhPa9XZ Z9e8exDKS8THuTKel1akQDnP8KgXEFNTYFIfY/QjpyqAJ2zYVp313j5E+UfXnHFPME Km5UrNglPI3go+YtfRpXdlovsj2L1u+Guv98VDt4= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host wifi.infracaninophile.co.uk [81.2.117.98] claimed to be seedling.local Message-ID: <54FE923C.7080308@infracaninophile.co.uk> Date: Tue, 10 Mar 2015 06:42:04 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: How could I increase "runaway" timer for package build cluster? References: <54FB7119.4030208@FreeBSD.org> <54FD7FEC.5080500@FreeBSD.org> <54FD82A7.6040905@infracaninophile.co.uk> In-Reply-To: OpenPGP: id=E1ECF9BB Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HB2TwqtVgru9tX5j1lmturA7bwnkXtWef" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,T_RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 06:42:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HB2TwqtVgru9tX5j1lmturA7bwnkXtWef Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/2015 23:11, Kevin Oberman wrote: > On Mon, Mar 9, 2015 at 4:23 AM, Matthew Seaman < > m.seaman@infracaninophile.co.uk> wrote: >=20 >> On 03/09/15 11:11, Lev Serebryakov wrote: >>> On 08.03.2015 12:40, Ben Woods wrote: >>>> Actually, taking a look at my /usr/local/etc/poudriere.conf >>>> configuration file, I see these settings have indeed been exposed >>>> for configuration there without having to touch the poudriere code >>>> itself. The appropriate settings are: >>> >>>> # This defines the max time (in seconds) that a command may run for >>>> a build # before it is killed for taking too long. Default: 86400 >>>> #MAX_EXECUTION_TIME=3D86400 >>> >>>> # This defines the time (in seconds) before a command is considered >>>> to # be in a runaway state for having no output on stdout. Default: >>>> 7200 #NOHANG_TIME=3D7200 >>> >>> The problem is, it is not my cluster, but FreeBSD official cluster. = I >>> could not change configs of it, I could only edit Makefile of my port= =2E >> >> I added a small change to make 'pkg create' emit a progress bar which >> will be in pkg-1.15 -- you have to tweak some settings in pkg.conf to >> enable it though. With this change I've managed to avoid poudriere >> timeouts while packaging stuff with large numbers of files -- >> texlive-texmf being a classic example. You can try it now by installi= ng >> net-mgmt/pkg-devel, but beware that will eventually cause all your >> client machines to end up running pkg-devel too. >> >> > Just slightly confused. Do you mean pkg-1.4.15 (now on 1.4.12) or pkg-1= =2E5? > Any idea on time-frame? Sorry, yes. That was a typo. pkg-1.5 is in the works. Bapt has said he wants to release it "before BSDCan" and there's a chunk of work gong in on regression testing at the moment. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --HB2TwqtVgru9tX5j1lmturA7bwnkXtWef Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQJ8BAEBCgBmBQJU/pJJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATpNEP/3ceJMlAjj+Qp/f6J/GfJRZY NPdqzj1EWKBMgysTrAw4cvqMkIlYEjw1uHBjPmJcww9KkX1T8NaFhxYxv4cnuP7m zuQRbkRL8UHaaX307uuSNM6CAiPqsiG3So4neZYYiV4vAUTSLnv+nalKuynT/N4f s9X/58T5iSz9RtHgEtlrqg7i63zcECBj3jWuydaVMr3sd1GJB6yyBBgwW6qr9oSU 4MsoaxO9hfaXJvUc+GKJ/03Rnur6PSWIiUxaElZQe9bFu0abWrW8Bz2acFziug8x GvSvFaB/cHg5JnpBv2Hi3EnDTO69bKj0RYUN6XTWYMZQDE84lTyvSckBC4a/ukXa TBSV3UAc47i2XquE2ncVL5oV8RutQ9wy0/LfO5DiZ1c2CRXxW5ilmwhBkokfVrQ8 Tnng9toQ2ldUIyz6EUf1fYKYsGUOj0frCCMBviBUjUVv5h4A3ObJAU6wPqXen7jS yEl0y60tVOfTzev7MTAGi+/mJ1L7hWMULFkPlHKQxF3oVfBVMqxxmD21659IUHnC Rh3HACfseKqG5h7cKOzBjgONkg4L7E6oxQ880UbCFATp5BncGTBzMerdwU8pVyAe 5QF0WKCWiPOLrPO/g/UeCnj3UBdzj8moZJDNk1BRFJDl3d3FnM+cRpdtaiSYlUK7 yIBnJ5P+pyhfb2WMH9EA =bV3j -----END PGP SIGNATURE----- --HB2TwqtVgru9tX5j1lmturA7bwnkXtWef-- From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 08:05:56 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3C8536E for ; Tue, 10 Mar 2015 08:05:56 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED64F4A for ; Tue, 10 Mar 2015 08:05:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::8da3:c8a7:e5cf:aeb5] (unknown [IPv6:2001:7b8:3a7:0:8da3:c8a7:e5cf:aeb5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 108175C48; Tue, 10 Mar 2015 09:05:53 +0100 (CET) Subject: Re: graphics/freeglut build fail Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_092C7F5C-DF7D-46B1-AC12-6E33028FC7E4"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Dimitry Andric In-Reply-To: <20150309204852.24553054@rsbsd.rsb> Date: Tue, 10 Mar 2015 09:05:48 +0100 Message-Id: <5259A5B5-6497-4E4A-9DBC-7D7637F521D7@FreeBSD.org> References: <20150219104534.5fb8b9b0@rsbsd.rsb> <20150220091220.57374e6b@rsbsd.rsb> <20150309204852.24553054@rsbsd.rsb> To: "Raif S. Berent" X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 08:05:56 -0000 --Apple-Mail=_092C7F5C-DF7D-46B1-AC12-6E33028FC7E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 09 Mar 2015, at 19:48, Raif S. Berent wrote: >=20 > I would not give this problem a second thought, since 40 to 50 ports = regularly break during poudriere runs. The exception for this port is = that many downstream ports (>370 for me) depend on it. Then, a "# make = package" from host gets accepted by the poudriere queue. >=20 > ccache has no relevance to the problem, and building with GCC works. = Can we place a conditional in the Makefile {if version > trillion ; use = GCC}? > I know, I suck at coding. I'm gonna get there some day... >=20 > poudriere build log: > = https://drive.google.com/file/d/0Bxs_eepbMt6qMVp0aGFZUklmTW8/view?usp=3Dsh= aring >=20 >> I got the port to build with USE_GCC=3DANY. >> poudriere accepted (did not delete) the binary created by host so the >> full build now continues :)) It builds just fine for me with clang, so it must be something in your environment. In my case, it does not add -lm to the link command line, but still succeeds to link. So what is causing a call to sin() to be emitted in your case? You must investigate that. -Dimitry --Apple-Mail=_092C7F5C-DF7D-46B1-AC12-6E33028FC7E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlT+pd8ACgkQsF6jCi4glqNfawCg3RnycWURffF49Iu817M+zBcc TDAAnAzWIB7Z6kHb1avAMzvYZNFO7uCK =b+4D -----END PGP SIGNATURE----- --Apple-Mail=_092C7F5C-DF7D-46B1-AC12-6E33028FC7E4-- From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 09:49:36 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A1694E8 for ; Tue, 10 Mar 2015 09:49:36 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4594CCAF for ; Tue, 10 Mar 2015 09:49:36 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2A9naIV070262 for ; Tue, 10 Mar 2015 09:49:36 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2A9nahK070261; Tue, 10 Mar 2015 09:49:36 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503100949.t2A9nahK070261@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Tue, 10 Mar 2015 09:49:36 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 09:49:36 -0000 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/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ deskutils/genius | 1.0.19 | 1.0.20 ------------------------------------------------+-----------------+------------ 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. From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 10:15:31 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A80ECB1 for ; Tue, 10 Mar 2015 10:15:31 +0000 (UTC) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBDD6FB4 for ; Tue, 10 Mar 2015 10:15:29 +0000 (UTC) Received: from [84.44.176.131] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YVH2w-0001RV-Fz for freebsd-ports@freebsd.org; Tue, 10 Mar 2015 11:05:54 +0100 Date: Tue, 10 Mar 2015 11:05:53 +0100 From: Fabian Keil To: freebsd-ports@freebsd.org Subject: Re: CFT: vlc 2.2.0 Message-ID: <1521cd20.5e223c5c@fabiankeil.de> In-Reply-To: <54FDCB8D.7030906@gmail.com> References: <20150308190113.GA96042@enceladus10.kn-bremen.de> <2d36b48f.6288711f@fabiankeil.de> <54FDCB8D.7030906@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Lww6THmnfW=2SRMA=zVi./u"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 10:15:31 -0000 --Sig_/Lww6THmnfW=2SRMA=zVi./u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Scott Furry wrote: > On 09/03/2015 08:46, Fabian Keil wrote: > > Juergen Lock wrote: > > > >> I just saw vlc 2.2.0 is out and updated the port, please test: > >> > >> https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch [...] > > The only regression I noticed so far is that vlc doesn't get the final = window > > size right when it's started with a video file specified on the command= line: > > https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-renderin= g-flaw.jpg > > > > After going to fullscreen and back again (for example by hitting f twic= e) > > vlc uses the expected window size. Moving the window around has the sam= e effect. > > Loading the video through the GUI seems to work around the problem as w= ell. > > > > I'm using a tiling window manager (i3) which could be part of the probl= em > > and I wouldn't be surprised if the problem was OS-independent. > There is also a vlc preference setting to control video sizing. So, if=20 > you have the window not maximized, the window will be seen to adjust=20 > "automatically" to the video size. This can be changed in=20 > tools->preferneces->interface->"Resize Interface to video size". I=20 > believe the default for this sitting is "checked". Thanks for the info. Toggling the option off seems to prevent the problem.= =20 Fabian --Sig_/Lww6THmnfW=2SRMA=zVi./u Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT+wf4ACgkQBYqIVf93VJ0/zwCeMbTBpr8SF8zOXDYgxvP+w+Tn idAAnRH0gTDIuTG9XgUhr1eGapo2Rj7b =/SoP -----END PGP SIGNATURE----- --Sig_/Lww6THmnfW=2SRMA=zVi./u-- From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 11:38:48 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21AD7841 for ; Tue, 10 Mar 2015 11:38:48 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A84D7C42 for ; Tue, 10 Mar 2015 11:38:47 +0000 (UTC) Received: by wivr20 with SMTP id r20so2138537wiv.3 for ; Tue, 10 Mar 2015 04:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Me5FLTqkI9pmX/TRPgkUKW3jhv57UcrTALGvbnWa+7w=; b=b0FkMYGFFzV6rFHKjoqjzZAj61/wNv6qS0BVHonNCUjghdVNR0S9z5phX4KFf23RqN br0hFiN0w3/dhnMGY8JS22h4QssXKjjSicoDH0cuk7HQwZVAH5WArJDwGOa1t5DoYb+2 YzvAW9+Sb+ISMrfWlHq3f13oakpMhPHFK2+V+kczTubm2/Mj9GnD47e1KQ8PBGchazkT gvHzjO1j0w4qZUN58lQqhfh8Vo+BOkSpv/PmKh5Lz0SJkcVgOa35HFVXMz3wcEVnNzGx DfPPktwIomeDImvGcsE6K30UbYpPeR8262qmyS69kep5bR8lVIXMrfvQAs05RCq/2jpq wbhQ== MIME-Version: 1.0 X-Received: by 10.194.221.100 with SMTP id qd4mr65898765wjc.113.1425987526207; Tue, 10 Mar 2015 04:38:46 -0700 (PDT) Received: by 10.194.124.35 with HTTP; Tue, 10 Mar 2015 04:38:46 -0700 (PDT) In-Reply-To: <201503100949.t2A9nahK070261@portscout.freebsd.org> References: <201503100949.t2A9nahK070261@portscout.freebsd.org> Date: Tue, 10 Mar 2015 19:38:46 +0800 Message-ID: Subject: Re: FreeBSD ports you maintain which are out of date From: Ben Woods To: FreeBSD Ports Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 11:38:48 -0000 PR submitted: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198486 deskutils/genius: Update to 1.0.20 -- From: Benjamin Woods woodsb02@gmail.com On 10 March 2015 at 17:49, wrote: > > 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/ports@freebsd.org.html > > > Port | Current version | New version > ------------------------------------------------+-----------------+------------ > deskutils/genius | 1.0.19 | 1.0.20 > ------------------------------------------------+-----------------+------------ > > > 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 > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 12:31:14 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C889756 for ; Tue, 10 Mar 2015 12:31:14 +0000 (UTC) Received: from cicero3.cybercity.dk (cicero3.cybercity.dk [212.242.43.248]) by mx1.freebsd.org (Postfix) with ESMTP id B6C78258 for ; Tue, 10 Mar 2015 12:31:13 +0000 (UTC) Received: from mail.flipmode.dk (0x5e9159bc.adsl.cybercity.dk [94.145.89.188]) by cicero3.cybercity.dk (Postfix) with ESMTP id F090510889C for ; Tue, 10 Mar 2015 13:31:04 +0100 (CET) Received: from ns1.flipmode.dk (unknown [127.0.0.1]) by mail.flipmode.dk (Postfix) with ESMTP id D47B11F10606 for ; Tue, 10 Mar 2015 13:31:04 +0100 (CET) X-Virus-Scanned: amavisd-new at flipmode.dk Received: from mail.flipmode.dk ([127.0.0.1]) by ns1.flipmode.dk (ns1.flipmode.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pIxq_dv1ybK for ; Tue, 10 Mar 2015 13:31:04 +0100 (CET) Received: from [192.168.1.211] (unknown [62.243.124.37]) by mail.flipmode.dk (Postfix) with ESMTPSA id 4DE921F10607 for ; Tue, 10 Mar 2015 13:31:04 +0100 (CET) Message-ID: <54FEE407.7020407@tomse.dk> Date: Tue, 10 Mar 2015 13:31:03 +0100 From: Carsten Jensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: pkgng deviates from defaults? References: <54FC44A4.7050707@tomse.dk> <20150308134144.GB69925@ivaldir.etoilebsd.net> <54FD90AF.1030008@tomse.dk> <54FDBFC0.1090403@egr.msu.edu> <54FDEEE5.4000606@tomse.dk> <54FE2A88.5000004@egr.msu.edu> In-Reply-To: <54FE2A88.5000004@egr.msu.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:31:14 -0000 On 03/10/2015 12:19 AM, Adam McDougall wrote:>> Lots of good answers, thank you :-) >> >> I can understand that php 5.6 is now the default, I did major upgrades a >> few weeks back, >> and it was 5.4 that was the default then. Thats not a problem for me as >> long as the upgrade >> process isn't troublesome. >> >> But I'm wondering why pkg-ng wants to remove other packages rather than >> just upgrading >> or reinstalling due to dependencies have changed. >> Shouldn't these applications have been built using the new defaults? >> >> The problems occured during the simple: >> pkg upgrade >> >> oh, and I've seen a couple of lines similar to this: >> mod_php5 has no direct installation candidates, change it to mod_php5? >> [Y/n]: >> >> no matter what I've chosen it does nothing than exiting to the shell, >> trying to run pkg upgrade >> again and it asks the same question. >> >> Carsten >> >> > > Sorry, I meant "pkg upgrade -f" may give you better results because it > will pull down all rebuilt packages and have more information to resolve > the problem, at least in my experience. It doesn't seem like it should > be necessary though. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > I'll see if that can help me. thanks for the help. Carsten From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 16:41:24 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F01BCFF2 for ; Tue, 10 Mar 2015 16:41:24 +0000 (UTC) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC4BBA3D for ; Tue, 10 Mar 2015 16:41:24 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 0612DBDC4C; Tue, 10 Mar 2015 17:41:21 +0100 (CET) Received: from gw.in.absolight.net (gw-ecl.in.absolight.net [79.143.241.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (not verified)) by prod2.absolight.net (Postfix) with ESMTPSA id DD6D2BDC44; Tue, 10 Mar 2015 17:41:20 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by gw.in.absolight.net (Postfix) with ESMTP id 0DA14614B; Tue, 10 Mar 2015 17:41:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id 84B6F7E9F353; Tue, 10 Mar 2015 17:41:18 +0100 (CET) Date: Tue, 10 Mar 2015 17:41:17 +0100 From: Mathieu Arnold To: Olli Hauer , Adam Weinberger , ports@FreeBSD.org Subject: Re: Re: WITH_OPENSSL_PORT documentation Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:41:25 -0000 I don't think we have a timeframe, we've been doing exp-runs without openssl in base to catch ports that behaved badly. I think the openssl libs will be moved to private, but I can be wrong :-) +--On 9 mars 2015 18:10:41 +0100 Olli Hauer wrote: | Hi Mathieu, | what is the target timeframe for."soon",.e.g. for.8.x and.9.x having an | older openssl in base. | Is there wip. to hide the base ssl libs ? | -- | Sent from my Android phone with GMX Mail. Please excuse my brevity. | | Mathieu Arnold wrote: | | +--On 8 mars 2015 13:24:09 -0600 Adam Weinberger | wrote: | | Can somebody please write something---anything, even 2 | sentences---for | | the PHB about how to use WITH_OPENSSL_PORT? What users should set | it to | | to get LibreSSL for example, and what porters are supposed to put | in the | | Makefile to support it? | | | | The text at the top of bsd.openssl.mk just shows | WITH_OPENSSL_PORT=yes. A | | few sentences would be a big help, and I'm sure the doc people | would be | | happy to take care of all the markup and formatting for you. | It'll soon be a moot point, WITH_OPENSSL_PORT will be the only | option :-) | -- | Mathieu Arnold | _______________________________________________ | freebsd-ports@freebsd.org mailing list | [1]http://lists.freebsd.org/mailman/listinfo/freebsd-ports | To unsubscribe, send any mail to | "freebsd-ports-unsubscribe@freebsd.org" | | References | | 1. http://lists.freebsd.org/mailman/listinfo/freebsd-ports | _______________________________________________ | freebsd-ports@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-ports | To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" | -- Mathieu Arnold From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 19:38:26 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC37CBDA for ; Tue, 10 Mar 2015 19:38:25 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D2CC27D for ; Tue, 10 Mar 2015 19:38:25 +0000 (UTC) Received: by igjz20 with SMTP id z20so6804763igj.4 for ; Tue, 10 Mar 2015 12:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KZeDGkX8eQ26hGSe+Fav/afbT9XQLgCbwXxrT3Fb924=; b=jPTS6ZWzYO/efIIj7k7RsH+t1MRItQ3t6Ea/Yo0Oi877/lHofxTs54/OVVH5kaJQLK paP31OAyC1vgcODhjtGkd9XS1XIs030+lb6NmdDYu6bIMW2xDkafMpxvVm1wsExuwwVm 1s3j/9TlDm0ZEhBl0RTARofoy6mnL4AtdOn1ZRlVNvWNHoo+JBLXnGDxgLajonHYzvxh Wlg44xc8jU7va3Rf9rsk/M9BB0elFf4wtPztvNHcvYh4VafcmR1KaqTWfE+UtqxVnsvn 9Vq38JNTkExqraYhsNmDNdlmDMHICIJ8PWsYrMd0gLt53BDlUb2zE/UrIQqdQIEFlUV6 PGfw== X-Received: by 10.107.11.226 with SMTP id 95mr31489823iol.5.1426016305048; Tue, 10 Mar 2015 12:38:25 -0700 (PDT) Received: from [10.0.1.155] (d205-206-84-235.abhsia.telus.net. [205.206.84.235]) by mx.google.com with ESMTPSA id 94sm1024694iod.23.2015.03.10.12.38.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 12:38:24 -0700 (PDT) Message-ID: <54FF482E.2070807@gmail.com> Date: Tue, 10 Mar 2015 13:38:22 -0600 From: Scott Furry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Juergen Lock Subject: Re: qemu-devel usage References: <201503071805.t27I5HoV056581@enceladus10.kn-bremen.de> In-Reply-To: <201503071805.t27I5HoV056581@enceladus10.kn-bremen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:38:26 -0000 On 07/03/2015 11:05, Juergen Lock wrote: > In article <54F64BBC.4060502@gmail.com> you write: >> I didn't have to go to this extreme when I setup qemu networking on a >> linux box. However, new OS. :) >> >> From my original setup files for qemu, I had used the -enable-kvm and >> -cpu host flags (see 2 below). Qemu on BSD just didn't want to accept >> "host" as a cpu option. The reference did point out how the flag worked, >> something I didn't realize. However, it would be really good to have the >> "host" flag to pass along the cpu accelerators to the VM without having >> to call them individually. Is anyone working on this? Just to amend this observation...I wouldn't worry about this ATM. "-cpu host" hides a lot of details about settings in qemu. When moving over to another VM tool, those hidden settings/unknown defaults become painful to manage. >> Is the -enable-kvm flag mentioned earlier still required here? > A little bit of history: qemu started as jit-only (software > emulation), then came kqemu, then kqemu was replaced by kvm. > However, the FreeBSD kvm kernel bits port was never finished so > recent qemu versions (qemu-devel, qemu-sbruno) are stuck with jit > again which means for x86-on-x86 virtualization you're better off > with bhyve or vbox, they're simply faster, I've since managed to convert images over to vdi's. Tweaking the settings for host params was...amusing?...entertaining?...challenging?...painful! (see comment above). Even with the links you gave to the handbook, I ended up on the Oracle site to learn there was a gui that could be used to manage things. And here I was dreading the idea of text file setup's. The gui has some painful quirks but is usable. Learning "what is a sane default" can be a determent to a steep learning curve. And I'm shaking my head at the foolishness. You can call a file by name, but must clean by UUID. And VBox doesn't provide a "UUID from name search" mechanism. I ended up modifying my original images "cleaning/backup" script to pull the UUID from a VBoxManager call. Speaking of entertaining... The blurring and cross-usage of qemu, kqemu and KVM made searching difficult. But the little history you provided makes reading through search results suddenly more CLEARER! Thank you. > The main use of the qemu ports on FreeBSD is for testing/emulating > other than the host arch From the available ports - got it. Having used qemu on other OS's. I was hoping to just pickup and carry on with existing files. Lovely thought on my part. Not possible practically. The move to VBox was inevitable it appears. Overall, I have my Win7 and BSD emulations working in VBox. I'm good. Juergen. Thanks for the details and the response! Scott From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 19:45:55 2015 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A977AF8E; Tue, 10 Mar 2015 19:45:55 +0000 (UTC) Received: from smtp.kn-bremen.de (gruenbaer.kn-bremen.de [148.251.8.79]) by mx1.freebsd.org (Postfix) with ESMTP id C643438C; Tue, 10 Mar 2015 19:45:54 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 120523DE0E2C; Tue, 10 Mar 2015 20:45:52 +0100 (CET) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id t2AJfn6s082507; Tue, 10 Mar 2015 20:41:49 +0100 (CET) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id t2AJfmlc082506; Tue, 10 Mar 2015 20:41:48 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Tue, 10 Mar 2015 20:41:48 +0100 To: Baptiste Daroussin Subject: Re: CFT: vlc 2.2.0 Message-ID: <20150310194148.GA82364@enceladus10.kn-bremen.de> References: <20150308190113.GA96042@enceladus10.kn-bremen.de> <201503092115.t29LF44v042910@enceladus10.kn-bremen.de> <20150309232107.GA33487@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150309232107.GA33487@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@FreeBSD.org, Juergen Lock X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:45:55 -0000 On Tue, Mar 10, 2015 at 12:21:07AM +0100, Baptiste Daroussin wrote: > On Mon, Mar 09, 2015 at 10:15:04PM +0100, Juergen Lock wrote: > > In article <2d36b48f.6288711f@fabiankeil.de> you write: > > >Juergen Lock wrote: > > > > > >> I just saw vlc 2.2.0 is out and updated the port, please test: > > >>=20 > > >> https://people.freebsd.org/~nox/tmp/vlc-2.2.0-001.patch > > > > > >Thanks for the update. > > > > > >I get a couple of warnings at build time: > > > > > >configure: WARNING: unrecognized options: --disable-egl, --disable-libvnc, --disable-quicksync, --enable-dirac, --enable-glx, --with-qt-includes, --with-qt-libraries, --with-extra-includes, --with-extra-libs > > >[...] > > > > Yeah probably not important. > > > > >====> Running Q/A tests (stage-qa) > > >Warning: 'lib/vlc/plugins/codec/libtheora_plugin.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} > > >[... same message for the other plugins ....] > > > > > Not sure plugins should be stripped... > They should at least no reason not to strip them > > Added a STRIP_CMD: https://people.freebsd.org/~nox/tmp/vlc-2.2.0-002.patch > > >The installed binary seems to mostly work as expected. > > > > > >The only regression I noticed so far is that vlc doesn't get the final window > > >size right when it's started with a video file specified on the command line: > > >https://www.fabiankeil.de/bilder/screenshots/vlc/vlc-2.2.0-001-rendering-flaw.jpg > > > > > >After going to fullscreen and back again (for example by hitting f twice) > > >vlc uses the expected window size. Moving the window around has the same effect. > > >Loading the video through the GUI seems to work around the problem as well. > > > > > >I'm using a tiling window manager (i3) which could be part of the problem > > > > Possibly, I don't see this on lxde here. (which isn't tiling) > > > > >and I wouldn't be surprised if the problem was OS-independent. > > > > > Right. > > > > Thanx for testing! :) > > Juergen > > _______________________________________________ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 20:12:03 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C039639 for ; Tue, 10 Mar 2015 20:12:03 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30B358E9 for ; Tue, 10 Mar 2015 20:12:02 +0000 (UTC) Received: (qmail 2381 invoked from network); 10 Mar 2015 20:11:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Mar 2015 20:11:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 10 Mar 2015 16:11:54 -0400 (EDT) Received: (qmail 31390 invoked from network); 10 Mar 2015 20:11:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Mar 2015 20:11:54 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 789801C43AC; Tue, 10 Mar 2015 13:11:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> Date: Tue, 10 Mar 2015 13:11:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> References: <54FC7D92.3010405@freebsd.org> <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> To: Nathan Whitehorn , freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:12:03 -0000 Brad King is adding the missing static to _stl_next_prime in KWSys and = from there it will eventually propagate into CMake's code base. Actually = in KWSys both static's are to be added. ( = http://review.source.kitware.com/#/c/19465/ ) Brad wrote that CMake's code base had added the static to = _get_stl_prime_list to handle a linking problem in some environment. = (Despite not knowing of KWSys I had guessed that there was some reason = why that static was there: that is why I suggested the direction of = making _stl_next_prime match instead of suggesting removing the static = on _get_stl_prime_list.) Once propagated the updates will make KWSys and = CMake's code again match in this area. So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG=3D= to be better behaved for CMake's programs that use it's hashtable.hxx . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-9, at 08:09 AM, Mark Millard wrote: I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan = "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 21:00:39 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1765489 for ; Tue, 10 Mar 2015 21:00:39 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FD11F0F for ; Tue, 10 Mar 2015 21:00:39 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id t2AL0RS1099652 for ; Tue, 10 Mar 2015 17:00:28 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id t2AL0Rhr099651 for ports@freebsd.org; Tue, 10 Mar 2015 17:00:27 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 10 Mar 2015 17:00:24 -0400 From: "Michael W. Lucas" To: ports@freebsd.org Subject: must resign maintainership of www/mod_auth_xradius Message-ID: <20150310210024.GA99605@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.michaelwlucas.com [127.0.0.1]); Tue, 10 Mar 2015 17:00:32 -0400 (EDT) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:00:40 -0000 Hi, I no longer have a working SSH key for the cluster, or I'd log in and add this to bugzilla myself. I no longer run web server farms, so I need to withdraw maintainership of www/mod_auth_xradius. Forgot about this until bug 198498 got sent to me. I no longer have an environment where I could realistically test this patch. Can someone pull me off this port? Thanks, ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 22:52:21 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEC03F3B for ; Tue, 10 Mar 2015 22:52:21 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A41C7E0E for ; Tue, 10 Mar 2015 22:52:21 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so34436495iec.0 for ; Tue, 10 Mar 2015 15:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=YF7MM4g4u0w27ysE65fbiK5WZTXDjHAnW/Z5kS8/gns=; b=wcNt7MKh90esI1OwOOD8W8FIot1aX6HxnPt1Giqn1YpUx79rGRWuLoMUpxGdomSo5k b0EgfgqkaKxmuiBtBsYhqwMbDd1LtAT4pIDEsi9/Ivf7PbOjX5Thp7s+qKz/pBypit5B FAeB6L8LSeaA/0YKjh0NRP9FDAKJ9MgaurjM17Naa+ulOf6ZLR9hDZEdXnALiT9VyqC4 xy6Gwn7UD4+UgcJBeNCd4b7/h017IjacwsRD6b/xwJOGSRZdIilLo7V1L7034HcyTjK7 GxQtj2nHCCL9BMgKzURnAueZl1SnpRbYRHKHlGOPi0lKms/f9hmvZTb6MB/doLe+YjqA 3Exw== X-Received: by 10.50.50.142 with SMTP id c14mr59992938igo.42.1426027941144; Tue, 10 Mar 2015 15:52:21 -0700 (PDT) Received: from [10.0.1.155] (d205-206-84-235.abhsia.telus.net. [205.206.84.235]) by mx.google.com with ESMTPSA id ik7sm1347297igb.1.2015.03.10.15.52.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 15:52:20 -0700 (PDT) Message-ID: <54FF75A2.4020803@gmail.com> Date: Tue, 10 Mar 2015 16:52:18 -0600 From: Scott Furry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: converters/iconv versioning Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:52:22 -0000 I am running into in a situation with other C code where a call to iconv and passing in a non-const source buffer would result in a build warning. Others who use the same code on other platforms do not report this warning. In tracking down the issue, I have discovered that there may be a difference in the iconv.h header file used on FreeBSD versus Mac/Linux et al. http://www.opensource.apple.com/source/libiconv/libiconv-30/install/iconv.h line 48 shows that call to iconv ----- size_t iconv (iconv_t /*cd*/, char ** __restrict /*inbuf*/, size_t * __restrict /*inbytesleft*/, char ** __restrict /*outbuf*/, size_t * __restrict /*outbytesleft*/); ---- /usr/local/include/iconv.h, line 83, shows something rather different. Even the commentary around the code is different. ----- extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); ----- My question is this, are we using a different or FreeBSD-specific version of iconv? S From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 23:02:08 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9960868A; Tue, 10 Mar 2015 23:02:08 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A9DD12D; Tue, 10 Mar 2015 23:02:08 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2AN1vAM086479; Tue, 10 Mar 2015 15:02:01 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503102302.t2AN1vAM086479@gw.catspoiler.org> Date: Tue, 10 Mar 2015 16:01:57 -0700 (PDT) From: Don Lewis Subject: Re: proper DOXYGEN option default value To: swills@FreeBSD.org In-Reply-To: <20150310024736.GB30716@mouf.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 23:02:08 -0000 On 10 Mar, Steve Wills wrote: > On Wed, Mar 04, 2015 at 02:41:48PM -0800, Don Lewis wrote: >> I maintain a number of ports that use doxygen to generate their >> documentation. They all list DOXYGEN in OPTIONS_DEFAULT so that >> the packages will include documentation. >> >> I recently received a PR for one of those ports that mentioned that most >> users don't require the documentation and pointed out that anyone >> building the port will find it is very painful because of the amount of >> time it takes to build doxygen and all of its dependencies (primarily >> all the TeX stuff). >> >> It's been my experience that there is enough churn in the dependencies >> that the whole mess needs to get rebuilt fairly frequently. >> >> As I see it, the pros and cons of listing DOXYGEN in OPTIONS_DEFAULT >> are: >> Pros: >> * Users who need the documentation can use the binary packages if >> they desire >> * This option gets regular exercise on the build cluster >> Cons: >> * A bit of extra load on the ports build cluster to install >> doxygen and its dependencies as a BUILD_DEPENDS for each >> supported OS version and architecture >> * The packages are a bit larger >> * A bit more space is consumed on the user's machine because >> documentation is installed, even if they don't need it >> * Users building from ports have to build and install doxygen >> and it's dependencies unless they take measures to avoid it, >> either by disabling the option for each port or adding >> OPTIONS_UNSET=DOXYGEN to their /etc/make.conf to do this >> globally >> >> The pros and cons of removing DOXYGEN from OPTIONS_DEFAULT: >> Pros: >> * Less load on the ports build cluster >> * Smaller packages >> * Less space consumed on most user machines >> * Users building from ports who do not need the documentation don't >> pay the doxygen penalty without taking any special measures >> Cons: >> * Anyone who does need the documentation has to build from the >> port and pay the cost of building and installing doxygen and its >> dependencies. >> * The DOXYGEN option would not get regular testing and could be >> subject to bit rot. >> >> Ideally, the documentation could be built and packaged separately. It >> could even be NO_ARCH. Unfortunately, at this time this would require >> adding a bunch of new ports just for the documentation. >> >> Since these ports only generate HTML documentation, it might be helpful >> to have a doxygen-lite port that has GRAPHVIZ and LATEX disabled, and >> use that as a BUILD_DEPENDS. That introduces the problem of conflicts >> between doxygen and doxygen-lite if someone who builds from ports needs >> the full featured doxygen for other purposes. >> >> Since we have neither of the above, should I leave my ports as-is, or >> should I disable DOXYGEN by default? > > Personally I would tend to lean towards leaving DOXYGEN off by default, > especially if there is other accompanying documentation. This is the case for > lang/ruby* for example. There's no other documentation in this case. Excluding the DOXYGEN stuff, this is the entire pkg-plist: bin/protoc-c include/google/protobuf-c/protobuf-c.h include/protobuf-c/protobuf-c.h lib/libprotobuf-c.a lib/libprotobuf-c.so lib/libprotobuf-c.so.1 lib/libprotobuf-c.so.1.0.0 libdata/pkgconfig/libprotobuf-c.pc That does sound like a good general guideline, though. > But beward that this may mean it is more likely that the DOXYGEN parts of the > plist may become outdated when the doxygen port is updated. So keep testing > that option. I've run into that problem when listing the DOXYGEN output explicitly in pkg-plist. I've since switched to PORTDOCS=* to avoid this source of breakage. From owner-freebsd-ports@FreeBSD.ORG Tue Mar 10 23:30:43 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4C46C84 for ; Tue, 10 Mar 2015 23:30:43 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51603401 for ; Tue, 10 Mar 2015 23:30:43 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2ANUZ5H086530 for ; Tue, 10 Mar 2015 15:30:39 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503102330.t2ANUZ5H086530@gw.catspoiler.org> Date: Tue, 10 Mar 2015 16:30:35 -0700 (PDT) From: Don Lewis Subject: possible to adjust OPTIONS_DEFAULT based on COMPILER_TYPE? To: ports@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 23:30:43 -0000 I've run into a situation where I'd like to change OPTIONS_DEFAULT based on the value of the value of COMPILER_TYPE. I'm setting USE_GCC=yes. If the base compiler is gcc, then I can enable a particular option to make the port more featureful. If the base compiler is clang, then some of the other ports the option depends on are C++ code that gets compiled with clang and the port breaks because of the libstdc++ vs. libc++ conflict. In that case, I'd like to disable the option to at least have working binary packages available, even though they aren't as featureful. This doesn't look possible, though. OPTIONS_DEFAULT needs to be set before the .include , and COMPILER_TYPE isn't set until after that, or possibly even after bsd.port.pre.mk. From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 00:05:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DE0520A for ; Wed, 11 Mar 2015 00:05:34 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D583F9B0 for ; Wed, 11 Mar 2015 00:05:33 +0000 (UTC) Received: by wggx12 with SMTP id x12so5422094wgg.10 for ; Tue, 10 Mar 2015 17:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Eg+c+XKuxvAQToB8px6VUh6NVEe4oHjUOLoi1JW0iU=; b=tt7JPxgZNCvAoOcwZ8FLf0YHy3qExfiD/XMo2OJx36OPlU/HbwS9CRwXkA1YpONL63 ZHfw/zlxRzG21ecDO9MvkFv+bXtlpb0gxU3XfH6eStaYXo9ZvNlCunj5qrhbg2iMGz3M jHGJpb+Y5EzlrSncr4NJ1twYhqWCQtWSJBsroW4mvkrfxlj0AUouMX2b6dBE1dATylkH MzKfsUJra3AHE/VGzt1Rtq2poz13Duj4tjOuIsAiFqh0Qn9tIqSQXj3HNTMfJpm0GSrC DJyia6sdZx4XU/HyGk+LCyKY4nUsJE2S0tKcbW2rVd8YbLIOJ4bj8OtDhzRxd7tV8cTW rZ/Q== MIME-Version: 1.0 X-Received: by 10.180.198.13 with SMTP id iy13mr43714871wic.7.1426032332354; Tue, 10 Mar 2015 17:05:32 -0700 (PDT) Received: by 10.194.124.35 with HTTP; Tue, 10 Mar 2015 17:05:32 -0700 (PDT) In-Reply-To: <54FF75A2.4020803@gmail.com> References: <54FF75A2.4020803@gmail.com> Date: Wed, 11 Mar 2015 08:05:32 +0800 Message-ID: Subject: Re: converters/iconv versioning From: Ben Woods To: Scott Furry Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:05:34 -0000 FreeBSD has its own native iconv (since FreeBSD 10). More details (including reference to commits) here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-iconv.html Regards, Ben On Wednesday, March 11, 2015, Scott Furry wrote: > I am running into in a situation with other C code where a call to iconv > and passing in a non-const source buffer would result in a build warning. > Others who use the same code on other platforms do not report this warning. > > In tracking down the issue, I have discovered that there may be a > difference in the iconv.h header file used on FreeBSD versus Mac/Linux et > al. > > http://www.opensource.apple.com/source/libiconv/libiconv- > 30/install/iconv.h > line 48 shows that call to iconv > ----- > size_t iconv (iconv_t /*cd*/, > char ** __restrict /*inbuf*/, size_t * __restrict /*inbytesleft*/, > char ** __restrict /*outbuf*/, size_t * __restrict /*outbytesleft*/); > ---- > > /usr/local/include/iconv.h, line 83, shows something rather different. > Even the commentary around the code is different. > ----- > extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, > char* * outbuf, size_t *outbytesleft); > ----- > > > My question is this, are we using a different or FreeBSD-specific version > of iconv? > > S > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 00:27:48 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B94F647F for ; Wed, 11 Mar 2015 00:27:48 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79A58BD9 for ; Wed, 11 Mar 2015 00:27:48 +0000 (UTC) Received: by iecsf10 with SMTP id sf10so287735iec.2 for ; Tue, 10 Mar 2015 17:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dICMdqRUg8B8BhCnLf6PyDN1LxNMHF2mCvg82wietHs=; b=k9EdrqVioMFQfACPAjygyT8yPCo1Jlstt8miXLfRuZFguRY10X0R129Vx4io4HTp3y gZS9l1y6Kqeb0mw4Ncm3LievPpOh/xZJPc6FqN6uLjSW6xXRuQqcAXs1pDjsczrW+eES 2tTBtA9EUbVzgl8P/qcajMEVUuMMvXY7nkuKkTKw9vL7r0KpqGKzQW0xZROqHeAt2ixH vF24fIzo3iTbDZUI5RiujOonf0UsS5nWtmXRd+cPpZc78s8HR3zoPa+0PgHfQ1Lqbw05 3pDHPng+vjnO+55OOLK0dy1qMZ9ZmVV/wMPWPVnCPC3e2TKS1FCKJRtiTpm/6XsErZyP aMNA== X-Received: by 10.50.171.170 with SMTP id av10mr87287020igc.28.1426033179930; Tue, 10 Mar 2015 17:19:39 -0700 (PDT) Received: from [10.0.1.155] (d205-206-84-235.abhsia.telus.net. [205.206.84.235]) by mx.google.com with ESMTPSA id f1sm1465865igt.14.2015.03.10.17.19.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 17:19:39 -0700 (PDT) Message-ID: <54FF8A19.3090700@gmail.com> Date: Tue, 10 Mar 2015 18:19:37 -0600 From: Scott Furry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Woods Subject: Re: converters/iconv versioning References: <54FF75A2.4020803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:27:48 -0000 On 10/03/2015 18:05, Ben Woods wrote: > On Wednesday, March 11, 2015, Scott Furry > wrote: > > I am running into in a situation with other C code where a call to > iconv and passing in a non-const source buffer would result in a > build warning. Others who use the same code on other platforms do > not report this warning. > > In tracking down the issue, I have discovered that there may be a > difference in the iconv.h header file used on FreeBSD versus > Mac/Linux et al. > > http://www.opensource.apple.com/source/libiconv/libiconv-30/install/iconv.h > line 48 shows that call to iconv > ----- > size_t iconv (iconv_t /*cd*/, > char ** __restrict /*inbuf*/, size_t * __restrict > /*inbytesleft*/, > char ** __restrict /*outbuf*/, size_t * __restrict > /*outbytesleft*/); > ---- > > /usr/local/include/iconv.h, line 83, shows something rather different. > Even the commentary around the code is different. > ----- > extern size_t iconv (iconv_t cd, const char* * inbuf, size_t > *inbytesleft, char* * outbuf, size_t *outbytesleft); > ----- > > > My question is this, are we using a different or FreeBSD-specific > version of iconv? > > S > > > FreeBSD has its own native iconv (since FreeBSD 10). > > More details (including reference to commits) here: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-iconv.html > > Regards, > Ben Okay...different iconv. But what's the reason for change? And does this one function call really need to be const? Is the __restrict in the type not used on FreeBSD? Seems strange to differ on a gnu-based. S From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 09:07:15 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA2FC1EF for ; Wed, 11 Mar 2015 09:07:15 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E104A02 for ; Wed, 11 Mar 2015 09:07:15 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hq12so2484035vcb.12 for ; Wed, 11 Mar 2015 02:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=PXQRsbrYnzcuoJdtidzS5xiAjm/f2PHYk0R5iitVRFA=; b=s9iURdPzZGQtCwMaKMnaVMqtUvPQlK1QH8kR7mvKZDyjp4xqvCcDiO5K1vJZAbCBDy IoOq4cZ9HCV/Oe4Iw+8G5tQtzvmsJlyEos/Gf3CbHyVRLrCukK+5dHbz0tlx8jKsWir2 //4g0MgVNhkAaLj1P+nGoIScrtr0lnBo+mAp5YVKIit0U8rEju/Rg4qV2X3CswlTknMp QHLZASg6nWsGe/Qpd19Tk7ik29Ah0inuYx9PJDYCX+o5nwtPjtRBP1ZdamwYmYMAFFd5 sz0wD2g0pQoPO8rYy/7l3T/tvS3d+0avMz4jFgZ6fUrLUfxeVm4COqyHVQu7dKzjWggp 2Row== MIME-Version: 1.0 X-Received: by 10.52.27.175 with SMTP id u15mr11218407vdg.55.1426064834521; Wed, 11 Mar 2015 02:07:14 -0700 (PDT) Received: by 10.52.29.106 with HTTP; Wed, 11 Mar 2015 02:07:14 -0700 (PDT) In-Reply-To: References: <4c18dec0d168e393ff5dddfdc65c7ec6@sdf.org> <20150228074951.GD62590@home.opsec.eu> <20150228110834.GF62590@home.opsec.eu> Date: Wed, 11 Mar 2015 12:07:14 +0300 Message-ID: Subject: Re: Initial squid 3.5 port From: Pavel Timofeev Cc: ports-list freebsd Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 09:07:15 -0000 Hi! I've just made a small update there https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198089 2015-02-28 15:30 GMT+03:00 Pavel Timofeev : > Ok, I'll do my best. > > 2015-02-28 14:08 GMT+03:00 Kurt Jaeger : >> Hi! >> >>> > Just in case, I uploaded it here https://yadi.sk/d/EcRxwc6BevgDc >>> >>> I've created >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198089 >>> >>> with that shar and I'm build-testing it right now. >> >> build testing: works on 10.1a, fails on 9.3a, 8.4i. >> >> poudriere build logs can be found at >> >> http://people.freebsd.org/~pi/logs/www__squid35* >> >> Older builds are with a custom config, newer builds with the generic config. >> >> Can you investigate the cause of the issue ? >> >> -- >> pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 09:58:41 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64172409 for ; Wed, 11 Mar 2015 09:58:41 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46F8FF54 for ; Wed, 11 Mar 2015 09:58:41 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2B9wfrN063031 for ; Wed, 11 Mar 2015 09:58:41 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2B9wfPp063030; Wed, 11 Mar 2015 09:58:41 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503110958.t2B9wfPp063030@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 11 Mar 2015 09:58:41 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 09:58:41 -0000 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/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ biology/tinker | 7.1.1 | 7.1.2 ------------------------------------------------+-----------------+------------ japanese/p5-Lingua-JA-Numbers | 0.04 | 0.05 ------------------------------------------------+-----------------+------------ x11-toolkits/p5-Alien-wxWidgets | 0.65 | 0.67 ------------------------------------------------+-----------------+------------ 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. From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 11:13:43 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DF4B25C; Wed, 11 Mar 2015 11:13:43 +0000 (UTC) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E1042A4D; Wed, 11 Mar 2015 11:13:42 +0000 (UTC) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 65292BDC56; Wed, 11 Mar 2015 12:13:39 +0100 (CET) Received: from gw.in.absolight.net (gw-ecl.in.absolight.net [79.143.241.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gw.in.absolight.net", Issuer "CA Cert Signing Authority" (not verified)) by prod2.absolight.net (Postfix) with ESMTPSA id 3F4FEBDC1D; Wed, 11 Mar 2015 12:13:39 +0100 (CET) Received: from ogg.in.absolight.net (ogg.in.absolight.net [79.143.241.239]) by gw.in.absolight.net (Postfix) with ESMTP id EEBD9617C; Wed, 11 Mar 2015 12:13:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ogg.in.absolight.net (Postfix) with ESMTP id 4B1AA7EAB302; Wed, 11 Mar 2015 12:13:36 +0100 (CET) Date: Wed, 11 Mar 2015 12:13:35 +0100 From: Mathieu Arnold To: Don Lewis , ports@FreeBSD.org Subject: Re: possible to adjust OPTIONS_DEFAULT based on COMPILER_TYPE? Message-ID: In-Reply-To: <201503102330.t2ANUZ5H086530@gw.catspoiler.org> References: <201503102330.t2ANUZ5H086530@gw.catspoiler.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 11:13:43 -0000 +--On 10 mars 2015 16:30:35 -0700 Don Lewis wrote: | I've run into a situation where I'd like to change OPTIONS_DEFAULT based | on the value of the value of COMPILER_TYPE. I'm setting USE_GCC=yes. If | the base compiler is gcc, then I can enable a particular option to make | the port more featureful. If the base compiler is clang, then some of | the other ports the option depends on are C++ code that gets compiled | with clang and the port breaks because of the libstdc++ vs. libc++ | conflict. In that case, I'd like to disable the option to at least have | working binary packages available, even though they aren't as | featureful. | | This doesn't look possible, though. OPTIONS_DEFAULT needs to be set | before the .include , and COMPILER_TYPE isn't set | until after that, or possibly even after bsd.port.pre.mk. Mmmm, yes, you're kinda stuck, I've already had a look, and it's not possible to have options working including port.options and also be able to change stuff after it. Though, USE_GCC=yes will never use the old base gcc, but always lang/gcc (well, the one defined in bsd.default-versions, which if left alone is lang/gcc), USE_GCC=any will use gcc from base though, but I'm not sure you can have a good reason to use it. -- Mathieu Arnold From owner-freebsd-ports@FreeBSD.ORG Wed Mar 11 18:03:18 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16516F1C; Wed, 11 Mar 2015 18:03:18 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98AE13E4; Wed, 11 Mar 2015 18:03:17 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2BI37Q0092119; Wed, 11 Mar 2015 10:03:11 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503111803.t2BI37Q0092119@gw.catspoiler.org> Date: Wed, 11 Mar 2015 11:03:07 -0700 (PDT) From: Don Lewis Subject: Re: possible to adjust OPTIONS_DEFAULT based on COMPILER_TYPE? To: mat@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:03:18 -0000 On 11 Mar, Mathieu Arnold wrote: > +--On 10 mars 2015 16:30:35 -0700 Don Lewis wrote: > | I've run into a situation where I'd like to change OPTIONS_DEFAULT based > | on the value of the value of COMPILER_TYPE. I'm setting USE_GCC=yes. If > | the base compiler is gcc, then I can enable a particular option to make > | the port more featureful. If the base compiler is clang, then some of > | the other ports the option depends on are C++ code that gets compiled > | with clang and the port breaks because of the libstdc++ vs. libc++ > | conflict. In that case, I'd like to disable the option to at least have > | working binary packages available, even though they aren't as > | featureful. > | > | This doesn't look possible, though. OPTIONS_DEFAULT needs to be set > | before the .include , and COMPILER_TYPE isn't set > | until after that, or possibly even after bsd.port.pre.mk. > > Mmmm, yes, you're kinda stuck, I've already had a look, and it's not > possible to have options working including port.options and also be able to > change stuff after it. > > Though, USE_GCC=yes will never use the old base gcc, but always lang/gcc > (well, the one defined in bsd.default-versions, which if left alone is > lang/gcc), USE_GCC=any will use gcc from base though, but I'm not sure you > can have a good reason to use it. At present, I always need to compile with gcc from ports, which is why I use USE_GCC=yes. On systems where clang is the base compiler, many ports with C++ code will use clang as their compiler and I need to avoid bringing in any of those because they will drag in libc++, which conflicts with libstdc++ that we use when compiling with gcc. One of the options for this port (that I want to enable by default) brings in one of those libraries, so I want to disable that option by default. I've come up with a workaround. Basically I'm duplicating the code from /usr/ports/Mk/Uses/compiler.mk that sets COMPILER_TYPE and adding it to Makefile before the OPTIONS stuff. Portlint -a whines about the !=, but I can live with that since this is hopefully a short term fix until I can get the port converted to build with clang. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 09:51:49 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 206FEE78 for ; Thu, 12 Mar 2015 09:51:49 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BAE4CE3 for ; Thu, 12 Mar 2015 09:51:49 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C9pmVP058156 for ; Thu, 12 Mar 2015 09:51:48 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2C9pm26058155; Thu, 12 Mar 2015 09:51:48 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503120951.t2C9pm26058155@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Thu, 12 Mar 2015 09:51:48 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 09:51:49 -0000 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/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ ftp/pear-Net_FTP | 1.3.7 | 1.4.0 ------------------------------------------------+-----------------+------------ textproc/py-texttable | 0.8.2 | 0.8.3 ------------------------------------------------+-----------------+------------ www/pecl-http | 2.3.1 | 2.3.2 ------------------------------------------------+-----------------+------------ 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. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 12:17:01 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A913C9E3 for ; Thu, 12 Mar 2015 12:17:01 +0000 (UTC) Received: from eu1sys200aog129.obsmtp.com (eu1sys200aog129.obsmtp.com [207.126.144.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05CF7EB4 for ; Thu, 12 Mar 2015 12:17:00 +0000 (UTC) Received: from mail-wi0-f180.google.com ([209.85.212.180]) (using TLSv1) by eu1sys200aob129.postini.com ([207.126.147.11]) with SMTP ID DSNKVQGDogVA02jDlNhXPCuTasn54fE4Tm5w@postini.com; Thu, 12 Mar 2015 12:17:01 UTC Received: by wiwl15 with SMTP id l15so47139021wiw.4 for ; Thu, 12 Mar 2015 05:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=4mLXgCHBzkKxZwwpvRepdoVSyatZWJnzefBCprroLf4=; b=AbclEg6kKcpamVzrvvPGS5apNap4qtVjEYIGCs59LvZmQ6xX4Ssg6bYVsRIU2RtKJx 9vtMPT7e/DcX4rnGYnU9JDpn2RYZVCrDYKSjOUsT91mR82pfRDm2z1FB4lYRIJWAHJOY Ug7Wb8eNvxweRLMWGAiNsUQLvekzOJPJLnQcv0gqy7/KEvDx6LTjANHnoQIjUaYrHhhn fvzHvbj1+PTBA4Jv0chLH51DtLuAjKVeyVHsdr2AlIJb7vVRP87kZpx7UFCxXuq2mAEv 22o3SUFNDG5vssQ/0kUAGhb8rIp75pjzkSBzDvSiNkUfXazTMDYT8fyaUR2nrqRgwejy b6oA== X-Received: by 10.194.59.199 with SMTP id b7mr87675810wjr.26.1426161130499; Thu, 12 Mar 2015 04:52:10 -0700 (PDT) X-Gm-Message-State: ALoCoQmLbasbX38YyR/U1x5z+5mGYPNeRyk4jIWmTw1fDHwlu8aXO4ph+EriOrGiZfYfc0+041A/R+lRos7DjEiDFNjSrqohIEvS4puHVxOxbZOhngLDWIDd4bgXEELnBNXB5RiACYUbM4kAOZ6ev9FJSfaljNPyvw== X-Received: by 10.194.59.199 with SMTP id b7mr87675788wjr.26.1426161130356; Thu, 12 Mar 2015 04:52:10 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id cn10sm10346781wib.15.2015.03.12.04.52.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 04:52:09 -0700 (PDT) Date: Thu, 12 Mar 2015 04:52:09 -0700 (PDT) X-Google-Original-Date: Thu, 12 Mar 2015 11:52:08 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2CBq8fw054189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Mar 2015 11:52:08 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2CBq8ku054188 for freebsd-ports@freebsd.org; Thu, 12 Mar 2015 11:52:08 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503121152.t2CBq8ku054188@mech-as221.men.bris.ac.uk> To: freebsd-ports@freebsd.org Subject: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 12:17:01 -0000 I'm still trying to figure out why flash wouldn't work on this particular laptop. I see this error/warning: $ sysctl -a | grep "compat.linux.os" <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory compat.linux.osname: Linux compat.linux.osrelease: 2.6.18 compat.linux.oss_version: 198144 I don't understand what it means. $ grep linux /etc/sysctl.conf compat.linux.osrelease=2.6.18 This is correct, right? I copied this from $ grep osrelease /usr/ports/UPDATING| grep 18 compat.linux.osrelease=2.6.18 compat.linux.osrelease=2.6.18 # sysctl compat.linux.osrelease=2.6.18 Please advise Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 13:01:56 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE7FF3D0 for ; Thu, 12 Mar 2015 13:01:56 +0000 (UTC) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D602609 for ; Thu, 12 Mar 2015 13:01:54 +0000 (UTC) Received: from mail-wg0-f48.google.com ([74.125.82.48]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKVQGOJNEZhXf/0woCFVddWuHFRS2BcKn6@postini.com; Thu, 12 Mar 2015 13:01:55 UTC Received: by wgha1 with SMTP id a1so16258925wgh.1 for ; Thu, 12 Mar 2015 06:01:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=W8/KBut9wakbkkjnE0CYrXxr9WnSyOTtZDRYB2srSjs=; b=Zmu6IgkhkCp+K5nGbuKZ87H22ocv8LY18Uz2U/QBEGVHN09xOC5a3pAexm3mpaqHkc lCTn3w5xBoHjkYf8f+YDR4oaWtQ6t2qDcB1Hz4ETgdrofnFIeQFMOJKWU4WABAFACTk4 fI+K5ApGYwrVDD3HgFpfzNpa3Zley50A87+RH9Qpakj1GEwKETP+WqxWXXapwwxPhb3x jfxkeSmSY3BGMhnGjzLwRD3L9s+aGziwLToN42iBlvBdIUL+MzJ+I2IFJMiSbqeDD3hp Wz1p5cj3THbifQbzTKa9dyCHCFpNtZ1d4xFFZXlqYu3y0x01uJ3rtTeOPNMvY5u1kvhE yiig== X-Received: by 10.194.109.9 with SMTP id ho9mr85662827wjb.29.1426164896260; Thu, 12 Mar 2015 05:54:56 -0700 (PDT) X-Gm-Message-State: ALoCoQkp4sl0LXTos9K3+1SP2OrfUMnfYcgdMMILwbawR0/1ZOr5BGy7UcI4wcnuh+4uA8Ia5ktMYY/UmbORAy2h1MPtBlANKItec+6GJ6xgQGpMKUctK77GzBCwqdubz0HSNudzdE0MUCjUYqBLa9/E4ByG6fq/nA== X-Received: by 10.194.109.9 with SMTP id ho9mr85662793wjb.29.1426164896009; Thu, 12 Mar 2015 05:54:56 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id l9sm10591763wij.16.2015.03.12.05.54.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 05:54:55 -0700 (PDT) Date: Thu, 12 Mar 2015 05:54:55 -0700 (PDT) X-Google-Original-Date: Thu, 12 Mar 2015 12:54:53 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2CCsrcU054426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Mar 2015 12:54:54 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2CCsrsE054425 for freebsd-ports@freebsd.org; Thu, 12 Mar 2015 12:54:53 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503121254.t2CCsrsE054425@mech-as221.men.bris.ac.uk> To: freebsd-ports@freebsd.org Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:01:57 -0000 >From mexas Thu Mar 12 12:49:17 2015 >To: david@catwhisker.org, mexas@bris.ac.uk >Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory >Cc: freebsd-ports@freebsd.org >Reply-To: mexas@bris.ac.uk >In-Reply-To: <20150312122324.GL1225@albert.catwhisker.org> > >>From david@catwhisker.org Thu Mar 12 12:44:43 2015 >> >>What does output of "kldstat | grep linux" look like? >> >>Expected: >> >>g1-251(11.0-C)[1] kldstat |grep linux >> 2 3 0xc17a4000 74c90 linux.ko >>g1-251(11.0-C)[2]=20 >> >> >>But if it's not loaded, I suspect that might be a valid reason for >>the OID to fail to be recognized > ># kldstat >Id Refs Address Size Name > 1 9 0xffffffff80200000 e33630 kernel > 2 1 0xffffffff81034000 e10350 nvidia.ko > 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko ># kldload linux >kldload: can't load linux: module already loaded or in kernel ># > >I have in the kernel config file: > >options COMPAT_43 >options COMPAT_LINUX32 >options LINPROCFS >options LINSYSFS > >Perhaps I also need to add > options COMPAT_LINUX ? This gives: # make buildkernel KERNCONF=MINKY -------------------------------------------------------------- >>> Kernel build for MINKY started on Thu Mar 12 12:52:06 GMT 2015 -------------------------------------------------------------- ===> MINKY mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/MINKY -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/MINKY' /usr/src/sys/amd64/conf/MINKY: unknown option "COMPAT_LINUX" *** Error code 1 This option is mentioned in NOTES: # grep COMPAT_LINUX /usr/src/sys/amd64/conf/NOTES # To enable Linuxulator support, one must also include COMPAT_LINUX in the #XXX#options COMPAT_LINUX options COMPAT_LINUX32 # Enable the linux-like proc filesystem support (requires COMPAT_LINUX32 #Enable the linux-like sys filesystem support (requires COMPAT_LINUX32 # Or is this no longer supported? Do I need to build linux modules, rather than use kernel config options? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 13:19:40 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E058CABF for ; Thu, 12 Mar 2015 13:19:40 +0000 (UTC) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C3157F9 for ; Thu, 12 Mar 2015 13:19:39 +0000 (UTC) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKVQGSU4d02RbyX72H0HJpfmM8FMMxetH8@postini.com; Thu, 12 Mar 2015 13:19:40 UTC Received: by wiwl15 with SMTP id l15so3879886wiw.1 for ; Thu, 12 Mar 2015 06:19:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=bjb9y37QqoIIk5suYlAM5dh9iEHAdpRcDcr10meanRM=; b=M0Dv2pA8alccUV8Bq8iczoyiZFRcxBzK+qGfkM+wZcaQgJUHOlcNRoo6wPfw/OdEFQ Eubtg70E9CV2GRjfTGOAL7AV/VbFJBuLtkMhRwF+q/waPpqbJ4PCFnGrRIE8DxQxSva9 S9YBkSFQtIuHXK++xNpbnbgPTMCspgqhAGNvX+6jCml5+jhU4z2KVOI8oMdRUNbtsXvC uHa1lyN2EmOyuZe5djghj0M1XOpvrY1mOduvGJaqou7sIWKKMdUGCR8U+oxumf4221EL 7oSgvTt147Rm1bgosiqHtlpW/yC9ZkCHozYZrx3vXwrA3s4rQW03eSPlBSMigeDFT242 cmkw== X-Received: by 10.194.237.34 with SMTP id uz2mr85341177wjc.157.1426164561474; Thu, 12 Mar 2015 05:49:21 -0700 (PDT) X-Gm-Message-State: ALoCoQmaoafBdNdeMiRl1iU7EjqU7I9wVctBkX25Au79QqXCc4r797QjmT44DCR5RA4UxDQ2uKwuuyH9kOd5kjfOGEtj5qU6FS6Zs/OifjZ/jYax39CnvUPYVwFfQaxLTDtsXEseT7QItXQ40i9mki6pjod8ZDMkxA== X-Received: by 10.194.237.34 with SMTP id uz2mr85341160wjc.157.1426164561361; Thu, 12 Mar 2015 05:49:21 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id ha10sm9881295wjc.37.2015.03.12.05.49.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 05:49:19 -0700 (PDT) Date: Thu, 12 Mar 2015 05:49:19 -0700 (PDT) X-Google-Original-Date: Thu, 12 Mar 2015 12:49:17 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2CCnIQA054398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Mar 2015 12:49:18 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2CCnHkV054397; Thu, 12 Mar 2015 12:49:17 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503121249.t2CCnHkV054397@mech-as221.men.bris.ac.uk> To: david@catwhisker.org, mexas@bris.ac.uk Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk In-Reply-To: <20150312122324.GL1225@albert.catwhisker.org> Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:19:41 -0000 >From david@catwhisker.org Thu Mar 12 12:44:43 2015 > >What does output of "kldstat | grep linux" look like? > >Expected: > >g1-251(11.0-C)[1] kldstat |grep linux > 2 3 0xc17a4000 74c90 linux.ko >g1-251(11.0-C)[2]=20 > > >But if it's not loaded, I suspect that might be a valid reason for >the OID to fail to be recognized # kldstat Id Refs Address Size Name 1 9 0xffffffff80200000 e33630 kernel 2 1 0xffffffff81034000 e10350 nvidia.ko 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko # kldload linux kldload: can't load linux: module already loaded or in kernel # I have in the kernel config file: options COMPAT_43 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS Perhaps I also need to add options COMPAT_LINUX ? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 14:32:55 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9C7D237 for ; Thu, 12 Mar 2015 14:32:55 +0000 (UTC) Received: from smtp205.alice.it (smtp205.alice.it [82.57.200.101]) by mx1.freebsd.org (Postfix) with ESMTP id 67D7911E for ; Thu, 12 Mar 2015 14:32:55 +0000 (UTC) Received: from soth.ventu (79.2.52.145) by smtp205.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 547D8A4D152EDDE0 for ports@freebsd.org; Thu, 12 Mar 2015 15:26:48 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.15.1/8.14.9) with ESMTP id t2CEQkuJ098447 for ; Thu, 12 Mar 2015 15:26:47 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <5501A226.6060404@netfence.it> Date: Thu, 12 Mar 2015 15:26:46 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ports@freebsd.org Subject: Cannot compile inkscape on 9.3/i386 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:32:55 -0000 Hello. As per subject, Inkscape will compile with clang, which will end with several "Bad machine code". There is more than one report of this, but I was not able to find a solution. Strangely Freshports reports "Fix the build on 9.x and 8.x." in a recent commit, but this does not seem to work for me. Is there any chance to use a newer clang (from ports) or gcc? How should I change the Makefile? I guess this is the line: > USES= compiler:c++0x desktop-file-utils gettext gmake iconv \ But what should I put instead? Any else to try? bye & Thanks av. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 14:53:50 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BDE0A23 for ; Thu, 12 Mar 2015 14:53:50 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F133D9 for ; Thu, 12 Mar 2015 14:53:49 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2CEt0Y2013055; Thu, 12 Mar 2015 07:55:00 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: david@catwhisker.org, In-Reply-To: <201503121249.t2CCnHkV054397@mech-as221.men.bris.ac.uk> References: <201503121249.t2CCnHkV054397@mech-as221.men.bris.ac.uk> From: "Chris H" Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Date: Thu, 12 Mar 2015 07:55:01 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2eefaea5c4fc8fe5e0372429cdf0ba74@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:53:50 -0000 On Thu, 12 Mar 2015 05:49:19 -0700 (PDT) Anton Shterenlikht wrote > >From david@catwhisker.org Thu Mar 12 12:44:43 2015 > > > >What does output of "kldstat | grep linux" look like? > > > >Expected: > > > >g1-251(11.0-C)[1] kldstat |grep linux > > 2 3 0xc17a4000 74c90 linux.ko > >g1-251(11.0-C)[2]=20 > > > > > >But if it's not loaded, I suspect that might be a valid reason for > >the OID to fail to be recognized > > # kldstat > Id Refs Address Size Name > 1 9 0xffffffff80200000 e33630 kernel > 2 1 0xffffffff81034000 e10350 nvidia.ko > 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko > # kldload linux > kldload: can't load linux: module already loaded or in kernel > # > > I have in the kernel config file: > > options COMPAT_43 > options COMPAT_LINUX32 > options LINPROCFS > options LINSYSFS > > Perhaps I also need to add > options COMPAT_LINUX ? By virtue of the fact that kldstat(8) returns nvidia. You can be assured that linux has already been loaded, or rather, that linux is already available. Which suggests to me that it is already part of your kernel. dmesg(8) (/var.run/dmesg.boot) might well reveal that, for you. Perhaps even in /var/log/messages. --Chris > > Thanks > > Anton > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 15:20:58 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72EFA9D0 for ; Thu, 12 Mar 2015 15:20:58 +0000 (UTC) Received: from eu1sys200aog124.obsmtp.com (eu1sys200aog124.obsmtp.com [207.126.144.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C13DD8CC for ; Thu, 12 Mar 2015 15:20:56 +0000 (UTC) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by eu1sys200aob124.postini.com ([207.126.147.11]) with SMTP ID DSNKVQGuvGF2H2X+7SXWaSkdZ/AWpxTlKkjL@postini.com; Thu, 12 Mar 2015 15:20:57 UTC Received: by wghn12 with SMTP id n12so17133425wgh.6 for ; Thu, 12 Mar 2015 08:20:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=cl822j9kMiUo4h7BKVAjRx0DPEVqGK98a0y1vRc/4PI=; b=l9pS6ZLNqNsNoI1wBwwW9t7B+576Qj1Q/Z9M1DzALh+i5+S+70Am6JvZiE0spdj21R aiwaYjGIgNy8drjW3vsyfJQfKnRegaZMxceSWS3gTwSw3L/S8q6Mvmp23KGS+l8O6D12 8iqt2F9soobUiNPV2CVuOiKttJvYdOX/Z44J6ZEYqywBz5lLOE3KiANICCAjjz1xknnt IZU3IfIxqfXcCaBKt0Hi6WZ1bS7FtfhegK1Z7KgkIJfXgxLxl3ySjogKFc/NFZJyMhR/ +exWhrG+2F5EdjXNYyNr4XGiOt1n38KrXnpbylOePda/qihMoOi8Sdp0w9UCQnCgvwy/ 1swg== X-Gm-Message-State: ALoCoQlW5XwPf24PLoyuZHJZxlTyGPJ2mDtTfXaOzowLWxX46J0BlfwiFZVmh8T6d6dXv6N6xLEbB3LFEDiC8IMqHnpDL5cBuYMHUD9fmjhVpnMy8J7xpnByccBWfLYgA9fKxQFozq07XImCqonQNrQNRfz8DJxvAw== X-Received: by 10.180.7.134 with SMTP id j6mr17368497wia.11.1426173628579; Thu, 12 Mar 2015 08:20:28 -0700 (PDT) X-Received: by 10.180.7.134 with SMTP id j6mr17368456wia.11.1426173628298; Thu, 12 Mar 2015 08:20:28 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id hn8sm11163586wib.18.2015.03.12.08.20.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 08:20:27 -0700 (PDT) Date: Thu, 12 Mar 2015 08:20:27 -0700 (PDT) X-Google-Original-Date: Thu, 12 Mar 2015 15:20:25 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2CFKPeL055037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Mar 2015 15:20:25 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2CFKP1N055036; Thu, 12 Mar 2015 15:20:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503121520.t2CFKP1N055036@mech-as221.men.bris.ac.uk> To: bsd-lists@bsdforge.com, david@catwhisker.org, mexas@bris.ac.uk Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk In-Reply-To: <2eefaea5c4fc8fe5e0372429cdf0ba74@ultimatedns.net> Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:20:58 -0000 >From bsd-lists@bsdforge.com Thu Mar 12 15:16:15 2015 >> >From david@catwhisker.org Thu Mar 12 12:44:43 2015 >> > >> >What does output of "kldstat | grep linux" look like? >> > >> >Expected: >> > >> >g1-251(11.0-C)[1] kldstat |grep linux >> > 2 3 0xc17a4000 74c90 linux.ko >> >g1-251(11.0-C)[2]=20 >> > >> > >> >But if it's not loaded, I suspect that might be a valid reason for >> >the OID to fail to be recognized >> >> # kldstat >> Id Refs Address Size Name >> 1 9 0xffffffff80200000 e33630 kernel >> 2 1 0xffffffff81034000 e10350 nvidia.ko >> 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko >> # kldload linux >> kldload: can't load linux: module already loaded or in kernel >> # >> >> I have in the kernel config file: >> >> options COMPAT_43 >> options COMPAT_LINUX32 >> options LINPROCFS >> options LINSYSFS >> >> Perhaps I also need to add >> options COMPAT_LINUX ? >By virtue of the fact that kldstat(8) returns nvidia. You >can be assured that linux has already been loaded, or >rather, that linux is already available. Which suggests to >me that it is already part of your kernel. dmesg(8) >(/var.run/dmesg.boot) might well reveal that, for you. >Perhaps even in /var/log/messages. $ grep -i linux /var/run/dmesg.boot $ What does this tell me? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 15:24:24 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E08A1F4 for ; Thu, 12 Mar 2015 15:24:24 +0000 (UTC) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C5AF9BC for ; Thu, 12 Mar 2015 15:24:23 +0000 (UTC) Received: from mail-we0-f173.google.com ([74.125.82.173]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKVQGvpUb1Tq9WCkXe6RKuCKFue0f0pvvU@postini.com; Thu, 12 Mar 2015 15:24:23 UTC Received: by wevk48 with SMTP id k48so17118102wev.7 for ; Thu, 12 Mar 2015 08:24:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=fGZ5uzAEBvMkA8HegZs4PneFt0/aA7cbSopk5/GNN9o=; b=FwtqHcxysdGLw4PIiIah3SaoVr7FmRe8/gtCTE62Q6gcU9F25a+q0MeehD3z4dm2mC AIKi4OTSv8GffE/w8DaWlxABQiydDzCxMzGRTFiBqxMSYI/wWHhbQ/LgXlDgY8AuuJDA PJs6FuwPccB1xFWU+GzdydZcZ3tC4CEWCu5DECwd+H3jXIs44l6TT+A8SrhDW6iMlgIj OIz+WJNioR6GH5yR206ty89/KmLrTJw2wHn6f+wrLqabiJoRHw9zraR31XzRTGgqNYyQ u31MOALro2Jmtv6ZU4BIvOWuV4xN+YXLaovtU2qHRPAPeQn0bvhmDS5Th3ZOODZDcJWu JJOQ== X-Gm-Message-State: ALoCoQnXwk5yQH/rGoIloxVuaM46JSazCZXPlLLrtJODmkYYyGEn1XgPgZPPJaDXfCVKGcdzP86aip/8dhWUdfvt7NP+CXM6fDJytumiWJdnHQalg9+KOmeFKaSZXnuTIzTDlSoRZV7l3dIAhsb7Rz9xrQgnY7JwZw== X-Received: by 10.194.122.98 with SMTP id lr2mr90470072wjb.115.1426173861046; Thu, 12 Mar 2015 08:24:21 -0700 (PDT) X-Received: by 10.194.122.98 with SMTP id lr2mr90470058wjb.115.1426173860939; Thu, 12 Mar 2015 08:24:20 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id s19sm13604445wik.18.2015.03.12.08.24.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 08:24:20 -0700 (PDT) Date: Thu, 12 Mar 2015 08:24:20 -0700 (PDT) X-Google-Original-Date: Thu, 12 Mar 2015 15:24:19 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2CFOJar055073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Mar 2015 15:24:19 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2CFOJ46055072 for freebsd-ports@freebsd.org; Thu, 12 Mar 2015 15:24:19 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503121524.t2CFOJ46055072@mech-as221.men.bris.ac.uk> To: freebsd-ports@freebsd.org Subject: PORTS_MODULES=x11/nvidia-driver-340 results in [all] Stopped -- signal 22 Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:24:24 -0000 # cat /etc/src.conf PORTS_MODULES=x11/nvidia-driver-340 net/bwn-firmware-kmod # on buildkernel I get: ===> Ports module x11/nvidia-driver-340 (all) cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver-340; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SRC_BASE=/usr/src OSVERSION=1001507 WRKDIRPREFIX=/usr/obj/usr/src/sys/MINKY make -B clean all ===> Cleaning for nvidia-driver-340-340.76 *** [all] Stopped -- signal 22 I think this used to work with x11/nvidia-driver. $ pkg info -xo nvidia-driver nvidia-driver-340-340.76 x11/nvidia-driver-340 Is there anybody else with x11/nvidia-driver-340 using PORTS_MODULES=x11/nvidia-driver-340 in /etc/src.conf? Or am I missing something simple? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 15:25:58 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B1864E5 for ; Thu, 12 Mar 2015 15:25:58 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA1AF9DB for ; Thu, 12 Mar 2015 15:25:57 +0000 (UTC) Received: by pabrd3 with SMTP id rd3so21372480pab.5 for ; Thu, 12 Mar 2015 08:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dukHuZIdqOOc8EiYWvv2Rx42LYUyJmT7SZZdPj9abxY=; b=pNhmZq7cg1Iu8H7cxFdDmU6d8e97YyqhkIPVw37QZxvXqa3xV7Qr0mGHl8uS2YRIMw zFUSAhDYTsfJQ8mmWuTq49b86sGcJc7JXzeg2wrpGdT7asmGKwrzGUoYTAL5umg8wjKg W98wIZ+Q+gT46/iT43EdSzC88TjCCykQiZM6tCXJxciIPMCYvv1OdqZgaKYZo9ZQh1Ng 8TjqTUnrsIJXO8rtnYQFvT5WWvObo2zNZXe0wTU/xSc5SYW+h4tazUhCufYo2ouU9mfG rmeVDkxbyS0T5GmecT/kkejaJKlJf45QRE/B0oDo249nte1NCNDo/WkbaYuX5DQPLYcl d0Gw== MIME-Version: 1.0 X-Received: by 10.66.164.163 with SMTP id yr3mr59221142pab.154.1426173957317; Thu, 12 Mar 2015 08:25:57 -0700 (PDT) Received: by 10.70.79.166 with HTTP; Thu, 12 Mar 2015 08:25:57 -0700 (PDT) In-Reply-To: <201503121520.t2CFKP1N055036@mech-as221.men.bris.ac.uk> References: <2eefaea5c4fc8fe5e0372429cdf0ba74@ultimatedns.net> <201503121520.t2CFKP1N055036@mech-as221.men.bris.ac.uk> Date: Thu, 12 Mar 2015 10:25:57 -0500 Message-ID: Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory From: Adam Vande More To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports , Chris H , David Wolfskill X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:25:58 -0000 On Thu, Mar 12, 2015 at 10:20 AM, Anton Shterenlikht wrote: > >By virtue of the fact that kldstat(8) returns nvidia. You > >can be assured that linux has already been loaded, or > >rather, that linux is already available. Which suggests to > >me that it is already part of your kernel. dmesg(8) > >(/var.run/dmesg.boot) might well reveal that, for you. > >Perhaps even in /var/log/messages. > > $ grep -i linux /var/run/dmesg.boot > $ > > What does this tell me? > That the string linux doesn't appear in /var/run/dmesg.boot I don't understand the fixation on this module. It's clearly loaded. Your problem lies elsewhere. -- Adam From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 17:31:39 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B758A77 for ; Thu, 12 Mar 2015 17:31:39 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EC13D40 for ; Thu, 12 Mar 2015 17:31:39 +0000 (UTC) Received: by iecsl2 with SMTP id sl2so50675804iec.1 for ; Thu, 12 Mar 2015 10:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pHGFF8Pcq9rUBon/L1gH4ma0s45ebJyrQV9S4L6cxK8=; b=gnh9m8SC3mL+vZDiuCFzIB1WAUa1cU5lEdokKZOGOK1Xl4QViTkN0ir9y0ZhdLL3Xn 5Gik1xb8Rs7jB5n0uQoDdZU1bLMpxyzGGqVnKV7PtqXsl70u5J1FMj/hWLdh8qbt5f3E QsjtoZmfnFsvQBoFLBOz1etWcCxIIKzi7kEv7VKY9uuLRXi1JqKEPBqduY/fxBzjryWL LrxQjGiAPwfmVLQ06UrCP3SoBDekC5jSyIfDmBOrsp0Dx/RxvngEWZa8Zj7BFA3s3Cw+ 7g5pV+WNdLPIgkBUD02Yd6R3wcXAPh6pS58R0RjJ/uRXsQ6XAGacL/VzlPoLjn5ZtIKv xRIw== MIME-Version: 1.0 X-Received: by 10.43.157.67 with SMTP id lp3mr40294770icc.23.1426181482434; Thu, 12 Mar 2015 10:31:22 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Thu, 12 Mar 2015 10:31:22 -0700 (PDT) In-Reply-To: <201503121152.t2CBq8ku054188@mech-as221.men.bris.ac.uk> References: <201503121152.t2CBq8ku054188@mech-as221.men.bris.ac.uk> Date: Thu, 12 Mar 2015 10:31:22 -0700 X-Google-Sender-Auth: XpbjtrqjL5K4vOnvFy63082h2Fc Message-ID: Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory From: Kevin Oberman To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:31:39 -0000 On Thu, Mar 12, 2015 at 4:52 AM, Anton Shterenlikht wrote: > I'm still trying to figure out why flash > wouldn't work on this particular laptop. > > I see this error/warning: > > $ sysctl -a | grep "compat.linux.os" > <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No > such file or directory > compat.linux.osname: Linux > compat.linux.osrelease: 2.6.18 > compat.linux.oss_version: 198144 > > I don't understand what it means. > Boy, has this one run WAY off the rails. After the first response, the relevant part of the report was elided from the thread and I think everyone has missed it. It looks to me like it has nothing to do with whether the module is loaded (it is) and everything to do with how people see what they expect and not what is really there. The error message is telling you that the OID "sysctl compat.linux.osrelease" is unknown, as it should as OIDs may not contain spaces. The real question is why "sysctl -a" is trying to execute "sysctl 'sysctl compat.linux.osrelease'" or some shell specific equivalent. Is "sysctl" aliased to a script or something like it? What do you get for the output of "sysctl -a > somefile"? -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 17:40:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04E45EEC for ; Thu, 12 Mar 2015 17:40:54 +0000 (UTC) Received: from smtp206.alice.it (smtp206.alice.it [82.57.200.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8F10DDD7 for ; Thu, 12 Mar 2015 17:40:53 +0000 (UTC) Received: from soth.ventu (79.2.52.145) by smtp206.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 547D8AFA1263F9FD for freebsd-ports@freebsd.org; Thu, 12 Mar 2015 18:35:10 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.15.1/8.14.9) with ESMTP id t2CHZ9vS002571 for ; Thu, 12 Mar 2015 18:35:09 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <5501CE4C.9030805@netfence.it> Date: Thu, 12 Mar 2015 18:35:08 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Suggestion on network backup Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:40:54 -0000 Hello. I'm looking for a centralized backup solution with the following requirements: _ server (FreeBSD) side storage and/or NAS storage; _ Windows and Mac client support; _ "push model" (meaning a client will initiate a backup when it is powered up/connected); _ ability to run script on the client (i.e. dump a database before starting the backup); _ good reporting (ideally I'd like to be notified of overall status and possibly when a client hasn't done a backup for a long time). I currently use Bacula, which I like a lot, but I don't really feel it's the right tool in this situation; while it has several nice features which are not useful here: _ it tends to hard to setup and manage when the number of clients grows; _ the director manages the schedule and AFAICT only works well for "server clients", which are up and connected 24/7. So I saw BackupPC and BoxBackup are in the port tree... Anyone is using them and can reccomend any? Or has anyone tried them and can suggest to stay away? So far, from what I read I'm worried about the following aspects of BackupPC: _ for Windows client it either works via SMB (which I fear might miss something); _ or via rsync (needing Cygwin installed); _ locked files cannot be backup up!!!; _ claims support for Windows clients up to XP!!!. And with BoxBackup: _ encryption is mandatory; _ locked files cannot be backup up!!!; _ claims support for Windows clients up to XP!!!. Any other player in the arena? bye & Thanks av. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 17:55:28 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B057246 for ; Thu, 12 Mar 2015 17:55:28 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E6F0FAA for ; Thu, 12 Mar 2015 17:55:27 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2CHuWVM037689; Thu, 12 Mar 2015 10:56:33 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: david@catwhisker.org, In-Reply-To: <201503121520.t2CFKP1N055036@mech-as221.men.bris.ac.uk> References: <201503121520.t2CFKP1N055036@mech-as221.men.bris.ac.uk> From: "Chris H" Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Date: Thu, 12 Mar 2015 10:56:34 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <0bde57fff39bbb2bdc6509edbe7724b4@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:55:28 -0000 On Thu, 12 Mar 2015 08:20:27 -0700 (PDT) Anton Shterenlikht wrote > >From bsd-lists@bsdforge.com Thu Mar 12 15:16:15 2015 > >> >From david@catwhisker.org Thu Mar 12 12:44:43 2015 > >> > > >> >What does output of "kldstat | grep linux" look like? > >> > > >> >Expected: > >> > > >> >g1-251(11.0-C)[1] kldstat |grep linux > >> > 2 3 0xc17a4000 74c90 linux.ko > >> >g1-251(11.0-C)[2]=20 > >> > > >> > > >> >But if it's not loaded, I suspect that might be a valid reason for > >> >the OID to fail to be recognized > >> > >> # kldstat > >> Id Refs Address Size Name > >> 1 9 0xffffffff80200000 e33630 kernel > >> 2 1 0xffffffff81034000 e10350 nvidia.ko > >> 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko > >> # kldload linux > >> kldload: can't load linux: module already loaded or in kernel > >> # > >> > >> I have in the kernel config file: > >> > >> options COMPAT_43 > >> options COMPAT_LINUX32 > >> options LINPROCFS > >> options LINSYSFS > >> > >> Perhaps I also need to add > >> options COMPAT_LINUX ? > >By virtue of the fact that kldstat(8) returns nvidia. You > >can be assured that linux has already been loaded, or > >rather, that linux is already available. Which suggests to > >me that it is already part of your kernel. dmesg(8) > >(/var.run/dmesg.boot) might well reveal that, for you. > >Perhaps even in /var/log/messages. > > $ grep -i linux /var/run/dmesg.boot > $ > > What does this tell me? [in your case] apparently, nothing. I have chosen not to include linux in my kernels, for convenience reasons. Should I need to update linux, or something goes wrong using the linux ABI. I can simply unload it, and deal with it accordingly. FWIW I know from experience that the nvidia blob will refuse to load, if the linux ABI is not present/available. So it's safe to assume, that in your case , the linux ABI 1) is available 2) must have come from within your kernel I'm sure it's possible to query various aspects of linux available. maybe by/through /proc or /compat/linux/proc and surely by other means. But I have made no effort to do so in the past. So I couldn't be of much help, there. All the best. > > Thanks > > Anton --Chris -- From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 20:28:54 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F2544A6; Thu, 12 Mar 2015 20:28:54 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 67CF56D6; Thu, 12 Mar 2015 20:28:53 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 12C802C13F; Thu, 12 Mar 2015 16:28:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4ydlL8LU2DF; Thu, 12 Mar 2015 16:28:46 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <5501F6FD.9060401@egr.msu.edu> Date: Thu, 12 Mar 2015 16:28:45 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Matthew Seaman Subject: Re: svn commit: r381041 - head/textproc/p5-HTML-FormatExternal References: <201503112151.t2BLpoqR050465@svn.freebsd.org> In-Reply-To: <201503112151.t2BLpoqR050465@svn.freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 20:28:54 -0000 On 03/11/2015 17:51, Matthew Seaman wrote: > Author: matthew > Date: Wed Mar 11 21:51:49 2015 > New Revision: 381041 > URL: https://svnweb.freebsd.org/changeset/ports/381041 > QAT: https://qat.redports.org/buildarchive/r381041/ > > Log: > Drop the dependency on p5-Encode. This is bundled with perl, and > p5-HTML-FormatExternal doesn't need any more recent verson itself. > > Submitted by: az > > Modified: > head/textproc/p5-HTML-FormatExternal/Makefile > > Modified: head/textproc/p5-HTML-FormatExternal/Makefile > ============================================================================== > --- head/textproc/p5-HTML-FormatExternal/Makefile Wed Mar 11 21:25:34 2015 (r381040) > +++ head/textproc/p5-HTML-FormatExternal/Makefile Wed Mar 11 21:51:49 2015 (r381041) > @@ -2,6 +2,7 @@ > > PORTNAME= HTML-FormatExternal > PORTVERSION= 22 > +PORTREVISION= 1 > CATEGORIES= textproc perl5 > MASTER_SITES= CPAN > PKGNAMEPREFIX= p5- > @@ -14,8 +15,7 @@ LICENSE= GPLv3 > OPTIONS_DEFINE= ELINKS HTML2TEXT LINKS LYNX LYNX_CURRENT NETRIK W3M > OPTIONS_DEFAULT= LYNX > > -BUILD_DEPENDS= p5-Encode>=0:${PORTSDIR}/converters/p5-Encode \ > - p5-URI>=0.08:${PORTSDIR}/net/p5-URI > +BUILD_DEPENDS= p5-URI>=0.08:${PORTSDIR}/net/p5-URI > RUN_DEPENDS:= ${BUILD_DEPENDS} > > USES= perl5 It appears p5-HTML-FormatExternal depends on devel/p5-IPC-Run? Does this seem like an appropriate RUN_DEPENDS to add? Thanks. # perl -e 'use HTML::FormatExternal;' Can't locate IPC/Run.pm in @INC (you may need to install the IPC::Run module) (@INC contains: /usr/local/lib/perl5/site_perl/mach/5.18 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.18/mach /usr/local/lib/perl5/5.18 /usr/local/lib/perl5/site_perl/5.18 /usr/local/lib/perl5/site_perl/5.18/mach .) at /usr/local/lib/perl5/site_perl/HTML/FormatExternal.pm line 33. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/HTML/FormatExternal.pm line 33. Compilation failed in require at -e line 1. # pkg install p5-IPC-Run Updating pkg-egr repository catalogue... pkg-egr repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 2 packages will be affected (of 0 checked): New packages to be INSTALLED: p5-IPC-Run: 0.94 p5-IO-Tty: 1.12_1 The process will require 365 KiB more space. Proceed with this action? [y/N]: y [1/2] Installing p5-IO-Tty-1.12_1... [1/2] Extracting p5-IO-Tty-1.12_1: 100% [2/2] Installing p5-IPC-Run-0.94... [2/2] Extracting p5-IPC-Run-0.94: 100% # perl -e 'use HTML::FormatExternal;' # From owner-freebsd-ports@FreeBSD.ORG Thu Mar 12 21:10:35 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80869C57 for ; Thu, 12 Mar 2015 21:10:35 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E492CC0D for ; Thu, 12 Mar 2015 21:10:34 +0000 (UTC) Received: from seedling.local (wifi.infracaninophile.co.uk [81.2.117.98]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t2CLANTT042746 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Mar 2015 21:10:24 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t2CLANTT042746 Authentication-Results: smtp.infracaninophile.co.uk/t2CLANTT042746; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host wifi.infracaninophile.co.uk [81.2.117.98] claimed to be seedling.local Message-ID: <550200B3.1080506@FreeBSD.org> Date: Thu, 12 Mar 2015 21:10:11 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adam McDougall Subject: Re: svn commit: r381041 - head/textproc/p5-HTML-FormatExternal References: <201503112151.t2BLpoqR050465@svn.freebsd.org> <5501F6FD.9060401@egr.msu.edu> In-Reply-To: <5501F6FD.9060401@egr.msu.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lUhkGXwPSlwNWhtKaGJtpTm24ww3LNHhI" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:10:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lUhkGXwPSlwNWhtKaGJtpTm24ww3LNHhI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/03/2015 20:28, Adam McDougall wrote: > It appears p5-HTML-FormatExternal depends on devel/p5-IPC-Run? Does > this seem like an appropriate RUN_DEPENDS to add? Thanks. You are correct. I'll commit an update very shortly. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --lUhkGXwPSlwNWhtKaGJtpTm24ww3LNHhI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iQJ8BAEBCgBmBQJVAgC8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATMEIQAJ8fVuVwbSR0QIKZ51iOAngg sSwxMUogJcK8bXcnIvJdnUOYsWTxWkF2ryJWP78XIglUAq6V3yhFfn6vW32wxBkg Y5vFD0SNMs1KXsdtCBbDX4S8COxkYR5RYOIOPXueIIdULjq8t2BI7EbpQasfSJ6U O8cbmniicqI8Mc3Qi6h6JKrHljnjzrWK1fJpYmjOef78LNkyTWl+3UlyPPSqQRmP mzZedgzZpQBf7/Zjj07j+9GEV9WHPcjb2X0tbnt/4C4Zj8Iqr7WbIhtMb5wngDXm 8bi2ir3C8b9Mc3j9IKBRlwaMO7rwOVAMJbJLONJ5nGS+iy3u0TSfoaEyTs8MJ2Z8 vsv/UXBP4dUwvsVUenhM+LP1SgKDAwrZPCp4TmkRbgQx1mXX4U5PSfZh6gW1tSV3 CkwFXhSS+aSpG1NwlQUoQIio9EiwsbbqYsOux0bu0b1yBxItLDqQP47hJakmN0wC F6+61XCcVbaT8U7Y1RyciWmkaJ6OQjgtBLXhOXjUpQHE0FyWBIFNzTxLS7Ae9qF7 sANbdqcwLqB2E0TFD6K0GLPJXNsB9/YgGfuT5Bmf+W8PYrwFA8v1ItKIxQQC91+4 aR+yKddCBKFGZw6wbh/9r2AOrROtetWah0ko6TS/n56yP+1ya9brUi21jvCcxUwJ 32W17DtREq0cpEtZXubH =mkXA -----END PGP SIGNATURE----- --lUhkGXwPSlwNWhtKaGJtpTm24ww3LNHhI-- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 09:27:05 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD4B2D47 for ; Fri, 13 Mar 2015 09:27:05 +0000 (UTC) Received: from smtp1g36.consultorpc.com (smtp1g36.consultorpc.com [93.159.214.136]) by mx1.freebsd.org (Postfix) with ESMTP id 88FDA9F7 for ; Fri, 13 Mar 2015 09:27:05 +0000 (UTC) Received: by smtp1g31.consultorpc.com id h0ammi16r3g6 for ; Fri, 13 Mar 2015 10:26:33 +0100 (envelope-from ) To: From: "web@axvisualpromocom.com" Reply-To: "web@axvisualpromocom.com" Date: Fri, 13 Mar 2015 10:26:16 +0100 Message-ID: <5502ad386aa6d@axalphaconsulting1_ip-zone_com-6> X-CcmId: 0419545b435151505f0812475a46080b05576a08421c4c0e5d566652595b585754540401020207 Feedback-ID: 39235:39235-7:1:Mailrelay X-Report-Abuse: Please report abuse for this campaign here http://axalphaconsulting1.mailrelay-ii.com/ccm/abuse?a=39235&m=7&s=753197 X-OriginalSender: web@axvisualpromocom.com Subject: Gestiona tu tienda online desde tu ERP MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 09:27:05 -0000 Gestiona tu tienda on-line desde tu ERP Las tiendas on-line es=C3=A1n de moda. Con una m=C3=ADnima inversi=C3=B3n e= con=C3=B3mica puedes tener una potente tienda virtual y vender productos en= todo el mundo. Pero lo que nadie dice es la inversi=C3=B3n de tiempo que n= ecesitas para introducir todos los productos, categor=C3=ADas, precios, ges= ti=C3=B3n de pedidos, facturas, im=C3=A1genes... Si tienes un ERP te ahorras mucho tiempo. Conecta tu programa de gesti= =C3=B3n con la tienda on-line y todos los datos se actualizar=C3=A1n autom= =C3=A1ticamente. S=C3=B3lo tendr=C3=A1s que enviar los productos y hacer la factura!=20 Consulta nuestras propuestas de tienda online y conector ERP AXvisual Promocom Av. Garrigues 44 pl.1. 08820 El Prat de Llobregat (Barcelona). Tel. 93 372 = 90 60. web@axvisualpromocom.com From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 09:42:13 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 952981E7 for ; Fri, 13 Mar 2015 09:42:13 +0000 (UTC) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4543BFE for ; Fri, 13 Mar 2015 09:42:12 +0000 (UTC) Received: from mail-we0-f181.google.com ([74.125.82.181]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKVQKw8sIiUnS/+C5u3PU8JVZ8fiBlnO3P@postini.com; Fri, 13 Mar 2015 09:42:13 UTC Received: by wevl61 with SMTP id l61so22029566wev.6 for ; Fri, 13 Mar 2015 02:42:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=m7mV/vXdmI+0g3oF17lO7jGdXQTgCFNXuedwykLLWQU=; b=mYwXwxlwct5CCN3gR+4UtFjCRaPqALCzXPX+SLFtdPVfdCGxJ7wA0V/faAlN1tToxc Zv9jHMvBZ7+LYg02LM4ER6XzuEPdD2E+lU1QecPOwbwZFYPNic4lWwlMT3ZXg4gxya4+ d8d9HU1W41il7Q+VMckQ4rxeUQc+XigHin6/6F5ZBTqUh7wVc7FRMEKxEdk8K2Adqxr/ zziE/imU3BqMbmIFdqRydZXmBSNpcpBq96gesRF0OG9fl9TIenG4R9ZTTGokFyPZUcIb YSw0r/dlUjXAUBx7unAu6CslmlAja/r/4jG3KpEvQb/MMOJc+SsZqnY3UraDgO19uqR+ p/+g== X-Received: by 10.180.39.139 with SMTP id p11mr44415328wik.61.1426239307324; Fri, 13 Mar 2015 02:35:07 -0700 (PDT) X-Gm-Message-State: ALoCoQkbQyTal4HLkNpXcmPDzRS4j7L4MP2+sTg/ty6qSBYj92muPlHx0OtVhNrd48zAs2SYZaat2d6XvRH/nNmmIaE1/Bps4fAkY1YP9ON5h57Fj08nnTdHXk9QT4aPtyorlCe7chTXMHYqdn/TGa8OfXznaYhq8A== X-Received: by 10.180.39.139 with SMTP id p11mr44415309wik.61.1426239307186; Fri, 13 Mar 2015 02:35:07 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id gt4sm1976621wib.21.2015.03.13.02.35.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 02:35:06 -0700 (PDT) Date: Fri, 13 Mar 2015 02:35:06 -0700 (PDT) X-Google-Original-Date: Fri, 13 Mar 2015 09:35:04 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2D9Z4FI059250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Mar 2015 09:35:05 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2D9Z46A059249; Fri, 13 Mar 2015 09:35:04 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503130935.t2D9Z46A059249@mech-as221.men.bris.ac.uk> To: mexas@bris.ac.uk, rkoberman@gmail.com Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk In-Reply-To: Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 09:42:13 -0000 >From kob6558@gmail.com Thu Mar 12 19:19:32 2015 > >spaces. The real question is why "sysctl -a" is trying to execute "sysctl >'sysctl compat.linux.osrelease'" or some shell specific equivalent. Is >"sysctl" aliased to a script or something like it? >What do you get for the output of "sysctl -a > somefile"? http://eis.bris.ac.uk/~mexas/sysctl-a This was a good suggestion. I think I get it now. It seems I mistakenly set "sysctl compat.linux.osrelease=2.6.18" at some point in /etc/sysctl.conf. I later corrected this to "compat.linux.osrelease=2.6.18" The correct option is now in use. However, because sysctl -a reports information from several previous boots, I still get the error message from when /etc/sysctl.conf was incorrect. Does this sould right? Thank you Anton From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 09:51:30 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C60286C1 for ; Fri, 13 Mar 2015 09:51:30 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1B86D64 for ; Fri, 13 Mar 2015 09:51:30 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2D9pUZo050850 for ; Fri, 13 Mar 2015 09:51:30 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2D9pUbV050849; Fri, 13 Mar 2015 09:51:30 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503130951.t2D9pUbV050849@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Fri, 13 Mar 2015 09:51:30 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 09:51:30 -0000 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/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ www/serendipity | 1.7.8 | 2.0.1 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 10:14:17 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48150AE2 for ; Fri, 13 Mar 2015 10:14:17 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB65F9E for ; Fri, 13 Mar 2015 10:14:16 +0000 (UTC) Received: by wesw62 with SMTP id w62so22194998wes.8 for ; Fri, 13 Mar 2015 03:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=IXEecUkdehCmew99mjm+E+RZICl+OmtnkPBD4cVz7ME=; b=YGtPhtuK4tz8MolfjdRj6d8VPrA+CI5hyOaQsPuW4pQ7xpasQ8HcSTDtKlc2FhH3lm MEvmcY2OnCSmhpLcBBz1V9wI7ew4qrtqPSDRiETCOhrvY9uXqSJ1km2Jnl6o5y7rn7BM CX9kcpgq4J819N0PreY4Ur9OQJe/6tJ+J+CIlZVLuq+eyIXLsxwywN6RM4q7F/vUx84a TbL2nJB0sQgOOqL7MTTqq40ktwrXeqOAia3I0rd1rH2aCG4hjIK2hDS+710JpGyNb0W8 xQLJbTvg0zWPNT9fAi5TARinQkUSBPSAFuJrn6jSx0zkp5s76UbPV0I6MyUurFltO6oH 6A+w== X-Received: by 10.194.57.170 with SMTP id j10mr22156653wjq.102.1426241655328; Fri, 13 Mar 2015 03:14:15 -0700 (PDT) Received: from ernst.home (p578E3C94.dip0.t-ipconnect.de. [87.142.60.148]) by mx.google.com with ESMTPSA id y14sm2131577wjr.39.2015.03.13.03.14.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 03:14:14 -0700 (PDT) Date: Fri, 13 Mar 2015 11:14:12 +0100 From: Gary Jennejohn To: "Chris H" Subject: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Message-ID: <20150313111412.20d5aad3@ernst.home> In-Reply-To: <2eefaea5c4fc8fe5e0372429cdf0ba74@ultimatedns.net> References: <201503121249.t2CCnHkV054397@mech-as221.men.bris.ac.uk> <2eefaea5c4fc8fe5e0372429cdf0ba74@ultimatedns.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mexas@bris.ac.uk, freebsd-ports@freebsd.org, david@catwhisker.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:14:17 -0000 On Thu, 12 Mar 2015 07:55:01 -0700 "Chris H" wrote: > On Thu, 12 Mar 2015 05:49:19 -0700 (PDT) Anton Shterenlikht > wrote > > > >From david@catwhisker.org Thu Mar 12 12:44:43 2015 > > > > > >What does output of "kldstat | grep linux" look like? > > > > > >Expected: > > > > > >g1-251(11.0-C)[1] kldstat |grep linux > > > 2 3 0xc17a4000 74c90 linux.ko > > >g1-251(11.0-C)[2]=20 > > > > > > > > >But if it's not loaded, I suspect that might be a valid reason for > > >the OID to fail to be recognized > > > > # kldstat > > Id Refs Address Size Name > > 1 9 0xffffffff80200000 e33630 kernel > > 2 1 0xffffffff81034000 e10350 nvidia.ko > > 3 1 0xffffffff81e45000 2ba58 bwn_v4_ucode.ko > > # kldload linux > > kldload: can't load linux: module already loaded or in kernel > > # > > > > I have in the kernel config file: > > > > options COMPAT_43 > > options COMPAT_LINUX32 > > options LINPROCFS > > options LINSYSFS > > > > Perhaps I also need to add > > options COMPAT_LINUX ? > By virtue of the fact that kldstat(8) returns nvidia. You > Not necessarily true. My nvidia module was compiled without Linux support. -- Gary Jennejohn From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 10:59:05 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 135DA573 for ; Fri, 13 Mar 2015 10:59:05 +0000 (UTC) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65AC1686 for ; Fri, 13 Mar 2015 10:59:03 +0000 (UTC) Received: from mail-wi0-f178.google.com ([209.85.212.178]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKVQLC74Y644xmKVvdJ5ARu48bRcwRgmO7@postini.com; Fri, 13 Mar 2015 10:59:04 UTC Received: by wibbs8 with SMTP id bs8so5161176wib.0 for ; Fri, 13 Mar 2015 03:58:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=pAMKE5FCdmcP8Ga9ihEDnHD+SliFcTmVyEakgno5Nh0=; b=Wk05DyGSv2G3th0uSy5Tq9E9vG2l1cWpM/m86dWfrcSdIRrPCtrInYeSUZhZHvZGij w4Ck83eNOq/vLVey8sZDwYbaS+mXbUZ6wrTv7Ht8WuekkFRC+wwYR3cORusb1KH1JYpT zSvWsOMisf2TTCovKBEGX1G2doALaOvrmmzXD/C9EjA0c1R8X35J5h1aAy6DSWUZxUtl i72EUzOU6fGXPGHM8XO1Nsqa+tHIqTp9m4hPFmlcEoCbFsrfllGmg73QhBrS+0wGRdX1 asavVisYXTTxMNt1oYHO/imhpKzSAmugsnzjPmKEwivUENqje5W6KiBLhV0Swt5P1fVc 02tA== X-Received: by 10.180.35.97 with SMTP id g1mr20432547wij.17.1426243948246; Fri, 13 Mar 2015 03:52:28 -0700 (PDT) X-Gm-Message-State: ALoCoQkpuvlayJH+dxbbL+73uwAYj9SeYrR8kvO7/Nzw3V1tvettCNmuz3jAwYSI6svSaaexOjOe1qOZCMdXbrHMmn7IRODjBShJMqg4qm30hXlCZe1c8C0p2S3UuTbgIyDLzsXG70Ye0TMsBUpqauGh2A759/KPrQ== X-Received: by 10.180.35.97 with SMTP id g1mr20432526wij.17.1426243948141; Fri, 13 Mar 2015 03:52:28 -0700 (PDT) Received: from mech-as221.men.bris.ac.uk (misc-users-pat-19-131.isys.bris.ac.uk. [137.222.19.131]) by mx.google.com with ESMTPSA id bx3sm2282356wjc.21.2015.03.13.03.52.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 03:52:27 -0700 (PDT) Date: Fri, 13 Mar 2015 03:52:27 -0700 (PDT) X-Google-Original-Date: Fri, 13 Mar 2015 10:52:25 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t2DAqPsE059618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Mar 2015 10:52:26 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t2DAqP0v059617; Fri, 13 Mar 2015 10:52:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201503131052.t2DAqP0v059617@mech-as221.men.bris.ac.uk> To: mexas@bris.ac.uk, ohauer@gmx.de Subject: SOLVED: WAS: Re: <118>sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory Reply-To: mexas@bris.ac.uk In-Reply-To: <5502B3A6.7040405@gmx.de> Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:59:05 -0000 >From ohauer@gmx.de Fri Mar 13 10:49:53 2015 > >There is a way to clean old dmesg messages (param -c) > >show dmesg once and clean the message buffer. ># dmesg -c > >A second call with dmesg will display nothing until something new is logged to the buffer (reboot, eventlog ...) Thank you $ sysctl -a | grep "compat.linux.osre" compat.linux.osrelease: 2.6.18 $ NOw I need to get back to my original problem - why firefox flash does not work... Anton From owner-freebsd-ports@FreeBSD.ORG Fri Mar 13 15:21:21 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71008BCB for ; Fri, 13 Mar 2015 15:21:21 +0000 (UTC) Received: from nm23-vm7.bullet.mail.gq1.yahoo.com (nm23-vm7.bullet.mail.gq1.yahoo.com [98.136.217.86]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 399DE876 for ; Fri, 13 Mar 2015 15:21:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1426259727; bh=ibox50T1a1Pd8x8SD19lra9/1mZPb99i2zCnEetkuzE=; h=Date:From:Reply-To:To:Subject:From:Subject; b=Vo7+oCWeX9qTHeSYAffFXG7I34PVKF7cd6TRT9lDCij2pFfB7DvRfg7kC2KhiLoQWPHItMZEP/MP4bDNdwaFnrFZ07eU90aUELRDZEsTOT30KdJrKa0GB9xK3pezStACiqWEu44Z0f2sFp3gKbMIKK/TvAGbcVO3svbj9l1h88KWv87oyRBx8DLY8u/tqzrjvqz4QlqS5v3P/UfDrwdviuiPR+ECw2ikjxIwyDgrRh0jnCwYb1DNVddNYxFTMNlUM60shMnV6looOgmJnV8AypIXf7nISn8djL1VTlAcohaTR4DcOR4H7udkwZcFKCx2rOVAGXoqvyGzrHCDQ2qj/g== Received: from [216.39.60.181] by nm23.bullet.mail.gq1.yahoo.com with NNFMP; 13 Mar 2015 15:15:27 -0000 Received: from [98.138.226.169] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 13 Mar 2015 15:15:26 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 13 Mar 2015 15:15:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 298829.99559.bm@omp1070.mail.ne1.yahoo.com X-YMail-OSG: jPjX_RYVM1noXL5qPSOzYE2JCCCOO357V5cTs40SStqsjr6Zjn5XV8rf6BoU3vS vEsRpQJAo6lcGALjtTQb0FZb4tzqWu_BZlAStNKyshRowB9MkwpbpV6kUpyJQVjhaWhhuVMVtRIH VtvVWKMT6LdckCMt_OA0I_An.rOYWeYuOWJpAaHnoVX.9XAI0.ukpVvhpvQjIIAI8N3fZUgw.x5n P8hm6zBt8e_AmAR_OHL6Z1II9K3Jr..S2bsLjEzcEhBO5OjXIBjf5v_tCv6txbz.9zVUynnMf2JO khONMLERYU2VOpRCpJlMSr89LgvwsYx.EyW2azx1cpb3rzw8x3V8y4Epz37fO2yiwm8_9mZncUgX VSndhwzRTLCO1X2h67IEI9YKpJCWTi5c6SHfm72IZMJRpqsvFbr8hxdavN.jGqscUKUElvHcjijs CgXhT5oTyShlyYQF1bEswIlmd0qqTopyrRwpeXuCvtA1xvVnh6DmQpgdhV_cxzOR7zU.0k0Pjp3E qsKEHywsM8PBkB5BEmfI- Received: by 98.138.105.213; Fri, 13 Mar 2015 15:15:25 +0000 Date: Fri, 13 Mar 2015 15:15:24 +0000 (UTC) From: =?UTF-8?Q?Yves_Gu=C3=A9rin?= Reply-To: =?UTF-8?Q?Yves_Gu=C3=A9rin?= To: "kwm@FreeBSD.org" , "mva@FreeBSD.org" , "ports@FreeBSD.org" Message-ID: <1734422266.4037954.1426259725295.JavaMail.yahoo@mail.yahoo.com> Subject: Circular dependencies with ImageMagick port MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4037953_1233289034.1426259725295" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:21:21 -0000 ------=_Part_4037953_1233289034.1426259725295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear, I try to compile the graphic/ImageMagick port and I face an circular depend= encies between sdl and zziplib ImageMagick-6.9.0.10,1sdl-1.2.15_5,2 zziplib-0.13.62_2 I run:=C2=A0FreeBSD daemonBSD 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: T= ue Feb 24 18:57:59 UTC 2015 =C2=A0 =C2=A0 root@amd64-builder.daemonology.ne= t:/usr/obj/usr/src/sys/GENERIC =C2=A0i386 >From the log look for the following keywords "***" and "CIRCULAR DEPENDENCI= E" So the path is: ImageMagick --...---> graphviz --> devil --> sdl* --> plusa= udio --> dbus --> xmlto --> dblatex --> texlive --> weave --> zziplib --> s= dl* (go back to sql port) The port tree was installed the 9th March 2015 Thank you in advance for your help=C2=A0 Yves Guerin ------=_Part_4037953_1233289034.1426259725295 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=imagemagick.log Content-ID: <9c428d3d-9aae-054f-1710-2e8b36197b73@yahoo.com> PT09PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IGdtYWtl IC0gZm91bmQNCj09PT4gICBJbWFnZU1hZ2ljay02LjkuMC40LDEgZGVwZW5kcyBvbiBleGVjdXRh YmxlOiBwa2djb25mIC0gZm91bmQNCj09PT4gICBJbWFnZU1hZ2ljay02LjkuMC40LDEgZGVwZW5k cyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hleHQucGMgLSBmb3VuZA0K PT09PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwv bGliZGF0YS9wa2djb25maWcveHQucGMgLSBmb3VuZA0KPT09PiAgIEltYWdlTWFnaWNrLTYuOS4w LjQsMSBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL3Blcmw1LjE4LjQgLSBmb3VuZA0K PT09PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IGdzIC0g Zm91bmQNCj09PT4gICBJbWFnZU1hZ2ljay02LjkuMC40LDEgZGVwZW5kcyBvbiBzaGFyZWQgbGli cmFyeTogbGlibHRkbC5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJsdGRsLnNvLjcuMy4x KQ0KPT09PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5 OiBsaWJJbG1JbWYuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliSWxtSW1mLTJfMi5zby4y Mi4wLjApDQo9PT0+ICAgSW1hZ2VNYWdpY2stNi45LjAuNCwxIGRlcGVuZHMgb24gc2hhcmVkIGxp YnJhcnk6IGxpYmRqdnVsaWJyZS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJkanZ1bGli cmUuc28uMjEuNC4wKQ0KPT09PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIHNo YXJlZCBsaWJyYXJ5OiBsaWJqcGVnLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmpwZWcu c28uOC40LjApDQo9PT0+ICAgSW1hZ2VNYWdpY2stNi45LjAuNCwxIGRlcGVuZHMgb24gc2hhcmVk IGxpYnJhcnk6IGxpYnBuZy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJwbmcxNi5zbykN Cj09PT4gICBJbWFnZU1hZ2ljay02LjkuMC40LDEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTog bGlidGlmZi5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJ0aWZmLnNvLjUuMi4wKQ0KPT09 PiAgIEltYWdlTWFnaWNrLTYuOS4wLjQsMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJs cXItMS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJscXItMS5zby4wLjMuMSkNCj09PT4g ICBJbWFnZU1hZ2ljay02LjkuMC40LDEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZmZ0 dzMuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliZmZ0dzMuc28uMy4zLjIpDQo9PT0+ICAg SW1hZ2VNYWdpY2stNi45LjAuNCwxIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmZweC5z byAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJmcHguc28uMikNCj09PT4gICBJbWFnZU1hZ2lj ay02LjkuMC40LDEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliamJpZy5zbyAtIGZvdW5k ICgvdXNyL2xvY2FsL2xpYi9saWJqYmlnLnNvLjIpDQo9PT0+ICAgSW1hZ2VNYWdpY2stNi45LjAu NCwxIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYm9wZW5qcDIuc28gLSBmb3VuZCAoL3Vz ci9sb2NhbC9saWIvbGlib3BlbmpwMi5zby43KQ0KKioqID09PT4gICBJbWFnZU1hZ2ljay02Ljku MC40LDEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZ3ZjLnNvIC0gbm90IGZvdW5kDQoq KiogPT09PiAgICBWZXJpZnlpbmcgZm9yIGxpYmd2Yy5zbyBpbiAvdXNyL3BvcnRzL2dyYXBoaWNz L2dyYXBodml6DQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBleGVjdXRhYmxl OiB0Y2xzaDguNiAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBl eGVjdXRhYmxlOiBzd2lnMi4wIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBl bmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvaW5jbHVkZS9waHAvbWFpbi9waHAuaCAtIGZvdW5kDQo9 PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9y dWJ5MjEgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZXhlY3V0 YWJsZTogZ21ha2UgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24g ZXhlY3V0YWJsZTogYmlzb24gLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVu ZHMgb24gZXhlY3V0YWJsZTogcGtnY29uZiAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4w XzYgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBtc2dmbXQgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6 LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vcHl0aG9uMi43IC0gZm91 bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHdpc2g4 LjYgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gcGFja2FnZTog bGliR0w+MCAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxl OiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2dscHJvdG8ucGMgLSBmb3VuZA0KPT09PiAg IGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3Br Z2NvbmZpZy9kcmkycHJvdG8ucGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRl cGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9nbHByb3RvLnBjIC0g Zm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9j YWwvbGliZGF0YS9wa2djb25maWcvZHJpMnByb3RvLnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZp ei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcv eGF3Ny5wYyAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxl OiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hwbS5wYyAtIGZvdW5kDQo9PT0+ICAgZ3Jh cGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29u ZmlnL3htdS5wYyAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBm aWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3h0LnBjIC0gZm91bmQNCj09PT4gICBn cmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2dj b25maWcvc20ucGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24g ZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9pY2UucGMgLSBmb3VuZA0KPT09PiAg IGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3Br Z2NvbmZpZy94ZXh0LnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRz IG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveDExLnBjIC0gZm91bmQNCj09 PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0 YS9wa2djb25maWcveGF1LnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBl bmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveGRtY3AucGMgLSBmb3Vu ZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9s aWJkYXRhL3BrZ2NvbmZpZy94cC5wYyAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYg ZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hyZW5kZXIucGMg LSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9s b2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94MTEucGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIu MzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94YXUu cGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94ZG1jcC5wYyAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2 aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmln L3NtLnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6 IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcvaWNlLnBjIC0gZm91bmQNCj09PT4gICBncmFw aHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25m aWcveGV4dC5wYyAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBm aWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hpbmVyYW1hLnBjIC0gZm91bmQNCj09 PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0 YS9wa2djb25maWcveGkucGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVu ZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94cmFuZHIucGMgLSBmb3Vu ZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9s aWJkYXRhL3BrZ2NvbmZpZy94Y3Vyc29yLnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4 LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveGZpeGVz LnBjIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91 c3IvbG9jYWwvbGliL3F0NC9saWJRdENvcmUuc28gLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIu MzguMF82IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWIvcXQ0L2xpYlF0R3VpLnNvIC0g Zm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9j YWwvYmluL2xpbmd1aXN0LXF0NCAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVw ZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9tb2MtcXQ0IC0gZm91bmQNCj09PT4gICBncmFw aHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL3FtYWtlLXF0NCAt IGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xv Y2FsL2Jpbi9yY2MgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24g ZmlsZTogL3Vzci9sb2NhbC9iaW4vdWljLXF0NCAtIGZvdW5kDQo9PT0+ICAgZ3JhcGh2aXotMi4z OC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2dub21l LW1pbWUtZGF0YS0yLjAucGMgLSBmb3VuZA0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVu ZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vaW50bHRvb2wtZXh0cmFjdCAtIGZvdW5kDQo9PT0+ ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9wZXJs NS4xOC40IC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIGV4ZWN1 dGFibGU6IGdzIC0gZm91bmQNCj09PT4gICBncmFwaHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIHNo YXJlZCBsaWJyYXJ5OiBsaWJsdGRsLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmx0ZGwu c28uNy4zLjEpDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBzaGFyZWQgbGli cmFyeTogbGlianBlZy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJqcGVnLnNvLjguNC4w KQ0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxp YnBuZy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJwbmcxNi5zbykNCj09PT4gICBncmFw aHZpei0yLjM4LjBfNiBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJmcmVldHlwZS5zbyAt IGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJmcmVldHlwZS5zby42LjExLjQpDQo9PT0+ICAgZ3Jh cGh2aXotMi4zOC4wXzYgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZm9udGNvbmZpZy5z byAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJmb250Y29uZmlnLnNvLjEuOC4wKQ0KPT09PiAg IGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmV4cGF0LnNv IC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmV4cGF0LnNvLjEuNi4wKQ0KPT09PiAgIGdyYXBo dml6LTIuMzguMF82IGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmdkLnNvIC0gZm91bmQg KC91c3IvbG9jYWwvbGliL2xpYmdkLnNvLjUuMC4wKQ0KPT09PiAgIGdyYXBodml6LTIuMzguMF82 IGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnBvcHBsZXItZ2xpYi5zbyAtIGZvdW5kICgv dXNyL2xvY2FsL2xpYi9saWJwb3BwbGVyLWdsaWIuc28uOC42LjApDQo9PT0+ICAgZ3JhcGh2aXot Mi4zOC4wXzYgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliYW5uLnNvIC0gZm91bmQgKC91 c3IvbG9jYWwvbGliL2xpYmFubi5zby4wKQ0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVu ZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmd0cy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJndHMtMC43LnNvLjUuMC4xKQ0KPT09PiAgIGdyYXBodml6LTIuMzguMF82IGRlcGVuZHMgb24g c2hhcmVkIGxpYnJhcnk6IGxpYmd0a2dsLTIuMC5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJndGtnbC0yLjAuc28uMS4wLjEpDQo9PT0+ICAgZ3JhcGh2aXotMi4zOC4wXzYgZGVwZW5kcyBv biBzaGFyZWQgbGlicmFyeTogbGliZ3RrZ2xleHQteDExLTEuMC5zbyAtIGZvdW5kICgvdXNyL2xv Y2FsL2xpYi9saWJndGtnbGV4dC14MTEtMS4wLnNvLjAuMC4wKQ0KKioqID09PT4gICBncmFwaHZp ei0yLjM4LjBfNiBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJJTC5zbyAtIG5vdCBmb3Vu ZA0KKioqID09PT4gICAgVmVyaWZ5aW5nIGZvciBsaWJJTC5zbyBpbiAvdXNyL3BvcnRzL2dyYXBo aWNzL2RldmlsDQoqKiogPT09PiAgIGRldmlsLTEuNy44XzIwLDEgZGVwZW5kcyBvbiBmaWxlOiAv dXNyL2xvY2FsL2Jpbi9zZGwtY29uZmlnIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWluZyBp bnN0YWxsIGZvciAvdXNyL2xvY2FsL2Jpbi9zZGwtY29uZmlnIGluIC91c3IvcG9ydHMvZGV2ZWwv c2RsMTINCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IG5hc20g LSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogZ21h a2UgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0YWJsZTog cGtnY29uZiAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAv dXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hleHRwcm90by5wYyAtIGZvdW5kDQo9PT0+ICAg c2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29u ZmlnL2dscHJvdG8ucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24g ZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9kcmkycHJvdG8ucGMgLSBmb3VuZA0K PT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRh L3BrZ2NvbmZpZy94MTEucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMg b24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94cmVuZGVyLnBjIC0gZm91bmQN Cj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0 YS9wa2djb25maWcveHJhbmRyLnBjIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBl bmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJhYS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJhYS5zby4xLjAuNCkNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIHNoYXJlZCBs aWJyYXJ5OiBsaWJhdWRpby5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJhdWRpby5zby4y KQ0KKioqID09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBs aWJwdWxzZS1zaW1wbGUuc28gLSBub3QgZm91bmQNCioqKiA9PT0+ICAgIFZlcmlmeWluZyBmb3Ig bGlicHVsc2Utc2ltcGxlLnNvIGluIC91c3IvcG9ydHMvYXVkaW8vcHVsc2VhdWRpbw0KPT09PiAg IHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBtc2dmbXQgLSBmb3VuZA0K PT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBnbWFrZSAtIGZv dW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHBrZ2Nv bmYgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNy L2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3gxMS5wYyAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRp by01LjBfMyBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcvc20u cGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNy L2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3h0c3QucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVk aW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2lj ZS5wYyAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGZpbGU6IC91 c3IvbG9jYWwvYmluL2ludGx0b29sLWV4dHJhY3QgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8t NS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlic2FtcGxlcmF0ZS5zbyAtIGZvdW5k ICgvdXNyL2xvY2FsL2xpYi9saWJzYW1wbGVyYXRlLnNvLjAuMS44KQ0KPT09PiAgIHB1bHNlYXVk aW8tNS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlic25kZmlsZS5zbyAtIGZvdW5k ICgvdXNyL2xvY2FsL2xpYi9saWJzbmRmaWxlLnNvLjEuMC4yNSkNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnNwZWV4ZHNwLnNvIC0gZm91bmQg KC91c3IvbG9jYWwvbGliL2xpYnNwZWV4ZHNwLnNvLjEuNS4wKQ0KPT09PiAgIHB1bHNlYXVkaW8t NS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZmZ0dzMuc28gLSBmb3VuZCAoL3Vz ci9sb2NhbC9saWIvbGliZmZ0dzMuc28uMy4zLjIpDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBk ZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJmZnR3M2Yuc28gLSBmb3VuZCAoL3Vzci9sb2Nh bC9saWIvbGliZmZ0dzNmLnNvLjMuMy4yKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5k cyBvbiBzaGFyZWQgbGlicmFyeTogbGlib3JjLTAuNC5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xp Yi9saWJvcmMtMC40LnNvLjAuMjMuMCkNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMg b24gc2hhcmVkIGxpYnJhcnk6IGxpYmpzb24tYy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJqc29uLWMuc28uMi4wLjEpDQoqKiogPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBv biBzaGFyZWQgbGlicmFyeTogbGliZGJ1cy0xLnNvIC0gbm90IGZvdW5kDQoqKiogPT09PiAgICBW ZXJpZnlpbmcgZm9yIGxpYmRidXMtMS5zbyBpbiAvdXNyL3BvcnRzL2RldmVsL2RidXMNCioqKiA9 PT0+ICAgZGJ1cy0xLjguMTJfMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHhtbHRvIC0gbm90IGZv dW5kDQo9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxsIGZvciB4bWx0byBpbiAvdXNyL3BvcnRzL3Rl eHRwcm9jL3htbHRvDQo9PT0+ICBTdGFnaW5nIGZvciB4bWx0by0wLjAuMjZfMg0KPT09PiAgIHht bHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vYmFzaCAtIGZvdW5k DQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9n ZXRvcHQgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZXhlY3V0YWJs ZTogeG1sbGludCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBleGVj dXRhYmxlOiB4c2x0cHJvYyAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBv biBwYWNrYWdlOiBkb2Nib29rLXhzbD4wIC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBk ZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHBhcGVyY29uZiAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4w LjI2XzIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB3M20gLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAu MC4yNl8yIGRlcGVuZHMgb24gcGFja2FnZTogZG9jYm9vay14bWw+MCAtIGZvdW5kDQo9PT0+ICAg eG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBwYWNrYWdlOiBmb3A+PTAuOTAgLSBmb3VuZA0KKioq ID09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2Ri bGF0ZXggLSBub3QgZm91bmQNCioqKiA9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxsIGZvciAvdXNy L2xvY2FsL2Jpbi9kYmxhdGV4IGluIC91c3IvcG9ydHMvdGV4dHByb2MvZGJsYXRleA0KKioqID09 PT4gICBkYmxhdGV4LTAuMy4yXzQgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL3NoYXJlL3Rl eG1mLWRpc3QvdGV4L2dlbmVyaWMvaWZ4ZXRleC9pZnhldGV4LnN0eSAtIG5vdCBmb3VuZA0KKioq ID09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9yIC91c3IvbG9jYWwvc2hhcmUvdGV4bWYtZGlz dC90ZXgvZ2VuZXJpYy9pZnhldGV4L2lmeGV0ZXguc3R5IGluIC91c3IvcG9ydHMvcHJpbnQvdGV4 bGl2ZS10ZXhtZg0KKioqID09PT4gICB0ZXhsaXZlLXRleG1mLTIwMTQwNTI1XzQgZGVwZW5kcyBv biBleGVjdXRhYmxlOiB0bG1nciAtIG5vdCBmb3VuZA0KKioqID09PT4gICAgVmVyaWZ5aW5nIGlu c3RhbGwgZm9yIHRsbWdyIGluIC91c3IvcG9ydHMvcHJpbnQvdGV4bGl2ZS1iYXNlDQoqKiogPT09 PiAgIHRleGxpdmUtYmFzZS0yMDE0MDUyNV82IGRlcGVuZHMgb24gZXhlY3V0YWJsZTogd2VhdmUg LSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9yIHdlYXZlIGluIC91c3Iv cG9ydHMvZGV2ZWwvdGV4LXdlYjJjDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5k cyBvbiBleGVjdXRhYmxlOiBwa2djb25mIC0gZm91bmQNCj09PT4gICB0ZXgtd2ViMmMtMjAxNDA1 MjVfMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IGdtYWtlIC0gZm91bmQNCj09PT4gICB0ZXgtd2Vi MmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25m aWcvcGl4bWFuLTEucGMgLSBmb3VuZA0KPT09PiAgIHRleC13ZWIyYy0yMDE0MDUyNV8xIGRlcGVu ZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYm9wZW5qcGVnLnNvIC0gZm91bmQgKC91c3IvbG9jYWwv bGliL2xpYm9wZW5qcGVnLnNvLjIpDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5k cyBvbiBzaGFyZWQgbGlicmFyeTogbGlicG5nLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xp YnBuZzE2LnNvKQ0KKioqID09PT4gICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIHNo YXJlZCBsaWJyYXJ5OiBsaWJ6emlwLnNvIC0gbm90IGZvdW5kDQoqKiogPT09PiAgICBWZXJpZnlp bmcgZm9yIGxpYnp6aXAuc28gaW4gL3Vzci9wb3J0cy9kZXZlbC96emlwbGliDQo9PT0+ICAgenpp cGxpYi0wLjEzLjYyXzIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB6aXAgLSBmb3VuZA0KKioqID09 PT4gICB6emlwbGliLTAuMTMuNjJfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL3Nk bC1jb25maWcgLSBub3QgZm91bmQNCioqKiA9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxsIGZvciAv dXNyL2xvY2FsL2Jpbi9zZGwtY29uZmlnIGluIC91c3IvcG9ydHMvZGV2ZWwvc2RsMTINCj09PT4g ICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IG5hc20gLSBmb3VuZA0KPT09 PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogZ21ha2UgLSBmb3VuZA0K PT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogcGtnY29uZiAtIGZv dW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xp YmRhdGEvcGtnY29uZmlnL3hleHRwcm90by5wYyAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81 LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2dscHJvdG8u cGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9s b2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9kcmkycHJvdG8ucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0x LjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94 MTEucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94cmVuZGVyLnBjIC0gZm91bmQNCj09PT4gICBzZGwt MS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcv eHJhbmRyLnBjIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIHNoYXJl ZCBsaWJyYXJ5OiBsaWJhYS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJhYS5zby4xLjAu NCkNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJh dWRpby5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJhdWRpby5zby4yKQ0KQ0lSQ1VMQVIg REVQRU5ERU5DSUUgPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJh cnk6IGxpYnB1bHNlLXNpbXBsZS5zbyAtIG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgZm9y IGxpYnB1bHNlLXNpbXBsZS5zbyBpbiAvdXNyL3BvcnRzL2F1ZGlvL3B1bHNlYXVkaW8NCj09PT4g ICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogbXNnZm10IC0gZm91bmQN Cj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogZ21ha2UgLSBm b3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBwa2dj b25mIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94MTEucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVk aW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3Nt LnBjIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94dHN0LnBjIC0gZm91bmQNCj09PT4gICBwdWxzZWF1 ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9p Y2UucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAv dXNyL2xvY2FsL2Jpbi9pbnRsdG9vbC1leHRyYWN0IC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnNhbXBsZXJhdGUuc28gLSBmb3Vu ZCAoL3Vzci9sb2NhbC9saWIvbGlic2FtcGxlcmF0ZS5zby4wLjEuOCkNCj09PT4gICBwdWxzZWF1 ZGlvLTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnNuZGZpbGUuc28gLSBmb3Vu ZCAoL3Vzci9sb2NhbC9saWIvbGlic25kZmlsZS5zby4xLjAuMjUpDQo9PT0+ICAgcHVsc2VhdWRp by01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJzcGVleGRzcC5zbyAtIGZvdW5k ICgvdXNyL2xvY2FsL2xpYi9saWJzcGVleGRzcC5zby4xLjUuMCkNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmZmdHczLnNvIC0gZm91bmQgKC91 c3IvbG9jYWwvbGliL2xpYmZmdHczLnNvLjMuMy4yKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMg ZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZmZ0dzNmLnNvIC0gZm91bmQgKC91c3IvbG9j YWwvbGliL2xpYmZmdHczZi5zby4zLjMuMikNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVu ZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYm9yYy0wLjQuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9s aWIvbGlib3JjLTAuNC5zby4wLjIzLjApDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRz IG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJqc29uLWMuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIv bGlianNvbi1jLnNvLjIuMC4xKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBz aGFyZWQgbGlicmFyeTogbGliZGJ1cy0xLnNvIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWlu ZyBmb3IgbGliZGJ1cy0xLnNvIGluIC91c3IvcG9ydHMvZGV2ZWwvZGJ1cw0KPT09PiAgIGRidXMt MS44LjEyXzEgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB4bWx0byAtIG5vdCBmb3VuZA0KPT09PiAg ICBWZXJpZnlpbmcgaW5zdGFsbCBmb3IgeG1sdG8gaW4gL3Vzci9wb3J0cy90ZXh0cHJvYy94bWx0 bw0KPT09PiAgU3RhZ2luZyBmb3IgeG1sdG8tMC4wLjI2XzINCj09PT4gICB4bWx0by0wLjAuMjZf MiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2Jhc2ggLSBmb3VuZA0KPT09PiAgIHht bHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vZ2V0b3B0IC0gZm91 bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHhtbGxpbnQg LSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogeHNs dHByb2MgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gcGFja2FnZTog ZG9jYm9vay14c2w+MCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBl eGVjdXRhYmxlOiBwYXBlcmNvbmYgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVu ZHMgb24gZXhlY3V0YWJsZTogdzNtIC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBl bmRzIG9uIHBhY2thZ2U6IGRvY2Jvb2steG1sPjAgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4y Nl8yIGRlcGVuZHMgb24gcGFja2FnZTogZm9wPj0wLjkwIC0gZm91bmQNCj09PT4gICB4bWx0by0w LjAuMjZfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2RibGF0ZXggLSBub3QgZm91 bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9yIC91c3IvbG9jYWwvYmluL2RibGF0ZXgg aW4gL3Vzci9wb3J0cy90ZXh0cHJvYy9kYmxhdGV4DQo9PT0+ICAgZGJsYXRleC0wLjMuMl80IGRl cGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9zaGFyZS90ZXhtZi1kaXN0L3RleC9nZW5lcmljL2lm eGV0ZXgvaWZ4ZXRleC5zdHkgLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwg Zm9yIC91c3IvbG9jYWwvc2hhcmUvdGV4bWYtZGlzdC90ZXgvZ2VuZXJpYy9pZnhldGV4L2lmeGV0 ZXguc3R5IGluIC91c3IvcG9ydHMvcHJpbnQvdGV4bGl2ZS10ZXhtZg0KPT09PiAgIHRleGxpdmUt dGV4bWYtMjAxNDA1MjVfNCBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHRsbWdyIC0gbm90IGZvdW5k DQo9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxsIGZvciB0bG1nciBpbiAvdXNyL3BvcnRzL3ByaW50 L3RleGxpdmUtYmFzZQ0KPT09PiAgIHRleGxpdmUtYmFzZS0yMDE0MDUyNV82IGRlcGVuZHMgb24g ZXhlY3V0YWJsZTogd2VhdmUgLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwg Zm9yIHdlYXZlIGluIC91c3IvcG9ydHMvZGV2ZWwvdGV4LXdlYjJjDQo9PT0+ICAgdGV4LXdlYjJj LTIwMTQwNTI1XzEgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBwa2djb25mIC0gZm91bmQNCj09PT4g ICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IGdtYWtlIC0gZm91 bmQNCj09PT4gICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9j YWwvbGliZGF0YS9wa2djb25maWcvcGl4bWFuLTEucGMgLSBmb3VuZA0KPT09PiAgIHRleC13ZWIy Yy0yMDE0MDUyNV8xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYm9wZW5qcGVnLnNvIC0g Zm91bmQgKC91c3IvbG9jYWwvbGliL2xpYm9wZW5qcGVnLnNvLjIpDQo9PT0+ICAgdGV4LXdlYjJj LTIwMTQwNTI1XzEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlicG5nLnNvIC0gZm91bmQg KC91c3IvbG9jYWwvbGliL2xpYnBuZzE2LnNvKQ0KPT09PiAgIHRleC13ZWIyYy0yMDE0MDUyNV8x IGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnp6aXAuc28gLSBub3QgZm91bmQNCj09PT4g ICAgVmVyaWZ5aW5nIGZvciBsaWJ6emlwLnNvIGluIC91c3IvcG9ydHMvZGV2ZWwvenppcGxpYg0K PT09PiAgIHp6aXBsaWItMC4xMy42Ml8yIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogemlwIC0gZm91 bmQNCj09PT4gICB6emlwbGliLTAuMTMuNjJfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwv YmluL3NkbC1jb25maWcgLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9y IC91c3IvbG9jYWwvYmluL3NkbC1jb25maWcgaW4gL3Vzci9wb3J0cy9kZXZlbC9zZGwxMg0KPT09 PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogbmFzbSAtIGZvdW5kDQo9 PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBnbWFrZSAtIGZvdW5k DQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBwa2djb25mIC0g Zm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwv bGliZGF0YS9wa2djb25maWcveGV4dHByb3RvLnBjIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1 XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcvZ2xwcm90 by5wYyAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNy L2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2RyaTJwcm90by5wYyAtIGZvdW5kDQo9PT0+ICAgc2Rs LTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmln L3gxMS5wYyAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAv dXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hyZW5kZXIucGMgLSBmb3VuZA0KPT09PiAgIHNk bC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZp Zy94cmFuZHIucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gc2hh cmVkIGxpYnJhcnk6IGxpYmFhLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmFhLnNvLjEu MC40KQ0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxp YmF1ZGlvLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmF1ZGlvLnNvLjIpDQo9PT0+ICAg c2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlicHVsc2Utc2ltcGxl LnNvIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWluZyBmb3IgbGlicHVsc2Utc2ltcGxlLnNv IGluIC91c3IvcG9ydHMvYXVkaW8vcHVsc2VhdWRpbw0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMg ZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBtc2dmbXQgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8t NS4wXzMgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBnbWFrZSAtIGZvdW5kDQo9PT0+ICAgcHVsc2Vh dWRpby01LjBfMyBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHBrZ2NvbmYgLSBmb3VuZA0KPT09PiAg IHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtn Y29uZmlnL3gxMS5wYyAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9u IGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcvc20ucGMgLSBmb3VuZA0KPT09PiAg IHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtn Y29uZmlnL3h0c3QucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBv biBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL2ljZS5wYyAtIGZvdW5kDQo9PT0+ ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2ludGx0 b29sLWV4dHJhY3QgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBz aGFyZWQgbGlicmFyeTogbGlic2FtcGxlcmF0ZS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJzYW1wbGVyYXRlLnNvLjAuMS44KQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBv biBzaGFyZWQgbGlicmFyeTogbGlic25kZmlsZS5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9s aWJzbmRmaWxlLnNvLjEuMC4yNSkNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24g c2hhcmVkIGxpYnJhcnk6IGxpYnNwZWV4ZHNwLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xp YnNwZWV4ZHNwLnNvLjEuNS4wKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBz aGFyZWQgbGlicmFyeTogbGliZmZ0dzMuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliZmZ0 dzMuc28uMy4zLjIpDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBs aWJyYXJ5OiBsaWJmZnR3M2Yuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliZmZ0dzNmLnNv LjMuMy4yKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFy eTogbGlib3JjLTAuNC5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJvcmMtMC40LnNvLjAu MjMuMCkNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6 IGxpYmpzb24tYy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJqc29uLWMuc28uMi4wLjEp DQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJk YnVzLTEuc28gLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGZvciBsaWJkYnVzLTEuc28g aW4gL3Vzci9wb3J0cy9kZXZlbC9kYnVzDQo9PT0+ICAgZGJ1cy0xLjguMTJfMSBkZXBlbmRzIG9u IGV4ZWN1dGFibGU6IHhtbHRvIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxs IGZvciB4bWx0byBpbiAvdXNyL3BvcnRzL3RleHRwcm9jL3htbHRvDQo9PT0+ICBTdGFnaW5nIGZv ciB4bWx0by0wLjAuMjZfMg0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZmlsZTog L3Vzci9sb2NhbC9iaW4vYmFzaCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5k cyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9nZXRvcHQgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAu MC4yNl8yIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogeG1sbGludCAtIGZvdW5kDQo9PT0+ICAgeG1s dG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB4c2x0cHJvYyAtIGZvdW5kDQo9PT0+ ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBwYWNrYWdlOiBkb2Nib29rLXhzbD4wIC0gZm91 bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHBhcGVyY29u ZiAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB3 M20gLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gcGFja2FnZTogZG9j Ym9vay14bWw+MCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBwYWNr YWdlOiBmb3A+PTAuOTAgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24g ZmlsZTogL3Vzci9sb2NhbC9iaW4vZGJsYXRleCAtIG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlp bmcgaW5zdGFsbCBmb3IgL3Vzci9sb2NhbC9iaW4vZGJsYXRleCBpbiAvdXNyL3BvcnRzL3RleHRw cm9jL2RibGF0ZXgNCj09PT4gICBkYmxhdGV4LTAuMy4yXzQgZGVwZW5kcyBvbiBmaWxlOiAvdXNy L2xvY2FsL3NoYXJlL3RleG1mLWRpc3QvdGV4L2dlbmVyaWMvaWZ4ZXRleC9pZnhldGV4LnN0eSAt IG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgaW5zdGFsbCBmb3IgL3Vzci9sb2NhbC9zaGFy ZS90ZXhtZi1kaXN0L3RleC9nZW5lcmljL2lmeGV0ZXgvaWZ4ZXRleC5zdHkgaW4gL3Vzci9wb3J0 cy9wcmludC90ZXhsaXZlLXRleG1mDQo9PT0+ICAgdGV4bGl2ZS10ZXhtZi0yMDE0MDUyNV80IGRl cGVuZHMgb24gZXhlY3V0YWJsZTogdGxtZ3IgLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5n IGluc3RhbGwgZm9yIHRsbWdyIGluIC91c3IvcG9ydHMvcHJpbnQvdGV4bGl2ZS1iYXNlDQo9PT0+ ICAgdGV4bGl2ZS1iYXNlLTIwMTQwNTI1XzYgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB3ZWF2ZSAt IG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgaW5zdGFsbCBmb3Igd2VhdmUgaW4gL3Vzci9w b3J0cy9kZXZlbC90ZXgtd2ViMmMNCj09PT4gICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRz IG9uIGV4ZWN1dGFibGU6IHBrZ2NvbmYgLSBmb3VuZA0KPT09PiAgIHRleC13ZWIyYy0yMDE0MDUy NV8xIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogZ21ha2UgLSBmb3VuZA0KPT09PiAgIHRleC13ZWIy Yy0yMDE0MDUyNV8xIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZp Zy9waXhtYW4tMS5wYyAtIGZvdW5kDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5k cyBvbiBzaGFyZWQgbGlicmFyeTogbGlib3BlbmpwZWcuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9s aWIvbGlib3BlbmpwZWcuc28uMikNCj09PT4gICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRz IG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJwbmcuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGli cG5nMTYuc28pDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5kcyBvbiBzaGFyZWQg bGlicmFyeTogbGlienppcC5zbyAtIG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgZm9yIGxp Ynp6aXAuc28gaW4gL3Vzci9wb3J0cy9kZXZlbC96emlwbGliDQo9PT0+ICAgenppcGxpYi0wLjEz LjYyXzIgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB6aXAgLSBmb3VuZA0KPT09PiAgIHp6aXBsaWIt MC4xMy42Ml8yIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vc2RsLWNvbmZpZyAtIG5v dCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgaW5zdGFsbCBmb3IgL3Vzci9sb2NhbC9iaW4vc2Rs LWNvbmZpZyBpbiAvdXNyL3BvcnRzL2RldmVsL3NkbDEyDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIg ZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBuYXNtIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUs MiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IGdtYWtlIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1 XzUsMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHBrZ2NvbmYgLSBmb3VuZA0KPT09PiAgIHNkbC0x LjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94 ZXh0cHJvdG8ucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmls ZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9nbHByb3RvLnBjIC0gZm91bmQNCj09PT4g ICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2dj b25maWcvZHJpMnByb3RvLnBjIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRz IG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveDExLnBjIC0gZm91bmQNCj09 PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9w a2djb25maWcveHJlbmRlci5wYyAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5k cyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hyYW5kci5wYyAtIGZvdW5k DQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliYWEu c28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliYWEuc28uMS4wLjQpDQo9PT0+ICAgc2RsLTEu Mi4xNV81LDIgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliYXVkaW8uc28gLSBmb3VuZCAo L3Vzci9sb2NhbC9saWIvbGliYXVkaW8uc28uMikNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBl bmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJwdWxzZS1zaW1wbGUuc28gLSBub3QgZm91bmQNCj09 PT4gICAgVmVyaWZ5aW5nIGZvciBsaWJwdWxzZS1zaW1wbGUuc28gaW4gL3Vzci9wb3J0cy9hdWRp by9wdWxzZWF1ZGlvDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGV4ZWN1dGFi bGU6IG1zZ2ZtdCAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGV4 ZWN1dGFibGU6IGdtYWtlIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMg b24gZXhlY3V0YWJsZTogcGtnY29uZiAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBk ZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveDExLnBjIC0gZm91 bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9s aWJkYXRhL3BrZ2NvbmZpZy9zbS5wYyAtIGZvdW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBk ZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvbGliZGF0YS9wa2djb25maWcveHRzdC5wYyAtIGZv dW5kDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwv bGliZGF0YS9wa2djb25maWcvaWNlLnBjIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8z IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vaW50bHRvb2wtZXh0cmFjdCAtIGZvdW5k DQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJz YW1wbGVyYXRlLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYnNhbXBsZXJhdGUuc28uMC4x LjgpDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBs aWJzbmRmaWxlLnNvIC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYnNuZGZpbGUuc28uMS4wLjI1 KQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGli c3BlZXhkc3Auc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGlic3BlZXhkc3Auc28uMS41LjAp DQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJm ZnR3My5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJmZnR3My5zby4zLjMuMikNCj09PT4g ICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmZmdHczZi5z byAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJmZnR3M2Yuc28uMy4zLjIpDQo9PT0+ICAgcHVs c2VhdWRpby01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJvcmMtMC40LnNvIC0g Zm91bmQgKC91c3IvbG9jYWwvbGliL2xpYm9yYy0wLjQuc28uMC4yMy4wKQ0KPT09PiAgIHB1bHNl YXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlianNvbi1jLnNvIC0gZm91 bmQgKC91c3IvbG9jYWwvbGliL2xpYmpzb24tYy5zby4yLjAuMSkNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmRidXMtMS5zbyAtIG5vdCBmb3Vu ZA0KPT09PiAgICBWZXJpZnlpbmcgZm9yIGxpYmRidXMtMS5zbyBpbiAvdXNyL3BvcnRzL2RldmVs L2RidXMNCj09PT4gICBkYnVzLTEuOC4xMl8xIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogeG1sdG8g LSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9yIHhtbHRvIGluIC91c3Iv cG9ydHMvdGV4dHByb2MveG1sdG8NCj09PT4gIFN0YWdpbmcgZm9yIHhtbHRvLTAuMC4yNl8yDQo9 PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9iYXNo IC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9j YWwvYmluL2dldG9wdCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBl eGVjdXRhYmxlOiB4bWxsaW50IC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRz IG9uIGV4ZWN1dGFibGU6IHhzbHRwcm9jIC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBk ZXBlbmRzIG9uIHBhY2thZ2U6IGRvY2Jvb2steHNsPjAgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAu MC4yNl8yIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogcGFwZXJjb25mIC0gZm91bmQNCj09PT4gICB4 bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHczbSAtIGZvdW5kDQo9PT0+ICAg eG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBwYWNrYWdlOiBkb2Nib29rLXhtbD4wIC0gZm91bmQN Cj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIHBhY2thZ2U6IGZvcD49MC45MCAtIGZv dW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2Jp bi9kYmxhdGV4IC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWluZyBpbnN0YWxsIGZvciAvdXNy L2xvY2FsL2Jpbi9kYmxhdGV4IGluIC91c3IvcG9ydHMvdGV4dHByb2MvZGJsYXRleA0KPT09PiAg IGRibGF0ZXgtMC4zLjJfNCBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvc2hhcmUvdGV4bWYt ZGlzdC90ZXgvZ2VuZXJpYy9pZnhldGV4L2lmeGV0ZXguc3R5IC0gbm90IGZvdW5kDQo9PT0+ICAg IFZlcmlmeWluZyBpbnN0YWxsIGZvciAvdXNyL2xvY2FsL3NoYXJlL3RleG1mLWRpc3QvdGV4L2dl bmVyaWMvaWZ4ZXRleC9pZnhldGV4LnN0eSBpbiAvdXNyL3BvcnRzL3ByaW50L3RleGxpdmUtdGV4 bWYNCj09PT4gICB0ZXhsaXZlLXRleG1mLTIwMTQwNTI1XzQgZGVwZW5kcyBvbiBleGVjdXRhYmxl OiB0bG1nciAtIG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgaW5zdGFsbCBmb3IgdGxtZ3Ig aW4gL3Vzci9wb3J0cy9wcmludC90ZXhsaXZlLWJhc2UNCj09PT4gICB0ZXhsaXZlLWJhc2UtMjAx NDA1MjVfNiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHdlYXZlIC0gbm90IGZvdW5kDQo9PT0+ICAg IFZlcmlmeWluZyBpbnN0YWxsIGZvciB3ZWF2ZSBpbiAvdXNyL3BvcnRzL2RldmVsL3RleC13ZWIy Yw0KPT09PiAgIHRleC13ZWIyYy0yMDE0MDUyNV8xIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogcGtn Y29uZiAtIGZvdW5kDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5kcyBvbiBleGVj dXRhYmxlOiBnbWFrZSAtIGZvdW5kDQo9PT0+ICAgdGV4LXdlYjJjLTIwMTQwNTI1XzEgZGVwZW5k cyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3BpeG1hbi0xLnBjIC0gZm91 bmQNCj09PT4gICB0ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5 OiBsaWJvcGVuanBlZy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJvcGVuanBlZy5zby4y KQ0KPT09PiAgIHRleC13ZWIyYy0yMDE0MDUyNV8xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6 IGxpYnBuZy5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJwbmcxNi5zbykNCj09PT4gICB0 ZXgtd2ViMmMtMjAxNDA1MjVfMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJ6emlwLnNv IC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWluZyBmb3IgbGlienppcC5zbyBpbiAvdXNyL3Bv cnRzL2RldmVsL3p6aXBsaWINCj09PT4gICB6emlwbGliLTAuMTMuNjJfMiBkZXBlbmRzIG9uIGV4 ZWN1dGFibGU6IHppcCAtIGZvdW5kDQo9PT0+ICAgenppcGxpYi0wLjEzLjYyXzIgZGVwZW5kcyBv biBmaWxlOiAvdXNyL2xvY2FsL2Jpbi9zZGwtY29uZmlnIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZl cmlmeWluZyBpbnN0YWxsIGZvciAvdXNyL2xvY2FsL2Jpbi9zZGwtY29uZmlnIGluIC91c3IvcG9y dHMvZGV2ZWwvc2RsMTINCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGV4ZWN1dGFi bGU6IG5hc20gLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhlY3V0 YWJsZTogZ21ha2UgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZXhl Y3V0YWJsZTogcGtnY29uZiAtIGZvdW5kDQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBv biBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3hleHRwcm90by5wYyAtIGZvdW5k DQo9PT0+ICAgc2RsLTEuMi4xNV81LDIgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRh dGEvcGtnY29uZmlnL2dscHJvdG8ucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRl cGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9kcmkycHJvdG8ucGMg LSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2Nh bC9saWJkYXRhL3BrZ2NvbmZpZy94MTEucGMgLSBmb3VuZA0KPT09PiAgIHNkbC0xLjIuMTVfNSwy IGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94cmVuZGVyLnBj IC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9j YWwvbGliZGF0YS9wa2djb25maWcveHJhbmRyLnBjIC0gZm91bmQNCj09PT4gICBzZGwtMS4yLjE1 XzUsMiBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJhYS5zbyAtIGZvdW5kICgvdXNyL2xv Y2FsL2xpYi9saWJhYS5zby4xLjAuNCkNCj09PT4gICBzZGwtMS4yLjE1XzUsMiBkZXBlbmRzIG9u IHNoYXJlZCBsaWJyYXJ5OiBsaWJhdWRpby5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJh dWRpby5zby4yKQ0KPT09PiAgIHNkbC0xLjIuMTVfNSwyIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJh cnk6IGxpYnB1bHNlLXNpbXBsZS5zbyAtIG5vdCBmb3VuZA0KPT09PiAgICBWZXJpZnlpbmcgZm9y IGxpYnB1bHNlLXNpbXBsZS5zbyBpbiAvdXNyL3BvcnRzL2F1ZGlvL3B1bHNlYXVkaW8NCj09PT4g ICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogbXNnZm10IC0gZm91bmQN Cj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogZ21ha2UgLSBm b3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiBwa2dj b25mIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94MTEucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVk aW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAvdXNyL2xvY2FsL2xpYmRhdGEvcGtnY29uZmlnL3Nt LnBjIC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vz ci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy94dHN0LnBjIC0gZm91bmQNCj09PT4gICBwdWxzZWF1 ZGlvLTUuMF8zIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9saWJkYXRhL3BrZ2NvbmZpZy9p Y2UucGMgLSBmb3VuZA0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBmaWxlOiAv dXNyL2xvY2FsL2Jpbi9pbnRsdG9vbC1leHRyYWN0IC0gZm91bmQNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnNhbXBsZXJhdGUuc28gLSBmb3Vu ZCAoL3Vzci9sb2NhbC9saWIvbGlic2FtcGxlcmF0ZS5zby4wLjEuOCkNCj09PT4gICBwdWxzZWF1 ZGlvLTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYnNuZGZpbGUuc28gLSBmb3Vu ZCAoL3Vzci9sb2NhbC9saWIvbGlic25kZmlsZS5zby4xLjAuMjUpDQo9PT0+ICAgcHVsc2VhdWRp by01LjBfMyBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJzcGVleGRzcC5zbyAtIGZvdW5k ICgvdXNyL2xvY2FsL2xpYi9saWJzcGVleGRzcC5zby4xLjUuMCkNCj09PT4gICBwdWxzZWF1ZGlv LTUuMF8zIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmZmdHczLnNvIC0gZm91bmQgKC91 c3IvbG9jYWwvbGliL2xpYmZmdHczLnNvLjMuMy4yKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMg ZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGliZmZ0dzNmLnNvIC0gZm91bmQgKC91c3IvbG9j YWwvbGliL2xpYmZmdHczZi5zby4zLjMuMikNCj09PT4gICBwdWxzZWF1ZGlvLTUuMF8zIGRlcGVu ZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYm9yYy0wLjQuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9s aWIvbGlib3JjLTAuNC5zby4wLjIzLjApDQo9PT0+ICAgcHVsc2VhdWRpby01LjBfMyBkZXBlbmRz IG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJqc29uLWMuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIv bGlianNvbi1jLnNvLjIuMC4xKQ0KPT09PiAgIHB1bHNlYXVkaW8tNS4wXzMgZGVwZW5kcyBvbiBz aGFyZWQgbGlicmFyeTogbGliZGJ1cy0xLnNvIC0gbm90IGZvdW5kDQo9PT0+ICAgIFZlcmlmeWlu ZyBmb3IgbGliZGJ1cy0xLnNvIGluIC91c3IvcG9ydHMvZGV2ZWwvZGJ1cw0KPT09PiAgIGRidXMt MS44LjEyXzEgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB4bWx0byAtIG5vdCBmb3VuZA0KPT09PiAg ICBWZXJpZnlpbmcgaW5zdGFsbCBmb3IgeG1sdG8gaW4gL3Vzci9wb3J0cy90ZXh0cHJvYy94bWx0 bw0KPT09PiAgU3RhZ2luZyBmb3IgeG1sdG8tMC4wLjI2XzINCj09PT4gICB4bWx0by0wLjAuMjZf MiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2Jhc2ggLSBmb3VuZA0KPT09PiAgIHht bHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9iaW4vZ2V0b3B0IC0gZm91 bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHhtbGxpbnQg LSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gZXhlY3V0YWJsZTogeHNs dHByb2MgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVuZHMgb24gcGFja2FnZTog ZG9jYm9vay14c2w+MCAtIGZvdW5kDQo9PT0+ICAgeG1sdG8tMC4wLjI2XzIgZGVwZW5kcyBvbiBl eGVjdXRhYmxlOiBwYXBlcmNvbmYgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4yNl8yIGRlcGVu ZHMgb24gZXhlY3V0YWJsZTogdzNtIC0gZm91bmQNCj09PT4gICB4bWx0by0wLjAuMjZfMiBkZXBl bmRzIG9uIHBhY2thZ2U6IGRvY2Jvb2steG1sPjAgLSBmb3VuZA0KPT09PiAgIHhtbHRvLTAuMC4y Nl8yIGRlcGVuZHMgb24gcGFja2FnZTogZm9wPj0wLjkwIC0gZm91bmQNCj09PT4gICB4bWx0by0w LjAuMjZfMiBkZXBlbmRzIG9uIGZpbGU6IC91c3IvbG9jYWwvYmluL2RibGF0ZXggLSBub3QgZm91 bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwgZm9yIC91c3IvbG9jYWwvYmluL2RibGF0ZXgg aW4gL3Vzci9wb3J0cy90ZXh0cHJvYy9kYmxhdGV4DQo9PT0+ICAgZGJsYXRleC0wLjMuMl80IGRl cGVuZHMgb24gZmlsZTogL3Vzci9sb2NhbC9zaGFyZS90ZXhtZi1kaXN0L3RleC9nZW5lcmljL2lm eGV0ZXgvaWZ4ZXRleC5zdHkgLSBub3QgZm91bmQNCj09PT4gICAgVmVyaWZ5aW5nIGluc3RhbGwg Zm9yIC91c3IvbG9jYWwvc2hhcmUvdGV4bWYtZGlzdC90ZXgvZ2VuZXJpYy9pZnhldGV4L2lmeGV0 ZXguc3R5IGluIC91c3IvcG9ydHMvcHJpbnQvdGV4bGl2ZS10ZXhtZg0K ------=_Part_4037953_1233289034.1426259725295-- From owner-freebsd-ports@FreeBSD.ORG Sat Mar 14 09:42:22 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2BB3C3C for ; Sat, 14 Mar 2015 09:42:22 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE691ABD for ; Sat, 14 Mar 2015 09:42:22 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2E9gM5e057249 for ; Sat, 14 Mar 2015 09:42:22 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2E9gMDd057248; Sat, 14 Mar 2015 09:42:22 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503140942.t2E9gMDd057248@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Sat, 14 Mar 2015 09:42:22 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 09:42:22 -0000 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/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ databases/pecl-mongo | 1.6.4 | 1.6.5 ------------------------------------------------+-----------------+------------ sysutils/createrepo | 0.10.3 | 0.10.4 ------------------------------------------------+-----------------+------------ 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. From owner-freebsd-ports@FreeBSD.ORG Sat Mar 14 19:41:20 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C44CE23 for ; Sat, 14 Mar 2015 19:41:20 +0000 (UTC) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C98A912 for ; Sat, 14 Mar 2015 19:41:19 +0000 (UTC) Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mx.arcor.de (Postfix) with ESMTP id 3l4D2D2C0hzY4X8 for ; Sat, 14 Mar 2015 20:08:36 +0100 (CET) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 47DC133B78C for ; Sat, 14 Mar 2015 20:08:36 +0100 (CET) X-Greylist: Passed host: 188.105.81.112 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-02.arcor-online.net 3l4D2D1BXGz1Syj Received: from lorvorc.mips.inka.de (dslb-188-105-081-112.188.105.pools.vodafone-ip.de [188.105.81.112]) by mail-in-02.arcor-online.net (Postfix) with ESMTPS id 3l4D2D1BXGz1Syj for ; Sat, 14 Mar 2015 20:08:36 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t2EJ8ZOF089462 for ; Sat, 14 Mar 2015 20:08:35 +0100 (CET) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t2EJ8Zj0089461 for freebsd-ports@freebsd.org; Sat, 14 Mar 2015 20:08:35 +0100 (CET) (envelope-from news) To: freebsd-ports@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.ports Subject: Re: converters/iconv versioning Date: Sat, 14 Mar 2015 19:08:35 +0000 (UTC) Lines: 21 Message-ID: References: <54FF75A2.4020803@gmail.com> <54FF8A19.3090700@gmail.com> X-Trace: lorvorc.mips.inka.de 1426360115 89309 ::1 (14 Mar 2015 19:08:35 GMT) X-Complaints-To: usenet@mips.inka.de User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:41:20 -0000 On 2015-03-11, Scott Furry wrote: > Okay...different iconv. But what's the reason for change? > And does this one function call really need to be const? Is the > __restrict in the type not used on FreeBSD? > > Seems strange to differ on a gnu-based. POSIX says: size_t iconv(iconv_t cd, char **restrict inbuf, size_t *restrict inbytesleft, char **restrict outbuf, size_t *restrict outbytesleft); For GNU iconv, whether you have a const in the prototype or not is configurable. I think by default it tries to match the prototype of an existing iconv on the machine. The FreeBSD port specifically asks for the const, presumably for consistency with earlier versions. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-ports@FreeBSD.ORG Sat Mar 14 21:03:10 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67900481 for ; Sat, 14 Mar 2015 21:03:10 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28124C0 for ; Sat, 14 Mar 2015 21:03:10 +0000 (UTC) Received: by iegc3 with SMTP id c3so147516230ieg.3 for ; Sat, 14 Mar 2015 14:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WODPCc5jZfYcqgd/reoBgptPJFKfBV/fqQdbVUMqV+w=; b=kIQIUK/zhQzM1ae5QEjew4P2ixQQzNPZSMkIlkfcCMC9UHp2NL5joZNvULb3GMFP6z HeiJylB42trhWSBL7/kKJtFMfjPjck+q4Xl7YlJ6ZNMdc/DQaHmm8erRTGW/gF8YTVmh aFJ7O0Wvq7U4tN/2OaazesxENZw6MHec2AWggU8DOHSm8z89Q0xwFcgFD5fiaMGIc8+5 SHm6l32U4Wlu2LwTVMPSYo4/uLC/KEPa1hoCauh8z7M7E8fsDvG9dSaE7kSQol/cMJCT QlLZ8kroxMoPBEPBG3+CbUI4Qna+XQAc3ZNbYvULK00Fmg7MvREFEgjMnnYZuuaxp/r+ cwzw== X-Received: by 10.107.154.73 with SMTP id c70mr4866052ioe.22.1426366989422; Sat, 14 Mar 2015 14:03:09 -0700 (PDT) Received: from [10.0.1.155] (d205-206-84-235.abhsia.telus.net. [205.206.84.235]) by mx.google.com with ESMTPSA id p76sm3850178iop.14.2015.03.14.14.03.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 14:03:08 -0700 (PDT) Message-ID: <5504A209.3030608@gmail.com> Date: Sat, 14 Mar 2015 15:03:05 -0600 From: Scott Furry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christian Weisgerber , freebsd-ports@freebsd.org Subject: Re: converters/iconv versioning References: <54FF75A2.4020803@gmail.com> <54FF8A19.3090700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 21:03:10 -0000 On 14/03/2015 13:08, Christian Weisgerber wrote: > On 2015-03-11, Scott Furry wrote: >> Okay...different iconv. But what's the reason for change? >> And does this one function call really need to be const? Is the >> __restrict in the type not used on FreeBSD? >> >> Seems strange to differ on a gnu-based. > POSIX says: > > size_t iconv(iconv_t cd, char **restrict inbuf, > size_t *restrict inbytesleft, char **restrict outbuf, > size_t *restrict outbytesleft); > > For GNU iconv, whether you have a const in the prototype or not is > configurable. I think by default it tries to match the prototype > of an existing iconv on the machine. The FreeBSD port specifically > asks for the const, presumably for consistency with earlier versions. Christian, Ran into a situation with other code where clang would issue a warning about calling iconv function without const variable. That's when I discovered the difference with FreeBSD's iconv (sorry, haven't memorized the handbook or porters handbook ;-) ). The function declaration you show matches what I've seen on both Mac and Linux. So iconv being used on FreeBSD differs from posix? Custom iconv Just seemed odd. Had to ask. Thanks for filling in a blank. Scott