From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V1mH9-0003ZW-UP for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 23:45:51 +0000 X-ACL-Warn: Received: from [162.213.26.82] (helo=zinan.dashjr.org) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V1mH8-0007w9-30 for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 23:45:51 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 03CED27A2966; Tue, 23 Jul 2013 23:45:40 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Tue, 23 Jul 2013 23:45:26 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.10-gentoo; KDE/4.10.4; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2520182.IJj2QRvikL"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201307232345.37289.luke@dashjr.org> X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1V1mH8-0007w9-30 Cc: Greg Troxel Subject: Re: [Bitcoin-development] Linux packaging letter X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:45:52 -0000 --nextPart2520182.IJj2QRvikL Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tuesday, July 23, 2013 11:23:27 PM Greg Troxel wrote: > I find it interesting that this is a "linux packaging letter". How much > of this applies to pkgsrc, FreeBSD ports, OpenBSD ports, and other > non-Linux packaging systems (pkgsrc supports Linux as on of 20 operating > systems, but is not a "Linux packaging system")? It was written with bitcoind/Bitcoin-Qt in mind, which don't work on BSD. :p > Is the repeatable build infrastructure portable (to any reasonable > mostly-POSIX-compliant system, with gcc or clang)? I have the vague > impression it's Ubuntu only, but I am very unclear on this point. How > does this repeatableness interact with building for multiple operating > systems and cpu types (say 20 OS, with typically 3 versions of the OS > for each, with 1-20 cpu types per OS, for a cross-product of perhaps 200 > combinations)? It should be portable to other systems, though hasn't been done yet. Would be nice if the concepts it uses could be integrated into the package- building systems. > Requiring precise library depdendencies is quite awkward. Certainly > requiring new enough to avoid known bugs is understandable, but that > should be caught at configure time and fail. The problem is that we require bugs. That is, if your library has those bug= s=20 fixed, you have introduced a security vulnerability. > It seems like a bug that the package will build on BE systems and then > fail tests. If it's known not to be ok, it seems that absent some > configure-time flag the build should fail. There is no configure-time for this node software yet. The autoconf-based o= ne=20 in the works *does* make this check, however. > Asking people not to patch should mean willingnesss to make accomodation > in the master sources for build issues for multiple packaging systems. > I haven't gotten around to packaging this for pkgsrc - so far I only > have the energy to lurk (due to too many things on the todo list). But > I often find that some changes are needed. If you're willing (in > theory) to add in configure flags to control build behavior (in a way > that you can audit and decide is safe), that's great, and of course we > can discuss an actual situation when one gets figured out. The review process is very slow and strict, but that is because of the same= =20 reasons it isn't safe to distribute patched versions in general. Merging yo= ur=20 patches to mainline is not only a good idea, but it helps to ensure they ge= t=20 the necessary testing needed to be safe. Luke --nextPart2520182.IJj2QRvikL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQQcBAABCAAGBQJR7xWgAAoJEL0ClCQh9Iify+wf/i2jZLpIx4oojvnp90mOJ4Vx zRphCrt4jFnLnY1w+BBSMlWx9YUG6IKRwVtG97ex4hMNMvtDSCfIO7eGpIWQHvhF aWWqPHBYa9QIzvLaRDnquVsrSnoxnf4bHCwuBhLreqTQSCwPvuWYtmN/naCB/LDg pKF86+HuPH3XLrnuG2Q+vCDC73EBEqbMIYnUWTE4zJpV0zEtWFMqn9pVtZZUEBRu bGGdQ1NwvHj7FfMqOqsZX8oTzT6U9jFQZmg6J29qPD7gJ5ptb3VVhV2k/CNkteaz cna85apfwelr33bxQrrcToHb1XWtMsL4lkqLaj4eGUr4nctXiFJnyk4seumaNzq6 b38RrhuaHYqvv7t0xg0cy9iQ6L65oHI6ZLg86y7hkAaNjc5Il+pfhKr9OPP5veRg VTvGaDzp9gVNblLI2EKa3HBRP8OMu4Vzh/I3XnWB4Ywi5Nk3QeJGjy3QScvi6QJN K36NWEOFfiapTdQu0WZcgiuom5tuRPogCBAZD3CbvswGJHPaI5qCgga3AACJzlda 0jc6s+LHM3XkkxJyfb3Lv8+Fu40vxGA8rF9ohM5J6q+Y4fsh8DOyHr3OnrqtympP Jy39LhUHbifi4HcEF41bKU61iXhSfPhoXv1U5J+8VUrTRuddVqj1kHrw+rEYaSt6 icbQHsYWQlzJAbMn0xQQR/j2o+MwL0fXjTOEnDC0TkRj0O+0Mg6ATX75hCJly/ih 2Tm18+Dl7K3gwOUBa0MDVxstsrwkwMadVSj/6pElbcI0W/pJuZLjQuzsUrbFoq8b gLUFLvxUluYfaEeEuIYMDkho/sufOAX5e9X+Y0AwICpN0BXaBKxd0zwpYDP90wqC pVa8OwX8jI9JQigq1VCGmtfs8uRraz3LpRo1C8179h5bM6O7AMhYV/VYYZ7D6vfd OrQPmdklTv1GELX0eNNOlO5PNNS9UPWoMCCNBpUVy178U+e4Mk4hUJerH7O4R0kb YOIE+F5DRhz5pr5P0suSTNPy+CYcmAIE2ooAsPDqBibzKgZgAVUQ+siUBwrDfyDW Ng1hPpJjPvM1QpNTTYBJdhDbPRV7co72RJlwVPjg6CZqALIyVJqq9perY0GvPFE2 6bs2cE3xm2mI5v+zSN5IWuOQ0R6Xko5Ifj8m0roFKEJNcN2AQqRGVo2PGol7GinD 8Oq6cmGMEpFIDZNDBD1GL8P5WzpFz8nmQWFKPWoiZ3KCjRShdQgvKTnH3H709Du2 RAK/aakPLZWbRGNuQJjHCona+SzIi/4y1tLx4v/LfKNpXjEoApqOB5SQJclLSW/I LxrfxQM74vJ2hpMGCJ0Yb4224arNp0lJdByrfwf9yzhHG5jcmoKdmc3Ri8z1YZI= =Bnfm -----END PGP SIGNATURE----- --nextPart2520182.IJj2QRvikL--