Summary: | dev-db/postgis-2.1.4 - make[2]: /var/tmp/portage/._portage_reinstall_.JeajSm/bin/ebuild-helpers/xattr/install: Command not found | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Thomas Beutin <tb> |
Component: | Unclassified | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aklhfex, aranea, dev-portage, hardened, kalin |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Thomas Beutin
2014-11-10 06:08:51 UTC
Created attachment 388984 [details]
build.log
This appears to be a defect of postgresql-server, since it has hardcoded the path to 'install' inside /usr/lib64/postgresql-9.3/lib64/pgxs/src/makefiles/pgxs.mk. Instead, it should use PATH to locate the 'install' binary. So far I'm unable to reproduce this issue. I don't see where install is hardcoded. The only hard coded path I see will never be referenced as VPATH is disabled. I only see references to install-sh relative to the location of pgxs.mk. However, the same line that's giving the reporter issue is calling '/usr/bin/install' on my system instead of '/var/tmp/portage/._portage_reinstall_.JeajSm/bin/ebuild-helpers/xattr/install' (In reply to Thomas Beutin from comment #0) > make -f Makefile.comments install > make[2]: Entering directory > '/var/tmp/portage/dev-db/postgis-2.1.4/work/postgis-2.1.4/doc' > /bin/mkdir -p > '/var/tmp/portage/dev-db/postgis-2.1.4/image//usr/share/postgresql-9.3/ > contrib/postgis-2.1' > /var/tmp/portage/._portage_reinstall_.JeajSm/bin/ebuild-helpers/xattr/ > install -c -m 644 postgis_comments.sql raster_comments.sql How about reemerging Portage with xattr disabled? USE=-xattr emerge portage (In reply to Aaron W. Swenson from comment #4) > (In reply to Thomas Beutin from comment #0) [...] > How about reemerging Portage with xattr disabled? > > USE=-xattr emerge portage USE="-xattr" emerge -1 sys-apps/portage && emerge -1 dev-db/postgis::gentoo results in the same error. maybe this is helpful: the suggested ebuild of bug 520694 comment 3 worked for me once, but not anymore. (In reply to Thomas Beutin from comment #5) > (In reply to Aaron W. Swenson from comment #4) > > (In reply to Thomas Beutin from comment #0) > [...] > > How about reemerging Portage with xattr disabled? > > > > USE=-xattr emerge portage > > USE="-xattr" emerge -1 sys-apps/portage && emerge -1 dev-db/postgis::gentoo > > results in the same error. > > maybe this is helpful: the suggested ebuild of bug 520694 comment 3 worked > for me once, but not anymore. There's nothing significantly different with that ebuild from the one in the tree. Adding dev-portage back on to hopefully get a bit more insight here. (In reply to Aaron W. Swenson from comment #3) > So far I'm unable to reproduce this issue. > > I don't see where install is hardcoded. The only hard coded path I see will > never be referenced as VPATH is disabled. I only see references to > install-sh relative to the location of pgxs.mk. > > However, the same line that's giving the reporter issue is calling > '/usr/bin/install' on my system instead of > '/var/tmp/portage/._portage_reinstall_.JeajSm/bin/ebuild-helpers/xattr/ > install' It's calling /usr/bin/install because postgresql-server was installed with FEATURES=xattr disabled. If you re-install postgresql-server with FEATURES=xattr enabled, then it's going to use portage's install wrapper, which is bad. For me it's re-emerging postgresql-base that fixes it. Is it relevant that the last postgresql-base emerge was before portage went from 2.2.8-r2 to 2.2.14? (In reply to Chris Mayo from comment #8) > For me it's re-emerging postgresql-base that fixes it. Okay, then it's postgresql-base that hardcodes the install path in /usr/lib64/postgresql-9.3/lib64/pgxs/src/makefiles/pgxs.mk. > Is it relevant that the last postgresql-base emerge was before portage went > from 2.2.8-r2 to 2.2.14? It's not relevant, because any recent all recent versions of portage do the _portage_reinstall_ thing when upgrading themselves. You will not notice breakage from the hardcoded install path in pgxs.mk unless you happen to have portage and postgresql-base upgraded by the same emerge invocation. Ping. This isn't fixed yet, installing postgresql with FEATURES=-xattr is just a workaround. I also hit this issue today after an transition from python3.3 to python3.4, because /usr/lib64/postgresql-9.4/lib64/pgxs/src/Makefile.global was still referencing the python3.3 version of the install wrapper. I spend some "fun" time hunting around this today... Finally found this bug and after `emerge =dev-db/postgresql-9.4.4` after portage with USE=xattr, I can emerge postgis (2.1.8, but I guess 2.1.1 would work too). My previous build of postgresql indeed captured the wrong path in /usr/lib64/postgresql-9.4/lib64/pgxs/src/Makefile.global Just an assumption, but this happened during `emerge -evtq @world` initially, so maybe it occurs only if portage and postgresql are emerged in one go with USE=xattr May that be a corner case of bug #547086 workaround? If so it should go under sys-apps/portage... Well, I decided to test my assumption, it seems I was partially right. :: Steps to reproduce: 1. `USE=xattr emerge portage dev-db/postgresql postgis` ... make[2]: Entering directory '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' /bin/mkdir -p '/var/tmp/portage/dev-db/postgis-2.1.8/image//usr/share/postgresql-9.4/contrib/postgis-2.1' /var/tmp/portage/._portage_reinstall_.8tjeeiyk/bin/ebuild-helpers/xattr/install -c -m 644 postgis_comments.sql raster_comments.sql topology_comments.sql '/var/tmp/portage/dev-db/postgis-2.1.8/image//usr/share/postgresql-9.4/contrib/postgis-2.1/' make[2]: Leaving directory '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' make[1]: Leaving directory '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' ... 2. USE=xattr emerge postgis What happens: postgresql wrongly records path, so next emerge postgis fails! # fgrep _portage_reinstall_ /usr/lib64/postgresql-9.4/lib64/pgxs/src/Makefile.global install_bin = /var/tmp/portage/._portage_reinstall_.8tjeeiyk/bin/ebuild-helpers/xattr/install -c :: Fix something should be done in postgresql or portage, not postgis :: Workaround `emerge postgresql postgis` I wonder if there are other packages failing in this way with >=sys-apps/portage-2.2.19 ?? If so, reopening bug #547086 is in order. (In reply to Kalin KOZHUHAROV from comment #12) > Well, I decided to test my assumption, it seems I was partially right. > > > :: Steps to reproduce: > 1. `USE=xattr emerge portage dev-db/postgresql postgis` > > ... > > make[2]: Entering directory > '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' > /bin/mkdir -p > '/var/tmp/portage/dev-db/postgis-2.1.8/image//usr/share/postgresql-9.4/ > contrib/postgis-2.1' > /var/tmp/portage/._portage_reinstall_.8tjeeiyk/bin/ebuild-helpers/xattr/ > install -c -m 644 postgis_comments.sql raster_comments.sql > topology_comments.sql > '/var/tmp/portage/dev-db/postgis-2.1.8/image//usr/share/postgresql-9.4/ > contrib/postgis-2.1/' > make[2]: Leaving directory > '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' > make[1]: Leaving directory > '/var/tmp/portage/dev-db/postgis-2.1.8/work/postgis-2.1.8/doc' > > ... > > 2. USE=xattr emerge postgis > > What happens: > postgresql wrongly records path, so next emerge postgis fails! > > # fgrep _portage_reinstall_ > /usr/lib64/postgresql-9.4/lib64/pgxs/src/Makefile.global > install_bin = > /var/tmp/portage/._portage_reinstall_.8tjeeiyk/bin/ebuild-helpers/xattr/ > install -c > > :: Fix > something should be done in postgresql or portage, not postgis > > :: Workaround > `emerge postgresql postgis` > > I wonder if there are other packages failing in this way with > >=sys-apps/portage-2.2.19 ?? > If so, reopening bug #547086 is in order. In the file /usr/lib64/postgresql-${SLOT}/lib64/pgxs/src/Makefile.global there's the following line: install_bin = /usr/bin/install -c Try changing it to: install_bin = install -c If it works, I'll figure out how to make the PostgreSQL ebuild spit out a modified Makefile.global. Postgres populates this line with the path to the current install utility on compilation, so it isn't going to be install_bin = /usr/bin/install -c on the affected systems. For example, over here it's install_bin = /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c But if you could statically replace this line by install_bin = install -c , this should in fact resolve the bug. I've just verified this approach works for dev-db/postgis. I've also verified that portage in fact places the .../xattr/install utility in PATH, so just calling "install" will use the xattr-install instead of /usr/bin/install, just as desired. Doing so should be quite easy; it looks like it'd be sufficient to do sed -ie 's/@install_bin@/install -c/' src/Makefile.global.in at a suitable spot in src_prepare(). (In reply to Luis Ressel from comment #15) > Doing so should be quite easy; it looks like it'd be sufficient to do > sed -ie 's/@install_bin@/install -c/' src/Makefile.global.in > at a suitable spot in src_prepare(). Excellent. That's what I was thinking it'd be, but I hadn't looked at that file yet. As mentioned in the previous comments, the fix needed to be implemented in the PostgreSQL ebuilds as PostGIS sources files generated by that package. commit 17eb751adda1ed29ae00e12e47199b09ff7f4673 Author: Aaron W. Swenson <titanofold@gentoo.org> Date: Tue Dec 15 16:39:51 2015 -0500 dev-db/postgresql: Hardcode install Rely on $PATH being in the proper order so that the correct install program is used for modules utilizing PGXS in both hardened and non-hardened environments. Bug: 528786 Package-Manager: portage-2.2.20.1 it hits in #568612 again :( Sorry for the noise - the recompile of dev-db/postgresql fixed bug 568612. |