Bugzilla Bug 160184

The following ebuilds/eclasses are using the almost deprecated gnuconfig_update
function from gnuconfig.eclass:

./dev-libs/nspr/nspr-4.4.1-r2.ebuild:   gnuconfig_update
./dev-libs/nspr/nspr-4.6.1-r2.ebuild:   gnuconfig_update
./dev-libs/nspr/nspr-4.6.1-r3.ebuild:   gnuconfig_update
./dev-libs/nspr/nspr-4.6.2.ebuild:      gnuconfig_update
./dev-libs/nspr/nspr-4.6.3.ebuild:      gnuconfig_update
./dev-libs/nspr/nspr-4.6.3-r1.ebuild:   gnuconfig_update
./dev-libs/nspr/nspr-4.6.4.ebuild:      gnuconfig_update

This might be due by various reasons, and some of them cannot be worked around
at the current time, so please find your case in the following list:

* the ebuild does not use econf, but ./configure, because it uses a very old
version of autoconf that does not support the parameters we pass; [1]
* the software use config.{guess,sub} although not using autotools, thus econf
cannot be used; [1]
* the ebuild uses ./configure just for fun; [2]
* the ebuild uses ../configure or variants thereof to run a different configure
script than the one in the current directory; [3]
* the ebuild uses an autogen script or some other autotools-rebuilding script
that calls ./configure; [4]
* the ebuild calls ./configure because it's doing an inline-build of another
package. [1]

Then see the procedure to handle this bug:

[1] You cannot drop gnuconfig_update, so please leave the bug open, but set the
status whiteboard to "Waiting autoepatch".
[2] Fix the ebuild, use econf!
[3] econf accepts a ECONF_SOURCE variable to tell it to run the configure found
in another directory; to run ../configure just use ECONF_SOURCE=".." econf.
[4] Fix your autotools with http://www.gentoo.org/proj/en/qa/autofailure.xml
adnd then use econf.

Once you're using econf, it will take care of updating gnuconfig by itself.

Thanks from Diego and Mike

OK.
Added nspr-4.6.4-r1, please check it out.
I have masked it for now.

ping mozilla

Index: nspr-4.6.4-r1.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/dev-libs/nspr/nspr-4.6.4-r1.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 nspr-4.6.4-r1.ebuild
--- nspr-4.6.4-r1.ebuild        5 Jan 2007 21:43:27 -0000       1.1
+++ nspr-4.6.4-r1.ebuild        16 Jan 2007 20:33:41 -0000
@@ -22,11 +22,11 @@
 src_unpack() {
        unpack ${A}
        cd "${S}"
-       EPATCH_OPTS="-p2" epatch "${FILESDIR}"/${PN}-4.6.1-config.patch
-       EPATCH_OPTS="-p2" epatch "${FILESDIR}"/${PN}-4.6.1-config-1.patch
+       epatch "${FILESDIR}"/${PN}-4.6.1-config.patch
+       epatch "${FILESDIR}"/${PN}-4.6.1-config-1.patch
        epatch "${FILESDIR}"/${PN}-4.6.4-config-2.patch
-       EPATCH_OPTS="-p2" epatch "${FILESDIR}"/${PN}-4.6.1-lang.patch
-       EPATCH_OPTS="-p2" epatch "${FILESDIR}"/${PN}-4.6.1-prtime.patch
+       epatch "${FILESDIR}"/${PN}-4.6.1-lang.patch
+       epatch "${FILESDIR}"/${PN}-4.6.1-prtime.patch
        eautoreconf
 }


Unless you have goo reason for needing the epatch ops? But I have yet to see
any reason for it so I would revert it.

Sure there is... What do you think, I just put it there?
Adding files without -j will put them at the wrong place.

(In reply to comment #4)
> Sure there is... What do you think, I just put it there?
> Adding files without -j will put them at the wrong place.
> 

Aight mozilla herd has control of this package it has been surrendered by
crypto, I will have that reverted and unmasked.

(In reply to comment #4)
> Sure there is... What do you think, I just put it there?
> Adding files without -j will put them at the wrong place.
> 

# You do not have to specify '-p' option to patch, as it will
# try with -p0 to -p5 until it succeed, or fail at -p5.

(In reply to comment #6)
> (In reply to comment #4)
> > Sure there is... What do you think, I just put it there?
> > Adding files without -j will put them at the wrong place.
> > 
> 
> # You do not have to specify '-p' option to patch, as it will
> # try with -p0 to -p5 until it succeed, or fail at -p5.
> 

This what I initially done.
Please try it your-self.
You will see that at least the pkg-config stuff is going to the wrong place.
But I don't mind.
If you are going to maintain it do whatever you feel right.

So what's left to do here? Just remove the mask? Is everyone OK with unmasking
as-is?

(In reply to comment #8)
> So what's left to do here? Just remove the mask? Is everyone OK with unmasking
> as-is?
> 

Yeah, why not.

We should make it stable asap.

Unmasked the fixed version.

We'll request a stabilization of that version soon.

Reopen when the ebuilds are removed please, no one moment before.

This was finally done.