The sed in the unpack/prepare function will cause maintainer-mode to trigger to rebuild autotools, and automake 1.9 will be executed without a proper dependency on it. Please don't run this kind of sed in the eclasses without rebuilding autotools. And yes I know you'd expect that not to fail because it also changes the Makefile.in; but since the sed executes in alphabetical order the timestamp is screwed up on sub-second mtime filesystems (xfs, tmpfs, ext4). Please just do it properly, pleeeease.
(testing as bugzilla sysadmin, as miknix is noting some weird problems posting)
(In reply to comment #1) > (testing as bugzilla sysadmin, as miknix is noting some weird problems posting) > test
(In reply to comment #0) > The sed in the unpack/prepare function will cause maintainer-mode to trigger to > rebuild autotools, and automake 1.9 will be executed without a proper > dependency on it. > > Please don't run this kind of sed in the eclasses without rebuilding autotools. > > And yes I know you'd expect that not to fail because it also changes the > Makefile.in; but since the sed executes in alphabetical order the timestamp is > screwed up on sub-second mtime filesystems (xfs, tmpfs, ext4). > > Please just do it properly, pleeeease. > My rootfs is XFS and I can reproduce it. <<< aclocal.m4:16: warning: this file was generated for autoconf 2.61. You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'. configure.ac:7: version mismatch. This is Automake 1.10.2, configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE configure.ac:7: comes from Automake 1.10.1. You should recreate configure.ac:7: aclocal.m4 with aclocal and run automake again. WARNING: `automake-1.10' is probably too old. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. >>> Although upstream is already fixing the strip issue which is the only reason we do the ugly sed. So the sed line will be removed in the future. Given that no package did break here because of bogus autotools versions and that there aren't so many people using this eclass right now (in fact you are the first GPE bug, thank you), I'd keep this intact until upstream does the right thing(TM). Anyway, does some GPE ebuild failed to you because of this?
I've fixed most if not all the stripping problems in the upstream svn. gpe-3.0 target would be an ideal time to remove the sed hacks/fixes.
I'd _highly_ suggest avoiding the issue by just changing Makefile.am and force rebuild of autotools to be on the safe side; you _don't_ want the thing to break subtly, and I've seen this being a problem enough times before that it does not look too funny at all.
I'd _highly_ suggest avoiding any issues by making sure Makefile.am is sedded before Makefile.in and avoid a forced eautoreconf that takes time, potentially adds many build time *.m4 file requirements and so on.
I think having $(find . -name 'Makefile*' |sort) instead of $(find . -name 'Makefile*') should pretty much fix it. Makefile will get ordered before Makefile.in, but that shouldn't be a problem -- ./configure has not been ran yet, so if Makefile.in does exist (with now sedded to have a newer timestamp than Makefile), it will be re-updated by ./configure to be newer, and by the time make is called for the am--refresh autotools Makefile rule to hit, it will already have a newer timestamp and it won't happen. I'm told Makefile is sedded too (with the Makefile* wildcard) only because many packages still aren't autotooled, so Makefile.in won't exist there and the Makefile's there won't have an am--refresh target either to cause the rebuild. So in short, pipe the find results through sort and everything should be fine.
The same thing happened for GNOME packages, which is when I found that patching both Makefile.am and Makefile.in in the same patch file is never an issue, and the issue could instead be sed's on a list of unordered files. The fixes are described here, with a detailed explanation in the commit log: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnome2-utils.eclass?view=log#rev1.11 http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnome2-utils.eclass?r1=1.10&r2=1.11
(In reply to comment #7) > I think having > > $(find . -name 'Makefile*' |sort) > > instead of > > $(find . -name 'Makefile*') > > should pretty much fix it. > That is a clean and quick solution, it's fixed in CVS. Thank you.
