From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 06:09:12 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9C59355 for ; Sun, 23 Jun 2013 06:09:12 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 1EDA91055 for ; Sun, 23 Jun 2013 06:09:11 +0000 (UTC) Received: (qmail 70577 invoked by uid 89); 23 Jun 2013 06:09:03 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.183.247) by mail.grem.de with ESMTPA; 23 Jun 2013 06:09:03 -0000 Date: Sun, 23 Jun 2013 08:09:05 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130623080905.17f77d71@bsd64.grem.de> In-Reply-To: References: <20130613031535.4087d7f9@bsd64.grem.de> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/LfKU5HdBj6_6Cc/VQfpV0gi" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 06:09:13 -0000 --MP_/LfKU5HdBj6_6Cc/VQfpV0gi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 22 Jun 2013 00:27:53 +0200 Dimitry Andric wrote: > On Jun 21, 2013, at 22:07, Dimitry Andric wrote: > > On Jun 13, 2013, at 03:15, Michael Gmelin wrote: > ... > >> - system clang + std=c++11 + system libc++: Build fails, due to > >> a dependency (databases/db5) not building with those flags. It > >> looks like a problem in libc++ to me, but I didn't have much time > >> to investigate. It might be one of those things that might just go > >> away after a while. > > > > No, db5 does not build because it is redefining a C++11 standard > > library identifier, atomic_init(). It should probably prefix all > > its internal defines with 'db_', to avoid collisions. The > > db-5.3.21/src/dbinc/atomic.h file is already patched by our port to > > avoid one such collision, but it is probably necessary to do this > > again for any other identifiers that are used either by C++, or are > > compiler builtins. > > Attached is a diff to fix the db5 port, so it correctly builds with > CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please have > a look at it? > > After db5 (compiled with libc++) was installed, I retried devel/ice > again, but the Slice/keyword test failed in exactly the same way. If > you comment out the "delete factoryTable" line in > cpp/src/Ice/FactoryTableInit.cpp, the Slice/keyword test does succeed. > > Many other tests after that also go well, and the next failure I get > was: > > *** running tests 39/83 > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp *** > configuration: Default *** test started: 06/22/13 00:20:11 > starting server #1... ok > starting server #2... Traceback (most recent call last): > File > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp/run.py", > line 41, in serverProc.append(TestUtil.startServer(server, > "%d" % i , adapter="McastTestAdapter")) File > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > line 1396, in startServer return spawnServer(cmd, env = env, adapter > = adapter, count = count, echo = echo,lang=config.lang,mx=config.mx) > File > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > line 1131, in spawnServer server.expect("%s ready\n" % adapter) File > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/Expect.py", > line 394, in expect raise e Expect.TIMEOUT: timeout exceeded in match > pattern: "McastTestAdapter ready\n" buffer: "ControlAdapter ready > Network.cpp:1701: Ice::SocketException: socket exception: Address > already in use " > > ('test > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp > failed with exit status', 256) > > Whatever the source of this problem is, it is not very likely that is > caused by a compiler or C++ library issue, but more likely some > unexpected API change in sockets. > > -Dimitry Hi Dimitry, I've been able to analyze issue further and developed a fix (make factoryTable's lifetime dependant on the lifetime of generated _Init classes). I filed a bug report upstream: http://www.zeroc.com/forums/bug-reports/6030-ice-3-5-0-slice2cpp-generated-code-relies-static-initialization-order-crash.html#post26001 The second issue is a little bit more tricky. Since I was building the port in a jail, the UDP based unit test didn't run and it didn't notice it fail. Therefore it's not limited to CURRENT and, as it turns out, it is a kernel bug. Digging a little bit deeper into the problem I noticed that there seems to be a multicast problem in the kernel. Usually setting SO_REUSEADDR on a multicast address should implicitly set SO_REUSEPORT as well. Staring at the kernel code this only seems to work on the currently created socket, but the cached flag of already listening multicast sockets is not retrieved correctly, which makes me believe that the cached flag is initialized correctly when creating it. I think that this problem might have been introduced a while ago in or after revision 227428: http://svnweb.freebsd.org/base?view=revision&revision=227428 Which MFC'd 227207 Which says: "Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid inp_socket->so_options dereference when we may not acquire the lock on the inpcb." I did some testing using a small test program that listened to a multicast address and noticed: - First invocation SO_REUSEADDR, second invocation SO_REUSEADDR => fail - First invocation SO_REUSEADDR, second invocation SO_REUSEPORT => fail - First invocation SO_REUSEPORT, second invocation SO_REUSEADDR => success - First invocation SO_REUSEPORT, second invocation SO_REUSEPORT => success My gut feeling tells me that the code used to set the correct values for inp_flags2 only works when setsockopt is called after the socket has been bound and testing verified that this is actually the case. Adding an additional setsockopt call after calling bind makes things work as expected. For comparison I also tested in a VM running ancient 7.x, where things worked as expected. So... if this was just about this port, the obvious fix would be patching devel/ice to use SO_REUSEPORT explicitly for multicast (which actually makes that unit test run ok), but this seems more like an issue that really needs to be fixed on a system level. Should I open a PR, or can you take it from here? Cheers, Michael p.s. - I attached the C program I used for testing and demonstrating the problem: [user@bsd64 /tmp]$ cc -o multicast multicast.c [user@bsd64 /tmp]$ ./multicast reuseaddr & [1] 9040 [user@bsd64 /tmp]$ ./multicast reuseaddr binding datagram socket: Address already in use [user@bsd64 /tmp]$ killall multicast ... [user@bsd64 /tmp]$ ./multicast reuseport & [1] 9093 [user@bsd64 /tmp]$ ./multicast reuseaddr & [2] 9098 [user@bsd64 /tmp]$ ./multicast reuseaddr & [3] 9107 [user@bsd64 /tmp]$ binding datagram socket: Address already in use [user@bsd64 /tmp]$ killall multicast ... [user@bsd64 /tmp]$ ./multicast reuseaddrafter & [1] 9132 [user@bsd64 /tmp]$ ./multicast reuseaddrafter & [2] 9135 [user@bsd64 /tmp]$ ./multicast reuseaddrafter & [3] 9136 [user@bsd64 /tmp]$ ./multicast reuseaddrafter & [4] 9137 [user@bsd64 /tmp]$ ./multicast reuseport & [5] 9140 [user@bsd64 /tmp]$ ./multicast reuseaddr & [6] 9181 [user@bsd64 /tmp]$ ./multicast reuseaddr & [7] 9184 [user@bsd64 /tmp]$ binding datagram socket: Address already in use -- Michael Gmelin --MP_/LfKU5HdBj6_6Cc/VQfpV0gi-- From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 07:35:46 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AA3C48A; Sun, 23 Jun 2013 07:35:46 +0000 (UTC) (envelope-from vd@v5d.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5257C1264; Sun, 23 Jun 2013 07:35:45 +0000 (UTC) Received: from mail.v5d.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5N7ZhlR031290; Sun, 23 Jun 2013 07:35:45 GMT (envelope-from vd@v5d.org) Received: by mail.v5d.org (Postfix, from userid 1007) id BA2462E2F0; Sun, 23 Jun 2013 10:35:43 +0300 (EEST) Date: Sun, 23 Jun 2013 10:35:43 +0300 From: Vasil Dimov To: Rob Clark Subject: Re: hugin, libboost_thread.so not found Message-ID: <20130623073543.GA28451@hag.hw.v5d.org> References: <20130622033016.72bad862.rpclark@tds.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20130622033016.72bad862.rpclark@tds.net> User-Agent: Mutt Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: vd@FreeBSD.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 07:35:46 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2013 at 03:30:16 -0400, Rob Clark wrote: > Cannot get hugin to work,=20 > I get the following: >=20 > $ hugin > /libexec/ld-elf.so.1: Shared object "libboost_thread.so"not > found, required by "hugin"=20 > $=20 [...] Hi, what is the output of the following commands, when executed in your environment: ldd `which hugin` ls -l /usr/local/lib/libboost* ls -l /var/db/pkg/, or if you are using pkg(8), then: pkg info --=20 Vasil Dimov gro.DSBeerF@dv % Without fools there would be no wisdom. --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlHGpU8ACgkQFw6SP/bBpCD+zACfX1qwXTTxLEq4i4ZrJ9qgXu3W jzwAn2Vkjhg9le7+Qu77+qr5cGXrJzWR =h5or -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 11:19:25 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 915587A1 for ; Sun, 23 Jun 2013 11:19:25 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE3C18E2 for ; Sun, 23 Jun 2013 11:19:24 +0000 (UTC) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id 7B40E35A3B9 for ; Sun, 23 Jun 2013 13:19:18 +0200 (CEST) Received: from mail-in-15.arcor-online.net (mail-in-15.arcor-online.net [151.189.21.55]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id 7D70728AC71 for ; Sun, 23 Jun 2013 13:19:18 +0200 (CEST) X-Greylist: Passed host: 94.217.99.168 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-15.arcor-online.net 1ECD21AB52F Received: from lorvorc.mips.inka.de (dslb-094-217-099-168.pools.arcor-ip.net [94.217.99.168]) by mail-in-15.arcor-online.net (Postfix) with ESMTPS id 1ECD21AB52F for ; Sun, 23 Jun 2013 13:19:17 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id r5NBJFux070306 for ; Sun, 23 Jun 2013 13:19:15 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id r5NBJF04070305 for freebsd-ports@freebsd.org; Sun, 23 Jun 2013 13:19:15 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Can not update png on 8.2-RELEASE-p9 amd64 Date: Sun, 23 Jun 2013 11:19:15 +0000 (UTC) Message-ID: References: <51C5735A.1090201@dehartog.nl> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:19:25 -0000 Hans de Hartog wrote: > Title says it all. WITH_PKGNG=yes. Error message: Support for 8.2-RELEASE has ended about a year ago. https://www.freebsd.org/security/unsupported.html -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 14:27:58 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8722B1EF for ; Sun, 23 Jun 2013 14:27:58 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qc0-x242.google.com (mail-qc0-x242.google.com [IPv6:2607:f8b0:400d:c01::242]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6ED1E87 for ; Sun, 23 Jun 2013 14:27:58 +0000 (UTC) Received: by mail-qc0-f194.google.com with SMTP id n1so3137658qcx.9 for ; Sun, 23 Jun 2013 07:27:57 -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:cc:content-type; bh=lzGlakmJw2pGmGMBuNWKb7y1Vtmy0LIwhVoq45XCvck=; b=CAUTLJ/jdyzj2wCS2fOTg7N6/mSlyFbHoO28MkUyci6wbkQZ82kXoZhZU9zp3UyB+U VdlHsEZhkkGqea6wBNoJ1w+MZ+ICT6TPY/wekcJR2n5RLUzZNxku6qnHuhXs1nk46psL Ly8o3PQNqxWURqS+uQCXiprVyq83CVGMP4UdxgGGxPu5BHoBc7Da0fxLwhj3v+nlWfdA 4804g0TqT/Vkl0sY1FKPiq9f5beskoQf3OiHOLI1Z8OFCQeWf2oiJlrF+SXz/w4AELkm gjFlXkPwpMjItQSupxGyRs20qh1QT6OtUoubCHfqFxvjnvbZBGWrFOvF/Ps3kDp84Yan pmcg== MIME-Version: 1.0 X-Received: by 10.49.12.145 with SMTP id y17mr23514346qeb.7.1371997676973; Sun, 23 Jun 2013 07:27:56 -0700 (PDT) Received: by 10.49.13.167 with HTTP; Sun, 23 Jun 2013 07:27:56 -0700 (PDT) Date: Sun, 23 Jun 2013 10:27:56 -0400 Message-ID: Subject: Re: net-mgmt/cflowd 2.1.b1 build failure From: Kim Culhan To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 14:27:58 -0000 On Mon, June 17, 2013 10:47 pm, Mark Felder wrote: > I just did a build of this in poudriere with no issues. I'd guess you > have a dirty build environment. Can you post the contents of your > make.conf? This build failure is happening on 2 machines running -current, r251377. >From the port Makefile: # Created by: Andreas Klemm # $FreeBSD: net-mgmt/cflowd/Makefile 313635 2013-03-08 11:32:11Z bapt $ We don't have a poudriere available for building ports. Tried sending a note to andreas@ the [non-obfuscated] address in the Makefile but it bounced. The build failure on both machines is: ../../classes/lib/.libs/libCfd.so: undefined reference to `yyFlexLexer::yywrap()' I don't think the problem is due to a dirty build environment, its just FreeBSD 10-current with nothing special in make.conf, do you have that available? thanks -kim From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 17:32:09 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0284C5B for ; Sun, 23 Jun 2013 17:32:09 +0000 (UTC) (envelope-from rpclark@tds.net) Received: from mail-gh0-x235.google.com (mail-gh0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id 872D316FC for ; Sun, 23 Jun 2013 17:32:09 +0000 (UTC) Received: by mail-gh0-f181.google.com with SMTP id z12so3110064ghb.12 for ; Sun, 23 Jun 2013 10:32:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=7HcVuVUsdN6WqAnV/wG8wAfJ7nQj8Q11y0I9h/OeAXc=; b=RcQhppCU07xHjiMdhjCJ291ZKHlT8MxBUa8iCpNO6CCuqP9EkkhjuPU65d/HIyzMGm 6V8nFrAzLNgq6GcFvA8wCLBYycKd7c6xdgbtMpdrbB0t2tx5YO88cF7dBL2DA8TAdCE9 AS4lyZT1YYfCCyxnCeBDTnwydefWV7JAcwl2S73f7cwPzBRkw4cU8NV592NhH45D66uR thSJC9Tmfzb2mfLxz0Oxdd1ivf8W4YrZBvb8KbPHJqSWJuv2fBw9dVhOaxp4yg7FFPoU j7co+k+RZavaEhfd7xU3LYNxy6zn0q2XWZffekhqThZHn3V85GuG91U4dPdQ5VQ2ZnF6 jGpg== X-Received: by 10.236.15.194 with SMTP id f42mr11389769yhf.104.1372008728969; Sun, 23 Jun 2013 10:32:08 -0700 (PDT) Received: from x2.largegray.org (h69-131-2-212.stmyga.broadband.dynamic.tds.net. [69.131.2.212]) by mx.google.com with ESMTPSA id e69sm24501962yhl.3.2013.06.23.10.32.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Jun 2013 10:32:08 -0700 (PDT) Date: Sun, 23 Jun 2013 13:32:06 -0400 From: Rob Clark To: vd@FreeBSD.org Subject: Re: hugin, libboost_thread.so not found Message-Id: <20130623133206.b5f50b5a.rpclark@tds.net> In-Reply-To: <20130623073543.GA28451@hag.hw.v5d.org> References: <20130622033016.72bad862.rpclark@tds.net> <20130623073543.GA28451@hag.hw.v5d.org> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; i386-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl1mcHUIhPU0tCwHmZVUc9OaJrj469P2iyor5AECSwVccoD5krP2mLIqGqmr3qcgu5Kw5MR Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 17:32:09 -0000 On Sun, 23 Jun 2013 10:35:43 +0300 Vasil Dimov wrote: > On Sat, Jun 22, 2013 at 03:30:16 -0400, Rob Clark wrote: > > Cannot get hugin to work, > > I get the following: > > > > $ hugin > > /libexec/ld-elf.so.1: Shared object "libboost_thread.so"not > > found, required by "hugin" > > $ > [...] > > Hi, what is the output of the following commands, when executed in your > environment: > > ldd `which hugin` > > ls -l /usr/local/lib/libboost* > > ls -l /var/db/pkg/, or if you are using pkg(8), then: > pkg info > > -- > Vasil Dimov > gro.DSBeerF@dv > % > Without fools there would be no wisdom. Thank you Vasil, hugin is now working thanks to your response. Here's what I did: Upon issuing the first command, ldd `which hugin` I learned that several deps were missing: libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) libboost_thread.so => not found (0x0) libboost_date_time.so => not found (0x0) libboost_regex.so => not found (0x0) libboost_filesystem.so => not found (0x0) libboost_iostreams.so => not found (0x0) libboost_system.so => not found (0x0) libboost_signals.so => not found (0x0) So, the second command: ls -l /usr/local/lib/libboost* did not give any results, not found, etc. These suggestions put me on the right track. So, in /usr/ports/graphics/hugin, I did: # make missing devel/boost-libs java/diablo-jdk16 devel/boost-jam java/javavmwrapper java/java-zoneinfo # I then did: make deinstall then make install clean, which worked without issue. ===> Registering installation for hugin-2011.4.0_1 ===> Cleaning for boost-libs-1.48.0 ===> Cleaning for boost-jam-1.48.0 ===> Cleaning for hugin-2011.4.0_1 I am still baffled as to how hugin installed with missing deps. Oh well, it's working now :-). Thank you for the quick response and putting me on 'the right track'. Rob -- Rob Clark From owner-freebsd-ports@FreeBSD.ORG Sun Jun 23 20:22:52 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D62D1AF for ; Sun, 23 Jun 2013 20:22:52 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id B42E51C0F for ; Sun, 23 Jun 2013 20:22:51 +0000 (UTC) Received: (qmail 80718 invoked by uid 89); 23 Jun 2013 20:16:08 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.183.247) by mail.grem.de with ESMTPA; 23 Jun 2013 20:16:08 -0000 Date: Sun, 23 Jun 2013 22:16:07 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130623221607.7e1e7754@bsd64.grem.de> In-Reply-To: <20130623080905.17f77d71@bsd64.grem.de> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130623080905.17f77d71@bsd64.grem.de> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 20:22:52 -0000 On Sun, 23 Jun 2013 08:09:05 +0200 Michael Gmelin wrote: > On Sat, 22 Jun 2013 00:27:53 +0200 > Dimitry Andric wrote: > > > On Jun 21, 2013, at 22:07, Dimitry Andric wrote: > > > On Jun 13, 2013, at 03:15, Michael Gmelin wrote: > > ... > > >> - system clang + std=c++11 + system libc++: Build fails, due to > > >> a dependency (databases/db5) not building with those flags. It > > >> looks like a problem in libc++ to me, but I didn't have much time > > >> to investigate. It might be one of those things that might just > > >> go away after a while. > > > > > > No, db5 does not build because it is redefining a C++11 standard > > > library identifier, atomic_init(). It should probably prefix all > > > its internal defines with 'db_', to avoid collisions. The > > > db-5.3.21/src/dbinc/atomic.h file is already patched by our port > > > to avoid one such collision, but it is probably necessary to do > > > this again for any other identifiers that are used either by C++, > > > or are compiler builtins. > > > > Attached is a diff to fix the db5 port, so it correctly builds with > > CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please > > have a look at it? > > > > After db5 (compiled with libc++) was installed, I retried devel/ice > > again, but the Slice/keyword test failed in exactly the same way. > > If you comment out the "delete factoryTable" line in > > cpp/src/Ice/FactoryTableInit.cpp, the Slice/keyword test does > > succeed. > > > > Many other tests after that also go well, and the next failure I get > > was: > > > > *** running tests 39/83 > > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp *** > > configuration: Default *** test started: 06/22/13 00:20:11 > > starting server #1... ok > > starting server #2... Traceback (most recent call last): > > File > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp/run.py", > > line 41, in serverProc.append(TestUtil.startServer(server, > > "%d" % i , adapter="McastTestAdapter")) File > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > > line 1396, in startServer return spawnServer(cmd, env = env, adapter > > = adapter, count = count, echo = echo,lang=config.lang,mx=config.mx) > > File > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > > line 1131, in spawnServer server.expect("%s ready\n" % adapter) File > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/Expect.py", > > line 394, in expect raise e Expect.TIMEOUT: timeout exceeded in > > match pattern: "McastTestAdapter ready\n" buffer: "ControlAdapter > > ready Network.cpp:1701: Ice::SocketException: socket exception: > > Address already in use " > > > > ('test > > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp > > failed with exit status', 256) > > > > Whatever the source of this problem is, it is not very likely that > > is caused by a compiler or C++ library issue, but more likely some > > unexpected API change in sockets. > > > > -Dimitry > > Hi Dimitry, > > I've been able to analyze issue further and developed a fix (make > factoryTable's lifetime dependant on the lifetime of generated _Init > classes). I filed a bug report upstream: > > http://www.zeroc.com/forums/bug-reports/6030-ice-3-5-0-slice2cpp-generated-code-relies-static-initialization-order-crash.html#post26001 > > The second issue is a little bit more tricky. Since I was building the > port in a jail, the UDP based unit test didn't run and it didn't > notice it fail. Therefore it's not limited to CURRENT and, as it > turns out, it is a kernel bug. > > Digging a little bit deeper into the problem I noticed that there > seems to be a multicast problem in the kernel. Usually setting > SO_REUSEADDR on a multicast address should implicitly set > SO_REUSEPORT as well. Staring at the kernel code this only seems to > work on the currently created socket, but the cached flag of already > listening multicast sockets is not retrieved correctly, which makes > me believe that the cached flag is initialized correctly when > creating it. I think that this problem might have been introduced a > while ago in or after revision 227428: > > http://svnweb.freebsd.org/base?view=revision&revision=227428 > > Which MFC'd 227207 > > Which says: > > "Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid > inp_socket->so_options dereference when we may not acquire the lock on > the inpcb." > > I did some testing using a small test program that listened to a > multicast address and noticed: > - First invocation SO_REUSEADDR, second invocation SO_REUSEADDR > => fail > - First invocation SO_REUSEADDR, second invocation SO_REUSEPORT > => fail > - First invocation SO_REUSEPORT, second invocation SO_REUSEADDR > => success > - First invocation SO_REUSEPORT, second invocation SO_REUSEPORT > => success > > My gut feeling tells me that the code used to set the correct values > for inp_flags2 only works when setsockopt is called after the socket > has been bound and testing verified that this is actually the case. > Adding an additional setsockopt call after calling bind makes things > work as expected. For comparison I also tested in a VM running > ancient 7.x, where things worked as expected. > > So... if this was just about this port, the obvious fix would be > patching devel/ice to use SO_REUSEPORT explicitly for multicast (which > actually makes that unit test run ok), but this seems more like an > issue that really needs to be fixed on a system level. Should I open a > PR, or can you take it from here? > > Cheers, > Michael > > p.s. - I attached the C program I used for testing and demonstrating > the problem: > > [user@bsd64 /tmp]$ cc -o multicast multicast.c > [user@bsd64 /tmp]$ ./multicast reuseaddr & > [1] 9040 > [user@bsd64 /tmp]$ ./multicast reuseaddr > binding datagram socket: Address already in use > [user@bsd64 /tmp]$ killall multicast > ... > [user@bsd64 /tmp]$ ./multicast reuseport & > [1] 9093 > [user@bsd64 /tmp]$ ./multicast reuseaddr & > [2] 9098 > [user@bsd64 /tmp]$ ./multicast reuseaddr & > [3] 9107 > [user@bsd64 /tmp]$ binding datagram socket: Address already in use > [user@bsd64 /tmp]$ killall multicast > ... > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > [1] 9132 > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > [2] 9135 > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > [3] 9136 > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > [4] 9137 > [user@bsd64 /tmp]$ ./multicast reuseport & > [5] 9140 > [user@bsd64 /tmp]$ ./multicast reuseaddr & > [6] 9181 > [user@bsd64 /tmp]$ ./multicast reuseaddr & > [7] 9184 > [user@bsd64 /tmp]$ binding datagram socket: Address already in use > > I took a closer look and this actually makes a lot of sense. The cached value of the flags is set in ip_ctloutput when setsockopt is called, the part controlling automatic setting of SO_REUSEPORT is (from sys/netinet/ip_output.c): switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(inp); if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { if ((so->so_options & (SO_REUSEADDR | SO_REUSEPORT)) != 0) inp->inp_flags2 |= INP_REUSEPORT; else inp->inp_flags2 &= ~INP_REUSEPORT; } INP_WUNLOCK(inp); error = 0; This cannot work though, since at the point setsockopt is called, the address is not known and IN_MULTICAST won't evaluate as true. The address is only known once bind is executed. That's why setting the option after the call to bind works. It still has to be set before bind is called, since bind uses the actual information at the point of initialization as well (or set SO_REUSEPORT to begin with). I'll file a bug report. Cheers, Michael -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 00:18:45 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDF479FD for ; Mon, 24 Jun 2013 00:18:45 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 118CA135B for ; Mon, 24 Jun 2013 00:18:44 +0000 (UTC) Received: (qmail 83474 invoked by uid 89); 24 Jun 2013 00:18:43 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.183.247) by mail.grem.de with ESMTPA; 24 Jun 2013 00:18:43 -0000 Date: Mon, 24 Jun 2013 02:18:42 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130624021842.66888fe4@bsd64.grem.de> In-Reply-To: <20130623221607.7e1e7754@bsd64.grem.de> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130623080905.17f77d71@bsd64.grem.de> <20130623221607.7e1e7754@bsd64.grem.de> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 00:18:45 -0000 On Sun, 23 Jun 2013 22:16:07 +0200 Michael Gmelin wrote: > On Sun, 23 Jun 2013 08:09:05 +0200 > Michael Gmelin wrote: > > > On Sat, 22 Jun 2013 00:27:53 +0200 > > Dimitry Andric wrote: > > > > > On Jun 21, 2013, at 22:07, Dimitry Andric wrote: > > > > On Jun 13, 2013, at 03:15, Michael Gmelin > > > > wrote: > > > ... > > > >> - system clang + std=c++11 + system libc++: Build fails, due > > > >> to a dependency (databases/db5) not building with those flags. > > > >> It looks like a problem in libc++ to me, but I didn't have > > > >> much time to investigate. It might be one of those things that > > > >> might just go away after a while. > > > > > > > > No, db5 does not build because it is redefining a C++11 standard > > > > library identifier, atomic_init(). It should probably prefix > > > > all its internal defines with 'db_', to avoid collisions. The > > > > db-5.3.21/src/dbinc/atomic.h file is already patched by our port > > > > to avoid one such collision, but it is probably necessary to do > > > > this again for any other identifiers that are used either by > > > > C++, or are compiler builtins. > > > > > > Attached is a diff to fix the db5 port, so it correctly builds > > > with CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you > > > please have a look at it? > > > > > > After db5 (compiled with libc++) was installed, I retried > > > devel/ice again, but the Slice/keyword test failed in exactly the > > > same way. If you comment out the "delete factoryTable" line in > > > cpp/src/Ice/FactoryTableInit.cpp, the Slice/keyword test does > > > succeed. > > > > > > Many other tests after that also go well, and the next failure I > > > get was: > > > > > > *** running tests 39/83 > > > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp > > > *** configuration: Default *** test started: 06/22/13 00:20:11 > > > starting server #1... ok > > > starting server #2... Traceback (most recent call last): > > > File > > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp/run.py", > > > line 41, in > > > serverProc.append(TestUtil.startServer(server, "%d" % i , > > > adapter="McastTestAdapter")) File > > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > > > line 1396, in startServer return spawnServer(cmd, env = env, > > > adapter = adapter, count = count, echo = > > > echo,lang=config.lang,mx=config.mx) File > > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/TestUtil.py", > > > line 1131, in spawnServer server.expect("%s ready\n" % adapter) > > > File > > > "/usr/work/usr/ports/devel/ice/work/Ice-3.5.0/scripts/Expect.py", > > > line 394, in expect raise e Expect.TIMEOUT: timeout exceeded in > > > match pattern: "McastTestAdapter ready\n" buffer: "ControlAdapter > > > ready Network.cpp:1701: Ice::SocketException: socket exception: > > > Address already in use " > > > > > > ('test > > > in /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Ice/udp > > > failed with exit status', 256) > > > > > > Whatever the source of this problem is, it is not very likely that > > > is caused by a compiler or C++ library issue, but more likely some > > > unexpected API change in sockets. > > > > > > -Dimitry > > > > Hi Dimitry, > > > > I've been able to analyze issue further and developed a fix (make > > factoryTable's lifetime dependant on the lifetime of generated _Init > > classes). I filed a bug report upstream: > > > > http://www.zeroc.com/forums/bug-reports/6030-ice-3-5-0-slice2cpp-generated-code-relies-static-initialization-order-crash.html#post26001 > > > > The second issue is a little bit more tricky. Since I was building > > the port in a jail, the UDP based unit test didn't run and it didn't > > notice it fail. Therefore it's not limited to CURRENT and, as it > > turns out, it is a kernel bug. > > > > Digging a little bit deeper into the problem I noticed that there > > seems to be a multicast problem in the kernel. Usually setting > > SO_REUSEADDR on a multicast address should implicitly set > > SO_REUSEPORT as well. Staring at the kernel code this only seems to > > work on the currently created socket, but the cached flag of already > > listening multicast sockets is not retrieved correctly, which makes > > me believe that the cached flag is initialized correctly when > > creating it. I think that this problem might have been introduced a > > while ago in or after revision 227428: > > > > http://svnweb.freebsd.org/base?view=revision&revision=227428 > > > > Which MFC'd 227207 > > > > Which says: > > > > "Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid > > inp_socket->so_options dereference when we may not acquire the lock > > on the inpcb." > > > > I did some testing using a small test program that listened to a > > multicast address and noticed: > > - First invocation SO_REUSEADDR, second invocation SO_REUSEADDR > > => fail > > - First invocation SO_REUSEADDR, second invocation SO_REUSEPORT > > => fail > > - First invocation SO_REUSEPORT, second invocation SO_REUSEADDR > > => success > > - First invocation SO_REUSEPORT, second invocation SO_REUSEPORT > > => success > > > > My gut feeling tells me that the code used to set the correct values > > for inp_flags2 only works when setsockopt is called after the socket > > has been bound and testing verified that this is actually the case. > > Adding an additional setsockopt call after calling bind makes things > > work as expected. For comparison I also tested in a VM running > > ancient 7.x, where things worked as expected. > > > > So... if this was just about this port, the obvious fix would be > > patching devel/ice to use SO_REUSEPORT explicitly for multicast > > (which actually makes that unit test run ok), but this seems more > > like an issue that really needs to be fixed on a system level. > > Should I open a PR, or can you take it from here? > > > > Cheers, > > Michael > > > > p.s. - I attached the C program I used for testing and demonstrating > > the problem: > > > > [user@bsd64 /tmp]$ cc -o multicast multicast.c > > [user@bsd64 /tmp]$ ./multicast reuseaddr & > > [1] 9040 > > [user@bsd64 /tmp]$ ./multicast reuseaddr > > binding datagram socket: Address already in use > > [user@bsd64 /tmp]$ killall multicast > > ... > > [user@bsd64 /tmp]$ ./multicast reuseport & > > [1] 9093 > > [user@bsd64 /tmp]$ ./multicast reuseaddr & > > [2] 9098 > > [user@bsd64 /tmp]$ ./multicast reuseaddr & > > [3] 9107 > > [user@bsd64 /tmp]$ binding datagram socket: Address already in use > > [user@bsd64 /tmp]$ killall multicast > > ... > > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > > [1] 9132 > > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > > [2] 9135 > > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > > [3] 9136 > > [user@bsd64 /tmp]$ ./multicast reuseaddrafter & > > [4] 9137 > > [user@bsd64 /tmp]$ ./multicast reuseport & > > [5] 9140 > > [user@bsd64 /tmp]$ ./multicast reuseaddr & > > [6] 9181 > > [user@bsd64 /tmp]$ ./multicast reuseaddr & > > [7] 9184 > > [user@bsd64 /tmp]$ binding datagram socket: Address already in use > > > > > > I took a closer look and this actually makes a lot of sense. > > The cached value of the flags is set in ip_ctloutput when setsockopt > is called, the part controlling automatic setting of SO_REUSEPORT is > (from sys/netinet/ip_output.c): > > switch (sopt->sopt_name) { > case SO_REUSEADDR: > INP_WLOCK(inp); > if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) > { if ((so->so_options & > (SO_REUSEADDR | SO_REUSEPORT)) != > 0) inp->inp_flags2 |= INP_REUSEPORT; > else > inp->inp_flags2 &= > ~INP_REUSEPORT; } > INP_WUNLOCK(inp); > error = 0; > > This cannot work though, since at the point setsockopt is called, the > address is not known and IN_MULTICAST won't evaluate as true. The > address is only known once bind is executed. That's why setting the > option after the call to bind works. It still has to be set before > bind is called, since bind uses the actual information at the point > of initialization as well (or set SO_REUSEPORT to begin with). > > I'll file a bug report. > > Cheers, > Michael > Filed a PR including a patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 02:27:55 2013 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id CB8F7444; Mon, 24 Jun 2013 02:27:55 +0000 (UTC) Date: Mon, 24 Jun 2013 02:27:55 +0000 From: Alexey Dokuchaev To: Pawel Pekala Subject: Re: LICENSE and PORTREVISION bump Message-ID: <20130624022755.GA50310@FreeBSD.org> References: <51BC4153.9010809@passap.ru> <20130615131816.4bdf8eac@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130615131816.4bdf8eac@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 02:27:55 -0000 On Sat, Jun 15, 2013 at 01:18:16PM +0200, Pawel Pekala wrote: > Dnia 2013-06-15, o godz. 14:26:27 > Boris Samorodov napisał(a): > >The FreeBSD Porters Book claims that a PORTREVISION should be bumped > >if a significant change is made to a port. > > > >My question is "Should a PORTREVISION be bumped while adding a > >license?". > > > >I used to bump PORTREVISION but what do you think? > > License framework installs files in > ${PREFIX}/share/licenses/${PKGNAME}/ so this is a plist change. Right, it is a plist change, so what? :-) There is a certain diversity among folks here: some bump PORTREVISION even when they apply pretty much no-op patch (like fixing the build on some exotic arch), some (myself included) only bump it when absolutely necessary: if the user installed package (before the change) is somehow broken. User probably does not care if the port comes with bundled LICENSE or not. In fact, I do not bump PORTREVISION when I add documentation or something, esp. to the ports that take long times to build: I hate to rebuild things, and I think it's quite rude to force users into rebuilding their perfectly fine package just because we forgot to add a bunch of non-essential docs. That said, the rule of "plist change" makes sense when previously plist was wrong; this would mean that user's currently installed package indeed has a problem and would not deinstall cleanly, etc. Or PORTREVISION is good if you fix some annoying/critical runtime bug. But when adding just couple of text files or LICENSE -- why bother? ./danfe From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 08:10:24 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E38883A0; Mon, 24 Jun 2013 08:10:24 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 791C515DF; Mon, 24 Jun 2013 08:10:24 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e10so6008561qcy.41 for ; Mon, 24 Jun 2013 01:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=6lhPowGeM8eYHuIES+ajajLqY5wJfubElj3jahmqlVo=; b=XdklFyfpdYOaREXQjfwJUU3UjBmEl/fxT4DfvjMUJd3Ta8kMsb85UzRLkVUk5fwDxL WFKNdsJOeSCmXguzHeBz1jvUEiiRNhNVTIbyKLB44MxNacdwPSBgJv2k6lQJSp0Ddh93 jdrKru0aDQcKFVc+kNbKSUaTtFECErHnofD2cq7UexuZPcKK+if1dWLzByb6jxiWg91d AgKCiMFCmntKBBXNrXTcdvcwmysjT3eQxwSk4bU3hV+k3iEVFonpLwyzDV0Wqqau+66K 095ils9J+UcihREsNFu9riJK0wGrJgZYKleCi0yF3B/3k1c0Tsmlf9Xo9ZHKCj4Abgnh J8Aw== MIME-Version: 1.0 X-Received: by 10.224.11.6 with SMTP id r6mr25813422qar.65.1372061424055; Mon, 24 Jun 2013 01:10:24 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.49.35.84 with HTTP; Mon, 24 Jun 2013 01:10:23 -0700 (PDT) Date: Mon, 24 Jun 2013 10:10:23 +0200 X-Google-Sender-Auth: R4phK5OQmRx6CLOHXlwAkiGRX8o Message-ID: Subject: [devel/urjtag] build problem From: CeDeROM To: freebsd-ports , ports@freebsd.org Content-Type: multipart/mixed; boundary=001a11c2cc98ca7d3204dfe1f183 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 08:10:25 -0000 --001a11c2cc98ca7d3204dfe1f183 Content-Type: text/plain; charset=UTF-8 ===> License GPLv2 accepted by the user ===> Found saved configuration for urjtag-0.10_3 => urjtag-0.10.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch http://heanet.dl.sourceforge.net/project/urjtag/urjtag/0.10/urjtag-0.10.tar.bz2 urjtag-0.10.tar.bz2 100% of 937 kB 1331 kBps ===> Fetching all distfiles required by urjtag-0.10_3 for building ===> Extracting for urjtag-0.10_3 => SHA256 Checksum OK for urjtag-0.10.tar.bz2. ===> Patching for urjtag-0.10_3 ===> Applying extra patch /mnt/stuff/usr/ports/devel/urjtag/files/extra-patch-usb ===> urjtag-0.10_3 depends on executable: flex - found ===> urjtag-0.10_3 depends on executable: gmake - found ===> urjtag-0.10_3 depends on shared library: ftdi - found ===> urjtag-0.10_3 depends on shared library: intl - found ===> Configuring for urjtag-0.10_3 configure: loading site script /usr/ports/Templates/config.site checking code revision... from ChangeLog: 1502 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether NLS is requested... yes checking for msgfmt... /usr/local/bin/msgfmt checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for msgmerge... /usr/local/bin/msgmerge checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... gcc3 checking build system type... amd64-portbld-freebsd9.1 checking host system type... amd64-portbld-freebsd9.1 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking whether NLS is requested... yes checking for GNU gettext in libc... no checking for iconv... yes checking how to link with libiconv... /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... (cached) none needed checking dependency style of cc... (cached) gcc3 checking for ranlib... ranlib checking for bison... no checking for byacc... byacc checking for library containing ioperm... no checking for library containing i386_set_ioperm... no checking for getline... yes checking for getdelim... yes checking for swprintf... yes checking for clock_gettime... (cached) yes checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... (cached) /usr/bin/egrep checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking linux/ppdev.h usability... no checking linux/ppdev.h presence... no checking for linux/ppdev.h... no checking dev/ppbus/ppi.h usability... yes checking dev/ppbus/ppi.h presence... yes checking for dev/ppbus/ppi.h... yes checking stropts.h usability... no checking stropts.h presence... no checking for stropts.h... no checking for wchar.h... (cached) yes checking for a readline compatible library... -lreadline checking readline.h usability... no checking readline.h presence... no checking for readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking whether readline supports history... yes checking history.h usability... no checking history.h presence... no checking for history.h... no checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking whether readline supports completion... yes checking for libusb-config... no checking for usb_find_devices... no configure: WARNING: *** libusb not detected. No support for USB JTAG cables via libusb. checking for libftdi-config... /usr/local/bin/libftdi-config checking for ftdi_usb_open... yes checking for FT_OpenEx in -lftd2xx... no configure: WARNING: *** libftd2xx not found. No support for FTDI-based USB JTAG cables via libftd2xx. checking for flex... /usr/local/bin/flex checking lex output file root... configure: error: cannot find output from /usr/local/bin/flex; giving up ===> Script "configure" failed unexpectedly. Please report the problem to ports@FreeBSD.org [maintainer] and attach the "/mnt/stuff/usr/ports/devel/urjtag/work/urjtag-0.10/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/sbin/pkg_info -Ea). *** [do-configure] Error code 1 Stop in /mnt/stuff/usr/ports/devel/urjtag. *** [build] Error code 1 Stop in /mnt/stuff/usr/ports/devel/urjtag. # flex -V flex version 2.5.4 # uname -a FreeBSD mercury 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Sun May 19 21:04:57 CEST 2013 root@mercury:/usr/obj/usr/src/sys/CeDeROM_FreeBSD_9.1 amd64 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --001a11c2cc98ca7d3204dfe1f183 Content-Type: application/octet-stream; name="config.log" Content-Disposition: attachment; filename="config.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hibdx7lz0 VGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNlZCBieSBjb21waWxlcnMgd2hp bGUKcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcgaWYgY29uZmlndXJlIG1ha2Vz IGEgbWlzdGFrZS4KCkl0IHdhcyBjcmVhdGVkIGJ5IFVySlRBRyBjb25maWd1cmUgMC4xMCwgd2hp Y2ggd2FzCmdlbmVyYXRlZCBieSBHTlUgQXV0b2NvbmYgMi42MS4gIEludm9jYXRpb24gY29tbWFu ZCBsaW5lIHdhcwoKICAkIC4vY29uZmlndXJlIC0td2l0aC1saWJ1c2IgLS13aXRoLWxpYmZ0ZGkg LS1wcmVmaXg9L3Vzci9sb2NhbCAtLW1hbmRpcj0vdXNyL2xvY2FsL21hbiAtLWluZm9kaXI9L3Vz ci9sb2NhbC9pbmZvLyAtLWJ1aWxkPWFtZDY0LXBvcnRibGQtZnJlZWJzZDkuMQoKIyMgLS0tLS0t LS0tICMjCiMjIFBsYXRmb3JtLiAjIwojIyAtLS0tLS0tLS0gIyMKCmhvc3RuYW1lID0gbWVyY3Vy eS5yZC50cC5wbAp1bmFtZSAtbSA9IGFtZDY0CnVuYW1lIC1yID0gOS4xLVJFTEVBU0UtcDMKdW5h bWUgLXMgPSBGcmVlQlNECnVuYW1lIC12ID0gRnJlZUJTRCA5LjEtUkVMRUFTRS1wMyAjMDogU3Vu IE1heSAxOSAyMTowNDo1NyBDRVNUIDIwMTMgICAgIHJvb3RAbWVyY3VyeS5yZC50cC5wbDovdXNy L29iai91c3Ivc3JjL3N5cy9DZURlUk9NX0ZyZWVCU0RfOS4xIAoKL3Vzci9iaW4vdW5hbWUgLXAg PSBhbWQ2NAovYmluL3VuYW1lIC1YICAgICA9IHVua25vd24KCi9iaW4vYXJjaCAgICAgICAgICAg ICAgPSB1bmtub3duCi91c3IvYmluL2FyY2ggLWsgICAgICAgPSB1bmtub3duCi91c3IvY29udmV4 L2dldHN5c2luZm8gPSB1bmtub3duCi91c3IvYmluL2hvc3RpbmZvICAgICAgPSB1bmtub3duCi9i aW4vbWFjaGluZSAgICAgICAgICAgPSB1bmtub3duCi91c3IvYmluL29zbGV2ZWwgICAgICAgPSB1 bmtub3duCi9iaW4vdW5pdmVyc2UgICAgICAgICAgPSB1bmtub3duCgpQQVRIOiAvc2JpbgpQQVRI OiAvYmluClBBVEg6IC91c3Ivc2JpbgpQQVRIOiAvdXNyL2JpbgpQQVRIOiAvdXNyL2dhbWVzClBB VEg6IC91c3IvbG9jYWwvc2JpbgpQQVRIOiAvdXNyL2xvY2FsL2JpbgpQQVRIOiAvcm9vdC9iaW4K CgojIyAtLS0tLS0tLS0tLSAjIwojIyBDb3JlIHRlc3RzLiAjIwojIyAtLS0tLS0tLS0tLSAjIwoK Y29uZmlndXJlOjE4NTQ6IGxvYWRpbmcgc2l0ZSBzY3JpcHQgL3Vzci9wb3J0cy9UZW1wbGF0ZXMv Y29uZmlnLnNpdGUKfCAjICRGcmVlQlNEOiBUZW1wbGF0ZXMvY29uZmlnLnNpdGUgMzE5NDgzIDIw MTMtMDUtMzEgMTA6NTM6MDRaIGJkcmV3ZXJ5ICQKfCAjIFBhdGgKfCA6ICR7YWNfY3ZfcGF0aF9H WklQPS91c3IvYmluL2d6aXB9CnwgOiAke2FjX2N2X3BhdGhfQlpJUDI9L3Vzci9iaW4vYnppcDJ9 CnwgOiAke2FjX2N2X3BhdGhfTUtURU1QX0NPTU1BTkQ9L3Vzci9iaW4vbWt0ZW1wfQp8IDogJHth Y19jdl9wYXRoX1NFRD0vdXNyL2Jpbi9zZWR9CnwgOiAke2FjX2N2X3BhdGhfaW5zdGFsbD0vdXNy L2Jpbi9pbnN0YWxsfQp8IDogJHthY19jdl9wYXRoX0dSRVA9L3Vzci9iaW4vZ3JlcH0KfCA6ICR7 YWNfY3ZfcGF0aF9FR1JFUD0vdXNyL2Jpbi9lZ3JlcH0KfCA6ICR7YWNfY3ZfcGF0aF9GR1JFUD0v dXNyL2Jpbi9mZ3JlcH0KfCA6ICR7YWNfY3ZfcGF0aF9ta2Rpcj0vYmluL21rZGlyfQp8IDogJHth bV9jdl9wcm9nX3Rhcl91c3Rhcj0vdXNyL2Jpbi90YXJ9CnwgOiAke2FjX2N2X3Byb2dfQVdLPS91 c3IvYmluL2F3a30KfCA6ICR7YWNfY3ZfcHJvZ19TRUQ9L3Vzci9iaW4vc2VkfQp8IDogJHtjbF9j dl9wcm9nX2NwPScvYmluL2NwIC1wJ30KfCA6ICR7Y2xfY3ZfcHJvZ19MTj0vYmluL2xufQp8IDog JHtsdF9jdl9wYXRoX01BR0lDX0NNRD0vdXNyL2Jpbi9maWxlfQp8IAp8ICMgSGVhZGVycwp8IDog JHthY19jdl9oZWFkZXJfc3RkYz15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfcGFyYW1faD15 ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRl cl9zeXNfc3RhdF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N0ZGxpYl9oPXllc30KfCA6ICR7 YWNfY3ZfaGVhZGVyX3N0cmluZ3NfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zdHJpbmdfaD15 ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9tZW1vcnlfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9p bnR0eXBlc19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N0ZGludF9oPXllc30KfCA6ICR7YWNf Y3ZfaGVhZGVyX3VuaXN0ZF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19o PW5vfQp8IDogJHthY19jdl9oZWFkZXJfd2NoYXJfaD15ZXN9CnwgOiAke2dsX2N2X2hlYWRlcl93 Y2hhcl9oX2NvcnJlY3RfaW5saW5lPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX2FsbG9jYV9oPW5v fQp8IDogJHthY19jdl9oZWFkZXJfc3lzX3RpbWVzX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJf c3lzX3RpbWVfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfc29ja2V0X2g9eWVzfQp8IDog JHthY19jdl9oZWFkZXJfc3lzX2ZjbnRsX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3lzX3Nl bGVjdF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX2RpcmVudF9oPXllc30KfCA6ICR7YWNfY3Zf aGVhZGVyX2RsZmNuX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfcHdkX2g9eWVzfQp8IDogJHth Y19jdl9oZWFkZXJfc2VhcmNoX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfY3R5cGVfaD15ZXN9 CnwgOiAke2FjX2N2X2hlYWRlcl9hcnBhX2luZXRfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9t YXRoX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfbmV0ZGJfaD15ZXN9CnwgOiAke2FjX2N2X2hl YWRlcl9uZXRpbmV0X2luX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfZXJybm9faD15ZXN9Cnwg OiAke2FjX2N2X2hlYWRlcl9nZXRvcHRfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfbW1h bl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3NpZ25hbF9oPXllc30KfCA6ICR7YWNfY3ZfaGVh ZGVyX3N0ZGRlZl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N0ZGlvX2g9eWVzfQp8IDogJHth Y19jdl9oZWFkZXJfdGltZV9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3djdHlwZV9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX2xpbWl0c19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N0ZGJv b2xfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zcGF3bl9oPXllc30KfCA6ICR7YWNfY3ZfaGVh ZGVyX25ldF9pZl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX25ldF9pZl9tZWRpYV9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX3NjaGVkX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3lzX3dh aXRfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl91Y29udGV4dF9oPXllc30KfCAKfCA6ICR7YWNf Y3ZfaGVhZGVyX2RsX2g9bm99CnwgOiAke2FjX2N2X2hlYWRlcl9tYWxsb2NfaD1ub30KfCA6ICR7 YWNfY3ZfaGVhZGVyX2J5dGVzd2FwX2g9bm99CnwgOiAke2FjX2N2X2hlYWRlcl92Zm9ya19oPW5v fQp8IDogJHthY19jdl9oZWFkZXJfcmFuZG9tX2g9bm99CnwgOiAke2FjX2N2X2hlYWRlcl9hcmd6 X2g9bm99CnwgCnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbWVtbWVtPXllc30KfCA6ICR7Z2xf Y3ZfaGF2ZV9yYXdfZGVjbF9tZW1jcHk9bm99CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbWVt cmNocj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcmF3bWVtY2hyPXllc30KfCA6ICR7 Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHBjcHk9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3N0cG5jcHk9eWVzfQp8ICMgVGhpcyBhcHBlYXJzIGluIEZyZWVCU0QgMTAgZG8gbm90IGNhY2hl IGl0Lgp8ICM6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJjaHJudWw9eWVzfQp8IDogJHtnbF9j dl9oYXZlX3Jhd19kZWNsX3N0cmR1cD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3Ry bmNhdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3RybmR1cD15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfc3Rybmxlbj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf c3RycGJyaz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3Ryc2VwPXllc30KfCA6ICR7 Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJjYXNlc3RyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9zdHJ0b2tfcj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3Ryc2lnbmFsPXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJ2ZXJzY21wPW5vfQp8IAp8ICMgVHlwZQp8 IDogJHthY19jdl90eXBlX2xvbmdfbG9uZ19pbnQ9eWVzfQp8IDogJHthY19jdl90eXBlX3Vuc2ln bmVkX2xvbmdfbG9uZ19pbnQ9eWVzfQp8IDogJHthY19jdl90eXBlX3Vuc2lnbmVkX2xvbmdfbG9u Zz15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdW5zaWduZWRfbG9uZz15ZXN9CnwgOiAke2FjX2N2X3R5 cGVfbG9uZz15ZXN9CnwgOiAke2FjX2N2X3R5cGVfc2l6ZV90PXllc30KfCA6ICR7YWNfY3ZfdHlw ZV9zc2l6ZV90PXllc30KfCA6ICR7YWNfY3ZfdHlwZV9pbnQzMl90PXllc30KfCA6ICR7YWNfY3Zf dHlwZV91X2ludDMyX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX2ludDE2X3Q9eWVzfQp8IDogJHth Y19jdl90eXBlX3VfaW50MTZfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdV9pbnQ4X3Q9eWVzfQp8 IDogJHthY19jdl90eXBlX3VfbG9uZz15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdV9pbnQ9eWVzfQp8 IDogJHthY19jdl90eXBlX3Vfc2hvcnQ9eWVzfQp8IDogJHthY19jdl90eXBlX3VfY2hhcj15ZXN9 CnwgOiAke2FjX2N2X3R5cGVfb2ZmX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX2NoYXJfcD15ZXN9 CnwgOiAke2FjX2N2X3R5cGVfdW5zaWduZWRfaW50PXllc30KfCA6ICR7YWNfY3ZfdHlwZV9pbnQ9 eWVzfQp8IDogJHthY19jdl90eXBlX3Vuc2lnbmVkX3Nob3J0PXllc30KfCA6ICR7YWNfY3ZfdHlw ZV9zaG9ydD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdW5zaWduZWRfY2hhcj15ZXN9CnwgOiAke2Fj X2N2X3R5cGVfY2hhcj15ZXN9CnwgOiAke2FjX2N2X3R5cGVfcGlkX3Q9eWVzfQp8IDogJHthY19j dl90eXBlX25saW5rX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3Bvc2l4X3NwYXduYXR0cl90PXll c30KfCA6ICR7YWNfY3ZfdHlwZV9wb3NpeF9zcGF3bl9maWxlX2FjdGlvbnNfdD15ZXN9CnwgOiAk e2FjX2N2X3R5cGVfd2ludF90PXllc30KfCA6ICR7YWNfY3ZfdHlwZV93Y2hhcl90PXllc30KfCA6 ICR7YWNfY3ZfdHlwZV9pbnRtYXhfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfcHRyZGlmZl90PXll c30KfCA6ICR7YWNfY3ZfdHlwZV9tYnN0YXRlX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX19Cb29s PXllc30KfCA6ICR7YWNfY3ZfdHlwZV9tb2RlX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3NpZ19h dG9taWNfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfc3RhY2tfdD15ZXN9CnwgOiAke2FjX2N2X3R5 cGVfdWlkX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3ZvbGF0aWxlX3NpZ19hdG9taWNfdD15ZXN9 CnwgCnwgOiAke2d0X2N2X2Nfd2ludF90PXllc30KfCA6ICR7Z3RfY3ZfY193Y2hhcl90PXllc30K fCA6ICR7Z2xfY3ZfdHlwZV93Y3R5cGVfdD15ZXN9CnwgOiAke2dsX2N2X3R5cGVfd2N0cmFuc190 PXllc30KfCA6ICR7Z3RfY3Zfc3NpemVfdD15ZXN9CnwgOiAke2dsX2N2X3NpemVfbWF4PXllc30K fCA6ICR7Z2xfY3Zfc2lnYWx0c3RhY2tfbG93X2Jhc2U9eWVzfQp8IAp8ICMgU3RydWN0CnwgOiAk e2FjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibGtzaXplPXllc30KfCA6ICR7YWNfY3ZfbWVt YmVyX3N0cnVjdF9zaWdhY3Rpb25fc2Ffc2lnYWN0aW9uPXllc30KfCA6ICR7YWNfY3Zfc3lzX3N0 YWNrX292ZXJmbG93X3dvcmtzPXllc30KfCA6ICR7Z2xfY3Zfc3lzX3N0cnVjdF90aW1lc3BlY19p bl90aW1lX2g9eWVzfQp8IDogJHtnbF9jdl9zeXNfc3RydWN0X3RpbWV2YWw9eWVzfQp8IAp8ICMg RnVuY3Rpb25zCnwgOiAke2FjX2N2X2Z1bmNfc2htZ2V0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19t bWFwPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRwYWdlc2l6ZT15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfbXVubWFwPXllc30KfCA6ICR7YWNfY3ZfZnVuY19tbG9jaz15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfbXVubG9jaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHJlYWQ9eWVzfQp8IDogJHthY19jdl9m dW5jX3B3cml0ZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3lzY29uZj15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc3RydG91bD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2VsZWN0PXllc30KfCA6ICR7YWNf Y3ZfZnVuY19nZXR1aWQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldHRpbWVvZmRheT15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfZ2V0cnVzYWdlPXllc30KfCA6ICR7YWNfY3ZfZnVuY19jbG9ja19nZXR0 aW1lPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHJlcnJvcj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNf c3RyZHVwPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHJjYXNlY21wPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19zbnByaW50Zj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcmFpc2U9eWVzfQp8IDogJHthY19j dl9mdW5jX3ZzbnByaW50Zj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbWVtbW92ZT15ZXN9CnwgOiAk e2FjX2N2X2Z1bmNfbWVtY3B5PXllc30KfCA6ICR7YWNfY3ZfZnVuY19tZW1jbXA9eWVzfQp8IDog JHthY19jdl9mdW5jX2dldG9wdD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfZ2V0Y3dkPXllc30KfCA6 ICR7YWNfY3ZfZnVuY19zY2hlZF95aWVsZD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdXRpbWU9eWVz fQp8IDogJHthY19jdl9mdW5jX3V0aW1lcz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfY2hvd249eWVz fQp8IDogJHthY19jdl9mdW5jX2R1cDI9eWVzfQp8IDogJHthY19jdl9mdW5jX2luZXRfbnRvcD15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfZm9yaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdmZvcms9eWVz fQp8IDogJHthY19jdl9mdW5jX2dldGhvc3RuYW1lPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRo b3N0YnluYW1lPXllc30KfCA6ICR7YWNfY3ZfZnVuY193YWl0cGlkPXllc30KfCAjIEhhcyBhcHBl YXJyZWQgaW4gRnJlZUJTRCAxMAp8ICM6ICR7YWNfY3ZfZnVuY193YWl0aWQ9eWVzfQp8IDogJHth Y19jdl9mdW5jX3Zhc3ByaW50Zj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdW5zZXRlbnY9eWVzfQp8 IDogJHtndF9jdl9mdW5jX3Vuc2V0ZW52X3JldD1pbnR9CnwgOiAke2FjX2N2X2Z1bmNfc3RydG9s PXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHJicms9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cnBi cms9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cmNzcG49eWVzfQp8ICMgSGFzIGFwcGVhcnJlZCBp biBGcmVlQlNEIDEwCnwgIzogJHthY19jdl9mdW5jX3N0cmNocm51bD15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc2lncHJvY21hc2s9eWVzfQp8IDogJHthY19jdl9mdW5jX21rZHRlbXA9eWVzfQp8IDog JHthY19jdl9mdW5jX21lbXNldD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RyZnRpbWU9eWVzfQp8 IDogJHthY19jdl9mdW5jX2dldGVnaWQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldGV1aWQ9eWVz fQp8IDogJHthY19jdl9mdW5jX3N0cGNweT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdHNlYXJjaD15 ZXN9CnwgIyBIYXMgYXBwZWFycmVkIGluIEZyZWVCU0QgOQp8ICM6ICR7YWNfY3ZfZnVuY191c2Vs b2NhbGU9eWVzfQp8ICM6ICR7YWNfY3ZfZnVuY19uZXdsb2NhbGU9eWVzfQp8IDogJHthY19jdl9m dW5jX2FzcHJpbnRmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19md3ByaW50Zj15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfcHV0ZW52PXllc30KfCA6ICR7YWNfY3ZfZnVuY19zZXRlbnY9eWVzfQp8IDogJHth Y19jdl9mdW5jX3NldGxvY2FsZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RybGVuPXllc30KfCA6 ICR7YWNfY3ZfZnVuY193Y3NsZW49eWVzfQp8IDogJHthY19jdl9mdW5jX3djc25sZW49eWVzfQp8 IDogJHthY19jdl9mdW5jX21icnRvd2M9eWVzfQp8IDogJHthY19jdl9mdW5jX3djcnRvbWI9eWVz fQp8IDogJHthY19jdl9mdW5jX3JlYWRsaW5rPXllc30KfCA6ICR7YWNfY3ZfZnVuY19yZWFscGF0 aD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbHN0YXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX21ic2lu aXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX21wcm90ZWN0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19t ZW1jaHI9eWVzfQp8IDogJHthY19jdl9mdW5jX3BhdGhjb25mPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19pc3djbnRybD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaXN3Ymxhbms9eWVzfQp8IDogJHthY19j dl9mdW5jX3djd2lkdGg9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cmVycm9yX3I9eWVzfQp8IDog JHthY19jdl9mdW5jX2dldG9wdF9sb25nX29ubHk9eWVzfQp8IDogJHthY19jdl9mdW5jX2FsbG9j YT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19idG93Yz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfYnRvd2Nfd29ya3M9eWVzfQp8IDogJHthY19j dl9mdW5jX3djdG9iPXllc30KfCA6ICR7Z2xfY3ZfZnVuY193Y3RvYl93b3Jrcz15ZXN9CnwgOiAk e2FjX2N2X2Z1bmNfcHRocmVhZF9zZWxmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX211 dGV4X2luaXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3B0aHJlYWRfbXV0ZXhfZGVzdHJveT15ZXN9 CnwgOiAke2FjX2N2X2Z1bmNfcHRocmVhZF9tdXRleF9sb2NrPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19wdGhyZWFkX211dGV4X3VubG9jaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHRocmVhZF9jb25k X2luaXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3B0aHJlYWRfY29uZF9kZXN0cm95PXllc30KfCA6 ICR7YWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfd2FpdD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHRo cmVhZF9jb25kX3RpbWVkd2FpdD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHRocmVhZF9jb25kX3Np Z25hbD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHRocmVhZF9jb25kX2Jyb2FkY2FzdD15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfcHRocmVhZF9lcXVhbD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcHRocmVh ZF9leGl0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19zZXRybGltaXQ9eWVzfQp8IDogJHthY19jdl9m dW5jX3NobWdldD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2lnYWN0aW9uPXllc30KfCA6ICR7YWNf Y3ZfZnVuY19zaWdhbHRzdGFjaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2lnaW50ZXJydXB0PXll c30KfCA6ICR7YWNfY3ZfZnVuY19mcHVyZ2U9eWVzfQp8IDogJHthY19jdl9mdW5jX2Z3cHJpbnRm PXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRkdGFibGVzaXplPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19nZXRwYWdlc2l6ZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaXNibGFuaz15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfaXN3Ymxhbms9eWVzfQp8IDogJHthY19jdl9mdW5jX2lzd2NudHJsPXllc30KfCA6 ICR7YWNfY3ZfZnVuY19pc3djdHlwZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbGluaz15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfbHN0YXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJl bmNlc19zbGFzaGVkX3N5bWxpbms9eWVzfQp8IDogJHthY19jdl9mdW5jX21hbGxvY18wX25vbm51 bGw9eWVzfQp8IDogJHthY19jdl9mdW5jX21rc3RlbXA9eWVzfQp8IDogJHthY19jdl9mdW5jX21s b2NrPXllc30KfCA6ICR7YWNfY3ZfZnVuY19ubF9sYW5naW5mbz15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfcGlwZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcG9zaXhfc3Bhd249eWVzfQp8IDogJHthY19j dl9mdW5jX3N0cm5kdXA9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cm5sZW49eWVzfQp8IDogJHth Y19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3Ryc2lnbmFs PXllc30KfCA6ICR7YWNfY3ZfZnVuY19zeW1saW5rPXllc30KfCA6ICR7YWNfY3ZfZnVuY193Y3Nj b2xsPXllc30KfCA6ICR7YWNfY3ZfZnVuY193Y3NsZW49eWVzfQp8IDogJHthY19jdl9mdW5jX3dj c25sZW49eWVzfQp8IDogJHthY19jdl9mdW5jX3djd2lkdGg9eWVzfQp8IAp8ICMgbm9uIGV4aXN0 aW5nIGZ1bmN0aW9ucwp8IDogJHthY19jdl9mdW5jX3lpZWxkPW5vfQp8IDogJHthY19jdl9mdW5j X3BzdGF0X2dldGR5bmFtaWM9bm99CnwgOiAke2FjX2N2X2Z1bmNfcmF3bWVtY2hyPW5vfQp8IDog JHthY19jdl9mdW5jX29ic3RhY2tzPW5vfQp8IDogJHthY19jdl9mdW5jX2FyZ3pfY291bnQ9bm99 CnwgOiAke2FjX2N2X2Z1bmNfYXJnel9zdHJpbmdpZnk9bm99CnwgOiAke2FjX2N2X2Z1bmNfYXJn el9uZXh0PW5vfQp8IAp8IDogJHthY19jdl9oYXZlX2RlY2xfYWxhcm09eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfY2xlYXJlcnJfdW5sb2NrZWQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xf ZmVvZl91bmxvY2tlZD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mZXJyb3JfdW5sb2NrZWQ9 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfZnB1cmdlPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX2ZyZXhwbD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mc2Vla289eWVzfQp8IDogJHth Y19jdl9oYXZlX2RlY2xfZnRlbGxvPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldGNfdW5s b2NrZWQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfZ2V0ZW52PXllc30KfCA6ICR7YWNfY3Zf aGF2ZV9kZWNsX2dldHBhZ2VzaXplPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2lzYmxhbms9 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcHV0Y191bmxvY2tlZD15ZXN9CnwgOiAke2FjX2N2 X2hhdmVfZGVjbF9zZXRlbnY9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc2lnYWx0c3RhY2s9 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc25wcmludGY9eWVzfQp8IDogJHthY19jdl9oYXZl X2RlY2xfc3RyZHVwPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0cmVycm9yX3I9eWVzfQp8 IDogJHthY19jdl9oYXZlX2RlY2xfc3RybmR1cD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9z dHJubGVuPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0cnNpZ25hbD15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfZGVjbF9zdHJ0b2Q9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc3lzX3NpZ2xp c3Q9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfdW5zZXRlbnY9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfd2N0b2I9eWVzfQp8IAp8ICMgZnVuY3Rpb24gc3BlY2lmaWMKfCA6ICR7Z2xfY3Zf ZGVjbF9udWxsX3dvcmtzPXllc30KfCA6ICR7Z2xfY3ZfZGVjbF9yZWFkbGlua193b3Jrcz15ZXN9 CnwgOiAke2dsX2N2X2Z1bmNfYnRvd2NfZW9mPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19idG93Y19u dWw9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2R1cDJfd29ya3M9eWVzfQp8IDogJHtnbF9jdl9mdW5j X2ZjbnRsX2ZfZHVwZmRfY2xvZXhlYz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfZmNudGxfZl9kdXBm ZF93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfZm9wZW5fc2xhc2g9eWVzfQp8IDogJHtnbF9j dl9mdW5jX2ZwdXJnZV93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfZnJleHBfbm9fbGlibT15 ZXN9CnwgOiAke2dsX2N2X2Z1bmNfZnNlZWtvPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19mdGVsbG89 eWVzfQp8IDogJHtnbF9jdl9mdW5jX2Z0ZWxsb193b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNf Z2V0b3B0X3Bvc2l4PXllc30KfCA6ICR7Z2xfY3ZfZnVuY19pc25hbmRfbm9fbGlibT15ZXN9Cnwg OiAke2dsX2N2X2Z1bmNfaXN3Y250cmxfd29ya3M9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2xkZXhw X25vX2xpYm09eWVzfQp8IDogJHtnbF9jdl9mdW5jX2xpbmtfd29ya3M9eWVzfQp8IDogJHtnbF9j dl9mdW5jX2xzZWVrX3BpcGU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX21hbGxvY18wX25vbm51bGw9 MX0KfCA6ICR7Z2xfY3ZfZnVuY19tYWxsb2NfcG9zaXg9eWVzfQp8IDogJHtnbF9jdl9mdW5jX21i cnRvd2NfaW5jb21wbGV0ZV9zdGF0ZT15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfbWJydG93Y19udWxf cmV0dmFsPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19tYnJ0b3djX251bGxfYXJnMT15ZXN9CnwgOiAk e2dsX2N2X2Z1bmNfbWJydG93Y19udWxsX2FyZzI9eWVzfQp8IDogJHtnbF9jdl9mdW5jX21icnRv d2NfcmV0dmFsPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19tYnJ0b3djX3Nhbml0eWNoZWNrPXllc30K fCA6ICR7Z2xfY3ZfZnVuY19tZW1jaHJfd29ya3M9eWVzfQp8IDogJHtnbF9jdl9mdW5jX25sX2xh bmdpbmZvX3llc2V4cHJfd29ya3M9eWVzfQp8IDogJHtnbF9jdl9mdW5jX29wZW5fc2xhc2g9eWVz fQp8IDogJHtnbF9jdl9mdW5jX3Bvc2l4X3NwYXduX3dvcmtzPXllc30KfCA6ICR7Z2xfY3ZfZnVu Y19wcmludGZfZGlyZWN0aXZlX2E9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50Zl9kaXJlY3Rp dmVfZj15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2ZV9scz15ZXN9CnwgOiAk e2dsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2ZV9uPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19wcmlu dGZfZmxhZ19ncm91cGluZz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2ZsYWdfbGVmdGFk anVzdD15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2ZsYWdfemVybz15ZXN9CnwgOiAke2ds X2N2X2Z1bmNfcHJpbnRmX2luZmluaXRlPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19wcmludGZfbG9u Z19kb3VibGU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50Zl9wb3NpdGlvbnM9eWVzfQp8IDog JHtnbF9jdl9mdW5jX3ByaW50Zl9wcmVjaXNpb249eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50 Zl9zaXplc19jOTk9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3JlYWRsaW5rX3dvcmtzPXllc30KfCA6 ICR7Z2xfY3ZfZnVuY19yZWFscGF0aF93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcmVuYW1l X2Rlc3Rfd29ya3M9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3JlbmFtZV9saW5rX3dvcmtzPXllc30K fCA6ICR7Z2xfY3ZfZnVuY19yZW5hbWVfc2xhc2hfZHN0X3dvcmtzPXllc30KfCA6ICR7Z2xfY3Zf ZnVuY19yZW5hbWVfc2xhc2hfc3JjX3dvcmtzPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19ybWRpcl93 b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfc2V0ZW52X3dvcmtzPXllc30KfCA6ICR7Z2xfY3Zf ZnVuY19zaWdwcm9jbWFzaz0xfQp8IDogJHtnbF9jdl9mdW5jX3NucHJpbnRmX3JldHZhbF9jOTk9 eWVzfQp8IDogJHtnbF9jdl9mdW5jX3NucHJpbnRmX3NpemUxPXllc30KfCA6ICR7Z2xfY3ZfZnVu Y19zbnByaW50Zl91c2FibGU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3NwYXduYXR0cl9zZXRzY2hl ZHBhcmFtPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19zcGF3bmF0dHJfc2V0c2NoZWRwb2xpY3k9eWVz fQp8IDogJHtnbF9jdl9mdW5jX3N0YXRfZGlyX3NsYXNoPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19z dGF0X2ZpbGVfc2xhc2g9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3N0cm5kdXBfd29ya3M9eWVzfQp8 IDogJHtnbF9jdl9mdW5jX3N0cnN0cl93b3Jrc19hbHdheXM9eWVzfQp8IDogJHtnbF9jdl9mdW5j X3N0cnRvZF93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfc3ltbGlua193b3Jrcz15ZXN9Cnwg OiAke2dsX2N2X2Z1bmNfdW5nZXRjX3dvcmtzPXllc30KfCA6ICR7Z2xfY3ZfZnVuY191bnNldGVu dl93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfdmFfY29weT15ZXN9CnwgOiAke2dsX2N2X2Z1 bmNfd2NydG9tYl9yZXR2YWw9eWVzfQp8IDogJHtnbF9jdl9oYXZlX2luY2x1ZGVfbmV4dD15ZXN9 CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcmF3bWVtY2hyPXllc30KfCA6ICR7Z2xfY3ZfaGVh ZGVyX2Vycm5vX2hfY29tcGxldGU9eWVzfQp8IDogJHtnbF9jdl9oZWFkZXJfaW50dHlwZXNfaD15 ZXN9CnwgOiAke2dsX2N2X2hlYWRlcl9sYW5naW5mb19jb2Rlc2V0PXllc30KfCA6ICR7Z2xfY3Zf aGVhZGVyX2xhbmdpbmZvX2VyYT15ZXN9CnwgOiAke2dsX2N2X2hlYWRlcl9sYW5naW5mb190X2Zt dF9hbXBtPXllc30KfCA6ICR7Z2xfY3ZfaGVhZGVyX2xhbmdpbmZvX3llc2V4cHI9eWVzfQp8IDog JHtnbF9jdl9oZWFkZXJfbWF0aF9odWdlX3ZhbF93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2hlYWRl cl9tYXRoX25hbl93b3Jrcz15ZXN9CnwgOiAke2dsX2N2X2hlYWRlcl9zdGRpbnRfaD15ZXN9CmNv bmZpZ3VyZToxOTY0OiBjaGVja2luZyBjb2RlIHJldmlzaW9uCmNvbmZpZ3VyZToxOTc4OiByZXN1 bHQ6IGZyb20gQ2hhbmdlTG9nOiAxNTAyCmNvbmZpZ3VyZToyMDQwOiBjaGVja2luZyBmb3IgYSBC U0QtY29tcGF0aWJsZSBpbnN0YWxsCmNvbmZpZ3VyZToyMDk2OiByZXN1bHQ6IC91c3IvYmluL2lu c3RhbGwgLWMgLW8gcm9vdCAtZyB3aGVlbApjb25maWd1cmU6MjEwNzogY2hlY2tpbmcgd2hldGhl ciBidWlsZCBlbnZpcm9ubWVudCBpcyBzYW5lCmNvbmZpZ3VyZToyMTUwOiByZXN1bHQ6IHllcwpj b25maWd1cmU6MjE3ODogY2hlY2tpbmcgZm9yIGEgdGhyZWFkLXNhZmUgbWtkaXIgLXAKY29uZmln dXJlOjIyMTc6IHJlc3VsdDogL2Jpbi9ta2RpciAtcApjb25maWd1cmU6MjIzMDogY2hlY2tpbmcg Zm9yIGdhd2sKY29uZmlndXJlOjIyNTc6IHJlc3VsdDogL3Vzci9iaW4vYXdrCmNvbmZpZ3VyZToy MjY4OiBjaGVja2luZyB3aGV0aGVyIGdtYWtlIHNldHMgJChNQUtFKQpjb25maWd1cmU6MjI4OTog cmVzdWx0OiB5ZXMKY29uZmlndXJlOjI0ODE6IGNoZWNraW5nIHdoZXRoZXIgdG8gZW5hYmxlIG1h aW50YWluZXItc3BlY2lmaWMgcG9ydGlvbnMgb2YgTWFrZWZpbGVzCmNvbmZpZ3VyZToyNDkwOiBy ZXN1bHQ6IG5vCmNvbmZpZ3VyZToyNTI4OiBjaGVja2luZyB3aGV0aGVyIE5MUyBpcyByZXF1ZXN0 ZWQKY29uZmlndXJlOjI1Mzc6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZToyNTc1OiBjaGVja2luZyBm b3IgbXNnZm10CmNvbmZpZ3VyZToyNjA2OiByZXN1bHQ6IC91c3IvbG9jYWwvYmluL21zZ2ZtdApj b25maWd1cmU6MjYxNTogY2hlY2tpbmcgZm9yIGdtc2dmbXQKY29uZmlndXJlOjI2NDY6IHJlc3Vs dDogL3Vzci9sb2NhbC9iaW4vbXNnZm10CmNvbmZpZ3VyZToyNjg2OiBjaGVja2luZyBmb3IgeGdl dHRleHQKY29uZmlndXJlOjI3MTc6IHJlc3VsdDogL3Vzci9sb2NhbC9iaW4veGdldHRleHQKY29u ZmlndXJlOjI3NTc6IGNoZWNraW5nIGZvciBtc2dtZXJnZQpjb25maWd1cmU6Mjc4NzogcmVzdWx0 OiAvdXNyL2xvY2FsL2Jpbi9tc2dtZXJnZQpjb25maWd1cmU6Mjg1MDogY2hlY2tpbmcgZm9yIHN0 eWxlIG9mIGluY2x1ZGUgdXNlZCBieSBnbWFrZQpjb25maWd1cmU6Mjg3ODogcmVzdWx0OiBHTlUK Y29uZmlndXJlOjI5NDg6IGNoZWNraW5nIGZvciBnY2MKY29uZmlndXJlOjI5NzU6IHJlc3VsdDog Y2MKY29uZmlndXJlOjMyMTM6IGNoZWNraW5nIGZvciBDIGNvbXBpbGVyIHZlcnNpb24KY29uZmln dXJlOjMyMjA6IGNjIC0tdmVyc2lvbiA+JjUKY2MgKEdDQykgNC4yLjEgMjAwNzA4MzEgcGF0Y2hl ZCBbRnJlZUJTRF0KQ29weXJpZ2h0IChDKSAyMDA3IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg SW5jLgpUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUgc291cmNlIGZvciBjb3B5aW5nIGNv bmRpdGlvbnMuICBUaGVyZSBpcyBOTwp3YXJyYW50eTsgbm90IGV2ZW4gZm9yIE1FUkNIQU5UQUJJ TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCmNvbmZpZ3VyZTozMjIz OiAkPyA9IDAKY29uZmlndXJlOjMyMzA6IGNjIC12ID4mNQpVc2luZyBidWlsdC1pbiBzcGVjcy4K VGFyZ2V0OiBhbWQ2NC11bmRlcm15ZGVzay1mcmVlYnNkCkNvbmZpZ3VyZWQgd2l0aDogRnJlZUJT RC9hbWQ2NCBzeXN0ZW0gY29tcGlsZXIKVGhyZWFkIG1vZGVsOiBwb3NpeApnY2MgdmVyc2lvbiA0 LjIuMSAyMDA3MDgzMSBwYXRjaGVkIFtGcmVlQlNEXQpjb25maWd1cmU6MzIzMzogJD8gPSAwCmNv bmZpZ3VyZTozMjQwOiBjYyAtViA+JjUKY2M6ICctVicgb3B0aW9uIG11c3QgaGF2ZSBhcmd1bWVu dApjb25maWd1cmU6MzI0MzogJD8gPSAxCmNvbmZpZ3VyZTozMjY2OiBjaGVja2luZyBmb3IgQyBj b21waWxlciBkZWZhdWx0IG91dHB1dCBmaWxlIG5hbWUKY29uZmlndXJlOjMyOTM6IGNjIC1PMiAt LXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgIC1ML3Vz ci9sb2NhbC9saWIgY29uZnRlc3QuYyAgPiY1CmNvbmZpZ3VyZTozMjk2OiAkPyA9IDAKY29uZmln dXJlOjMzMzQ6IHJlc3VsdDogYS5vdXQKY29uZmlndXJlOjMzNTE6IGNoZWNraW5nIHdoZXRoZXIg dGhlIEMgY29tcGlsZXIgd29ya3MKY29uZmlndXJlOjMzNjE6IC4vYS5vdXQKY29uZmlndXJlOjMz NjQ6ICQ/ID0gMApjb25maWd1cmU6MzM4MTogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjMzODg6IGNo ZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZwpjb25maWd1cmU6MzM5MDogcmVz dWx0OiBubwpjb25maWd1cmU6MzM5MzogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxl cwpjb25maWd1cmU6MzQwMDogY2MgLW8gY29uZnRlc3QgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmlj dC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSAgLUwvdXNyL2xvY2FsL2xpYiBjb25mdGVz dC5jICA+JjUKY29uZmlndXJlOjM0MDM6ICQ/ID0gMApjb25maWd1cmU6MzQyNzogcmVzdWx0OiAK Y29uZmlndXJlOjM0MzM6IGNoZWNraW5nIGZvciBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzCmNvbmZp Z3VyZTozNDU5OiBjYyAtYyAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vz ci9sb2NhbC9pbmNsdWRlIGNvbmZ0ZXN0LmMgPiY1CmNvbmZpZ3VyZTozNDYyOiAkPyA9IDAKY29u ZmlndXJlOjM0ODU6IHJlc3VsdDogbwpjb25maWd1cmU6MzQ4OTogY2hlY2tpbmcgd2hldGhlciB3 ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNvbXBpbGVyCmNvbmZpZ3VyZTozNTE4OiBjYyAtYyAtTzIg LS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNsdWRlIGNvbmZ0 ZXN0LmMgPiY1CmNvbmZpZ3VyZTozNTI0OiAkPyA9IDAKY29uZmlndXJlOjM1NDE6IHJlc3VsdDog eWVzCmNvbmZpZ3VyZTozNTQ2OiBjaGVja2luZyB3aGV0aGVyIGNjIGFjY2VwdHMgLWcKY29uZmln dXJlOjM1NzY6IGNjIC1jIC1nIC1JL3Vzci9sb2NhbC9pbmNsdWRlIGNvbmZ0ZXN0LmMgPiY1CmNv bmZpZ3VyZTozNTgyOiAkPyA9IDAKY29uZmlndXJlOjM2ODE6IHJlc3VsdDogeWVzCmNvbmZpZ3Vy ZTozNjk4OiBjaGVja2luZyBmb3IgY2Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5CmNvbmZpZ3Vy ZTozNzcyOiBjYyAgLWMgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3Iv bG9jYWwvaW5jbHVkZSBjb25mdGVzdC5jID4mNQpjb25maWd1cmU6Mzc3ODogJD8gPSAwCmNvbmZp Z3VyZTozODAxOiByZXN1bHQ6IG5vbmUgbmVlZGVkCmNvbmZpZ3VyZTozODIxOiBjaGVja2luZyBk ZXBlbmRlbmN5IHN0eWxlIG9mIGNjCmNvbmZpZ3VyZTozOTEyOiByZXN1bHQ6IGdjYzMKY29uZmln dXJlOjM5MzM6IGNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlCmNvbmZpZ3VyZTozOTUxOiByZXN1 bHQ6IGFtZDY0LXBvcnRibGQtZnJlZWJzZDkuMQpjb25maWd1cmU6Mzk3MzogY2hlY2tpbmcgaG9z dCBzeXN0ZW0gdHlwZQpjb25maWd1cmU6Mzk4ODogcmVzdWx0OiBhbWQ2NC1wb3J0YmxkLWZyZWVi c2Q5LjEKY29uZmlndXJlOjQwMzQ6IGNoZWNraW5nIGZvciBsZCB1c2VkIGJ5IEdDQwpjb25maWd1 cmU6NDA5ODogcmVzdWx0OiAvdXNyL2Jpbi9sZApjb25maWd1cmU6NDEwNzogY2hlY2tpbmcgaWYg dGhlIGxpbmtlciAoL3Vzci9iaW4vbGQpIGlzIEdOVSBsZApjb25maWd1cmU6NDEyMDogcmVzdWx0 OiB5ZXMKY29uZmlndXJlOjQxMjY6IGNoZWNraW5nIGZvciBzaGFyZWQgbGlicmFyeSBydW4gcGF0 aCBvcmlnaW4KY29uZmlndXJlOjQxMzk6IHJlc3VsdDogZG9uZQpjb25maWd1cmU6NDU1NjogY2hl Y2tpbmcgd2hldGhlciBOTFMgaXMgcmVxdWVzdGVkCmNvbmZpZ3VyZTo0NTY1OiByZXN1bHQ6IHll cwpjb25maWd1cmU6NDU4MzogY2hlY2tpbmcgZm9yIEdOVSBnZXR0ZXh0IGluIGxpYmMKY29uZmln dXJlOjQ2MTI6IGNjIC1vIGNvbmZ0ZXN0IC1PMiAtLXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNp bmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgIC1ML3Vzci9sb2NhbC9saWIgY29uZnRlc3QuYyAgPiY1 Ci90bXAvL2NjOFl3NDVuLm86IEluIGZ1bmN0aW9uIGBtYWluJzoKY29uZnRlc3QuYzooLnRleHQr MHhkKTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgbGliaW50bF9iaW5kdGV4dGRvbWFpbicKY29u ZnRlc3QuYzooLnRleHQrMHgxNyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGxpYmludGxfZ2V0 dGV4dCcKY29uZnRlc3QuYzooLnRleHQrMHgxZSk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYF9u bF9kb21haW5fYmluZGluZ3MnCmNvbmZ0ZXN0LmM6KC50ZXh0KzB4MjcpOiB1bmRlZmluZWQgcmVm ZXJlbmNlIHRvIGBfbmxfbXNnX2NhdF9jbnRyJwpjb25maWd1cmU6NDYxODogJD8gPSAxCmNvbmZp Z3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUg UEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIK fCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5H ICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFn Lm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVy anRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwg LyogZW5kIGNvbmZkZWZzLmguICAqLwp8ICNpbmNsdWRlIDxsaWJpbnRsLmg+CnwgZXh0ZXJuIGlu dCBfbmxfbXNnX2NhdF9jbnRyOwp8IGV4dGVybiBpbnQgKl9ubF9kb21haW5fYmluZGluZ3M7Cnwg aW50CnwgbWFpbiAoKQp8IHsKfCBiaW5kdGV4dGRvbWFpbiAoIiIsICIiKTsKfCByZXR1cm4gKGxv bmcpIGdldHRleHQgKCIiKSArIF9ubF9tc2dfY2F0X2NudHIgKyAqX25sX2RvbWFpbl9iaW5kaW5n cwp8ICAgOwp8ICAgcmV0dXJuIDA7CnwgfQpjb25maWd1cmU6NDYzNTogcmVzdWx0OiBubwpjb25m aWd1cmU6NDY2OTogY2hlY2tpbmcgZm9yIGljb252CmNvbmZpZ3VyZTo0NzAxOiBjYyAtbyBjb25m dGVzdCAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNs dWRlICAtTC91c3IvbG9jYWwvbGliIGNvbmZ0ZXN0LmMgID4mNQovdG1wLy9jY2xoYVJ6SS5vOiBJ biBmdW5jdGlvbiBgbWFpbic6CmNvbmZ0ZXN0LmM6KC50ZXh0KzB4YSk6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYGxpYmljb252X29wZW4nCmNvbmZ0ZXN0LmM6KC50ZXh0KzB4MWUpOiB1bmRlZmlu ZWQgcmVmZXJlbmNlIHRvIGBsaWJpY29udicKY29uZnRlc3QuYzooLnRleHQrMHgyNik6IHVuZGVm aW5lZCByZWZlcmVuY2UgdG8gYGxpYmljb252X2Nsb3NlJwpjb25maWd1cmU6NDcwNzogJD8gPSAx CmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNk ZWZpbmUgUEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVy anRhZyIKfCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0Vf U1RSSU5HICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8v dXJqdGFnLm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tB R0UgInVyanRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJD RSAxCnwgLyogZW5kIGNvbmZkZWZzLmguICAqLwp8ICNpbmNsdWRlIDxzdGRsaWIuaD4KfCAjaW5j bHVkZSA8aWNvbnYuaD4KfCBpbnQKfCBtYWluICgpCnwgewp8IGljb252X3QgY2QgPSBpY29udl9v cGVuKCIiLCIiKTsKfCAgICAgICAgaWNvbnYoY2QsTlVMTCxOVUxMLE5VTEwsTlVMTCk7CnwgICAg ICAgIGljb252X2Nsb3NlKGNkKTsKfCAgIDsKfCAgIHJldHVybiAwOwp8IH0KY29uZmlndXJlOjQ3 NTA6IGNjIC1vIGNvbmZ0ZXN0IC1PMiAtLXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkv dXNyL2xvY2FsL2luY2x1ZGUgIC1ML3Vzci9sb2NhbC9saWIgY29uZnRlc3QuYyAgL3Vzci9sb2Nh bC9saWIvbGliaWNvbnYuc28gLVdsLC1ycGF0aCAtV2wsL3Vzci9sb2NhbC9saWIgPiY1CmNvbmZp Z3VyZTo0NzU2OiAkPyA9IDAKY29uZmlndXJlOjQ3Nzc6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo0 Nzg3OiBjaGVja2luZyBob3cgdG8gbGluayB3aXRoIGxpYmljb252CmNvbmZpZ3VyZTo0Nzg5OiBy ZXN1bHQ6IC91c3IvbG9jYWwvbGliL2xpYmljb252LnNvIC1XbCwtcnBhdGggLVdsLC91c3IvbG9j YWwvbGliCmNvbmZpZ3VyZTo1MTc4OiBjaGVja2luZyBmb3IgR05VIGdldHRleHQgaW4gbGliaW50 bApjb25maWd1cmU6NTIxNTogY2MgLW8gY29uZnRlc3QgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmlj dC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSAgIC1ML3Vzci9sb2NhbC9saWIgY29uZnRl c3QuYyAgL3Vzci9sb2NhbC9saWIvbGliaW50bC5zbyAvdXNyL2xvY2FsL2xpYi9saWJpY29udi5z byAtV2wsLXJwYXRoIC1XbCwvdXNyL2xvY2FsL2xpYiA+JjUKY29uZmlndXJlOjUyMjE6ICQ/ID0g MApjb25maWd1cmU6NTI5NjogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjUzMjU6IGNoZWNraW5nIHdo ZXRoZXIgdG8gdXNlIE5MUwpjb25maWd1cmU6NTMyNzogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjUz MzA6IGNoZWNraW5nIHdoZXJlIHRoZSBnZXR0ZXh0IGZ1bmN0aW9uIGNvbWVzIGZyb20KY29uZmln dXJlOjUzNDE6IHJlc3VsdDogZXh0ZXJuYWwgbGliaW50bApjb25maWd1cmU6NTM0OTogY2hlY2tp bmcgaG93IHRvIGxpbmsgd2l0aCBsaWJpbnRsCmNvbmZpZ3VyZTo1MzUxOiByZXN1bHQ6IC91c3Iv bG9jYWwvbGliL2xpYmludGwuc28gL3Vzci9sb2NhbC9saWIvbGliaWNvbnYuc28gLVdsLC1ycGF0 aCAtV2wsL3Vzci9sb2NhbC9saWIKY29uZmlndXJlOjU0NTI6IGNoZWNraW5nIGZvciBnY2MKY29u ZmlndXJlOjU0Nzk6IHJlc3VsdDogY2MKY29uZmlndXJlOjU3MTc6IGNoZWNraW5nIGZvciBDIGNv bXBpbGVyIHZlcnNpb24KY29uZmlndXJlOjU3MjQ6IGNjIC0tdmVyc2lvbiA+JjUKY2MgKEdDQykg NC4yLjEgMjAwNzA4MzEgcGF0Y2hlZCBbRnJlZUJTRF0KQ29weXJpZ2h0IChDKSAyMDA3IEZyZWUg U29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgpUaGlzIGlzIGZyZWUgc29mdHdhcmU7IHNlZSB0aGUg c291cmNlIGZvciBjb3B5aW5nIGNvbmRpdGlvbnMuICBUaGVyZSBpcyBOTwp3YXJyYW50eTsgbm90 IGV2ZW4gZm9yIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4KCmNvbmZpZ3VyZTo1NzI3OiAkPyA9IDAKY29uZmlndXJlOjU3MzQ6IGNjIC12ID4mNQpV c2luZyBidWlsdC1pbiBzcGVjcy4KVGFyZ2V0OiBhbWQ2NC11bmRlcm15ZGVzay1mcmVlYnNkCkNv bmZpZ3VyZWQgd2l0aDogRnJlZUJTRC9hbWQ2NCBzeXN0ZW0gY29tcGlsZXIKVGhyZWFkIG1vZGVs OiBwb3NpeApnY2MgdmVyc2lvbiA0LjIuMSAyMDA3MDgzMSBwYXRjaGVkIFtGcmVlQlNEXQpjb25m aWd1cmU6NTczNzogJD8gPSAwCmNvbmZpZ3VyZTo1NzQ0OiBjYyAtViA+JjUKY2M6ICctVicgb3B0 aW9uIG11c3QgaGF2ZSBhcmd1bWVudApjb25maWd1cmU6NTc0NzogJD8gPSAxCmNvbmZpZ3VyZTo1 NzUwOiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMgY29tcGlsZXIKY29u ZmlndXJlOjU4MDI6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo1ODA3OiBjaGVja2luZyB3aGV0aGVy IGNjIGFjY2VwdHMgLWcKY29uZmlndXJlOjU5NDI6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo1OTU5 OiBjaGVja2luZyBmb3IgY2Mgb3B0aW9uIHRvIGFjY2VwdCBJU08gQzg5CmNvbmZpZ3VyZTo2MDYy OiByZXN1bHQ6IG5vbmUgbmVlZGVkCmNvbmZpZ3VyZTo2MDgyOiBjaGVja2luZyBkZXBlbmRlbmN5 IHN0eWxlIG9mIGNjCmNvbmZpZ3VyZTo2MTczOiByZXN1bHQ6IGdjYzMKY29uZmlndXJlOjYyMzE6 IGNoZWNraW5nIGZvciByYW5saWIKY29uZmlndXJlOjYyNDc6IGZvdW5kIC91c3IvYmluL3Jhbmxp Ygpjb25maWd1cmU6NjI1ODogcmVzdWx0OiByYW5saWIKY29uZmlndXJlOjYyODg6IGNoZWNraW5n IGZvciBiaXNvbgpjb25maWd1cmU6NjMxODogcmVzdWx0OiBubwpjb25maWd1cmU6NjI4ODogY2hl Y2tpbmcgZm9yIGJ5YWNjCmNvbmZpZ3VyZTo2MzA0OiBmb3VuZCAvdXNyL2Jpbi9ieWFjYwpjb25m aWd1cmU6NjMxNTogcmVzdWx0OiBieWFjYwpjb25maWd1cmU6NjMyOTogY2hlY2tpbmcgZm9yIGxp YnJhcnkgY29udGFpbmluZyBpb3Blcm0KY29uZmlndXJlOjYzNzA6IGNjIC1vIGNvbmZ0ZXN0IC1P MiAtLXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgIC1M L3Vzci9sb2NhbC9saWIgY29uZnRlc3QuYyAgPiY1Ci90bXAvL2NjZkJNSXVQLm86IEluIGZ1bmN0 aW9uIGBtYWluJzoKY29uZnRlc3QuYzooLnRleHQrMHg3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0 byBgaW9wZXJtJwpjb25maWd1cmU6NjM3NjogJD8gPSAxCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dy YW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUgUEFDS0FHRV9OQU1FICJVckpU QUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIKfCAjZGVmaW5lIFBBQ0tBR0Vf VkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJVckpUQUcgMC4xMCIKfCAj ZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFnLm9yZyIKfCAjZGVmaW5lIFNW Tl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVyanRhZyIKfCAjZGVmaW5lIFZF UlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwgI2RlZmluZSBIQVZFX0lDT05W IDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFWRV9HRVRURVhUIDEKfCAjZGVm aW5lIEhBVkVfRENHRVRURVhUIDEKfCAvKiBlbmQgY29uZmRlZnMuaC4gICovCnwgCnwgLyogT3Zl cnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCnwgICAg VXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0ND CnwgICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8KfCAjaWZkZWYgX19jcGx1c3BsdXMKfCBleHRlcm4gIkMiCnwgI2VuZGlmCnwg Y2hhciBpb3Blcm0gKCk7CnwgaW50CnwgbWFpbiAoKQp8IHsKfCByZXR1cm4gaW9wZXJtICgpOwp8 ICAgOwp8ICAgcmV0dXJuIDA7CnwgfQpjb25maWd1cmU6NjM3MDogY2MgLW8gY29uZnRlc3QgLU8y IC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSAgLUwv dXNyL2xvY2FsL2xpYiBjb25mdGVzdC5jIC1saW9wZXJtICAgPiY1Ci91c3IvYmluL2xkOiBjYW5u b3QgZmluZCAtbGlvcGVybQpjb25maWd1cmU6NjM3NjogJD8gPSAxCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUgUEFDS0FHRV9OQU1F ICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIKfCAjZGVmaW5lIFBB Q0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJVckpUQUcgMC4x MCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFnLm9yZyIKfCAjZGVm aW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVyanRhZyIKfCAjZGVm aW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwgI2RlZmluZSBIQVZF X0lDT05WIDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFWRV9HRVRURVhUIDEK fCAjZGVmaW5lIEhBVkVfRENHRVRURVhUIDEKfCAvKiBlbmQgY29uZmRlZnMuaC4gICovCnwgCnwg LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu CnwgICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m IGEgR0NDCnwgICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk IHN0aWxsIGFwcGx5LiAgKi8KfCAjaWZkZWYgX19jcGx1c3BsdXMKfCBleHRlcm4gIkMiCnwgI2Vu ZGlmCnwgY2hhciBpb3Blcm0gKCk7CnwgaW50CnwgbWFpbiAoKQp8IHsKfCByZXR1cm4gaW9wZXJt ICgpOwp8ICAgOwp8ICAgcmV0dXJuIDA7CnwgfQpjb25maWd1cmU6NjQwNDogcmVzdWx0OiBubwpj b25maWd1cmU6NjQyMDogY2hlY2tpbmcgZm9yIGxpYnJhcnkgY29udGFpbmluZyBpMzg2X3NldF9p b3Blcm0KY29uZmlndXJlOjY0NjE6IGNjIC1vIGNvbmZ0ZXN0IC1PMiAtLXN0ZD1jOTkgLWZuby1z dHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgIC1ML3Vzci9sb2NhbC9saWIgY29u ZnRlc3QuYyAgPiY1Ci90bXAvL2NjNmFocEJNLm86IEluIGZ1bmN0aW9uIGBtYWluJzoKY29uZnRl c3QuYzooLnRleHQrMHg3KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgaTM4Nl9zZXRfaW9wZXJt Jwpjb25maWd1cmU6NjQ2NzogJD8gPSAxCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8 IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUgUEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2Rl ZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIKfCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAi MC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBB Q0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFnLm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lP TiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVyanRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAu MTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwgI2RlZmluZSBIQVZFX0lDT05WIDEKfCAjZGVm aW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFWRV9HRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVf RENHRVRURVhUIDEKfCAvKiBlbmQgY29uZmRlZnMuaC4gICovCnwgCnwgLyogT3ZlcnJpZGUgYW55 IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCnwgICAgVXNlIGNoYXIg YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCnwgICAgYnVp bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg Ki8KfCAjaWZkZWYgX19jcGx1c3BsdXMKfCBleHRlcm4gIkMiCnwgI2VuZGlmCnwgY2hhciBpMzg2 X3NldF9pb3Blcm0gKCk7CnwgaW50CnwgbWFpbiAoKQp8IHsKfCByZXR1cm4gaTM4Nl9zZXRfaW9w ZXJtICgpOwp8ICAgOwp8ICAgcmV0dXJuIDA7CnwgfQpjb25maWd1cmU6NjQ2MTogY2MgLW8gY29u ZnRlc3QgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5j bHVkZSAgLUwvdXNyL2xvY2FsL2xpYiBjb25mdGVzdC5jIC1saTM4NiAgID4mNQovdXNyL2Jpbi9s ZDogY2Fubm90IGZpbmQgLWxpMzg2CmNvbmZpZ3VyZTo2NDY3OiAkPyA9IDEKY29uZmlndXJlOiBm YWlsZWQgcHJvZ3JhbSB3YXM6CnwgLyogY29uZmRlZnMuaC4gICovCnwgI2RlZmluZSBQQUNLQUdF X05BTUUgIlVySlRBRyIKfCAjZGVmaW5lIFBBQ0tBR0VfVEFSTkFNRSAidXJqdGFnIgp8ICNkZWZp bmUgUEFDS0FHRV9WRVJTSU9OICIwLjEwIgp8ICNkZWZpbmUgUEFDS0FHRV9TVFJJTkcgIlVySlRB RyAwLjEwIgp8ICNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQgImh0dHA6Ly91cmp0YWcub3JnIgp8 ICNkZWZpbmUgU1ZOX1JFVklTSU9OICIxNTAyIgp8ICNkZWZpbmUgUEFDS0FHRSAidXJqdGFnIgp8 ICNkZWZpbmUgVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIF9HTlVfU09VUkNFIDEKfCAjZGVmaW5l IEhBVkVfSUNPTlYgMQp8ICNkZWZpbmUgRU5BQkxFX05MUyAxCnwgI2RlZmluZSBIQVZFX0dFVFRF WFQgMQp8ICNkZWZpbmUgSEFWRV9EQ0dFVFRFWFQgMQp8IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8K fCAKfCAvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl cnJvci4KfCAgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5 cGUgb2YgYSBHQ0MKfCAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg d291bGQgc3RpbGwgYXBwbHkuICAqLwp8ICNpZmRlZiBfX2NwbHVzcGx1cwp8IGV4dGVybiAiQyIK fCAjZW5kaWYKfCBjaGFyIGkzODZfc2V0X2lvcGVybSAoKTsKfCBpbnQKfCBtYWluICgpCnwgewp8 IHJldHVybiBpMzg2X3NldF9pb3Blcm0gKCk7CnwgICA7CnwgICByZXR1cm4gMDsKfCB9CmNvbmZp Z3VyZTo2NDk1OiByZXN1bHQ6IG5vCmNvbmZpZ3VyZTo2NTE4OiBjaGVja2luZyBmb3IgZ2V0bGlu ZQpjb25maWd1cmU6NjU3NDogY2MgLW8gY29uZnRlc3QgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmlj dC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSAgLUwvdXNyL2xvY2FsL2xpYiBjb25mdGVz dC5jICA+JjUKY29uZmlndXJlOjY1ODA6ICQ/ID0gMApjb25maWd1cmU6NjU5ODogcmVzdWx0OiB5 ZXMKY29uZmlndXJlOjY1MTg6IGNoZWNraW5nIGZvciBnZXRkZWxpbQpjb25maWd1cmU6NjU3NDog Y2MgLW8gY29uZnRlc3QgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3Iv bG9jYWwvaW5jbHVkZSAgLUwvdXNyL2xvY2FsL2xpYiBjb25mdGVzdC5jICA+JjUKY29uZmlndXJl OjY1ODA6ICQ/ID0gMApjb25maWd1cmU6NjU5ODogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjY2MTI6 IGNoZWNraW5nIGZvciBzd3ByaW50Zgpjb25maWd1cmU6NjY2ODogY2MgLW8gY29uZnRlc3QgLU8y IC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSAgLUwv dXNyL2xvY2FsL2xpYiBjb25mdGVzdC5jICA+JjUKY29uZmlndXJlOjY2NzQ6ICQ/ID0gMApjb25m aWd1cmU6NjY5MjogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjY3MDM6IGNoZWNraW5nIGZvciBjbG9j a19nZXR0aW1lCmNvbmZpZ3VyZTo2NzgyOiByZXN1bHQ6IHllcwpjb25maWd1cmU6Njg2NjogY2hl Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IKY29uZmlndXJlOjY5ODI6IHJlc3Vs dDogY3BwCmNvbmZpZ3VyZTo3MDExOiBjcHAgLUkvdXNyL2xvY2FsL2luY2x1ZGUgY29uZnRlc3Qu Ywpjb25maWd1cmU6NzAxNzogJD8gPSAwCmNvbmZpZ3VyZTo3MDQ4OiBjcHAgLUkvdXNyL2xvY2Fs L2luY2x1ZGUgY29uZnRlc3QuYwpjb25mdGVzdC5jOjE5OjI4OiBlcnJvcjogYWNfbm9uZXhpc3Rl bnQuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpjb25maWd1cmU6NzA1NDogJD8gPSAxCmNv bmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZp bmUgUEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRh ZyIKfCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RS SU5HICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJq dGFnLm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0Ug InVyanRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAx CnwgI2RlZmluZSBIQVZFX0lDT05WIDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUg SEFWRV9HRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfRENHRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVf R0VUTElORSAxCnwgI2RlZmluZSBIQVZFX0dFVERFTElNIDEKfCAjZGVmaW5lIEhBVkVfU1dQUklO VEYgMQp8IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KfCAjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQu aD4KY29uZmlndXJlOjcwOTI6IGNoZWNraW5nIGZvciBncmVwIHRoYXQgaGFuZGxlcyBsb25nIGxp bmVzIGFuZCAtZQpjb25maWd1cmU6NzE2NjogcmVzdWx0OiAvdXNyL2Jpbi9ncmVwCmNvbmZpZ3Vy ZTo3MTcxOiBjaGVja2luZyBmb3IgZWdyZXAKY29uZmlndXJlOjcyNDk6IHJlc3VsdDogL3Vzci9i aW4vZWdyZXAKY29uZmlndXJlOjcyNTQ6IGNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVz CmNvbmZpZ3VyZTo3NDE4OiByZXN1bHQ6IHllcwpjb25maWd1cmU6NzQ0MjogY2hlY2tpbmcgZm9y IHN5cy90eXBlcy5oCmNvbmZpZ3VyZTo3NDg1OiByZXN1bHQ6IHllcwpjb25maWd1cmU6NzQ0Mjog Y2hlY2tpbmcgZm9yIHN5cy9zdGF0LmgKY29uZmlndXJlOjc0ODU6IHJlc3VsdDogeWVzCmNvbmZp Z3VyZTo3NDQyOiBjaGVja2luZyBmb3Igc3RkbGliLmgKY29uZmlndXJlOjc0ODU6IHJlc3VsdDog eWVzCmNvbmZpZ3VyZTo3NDQyOiBjaGVja2luZyBmb3Igc3RyaW5nLmgKY29uZmlndXJlOjc0ODU6 IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo3NDQyOiBjaGVja2luZyBmb3IgbWVtb3J5LmgKY29uZmln dXJlOjc0ODU6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo3NDQyOiBjaGVja2luZyBmb3Igc3RyaW5n cy5oCmNvbmZpZ3VyZTo3NDg1OiByZXN1bHQ6IHllcwpjb25maWd1cmU6NzQ0MjogY2hlY2tpbmcg Zm9yIGludHR5cGVzLmgKY29uZmlndXJlOjc0ODU6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo3NDQy OiBjaGVja2luZyBmb3Igc3RkaW50LmgKY29uZmlndXJlOjc0ODU6IHJlc3VsdDogeWVzCmNvbmZp Z3VyZTo3NDQyOiBjaGVja2luZyBmb3IgdW5pc3RkLmgKY29uZmlndXJlOjc0ODU6IHJlc3VsdDog eWVzCmNvbmZpZ3VyZTo3NTEyOiBjaGVja2luZyBsaW51eC9wcGRldi5oIHVzYWJpbGl0eQpjb25m aWd1cmU6NzUyOTogY2MgLWMgLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91 c3IvbG9jYWwvaW5jbHVkZSBjb25mdGVzdC5jID4mNQpjb25mdGVzdC5jOjYyOjI1OiBlcnJvcjog bGludXgvcHBkZXYuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpjb25maWd1cmU6NzUzNTog JD8gPSAxCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAq Lwp8ICNkZWZpbmUgUEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5B TUUgInVyanRhZyIKfCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBB Q0tBR0VfU1RSSU5HICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJo dHRwOi8vdXJqdGFnLm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5l IFBBQ0tBR0UgInVyanRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05V X1NPVVJDRSAxCnwgI2RlZmluZSBIQVZFX0lDT05WIDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8 ICNkZWZpbmUgSEFWRV9HRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfRENHRVRURVhUIDEKfCAjZGVm aW5lIEhBVkVfR0VUTElORSAxCnwgI2RlZmluZSBIQVZFX0dFVERFTElNIDEKfCAjZGVmaW5lIEhB VkVfU1dQUklOVEYgMQp8ICNkZWZpbmUgU1REQ19IRUFERVJTIDEKfCAjZGVmaW5lIEhBVkVfU1lT X1RZUEVTX0ggMQp8ICNkZWZpbmUgSEFWRV9TWVNfU1RBVF9IIDEKfCAjZGVmaW5lIEhBVkVfU1RE TElCX0ggMQp8ICNkZWZpbmUgSEFWRV9TVFJJTkdfSCAxCnwgI2RlZmluZSBIQVZFX01FTU9SWV9I IDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HU19IIDEKfCAjZGVmaW5lIEhBVkVfSU5UVFlQRVNfSCAx CnwgI2RlZmluZSBIQVZFX1NURElOVF9IIDEKfCAjZGVmaW5lIEhBVkVfVU5JU1REX0ggMQp8IC8q IGVuZCBjb25mZGVmcy5oLiAgKi8KfCAjaW5jbHVkZSA8c3RkaW8uaD4KfCAjaWZkZWYgSEFWRV9T WVNfVFlQRVNfSAp8ICMgaW5jbHVkZSA8c3lzL3R5cGVzLmg+CnwgI2VuZGlmCnwgI2lmZGVmIEhB VkVfU1lTX1NUQVRfSAp8ICMgaW5jbHVkZSA8c3lzL3N0YXQuaD4KfCAjZW5kaWYKfCAjaWZkZWYg U1REQ19IRUFERVJTCnwgIyBpbmNsdWRlIDxzdGRsaWIuaD4KfCAjIGluY2x1ZGUgPHN0ZGRlZi5o Pgp8ICNlbHNlCnwgIyBpZmRlZiBIQVZFX1NURExJQl9ICnwgIyAgaW5jbHVkZSA8c3RkbGliLmg+ CnwgIyBlbmRpZgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX1NUUklOR19ICnwgIyBpZiAhZGVmaW5l ZCBTVERDX0hFQURFUlMgJiYgZGVmaW5lZCBIQVZFX01FTU9SWV9ICnwgIyAgaW5jbHVkZSA8bWVt b3J5Lmg+CnwgIyBlbmRpZgp8ICMgaW5jbHVkZSA8c3RyaW5nLmg+CnwgI2VuZGlmCnwgI2lmZGVm IEhBVkVfU1RSSU5HU19ICnwgIyBpbmNsdWRlIDxzdHJpbmdzLmg+CnwgI2VuZGlmCnwgI2lmZGVm IEhBVkVfSU5UVFlQRVNfSAp8ICMgaW5jbHVkZSA8aW50dHlwZXMuaD4KfCAjZW5kaWYKfCAjaWZk ZWYgSEFWRV9TVERJTlRfSAp8ICMgaW5jbHVkZSA8c3RkaW50Lmg+CnwgI2VuZGlmCnwgI2lmZGVm IEhBVkVfVU5JU1REX0gKfCAjIGluY2x1ZGUgPHVuaXN0ZC5oPgp8ICNlbmRpZgp8ICNpbmNsdWRl IDxsaW51eC9wcGRldi5oPgpjb25maWd1cmU6NzU0OTogcmVzdWx0OiBubwpjb25maWd1cmU6NzU1 MzogY2hlY2tpbmcgbGludXgvcHBkZXYuaCBwcmVzZW5jZQpjb25maWd1cmU6NzU2ODogY3BwIC1J L3Vzci9sb2NhbC9pbmNsdWRlIGNvbmZ0ZXN0LmMKY29uZnRlc3QuYzoyOToyNTogZXJyb3I6IGxp bnV4L3BwZGV2Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKY29uZmlndXJlOjc1NzQ6ICQ/ ID0gMQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoKfCAvKiBjb25mZGVmcy5oLiAgKi8K fCAjZGVmaW5lIFBBQ0tBR0VfTkFNRSAiVXJKVEFHIgp8ICNkZWZpbmUgUEFDS0FHRV9UQVJOQU1F ICJ1cmp0YWciCnwgI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBQQUNL QUdFX1NUUklORyAiVXJKVEFHIDAuMTAiCnwgI2RlZmluZSBQQUNLQUdFX0JVR1JFUE9SVCAiaHR0 cDovL3VyanRhZy5vcmciCnwgI2RlZmluZSBTVk5fUkVWSVNJT04gIjE1MDIiCnwgI2RlZmluZSBQ QUNLQUdFICJ1cmp0YWciCnwgI2RlZmluZSBWRVJTSU9OICIwLjEwIgp8ICNkZWZpbmUgX0dOVV9T T1VSQ0UgMQp8ICNkZWZpbmUgSEFWRV9JQ09OViAxCnwgI2RlZmluZSBFTkFCTEVfTkxTIDEKfCAj ZGVmaW5lIEhBVkVfR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZFX0RDR0VUVEVYVCAxCnwgI2RlZmlu ZSBIQVZFX0dFVExJTkUgMQp8ICNkZWZpbmUgSEFWRV9HRVRERUxJTSAxCnwgI2RlZmluZSBIQVZF X1NXUFJJTlRGIDEKfCAjZGVmaW5lIFNURENfSEVBREVSUyAxCnwgI2RlZmluZSBIQVZFX1NZU19U WVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1NUQVRfSCAxCnwgI2RlZmluZSBIQVZFX1NURExJ Ql9IIDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HX0ggMQp8ICNkZWZpbmUgSEFWRV9NRU1PUllfSCAx CnwgI2RlZmluZSBIQVZFX1NUUklOR1NfSCAxCnwgI2RlZmluZSBIQVZFX0lOVFRZUEVTX0ggMQp8 ICNkZWZpbmUgSEFWRV9TVERJTlRfSCAxCnwgI2RlZmluZSBIQVZFX1VOSVNURF9IIDEKfCAvKiBl bmQgY29uZmRlZnMuaC4gICovCnwgI2luY2x1ZGUgPGxpbnV4L3BwZGV2Lmg+CmNvbmZpZ3VyZTo3 NTg4OiByZXN1bHQ6IG5vCmNvbmZpZ3VyZTo3NjIxOiBjaGVja2luZyBmb3IgbGludXgvcHBkZXYu aApjb25maWd1cmU6NzYyOTogcmVzdWx0OiBubwpjb25maWd1cmU6NzY1NzogY2hlY2tpbmcgZGV2 L3BwYnVzL3BwaS5oIHVzYWJpbGl0eQpjb25maWd1cmU6NzY3NDogY2MgLWMgLU8yIC0tc3RkPWM5 OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtSS91c3IvbG9jYWwvaW5jbHVkZSBjb25mdGVzdC5jID4m NQpjb25maWd1cmU6NzY4MDogJD8gPSAwCmNvbmZpZ3VyZTo3Njk0OiByZXN1bHQ6IHllcwpjb25m aWd1cmU6NzY5ODogY2hlY2tpbmcgZGV2L3BwYnVzL3BwaS5oIHByZXNlbmNlCmNvbmZpZ3VyZTo3 NzEzOiBjcHAgLUkvdXNyL2xvY2FsL2luY2x1ZGUgY29uZnRlc3QuYwpjb25maWd1cmU6NzcxOTog JD8gPSAwCmNvbmZpZ3VyZTo3NzMzOiByZXN1bHQ6IHllcwpjb25maWd1cmU6Nzc2NjogY2hlY2tp bmcgZm9yIGRldi9wcGJ1cy9wcGkuaApjb25maWd1cmU6Nzc3NDogcmVzdWx0OiB5ZXMKY29uZmln dXJlOjc4MDI6IGNoZWNraW5nIHN0cm9wdHMuaCB1c2FiaWxpdHkKY29uZmlndXJlOjc4MTk6IGNj IC1jIC1PMiAtLXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1 ZGUgY29uZnRlc3QuYyA+JjUKY29uZnRlc3QuYzo2MzoyMTogZXJyb3I6IHN0cm9wdHMuaDogTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpjb25maWd1cmU6NzgyNTogJD8gPSAxCmNvbmZpZ3VyZTog ZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUgUEFDS0FH RV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIKfCAjZGVm aW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJVckpU QUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFnLm9yZyIK fCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVyanRhZyIK fCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwgI2RlZmlu ZSBIQVZFX0lDT05WIDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFWRV9HRVRU RVhUIDEKfCAjZGVmaW5lIEhBVkVfRENHRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfR0VUTElORSAx CnwgI2RlZmluZSBIQVZFX0dFVERFTElNIDEKfCAjZGVmaW5lIEhBVkVfU1dQUklOVEYgMQp8ICNk ZWZpbmUgU1REQ19IRUFERVJTIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1RZUEVTX0ggMQp8ICNkZWZp bmUgSEFWRV9TWVNfU1RBVF9IIDEKfCAjZGVmaW5lIEhBVkVfU1RETElCX0ggMQp8ICNkZWZpbmUg SEFWRV9TVFJJTkdfSCAxCnwgI2RlZmluZSBIQVZFX01FTU9SWV9IIDEKfCAjZGVmaW5lIEhBVkVf U1RSSU5HU19IIDEKfCAjZGVmaW5lIEhBVkVfSU5UVFlQRVNfSCAxCnwgI2RlZmluZSBIQVZFX1NU RElOVF9IIDEKfCAjZGVmaW5lIEhBVkVfVU5JU1REX0ggMQp8ICNkZWZpbmUgSEFWRV9ERVZfUFBC VVNfUFBJX0ggMQp8IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KfCAjaW5jbHVkZSA8c3RkaW8uaD4K fCAjaWZkZWYgSEFWRV9TWVNfVFlQRVNfSAp8ICMgaW5jbHVkZSA8c3lzL3R5cGVzLmg+CnwgI2Vu ZGlmCnwgI2lmZGVmIEhBVkVfU1lTX1NUQVRfSAp8ICMgaW5jbHVkZSA8c3lzL3N0YXQuaD4KfCAj ZW5kaWYKfCAjaWZkZWYgU1REQ19IRUFERVJTCnwgIyBpbmNsdWRlIDxzdGRsaWIuaD4KfCAjIGlu Y2x1ZGUgPHN0ZGRlZi5oPgp8ICNlbHNlCnwgIyBpZmRlZiBIQVZFX1NURExJQl9ICnwgIyAgaW5j bHVkZSA8c3RkbGliLmg+CnwgIyBlbmRpZgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX1NUUklOR19I CnwgIyBpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMgJiYgZGVmaW5lZCBIQVZFX01FTU9SWV9ICnwg IyAgaW5jbHVkZSA8bWVtb3J5Lmg+CnwgIyBlbmRpZgp8ICMgaW5jbHVkZSA8c3RyaW5nLmg+Cnwg I2VuZGlmCnwgI2lmZGVmIEhBVkVfU1RSSU5HU19ICnwgIyBpbmNsdWRlIDxzdHJpbmdzLmg+Cnwg I2VuZGlmCnwgI2lmZGVmIEhBVkVfSU5UVFlQRVNfSAp8ICMgaW5jbHVkZSA8aW50dHlwZXMuaD4K fCAjZW5kaWYKfCAjaWZkZWYgSEFWRV9TVERJTlRfSAp8ICMgaW5jbHVkZSA8c3RkaW50Lmg+Cnwg I2VuZGlmCnwgI2lmZGVmIEhBVkVfVU5JU1REX0gKfCAjIGluY2x1ZGUgPHVuaXN0ZC5oPgp8ICNl bmRpZgp8ICNpbmNsdWRlIDxzdHJvcHRzLmg+CmNvbmZpZ3VyZTo3ODM5OiByZXN1bHQ6IG5vCmNv bmZpZ3VyZTo3ODQzOiBjaGVja2luZyBzdHJvcHRzLmggcHJlc2VuY2UKY29uZmlndXJlOjc4NTg6 IGNwcCAtSS91c3IvbG9jYWwvaW5jbHVkZSBjb25mdGVzdC5jCmNvbmZ0ZXN0LmM6MzA6MjE6IGVy cm9yOiBzdHJvcHRzLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKY29uZmlndXJlOjc4NjQ6 ICQ/ID0gMQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoKfCAvKiBjb25mZGVmcy5oLiAg Ki8KfCAjZGVmaW5lIFBBQ0tBR0VfTkFNRSAiVXJKVEFHIgp8ICNkZWZpbmUgUEFDS0FHRV9UQVJO QU1FICJ1cmp0YWciCnwgI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBQ QUNLQUdFX1NUUklORyAiVXJKVEFHIDAuMTAiCnwgI2RlZmluZSBQQUNLQUdFX0JVR1JFUE9SVCAi aHR0cDovL3VyanRhZy5vcmciCnwgI2RlZmluZSBTVk5fUkVWSVNJT04gIjE1MDIiCnwgI2RlZmlu ZSBQQUNLQUdFICJ1cmp0YWciCnwgI2RlZmluZSBWRVJTSU9OICIwLjEwIgp8ICNkZWZpbmUgX0dO VV9TT1VSQ0UgMQp8ICNkZWZpbmUgSEFWRV9JQ09OViAxCnwgI2RlZmluZSBFTkFCTEVfTkxTIDEK fCAjZGVmaW5lIEhBVkVfR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZFX0RDR0VUVEVYVCAxCnwgI2Rl ZmluZSBIQVZFX0dFVExJTkUgMQp8ICNkZWZpbmUgSEFWRV9HRVRERUxJTSAxCnwgI2RlZmluZSBI QVZFX1NXUFJJTlRGIDEKfCAjZGVmaW5lIFNURENfSEVBREVSUyAxCnwgI2RlZmluZSBIQVZFX1NZ U19UWVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1NUQVRfSCAxCnwgI2RlZmluZSBIQVZFX1NU RExJQl9IIDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HX0ggMQp8ICNkZWZpbmUgSEFWRV9NRU1PUllf SCAxCnwgI2RlZmluZSBIQVZFX1NUUklOR1NfSCAxCnwgI2RlZmluZSBIQVZFX0lOVFRZUEVTX0gg MQp8ICNkZWZpbmUgSEFWRV9TVERJTlRfSCAxCnwgI2RlZmluZSBIQVZFX1VOSVNURF9IIDEKfCAj ZGVmaW5lIEhBVkVfREVWX1BQQlVTX1BQSV9IIDEKfCAvKiBlbmQgY29uZmRlZnMuaC4gICovCnwg I2luY2x1ZGUgPHN0cm9wdHMuaD4KY29uZmlndXJlOjc4Nzg6IHJlc3VsdDogbm8KY29uZmlndXJl Ojc5MTE6IGNoZWNraW5nIGZvciBzdHJvcHRzLmgKY29uZmlndXJlOjc5MTk6IHJlc3VsdDogbm8K Y29uZmlndXJlOjc5Mzc6IGNoZWNraW5nIGZvciB3Y2hhci5oCmNvbmZpZ3VyZTo3OTQzOiByZXN1 bHQ6IHllcwpjb25maWd1cmU6ODA3OTogY2hlY2tpbmcgZm9yIGEgcmVhZGxpbmUgY29tcGF0aWJs ZSBsaWJyYXJ5CmNvbmZpZ3VyZTo4MTIyOiBjYyAtbyBjb25mdGVzdCAtTzIgLS1zdGQ9Yzk5IC1m bm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNsdWRlICAtTC91c3IvbG9jYWwvbGli IGNvbmZ0ZXN0LmMgIC1scmVhZGxpbmUgPiY1CmNvbmZpZ3VyZTo4MTI4OiAkPyA9IDAKY29uZmln dXJlOjgxNTg6IHJlc3VsdDogLWxyZWFkbGluZQpjb25maWd1cmU6ODE4MzogY2hlY2tpbmcgcmVh ZGxpbmUuaCB1c2FiaWxpdHkKY29uZmlndXJlOjgyMDA6IGNjIC1jIC1PMiAtLXN0ZD1jOTkgLWZu by1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgY29uZnRlc3QuYyA+JjUKY29u ZnRlc3QuYzo2NToyMjogZXJyb3I6IHJlYWRsaW5lLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkKY29uZmlndXJlOjgyMDY6ICQ/ID0gMQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoK fCAvKiBjb25mZGVmcy5oLiAgKi8KfCAjZGVmaW5lIFBBQ0tBR0VfTkFNRSAiVXJKVEFHIgp8ICNk ZWZpbmUgUEFDS0FHRV9UQVJOQU1FICJ1cmp0YWciCnwgI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04g IjAuMTAiCnwgI2RlZmluZSBQQUNLQUdFX1NUUklORyAiVXJKVEFHIDAuMTAiCnwgI2RlZmluZSBQ QUNLQUdFX0JVR1JFUE9SVCAiaHR0cDovL3VyanRhZy5vcmciCnwgI2RlZmluZSBTVk5fUkVWSVNJ T04gIjE1MDIiCnwgI2RlZmluZSBQQUNLQUdFICJ1cmp0YWciCnwgI2RlZmluZSBWRVJTSU9OICIw LjEwIgp8ICNkZWZpbmUgX0dOVV9TT1VSQ0UgMQp8ICNkZWZpbmUgSEFWRV9JQ09OViAxCnwgI2Rl ZmluZSBFTkFCTEVfTkxTIDEKfCAjZGVmaW5lIEhBVkVfR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZF X0RDR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZFX0dFVExJTkUgMQp8ICNkZWZpbmUgSEFWRV9HRVRE RUxJTSAxCnwgI2RlZmluZSBIQVZFX1NXUFJJTlRGIDEKfCAjZGVmaW5lIFNURENfSEVBREVSUyAx CnwgI2RlZmluZSBIQVZFX1NZU19UWVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1NUQVRfSCAx CnwgI2RlZmluZSBIQVZFX1NURExJQl9IIDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HX0ggMQp8ICNk ZWZpbmUgSEFWRV9NRU1PUllfSCAxCnwgI2RlZmluZSBIQVZFX1NUUklOR1NfSCAxCnwgI2RlZmlu ZSBIQVZFX0lOVFRZUEVTX0ggMQp8ICNkZWZpbmUgSEFWRV9TVERJTlRfSCAxCnwgI2RlZmluZSBI QVZFX1VOSVNURF9IIDEKfCAjZGVmaW5lIEhBVkVfREVWX1BQQlVTX1BQSV9IIDEKfCAjZGVmaW5l IEhBVkVfV0NIQVJfSCAxCnwgI2RlZmluZSBIQVZFX0xJQlJFQURMSU5FIDEKfCAvKiBlbmQgY29u ZmRlZnMuaC4gICovCnwgI2luY2x1ZGUgPHN0ZGlvLmg+CnwgI2lmZGVmIEhBVkVfU1lTX1RZUEVT X0gKfCAjIGluY2x1ZGUgPHN5cy90eXBlcy5oPgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX1NZU19T VEFUX0gKfCAjIGluY2x1ZGUgPHN5cy9zdGF0Lmg+CnwgI2VuZGlmCnwgI2lmZGVmIFNURENfSEVB REVSUwp8ICMgaW5jbHVkZSA8c3RkbGliLmg+CnwgIyBpbmNsdWRlIDxzdGRkZWYuaD4KfCAjZWxz ZQp8ICMgaWZkZWYgSEFWRV9TVERMSUJfSAp8ICMgIGluY2x1ZGUgPHN0ZGxpYi5oPgp8ICMgZW5k aWYKfCAjZW5kaWYKfCAjaWZkZWYgSEFWRV9TVFJJTkdfSAp8ICMgaWYgIWRlZmluZWQgU1REQ19I RUFERVJTICYmIGRlZmluZWQgSEFWRV9NRU1PUllfSAp8ICMgIGluY2x1ZGUgPG1lbW9yeS5oPgp8 ICMgZW5kaWYKfCAjIGluY2x1ZGUgPHN0cmluZy5oPgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX1NU UklOR1NfSAp8ICMgaW5jbHVkZSA8c3RyaW5ncy5oPgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX0lO VFRZUEVTX0gKfCAjIGluY2x1ZGUgPGludHR5cGVzLmg+CnwgI2VuZGlmCnwgI2lmZGVmIEhBVkVf U1RESU5UX0gKfCAjIGluY2x1ZGUgPHN0ZGludC5oPgp8ICNlbmRpZgp8ICNpZmRlZiBIQVZFX1VO SVNURF9ICnwgIyBpbmNsdWRlIDx1bmlzdGQuaD4KfCAjZW5kaWYKfCAjaW5jbHVkZSA8cmVhZGxp bmUuaD4KY29uZmlndXJlOjgyMjA6IHJlc3VsdDogbm8KY29uZmlndXJlOjgyMjQ6IGNoZWNraW5n IHJlYWRsaW5lLmggcHJlc2VuY2UKY29uZmlndXJlOjgyMzk6IGNwcCAtSS91c3IvbG9jYWwvaW5j bHVkZSBjb25mdGVzdC5jCmNvbmZ0ZXN0LmM6MzI6MjI6IGVycm9yOiByZWFkbGluZS5oOiBObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5CmNvbmZpZ3VyZTo4MjQ1OiAkPyA9IDEKY29uZmlndXJlOiBm YWlsZWQgcHJvZ3JhbSB3YXM6CnwgLyogY29uZmRlZnMuaC4gICovCnwgI2RlZmluZSBQQUNLQUdF X05BTUUgIlVySlRBRyIKfCAjZGVmaW5lIFBBQ0tBR0VfVEFSTkFNRSAidXJqdGFnIgp8ICNkZWZp bmUgUEFDS0FHRV9WRVJTSU9OICIwLjEwIgp8ICNkZWZpbmUgUEFDS0FHRV9TVFJJTkcgIlVySlRB RyAwLjEwIgp8ICNkZWZpbmUgUEFDS0FHRV9CVUdSRVBPUlQgImh0dHA6Ly91cmp0YWcub3JnIgp8 ICNkZWZpbmUgU1ZOX1JFVklTSU9OICIxNTAyIgp8ICNkZWZpbmUgUEFDS0FHRSAidXJqdGFnIgp8 ICNkZWZpbmUgVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIF9HTlVfU09VUkNFIDEKfCAjZGVmaW5l IEhBVkVfSUNPTlYgMQp8ICNkZWZpbmUgRU5BQkxFX05MUyAxCnwgI2RlZmluZSBIQVZFX0dFVFRF WFQgMQp8ICNkZWZpbmUgSEFWRV9EQ0dFVFRFWFQgMQp8ICNkZWZpbmUgSEFWRV9HRVRMSU5FIDEK fCAjZGVmaW5lIEhBVkVfR0VUREVMSU0gMQp8ICNkZWZpbmUgSEFWRV9TV1BSSU5URiAxCnwgI2Rl ZmluZSBTVERDX0hFQURFUlMgMQp8ICNkZWZpbmUgSEFWRV9TWVNfVFlQRVNfSCAxCnwgI2RlZmlu ZSBIQVZFX1NZU19TVEFUX0ggMQp8ICNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCnwgI2RlZmluZSBI QVZFX1NUUklOR19IIDEKfCAjZGVmaW5lIEhBVkVfTUVNT1JZX0ggMQp8ICNkZWZpbmUgSEFWRV9T VFJJTkdTX0ggMQp8ICNkZWZpbmUgSEFWRV9JTlRUWVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1RE SU5UX0ggMQp8ICNkZWZpbmUgSEFWRV9VTklTVERfSCAxCnwgI2RlZmluZSBIQVZFX0RFVl9QUEJV U19QUElfSCAxCnwgI2RlZmluZSBIQVZFX1dDSEFSX0ggMQp8ICNkZWZpbmUgSEFWRV9MSUJSRUFE TElORSAxCnwgLyogZW5kIGNvbmZkZWZzLmguICAqLwp8ICNpbmNsdWRlIDxyZWFkbGluZS5oPgpj b25maWd1cmU6ODI1OTogcmVzdWx0OiBubwpjb25maWd1cmU6ODI5MjogY2hlY2tpbmcgZm9yIHJl YWRsaW5lLmgKY29uZmlndXJlOjgzMDA6IHJlc3VsdDogbm8KY29uZmlndXJlOjgxODM6IGNoZWNr aW5nIHJlYWRsaW5lL3JlYWRsaW5lLmggdXNhYmlsaXR5CmNvbmZpZ3VyZTo4MjAwOiBjYyAtYyAt TzIgLS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNsdWRlIGNv bmZ0ZXN0LmMgPiY1CmNvbmZpZ3VyZTo4MjA2OiAkPyA9IDAKY29uZmlndXJlOjgyMjA6IHJlc3Vs dDogeWVzCmNvbmZpZ3VyZTo4MjI0OiBjaGVja2luZyByZWFkbGluZS9yZWFkbGluZS5oIHByZXNl bmNlCmNvbmZpZ3VyZTo4MjM5OiBjcHAgLUkvdXNyL2xvY2FsL2luY2x1ZGUgY29uZnRlc3QuYwpj b25maWd1cmU6ODI0NTogJD8gPSAwCmNvbmZpZ3VyZTo4MjU5OiByZXN1bHQ6IHllcwpjb25maWd1 cmU6ODI5MjogY2hlY2tpbmcgZm9yIHJlYWRsaW5lL3JlYWRsaW5lLmgKY29uZmlndXJlOjgzMDA6 IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo4MzEzOiBjaGVja2luZyB3aGV0aGVyIHJlYWRsaW5lIHN1 cHBvcnRzIGhpc3RvcnkKY29uZmlndXJlOjgzNDc6IGNjIC1vIGNvbmZ0ZXN0IC1PMiAtLXN0ZD1j OTkgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgIC1ML3Vzci9sb2Nh bC9saWIgY29uZnRlc3QuYyAgLWxyZWFkbGluZSA+JjUKY29uZmlndXJlOjgzNTM6ICQ/ID0gMApj b25maWd1cmU6ODM3MDogcmVzdWx0OiB5ZXMKY29uZmlndXJlOjgzOTQ6IGNoZWNraW5nIGhpc3Rv cnkuaCB1c2FiaWxpdHkKY29uZmlndXJlOjg0MTE6IGNjIC1jIC1PMiAtLXN0ZD1jOTkgLWZuby1z dHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUgY29uZnRlc3QuYyA+JjUKY29uZnRl c3QuYzo2NzoyMTogZXJyb3I6IGhpc3RvcnkuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpj b25maWd1cmU6ODQxNzogJD8gPSAxCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8q IGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUgUEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmlu ZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIKfCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4x MCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tB R0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFnLm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAi MTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVyanRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAi CnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwgI2RlZmluZSBIQVZFX0lDT05WIDEKfCAjZGVmaW5l IEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFWRV9HRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfRENH RVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfR0VUTElORSAxCnwgI2RlZmluZSBIQVZFX0dFVERFTElN IDEKfCAjZGVmaW5lIEhBVkVfU1dQUklOVEYgMQp8ICNkZWZpbmUgU1REQ19IRUFERVJTIDEKfCAj ZGVmaW5lIEhBVkVfU1lTX1RZUEVTX0ggMQp8ICNkZWZpbmUgSEFWRV9TWVNfU1RBVF9IIDEKfCAj ZGVmaW5lIEhBVkVfU1RETElCX0ggMQp8ICNkZWZpbmUgSEFWRV9TVFJJTkdfSCAxCnwgI2RlZmlu ZSBIQVZFX01FTU9SWV9IIDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HU19IIDEKfCAjZGVmaW5lIEhB VkVfSU5UVFlQRVNfSCAxCnwgI2RlZmluZSBIQVZFX1NURElOVF9IIDEKfCAjZGVmaW5lIEhBVkVf VU5JU1REX0ggMQp8ICNkZWZpbmUgSEFWRV9ERVZfUFBCVVNfUFBJX0ggMQp8ICNkZWZpbmUgSEFW RV9XQ0hBUl9IIDEKfCAjZGVmaW5lIEhBVkVfTElCUkVBRExJTkUgMQp8ICNkZWZpbmUgSEFWRV9S RUFETElORV9SRUFETElORV9IIDEKfCAjZGVmaW5lIEhBVkVfUkVBRExJTkVfSElTVE9SWSAxCnwg LyogZW5kIGNvbmZkZWZzLmguICAqLwp8ICNpbmNsdWRlIDxzdGRpby5oPgp8ICNpZmRlZiBIQVZF X1NZU19UWVBFU19ICnwgIyBpbmNsdWRlIDxzeXMvdHlwZXMuaD4KfCAjZW5kaWYKfCAjaWZkZWYg SEFWRV9TWVNfU1RBVF9ICnwgIyBpbmNsdWRlIDxzeXMvc3RhdC5oPgp8ICNlbmRpZgp8ICNpZmRl ZiBTVERDX0hFQURFUlMKfCAjIGluY2x1ZGUgPHN0ZGxpYi5oPgp8ICMgaW5jbHVkZSA8c3RkZGVm Lmg+CnwgI2Vsc2UKfCAjIGlmZGVmIEhBVkVfU1RETElCX0gKfCAjICBpbmNsdWRlIDxzdGRsaWIu aD4KfCAjIGVuZGlmCnwgI2VuZGlmCnwgI2lmZGVmIEhBVkVfU1RSSU5HX0gKfCAjIGlmICFkZWZp bmVkIFNURENfSEVBREVSUyAmJiBkZWZpbmVkIEhBVkVfTUVNT1JZX0gKfCAjICBpbmNsdWRlIDxt ZW1vcnkuaD4KfCAjIGVuZGlmCnwgIyBpbmNsdWRlIDxzdHJpbmcuaD4KfCAjZW5kaWYKfCAjaWZk ZWYgSEFWRV9TVFJJTkdTX0gKfCAjIGluY2x1ZGUgPHN0cmluZ3MuaD4KfCAjZW5kaWYKfCAjaWZk ZWYgSEFWRV9JTlRUWVBFU19ICnwgIyBpbmNsdWRlIDxpbnR0eXBlcy5oPgp8ICNlbmRpZgp8ICNp ZmRlZiBIQVZFX1NURElOVF9ICnwgIyBpbmNsdWRlIDxzdGRpbnQuaD4KfCAjZW5kaWYKfCAjaWZk ZWYgSEFWRV9VTklTVERfSAp8ICMgaW5jbHVkZSA8dW5pc3RkLmg+CnwgI2VuZGlmCnwgI2luY2x1 ZGUgPGhpc3RvcnkuaD4KY29uZmlndXJlOjg0MzE6IHJlc3VsdDogbm8KY29uZmlndXJlOjg0MzU6 IGNoZWNraW5nIGhpc3RvcnkuaCBwcmVzZW5jZQpjb25maWd1cmU6ODQ1MDogY3BwIC1JL3Vzci9s b2NhbC9pbmNsdWRlIGNvbmZ0ZXN0LmMKY29uZnRlc3QuYzozNDoyMTogZXJyb3I6IGhpc3Rvcnku aDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpjb25maWd1cmU6ODQ1NjogJD8gPSAxCmNvbmZp Z3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOgp8IC8qIGNvbmZkZWZzLmguICAqLwp8ICNkZWZpbmUg UEFDS0FHRV9OQU1FICJVckpUQUciCnwgI2RlZmluZSBQQUNLQUdFX1RBUk5BTUUgInVyanRhZyIK fCAjZGVmaW5lIFBBQ0tBR0VfVkVSU0lPTiAiMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5H ICJVckpUQUcgMC4xMCIKfCAjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICJodHRwOi8vdXJqdGFn Lm9yZyIKfCAjZGVmaW5lIFNWTl9SRVZJU0lPTiAiMTUwMiIKfCAjZGVmaW5lIFBBQ0tBR0UgInVy anRhZyIKfCAjZGVmaW5lIFZFUlNJT04gIjAuMTAiCnwgI2RlZmluZSBfR05VX1NPVVJDRSAxCnwg I2RlZmluZSBIQVZFX0lDT05WIDEKfCAjZGVmaW5lIEVOQUJMRV9OTFMgMQp8ICNkZWZpbmUgSEFW RV9HRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfRENHRVRURVhUIDEKfCAjZGVmaW5lIEhBVkVfR0VU TElORSAxCnwgI2RlZmluZSBIQVZFX0dFVERFTElNIDEKfCAjZGVmaW5lIEhBVkVfU1dQUklOVEYg MQp8ICNkZWZpbmUgU1REQ19IRUFERVJTIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1RZUEVTX0ggMQp8 ICNkZWZpbmUgSEFWRV9TWVNfU1RBVF9IIDEKfCAjZGVmaW5lIEhBVkVfU1RETElCX0ggMQp8ICNk ZWZpbmUgSEFWRV9TVFJJTkdfSCAxCnwgI2RlZmluZSBIQVZFX01FTU9SWV9IIDEKfCAjZGVmaW5l IEhBVkVfU1RSSU5HU19IIDEKfCAjZGVmaW5lIEhBVkVfSU5UVFlQRVNfSCAxCnwgI2RlZmluZSBI QVZFX1NURElOVF9IIDEKfCAjZGVmaW5lIEhBVkVfVU5JU1REX0ggMQp8ICNkZWZpbmUgSEFWRV9E RVZfUFBCVVNfUFBJX0ggMQp8ICNkZWZpbmUgSEFWRV9XQ0hBUl9IIDEKfCAjZGVmaW5lIEhBVkVf TElCUkVBRExJTkUgMQp8ICNkZWZpbmUgSEFWRV9SRUFETElORV9SRUFETElORV9IIDEKfCAjZGVm aW5lIEhBVkVfUkVBRExJTkVfSElTVE9SWSAxCnwgLyogZW5kIGNvbmZkZWZzLmguICAqLwp8ICNp bmNsdWRlIDxoaXN0b3J5Lmg+CmNvbmZpZ3VyZTo4NDcwOiByZXN1bHQ6IG5vCmNvbmZpZ3VyZTo4 NTAzOiBjaGVja2luZyBmb3IgaGlzdG9yeS5oCmNvbmZpZ3VyZTo4NTExOiByZXN1bHQ6IG5vCmNv bmZpZ3VyZTo4Mzk0OiBjaGVja2luZyByZWFkbGluZS9oaXN0b3J5LmggdXNhYmlsaXR5CmNvbmZp Z3VyZTo4NDExOiBjYyAtYyAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vz ci9sb2NhbC9pbmNsdWRlIGNvbmZ0ZXN0LmMgPiY1CmNvbmZpZ3VyZTo4NDE3OiAkPyA9IDAKY29u ZmlndXJlOjg0MzE6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo4NDM1OiBjaGVja2luZyByZWFkbGlu ZS9oaXN0b3J5LmggcHJlc2VuY2UKY29uZmlndXJlOjg0NTA6IGNwcCAtSS91c3IvbG9jYWwvaW5j bHVkZSBjb25mdGVzdC5jCmNvbmZpZ3VyZTo4NDU2OiAkPyA9IDAKY29uZmlndXJlOjg0NzA6IHJl c3VsdDogeWVzCmNvbmZpZ3VyZTo4NTAzOiBjaGVja2luZyBmb3IgcmVhZGxpbmUvaGlzdG9yeS5o CmNvbmZpZ3VyZTo4NTExOiByZXN1bHQ6IHllcwpjb25maWd1cmU6ODUyNjogY2hlY2tpbmcgd2hl dGhlciByZWFkbGluZSBzdXBwb3J0cyBjb21wbGV0aW9uCmNvbmZpZ3VyZTo4NTYwOiBjYyAtbyBj b25mdGVzdCAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9p bmNsdWRlICAtTC91c3IvbG9jYWwvbGliIGNvbmZ0ZXN0LmMgIC1scmVhZGxpbmUgPiY1CmNvbmZp Z3VyZTo4NTY2OiAkPyA9IDAKY29uZmlndXJlOjg1ODM6IHJlc3VsdDogeWVzCmNvbmZpZ3VyZTo4 Njc2OiBjaGVja2luZyBmb3IgbGlidXNiLWNvbmZpZwpjb25maWd1cmU6ODcwOTogcmVzdWx0OiBu bwpjb25maWd1cmU6ODc0NDogY2hlY2tpbmcgZm9yIHVzYl9maW5kX2RldmljZXMKY29uZmlndXJl Ojg4MDA6IGNjIC1vIGNvbmZ0ZXN0IC1PMiAtLXN0ZD1jOTkgLWZuby1zdHJpY3QtYWxpYXNpbmcg LUkvdXNyL2xvY2FsL2luY2x1ZGUgICAtTC91c3IvbG9jYWwvbGliIGNvbmZ0ZXN0LmMgIC1scmVh ZGxpbmUgID4mNQovdG1wLy9jY3E4ekFzcy5vOiBJbiBmdW5jdGlvbiBgbWFpbic6CmNvbmZ0ZXN0 LmM6KC50ZXh0KzB4Nyk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYHVzYl9maW5kX2RldmljZXMn CmNvbmZpZ3VyZTo4ODA2OiAkPyA9IDEKY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6Cnwg LyogY29uZmRlZnMuaC4gICovCnwgI2RlZmluZSBQQUNLQUdFX05BTUUgIlVySlRBRyIKfCAjZGVm aW5lIFBBQ0tBR0VfVEFSTkFNRSAidXJqdGFnIgp8ICNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIw LjEwIgp8ICNkZWZpbmUgUEFDS0FHRV9TVFJJTkcgIlVySlRBRyAwLjEwIgp8ICNkZWZpbmUgUEFD S0FHRV9CVUdSRVBPUlQgImh0dHA6Ly91cmp0YWcub3JnIgp8ICNkZWZpbmUgU1ZOX1JFVklTSU9O ICIxNTAyIgp8ICNkZWZpbmUgUEFDS0FHRSAidXJqdGFnIgp8ICNkZWZpbmUgVkVSU0lPTiAiMC4x MCIKfCAjZGVmaW5lIF9HTlVfU09VUkNFIDEKfCAjZGVmaW5lIEhBVkVfSUNPTlYgMQp8ICNkZWZp bmUgRU5BQkxFX05MUyAxCnwgI2RlZmluZSBIQVZFX0dFVFRFWFQgMQp8ICNkZWZpbmUgSEFWRV9E Q0dFVFRFWFQgMQp8ICNkZWZpbmUgSEFWRV9HRVRMSU5FIDEKfCAjZGVmaW5lIEhBVkVfR0VUREVM SU0gMQp8ICNkZWZpbmUgSEFWRV9TV1BSSU5URiAxCnwgI2RlZmluZSBTVERDX0hFQURFUlMgMQp8 ICNkZWZpbmUgSEFWRV9TWVNfVFlQRVNfSCAxCnwgI2RlZmluZSBIQVZFX1NZU19TVEFUX0ggMQp8 ICNkZWZpbmUgSEFWRV9TVERMSUJfSCAxCnwgI2RlZmluZSBIQVZFX1NUUklOR19IIDEKfCAjZGVm aW5lIEhBVkVfTUVNT1JZX0ggMQp8ICNkZWZpbmUgSEFWRV9TVFJJTkdTX0ggMQp8ICNkZWZpbmUg SEFWRV9JTlRUWVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1RESU5UX0ggMQp8ICNkZWZpbmUgSEFW RV9VTklTVERfSCAxCnwgI2RlZmluZSBIQVZFX0RFVl9QUEJVU19QUElfSCAxCnwgI2RlZmluZSBI QVZFX1dDSEFSX0ggMQp8ICNkZWZpbmUgSEFWRV9MSUJSRUFETElORSAxCnwgI2RlZmluZSBIQVZF X1JFQURMSU5FX1JFQURMSU5FX0ggMQp8ICNkZWZpbmUgSEFWRV9SRUFETElORV9ISVNUT1JZIDEK fCAjZGVmaW5lIEhBVkVfUkVBRExJTkVfSElTVE9SWV9IIDEKfCAjZGVmaW5lIEhBVkVfUkVBRExJ TkVfQ09NUExFVElPTiAxCnwgLyogZW5kIGNvbmZkZWZzLmguICAqLwp8IC8qIERlZmluZSB1c2Jf ZmluZF9kZXZpY2VzIHRvIGFuIGlubm9jdW91cyB2YXJpYW50LCBpbiBjYXNlIDxsaW1pdHMuaD4g ZGVjbGFyZXMgdXNiX2ZpbmRfZGV2aWNlcy4KfCAgICBGb3IgZXhhbXBsZSwgSFAtVVggMTFpIDxs aW1pdHMuaD4gZGVjbGFyZXMgZ2V0dGltZW9mZGF5LiAgKi8KfCAjZGVmaW5lIHVzYl9maW5kX2Rl dmljZXMgaW5ub2N1b3VzX3VzYl9maW5kX2RldmljZXMKfCAKfCAvKiBTeXN0ZW0gaGVhZGVyIHRv IGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsCnwgICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgdXNiX2ZpbmRfZGV2aWNlcyAoKTsgYmVsb3cu CnwgICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVm aW5lZCwgc2luY2UKfCAgICAgPGxpbWl0cy5oPiBleGlzdHMgZXZlbiBvbiBmcmVlc3RhbmRpbmcg Y29tcGlsZXJzLiAgKi8KfCAKfCAjaWZkZWYgX19TVERDX18KfCAjIGluY2x1ZGUgPGxpbWl0cy5o Pgp8ICNlbHNlCnwgIyBpbmNsdWRlIDxhc3NlcnQuaD4KfCAjZW5kaWYKfCAKfCAjdW5kZWYgdXNi X2ZpbmRfZGV2aWNlcwp8IAp8IC8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl IHRvIGF2b2lkIGFuIGVycm9yLgp8ICAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNo IHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQwp8ICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCnwgI2lmZGVmIF9fY3BsdXNwbHVz CnwgZXh0ZXJuICJDIgp8ICNlbmRpZgp8IGNoYXIgdXNiX2ZpbmRfZGV2aWNlcyAoKTsKfCAvKiBU aGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzCnwgICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMg YXJlIGFjdHVhbGx5IG5hbWVkCnwgICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0 aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLwp8ICNpZiBkZWZpbmVkIF9fc3R1Yl91c2Jf ZmluZF9kZXZpY2VzIHx8IGRlZmluZWQgX19zdHViX19fdXNiX2ZpbmRfZGV2aWNlcwp8IGNob2tl IG1lCnwgI2VuZGlmCnwgCnwgaW50CnwgbWFpbiAoKQp8IHsKfCByZXR1cm4gdXNiX2ZpbmRfZGV2 aWNlcyAoKTsKfCAgIDsKfCAgIHJldHVybiAwOwp8IH0KY29uZmlndXJlOjg4MjM6IHJlc3VsdDog bm8KY29uZmlndXJlOjg4MzY6IFdBUk5JTkc6ICoqKiBsaWJ1c2Igbm90IGRldGVjdGVkLiBObyBz dXBwb3J0IGZvciBVU0IgSlRBRyBjYWJsZXMgdmlhIGxpYnVzYi4KY29uZmlndXJlOjg5NDA6IGNo ZWNraW5nIGZvciBsaWJmdGRpLWNvbmZpZwpjb25maWd1cmU6ODk1ODogZm91bmQgL3Vzci9sb2Nh bC9iaW4vbGliZnRkaS1jb25maWcKY29uZmlndXJlOjg5NzA6IHJlc3VsdDogL3Vzci9sb2NhbC9i aW4vbGliZnRkaS1jb25maWcKY29uZmlndXJlOjkwMDg6IGNoZWNraW5nIGZvciBmdGRpX3VzYl9v cGVuCmNvbmZpZ3VyZTo5MDY0OiBjYyAtbyBjb25mdGVzdCAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3Ry aWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNsdWRlIC1JL3Vzci9sb2NhbC9pbmNsdWRlICAt TC91c3IvbG9jYWwvbGliIGNvbmZ0ZXN0LmMgLUwvdXNyL2xvY2FsL2xpYiAtbGZ0ZGkgLWx1c2Ig IC1scmVhZGxpbmUgPiY1CmNvbmZpZ3VyZTo5MDcwOiAkPyA9IDAKY29uZmlndXJlOjkwODc6IHJl c3VsdDogeWVzCmNvbmZpZ3VyZTo5MTUwOiBjaGVja2luZyBmb3IgRlRfT3BlbkV4IGluIC1sZnRk Mnh4CmNvbmZpZ3VyZTo5MTg1OiBjYyAtbyBjb25mdGVzdCAtTzIgLS1zdGQ9Yzk5IC1mbm8tc3Ry aWN0LWFsaWFzaW5nIC1JL3Vzci9sb2NhbC9pbmNsdWRlIC1JL3Vzci9sb2NhbC9pbmNsdWRlICAt TC91c3IvbG9jYWwvbGliIGNvbmZ0ZXN0LmMgLWxmdGQyeHggIC1ML3Vzci9sb2NhbC9saWIgLWxm dGRpIC1sdXNiICAtbHJlYWRsaW5lID4mNQovdXNyL2Jpbi9sZDogY2Fubm90IGZpbmQgLWxmdGQy eHgKY29uZmlndXJlOjkxOTE6ICQ/ID0gMQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoK fCAvKiBjb25mZGVmcy5oLiAgKi8KfCAjZGVmaW5lIFBBQ0tBR0VfTkFNRSAiVXJKVEFHIgp8ICNk ZWZpbmUgUEFDS0FHRV9UQVJOQU1FICJ1cmp0YWciCnwgI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04g IjAuMTAiCnwgI2RlZmluZSBQQUNLQUdFX1NUUklORyAiVXJKVEFHIDAuMTAiCnwgI2RlZmluZSBQ QUNLQUdFX0JVR1JFUE9SVCAiaHR0cDovL3VyanRhZy5vcmciCnwgI2RlZmluZSBTVk5fUkVWSVNJ T04gIjE1MDIiCnwgI2RlZmluZSBQQUNLQUdFICJ1cmp0YWciCnwgI2RlZmluZSBWRVJTSU9OICIw LjEwIgp8ICNkZWZpbmUgX0dOVV9TT1VSQ0UgMQp8ICNkZWZpbmUgSEFWRV9JQ09OViAxCnwgI2Rl ZmluZSBFTkFCTEVfTkxTIDEKfCAjZGVmaW5lIEhBVkVfR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZF X0RDR0VUVEVYVCAxCnwgI2RlZmluZSBIQVZFX0dFVExJTkUgMQp8ICNkZWZpbmUgSEFWRV9HRVRE RUxJTSAxCnwgI2RlZmluZSBIQVZFX1NXUFJJTlRGIDEKfCAjZGVmaW5lIFNURENfSEVBREVSUyAx CnwgI2RlZmluZSBIQVZFX1NZU19UWVBFU19IIDEKfCAjZGVmaW5lIEhBVkVfU1lTX1NUQVRfSCAx CnwgI2RlZmluZSBIQVZFX1NURExJQl9IIDEKfCAjZGVmaW5lIEhBVkVfU1RSSU5HX0ggMQp8ICNk ZWZpbmUgSEFWRV9NRU1PUllfSCAxCnwgI2RlZmluZSBIQVZFX1NUUklOR1NfSCAxCnwgI2RlZmlu ZSBIQVZFX0lOVFRZUEVTX0ggMQp8ICNkZWZpbmUgSEFWRV9TVERJTlRfSCAxCnwgI2RlZmluZSBI QVZFX1VOSVNURF9IIDEKfCAjZGVmaW5lIEhBVkVfREVWX1BQQlVTX1BQSV9IIDEKfCAjZGVmaW5l IEhBVkVfV0NIQVJfSCAxCnwgI2RlZmluZSBIQVZFX0xJQlJFQURMSU5FIDEKfCAjZGVmaW5lIEhB VkVfUkVBRExJTkVfUkVBRExJTkVfSCAxCnwgI2RlZmluZSBIQVZFX1JFQURMSU5FX0hJU1RPUlkg MQp8ICNkZWZpbmUgSEFWRV9SRUFETElORV9ISVNUT1JZX0ggMQp8ICNkZWZpbmUgSEFWRV9SRUFE TElORV9DT01QTEVUSU9OIDEKfCAjZGVmaW5lIEhBVkVfTElCRlRESSAxCnwgLyogZW5kIGNvbmZk ZWZzLmguICAqLwp8IAp8IC8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRv IGF2b2lkIGFuIGVycm9yLgp8ICAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo ZSByZXR1cm4gdHlwZSBvZiBhIEdDQwp8ICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50 IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCnwgI2lmZGVmIF9fY3BsdXNwbHVzCnwg ZXh0ZXJuICJDIgp8ICNlbmRpZgp8IGNoYXIgRlRfT3BlbkV4ICgpOwp8IGludAp8IG1haW4gKCkK fCB7CnwgcmV0dXJuIEZUX09wZW5FeCAoKTsKfCAgIDsKfCAgIHJldHVybiAwOwp8IH0KY29uZmln dXJlOjkyMDk6IHJlc3VsdDogbm8KY29uZmlndXJlOjkyMTg6IFdBUk5JTkc6ICoqKiBsaWJmdGQy eHggbm90IGZvdW5kLiBObyBzdXBwb3J0IGZvciBGVERJLWJhc2VkIFVTQiBKVEFHIGNhYmxlcyB2 aWEgbGliZnRkMnh4Lgpjb25maWd1cmU6OTM0MTogY2hlY2tpbmcgZm9yIGZsZXgKY29uZmlndXJl OjkzNjg6IHJlc3VsdDogL3Vzci9sb2NhbC9iaW4vZmxleApjb25maWd1cmU6OTQwNTogL3Vzci9s b2NhbC9iaW4vZmxleCBjb25mdGVzdC5sCmV2YWw6IC91c3IvbG9jYWwvYmluL2ZsZXg6IG5vdCBm b3VuZApjb25maWd1cmU6OTQwODogJD8gPSAxMjcKY29uZmlndXJlOjk0MTA6IGNoZWNraW5nIGxl eCBvdXRwdXQgZmlsZSByb290CmNvbmZpZ3VyZTo5NDIxOiBlcnJvcjogY2Fubm90IGZpbmQgb3V0 cHV0IGZyb20gL3Vzci9sb2NhbC9iaW4vZmxleDsgZ2l2aW5nIHVwCgojIyAtLS0tLS0tLS0tLS0t LS0tICMjCiMjIENhY2hlIHZhcmlhYmxlcy4gIyMKIyMgLS0tLS0tLS0tLS0tLS0tLSAjIwoKYWNf Y3ZfYnVpbGQ9YW1kNjQtcG9ydGJsZC1mcmVlYnNkOS4xCmFjX2N2X2NfY29tcGlsZXJfZ251PXll cwphY19jdl9lbnZfQ0Nfc2V0PXNldAphY19jdl9lbnZfQ0NfdmFsdWU9Y2MKYWNfY3ZfZW52X0NG TEFHU19zZXQ9c2V0CmFjX2N2X2Vudl9DRkxBR1NfdmFsdWU9Jy1PMiAtLXN0ZD1jOTkgLWZuby1z dHJpY3QtYWxpYXNpbmcnCmFjX2N2X2Vudl9DUFBGTEFHU19zZXQ9c2V0CmFjX2N2X2Vudl9DUFBG TEFHU192YWx1ZT0tSS91c3IvbG9jYWwvaW5jbHVkZQphY19jdl9lbnZfQ1BQX3NldD1zZXQKYWNf Y3ZfZW52X0NQUF92YWx1ZT1jcHAKYWNfY3ZfZW52X0xERkxBR1Nfc2V0PXNldAphY19jdl9lbnZf TERGTEFHU192YWx1ZT0nIC1ML3Vzci9sb2NhbC9saWInCmFjX2N2X2Vudl9MSUJTX3NldD0nJwph Y19jdl9lbnZfTElCU192YWx1ZT0nJwphY19jdl9lbnZfWUFDQ19zZXQ9JycKYWNfY3ZfZW52X1lB Q0NfdmFsdWU9JycKYWNfY3ZfZW52X1lGTEFHU19zZXQ9JycKYWNfY3ZfZW52X1lGTEFHU192YWx1 ZT0nJwphY19jdl9lbnZfYnVpbGRfYWxpYXNfc2V0PXNldAphY19jdl9lbnZfYnVpbGRfYWxpYXNf dmFsdWU9YW1kNjQtcG9ydGJsZC1mcmVlYnNkOS4xCmFjX2N2X2Vudl9ob3N0X2FsaWFzX3NldD0n JwphY19jdl9lbnZfaG9zdF9hbGlhc192YWx1ZT0nJwphY19jdl9lbnZfdGFyZ2V0X2FsaWFzX3Nl dD0nJwphY19jdl9lbnZfdGFyZ2V0X2FsaWFzX3ZhbHVlPScnCmFjX2N2X2Z1bmNfYWxsb2NhPXll cwphY19jdl9mdW5jX2FsbG9jYV93b3Jrcz15ZXMKYWNfY3ZfZnVuY19hcmd6X2NvdW50PW5vCmFj X2N2X2Z1bmNfYXJnel9uZXh0PW5vCmFjX2N2X2Z1bmNfYXJnel9zdHJpbmdpZnk9bm8KYWNfY3Zf ZnVuY19hc3ByaW50Zj15ZXMKYWNfY3ZfZnVuY19idG93Yz15ZXMKYWNfY3ZfZnVuY19jaG93bj15 ZXMKYWNfY3ZfZnVuY19jbG9ja19nZXR0aW1lPXllcwphY19jdl9mdW5jX2R1cDI9eWVzCmFjX2N2 X2Z1bmNfZm9yaz15ZXMKYWNfY3ZfZnVuY19mcHVyZ2U9eWVzCmFjX2N2X2Z1bmNfZnRkaV91c2Jf b3Blbj15ZXMKYWNfY3ZfZnVuY19md3ByaW50Zj15ZXMKYWNfY3ZfZnVuY19nZXRjd2Q9eWVzCmFj X2N2X2Z1bmNfZ2V0ZGVsaW09eWVzCmFjX2N2X2Z1bmNfZ2V0ZHRhYmxlc2l6ZT15ZXMKYWNfY3Zf ZnVuY19nZXRlZ2lkPXllcwphY19jdl9mdW5jX2dldGV1aWQ9eWVzCmFjX2N2X2Z1bmNfZ2V0aG9z dGJ5bmFtZT15ZXMKYWNfY3ZfZnVuY19nZXRob3N0bmFtZT15ZXMKYWNfY3ZfZnVuY19nZXRsaW5l PXllcwphY19jdl9mdW5jX2dldG9wdD15ZXMKYWNfY3ZfZnVuY19nZXRvcHRfbG9uZ19vbmx5PXll cwphY19jdl9mdW5jX2dldHBhZ2VzaXplPXllcwphY19jdl9mdW5jX2dldHJ1c2FnZT15ZXMKYWNf Y3ZfZnVuY19nZXR0aW1lb2ZkYXk9eWVzCmFjX2N2X2Z1bmNfZ2V0dWlkPXllcwphY19jdl9mdW5j X2luZXRfbnRvcD15ZXMKYWNfY3ZfZnVuY19pc2JsYW5rPXllcwphY19jdl9mdW5jX2lzd2JsYW5r PXllcwphY19jdl9mdW5jX2lzd2NudHJsPXllcwphY19jdl9mdW5jX2lzd2N0eXBlPXllcwphY19j dl9mdW5jX2xpbms9eWVzCmFjX2N2X2Z1bmNfbHN0YXQ9eWVzCmFjX2N2X2Z1bmNfbHN0YXRfZGVy ZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz15ZXMKYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxs PXllcwphY19jdl9mdW5jX21icnRvd2M9eWVzCmFjX2N2X2Z1bmNfbWJzaW5pdD15ZXMKYWNfY3Zf ZnVuY19tZW1jaHI9eWVzCmFjX2N2X2Z1bmNfbWVtY21wPXllcwphY19jdl9mdW5jX21lbWNweT15 ZXMKYWNfY3ZfZnVuY19tZW1tb3ZlPXllcwphY19jdl9mdW5jX21lbXNldD15ZXMKYWNfY3ZfZnVu Y19ta2R0ZW1wPXllcwphY19jdl9mdW5jX21rc3RlbXA9eWVzCmFjX2N2X2Z1bmNfbWxvY2s9eWVz CmFjX2N2X2Z1bmNfbW1hcD15ZXMKYWNfY3ZfZnVuY19tcHJvdGVjdD15ZXMKYWNfY3ZfZnVuY19t dW5sb2NrPXllcwphY19jdl9mdW5jX211bm1hcD15ZXMKYWNfY3ZfZnVuY19ubF9sYW5naW5mbz15 ZXMKYWNfY3ZfZnVuY19vYnN0YWNrcz1ubwphY19jdl9mdW5jX3BhdGhjb25mPXllcwphY19jdl9m dW5jX3BpcGU9eWVzCmFjX2N2X2Z1bmNfcG9zaXhfc3Bhd249eWVzCmFjX2N2X2Z1bmNfcHJlYWQ9 eWVzCmFjX2N2X2Z1bmNfcHN0YXRfZ2V0ZHluYW1pYz1ubwphY19jdl9mdW5jX3B0aHJlYWRfY29u ZF9icm9hZGNhc3Q9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9jb25kX2Rlc3Ryb3k9eWVzCmFjX2N2 X2Z1bmNfcHRocmVhZF9jb25kX2luaXQ9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9jb25kX3NpZ25h bD15ZXMKYWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfdGltZWR3YWl0PXllcwphY19jdl9mdW5jX3B0 aHJlYWRfY29uZF93YWl0PXllcwphY19jdl9mdW5jX3B0aHJlYWRfZXF1YWw9eWVzCmFjX2N2X2Z1 bmNfcHRocmVhZF9leGl0PXllcwphY19jdl9mdW5jX3B0aHJlYWRfbXV0ZXhfZGVzdHJveT15ZXMK YWNfY3ZfZnVuY19wdGhyZWFkX211dGV4X2luaXQ9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9tdXRl eF9sb2NrPXllcwphY19jdl9mdW5jX3B0aHJlYWRfbXV0ZXhfdW5sb2NrPXllcwphY19jdl9mdW5j X3B0aHJlYWRfc2VsZj15ZXMKYWNfY3ZfZnVuY19wdXRlbnY9eWVzCmFjX2N2X2Z1bmNfcHdyaXRl PXllcwphY19jdl9mdW5jX3JhaXNlPXllcwphY19jdl9mdW5jX3Jhd21lbWNocj1ubwphY19jdl9m dW5jX3JlYWRsaW5rPXllcwphY19jdl9mdW5jX3JlYWxwYXRoPXllcwphY19jdl9mdW5jX3NjaGVk X3lpZWxkPXllcwphY19jdl9mdW5jX3NlbGVjdD15ZXMKYWNfY3ZfZnVuY19zZXRlbnY9eWVzCmFj X2N2X2Z1bmNfc2V0bG9jYWxlPXllcwphY19jdl9mdW5jX3NldHJsaW1pdD15ZXMKYWNfY3ZfZnVu Y19zaG1nZXQ9eWVzCmFjX2N2X2Z1bmNfc2lnYWN0aW9uPXllcwphY19jdl9mdW5jX3NpZ2FsdHN0 YWNrPXllcwphY19jdl9mdW5jX3NpZ2ludGVycnVwdD15ZXMKYWNfY3ZfZnVuY19zaWdwcm9jbWFz az15ZXMKYWNfY3ZfZnVuY19zbnByaW50Zj15ZXMKYWNfY3ZfZnVuY19zdHBjcHk9eWVzCmFjX2N2 X2Z1bmNfc3RyYnJrPXllcwphY19jdl9mdW5jX3N0cmNhc2VjbXA9eWVzCmFjX2N2X2Z1bmNfc3Ry Y3Nwbj15ZXMKYWNfY3ZfZnVuY19zdHJkdXA9eWVzCmFjX2N2X2Z1bmNfc3RyZXJyb3I9eWVzCmFj X2N2X2Z1bmNfc3RyZXJyb3Jfcj15ZXMKYWNfY3ZfZnVuY19zdHJmdGltZT15ZXMKYWNfY3ZfZnVu Y19zdHJsZW49eWVzCmFjX2N2X2Z1bmNfc3RybmR1cD15ZXMKYWNfY3ZfZnVuY19zdHJubGVuPXll cwphY19jdl9mdW5jX3N0cm5sZW5fd29ya2luZz15ZXMKYWNfY3ZfZnVuY19zdHJwYnJrPXllcwph Y19jdl9mdW5jX3N0cnNpZ25hbD15ZXMKYWNfY3ZfZnVuY19zdHJ0b2w9eWVzCmFjX2N2X2Z1bmNf c3RydG91bD15ZXMKYWNfY3ZfZnVuY19zd3ByaW50Zj15ZXMKYWNfY3ZfZnVuY19zeW1saW5rPXll cwphY19jdl9mdW5jX3N5c2NvbmY9eWVzCmFjX2N2X2Z1bmNfdHNlYXJjaD15ZXMKYWNfY3ZfZnVu Y191bnNldGVudj15ZXMKYWNfY3ZfZnVuY191c2JfZmluZF9kZXZpY2VzPW5vCmFjX2N2X2Z1bmNf dXRpbWU9eWVzCmFjX2N2X2Z1bmNfdXRpbWVzPXllcwphY19jdl9mdW5jX3Zhc3ByaW50Zj15ZXMK YWNfY3ZfZnVuY192Zm9yaz15ZXMKYWNfY3ZfZnVuY192c25wcmludGY9eWVzCmFjX2N2X2Z1bmNf d2FpdHBpZD15ZXMKYWNfY3ZfZnVuY193Y3J0b21iPXllcwphY19jdl9mdW5jX3djc2NvbGw9eWVz CmFjX2N2X2Z1bmNfd2NzbGVuPXllcwphY19jdl9mdW5jX3djc25sZW49eWVzCmFjX2N2X2Z1bmNf d2N0b2I9eWVzCmFjX2N2X2Z1bmNfd2N3aWR0aD15ZXMKYWNfY3ZfZnVuY195aWVsZD1ubwphY19j dl9oYXZlX2RlY2xfYWxhcm09eWVzCmFjX2N2X2hhdmVfZGVjbF9jbGVhcmVycl91bmxvY2tlZD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX2Zlb2ZfdW5sb2NrZWQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9mZXJy b3JfdW5sb2NrZWQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9mcHVyZ2U9eWVzCmFjX2N2X2hhdmVfZGVj bF9mcmV4cGw9eWVzCmFjX2N2X2hhdmVfZGVjbF9mc2Vla289eWVzCmFjX2N2X2hhdmVfZGVjbF9m dGVsbG89eWVzCmFjX2N2X2hhdmVfZGVjbF9nZXRjX3VubG9ja2VkPXllcwphY19jdl9oYXZlX2Rl Y2xfZ2V0ZW52PXllcwphY19jdl9oYXZlX2RlY2xfZ2V0cGFnZXNpemU9eWVzCmFjX2N2X2hhdmVf ZGVjbF9pc2JsYW5rPXllcwphY19jdl9oYXZlX2RlY2xfcHV0Y191bmxvY2tlZD15ZXMKYWNfY3Zf aGF2ZV9kZWNsX3NldGVudj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3NpZ2FsdHN0YWNrPXllcwphY19j dl9oYXZlX2RlY2xfc25wcmludGY9eWVzCmFjX2N2X2hhdmVfZGVjbF9zdHJkdXA9eWVzCmFjX2N2 X2hhdmVfZGVjbF9zdHJlcnJvcl9yPXllcwphY19jdl9oYXZlX2RlY2xfc3RybmR1cD15ZXMKYWNf Y3ZfaGF2ZV9kZWNsX3N0cm5sZW49eWVzCmFjX2N2X2hhdmVfZGVjbF9zdHJzaWduYWw9eWVzCmFj X2N2X2hhdmVfZGVjbF9zdHJ0b2Q9eWVzCmFjX2N2X2hhdmVfZGVjbF9zeXNfc2lnbGlzdD15ZXMK YWNfY3ZfaGF2ZV9kZWNsX3Vuc2V0ZW52PXllcwphY19jdl9oYXZlX2RlY2xfd2N0b2I9eWVzCmFj X2N2X2hlYWRlcl9hbGxvY2FfaD1ubwphY19jdl9oZWFkZXJfYXJnel9oPW5vCmFjX2N2X2hlYWRl cl9hcnBhX2luZXRfaD15ZXMKYWNfY3ZfaGVhZGVyX2J5dGVzd2FwX2g9bm8KYWNfY3ZfaGVhZGVy X2N0eXBlX2g9eWVzCmFjX2N2X2hlYWRlcl9kZXZfcHBidXNfcHBpX2g9eWVzCmFjX2N2X2hlYWRl cl9kaXJlbnRfaD15ZXMKYWNfY3ZfaGVhZGVyX2RsX2g9bm8KYWNfY3ZfaGVhZGVyX2RsZmNuX2g9 eWVzCmFjX2N2X2hlYWRlcl9lcnJub19oPXllcwphY19jdl9oZWFkZXJfZ2V0b3B0X2g9eWVzCmFj X2N2X2hlYWRlcl9oaXN0b3J5X2g9bm8KYWNfY3ZfaGVhZGVyX2ludHR5cGVzX2g9eWVzCmFjX2N2 X2hlYWRlcl9saW1pdHNfaD15ZXMKYWNfY3ZfaGVhZGVyX2xpbnV4X3BwZGV2X2g9bm8KYWNfY3Zf aGVhZGVyX21hbGxvY19oPW5vCmFjX2N2X2hlYWRlcl9tYXRoX2g9eWVzCmFjX2N2X2hlYWRlcl9t ZW1vcnlfaD15ZXMKYWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oPW5vCmFjX2N2X2hlYWRlcl9u ZXRfaWZfaD15ZXMKYWNfY3ZfaGVhZGVyX25ldF9pZl9tZWRpYV9oPXllcwphY19jdl9oZWFkZXJf bmV0ZGJfaD15ZXMKYWNfY3ZfaGVhZGVyX25ldGluZXRfaW5faD15ZXMKYWNfY3ZfaGVhZGVyX3B3 ZF9oPXllcwphY19jdl9oZWFkZXJfcmFuZG9tX2g9bm8KYWNfY3ZfaGVhZGVyX3JlYWRsaW5lX2g9 bm8KYWNfY3ZfaGVhZGVyX3JlYWRsaW5lX2hpc3RvcnlfaD15ZXMKYWNfY3ZfaGVhZGVyX3JlYWRs aW5lX3JlYWRsaW5lX2g9eWVzCmFjX2N2X2hlYWRlcl9zY2hlZF9oPXllcwphY19jdl9oZWFkZXJf c2VhcmNoX2g9eWVzCmFjX2N2X2hlYWRlcl9zaWduYWxfaD15ZXMKYWNfY3ZfaGVhZGVyX3NwYXdu X2g9eWVzCmFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCmFjX2N2X2hlYWRlcl9zdGRjPXllcwph Y19jdl9oZWFkZXJfc3RkZGVmX2g9eWVzCmFjX2N2X2hlYWRlcl9zdGRpbnRfaD15ZXMKYWNfY3Zf aGVhZGVyX3N0ZGlvX2g9eWVzCmFjX2N2X2hlYWRlcl9zdGRsaWJfaD15ZXMKYWNfY3ZfaGVhZGVy X3N0cmluZ19oPXllcwphY19jdl9oZWFkZXJfc3RyaW5nc19oPXllcwphY19jdl9oZWFkZXJfc3Ry b3B0c19oPW5vCmFjX2N2X2hlYWRlcl9zeXNfZmNudGxfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19t bWFuX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfcGFyYW1faD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19z ZWxlY3RfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19zb2NrZXRfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5 c19zdGF0X2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfdGltZV9oPXllcwphY19jdl9oZWFkZXJfc3lz X3RpbWVzX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5 c193YWl0X2g9eWVzCmFjX2N2X2hlYWRlcl90aW1lX2g9eWVzCmFjX2N2X2hlYWRlcl91Y29udGV4 dF9oPXllcwphY19jdl9oZWFkZXJfdW5pc3RkX2g9eWVzCmFjX2N2X2hlYWRlcl92Zm9ya19oPW5v CmFjX2N2X2hlYWRlcl93Y2hhcl9oPXllcwphY19jdl9oZWFkZXJfd2N0eXBlX2g9eWVzCmFjX2N2 X2hvc3Q9YW1kNjQtcG9ydGJsZC1mcmVlYnNkOS4xCmFjX2N2X2xpYl9mdGQyeHhfRlRfT3BlbkV4 PW5vCmFjX2N2X21lbWJlcl9zdHJ1Y3Rfc2lnYWN0aW9uX3NhX3NpZ2FjdGlvbj15ZXMKYWNfY3Zf bWVtYmVyX3N0cnVjdF9zdGF0X3N0X2Jsa3NpemU9eWVzCmFjX2N2X29iamV4dD1vCmFjX2N2X3Bh dGhfQlpJUDI9L3Vzci9iaW4vYnppcDIKYWNfY3ZfcGF0aF9FR1JFUD0vdXNyL2Jpbi9lZ3JlcAph Y19jdl9wYXRoX0ZHUkVQPS91c3IvYmluL2ZncmVwCmFjX2N2X3BhdGhfR01TR0ZNVD0vdXNyL2xv Y2FsL2Jpbi9tc2dmbXQKYWNfY3ZfcGF0aF9HUkVQPS91c3IvYmluL2dyZXAKYWNfY3ZfcGF0aF9H WklQPS91c3IvYmluL2d6aXAKYWNfY3ZfcGF0aF9NS1RFTVBfQ09NTUFORD0vdXNyL2Jpbi9ta3Rl bXAKYWNfY3ZfcGF0aF9NU0dGTVQ9L3Vzci9sb2NhbC9iaW4vbXNnZm10CmFjX2N2X3BhdGhfTVNH TUVSR0U9L3Vzci9sb2NhbC9iaW4vbXNnbWVyZ2UKYWNfY3ZfcGF0aF9TRUQ9L3Vzci9iaW4vc2Vk CmFjX2N2X3BhdGhfWEdFVFRFWFQ9L3Vzci9sb2NhbC9iaW4veGdldHRleHQKYWNfY3ZfcGF0aF9h Y19wdF9MSUJGVERJX0NPTkZJRz0vdXNyL2xvY2FsL2Jpbi9saWJmdGRpLWNvbmZpZwphY19jdl9w YXRoX2luc3RhbGw9L3Vzci9iaW4vaW5zdGFsbAphY19jdl9wYXRoX21rZGlyPS9iaW4vbWtkaXIK YWNfY3ZfcHJvZ19BV0s9L3Vzci9iaW4vYXdrCmFjX2N2X3Byb2dfQ1BQPWNwcAphY19jdl9wcm9n X0xFWD0vdXNyL2xvY2FsL2Jpbi9mbGV4CmFjX2N2X3Byb2dfU0VEPS91c3IvYmluL3NlZAphY19j dl9wcm9nX1lBQ0M9YnlhY2MKYWNfY3ZfcHJvZ19hY19jdF9DQz1jYwphY19jdl9wcm9nX2FjX2N0 X1JBTkxJQj1yYW5saWIKYWNfY3ZfcHJvZ19jY19jODk9JycKYWNfY3ZfcHJvZ19jY19nPXllcwph Y19jdl9wcm9nX21ha2VfZ21ha2Vfc2V0PXllcwphY19jdl9zZWFyY2hfaTM4Nl9zZXRfaW9wZXJt PW5vCmFjX2N2X3NlYXJjaF9pb3Blcm09bm8KYWNfY3Zfc3lzX3N0YWNrX292ZXJmbG93X3dvcmtz PXllcwphY19jdl90eXBlX19Cb29sPXllcwphY19jdl90eXBlX2NoYXI9eWVzCmFjX2N2X3R5cGVf Y2hhcl9wPXllcwphY19jdl90eXBlX2ludDE2X3Q9eWVzCmFjX2N2X3R5cGVfaW50MzJfdD15ZXMK YWNfY3ZfdHlwZV9pbnQ9eWVzCmFjX2N2X3R5cGVfaW50bWF4X3Q9eWVzCmFjX2N2X3R5cGVfbG9u Zz15ZXMKYWNfY3ZfdHlwZV9sb25nX2xvbmdfaW50PXllcwphY19jdl90eXBlX21ic3RhdGVfdD15 ZXMKYWNfY3ZfdHlwZV9tb2RlX3Q9eWVzCmFjX2N2X3R5cGVfbmxpbmtfdD15ZXMKYWNfY3ZfdHlw ZV9vZmZfdD15ZXMKYWNfY3ZfdHlwZV9waWRfdD15ZXMKYWNfY3ZfdHlwZV9wb3NpeF9zcGF3bl9m aWxlX2FjdGlvbnNfdD15ZXMKYWNfY3ZfdHlwZV9wb3NpeF9zcGF3bmF0dHJfdD15ZXMKYWNfY3Zf dHlwZV9wdHJkaWZmX3Q9eWVzCmFjX2N2X3R5cGVfc2hvcnQ9eWVzCmFjX2N2X3R5cGVfc2lnX2F0 b21pY190PXllcwphY19jdl90eXBlX3NpemVfdD15ZXMKYWNfY3ZfdHlwZV9zc2l6ZV90PXllcwph Y19jdl90eXBlX3N0YWNrX3Q9eWVzCmFjX2N2X3R5cGVfdV9jaGFyPXllcwphY19jdl90eXBlX3Vf aW50MTZfdD15ZXMKYWNfY3ZfdHlwZV91X2ludDMyX3Q9eWVzCmFjX2N2X3R5cGVfdV9pbnQ4X3Q9 eWVzCmFjX2N2X3R5cGVfdV9pbnQ9eWVzCmFjX2N2X3R5cGVfdV9sb25nPXllcwphY19jdl90eXBl X3Vfc2hvcnQ9eWVzCmFjX2N2X3R5cGVfdWlkX3Q9eWVzCmFjX2N2X3R5cGVfdW5zaWduZWRfY2hh cj15ZXMKYWNfY3ZfdHlwZV91bnNpZ25lZF9pbnQ9eWVzCmFjX2N2X3R5cGVfdW5zaWduZWRfbG9u Zz15ZXMKYWNfY3ZfdHlwZV91bnNpZ25lZF9sb25nX2xvbmc9eWVzCmFjX2N2X3R5cGVfdW5zaWdu ZWRfbG9uZ19sb25nX2ludD15ZXMKYWNfY3ZfdHlwZV91bnNpZ25lZF9zaG9ydD15ZXMKYWNfY3Zf dHlwZV92b2xhdGlsZV9zaWdfYXRvbWljX3Q9eWVzCmFjX2N2X3R5cGVfd2NoYXJfdD15ZXMKYWNf Y3ZfdHlwZV93aW50X3Q9eWVzCmFjbF9jdl9oYXJkY29kZV9kaXJlY3Q9bm8KYWNsX2N2X2hhcmRj b2RlX2xpYmRpcl9mbGFnX3NwZWM9JyR7d2x9LXJwYXRoICR7d2x9JGxpYmRpcicKYWNsX2N2X2hh cmRjb2RlX2xpYmRpcl9zZXBhcmF0b3I9JycKYWNsX2N2X2hhcmRjb2RlX21pbnVzX0w9bm8KYWNs X2N2X2xpYmV4dD1hCmFjbF9jdl9wYXRoX0xEPS91c3IvYmluL2xkCmFjbF9jdl9wcm9nX2dudV9s ZD15ZXMKYWNsX2N2X3JwYXRoPWRvbmUKYWNsX2N2X3NobGliZXh0PXNvCmFjbF9jdl93bD0tV2ws CmFtX2N2X0NDX2RlcGVuZGVuY2llc19jb21waWxlcl90eXBlPWdjYzMKYW1fY3ZfZnVuY19pY29u dj15ZXMKYW1fY3ZfbGliX2ljb252PXllcwphbV9jdl9wcm9nX3Rhcl91c3Rhcj0vdXNyL2Jpbi90 YXIKY2xfY3ZfcHJvZ19MTj0vYmluL2xuCmNsX2N2X3Byb2dfY3A9Jy9iaW4vY3AgLXAnCmdsX2N2 X2RlY2xfbnVsbF93b3Jrcz15ZXMKZ2xfY3ZfZGVjbF9yZWFkbGlua193b3Jrcz15ZXMKZ2xfY3Zf ZnVuY19idG93Y19lb2Y9eWVzCmdsX2N2X2Z1bmNfYnRvd2NfbnVsPXllcwpnbF9jdl9mdW5jX2J0 b3djX3dvcmtzPXllcwpnbF9jdl9mdW5jX2R1cDJfd29ya3M9eWVzCmdsX2N2X2Z1bmNfZmNudGxf Zl9kdXBmZF9jbG9leGVjPXllcwpnbF9jdl9mdW5jX2ZjbnRsX2ZfZHVwZmRfd29ya3M9eWVzCmds X2N2X2Z1bmNfZm9wZW5fc2xhc2g9eWVzCmdsX2N2X2Z1bmNfZnB1cmdlX3dvcmtzPXllcwpnbF9j dl9mdW5jX2ZyZXhwX25vX2xpYm09eWVzCmdsX2N2X2Z1bmNfZnNlZWtvPXllcwpnbF9jdl9mdW5j X2Z0ZWxsbz15ZXMKZ2xfY3ZfZnVuY19mdGVsbG9fd29ya3M9eWVzCmdsX2N2X2Z1bmNfZ2V0b3B0 X3Bvc2l4PXllcwpnbF9jdl9mdW5jX2lzbmFuZF9ub19saWJtPXllcwpnbF9jdl9mdW5jX2lzd2Nu dHJsX3dvcmtzPXllcwpnbF9jdl9mdW5jX2xkZXhwX25vX2xpYm09eWVzCmdsX2N2X2Z1bmNfbGlu a193b3Jrcz15ZXMKZ2xfY3ZfZnVuY19sc2Vla19waXBlPXllcwpnbF9jdl9mdW5jX21hbGxvY18w X25vbm51bGw9MQpnbF9jdl9mdW5jX21hbGxvY19wb3NpeD15ZXMKZ2xfY3ZfZnVuY19tYnJ0b3dj X2luY29tcGxldGVfc3RhdGU9eWVzCmdsX2N2X2Z1bmNfbWJydG93Y19udWxfcmV0dmFsPXllcwpn bF9jdl9mdW5jX21icnRvd2NfbnVsbF9hcmcxPXllcwpnbF9jdl9mdW5jX21icnRvd2NfbnVsbF9h cmcyPXllcwpnbF9jdl9mdW5jX21icnRvd2NfcmV0dmFsPXllcwpnbF9jdl9mdW5jX21icnRvd2Nf c2FuaXR5Y2hlY2s9eWVzCmdsX2N2X2Z1bmNfbWVtY2hyX3dvcmtzPXllcwpnbF9jdl9mdW5jX25s X2xhbmdpbmZvX3llc2V4cHJfd29ya3M9eWVzCmdsX2N2X2Z1bmNfb3Blbl9zbGFzaD15ZXMKZ2xf Y3ZfZnVuY19wb3NpeF9zcGF3bl93b3Jrcz15ZXMKZ2xfY3ZfZnVuY19wcmludGZfZGlyZWN0aXZl X2E9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2ZV9mPXllcwpnbF9jdl9mdW5jX3ByaW50 Zl9kaXJlY3RpdmVfbHM9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2ZV9uPXllcwpnbF9j dl9mdW5jX3ByaW50Zl9mbGFnX2dyb3VwaW5nPXllcwpnbF9jdl9mdW5jX3ByaW50Zl9mbGFnX2xl ZnRhZGp1c3Q9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2ZsYWdfemVybz15ZXMKZ2xfY3ZfZnVuY19w cmludGZfaW5maW5pdGU9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2xvbmdfZG91YmxlPXllcwpnbF9j dl9mdW5jX3ByaW50Zl9wb3NpdGlvbnM9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX3ByZWNpc2lvbj15 ZXMKZ2xfY3ZfZnVuY19wcmludGZfc2l6ZXNfYzk5PXllcwpnbF9jdl9mdW5jX3JlYWRsaW5rX3dv cmtzPXllcwpnbF9jdl9mdW5jX3JlYWxwYXRoX3dvcmtzPXllcwpnbF9jdl9mdW5jX3JlbmFtZV9k ZXN0X3dvcmtzPXllcwpnbF9jdl9mdW5jX3JlbmFtZV9saW5rX3dvcmtzPXllcwpnbF9jdl9mdW5j X3JlbmFtZV9zbGFzaF9kc3Rfd29ya3M9eWVzCmdsX2N2X2Z1bmNfcmVuYW1lX3NsYXNoX3NyY193 b3Jrcz15ZXMKZ2xfY3ZfZnVuY19ybWRpcl93b3Jrcz15ZXMKZ2xfY3ZfZnVuY19zZXRlbnZfd29y a3M9eWVzCmdsX2N2X2Z1bmNfc2lncHJvY21hc2s9MQpnbF9jdl9mdW5jX3NucHJpbnRmX3JldHZh bF9jOTk9eWVzCmdsX2N2X2Z1bmNfc25wcmludGZfc2l6ZTE9eWVzCmdsX2N2X2Z1bmNfc25wcmlu dGZfdXNhYmxlPXllcwpnbF9jdl9mdW5jX3NwYXduYXR0cl9zZXRzY2hlZHBhcmFtPXllcwpnbF9j dl9mdW5jX3NwYXduYXR0cl9zZXRzY2hlZHBvbGljeT15ZXMKZ2xfY3ZfZnVuY19zdGF0X2Rpcl9z bGFzaD15ZXMKZ2xfY3ZfZnVuY19zdGF0X2ZpbGVfc2xhc2g9eWVzCmdsX2N2X2Z1bmNfc3RybmR1 cF93b3Jrcz15ZXMKZ2xfY3ZfZnVuY19zdHJzdHJfd29ya3NfYWx3YXlzPXllcwpnbF9jdl9mdW5j X3N0cnRvZF93b3Jrcz15ZXMKZ2xfY3ZfZnVuY19zeW1saW5rX3dvcmtzPXllcwpnbF9jdl9mdW5j X3VuZ2V0Y193b3Jrcz15ZXMKZ2xfY3ZfZnVuY191bnNldGVudl93b3Jrcz15ZXMKZ2xfY3ZfZnVu Y192YV9jb3B5PXllcwpnbF9jdl9mdW5jX3djcnRvbWJfcmV0dmFsPXllcwpnbF9jdl9mdW5jX3dj dG9iX3dvcmtzPXllcwpnbF9jdl9oYXZlX2luY2x1ZGVfbmV4dD15ZXMKZ2xfY3ZfaGF2ZV9yYXdf ZGVjbF9tZW1jcHk9bm8KZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9tZW1tZW09eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfbWVtcmNocj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9yYXdtZW1jaHI9eWVzCmds X2N2X2hhdmVfcmF3X2RlY2xfc3RwY3B5PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cG5jcHk9 eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RyY2FzZXN0cj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVj bF9zdHJkdXA9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RybmNhdD15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9zdHJuZHVwPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cm5sZW49eWVzCmdsX2N2 X2hhdmVfcmF3X2RlY2xfc3RycGJyaz15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJzZXA9eWVz CmdsX2N2X2hhdmVfcmF3X2RlY2xfc3Ryc2lnbmFsPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0 cnRva19yPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cnZlcnNjbXA9bm8KZ2xfY3ZfaGVhZGVy X2Vycm5vX2hfY29tcGxldGU9eWVzCmdsX2N2X2hlYWRlcl9pbnR0eXBlc19oPXllcwpnbF9jdl9o ZWFkZXJfbGFuZ2luZm9fY29kZXNldD15ZXMKZ2xfY3ZfaGVhZGVyX2xhbmdpbmZvX2VyYT15ZXMK Z2xfY3ZfaGVhZGVyX2xhbmdpbmZvX3RfZm10X2FtcG09eWVzCmdsX2N2X2hlYWRlcl9sYW5naW5m b195ZXNleHByPXllcwpnbF9jdl9oZWFkZXJfbWF0aF9odWdlX3ZhbF93b3Jrcz15ZXMKZ2xfY3Zf aGVhZGVyX21hdGhfbmFuX3dvcmtzPXllcwpnbF9jdl9oZWFkZXJfc3RkaW50X2g9eWVzCmdsX2N2 X2hlYWRlcl93Y2hhcl9oX2NvcnJlY3RfaW5saW5lPXllcwpnbF9jdl9zaWdhbHRzdGFja19sb3df YmFzZT15ZXMKZ2xfY3Zfc2l6ZV9tYXg9eWVzCmdsX2N2X3N5c19zdHJ1Y3RfdGltZXNwZWNfaW5f dGltZV9oPXllcwpnbF9jdl9zeXNfc3RydWN0X3RpbWV2YWw9eWVzCmdsX2N2X3R5cGVfd2N0cmFu c190PXllcwpnbF9jdl90eXBlX3djdHlwZV90PXllcwpndF9jdl9jX3djaGFyX3Q9eWVzCmd0X2N2 X2Nfd2ludF90PXllcwpndF9jdl9mdW5jX2dudWdldHRleHQxX2xpYmM9bm8KZ3RfY3ZfZnVuY19n bnVnZXR0ZXh0MV9saWJpbnRsPXllcwpndF9jdl9mdW5jX3Vuc2V0ZW52X3JldD1pbnQKZ3RfY3Zf c3NpemVfdD15ZXMKbHRfY3ZfcGF0aF9NQUdJQ19DTUQ9L3Vzci9iaW4vZmlsZQpsdF9jdl9zeXNf bWF4X2NtZF9sZW49MjYyMTQ0CnZsX2N2X2xpYl9yZWFkbGluZT0tbHJlYWRsaW5lCnZsX2N2X2xp Yl9yZWFkbGluZV9jb21wbGV0aW9uPXllcwp2bF9jdl9saWJfcmVhZGxpbmVfaGlzdG9yeT15ZXMK CiMjIC0tLS0tLS0tLS0tLS0tLS0tICMjCiMjIE91dHB1dCB2YXJpYWJsZXMuICMjCiMjIC0tLS0t LS0tLS0tLS0tLS0tICMjCgpBQ0xPQ0FMPScke1NIRUxMfSAvbW50L3N0dWZmL3Vzci9wb3J0cy9k ZXZlbC91cmp0YWcvd29yay91cmp0YWctMC4xMC90b29scy9taXNzaW5nIC0tcnVuIGFjbG9jYWwt MS4xMCcKQU1ERVBCQUNLU0xBU0g9J1wnCkFNREVQX0ZBTFNFPScjJwpBTURFUF9UUlVFPScnCkFN VEFSPScke1NIRUxMfSAvbW50L3N0dWZmL3Vzci9wb3J0cy9kZXZlbC91cmp0YWcvd29yay91cmp0 YWctMC4xMC90b29scy9taXNzaW5nIC0tcnVuIHRhcicKQVVUT0NPTkY9JyR7U0hFTEx9IC9tbnQv c3R1ZmYvdXNyL3BvcnRzL2RldmVsL3VyanRhZy93b3JrL3VyanRhZy0wLjEwL3Rvb2xzL21pc3Np bmcgLS1ydW4gYXV0b2NvbmYnCkFVVE9IRUFERVI9JyR7U0hFTEx9IC9tbnQvc3R1ZmYvdXNyL3Bv cnRzL2RldmVsL3VyanRhZy93b3JrL3VyanRhZy0wLjEwL3Rvb2xzL21pc3NpbmcgLS1ydW4gYXV0 b2hlYWRlcicKQVVUT01BS0U9JyR7U0hFTEx9IC9tbnQvc3R1ZmYvdXNyL3BvcnRzL2RldmVsL3Vy anRhZy93b3JrL3VyanRhZy0wLjEwL3Rvb2xzL21pc3NpbmcgLS1ydW4gYXV0b21ha2UtMS4xMCcK QVdLPScvdXNyL2Jpbi9hd2snCkNDPSdjYycKQ0NERVBNT0RFPSdkZXBtb2RlPWdjYzMnCkNGTEFH Uz0nLU8yIC0tc3RkPWM5OSAtZm5vLXN0cmljdC1hbGlhc2luZyAtV2FsbCcKQ1BQPSdjcHAnCkNQ UEZMQUdTPSctSSQodG9wX3NyY2RpcikgLUkkKHRvcF9zcmNkaXIpL2luY2x1ZGUgLUkvdXNyL2xv Y2FsL2luY2x1ZGUgLUkvdXNyL2xvY2FsL2luY2x1ZGUnCkNZR1BBVEhfVz0nZWNobycKREVGUz0n JwpERVBESVI9Jy5kZXBzJwpETUFMTE9DX0ZBTFNFPScnCkRNQUxMT0NfVFJVRT0nJwpFQ0hPX0M9 JycKRUNIT19OPSctbicKRUNIT19UPScnCkVHUkVQPScvdXNyL2Jpbi9lZ3JlcCcKRU5BQkxFX0JT RExfRkFMU0U9JycKRU5BQkxFX0JTRExfVFJVRT0nJwpFTkFCTEVfQlVTX0FVMTUwMF9GQUxTRT0n JwpFTkFCTEVfQlVTX0FVMTUwMF9UUlVFPScnCkVOQUJMRV9CVVNfQVZSMzJfRkFMU0U9JycKRU5B QkxFX0JVU19BVlIzMl9UUlVFPScnCkVOQUJMRV9CVVNfQkNNMTI1MF9GQUxTRT0nJwpFTkFCTEVf QlVTX0JDTTEyNTBfVFJVRT0nJwpFTkFCTEVfQlVTX0JGNTI2X0VaS0lUX0ZBTFNFPScnCkVOQUJM RV9CVVNfQkY1MjZfRVpLSVRfVFJVRT0nJwpFTkFCTEVfQlVTX0JGNTI3X0VaS0lUX0ZBTFNFPScn CkVOQUJMRV9CVVNfQkY1MjdfRVpLSVRfVFJVRT0nJwpFTkFCTEVfQlVTX0JGNTMzX0VaS0lUX0ZB TFNFPScnCkVOQUJMRV9CVVNfQkY1MzNfRVpLSVRfVFJVRT0nJwpFTkFCTEVfQlVTX0JGNTMzX1NU QU1QX0ZBTFNFPScnCkVOQUJMRV9CVVNfQkY1MzNfU1RBTVBfVFJVRT0nJwpFTkFCTEVfQlVTX0JG NTM3X0VaS0lUX0ZBTFNFPScnCkVOQUJMRV9CVVNfQkY1MzdfRVpLSVRfVFJVRT0nJwpFTkFCTEVf QlVTX0JGNTM3X1NUQU1QX0ZBTFNFPScnCkVOQUJMRV9CVVNfQkY1MzdfU1RBTVBfVFJVRT0nJwpF TkFCTEVfQlVTX0JGNTM4Rl9FWktJVF9GQUxTRT0nJwpFTkFCTEVfQlVTX0JGNTM4Rl9FWktJVF9U UlVFPScnCkVOQUJMRV9CVVNfQkY1NDhfRVpLSVRfRkFMU0U9JycKRU5BQkxFX0JVU19CRjU0OF9F WktJVF9UUlVFPScnCkVOQUJMRV9CVVNfQkY1NjFfRVpLSVRfRkFMU0U9JycKRU5BQkxFX0JVU19C RjU2MV9FWktJVF9UUlVFPScnCkVOQUJMRV9CVVNfQlNDT0FDSF9GQUxTRT0nJwpFTkFCTEVfQlVT X0JTQ09BQ0hfVFJVRT0nJwpFTkFCTEVfQlVTX0VKVEFHX0RNQV9GQUxTRT0nJwpFTkFCTEVfQlVT X0VKVEFHX0RNQV9UUlVFPScnCkVOQUJMRV9CVVNfRUpUQUdfRkFMU0U9JycKRU5BQkxFX0JVU19F SlRBR19UUlVFPScnCkVOQUJMRV9CVVNfRkpNRU1fRkFMU0U9JycKRU5BQkxFX0JVU19GSk1FTV9U UlVFPScnCkVOQUJMRV9CVVNfSDcyMDJfRkFMU0U9JycKRU5BQkxFX0JVU19INzIwMl9UUlVFPScn CkVOQUJMRV9CVVNfSVhQNDI1X0ZBTFNFPScnCkVOQUJMRV9CVVNfSVhQNDI1X1RSVUU9JycKRU5B QkxFX0JVU19KT1BDWUNfRkFMU0U9JycKRU5BQkxFX0JVU19KT1BDWUNfVFJVRT0nJwpFTkFCTEVf QlVTX0xIN0E0MDBfRkFMU0U9JycKRU5BQkxFX0JVU19MSDdBNDAwX1RSVUU9JycKRU5BQkxFX0JV U19NUEM1MjAwX0ZBTFNFPScnCkVOQUJMRV9CVVNfTVBDNTIwMF9UUlVFPScnCkVOQUJMRV9CVVNf TVBDODI0WF9GQUxTRT0nJwpFTkFCTEVfQlVTX01QQzgyNFhfVFJVRT0nJwpFTkFCTEVfQlVTX1BQ QzQwNUVQX0ZBTFNFPScnCkVOQUJMRV9CVVNfUFBDNDA1RVBfVFJVRT0nJwpFTkFCTEVfQlVTX1BQ QzQ0MEdYX0VCQzhfRkFMU0U9JycKRU5BQkxFX0JVU19QUEM0NDBHWF9FQkM4X1RSVUU9JycKRU5B QkxFX0JVU19QUk9UT1RZUEVfRkFMU0U9JycKRU5BQkxFX0JVU19QUk9UT1RZUEVfVFJVRT0nJwpF TkFCTEVfQlVTX1BYQTI3WF9GQUxTRT0nJwpFTkFCTEVfQlVTX1BYQTI3WF9UUlVFPScnCkVOQUJM RV9CVVNfUFhBMlgwX0ZBTFNFPScnCkVOQUJMRV9CVVNfUFhBMlgwX1RSVUU9JycKRU5BQkxFX0JV U19TM0M0NTEwX0ZBTFNFPScnCkVOQUJMRV9CVVNfUzNDNDUxMF9UUlVFPScnCkVOQUJMRV9CVVNf U0ExMTEwX0ZBTFNFPScnCkVOQUJMRV9CVVNfU0ExMTEwX1RSVUU9JycKRU5BQkxFX0JVU19TSDc3 MjdfRkFMU0U9JycKRU5BQkxFX0JVU19TSDc3MjdfVFJVRT0nJwpFTkFCTEVfQlVTX1NINzc1MFJf RkFMU0U9JycKRU5BQkxFX0JVU19TSDc3NTBSX1RSVUU9JycKRU5BQkxFX0JVU19TSDc3NTFSX0ZB TFNFPScnCkVOQUJMRV9CVVNfU0g3NzUxUl9UUlVFPScnCkVOQUJMRV9CVVNfU0hBUkNfMjEwNjVM X0ZBTFNFPScnCkVOQUJMRV9CVVNfU0hBUkNfMjEwNjVMX1RSVUU9JycKRU5BQkxFX0JVU19TTFNV UDNfRkFMU0U9JycKRU5BQkxFX0JVU19TTFNVUDNfVFJVRT0nJwpFTkFCTEVfQlVTX1RYNDkyNV9G QUxTRT0nJwpFTkFCTEVfQlVTX1RYNDkyNV9UUlVFPScnCkVOQUJMRV9CVVNfWkVGQU5UX1hTM19G QUxTRT0nJwpFTkFCTEVfQlVTX1pFRkFOVF9YUzNfVFJVRT0nJwpFTkFCTEVfQ0FCTEVfQVJDT01f RkFMU0U9JycKRU5BQkxFX0NBQkxFX0FSQ09NX1RSVUU9JycKRU5BQkxFX0NBQkxFX0JZVEVCTEFT VEVSX0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9CWVRFQkxBU1RFUl9UUlVFPScnCkVOQUJMRV9DQUJM RV9ETEM1X0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9ETEM1X1RSVUU9JycKRU5BQkxFX0NBQkxFX0VB MjUzX0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9FQTI1M19UUlVFPScnCkVOQUJMRV9DQUJMRV9FSTAx Ml9GQUxTRT0nJwpFTkFCTEVfQ0FCTEVfRUkwMTJfVFJVRT0nJwpFTkFCTEVfQ0FCTEVfRVA5MzA3 X0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9FUDkzMDdfVFJVRT0nJwpFTkFCTEVfQ0FCTEVfRlQyMjMy X0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9GVDIyMzJfVFJVRT0nJwpFTkFCTEVfQ0FCTEVfSUdMT09f RkFMU0U9JycKRU5BQkxFX0NBQkxFX0lHTE9PX1RSVUU9JycKRU5BQkxFX0NBQkxFX0pMSU5LX0ZB TFNFPScnCkVOQUJMRV9DQUJMRV9KTElOS19UUlVFPScnCkVOQUJMRV9DQUJMRV9LRUlUSEtPRVBf RkFMU0U9JycKRU5BQkxFX0NBQkxFX0tFSVRIS09FUF9UUlVFPScnCkVOQUJMRV9DQUJMRV9MQVRU SUNFX0ZBTFNFPScnCkVOQUJMRV9DQUJMRV9MQVRUSUNFX1RSVUU9JycKRU5BQkxFX0NBQkxFX01Q Q0JETV9GQUxTRT0nJwpFTkFCTEVfQ0FCTEVfTVBDQkRNX1RSVUU9JycKRU5BQkxFX0NBQkxFX1RS SVRPTl9GQUxTRT0nJwpFTkFCTEVfQ0FCTEVfVFJJVE9OX1RSVUU9JycKRU5BQkxFX0NBQkxFX1RT NzgwMF9GQUxTRT0nJwpFTkFCTEVfQ0FCTEVfVFM3ODAwX1RSVUU9JycKRU5BQkxFX0NBQkxFX1VT QkJMQVNURVJfRkFMU0U9JycKRU5BQkxFX0NBQkxFX1VTQkJMQVNURVJfVFJVRT0nJwpFTkFCTEVf Q0FCTEVfV0lHR0xFUl9GQUxTRT0nJwpFTkFCTEVfQ0FCTEVfV0lHR0xFUl9UUlVFPScnCkVOQUJM RV9DQUJMRV9YUENfRkFMU0U9JycKRU5BQkxFX0NBQkxFX1hQQ19UUlVFPScnCkVOQUJMRV9KSU1f RkFMU0U9JycKRU5BQkxFX0pJTV9UUlVFPScnCkVOQUJMRV9MT1dMRVZFTF9ESVJFQ1RfRkFMU0U9 JycKRU5BQkxFX0xPV0xFVkVMX0RJUkVDVF9UUlVFPScnCkVOQUJMRV9MT1dMRVZFTF9GVEQyWFhf RkFMU0U9JycKRU5BQkxFX0xPV0xFVkVMX0ZURDJYWF9UUlVFPScnCkVOQUJMRV9MT1dMRVZFTF9G VERJX0ZBTFNFPScnCkVOQUJMRV9MT1dMRVZFTF9GVERJX1RSVUU9JycKRU5BQkxFX0xPV0xFVkVM X1BQREVWX0ZBTFNFPScnCkVOQUJMRV9MT1dMRVZFTF9QUERFVl9UUlVFPScnCkVOQUJMRV9MT1dM RVZFTF9QUElfRkFMU0U9JycKRU5BQkxFX0xPV0xFVkVMX1BQSV9UUlVFPScnCkVOQUJMRV9TVkZf RkFMU0U9JycKRU5BQkxFX1NWRl9UUlVFPScnCkVYRUVYVD0nJwpGVEQyWFhMSUI9JycKR01TR0ZN VD0nL3Vzci9sb2NhbC9iaW4vbXNnZm10JwpHUkVQPScvdXNyL2Jpbi9ncmVwJwpIQVZFX0lOUE9V VFhYX0ZBTFNFPScnCkhBVkVfSU5QT1VUWFhfVFJVRT0nIycKSEFWRV9MSUJGVEQyWFhfRkFMU0U9 JycKSEFWRV9MSUJGVEQyWFhfVFJVRT0nIycKSEFWRV9MSUJGVERJX0ZBTFNFPScjJwpIQVZFX0xJ QkZURElfVFJVRT0nJwpIQVZFX0xJQlVTQl9GQUxTRT0nJwpIQVZFX0xJQlVTQl9UUlVFPScjJwpJ TlNUQUxMX0RBVEE9J2luc3RhbGwgIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0JwpJTlNUQUxMX1BS T0dSQU09J2luc3RhbGwgIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1JwpJTlNUQUxMX1NDUklQ VD0naW5zdGFsbCAgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUnCklOU1RBTExfU1RSSVBfUFJPR1JB TT0nJChpbnN0YWxsX3NoKSAtYyAtcycKSU5UTExJQlM9Jy91c3IvbG9jYWwvbGliL2xpYmludGwu c28gL3Vzci9sb2NhbC9saWIvbGliaWNvbnYuc28gLVdsLC1ycGF0aCAtV2wsL3Vzci9sb2NhbC9s aWInCkpFREVDX0VYUF9GQUxTRT0nJwpKRURFQ19FWFBfVFJVRT0nJwpKVEFHX1JFTE9DQVRBQkxF X0ZBTFNFPScnCkpUQUdfUkVMT0NBVEFCTEVfVFJVRT0nJwpMREZMQUdTPScgLUwvdXNyL2xvY2Fs L2xpYicKTEVYPScvdXNyL2xvY2FsL2Jpbi9mbGV4JwpMRVhMSUI9JycKTEVYX09VVFBVVF9ST09U PScnCkxJQkZURElfQ09ORklHPScvdXNyL2xvY2FsL2Jpbi9saWJmdGRpLWNvbmZpZycKTElCSUNP TlY9Jy91c3IvbG9jYWwvbGliL2xpYmljb252LnNvIC1XbCwtcnBhdGggLVdsLC91c3IvbG9jYWwv bGliJwpMSUJJTlRMPScvdXNyL2xvY2FsL2xpYi9saWJpbnRsLnNvIC91c3IvbG9jYWwvbGliL2xp Ymljb252LnNvIC1XbCwtcnBhdGggLVdsLC91c3IvbG9jYWwvbGliJwpMSUJPQkpTPScnCkxJQlM9 Jy1ML3Vzci9sb2NhbC9saWIgLWxmdGRpIC1sdXNiICAtbHJlYWRsaW5lJwpMSUJVU0JfQ09ORklH PSdubycKTFRMSUJJQ09OVj0nLUwvdXNyL2xvY2FsL2xpYiAtbGljb252IC1SL3Vzci9sb2NhbC9s aWInCkxUTElCSU5UTD0nLUwvdXNyL2xvY2FsL2xpYiAtbGludGwgLUwvdXNyL2xvY2FsL2xpYiAt bGljb252IC1SL3Vzci9sb2NhbC9saWInCkxUTElCT0JKUz0nJwpNQUlOVD0nIycKTUFJTlRBSU5F Ul9NT0RFX0ZBTFNFPScnCk1BSU5UQUlORVJfTU9ERV9UUlVFPScjJwpNQUtFSU5GTz0nJHtTSEVM TH0gL21udC9zdHVmZi91c3IvcG9ydHMvZGV2ZWwvdXJqdGFnL3dvcmsvdXJqdGFnLTAuMTAvdG9v bHMvbWlzc2luZyAtLXJ1biBtYWtlaW5mbycKTUtJTlNUQUxMRElSUz0nJCh0b3BfYnVpbGRkaXIp L3Rvb2xzL21raW5zdGFsbGRpcnMnCk1TR0ZNVD0nL3Vzci9sb2NhbC9iaW4vbXNnZm10JwpNU0dN RVJHRT0nL3Vzci9sb2NhbC9iaW4vbXNnbWVyZ2UnCk9CSkVYVD0nbycKUEFDS0FHRT0ndXJqdGFn JwpQQUNLQUdFX0JVR1JFUE9SVD0naHR0cDovL3VyanRhZy5vcmcnClBBQ0tBR0VfTkFNRT0nVXJK VEFHJwpQQUNLQUdFX1NUUklORz0nVXJKVEFHIDAuMTAnClBBQ0tBR0VfVEFSTkFNRT0ndXJqdGFn JwpQQUNLQUdFX1ZFUlNJT049JzAuMTAnClBBVEhfU0VQQVJBVE9SPSc6JwpQT1NVQj0ncG8nClJB TkxJQj0ncmFubGliJwpTRUQ9JycKU0VUX01BS0U9JycKU0hFTEw9Jy9iaW4vc2gnClNUUklQPScn ClNWTl9SRVZJU0lPTj0nMTUwMicKVVNFX05MUz0neWVzJwpWRVJTSU9OPScwLjEwJwpYR0VUVEVY VD0nL3Vzci9sb2NhbC9iaW4veGdldHRleHQnCllBQ0M9J2J5YWNjJwpZRkxBR1M9JycKYWNfY3Rf Q0M9J2NjJwphbV9fZmFzdGRlcENDX0ZBTFNFPScjJwphbV9fZmFzdGRlcENDX1RSVUU9JycKYW1f X2luY2x1ZGU9J2luY2x1ZGUnCmFtX19pc3JjPScnCmFtX19sZWFkaW5nX2RvdD0nLicKYW1fX3F1 b3RlPScnCmFtX190YXI9JyR7QU1UQVJ9IGNob2YgLSAiJCR0YXJkaXIiJwphbV9fdW50YXI9JyR7 QU1UQVJ9IHhmIC0nCmJpbmRpcj0nJHtleGVjX3ByZWZpeH0vYmluJwpidWlsZD0nYW1kNjQtcG9y dGJsZC1mcmVlYnNkOS4xJwpidWlsZF9hbGlhcz0nYW1kNjQtcG9ydGJsZC1mcmVlYnNkOS4xJwpi dWlsZF9jcHU9J2FtZDY0JwpidWlsZF9vcz0nZnJlZWJzZDkuMScKYnVpbGRfdmVuZG9yPSdwb3J0 YmxkJwpkYXRhZGlyPScke2RhdGFyb290ZGlyfScKZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFy ZScKZG9jZGlyPScke2RhdGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9JwpkdmlkaXI9 JyR7ZG9jZGlyfScKZXhlY19wcmVmaXg9J05PTkUnCmhvc3Q9J2FtZDY0LXBvcnRibGQtZnJlZWJz ZDkuMScKaG9zdF9hbGlhcz0nJwpob3N0X2NwdT0nYW1kNjQnCmhvc3Rfb3M9J2ZyZWVic2Q5LjEn Cmhvc3RfdmVuZG9yPSdwb3J0YmxkJwpodG1sZGlyPScke2RvY2Rpcn0nCmluY2x1ZGVkaXI9JyR7 cHJlZml4fS9pbmNsdWRlJwppbmZvZGlyPScvdXNyL2xvY2FsL2luZm8vJwppbnN0YWxsX3NoPSck KFNIRUxMKSAvbW50L3N0dWZmL3Vzci9wb3J0cy9kZXZlbC91cmp0YWcvd29yay91cmp0YWctMC4x MC90b29scy9pbnN0YWxsLXNoJwpsaWJkaXI9JyR7ZXhlY19wcmVmaXh9L2xpYicKbGliZXhlY2Rp cj0nJHtleGVjX3ByZWZpeH0vbGliZXhlYycKbG9jYWxlZGlyPScke2RhdGFyb290ZGlyfS9sb2Nh bGUnCmxvY2Fsc3RhdGVkaXI9JyR7cHJlZml4fS92YXInCm1hbmRpcj0nL3Vzci9sb2NhbC9tYW4n Cm1rZGlyX3A9Jy9iaW4vbWtkaXIgLXAnCm9sZGluY2x1ZGVkaXI9Jy91c3IvaW5jbHVkZScKcGRm ZGlyPScke2RvY2Rpcn0nCnByZWZpeD0nL3Vzci9sb2NhbCcKcHJvZ3JhbV90cmFuc2Zvcm1fbmFt ZT0ncyx4LHgsJwpwc2Rpcj0nJHtkb2NkaXJ9JwpzYmluZGlyPScke2V4ZWNfcHJlZml4fS9zYmlu JwpzaGFyZWRzdGF0ZWRpcj0nJHtwcmVmaXh9L2NvbScKc3lzY29uZmRpcj0nJHtwcmVmaXh9L2V0 YycKdGFyZ2V0X2FsaWFzPScnCgojIyAtLS0tLS0tLS0tLSAjIwojIyBjb25mZGVmcy5oLiAjIwoj IyAtLS0tLS0tLS0tLSAjIwoKI2RlZmluZSBQQUNLQUdFX05BTUUgIlVySlRBRyIKI2RlZmluZSBQ QUNLQUdFX1RBUk5BTUUgInVyanRhZyIKI2RlZmluZSBQQUNLQUdFX1ZFUlNJT04gIjAuMTAiCiNk ZWZpbmUgUEFDS0FHRV9TVFJJTkcgIlVySlRBRyAwLjEwIgojZGVmaW5lIFBBQ0tBR0VfQlVHUkVQ T1JUICJodHRwOi8vdXJqdGFnLm9yZyIKI2RlZmluZSBTVk5fUkVWSVNJT04gIjE1MDIiCiNkZWZp bmUgUEFDS0FHRSAidXJqdGFnIgojZGVmaW5lIFZFUlNJT04gIjAuMTAiCiNkZWZpbmUgX0dOVV9T T1VSQ0UgMQojZGVmaW5lIEhBVkVfSUNPTlYgMQojZGVmaW5lIEVOQUJMRV9OTFMgMQojZGVmaW5l IEhBVkVfR0VUVEVYVCAxCiNkZWZpbmUgSEFWRV9EQ0dFVFRFWFQgMQojZGVmaW5lIEhBVkVfR0VU TElORSAxCiNkZWZpbmUgSEFWRV9HRVRERUxJTSAxCiNkZWZpbmUgSEFWRV9TV1BSSU5URiAxCiNk ZWZpbmUgU1REQ19IRUFERVJTIDEKI2RlZmluZSBIQVZFX1NZU19UWVBFU19IIDEKI2RlZmluZSBI QVZFX1NZU19TVEFUX0ggMQojZGVmaW5lIEhBVkVfU1RETElCX0ggMQojZGVmaW5lIEhBVkVfU1RS SU5HX0ggMQojZGVmaW5lIEhBVkVfTUVNT1JZX0ggMQojZGVmaW5lIEhBVkVfU1RSSU5HU19IIDEK I2RlZmluZSBIQVZFX0lOVFRZUEVTX0ggMQojZGVmaW5lIEhBVkVfU1RESU5UX0ggMQojZGVmaW5l IEhBVkVfVU5JU1REX0ggMQojZGVmaW5lIEhBVkVfREVWX1BQQlVTX1BQSV9IIDEKI2RlZmluZSBI QVZFX1dDSEFSX0ggMQojZGVmaW5lIEhBVkVfTElCUkVBRExJTkUgMQojZGVmaW5lIEhBVkVfUkVB RExJTkVfUkVBRExJTkVfSCAxCiNkZWZpbmUgSEFWRV9SRUFETElORV9ISVNUT1JZIDEKI2RlZmlu ZSBIQVZFX1JFQURMSU5FX0hJU1RPUllfSCAxCiNkZWZpbmUgSEFWRV9SRUFETElORV9DT01QTEVU SU9OIDEKI2RlZmluZSBIQVZFX0xJQkZUREkgMQoKY29uZmlndXJlOiBleGl0IDEK --001a11c2cc98ca7d3204dfe1f183-- From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 09:07:48 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDD1C36C for ; Mon, 24 Jun 2013 09:07:48 +0000 (UTC) (envelope-from indexbuild@FreeBSD.org) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) by mx1.freebsd.org (Postfix) with ESMTP id E109B1799 for ; Mon, 24 Jun 2013 09:07:48 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.7) with ESMTP id r5O97mnf002026 for ; Mon, 24 Jun 2013 09:07:48 GMT (envelope-from indexbuild@portsindexbuild.ysv.freebsd.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.5/Submit) id r5O97mux002025 for ports@FreeBSD.org; Mon, 24 Jun 2013 09:07:48 GMT (envelope-from indexbuild) Date: Mon, 24 Jun 2013 09:07:48 GMT From: Ports Index build Message-Id: <201306240907.r5O97mux002025@portsindexbuild.ysv.freebsd.org> To: ports@FreeBSD.org Subject: INDEX build failed for 8.x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 09:07:49 -0000 INDEX build failed with errors: Generating INDEX-8 - please wait..clang: not found clang: not found Done. Warning: Duplicate INDEX entry: pkg-1.1 Committers on the hook: bapt culot decke demon Most recent SVN update was: Updating '.': U ports-mgmt/pkg/Makefile U ports-mgmt/pkg/distinfo U ports-mgmt/pkg/pkg-plist U emulators/virtualbox-ose-kmod/Makefile U emulators/virtualbox-ose-kmod/distinfo UU emulators/virtualbox-ose-kmod/pkg-descr U emulators/virtualbox-ose-kmod/files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c A emulators/virtualbox-ose-kmod/files/patch-src-VBox-HostDrivers-VBoxNetAdp-Makefile.kmk U emulators/virtualbox-ose-additions/Makefile U emulators/virtualbox-ose-additions/distinfo UU emulators/virtualbox-ose-additions/pkg-descr A emulators/virtualbox-ose/files/patch-src-VBox-ExtPacks-VNC-VBoxVNC.cpp U emulators/virtualbox-ose/Makefile U emulators/virtualbox-ose/distinfo UU emulators/virtualbox-ose/pkg-descr U archivers/p5-Compress-Bzip2/Makefile U archivers/p5-Compress-Bzip2/distinfo U sysutils/parallel/distinfo U sysutils/parallel/Makefile U devel/p5-Module-Info/Makefile U devel/p5-Module-Info/distinfo U misc/p5-Locale-Codes/Makefile U misc/p5-Locale-Codes/distinfo U graphics/gource/Makefile U graphics/gource/distinfo U math/glm/distinfo U math/glm/Makefile Updated to revision 321671. From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 09:40:34 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD1ACB64; Mon, 24 Jun 2013 09:40:34 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 717F7194B; Mon, 24 Jun 2013 09:40:34 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id f14so2078046qak.0 for ; Mon, 24 Jun 2013 02:40:34 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=YvlWMUwYfmUDxtQAvkzs65lOQ62OBNzLSPf9Rt46lVc=; b=vk/U0L30lJRcCxOqMlwlO6dE/tBbA38hO2eRURrJncpcDB48aX4eNkOQhmRIOH2f74 WC4FkiRUsLJtCF4/erf39Bk9DV+yPz7VNnlLnBCOUqxPbRrQwQfSYBn8CJeZM3Aa0Kb7 yE40LxL1iSi0x5HsNaUZEaV0lztjjq4Y+aszDK+9mEIfR3AXt1aZNZOZR6KI4MMEh6jO NEnzynEGWiy2yWPjsfigF7h37y4jnWXcFnTN3z47OLiEa78zLo1Z/2bweTkJls2xM5An upAXA1fTIE/G8eQgXI2FxClAT+YY60HP6LiNL0erf3i61rMcYkgVJ0QR4wEf/7Ym0XSp GUew== MIME-Version: 1.0 X-Received: by 10.224.61.5 with SMTP id r5mr21920834qah.32.1372066833874; Mon, 24 Jun 2013 02:40:33 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.49.35.84 with HTTP; Mon, 24 Jun 2013 02:40:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Jun 2013 11:40:33 +0200 X-Google-Sender-Auth: xwaFrhZHoKNaond8CrVvJMyX600 Message-ID: Subject: Re: [devel/urjtag] build problem From: CeDeROM To: freebsd-ports , ports@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 09:40:34 -0000 Installing FLEX solved the build/configure issue. Please add flex to dependency list of devel/urjtag :-) # pkg install flex Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing flex: 2.5.37 The installation will require 1 MB more space 757 kB to be downloaded Proceed with installing packages [y/N]: y flex-2.5.37.txz 100% 758KB 757.7KB/s 757.7KB/s 00:00 Checking integrity... done Installing flex-2.5.37... done root@mercury:/usr/ports/devel/urjtag # make ===> urjtag-0.10_3 depends on executable: flex - found ===> urjtag-0.10_3 depends on executable: gmake - found ===> urjtag-0.10_3 depends on shared library: ftdi - found ===> urjtag-0.10_3 depends on shared library: intl - found ===> Configuring for urjtag-0.10_3 configure: loading site script /usr/ports/Templates/config.site checking code revision... from ChangeLog: 1502 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether NLS is requested... yes checking for msgfmt... /usr/local/bin/msgfmt checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for msgmerge... /usr/local/bin/msgmerge checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... gcc3 checking build system type... amd64-portbld-freebsd9.1 checking host system type... amd64-portbld-freebsd9.1 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking whether NLS is requested... yes checking for GNU gettext in libc... no checking for iconv... yes checking how to link with libiconv... /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib checking for gcc... (cached) cc checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... (cached) none needed checking dependency style of cc... (cached) gcc3 checking for ranlib... ranlib checking for bison... no checking for byacc... byacc checking for library containing ioperm... no checking for library containing i386_set_ioperm... no checking for getline... yes checking for getdelim... yes checking for swprintf... yes checking for clock_gettime... (cached) yes checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... (cached) /usr/bin/egrep checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking linux/ppdev.h usability... no checking linux/ppdev.h presence... no checking for linux/ppdev.h... no checking dev/ppbus/ppi.h usability... yes checking dev/ppbus/ppi.h presence... yes checking for dev/ppbus/ppi.h... yes checking stropts.h usability... no checking stropts.h presence... no checking for stropts.h... no checking for wchar.h... (cached) yes checking for a readline compatible library... -lreadline checking readline.h usability... no checking readline.h presence... no checking for readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking whether readline supports history... yes checking history.h usability... no checking history.h presence... no checking for history.h... no checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking whether readline supports completion... yes checking for libusb-config... no checking for usb_find_devices... no configure: WARNING: *** libusb not detected. No support for USB JTAG cables via libusb. checking for libftdi-config... /usr/local/bin/libftdi-config checking for ftdi_usb_open... yes checking for FT_OpenEx in -lftd2xx... no configure: WARNING: *** libftd2xx not found. No support for FTDI-based USB JTAG cables via libftd2xx. checking for flex... /usr/local/bin/flex checking lex output file root... lex.yy checking lex library... -lfl checking whether yytext is a pointer... yes checking for gawk... (cached) /usr/bin/awk checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fmax in -lm... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating data/Makefile config.status: creating include/Makefile config.status: creating src/Makefile config.status: creating src/lib/Makefile config.status: creating src/tap/Makefile config.status: creating src/part/Makefile config.status: creating src/bus/Makefile config.status: creating src/flash/Makefile config.status: creating src/cmd/Makefile config.status: creating src/svf/Makefile config.status: creating src/bsdl/Makefile config.status: creating src/jim/Makefile config.status: creating po/Makefile.in config.status: WARNING: po/Makefile.in.in seems to ignore the --datarootdir setting config.status: creating config.h config.status: executing default-1 commands config.status: creating po/POTFILES config.status: creating po/Makefile config.status: executing depfiles commands configure: jtag is now configured for Detected libusb : no Detected libftdi : yes Detected libftd2xx : no Detected inpout32 : no Build SVF player : yes Build BSDL subsystem : yes Bus drivers : au1500 avr32 bcm1250 bf526_ezkit bf527_ezkit bf533_stamp bf533_ezkit bf537_stamp bf537_ezkit bf538f_ezkit bf548_ezkit bf561_ezkit bscoach ejtag ejtag_dma fjmem ixp425 jopcyc h7202 lh7a400 mpc5200 mpc824x ppc405ep ppc440gx_ebc8 prototype pxa2x0 pxa27x s3c4510 sa1110 sh7727 sh7750r sh7751r sharc_21065L slsup3 tx4925 zefant_xs3 Cable drivers : arcom byteblaster dlc5 ea253 ei012 ft2232 igloo keithkoep lattice mpcbdm triton usbblaster wiggler Lowlevel drivers : ftdi ppi -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 11:06:03 2013 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2DCBF28 for ; Mon, 24 Jun 2013 11:06:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B6F1A1D59 for ; Mon, 24 Jun 2013 11:06:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5OB63k4099975 for ; Mon, 24 Jun 2013 11:06:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5OB631K099973 for freebsd-ports@FreeBSD.org; Mon, 24 Jun 2013 11:06:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Jun 2013 11:06:03 GMT Message-Id: <201306241106.r5OB631K099973@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD ports list Subject: Current unassigned ports problem reports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:06:03 -0000 (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f ports/179924 [PATCH] emulators/dosbox: add OPTIONS to enable intern o ports/179923 [MAINTAINER] games/cretan-hubris: Trim dependency for o ports/179922 [MAINTAINER] games/fbg2: Trim dependency, add DOCS opt o ports/179921 [MAINTAINER] games/avoision: Trim dependencies, add DO o ports/179919 Patch astro/foxtrotgps to fix crash [maintainer] o ports/179917 [PATCH] japanese/wordpress: update to 3.5.2 o ports/179916 [PATCH] audio/liblo: update to 0.27, take maintainersh o ports/179903 [MAINTAINER] games/epiar: Change master sites, fix bui o ports/179858 [NEW PORT] deskutils/lxshortcut: Small utility used to o ports/179855 New port: science/sigrok-cli o ports/179854 New port: science/pulseview o ports/179853 New port: devel/libsigrok o ports/179852 New port: devel/libsigrokdecode o ports/179843 emacs and texinfo collide f ports/179825 [PATCH] graphics/gpicview: update to 0.2.3, add licens o ports/179790 [PATCH] biology/phylip: checksum mismatch o ports/179778 new port: net/fish-sync -- network file sync tool f ports/179768 [PATCH] databases/mtop: add missing RUN_DEPENDS o ports/179730 (Possible) change to textproc/slides f ports/179726 www/cherokee cannot be installed on FreeBSD 9.1 f ports/179708 net-mgmt/macroscope: Requires non-existent MySQL 5.0 b o ports/179691 New port: net/mtr082 f ports/179670 security/courierpasswd: MASTER_SITES reorganized, dist f ports/179662 devel/m17n-docs: unfetchable due to MASTER_SITES chang f ports/179654 sysutils/mmore: MASTER_SITES disappeared, distfile unf f ports/179650 sysutils/ckl: MASTER_SITES disappeared o ports/179642 databases/mysql-workbench52 don't compile because it c f ports/179637 [patch] ports-mgmt/portupdate-scan: add the "-a [date] o ports/179611 running sysutils/pdumpfs fails with ruby19 o ports/179577 sysutils/fusefs-mp3fs does not build with current vers f ports/179572 Add option for science/py-h5py to use science/hdf5-18 o ports/179545 update dns/dnscrypt-proxy to 1.3.1 o ports/179499 [patch] port sysutils/devcpu-data is unmaintained and o ports/179480 [MAINTAINER] www/MT: update to 5.2.6,1 o ports/179462 New port: devel/ocaml-opam - package manager for OCaml o ports/179460 [MAINTAINER] multimedia/transcode: Add v4l support f ports/179436 security/openvpn-devel: broken checksum f ports/179370 updating science/paraview f ports/179365 switch devel/gnustep-make dependency from lang/gcc42 t o ports/179321 New port: sysutils/storcli SAS MegaRAID FreeBSD StorCL o ports/179316 [NEW PORT] dns/ddns: lightweight UDP-based dynamic DNS o ports/179305 new port: www/p5-Dancer2, Perl extension for minimal-e f ports/179295 [PATCH] databases/mantis: Update to 1.2.15 f ports/179268 [PATCH] www/trafficserver: Fix disk usage miscalculate f ports/179236 Build failure (lib-depends) for net/tigervnc when HPJP o ports/179203 [maintainer update] net/gpxe : Fix checksum mismatch o ports/179180 devel/freeocl: Minor changes regarding upcoming POCL p o ports/179116 New port: graphics/xcftools Command-line tools for ext f ports/179081 www/dfileserver upstream disapear o ports/179030 New port: devel/dxa65: dxa65 disassembler for MOS 6502 o ports/179021 New port: devel/xa65: xa65 high-speed, two-pass portab o ports/179019 New port: devel/acme: cross-assembler for 6502, 65c02 f ports/179010 [PATCH] devel/doxygen: update to 1.8.4_1 f ports/179003 Port net-mgmt/nagios has lost dependency(textproc/php5 o ports/178998 New port: devel/sfml2: a multimedia library o ports/178982 devel/opencl: Update and patch Makefile f ports/178973 [PATCH] net/scribe: Use USE_GITHUB framework to fetch o ports/178946 New port: net/owncloud-csync, a library for mirall, an o ports/178945 [NEW PORT] devel/commit-patch: Commit patches or parti f ports/178826 Upgrade net/rabbitmq to 3.1.1 o ports/178808 devel/wxGlade raises exception when generating XRC cod f ports/178785 mail/dracmail: adoption of optionsNG, and standardize o ports/178784 [patch] enable PowerPC support in devel/gdb o ports/178783 [NEW PORT] misc/auto-multiple-choice: Multiple Choice o ports/178780 [patch] updated databases/libdbi-drivers to 0.9.0 o ports/178772 Port update: net-mgmt/snmptt f ports/178766 science/hdf5: crt1.c:(.text+0x8a): undefined reference o ports/178757 devel/freeocl: Update o ports/178726 [PATCH] databases/mariadb55-server: multi-instances st o ports/178709 [new port]: databases/hyperdex Searchable distributed o ports/178695 [new port] www/eaccelerator-devel Development version f ports/178687 audio/clementine-player fails to build f ports/178616 ports-mgmt/porttools: port test does not handle pkgNG o ports/178614 [new port]: databases/php5-tarantool PECL PHP driver f o ports/178557 Ports with USE_GCC=any don't respect local CC and CXX f ports/178534 sysutils/gkrelltop: master_site disappeared (universit o ports/178530 japanese/mutt-devel update to 1.5.21-ja.2 f ports/178529 net/hornetq: uses home directory during build, not all f ports/178475 [UPDATE] graphics/gmt: New version 4.5.9 available o ports/178474 [NEW PORT] games/linux-dwarf-fortress: Dwarf Fortress o ports/178464 [NEW PORT] www/redaxo: The REDAXO content management s o ports/178457 [New port]audio/hydrogen-devel o ports/178441 [NEW PORT] databases/memkeys: A tool to show memcache f ports/178431 graphics/geos hardcodes PHP 5.4 version o ports/178333 [new port] net/libnss-pgsql: allow user accounts to be s ports/178281 [new port] www/torbrowser: Request for a Native Torbro f ports/178275 build failed: net/rabbitmq: validity error : Could not f ports/178251 [patch] converters/unix2dos implicit declaration of fu f ports/178246 mail/fetchyahoo: is BROKEN f ports/178245 [patch] mail/getlive: 3.0 has been released o ports/178240 Update port science/meep to 1.2 f ports/178239 Update port science/libctl to 3.2.1 f ports/178229 devel/gnustep failed install - no objective c compiler o ports/178196 /usr/ports/www/trac-mercurial broken f ports/178187 [PATCH] games/freedink-dfarc: Fix build and plist o ports/178160 emulators/sness9express: Fix build o ports/178126 [NEW PORT] databases/mysql56-server-cluster: MySQL Clu o ports/178125 [NEW PORT] databases/mysql56-client-cluster: Multithre o ports/178078 [new port]: lang/angelscript AngelCode Scripting Libra o ports/178052 New port submission: dns/mDNSRedponder_nss f ports/178042 sysutils/ezjail: zsh completion does not work f ports/178024 mail/archmbox -- uses fuser(1) with incompatible flags f ports/177991 astro/qlandkartegt : upgrade to 1.7.0 o ports/177906 [new port] x11-fonts/fpf Free Persian font o ports/177900 New port: net/owncloud-csync, a backend app for Ownclo f ports/177797 [PATCH] mail/postfix-policyd-spf-python: update to 1.1 o ports/177790 [new port] security/axTLS o ports/177771 maintainer update: math/dolfin-devel f ports/177758 security/amavisd-milter does not build on FreeBSD 9.1 o ports/177753 New port: sysutils/slurm-devel o ports/177745 New port: science/lammps o ports/177744 New port: science/lammps-openmpi f ports/177741 net-mgmt/sipcalc cannot handle ipv6 zone index f ports/177733 [maintainer update] graphics/nomacs update to version f ports/177721 multimedia/mplayer: Missing dependency o ports/177692 New port: science/openkim f ports/177669 news/nzbget - PostProcess script terminated with unkno o ports/177651 New port: security/openiked OpenBSD's IKEv2 daemon o ports/177649 [NEW PORT] net/hanstunnel: Hans makes it possible to t o ports/177643 Update port graphics/fotoxx to latest version o ports/177589 [maintainer update] misc/vifm: update to 0.7.4b f ports/177588 ports-mgmt/porttools: does not permit SVN diff mode ou o ports/177584 New port: sysutils/graffer - utility which collects n o ports/177565 [NEW PORT] www/trac-keywordsecretticket: Adds ticket s o ports/177512 Make emulators/snes9express compile again o ports/177506 irc/unreal: Update UnrealIRCD to 3.2.10 f ports/177497 mail/dovecot startup script breaks onestart functional o ports/177493 [patch] change games/minecraft-client to use openjdk7 o ports/177492 [New Port] graphics/multiraw (replace prev) o ports/177490 [New Port] graphics/dcraw-m Modified dcraw o ports/177486 [NEW PORT] mail/opendmarc: DMARC library an milter imp o ports/177418 [New Port] math/cloog o ports/177411 [NEW PORT] databases/mysql-udf-ipv6: MySQL UDFs provid f ports/177407 graphics/fotoxx: MASTER_SITES kornelix.squarespace.com f ports/177406 update port and add arch: lang/mlton o ports/177401 Mk/bsd.ldap.mk move -DLDAP_DEPRECATED from CFLAGS to C f ports/177397 [patch] security/heimdal: fix conflict between heimdal f ports/177371 sysutils/smartmontools - triggers channel blocking o ports/177370 New port: audio/opusfile o ports/177364 [patch] math/scilab port build fails configuration ste o ports/177363 graphics/pqiv aborts when opening an image f ports/177340 [PATCH] devel/php-xdebug: update to 2.2.2 f ports/177222 deskutils/cairo-dock-plugins won't build o ports/177220 New Port: ports-mgmt/chucky o ports/177211 net-mgmt/cflowd: cflowd CflowdPacketQueue.cc fix f ports/177207 multimedia/xbmc maint update to 12.1 f ports/177193 audio/moc: please include FLAC support by default in p o ports/177182 audio/mixxx segmentation fault f ports/177152 sysutils/fusefs-kmod missing pkg-message file o ports/177074 [fix] audio/timidity and audio/guspat o ports/177071 editors/slime not working with emacs-24 o ports/177042 [new port] emulators/ucon64 o ports/177014 new port: databases/sqlayer f ports/176874 sysutils/fusefs-sshfs crashes on amd64 f ports/176816 www/privoxy+ipv6 is obsolete f ports/176805 rc scripts provided with security/heimdal haven't a co o ports/176782 new port: dns/bind10 o ports/176767 [patch] net-im/ari-yahoo broken on freebsd-head o ports/176720 sysutils/syslinux 5.01 not installing all c32 files o ports/176716 [patch] devel/boehm-gc update to 7.2d combining previo f ports/176676 [patch] net/ss5: syslog option is noisy o ports/176660 [ports] editors/pdfedit: build failure on ia64 -curren o ports/176651 NEW PORT: graphics/flashprojector - Adobe standalone S o ports/176625 New Port: ports-mgmt/prhistory-sync-perl Sync GNATS PR o ports/176615 New port: deskutils/cairo-dock3, Cairo-Dock is a light o ports/176613 New port: devel/libgdbmgr, vim interface to gdb o ports/176509 [NEW PORT] www/dnssec-validator: DNSSEC Validator exte o ports/176507 [NEW PORT] www/xpi-dnssec: DNSSEC Validator extension o ports/176505 [NEW PORT] www/crx-dnssec: DNSSEC Validator extension o ports/176504 [NEW PORT] devel/crxmake: Make chromium extensions o ports/176468 www/sams can not use the mask /32, with authorization o ports/176456 NEW PORT: lang/jsawk - Command-line JSON parser o ports/176445 New port: audio/icecast-kh Streaming mp3/ogg-vorbis au s ports/176442 Port files with double-colons cannot exist on FAT part f ports/176438 net-mgmt/nrpe2 consuming cpu when handling new connect f ports/176423 audio/clementine-player: always needs two starts f ports/176383 sysutils/ipmitool cannot connect over SOL o ports/176378 [PATCH] Fix several typos in the ports tree o ports/176195 [PATCH] games/cre: Set NO_WRKSUBDIR and BUILD_WRKSRC i f ports/176180 mail/mailman broken without NLS f ports/176172 graphics/povray37: /usr/local/bin/ld: disp_sdl.o: unde o ports/176096 [NEW PORT] www/xibo-server: Xibo - Digital Signage (se o ports/176095 [NEW PORT] www/zikula: MVC web application framework ( f ports/176047 ports: graphics/ImageMagick: -delay option spurious me f ports/176044 ports: print/ghostview (1.5_3) segfault/coredump f ports/176012 irc/inspircd fails to detect OpenSSL in base running r f ports/175987 audio/clementine-player 1.1.0_1 - album art not displ o ports/175947 [NEW PORT] www/sogo: Groupware server with a focus on o ports/175946 [NEW PORT] devel/sope: An extensive set of GNUstep web f ports/175944 [PATCH] x11-wm/obmenu: OptionsNG, changed Makefile, De f ports/175936 [NEW PORT] x11-wm/lxmed: LXDE Main Menu Editor f ports/175868 security/nessus-libnasl: nasl_crypto.c:25:10: fatal er f ports/175813 [patch] mail/dovecot2 doesn't detect libstemmer or ext f ports/175798 FreeBSD 10 unable to build sysutils/fusefs-kmod f ports/175772 Update to finance/php-tclink o ports/175748 New port: www/your-freedom A SOCKS proxy application f ports/175733 devel/libatomic_ops: Segmentation fault : install - o ports/175620 New port: devel/bashdb, Bash debugger f ports/175611 sysutils/zfs-periodic package do not enable cron to ho f ports/175534 [patch] net-mgmt/rackmonkey: Fix a redirect f ports/175523 pkgng: mail/dovecot2-pigeonhole conflicts with mail/do f ports/175429 audio/clementine-player: build error o ports/175385 dns/fastresolve does not compile o ports/175308 [NEW PORT] graphics/linux-f10-sdl_ttf: SDL graphics dr o ports/175307 [NEW PORT] graphics/linux-f10-sdl_gfx: SDL graphics dr o ports/175274 [NEW PORT] audio/linux-f10-libsndfile: Reading and wri o ports/175234 update multimedia/qmmp, multimedia/qmmp-plugin-pack o ports/175233 devel/boehm-gc: GC does not scan static roots in share o ports/175229 x11-toolkit/swt-devel fails f ports/175121 devel/buildapp does not produce executable file o ports/175113 devel/freeocl: Port revision PORTREVISION=1 f ports/175107 devel/opencl: bug in CL/cl_ext.h (upstream): o ports/175068 [PATCH] net/proxychains: update to 4.4, take maintaine o ports/174988 New port: net/tclsoap o ports/174960 sysutils/fusefs-ntfs mkntfs fails because of "no block o ports/174951 [PATCH] games/vamos: added OptionsNG, icon, desktop en o ports/174947 [new port] ftp/php5-dav, php5 webdav module, allowing o ports/174940 [new port]: misc/valspeak, a filter that converts Engl o ports/174911 [PATCH] cad/leocad: update to 0.79.1, take maintainers f ports/174898 graphics/openimageio: pkg: (openimageio-1.1.2) /usr/lo o ports/174883 databases/grass: cut: ../dist.amd64-portbld-freebsd10. f ports/174867 irc/unreal: Port Update to UnrealIRCD o ports/174841 graphics/sane-frontends fails to build f ports/174798 audio/soundtracker: request to add system menu item/en o ports/174795 x11-toolskits/open-motif: Installing open-motif-2.3.4. f ports/174764 [patch] upgrade databases/postgis to 1.5.8 (fixes comp o ports/174746 Segmentation fault in security/prelude-lml o ports/174667 [new port] sysutils/ksysguardd3 (KDE3 ksysguardd) o ports/174655 japanese/mutt-devel: mutt ja patch new version release o ports/174647 [NEW PORT] net/infinispan: Open source highly scalable f ports/174583 devel/libreadline-java: patch for UTF8 support o ports/174561 [patch] upgrade devel/avr-binutils from 2.20.1 to 2.22 o ports/174560 [patch] upgrade devel/avr-gcc from 4.5.1 to 4.6.2 o ports/174559 [patch] add vendor patchset to devel/avr-libc f ports/174487 mail/notmuch fails to build during portupgrade o ports/174368 New port: lang/nimrod The Nimrod programming language. s ports/174342 [NEW PORT] irc/shirk: Modular IRC bot based on the Twi o ports/174308 [bsd.database.mk] cyrus-sasl-2.1.25_2 will not compile f ports/174303 [PATCH] Update devel/libgta to version 1.0.4 o ports/174289 net/ssvnc build fails - configure: error: /usr/bin/cpp f ports/174237 databases/php5-redis - zAdd does not set the correct s o ports/174131 net/citrix_ica: Update port to 12.0.0.189834 f ports/174129 [Maintainer-Update] print/cups-bjnp to latest f ports/174118 graphics/pecl-gmagick o ports/174069 [PATCH] misc/explosions: OptionsNG, added categories, o ports/174057 [PATCH] misc/cmatrix: OptionsNG, added license, mtx.pc o ports/174055 Default Linux ALSA configuration update request o ports/174022 [PATCH] games/gnurobots: Added OptionsNG, license, des f ports/174018 Can't disable security/sshguard -b option o ports/174015 [PATCH] finance/venice: update to 0.751beta, take main o ports/173998 textproc/xalan-c from version 1.10 to 1.11 o ports/173996 net-mgmt/p5-Cflow: add support for net-mgmt/flow-tools o ports/173888 [NEW PORT] games/sudoku-sensei: Enjoy playing with Sud o ports/173882 [PATCH] games/xsc: Changed Comment, added Deskop entri o ports/173881 [NEW PORT] games/vodovod: Cross-platform pipe connecti o ports/173880 [PATCH] games/pipenightdreams: Added Portdoss, Desktop o ports/173875 [PATCH] games/cuyo: update to 2.0.0,1, Added License, f ports/173858 sysutils/bsdadminscripts installs pkg_libchk that does o ports/173581 new port submission, security/sagan o ports/173542 [PATCH] graphics/fracplanet: take maintainership, Make o ports/173534 [NEW PORT] games/wizznic: Implementation of the arcade f ports/173489 [PATCH] databases/mysqltuner: [SUMMARIZE CHANGES] o ports/173457 [NEW PORT] games/edgar: 2D platform game with a persis f ports/173369 math/gnuplot+: avoid conflicts with math/gnuplot o ports/173368 [PATCH] games/glmaze: OptionsNG, changed Makefile, add o ports/173352 [PATCH] games/gtkatlantic: OptionsNG, changed Makefile o ports/173351 [PATCH] games/4stattack: OptionsNG, Makefile simplifie o ports/173350 [PATCH] games/ppracer: OptionsNG, Makefile changed, ta o ports/173335 [PATCH] games/xarchon: OptionsNG, changed Makefile, pk o ports/173282 New port: security/keepassx2 Cross Platform Password M f ports/173230 sysutils/parallel 20121022 complains about defined(@ar o ports/173194 [new port] java/eclipse-birt: BIRT plugin for Eclipse o ports/173184 [PATCH] games/abe: Makefile changed, removed pkg-plist o kern/173030 [atf] [patch] emulators/open-vm-tools: fix clang compi o ports/173021 [NEW PORT] www/jetspeed2: Open Source Portal, written o ports/172981 [NEW PORT] devel/allegro-devel5: Cross-platform librar o ports/172967 [restore port] www/asterisk-gui for asterisk 1.6 to as o ports/172944 [NEW PORT] games/oneisenough: Economic development in o ports/172917 textproc/syck: LuaYAML-Testcases test-suite for lua ex o ports/172863 [NEW PORT] net/pjsip: Multimedia communication library f ports/172837 lang/swi-pl compiles with databases/libiodbc f ports/172750 graphics/luminance does not compile if graphics/libraw f ports/172595 New port: net-p2p/pushpoold bitcoin push-mining pool s f ports/172441 chinese/fcitx should be in 'textproc' instead of 'chin o ports/172439 [New Port] chinese/fcitx-table-yonh: Pinyin-like input f ports/172361 lang/gnustep-base fail to configure with clang f ports/172353 multimedia/mencoder does not build with clang on amd64 f ports/172272 www/speedtest-mini - port not working o ports/172168 [new port] comms/libdlo: the basis for the DisplayPort f ports/172141 [PATCH] deskutils/q4wine: update to 0.121, OptionsNG, f ports/171950 devel/tnt: include/tnt/tnt_sparse_matrix_csr.h:97:3: e o ports/171945 sysutils/fusefs-smbnetfs crash since fusefs-libs updat o ports/171921 New port: devel/ocltools: o ports/171903 net-mgmt/observium port should only provide dependenci f ports/171886 [PATCH] multimedia/gpac-mp4box: [SUMMARIZE CHANGES] f ports/171868 [new port] net/remotebox: Open Source VirtualBox Clien o ports/171855 [NEW PORT] net-mgmt/node-statsd - Simple daemon for ea f ports/171850 Misleading pkg install option in sysutils/fusefs-kmod f ports/171849 databases/postgis: port switches compiler! GCC -> CLAN f ports/171818 Please add option for Python-integration to sysutils/b o ports/171801 [patch] www/sams: Problem with creating MySQL database o ports/171798 [PATCH] textproc/sablotron: MASTER_SITES, CFLAGS, Docu o ports/171735 [NEW PORT] editors/py31-loook-devel: Simple Python too o ports/171734 [NEW PORT] editors/py27-loook: Simple Python tool that o ports/171675 [NEW PORT] games/cocos2d: Framework for building 2D ga o ports/171603 [NEW PORT] games/py27-dcross: Blocks fall from the top o ports/171602 [NEW PORT] games/py27-cargocarrier: Collect cargo crat o ports/171576 [NEW PORT] games/py27-bombz: Simple 2D puzzle game wit o ports/171559 [NEW PORT] games/airstrike: 2d biplane dogfight game o ports/171552 [NEW PORT] games/traingame: Game about Trains f ports/171539 [patch] net-mgmt/nrpe2 small fixes o ports/171392 [NEW PORT] games/py27-super_mario_bros_python: Clone o o ports/171391 [NEW PORT] games/py27-pytowerdefense: Tower Defense Ga f ports/171338 both databases/mariadb-scripts and databases/mariadb-s o ports/171332 [NEW PORT] games/py27-pythonsudoku: Text and graphical o ports/171236 [NEW PORT] games/schwarzweiss: Tank game for 2 players f ports/171231 audio/clementine-player starts only at the second time o ports/171224 [NEW PORT] games/bouncy: You are a hungry rabbit. Eat o ports/171176 new port: net/winexe f ports/171160 sysutils/loganalyzer depends on php5 o ports/171149 new port: textproc/imsettings - a framework manages in o ports/171106 New Port: net/jdownloader - Download manager (java) o ports/171019 [new port] science/isis3: USGS ISIS3 planetary mapping o ports/171017 [new port] astro/cspice: New scientific port: NASA/NAI o ports/170819 New port: net-mgmt/UniFi UniFi Wireless Controller o ports/170695 sysutils/fusefs-ntfs - instant reboot when mv from UFS o ports/170662 [NEW PORT] devel/pymunk: A easy-to-use pythonic 2d phy o ports/170661 [NEW PORT] graphics/py27-pyglet-devel: Cross-platform o ports/170448 [NEW PORT] devel/allegro5: Allegro 5 is a game program o ports/170417 Update port: sysutils/grub2 to 2.00 f ports/170366 lang/libobjc2: update to 1.6.1 f ports/170339 www/node: segmentation violation in v8::internal::Hand f ports/170100 astro/orsa: version 0.7.0 in ports hopelessly outdated o ports/169741 [new port] devel/visualparadigm o ports/169628 sysutils/devcpu-data f ports/169322 New port: net/armsd: SMFv2/ARMS Service Adapter daemon o ports/169165 sysutils/fusefs-kmod: calling fchown(2) on sshfs files o ports/168647 Remove trailing spaces from all ports-related files o ports/168404 [NEW PORT] databases/dev-sqlite3: This is a developmen o ports/168328 [REPOCOPY] devel/codeblocks --> devel/codeblocks-devel o ports/168114 [NEW PORT] games/duckmaze: A game about a duck that is o ports/167759 [New Ports] x11-wm/e17-modules-ecomorph and x11-wm/eco f ports/167691 security/heimdal: problem compiling kerberos/heimdal o ports/167042 New port: net-p2p/tahoe-lafs f ports/167031 security/heimdal ignore environment after process call o ports/166987 net/nss_ldap: ports/152982 causes nss_ldap to not func o ports/166826 New port: misc/libphidget The driver for Phidgets devi o ports/166812 New port: mail/bounceHammer o ports/166006 Problem with postfix and mail/mailman integration o ports/165586 New port german/lx-office-erp, sql-ledger fork with ex o ports/165565 New port: www/mod_auth_token Token-based authenticatio o ports/164197 smsd(comms/smstools3) doesn't read some configurations o ports/163850 New port: cad/linux-bricscad o ports/158983 [NEW PORT] devel/pecl-dtrace: PHP DTrace provider o ports/158791 Update security/openvas-* o ports/156834 New port: games/fairymax-devel latest version of games o i386/138737 [endian] [patch] Patch for bswap64(9) operation on IA o ports/107354 net/icmpinfo: icmpinfo -vvv does not recocnize any ICM 358 problems total. From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 12:07:49 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A23FD9B for ; Mon, 24 Jun 2013 12:07:49 +0000 (UTC) (envelope-from indexbuild@FreeBSD.org) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) by mx1.freebsd.org (Postfix) with ESMTP id 8CFEF12AF for ; Mon, 24 Jun 2013 12:07:49 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.7) with ESMTP id r5OC7nnN063953 for ; Mon, 24 Jun 2013 12:07:49 GMT (envelope-from indexbuild@portsindexbuild.ysv.freebsd.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.5/Submit) id r5OC7nct063952 for ports@FreeBSD.org; Mon, 24 Jun 2013 12:07:49 GMT (envelope-from indexbuild) Date: Mon, 24 Jun 2013 12:07:49 GMT From: Ports Index build Message-Id: <201306241207.r5OC7nct063952@portsindexbuild.ysv.freebsd.org> To: ports@FreeBSD.org Subject: INDEX build failed for 8.x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:07:49 -0000 INDEX build failed with errors: Generating INDEX-8 - please wait..clang: not found clang: not found Done. Warning: Duplicate INDEX entry: pkg-1.1 Committers on the hook: bapt culot decke demon gahr rene wg zi Most recent SVN update was: Updating '.': A net-im/openfire/files/patch-tls-dialback U net-im/openfire/Makefile U net-im/openfire/distinfo UU devel/uthash/Makefile UU devel/uthash/distinfo UU security/duo/pkg-plist UU security/duo/Makefile UU security/duo/distinfo UU security/duo/files/pkg-message.in A security/duo/files/patch-login__duo_Makefile.in A security/duo/files/patch-pam__duo_Makefile.in U comms/dcf77pi/Makefile U comms/dcf77pi/distinfo A math/gambit/files A math/gambit/files/patch-src-labenski-src_sheet.cpp UU math/gambit/pkg-plist UU math/gambit/Makefile UU math/gambit/distinfo U net-mgmt/netdisco/distinfo U net-mgmt/netdisco/files/pkg-message.in U net-mgmt/netdisco/files/netdisco.in U net-mgmt/netdisco/pkg-plist U net-mgmt/netdisco/Makefile Updated to revision 321677. From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 15:07:57 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94CDE916 for ; Mon, 24 Jun 2013 15:07:57 +0000 (UTC) (envelope-from indexbuild@FreeBSD.org) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3F71CC1 for ; Mon, 24 Jun 2013 15:07:57 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.7) with ESMTP id r5OF7uxT055257 for ; Mon, 24 Jun 2013 15:07:56 GMT (envelope-from indexbuild@portsindexbuild.ysv.freebsd.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.5/Submit) id r5OF7ugE055255 for ports@FreeBSD.org; Mon, 24 Jun 2013 15:07:56 GMT (envelope-from indexbuild) Date: Mon, 24 Jun 2013 15:07:56 GMT From: Ports Index build Message-Id: <201306241507.r5OF7ugE055255@portsindexbuild.ysv.freebsd.org> To: ports@FreeBSD.org Subject: INDEX now builds successfully on 8.x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:07:57 -0000 From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 16:21:05 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2CB0AC9; Mon, 24 Jun 2013 16:21:05 +0000 (UTC) (envelope-from qat@redports.org) Received: from qat.redports.org (qat.redports.org [96.47.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id B85FD1079; Mon, 24 Jun 2013 16:21:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=redports.org; s=04012012; h=Sender:Message-Id:To:Subject:Reply-To:Date:To:Cc:From:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=RHvfisYwlb3fWY2ISuJPPVLaXWGBXj09bVIpn7CdFvM=; b=ldzvQWsvl5Wsjr+MIr18q65ihCip2xQq/d1CL8hjPTrTp6VbiZDiIcSbVClYlf3D7gc5d5bmRb3z6O9DCxeUjQux3V7qV3dQg3rCrV3P5bH02Cbf8qP/OlDz4JGXMV0zVZpwOxqubUK7a2L+5EVH8tZvKYP3iXEjQFNt28K12sk=; Received: from www by qat.redports.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ur9Vo-000AQw-23; Mon, 24 Jun 2013 16:21:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ports-QAT" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: wg@FreeBSD.org X-Trac-Project: redports Date: Mon, 24 Jun 2013 16:21:04 -0000 X-URL: https://qat.redports.org/ Subject: [QAT] r321689: 4x leftovers To: wg@FreeBSD.org X-Trac-Build-URL: https://qat.redports.org/buildarchive/20130624161000-34658 X-Trac-Build-ID: 20130624161000-34658 Message-Id: Sender: World Wide Web Owner Cc: ports@FreeBSD.org, decke@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: qat@redports.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:21:06 -0000 devel/py-hgsubversion: update to 1.5.1 - Update to 1.5.1 - Add LICENSE (GPLv2) - Add creator address --------------------------------------------------------------------- Build ID: 20130624161000-34658 Job owner: wg@FreeBSD.org Buildtime: 11 minutes Enddate: Mon, 24 Jun 2013 16:21:02 GMT Revision: r321689 Repository: https://svnweb.freebsd.org/ports?view=revision&revision=321689 --------------------------------------------------------------------- Port: devel/py-hgsubversion 1.5.1 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~wg@FreeBSD.org/20130624161000-34658-155132/py27-hgsubversion-1.5.1.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~wg@FreeBSD.org/20130624161000-34658-155133/py27-hgsubversion-1.5.1.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~wg@FreeBSD.org/20130624161000-34658-155134/py27-hgsubversion-1.5.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~wg@FreeBSD.org/20130624161000-34658-155135/py27-hgsubversion-1.5.1.log -- Buildarchive URL: redports From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 17:58:29 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id D1657257; Mon, 24 Jun 2013 17:58:28 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 5724023CE92; Mon, 24 Jun 2013 19:58:26 +0200 (CEST) Message-ID: <51C888C2.2040706@FreeBSD.org> Date: Mon, 24 Jun 2013 19:58:26 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? References: <20130613031535.4087d7f9@bsd64.grem.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 17:58:29 -0000 Am 22.06.2013 00:27, schrieb Dimitry Andric: > Attached is a diff to fix the db5 port, so it correctly builds with > CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please have a > look at it? Does databases/db6 as a requisite make your failing port compile properly? From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 18:23:35 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19794A07 for ; Mon, 24 Jun 2013 18:23:35 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 6054617BA for ; Mon, 24 Jun 2013 18:23:33 +0000 (UTC) Received: (qmail 4199 invoked by uid 89); 24 Jun 2013 18:23:26 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.167.148) by mail.grem.de with ESMTPA; 24 Jun 2013 18:23:26 -0000 Date: Mon, 24 Jun 2013 20:23:26 +0200 From: Michael Gmelin To: Matthias Andree Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130624202326.2a6111a6@bsd64.grem.de> In-Reply-To: <51C888C2.2040706@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <51C888C2.2040706@FreeBSD.org> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 18:23:35 -0000 On Mon, 24 Jun 2013 19:58:26 +0200 Matthias Andree wrote: > Am 22.06.2013 00:27, schrieb Dimitry Andric: > > > Attached is a diff to fix the db5 port, so it correctly builds with > > CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please > > have a look at it? > > Does databases/db6 as a requisite make your failing port compile > properly? The port failing to build using c++11 is databases/db5 itself. The port depending on db5 that raised the question is devel/ice, which might build with db6, but upstream only developed and tested it using db5, so sticking to that version is preferred. -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 19:01:52 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA8CDDF7 for ; Mon, 24 Jun 2013 19:01:52 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id AE75D1946 for ; Mon, 24 Jun 2013 19:01:52 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r5OJ1ndr048484; Mon, 24 Jun 2013 13:01:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r5OJ1n4P048481; Mon, 24 Jun 2013 13:01:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 24 Jun 2013 13:01:49 -0600 (MDT) From: Warren Block To: Bernt Hansson Subject: Re: Unable to print from firefox In-Reply-To: <51B9E7A8.7020309@bananmonarki.se> Message-ID: References: <20130612090116.GA45417@pcjas.obspm.fr> <51B9E7A8.7020309@bananmonarki.se> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 24 Jun 2013 13:01:49 -0600 (MDT) Cc: Albert Shih , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:01:53 -0000 On Thu, 13 Jun 2013, Bernt Hansson wrote: > > > On 2013-06-12 11:01, Albert Shih wrote: >> Hi >> >> I'm unable to print from firefox/chrome/opera so that really s***.. >> >> When I try to print something in firefox I got this message >> >> (firefox:45435): Gtk-WARNING **: Unknown paper size A4 > > Do you have for example print/libpaper, print/papersize-default-a4 or any > other paper size stuff installed. Just getting back to this. I decided to see what had installed cups-client as a dependency. To my surprise, pkg_delete did not complain and just went ahead and deleted it. Now Firefox printing is fine. From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 19:15:21 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C4714B6; Mon, 24 Jun 2013 19:15:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id F379219D2; Mon, 24 Jun 2013 19:15:20 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c59:a48:7e6d:e3d1] (unknown [IPv6:2001:7b8:3a7:0:c59:a48:7e6d:e3d1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EB7815C43; Mon, 24 Jun 2013 21:15:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Are ports supposed to build and run on 10-CURRENT? From: Dimitry Andric In-Reply-To: <20130624202326.2a6111a6@bsd64.grem.de> Date: Mon, 24 Jun 2013 21:15:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130613031535.4087d7f9@bsd64.grem.de> <51C888C2.2040706@FreeBSD.org> <20130624202326.2a6111a6@bsd64.grem.de> To: Matthias Andree X-Mailer: Apple Mail (2.1508) Cc: "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:15:21 -0000 On Jun 24, 2013, at 20:23, Michael Gmelin wrote: > On Mon, 24 Jun 2013 19:58:26 +0200 > Matthias Andree wrote: >> Am 22.06.2013 00:27, schrieb Dimitry Andric: >> >>> Attached is a diff to fix the db5 port, so it correctly builds with >>> CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please >>> have a look at it? >> >> Does databases/db6 as a requisite make your failing port compile >> properly? > > The port failing to build using c++11 is databases/db5 itself. The port > depending on db5 that raised the question is devel/ice, which might > build with db6, but upstream only developed and tested it using > db5, so sticking to that version is preferred. Indeed, I should probably have sent this a separate mail, sorry. The diff was just to get db5 building with libc++. A similar diff is needed for db6, but before I start producing it, I would like to know if there is any interest. :-) Note the fixes are mostly trivial, just a renaming of a few identifiers. If you would rather have me take it upstream, please let me know. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 19:42:39 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AFE50F27 for ; Mon, 24 Jun 2013 19:42:39 +0000 (UTC) (envelope-from crwhipp@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 7495B1BB7 for ; Mon, 24 Jun 2013 19:42:39 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j8so19815qah.10 for ; Mon, 24 Jun 2013 12:42:39 -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=EWs4vkODxD+6QLoPzL33OyWAGlUktaTapjl/Qg9KHrA=; b=vDFZLtTRUgjyell7N8JCL2+CIl3j8EvSww9aEJZ6QFsgIR7UqYlF2cwM2CuedtjjnO L91tF1KfWOvO51/Z2B2g2QMbD7nL38m5fbIK6aCteloVezlfuB6sr71EjJMpm0g8qewm YvpjT/s8142ikQ3qUzi5HL7TzXUN2iwoZVnPp1jRwSxLvs7bfF3+u/gOQnBt14nT7VJ/ 7G8DkCY1p+wqKVcXxJVQyiJk1x/B0yR/WibjLOgFu57Drc0sCGUi52eMYf3+ECr9OKFq dAYEusEXoNXnRxdNM9LPY0c3BlSS4bCzqzPMMpWNUcpwNCzP0Z/8g6XORmuiSj7nSBsg 3GKg== MIME-Version: 1.0 X-Received: by 10.224.114.207 with SMTP id f15mr20438374qaq.115.1372102958942; Mon, 24 Jun 2013 12:42:38 -0700 (PDT) Received: by 10.224.45.70 with HTTP; Mon, 24 Jun 2013 12:42:38 -0700 (PDT) In-Reply-To: <20130430081629.GA26813@sh4-5.1blu.de> References: <20130428180134.GA1770@tiny.Sisis.de> <20130429154031.GA2206@tinyCurrent> <20130429205032.GO3880@defora.org> <20130429212416.4039e3d6@gmail.com> <20130430081629.GA26813@sh4-5.1blu.de> Date: Mon, 24 Jun 2013 12:42:38 -0700 Message-ID: Subject: Re: astro/foxtrotgps (1.1.1_1 from ports SVN r315646) crashes on start From: Craig Whipp To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ports@freebsd.org, Pierre Pronchery X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:42:39 -0000 I submitted a PR to patch this, with the change from upstream. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D179919 On Tue, Apr 30, 2013 at 1:16 AM, Matthias Apitz wrote: > El d=EDa Monday, April 29, 2013 a las 09:24:16PM -0700, Craig Whipp escri= bi=F3: > > > On Mon, 29 Apr 2013 22:50:32 +0200 > > Pierre Pronchery wrote: > > > > > Hey, > > > > > > On Mon, Apr 29, 2013 at 05:40:32PM +0200, Matthias Apitz wrote: > > > > El d=EDa Sunday, April 28, 2013 a las 08:01:35PM +0200, Matthias > > > > Apitz escribi=F3: > > > > > > > > > Foxtrotgps crashes on start on 10-CURRENT r235646 during > > > > > 'pthread_mutex_unlock', details follow below; > > > > > > > > The attached patch (to be placed in > > > > astro/foxtrotgps/files/patch-src-main before 'make install') fixes > > > > the bug; > > > > > > thank you for the patch, it fixes the reproducible crash upon startup= , > > > and I have committed it to pkgsrc-wip. > > > > > > However, I am afraid that it may break functionality, and allow only > > > the main Gtk+ thread to start. Map download in particular was > > > performed in a separate thread in TangoGPS IIRC, and here foxtrot > > > doesn't download anything... I'm afraid this issue results from the > > > patch. It may be more work than just this to get it to run properly := / > > > > > > Please let me know if it works better for you. > > I've tested the patched foxtrotgps this morning and can confirm: > - it does not crash on startup anymore > - it fetches missing tiles (I watched with TCPDUMP to make that sure); > > > > I don't have a CURRENT machine to test this on. FoxtrotGPS works fine > > on 9.1-RELEASE, without the patch. What's the difference between 9.1 > > and -CURRENT that would cause this to break? > > I have an older VM with: > > $ uname -a > FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 1= 7 > 03:28:12 CEST 2011 > > $ head Makefile > ... > # $FreeBSD: ports/astro/foxtrotgps/Makefile,v 1.3 2011/03/25 20:30:54 > amdmi3 Exp $ > # > > PORTNAME=3D foxtrotgps > PORTVERSION=3D 1.0.0 > PORTREVISION=3D 2 > > in this older kernel + ports the foxtrotgps works as well unpatched; mayb= e > now > in -CURRENT (and ports from SVN head) there has something changed in the > Gtk shared libs; my patch contains a comment to some thread about a > discussion of the same problem in tangGPS and I have just derived as I > wild guess the change from this discussion (see the reply there from > Kirill of 9th October 2012). For sure, one could compile gdk and gtk > with debug symbols and step down with gdb to verify this. I will let > this for someone else :-) > > > For what it's worth, my initial testing shows that map tile downloads > > seem to work fine on 9.1-RELEASE with the patch applied, too. > > Good to know. I'd apply the patch to ports /head if it works for me and > Pierre and does not break 9.1-RELEASE > > Thanks > > matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 19:59:38 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 6BC4E514; Mon, 24 Jun 2013 19:59:38 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 67A4B23CEE7; Mon, 24 Jun 2013 21:59:37 +0200 (CEST) Message-ID: <51C8A529.40508@FreeBSD.org> Date: Mon, 24 Jun 2013 21:59:37 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? References: <20130613031535.4087d7f9@bsd64.grem.de> <51C888C2.2040706@FreeBSD.org> <20130624202326.2a6111a6@bsd64.grem.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:59:38 -0000 Am 24.06.2013 21:15, schrieb Dimitry Andric: > On Jun 24, 2013, at 20:23, Michael Gmelin wrote: >> On Mon, 24 Jun 2013 19:58:26 +0200 >> Matthias Andree wrote: >>> Am 22.06.2013 00:27, schrieb Dimitry Andric: >>> >>>> Attached is a diff to fix the db5 port, so it correctly builds with >>>> CXXFLAGS?=-std=c++11 -stdlib=libc++. Matthias, could you please >>>> have a look at it? >>> >>> Does databases/db6 as a requisite make your failing port compile >>> properly? >> >> The port failing to build using c++11 is databases/db5 itself. The port >> depending on db5 that raised the question is devel/ice, which might >> build with db6, but upstream only developed and tested it using >> db5, so sticking to that version is preferred. > > > Indeed, I should probably have sent this a separate mail, sorry. The > diff was just to get db5 building with libc++. A similar diff is needed > for db6, but before I start producing it, I would like to know if there > is any interest. :-) > > Note the fixes are mostly trivial, just a renaming of a few identifiers. > If you would rather have me take it upstream, please let me know. These need to be taken upstream, but I will also need to fix db5 because I intend to keep that version going, as the last version under SleepyCat license. db6 has switched to the Affero GPL v3 which requires to also offer sources when the modified software is not distributed, but used as a service. As long as the identifiers are not exposed, renaming them should be safe. I will see to that, but it will take me a few days before I get around to it. Thanks for the heads-up. From owner-freebsd-ports@FreeBSD.ORG Mon Jun 24 21:01:24 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 823F84E9 for ; Mon, 24 Jun 2013 21:01:24 +0000 (UTC) (envelope-from info@newsletter.cisjournal.org) Received: from newsletter.cisjournal.org (newsletter.cisjournal.org [100.42.48.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5E53E1FA7 for ; Mon, 24 Jun 2013 21:01:24 +0000 (UTC) Received: from saeedm by glass.arvixe.com with local (Exim 4.80) (envelope-from ) id 1UrCTu-00012T-A0 for ports@FreeBSD.org; Mon, 24 Jun 2013 12:31:18 -0700 To: ports@FreeBSD.org Subject: Call for Papers (CFP) From: ARPN Publishers X-Mailer: twwMailer 1.2 Message-Id: Date: Mon, 24 Jun 2013 12:31:18 -0700 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - glass.arvixe.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [949 946] / [47 12] X-AntiAbuse: Sender Address Domain - newsletter.cisjournal.org X-Get-Message-Sender-Via: glass.arvixe.com: authenticated_id: saeedm/from_h MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:01:24 -0000 //** Apologies for cross-posting. Please send to interested colleagues and students **// Call for Papers Dear Scientists and Colleagues, On behalf of the ARPN Publishers, I would like to invite you to submit your valuable contributions in the following Journals: * JETCIS (Journal of Emerging Trends in Computing and Information Sciences) [1]http://www.cisjournal.org/ Topics of interest for JETCIS include, but are not limited to: * Computer Systems * Networks & Telecommunication * Database Systems and Theory * Embedded Systems * Information Technology * Artificial Intelligence * Distributed Computing * AJST (ARPN Journal of Science and Technology) [2]http://ejournalofscience.org/ Topics that fit the interests of the AJST include the following, but are not limited to: * Biology * Physics * Chemistry * Agriculture and Forestry * Environmental Sciences * Mathematics * Social Science * Political Science * AJSS (ARPN Journal of Systems and Software ) [3]http://scientific-journals.org/ A partial list of topics of interest includes: * Systems Biology / Bioinformatics * Software Engineering * Decision Support Systems * Discrete Systems and Methodologies * Mechanical and Physical Modeling * Fuzzy Systems / Models * Business Systems / Models * JEFM (Journal of Economics, Finance and Management) [4]http://ejournalofbusiness.org/ Journal Scope: * Finance * Economics * Banking * Accounting * Governments and Markets * Investments, Risks, and Returns * Corporate Culture * Entrepreneurship and Management Processes * Quantitative Methods and Econometrics Manuscript Submission: We invite paper submissions in five forms: * Original research * Literature Review / Systematic Literature Review * Short Articles on industrial and hands-on experience on any relevant area * Preliminary Findings * Technical Reports / Notes Each issue is running issue and all officially accepted manuscripts will be immediately published online. State-of-the-art running issue concept gives authors the benefit of 'Zero Waiting Time' for the officially accepted manuscripts to be published. Submissions must be original work and have not been published elsewhere, nor can they be under concurrent review for publication by another conference or journal. Confidentiality of submissions is maintained during the review process. All submitted papers should be written in English. All the submissions will be peer-reviewed by the panel of experts associated with journals. Once a manuscript has been accepted for publication, it will undergo language copyediting, typesetting, and reference validation in order to provide the highest publication quality possible. Manuscripts can be submitted through online submission system (by browsing the Journal URL) or in an electronic form (.pdf or .doc) to: [5]managing.editor.arpn@gmail.com Authors may contact ARPN for expression of interest and content appropriateness at any time. Since we receive papers in continuous flow, there is no deadline for manuscript submission. Sincerely Yours, Managing Editor ARPN Publishers __________________________________________________________________ Unsubscribe: If you prefer not to receive this email, please, send email to editor.scjournal@gmail.com with the subject unsubscribe. References 1. http://www.cisjournal.org/ 2. http://ejournalofscience.org/ 3. http://scientific-journals.org/ 4. http://ejournalofbusiness.org/ 5. mailto:managing.editor.arpn@gmail.com From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 02:10:28 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F2222E7F for ; Tue, 25 Jun 2013 02:10:28 +0000 (UTC) (envelope-from qdforwell@vip.sina.com) Received: from smtp-6-99.vip.sina.com (mail3-174.sinamail.sina.com.cn [202.108.3.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8051D1BB3 for ; Tue, 25 Jun 2013 02:10:27 +0000 (UTC) Received: from ironsmtp-xd5-205.sinamail.sina.com.cn (unknown [10.55.5.205]) by smtp-6-99.vip.sina.com (SINAMAIL) with ESMTP id 41A619581FC for ; Tue, 25 Jun 2013 10:10:26 +0800 (CST) X-Originating-IP: [172.16.53.123] Received: from unknown (HELO webmail.sinamail.sina.com.cn) ([172.16.53.123]) by ironsmtp-xd5-205.sinamail.sina.com.cn with ESMTP; 25 Jun 2013 10:10:26 +0800 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 80) id 39D005900D0; Tue, 25 Jun 2013 10:10:26 +0800 (CST) Date: Tue, 25 Jun 2013 10:10:25 +0800 Received: from qdforwell@vip.sina.com([124.163.223.251]) by vipmail2.mail.sina.com.cn via HTTP; Tue, 25 Jun 2013 10:10:25 +0800 (CST) From: "Elieen Wang" To: "ports" Subject: Event chairs and tables MIME-Version: 1.0 X-Priority: 3 X-MessageID: 1372126225.162.2829 X-Mailer: Sina WebMail 4.0 X-Sina-Sendseparate: 1 Message-Id: <20130625021026.39D005900D0@webmail.sinamail.sina.com.cn> Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: qdforwell@vip.sina.com List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:10:29 -0000 RGVhcnMNCg0KDQoKV2UgYXJlIG1hbnVmYWN0dXJlciBvZiBjaGFpcnMgZm9yIHdlZGRpbmcsZXZl bnQsaGlyZSxvZmZpY2UgZWN0LiBmcm9tIENoaW5hLiANCkhpZ2ggcXVhbGl0eSBhbmQgbG93IHBy aWNlLg0KQ291bGQgd2UgaGF2ZSBhIGNoYW5jZSB0byBjb29wZXJhdGVkIHdpdGggeW91P01heSBp IGtub3cgdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gb2YgeW91ciBwdXJjaGFzZSBkZXB0Lj8NCiAN ClRoYW5rIHlvdSBpbiBhZHZhbmNlLk5pY2UgZGF5IHRvIHlvdS4NCiANCkIuUgpFbGllZW4gV2Fu ZwotLS0tLS0tLS0tLS0KRm9yd2VsbCBGdXJuaXR1cmUgQ28sLkx0ZC4KaHR0cDovL3d3dy5xZGZv cndlbGwuY29tClRlbC9mYXg6Kzg2IDA1MzIgODgzODQ1MTUKRS1tYWlsOmluZm9AcWRmb3J3ZWxs LmNvbQotLS0tLS0tLS0tLS0NCgogDQoK From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 06:31:59 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 859DC1D5 for ; Tue, 25 Jun 2013 06:31:59 +0000 (UTC) (envelope-from leslie@eskk.nu) Received: from mx1.bjare.net (mx1.bjare.net [212.31.160.3]) by mx1.freebsd.org (Postfix) with ESMTP id 19F491652 for ; Tue, 25 Jun 2013 06:31:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.bjare.net (Postfix) with ESMTP id 2E1195E412; Tue, 25 Jun 2013 08:31:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx1.bjare.net X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SPF_SOFTFAIL=0.596] Received: from mx1.bjare.net ([127.0.0.1]) by localhost (mx1.bjare.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pfxwCMnctznR; Tue, 25 Jun 2013 08:31:47 +0200 (CEST) X-BN-MX1: ja X-BN-MailInfo: BjareNet Received: from bljbsd01.no-ip.org (c224-156-70-80.bjare.net [80.70.156.224]) by mx1.bjare.net (Postfix) with ESMTP id 6C12F5E4F9; Tue, 25 Jun 2013 08:31:45 +0200 (CEST) Message-ID: <51C93950.9060305@eskk.nu> Date: Tue, 25 Jun 2013 08:31:44 +0200 From: Leslie Jensen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130613 Thunderbird/17.0.6 MIME-Version: 1.0 To: Warren Block Subject: Re: Unable to print from firefox References: <20130612090116.GA45417@pcjas.obspm.fr> <51B9E7A8.7020309@bananmonarki.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Albert Shih , freebsd-ports@freebsd.org, Bernt Hansson X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 06:31:59 -0000 2013-06-24 21:01, Warren Block skrev: > On Thu, 13 Jun 2013, Bernt Hansson wrote: > >> >> >> On 2013-06-12 11:01, Albert Shih wrote: >>> Hi >>> >>> I'm unable to print from firefox/chrome/opera so that really s***.. >>> >>> When I try to print something in firefox I got this message >>> >>> (firefox:45435): Gtk-WARNING **: Unknown paper size A4 >> >> Do you have for example print/libpaper, print/papersize-default-a4 or >> any other paper size stuff installed. > > Just getting back to this. I decided to see what had installed > cups-client as a dependency. To my surprise, pkg_delete did not > complain and just went ahead and deleted it. Now Firefox printing is fine. > _______________________________________________ > 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" Interesting! If I do that I get: pkg delete cups-client pkg: Error while trying to delete packages, dependencies that are still required: print/cups-client: print/cups-base, print/cups-image, print/cups-pstoraster, print/ghostscript9, x11-themes/gtk-engines2, graphics/librsvg2, graphics/ImageMagick, devel/libglade2, net/avahi-gtk, print/teTeX-base, print/cm-super, print/dvipsk-tetex, devel/gconf2, graphics/libopenraw, x11-toolkits/gtkmm24, sysutils/gsmartcontrol, x11-themes/gtk-xfce-engine, print/gutenprint-base, print/gutenprint-cups, print/gutenprint-ijs, audio/libcanberra, devel/libnotify, x11-toolkits/libwnck, www/nspluginwrapper, x11-toolkits/py-gtk2, print/dvipdfmx, print/teTeX, x11/xfce4-conf, x11/libxfce4menu, x11/libexo, x11-fm/thunar-vfs, x11-toolkits/vte, x11/wbar, x11/wbarconf, print/xdvik, print/foomatic-filters, print/hplip, x11-toolkits/gtksourceview2, editors/mousepad, security/libgnome-keyring, devel/libsoup-gnome, sysutils/policykit-gnome, sysutils/gnome-mount, devel/gvfs, www/webkit-gtk2, print/gimp-gutenprint, print/gutenprint, x11-toolkits/unique, x11-fm/thunar, x11-toolkits/libxfce4gui, x11-wm/xfce4-panel, deskutils/orage, archivers/squeeze, misc/xfce4-appfinder, x11-wm/xfce4-desktop, audio/xfce4-mixer, deskutils/xfce4-notifyd, print/xfce4-print, sysutils/xfce4-settings, x11/xfce4-terminal, x11-wm/xfce4-wm, x11-wm/xfce4-session, x11-wm/xfce4, sysutils/xfce4-battery-plugin, sysutils/xfce4-systemload-plugin, sysutils/xfce4-wavelan-plugin, mail/thunderbird, mail/thunderbird-i18n, www/firefox, www/firefox-i18n, www/libxul, audio/pulseaudio, net/freerdp, java/icedtea-web, x11-toolkits/gtk20, graphics/gegl, net/remmina, net/remmina-plugin-i18n, net/remmina-plugin-vnc, editors/libreoffice, editors/libreoffice-sv, graphics/gimp-app, graphics/gimp /Leslie From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 09:35:42 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1210DB87 for ; Tue, 25 Jun 2013 09:35:42 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id D0CCB1DFE for ; Tue, 25 Jun 2013 09:35:41 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id ne12so511863qeb.41 for ; Tue, 25 Jun 2013 02:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=IFJMEvvzfzwZb7XnoCcUF6MmqfmkDBszq0q2aD5rJZQ=; b=tORHEFdVnygnkkoIAb4QHfBipLJ0WkQCzmJpqIPXFMpDsDvKcbwNB6MzfH/nz2iUuT D1Ak2xTDel3QpyNX7rxitMJRQnZdcND5oPttHLxaMKjgY2E7kXnq9QT0QTBAQX9uM6Bl n+EvOPbDeSjiJz8S5j9aqFJ9WXXWgLk0mO5LGmPhDPRyKSnkZWXmwFuRAy7Coj9XAy5r Ld/udcuCmQupCrwLxuPps+76PQT9r3R4W35nHCBRhdx8PO8QiE5q6D3wX3S+u8AuXnYj uBGu528BoFvedaE+lAnFnRdsFT4bDBhqUk5Jhm662njD53/e+ROJb65wYjrBtSFp4wW/ R2Fw== MIME-Version: 1.0 X-Received: by 10.229.78.213 with SMTP id m21mr5225848qck.55.1372152941233; Tue, 25 Jun 2013 02:35:41 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 02:35:41 -0700 (PDT) Date: Tue, 25 Jun 2013 10:35:41 +0100 X-Google-Sender-Auth: 3FlSxjYHldicL40rWqPh-cHsUPc Message-ID: Subject: Log rotation kills squeezeboxserver CLI From: Ben Laurie To: markk@knigma.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:35:42 -0000 I haven't figured out why, unfortunately, but if you use SBS' CLI interface, it stops responding when the log gets rotated by newsyslog. Removing it from newsyslog.conf fixes the problem (obviously at the cost of no log rotation :-). It also logs a _lot_ of crap, btw. From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 09:36:15 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20B50C2A for ; Tue, 25 Jun 2013 09:36:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id DCE5B1E0D for ; Tue, 25 Jun 2013 09:36:14 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id i11so522620qej.11 for ; Tue, 25 Jun 2013 02:36:14 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=FzvndA1/Xoopv1PPB8c1/RBbw3CcWCzMJWtucrCHyX8=; b=g95VwU1ZgaiSlSRAsn5nse2uio1zp592kiGGseYgooKxaP/gWzV4W8PD8PYohgDzIj yM6kvfEr0xcaBXzVQ6dJJTizjT3dtWE0tv/zEU0qN1Gj25ZOYro6vQcRcAn+8NeYXaBA asSurSp5pxZUHvVHI2bNC/QLnQXcZ6EmPOwSzAU9vOUU4kydt2U9c2ZxQzTceCNagMmv SaDWwhD5MqcVIWj1KNJsBCpR0n2ROG3adp7cfJargzHLOcKS1F9iN6jutXqmnQ5yz2LA ExZf1CEpN4rRvcrziq0e9//60p+TGATsZ7RkVso5RA/hQHo0bQjEC7GG9EWbNorWWKwH yBEA== MIME-Version: 1.0 X-Received: by 10.224.56.9 with SMTP id w9mr4160416qag.109.1372152974417; Tue, 25 Jun 2013 02:36:14 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 02:36:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Jun 2013 10:36:14 +0100 X-Google-Sender-Auth: _BUWtPS5C3Jxh5KCIohMQUdcqUM Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:36:15 -0000 ping? On 22 June 2013 18:46, Ben Laurie wrote: > $ pwd > /usr/ports/textproc/xml2rfc > $ make build-depends-list > /usr/ports/ports-mgmt/pkg > $ make run-depends-list > /usr/ports/lang/tcl86 > /usr/ports/x11-toolkits/tk86 > > But... > > $ pkg query '%n: %do' xml2rfc > xml2rfc: textproc/expat2 > xml2rfc: x11-fonts/fontconfig > xml2rfc: print/freetype2 > xml2rfc: x11/kbproto > xml2rfc: x11/libX11 > xml2rfc: x11/libXau > xml2rfc: x11/libXdmcp > xml2rfc: x11-fonts/libXft > xml2rfc: x11/libXrender > xml2rfc: devel/libpthread-stubs > xml2rfc: x11/libxcb > xml2rfc: devel/pkgconf > xml2rfc: x11/renderproto > xml2rfc: lang/tcl-modules > xml2rfc: lang/tcl85 > xml2rfc: x11-toolkits/tk85 > xml2rfc: x11/xproto > > > a) Why so many more dependencies, and... > > b) Why different versions of tcl/tk? > > And ... how do I fix it? > > BTW, I use portmaster to maintain my installed ports... From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 10:28:08 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76730864 for ; Tue, 25 Jun 2013 10:28:08 +0000 (UTC) (envelope-from Olivier.Nicole@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.freebsd.org (Postfix) with ESMTP id D9646105D for ; Tue, 25 Jun 2013 10:28:06 +0000 (UTC) Received: from mail.cs.ait.ac.th (localhost [127.0.0.1]) by mail.cs.ait.ac.th (Postfix) with ESMTP id 97759FEBCF; Tue, 25 Jun 2013 17:28:05 +0700 (ICT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.ait.ac.th; h= subject:subject:from:from:message-id:date:date:received:received :received; s=selector1; t=1372156085; x=1373970486; bh=qDEkpT/bj yMk5Fu6v3k3BUIAazZE2OaSKQbVeeR+BoM=; b=AM650AGNaHukQxVOCJulh8dMU Ym31YCWPhrw8Oew4f4Q9Lxx6KIBzOZx+VZH0O35Pkagn0AhCB5Xhu8rHYv/EYPd3 DTPrJyVo2Pzt6V/WRSba85gfD3YLUtXNEEf8OCu47BVhcSTyrcGsTjSo08fJzudC Se3U1LHvje5hXMPvuM= X-Virus-Scanned: amavisd-new at cs.ait.ac.th Received: from mail.cs.ait.ac.th ([127.0.0.1]) by mail.cs.ait.ac.th (mail.cs.ait.ac.th [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GPQKHwbqW2df; Tue, 25 Jun 2013 17:28:05 +0700 (ICT) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.ait.ac.th (Postfix) with ESMTPS id 46888FEBBA; Tue, 25 Jun 2013 17:28:05 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.14.6/8.14.6/Submit) id r5PAS4LU027416; Tue, 25 Jun 2013 17:28:04 +0700 (ICT) (envelope-from on) Date: Tue, 25 Jun 2013 17:28:04 +0700 (ICT) Message-Id: <201306251028.r5PAS4LU027416@banyan.cs.ait.ac.th> From: Olivier Nicole To: js@jeannot.org, freebsd-ports@freebsd.org Subject: math/scilab port X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:28:08 -0000 Hi, I suggest the following patch for math/scilab: due to a problem in the port math/suitesparse umfpack is not linked to suitesparseconfig and -lsuitesparseconfig must be explicitely added each time -lumfpack is used. Best regards, Olivier $ pkg_info -E suitesparse\* suitesparse-4.0.2_1 $ pkg_info -E scilab\* scilab-5.3.3_5 $ uname -a FreeBSD banyan2.cs.ait.ac.th 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #8: Tue Jun 18 08:39:59 ICT 2013 root@banyan2.cs.ait.ac.th:/usr/obj/usr/src/sys/CSIM amd64 -------- /usr/ports/math/scilab/files/patch-configure --- configure.orig 2011-07-20 15:15:42.000000000 +0700 +++ configure 2013-06-25 17:16:06.000000000 +0700 @@ -22347,13 +22347,13 @@ fi - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for umf_divcomplex in -lumfpack" >&5 -$as_echo_n "checking for umf_divcomplex in -lumfpack... " >&6; } + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for umf_divcomplex in -lumfpack -lsuitesparseconfig" >&5 +$as_echo_n "checking for umf_divcomplex in -lumfpack -lsuitesparseconfig... " >&6; } if test "${ac_cv_lib_umfpack_umf_divcomplex+set}" = set; then : $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS -LIBS="-lumfpack $LIBS" +LIBS="-lumfpack -lsuitesparseconfig $LIBS" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -22392,7 +22392,7 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_umfpack_umf_divcomplex" >&5 $as_echo "$ac_cv_lib_umfpack_umf_divcomplex" >&6; } if test "x$ac_cv_lib_umfpack_umf_divcomplex" = x""yes; then : - UMFPACK_LIB="-L$with_umfpack_library -lumfpack $UMFPACK_LIB"; UMFPACK_OK=yes + UMFPACK_LIB="-L$with_umfpack_library -lumfpack -lsuitesparseconfig $UMFPACK_LIB"; UMFPACK_OK=yes else as_fn_error $? "libumfpack : Library missing. (Cannot find umf_divcomplex). Check if libumfpack is installed and if the version is correct (also called lib suitesparse)" "$LINENO" 5 @@ -22463,13 +22463,13 @@ fi LIBS="$UMFPACK_LIB $LIBS" - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for umf_divcomplex in -lumfpack" >&5 -$as_echo_n "checking for umf_divcomplex in -lumfpack... " >&6; } + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for umf_divcomplex in -lumfpack -lsuitesparseconfig" >&5 +$as_echo_n "checking for umf_divcomplex in -lumfpack -lsuitesparseconfig... " >&6; } if test "${ac_cv_lib_umfpack_umf_divcomplex+set}" = set; then : $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS -LIBS="-lumfpack $LIBS" +LIBS="-lumfpack -lsuitesparseconfig $LIBS" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -22508,7 +22508,7 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_umfpack_umf_divcomplex" >&5 $as_echo "$ac_cv_lib_umfpack_umf_divcomplex" >&6; } if test "x$ac_cv_lib_umfpack_umf_divcomplex" = x""yes; then : - UMFPACK_LIB="-lumfpack $UMFPACK_LIB"; UMFPACK_OK=yes + UMFPACK_LIB="-lumfpack -lsuitesparseconfig $UMFPACK_LIB"; UMFPACK_OK=yes else as_fn_error $? "libumfpack: Library missing. (Cannot find symbol umf_divcomplex). Check if libumfpack is installed and if the version is correct (also called lib suitesparse)" "$LINENO" 5 -------- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 10:31:57 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AECC6930 for ; Tue, 25 Jun 2013 10:31:57 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 465CE1083 for ; Tue, 25 Jun 2013 10:31:57 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id f11so9016037wgh.3 for ; Tue, 25 Jun 2013 03:31:56 -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=65QdD1pYFuB7XPjFdoxXT+cbvkiswbAAodHnak9DndA=; b=mywvM32vrmQnB4EIEUSBTIPzdz8Yu4BH88bF+QcuEvktzMWX7yZzMDBx3OJgrSHwVe MK/TAwJQ65HmgOgFpGeKJFg6RryBCf4vHSvWkV0UCLHu5Ym7iX2c+/HuyCSm/ck0CgqZ z0isajEF41P8M0TMPPNIE0eqSu+O1/YZ7LaJqkfs0LQFDc3OzYeqetatSURoXXmIuzzT 4aKjRp8FEonB6EI0zY9f8PIqUF2BwBhRqJJ56jPVY2dP7U8z8GIno0cE6m+qaek9X/3n IwsXcfyKSvJjpjCiJ6xYV4vrW7Kn96+MmkaAhsFySudFVlwmbawYRn4v8I0tF7cpwcwB nvBQ== X-Received: by 10.194.47.167 with SMTP id e7mr19111088wjn.57.1372156316519; Tue, 25 Jun 2013 03:31:56 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id x13sm3192493wib.3.2013.06.25.03.31.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 03:31:55 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 12:31:53 +0200 From: Baptiste Daroussin To: Ben Laurie Subject: Re: pkgng seems to be out of date? Message-ID: <20130625103152.GF75533@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p8PhoBjPxaQXD0vg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:31:57 -0000 --p8PhoBjPxaQXD0vg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: > ping? >=20 > On 22 June 2013 18:46, Ben Laurie wrote: > > $ pwd > > /usr/ports/textproc/xml2rfc > > $ make build-depends-list > > /usr/ports/ports-mgmt/pkg > > $ make run-depends-list > > /usr/ports/lang/tcl86 > > /usr/ports/x11-toolkits/tk86 > > > > But... > > > > $ pkg query '%n: %do' xml2rfc > > xml2rfc: textproc/expat2 > > xml2rfc: x11-fonts/fontconfig > > xml2rfc: print/freetype2 > > xml2rfc: x11/kbproto > > xml2rfc: x11/libX11 > > xml2rfc: x11/libXau > > xml2rfc: x11/libXdmcp > > xml2rfc: x11-fonts/libXft > > xml2rfc: x11/libXrender > > xml2rfc: devel/libpthread-stubs > > xml2rfc: x11/libxcb > > xml2rfc: devel/pkgconf > > xml2rfc: x11/renderproto > > xml2rfc: lang/tcl-modules > > xml2rfc: lang/tcl85 > > xml2rfc: x11-toolkits/tk85 > > xml2rfc: x11/xproto > > > > > > a) Why so many more dependencies, and... > > > > b) Why different versions of tcl/tk? > > > > And ... how do I fix it? > > > > BTW, I use portmaster to maintain my installed ports... That is how the ports tree works for eons, and that can't be fixed until we= can totally get rid if pkg_install (to many corner egdes) pkg_install to work properly needs to track fully direct and indirect dependencies, pkg does no= t, but because the ports tree still need to be compatible with pkg_install and lots of people are still using all habits from the pkg_install time, it is = very hard to remove this right now.) But yes for sure this "feature" will get removed :)) regards, Bapt --p8PhoBjPxaQXD0vg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJcZgACgkQ8kTtMUmk6ExU7ACeLsBucZa7DDY1TlIS6B2unJGM bZcAoK0jdRQLSpgwF+isr1YJrmXaQwEx =BnLr -----END PGP SIGNATURE----- --p8PhoBjPxaQXD0vg-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 10:36:09 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AED1BA6; Tue, 25 Jun 2013 10:36:09 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id B4FBD10AD; Tue, 25 Jun 2013 10:36:08 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id l10so7088189qcy.32 for ; Tue, 25 Jun 2013 03:36:07 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/o1imgpIuG+SqMjEC/pbcjy9TFyIVuCjp5QUWWCm2HM=; b=o7juogTuz8Yj5u10JuZfdY7i75RHmfDuT7l9Ro3DSCYDYC4T7BkkgOsMPK9IsBFnPY Ixuj8kR70gO25hVw58vNgvppuCzKH6ewpoqh1GR8SeLPrTfYeE+fo5ojMp1Pa6QCK+KF jn55MOngtlnRUaeFPm4bpwwQX4dtTXtEdfiNNocLQvFw0Od0rhG3/J2ONbackGxW35Op te7lhg9bOTYVy0aQtPOKo33C7kFrg4rC1IFjQwO8d4CTBS3cNebgIZ/ZrBH7Wnz1Rh0i NTLMkMgzNF6g4Sx9zqx2NRe7jOFgQhY60YuWfylY+Snkg9bAXvZuCW58LJsrubHBCjfJ DlEw== MIME-Version: 1.0 X-Received: by 10.49.48.83 with SMTP id j19mr31564475qen.56.1372156567398; Tue, 25 Jun 2013 03:36:07 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 03:36:07 -0700 (PDT) In-Reply-To: <20130625103152.GF75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> Date: Tue, 25 Jun 2013 11:36:07 +0100 X-Google-Sender-Auth: -S_4IBeyVd9GxLwCZIjPUtmeayQ Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:36:09 -0000 On 25 June 2013 11:31, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: >> ping? >> >> On 22 June 2013 18:46, Ben Laurie wrote: >> > $ pwd >> > /usr/ports/textproc/xml2rfc >> > $ make build-depends-list >> > /usr/ports/ports-mgmt/pkg >> > $ make run-depends-list >> > /usr/ports/lang/tcl86 >> > /usr/ports/x11-toolkits/tk86 >> > >> > But... >> > >> > $ pkg query '%n: %do' xml2rfc >> > xml2rfc: textproc/expat2 >> > xml2rfc: x11-fonts/fontconfig >> > xml2rfc: print/freetype2 >> > xml2rfc: x11/kbproto >> > xml2rfc: x11/libX11 >> > xml2rfc: x11/libXau >> > xml2rfc: x11/libXdmcp >> > xml2rfc: x11-fonts/libXft >> > xml2rfc: x11/libXrender >> > xml2rfc: devel/libpthread-stubs >> > xml2rfc: x11/libxcb >> > xml2rfc: devel/pkgconf >> > xml2rfc: x11/renderproto >> > xml2rfc: lang/tcl-modules >> > xml2rfc: lang/tcl85 >> > xml2rfc: x11-toolkits/tk85 >> > xml2rfc: x11/xproto >> > >> > >> > a) Why so many more dependencies, and... >> > >> > b) Why different versions of tcl/tk? >> > >> > And ... how do I fix it? >> > >> > BTW, I use portmaster to maintain my installed ports... > > That is how the ports tree works for eons, and that can't be fixed until we can > totally get rid if pkg_install (to many corner egdes) pkg_install to work > properly needs to track fully direct and indirect dependencies, pkg does not, > but because the ports tree still need to be compatible with pkg_install and > lots of people are still using all habits from the pkg_install time, it is very > hard to remove this right now.) > > But yes for sure this "feature" will get removed :)) So are you saying that pkg includes indirect dependencies, while ports do not? But that doesn't explain why pkg says tcl85 and ports says tcl86.... From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 10:40:33 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 612C5DB6 for ; Tue, 25 Jun 2013 10:40:33 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id E8E2E10F9 for ; Tue, 25 Jun 2013 10:40:32 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b12so9193802wgh.19 for ; Tue, 25 Jun 2013 03:40:32 -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=GoAKlo/ujXjA9d88bjyuuNe8alcAeGQmEfwmknJspdw=; b=e7LjOnQkUhCbW45A33WmgWH3XDwYtbdSL6O3tKNH1yWcxNkmc+PcO5U27SARYA/O1t HnPCwA6YpKg7vl6iYpRB6Wv7e4KKBhHdJK+c49nLj0m+K2yOIdjVWg140NpnFVbpkNvr ykZCh9WNXnaUlws+rdZOY7DR4XtTWmn+ew3XMtXm9qETfYaLTzuWqOy+vup+nRpm6FU/ 1vpgY6n81tSJm/URk5U9opsm6v5ZkKlwVnfZH1YFB+uXIBu1yOAvdLOxzs8VlxulDnu7 WRDVjuAQz0iRjym4d5GXlwCw2mWZMXpfE8d627I84sBNh534bylv17cvMKv9rD2AJgZe dXSw== X-Received: by 10.194.239.225 with SMTP id vv1mr19443279wjc.63.1372156832121; Tue, 25 Jun 2013 03:40:32 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id eu1sm3174134wib.8.2013.06.25.03.40.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 03:40:30 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 12:40:28 +0200 From: Baptiste Daroussin To: Ben Laurie Subject: Re: pkgng seems to be out of date? Message-ID: <20130625104028.GG75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JkW1gnuWHDypiMFO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:40:33 -0000 --JkW1gnuWHDypiMFO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: > On 25 June 2013 11:31, Baptiste Daroussin wrote: > > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: > >> ping? > >> > >> On 22 June 2013 18:46, Ben Laurie wrote: > >> > $ pwd > >> > /usr/ports/textproc/xml2rfc > >> > $ make build-depends-list > >> > /usr/ports/ports-mgmt/pkg > >> > $ make run-depends-list > >> > /usr/ports/lang/tcl86 > >> > /usr/ports/x11-toolkits/tk86 > >> > > >> > But... > >> > > >> > $ pkg query '%n: %do' xml2rfc > >> > xml2rfc: textproc/expat2 > >> > xml2rfc: x11-fonts/fontconfig > >> > xml2rfc: print/freetype2 > >> > xml2rfc: x11/kbproto > >> > xml2rfc: x11/libX11 > >> > xml2rfc: x11/libXau > >> > xml2rfc: x11/libXdmcp > >> > xml2rfc: x11-fonts/libXft > >> > xml2rfc: x11/libXrender > >> > xml2rfc: devel/libpthread-stubs > >> > xml2rfc: x11/libxcb > >> > xml2rfc: devel/pkgconf > >> > xml2rfc: x11/renderproto > >> > xml2rfc: lang/tcl-modules > >> > xml2rfc: lang/tcl85 > >> > xml2rfc: x11-toolkits/tk85 > >> > xml2rfc: x11/xproto > >> > > >> > > >> > a) Why so many more dependencies, and... > >> > > >> > b) Why different versions of tcl/tk? > >> > > >> > And ... how do I fix it? > >> > > >> > BTW, I use portmaster to maintain my installed ports... > > > > That is how the ports tree works for eons, and that can't be fixed unti= l we can > > totally get rid if pkg_install (to many corner egdes) pkg_install to wo= rk > > properly needs to track fully direct and indirect dependencies, pkg doe= s not, > > but because the ports tree still need to be compatible with pkg_install= and > > lots of people are still using all habits from the pkg_install time, it= is very > > hard to remove this right now.) > > > > But yes for sure this "feature" will get removed :)) >=20 > So are you saying that pkg includes indirect dependencies, while ports do= not? >=20 Yes > But that doesn't explain why pkg says tcl85 and ports says tcl86.... That is probably a bug of run-depends not discovering you have tcl85 instal= led so getting to the default tcl for its dependency which is tcl86. I'll try to figure out that bug. regards, Bapt --JkW1gnuWHDypiMFO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJc5wACgkQ8kTtMUmk6Ew3AQCdG20O+UvXUDoTzV9+JPnwkEgT r4wAn3VPEIPE3+M9gbALh3X46hIOoZTH =0lLe -----END PGP SIGNATURE----- --JkW1gnuWHDypiMFO-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 10:56:47 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5E3B61F; Tue, 25 Jun 2013 10:56:47 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 8B61E11D8; Tue, 25 Jun 2013 10:56:47 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id k14so7120085qcv.34 for ; Tue, 25 Jun 2013 03:56:47 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n2T7laUMJUX285zVpZPaBqBRMvJgkmxaGIZZkSEb07E=; b=l0yOuavB3VZGd8uf59wL+2y/oDeGuhuflWhnqpQ8wV3zZLy6K6UooQIyU0ZT3kvH4T sn1dl8QtmCGpCunz8/IiDsH5NQSBokXrtPpXbIr4KktfVpwdovhBcetxuByu4/86Sscu NVHQ1cRvdA1Ft5IHrosjVxdaxMHeKU9zcrGJyYNV0mZxty6kYsB0+hnNyBCn7PQKUWSa P8B5iGgAQ41Xe20X2i8PC6zBcZaA3sRGqbM+aEF3hVA89GGoJ5xilPBHKX4UJbNEkWxF ILmN0moSfN86tXRXgtKxFEY/cWCVL/wL+c9jltzLQfocT+3gj2CW7DsXbiEUXi+hKQ0s ofyg== MIME-Version: 1.0 X-Received: by 10.49.48.83 with SMTP id j19mr31631628qen.56.1372157807048; Tue, 25 Jun 2013 03:56:47 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 03:56:46 -0700 (PDT) In-Reply-To: <20130625104028.GG75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> Date: Tue, 25 Jun 2013 11:56:46 +0100 X-Google-Sender-Auth: wv79aWS0181gcfPUm_NADqf3GDY Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:56:47 -0000 On 25 June 2013 11:40, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: >> On 25 June 2013 11:31, Baptiste Daroussin wrote: >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: >> >> ping? >> >> >> >> On 22 June 2013 18:46, Ben Laurie wrote: >> >> > $ pwd >> >> > /usr/ports/textproc/xml2rfc >> >> > $ make build-depends-list >> >> > /usr/ports/ports-mgmt/pkg >> >> > $ make run-depends-list >> >> > /usr/ports/lang/tcl86 >> >> > /usr/ports/x11-toolkits/tk86 >> >> > >> >> > But... >> >> > >> >> > $ pkg query '%n: %do' xml2rfc >> >> > xml2rfc: textproc/expat2 >> >> > xml2rfc: x11-fonts/fontconfig >> >> > xml2rfc: print/freetype2 >> >> > xml2rfc: x11/kbproto >> >> > xml2rfc: x11/libX11 >> >> > xml2rfc: x11/libXau >> >> > xml2rfc: x11/libXdmcp >> >> > xml2rfc: x11-fonts/libXft >> >> > xml2rfc: x11/libXrender >> >> > xml2rfc: devel/libpthread-stubs >> >> > xml2rfc: x11/libxcb >> >> > xml2rfc: devel/pkgconf >> >> > xml2rfc: x11/renderproto >> >> > xml2rfc: lang/tcl-modules >> >> > xml2rfc: lang/tcl85 >> >> > xml2rfc: x11-toolkits/tk85 >> >> > xml2rfc: x11/xproto >> >> > >> >> > >> >> > a) Why so many more dependencies, and... >> >> > >> >> > b) Why different versions of tcl/tk? >> >> > >> >> > And ... how do I fix it? >> >> > >> >> > BTW, I use portmaster to maintain my installed ports... >> > >> > That is how the ports tree works for eons, and that can't be fixed until we can >> > totally get rid if pkg_install (to many corner egdes) pkg_install to work >> > properly needs to track fully direct and indirect dependencies, pkg does not, >> > but because the ports tree still need to be compatible with pkg_install and >> > lots of people are still using all habits from the pkg_install time, it is very >> > hard to remove this right now.) >> > >> > But yes for sure this "feature" will get removed :)) >> >> So are you saying that pkg includes indirect dependencies, while ports do not? >> > Yes >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... > > That is probably a bug of run-depends not discovering you have tcl85 installed > so getting to the default tcl for its dependency which is tcl86. I actually have both installed, so I think the bug is in pkg. I'd like to remove ports I don't need but pkg won't let me remove tcl85, which I think I don't really need... How can I force pkg to rebuild its dependencies? Is it even possible? Is there any way for pkg to check the integrity of its database? > > I'll try to figure out that bug. > > regards, > Bapt From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 11:32:11 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5E9F15D for ; Tue, 25 Jun 2013 11:32:11 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5A31385 for ; Tue, 25 Jun 2013 11:32:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w59so8909802wes.24 for ; Tue, 25 Jun 2013 04:32: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=6T0FQBf0oyTtyNrgAJVWGunDbvH2eSnWjI+ZnQjKAkM=; b=EGP+ho/SN+AoAOCNj9hQeXJERn/l3ScX1/ALZJvk8HDuR848+KmnjO77FijbUtuKrt c5+XhkAZr6Gw2K6lZFmu8l7s1/ve8NWT1eJD9F6CcEPhZ7afrDQcOIDWDbY5rAQkQZUQ mFfphNz5AhgkY/By5+uaPUWVjZYHDMO0+zZwPOhL4UqoQn81BrTFzsVq8BslFnhgGiLM 7YdukbuM/ZD/hUT2OgxV4b9N34VAxvueOktJmwVLnSBhQ03bd+ymyO+23HK22qQBFl4V YVOtbxQwLSSmPEnERjFXw2C8sFEGEPDF9ZAF/BlIjuir9+/+7aFlcGdLAFTY5G7JGgeM EcwQ== X-Received: by 10.180.75.212 with SMTP id e20mr8866017wiw.30.1372159930353; Tue, 25 Jun 2013 04:32:10 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id f8sm3749190wiv.0.2013.06.25.04.32.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 04:32:09 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 13:32:07 +0200 From: Baptiste Daroussin To: Ben Laurie Subject: Re: pkgng seems to be out of date? Message-ID: <20130625113206.GH75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rCwQ2Y43eQY6RBgR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:32:11 -0000 --rCwQ2Y43eQY6RBgR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 11:56:46AM +0100, Ben Laurie wrote: > On 25 June 2013 11:40, Baptiste Daroussin wrote: > > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: > >> On 25 June 2013 11:31, Baptiste Daroussin wrote: > >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: > >> >> ping? > >> >> > >> >> On 22 June 2013 18:46, Ben Laurie wrote: > >> >> > $ pwd > >> >> > /usr/ports/textproc/xml2rfc > >> >> > $ make build-depends-list > >> >> > /usr/ports/ports-mgmt/pkg > >> >> > $ make run-depends-list > >> >> > /usr/ports/lang/tcl86 > >> >> > /usr/ports/x11-toolkits/tk86 > >> >> > > >> >> > But... > >> >> > > >> >> > $ pkg query '%n: %do' xml2rfc > >> >> > xml2rfc: textproc/expat2 > >> >> > xml2rfc: x11-fonts/fontconfig > >> >> > xml2rfc: print/freetype2 > >> >> > xml2rfc: x11/kbproto > >> >> > xml2rfc: x11/libX11 > >> >> > xml2rfc: x11/libXau > >> >> > xml2rfc: x11/libXdmcp > >> >> > xml2rfc: x11-fonts/libXft > >> >> > xml2rfc: x11/libXrender > >> >> > xml2rfc: devel/libpthread-stubs > >> >> > xml2rfc: x11/libxcb > >> >> > xml2rfc: devel/pkgconf > >> >> > xml2rfc: x11/renderproto > >> >> > xml2rfc: lang/tcl-modules > >> >> > xml2rfc: lang/tcl85 > >> >> > xml2rfc: x11-toolkits/tk85 > >> >> > xml2rfc: x11/xproto > >> >> > > >> >> > > >> >> > a) Why so many more dependencies, and... > >> >> > > >> >> > b) Why different versions of tcl/tk? > >> >> > > >> >> > And ... how do I fix it? > >> >> > > >> >> > BTW, I use portmaster to maintain my installed ports... > >> > > >> > That is how the ports tree works for eons, and that can't be fixed u= ntil we can > >> > totally get rid if pkg_install (to many corner egdes) pkg_install to= work > >> > properly needs to track fully direct and indirect dependencies, pkg = does not, > >> > but because the ports tree still need to be compatible with pkg_inst= all and > >> > lots of people are still using all habits from the pkg_install time,= it is very > >> > hard to remove this right now.) > >> > > >> > But yes for sure this "feature" will get removed :)) > >> > >> So are you saying that pkg includes indirect dependencies, while ports= do not? > >> > > Yes > >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... > > > > That is probably a bug of run-depends not discovering you have tcl85 in= stalled > > so getting to the default tcl for its dependency which is tcl86. >=20 > I actually have both installed, so I think the bug is in pkg. I'd like > to remove ports I don't need but pkg won't let me remove tcl85, which > I think I don't really need... I think is it a bug in portmaster and/or not having fully follow 20130206 o= f UPDATING. pkg only registers dependencies it is being told to register by the ports tree/portmaster. >=20 > How can I force pkg to rebuild its dependencies? Is it even possible? portmaster -af should do it probably (I'm not a portmaster user) >=20 > Is there any way for pkg to check the integrity of its database? >=20 pkg check -d will do, but imho will find nothing. regards, Bapt --rCwQ2Y43eQY6RBgR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJf7YACgkQ8kTtMUmk6EzSDQCeJv6PUe78a5+v61w587blsZV3 icYAnjTY82YBvTLcHA85ulPTUkRNK463 =sB96 -----END PGP SIGNATURE----- --rCwQ2Y43eQY6RBgR-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 11:53:43 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ABFE77E9; Tue, 25 Jun 2013 11:53:43 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8D91650; Tue, 25 Jun 2013 11:53:43 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id b4so555273qen.28 for ; Tue, 25 Jun 2013 04:53:43 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WLFquEIaTe14W1CIawN1ZWtWDbG3WcSb4EB8er/hcLE=; b=t7judjUiBVjoTXkQa1rQH3eJ2x3VTL6zhNstLvvEtp/vVgwG1dpc02LlsIaj7WkltQ 1RMJBQmMJm0ZAnjFEkXevvbG+VbzCkCDe4Ks/spAbVb9edTFk7CGtUpdzcLjXdbvKd95 w06SFXWPl1iMu1yYpj1fE1AV7nK6GPhAl/0d8qgkrj7PQDyNQhJRepwhKXQu6RaSUita 3ktGOYfDiaSDDleDM/d6lpLn+MzJ1gcrql/f6Bb911wI2RH+DvNdjWiXJ/LlTIpmxu3m XYtewWHF0duUopRLeD3njcIir7SVo2so2XGJhtRsxbUMMAc2X9RqCZC8VSwB5DrrEHQg TvLw== MIME-Version: 1.0 X-Received: by 10.49.48.83 with SMTP id j19mr31847971qen.56.1372161222937; Tue, 25 Jun 2013 04:53:42 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 04:53:42 -0700 (PDT) In-Reply-To: <20130625113206.GH75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> Date: Tue, 25 Jun 2013 12:53:42 +0100 X-Google-Sender-Auth: s7pAhSdmg9YPUDunmMf8byyr1vc Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:53:43 -0000 On 25 June 2013 12:32, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 11:56:46AM +0100, Ben Laurie wrote: >> On 25 June 2013 11:40, Baptiste Daroussin wrote: >> > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: >> >> On 25 June 2013 11:31, Baptiste Daroussin wrote: >> >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: >> >> >> ping? >> >> >> >> >> >> On 22 June 2013 18:46, Ben Laurie wrote: >> >> >> > $ pwd >> >> >> > /usr/ports/textproc/xml2rfc >> >> >> > $ make build-depends-list >> >> >> > /usr/ports/ports-mgmt/pkg >> >> >> > $ make run-depends-list >> >> >> > /usr/ports/lang/tcl86 >> >> >> > /usr/ports/x11-toolkits/tk86 >> >> >> > >> >> >> > But... >> >> >> > >> >> >> > $ pkg query '%n: %do' xml2rfc >> >> >> > xml2rfc: textproc/expat2 >> >> >> > xml2rfc: x11-fonts/fontconfig >> >> >> > xml2rfc: print/freetype2 >> >> >> > xml2rfc: x11/kbproto >> >> >> > xml2rfc: x11/libX11 >> >> >> > xml2rfc: x11/libXau >> >> >> > xml2rfc: x11/libXdmcp >> >> >> > xml2rfc: x11-fonts/libXft >> >> >> > xml2rfc: x11/libXrender >> >> >> > xml2rfc: devel/libpthread-stubs >> >> >> > xml2rfc: x11/libxcb >> >> >> > xml2rfc: devel/pkgconf >> >> >> > xml2rfc: x11/renderproto >> >> >> > xml2rfc: lang/tcl-modules >> >> >> > xml2rfc: lang/tcl85 >> >> >> > xml2rfc: x11-toolkits/tk85 >> >> >> > xml2rfc: x11/xproto >> >> >> > >> >> >> > >> >> >> > a) Why so many more dependencies, and... >> >> >> > >> >> >> > b) Why different versions of tcl/tk? >> >> >> > >> >> >> > And ... how do I fix it? >> >> >> > >> >> >> > BTW, I use portmaster to maintain my installed ports... >> >> > >> >> > That is how the ports tree works for eons, and that can't be fixed until we can >> >> > totally get rid if pkg_install (to many corner egdes) pkg_install to work >> >> > properly needs to track fully direct and indirect dependencies, pkg does not, >> >> > but because the ports tree still need to be compatible with pkg_install and >> >> > lots of people are still using all habits from the pkg_install time, it is very >> >> > hard to remove this right now.) >> >> > >> >> > But yes for sure this "feature" will get removed :)) >> >> >> >> So are you saying that pkg includes indirect dependencies, while ports do not? >> >> >> > Yes >> >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... >> > >> > That is probably a bug of run-depends not discovering you have tcl85 installed >> > so getting to the default tcl for its dependency which is tcl86. >> >> I actually have both installed, so I think the bug is in pkg. I'd like >> to remove ports I don't need but pkg won't let me remove tcl85, which >> I think I don't really need... > > I think is it a bug in portmaster and/or not having fully follow 20130206 of UPDATING. > > pkg only registers dependencies it is being told to register by the ports > tree/portmaster. >> >> How can I force pkg to rebuild its dependencies? Is it even possible? > > portmaster -af should do it probably (I'm not a portmaster user) I just did a portmaster -a, that's how I got into this situation... What port management tool _does_ work with pkg? >> Is there any way for pkg to check the integrity of its database? >> > > pkg check -d will do, but imho will find nothing. # pkg check -d x11-toolkits/py-wxPython28-common has a missing dependency: lang/tcl-modules x11-toolkits/py-wxPython28-unicode has a missing dependency: lang/tcl-modules textproc/xml2rfc has a missing dependency: lang/tcl-modules From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 11:57:15 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9264991 for ; Tue, 25 Jun 2013 11:57:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB29168F for ; Tue, 25 Jun 2013 11:57:15 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id t56so8943374wes.7 for ; Tue, 25 Jun 2013 04:57:14 -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=gf6hMfyTp1IW5S1Kg+Dii1T9/EDrh4wbSmORbkYpZNk=; b=pcjiqqc3wPYvx8PfIM1A7w41zOEhz8FOXZd++CcA3HelnlmIRum7QyQmJpIqQOBbrc C6qMB+UIslbvoz1zdWe5xXqwwDicIS4JpKd+mRpxqZ9I03vpUoBodZZRI+7DUBNJsApb ZIVZ+yksl+lh2vNJ2MTuBmdVNkc8nvymqoJBCtnH+K12HcNGTVVhcI7mMdZEOtbkxNhl BbC1QN4Rwa9YbcdF9CXcs+FV3DkTafxFdiWx5Q3i+keLTBgAUHLytf4YRy4BBun0z+vH tvNP7UIEb7yjRgqtmAEV+vKMgKCOyvjV0s59rd8ux7yvTv50r/W6wzvnJbYdc2RKCxyV XBmQ== X-Received: by 10.180.126.10 with SMTP id mu10mr8807131wib.64.1372161434571; Tue, 25 Jun 2013 04:57:14 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fv11sm3593941wic.11.2013.06.25.04.57.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 04:57:13 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 13:57:11 +0200 From: Baptiste Daroussin To: Ben Laurie Subject: Re: pkgng seems to be out of date? Message-ID: <20130625115711.GJ75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRtZRu2mMGBZ6YQ7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:57:15 -0000 --wRtZRu2mMGBZ6YQ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 12:53:42PM +0100, Ben Laurie wrote: > On 25 June 2013 12:32, Baptiste Daroussin wrote: > > On Tue, Jun 25, 2013 at 11:56:46AM +0100, Ben Laurie wrote: > >> On 25 June 2013 11:40, Baptiste Daroussin wrote: > >> > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: > >> >> On 25 June 2013 11:31, Baptiste Daroussin wrote: > >> >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: > >> >> >> ping? > >> >> >> > >> >> >> On 22 June 2013 18:46, Ben Laurie wrote: > >> >> >> > $ pwd > >> >> >> > /usr/ports/textproc/xml2rfc > >> >> >> > $ make build-depends-list > >> >> >> > /usr/ports/ports-mgmt/pkg > >> >> >> > $ make run-depends-list > >> >> >> > /usr/ports/lang/tcl86 > >> >> >> > /usr/ports/x11-toolkits/tk86 > >> >> >> > > >> >> >> > But... > >> >> >> > > >> >> >> > $ pkg query '%n: %do' xml2rfc > >> >> >> > xml2rfc: textproc/expat2 > >> >> >> > xml2rfc: x11-fonts/fontconfig > >> >> >> > xml2rfc: print/freetype2 > >> >> >> > xml2rfc: x11/kbproto > >> >> >> > xml2rfc: x11/libX11 > >> >> >> > xml2rfc: x11/libXau > >> >> >> > xml2rfc: x11/libXdmcp > >> >> >> > xml2rfc: x11-fonts/libXft > >> >> >> > xml2rfc: x11/libXrender > >> >> >> > xml2rfc: devel/libpthread-stubs > >> >> >> > xml2rfc: x11/libxcb > >> >> >> > xml2rfc: devel/pkgconf > >> >> >> > xml2rfc: x11/renderproto > >> >> >> > xml2rfc: lang/tcl-modules > >> >> >> > xml2rfc: lang/tcl85 > >> >> >> > xml2rfc: x11-toolkits/tk85 > >> >> >> > xml2rfc: x11/xproto > >> >> >> > > >> >> >> > > >> >> >> > a) Why so many more dependencies, and... > >> >> >> > > >> >> >> > b) Why different versions of tcl/tk? > >> >> >> > > >> >> >> > And ... how do I fix it? > >> >> >> > > >> >> >> > BTW, I use portmaster to maintain my installed ports... > >> >> > > >> >> > That is how the ports tree works for eons, and that can't be fixe= d until we can > >> >> > totally get rid if pkg_install (to many corner egdes) pkg_install= to work > >> >> > properly needs to track fully direct and indirect dependencies, p= kg does not, > >> >> > but because the ports tree still need to be compatible with pkg_i= nstall and > >> >> > lots of people are still using all habits from the pkg_install ti= me, it is very > >> >> > hard to remove this right now.) > >> >> > > >> >> > But yes for sure this "feature" will get removed :)) > >> >> > >> >> So are you saying that pkg includes indirect dependencies, while po= rts do not? > >> >> > >> > Yes > >> >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... > >> > > >> > That is probably a bug of run-depends not discovering you have tcl85= installed > >> > so getting to the default tcl for its dependency which is tcl86. > >> > >> I actually have both installed, so I think the bug is in pkg. I'd like > >> to remove ports I don't need but pkg won't let me remove tcl85, which > >> I think I don't really need... > > > > I think is it a bug in portmaster and/or not having fully follow 201302= 06 of UPDATING. > > > > pkg only registers dependencies it is being told to register by the por= ts > > tree/portmaster. > >> > >> How can I force pkg to rebuild its dependencies? Is it even possible? > > > > portmaster -af should do it probably (I'm not a portmaster user) >=20 > I just did a portmaster -a, that's how I got into this situation... >=20 > What port management tool _does_ work with pkg? both portmaster and portupgrade, I'm sure what you hit is the UPDATING that= has not been followed, there is a decicated part for tcl. >=20 > >> Is there any way for pkg to check the integrity of its database? > >> > > > > pkg check -d will do, but imho will find nothing. >=20 > # pkg check -d > x11-toolkits/py-wxPython28-common has a missing dependency: lang/tcl-modu= les > x11-toolkits/py-wxPython28-unicode has a missing dependency: lang/tcl-mod= ules > textproc/xml2rfc has a missing dependency: lang/tcl-modules That proves you haven't followed the 20130206 entry. regards, Bapt --wRtZRu2mMGBZ6YQ7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJhZcACgkQ8kTtMUmk6EwbRgCeNv63cuq1SDRiKfDtbg6BaC4u tMAAniFM2oadTeXGGazRUmjs90oq5WrD =jaDO -----END PGP SIGNATURE----- --wRtZRu2mMGBZ6YQ7-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 12:26:28 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F8507C0 for ; Tue, 25 Jun 2013 12:26:28 +0000 (UTC) (envelope-from markk@knigma.org) Received: from shrewd.pub.knigma.org (shrewd.ipv6.pub.knigma.org [IPv6:2001:8b0:b0:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 46D791845 for ; Tue, 25 Jun 2013 12:26:28 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (authenticated bits=0) by shrewd.pub.knigma.org (8.14.5/8.14.5) with ESMTP id r5PCQQfP033276 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 13:26:26 +0100 (BST) (envelope-from markk@knigma.org) Message-ID: <51C98C71.1030609@knigma.org> Date: Tue, 25 Jun 2013 13:26:25 +0100 From: Mark Knight User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ben Laurie Subject: Re: Log rotation kills squeezeboxserver CLI References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:26:28 -0000 Hi Ben, if you change newsyslog.conf to recreate the file with slimserv ownership, does it fix the error (although not the warnings)? /var/log/squeezeboxserver/server.log slimserv:slimserv 644 3 100 * J /var/run/squeezeboxserver/squeezeboxserver.pid -- Mark Knight Mobile: +44 7880 556751. Home: +44 1223 858596 Email: markk@knigma.org. Skype: knigma On 25/06/2013 10:35, Ben Laurie wrote: > I haven't figured out why, unfortunately, but if you use SBS' CLI > interface, it stops responding when the log gets rotated by newsyslog. > > Removing it from newsyslog.conf fixes the problem (obviously at the > cost of no log rotation :-). > > It also logs a _lot_ of crap, btw. > From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 12:34:41 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89FF4BCF for ; Tue, 25 Jun 2013 12:34:41 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 1E51318BF for ; Tue, 25 Jun 2013 12:34:40 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id q58so9326297wes.33 for ; Tue, 25 Jun 2013 05:34:40 -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=YAbQ8Rrmdk5iurGFj47+z6mNjo+dyx1/5OKqpW+N6u0=; b=TSptJ73zBWYaZR5pEEUE+xnHpeyjTr3sCSHGkAHFtcck/zZV8Rt251D8a2OEP77KkW BpllrDBG8ySfAThTT7mYy3Gb36KQJAMq4CoH2C520PTrZDU4iDFlNMvVotrZOTQ3ZrBO r9EnSovVwcPC9H45/dsc/iL0SUsiPaHzgG+EPIjNsdTPjo/wAejkRONVzIb2vMTSTNGj zaOBkCesmNi/Gt47OpbFkvGJQpb/BtGAiVRohPq4GZc5/sFqfTJRxz6xB/7+yePWtU3d fnE7NJ73qPG8qBenMN01MPwOQ0iOpQG3Jc5s0WJI5lur8aqBiMslOPiffbh2O1D+kjcK /qtQ== X-Received: by 10.180.160.144 with SMTP id xk16mr8889445wib.62.1372163680172; Tue, 25 Jun 2013 05:34:40 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fb2sm3868043wic.4.2013.06.25.05.34.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 05:34:39 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 14:34:37 +0200 From: Baptiste Daroussin To: John Marino Subject: Re: make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null 2>&1; then echo YES; fi Message-ID: <20130625123436.GL75533@ithaqua.etoilebsd.net> References: <201306211442.r5LEgwV8052391@mech-cluster241.men.bris.ac.uk> <51C4691E.2030905@marino.st> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sMZCuqyhuhd4ycTi" Content-Disposition: inline In-Reply-To: <51C4691E.2030905@marino.st> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Anton Shterenlikht , mexas@bristol.ac.uk, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:34:41 -0000 --sMZCuqyhuhd4ycTi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 04:54:22PM +0200, John Marino wrote: > On 6/21/2013 16:42, Anton Shterenlikht wrote: > > On ia64 r252055 with ports at r321471 make issues lots of warnings > > like: > > > > # make -C /usr/ports/ fetchindex make: > > "/usr/ports/Mk/bsd.port.subdir.mk" line 101: warning: Couldn't read > > shell's output for "if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null > > 2>&1; then echo YES; fi" make: "/usr/ports/Mk/bsd.port.mk" line 1638: > > warning: Couldn't read shell's output for "if /sbin/sysctl -n > > compat.ia32.maxvmem >/dev/null 2>&1; then echo YES; fi" > > > > *and many more idencal ones* >=20 > That looks like bmake output. > There should be an "else" part of the conditional that returns TRUE or=20 > echo. bmake shell commands don't like null output. >=20 > The bsd.port.subdir.mk needs to be tweaked for bmake. >=20 > John Fixed as of r321735 and r321739 regards, Bapt --sMZCuqyhuhd4ycTi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJjlwACgkQ8kTtMUmk6EyD9wCfZBnXL8WsDNL4tb15GljZvIIn p0cAn2V6zoEXrL5i88PqdsDdp1rWV7J0 =6n8V -----END PGP SIGNATURE----- --sMZCuqyhuhd4ycTi-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 12:35:09 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EE035C69; Tue, 25 Jun 2013 12:35:09 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A074C18CA; Tue, 25 Jun 2013 12:35:09 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n1so7144894qcw.16 for ; Tue, 25 Jun 2013 05:35:09 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vt0b31KboR6Z68voyGLJ2Yz8wgzHoC9DNaLKVCc0OcQ=; b=KPMDlbpEGPRP6k6BS2py1CM7RKRn3HB9IH1ZmdxRvKbJkODiCwVwpvBZeaZuaIiB97 FiHLy1BiDkg41kt6rXzb9DPTBMuCCaoPapj7JlMQl9ghfbc+ZIqqlc28JGuaPisU/089 la7PhG8RKptn6T/0XIcU/+aDycv6bTiDtxWSwGmjg894P+uVnlITqFhi10YFufg6EqrM Whhe4v7umIVHYCKkxNX4V7KkEyb0nC4JZD3+BjGsNscK/KLaT+3Cm0iV1RtghXrmwfnl zNHMY6Ltooc/NhZWP/gCvCIUV26bYYKGLQfIaY0EfbpZA42FOxAu9VdQGFiAtmSQm3Mm 5DSQ== MIME-Version: 1.0 X-Received: by 10.224.127.73 with SMTP id f9mr31751173qas.4.1372163709220; Tue, 25 Jun 2013 05:35:09 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 05:35:09 -0700 (PDT) In-Reply-To: <20130625115711.GJ75533@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> <20130625115711.GJ75533@ithaqua.etoilebsd.net> Date: Tue, 25 Jun 2013 13:35:09 +0100 X-Google-Sender-Auth: XKhigMiVcibFROVYhB-1NUwKkLo Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:35:10 -0000 On 25 June 2013 12:57, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 12:53:42PM +0100, Ben Laurie wrote: >> On 25 June 2013 12:32, Baptiste Daroussin wrote: >> > On Tue, Jun 25, 2013 at 11:56:46AM +0100, Ben Laurie wrote: >> >> On 25 June 2013 11:40, Baptiste Daroussin wrote: >> >> > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: >> >> >> On 25 June 2013 11:31, Baptiste Daroussin wrote: >> >> >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: >> >> >> >> ping? >> >> >> >> >> >> >> >> On 22 June 2013 18:46, Ben Laurie wrote: >> >> >> >> > $ pwd >> >> >> >> > /usr/ports/textproc/xml2rfc >> >> >> >> > $ make build-depends-list >> >> >> >> > /usr/ports/ports-mgmt/pkg >> >> >> >> > $ make run-depends-list >> >> >> >> > /usr/ports/lang/tcl86 >> >> >> >> > /usr/ports/x11-toolkits/tk86 >> >> >> >> > >> >> >> >> > But... >> >> >> >> > >> >> >> >> > $ pkg query '%n: %do' xml2rfc >> >> >> >> > xml2rfc: textproc/expat2 >> >> >> >> > xml2rfc: x11-fonts/fontconfig >> >> >> >> > xml2rfc: print/freetype2 >> >> >> >> > xml2rfc: x11/kbproto >> >> >> >> > xml2rfc: x11/libX11 >> >> >> >> > xml2rfc: x11/libXau >> >> >> >> > xml2rfc: x11/libXdmcp >> >> >> >> > xml2rfc: x11-fonts/libXft >> >> >> >> > xml2rfc: x11/libXrender >> >> >> >> > xml2rfc: devel/libpthread-stubs >> >> >> >> > xml2rfc: x11/libxcb >> >> >> >> > xml2rfc: devel/pkgconf >> >> >> >> > xml2rfc: x11/renderproto >> >> >> >> > xml2rfc: lang/tcl-modules >> >> >> >> > xml2rfc: lang/tcl85 >> >> >> >> > xml2rfc: x11-toolkits/tk85 >> >> >> >> > xml2rfc: x11/xproto >> >> >> >> > >> >> >> >> > >> >> >> >> > a) Why so many more dependencies, and... >> >> >> >> > >> >> >> >> > b) Why different versions of tcl/tk? >> >> >> >> > >> >> >> >> > And ... how do I fix it? >> >> >> >> > >> >> >> >> > BTW, I use portmaster to maintain my installed ports... >> >> >> > >> >> >> > That is how the ports tree works for eons, and that can't be fixed until we can >> >> >> > totally get rid if pkg_install (to many corner egdes) pkg_install to work >> >> >> > properly needs to track fully direct and indirect dependencies, pkg does not, >> >> >> > but because the ports tree still need to be compatible with pkg_install and >> >> >> > lots of people are still using all habits from the pkg_install time, it is very >> >> >> > hard to remove this right now.) >> >> >> > >> >> >> > But yes for sure this "feature" will get removed :)) >> >> >> >> >> >> So are you saying that pkg includes indirect dependencies, while ports do not? >> >> >> >> >> > Yes >> >> >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... >> >> > >> >> > That is probably a bug of run-depends not discovering you have tcl85 installed >> >> > so getting to the default tcl for its dependency which is tcl86. >> >> >> >> I actually have both installed, so I think the bug is in pkg. I'd like >> >> to remove ports I don't need but pkg won't let me remove tcl85, which >> >> I think I don't really need... >> > >> > I think is it a bug in portmaster and/or not having fully follow 20130206 of UPDATING. >> > >> > pkg only registers dependencies it is being told to register by the ports >> > tree/portmaster. >> >> >> >> How can I force pkg to rebuild its dependencies? Is it even possible? >> > >> > portmaster -af should do it probably (I'm not a portmaster user) >> >> I just did a portmaster -a, that's how I got into this situation... >> >> What port management tool _does_ work with pkg? > > both portmaster and portupgrade, I'm sure what you hit is the UPDATING that has > not been followed, there is a decicated part for tcl. >> >> >> Is there any way for pkg to check the integrity of its database? >> >> >> > >> > pkg check -d will do, but imho will find nothing. >> >> # pkg check -d >> x11-toolkits/py-wxPython28-common has a missing dependency: lang/tcl-modules >> x11-toolkits/py-wxPython28-unicode has a missing dependency: lang/tcl-modules >> textproc/xml2rfc has a missing dependency: lang/tcl-modules > > That proves you haven't followed the 20130206 entry. Oh, sorry, I missed that reference the first time round. Hmm, just discovered "pkg updating". It'd be nice if there were a way to skip all the things that say "rebuild everything that depends on it", which seems kinda obvious... From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 12:50:54 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F78B308; Tue, 25 Jun 2013 12:50:54 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id EE533196A; Tue, 25 Jun 2013 12:50:53 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id z10so7071139qcx.21 for ; Tue, 25 Jun 2013 05:50:53 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KA7XavxN98eJz4nK3T8MrhctPeu4r4Xm6945X09XRoY=; b=sIYw2F4f2kkg/b/hHWSmU+HuIjAkU3NIc46FMsoT8xtU1uF6L32aJvoxjr+b9KRZDC 4bQiyCqOyGhD+5eJXf+/sCmHIXdZDFVMdpKpfuhrJ+SP3qRwib/xpps1pcKhiI3z27GU Hcsv1xrbRpTKcJQrV/OKs0KxD85EKkBmW0EJbCmUDURhtxy9q9VausVNgetPDmWc1q07 dpGKfKMG85pv32gFireVGEPngFekeK1S69SNk+6Ga63p87CK84Iz5QOx99/qbSiOqUnk G7ezTZG3qmZPttu/mPEf70V7Yt3WJtYgHPIrA2EdiOP40Q+yGBNC2GFHIyv0Xy5k+Ult NT3A== MIME-Version: 1.0 X-Received: by 10.224.29.69 with SMTP id p5mr8414897qac.5.1372164653449; Tue, 25 Jun 2013 05:50:53 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 25 Jun 2013 05:50:53 -0700 (PDT) In-Reply-To: References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> <20130625115711.GJ75533@ithaqua.etoilebsd.net> Date: Tue, 25 Jun 2013 13:50:53 +0100 X-Google-Sender-Auth: SER7PmH3Nn4oSJ3UUtuwDOXxmWk Message-ID: Subject: Re: pkgng seems to be out of date? From: Ben Laurie To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:50:54 -0000 On 25 June 2013 13:35, Ben Laurie wrote: > On 25 June 2013 12:57, Baptiste Daroussin wrote: >> On Tue, Jun 25, 2013 at 12:53:42PM +0100, Ben Laurie wrote: >>> On 25 June 2013 12:32, Baptiste Daroussin wrote: >>> > On Tue, Jun 25, 2013 at 11:56:46AM +0100, Ben Laurie wrote: >>> >> On 25 June 2013 11:40, Baptiste Daroussin wrote: >>> >> > On Tue, Jun 25, 2013 at 11:36:07AM +0100, Ben Laurie wrote: >>> >> >> On 25 June 2013 11:31, Baptiste Daroussin wrote: >>> >> >> > On Tue, Jun 25, 2013 at 10:36:14AM +0100, Ben Laurie wrote: >>> >> >> >> ping? >>> >> >> >> >>> >> >> >> On 22 June 2013 18:46, Ben Laurie wrote: >>> >> >> >> > $ pwd >>> >> >> >> > /usr/ports/textproc/xml2rfc >>> >> >> >> > $ make build-depends-list >>> >> >> >> > /usr/ports/ports-mgmt/pkg >>> >> >> >> > $ make run-depends-list >>> >> >> >> > /usr/ports/lang/tcl86 >>> >> >> >> > /usr/ports/x11-toolkits/tk86 >>> >> >> >> > >>> >> >> >> > But... >>> >> >> >> > >>> >> >> >> > $ pkg query '%n: %do' xml2rfc >>> >> >> >> > xml2rfc: textproc/expat2 >>> >> >> >> > xml2rfc: x11-fonts/fontconfig >>> >> >> >> > xml2rfc: print/freetype2 >>> >> >> >> > xml2rfc: x11/kbproto >>> >> >> >> > xml2rfc: x11/libX11 >>> >> >> >> > xml2rfc: x11/libXau >>> >> >> >> > xml2rfc: x11/libXdmcp >>> >> >> >> > xml2rfc: x11-fonts/libXft >>> >> >> >> > xml2rfc: x11/libXrender >>> >> >> >> > xml2rfc: devel/libpthread-stubs >>> >> >> >> > xml2rfc: x11/libxcb >>> >> >> >> > xml2rfc: devel/pkgconf >>> >> >> >> > xml2rfc: x11/renderproto >>> >> >> >> > xml2rfc: lang/tcl-modules >>> >> >> >> > xml2rfc: lang/tcl85 >>> >> >> >> > xml2rfc: x11-toolkits/tk85 >>> >> >> >> > xml2rfc: x11/xproto >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > a) Why so many more dependencies, and... >>> >> >> >> > >>> >> >> >> > b) Why different versions of tcl/tk? >>> >> >> >> > >>> >> >> >> > And ... how do I fix it? >>> >> >> >> > >>> >> >> >> > BTW, I use portmaster to maintain my installed ports... >>> >> >> > >>> >> >> > That is how the ports tree works for eons, and that can't be fixed until we can >>> >> >> > totally get rid if pkg_install (to many corner egdes) pkg_install to work >>> >> >> > properly needs to track fully direct and indirect dependencies, pkg does not, >>> >> >> > but because the ports tree still need to be compatible with pkg_install and >>> >> >> > lots of people are still using all habits from the pkg_install time, it is very >>> >> >> > hard to remove this right now.) >>> >> >> > >>> >> >> > But yes for sure this "feature" will get removed :)) >>> >> >> >>> >> >> So are you saying that pkg includes indirect dependencies, while ports do not? >>> >> >> >>> >> > Yes >>> >> >> But that doesn't explain why pkg says tcl85 and ports says tcl86.... >>> >> > >>> >> > That is probably a bug of run-depends not discovering you have tcl85 installed >>> >> > so getting to the default tcl for its dependency which is tcl86. >>> >> >>> >> I actually have both installed, so I think the bug is in pkg. I'd like >>> >> to remove ports I don't need but pkg won't let me remove tcl85, which >>> >> I think I don't really need... >>> > >>> > I think is it a bug in portmaster and/or not having fully follow 20130206 of UPDATING. >>> > >>> > pkg only registers dependencies it is being told to register by the ports >>> > tree/portmaster. >>> >> >>> >> How can I force pkg to rebuild its dependencies? Is it even possible? >>> > >>> > portmaster -af should do it probably (I'm not a portmaster user) >>> >>> I just did a portmaster -a, that's how I got into this situation... >>> >>> What port management tool _does_ work with pkg? >> >> both portmaster and portupgrade, I'm sure what you hit is the UPDATING that has >> not been followed, there is a decicated part for tcl. >>> >>> >> Is there any way for pkg to check the integrity of its database? >>> >> >>> > >>> > pkg check -d will do, but imho will find nothing. >>> >>> # pkg check -d >>> x11-toolkits/py-wxPython28-common has a missing dependency: lang/tcl-modules >>> x11-toolkits/py-wxPython28-unicode has a missing dependency: lang/tcl-modules >>> textproc/xml2rfc has a missing dependency: lang/tcl-modules >> >> That proves you haven't followed the 20130206 entry. > > Oh, sorry, I missed that reference the first time round. > > Hmm, just discovered "pkg updating". It'd be nice if there were a way > to skip all the things that say "rebuild everything that depends on > it", which seems kinda obvious... Hmmm. pkg updating doesn't actually show the relevant 20130206 entry - so not actually useful. From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 13:23:03 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4AA18AA4 for ; Tue, 25 Jun 2013 13:23:03 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDC91ACF for ; Tue, 25 Jun 2013 13:23:01 +0000 (UTC) Received: from mail-we0-f172.google.com ([74.125.82.172]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKUcmZm2Xab+BEmbMN8hHnGct3mXtRyXpB@postini.com; Tue, 25 Jun 2013 13:23:02 UTC Received: by mail-we0-f172.google.com with SMTP id q56so9396482wes.3 for ; Tue, 25 Jun 2013 06:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:message-id:to:subject:reply-to:x-gm-message-state; bh=57+vWDM9BG1AC3ZqXKLSJPZMv+VjBish21FvvKPyFU0=; b=acUJ+4wgS8TcSq8VKWKkdTLkljOvL1Bg8TDWKVa95gsCPvKxzeZpGBigZtdxlii62y AiHd5QgloB2sDRQykuN5gRNen/uPy36HoylQGkue6qLBJR+KWAkh/OQrl5TbTexwPMZE B/nE8XgLyL0KgNdhvb/RFqB5qjiiKYLo0tpxELNw3WCruUfRri9tqRI2JK88wdXGb6Uq ePTiqm2KoLKJsJlMzzzvkYL1cEUVvn4uV2UPS5JjhPOUYq9bsu7/6kgTiaZn7nK106kh nS8JfeqIYNco+jgti17jsmcCDKrAaKsFb+jdbIjw7bf1a8blP/+6uslKmp/0oqZmjFCR RqHg== X-Received: by 10.194.93.74 with SMTP id cs10mr20739824wjb.9.1372166555550; Tue, 25 Jun 2013 06:22:35 -0700 (PDT) X-Received: by 10.194.93.74 with SMTP id cs10mr20739821wjb.9.1372166555497; Tue, 25 Jun 2013 06:22:35 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id o14sm4151792wiv.3.2013.06.25.06.22.33 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 06:22:34 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r5PDMWFD090859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Jun 2013 14:22:32 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r5PDMVZb090858 for freebsd-ports@freebsd.org; Tue, 25 Jun 2013 14:22:31 +0100 (BST) (envelope-from mexas) Date: Tue, 25 Jun 2013 14:22:31 +0100 (BST) From: Anton Shterenlikht Message-Id: <201306251322.r5PDMVZb090858@mech-cluster241.men.bris.ac.uk> To: freebsd-ports@freebsd.org Subject: pkg: sqlite: no such column: infos (pkgdb.c:1086) X-Gm-Message-State: ALoCoQkhzEReaUeAFyCevyTbTOyXuMBOyRaObWsjleX6daRBDesO8+MI5CrNS+XfUuZEj3sooQNwKR0JaJDUiIhB1Am1OkZ8f3JuZLaR/DU2P4+o9VCy2EfQsB0WrMIUXQ6RCKY9YO0ikmWdGAHsPNhiDzMbJxnOckTFrwEJ7X+7Th91vwG4THs= X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:23:03 -0000 I'm debugging X11 on sparc64. I need to roll the ports tree back to 319054. On downgrading pkg I get: ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for pkg-1.0.12_1 pkg: warning: database version 19 is newer than libpkg(3) version 12, but still compatible pkg: sqlite: no such column: infos (pkgdb.c:1086) pkg-static: warning: database version 19 is newer than libpkg(3) version 12, but still compatible Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no column named infos (pkgdb.c:1757) pkg-static: sqlite: cannot rollback - no transaction is active (pkgdb.c:2266) *** Error code 70 Stop. make: stopped in /usr/ports/ports-mgmt/pkg *** Error code 1 Shall I open a PR? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 13:30:38 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9AFBBD87 for ; Tue, 25 Jun 2013 13:30:38 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 31FBE1B28 for ; Tue, 25 Jun 2013 13:30:38 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id j13so9563055wgh.24 for ; Tue, 25 Jun 2013 06:30:37 -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=k+G94EK0iZcFgEHfewmRBLAZ3HFUA3VQ+ffgUEjLDx0=; b=YoHZB+pRe+XgE8LyDUg3g65xfm2iAcJvaZ4hn1SW+pcUn1Qbz1c3PPW8t8J4nindYz jKPQIOQVDHzZOQevt5Nt/Y8XMgUSTg6gp64SuWMk8s3rDoexmS6a/7xFtezKSNof2Uq4 yNejoRJZtvXZK5nVQeoh0LCpmxxf14D/TcWHtJNOXnYZuchfWJv+qzNCk9yF9BqZWxcX 6MuxDEnH3Pb6ze3jqu7g53oznvLKvhOX9TBOD6AklH+scSZOG409R5tLVQcdJfUbMHrv fNocegFiPWK6027bIkdgQHsA2cYulJ8tiCZVKFNNuGfp+DdvrQGLBQmhBJMfw0DVBgXS 89PA== X-Received: by 10.180.100.35 with SMTP id ev3mr9186784wib.12.1372167037320; Tue, 25 Jun 2013 06:30:37 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id w4sm4138920wia.9.2013.06.25.06.30.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 06:30:36 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 15:30:34 +0200 From: Baptiste Daroussin To: mexas@bristol.ac.uk Subject: Re: pkg: sqlite: no such column: infos (pkgdb.c:1086) Message-ID: <20130625133034.GN75533@ithaqua.etoilebsd.net> References: <201306251322.r5PDMVZb090858@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TXIPBuAs4GDcsx9K" Content-Disposition: inline In-Reply-To: <201306251322.r5PDMVZb090858@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:30:38 -0000 --TXIPBuAs4GDcsx9K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 02:22:31PM +0100, Anton Shterenlikht wrote: > I'm debugging X11 on sparc64. > I need to roll the ports tree back to 319054. > On downgrading pkg I get: >=20 > =3D=3D=3D> Running ldconfig > /sbin/ldconfig -m /usr/local/lib > =3D=3D=3D> Registering installation for pkg-1.0.12_1 > pkg: warning: database version 19 is newer than libpkg(3) version 12, but= still > compatible > pkg: sqlite: no such column: infos (pkgdb.c:1086) > pkg-static: warning: database version 19 is newer than libpkg(3) version = 12, but > still compatible > Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no colum= n named > infos (pkgdb.c:1757) > pkg-static: sqlite: cannot rollback - no transaction is active (pkgdb.c:2= 266) > *** Error code 70 >=20 > Stop. > make: stopped in /usr/ports/ports-mgmt/pkg > *** Error code 1 >=20 > Shall I open a PR? >=20 > Thanks >=20 > Anton >=20 > _______________________________________________ > 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" Why downgrading? Please upgrade again to 1.1.2 :) and report bug if any. regards, Bapt --TXIPBuAs4GDcsx9K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJm3oACgkQ8kTtMUmk6EwUNACfdj06qz1qKZOZkC5iHU5lHcIt TJ8AniZGCNqoJShX8WisZZwhxAxTCRYI =1eXJ -----END PGP SIGNATURE----- --TXIPBuAs4GDcsx9K-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 13:58:16 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 492889DF for ; Tue, 25 Jun 2013 13:58:16 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8BC1C9E for ; Tue, 25 Jun 2013 13:58:01 +0000 (UTC) Received: from mail-wg0-f54.google.com ([74.125.82.54]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKUcmhyTON3bACL9vfHe2xhRmcuIScaARM@postini.com; Tue, 25 Jun 2013 13:58:02 UTC Received: by mail-wg0-f54.google.com with SMTP id n11so9297818wgh.33 for ; Tue, 25 Jun 2013 06:57:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:message-id:to:subject:cc:reply-to:in-reply-to :x-gm-message-state; bh=imO2DwsLb6Pmr3sTiNIYTdusRYlvtLN2BoAZR2XxTDA=; b=FBwzqaorapWRl5OaobC9ojqYDX1gMAhYjU5j/XMTNJCkVbfxD/9uo3yMA34AHMU87W gnJVCdtaR9RceeadP04hQQA47NgA1GpazUsAHwD+t6orUnkZfPgektKconFIhdNu3KTz hfiEpluAkntGrqPPQ3lLJjTud2gP7AlqCCDOKO4+g7toEUQEemKWHQtttwDx47SkXUiY XQg2oK0bTwUe9e7mKKvmmsR7SOfDETkmfQDH19RxGh3edDC/buikGSr9Y61kJcFDzapt bfsi9F3lX5pohDo0K7g2nYyghLT0mrNqnOkRna+isaxWlEkGOMMVuRi9oAXPO4CFCgiG MQNQ== X-Received: by 10.194.58.239 with SMTP id u15mr20061455wjq.87.1372168640172; Tue, 25 Jun 2013 06:57:20 -0700 (PDT) X-Received: by 10.194.58.239 with SMTP id u15mr20061447wjq.87.1372168640113; Tue, 25 Jun 2013 06:57:20 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id ev19sm4361006wid.2.2013.06.25.06.57.18 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 06:57:19 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r5PDvGbR012711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2013 14:57:17 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r5PDvGgm012710; Tue, 25 Jun 2013 14:57:16 +0100 (BST) (envelope-from mexas) Date: Tue, 25 Jun 2013 14:57:16 +0100 (BST) From: Anton Shterenlikht Message-Id: <201306251357.r5PDvGgm012710@mech-cluster241.men.bris.ac.uk> To: bapt@FreeBSD.org, mexas@bristol.ac.uk Subject: Re: pkg: sqlite: no such column: infos (pkgdb.c:1086) In-Reply-To: <20130625133034.GN75533@ithaqua.etoilebsd.net> X-Gm-Message-State: ALoCoQmiLNbQQ0vS30uOi7p3Ys3h1Dpyoqk+Sbkgxs/oB3wXcbpJCefzbdTlbSOzzeIZGwhAuMPI1RqrRb6IjFtA7M4kbO6xWnyLrxvWbDX+BR5X0lQAcTNxlLIQQTe0r4bpAiDIqTsWmQ8SGhEzPYf6d18tuPKQcOnOMpKrkwoNu4L3wZ89MCQ= Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:58:16 -0000 From baptiste.daroussin@gmail.com Tue Jun 25 14:52:59 2013 On Tue, Jun 25, 2013 at 02:22:31PM +0100, Anton Shterenlikht wrote: > I'm debugging X11 on sparc64. > I need to roll the ports tree back to 319054. > On downgrading pkg I get: > > > Running ldconfig > /sbin/ldconfig -m /usr/local/lib > > Registering installation for pkg-1.0.12_1 > pkg: warning: database version 19 is newer than libpkg(3) version 12, but= still > compatible > pkg: sqlite: no such column: infos (pkgdb.c:1086) > pkg-static: warning: database version 19 is newer than libpkg(3) version = 12, but > still compatible > Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no colum= n named > infos (pkgdb.c:1757) > pkg-static: sqlite: cannot rollback - no transaction is active (pkgdb.c:2= 266) > *** Error code 70 > > Stop. > make: stopped in /usr/ports/ports-mgmt/pkg > *** Error code 1 > > Shall I open a PR? > > Thanks > > Anton Why downgrading? Please upgrade again to 1.1.2 :) and report bug if any. Sorry, I don't get you. I need the ports tree to be at 319054. I then do pkg info -xd xorg-server > /root/xorg-dep portmaster -f `cat /root/xorg-dep` Is this not supported? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 14:01:51 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB104CB3 for ; Tue, 25 Jun 2013 14:01:50 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 814911CE5 for ; Tue, 25 Jun 2013 14:01:50 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id y10so9598019wgg.32 for ; Tue, 25 Jun 2013 07:01:49 -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=94vhN13YeJ0f2DyWM46UrufviWtEHB3PG/Iat6z/hWY=; b=w8SDMs+/sGoKfv9VaiwT4/LIluszyOBjQhLA0RN2COhTIJJIXWfcWaEG7DlQIMB7h5 /uV9g+dkwdOZmKThthr1NDUdgJb+aqxUEMZjYklfCYvklDamT2NjwZR3advAeFrR2j+2 dZa51UZTsDJVmMNYKMr6ELDqTXNuq74CAl+kjs5xpoaskufKpbXQS6aLzitjl0UbN0fe xbNvoRJIjB0n/Yb8u9pgDyg5c99XNv/NRX5+HgMwAgtC5c74psiMv/vCIlav9pCXfzKl +K3sPASNQgqKCCj1iypr0CkxWkU25/WRxfoWzz0uyWXfCvrdPCrdMiWKhZ6qX2uzMO+G wUyA== X-Received: by 10.180.206.70 with SMTP id lm6mr9359933wic.50.1372168909741; Tue, 25 Jun 2013 07:01:49 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id fs8sm4409974wib.0.2013.06.25.07.01.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 07:01:48 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 16:01:46 +0200 From: Baptiste Daroussin To: mexas@bristol.ac.uk Subject: Re: pkg: sqlite: no such column: infos (pkgdb.c:1086) Message-ID: <20130625140146.GA93612@ithaqua.etoilebsd.net> References: <20130625133034.GN75533@ithaqua.etoilebsd.net> <201306251357.r5PDvGgm012710@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <201306251357.r5PDvGgm012710@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:01:51 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 02:57:16PM +0100, Anton Shterenlikht wrote: > From baptiste.daroussin@gmail.com Tue Jun 25 14:52:59 2013 >=20 > On Tue, Jun 25, 2013 at 02:22:31PM +0100, Anton Shterenlikht wrote: > > I'm debugging X11 on sparc64. > > I need to roll the ports tree back to 319054. > > On downgrading pkg I get: > > > > > Running ldconfig > > /sbin/ldconfig -m /usr/local/lib > > > Registering installation for pkg-1.0.12_1 > > pkg: warning: database version 19 is newer than libpkg(3) version 12, = but=3D > still > > compatible > > pkg: sqlite: no such column: infos (pkgdb.c:1086) > > pkg-static: warning: database version 19 is newer than libpkg(3) versi= on =3D > 12, but > > still compatible > > Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no co= lum=3D > n named > > infos (pkgdb.c:1757) > > pkg-static: sqlite: cannot rollback - no transaction is active (pkgdb.= c:2=3D > 266) > > *** Error code 70 > > > > Stop. > > make: stopped in /usr/ports/ports-mgmt/pkg > > *** Error code 1 > > > > Shall I open a PR? > > > > Thanks > > > > Anton >=20 > Why downgrading? Please upgrade again to 1.1.2 :) and report bug if any. >=20 > Sorry, I don't get you. >=20 > I need the ports tree to be at 319054. > I then do >=20 > pkg info -xd xorg-server > /root/xorg-dep > portmaster -f `cat /root/xorg-dep` >=20 > Is this not supported? You mean you went forward and switch back to a former version? Switching from 1.1 back to 1.0 has been taken in account during the pkg-dev= el phase, but not considered for after 1.1 is offically released which explain= s why you have this message. We could had the compatibility he really needed. Normal path is not to go backward :) regards, Bapt --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJosoACgkQ8kTtMUmk6EyjUwCfW9JGqRpifkybnX0i6k+gjGoc aloAoLWy1rKcYJIy+dE06QZ+SsVeVMUW =keuD -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 14:27:54 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F836348 for ; Tue, 25 Jun 2013 14:27:54 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 170131E34 for ; Tue, 25 Jun 2013 14:27:53 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so817029wiv.15 for ; Tue, 25 Jun 2013 07:27:53 -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=AMTnmIA3s58bS15Ai7HB1ICyVlkp3IjG2nRecrnTRjk=; b=JNJDpSJooYAkIi5co8BYi4hEgiJ2PPcrRzAb6PV4aTPtZKN6vry2+lKWBdWC1+Goif gXFE4Rcrz4E5RD3OWwtxiIvW9UwYOPou1o0bpUXq6JTPOLT0aT5NPojyCNhvt+3Mxipg hT2KVz0Zeg9emElrE91n9+vf+XoYG5MMsu+uxExoynBHHzt6YAkIdmWL/Pfav1Crq1e9 L5XMGqmwEYm6uivie/OivqZhjeCaMthLmv6PFm1va/aTE7Zvw7RNlmQemFchiXVXc5EX VEmNRgYUNQE9GjA1cwmx0HdtLdDT6Zkq77xuVHY5AofooJ58bXSQw3VJVMu5m/K+dIIX tw5g== X-Received: by 10.194.249.69 with SMTP id ys5mr21243075wjc.39.1372170467917; Tue, 25 Jun 2013 07:27:47 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id i1sm4479428wiz.6.2013.06.25.07.27.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 07:27:46 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 16:27:42 +0200 From: Baptiste Daroussin To: mexas@bristol.ac.uk Subject: Re: pkg: sqlite: no such column: infos (pkgdb.c:1086) Message-ID: <20130625142742.GB93612@ithaqua.etoilebsd.net> References: <20130625140146.GA93612@ithaqua.etoilebsd.net> <201306251423.r5PENsE2016716@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <201306251423.r5PENsE2016716@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:27:54 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 03:23:54PM +0100, Anton Shterenlikht wrote: > From baptiste.daroussin@gmail.com Tue Jun 25 15:20:11 2013 >=20 > On Tue, Jun 25, 2013 at 02:57:16PM +0100, Anton Shterenlikht wrote: > > From baptiste.daroussin@gmail.com Tue Jun 25 14:52:59 2013 > >=3D20 > > On Tue, Jun 25, 2013 at 02:22:31PM +0100, Anton Shterenlikht wrote: > > > I'm debugging X11 on sparc64. > > > I need to roll the ports tree back to 319054. > > > On downgrading pkg I get: > > > > > > > Running ldconfig > > > /sbin/ldconfig -m /usr/local/lib > > > > Registering installation for pkg-1.0.12_1 > > > pkg: warning: database version 19 is newer than libpkg(3) version 1= 2, =3D > but=3D3D > > still > > > compatible > > > pkg: sqlite: no such column: infos (pkgdb.c:1086) > > > pkg-static: warning: database version 19 is newer than libpkg(3) ve= rsi=3D > on =3D3D > > 12, but > > > still compatible > > > Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no= co=3D > lum=3D3D > > n named > > > infos (pkgdb.c:1757) > > > pkg-static: sqlite: cannot rollback - no transaction is active (pkg= db.=3D > c:2=3D3D > > 266) > > > *** Error code 70 > > > > > > Stop. > > > make: stopped in /usr/ports/ports-mgmt/pkg > > > *** Error code 1 > > > > > > Shall I open a PR? > > > > > > Thanks > > > > > > Anton > >=3D20 > > Why downgrading? Please upgrade again to 1.1.2 :) and report bug if a= ny. > >=3D20 > > Sorry, I don't get you. > >=3D20 > > I need the ports tree to be at 319054. > > I then do > >=3D20 > > pkg info -xd xorg-server > /root/xorg-dep > > portmaster -f `cat /root/xorg-dep` > >=3D20 > > Is this not supported? >=20 > You mean you went forward and switch back to a former version? >=20 > yes >=20 >=20 > Switching from 1.1 back to 1.0 has been taken in account during the pkg-= dev=3D > el > phase, but not considered for after 1.1 is offically released which expl= ain=3D > s why > you have this message. >=20 > We could had the compatibility he really needed. >=20 > Normal path is not to go backward :) >=20 > ok, so what if I keep only ports-mgmt/pkg up to > date, and leave the rest of the ports tree at > 319054? Will this work, i.e. wil I be able > to use pkg tools with older portmaster? > Or maybe I need to keep both pkg and portmaster > up to date? Will this work? Normally only keeping ports-mgmt/pkg up to date will work, however I will recommand anyway to keep portmaster uptodate either. regards, Bapt --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJqN4ACgkQ8kTtMUmk6ExPAACfcXXVfJXJyTDzquEIA6wJ7/1o kUcAoLmPKEaKO2e04ABNooRgrHi7ErRq =2IhW -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 14:29:53 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90B893F9 for ; Tue, 25 Jun 2013 14:29:53 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by mx1.freebsd.org (Postfix) with ESMTP id E19C21E4B for ; Tue, 25 Jun 2013 14:29:52 +0000 (UTC) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKUcmpWuHcaPLBVWPYIx+HbVXstipmHHxo@postini.com; Tue, 25 Jun 2013 14:29:53 UTC Received: by mail-wi0-f172.google.com with SMTP id c10so868104wiw.17 for ; Tue, 25 Jun 2013 07:29:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:message-id:to:subject:cc:reply-to:in-reply-to :x-gm-message-state; bh=gvXePifE6OAocpArzxoPhqjHIcBcsRhpfWgN/d4O/pU=; b=VQC/qz4JFCAy+Ucoh8N3hrcMzzGa/Y6mNGxG8oxS8r7Gdm+hbZA0joCWflWYXdsO7R ImPMyxd+1Fa/Dr6JsD7NhUGlGyoM6KF6nUMZ6SH+xUf6m4MHu5Tzv008c96yZVqGZmsO bH6lumka2z0QXzhp1fOzmU02KQTQ8RfdI83n8W8zR7vyVBbDyqHXBaqmUJ6xi2cwHkax oaPM53ONeDxdBMjzfX2DD6iw9itYxZaL38vnOOMyED0GJt173/tKgzvfAl0RaN8NXdON axp+bKjsTaI0HmWmd4CwKEPCfVquRjc3B3xNjG60cgrpgu1audGFrOqHzBe94VXl5ZZ5 kuTw== X-Received: by 10.180.92.98 with SMTP id cl2mr9272772wib.43.1372170237949; Tue, 25 Jun 2013 07:23:57 -0700 (PDT) X-Received: by 10.180.92.98 with SMTP id cl2mr9272767wib.43.1372170237880; Tue, 25 Jun 2013 07:23:57 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id m3sm4474302wij.5.2013.06.25.07.23.56 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 07:23:56 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r5PENssl016717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2013 15:23:55 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r5PENsE2016716; Tue, 25 Jun 2013 15:23:54 +0100 (BST) (envelope-from mexas) Date: Tue, 25 Jun 2013 15:23:54 +0100 (BST) From: Anton Shterenlikht Message-Id: <201306251423.r5PENsE2016716@mech-cluster241.men.bris.ac.uk> To: bapt@FreeBSD.org, mexas@bristol.ac.uk Subject: Re: pkg: sqlite: no such column: infos (pkgdb.c:1086) In-Reply-To: <20130625140146.GA93612@ithaqua.etoilebsd.net> X-Gm-Message-State: ALoCoQnQjWK7Svb+HeFiF+mOeeEcchoi/QK0qYjUaernyCCif89hJoLurSe9BHmpqBEN6P88dXIcuFchXsvISykQpEV0rBfx1tQt9vWENWqk1OOgCpLsFlEHnSwFBxlVYFgeRHRQJN0lPpPRHW7c1h1eFVf0rtLcOSm+Z8e89nR4QTYGC4jeV2U= Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:29:53 -0000 From baptiste.daroussin@gmail.com Tue Jun 25 15:20:11 2013 On Tue, Jun 25, 2013 at 02:57:16PM +0100, Anton Shterenlikht wrote: > From baptiste.daroussin@gmail.com Tue Jun 25 14:52:59 2013 >=20 > On Tue, Jun 25, 2013 at 02:22:31PM +0100, Anton Shterenlikht wrote: > > I'm debugging X11 on sparc64. > > I need to roll the ports tree back to 319054. > > On downgrading pkg I get: > > > > > Running ldconfig > > /sbin/ldconfig -m /usr/local/lib > > > Registering installation for pkg-1.0.12_1 > > pkg: warning: database version 19 is newer than libpkg(3) version 12, = but=3D > still > > compatible > > pkg: sqlite: no such column: infos (pkgdb.c:1086) > > pkg-static: warning: database version 19 is newer than libpkg(3) versi= on =3D > 12, but > > still compatible > > Installing pkg-1.0.12_1...pkg-static: sqlite: table packages has no co= lum=3D > n named > > infos (pkgdb.c:1757) > > pkg-static: sqlite: cannot rollback - no transaction is active (pkgdb.= c:2=3D > 266) > > *** Error code 70 > > > > Stop. > > make: stopped in /usr/ports/ports-mgmt/pkg > > *** Error code 1 > > > > Shall I open a PR? > > > > Thanks > > > > Anton >=20 > Why downgrading? Please upgrade again to 1.1.2 :) and report bug if any. >=20 > Sorry, I don't get you. >=20 > I need the ports tree to be at 319054. > I then do >=20 > pkg info -xd xorg-server > /root/xorg-dep > portmaster -f `cat /root/xorg-dep` >=20 > Is this not supported? You mean you went forward and switch back to a former version? yes Switching from 1.1 back to 1.0 has been taken in account during the pkg-dev= el phase, but not considered for after 1.1 is offically released which explain= s why you have this message. We could had the compatibility he really needed. Normal path is not to go backward :) ok, so what if I keep only ports-mgmt/pkg up to date, and leave the rest of the ports tree at 319054? Will this work, i.e. wil I be able to use pkg tools with older portmaster? Or maybe I need to keep both pkg and portmaster up to date? Will this work? Thanks Anton From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 14:58:57 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A551FD for ; Tue, 25 Jun 2013 14:58:57 +0000 (UTC) (envelope-from feld@feld.me) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3A48E1FDA for ; Tue, 25 Jun 2013 14:58:56 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9E10B2084D for ; Tue, 25 Jun 2013 10:58:55 -0400 (EDT) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute2.internal (MEProxy); Tue, 25 Jun 2013 10:58:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= 5NlOCEFpf0DXIiiMa0L6LlFdZP0=; b=a6J6wcDRfoNC13F9ZoCm0s+JvikZZN0d cBvO1o/xa3pI1rBZu3qESMEk/lv8v9nlorRd9n9JP7uI18OVG5mVNOVugu6NF+DJ NQir6aNNeJz2+/IcmSrIA2mH2VJxJvDa82g9prMfaHYghRM+PS5pT8zf/8Kq9p9o vu1EsPWE17c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=5NlOCEFpf0DXIiiMa0L6LlFdZP0=; b=U1t ULjtWBF97Uj/JJtZYEu1tyvGIDmMNVjS0RVpUxUw5M9Ub7rHNK74LuuHY5y/MW0M OjfKUIc3BBhfeVnmLwHiZC85FNv+JmbVVCFj/2MBsTCJjOBVKkc0I7equlEaKjG+ r6m+yVcHG83TQsHKtjF479adHQd7y5KZyg02KVNQ= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 74B46B00003; Tue, 25 Jun 2013 10:58:55 -0400 (EDT) Message-Id: <1372172335.25500.140661248295345.035BF416@webmail.messagingengine.com> X-Sasl-Enc: gc5ontLSKOK4B+EM+H9wxjmSTg/1lNV6tMI1OPFvUGjX 1372172335 From: Mark Felder To: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae8e04c In-Reply-To: References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> <20130625115711.GJ75533@ithaqua.etoilebsd.net> Subject: Re: pkgng seems to be out of date? Date: Tue, 25 Jun 2013 09:58:55 -0500 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:58:57 -0000 On Tue, Jun 25, 2013, at 7:50, Ben Laurie wrote: > > Hmmm. pkg updating doesn't actually show the relevant 20130206 entry - > so not actually useful. > pkg updating literally just reads /usr/ports/UPDATING... is your ports tree up to date? Did the committer of this tcl incident commit the changes before touching UPDATING and you're caught inbetween? I suppose this could use a bit of investigation... From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 15:17:13 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BFCF8534 for ; Tue, 25 Jun 2013 15:17:13 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 515F710A4 for ; Tue, 25 Jun 2013 15:17:13 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id hq4so927820wib.12 for ; Tue, 25 Jun 2013 08:17:12 -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=4q0es8JNobdTg9zHOBkWYJlzFmufggGPdki5EGKzwps=; b=rqoi+cAaD0bzZjrnoZn+5QosjCYpw+7UsVXKyWxCHqrH9+xiZRsPJHZp9FkM7raZZ0 je72aI4qnZ+eJr5LoxSeDrUBvFpHFk+SZc/bCuaZ0a2fYTsZovk2kenrD/y+cPxNjGIH D0AboERubi9c9w6Rxgpov141NNJyc7FIpeKb95yUgBTDpDokIJtBqc+WZFe7AroQzxYJ 0MQYBM0pMElkrav0+07DKqmlgPQdy01ruVoKvHNSUBRUASCAvFaRa9/iMqYCSh4gY38j wyrjMiYj/9KGg6QVNNrGdAEIybyYo73IVXrQe0U85anNpRRPCEou8IaSMDYuFFm7m4+o 6bhA== X-Received: by 10.180.90.104 with SMTP id bv8mr9508762wib.15.1372173432555; Tue, 25 Jun 2013 08:17:12 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id p1sm4723251wix.9.2013.06.25.08.17.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 08:17:11 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 17:17:08 +0200 From: Baptiste Daroussin To: Mark Felder Subject: Re: pkgng seems to be out of date? Message-ID: <20130625151708.GC93612@ithaqua.etoilebsd.net> References: <20130625103152.GF75533@ithaqua.etoilebsd.net> <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> <20130625115711.GJ75533@ithaqua.etoilebsd.net> <1372172335.25500.140661248295345.035BF416@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: <1372172335.25500.140661248295345.035BF416@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:17:13 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 09:58:55AM -0500, Mark Felder wrote: > On Tue, Jun 25, 2013, at 7:50, Ben Laurie wrote: > >=20 > > Hmmm. pkg updating doesn't actually show the relevant 20130206 entry - > > so not actually useful. > > >=20 > pkg updating literally just reads /usr/ports/UPDATING... is your ports > tree up to date? Did the committer of this tcl incident commit the > changes before touching UPDATING and you're caught inbetween? I suppose > this could use a bit of investigation... pkg updating tries match the installed packages origin in AFFECTS line, via strstr, in that case it does not match that is why it fails at showing it u= p. I'm fixing the UPDATING entry. regards, Bapt --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJtHQACgkQ8kTtMUmk6Ewt0ACfVt4vOqXfOJ9sQkVIKbmC6suO 48oAniuiDjqvnoJ3bnt/3D1M6JJl/LPN =hmoZ -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 15:23:15 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08EA671B for ; Tue, 25 Jun 2013 15:23:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8111149 for ; Tue, 25 Jun 2013 15:23:14 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so9324227wgh.11 for ; Tue, 25 Jun 2013 08:23:13 -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=53Iq8Ln+A5s7p0w3POWzcL2iZXMlkKCOo1kZj122iZ4=; b=I0a57D8alpJ5axDSrGijtrHiesZ07RuvK7TLuoMyAYycsGnSUTpsdoScw82jyMhHW7 weLmEgQhATn3nd/obOHl8TLOVFk3skIyJx5mSapkDQ384lW/o4Hbea8MG4TgLwTWdiV+ r9GIuH+AcYboSySzc97QjclYz/VZceizvQiCkp01VUZSJYagwUynxP6FF1VOkqRTYtHC 2tCpfnePXyg1oYUGFjLcOCsPto9h3Iiuzy3HY1zawHBfvb2mi6g8UBs8AeI15YZrjvgO 9WUYn0NoXhGLEz0tdal73lv0aRN4/fI5Oe3qurIVeCPD+kpkGOsez6AMje2xKsszNoek QmiA== X-Received: by 10.194.9.70 with SMTP id x6mr14955358wja.19.1372173793750; Tue, 25 Jun 2013 08:23:13 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id cw8sm4779302wib.7.2013.06.25.08.23.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 08:23:12 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 17:23:10 +0200 From: Baptiste Daroussin To: Mark Felder Subject: Re: pkgng seems to be out of date? Message-ID: <20130625152310.GD93612@ithaqua.etoilebsd.net> References: <20130625104028.GG75533@ithaqua.etoilebsd.net> <20130625113206.GH75533@ithaqua.etoilebsd.net> <20130625115711.GJ75533@ithaqua.etoilebsd.net> <1372172335.25500.140661248295345.035BF416@webmail.messagingengine.com> <20130625151708.GC93612@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xm/fll+QQv+hsKip" Content-Disposition: inline In-Reply-To: <20130625151708.GC93612@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:23:15 -0000 --Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 05:17:08PM +0200, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 09:58:55AM -0500, Mark Felder wrote: > > On Tue, Jun 25, 2013, at 7:50, Ben Laurie wrote: > > >=20 > > > Hmmm. pkg updating doesn't actually show the relevant 20130206 entry - > > > so not actually useful. > > > > >=20 > > pkg updating literally just reads /usr/ports/UPDATING... is your ports > > tree up to date? Did the committer of this tcl incident commit the > > changes before touching UPDATING and you're caught inbetween? I suppose > > this could use a bit of investigation... >=20 > pkg updating tries match the installed packages origin in AFFECTS line, v= ia > strstr, in that case it does not match that is why it fails at showing it= up. >=20 > I'm fixing the UPDATING entry. In fact that would mean too many entries in AFFECTS. Best would be to impro= ve pkg updating matching. regards, Bapt --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHJtd4ACgkQ8kTtMUmk6EwcxQCePcpWSF9h9VO0gXDdROhdDOxL duIAn3TsFeqf/ytgcBToBuYfijh/yCX6 =e0k0 -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 18:47:03 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51976C21; Tue, 25 Jun 2013 18:47:03 +0000 (UTC) (envelope-from michipili@gmail.com) Received: from cc-smtpout2.netcologne.de (cc-smtpout2.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:2]) by mx1.freebsd.org (Postfix) with ESMTP id 15E831D77; Tue, 25 Jun 2013 18:47:03 +0000 (UTC) Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id 8AB191247C; Tue, 25 Jun 2013 20:47:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by cc-smtpin3.netcologne.de (Postfix) with ESMTP id 85CD311DFC; Tue, 25 Jun 2013 20:47:01 +0200 (CEST) Received: from [89.0.150.163] (helo=cc-smtpin3.netcologne.de) by localhost with ESMTP (eXpurgate 4.0.0) (envelope-from ) id 51c9e5a5-05d7-7f0000012729-7f00000198b7-1 for ; Tue, 25 Jun 2013 20:47:01 +0200 Received: from llea.celt.neu (xdsl-89-0-150-163.netcologne.de [89.0.150.163]) by cc-smtpin3.netcologne.de (Postfix) with ESMTPA; Tue, 25 Jun 2013 20:47:00 +0200 (CEST) Message-ID: <51C9E5A4.2060502@gmail.com> Date: Tue, 25 Jun 2013 20:47:00 +0200 From: =?ISO-8859-1?Q?Michael_Gr=FCnewald?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121104 Firefox/16.0 SeaMonkey/2.13.2 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: Ocaml ports needs love References: <20130227132633.GI16178@ithaqua.etoilebsd.net> In-Reply-To: <20130227132633.GI16178@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:47:03 -0000 Baptiste Daroussin wrote: > On Wed, Feb 27, 2013 at 01:09:34PM +0000, b.f. wrote: >>> Probably creating a ocaml@ team would be a good idea? It feels good to see that more people are willing to improve the support of OCaml in FreeBSD. Besides maintaining individual ports, we also want to integrate GODI or OASIS in ports, so it is probably a good idea to have a common place to discuss these projects, to keep a list of open tasks and describe best practices. A mailing list could be useful, as would a section on the wiki [1]. I am pleased to announce that I improved my submission for OCaml-4.00 [2] (there is still a minor issue) and applied for a project ocaml-freebsd on OCamcore's forge. [1] https://wiki.freebsd.org/Haskell [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=173364&cat=ports Regards, Michael From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 19:44:33 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4B11BC8; Tue, 25 Jun 2013 19:44:33 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6725B10E5; Tue, 25 Jun 2013 19:44:33 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r5PJiVhm020070; Tue, 25 Jun 2013 15:44:31 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r5PJiV97020067; Tue, 25 Jun 2013 15:44:31 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20937.62239.626943.350086@hergotha.csail.mit.edu> Date: Tue, 25 Jun 2013 15:44:31 -0400 From: Garrett Wollman To: hackers@freebsd.org, ports@freebsd.org Subject: rc.d scripts to control multiple instances of the same daemon? X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 25 Jun 2013 15:44:32 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:44:33 -0000 I'm in the process of (re)writing an rc.d script for kadmind (security/krb5). Unlike the main Kerberos daemon, kadmind needs to have a separate instance for each realm on the server -- it can't support multiple realms in a single process. What I need to be able to do: 1) Have different flags and pidfiles for each instance. 2) Be able to start, stop, restart, and status each individual instance by giving its name on the command line. 3) Have all instances start/stop automatically when a specific instance isn't specified. I've looked around for examples of good practice to emulate, and haven't found much. The closest to what I want looks to be vboxheadless, but I'm uncomfortable with the amount of mechanism from rc.subr that it needs to reimplement. Are there any better examples? -GAWollman From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 19:56:26 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D860F6F for ; Tue, 25 Jun 2013 19:56:26 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id A0F0C1184 for ; Tue, 25 Jun 2013 19:56:25 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LfUkZ-1USuhd1lCT-00p8Rb for ; Tue, 25 Jun 2013 21:56:24 +0200 Received: (qmail invoked by alias); 25 Jun 2013 19:56:24 -0000 Received: from p578be941.dip0.t-ipconnect.de (EHLO [192.168.0.100]) [87.139.233.65] by mail.gmx.net (mp019) with SMTP; 25 Jun 2013 21:56:24 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX1+tvalV52St3Ulr54PBWEK6g9XB9KhxPWF9FMi7Br VHzVXUnwYne1sg Message-ID: <51C9F5E7.1040607@gmx.de> Date: Tue, 25 Jun 2013 21:56:23 +0200 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Garrett Wollman Subject: Re: rc.d scripts to control multiple instances of the same daemon? References: <20937.62239.626943.350086@hergotha.csail.mit.edu> In-Reply-To: <20937.62239.626943.350086@hergotha.csail.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ports@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:56:26 -0000 On 2013-06-25 21:44, Garrett Wollman wrote: > I'm in the process of (re)writing an rc.d script for kadmind > (security/krb5). Unlike the main Kerberos daemon, kadmind needs to > have a separate instance for each realm on the server -- it can't > support multiple realms in a single process. What I need to be able > to do: > > 1) Have different flags and pidfiles for each instance. > 2) Be able to start, stop, restart, and status each individual > instance by giving its name on the command line. > 3) Have all instances start/stop automatically when a specific > instance isn't specified. > > I've looked around for examples of good practice to emulate, and > haven't found much. The closest to what I want looks to be > vboxheadless, but I'm uncomfortable with the amount of mechanism from > rc.subr that it needs to reimplement. Are there any better examples? > > -GAWollman > Take a look into the openvpn rc script (works with softlinks). A more complex script that supports multiple instances can be found in the www/apache2x ports. -- olli From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 20:12:18 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8498A4E; Tue, 25 Jun 2013 20:12:18 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 804EE12BC; Tue, 25 Jun 2013 20:12:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UrZb2-0005bD-66; Tue, 25 Jun 2013 20:12:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r5PKC9Pl001014; Tue, 25 Jun 2013 14:12:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19JCODgVcEHrM5GTHs+uewb Subject: Re: rc.d scripts to control multiple instances of the same daemon? From: Ian Lepore To: Garrett Wollman In-Reply-To: <20937.62239.626943.350086@hergotha.csail.mit.edu> References: <20937.62239.626943.350086@hergotha.csail.mit.edu> Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 2013 14:12:09 -0600 Message-ID: <1372191129.1109.90.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, hackers@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:12:18 -0000 On Tue, 2013-06-25 at 15:44 -0400, Garrett Wollman wrote: > I'm in the process of (re)writing an rc.d script for kadmind > (security/krb5). Unlike the main Kerberos daemon, kadmind needs to > have a separate instance for each realm on the server -- it can't > support multiple realms in a single process. What I need to be able > to do: > > 1) Have different flags and pidfiles for each instance. > 2) Be able to start, stop, restart, and status each individual > instance by giving its name on the command line. > 3) Have all instances start/stop automatically when a specific > instance isn't specified. > > I've looked around for examples of good practice to emulate, and > haven't found much. The closest to what I want looks to be > vboxheadless, but I'm uncomfortable with the amount of mechanism from > rc.subr that it needs to reimplement. Are there any better examples? The one like that I use the most is "service netif restart fpx0" but I'm not sure the complex network stuff will be the cleanest example of anything except how to do complex network stuff. :) -- Ian From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 20:37:48 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3DDA25B3; Tue, 25 Jun 2013 20:37:48 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel09.rubas.ch (cpanel09.rubas.ch [195.182.222.79]) by mx1.freebsd.org (Postfix) with ESMTP id F02F7156D; Tue, 25 Jun 2013 20:37:47 +0000 (UTC) Received: from 98-41.199-178.cust.bluewin.ch ([178.199.41.98]:60667 helo=gahrfit.gahr.ch) by cpanel09.rubas.ch with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UrZzf-000xjQ-M8; Tue, 25 Jun 2013 22:37:40 +0200 Date: Tue, 25 Jun 2013 22:37:36 +0200 From: Pietro Cerutti To: Garrett Wollman Subject: Re: rc.d scripts to control multiple instances of the same daemon? Message-ID: <20130625203734.GD32654@gahrfit.gahr.ch> References: <20937.62239.626943.350086@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d9ADC0YsG2v16Js0" Content-Disposition: inline In-Reply-To: <20937.62239.626943.350086@hergotha.csail.mit.edu> X-PGP-Key: 0x9571F78E X-PGP-Fingerprint: 1203 92B5 3919 AF84 9B97 28D6 C0C2 6A98 9571 F78E User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel09.rubas.ch X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Get-Message-Sender-Via: cpanel09.rubas.ch: authenticated_id: gahr@gahr.ch Cc: ports@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:37:48 -0000 --d9ADC0YsG2v16Js0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jun-25, 15:44, Garrett Wollman wrote: > I'm in the process of (re)writing an rc.d script for kadmind > (security/krb5). Unlike the main Kerberos daemon, kadmind needs to > have a separate instance for each realm on the server -- it can't > support multiple realms in a single process. What I need to be able > to do: >=20 > 1) Have different flags and pidfiles for each instance. > 2) Be able to start, stop, restart, and status each individual > instance by giving its name on the command line. > 3) Have all instances start/stop automatically when a specific > instance isn't specified. >=20 > I've looked around for examples of good practice to emulate, and > haven't found much. The closest to what I want looks to be > vboxheadless, but I'm uncomfortable with the amount of mechanism from > rc.subr that it needs to reimplement. Are there any better examples? Wouldn't something like this be enough? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #!/bin/sh =2E /etc/rc.subr name=3D"kadmind" rcvar=3D${name}_enable start_cmd=3D"kadmind_start $2" load_rc_config $name kadmind_start() { if [ -z $1 ]; then echo "starting all instances" else echo "starting instance $1" fi } run_rc_command "$1" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # /usr/local/etc/rc.d/kadmind start starting all instances # /usr/local/etc/rc.d/kadmind start myinst starting instance myinst --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --d9ADC0YsG2v16Js0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHJ/44ACgkQwMJqmJVx944dUQCfXpZpkBM0hu+ycjlJJAy0tJLQ /VsAoNPUIY1yZl9dLBc0WOmPx3uyJZUW =djit -----END PGP SIGNATURE----- --d9ADC0YsG2v16Js0-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 20:41:04 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30F197EC; Tue, 25 Jun 2013 20:41:04 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1A41603; Tue, 25 Jun 2013 20:41:03 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so9983799wgh.9 for ; Tue, 25 Jun 2013 13:41:02 -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=MgiLg/jIt0eeYj8QZPCQ7KYHXEK3dCaKYpF+4b3wBlc=; b=J9OcvungpsMB82UjIH778Nrgo518bHkXuk3PMP+kUay4YdCaEIPFf2rSMo9+fK5ZXU 8hybwDBOFZWyEhPscpHKZ92jqfUI4kR/2DrjTbwshJ1bDh0n9dC661YUnV6LeJDFiQDX WoSkylVXvh/++Yqc4EtxgZ7N1XsKFotXott2OlmyOolFb3nrBlMIJJ6om48tdlb/B0jh s2gZT3CpQ40puIRAcmXQbpPkcBouDdGCYs1beudoEooY58fPAQjSGGGVie0+NJp+V4AM K55OxHpqfQy3GvKIdfjlVUPeTJv65D4Sb2zN0V8xDlp8XAyNH0Z0WvYvdXnAmgAYDINN WP7g== X-Received: by 10.180.87.162 with SMTP id az2mr10408922wib.10.1372192862675; Tue, 25 Jun 2013 13:41:02 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id s19sm6538245wik.11.2013.06.25.13.41.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 13:41:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 25 Jun 2013 22:40:59 +0200 From: Baptiste Daroussin To: Garrett Wollman Subject: Re: rc.d scripts to control multiple instances of the same daemon? Message-ID: <20130625204059.GE93612@ithaqua.etoilebsd.net> References: <20937.62239.626943.350086@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mR8QP4gmHujQHb1c" Content-Disposition: inline In-Reply-To: <20937.62239.626943.350086@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:41:04 -0000 --mR8QP4gmHujQHb1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 03:44:31PM -0400, Garrett Wollman wrote: > I'm in the process of (re)writing an rc.d script for kadmind > (security/krb5). Unlike the main Kerberos daemon, kadmind needs to > have a separate instance for each realm on the server -- it can't > support multiple realms in a single process. What I need to be able > to do: >=20 > 1) Have different flags and pidfiles for each instance. > 2) Be able to start, stop, restart, and status each individual > instance by giving its name on the command line. > 3) Have all instances start/stop automatically when a specific > instance isn't specified. >=20 > I've looked around for examples of good practice to emulate, and > haven't found much. The closest to what I want looks to be > vboxheadless, but I'm uncomfortable with the amount of mechanism from > rc.subr that it needs to reimplement. Are there any better examples? >=20 > -GAWollman >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" This is a simple multi instance rc.d script: http://svnweb.freebsd.org/ports/head/www/fcgiwrap/files/fcgiwrap.in?revisio= n=3D307542&view=3Dmarkup regards, Bapt --mR8QP4gmHujQHb1c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHKAFsACgkQ8kTtMUmk6ExvigCgoz3XDihcKC/fS3u1vpTm0ZLZ SO4AoKLFTTIINM+PNjz48h57lyimXcBM =EHLw -----END PGP SIGNATURE----- --mR8QP4gmHujQHb1c-- From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 23:53:05 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51CBBAD6 for ; Tue, 25 Jun 2013 23:53:05 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 2E7001CDF for ; Tue, 25 Jun 2013 23:53:05 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq13so13361704pab.39 for ; Tue, 25 Jun 2013 16:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=+ePIDVHUvZJMQKbmAXtsFwQUl3L5Ck7YyMR8815lKCc=; b=HOmuJGmf/7yfDvJlzZJo6vCgNF16bBb2rMvhUJR+i06sJ/22zgKmdmwhyGk2eTGuIG gcndsddDDK5+65Ix3BDVjaZKtx5DtJvNcNRJ3y9Jwp3aFX9dDmtL3jbGwiCmu1Q7Xp5n Ejay5QjJgt1OBDOMhNViAEO/UvH4uh2Hub35jPE71YEw126oxXW1VJOOzAtNms0x+SMB nmHiBeappoRoCXcjcBepQ03M4ILYZU2THoZw2EmVNrH0iGgJgi6QamhQe2/yyBMlHdaG CAcfTC1cV1qYglpqPQzA5KjFIcfqyOgE4sY01nUfpLCpSpbNCv6AYOeX6ksjPKwEGyBO NSbw== X-Received: by 10.68.163.97 with SMTP id yh1mr1448772pbb.33.1372204385011; Tue, 25 Jun 2013 16:53:05 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id xl3sm25260532pbb.17.2013.06.25.16.53.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 16:53:04 -0700 (PDT) Message-ID: <51CA2D5A.1020309@FreeBSD.org> Date: Wed, 26 Jun 2013 09:52:58 +1000 From: Kubilay Kocak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Janet Sullivan Subject: Re: REWARD for working pam_mount References: <0a9ae9e0df704d13b643ee26d487e73a@BY2PR07MB043.namprd07.prod.outlook.com> In-Reply-To: <0a9ae9e0df704d13b643ee26d487e73a@BY2PR07MB043.namprd07.prod.outlook.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: koobs@FreeBSD.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:53:05 -0000 On 8/06/2013 1:57 PM, Janet Sullivan wrote: > The /usr/ports/sysutils/pam_mount port is broken, because it's expecting an older version of libHX. I'd really like to have a working pam_mount, and am willing to paypal US $50 over to the first person who gets it working. I'm not subscribed to the list, so please email me directly to claim the prize. > _______________________________________________ > 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" > Hi Janet, Just wanted to get a follow-up on whether the patched worked for you so I can submit is as a PR for the maintainer and get it committed Koobs From owner-freebsd-ports@FreeBSD.ORG Tue Jun 25 23:55:15 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7CD35B82 for ; Tue, 25 Jun 2013 23:55:15 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id A248E1CF5 for ; Tue, 25 Jun 2013 23:55:14 +0000 (UTC) Received: (qmail 34518 invoked by uid 89); 25 Jun 2013 23:55:07 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.66) by mail.grem.de with ESMTPA; 25 Jun 2013 23:55:07 -0000 Date: Wed, 26 Jun 2013 01:55:08 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130626015508.426ab5b9@bsd64.grem.de> In-Reply-To: References: <20130613031535.4087d7f9@bsd64.grem.de> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 23:55:15 -0000 On Sat, 22 Jun 2013 00:27:53 +0200 Dimitry Andric wrote: > On Jun 21, 2013, at 22:07, Dimitry Andric wrote: > > On Jun 13, 2013, at 03:15, Michael Gmelin wrote: > > ... Hi Dimitry, Despite my patch to mitigate the problem I discussed and analyzed the initialization order issue and I think there is a something wrong in 10-CURRENT. The problem is that static initialization happens in the expected order (same translation unit), but termination does *not* happen in the reverse order of initialization, which - according to the C++ standard section 3.6.3 should be guaranteed: "If the completion of the constructor or dynamic initialization of an object with static storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first." The following conditions have to be met in order to show the problem: 1. Two static objects defined in the translation unit containing main 2. Definition of one of the underlying objects is in a separate source which is used to build a shared library 3. Both, the translation unit containing main an the one forming the shared library are compiled using -fPIC (or -fpic). The problem happens on: - 10-CURRENT with system clang - 10-CURRENT with clang 3.3 from ports It doesn't happen on: - 10-CURRENT with system gcc - 9.1-RELEASE with system gcc - 9.1-RELEASE with system clang - 9.1-RELEASE with clang 3.3 from ports Also, it does *not* happen on: - 9.1-RELEASE running executables built on 10-CURRENT (any compiler) I stripped the problem down to an easy to handle test case, you can find as an patch at the end of this mail or download a tarball at http://blog.grem.de/majortom.tgz To execute the test: fetch -o - http://blog.grem.de/majortom.tgz | tar -xzf - cd majortom make run The expected outcome is: Ground | Outer::Outer Control | Inner::Inner to | main() Major | Inner::~Inner Tom | Outer::~Outer The actual outcome on 10-CURRENT system clang or clang33 from ports is: Ground | Outer::Outer Control | Inner::Inner to | main() Tom | Outer::~Outer Major | Inner::~Inner Which is really bad (not just for Bowie). Time to open another PR? Cheers, Michael --- majortom.patch begins here --- diff -x .git -ruN majortom.old/Makefile majortom/Makefile --- majortom.old/Makefile 1970-01-01 00:00:00.000000000 +0000 +++ majortom/Makefile 2013-06-25 22:40:48.039332456 +0000 @@ -0,0 +1,21 @@ +CXX?=c++ + +all: example + +out.o: out.cpp out.h + $(CXX) -pthread -c -fPIC out.cpp -I. -I/usr/local/include -o out.o + +libout.so: out.o + $(CXX) -pthread -shared -fPIC out.o -o libout.so + +main.o: main.cpp out.h + $(CXX) -pthread -c -fPIC main.cpp -I. -I/usr/local/include -o main.o + +example: libout.so main.o + $(CXX) -pthread -fPIC -L. -lout main.o -o example + +run: example + @LD_LIBRARY_PATH=. ./example + +clean: + rm -f *.so example *.o *~ \ No newline at end of file diff -x .git -ruN majortom.old/main.cpp majortom/main.cpp --- majortom.old/main.cpp 1970-01-01 00:00:00.000000000 +0000 +++ majortom/main.cpp 2013-06-25 22:43:27.116055202 +0000 @@ -0,0 +1,20 @@ +#include +#include + +struct Inner +{ + Inner() { + printf("\t Control | Inner::Inner\n"); + } + + ~Inner() { + printf("\t Major | Inner::~Inner\n"); + } +}; + +static Outer outerInstance; +static Inner innerInstance; + +int main() { + printf("\t to | main()\n"); +} diff -x .git -ruN majortom.old/out.cpp majortom/out.cpp --- majortom.old/out.cpp 1970-01-01 00:00:00.000000000 +0000 +++ majortom/out.cpp 2013-06-25 22:42:55.188061650 +0000 @@ -0,0 +1,10 @@ +#include +#include + +Outer::Outer() { + printf("\tGround | Outer::Outer\n"); +} + +Outer::~Outer() { + printf("\t Tom | Outer::~Outer\n"); +} diff -x .git -ruN majortom.old/out.h majortom/out.h --- majortom.old/out.h 1970-01-01 00:00:00.000000000 +0000 +++ majortom/out.h 2013-06-25 22:25:44.817345120 +0000 @@ -0,0 +1,11 @@ +#ifndef OUT_H +#define OUT_H + +class Outer +{ +public: + Outer(); + ~Outer(); +}; + +#endif --- majortom.patch ends here --- -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 00:14:29 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB1E321E; Wed, 26 Jun 2013 00:14:29 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 657DB1DA3; Wed, 26 Jun 2013 00:14:29 +0000 (UTC) Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A41E1172067; Wed, 26 Jun 2013 02:14:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id JzgpIDyu1P7A; Wed, 26 Jun 2013 02:14:09 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 0C22E172074; Wed, 26 Jun 2013 02:14:09 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 61A6673A1C; Tue, 25 Jun 2013 17:14:06 -0700 (PDT) Date: Tue, 25 Jun 2013 17:14:06 -0700 From: Jeremy Chadwick To: freebsd-ports@freebsd.org Subject: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626001406.GA63314@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, bapt@freebsd.org, az@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 00:14:29 -0000 (I am not subscribed to -ports so please keep me CC'd) To the committers and reviewers of r320679: http://svnweb.freebsd.org/ports?view=revision&revision=320679 The pathing change in bsd.perl.mk has broken things quite badly for anyone who **does not** upgrade lang/perl* but chooses to upgrade a perl module port (ex. p5-*) -- or even reinstall an existing one. This creates a very broken situation. The issue is 100% reproducible; simplest method: pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever What I'd like to know: - Why the major.minor.patchlevel --> major.minor path change in the first place. I have never, ever seen this done anywhere on any *IX system I've used. Where's the justification? Was this discussed on some perl mailing list somewhere as a "new and better way"? It's essentially saying "x.y.z is always going to be compatible with x.y.z+1" which is not true (particularly with XS, as I understand it). Where was this discussed publicly? - Why bsd.perl.mk was changed how it was, i.e. why it didn't stick with using the major.minor.patchlevel pathing scheme by default, and if one of the newer perl versions was used (which would warrant the user having to uninstall their perl, thus forced to rebuild/reinstall all their p5-* stuff anyway), use the newer pathing scheme? It could be dealt with equivalently (pseudo-code per se) as: if ($PERL_VERSION =~ /^5\.12\.[5-9]/ or $PERL_VERSION =~ /^5\.14\.[4-9]/ or $PERL_VERSION =~ /^5\.16\.[3-9]/) { $use_newer_paths = 1; } else { $use_newer_paths = 0; } The logic here could be modified (or inverted) if desired. And this framework would only have to be left in for a little while (maybe a few years) until all the older FreeBSD versions had been officially EOL'd. (Remember: those using EOL'd FreeBSD versions but with ports trees updated past that EOL date are living dangerously, as no compatibility is guaranteed -- this has come up many times on the lists, and even somewhat recently). You should have seen the look on my face when I went to update p5-Mail-SpamAssassin (and nothing else) on my system and suddenly found it shitting the bed, forcing me to "pkg_delete -af && rm -fr /usr/local" and start over fresh due to leftover cruft populating /usr/local. I say all this well aware of what ports/UPDATING said -- however the instructions blindly make the assumption the person is building from source or using pkg (not pkg_* tools). The versions of perl on the official package mirrors in Latest/ do not work properly with these changes, and those are still packages which are **actively used** during **present-day-supported** FreeBSD installations. FreeBSD users do expect to "pkg_add -r" something (which can also be done from the installer on fresh installations), then install things from /usr/ports with "make install"; this is normal and must be supported. Something tells me this is one of those situations where if we still had dougb@ he would have caught it in advance and yelled loudly. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 01:35:44 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A60A73AC; Wed, 26 Jun 2013 01:35:44 +0000 (UTC) (envelope-from dutchman01@quicknet.nl) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6A45A1034; Wed, 26 Jun 2013 01:35:43 +0000 (UTC) Received: from [212.54.42.134] (helo=smtp3.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1UrdxU-0005cK-Jx; Wed, 26 Jun 2013 02:51:40 +0200 Received: from 5ed3f892.cm-7-4d.dynamic.ziggo.nl ([94.211.248.146] helo=PC01) by smtp3.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1UrdxU-0004Nn-E5; Wed, 26 Jun 2013 02:51:40 +0200 From: "Dutchman01" To: Subject: FreeBSD Port: samba36-3.6.13 Date: Wed, 26 Jun 2013 02:51:34 +0200 Message-ID: <000301ce7207$4e8a3120$eb9e9360$@quicknet.nl> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5yByXIeRFfHbBXSfyPmGQo0e9Ygg== Content-Language: nl X-Ziggo-spambar: -- X-Ziggo-spamscore: -2.1 X-Ziggo-spamreport: ALL_TRUSTED=-1, BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, DYN_RDNS_SHORT_HELO_HTML=0.001, FSL_HELO_NON_FQDN_1=0.001, HELO_NO_DOMAIN=0.001, HTML_MESSAGE=0.001, PROLO_TRUST_RDNS=-3, RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:35:44 -0000 Hello timur, Please bump samba to 3.6.16. Thanks, dutchman From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 01:48:07 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2A76B6D2 for ; Wed, 26 Jun 2013 01:48:07 +0000 (UTC) (envelope-from amurphy@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A2F0410B8 for ; Wed, 26 Jun 2013 01:48:06 +0000 (UTC) Received: from [127.0.0.1] (Zia.gsoft.com.au [203.31.81.56]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r5Q1lrWP072463 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 11:17:54 +0930 (CST) (envelope-from amurphy@gsoft.com.au) Message-ID: <51CA485C.1040505@gsoft.com.au> Date: Wed, 26 Jun 2013 11:18:12 +0930 From: Adrian Murphy User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: ports@freebsd.org Subject: pkg & portmaster Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.55 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 01:48:07 -0000 Hi, I noticed portmaster developed a problem after a recent update to ports-mgmt/pkg where the following appears in the output: [: false: bad number I traced it to lines in portmaster where np_orphan is set: np_orphan=`pkg query "%a" $upg_port` It appears 'pkg query "%a"' used to return 0 or 1 and now it returns 'true' or 'false'. The 'pkg help query' text says "%a Returns 1 if the matched package is an orphan package and can be pkg-autoremove(1)'d, 0 otherwise" I further ran into trouble with ports-mgmt/pkg-devel today where portmaster calls: pkg info pkg This fails with ports-mgmt/pkg-devel unless the line is changed to: pkg info pkg-devel This stopped portmaster from working. I reverted to using ports-mgmt/pkg to get around this. Regards, Adrian From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 04:50:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CDB2E25; Wed, 26 Jun 2013 04:50:56 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2861D85; Wed, 26 Jun 2013 04:50:54 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Urhgx-0006e4-UB; Wed, 26 Jun 2013 06:50:51 +0200 Date: Wed, 26 Jun 2013 06:50:51 +0200 From: Kurt Jaeger To: Jeremy Chadwick Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626045051.GA82524@home.opsec.eu> References: <20130626001406.GA63314@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626001406.GA63314@icarus.home.lan> Cc: culot@freebsd.org, bapt@freebsd.org, az@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 04:50:56 -0000 Hi! > - Why the major.minor.patchlevel --> major.minor path change in the > first place. Probably this: Currently, if the perl port is updated to the next patchlevel, one has to recompile a lot of ports. One of my reference hosts still compiles, started approx. a week ago. -- pi@opsec.eu +49 171 3101372 7 years to go ! From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 05:23:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B04C4ADF; Wed, 26 Jun 2013 05:23:56 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 35CC41E8E; Wed, 26 Jun 2013 05:23:55 +0000 (UTC) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BB1C241C088; Wed, 26 Jun 2013 07:23:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MSGWwmyknCjF; Wed, 26 Jun 2013 07:23:37 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B911F41C079; Wed, 26 Jun 2013 07:23:36 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 0098273A1C; Tue, 25 Jun 2013 22:23:34 -0700 (PDT) Date: Tue, 25 Jun 2013 22:23:34 -0700 From: Jeremy Chadwick To: Kurt Jaeger Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626052334.GA67802@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <20130626045051.GA82524@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626045051.GA82524@home.opsec.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, bapt@freebsd.org, az@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:23:56 -0000 On Wed, Jun 26, 2013 at 06:50:51AM +0200, Kurt Jaeger wrote: > Hi! > > > - Why the major.minor.patchlevel --> major.minor path change in the > > first place. > > Probably this: > Currently, if the perl port is updated to the next patchlevel, one has to > recompile a lot of ports. That doesn't make any sense. An example of what "we" (FreeBSD users/ports) had prior to r320679: User has perl-5.12.3 installed (package or port, doesn't matter), and also some perl module (we'll call it p5-Snakes-1.00). User updates /usr/ports, and finds that lang/perl5.12 has been updated to perl 5.12.4 -- this doesn't matter in the least, nothing forces them to update to that, it's unnecessary unless the individual port mandates it (via $PERL_LEVEL). The user also sees p5-Snakes has been updated to 1.02, so the user pkg_delete/deinstalls it, make installs, and now has p5-Snakes-1.02 (fully usable) on their system. It Just Works(tm), built completely off the existing perl-5.12.3 bits. If the user wants to update to perl-5.12.4, yes, they will need to reinstall all their ports -- and justifiably so. Expanding on that: There is no reason I'd assume a.b.c would necessarily be completely compatible with a.b.c+1 or subsequent updates. The two things that come to mind with perl are perlxs and libperl.so (note that there is no .so.N versioning scheme with perl .so bits). The DBI/DBD layer comes to mind here (and that degree of breakage would really upset FreeBSD users). Perl as a language tries to be backwards-compatible as much as possible, but AFAIK this is purely a language/operational compatibility; whether or not the underlying libraries and ABI/API of the shared objects are compatible between minor revisions is an assumption -- unless someone can show me proof otherwise. But even if they can show such proof, it's not justification for the backwards-compatibility breakage in bsd.perl.mk > One of my reference hosts still compiles, started approx. a week ago. I understand, but prior to r320679, you wouldn't have had to do that unless you chose to updated lang/perl5.xx. Instead, what we have *right now* is something that makes assumptions (see above paragraph) **and** breaks fresh FreeBSD installs where the person chooses to install the perl package + update /usr/ports + install a perl module from ports, **as well** as an existing system where an admin just wants to update a perl module from ports. This is for present-day supported FreeBSD versions, not EOL! I'm fine with the major.minor.patchlevel --> major.minor pathname change, **as long** as shims in bsd.perl.mk are put in place to retain use of major.minor.patchlevel paths if an older version of perl is installed on the system. Those shims were not written, and I want to know why, because as I see it we *can* have it both ways. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 05:42:38 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 487CBDFF; Wed, 26 Jun 2013 05:42:38 +0000 (UTC) (envelope-from andrej.zverev@gmail.com) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 00B4A1F18; Wed, 26 Jun 2013 05:42:37 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h1so14419729oag.5 for ; Tue, 25 Jun 2013 22:42:37 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nJJHBNDlS2ZHcVfDWnDvtl72VMoq5YQjtWS4Xa2j/Qo=; b=0B88DZtgoOyFZUQdcKRwqeakgJ+Tjqj1EgdUBZ2ufETJvwbULx/OPuttau2RzhoaId NdeZMetwkK/S2Bdtl3nD2mqvip/rZ/75kBGCoti6chn2+FoQKIDBA5r3BFRUAR+VbLJh qc9/81z8HGc4SDWAxtb/G6qUcbWS76lWiGIB3x28uEXq2a0BbPNCs9fUKzQnyOBzp+7E xah46qYmrdxnYDHlt12rwbIUJ3wecur510vQ8EKx+cxhiJHXd1DRA12Z6F56fx09Uzxp xuCxyP/rd0MRMbQ8KxZcj4LEgjT5Zvrtmr5vdKnFE7thVvcTl84tLRYiz/SH9hO+bUIM KmNw== MIME-Version: 1.0 X-Received: by 10.182.186.41 with SMTP id fh9mr908771obc.37.1372225357609; Tue, 25 Jun 2013 22:42:37 -0700 (PDT) Sender: andrej.zverev@gmail.com Received: by 10.182.144.34 with HTTP; Tue, 25 Jun 2013 22:42:37 -0700 (PDT) In-Reply-To: <20130626001406.GA63314@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> Date: Wed, 26 Jun 2013 09:42:37 +0400 X-Google-Sender-Auth: VWCq-g_MQAc8nOtKkqWtdwrKB20 Message-ID: Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) From: Andrej Zverev To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: culot@freebsd.org, bapt@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:42:38 -0000 Hello, and first please accept my apologies for this situation. > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > svn up /usr/ports > cd /usr/ports/whatever/p5-whatever > make install > pkg_delete p5-whatever As I know we are never supported mixing of ports and packages. If you initially installed something from package and decide to use ports in this case better to rebuild all or stay with packages. > > What I'd like to know: > > - Why the major.minor.patchlevel --> major.minor path change in the > first place. I have never, ever seen this done anywhere on any *IX > system I've used. Where's the justification? Was this discussed on > some perl mailing list somewhere as a "new and better way"? It's > essentially saying "x.y.z is always going to be compatible with x.y.z+1" > which is not true (particularly with XS, as I understand it). Where > was this discussed publicly? http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl I don't want to start yet another bikeshed here. Maybe link above will make some things more clear to you. From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 06:12:35 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B0B9A19; Wed, 26 Jun 2013 06:12:35 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 10BFD1022; Wed, 26 Jun 2013 06:12:34 +0000 (UTC) Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 32D3741C075; Wed, 26 Jun 2013 08:12:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Qf6b70OYnaBi; Wed, 26 Jun 2013 08:12:22 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D328A41C060; Wed, 26 Jun 2013 08:12:21 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 00F1873A1C; Tue, 25 Jun 2013 23:12:19 -0700 (PDT) Date: Tue, 25 Jun 2013 23:12:19 -0700 From: Jeremy Chadwick To: Andrej Zverev Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626061219.GA68398@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, bapt@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 06:12:35 -0000 On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: > Hello, and first please accept my apologies for this situation. Understood, I just hope this can get addressed/fixed sooner than later, because what we have right now is reproducible breakage. :-) > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > > svn up /usr/ports > > cd /usr/ports/whatever/p5-whatever > > make install > > pkg_delete p5-whatever > > As I know we are never supported mixing of ports and packages. > If you initially installed something from package and decide to use > ports in this case better to rebuild all or stay with packages. And here is where you are sadly mistaken. While I cannot find any sort of official statement on the "mixing of the two", the fact of the matter is (and possibly you did not know this -- I'm not sure) that packages are built **from** ports ("make package" does the magic). This is confirmed as well: http://www.freebsd.org/ports/index.html http://www.freebsd.org/doc/en/articles/linux-users/software.html Please be aware when I say "package" I am talking about the .tbz balls utilised by the base system's pkg_* tools (not pkg(8)) and used by the OS installer and so on. For pkg(8) I believe poudriere is used to make the packages. I don't use/can't speak about pkg(8) et al. For both pkg_* tools and ports, both use the same default base path (/usr/local), **and** both register their bits in /var/db/pkg. Package installation does not utilise any part of the ports/Mk/* framework, but that isn't anything new -- it's been like that since at least the 2.2.x days, possibly earlier. So in summary, when making changes to ports/Mk/*, you really have to think about the combination of the two, and make sure you don't break anything when changing key pieces of those framework bits. > > What I'd like to know: > > > > - Why the major.minor.patchlevel --> major.minor path change in the > > first place. I have never, ever seen this done anywhere on any *IX > > system I've used. Where's the justification? Was this discussed on > > some perl mailing list somewhere as a "new and better way"? It's > > essentially saying "x.y.z is always going to be compatible with x.y.z+1" > > which is not true (particularly with XS, as I understand it). Where > > was this discussed publicly? > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl > > I don't want to start yet another bikeshed here. Maybe link above will > make some things more clear to you. Thanks -- I wasn't aware of the freebsd-perl mailing list. I just finished reading the entire thread. The justification seems to be "because Fedora and Debian do it" (that's the best I can find). Okay, fine/great/whatever -- I guess that's a form of justification, just not one I was hoping for. I won't dwell on this at this point -- I got the answer I was looking for. I see no actual harm in moving to major.minor, but the issue here is that backwards compatibility in Mk/bsd.perl.mk for existing perl installations. Many people, for example, do not want to build X.org from source -- so they pkg_add -r X, then build other bits/pieces related to X from ports/source. Even more people do this for OpenOffice/LibreOffice or whatever it's called today ( :-) ). This "combination" needs to be supported. I know it hurts to have to retain backwards compatibility, but it's necessary given how all of this was designed. Such backwards compatibility could be removed, as I said, once sufficient time has passed, particularly once the FreeBSD versions shipping with a ports tree snapshot with perl versions older than those in r320679 have been EOL'd. After that you could remove the framework and cite EOL on such support. This is normal too -- for example on occasion FreeBSD [67].x people show up on -ports and complain that something won't build/some part of the Mk/* framework is broken for them, and EOL is the proper response to that. I know this probably won't hold any ground because I'm not one any longer, but I was a FreeBSD ports committer myself some years ago (~5), so please don't think that I'm just flying off the handle without some existing familiarity with things. If there is truly going to be a "split" between ports and packages in this way, then someone needs to start doing SVN tagging/branches for major changes like this. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 06:40:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C521FFF2; Wed, 26 Jun 2013 06:40:56 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 0B990112E; Wed, 26 Jun 2013 06:40:55 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id w59so10068267wes.10 for ; Tue, 25 Jun 2013 23:40:55 -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=w958lv0Ev0d8U1P5b5AsXMe+jl5iqiQuhC5uocmvQak=; b=ixiXIeMPZoA60ErlJJDItZ5EfSnU16HkNf7GEmAnoZjYXZG/BmqOk9MzzZIXF1Xtos +nw7cdiMVBSfsfougtdQiz5b72lKu5GSUVpzhIKQYUCGEmso2yQEv7a5Sirp8Vh0qCUw n8q2irfWJKXUtaDADs4716dGcgZ5pzm8vRG87JRWOWSF0xgKC4pFVk9Gk0ICKoDiNUtd 8vXXOxxQvCU41sQMnc4J8YK8rjjOgM5pD5r2EnW5SrXqOHwMaPxZCpRqTVelrN9dX0pC WIxoOguITCuPGK92M4+88J+bN7kSfMBGnsWrkIjVTcoHLBGMmF8c25Nq/56m8uSAbKhA Js5g== X-Received: by 10.180.85.35 with SMTP id e3mr1564808wiz.30.1372228855231; Tue, 25 Jun 2013 23:40:55 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id u9sm8625370wif.6.2013.06.25.23.40.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 23:40:54 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 26 Jun 2013 08:40:52 +0200 From: Baptiste Daroussin To: Jeremy Chadwick Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626064051.GG93612@ithaqua.etoilebsd.net> References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qxfKREH7IwbezJ+T" Content-Disposition: inline In-Reply-To: <20130626061219.GA68398@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, freebsd-ports@freebsd.org, Andrej Zverev X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 06:40:56 -0000 --qxfKREH7IwbezJ+T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: > On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: > > Hello, and first please accept my apologies for this situation. >=20 > Understood, I just hope this can get addressed/fixed sooner than later, > because what we have right now is reproducible breakage. :-) >=20 > > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > > > svn up /usr/ports > > > cd /usr/ports/whatever/p5-whatever > > > make install > > > pkg_delete p5-whatever > >=20 > > As I know we are never supported mixing of ports and packages. > > If you initially installed something from package and decide to use > > ports in this case better to rebuild all or stay with packages. >=20 > And here is where you are sadly mistaken. While I cannot find any sort > of official statement on the "mixing of the two", the fact of the matter > is (and possibly you did not know this -- I'm not sure) that packages > are built **from** ports ("make package" does the magic). This is > confirmed as well: >=20 > http://www.freebsd.org/ports/index.html > http://www.freebsd.org/doc/en/articles/linux-users/software.html >=20 > Please be aware when I say "package" I am talking about the .tbz balls > utilised by the base system's pkg_* tools (not pkg(8)) and used by the > OS installer and so on. For pkg(8) I believe poudriere is used to make > the packages. I don't use/can't speak about pkg(8) et al. Wrong and totally wrong, the way the ports tree works with pkg(8) is exactl= y the same way it works with pkg_install (make package does the same). poudriere is just some script to make sure everything is done in the right order, cleanly and works transparently with both pkg(8) and pkg_install. >=20 > For both pkg_* tools and ports, both use the same default base path > (/usr/local), **and** both register their bits in /var/db/pkg. Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the packa= ge tool to register a package may that be pkg_install or pkg(8) this tool will register the package where ever it seems suitable to itself meaning /var/db= /pkg in the case of both pkg(8) and pkg_install. >=20 > Package installation does not utilise any part of the ports/Mk/* > framework, but that isn't anything new -- it's been like that since at > least the 2.2.x days, possibly earlier. >=20 > So in summary, when making changes to ports/Mk/*, you really have to > think about the combination of the two, and make sure you don't break > anything when changing key pieces of those framework bits. That is exactly what has been done in the case of the change. >=20 > > > What I'd like to know: > > > > > > - Why the major.minor.patchlevel --> major.minor path change in the > > > first place. I have never, ever seen this done anywhere on any *IX > > > system I've used. Where's the justification? Was this discussed on > > > some perl mailing list somewhere as a "new and better way"? It's > > > essentially saying "x.y.z is always going to be compatible with x.y.z= +1" > > > which is not true (particularly with XS, as I understand it). Where > > > was this discussed publicly? > >=20 > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D26605+0+archive/2013/fre= ebsd-perl/20130609.freebsd-perl > >=20 > > I don't want to start yet another bikeshed here. Maybe link above will > > make some things more clear to you. >=20 > Thanks -- I wasn't aware of the freebsd-perl mailing list. >=20 > I just finished reading the entire thread. The justification seems to > be "because Fedora and Debian do it" (that's the best I can find). > Okay, fine/great/whatever -- I guess that's a form of justification, > just not one I was hoping for. I won't dwell on this at this point -- I > got the answer I was looking for. No the justification is that we use to have a perl-after-upgrade script to workaround the fact that we used major.minor.patchlevel my bypassing the pa= ckage tool to modify directly the content of the package database and more some f= iles on the file system each time a new perl update comes (like perl 5.12.2 -> 5.12.4) without this script being run every single minor update of perl was requiring manual intervention to fix up all the installed packages whereever they came from ports or package etc. The reference concerning Fedora/Debian was just when some asked if we were = doing something exotic to say no this is a "normal way" of doing things, look oth= ers do and the perl build system is extecting use to do that. >=20 > I see no actual harm in moving to major.minor, but the issue here is > that backwards compatibility in Mk/bsd.perl.mk for existing perl > installations. >=20 > Many people, for example, do not want to build X.org from source -- so > they pkg_add -r X, then build other bits/pieces related to X from > ports/source. Even more people do this for OpenOffice/LibreOffice or > whatever it's called today ( :-) ). >=20 > This "combination" needs to be supported. I know it hurts to have to > retain backwards compatibility, but it's necessary given how all of this > was designed. This has never been supported neither been unsupported, this commit doesn't changed anything here. >=20 > Such backwards compatibility could be removed, as I said, once > sufficient time has passed, particularly once the FreeBSD versions > shipping with a ports tree snapshot with perl versions older than those > in r320679 have been EOL'd. After that you could remove the framework > and cite EOL on such support. This is normal too -- for example on > occasion FreeBSD [67].x people show up on -ports and complain that > something won't build/some part of the Mk/* framework is broken for > them, and EOL is the proper response to that. Such compatibility hasn't been removed but improved with this patch: old behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1 then the perl path was changed and all compatibility was broken. new behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1: nothing to do >=20 > I know this probably won't hold any ground because I'm not one any > longer, but I was a FreeBSD ports committer myself some years ago (~5), > so please don't think that I'm just flying off the handle without some > existing familiarity with things. >=20 > If there is truly going to be a "split" between ports and packages > in this way, then someone needs to start doing SVN tagging/branches > for major changes like this. This has never been the matter of the patch and noone said that their will = be a split like this in the futur. regards, Bapt --qxfKREH7IwbezJ+T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHKjPMACgkQ8kTtMUmk6EwRSQCfVVxBB216SMXY+JZ4IBUdE7CW 38YAn2+y64X90lKtmpUZjlz8zVCyilss =w2Y1 -----END PGP SIGNATURE----- --qxfKREH7IwbezJ+T-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 07:15:55 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 48F7A85B; Wed, 26 Jun 2013 07:15:55 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id E35D5125F; Wed, 26 Jun 2013 07:15:54 +0000 (UTC) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id ACDCCA80CA; Wed, 26 Jun 2013 09:15:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3k+dCIupgo6m; Wed, 26 Jun 2013 09:15:42 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1C504A80BE; Wed, 26 Jun 2013 09:15:41 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id B04D773A1C; Wed, 26 Jun 2013 00:15:37 -0700 (PDT) Date: Wed, 26 Jun 2013 00:15:37 -0700 From: Jeremy Chadwick To: Baptiste Daroussin Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626071537.GA69414@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> <20130626064051.GG93612@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626064051.GG93612@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, freebsd-ports@freebsd.org, Andrej Zverev X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 07:15:55 -0000 On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: > On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: > > On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: > > > Hello, and first please accept my apologies for this situation. > > > > Understood, I just hope this can get addressed/fixed sooner than later, > > because what we have right now is reproducible breakage. :-) > > > > > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > > > > svn up /usr/ports > > > > cd /usr/ports/whatever/p5-whatever > > > > make install > > > > pkg_delete p5-whatever > > > > > > As I know we are never supported mixing of ports and packages. > > > If you initially installed something from package and decide to use > > > ports in this case better to rebuild all or stay with packages. > > > > And here is where you are sadly mistaken. While I cannot find any sort > > of official statement on the "mixing of the two", the fact of the matter > > is (and possibly you did not know this -- I'm not sure) that packages > > are built **from** ports ("make package" does the magic). This is > > confirmed as well: > > > > http://www.freebsd.org/ports/index.html > > http://www.freebsd.org/doc/en/articles/linux-users/software.html > > > > Please be aware when I say "package" I am talking about the .tbz balls > > utilised by the base system's pkg_* tools (not pkg(8)) and used by the > > OS installer and so on. For pkg(8) I believe poudriere is used to make > > the packages. I don't use/can't speak about pkg(8) et al. > > Wrong and totally wrong, the way the ports tree works with pkg(8) is exactly the > same way it works with pkg_install (make package does the same). > > poudriere is just some script to make sure everything is done in the right > order, cleanly and works transparently with both pkg(8) and pkg_install. Thanks for the clarification and the education on this point -- like I said, I have no experience with pkg(8) and its kin. > > For both pkg_* tools and ports, both use the same default base path > > (/usr/local), **and** both register their bits in /var/db/pkg. > > Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the package > tool to register a package may that be pkg_install or pkg(8) this tool will > register the package where ever it seems suitable to itself meaning /var/db/pkg > in the case of both pkg(8) and pkg_install. Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look for it throughout the entire file and look at how/where it's used. It's used *heavily* throughout dependency checking and actual installation (think "Registering installation of ..." messages and what happens under the hood, if I remember right -- otherwise you have a port installed that you cannot pkg_delete). > > Package installation does not utilise any part of the ports/Mk/* > > framework, but that isn't anything new -- it's been like that since at > > least the 2.2.x days, possibly earlier. > > > > So in summary, when making changes to ports/Mk/*, you really have to > > think about the combination of the two, and make sure you don't break > > anything when changing key pieces of those framework bits. > > That is exactly what has been done in the case of the change. But only when looking forward, not when looking at existing installations or new installations. I will repeat my instructions for how to reproduce the problem: pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what happens -- it breaks, and that breakage results in leftover shit in LOCALBASE. > > > > What I'd like to know: > > > > > > > > - Why the major.minor.patchlevel --> major.minor path change in the > > > > first place. I have never, ever seen this done anywhere on any *IX > > > > system I've used. Where's the justification? Was this discussed on > > > > some perl mailing list somewhere as a "new and better way"? It's > > > > essentially saying "x.y.z is always going to be compatible with x.y.z+1" > > > > which is not true (particularly with XS, as I understand it). Where > > > > was this discussed publicly? > > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl > > > > > > I don't want to start yet another bikeshed here. Maybe link above will > > > make some things more clear to you. > > > > Thanks -- I wasn't aware of the freebsd-perl mailing list. > > > > I just finished reading the entire thread. The justification seems to > > be "because Fedora and Debian do it" (that's the best I can find). > > Okay, fine/great/whatever -- I guess that's a form of justification, > > just not one I was hoping for. I won't dwell on this at this point -- I > > got the answer I was looking for. > > No the justification is that we use to have a perl-after-upgrade script to > workaround the fact that we used major.minor.patchlevel my bypassing the package > tool to modify directly the content of the package database and more some files > on the file system each time a new perl update comes (like perl 5.12.2 -> > 5.12.4) without this script being run every single minor update of perl was > requiring manual intervention to fix up all the installed packages whereever > they came from ports or package etc. That sounds like a mess, and I agree getting rid of that sounds great. I wasn't aware of that piece. But my stand on the breakage due to the backwards compatibility shims not being there stands. > The reference concerning Fedora/Debian was just when some asked if we were doing > something exotic to say no this is a "normal way" of doing things, look others > do and the perl build system is extecting use to do that. On the Solaris systems I use to administrate, I remember the paths containing major.minor.patchlevel. I doubt I'll find anything out about this in any of the perl documentation online though. > > I see no actual harm in moving to major.minor, but the issue here is > > that backwards compatibility in Mk/bsd.perl.mk for existing perl > > installations. > > > > Many people, for example, do not want to build X.org from source -- so > > they pkg_add -r X, then build other bits/pieces related to X from > > ports/source. Even more people do this for OpenOffice/LibreOffice or > > whatever it's called today ( :-) ). > > > > This "combination" needs to be supported. I know it hurts to have to > > retain backwards compatibility, but it's necessary given how all of this > > was designed. > > This has never been supported neither been unsupported, this commit doesn't > changed anything here. See above, re: what the commit has broken. > > Such backwards compatibility could be removed, as I said, once > > sufficient time has passed, particularly once the FreeBSD versions > > shipping with a ports tree snapshot with perl versions older than those > > in r320679 have been EOL'd. After that you could remove the framework > > and cite EOL on such support. This is normal too -- for example on > > occasion FreeBSD [67].x people show up on -ports and complain that > > something won't build/some part of the Mk/* framework is broken for > > them, and EOL is the proper response to that. > > Such compatibility hasn't been removed but improved with this patch: > old behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1 then the perl path was > changed and all compatibility was broken. > new behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1: nothing to do See above, re: only looking forward, not looking at existing support and what happens if someone does what I said. > > I know this probably won't hold any ground because I'm not one any > > longer, but I was a FreeBSD ports committer myself some years ago (~5), > > so please don't think that I'm just flying off the handle without some > > existing familiarity with things. > > > > If there is truly going to be a "split" between ports and packages > > in this way, then someone needs to start doing SVN tagging/branches > > for major changes like this. > > This has never been the matter of the patch and noone said that their will be a > split like this in the futur. Please correct me if I'm wrong here -- and god do I hope I am -- but the short version sounds to me like you're saying "nothing is wrong with the commit, nothing is broken, there is no problem, what are you complaining about?" I want to make sure I understand if that's what you're saying before I react past this point. But I would urge you to go do what I said, re: those 5 commands, and watch the breakage for yourself. Of course, I guess the alternate "solution" would be to have whoever maintains the official package sites (not for pkg, but pkg_*) update all the packages in Latest/ so that they refer to the new path convention... -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 07:55:09 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45F3E6B7 for ; Wed, 26 Jun 2013 07:55:09 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from relay.andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with ESMTP id 843EA1491 for ; Wed, 26 Jun 2013 07:55:08 +0000 (UTC) Received: (qmail 36930 invoked from network); 26 Jun 2013 07:55:07 -0000 Received: from alex.andxor.it (a.premoli@andxor.it@192.168.2.30) by relay.andxor.it with ESMTPSA; 26 Jun 2013 07:55:07 -0000 Message-ID: <51CA9E5B.4010909@FreeBSD.org> Date: Wed, 26 Jun 2013 09:55:07 +0200 From: Alex Dupre User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: Garrett Wollman , hackers@freebsd.org, ports@freebsd.org Subject: Re: rc.d scripts to control multiple instances of the same daemon? References: <20937.62239.626943.350086@hergotha.csail.mit.edu> In-Reply-To: <20937.62239.626943.350086@hergotha.csail.mit.edu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 07:55:09 -0000 Garrett Wollman ha scritto: > I've looked around for examples of good practice to emulate, and > haven't found much. The closest to what I want looks to be > vboxheadless, but I'm uncomfortable with the amount of mechanism from > rc.subr that it needs to reimplement. Are there any better examples? Basically there are two types of implementation with different pro/cons: profiles and symlinks. vboxheadless is in the first category, tomcat7 in the second one: http://svnweb.freebsd.org/ports/head/www/tomcat7/files/tomcat7.in?revision=307489&view=markup -- Alex Dupre From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 09:00:43 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92EF615B; Wed, 26 Jun 2013 09:00:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 56A56188D; Wed, 26 Jun 2013 09:00:43 +0000 (UTC) Received: from spaceball.andric.com (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B19BF5C43; Wed, 26 Jun 2013 11:00:38 +0200 (CEST) Message-ID: <51CAADB8.7090603@FreeBSD.org> Date: Wed, 26 Jun 2013 11:00:40 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Michael Gmelin Subject: Re: Are ports supposed to build and run on 10-CURRENT? References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> In-Reply-To: <20130626015508.426ab5b9@bsd64.grem.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Chisnall , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:00:43 -0000 On 2013-06-26 01:55, Michael Gmelin wrote: ... > The problem is that static initialization happens in the expected > order (same translation unit), but termination does *not* happen in the > reverse order of initialization, which - according to the C++ standard > section 3.6.3 should be guaranteed: > > "If the completion of the constructor or dynamic initialization of an > object with static storage duration is sequenced before that of > another, the completion of the destructor of the second is sequenced > before the initiation of the destructor of the first." > > The following conditions have to be met in order to show the problem: > > 1. Two static objects defined in the translation unit containing main > 2. Definition of one of the underlying objects is in a separate > source which is used to build a shared library > 3. Both, the translation unit containing main an the one forming the > shared library are compiled using -fPIC (or -fpic). Strange, if you compile the main program without -fPIC, the testcase works correctly. Normally, there should never be a need to compile a normal executable with -fPIC, but it should not break anything either. I am not sure what causes this, but I will investigate. For now, the workaround is to compile only shared objects with -fPIC. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 10:03:27 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 967A81FB for ; Wed, 26 Jun 2013 10:03:27 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org (unknown [IPv6:2001:1900:2254:206a::50:123]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0F31B67 for ; Wed, 26 Jun 2013 10:03:27 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.7/8.14.7) with ESMTP id r5QA3RlD099118 for ; Wed, 26 Jun 2013 10:03:27 GMT (envelope-from portscout@portscout.freebsd.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.7/8.14.6/Submit) id r5QA3Rdi099115; Wed, 26 Jun 2013 10:03:27 GMT (envelope-from portscout) Message-Id: <201306261003.r5QA3Rdi099115@portscout.freebsd.org> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 26 Jun 2013 10:03:27 +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.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:03:27 -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 ------------------------------------------------+-----------------+------------ print/py-fonttools | 2.3 | 2.4 ------------------------------------------------+-----------------+------------ www/xpi-pentadactyl | 20130407 | 20130626 ------------------------------------------------+-----------------+------------ x11-toolkits/sakura | 2.4.2 | 3.1.0 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portscout@FreeBSD.org Thanks. From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 10:23:25 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42051668; Wed, 26 Jun 2013 10:23:25 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3841C49; Wed, 26 Jun 2013 10:23:23 +0000 (UTC) Received: from mfilter4-d.gandi.net (mfilter4-d.gandi.net [217.70.178.134]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5B67EA80D9; Wed, 26 Jun 2013 12:23:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter4-d.gandi.net (mfilter4-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 2ONrTauwaD5E; Wed, 26 Jun 2013 12:23:09 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 95D23A80E9; Wed, 26 Jun 2013 12:23:08 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A268373A1C; Wed, 26 Jun 2013 03:23:06 -0700 (PDT) Date: Wed, 26 Jun 2013 03:23:06 -0700 From: Jeremy Chadwick To: Baptiste Daroussin Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626102306.GA71709@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> <20130626064051.GG93612@ithaqua.etoilebsd.net> <20130626071537.GA69414@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626071537.GA69414@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, freebsd-ports@freebsd.org, Andrej Zverev X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:23:25 -0000 On Wed, Jun 26, 2013 at 12:15:37AM -0700, Jeremy Chadwick wrote: > On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: > > On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: > > > On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: > > > > Hello, and first please accept my apologies for this situation. > > > > > > Understood, I just hope this can get addressed/fixed sooner than later, > > > because what we have right now is reproducible breakage. :-) > > > > > > > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > > > > > svn up /usr/ports > > > > > cd /usr/ports/whatever/p5-whatever > > > > > make install > > > > > pkg_delete p5-whatever > > > > > > > > As I know we are never supported mixing of ports and packages. > > > > If you initially installed something from package and decide to use > > > > ports in this case better to rebuild all or stay with packages. > > > > > > And here is where you are sadly mistaken. While I cannot find any sort > > > of official statement on the "mixing of the two", the fact of the matter > > > is (and possibly you did not know this -- I'm not sure) that packages > > > are built **from** ports ("make package" does the magic). This is > > > confirmed as well: > > > > > > http://www.freebsd.org/ports/index.html > > > http://www.freebsd.org/doc/en/articles/linux-users/software.html > > > > > > Please be aware when I say "package" I am talking about the .tbz balls > > > utilised by the base system's pkg_* tools (not pkg(8)) and used by the > > > OS installer and so on. For pkg(8) I believe poudriere is used to make > > > the packages. I don't use/can't speak about pkg(8) et al. > > > > Wrong and totally wrong, the way the ports tree works with pkg(8) is exactly the > > same way it works with pkg_install (make package does the same). > > > > poudriere is just some script to make sure everything is done in the right > > order, cleanly and works transparently with both pkg(8) and pkg_install. > > Thanks for the clarification and the education on this point -- like I > said, I have no experience with pkg(8) and its kin. > > > > For both pkg_* tools and ports, both use the same default base path > > > (/usr/local), **and** both register their bits in /var/db/pkg. > > > > Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the package > > tool to register a package may that be pkg_install or pkg(8) this tool will > > register the package where ever it seems suitable to itself meaning /var/db/pkg > > in the case of both pkg(8) and pkg_install. > > Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look > for it throughout the entire file and look at how/where it's used. It's > used *heavily* throughout dependency checking and actual installation > (think "Registering installation of ..." messages and what happens under > the hood, if I remember right -- otherwise you have a port installed > that you cannot pkg_delete). > > > > Package installation does not utilise any part of the ports/Mk/* > > > framework, but that isn't anything new -- it's been like that since at > > > least the 2.2.x days, possibly earlier. > > > > > > So in summary, when making changes to ports/Mk/*, you really have to > > > think about the combination of the two, and make sure you don't break > > > anything when changing key pieces of those framework bits. > > > > That is exactly what has been done in the case of the change. > > But only when looking forward, not when looking at existing > installations or new installations. I will repeat my instructions for > how to reproduce the problem: > > pkg_add -r perl (this will install perl-5.14.2_3.tbz) > svn up /usr/ports > cd /usr/ports/whatever/p5-whatever > make install > pkg_delete p5-whatever > > Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what > happens -- it breaks, and that breakage results in leftover shit in > LOCALBASE. > > > > > > What I'd like to know: > > > > > > > > > > - Why the major.minor.patchlevel --> major.minor path change in the > > > > > first place. I have never, ever seen this done anywhere on any *IX > > > > > system I've used. Where's the justification? Was this discussed on > > > > > some perl mailing list somewhere as a "new and better way"? It's > > > > > essentially saying "x.y.z is always going to be compatible with x.y.z+1" > > > > > which is not true (particularly with XS, as I understand it). Where > > > > > was this discussed publicly? > > > > > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl > > > > > > > > I don't want to start yet another bikeshed here. Maybe link above will > > > > make some things more clear to you. > > > > > > Thanks -- I wasn't aware of the freebsd-perl mailing list. > > > > > > I just finished reading the entire thread. The justification seems to > > > be "because Fedora and Debian do it" (that's the best I can find). > > > Okay, fine/great/whatever -- I guess that's a form of justification, > > > just not one I was hoping for. I won't dwell on this at this point -- I > > > got the answer I was looking for. > > > > No the justification is that we use to have a perl-after-upgrade script to > > workaround the fact that we used major.minor.patchlevel my bypassing the package > > tool to modify directly the content of the package database and more some files > > on the file system each time a new perl update comes (like perl 5.12.2 -> > > 5.12.4) without this script being run every single minor update of perl was > > requiring manual intervention to fix up all the installed packages whereever > > they came from ports or package etc. > > That sounds like a mess, and I agree getting rid of that sounds great. > I wasn't aware of that piece. But my stand on the breakage due to the > backwards compatibility shims not being there stands. > > > The reference concerning Fedora/Debian was just when some asked if we were doing > > something exotic to say no this is a "normal way" of doing things, look others > > do and the perl build system is extecting use to do that. > > On the Solaris systems I use to administrate, I remember the paths > containing major.minor.patchlevel. I doubt I'll find anything out about > this in any of the perl documentation online though. > > > > I see no actual harm in moving to major.minor, but the issue here is > > > that backwards compatibility in Mk/bsd.perl.mk for existing perl > > > installations. > > > > > > Many people, for example, do not want to build X.org from source -- so > > > they pkg_add -r X, then build other bits/pieces related to X from > > > ports/source. Even more people do this for OpenOffice/LibreOffice or > > > whatever it's called today ( :-) ). > > > > > > This "combination" needs to be supported. I know it hurts to have to > > > retain backwards compatibility, but it's necessary given how all of this > > > was designed. > > > > This has never been supported neither been unsupported, this commit doesn't > > changed anything here. > > See above, re: what the commit has broken. > > > > Such backwards compatibility could be removed, as I said, once > > > sufficient time has passed, particularly once the FreeBSD versions > > > shipping with a ports tree snapshot with perl versions older than those > > > in r320679 have been EOL'd. After that you could remove the framework > > > and cite EOL on such support. This is normal too -- for example on > > > occasion FreeBSD [67].x people show up on -ports and complain that > > > something won't build/some part of the Mk/* framework is broken for > > > them, and EOL is the proper response to that. > > > > Such compatibility hasn't been removed but improved with this patch: > > old behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1 then the perl path was > > changed and all compatibility was broken. > > new behaviour update from perl-X.Y.Z -> perl-X.Y.Z+1: nothing to do > > See above, re: only looking forward, not looking at existing support and > what happens if someone does what I said. > > > > I know this probably won't hold any ground because I'm not one any > > > longer, but I was a FreeBSD ports committer myself some years ago (~5), > > > so please don't think that I'm just flying off the handle without some > > > existing familiarity with things. > > > > > > If there is truly going to be a "split" between ports and packages > > > in this way, then someone needs to start doing SVN tagging/branches > > > for major changes like this. > > > > This has never been the matter of the patch and noone said that their will be a > > split like this in the futur. > > Please correct me if I'm wrong here -- and god do I hope I am -- but the > short version sounds to me like you're saying "nothing is wrong with the > commit, nothing is broken, there is no problem, what are you complaining > about?" I want to make sure I understand if that's what you're saying > before I react past this point. But I would urge you to go do what I > said, re: those 5 commands, and watch the breakage for yourself. > > Of course, I guess the alternate "solution" would be to have whoever > maintains the official package sites (not for pkg, but pkg_*) update all > the packages in Latest/ so that they refer to the new path convention... And it just occurred to me: thanks to your tip about perl-after-upgrade, the below works. It should be crystal clear the methodology. I tested this on a bare 9.1-RELEASE system using devel/p5-Config-Record as a test subject (since it has no dependencies and builds fast), with both pkg_add -r perl (i.e. package with the old pathing scheme in place), and then alternately lang/perl5.14 from ports (at r320679). No more errors, no more cruft, no more issues. And like I said earlier: once all the FreeBSD releases get EOL'd and the packages which make use of the major.minor.patchlevel scheme are gone/nuked from orbit, this simple code can be removed. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | Index: bsd.perl.mk =================================================================== --- bsd.perl.mk (revision 321789) +++ bsd.perl.mk (working copy) @@ -50,7 +50,14 @@ Perl_Pre_Include= bsd.perl.mk PERL_Include_MAINTAINER= perl@FreeBSD.org PERL_VERSION?= 5.14.4 + +# Legacy support for old perl packages which use the deprecated +# (as of r320679) major.minor.patchlevel pathing scheme. +.if exists(${LOCALBASE}/bin/perl-after-upgrade) +PERL_VER?= ${PERL_VERSION} +.else PERL_VER?= ${PERL_VERSION:C/\.[0-9]+$//} +.endif .if !defined(PERL_LEVEL) && defined(PERL_VERSION) perl_major= ${PERL_VERSION:C|^([1-9]+).*|\1|} From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 11:31:53 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF6A4768 for ; Wed, 26 Jun 2013 11:31:53 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 21A481EF2 for ; Wed, 26 Jun 2013 11:31:52 +0000 (UTC) Received: (qmail 50809 invoked by uid 89); 26 Jun 2013 11:31:51 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 11:31:51 -0000 Date: Wed, 26 Jun 2013 13:31:49 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130626133149.4835f14a@bsd64.grem.de> In-Reply-To: <51CAADB8.7090603@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:31:54 -0000 On Wed, 26 Jun 2013 11:00:40 +0200 Dimitry Andric wrote: > On 2013-06-26 01:55, Michael Gmelin wrote: > ... > > The problem is that static initialization happens in the expected > > order (same translation unit), but termination does *not* happen in > > the reverse order of initialization, which - according to the C++ > > standard section 3.6.3 should be guaranteed: > > > > "If the completion of the constructor or dynamic initialization of > > an object with static storage duration is sequenced before that of > > another, the completion of the destructor of the second is sequenced > > before the initiation of the destructor of the first." > > > > The following conditions have to be met in order to show the > > problem: > > > > 1. Two static objects defined in the translation unit containing > > main 2. Definition of one of the underlying objects is in a separate > > source which is used to build a shared library > > 3. Both, the translation unit containing main an the one forming the > > shared library are compiled using -fPIC (or -fpic). > > Strange, if you compile the main program without -fPIC, the testcase > works correctly. Normally, there should never be a need to compile a > normal executable with -fPIC, but it should not break anything either. Yep, strange indeed - my test cases didn't use fPIC at first, so it took a while to figure it out. It's seems to be some sort of combined link/runtime problem, since the same executable built on 10 runs fine on 9.1-RELEASE when copied over. I tried replacing various system libraries with their versions from 9.1 in a jail to see if I could make it run on 10, but to no success. By the way, the same code built on 9.1 using clang 3.1 or clang 3.3 runs fine on 10 as well, so the only case that does NOT work is build on 10 and run on 10 using clang. Also, when I link copies of main.o and libout.so that have been built on 10 on 9.1 using clang33 the problem doesn't happen as well. So it appears that the problem happens when linking the executable when one of the objects is position independent and then only surfaces on 10. Looking at the binaries using elfdump it's obvious that there are quite some differences in the generated code of example between the versions, mostly offsets and sizes, but a few things are actually new in the version linked on 10: entry: 29 st_name: crt_noinit_tag st_value: 0x400230 st_size: 24 st_info: STT_OBJECT STB_LOCAL st_shndx: 2 entry: 30 st_name: finalizer st_value: 0x4007f0 st_size: 85 st_info: STT_FUNC STB_LOCAL st_shndx: 13 ... entry: 51 st_name: __preinit_array_start st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 entry: 52 st_name: __fini_array_end st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 ... entry: 55 st_name: __preinit_array_end st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 entry: 56 st_name: __fini_array_start st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 entry: 57 st_name: __init_array_end st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 entry: 58 st_name: __init_array_start st_value: 0x600c94 st_size: 0 st_info: STT_NOTYPE STB_LOCAL st_shndx: 18 Based on this I would *speculate* that the problem first appeared when r232832 was committed [1] and there's something wrong with the order of how fini_array is filled b the linker (or traversed later). Unfortunately I don't even have an instance/VM of 10 ready in which I could experiment hacking that deep into the system and I don't really have the expertise to do this in a efficiently anyway, so at this point I'll have to leave it up to you. > > I am not sure what causes this, but I will investigate. For now, the > workaround is to compile only shared objects with -fPIC. For many ports this is not a real option I'm afraid (simply too much work to factor out the use of CXXFLAGS in various places). I assume it's best to wait for a solution of the underlying problem. > > -Dimitry [1] http://svnweb.freebsd.org/base?view=revision&revision=232832 -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 11:43:57 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F01BA20 for ; Wed, 26 Jun 2013 11:43:57 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3D01F84 for ; Wed, 26 Jun 2013 11:43:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5QBhtsa003303 for ; Wed, 26 Jun 2013 11:43:55 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5QBht8i003302 for ports@freebsd.org; Wed, 26 Jun 2013 11:43:55 GMT (envelope-from bdrewery) Received: (qmail 72613 invoked from network); 26 Jun 2013 06:43:53 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 26 Jun 2013 06:43:53 -0500 Message-ID: <51CAD3EE.6090708@FreeBSD.org> Date: Wed, 26 Jun 2013 06:43:42 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Murphy Subject: Re: pkg & portmaster References: <51CA485C.1040505@gsoft.com.au> In-Reply-To: <51CA485C.1040505@gsoft.com.au> X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IRLPTFPOORUWMNSLXSGH" Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:43:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IRLPTFPOORUWMNSLXSGH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/25/2013 8:48 PM, Adrian Murphy wrote: > Hi, >=20 > I noticed portmaster developed a problem after a recent update to > ports-mgmt/pkg where the following appears in the output: >=20 > [: false: bad number >=20 > I traced it to lines in portmaster where np_orphan is set: >=20 > np_orphan=3D`pkg query "%a" $upg_port` >=20 > It appears 'pkg query "%a"' used to return 0 or 1 and now it returns > 'true' or 'false'. >=20 > The 'pkg help query' text says "%a Returns 1 if the matched package is= > an orphan package and can be pkg-autoremove(1)'d, 0 otherwise" >=20 >=20 > I further ran into trouble with ports-mgmt/pkg-devel today where > portmaster calls: > pkg info pkg >=20 > This fails with ports-mgmt/pkg-devel unless the line is changed to: > pkg info pkg-devel >=20 > This stopped portmaster from working. >=20 > I reverted to using ports-mgmt/pkg to get around this. >=20 > Regards, Adrian This is an unintended regression in pkg-1.1. We are fixing it there. Thanks for your report. --=20 Regards, Bryan Drewery ------enig2IRLPTFPOORUWMNSLXSGH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRytPzAAoJEG54KsA8mwz5clkP/RI9uqg5X0N+5oDtIbuOhnD9 6HbIH3UoCFE0AzjPO/3R2LedsTYlHMWhd3utrDpdr4xN5JeQlKMfJ+2Sv/YAylYd IoyG6w32u+1r4leL73ejVvdbg/mbuDz+i0UX2d36NHEIPlzWn9hUZ8H8gpaA+ElE VVWoqbs7TbXcj7GJecSJnoyYzPLEss7lpgeSnHrdS8tZAenDgLAjgihQw1THjY76 xl2qal9NlFS+tyz519QoC59UdliNZhkY0Zi3rfdpuYuU5mPpnX63Vi2Sy6+Vlxem XVXnZhjZlLUswooFSvllBNruEuMCsyDNYKJTNdwzWsvhSv2y6LH5KeV01V85xv5Q dH7TDwc2HkYplW4ngMd+JoN3N8yaSvDbrvw073nP8G4mHYJb9qic82jMNsTp1tLa I5+orerPOc7YHyayRcG/bXkmcy04lum5cvzdy5/oag8BT9eE0vvezPZ4AdNyXpzm gSYCMVaoQbqSKCuBFe08okORCaVpfNyxRqFJ6kQfqta185RGlTQhyYtUJwBuN81k qjYdmjACM4AHO/AI8ImZ2mgQixdu/7IZ6LnS9GuhnzZ66I2EjgkdMG2gS15KTz+2 medxlq4dV2juK3ynyVHLjUV9O7HtjltWFQ8Zk++99nqHC7FPf22uAWxoEXzWybWW bQpDQK6xknhBalFg7hsA =ynX/ -----END PGP SIGNATURE----- ------enig2IRLPTFPOORUWMNSLXSGH-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 12:11:25 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 496F371C; Wed, 26 Jun 2013 12:11:25 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id A7EAF11F5; Wed, 26 Jun 2013 12:11:24 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UroZ8-0002h4-Qh; Wed, 26 Jun 2013 19:11:14 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r5QCCkX9028206; Wed, 26 Jun 2013 19:12:46 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r5QCCfmv028170; Wed, 26 Jun 2013 19:12:41 +0700 (NOVT) (envelope-from danfe) Date: Wed, 26 Jun 2013 19:12:41 +0700 From: Alexey Dokuchaev To: Baptiste Daroussin Subject: Re: Proposal: further OptionsNG improvements Message-ID: <20130626121241.GA23956@regency.nsu.ru> References: <20130618160037.GA26677@regency.nsu.ru> <20130618162708.GA34175@regency.nsu.ru> <20130621080451.GL23721@ithaqua.etoilebsd.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <20130621080451.GL23721@ithaqua.etoilebsd.net> User-Agent: Mutt/1.4.2.1i Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:11:25 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 21, 2013 at 10:04:51AM +0200, Baptiste Daroussin wrote: > Sorry it took time for me to reply, after we last talk about this, I > thought a lot about this, and while in principe I do like the idea, I have > a couple of concerns: > > 1: this reduces lots of flexibility we now have with the new options > framework, well at the least the patch should make sure it doesn't reduce it > for instance, it should work properly with: > OPTIONS_EXCLUDE and OPTIONS_SLAVE. My current approach is to handle new "extended" syntax without interfering with OptionsNG, and since OPTIONS_EXCLUDE or OPTIONS_SLAVE would not contain any of that new :on or /${arch} stuff, I hope they would just work as before. ;-) > if should be able to handle properly the following situation: > OPTIONS_DEFINE= DOCS X11 > OPTIONS_DEFINE_i386= MYSQL PGSQL > OPTIONS_DEFINE_amd64= MYSQL PGSQL > OPTIONS_DEFAULT_i386= MYSQL > OPTIONS_DEFAULT_amd64= PGSQL > OPTIONS_EXCLUDE_powerpc= X11 Yes, it does handle it; in fact, hanlding this sort of several-lines ugly constructs is one the pripary reasons why I want something more elegant. I've cooked something up just now, take a look at the attached diff. I've only barely tested it, but it seems to work for a few of my hand-crafted configurations. It also handles known options groups (single/multi/etc.), tested on www/firefox. With the new syntax, the example above would simply become: OPTIONS= DOCS MYSQL/i386:on,amd64 PGSQL/i386,amd64:on X11!powerpc Verified (old vs. new) by "make showconfig ARCH=... | md5". Feedback welcome, as I might have missed some edge cases or a bug or two. > This is things I haven't been able to imagine in a concise/understandable > syntax like the one you are proposing, if we are able to do it then fine > for me :) > > 2: I'm concern about the parsing performance, not that I have tested > anything, but it just looks like it would be less performant for make(1) > to parse properly all this, this should be measured to at least know the > impact in the package building clusters and index building boxes once > everything will be converted. True, although I don't have idea how to measure it without converting quite a number of ports first. Perhaps an automated tool would help. ./danfe --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="newsyntax.diff" Index: bsd.options.mk =================================================================== --- bsd.options.mk (revision 321792) +++ bsd.options.mk (working copy) @@ -94,6 +94,43 @@ PORT_OPTIONS+= IPV6 +### Parse new OPTIONS knob (extended syntax) +.for opt in ${OPTIONS:N*/*:N*!*} +OPTIONS_DEFINE+= ${opt:C^:.*^^} +OPTIONS_DEFAULT+= ${opt:M*\:on:S^:on^^} +.endfor + +# Process known option groups +.for otype in SINGLE RADIO MULTI GROUP +. for m in ${OPTIONS_${otype}} +_${otype}_default:= ${OPTIONS_${otype}_${m}:M*\:on:S^:on^^} +OPTIONS_DEFAULT+= ${_${otype}_default} +OPTIONS_${otype}_${m}:= ${OPTIONS_${otype}_${m}:C^:.*^^} +. endfor +.endfor + +# Process architecture-specific options +.for opt in ${OPTIONS:M*/*} +. for arch in ${opt:C^.*/^^:S^,^ ^g} +. for defarch in OPTIONS_DEFINE_${arch:C^:.*^^} +${defarch}+= ${opt:C^/.*^^} +. endfor +. for defarch in OPTIONS_DEFAULT_${arch:M*\:on:S^:on^^} +${defarch}+= ${opt:C^/.*^^} +. endfor +. endfor +.endfor + +# Process options unsupported on some architectures +.for opt in ${OPTIONS:M*!*} +OPTIONS_DEFINE+= ${opt:C^[:!].*^^} +OPTIONS_DEFAULT+= ${opt:M*\:on!*:C^:.*^^} +. for arch in ${opt:C^.*!^^:S^,^ ^g} +OPTIONS_EXCLUDE_${arch}+= ${opt:C^[:!].*^^} +. endfor +.endfor +### + # Add per arch options .for opt in ${OPTIONS_DEFINE_${ARCH}} .if empty(OPTIONS_DEFINE:M${opt}) @@ -130,7 +167,7 @@ ALL_OPTIONS:= ${OPTIONS_DEFINE:O:u} OPTIONS_DEFAULT:= ${OPTIONS_DEFAULT:O:u} -# complete list +# Complete list COMPLETE_OPTIONS_LIST= ${ALL_OPTIONS} .for otype in SINGLE RADIO MULTI GROUP . for m in ${OPTIONS_${otype}} --IS0zKkzwUGydFO0o-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 12:29:32 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DF73B32; Wed, 26 Jun 2013 12:29:32 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7C112D4; Wed, 26 Jun 2013 12:29:31 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1Uroqm-0003DE-Bu; Wed, 26 Jun 2013 19:29:28 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r5QCV0s8032923; Wed, 26 Jun 2013 19:31:00 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r5QCUtIg032890; Wed, 26 Jun 2013 19:30:55 +0700 (NOVT) (envelope-from danfe) Date: Wed, 26 Jun 2013 19:30:55 +0700 From: Alexey Dokuchaev To: Baptiste Daroussin Subject: Re: Proposal: further OptionsNG improvements Message-ID: <20130626123055.GA30841@regency.nsu.ru> References: <20130618160037.GA26677@regency.nsu.ru> <20130618162708.GA34175@regency.nsu.ru> <20130621080451.GL23721@ithaqua.etoilebsd.net> <20130626121241.GA23956@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626121241.GA23956@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:29:32 -0000 On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote: > I've cooked something up just now, take a look at the attached diff. I've > only barely tested it, but it seems to work for a few of my hand-crafted > configurations. It also handles known options groups (single/multi/etc.), > tested on www/firefox. One known limitation of option groups right now is that you cannot have per-arch or !arch stuff, only :on. It should not be hard to fix, but I need to think how to avoid code duplication. I miss $(call ...) of GNU make sometimes... ./danfe From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 12:43:41 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94049FFE for ; Wed, 26 Jun 2013 12:43:41 +0000 (UTC) (envelope-from lists@pingle.org) Received: from chloe.pingle.org (chloe.pingle.org [69.64.6.8]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB89139F for ; Wed, 26 Jun 2013 12:43:41 +0000 (UTC) Received: from chloe.pingle.org (unknown [127.0.0.1]) by chloe.pingle.org (Postfix) with ESMTP id 7C8B3450B1 for ; Wed, 26 Jun 2013 08:43:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at pingle.org Received: from chloe.pingle.org ([127.0.0.1]) by chloe.pingle.org (chloe.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R30aCDs8OxsV for ; Wed, 26 Jun 2013 08:43:40 -0400 (EDT) Received: from [192.168.20.31] (unknown [199.116.247.242]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by chloe.pingle.org (Postfix) with ESMTPSA id 127E045068 for ; Wed, 26 Jun 2013 08:43:40 -0400 (EDT) Message-ID: <51CAE1F8.5090502@pingle.org> Date: Wed, 26 Jun 2013 08:43:36 -0400 From: Jim Pingle User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) References: <20130626001406.GA63314@icarus.home.lan> <20130626061219.GA68398@icarus.home.lan> <20130626064051.GG93612@ithaqua.etoilebsd.net> In-Reply-To: <20130626064051.GG93612@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:43:41 -0000 On 6/26/2013 2:40 AM, Baptiste Daroussin wrote: > No the justification is that we use to have a perl-after-upgrade script to > workaround the fact that we used major.minor.patchlevel my bypassing the package > tool to modify directly the content of the package database and more some files > on the file system each time a new perl update comes (like perl 5.12.2 -> > 5.12.4) without this script being run every single minor update of perl was > requiring manual intervention to fix up all the installed packages whereever > they came from ports or package etc. For what it's worth, as a user, I would love to have seen perl-after-upgrade stick around just a little longer to move the files from major.minor.patchlevel to major.minor. Without it, it did require recompiling everything related to perl, or manually chasing down ports and forcing an update of anything that dropped files in major.minor.patchlevel, which is exactly what it was intended to help avoid. Maybe some industrious perl wizard could fix it and make a separate port for it for those of us who don't need pkgng (yet!) and still want to use it at least this one last time. There are probably various technical reasons why that wouldn't have made sense or have been possible, but it bit me yesterday on my desktop. I found myself really missing perl-after-upgrade, especially when portupgrade was telling me it wanted to rebuild 682 ports and I decided the manual way was faster (upgraded p5* and then manually tracked down stragglers in maj.min.pat) Some more expansion on the note in UPDATING at least other than stating it was removed might be nice to see. Maybe a link to the freebsd-perl mailing list thread with the discussion. I think the move was a good one overall, but the transition could be smoother. Jim From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 12:54:13 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C54CA28D; Wed, 26 Jun 2013 12:54:13 +0000 (UTC) (envelope-from erwin@FreeBSD.org) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) by mx1.freebsd.org (Postfix) with ESMTP id 99BDB15C1; Wed, 26 Jun 2013 12:54:13 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.7) with ESMTP id r5QCsDpx005542; Wed, 26 Jun 2013 12:54:13 GMT (envelope-from erwin@FreeBSD.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.7/8.14.5/Submit) id r5QCsBsf005499; Wed, 26 Jun 2013 12:54:11 GMT (envelope-from erwin@FreeBSD.org) Date: Wed, 26 Jun 2013 12:54:11 GMT Message-Id: <201306261254.r5QCsBsf005499@portsindexbuild.ysv.freebsd.org> X-Authentication-Warning: portsindexbuild.ysv.freebsd.org: indexbuild set sender to erwin@FreeBSD.org using -f From: erwin@FreeBSD.org To: erwin@FreeBSD.org Subject: Ports with a broken PKGORIGIN: devel/boost-all, mail/squirrelma... X-FreeBSD-Chkversion: PKGORIGIN Cc: office@FreeBSD.org, stb@lassitu.de, lambert@lambertfam.org, ports@FreeBSD.org, pakhom706@gmail.com, tabthorpe@FreeBSD.org, itetcu@FreeBSD.org, neil@darlow.co.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: erwin@FreeBSD.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:54:13 -0000 ** The following ports have an incorrect PKGORIGIN ** PKGORIGIN connects packaged or installed ports to the directory they originated from. This is essential for tools like pkg_version or portupgrade to work correctly. Wrong PKGORIGINs are often caused by a wrong order of CATEGORIES after a repocopy. Please fix any errors as soon as possible. The ports tree was updated at Wed Jun 26 2013 12:37:04 UTC. - *devel/boost-all* : /boost-all - *mail/squirrelmail-abook_import_export-plugin* : /squirrelmail-abook_import_export-plugin - *mail/squirrelmail-askuserinfo-plugin* : /squirrelmail-askuserinfo-plugin - *mail/squirrelmail-avelsieve-plugin* : /squirrelmail-avelsieve-plugin - *mail/squirrelmail-calendar_file_backend-plugin* : /squirrelmail-calendar_file_backend-plugin - *mail/squirrelmail-calendar_sql_backend-plugin* : /squirrelmail-calendar_sql_backend-plugin - *mail/squirrelmail-change_ldappass-plugin* : /squirrelmail-change_ldappass-plugin - *mail/squirrelmail-change_sqlpass-plugin* : /squirrelmail-change_sqlpass-plugin - *mail/squirrelmail-check_quota-plugin* : /squirrelmail-check_quota-plugin - *mail/squirrelmail-email_footer-plugin* : /squirrelmail-email_footer-plugin - *mail/squirrelmail-login_auth-plugin* : /squirrelmail-login_auth-plugin - *mail/squirrelmail-login_notes-plugin* : /squirrelmail-login_notes-plugin - *mail/squirrelmail-mark_read-plugin* : /squirrelmail-mark_read-plugin - *mail/squirrelmail-pupdate-plugin* : /squirrelmail-pupdate-plugin - *mail/squirrelmail-qmailadmin_login-plugin* : /squirrelmail-qmailadmin_login-plugin - *mail/squirrelmail-secure_login-plugin* : /squirrelmail-secure_login-plugin - *mail/squirrelmail-spam-buttons-plugin* : /squirrelmail-spam-buttons-plugin - *mail/squirrelmail-timeout_user-plugin* : /squirrelmail-timeout_user-plugin - *mail/squirrelmail-unsafe_image_rules-plugin* : /squirrelmail-unsafe_image_rules-plugin - *mail/squirrelmail-user_special_mailboxes-plugin* : /squirrelmail-user_special_mailboxes-plugin - *mail/squirrelmail-websearch-plugin* : /squirrelmail-websearch-plugin - *net-mgmt/zabbix2-agent* : /zabbix2-agent (master: net-mgmt/zabbix2-server) - *net-mgmt/zabbix2-frontend* : /zabbix2-frontend (master: net-mgmt/zabbix2-server) From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 13:02:02 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E40B553 for ; Wed, 26 Jun 2013 13:02:02 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 088F21631 for ; Wed, 26 Jun 2013 13:02:01 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g15so7569537eak.18 for ; Wed, 26 Jun 2013 06:02:01 -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=EYnOrgNyMV2gUQLG+oNSGKAHfs/XGx/rSQMC9iY80OQ=; b=f/XIjCWTg9nAQ075f6ZcOWoKXU1B5VWP/7yWoddMCfIMSa89gXBKy3CSrggqwq7cdu 4cXq00lhrga1vpEuuaUFoRw/t2GCzmJVXG2jmFBTVgHeyOYGsn/9MpnzzAoF1LQSPrtz 07O3tUusZuG7tyrWGHi+wFu2A4ohgbDTMBYB9BRLkbUGo+cbZgpLwyhNsEKTPB5n4o/4 KWmCU5AjUBlUYDmbEt42Y1iDL5JDm5u9Lek9PJE1z2TO49OOGOcjV9FA52K3oZj0ecuF lKnVZOGP4J/kWi1xjImPpaqDj69AoGaNUa1y/rRQWZ8sJ184XLM+t3IKwDG6hXFfIZs3 lMyQ== X-Received: by 10.15.63.204 with SMTP id m52mr4098727eex.59.1372251721216; Wed, 26 Jun 2013 06:02:01 -0700 (PDT) Received: from [192.168.50.107] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPSA id m1sm42886842eex.17.2013.06.26.06.01.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 06:02:00 -0700 (PDT) Message-ID: <51CAE646.6000200@gmail.com> Date: Wed, 26 Jun 2013 15:01:58 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Subject: dovecot2 fails to update in combination with pigeonhole-0.4.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:02:02 -0000 Hello all! I try to update my dovecot server. But the following error is printed. I use pkgng. # portmaster -d dovecot2 < snip> ===> Correct pkg-plist sequence to create group(s) and user(s) ===> Compressing manual pages for dovecot-2.2.4 ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib/dovecot ===> Installing ldconfig configuration file ===> Registering installation for dovecot-2.2.4 pkg-static: unknown keyword stopdaemon, ignoring @stopdaemon pkg-static: duplicate directory listing: /usr/local/share/doc/dovecot/, ignoring Installing dovecot-2.2.4...pkg-static: dovecot-2.2.4 conflicts with dovecot-pigeonhole-0.4.0 (installs files into the same place). Problematic file: /usr/local/share/d oc/dovecot/example-config/conf.d/20-managesieve.conf *** [fake-pkg] Error code 70 Stop in /usr/ports/mail/dovecot2. *** [install] Error code 1 Stop in /usr/ports/mail/dovecot2. ===>>> Installation of dovecot-2.2.4 (mail/dovecot2) failed ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> You can restart from the point of failure with this command line: portmaster mail/dovecot2 ===>>> Exiting System is FreeBSD 9.1-RELEASE-p2 Thanks all regards Johan Hendriks From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 17:37:57 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D476877; Wed, 26 Jun 2013 17:37:57 +0000 (UTC) (envelope-from qat@redports.org) Received: from qat.redports.org (qat.redports.org [96.47.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id 45A2D1189; Wed, 26 Jun 2013 17:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=redports.org; s=04012012; h=Sender:Message-Id:To:Subject:Reply-To:Date:To:Cc:From:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=LOvJZaHmWR8gxt7tthRqzmyQPTXhuAooyPZ99TbEPBI=; b=u/XCiIX8Rn6HNY3XI8+0hHYcMg8IVo1FwOMNKYgThHuxmMjZE1qxAlhT1oBQLt+DWMQePZHCE/sEEn5Chmimrs5c11WLIeGkvdtQPwIABJaz8P6ryLVNQ4LMFYSOpT6LidL4SH95N1wkmgGZk9T2lWWSHO4Kra1e4hQoa0xw+FU=; Received: from www by qat.redports.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UrtfI-000NYx-RD; Wed, 26 Jun 2013 17:37:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ports-QAT" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: mat@FreeBSD.org X-Trac-Project: redports Date: Wed, 26 Jun 2013 17:37:56 -0000 X-URL: https://qat.redports.org/ Subject: [QAT] r321799: 4x leftovers, 4x dud, 4x success To: mat@FreeBSD.org X-Trac-Build-URL: https://qat.redports.org/buildarchive/20130626165800-11105 X-Trac-Build-ID: 20130626165800-11105 Message-Id: Sender: World Wide Web Owner Cc: ports@FreeBSD.org, decke@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: qat@redports.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:37:57 -0000 Upgrade net-mgmt/netmagis-* ports to 2.2.0 PR: ports/180000 Submitted by: maintainer --------------------------------------------------------------------- Build ID: 20130626165800-11105 Job owner: mat@FreeBSD.org Buildtime: 39 minutes Enddate: Wed, 26 Jun 2013 17:36:56 GMT Revision: r321799 Repository: https://svnweb.freebsd.org/ports?view=revision&revision=321799 --------------------------------------------------------------------- Port: net-mgmt/netmagis-common 2.2.0_1 Buildgroup: 9.1-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155688/netmagis-common-2.2.0_1.log Buildgroup: 9.1-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155689/netmagis-common-2.2.0_1.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155690/netmagis-common-2.2.0_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155691/netmagis-common-2.2.0_1.log --------------------------------------------------------------------- Port: net-mgmt/netmagis-database 2.2.0_1 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155692/netmagis-database-2.2.0_1.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155693/netmagis-database-2.2.0_1.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155694/netmagis-database-2.2.0_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mat@FreeBSD.org/20130626165800-11105-155695/netmagis-database-2.2.0_1.log --------------------------------------------------------------------- Port: net-mgmt/netmagis-www 2.2.0_1 Buildgroup: 9.1-QAT/amd64 Buildstatus: DUD Buildgroup: 9.1-QAT/i386 Buildstatus: DUD Buildgroup: 8.4-QAT/amd64 Buildstatus: DUD Buildgroup: 8.4-QAT/i386 Buildstatus: DUD -- Buildarchive URL: redports From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 18:32:08 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E97868FC; Wed, 26 Jun 2013 18:32:08 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2B45915D0; Wed, 26 Jun 2013 18:32:08 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UruVf-000634-75; Thu, 27 Jun 2013 01:32:03 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r5QIXbDN084752; Thu, 27 Jun 2013 01:33:37 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r5QIXVTY084731; Thu, 27 Jun 2013 01:33:31 +0700 (NOVT) (envelope-from danfe) Date: Thu, 27 Jun 2013 01:33:31 +0700 From: Alexey Dokuchaev To: Baptiste Daroussin Subject: Re: Proposal: further OptionsNG improvements Message-ID: <20130626183331.GA78963@regency.nsu.ru> References: <20130618160037.GA26677@regency.nsu.ru> <20130618162708.GA34175@regency.nsu.ru> <20130621080451.GL23721@ithaqua.etoilebsd.net> <20130626121241.GA23956@regency.nsu.ru> <20130626123055.GA30841@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20130626123055.GA30841@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:32:09 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 26, 2013 at 07:30:55PM +0700, Alexey Dokuchaev wrote: > On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote: > > I've cooked something up just now, take a look at the attached diff. I've > > only barely tested it, but it seems to work for a few of my hand-crafted > > configurations. It also handles known options groups (single/multi/etc.), > > tested on www/firefox. > > One known limitation of option groups right now is that you cannot have > per-arch or !arch stuff, only :on. It should not be hard to fix, but I > need to think how to avoid code duplication. I miss $(call ...) of GNU > make sometimes... It just occurred to me that it seems we actually do not support something like OPTIONS_SINGLE_AUDIO_${ARCH}, which simplifies my work (please tell me if I'm wrong). So all I need is to remember about OPTIONS_EXCLUDE's in this case. Now it's possible (example for www/firefox/Makefile.options): OPTIONS_SINGLE_AUDIO= ALSA:on OSS!sparc64 PULSEAUDIO!powerpc,mips,i386 New diff attached (also comes with some comments tweaks, and I've switched from ^ to ~ as regex delimiter: it looks nicer and there is no confusion with start-of-line marker). I hope now it can cover anything possible to achieve with current OptionsNG. But we need reviewers and testers! ./danfe P.S. This was all developed on 8.3-STABLE, that is, with our traditional make(1). I will test new make(1) on 10-CURRENT tomorrow. --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="newsyntax2.diff" Index: bsd.options.mk =================================================================== --- bsd.options.mk (revision 321792) +++ bsd.options.mk (working copy) @@ -10,7 +10,7 @@ # specific to ${ARCH} # OPTIONS_DEFAULT - List of options activated by default # OPTIONS_DEFAULT_${ARCH} - List of options activated by default for a -# given arch +# given ${ARCH} # # ${OPTION}_DESC - Description of the ${OPTION} # @@ -94,14 +94,59 @@ PORT_OPTIONS+= IPV6 -# Add per arch options +### Parse new extended syntax OPTIONS knob (architecture-independent) +.for opt in ${OPTIONS:N*/*:N*!*} +OPTIONS_DEFINE+= ${opt:C~:.*~~} +OPTIONS_DEFAULT+= ${opt:M*\:on:S~:on~~} +.endfor + +# Process known option groups (only architecture exclusion supported) +.for otype in SINGLE RADIO MULTI GROUP +. for group in ${OPTIONS_${otype}} +# Here we need the temporary variables because of the := operator used few +# lines below +_exclude:= ${OPTIONS_${otype}_${group}:M*!*} +_default:= ${OPTIONS_${otype}_${group}:M*\:on*:C~:.*~~} +OPTIONS_DEFAULT+= ${_default} +OPTIONS_${otype}_${group}:= ${OPTIONS_${otype}_${group}:C~[:!].*~~} +. for opt in ${_exclude} +. for arch in ${opt:C~.*!~~:S~,~ ~g} +OPTIONS_EXCLUDE_${arch}+= ${opt:C~[:!].*~~} +. endfor +. endfor +. endfor +.endfor + +# Process architecture-specific options +.for opt in ${OPTIONS:M*/*} +. for arch in ${opt:C~.*/~~:S~,~ ~g} +. for defarch in OPTIONS_DEFINE_${arch:C~:.*~~} +${defarch}+= ${opt:C~/.*~~} +. endfor +. for defarch in OPTIONS_DEFAULT_${arch:M*\:on:S~:on~~} +${defarch}+= ${opt:C~/.*~~} +. endfor +. endfor +.endfor + +# Process options unsupported on some architectures +.for opt in ${OPTIONS:M*!*} +OPTIONS_DEFINE+= ${opt:C~[:!].*~~} +OPTIONS_DEFAULT+= ${opt:M*\:on!*:C~:.*~~} +. for arch in ${opt:C~.*!~~:S~,~ ~g} +OPTIONS_EXCLUDE_${arch}+= ${opt:C~[:!].*~~} +. endfor +.endfor +### + +# Add per-architecture options .for opt in ${OPTIONS_DEFINE_${ARCH}} .if empty(OPTIONS_DEFINE:M${opt}) OPTIONS_DEFINE+= ${opt} .endif .endfor -# Add per arch defaults +# Add per-architecture defaults OPTIONS_DEFAULT+= ${OPTIONS_DEFAULT_${ARCH}} # Remove options the port maintainer doesn't want @@ -130,7 +175,7 @@ ALL_OPTIONS:= ${OPTIONS_DEFINE:O:u} OPTIONS_DEFAULT:= ${OPTIONS_DEFAULT:O:u} -# complete list +# Complete list COMPLETE_OPTIONS_LIST= ${ALL_OPTIONS} .for otype in SINGLE RADIO MULTI GROUP . for m in ${OPTIONS_${otype}} --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 19:26:17 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D509FB1; Wed, 26 Jun 2013 19:26:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 880881805; Wed, 26 Jun 2013 19:26:16 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::acbc:c165:3b28:a78a] (unknown [IPv6:2001:7b8:3a7:0:acbc:c165:3b28:a78a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3A8D05C43; Wed, 26 Jun 2013 21:26:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) From: Dimitry Andric In-Reply-To: <20130626133149.4835f14a@bsd64.grem.de> Date: Wed, 26 Jun 2013 21:26:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> To: Michael Gmelin X-Mailer: Apple Mail (2.1508) Cc: Kostik Belousov , Brooks Davis , David Chisnall , Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 19:26:17 -0000 On Jun 26, 2013, at 13:31, Michael Gmelin wrote: > On Wed, 26 Jun 2013 11:00:40 +0200 > Dimitry Andric wrote: >> On 2013-06-26 01:55, Michael Gmelin wrote: >> ... >>> The problem is that static initialization happens in the expected >>> order (same translation unit), but termination does *not* happen in >>> the reverse order of initialization, ... > Yep, strange indeed - my test cases didn't use fPIC at first, so it > took a while to figure it out. It's seems to be some sort of > combined link/runtime problem, since the same executable built on 10 > runs fine on 9.1-RELEASE when copied over. I tried replacing various > system libraries with their versions from 9.1 in a jail to see if I > could make it run on 10, but to no success. >=20 > By the way, the same code built on 9.1 using clang 3.1 or clang 3.3 > runs fine on 10 as well, so the only case that does NOT work is build > on 10 and run on 10 using clang. Also, when I link copies of main.o = and > libout.so that have been built on 10 on 9.1 using clang33 the problem > doesn't happen as well. So it appears that the problem happens > when linking the executable when one of the objects is position > independent and then only surfaces on 10. So I did a bit of investigation, and the root cause is that both clang and newer versions of gcc emit direct calls to the destructors of global objects, while older gcc's, such as the one in base, generate anonymous wrapper functions, which in turn call the destructors. The direct destructor calls will not work correctly, if the destructors are located in shared objects, while the global objects themselves are in the main program, and if the main program is compiled with -fPIC. This problem happens after the following revision, which changed the behavior of __cxa_finalize(); http://svnweb.freebsd.org/base?view=3Drevision&revision=3D211706 This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the problem can also be reproduced there. To illustrate: if you compile your test program's main.cpp with gcc -fPIC, it produces (excerpted the assembly a bit for readability): .section .ctors,"aw",@progbits .align 4 .long _GLOBAL__I_main [...] __tcf_1: pushl %ebp movl %esp, %ebp pushl %ebx call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx subl $16, %esp leal innerInstance@GOTOFF(%ebx), %eax pushl %eax call _ZN5InnerD1Ev@PLT addl $16, %esp movl -4(%ebp), %ebx leave ret [...] _Z41__static_initialization_and_destruction_0ii: pushl %ebp movl %esp, %ebp pushl %esi pushl %ebx call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx decl %eax jne .L14 cmpl $65535, %edx jne .L14 subl $12, %esp leal outerInstance@GOTOFF(%ebx), %eax pushl %eax call _ZN5OuterC1Ev@PLT movl __dso_handle@GOT(%ebx), %esi addl $12, %esp leal __tcf_0@GOTOFF(%ebx), %eax pushl %esi pushl $0 pushl %eax call __cxa_atexit@PLT leal innerInstance@GOTOFF(%ebx), %eax movl %eax, (%esp) call _ZN5InnerC1Ev@PLT addl $12, %esp pushl %esi pushl $0 leal __tcf_1@GOTOFF(%ebx), %eax pushl %eax call __cxa_atexit@PLT addl $16, %esp .L14: leal -8(%ebp), %esp popl %ebx popl %esi popl %ebp ret [...] _GLOBAL__I_main: pushl %ebp movl $65535, %edx movl %esp, %ebp movl $1, %eax popl %ebp jmp _Z41__static_initialization_and_destruction_0ii [...] __tcf_0: pushl %ebp movl %esp, %ebp pushl %ebx call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx subl $16, %esp leal outerInstance@GOTOFF(%ebx), %eax pushl %eax call _ZN5OuterD1Ev@PLT addl $16, %esp movl -4(%ebp), %ebx leave ret [...] Summarizing: - the startup code calls _GLOBAL__I_main, a.k.a. "global constructors = keyed to main" - jumps to _Z41__static_initialization_and_destruction_0ii, a.k.a. __static_initialization_and_destruction_0(int, int) - calls _ZN5OuterC1Ev, a.k.a. Outer::Outer(), to construct the outerInstance object - calls __cxa_atexit(), registering a generated wrapper function __tcf_0(), which actually calls _ZN5OuterD1Ev, a.k.a. Outer::~Outer() - similar for the innerInstance object In contrast, clang produces the following: _GLOBAL__I_a: # @_GLOBAL__I_a pushl %ebp movl %esp, %ebp pushl %ebx pushl %edi pushl %esi subl $12, %esp calll .L2$pb .L2$pb: popl %ebx addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp13-.L2$pb), %ebx leal _ZL13outerInstance@GOTOFF(%ebx), %edi movl %edi, (%esp) calll _ZN5OuterC1Ev@PLT movl __dso_handle@GOT(%ebx), %esi movl %esi, 8(%esp) movl %edi, 4(%esp) movl _ZN5OuterD1Ev@GOT(%ebx), %eax movl %eax, (%esp) calll __cxa_atexit@PLT leal .Lstr5@GOTOFF(%ebx), %eax movl %eax, (%esp) calll puts@PLT movl %esi, 8(%esp) leal _ZL13innerInstance@GOTOFF(%ebx), %eax movl %eax, 4(%esp) movl _ZN5InnerD1Ev@GOT(%ebx), %eax movl %eax, (%esp) calll __cxa_atexit@PLT addl $12, %esp popl %esi popl %edi popl %ebx popl %ebp ret [...] .section .ctors,"aw",@progbits .align 4 .long _GLOBAL__I_a Summarizing: - the startup code calls _GLOBAL__I_a, a.k.a. "global constructors keyed to a" - calls _ZN5OuterC1Ev, a.k.a. Outer::Outer(), to construct the outerInstance object - calls __cxa_atexit(), directly registering _ZN5OuterD1Ev, a.k.a Outer::~Outer() - similar for the innerInstance object (though the constructor is inlined) The crucial difference is that clang *directly* registers the destructor's function pointer, instead of using a locally generated wrapper. Newer versions of gcc behave the same way, since this upstream revision: http://gcc.gnu.org/viewcvs/gcc?view=3Drevision&revision=3D125253 This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates: _GLOBAL__sub_I_main.cpp: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx call __x86.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx subl $24, %esp leal _ZL13outerInstance@GOTOFF(%ebx), %edi pushl %edi call _ZN5OuterC1Ev@PLT leal __dso_handle@GOTOFF(%ebx), %esi addl $12, %esp pushl %esi pushl %edi pushl _ZN5OuterD1Ev@GOT(%ebx) call __cxa_atexit@PLT leal .LC2@GOTOFF(%ebx), %eax movl %eax, (%esp) call puts@PLT addl $12, %esp pushl %esi leal _ZL13innerInstance@GOTOFF(%ebx), %eax pushl %eax pushl _ZN5InnerD1Ev@GOT(%ebx) call __cxa_atexit@PLT addl $16, %esp leal -12(%ebp), %esp popl %ebx popl %esi popl %edi popl %ebp ret [...] .section .ctors,"aw",@progbits .align 4 .long _GLOBAL__sub_I_main.cpp In each case, __cxa_exit() is called with the following three arguments: the address of the destructor, the pointer to the object ('this'), and the dso handle, which in this case belongs to main. Now, when the program exits, it will repeatedly call __cxa_finalize() to actually call the registered exit functions, each time passing a pointer to the dso being unloaded (or NULL for main): void __cxa_finalize(void *dso) { struct dl_phdr_info phdr_info; struct atexit *p; struct atexit_fn fn; int n, has_phdr; if (dso !=3D NULL) has_phdr =3D _rtld_addr_phdr(dso, &phdr_info); else has_phdr =3D 0; _MUTEX_LOCK(&atexit_mutex); for (p =3D __atexit; p; p =3D p->next) { for (n =3D p->ind; --n >=3D 0;) { if (p->fns[n].fn_type =3D=3D ATEXIT_FN_EMPTY) continue; /* already been called */ fn =3D p->fns[n]; if (dso !=3D NULL && dso !=3D fn.fn_dso) { /* wrong DSO ? */ if (!has_phdr || !__elf_phdr_match_addr( &phdr_info, fn.fn_ptr.cxa_func)) continue; } /* Mark entry to indicate that this particular = handler has already been called. */ p->fns[n].fn_type =3D ATEXIT_FN_EMPTY; _MUTEX_UNLOCK(&atexit_mutex); /* Call the function of correct type. */ if (fn.fn_type =3D=3D ATEXIT_FN_CXA) fn.fn_ptr.cxa_func(fn.fn_arg); else if (fn.fn_type =3D=3D ATEXIT_FN_STD) fn.fn_ptr.std_func(); [...] The problem is in the part with the comment "wrong DSO?". When the main program is compiled with -fPIC, and __cxa_finalize() is called for libout.so (which is the first dso to be processed), it will encounter the entry for Outer::~Outer(). Then, the "wrong DSO?" part will be entered, and because has_phdr is true, it will call __elf_phdr_match_addr() with the address of the destructor. Since the destructor is registered with _ZN5OuterD1Ev@GOT, it will match, and it will be called. In contrast, if the main program is not compiled with -fPIC, the destructor will be registered with _ZN5OuterD1Ev (e.g. without @GOT), and __elf_phdr_match_addr() will not match, and the loop continues without calling the destructor. Finally, if the main program is compiled with gcc and -fPIC, the destructor itself is never considered in the __cxa_finalize() loop, only the locally generated wrapper function. That function will only be called in the __cxa_finalize() call for the main program, and so the destructor will be called at the right time. I am not entirely sure what can be done to remedy this scenario, and I also do not know the exact reasons for r211706 changing the behavior. E.g., before r211706, if the atexit_fn's fn_dso did not match the dso being unloaded, the loop would unconditionally continue without calling the handler. On the other hand, r211706 seems to make sure functions from dso's will be called before they are unloaded, as calling them afterwards would not always make sense... :-) > Based on this I would *speculate* that the problem first appeared when > r232832 was committed [1] and there's something wrong with the order = of > how fini_array is filled b the linker (or traversed later). At this point, I do not think r232832 is the culprit. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 20:31:36 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CCBE4893 for ; Wed, 26 Jun 2013 20:31:36 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id C92921B32 for ; Wed, 26 Jun 2013 20:31:35 +0000 (UTC) Received: (qmail 57801 invoked by uid 89); 26 Jun 2013 20:31:33 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 20:31:33 -0000 Date: Wed, 26 Jun 2013 22:31:33 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626223133.1cc1e009@bsd64.grem.de> In-Reply-To: <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:31:36 -0000 On Wed, 26 Jun 2013 21:26:09 +0200 Dimitry Andric wrote: > On Jun 26, 2013, at 13:31, Michael Gmelin wrote: > > On Wed, 26 Jun 2013 11:00:40 +0200 > > Dimitry Andric wrote: > >> On 2013-06-26 01:55, Michael Gmelin wrote: > >> ... > >>> The problem is that static initialization happens in the expected > >>> order (same translation unit), but termination does *not* happen > >>> in the reverse order of initialization, > ... > > Yep, strange indeed - my test cases didn't use fPIC at first, so it > > took a while to figure it out. It's seems to be some sort of > > combined link/runtime problem, since the same executable built on 10 > > runs fine on 9.1-RELEASE when copied over. I tried replacing various > > system libraries with their versions from 9.1 in a jail to see if I > > could make it run on 10, but to no success. > > > > By the way, the same code built on 9.1 using clang 3.1 or clang 3.3 > > runs fine on 10 as well, so the only case that does NOT work is > > build on 10 and run on 10 using clang. Also, when I link copies of > > main.o and libout.so that have been built on 10 on 9.1 using > > clang33 the problem doesn't happen as well. So it appears that the > > problem happens when linking the executable when one of the objects > > is position independent and then only surfaces on 10. > > So I did a bit of investigation, and the root cause is that both clang > and newer versions of gcc emit direct calls to the destructors of > global objects, while older gcc's, such as the one in base, generate > anonymous wrapper functions, which in turn call the destructors. > > The direct destructor calls will not work correctly, if the > destructors are located in shared objects, while the global objects > themselves are in the main program, and if the main program is > compiled with -fPIC. This problem happens after the following > revision, which changed the behavior of __cxa_finalize(); > > http://svnweb.freebsd.org/base?view=revision&revision=211706 > > This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the > problem can also be reproduced there. > > To illustrate: if you compile your test program's main.cpp with gcc > -fPIC, it produces (excerpted the assembly a bit for readability): > > .section .ctors,"aw",@progbits > .align 4 > .long _GLOBAL__I_main > [...] > __tcf_1: > pushl %ebp > movl %esp, %ebp > pushl %ebx > call __i686.get_pc_thunk.bx > addl $_GLOBAL_OFFSET_TABLE_, %ebx > subl $16, %esp > leal innerInstance@GOTOFF(%ebx), %eax > pushl %eax > call _ZN5InnerD1Ev@PLT > addl $16, %esp > movl -4(%ebp), %ebx > leave > ret > [...] > _Z41__static_initialization_and_destruction_0ii: > pushl %ebp > movl %esp, %ebp > pushl %esi > pushl %ebx > call __i686.get_pc_thunk.bx > addl $_GLOBAL_OFFSET_TABLE_, %ebx > decl %eax > jne .L14 > cmpl $65535, %edx > jne .L14 > subl $12, %esp > leal outerInstance@GOTOFF(%ebx), %eax > pushl %eax > call _ZN5OuterC1Ev@PLT > movl __dso_handle@GOT(%ebx), %esi > addl $12, %esp > leal __tcf_0@GOTOFF(%ebx), %eax > pushl %esi > pushl $0 > pushl %eax > call __cxa_atexit@PLT > leal innerInstance@GOTOFF(%ebx), %eax > movl %eax, (%esp) > call _ZN5InnerC1Ev@PLT > addl $12, %esp > pushl %esi > pushl $0 > leal __tcf_1@GOTOFF(%ebx), %eax > pushl %eax > call __cxa_atexit@PLT > addl $16, %esp > .L14: > leal -8(%ebp), %esp > popl %ebx > popl %esi > popl %ebp > ret > [...] > _GLOBAL__I_main: > pushl %ebp > movl $65535, %edx > movl %esp, %ebp > movl $1, %eax > popl %ebp > jmp _Z41__static_initialization_and_destruction_0ii > [...] > __tcf_0: > pushl %ebp > movl %esp, %ebp > pushl %ebx > call __i686.get_pc_thunk.bx > addl $_GLOBAL_OFFSET_TABLE_, %ebx > subl $16, %esp > leal outerInstance@GOTOFF(%ebx), %eax > pushl %eax > call _ZN5OuterD1Ev@PLT > addl $16, %esp > movl -4(%ebp), %ebx > leave > ret > [...] > > Summarizing: > - the startup code calls _GLOBAL__I_main, a.k.a. "global constructors > keyed to main" > - jumps to _Z41__static_initialization_and_destruction_0ii, a.k.a. > __static_initialization_and_destruction_0(int, int) > - calls _ZN5OuterC1Ev, a.k.a. Outer::Outer(), to construct the > outerInstance object > - calls __cxa_atexit(), registering a generated wrapper function > __tcf_0(), which actually calls _ZN5OuterD1Ev, a.k.a. > Outer::~Outer() > - similar for the innerInstance object > > In contrast, clang produces the following: > > _GLOBAL__I_a: # @_GLOBAL__I_a > pushl %ebp > movl %esp, %ebp > pushl %ebx > pushl %edi > pushl %esi > subl $12, %esp > calll .L2$pb > .L2$pb: > popl %ebx > addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp13-.L2$pb), %ebx > leal _ZL13outerInstance@GOTOFF(%ebx), %edi > movl %edi, (%esp) > calll _ZN5OuterC1Ev@PLT > movl __dso_handle@GOT(%ebx), %esi > movl %esi, 8(%esp) > movl %edi, 4(%esp) > movl _ZN5OuterD1Ev@GOT(%ebx), %eax > movl %eax, (%esp) > calll __cxa_atexit@PLT > leal .Lstr5@GOTOFF(%ebx), %eax > movl %eax, (%esp) > calll puts@PLT > movl %esi, 8(%esp) > leal _ZL13innerInstance@GOTOFF(%ebx), %eax > movl %eax, 4(%esp) > movl _ZN5InnerD1Ev@GOT(%ebx), %eax > movl %eax, (%esp) > calll __cxa_atexit@PLT > addl $12, %esp > popl %esi > popl %edi > popl %ebx > popl %ebp > ret > [...] > .section .ctors,"aw",@progbits > .align 4 > .long _GLOBAL__I_a > > Summarizing: > - the startup code calls _GLOBAL__I_a, a.k.a. "global constructors > keyed to a" > - calls _ZN5OuterC1Ev, a.k.a. Outer::Outer(), to construct the > outerInstance object > - calls __cxa_atexit(), directly registering _ZN5OuterD1Ev, a.k.a > Outer::~Outer() > - similar for the innerInstance object (though the constructor is > inlined) > > The crucial difference is that clang *directly* registers the > destructor's function pointer, instead of using a locally generated > wrapper. Newer versions of gcc behave the same way, since this > upstream revision: > > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=125253 > > This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates: > > _GLOBAL__sub_I_main.cpp: > pushl %ebp > movl %esp, %ebp > pushl %edi > pushl %esi > pushl %ebx > call __x86.get_pc_thunk.bx > addl $_GLOBAL_OFFSET_TABLE_, %ebx > subl $24, %esp > leal _ZL13outerInstance@GOTOFF(%ebx), %edi > pushl %edi > call _ZN5OuterC1Ev@PLT > leal __dso_handle@GOTOFF(%ebx), %esi > addl $12, %esp > pushl %esi > pushl %edi > pushl _ZN5OuterD1Ev@GOT(%ebx) > call __cxa_atexit@PLT > leal .LC2@GOTOFF(%ebx), %eax > movl %eax, (%esp) > call puts@PLT > addl $12, %esp > pushl %esi > leal _ZL13innerInstance@GOTOFF(%ebx), %eax > pushl %eax > pushl _ZN5InnerD1Ev@GOT(%ebx) > call __cxa_atexit@PLT > addl $16, %esp > leal -12(%ebp), %esp > popl %ebx > popl %esi > popl %edi > popl %ebp > ret > [...] > .section .ctors,"aw",@progbits > .align 4 > .long _GLOBAL__sub_I_main.cpp > > In each case, __cxa_exit() is called with the following three > arguments: the address of the destructor, the pointer to the object > ('this'), and the dso handle, which in this case belongs to main. > > Now, when the program exits, it will repeatedly call __cxa_finalize() > to actually call the registered exit functions, each time passing a > pointer to the dso being unloaded (or NULL for main): > > void > __cxa_finalize(void *dso) > { > struct dl_phdr_info phdr_info; > struct atexit *p; > struct atexit_fn fn; > int n, has_phdr; > > if (dso != NULL) > has_phdr = _rtld_addr_phdr(dso, &phdr_info); > else > has_phdr = 0; > > _MUTEX_LOCK(&atexit_mutex); > for (p = __atexit; p; p = p->next) { > for (n = p->ind; --n >= 0;) { > if (p->fns[n].fn_type == ATEXIT_FN_EMPTY) > continue; /* already been called */ > fn = p->fns[n]; > if (dso != NULL && dso != fn.fn_dso) { > /* wrong DSO ? */ > if (!has_phdr > || !__elf_phdr_match_addr( &phdr_info, fn.fn_ptr.cxa_func)) > continue; > } > /* > Mark entry to indicate that this particular > handler has already been called. > */ > p->fns[n].fn_type = ATEXIT_FN_EMPTY; > _MUTEX_UNLOCK(&atexit_mutex); > > /* Call the function of correct type. */ > if (fn.fn_type == ATEXIT_FN_CXA) > fn.fn_ptr.cxa_func(fn.fn_arg); > else if (fn.fn_type == ATEXIT_FN_STD) > fn.fn_ptr.std_func(); > [...] > > The problem is in the part with the comment "wrong DSO?". When the > main program is compiled with -fPIC, and __cxa_finalize() is called > for libout.so (which is the first dso to be processed), it will > encounter the entry for Outer::~Outer(). > > Then, the "wrong DSO?" part will be entered, and because has_phdr is > true, it will call __elf_phdr_match_addr() with the address of the > destructor. Since the destructor is registered with > _ZN5OuterD1Ev@GOT, it will match, and it will be called. > > In contrast, if the main program is not compiled with -fPIC, the > destructor will be registered with _ZN5OuterD1Ev (e.g. without @GOT), > and __elf_phdr_match_addr() will not match, and the loop continues > without calling the destructor. > > Finally, if the main program is compiled with gcc and -fPIC, the > destructor itself is never considered in the __cxa_finalize() loop, > only the locally generated wrapper function. That function will only > be called in the __cxa_finalize() call for the main program, and so > the destructor will be called at the right time. > > I am not entirely sure what can be done to remedy this scenario, and I > also do not know the exact reasons for r211706 changing the behavior. > > E.g., before r211706, if the atexit_fn's fn_dso did not match the dso > being unloaded, the loop would unconditionally continue without > calling the handler. On the other hand, r211706 seems to make sure > functions from dso's will be called before they are unloaded, as > calling them afterwards would not always make sense... :-) > Thanks for the in-depth analysis, quite interesting read that makes a lot of sense and matches the gut feeling that "it's destroying everything defined in the shared lib first". Call me Mr. Obvious, but I assume clang and gcc won't change the way destructors are registered, so we need a fix in FreeBSD. Maybe kib@ could shed some light on this? Cheers, Michael -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 20:45:27 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DBC5D00; Wed, 26 Jun 2013 20:45:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BE5261BD1; Wed, 26 Jun 2013 20:45:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5QKjMYx076019; Wed, 26 Jun 2013 23:45:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5QKjMYx076019 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5QKjMJ9076014; Wed, 26 Jun 2013 23:45:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Jun 2013 23:45:21 +0300 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626204521.GU91021@kib.kiev.ua> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UkVofV5Xw/L9x8rZ" Content-Disposition: inline In-Reply-To: <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Matthias Andree , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:45:27 -0000 --UkVofV5Xw/L9x8rZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: > This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the > problem can also be reproduced there. ... > This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates: I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD. In both cases, major tom did not fail, at least not in the peculiar way. The gcc-generated code passed the PLT address of the corresponding destructor. The r211706 intent is indeed to prevent a situation when the libc calls the atexit(3)-registered termination function from dso which is already unloaded. This is apparently epidemic with PHP and similar environments. --UkVofV5Xw/L9x8rZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRy1LhAAoJEJDCuSvBvK1BtiIP/1AQbpC8KkPWdQkQC8K5WG9b kND0OU97MfU+D4vVufzxA4T9RKCCBTrpboqwHzcdKv7DYhVkb2SHDP29MAh8kwHZ GH8SWxphx4dD4hI3etSJHt73j9xMDL2S7Ar9+sN13UmVs69G77ragb+8+N9Hkb7c u5UdtUXQKcGPW5Z8W7nZr1D0tNxb9+8Zmj2MLZcogE9dTJATZAYNyLNalGF34oMn gh2Mirpf4JKAH01ViTLkeC8ZE/ku7m8h1wGPlHQ3hwWeLEaHm+R7VadBctsubziE wkRsxstmpp2MKb5az8mhGURtaIsR6eXyY2JyQXzJCRUrV2ONoOaRuqsmpdJ+Ij6D QsT5P374pJXemnDxZ9RlzB3Gi+v8rU+sFmJoyaMbJQnwuivf83iaVLW+B5matOQc jDb0TVfeLU6y0KhEN0ljqaIa6v9bF8E6P33ISWmL8Lx02dyN6GrrYgpa4t9IrzgW HIx+PMh0fRgUE/6bmUDg3RIiNCQ6bCUT4R7JaE8pE9z8ydI9ucHQNK+rwUMHi4eh toBkziE+yOJEn1C060yrRhmF6z3iw3H1zKXIaVvUsn2F/6Myc4H3H9KvKZZUCTUO Ljuw5aYo5SxQBpg2g1fmXDjFVmzbqhwRHmsoc0tRIJERx6oaylCXDcOt1QlYzwy8 /pROX+XGNM4kqWxkY5R2 =YmiI -----END PGP SIGNATURE----- --UkVofV5Xw/L9x8rZ-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 20:51:38 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A762E19 for ; Wed, 26 Jun 2013 20:51:38 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id D11C91C0F for ; Wed, 26 Jun 2013 20:51:37 +0000 (UTC) Received: (qmail 58082 invoked by uid 89); 26 Jun 2013 20:51:36 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 20:51:36 -0000 Date: Wed, 26 Jun 2013 22:51:37 +0200 From: Michael Gmelin To: Konstantin Belousov Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626225137.7b36167f@bsd64.grem.de> In-Reply-To: <20130626204521.GU91021@kib.kiev.ua> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Chisnall , Brooks Davis , Dimitry Andric , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:51:38 -0000 On Wed, 26 Jun 2013 23:45:21 +0300 Konstantin Belousov wrote: > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: > > This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the > > problem can also be reproduced there. > ... > > This is roughly gcc 4.3.0 and later. For example, gcc 4.8 > > generates: > I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD. > In both cases, major tom did not fail, at least not in the peculiar > way. The gcc-generated code passed the PLT address of the > corresponding destructor. Could you replicate the problem using clang on stable/9 and HEAD? (I didn't test gcc > 4.2.1 myself). > > The r211706 intent is indeed to prevent a situation when the libc > calls the atexit(3)-registered termination function from dso which is > already unloaded. This is apparently epidemic with PHP and similar > environments. > -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 20:56:50 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F4B4128; Wed, 26 Jun 2013 20:56:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E415D1C68; Wed, 26 Jun 2013 20:56:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5QKukMT078851; Wed, 26 Jun 2013 23:56:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5QKukMT078851 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5QKukHp078850; Wed, 26 Jun 2013 23:56:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Jun 2013 23:56:46 +0300 From: Konstantin Belousov To: Michael Gmelin Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626205646.GW91021@kib.kiev.ua> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <20130626225137.7b36167f@bsd64.grem.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGbAx67h5zWZd0A1" Content-Disposition: inline In-Reply-To: <20130626225137.7b36167f@bsd64.grem.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: David Chisnall , Brooks Davis , Dimitry Andric , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:56:50 -0000 --vGbAx67h5zWZd0A1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 26, 2013 at 10:51:37PM +0200, Michael Gmelin wrote: > Could you replicate the problem using clang on stable/9 and HEAD? (I > didn't test gcc > 4.2.1 myself). On stable no, it is not reproducable. As I understand, stable clang is 3.2-something. On HEAD with clang, I do see the indentation change and wrong order. --vGbAx67h5zWZd0A1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRy1WNAAoJEJDCuSvBvK1Bio0QAJx152INYya3B9mEypcVOp6e H/JBSDltnsZt9n0SR3vRUSRduXBoZ/wFWTnyJSG31rJogcD4Cr3URIh64YPWm/S5 vL0AQev/YDZbLm5LjmwwuulCpekPBxutj2SUO7bApvOyaqku43AkgqLjnlRnjR+S ttxH1+foWsdWCKlNPlF/Yq0ilFbPzBn2lPiYiLq+G4sgLI/tUON8dQEHxXdLeTvk zwqLdYmlqoWB4TqXYXZLARwx08yXBdW02KtJMNl2gPathaHaBMcZpQFl7UkXmhZ8 u7NagCF0obUjCH213gT/PbhHW2HRpxJnYcktxu78EZvJ6GFwHod73lw58WQ2vvHN 7Qadt8X9qjMbm/zR0J+77XhpKdPU862J/HahYHPv73Lgvgeeeh+wsII4EDB2fyq4 89SNPIBmOupYf7LWIMPvaxlvzokPnUfXXfEtVmUfat+GMkRctDc+FejFInxCd6WW no1yhVNmLL/vgse/e5N3JK5srLiVT9l92uANWw94JalIxIQmBAakhu7a57PFZWCD HmiHrSKNBMJBZuB34xrNkZLDSkr7DNJaVBn06LMboQ51TMEi7s/5IJaQgHc0ztJO jdA2A3PuLS/uYkoZlipio2EfHw3jFFV3pjJlZS8T/0FBFJcY+nYBLnB0p2tVEueM H/Wws2nb7qcVZEzDw/zi =AcDy -----END PGP SIGNATURE----- --vGbAx67h5zWZd0A1-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 20:59:26 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B051B1F8; Wed, 26 Jun 2013 20:59:26 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 754581C8A; Wed, 26 Jun 2013 20:59:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::acbc:c165:3b28:a78a] (unknown [IPv6:2001:7b8:3a7:0:acbc:c165:3b28:a78a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 554675C43; Wed, 26 Jun 2013 22:59:23 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) From: Dimitry Andric In-Reply-To: <20130626204521.GU91021@kib.kiev.ua> Date: Wed, 26 Jun 2013 22:59:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Matthias Andree , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:59:26 -0000 On Jun 26, 2013, at 22:45, Konstantin Belousov wrote: > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: >> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the >> problem can also be reproduced there. > ... >> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates: > I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD. > In both cases, major tom did not fail, at least not in the peculiar way. > The gcc-generated code passed the PLT address of the corresponding > destructor. That is strange, did you compile the main program with -fPIC? That is the problem case. If you don't compile the main program with -fPIC, the problem will indeed not occur. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:05:41 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE0D85C0; Wed, 26 Jun 2013 21:05:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6931CF9; Wed, 26 Jun 2013 21:05:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5QL5Y4c081292; Thu, 27 Jun 2013 00:05:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5QL5Y4c081292 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5QL5YUe081291; Thu, 27 Jun 2013 00:05:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Jun 2013 00:05:34 +0300 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626210534.GY91021@kib.kiev.ua> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zeTRWudynWXPpCJH" Content-Disposition: inline In-Reply-To: <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Matthias Andree , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:05:42 -0000 --zeTRWudynWXPpCJH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote: > On Jun 26, 2013, at 22:45, Konstantin Belousov wrot= e: > > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: > >> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the > >> problem can also be reproduced there. > > ... > >> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 generates: > > I just tested the thing with gcc 4.8 on up to date stable/9 and HEAD. > > In both cases, major tom did not fail, at least not in the peculiar way. > > The gcc-generated code passed the PLT address of the corresponding > > destructor. >=20 > That is strange, did you compile the main program with -fPIC? That is > the problem case. If you don't compile the main program with -fPIC, the > problem will indeed not occur. I just used the Makefile provided by the earlier message, and it contains the -fPIC flag (which is strange thing to do on its own, binaries should use -fPIE). This is how the registration for the outer dtr looks for me, gcc 4.8.1/i386: 0x08048763 <+42>: call 0x8048520 <_ZN5OuterC1Ev@plt> 0x08048768 <+47>: lea 0x28(%ebx),%eax 0x0804876e <+53>: mov %eax,0x8(%esp) 0x08048772 <+57>: lea 0x34(%ebx),%eax 0x08048778 <+63>: mov %eax,0x4(%esp) 0x0804877c <+67>: mov -0x4(%ebx),%eax 0x08048782 <+73>: mov %eax,(%esp) 0x08048785 <+76>: call 0x8048500 <__cxa_atexit@plt> ebx was set up earlier as the GOT pointer. --zeTRWudynWXPpCJH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRy1edAAoJEJDCuSvBvK1BH/4P/0Z+2ketTUTOBdnYOaV4TK0h WzYpZc6u5sAKjU0JL+qeccJj83ejMPQP/tKpHQTSwbUGpp3IgX+jCysAcxCBjXnv QBbMBP9em7sx50VTaoMvyfvNiVMv8EzBzJ2bofEfZsqXs71h6y7OML9N+Be5fz1V FHIlcf12fncAtTCxpgQl50lGLoZV7fWH7coDxmPZp2NOVgunH+v/LcQBHzC7hLpd qiZRZPNZcka9AAf/bERbxpV8HXPNOeteExnuS96Inu/qpo7H6XvC4sA2+vp0J85n 4GFrnkOg27pJAQcQJN5CksnFPFqDfG5YKSksEyEWB0ll/ZNIEhw1pXDQs8Q4AGP7 Ea8FfvHJkEI/WKUsRIH1usuz45Ipp/QdIsSF0DvShyoRNsTOuA+eW66NlOD92Yb8 sJqy0OxHu186ZJyKq3jfPVsvj3cSnkn5FhLEwoG+e3DlCLyQk6UMbrTOARAuxYd/ UHti0GsIjWn41vk34I2QlyIo+sOHDpYbUvRoKmsJ5LjDuAxO8oHjPmwnMlq9uY+u YWpl3jEKkgv9HKKYwYQKVf4qfjrKfUfC0er4P6jeY43trqJfVRDDs+5FDkeeGR4k POdNKk9mZRuM+eWunrAfrpF2gzsLNf11IdCi8V8D6zm23nYEhV5WzUFNtUUJJVmt B02/fGUJ1MaWetPgSUQ1 =5vJk -----END PGP SIGNATURE----- --zeTRWudynWXPpCJH-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:09:09 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 190A98A2 for ; Wed, 26 Jun 2013 21:09:09 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 757471D30 for ; Wed, 26 Jun 2013 21:09:08 +0000 (UTC) Received: (qmail 58468 invoked by uid 89); 26 Jun 2013 21:09:07 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 21:09:07 -0000 Date: Wed, 26 Jun 2013 23:09:08 +0200 From: Michael Gmelin To: Konstantin Belousov Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626230908.327fabdf@bsd64.grem.de> In-Reply-To: <20130626210534.GY91021@kib.kiev.ua> References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Chisnall , Brooks Davis , Dimitry Andric , Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:09:09 -0000 On Thu, 27 Jun 2013 00:05:34 +0300 Konstantin Belousov wrote: > On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote: > > On Jun 26, 2013, at 22:45, Konstantin Belousov > > wrote: > > > On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: > > >> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so > > >> the problem can also be reproduced there. > > > ... > > >> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 > > >> generates: > > > I just tested the thing with gcc 4.8 on up to date stable/9 and > > > HEAD. In both cases, major tom did not fail, at least not in the > > > peculiar way. The gcc-generated code passed the PLT address of > > > the corresponding destructor. > > > > That is strange, did you compile the main program with -fPIC? That > > is the problem case. If you don't compile the main program with > > -fPIC, the problem will indeed not occur. > > I just used the Makefile provided by the earlier message, and it > contains the -fPIC flag (which is strange thing to do on its own, > binaries should use -fPIE). > > This is how the registration for the outer dtr looks for me, gcc > 4.8.1/i386: > > 0x08048763 <+42>: call 0x8048520 <_ZN5OuterC1Ev@plt> > 0x08048768 <+47>: lea 0x28(%ebx),%eax > 0x0804876e <+53>: mov %eax,0x8(%esp) > 0x08048772 <+57>: lea 0x34(%ebx),%eax > 0x08048778 <+63>: mov %eax,0x4(%esp) > 0x0804877c <+67>: mov -0x4(%ebx),%eax > 0x08048782 <+73>: mov %eax,(%esp) > 0x08048785 <+76>: call 0x8048500 <__cxa_atexit@plt> > > ebx was set up earlier as the GOT pointer. The link step doesn't require -fPIC, only main.cpp needs to be built with it to trigger the problem (which is not that uncommon after all). All test were done using amd64. -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:11:39 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E9A6A17; Wed, 26 Jun 2013 21:11:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7281D53; Wed, 26 Jun 2013 21:11:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::acbc:c165:3b28:a78a] (unknown [IPv6:2001:7b8:3a7:0:acbc:c165:3b28:a78a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 532B55C43; Wed, 26 Jun 2013 23:11:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) From: Dimitry Andric In-Reply-To: <20130626210534.GY91021@kib.kiev.ua> Date: Wed, 26 Jun 2013 23:11:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Matthias Andree , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:11:39 -0000 On Jun 26, 2013, at 23:05, Konstantin Belousov = wrote: > On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote: >> On Jun 26, 2013, at 22:45, Konstantin Belousov = wrote: >>> On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: >>>> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so the >>>> problem can also be reproduced there. >>> ... >>>> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 = generates: >>> I just tested the thing with gcc 4.8 on up to date stable/9 and = HEAD. >>> In both cases, major tom did not fail, at least not in the peculiar = way. >>> The gcc-generated code passed the PLT address of the corresponding >>> destructor. >>=20 >> That is strange, did you compile the main program with -fPIC? That = is >> the problem case. If you don't compile the main program with -fPIC, = the >> problem will indeed not occur. >=20 > I just used the Makefile provided by the earlier message, and it = contains > the -fPIC flag (which is strange thing to do on its own, binaries = should > use -fPIE). >=20 > This is how the registration for the outer dtr looks for me, gcc = 4.8.1/i386: >=20 > 0x08048763 <+42>: call 0x8048520 <_ZN5OuterC1Ev@plt> > 0x08048768 <+47>: lea 0x28(%ebx),%eax > 0x0804876e <+53>: mov %eax,0x8(%esp) > 0x08048772 <+57>: lea 0x34(%ebx),%eax > 0x08048778 <+63>: mov %eax,0x4(%esp) > 0x0804877c <+67>: mov -0x4(%ebx),%eax > 0x08048782 <+73>: mov %eax,(%esp) > 0x08048785 <+76>: call 0x8048500 <__cxa_atexit@plt> >=20 > ebx was set up earlier as the GOT pointer. Strange, you must have a different gcc 4.8 than me, in my case it always = uses GOT: call _ZN5OuterC1Ev@PLT leal __dso_handle@GOTOFF(%ebx), %esi addl $12, %esp pushl %esi pushl %edi pushl _ZN5OuterD1Ev@GOT(%ebx) call __cxa_atexit@PLT This is the lang/gcc48 port, btw. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:17:42 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 804ACEED for ; Wed, 26 Jun 2013 21:17:42 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id DD2821DC7 for ; Wed, 26 Jun 2013 21:17:41 +0000 (UTC) Received: (qmail 58690 invoked by uid 89); 26 Jun 2013 21:17:40 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 21:17:40 -0000 Date: Wed, 26 Jun 2013 23:17:41 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626231741.497f7a9b@bsd64.grem.de> In-Reply-To: References: <20130613031535.4087d7f9@bsd64.grem.de> <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Brooks Davis , David Chisnall , Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:17:42 -0000 On Wed, 26 Jun 2013 23:11:34 +0200 Dimitry Andric wrote: > On Jun 26, 2013, at 23:05, Konstantin Belousov > wrote: > > On Wed, Jun 26, 2013 at 10:59:24PM +0200, Dimitry Andric wrote: > >> On Jun 26, 2013, at 22:45, Konstantin Belousov > >> wrote: > >>> On Wed, Jun 26, 2013 at 09:26:09PM +0200, Dimitry Andric wrote: > >>>> This revision is not in 9.1-RELEASE, but it is in 9-STABLE, so > >>>> the problem can also be reproduced there. > >>> ... > >>>> This is roughly gcc 4.3.0 and later. For example, gcc 4.8 > >>>> generates: > >>> I just tested the thing with gcc 4.8 on up to date stable/9 and > >>> HEAD. In both cases, major tom did not fail, at least not in the > >>> peculiar way. The gcc-generated code passed the PLT address of > >>> the corresponding destructor. > >> > >> That is strange, did you compile the main program with -fPIC? > >> That is the problem case. If you don't compile the main program > >> with -fPIC, the problem will indeed not occur. > > > > I just used the Makefile provided by the earlier message, and it > > contains the -fPIC flag (which is strange thing to do on its own, > > binaries should use -fPIE). > > > > This is how the registration for the outer dtr looks for me, gcc > > 4.8.1/i386: > > > > 0x08048763 <+42>: call 0x8048520 <_ZN5OuterC1Ev@plt> > > 0x08048768 <+47>: lea 0x28(%ebx),%eax > > 0x0804876e <+53>: mov %eax,0x8(%esp) > > 0x08048772 <+57>: lea 0x34(%ebx),%eax > > 0x08048778 <+63>: mov %eax,0x4(%esp) > > 0x0804877c <+67>: mov -0x4(%ebx),%eax > > 0x08048782 <+73>: mov %eax,(%esp) > > 0x08048785 <+76>: call 0x8048500 <__cxa_atexit@plt> > > > > ebx was set up earlier as the GOT pointer. > > Strange, you must have a different gcc 4.8 than me, in my case it > always uses GOT: > > call _ZN5OuterC1Ev@PLT > leal __dso_handle@GOTOFF(%ebx), %esi > addl $12, %esp > pushl %esi > pushl %edi > pushl _ZN5OuterD1Ev@GOT(%ebx) > call __cxa_atexit@PLT > > This is the lang/gcc48 port, btw. > > -Dimitry > Are you both on the same architecture? -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:20:00 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7D2211C; Wed, 26 Jun 2013 21:20:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id B002B1DEA; Wed, 26 Jun 2013 21:20:00 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 2608C19DEE6; Wed, 26 Jun 2013 21:19:59 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Ports with a broken PKGORIGIN: devel/boost-all, mail/squirrelma... From: Stefan Bethke In-Reply-To: <201306261254.r5QCsBsf005499@portsindexbuild.ysv.freebsd.org> Date: Wed, 26 Jun 2013 23:19:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201306261254.r5QCsBsf005499@portsindexbuild.ysv.freebsd.org> To: erwin@FreeBSD.org X-Mailer: Apple Mail (2.1508) Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:20:01 -0000 Am 26.06.2013 um 14:54 schrieb erwin@freebsd.org: > ** The following ports have an incorrect PKGORIGIN ** >=20 > PKGORIGIN connects packaged or installed ports to the directory they > originated from. This is essential for tools like pkg_version or > portupgrade to work correctly. Wrong PKGORIGINs are often caused by a > wrong order of CATEGORIES after a repocopy. >=20 > Please fix any errors as soon as possible. >=20 > The ports tree was updated at Wed Jun 26 2013 12:37:04 UTC. >=20 > - *mail/squirrelmail-login_auth-plugin* : = /squirrelmail-login_auth-plugin Thank you for the notice, but I'm not sure what the issue is. portlint reports this: root@diesel:/usr/ports/mail/squirrelmail-login_auth-plugin# portlint WARN: Makefile: CATEGORIES is set externally to this port's Makefile, = but this port is not configured as a slave port. 0 fatal errors and 1 warning found. Is this the reason for the change, or did a change to = bsd.squirrelmail.mk trigger the warning? Both the plugin ports as well = as the main squirrelmail port haven't been updated in months=85 Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 21:28:37 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6DBB8335; Wed, 26 Jun 2013 21:28:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D0DAF1E46; Wed, 26 Jun 2013 21:28:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5QLSXtK085740; Thu, 27 Jun 2013 00:28:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5QLSXtK085740 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5QLSXLt085739; Thu, 27 Jun 2013 00:28:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Jun 2013 00:28:33 +0300 From: Konstantin Belousov To: Michael Gmelin Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130626212833.GB91021@kib.kiev.ua> References: <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <20130626231741.497f7a9b@bsd64.grem.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/RqEFHMuhBp2bkqw" Content-Disposition: inline In-Reply-To: <20130626231741.497f7a9b@bsd64.grem.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: David Chisnall , Brooks Davis , Dimitry Andric , Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:28:37 -0000 --/RqEFHMuhBp2bkqw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote: > Are you both on the same architecture? I tested both on amd64 and i386. For i386, it was -m32 for clang, and native 32bit gcc 4.8.1, stock build from the tarball. --/RqEFHMuhBp2bkqw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRy10AAAoJEJDCuSvBvK1Bi6MQAIKDSBKslaUXvACeKd7VROdl EUbjJuSnZyO33BVqUHUeWoI/+YxFEmn5ve5uJiiEM7pu4JtosQX6htsnPf5bdN1f 6/54Jpu8b0d1MgRh7x5q2wy4Ejbj+4Qk4ygLQLhd3QL2s4mLTRstxsK8JoLd0cGB IUWlW/qFDbiTxVjItPAM+xd8JE+Mgc2uvAYJiaiPfdb8/pvhgKRRdUS/M2uTkFrM w7fQsncoxptXGWu5Kq9LdkXTG70ng7+g8KACwk8SvBx827NOGRTo/9DL+6+drX0d Z7G1lRacT+KYLItn0YCw0pp1SPYbxnUHOvGBnlXQyzH80AxkyE4LDRhtmdN5IPHu PuOmfb2PlgQsI8CZhD837N3e4xnFHf2gMRSdVprnEQMcIr4aRtf3o5y7QsUEfqj2 1DlieC6StLY3U/N6pvsS8W2JgvB8AuYEaRTG58TwfEEl/+dClTNLn+YgMnea4KBa YImfD636FENuCluD7dpqcn62t8IKsSk7DAj0zuZN2/qrMiMseAM4CykSZDiBSiK1 IHAz2+2KVVZpAp026UQ36c6JUIeQws12vzvLGKwdSzL3b+YvQV7xL7Xux7heHm/y ZZqAvDKKCJ7Lgm/Kvs7ACphYUvtwN1R7B+Q0EVEW7gd0uqA7BPy6vlYUE/4s7DQz ymtMAhrVAS0mcA9pNupd =tMzB -----END PGP SIGNATURE----- --/RqEFHMuhBp2bkqw-- From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 22:55:39 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 247E1FAE; Wed, 26 Jun 2013 22:55:39 +0000 (UTC) (envelope-from qat@redports.org) Received: from qat.redports.org (qat.redports.org [96.47.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id E5424124C; Wed, 26 Jun 2013 22:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=redports.org; s=04012012; h=Sender:Message-Id:To:Subject:Reply-To:Date:To:Cc:From:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=0vV5cAPuaap06nZdfh6M1GWrlBXiF0uq9Oytz5xJH8g=; b=gZoiXvkilNLFocx5WMxpUSst8vg9DWdAxOADnKlaLYRFiGGYeXGfn+MFCsR6boKwRJKqcRkcb9AAJzXisopnS5ZmZnEf4D0ovGGRtmqDaRF4Quvag54TKh+F1O14oAC0B5T6nv5epDMYb/6DwA2p87SIfgmku5q5dJSY29CNozw=; Received: from www by qat.redports.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uryck-000IY3-DF; Wed, 26 Jun 2013 22:55:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ports-QAT" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: jkim@FreeBSD.org X-Trac-Project: redports Date: Wed, 26 Jun 2013 22:55:38 -0000 X-URL: https://qat.redports.org/ Subject: [QAT] r321820: 4x leftovers To: jkim@FreeBSD.org X-Trac-Build-URL: https://qat.redports.org/buildarchive/20130626224800-40172 X-Trac-Build-ID: 20130626224800-40172 Message-Id: Sender: World Wide Web Owner Cc: ports@FreeBSD.org, decke@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: qat@redports.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 22:55:39 -0000 The ACPI Component Architecture (ACPICA) project provides an operating system (OS)-independent reference implementation of the Advanced Configuration and Power Interface Specification (ACPI). This port provides utilities bundled with the ACPICA release. WWW: https://acpica.org --------------------------------------------------------------------- Build ID: 20130626224800-40172 Job owner: jkim@FreeBSD.org Buildtime: 8 minutes Enddate: Wed, 26 Jun 2013 22:55:35 GMT Revision: r321820 Repository: https://svnweb.freebsd.org/ports?view=revision&revision=321820 --------------------------------------------------------------------- Port: sysutils/acpica-tools 20130626 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jkim@FreeBSD.org/20130626224800-40172-155860/acpica-tools-20130626.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jkim@FreeBSD.org/20130626224800-40172-155861/acpica-tools-20130626.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jkim@FreeBSD.org/20130626224800-40172-155862/acpica-tools-20130626.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~jkim@FreeBSD.org/20130626224800-40172-155863/acpica-tools-20130626.log -- Buildarchive URL: redports From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 23:56:09 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB2425A2 for ; Wed, 26 Jun 2013 23:56:09 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 0A7DC1786 for ; Wed, 26 Jun 2013 23:56:08 +0000 (UTC) Received: (qmail 60634 invoked by uid 89); 26 Jun 2013 23:56:00 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.170.226) by mail.grem.de with ESMTPA; 26 Jun 2013 23:56:00 -0000 Date: Thu, 27 Jun 2013 01:56:02 +0200 From: Michael Gmelin To: Konstantin Belousov Subject: Re: Global destructor order problems (was: Re: Are ports supposed to build and run on 10-CURRENT?) Message-ID: <20130627015602.7a437aad@bsd64.grem.de> In-Reply-To: <20130626212833.GB91021@kib.kiev.ua> References: <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <20130626231741.497f7a9b@bsd64.grem.de> <20130626212833.GB91021@kib.kiev.ua> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 23:56:09 -0000 On Thu, 27 Jun 2013 00:28:33 +0300 Konstantin Belousov wrote: > On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote: > > Are you both on the same architecture? > > I tested both on amd64 and i386. For i386, it was -m32 for clang, and > native 32bit gcc 4.8.1, stock build from the tarball. > For completeness sake I tested once more using various compilers including gcc 4.8.1 on 10-CURRENT amd64 (see below). I provided all information I can at this point, if there is anything else I could do to help (objdumps, etc.) please let me know. - Michael uname -a FreeBSD srv 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r251129: Thu May 30 14:34:35 UTC 2013 root@srv:/usr/obj/usr/src/sys/GENERIC amd64 [root@srv ~/majortom]# CXX=g++ make clean run gcc version 4.2.1 20070831 patched [FreeBSD] g++ -pthread -c -fPIC out.cpp -I. -I/usr/local/include -o out.o g++ -pthread -shared -fPIC out.o -o libout.so g++ -pthread -c -fPIC main.cpp -I. -I/usr/local/include -o main.o g++ -pthread -L. -lout main.o -o example Ground | Outer::Outer Control | Inner::Inner to | main() Major | Inner::~Inner Tom | Outer::~Outer [root@srv ~/majortom]# CXX=g++48 make clean run gcc version 4.8.1 20130418 (prerelease) (FreeBSD Ports Collection) g++48 -pthread -c -fPIC out.cpp -I. -I/usr/local/include -o out.o g++48 -pthread -shared -fPIC out.o -o libout.so g++48 -pthread -c -fPIC main.cpp -I. -I/usr/local/include -o main.o g++48 -pthread -L. -lout main.o -o example Ground | Outer::Outer Control | Inner::Inner to | main() Tom | Outer::~Outer Major | Inner::~Inner [root@srv ~/majortom]# CXX=clang++ make clean run FreeBSD clang version 3.3 (trunk 178860) 20130405 Target: x86_64-unknown-freebsd10.0 Thread model: posix clang++ -pthread -c -fPIC out.cpp -I. -I/usr/local/include -o out.o clang++ -pthread -shared -fPIC out.o -o libout.so clang++ -pthread -c -fPIC main.cpp -I. -I/usr/local/include -o main.o clang++ -pthread -L. -lout main.o -o example Ground | Outer::Outer Control | Inner::Inner to | main() Tom | Outer::~Outer Major | Inner::~Inner [root@srv ~/majortom]# CXX=clang++33 make clean run clang version 3.3 (tags/RELEASE_33/final) Target: amd64-portbld-freebsd10.0 Thread model: posix clang++33 -pthread -c -fPIC out.cpp -I. -I/usr/local/include -o out.o clang++33 -pthread -shared -fPIC out.o -o libout.so clang++33 -pthread -c -fPIC main.cpp -I. -I/usr/local/include -o main.o clang++33 -pthread -L. -lout main.o -o example Ground | Outer::Outer Control | Inner::Inner to | main() Tom | Outer::~Outer Major | Inner::~Inner pkg info clang clang-3.3 C, Objective-C, and C++ compiler pkg info gcc gcc-4.8.1.20130418 GNU Compiler Collection 4.8 pkg info binutils binutils-2.23.1 GNU binary tools -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 00:49:50 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A9EA9AF for ; Thu, 27 Jun 2013 00:49:50 +0000 (UTC) (envelope-from bsd-src@helfman.org) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by mx1.freebsd.org (Postfix) with ESMTP id 76D9819AD for ; Thu, 27 Jun 2013 00:49:50 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id 14so63643pdj.12 for ; Wed, 26 Jun 2013 17:49:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zQed2l+peCyaFPH8/ILrAkpdWKyTbUGIkKyJSgToTb0=; b=neO1y2epREanDg3IdoxDmkZ/xkw5T3lcSc+LzJToBgzZjueca8KdkfMrW5QRNRNTed 4Er3slGNSC2AXOQbu6ylcUBFSmXGjFW98Yvf3VUnCVKDLLWKlsgCw1YgPylCyF3ILtNg 93s3HxYThBiDuHH61gF9gCylWJ14HmGNX9D0Ywm3zmfii5jTFdryO0aD8xuLkVB+tZPp a0Gmi/by9nJ1ck8WIXxLk/eWtq7kWbSJ1jkXqhHGQqi7S7NuQyjSFBCU7S6hCZjwgrkz IJc+3OGB4dJ3JjW2BnvOz2jiMi/Ci6PQDGW1Vr0F+AtWZlrt/444i1TeOOAtuTyhcN0/ PsbA== MIME-Version: 1.0 X-Received: by 10.66.9.72 with SMTP id x8mr3278906paa.13.1372293762162; Wed, 26 Jun 2013 17:42:42 -0700 (PDT) Sender: bsd-src@helfman.org Received: by 10.70.1.226 with HTTP; Wed, 26 Jun 2013 17:42:42 -0700 (PDT) In-Reply-To: References: <201306261254.r5QCsBsf005499@portsindexbuild.ysv.freebsd.org> Date: Wed, 26 Jun 2013 17:42:42 -0700 X-Google-Sender-Auth: OxLPubg0AAv0AzkkIjKqE9NoWQM Message-ID: Subject: Re: Ports with a broken PKGORIGIN: devel/boost-all, mail/squirrelma... From: Jason Helfman To: Stefan Bethke X-Gm-Message-State: ALoCoQnRo0Gf5oFqTOgH592n/D+lKYPRt388kHjOA9jG2vPiiT7EI+7C3jTkWvvCBgBzP8s1PDs6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 00:49:50 -0000 On Wed, Jun 26, 2013 at 2:19 PM, Stefan Bethke wrote: > Am 26.06.2013 um 14:54 schrieb erwin@freebsd.org: > > > ** The following ports have an incorrect PKGORIGIN ** > > > > PKGORIGIN connects packaged or installed ports to the directory they > > originated from. This is essential for tools like pkg_version or > > portupgrade to work correctly. Wrong PKGORIGINs are often caused by a > > wrong order of CATEGORIES after a repocopy. > > > > Please fix any errors as soon as possible. > > > > The ports tree was updated at Wed Jun 26 2013 12:37:04 UTC. > > > > > - *mail/squirrelmail-login_auth-plugin* : > /squirrelmail-login_auth-plugin > > Thank you for the notice, but I'm not sure what the issue is. > > portlint reports this: > root@diesel:/usr/ports/mail/squirrelmail-login_auth-plugin# portlint > WARN: Makefile: CATEGORIES is set externally to this port's Makefile, but > this port is not configured as a slave port. > 0 fatal errors and 1 warning found. > > Is this the reason for the change, or did a change to bsd.squirrelmail.mk= trigger the warning? Both the plugin ports as well as the main > squirrelmail port haven't been updated in months=85 > > > Thanks, > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > This may have something to do with it, but not saying this *is* the reaso= n. http://svnweb.freebsd.org/ports?view=3Drevision&revision=3D321785 -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh | The Power to Serve From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 08:02:20 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 984763C8; Thu, 27 Jun 2013 08:02:20 +0000 (UTC) (envelope-from qat@redports.org) Received: from qat.redports.org (qat.redports.org [96.47.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE5410D7; Thu, 27 Jun 2013 08:02:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=redports.org; s=04012012; h=Sender:Message-Id:To:Subject:Reply-To:Date:To:Cc:From:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Rg74hhi0jvqcPhoqZ5ySnSd0PrKi5fvQQVI8x6WI27A=; b=5PXee1sz3aZS8ckIFj8t13OiRIRmV7gTXi51lM/hbRzphOZjeMzPShvsuX+culRp5tzwiNRRAG7nca0iv6bAY2IobbrgaM9067MA46gTk5M2GrU8EK/WorbbhL9LHjucQsQeZcx8gAEGhFlwRrw2kb3nT6yKelkk87UK5iS1uF4=; Received: from www by qat.redports.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Us79m-00037O-CC; Thu, 27 Jun 2013 08:02:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ports-QAT" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: flo@FreeBSD.org X-Trac-Project: redports Date: Thu, 27 Jun 2013 08:02:18 -0000 X-URL: https://qat.redports.org/ Subject: [QAT] r321867: 4x leftovers To: flo@FreeBSD.org X-Trac-Build-URL: https://qat.redports.org/buildarchive/20130627072201-51381 X-Trac-Build-ID: 20130627072201-51381 Message-Id: Sender: World Wide Web Owner Cc: ports@FreeBSD.org, decke@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: qat@redports.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 08:02:20 -0000 Update distinfo to 22.0 PR: ports/180020 Submitted by: Volodymyr Kostyrko --------------------------------------------------------------------- Build ID: 20130627072201-51381 Job owner: flo@FreeBSD.org Buildtime: 40 minutes Enddate: Thu, 27 Jun 2013 08:02:15 GMT Revision: r321867 Repository: https://svnweb.freebsd.org/ports?view=revision&revision=321867 --------------------------------------------------------------------- Port: www/firefox-i18n 22.0 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flo@FreeBSD.org/20130627072201-51381-156048/firefox-i18n-22.0.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flo@FreeBSD.org/20130627072201-51381-156049/firefox-i18n-22.0.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flo@FreeBSD.org/20130627072201-51381-156050/firefox-i18n-22.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flo@FreeBSD.org/20130627072201-51381-156051/firefox-i18n-22.0.log -- Buildarchive URL: redports From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 08:59:44 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 755BDA0C; Thu, 27 Jun 2013 08:59:44 +0000 (UTC) (envelope-from qat@redports.org) Received: from qat.redports.org (qat.redports.org [96.47.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA821360; Thu, 27 Jun 2013 08:59:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=redports.org; s=04012012; h=Sender:Message-Id:To:Subject:Reply-To:Date:To:Cc:From:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=ArNTI9vj7myTAZVPGayI6YQScbW5/a5YXnbhR4vrxJw=; b=ltb/XXtK39v0dWW6AHOYaNy1pvzmstAfw5+62pDX62XwTp+iiIYgufJpJpRvqMjw40SwvG6kJm0WimDnxnTYRwFYVo3rf6bk1IzOOEnGhi2pC81LuPWJqwf3rdNOuF/Q90Aeu0ou8/dfPqeXTXSHsYoYbG07BZoUpkhJiEjAfO0=; Received: from www by qat.redports.org with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Us83M-0006wK-1D; Thu, 27 Jun 2013 08:59:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ports-QAT" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: timur@FreeBSD.org X-Trac-Project: redports Date: Thu, 27 Jun 2013 08:59:43 -0000 X-URL: https://qat.redports.org/ Subject: [QAT] r321875: 4x leftovers To: timur@FreeBSD.org X-Trac-Build-URL: https://qat.redports.org/buildarchive/20130627084800-25541 X-Trac-Build-ID: 20130627084800-25541 Message-Id: Sender: World Wide Web Owner Cc: ports@FreeBSD.org, decke@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: qat@redports.org List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 08:59:44 -0000 Upgraded port to the latest 3.6.16 revision. --------------------------------------------------------------------- Build ID: 20130627084800-25541 Job owner: timur@FreeBSD.org Buildtime: 12 minutes Enddate: Thu, 27 Jun 2013 08:59:42 GMT Revision: r321875 Repository: https://svnweb.freebsd.org/ports?view=revision&revision=321875 --------------------------------------------------------------------- Port: net/samba36 3.6.16 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~timur@FreeBSD.org/20130627084800-25541-156076/samba36-3.6.16.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~timur@FreeBSD.org/20130627084800-25541-156077/samba36-3.6.16.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~timur@FreeBSD.org/20130627084800-25541-156078/samba36-3.6.16.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~timur@FreeBSD.org/20130627084800-25541-156079/samba36-3.6.16.log -- Buildarchive URL: redports From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 09:42:34 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B65FF69 for ; Thu, 27 Jun 2013 09:42:34 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org (unknown [IPv6:2001:1900:2254:206a::50:123]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB301732 for ; Thu, 27 Jun 2013 09:42:34 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.7/8.14.7) with ESMTP id r5R9gYGt055602 for ; Thu, 27 Jun 2013 09:42:34 GMT (envelope-from portscout@portscout.freebsd.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.7/8.14.6/Submit) id r5R9gYdB055601; Thu, 27 Jun 2013 09:42:34 GMT (envelope-from portscout) Message-Id: <201306270942.r5R9gYdB055601@portscout.freebsd.org> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Thu, 27 Jun 2013 09:42:34 +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.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:42:34 -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 ------------------------------------------------+-----------------+------------ games/freecell-solver | 3.18.1 | 3.20.0 ------------------------------------------------+-----------------+------------ www/xpi-pentadactyl | 20130407 | 20130627 ------------------------------------------------+-----------------+------------ 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 If wish to stop receiving portscout reminders, please contact portscout@FreeBSD.org Thanks. From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 09:47:23 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 714E2199 for ; Thu, 27 Jun 2013 09:47:23 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 32B651782 for ; Thu, 27 Jun 2013 09:47:22 +0000 (UTC) Received: from kaa.mimar.rs (unknown [193.53.106.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 21680B902B; Thu, 27 Jun 2013 11:39:21 +0200 (CEST) Date: Thu, 27 Jun 2013 11:39:20 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: joh.hendriks@gmail.com Subject: Re: dovecot2 fails to update in combination with pigeonhole-0.4.0 Message-Id: <20130627113920.42b6974f26fb63a23384fe08@mimar.rs> In-Reply-To: References: Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:47:23 -0000 I solved this by de-selecting "EXAMPLES" option in mail/dovecot2-pigeonhole: # cd /usr/ports/mail/dovecot2-pigeonhole # make config # portmaster -d dovecot2 -- Marko Cupać From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 09:54:20 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 482CA2D2 for ; Thu, 27 Jun 2013 09:54:20 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id DA89A17D7 for ; Thu, 27 Jun 2013 09:54:19 +0000 (UTC) Received: (qmail 74929 invoked by uid 89); 27 Jun 2013 09:54:17 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.167.13) by mail.grem.de with ESMTPA; 27 Jun 2013 09:54:17 -0000 Date: Thu, 27 Jun 2013 11:54:17 +0200 From: Michael Gmelin To: freebsd-ports@freebsd.org Subject: Could somebody look into pr 172547 Message-ID: <20130627115417.0249201f@bsd64.grem.de> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:54:20 -0000 I just ran into the same problem while using DESTDIR. http://www.freebsd.org/cgi/query-pr.cgi?pr=172547&cat= Thanks -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 12:20:43 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0E1ACE1E for ; Thu, 27 Jun 2013 12:20:43 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id CA7761FB4 for ; Thu, 27 Jun 2013 12:20:42 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 01169E6B0E for ; Thu, 27 Jun 2013 13:20:42 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=Ipwl5fyaSKpxta31QUljLUxwj EA=; b=XAzK8nmd+6HMtdyVyFL8ADmN1JqOWaToWG01XZNsKD6y2f+tq6XqTA4oT KNf064Cndassumu0HzqI/LX9HtXfoUh53gYFEBh7zaCVm2oT1HlHDWZyko3SzFkN AYO6XlELrGcCfUmzvIuJ1ioA0u/Kj4e9Da9wU/RCcgIdzPNX84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=Z1bH+89iFgSyTwoxxJw dXXIlEzc2eKVeQfGz0aMn0NVT+TQoNV2yYYj54kUwj8Cp3cXIDE1O/r1B4GNQkzG AfaCpmQ0vFRf8bnFB0WVPPMYW9LDLIO+MpFT64EccLpbDtVhlnJYPRl3XLXEtpOu oYpEDwJdbZhpPRDetsY/P4gs= Received: from [IPv6:2a01:348:301:2:ccf1:925a:43f8:4bbc] (unknown [IPv6:2a01:348:301:2:ccf1:925a:43f8:4bbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id CCC8DE6AEC for ; Thu, 27 Jun 2013 13:20:41 +0100 (BST) Message-ID: <51CC2E18.4090802@cran.org.uk> Date: Thu, 27 Jun 2013 13:20:40 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:20:43 -0000 I've given up my commit bit: could someone reset the maintainer for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock please? -- Bruce Cran (brucec) From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 12:28:26 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18BA91FE for ; Thu, 27 Jun 2013 12:28:26 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id BDEA01025 for ; Thu, 27 Jun 2013 12:28:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E7C7B4001D for ; Thu, 27 Jun 2013 14:28:24 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DD40B4001C; Thu, 27 Jun 2013 14:28:24 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8FD5740012; Thu, 27 Jun 2013 14:28:23 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bh0kv2nfbz8hVn; Thu, 27 Jun 2013 14:28:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id MXJ7qYQ-qCvV; Thu, 27 Jun 2013 14:28:21 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bh0ks2Px6z8hVm; Thu, 27 Jun 2013 14:28:21 +0200 (CEST) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bh0ks1l06z9Ctq; Thu, 27 Jun 2013 14:28:21 +0200 (CEST) Message-ID: <51CC2FE4.6010007@freebsd.org> Date: Thu, 27 Jun 2013 14:28:20 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Bruce Cran Subject: Re: Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock References: <51CC2E18.4090802@cran.org.uk> In-Reply-To: <51CC2E18.4090802@cran.org.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:28:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/27/13 14:20, Bruce Cran wrote: > I've given up my commit bit: could someone reset the maintainer > for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock > please? > Done. Thank you for your support! Regards! - -- Niclas Zeising -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCgAGBQJRzC/iAAoJELuNS1e7i1VRN0MP/RTGUSUPO+nWxfQ6bL86yqkp fSq8nG2+ErkorxwSRF6mG2LIjuQWhygaRlDWtSlPlTYRoKCDYYKsv0M1XGhpOxJj tQov1jsDCuMz2Az9/kJ4hJtiIwieWFtpWcFiD8MeHaZpXqVKuM7JOLktkkKRvTl5 L15iARF/tOkRaSmHAeGmNKnRBoQmwq+SxdzqjVWliYh34l9PQVxsyV1goAwnTBZ5 BBPadJqFRBEwrDmfhnq03QF9QWdLCuVmvGvQLMSuU6nezpCjalccywrFLnWIKYh3 Nv+cYo7TSTNAQw+3uQw90EW48XyZRlJwMS9iGxoxSwBamsNVMw7d2rNIA/9F36N1 WIJ1pLZLpFXd4HEYtw1Ztj7yUeE+KmXMb/q5DmcNGq6AMZtB5ZAkMKGv0sKrl6i7 ArtUm9oTtnosX99cv95lQdx2Tnj8NnzPtE2r91lgrjPqUgBV+7q+WIUeRQd19FZP ISJMKv4vv/tYCGxi8nm1d2eJ6RzCfioOXYhuPbFwAqRHGqjgfw2h7xuhFhnawAYl ktyQ6Q00w3yJBfmmjYDrXMJWjm5BajpOY12HRy9wIlAwW4hEdMAzo4iujAWP2JfW oD2wJlqQAumkhwk98R8/QLUdw+E4teQkpPOcLrC/1fOpY/z5vbw/y066uzpauBmp tyDlihOtIIqBCZXkUlfy =pkju -----END PGP SIGNATURE----- From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 13:41:49 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 537C8E3B; Thu, 27 Jun 2013 13:41:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 131851658; Thu, 27 Jun 2013 13:41:48 +0000 (UTC) Received: from spaceball.andric.com (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E10885C43; Thu, 27 Jun 2013 15:41:45 +0200 (CEST) Message-ID: <51CC411C.4060105@FreeBSD.org> Date: Thu, 27 Jun 2013 15:41:48 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Michael Gmelin , Konstantin Belousov Subject: Re: Global destructor order problems References: <20130626015508.426ab5b9@bsd64.grem.de> <51CAADB8.7090603@FreeBSD.org> <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <20130626231741.497f7a9b@bsd64.grem.de> <20130626212833.GB91021@kib.kiev.ua> <20130627015602.7a437aad@bsd64.grem.de> In-Reply-To: <20130627015602.7a437aad@bsd64.grem.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis , David Chisnall , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:41:49 -0000 On 2013-06-27 01:56, Michael Gmelin wrote: > On Thu, 27 Jun 2013 00:28:33 +0300 > Konstantin Belousov wrote: > >> On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote: >>> Are you both on the same architecture? >> >> I tested both on amd64 and i386. For i386, it was -m32 for clang, and >> native 32bit gcc 4.8.1, stock build from the tarball. >> > > For completeness sake I tested once more using various compilers > including gcc 4.8.1 on 10-CURRENT amd64 (see below). I have now tested the lang/gcc44, 46, 47, 48 and 49 ports, on both i386 and amd64. All result in the incorrect destructor order. -Dimitry From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 14:04:32 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AB1558A; Thu, 27 Jun 2013 14:04:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0B53B176A; Thu, 27 Jun 2013 14:04:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r5RE4STB010282; Thu, 27 Jun 2013 17:04:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5RE4STB010282 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5RE4SP1010281; Thu, 27 Jun 2013 17:04:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Jun 2013 17:04:28 +0300 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Global destructor order problems Message-ID: <20130627140428.GI91021@kib.kiev.ua> References: <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <20130626231741.497f7a9b@bsd64.grem.de> <20130626212833.GB91021@kib.kiev.ua> <20130627015602.7a437aad@bsd64.grem.de> <51CC411C.4060105@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OHOABd/r1N6D/+xo" Content-Disposition: inline In-Reply-To: <51CC411C.4060105@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-ports@freebsd.org Ports" , Brooks Davis , David Chisnall , Matthias Andree , Michael Gmelin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:04:32 -0000 --OHOABd/r1N6D/+xo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2013 at 03:41:48PM +0200, Dimitry Andric wrote: > On 2013-06-27 01:56, Michael Gmelin wrote: > > On Thu, 27 Jun 2013 00:28:33 +0300 > > Konstantin Belousov wrote: > > > >> On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote: > >>> Are you both on the same architecture? > >> > >> I tested both on amd64 and i386. For i386, it was -m32 for clang, and > >> native 32bit gcc 4.8.1, stock build from the tarball. > >> > > > > For completeness sake I tested once more using various compilers > > including gcc 4.8.1 on 10-CURRENT amd64 (see below). >=20 > I have now tested the lang/gcc44, 46, 47, 48 and 49 ports, on both i386 > and amd64. All result in the incorrect destructor order. My build of gcc is stock, not from the ports. Another detail, I built the compiler on stable/9, but use it on both stable and current. I am very curious what makes the my build to generate the code which uses PLT instead of direct reference, but have no time to investigate. I think that we could revert the termination calls to the functions =66rom the dso being unloaded, but this is quite unfortunate, since it will restore the endless series of 'segfault at the process termination' reports. --OHOABd/r1N6D/+xo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzEZrAAoJEJDCuSvBvK1BRzsP/34vWkdhOfnjvkcANTyKpuZx a5RP05npxVnNgx/1m131IlBvvltmjVitRan6GrDsNi3qTniMbUWCD4dOmHSq/Dul c5YXcXvJ6PiHnKRLRjm5AfvbbCjI2AE10xxLUpCdm6GY/xw6HLOLANQADwjtd4Km /StBg1YizfWZEr2N9IkC4Ynxcjoy0B4wd/a2NnFrqwR8+LwkpuzbF18p/ecYPWs1 MGI+fhbd4ulOLCxzn4eoltaDY8m7/7KkqQgi4QXF+BveG9AqiQBqQYyW0oZ87XhN 8ClPe/JCrSk4AyvFgcjBRMT2wGvvdg83ta/5l+5237o8EFk/vez+Zx6ETR9dL2Qm t7KBSDuRQXOtfghU+b4YWYSjOmsTFthDo+Z8qm9hA82NMFbwboiUMxfvDvb5LIMC CjERJT7nw/F+FXUBmGain2gBWg+EHqlDrSYbHnfIodQq1UesAf2JAM80+mZTZX3p Mw/atNTKb9g07FSB7gMIaaEBvlbR8+8of2dc6M36sp657EncS9P9QUoUnRdvdGUr 4c5Ac75w9txBlWA75tN6HRZZ2ZTX6m4Eme+A3iK44ZVbVDJ3Ok3UP+7ZUcWqKvbw 3DC/W13ntCwHj812g26VtM7fNBFyGxa6xhU4bha1oQk7nmoOf+IodP2LeI0IQ4jn 2ClgV0atCOjMJqo936Mx =iSDB -----END PGP SIGNATURE----- --OHOABd/r1N6D/+xo-- From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 16:03:01 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F8D7DCF for ; Thu, 27 Jun 2013 16:03:01 +0000 (UTC) (envelope-from sjk4015@gmail.com) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 3EDE61FB6 for ; Thu, 27 Jun 2013 16:03:01 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id xb12so1087605pbc.40 for ; Thu, 27 Jun 2013 09:03:01 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6vq5fAa5WP7agee/NfzHTcTirJm9cCvE/kDnk0gQ2j8=; b=iH8skPmX9Bqg161RDIqUSA4oJkccBHXFg/ZE5LVH+upfiiEGBkWCJxsGv+/7Ek6rtM 3R9WjzsEaM56vfRUuiQQ3fGHdFGdwdEalZePTsQmj69r69SBMYuFaVtzSJnA4EwEloSS YdFMpvbmNDhEpk/DdABiD7mo5T8fyYWR1PnTcgOqNyBiGB5XIcHblIaO8Pso2Yrb4ERB 9+Am5/aP6muQhOKlFJUsLibiR9aQ88MjChD4DkIHDDB0oqS4R1Vb6lXAvRW0EMWA9c/2 GyhX6Q21+yTiwwNwhfWy9WKJQAxrpn6419hr5uw1/+mHm9xzqnxgNgOheczbjvkhtkRC wUeA== MIME-Version: 1.0 X-Received: by 10.69.2.228 with SMTP id br4mr6729227pbd.91.1372348980994; Thu, 27 Jun 2013 09:03:00 -0700 (PDT) Sender: sjk4015@gmail.com Received: by 10.68.195.199 with HTTP; Thu, 27 Jun 2013 09:03:00 -0700 (PDT) In-Reply-To: <51CC2E18.4090802@cran.org.uk> References: <51CC2E18.4090802@cran.org.uk> Date: Thu, 27 Jun 2013 12:03:00 -0400 X-Google-Sender-Auth: gaKfwtItroHwykBX4uplc2R5QV0 Message-ID: Subject: Re: Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock From: Steven Kreuzer To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:03:01 -0000 On Thu, Jun 27, 2013 at 8:20 AM, Bruce Cran wrote: > I've given up my commit bit: could someone reset the maintainer for > benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock please? I've adopted benchmarks/fio from you. Thanks for maintaining over the past couple of years From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 16:17:35 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5117433C; Thu, 27 Jun 2013 16:17:35 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id E3C101058; Thu, 27 Jun 2013 16:17:34 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 51972E6B0E; Thu, 27 Jun 2013 17:17:33 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=mail; bh=ndHLNyiVaiRjqd3VDkoSquOaziM=; b=H7cGKL 8d0sRuf/QjB7gt6GHDMVSx2cJRlp51RY1ikFa1aBQa0lULuXrLpgQ1ZiXwLA84LS D7BcZSN+N4tMqcKaedHfvF/ltRC8hQASPIbO6t8wtjAUTO83qsLjcbwq/ugzuS+I B199LD+JfJYi5CxUpakQPqz9hPRLuIL8hMEkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=mail; b=bycOpfJDOXGmtYzm8olNANFdgaesvGrY lSLTdGAVDpgxvVEJSzbX6fYqJyLM/VLEnCqQzGbu2s4Vnb0p/Y/W9g+t0f06JShP 5FaBQJEovaYqI2OYzbfoxwCIe6xJUwHmLLTTxYRkY9vKfOlTXDY/YZkrio0om1s2 7vrXiYu6gIc= Received: from [IPv6:2a01:348:301:2:ccf1:925a:43f8:4bbc] (unknown [IPv6:2a01:348:301:2:ccf1:925a:43f8:4bbc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 20956E6AEC; Thu, 27 Jun 2013 17:17:33 +0100 (BST) Message-ID: <51CC659A.4020409@cran.org.uk> Date: Thu, 27 Jun 2013 17:17:30 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Steven Kreuzer Subject: Re: Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock References: <51CC2E18.4090802@cran.org.uk> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050901020104010209050906" Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:17:35 -0000 This is a multi-part message in MIME format. --------------050901020104010209050906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 27/06/2013 17:03, Steven Kreuzer wrote: > I've adopted benchmarks/fio from you. Thanks. It needs updated to 2.1.1 - I've attached the patch, though the Makefile change probably won't apply now. -- Bruce --------------050901020104010209050906 Content-Type: text/plain; charset=windows-1252; name="fio.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fio.diff" Index: Makefile =================================================================== --- Makefile (revision 321878) +++ Makefile (working copy) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= fio -PORTVERSION= 2.0.15 +PORTVERSION= 2.1.1 CATEGORIES= benchmarks MASTER_SITES= http://brick.kernel.dk/snaps/ Index: distinfo =================================================================== --- distinfo (revision 321878) +++ distinfo (working copy) @@ -1,2 +1,2 @@ -SHA256 (fio-2.0.15.tar.bz2) = 3cc1b5e6c6955f9acad016b4d2ef619061ad9937874c7663e2a29777ed845ac4 -SIZE (fio-2.0.15.tar.bz2) = 258773 +SHA256 (fio-2.1.1.tar.bz2) = bbe68cb9b6d4c5ec3da4dbf22b30605358bf593702baae4566ec291ac3d8076b +SIZE (fio-2.1.1.tar.bz2) = 316673 Index: pkg-plist =================================================================== --- pkg-plist (revision 321878) +++ pkg-plist (working copy) @@ -1,25 +1,25 @@ bin/fio bin/fio_generate_plots -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/1mbs_clients -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/aio-read -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/cpuio -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/disk-zone-profile -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/e4defrag -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/e4defrag2 -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/enospc-pressure -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/falloc -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/flow -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/fsx +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/1mbs_clients.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/aio-read.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/cpuio.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/disk-zone-profile.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/e4defrag.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/e4defrag2.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/enospc-pressure.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/falloc.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/flow.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/fsx.fio %%PORTEXAMPLES%%%%EXAMPLESDIR%%/fusion-aw-sync.ini -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/iometer-file-access-server -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/netio -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/null -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/numa -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/rdmaio-client -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/rdmaio-server +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/iometer-file-access-server.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/netio.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/null.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/numa.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/rdmaio-client.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/rdmaio-server.fio %%PORTEXAMPLES%%%%EXAMPLESDIR%%/ssd-steadystate.fio -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/ssd-test -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/surface-scan -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/tiobench-example -%%PORTEXAMPLES%%%%EXAMPLESDIR%%/zipf +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/ssd-test.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/surface-scan.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/tiobench-example.fio +%%PORTEXAMPLES%%%%EXAMPLESDIR%%/zipf.fio %%PORTEXAMPLES%%@dirrm %%EXAMPLESDIR%% --------------050901020104010209050906-- From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 17:39:27 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE24E629 for ; Thu, 27 Jun 2013 17:39:27 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 2582F1487 for ; Thu, 27 Jun 2013 17:39:26 +0000 (UTC) Received: (qmail 81100 invoked by uid 89); 27 Jun 2013 17:39:24 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.167.13) by mail.grem.de with ESMTPA; 27 Jun 2013 17:39:24 -0000 Date: Thu, 27 Jun 2013 19:39:24 +0200 From: Michael Gmelin To: Konstantin Belousov Subject: Re: Global destructor order problems Message-ID: <20130627193924.04a5e89e@bsd64.grem.de> In-Reply-To: <20130627140428.GI91021@kib.kiev.ua> References: <20130626133149.4835f14a@bsd64.grem.de> <7CD9075C-F8D6-41C1-8D21-8B10DF866ECE@FreeBSD.org> <20130626204521.GU91021@kib.kiev.ua> <6900C006-2A57-4EAF-B19A-629A85CBA001@FreeBSD.org> <20130626210534.GY91021@kib.kiev.ua> <20130626231741.497f7a9b@bsd64.grem.de> <20130626212833.GB91021@kib.kiev.ua> <20130627015602.7a437aad@bsd64.grem.de> <51CC411C.4060105@FreeBSD.org> <20130627140428.GI91021@kib.kiev.ua> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Chisnall , Brooks Davis , Dimitry Andric , "freebsd-ports@freebsd.org Ports" , Matthias Andree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:39:27 -0000 On Thu, 27 Jun 2013 17:04:28 +0300 Konstantin Belousov wrote: > On Thu, Jun 27, 2013 at 03:41:48PM +0200, Dimitry Andric wrote: > > On 2013-06-27 01:56, Michael Gmelin wrote: > > > On Thu, 27 Jun 2013 00:28:33 +0300 > > > Konstantin Belousov wrote: > > > > > >> On Wed, Jun 26, 2013 at 11:17:41PM +0200, Michael Gmelin wrote: > > >>> Are you both on the same architecture? > > >> > > >> I tested both on amd64 and i386. For i386, it was -m32 for > > >> clang, and native 32bit gcc 4.8.1, stock build from the tarball. > > >> > > > > > > For completeness sake I tested once more using various compilers > > > including gcc 4.8.1 on 10-CURRENT amd64 (see below). > > > > I have now tested the lang/gcc44, 46, 47, 48 and 49 ports, on both > > i386 and amd64. All result in the incorrect destructor order. > > My build of gcc is stock, not from the ports. Another detail, I built > the compiler on stable/9, but use it on both stable and current. I am > very curious what makes the my build to generate the code which uses > PLT instead of direct reference, but have no time to investigate. > > I think that we could revert the termination calls to the functions > from the dso being unloaded, but this is quite unfortunate, since it > will restore the endless series of 'segfault at the process > termination' reports. Do you have a simple real world example of the original problem (you mentioned PHP, but not which combination of extensions etc.)? Maybe there's a better solution. -- Michael Gmelin From owner-freebsd-ports@FreeBSD.ORG Thu Jun 27 20:13:11 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30C777BB for ; Thu, 27 Jun 2013 20:13:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 00EA41C98 for ; Thu, 27 Jun 2013 20:13:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5RKDAQR002742 for ; Thu, 27 Jun 2013 20:13:10 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5RKDANu002731 for ports@freebsd.org; Thu, 27 Jun 2013 20:13:10 GMT (envelope-from bdrewery) Received: (qmail 50239 invoked from network); 27 Jun 2013 15:13:08 -0500 Received: from unknown (HELO ?192.168.1.137?) (freebsd@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 27 Jun 2013 15:13:08 -0500 Message-ID: <51CC9CD6.7000302@FreeBSD.org> Date: Thu, 27 Jun 2013 15:13:10 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Ports , pkg@Freebsd.org Subject: [HEADS UP] portmaster 3.17 detects pkgng differently X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PSCSUDAABMKFRHCQVQEM" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:13:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PSCSUDAABMKFRHCQVQEM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since June 22nd, portmaster no longer relies on 'WITH_PKGNG' to be defined, or ports to be checked out to enable pkgng support. It now considers whether or not pkg is installed and registered with itse= lf. I.e., if this returns data, pkgng is considered in use: # pkg info pkg It's possible that you may have tested pkgng in the past, ran pkg2ng, and never fully committed to it by setting WITH_PKGNG. If this is the case, uninstall pkg with pkg_delete and also remove the stale database, rm /var/db/pkg/local.sqlite. This could manifest itself as portmaster -L showing the wrong versions, or portmaster no longer detecting installed packages correctly. Note that PORTS still require WITH_PKGNG=3Dyes in make.conf if you are no= t running CURRENT. --=20 Regards, Bryan Drewery ------enig2PSCSUDAABMKFRHCQVQEM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRzJzWAAoJEG54KsA8mwz5pb8P/1mPx/zfMeCbzbeeoFEPZ6m6 FQHEF9l5aoPxf9BuT9yozqBrTMeTR6zS/gvXXaYuk7EeU6wYXxh6F6SdE0wGUYLu nyRCBpxWO30ekCQQbXhakZHSLPYWcZF1k5ZVKhoMkzXdjX2vYwTpGdDcRaY1I5S1 qxjUryoJ+abE48nxl/1dX3xKzLYFQGqFNqbhngTBxVwkz1fwdKCqgyFLmN9ZllUM vzgnHq0gQxHGaq8oPf5/1NvOmT85OBEfMoAiQ7tTaZe9irIrmyMfQ/iEtSqnQtI9 J45jHf5dJ+ONI0O3bj7XR8KArwlJ6WSJBq9g+UQoKV7ytdHW11gYcPoYmJMC/co6 buyoIkNgyndGGxfdePrSg4Ack2bu6C3GmQUm05U1PPEgqGn5VAUd3qszxHcum4mC LnbqxGq9OFzvS6vJHZ/FReybr/gitrS8B9c8qHR4ggCYUTfAqD9NdXMBykJAvECz OesPNkNUpUa9jy5aQveH0VAJ+124HT5HI81iYbReSrtStIJ0ic8j6+dffsXt0XjA a8SsoKGaGqW/Kh2O0tCxQfln4v4s6G19+GWq/BOc246/Yi/lRwFJSzQAYqhnvMwY Q35WqdxGe2U0+q5NkCjiiJoGK87ezLSxdDQkyiV7zN/rkQzpBmmJsVhuEVCDzFyw BmzmP6uU81FtmkekmOtt =Hq90 -----END PGP SIGNATURE----- ------enig2PSCSUDAABMKFRHCQVQEM-- From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 09:58:27 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D7EB939 for ; Fri, 28 Jun 2013 09:58:27 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org (unknown [IPv6:2001:1900:2254:206a::50:123]) by mx1.freebsd.org (Postfix) with ESMTP id 904E71F42 for ; Fri, 28 Jun 2013 09:58:27 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.7/8.14.7) with ESMTP id r5S9wRTG000643 for ; Fri, 28 Jun 2013 09:58:27 GMT (envelope-from portscout@portscout.freebsd.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.7/8.14.6/Submit) id r5S9wRqv000642; Fri, 28 Jun 2013 09:58:27 GMT (envelope-from portscout) Message-Id: <201306280958.r5S9wRqv000642@portscout.freebsd.org> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Fri, 28 Jun 2013 09:58:27 +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.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 09:58:27 -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 ------------------------------------------------+-----------------+------------ games/wmpuzzle | 0.5.1 | 0.5.2 ------------------------------------------------+-----------------+------------ print/lout | 3.39 | 3.40 ------------------------------------------------+-----------------+------------ www/xpi-pentadactyl | 20130407 | 20130628 ------------------------------------------------+-----------------+------------ 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 If wish to stop receiving portscout reminders, please contact portscout@FreeBSD.org Thanks. From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 12:04:32 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52A1A2E5; Fri, 28 Jun 2013 12:04:32 +0000 (UTC) (envelope-from megasoft99@mail.ru) Received: from fallback4.mail.ru (fallback4.mail.ru [94.100.176.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0771F1601; Fri, 28 Jun 2013 12:04:31 +0000 (UTC) Received: from f100.mail.ru (f100.mail.ru [94.100.178.72]) by fallback4.mail.ru (mPOP.Fallback_MX) with ESMTP id 5D5E51D92B6; Fri, 28 Jun 2013 16:02:50 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:To:From; bh=DcrPG2ZRVWScbHXE9GikGUlrJZRlq2FziExWdP8NHtM=; b=AJvRNUSg+V8eKJSLKvnLPzbmMQ10O1Fl0z2kn0jFkZFcCXtqBIlweCFEqUrANU1CA/yVg7nXk5GlHQ0jCySyR2bd/L4B01F+klFRWsHeUmnIS0PwZJDOadZljXRkwQyPI990BMMcJbPrHn5cUsQNdoyDazOMyKSqbKj03PkrtzU=; Received: from mail by f100.mail.ru with local (envelope-from ) id 1UsXNz-0005CE-1g; Fri, 28 Jun 2013 16:02:43 +0400 Received: from [46.32.68.46] by e.mail.ru with HTTP; Fri, 28 Jun 2013 16:02:43 +0400 From: =?UTF-8?B?0KHQtdGA0LPQtdC5INCf0YDQvtC60L7RhNGM0LXQsg==?= To: =?UTF-8?B?b3NhQEZyZWVCU0Qub3Jn?= , =?UTF-8?B?cG9ydHNARnJlZUJTRC5vcmc=?= Subject: =?UTF-8?B?RnJlZUJTRCBQb3J0OiBuZ2lueC0xLjQuMV8xLDE=?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [46.32.68.46] Date: Fri, 28 Jun 2013 16:02:43 +0400 X-Priority: 3 (Normal) Message-ID: <1372420962.158605522@f100.mail.ru> X-Spam: Not detected X-Mras: Ok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?0KHQtdGA0LPQtdC5INCf0YDQvtC60L7RhNGM0LXQsg==?= List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:04:32 -0000 CkhpIQpJIGNhbiBub3QgCmluc3RhbGwgTmdpbnggd2l0aCBSVE1QIG1vZHVsZSBmb3IgMyAKd2Vl a3MgLgpCZWZvcmUgd29ya2VkIApub3JtYWxseS4KwqAKU2VyZ2V5Lgo= From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 12:31:32 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B458820 for ; Fri, 28 Jun 2013 12:31:32 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog125.obsmtp.com (eu1sys200aog125.obsmtp.com [207.126.144.159]) by mx1.freebsd.org (Postfix) with ESMTP id EEF381756 for ; Fri, 28 Jun 2013 12:31:31 +0000 (UTC) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by eu1sys200aob125.postini.com ([207.126.147.11]) with SMTP ID DSNKUc2CCMyRbVaHhHyGzop35fYPZghUWmhW@postini.com; Fri, 28 Jun 2013 12:31:32 UTC Received: by mail-wi0-f172.google.com with SMTP id c10so694882wiw.17 for ; Fri, 28 Jun 2013 05:31:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:message-id:to:subject:reply-to:x-gm-message-state; bh=2acYfWbhFGlHCSPL6Kew+gNsQxKv0McjynWPK7UBKR0=; b=pmOUafxtANdthv4K4C8NywNd/VQPIZwnTkAEhH8AMDL8zynscO9ho9WRvv3Nv0bDKI 3ywl6OyHcRDnAnJbRPVOxoUF6KeVkpRW15A/XbRi19FbQS6ZdXYrL7AIeXqpneJLcKqM RGn+kpeb4oe76M0YzCcp7MxfmaDlxcGk7ck0rGtL4C4kfRHbPpP5gm0+eweAvE59FofH DEknDrG+1vR3GjkVne4ThPrUTn9LslDMFOBuhMl6+kG7uUwz/alnGuGxSX0a20LvdvI+ txWAFs2ZVrffTMlk6QVl0Y9dUjJpdkIqV9SV/wHq1qzXA9z08xaSYaHERGAbCvPq3NTN B2VQ== X-Received: by 10.194.24.40 with SMTP id r8mr9515884wjf.7.1372422664812; Fri, 28 Jun 2013 05:31:04 -0700 (PDT) X-Received: by 10.194.24.40 with SMTP id r8mr9515881wjf.7.1372422664766; Fri, 28 Jun 2013 05:31:04 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id r9sm23683167wik.1.2013.06.28.05.31.02 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 05:31:03 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r5SCV1V9089050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 28 Jun 2013 13:31:01 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r5SCV1Mf089046 for freebsd-ports@freebsd.org; Fri, 28 Jun 2013 13:31:01 +0100 (BST) (envelope-from mexas) Date: Fri, 28 Jun 2013 13:31:01 +0100 (BST) From: Anton Shterenlikht Message-Id: <201306281231.r5SCV1Mf089046@mech-cluster241.men.bris.ac.uk> To: freebsd-ports@freebsd.org Subject: portmaster: make: /usr/ports/graphics/ImageMagick/Makefile line 83: warning: Couldn't read shell's output for "/bin/sh -c 'case `perl --version` in *freebsd-thread*) echo yes ; ; esac'" X-Gm-Message-State: ALoCoQn3FhUy/6dKEVnQG+YwmSRYpsx906JRXZfHKlugbeUI8qnKbc7Ma9koI5Mm4glPobfZOTNupmMdYyiekxVaOdSZmyVusK2yLBsnXuNfUPMdnBOb6aVIUtZjZ5tCeUGTcavUqi0/0/cygq4iLzxqe4p2N7sUuNiXbAYEZsPbK4VzDJXICJA= X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:31:32 -0000 This is on amd64 r252033 with ports at 321955: Running portmaster -a I see this: ===>>> Returning to update check of installed ports make: "/usr/ports/graphics/ImageMagick/Makefile" line 83: warning: Couldn't read shell's output for "/bin/sh -c 'case `perl --version` in *freebsd-thread*) echo yes ;; esac'" ^C Is this a problem in portmaster? Anton From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 14:06:20 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61970F6F for ; Fri, 28 Jun 2013 14:06:20 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 90E9A1EC0 for ; Fri, 28 Jun 2013 14:06:19 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id r5SE6HCJ093779 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Jun 2013 15:06:18 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <51CD9859.4030404@unsane.co.uk> Date: Fri, 28 Jun 2013 15:06:17 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ports@freebsd.org Subject: oddness with py27-ldap2 port vs poudiere package, also how to sign digests.txz? X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 14:06:20 -0000 I build my packages locally using poudriere-devel root@bsdpkgbuild:~ # pkg info poudriere-devel poudriere-devel-3.0.99.20130614 I am trying to add py-ldap2 however I'm getting errors installing py27-ldap2 from packages which I dont when I build it locally. The output when I try to install the package I have build and put in my repo: root@ipamtest:~ # pkg install py27-ldap2 Updating repository catalogue digests.txz 100% 22KB 22.4KB/s 22.4KB/s 00:00 pkg: fopen((null)): Bad address pkg: /etc/ssl/certs/pkg.cert: error:04077068:rsa routines:RSA_verify:bad signature pkg: Invalid signature, removing repository. pkg: No digest falling back on legacy catalog format repo.txz 100% 185KB 185.4KB/s 185.4KB/s 00:00 pkg: Repo "repo-packagesite" upgrade schema 2001 to 2002: Modify shlib tracking to add 'provided' capability pkg: Repo "repo-packagesite" upgrade schema 2002 to 2003: Add abstract metadata capability pkg: Repo "repo-packagesite" upgrade schema 2003 to 2004: Add manifest digest field pkg: Repo "repo-packagesite" upgrade schema 2004 to 2005: Rename 'abstract metadata' to 'annotations' The following 1 packages will be installed: Installing py27-ldap2: 2.4.12 The installation will require 724 kB more space 107 kB to be downloaded Proceed with installing packages [y/N]: y pkg: cached package py27-ldap2-2.4.12: checksum mismatch, fetching from remote py27-ldap2-2.4.12.txz 100% 108KB 107.6KB/s 107.6KB/s 00:00 Checking integrity... done [1/1] Installing py27-ldap2-2.4.12...defines: HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R extra_compile_args: extra_objects: include_dirs: /opt/openldap-RE24/include /usr/include/sasl /usr/include library_dirs: /opt/openldap-RE24/lib /usr/lib libs: ldap_r file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found warning: no files found matching 'Makefile' warning: no files found matching 'Modules/LICENSE' file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found In file included from Modules/LDAPObject.c:9: Modules/errors.h:8:18: error: lber.h: No such file or directory Modules/errors.h:9:18: error: ldap.h: No such file or directory In file included from Modules/LDAPObject.c:9: Modules/errors.h:12: error: expected ')' before '*' token In file included from Modules/LDAPObject.c:11: Modules/LDAPObject.h:12:2: error: #error Current python-ldap requires OpenLDAP 2.x In file included from Modules/LDAPObject.c:11: Modules/LDAPObject.h:23: error: expected specifier-qualifier-list before 'LDAP' Modules/LDAPObject.h:31: error: expected ')' before '*' token In file included from Modules/LDAPObject.c:12: Modules/ldapcontrol.h:11: error: expected ')' before '*' token Modules/ldapcontrol.h:12: error: expected declaration specifiers or '...' before 'LDAPControl' Modules/ldapcontrol.h:13: error: expected ')' before '*' token In file included from Modules/LDAPObject.c:13: Modules/message.h:11: error: expected ')' before '*' token In file included from Modules/LDAPObject.c:14: Modules/berval.h:10: warning: 'struct berval' declared inside parameter list Modules/berval.h:10: warning: its scope is only this definition or declaration, which is probably not what you want Modules/berval.h:12: warning: 'struct berval' declared inside parameter list Modules/berval.h:13: warning: 'struct berval' declared inside parameter list Modules/LDAPObject.c:18:18: error: sasl.h: No such file or directory Modules/LDAPObject.c:26: error: expected ')' before '*' token Modules/LDAPObject.c: In function 'dealloc': Modules/LDAPObject.c:42: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:43: error: 'LDAPObject' has no member named 'valid' Modules/LDAPObject.c:44: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:44: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:45: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:46: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:46: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:47: error: 'LDAPObject' has no member named 'valid' Modules/LDAPObject.c:49: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c: In function 'not_valid': Modules/LDAPObject.c:65: error: 'LDAPObject' has no member named 'valid' Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:76: error: expected ')' before '*' token Modules/LDAPObject.c:103: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token Modules/LDAPObject.c:194: error: expected ')' before '*' token Modules/LDAPObject.c:206: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token Modules/LDAPObject.c: In function 'l_ldap_unbind_ext': Modules/LDAPObject.c:332: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:332: error: (Each undeclared identifier is reported only once Modules/LDAPObject.c:332: error: for each function it appears in.) Modules/LDAPObject.c:332: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:333: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:341: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:346: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:350: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:350: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:351: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:352: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:352: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:357: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:358: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:358: warning: return makes pointer from integer without a cast Modules/LDAPObject.c:360: error: 'LDAPObject' has no member named 'valid' Modules/LDAPObject.c: In function 'l_ldap_abandon_ext': Modules/LDAPObject.c:373: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:373: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:374: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:382: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:387: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:391: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:391: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:392: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:393: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:393: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:398: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:399: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:399: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_add_ext': Modules/LDAPObject.c:414: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:414: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:415: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:419: error: 'LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:419: error: 'mods' undeclared (first use in this function) Modules/LDAPObject.c:429: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:434: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:438: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:438: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:439: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:440: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:440: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:445: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:446: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:446: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_simple_bind': Modules/LDAPObject.c:462: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:462: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:463: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:464: error: storage size of 'cred' isn't known Modules/LDAPObject.c:467: error: 'ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:467: error: expected ';' before 'cred_len' Modules/LDAPObject.c:472: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:477: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:481: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:481: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:482: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:482: error: 'LDAP_SASL_SIMPLE' undeclared (first use in this function) Modules/LDAPObject.c:483: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:483: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:488: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:489: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:489: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:553: error: expected declaration specifiers or '...' before 'sasl_interact_t' Modules/LDAPObject.c: In function 'interaction': Modules/LDAPObject.c:562: error: 'interact' undeclared (first use in this function) Modules/LDAPObject.c:569: error: 'LDAP_OPERATIONS_ERROR' undeclared (first use in this function) Modules/LDAPObject.c:589: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:601: error: expected ')' before '*' token Modules/LDAPObject.c: In function 'l_ldap_sasl_interactive_bind_s': Modules/LDAPObject.c:627: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:627: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:628: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:634: error: 'LDAP_SASL_QUIET' undeclared (first use in this function) Modules/LDAPObject.c:653: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:658: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:674: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:677: error: expected expression before ')' token Modules/LDAPObject.c:686: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:687: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:687: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_compare_ext': Modules/LDAPObject.c:745: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:745: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:746: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:751: error: storage size of 'value' isn't known Modules/LDAPObject.c:754: error: 'ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:754: error: expected ';' before 'value_len' Modules/LDAPObject.c:759: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:764: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:768: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:768: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:769: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:770: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:770: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:775: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:776: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:776: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_delete_ext': Modules/LDAPObject.c:790: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:790: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:791: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:800: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:805: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:809: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:809: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:810: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:811: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:811: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:816: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:817: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:817: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_modify_ext': Modules/LDAPObject.c:832: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:832: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:833: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:837: error: 'LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:837: error: 'mods' undeclared (first use in this function) Modules/LDAPObject.c:847: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:852: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:856: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:856: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:857: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:858: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:858: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:864: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:865: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:865: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_rename': Modules/LDAPObject.c:881: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:881: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:882: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:892: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:897: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:901: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:901: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:902: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:903: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:903: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:908: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:909: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:909: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_result4': Modules/LDAPObject.c:920: error: 'LDAP_RES_ANY' undeclared (first use in this function) Modules/LDAPObject.c:929: error: 'LDAPMessage' undeclared (first use in this function) Modules/LDAPObject.c:929: error: 'msg' undeclared (first use in this function) Modules/LDAPObject.c:946: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:946: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:947: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:948: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:948: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:951: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:951: warning: return makes pointer from integer without a cast Modules/LDAPObject.c:963: error: 'LDAP_TIMEOUT' undeclared (first use in this function) Modules/LDAPObject.c:969: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:971: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:971: error: 'serverctrls' undeclared (first use in this function) Modules/LDAPObject.c:972: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:972: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:973: error: 'LDAP_RES_SEARCH_ENTRY' undeclared (first use in this function) Modules/LDAPObject.c:975: error: 'LDAP_RES_SEARCH_REFERENCE' undeclared (first use in this function) Modules/LDAPObject.c:977: error: 'LDAP_RES_INTERMEDIATE' undeclared (first use in this function) Modules/LDAPObject.c:981: error: 'LDAP_RES_EXTENDED' undeclared (first use in this function) Modules/LDAPObject.c:983: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:986: warning: passing argument 1 of 'LDAPberval_to_object' from incompatible pointer type Modules/LDAPObject.c:991: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:994: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:994: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:998: error: 'LDAP_REFERRAL' undeclared (first use in this function) Modules/LDAPObject.c:1004: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1004: warning: return makes pointer from integer without a cast Modules/LDAPObject.c:1007: warning: assignment makes pointer from integer without a cast Modules/LDAPObject.c:1008: error: 'LDAP_NO_MEMORY' undeclared (first use in this function) Modules/LDAPObject.c:1009: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1009: error: 'LDAP_OPT_ERROR_NUMBER' undeclared (first use in this function) Modules/LDAPObject.c:1011: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1011: warning: return makes pointer from integer without a cast Modules/LDAPObject.c:1015: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1015: warning: assignment makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_search_ext': Modules/LDAPObject.c:1057: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1057: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1058: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1085: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1090: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1094: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1094: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1095: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1097: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1097: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1103: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1104: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1104: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_whoami_s': Modules/LDAPObject.c:1117: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1117: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1118: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1129: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1134: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1138: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1138: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1139: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1140: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1140: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1145: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1146: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1146: warning: return makes pointer from integer without a cast Modules/LDAPObject.c:1148: warning: passing argument 1 of 'LDAPberval_to_object' from incompatible pointer type Modules/LDAPObject.c: In function 'l_ldap_start_tls_s': Modules/LDAPObject.c:1164: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1165: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1166: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1166: error: 'LDAP_OPT_ERROR_NUMBER' undeclared (first use in this function) Modules/LDAPObject.c:1167: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1167: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_passwd': Modules/LDAPObject.c:1211: error: storage size of 'user' isn't known Modules/LDAPObject.c:1213: error: storage size of 'oldpw' isn't known Modules/LDAPObject.c:1215: error: storage size of 'newpw' isn't known Modules/LDAPObject.c:1219: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1219: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1220: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1228: error: 'ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:1228: error: expected ';' before 'user_len' Modules/LDAPObject.c:1229: error: expected ';' before 'oldpw_len' Modules/LDAPObject.c:1230: error: expected ';' before 'newpw_len' Modules/LDAPObject.c:1235: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1240: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1244: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1244: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1245: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1252: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1252: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1257: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1258: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1258: warning: return makes pointer from integer without a cast Modules/LDAPObject.c: In function 'l_ldap_extended_operation': Modules/LDAPObject.c:1270: error: variable 'reqvalue' has initializer but incomplete type Modules/LDAPObject.c:1270: warning: excess elements in struct initializer Modules/LDAPObject.c:1270: warning: (near initialization for 'reqvalue') Modules/LDAPObject.c:1270: warning: excess elements in struct initializer Modules/LDAPObject.c:1270: warning: (near initialization for 'reqvalue') Modules/LDAPObject.c:1270: error: storage size of 'reqvalue' isn't known Modules/LDAPObject.c:1273: error: 'LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1273: error: 'server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1274: error: 'client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1285: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1290: error: too many arguments to function 'LDAPControls_from_object' Modules/LDAPObject.c:1294: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1294: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1295: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1300: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1300: error: 'LDAPObject' has no member named '_save' Modules/LDAPObject.c:1305: error: 'LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1306: error: 'LDAPObject' has no member named 'ldap' Modules/LDAPObject.c:1306: warning: return makes pointer from integer without a cast error: Setup script exited with error: command 'cc' failed with exit status 1 pkg: POST-INSTALL script failed done root@ipamtest:~ # and similar on pkg remove py27-ldap2 however building from ports locally works as expected, any hints? Also since the update to pkg I get Updating repository catalogue digests.txz 100% 22KB 22.4KB/s 22.4KB/s 00:00 pkg: fopen((null)): Bad address pkg: /etc/ssl/certs/pkg.cert: error:04077068:rsa routines:RSA_verify:bad signature pkg: Invalid signature, removing repository. pkg: No digest falling back on legacy catalog format repo.txz 100% 185KB 185.4KB/s 185.4KB/s 00:00 pkg: Repo "repo-packagesite" upgrade schema 2001 to 2002: Modify shlib tracking to add 'provided' capability pkg: Repo "repo-packagesite" upgrade schema 2002 to 2003: Add abstract metadata capability pkg: Repo "repo-packagesite" upgrade schema 2003 to 2004: Add manifest digest field pkg: Repo "repo-packagesite" upgrade schema 2004 to 2005: Rename 'abstract metadata' to 'annotations' every time I update the repo, is this expected? I'm signing my repo using a certificate which has up till now been working as expected. any suggestions welcome. Vince From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 14:59:10 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3DA6ECF1 for ; Fri, 28 Jun 2013 14:59:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9E61145 for ; Fri, 28 Jun 2013 14:59:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SEx8ia028762 for ; Fri, 28 Jun 2013 14:59:08 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SEx8KC028761 for freebsd-ports@freebsd.org; Fri, 28 Jun 2013 14:59:08 GMT (envelope-from bdrewery) Received: (qmail 29339 invoked from network); 28 Jun 2013 09:59:07 -0500 Received: from unknown (HELO ?192.168.1.137?) (freebsd@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 28 Jun 2013 09:59:07 -0500 Message-ID: <51CDA4BB.4030605@FreeBSD.org> Date: Fri, 28 Jun 2013 09:59:07 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Anton Shterenlikht Subject: Re: portmaster: make: /usr/ports/graphics/ImageMagick/Makefile line 83: warning: Couldn't read shell's output for "/bin/sh -c 'case `perl --version` in *freebsd-thread*) echo yes ; ; esac'" References: <201306281231.r5SCV1Mf089046@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201306281231.r5SCV1Mf089046@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2OPSOJFVFXIKOBGBGBJJN" Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 14:59:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OPSOJFVFXIKOBGBGBJJN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/28/2013 7:31 AM, Anton Shterenlikht wrote: > This is on amd64 r252033 with ports at 321955: >=20 > Running portmaster -a I see this: >=20 > =3D=3D=3D>>> Returning to update check of installed ports >=20 > make: "/usr/ports/graphics/ImageMagick/Makefile" line 83: warning: Coul= dn't read shell's output for "/bin/sh -c 'case `perl --version` in *freeb= sd-thread*) echo yes ;; esac'" > ^C >=20 > Is this a problem in portmaster? >=20 > Anton >=20 No, this is a problem with the Makefile not being compatible with bmake. --=20 Regards, Bryan Drewery ------enig2OPSOJFVFXIKOBGBGBJJN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRzaS7AAoJEG54KsA8mwz5A1AQAI+wCGTuXERE7oN+v8lzW5eJ emnNXJVpAxbNHnR6i9XZrmyemlPzJEcsoaxlxsjIDkTMCMqa5lubzXj/fGKGDUWH JPtIyBGsBHtyArw10PHVmSuUPXTPvzUtg8n0s3uA44t+Cx55xRToN/wTfTcl2Zc9 7K9a9bZIIoL57vZiMo8bqMpjeQ0Qa697iIBQw1pzUmnQIy0/vllHCXDjWasGAEl4 zbwIUGDSNslucAsf4LdVqyYSSyHJ5iAx77EiNbXUi03GLhkhIrWlgE6Lpyihci2u 4uqVyJxXuLLtq+UfO7SYn62/o4/W3C7G7ppGYzNj5WrqsyiNBcF4eB3vwvPs8nLC qTdOlBTGn2BiY0h4NwPs5U+5MjLwdZjvDC1xQ5KDeZ8vbgAFWfyOnCTRrm6ON6WI Thlfq0/onkyiFjXek2gxSNIODKfPfOIb7qII8X9l0DsxYHHTYqnQfPPerqLP3JkF r+/0I/5O4oNOd1DIwjHHtdJN6ikUioqW8awlYN7OGhqUZtkE0p4sYkVMM/f5N67j CgBS/aPqCR245uIm7/qsZqQxvOCBsZhFX1DYUvdcR2XfutLVPBzyneW4E0TL+jkt pQ1hUuxz9Zhn5T+UVRC38iJSrXw8DVLCTntdxYaMlUqerCz7wM09lI3835iwDlve nXs6ofQgRUurSLm0GMWF =xt+R -----END PGP SIGNATURE----- ------enig2OPSOJFVFXIKOBGBGBJJN-- From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 16:38:20 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8A343C8 for ; Fri, 28 Jun 2013 16:38:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 889AB17F0 for ; Fri, 28 Jun 2013 16:38:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5SGcJTg050683 for ; Fri, 28 Jun 2013 16:38:19 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5SGcJEG050682 for ports@freebsd.org; Fri, 28 Jun 2013 16:38:19 GMT (envelope-from bdrewery) Received: (qmail 3569 invoked from network); 28 Jun 2013 11:38:17 -0500 Received: from unknown (HELO ?192.168.1.137?) (freebsd@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 28 Jun 2013 11:38:17 -0500 Message-ID: <51CDBBF6.8030903@FreeBSD.org> Date: Fri, 28 Jun 2013 11:38:14 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vincent Hoffman Subject: Re: oddness with py27-ldap2 port vs poudiere package, also how to sign digests.txz? References: <51CD9859.4030404@unsane.co.uk> In-Reply-To: <51CD9859.4030404@unsane.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2OKHBLPGDPPPXRMJEFWPM" Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:38:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OKHBLPGDPPPXRMJEFWPM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/28/2013 9:06 AM, Vincent Hoffman wrote: > I build my packages locally using poudriere-devel > root@bsdpkgbuild:~ # pkg info poudriere-devel > poudriere-devel-3.0.99.20130614 >=20 > I am trying to add py-ldap2 however I'm getting errors installing > py27-ldap2 from packages which I dont when I build it locally. >=20 > The output when I try to install the package I have build and put in my= > repo: >=20 > root@ipamtest:~ # pkg install py27-ldap2 > Updating repository catalogue > digests.txz = =20 > 100% 22KB 22.4KB/s 22.4KB/s 00:00 =20 > pkg: fopen((null)): Bad address > pkg: /etc/ssl/certs/pkg.cert: error:04077068:rsa routines:RSA_verify:ba= d > signature This is a bug in pkg-1.1.2. It will be fixed by 1.1.3 soon. > pkg: Invalid signature, removing repository. > pkg: No digest falling back on legacy catalog format > repo.txz = =20 > 100% 185KB 185.4KB/s 185.4KB/s 00:00 =20 > pkg: Repo "repo-packagesite" upgrade schema 2001 to 2002: Modify shlib > tracking to add 'provided' capability > pkg: Repo "repo-packagesite" upgrade schema 2002 to 2003: Add abstract > metadata capability > pkg: Repo "repo-packagesite" upgrade schema 2003 to 2004: Add manifest > digest field > pkg: Repo "repo-packagesite" upgrade schema 2004 to 2005: Rename > 'abstract metadata' to 'annotations' > The following 1 packages will be installed: --=20 Regards, Bryan Drewery ------enig2OKHBLPGDPPPXRMJEFWPM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRzbv5AAoJEG54KsA8mwz5LyIP/1C5Erk91O2jyA9CrUPjL4Cf cwY1c08v6K0BnKUW1dvx5FgbinHto8pdwbDhkIxzSc5Nnpw9DGa7+0AwIMe3O0MX BZHIR1uaKUpRUxKcqay0Rc1/rMq0PR/Lv9dZ4JxtkIs/Fj2xA29Jylq4JDXOfXK8 a44C1UH2H/8XnLJhOFmLn2st5glV9IzxpH9Ud1Tw7i6JZB3JA1yB4xz7FF+bzTyg XSSMGvuWQJ5I9dwNLVCH8gmBbxT2lOSJvifNSJLyeWOERhQvGk444c7BlLnVZXB3 OecIyDGvwXnTHl3EqRJSV9u0eixwUx9372FHi+aIpU8VK3AZ5ZDNVXMSs5aVGCJn S2scSx72lYjWkX/2MLBaitV6PacpLj6rZ6qIWThG4FyMxGQgW3sVro9cAYkR5rH1 113TA1n7CfcbwxTYNhn274ch1dFyuK09BhaME9BWoTsdm4Hq4aUN0RpRkIGRqbo1 D9MxbZo4r64dRKmjDoHtWT4/V7KK/vOrRZjtyTI4WqldqIxcwXPhAmoYbNqmipOM ObC+2lJa1Rfq4YZJ/uYqiNdQFcVRe9lPb/OR4zjWaarHxodjmpK0uQVBczujdMCN EFXRxHE6517h9CQ33XCQWnlliVzl44rYFYDuKcvcDvZcdCCno1Riay1BF7eKNs+7 Z6o0CDe3vthfAZm8GVIL =unBn -----END PGP SIGNATURE----- ------enig2OKHBLPGDPPPXRMJEFWPM-- From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 19:02:36 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFEA4ECA for ; Fri, 28 Jun 2013 19:02:36 +0000 (UTC) (envelope-from info@zubkov.info) Received: from mx.mybsd.ru (mx.mybsd.ru [83.222.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 409DD1FE9 for ; Fri, 28 Jun 2013 19:02:35 +0000 (UTC) Received: (qmail 60221 invoked from network); 28 Jun 2013 18:55:47 -0000 Received: from unknown (HELO sasha.comp) (sasha@sekrett.ru@91.219.26.181) by mx.mybsd.ru with ESMTPA; 28 Jun 2013 18:55:47 -0000 Message-ID: <51CDDC32.9090509@zubkov.info> Date: Fri, 28 Jun 2013 22:55:46 +0400 From: "Alexander B. Zubkov" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ale@FreeBSD.org Subject: FreeBSD Port: mysql-client-5.6.12 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 19:02:36 -0000 Hello! Please take a look why mysql distro became bigger on all the mirrors: => mysql-5.6.12.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: size mismatch: expected 35876046, actual 35853760 => Attempting to fetch http://mysql.mirrors.cybercity.dk/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: http://mysql.mirrors.cybercity.dk/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: No route to host => Attempting to fetch ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: size mismatch: expected 35876046, actual 35853760 => Attempting to fetch ftp://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: ftp://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: size mismatch: expected 35876046, actual 35853760 => Attempting to fetch http://netmirror.org/mirror/mysql.com/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: http://netmirror.org/mirror/mysql.com/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: Not Found => Attempting to fetch ftp://netmirror.org/mysql.com/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: ftp://netmirror.org/mysql.com/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: Protocol error => Attempting to fetch http://mirrors.ntua.gr/MySQL/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz fetch: http://mirrors.ntua.gr/MySQL/Downloads/MySQL-5.6/mysql-5.6.12.tar.gz: size mismatch: expected 35876046, actual 35853760 .... Alexander Zubkov From owner-freebsd-ports@FreeBSD.ORG Fri Jun 28 19:04:45 2013 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9379AF8F for ; Fri, 28 Jun 2013 19:04:45 +0000 (UTC) (envelope-from info@zubkov.info) Received: from mx.mybsd.ru (mx.mybsd.ru [83.222.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id ECF1E101B for ; Fri, 28 Jun 2013 19:04:44 +0000 (UTC) Received: (qmail 34260 invoked from network); 28 Jun 2013 19:04:37 -0000 Received: from unknown (HELO sasha.comp) (sasha@sekrett.ru@91.219.26.181) by mx.mybsd.ru with ESMTPA; 28 Jun 2013 19:04:37 -0000 Message-ID: <51CDDE44.3070302@zubkov.info> Date: Fri, 28 Jun 2013 23:04:36 +0400 From: "Alexander B. Zubkov" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ale@FreeBSD.org Subject: FreeBSD Port: mysql-client-5.6.12 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 19:04:45 -0000 Hello! So, there are some documentation changes: % diff -rq mysql-5.6.12 mysql-5.6.12-new Files mysql-5.6.12/Docs/INFO_SRC and mysql-5.6.12-new/Docs/INFO_SRC differ Files mysql-5.6.12/Docs/mysql.info and mysql-5.6.12-new/Docs/mysql.info differ Files mysql-5.6.12/INSTALL-SOURCE and mysql-5.6.12-new/INSTALL-SOURCE differ Files mysql-5.6.12/man/comp_err.1 and mysql-5.6.12-new/man/comp_err.1 differ Files mysql-5.6.12/man/innochecksum.1 and mysql-5.6.12-new/man/innochecksum.1 differ Files mysql-5.6.12/man/msql2mysql.1 and mysql-5.6.12-new/man/msql2mysql.1 differ Files mysql-5.6.12/man/my_print_defaults.1 and mysql-5.6.12-new/man/my_print_defaults.1 differ Files mysql-5.6.12/man/myisam_ftdump.1 and mysql-5.6.12-new/man/myisam_ftdump.1 differ Files mysql-5.6.12/man/myisamchk.1 and mysql-5.6.12-new/man/myisamchk.1 differ Files mysql-5.6.12/man/myisamlog.1 and mysql-5.6.12-new/man/myisamlog.1 differ Files mysql-5.6.12/man/myisampack.1 and mysql-5.6.12-new/man/myisampack.1 differ Files mysql-5.6.12/man/mysql-stress-test.pl.1 and mysql-5.6.12-new/man/mysql-stress-test.pl.1 differ Files mysql-5.6.12/man/mysql-test-run.pl.1 and mysql-5.6.12-new/man/mysql-test-run.pl.1 differ Files mysql-5.6.12/man/mysql.1 and mysql-5.6.12-new/man/mysql.1 differ Files mysql-5.6.12/man/mysql.server.1 and mysql-5.6.12-new/man/mysql.server.1 differ Files mysql-5.6.12/man/mysql_client_test.1 and mysql-5.6.12-new/man/mysql_client_test.1 differ Files mysql-5.6.12/man/mysql_client_test_embedded.1 and mysql-5.6.12-new/man/mysql_client_test_embedded.1 differ Files mysql-5.6.12/man/mysql_config.1 and mysql-5.6.12-new/man/mysql_config.1 differ Files mysql-5.6.12/man/mysql_config_editor.1 and mysql-5.6.12-new/man/mysql_config_editor.1 differ Files mysql-5.6.12/man/mysql_convert_table_format.1 and mysql-5.6.12-new/man/mysql_convert_table_format.1 differ Files mysql-5.6.12/man/mysql_find_rows.1 and mysql-5.6.12-new/man/mysql_find_rows.1 differ Files mysql-5.6.12/man/mysql_fix_extensions.1 and mysql-5.6.12-new/man/mysql_fix_extensions.1 differ Files mysql-5.6.12/man/mysql_install_db.1 and mysql-5.6.12-new/man/mysql_install_db.1 differ Files mysql-5.6.12/man/mysql_plugin.1 and mysql-5.6.12-new/man/mysql_plugin.1 differ Files mysql-5.6.12/man/mysql_secure_installation.1 and mysql-5.6.12-new/man/mysql_secure_installation.1 differ Files mysql-5.6.12/man/mysql_setpermission.1 and mysql-5.6.12-new/man/mysql_setpermission.1 differ Files mysql-5.6.12/man/mysql_tzinfo_to_sql.1 and mysql-5.6.12-new/man/mysql_tzinfo_to_sql.1 differ Files mysql-5.6.12/man/mysql_upgrade.1 and mysql-5.6.12-new/man/mysql_upgrade.1 differ Files mysql-5.6.12/man/mysql_waitpid.1 and mysql-5.6.12-new/man/mysql_waitpid.1 differ Files mysql-5.6.12/man/mysql_zap.1 and mysql-5.6.12-new/man/mysql_zap.1 differ Files mysql-5.6.12/man/mysqlaccess.1 and mysql-5.6.12-new/man/mysqlaccess.1 differ Files mysql-5.6.12/man/mysqladmin.1 and mysql-5.6.12-new/man/mysqladmin.1 differ Files mysql-5.6.12/man/mysqlbinlog.1 and mysql-5.6.12-new/man/mysqlbinlog.1 differ Files mysql-5.6.12/man/mysqlbug.1 and mysql-5.6.12-new/man/mysqlbug.1 differ Files mysql-5.6.12/man/mysqlcheck.1 and mysql-5.6.12-new/man/mysqlcheck.1 differ Files mysql-5.6.12/man/mysqld.8 and mysql-5.6.12-new/man/mysqld.8 differ Files mysql-5.6.12/man/mysqld_multi.1 and mysql-5.6.12-new/man/mysqld_multi.1 differ Files mysql-5.6.12/man/mysqld_safe.1 and mysql-5.6.12-new/man/mysqld_safe.1 differ Files mysql-5.6.12/man/mysqldump.1 and mysql-5.6.12-new/man/mysqldump.1 differ Files mysql-5.6.12/man/mysqldumpslow.1 and mysql-5.6.12-new/man/mysqldumpslow.1 differ Files mysql-5.6.12/man/mysqlhotcopy.1 and mysql-5.6.12-new/man/mysqlhotcopy.1 differ Files mysql-5.6.12/man/mysqlimport.1 and mysql-5.6.12-new/man/mysqlimport.1 differ Files mysql-5.6.12/man/mysqlshow.1 and mysql-5.6.12-new/man/mysqlshow.1 differ Files mysql-5.6.12/man/mysqlslap.1 and mysql-5.6.12-new/man/mysqlslap.1 differ Files mysql-5.6.12/man/mysqltest.1 and mysql-5.6.12-new/man/mysqltest.1 differ Files mysql-5.6.12/man/mysqltest_embedded.1 and mysql-5.6.12-new/man/mysqltest_embedded.1 differ Files mysql-5.6.12/man/ndb-common-options.1 and mysql-5.6.12-new/man/ndb-common-options.1 differ Files mysql-5.6.12/man/ndb_config.1 and mysql-5.6.12-new/man/ndb_config.1 differ Files mysql-5.6.12/man/ndb_cpcd.1 and mysql-5.6.12-new/man/ndb_cpcd.1 differ Files mysql-5.6.12/man/ndb_delete_all.1 and mysql-5.6.12-new/man/ndb_delete_all.1 differ Files mysql-5.6.12/man/ndb_desc.1 and mysql-5.6.12-new/man/ndb_desc.1 differ Files mysql-5.6.12/man/ndb_drop_index.1 and mysql-5.6.12-new/man/ndb_drop_index.1 differ Files mysql-5.6.12/man/ndb_drop_table.1 and mysql-5.6.12-new/man/ndb_drop_table.1 differ Files mysql-5.6.12/man/ndb_error_reporter.1 and mysql-5.6.12-new/man/ndb_error_reporter.1 differ Files mysql-5.6.12/man/ndb_index_stat.1 and mysql-5.6.12-new/man/ndb_index_stat.1 differ Files mysql-5.6.12/man/ndb_mgm.1 and mysql-5.6.12-new/man/ndb_mgm.1 differ Files mysql-5.6.12/man/ndb_mgmd.8 and mysql-5.6.12-new/man/ndb_mgmd.8 differ Files mysql-5.6.12/man/ndb_print_backup_file.1 and mysql-5.6.12-new/man/ndb_print_backup_file.1 differ Files mysql-5.6.12/man/ndb_print_schema_file.1 and mysql-5.6.12-new/man/ndb_print_schema_file.1 differ Files mysql-5.6.12/man/ndb_print_sys_file.1 and mysql-5.6.12-new/man/ndb_print_sys_file.1 differ Files mysql-5.6.12/man/ndb_restore.1 and mysql-5.6.12-new/man/ndb_restore.1 differ Files mysql-5.6.12/man/ndb_select_all.1 and mysql-5.6.12-new/man/ndb_select_all.1 differ Files mysql-5.6.12/man/ndb_select_count.1 and mysql-5.6.12-new/man/ndb_select_count.1 differ Files mysql-5.6.12/man/ndb_setup.1 and mysql-5.6.12-new/man/ndb_setup.1 differ Files mysql-5.6.12/man/ndb_show_tables.1 and mysql-5.6.12-new/man/ndb_show_tables.1 differ Files mysql-5.6.12/man/ndb_size.pl.1 and mysql-5.6.12-new/man/ndb_size.pl.1 differ Files mysql-5.6.12/man/ndb_waiter.1 and mysql-5.6.12-new/man/ndb_waiter.1 differ Files mysql-5.6.12/man/ndbd.8 and mysql-5.6.12-new/man/ndbd.8 differ Files mysql-5.6.12/man/ndbd_redo_log_reader.1 and mysql-5.6.12-new/man/ndbd_redo_log_reader.1 differ Files mysql-5.6.12/man/ndbinfo_select_all.1 and mysql-5.6.12-new/man/ndbinfo_select_all.1 differ Files mysql-5.6.12/man/ndbmtd.8 and mysql-5.6.12-new/man/ndbmtd.8 differ Files mysql-5.6.12/man/perror.1 and mysql-5.6.12-new/man/perror.1 differ Files mysql-5.6.12/man/replace.1 and mysql-5.6.12-new/man/replace.1 differ Files mysql-5.6.12/man/resolve_stack_dump.1 and mysql-5.6.12-new/man/resolve_stack_dump.1 differ Files mysql-5.6.12/man/resolveip.1 and mysql-5.6.12-new/man/resolveip.1 differ Files mysql-5.6.12/mysql-test/collections/default.release.done and mysql-5.6.12-new/mysql-test/collections/default.release.done differ Files mysql-5.6.12/scripts/fill_help_tables.sql and mysql-5.6.12-new/scripts/fill_help_tables.sql differ Files mysql-5.6.12/sql/sql_yacc.cc and mysql-5.6.12-new/sql/sql_yacc.cc differ Files mysql-5.6.12/sql/sql_yacc.h and mysql-5.6.12-new/sql/sql_yacc.h differ Alexander Zubkov From owner-freebsd-ports@FreeBSD.ORG Sat Jun 29 04:59:08 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 175B44CF; Sat, 29 Jun 2013 04:59:08 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id CEF55185C; Sat, 29 Jun 2013 04:59:07 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j6so3137936oag.15 for ; Fri, 28 Jun 2013 21:59:07 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+URamd0ur1+kHLpsU9xPBru5JvUDGNDw5gJH+o7L3N8=; b=fa/8IUB+twy6oxfQPlV21150Ip7OZZrJUsop3aCHY6o3iwUWNfOXtcld+fyLjBh08G /ocEwbK//+m1kQOgRdUomw9pk2w4pDXw+/o2mu8PVEGCfuB2S7ZIXTJk6jI+lJdW6Y7O 1TG0yXiN5NU11KrXdVZjcyVKXNc4Nc8w15WQvzT0h5aUMuso3D9XQzY3/H2XcG9zOzKi TmrMKbAMlyoDgH3DsMDiyr8Fs7+x8hsI4StJU96izdJNXs2RHjcwnWjgVc1DzVxdNWkc aP1CMfIAoH/G+t5BkScPggNLsJkmIMIa6zSE+U6sFZSqELjEtLUHdoVKapG2y/dOqEZD 1ZJQ== MIME-Version: 1.0 X-Received: by 10.182.72.170 with SMTP id e10mr7762699obv.62.1372481947498; Fri, 28 Jun 2013 21:59:07 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.27.101 with HTTP; Fri, 28 Jun 2013 21:59:07 -0700 (PDT) In-Reply-To: <51C9E5A4.2060502@gmail.com> References: <20130227132633.GI16178@ithaqua.etoilebsd.net> <51C9E5A4.2060502@gmail.com> Date: Sat, 29 Jun 2013 06:59:07 +0200 X-Google-Sender-Auth: L1RW25KYT3iUVFRb-CMgOsyPo-s Message-ID: Subject: Re: Ocaml ports needs love From: Gabor Pali To: =?ISO-8859-1?Q?Michael_Gr=FCnewald?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Baptiste Daroussin , FreeBSD ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 04:59:08 -0000 Hi Michael, On Tue, Jun 25, 2013 at 8:47 PM, Michael Gr=FCnewald = wrote: > Besides maintaining individual ports, we also want to integrate GODI or > OASIS in ports, so it is probably a good idea to have a common place to > discuss these projects, to keep a list of open tasks and describe best > practices. I concur absolutely. Although my priority is rather to work with OPAM-based [1] packages. > A mailing list could be useful, as would a section on the wiki [1]. I can help with this. However, it basically requires a valid FreeBSD wiki registration (I am not sure if you have such account already). > I am pleased to announce that I improved my submission for OCaml-4.00 > [2] (there is still a minor issue) Great news! > and applied for a project ocaml-freebsd on OCamcore's forge. Let me know about the URL of the project once it is accepted and activated. [1] http://opam.ocamlpro.com/ From owner-freebsd-ports@FreeBSD.ORG Sat Jun 29 09:41:55 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89BB2E0F for ; Sat, 29 Jun 2013 09:41:55 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.freebsd.org (unknown [IPv6:2001:1900:2254:206a::50:123]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4151FAE for ; Sat, 29 Jun 2013 09:41:55 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.7/8.14.7) with ESMTP id r5T9ft4F026905 for ; Sat, 29 Jun 2013 09:41:55 GMT (envelope-from portscout@portscout.freebsd.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.7/8.14.6/Submit) id r5T9ftgG026904; Sat, 29 Jun 2013 09:41:55 GMT (envelope-from portscout) Message-Id: <201306290941.r5T9ftgG026904@portscout.freebsd.org> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Sat, 29 Jun 2013 09:41:55 +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.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 09:41:55 -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 ------------------------------------------------+-----------------+------------ lang/libobjc2 | 1.6 | 1.7 ------------------------------------------------+-----------------+------------ www/xpi-pentadactyl | 20130407 | 20130629 ------------------------------------------------+-----------------+------------ 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 If wish to stop receiving portscout reminders, please contact portscout@FreeBSD.org Thanks. From owner-freebsd-ports@FreeBSD.ORG Sat Jun 29 23:37:46 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E383D47D for ; Sat, 29 Jun 2013 23:37:46 +0000 (UTC) (envelope-from nzp@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by mx1.freebsd.org (Postfix) with ESMTP id CDAB719BA for ; Sat, 29 Jun 2013 23:37:46 +0000 (UTC) Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id A6EA7473A5 for ; Sat, 29 Jun 2013 16:37:40 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nzp@fulvetta.riseup.net) with ESMTPSA id 5EBE136B Date: Sun, 30 Jun 2013 01:37:36 +0200 From: Nikola =?utf-8?B?UGF2bG92acSH?= To: freebsd-ports@freebsd.org Subject: Vim and Vim-lite ports broken options Message-ID: <20130629233736.GA20067@sputnjik.localdomain> Mail-Followup-To: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 23:37:47 -0000 Hello, Is it just me, or did the last revision[*] of editors/vim break options for both it and editors/vim-lite? When I try to update vim-lite optional dependencies from vim are forced on this port, so I get mandatory Python, Lua, Ruby... with vim-lite. :) I only ever install vim-lite, so just out of curiosity I tried make config in vim, and it said there are no options to configure, so something is definitely wrong with that. Yesterday I upgraded vim-lite on the same machine (in a different jail, and outside) and it worked fine. I couldn't spot the error immediately, and I'm not really up to date with OptionsNG ATM to tinker. [*] http://svnweb.freebsd.org/ports?view=revision&revision=322016 -- Big M, Little M, many mumbling mice Are making midnight music in the moonlight, Mighty nice!