Summary: | app-arch/rpm-4.4.7 failed running automake | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Willard Dawson <willard.dawson> |
Component: | Current packages | Assignee: | Peter Volkov (RETIRED) <pva> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dm.konrad, hanno, pva, teidakankan, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fix for the problem. |
Description
Willard Dawson
2006-10-17 20:08:04 UTC
Thank you for report, Willard. While I'm trying to reproduce your bug can you test 4.4.6-r2? Hi Peter, I tried emerging 'world' this morning and found rpm-4.4.7. It also shows the same basic error as the one I reported via bugzilla. >>> Emerging (1 of 1) app-arch/rpm-4.4.7 to / * rpm-4.4.7.tar.gz MD5 ;-) ... [ ok ] * rpm-4.4.7.tar.gz RMD160 ;-) ... [ ok ] * rpm-4.4.7.tar.gz SHA1 ;-) ... [ ok ] * rpm-4.4.7.tar.gz SHA256 ;-) ... [ ok ] * rpm-4.4.7.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking rpm-4.4.7.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking rpm-4.4.7.tar.gz to /var/tmp/portage/app-arch/rpm-4.4.7/work * Applying rpm-4.4.6-with-sqlite.patch ... [ ok ] * Applying rpm-4.4.7-stupidness.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/app-arch/rpm-4.4.7/work/rpm-4.4.7' ... * Requested autoconf 2.5 * Using autoconf (GNU Autoconf) 2.60 * Using autoheader (GNU Autoconf) 2.60 * Requested automake 1.10 * Using automake (GNU automake) 1.10 * Using aclocal (GNU automake) 1.10 * Running aclocal ... [ ok ] * Running libtoolize --copy --force --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ !! ] * Failed Running automake ! * * Include in your bugreport the contents of: * * /var/tmp/portage/app-arch/rpm-4.4.7/temp/automake-12408.out !!! ERROR: app-arch/rpm-4.4.7 failed. Call stack: ebuild.sh, line 1568: Called dyn_unpack ebuild.sh, line 708: Called src_unpack rpm-4.4.7.ebuild, line 48: Called eautoreconf autotools.eclass, line 87: Called eautomake autotools.eclass, line 188: Called autotools_run_tool 'automake' '--add-missing' '--copy' '--foreign' autotools.eclass, line 239: Called die !!! Failed Running automake ! !!! If you need support, post the topmost build error, and the call stack if relevant. WDAWSONLT ~ # cat /var/tmp/portage/app-arch/rpm-4.4.7/temp/automake-12408.out ***** automake ***** configure.ac:676: warning: AC_COMPILE_IFELSE was called before AC_GNU_SOURCE ../../lib/autoconf/specific.m4:335: AC_GNU_SOURCE is expanded from... aclocal.m4:8669: gl_LOCK_BODY is expanded from... aclocal.m4:8463: gl_LOCK is expanded from... aclocal.m4:609: gt_INTL_SUBDIR_CORE is expanded from... aclocal.m4:511: AM_INTL_SUBDIR is expanded from... aclocal.m4:387: AM_GNU_GETTEXT is expanded from... configure.ac:676: the top level configure.ac:676: warning: AC_RUN_IFELSE was called before AC_GNU_SOURCE configure.ac:676: required file `./config.rpath' not found configure.ac: installing `./ylwrap' Makefile.am:19: AM_GNU_GETTEXT used but `intl' not in SUBDIRS CC vapier. vapier: The problem is because now ebuild calls eautorconf instead of proposed in 4.4.7 eautoconf && eautomake. eautoreconf calls aclocal and regenerates aclocal.m4. This cause problems on new systems. The package itself does not provide m4 macroses thus solution is not to call aclocal at all. Would you like to fix this? Or if you want I can do that. Also I would like to keep automake version close to upstream and use version 1.9 (see autogen.sh) and personally I do not like "latest" in WANT_* variables as "latest" may change. And I take bug to avoid bugspam on maintainer-needed@gentoo.org. And I just checked. rpm-4.4.6-r2 also have this problem. Created attachment 99939 [details, diff]
Fix for the problem.
Proposed patch should fix the problem. I'll wait for vapier's opinion on the issue before commit.
Same problem here * A dry-run of patch command succeeded, but actually * applying the patch failed! * Failed Patch: rpm-4.4.7.patch ! * ( /usr/local/portage/app-arch/rpm/files/rpm-4.4.7.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/app-arch/rpm-4.4.7/temp/rpm-4.4.7.patch-1155.out !!! ERROR: app-arch/rpm-4.4.7 failed. Call stack: ebuild.sh, line 1568: Called dyn_unpack ebuild.sh, line 708: Called src_unpack rpm-4.4.7.ebuild, line 40: Called epatch '/usr/local/portage/app-arch/rpm/files/rpm-4.4.7.patch' eutils.eclass, line 341: Called die !!! Failed Patch: rpm-4.4.7.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-app-arch_-_rpm-4.4.7-1154.log" rename: /usr/portage/app-arch/rpm/rpm-4.4.7.ebuild -------------------------------------------------------------------------------- !!! This ebuild is from an overlay: '/usr/local/portage' ***** rpm-4.4.7.patch ***** =========================== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage/app-arch/rpm/files/rpm-4.4.7.patch =========================== patching file /usr/portage/app-arch/rpm/rpm-4.4.7.ebuild =========================== ACTUALLY APPLYING rpm-4.4.7.patch ... =========================== patching file /usr/portage/app-arch/rpm/rpm-4.4.7.ebuild ACCESS DENIED rename: /usr/portage/app-arch/rpm/rpm-4.4.7.ebuild patch: **** Can't rename file /var/tmp/portage/app-arch/rpm-4.4.7/temp/po8CHNoX to /usr/portage/app-arch/rpm/rpm-4.4.7.ebuild : Permission denied konrad: That was patch for ebuild ;) oh:/ sorry :( works perfectly now:) How could I get rid of sandbox violation any way? works perfectly now:) How could I get rid of sandbox violation any way? I mean with other packages when sth like this occur? there was a bug in the autotool.eclass that was causing this problem the code in portage at the moment for rpm is fine |