From owner-freebsd-gnome@FreeBSD.ORG Sun Dec 18 22:43:54 2011 Return-Path: Delivered-To: gnome@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0532B10656D5 for ; Sun, 18 Dec 2011 22:43:54 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id 435CC8FC0A for ; Sun, 18 Dec 2011 22:43:52 +0000 (UTC) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.4/8.14.4) with ESMTP id pBIMD6Xk085787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Dec 2011 23:13:07 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.4/8.14.4/Submit) with UUCP id pBIMD699085786 for gnome@FreeBSD.org; Sun, 18 Dec 2011 23:13:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.5/8.14.5) with ESMTP id pBILMdqm025273 for ; Sun, 18 Dec 2011 22:22:39 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.5/8.14.5) with ESMTP id pBILKc9A024969 for ; Sun, 18 Dec 2011 22:20:38 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.14.5/8.14.5/Submit) id pBILKcYU024968 for gnome@FreeBSD.org; Sun, 18 Dec 2011 22:20:38 +0100 (CET) (envelope-from peter) Date: Sun, 18 Dec 2011 22:20:37 +0100 From: Peter To: gnome@FreeBSD.org Message-ID: <20111218212037.GA24297@gate.oper.dinoex.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (uucp.dinoex.sub.de [194.45.71.2]); Sun, 18 Dec 2011 23:13:07 +0100 (CET) Cc: Subject: graphics/gegl: make and bsd.gnome.mk its all really hosed X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 22:43:54 -0000 Beware, friends, this will be real fun! So take a cup of tea, sit down and enjoy! Everythig started when I noticed that my graphics/gegl build ended with this error: > ===> Registering installation for gegl-0.1.8_1 > ===> Building package for gegl-0.1.8_1 > tar: libdata/pkgconfig/gegl.pc: Cannot stat: No such file or directory > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > *** Error code 1 > > Stop in /usr/ports/graphics/gegl. That was not really funny, but it became better: Next time the build was run, it completed without this error! Now let me mention a thing first: I am building ports in a chroot, which is based on ZFS snapshots, so it can always be rolled back to a defined state. That also means: I am talking about well defined circumstances. Things that happen to happen randomly are quite strange in such a situation. Now, as usual, when such strange errors appear, one will suppose that its the JOBS ('make -j') feature. So I searched into that direction - which figured wrong later - but I found something there, nevertheless. It seemed that the error would not likely appear when simply running "make" in the portsdir, but it would rather likely appear when running "make -j2". I further noticed that it was enough to run "make -j2 patch" to trigger the error. Now, I know there are ports that do work with -j, and there are others that do not work. But "make patch" is not the port itself, it is our stuff from ports/Mk, and I might suppose that should be solid enough to handle -j. There is now also an interesting thing to see in the output: > # make clean > ===> Cleaning for gegl-0.1.8_1 > # make -j2 patch > find: /usr/ports/graphics/gegl/work/gegl-0.1.8: No such file or directory > find: /usr/ports/graphics/gegl/work/gegl-0.1.8: No such file or directory > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > ===> Found saved configuration for gegl-0.1.8_1 > ===> Extracting for gegl-0.1.8_1 > => SHA256 Checksum OK for gegl-0.1.8.tar.bz2. These two "find:" warnings do not belong there, I suppose. I went searching the "find"s, and I found the "find"s. They are in Mk/bsd.gnome.mk, named "gnomehack_PRE_PATCH". This does exactly what I expected: it modifies the "Makefile.in", so that the "pkgconfig" directory is assumed below "libdata" instead of "lib": > --- Makefile.in.bak 2011-11-18 19:13:18.000000000 +0000 > +++ Makefile.in 2011-12-18 11:10:41.602742074 +0000 > @@ -364,7 +364,7 @@ > # the next run of make. > SUBDIRS = libs gegl operations bin tools examples tests \ > $(am__append_1) > -pkgconfigdir = $(libdir)/pkgconfig > +pkgconfigdir = $(prefix)/libdata/pkgconfig > pkgconfig_DATA = gegl.pc > built_dist_files = README > EXTRA_DIST = \ So, I fixed this one to be forced to run later, with the followning patch. *** ports/Mk/bsd.gnome.mk.orig Sun Dec 18 05:55:08 2011 --- ports/Mk/bsd.gnome.mk Sun Dec 18 05:56:31 2011 *************** *** 780,786 **** pre-patch: gnome-pre-patch ! gnome-pre-patch: @${GNOME_PRE_PATCH:C/^;//1} .endif --- 780,786 ---- pre-patch: gnome-pre-patch ! gnome-pre-patch: patch-dos2unix @${GNOME_PRE_PATCH:C/^;//1} .endif At that point I thought I had caught it and am now clear on the vortex; and started the build again. But it got funnier: the behaviour was unchanged! It still did occasionally work or not work, with the same error as before! Then I figured that "make -j" was not even used for the patch step; so, while the above patch would help people who enter "make -j" in the portsdir directly, it has nothing to do with the automatix as controlled by the FORCE_MAKE_JOBS option. But then, what the f**k was going on here? I found another thing in the Makefile of graphics/gegl itself: > # Disable docs until I fix the problem with graphviz's dot > NOPORTDOCS= yes [...] > post-patch: > .if defined(NOPORTDOCS) > ${REINPLACE_CMD} -e '10s|\\||; 11,13d' ${WRKSRC}/Makefile.am > .endif Now, while the "gnomehack_PRE_PATCH" modifies "Makefile.in", this one modifies "Makefile.am". Precisely, it deletes three lines from "Makefile.am", which removes some directories from the build list: > disp-chroot# diff -u Makefile.am.bak Makefile.am > --- Makefile.am.bak 2011-11-18 16:00:53.000000000 +0000 > +++ Makefile.am 2011-12-18 09:59:03.065282655 +0000 > @@ -7,10 +7,7 @@ > libs \ > gegl \ > operations \ > - bin \ > - tools \ > - examples \ > - tests > + bin > > if ENABLE_DOCS > SUBDIRS+= docs This is in some way reflected in the plist, too - but from one or two glances it doesn't seem to me that the variables would match. I am no specialist in matter of automake and friends, so I do not know precisely what "Makefile.in" and "Makefile.am" are good for or what one can do (or not do) with them. But then I figured an essential point of my random results: *EITHER* these changes to "Makefile.am" get propagated to "Makefile.in" (and finally to "Makefile"). By that, the previous change to "Makefile.in" (that is, the correct pkgconfig path from "gnomehack_PRE_PATCH") will be overwritten! And then the gegl.pc file is found missing at packaging time (because it is placed into lib/pkgconfig instead of libdata/pkgconfig). *OR* the "Makefile.in" is NOT overwritten. Then the changes to "Makefile.am" have no effect and are useless! Then the "tools", "examples" and "tests" are built and installed, and we seem to get a bunch of files onto the system which aren't recorded in a plist. It's broken either way. Finally: why does this behaviour change erratically? I can repeat a sequence of "make clean; make" in the portsdir, and one time it's this way and next the other! The critical point seems to be the following operations: > ===> Building for gegl-0.1.8_1 > cd . && /bin/sh /usr/ports/graphics/gegl/work/gegl-0.1.8/missing --run automake-1.11 --gnu Makefile > cd . && /bin/sh ./config.status Makefile > config.status: creating Makefile These happen to happen, once, and do not happen the next time - it seems to be dependent on some strange race. For my purposes, I do now: *** ports/graphics/gegl/Makefile.orig Sun Dec 18 15:32:58 2011 --- ports/graphics/gegl/Makefile Sun Dec 18 15:34:59 2011 *************** *** 184,189 **** --- 184,192 ---- ${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g' ${WRKSRC}/configure ${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|' ${WRKSRC}/tools/gobj2dot.rb + pre-build: + touch ${WRKSRC}/Makefile.in + post-build: .if !defined(NOPORTDOCS) cd ${WRKSRC}/docs && ${GMAKE} This seems to give me some *defined* behaviour, at least. To be honest, I am currently clueless on how to *correctly* fix this. The best idea I would imagine would be to extend the "gnomehack_PRE_PATCH" to not only modify "Makefile.in" but also "Makefile.am". But as this is used by some thousand ports, it might just be calling for more trouble... PMc