From owner-freebsd-ports@FreeBSD.ORG Sun Nov 3 22:03: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EC38650A; Sun, 3 Nov 2013 22:03:45 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay003.isp.belgacom.be (mailrelay003.isp.belgacom.be [195.238.6.53]) by mx1.freebsd.org (Postfix) with ESMTP id 82F5D259D; Sun, 3 Nov 2013 22:03:44 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGACfHdlJbs76w/2dsb2JhbABZgwc4RwEBv1mBGhd0giUBAQUnLx4FEAsYCSUPKh4GE4gFAQi9SI4ZgQwzB4QuA5gJgTCQWoMnO4Es Received: from 176.190-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.190.176]) by relay.skynet.be with ESMTP; 03 Nov 2013 23:03:36 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id rA3M3YgS014584; Sun, 3 Nov 2013 23:03:34 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Sun, 3 Nov 2013 23:03:34 +0100 From: Tijl Coosemans To: Tijl Coosemans Subject: Re: Updating linux-f10-pango fails Message-ID: <20131103230334.16b33efe@kalimero.tijl.coosemans.org> In-Reply-To: <20131103183004.6364bc18@kalimero.tijl.coosemans.org> References: <20131015065816.4be007fb@scorpio> <525D3C65.7050501@passap.ru> <525E8715.9000205@freebsd.org> <20131016211703.00006ed9@unknown> <525EEEFB.6050403@FreeBSD.org> <20131103183004.6364bc18@kalimero.tijl.coosemans.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jerry@seibercom.net, portmgr@FreeBSD.org, freebsd-ports@freebsd.org, =?ISO-8859-1?Q?Ren=E9?= Ladan , Alexander Leidinger , 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, 03 Nov 2013 22:03:46 -0000 On Sun, 3 Nov 2013 18:30:04 +0100 Tijl Coosemans wrote: > On Wed, 16 Oct 2013 21:54:35 +0200 Matthias Andree wrote: >> Am 16.10.2013 21:17, schrieb Alexander Leidinger: >>> On Wed, 16 Oct 2013 14:31:17 +0200 >>> Ren=C3=A9 Ladan wrote: >>>> On 15-10-2013 15:00, Boris Samorodov wrote: >>>>> 15.10.2013 15:08, Ren=E9 Ladan ?????: >>>>>> Here tar gets confused somehow, it wants to pack >>>>>> ${STAGEDIR}/usr/compat/linux (note the extra usr/ ), which fails >>>>>> consequently. >>>>> >>>>> Does the affected system (poudiere jail) use links, like >>>>> /compat -> /usr/compat? >>>> >>>> Mine does not have a /usr/compat -> /compat link (nor the other way >>>> around), and /compat is only created when building/installing linux >>>> ports (or other ports that require it). >>>=20 >>> A normal install creates (or used to create, so at least there are old >>> systems with this) the link /compat -> /usr/compat, so maybe somewhere >>> realpath comes into use and exhibits a problem here ("here" being the >>> staging support in general, not limited to the port). >>=20 >> I think I can confirm your assessment. >>=20 >>=20 >> Ren=E9, >>=20 >> I had the same issue as Jerry (as reported on IRC, on >> 9.1-RELEASE-amd64), but did not dig deeper. >>=20 >> In the end I sidestepped the problem because I could not solve it; >> meaning I used poudriere to build the package and installed that through >> pkg_add. That is not the canonical way to do that. >>=20 >> I think I can confirm Alexanders suspicion. >>=20 >> I do have the symbolic link that Alexander states: >>=20 >> $ ls -l /compat >> lrwxr-xr-x 1 root wheel 10 10 Okt 2009 /compat -> usr/compat >>=20 >> "make package" in the actual system fails (poudriere is fine for me, too= ). >>=20 >> So perhaps either Poudriere sets up the jail a touch differently than a >> regular system would install it (possibly through sysinstall or whatever >> I used to get 9.1, I do not remember). >>=20 >>=20 >> Now, my workaround that makes "make package" work is to alias the file >> systems instead of : >>=20 >> # mv /compat /compat.off >> # mkdir /compat && mount_nullfs /usr/compat /compat >>=20 >> (Further hints below.) >>=20 >> Then: >>=20 >> $ make package >> =3D=3D=3D> Building package for linux-f10-pango-1.28.3_1 >> Creating package >> /var/tmp/usr/ports.svn/x11-toolkits/linux-f10-pango/work/linux-f10-pango= -1.28.3_1.tbz >> Registering depends: linux-f10-cairo-1.8.0_2 linux-f10-xorg-libs-7.4_1 >> linux-f10-fontconfig-2.6.0 linux-f10-expat-2.0.1 linux-f10-png-1.2.37_2 >> linux_base-f10-10_7. >> Registering conflicts: linux-pango-[0-9]* linux-f8-pango-[0-9]*. >> Creating bzip'd tar ball in >> '/var/tmp/usr/ports.svn/x11-toolkits/linux-f10-pango/work/linux-f10-pang= o-1.28.3_1.tbz' >> $ >>=20 >> *This would seem to confirm that the symlink is the trigger for the >> problem.* >>=20 >>=20 >> Now, for the archives, further hints: >>=20 >> 1. to make the change permanent, add one line to /etc/fstab so the mount >> gets re-established after reboot >>=20 >> # printf '/usr/compat\t\t/compat\t\tnullfs\trw\t\t0\t0\n' >> /etc/fstab >>=20 >> 2. if instead you want to revert the change: >>=20 >> # umount /compat >> # rmdir /compat && mv /compat.off /compat >> # sed -i.bak -e '/^\/usr\/compat/d' /etc/fstab >>=20 >> 3. if /compat gets destroyed: >>=20 >> # ln -sfn usr/compat /compat >>=20 >>=20 >> I hope portmgr can investigate and fix this problem. >=20 > If there's no immediate fix for this can it please be reverted. > Everybody who has separate / and /usr partitions has a /compat -> > /usr/compat link because you don't want to install packages on the > root file system. This includes pretty much everyone running FreeBSD > 8 because the installer creates separate partitions by default there. I've looked into this a bit deeper. The call to realpath in pkg_create has been introduced in: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D231300 This revision has been MFCed to stable/8 between releng/8.3 and releng/8.4 and to stable/9 between releng/9.0 and releng/9.1. The call has been disabled for absolute path names in http://svnweb.freebsd.org/base?view=3Drevision&revision=3D240682 This revision has been MFCed to stable/8 between releng/8.3 and releng/8.4 and to stable/9 between releng/9.1 and releng/9.2. So only FreeBSD 9.1 is affected by this. People in this thread running stable should just update. If you run FreeBSD 9.1 a workaround is to switch to the new pkg tools.