From owner-freebsd-ports@freebsd.org Sun Dec 3 03:08:24 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE602DD7D7F for ; Sun, 3 Dec 2017 03:08:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-163.reflexion.net [208.70.210.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 937B5675A3 for ; Sun, 3 Dec 2017 03:08:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32634 invoked from network); 3 Dec 2017 02:41:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Dec 2017 02:41:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 02 Dec 2017 21:41:37 -0500 (EST) Received: (qmail 28667 invoked from network); 3 Dec 2017 02:41:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Dec 2017 02:41:37 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6E458EC8AD0 for ; Sat, 2 Dec 2017 18:41:36 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Welcome flavors! portmaster now dead? synth? Message-Id: Date: Sat, 2 Dec 2017 18:41:35 -0800 To: FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 03:08:24 -0000 Rozhuk Ivan rozhuk.im at gmail.com wrote on Sat Dec 2 18:18:39 UTC 2017 : > I dont want poudriere because I dont need ZFS, jails and other crap on = my system. > I dont want to play system administrator: keep and admin build servers = at home/work. >=20 > I just want update from source all my ports, make packages, and on = other > computers run portmaster to update from these packages on nfs share. > Minimum overhead. >=20 > synth - at least require specific depencies. Poudriere certainly has more space and time use in its way of operation. (The useful vs. overhead is status is context dependent.) But, I did just recently experiment with a from-scratch try-to-build-everything ( poudriere bulk -C -a ) on a system configuration that is just UFS based. It worked okay. (UFS vs. ZFS has various tradeoffs for such. For now I'm using UFS in this large-use context.) I use UFS with poudriere-devel on a BPI-M3 armv7 board and a Pine64+ 2GB board as well (for vastly fewer ports). There is 2 GiBytes of RAM in each of those. For them I use PARALLEL_JOBS=3D1 to be more like ports-mgmt/portmaster and its one-builder status. By the time indirect dependencies are traced, building and then using ports-mgmt/poudriere-devel does require: misc/freebsd-release-manifests security/ca_root_nss where the indirect dependency status is: security/ca_root_nss lang/perl5.24 So normally the devel/poudriere and those 3 other ports, plus ports-mgmt/pkg itself. I've been able to establish such a context on powerpc64, powerpc, armv7 (previously armv6), aarch64, and amd64. For ports-mgmt/synth only the last two of the 5 had been directly possible. (Last I knew aarch64 was no longer buildable, due to the initial-binary-bootstrap stage of the compiler toolchain involved vs. later FreeBSD header changes.) Note: I have experimented with ports-mgmt/synth in the past, including on the Pine64+ 2 GB (aarch64) before building synth and the toolchain it is based on was broken. But I prefer an more uniform environment instead of using distinct techniques. Other than that, the experiment was interesting and worked fine. I do not claim the following is a typical context or that it would apply to your specific context. But it does apply to my context. ports-mgmt/poudiere-devel does allow: emulators/qemu-user-static (optional: atypical?) For enabling potential cross builds targeting armv7, arrch64, and possibly some others. This leads to more dependencies when selected: emulators/qemu-user-static (optional) (flattened, sorted list) converters/libiconv devel/bison devel/gettext-runtime devel/gettext-tools devel/glib20 devel/gmake devel/libffi devel/m4 devel/p5-Locale-gettext devel/pcre devel/pkgconf devel/readline lang/perl5.24 lang/python2 lang/python27 misc/help2man print/indexinfo print/texinfo I have done amd64 -> armv7 and aarch64 cross builds of ports via poudriere. As I remember powerpc64 is supposed to be able to use emulators/qemu-user-static and so could target armv7 or aarch64, although I've not tested such. (qemu-user-static does not work for emulating powerpc64 or powerpc FreeBSD operation sufficiently, so, I've not used those types of targets for cross builds.) I do modify poudriere's jail.sh a little to allow a more extreme form of (for example): A) poudriere jail -c -j jailArmV7 -a arm.armv7 -x \ -m null \ -M /usr/obj/DESTDIRs/armv7-installworld-poud \ -S /usr/src -v 12.0-CURRENT (jail creation with some native cross-build tools and tied to my local /usr/src/ materials .) B) poudriere ports -c -m null -M /usr/ports where I've prebuilt world and appropriately installed /usr/obj/DESTDIRs/armv7-installworld-poud . The bulk builds produce armv7 materials for that jail. I have put copies of such world builds on the target device and used it with poudriere on that device as well. Thus the BPI-M3 did not have to do its own buildworld for poudriere use in its jail when I tried local port builds via poudriere. =3D=3D=3D Mark Millard markmi at dsl-only.net