Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 278354 - media-libs/libcanberra-0.14 fails trying to remove some files (and after correcting during autoconf if gconf is not installed)
Summary: media-libs/libcanberra-0.14 fails trying to remove some files (and after corr...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-19 20:51 UTC by Aelia
Modified: 2009-07-21 06:20 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
my modified version of the ebuild that compiles (need the patch) (libcanberra-0.14.ebuild,2.16 KB, text/plain)
2009-07-19 20:52 UTC, Aelia
Details
the patch to remove references to gconf macro (libcanberra-0.14-autoconf-without-gconf.patch,2.45 KB, patch)
2009-07-19 20:53 UTC, Aelia
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aelia 2009-07-19 20:51:00 UTC
I have an ~amd64 system (with really custom USE flags) but I think this will apply for every arch and KEYWORD because the ebuild has something idiotic... :

        rm "${S}/lt*"    || die "clean-up ltmain.sh failed"
        rm "${S}/m4/lt*" || die "clean-up lt scripts failed"
        rm "${S}/m4/libtool*" || die "clean-up libtool script failed"

the tarball doesn't even contain these files...
removing this and adding some other rm (found in the bootstrap.sh called by autogen.sh) it fails during eautoreconf :

***** autoconf *****
***** PWD: /var/tmp/portage/media-libs/libcanberra-0.14/work/libcanberra-0.14
***** autoconf

configure.ac:364: error: possibly undefined macro: AM_GCONF_SOURCE_2
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.



libcanberra-0.14 has a reference to some gconf autoconf macro, so even if you don't want to compile with gconf support you need the macro, which means you need gconf installed.

Reproducible: Always

Steps to Reproduce:
1. make sure gconf is not installed
2. USE="-gtk" emerge =libcanberra-0.14
3. watch it fail

Actual Results:  
it fails with errors 

Expected Results:  
should compile...
Comment 1 Aelia 2009-07-19 20:52:45 UTC
Created attachment 198501 [details]
my modified version of the ebuild that compiles (need the patch)

I apply the patch to remove the references to the gconf macro if the gtk useflag is disabled.
Comment 2 Aelia 2009-07-19 20:53:25 UTC
Created attachment 198502 [details, diff]
the patch to remove references to gconf macro
Comment 3 Romain Perier (RETIRED) gentoo-dev 2009-07-20 11:36:18 UTC
(In reply to comment #0)
> 
>         rm "${S}/lt*"    || die "clean-up ltmain.sh failed"
>         rm "${S}/m4/lt*" || die "clean-up lt scripts failed"
>         rm "${S}/m4/libtool*" || die "clean-up libtool script failed"
> 
> the tarball doesn't even contain these files...

Have a look to the last commit (it was fixed, so resync the tree) and then have a look to the tarball, these files exist.
These files was generated using libtool-2.2 into tarball, in the case where libtool-1.5 is used , compilation will fail, if these files are not regenerated.

now try the following command:
$ USE="-gtk" ebuild /usr/portage/media-libs/libcanberra/libcanberra-0.14.ebuild install

then have a look to ${D}/usr, there are no schemas, however there is gnome2_gconf_install into pkg_postinst() ...
Comment 4 Aelia 2009-07-20 12:43:52 UTC
ok it goes through the rm now that I synced the tree but the problem with autoconf is still there...

(and having "|| die" is idiotic for a rm... we are root so if it fails it just means the files aren't here so we are in the case we wanted no need to die...)
Comment 5 Romain Perier (RETIRED) gentoo-dev 2009-07-21 06:20:09 UTC
Fixed into the overlay without a revision bump.
I backported gconf-2.m4 from aclocal's system dir to m4/ sources dir.
See diego's blog about "why don't use aclocal.m4 as a reference".

Due to our policy (and for some technicals reasons) we avoid to apply a patch conditionnally into ebuilds (from a if statement)

Thanks for reporting ;)