From owner-freebsd-ports@freebsd.org Sat Aug 19 13:01:15 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 391EBDE851E for ; Sat, 19 Aug 2017 13:01:15 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 0785973AC5; Sat, 19 Aug 2017 13:01:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7JD1CYE093599; Sat, 19 Aug 2017 13:01:12 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7JD1CUF093598; Sat, 19 Aug 2017 06:01:12 -0700 (PDT) (envelope-from david) Date: Sat, 19 Aug 2017 06:01:12 -0700 From: David Wolfskill To: freebsd-ports@freebsd.org Subject: x11/nvidia-settings: poudriere fails; portmaster succeeds Message-ID: <20170819130112.GV1133@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rWty3NhOxSZDKxGe" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 13:01:15 -0000 --rWty3NhOxSZDKxGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In fairness, this may be an "apple vs. orange" comparison. But it's fairly unusual (in my experience) for poudriere to fail to build a port, but when it's a port that I had just built successfully (using portmaster) on my laptop... well, I thought it was worth mentioning. The whine in the poudriere log is: =2E.. cc -O2 -pipe -fstack-protector -fno-strict-aliasing -fno-strict-aliasing -= fno-omit-frame-pointer -Wformat=3D2 -Wno-unused-parameter -Wno-format-zero-= length -DNV_BSD -I/usr/local/include -I . -I image_data -I libXNVCtrl -I = XF86Config-parser/.. -I libXNVCtrlAttributes -I xpm_data -I common-utils -I= common-unix/virtual-resolutions -I _out/FreeBSD_amd64 -I/usr/local/include= -D_THREAD_SAFE -pthread -I /usr/include/dbus-1.0/ -DPROGRAM_NAME=3D\"nvid= ia-settings\" -fPIC -c XF86Config-parser/Generate.c -o _out/FreeBSD_amd64/G= enerate.o && cc -MM -O2 -pipe -fstack-protector -fno-strict-aliasing -fno-= strict-aliasing -fno-omit-frame-pointer -Wformat=3D2 -Wno-unused-parameter = -Wno-format-zero-length -DNV_BSD -I/usr/local/include -I . -I image_data = -I libXNVCtrl -I XF86Config-parser/.. -I libXNVCtrlAttributes -I xpm_data -= I common-utils -I common-unix/virtual-resolutions -I _out/FreeBSD_amd64 -I/= usr/local/include -D_THREAD_SAFE -pthread -I /usr/include/dbus-1.0/ -DPROG= RAM_NAME=3D\"nvidia-settings\" -fPIC XF86Config-parser/Generate.c | sed -e = "s,: ,: $\(wildcard ," -e "s,\([^\\]\)$,\1)," -e "s;^Generate.o: ; _out/Fre= eBSD_amd64/Generate.o: ;" > _out/FreeBSD_amd64/Generate.d gtk+-2.x/ctkgridlicense.c:42:10: fatal error: 'dbus/dbus.h' file not found #include ^~~~~~~~~~~~~ 1 error generated. =2E... which looks to me as if somehow nvidia-settings has a dependency on dbus of which poudriere was unaware; more on that below (after I sketch the environment). I have two machines that have nightly-updated private mirrors of the FreeBSD SVN src, ports, and doc repositories: my laptop and a "build machine" ("freebeast"). As described in , I perform a source-based update of stable/11 on each of the machines each morning; upon reboot and after "make delete-old-libs", I use portmaster on each of these machines to update the installed ports to match the state of the just-updated /usr/ports working copy. The laptop only builds the world & its own custom kernel; freebeast runs a GENERIC kernel and builds that, as well as kernels for the two "production" machines. On a regular basis (normally, each Sunday morning), I update the production machines by installing the just-built snapshot of stable/11 onto them, reboot, perform a "pkg updgrade", and reboot again. The production machines are configured to get their packages (for the "pkg upgrade") from freebeast. freebeast uses poudriere to build the packages. Since I (normally) only update the production machines on Sunday, I don't see much value in running poudriere every day. On the other hand, if I wait until Sunday (to get a week's worth of updates), that can take a while, even with a reasonably fast machine. So, as a compromise, I do the "weekly" package-building in two stages: the first is on Saturday (as in, today), doing a "catch up" run for the last 6 days of updates, then on Sunday -- usually! -- there's only a small amount of work to get caught up. Thus, the successful build of x11/nvidia-settings was on my laptop, yesterday: =2E.. =3D=3D=3D>>> The following actions were performed: Upgrade of nvidia-xconfig-378.13 to nvidia-xconfig-384.59 Upgrade of libuv-1.13.1 to libuv-1.14.0 Upgrade of cups-filters-1.13.5 to cups-filters-1.16.0 Upgrade of harfbuzz-1.4.7 to harfbuzz-1.4.8 Upgrade of harfbuzz-icu-1.4.7 to harfbuzz-icu-1.4.8 Upgrade of opusfile-0.8 to opusfile-0.9 Upgrade of nvidia-settings-378.13_1 to nvidia-settings-384.59_1 Command exit status: 0 freebeast runs (essentially) headless; it has no X11-related ports installed at all. So my next attempt to build x11/nvidia-settings was on freebeast, but using poudriere -- which failed as described above. Checking (on my laptop) for ports on which nvidia-settings depends, I see: g1-252(11.1-S)[1] pkg info -d x11/nvidia-settings nvidia-settings-384.59_1: libXxf86vm-1.1.4_1 libXv-1.0.11,1 libXext-1.3.3_1,1 libX11-1.6.5,1 pango-1.40.6 gtk2-2.24.31 fontconfig-2.12.1,1 freetype2-2.8 libvdpau-1.1.1 mesa-libs-17.1.5 gdk-pixbuf2-2.36.6 cairo-1.14.8_1,2 jansson-2.10 glib-2.50.2_4,1 gettext-runtime-0.19.8.1_1 atk-2.24.0 g1-252(11.1-S)[2]=20 And that list does not seem to mention any dbus-related ports. So I *suspect* that the portmaster build was "successful" only by accident (because portmaster builds in teh local enviornment, which happened to already have dbus installed, so dbus/dbus.h was already present -- even though not called out as a dependency), while poudriere would (I expect) have provided the file if it had actually been advised that it was wanted.... Sorry for going on at such lengh; hope it was of some use despite that. Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --rWty3NhOxSZDKxGe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZmDaYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XscQH/1ULW/qUFUl9iTuc38cDiyXi XhFon/67BZcBXsBg67zzGAjXYBDjdwBdLh5P494ugteOK08MmWi3abjPOgTORnBx aPiizqFYqiwOMwbDVsfSQkWI9QR900H8zlovOe3XZRbM+m+oDNmf/GATW19NreKt Fc9VY7aOYhh8PApTsakCGUmQcAGBnxUZiTklLFP8eW/K8nQeey/gvlnAJJkYm5b0 bgLy6oq8WWnxR+FaPuEc0bfhrftIzifSezQOzvVxRFmLVbfWPqn827HMCi58iOpo 0hWgSXBgIpuByxf6V2/ppycjIixwmHjVP2RjIflFJr9TyV5d7BGpIKT2sqVpvYA= =AFvm -----END PGP SIGNATURE----- --rWty3NhOxSZDKxGe--