There is is a "recent" (compared to 2009) v0.1 tag in gnulib Git, from which a new version could be built. Reproducible: Always
The following patch works surprisingly well: --- /var/cache/portage/gentoo/dev-libs/gnulib/gnulib-9999-r1.ebuild 2014-11-12 12:31:06.000000000 +0100 +++ /var/cache/portage/local/dev-libs/gnulib/gnulib-0.1.ebuild 2014-12-18 15:24:44.990759716 +0100 @@ -4,15 +4,12 @@ EAPI=5 -inherit eutils git-r3 +inherit eutils DESCRIPTION="Gnulib is a library of common routines intended to be shared at the source level" HOMEPAGE="http://www.gnu.org/software/gnulib" +SRC_URI="http://git.savannah.gnu.org/cgit/gnulib.git/snapshot/${P}.tar.gz" -EGIT_REPO_URI=" - git://git.savannah.gnu.org/${PN}.git - http://git.savannah.gnu.org/r/${PN}.git -" LICENSE="GPL-2" SLOT="0" KEYWORDS=""
(In reply to Dennis Schridde from comment #1) > The following patch works surprisingly well: Probably because I committed a couple of fixes during the past months. :)
Bumped, thanks!
(In reply to Fabian Groffen from comment #3) > Bumped, thanks! I see this commit: 27 Dec 2014; Fabian Groffen <grobian@gentoo.org> +gnulib-2013.10.28.22.33.52.ebuild: Version bump, by Dennis Schridde in bug #532936 But I actually asked for an ebuild for the v0.1 tag. Is it possible to get that instead?
The v0.1 tag of gnulib does not make any sense except for git-describe: https://lists.gnu.org/archive/html/bug-gnulib/2013-10/msg00118.html gnulib even is not intended to install as standalone library at all: http://www.gnu.org/software/gnulib/ However, we've found it easier to provide gnulib as pre-built library on exotic platforms for packages not using gnulib, which would require lots of porting effort otherways.
(In reply to Michael Haubenwallner from comment #5) > However, we've found it easier to provide gnulib as pre-built library on > exotic platforms for packages not using gnulib, which would require lots of > porting effort otherways. Thanks for the explanation. What's the path forward for e.g. bug #369549, where gnulib is necessary to build the package?
(In reply to Dennis Schridde from comment #6) > (In reply to Michael Haubenwallner from comment #5) > > However, we've found it easier to provide gnulib as pre-built library on > > exotic platforms for packages not using gnulib, which would require lots of > > porting effort otherways. > > Thanks for the explanation. > > What's the path forward for e.g. bug #369549, where gnulib is necessary to > build the package? In regards to bug #369549, gnulib is no longer necessary - see that bug for details.
