On Wed, 16 Oct 2013 21:54:35 +0200 Matthias Andree articulated: > Am 16.10.2013 21:17, schrieb Alexander Leidinger: > > On Wed, 16 Oct 2013 14:31:17 +0200 > > René Ladan <[email protected]> wrote: > > > >> On 15-10-2013 15:00, Boris Samorodov wrote: > >>> 15.10.2013 15:08, René 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). > > > > 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). > > > > Bye, > > Alexander. > > > > Alexander, > > I think I can confirm your assessment. > > > René, > > I had the same issue as Jerry (as reported on IRC, on > 9.1-RELEASE-amd64), but did not dig deeper. > > 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. > > I think I can confirm Alexanders suspicion. > > I do have the symbolic link that Alexander states: > > $ ls -l /compat > lrwxr-xr-x 1 root wheel 10 10 Okt 2009 /compat -> usr/compat > > "make package" in the actual system fails (poudriere is fine for me, > too). > > 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). > > > Now, my workaround that makes "make package" work is to alias the file > systems instead of : > > # mv /compat /compat.off > # mkdir /compat && mount_nullfs /usr/compat /compat > > (Further hints below.) > > Then: > > $ make package > ===> 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-pango-1.28.3_1.tbz' > $ > > *This would seem to confirm that the symlink is the trigger for the > problem.* > > > Now, for the archives, further hints: > > 1. to make the change permanent, add one line to /etc/fstab so the > mount gets re-established after reboot > > # printf '/usr/compat\t\t/compat\t\tnullfs\trw\t\t0\t0\n' > >> /etc/fstab > > 2. if instead you want to revert the change: > > # umount /compat > # rmdir /compat && mv /compat.off /compat > # sed -i.bak -e '/^\/usr\/compat/d' /etc/fstab > > 3. if /compat gets destroyed: > > # ln -sfn usr/compat /compat > > > I hope portmgr can investigate and fix this problem.
I asked the other day if I should file a PR against this port; however, I never received a reply. Unless I am told not to, I will file one tomorrow. I don't want this problem to fall through the cracks. Ever since this staging support started, too many ports are failing. I am wondering just how thoroughly this was tested before being force on the general populace. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________
signature.asc
Description: PGP signature
