Hi folks, the uclibc ebuild is currently "stable" for a 2007 version of
uclibc. Latest ebuild in the tree is from early 2009, yet there was a
new release in early 2010?
Recently I have bumped the ebuild to use a git checkout, together with
nptl and this is definitely their best version yet (at least on x86 and
looks like amd64 is also getting there rapidly). I'm only speaking for
x86, but the most recent uclibc appear to bring good support for
hardened, apparently working nptl and best compatibility yet with glibc.
To bump the in-tree ebuild to use git simply requires adjusting the
patch version variables so that old patches are not applied and changing
the download location to be your favourite git checkout (browse the
tree, each commit has a link that automatically creates a tarball of
that code version)
Do we have an active maintainer for uclibc at present? What can I/we do
to help get uclibc more up to date? Personally I think there is a case
that this is a sufficiently niche library that it's worth pushing for at
least a keyworded ebuild that tracks git, and I think there is even a
case that the unmasked version should generally be the latest release
(I'm sure stuff breaks, but on average each new release breaks less
stuff, not more)?
If we don't have a maintainer then could someone perhaps proxy
maintain? I was previously maintaining a stack of patches on an older
release - so far none for git, but I guess others will also be sitting
on a pile of personal tweaks?
Cheers
Ed W
uclibc. Latest ebuild in the tree is from early 2009, yet there was a
new release in early 2010?
Recently I have bumped the ebuild to use a git checkout, together with
nptl and this is definitely their best version yet (at least on x86 and
looks like amd64 is also getting there rapidly). I'm only speaking for
x86, but the most recent uclibc appear to bring good support for
hardened, apparently working nptl and best compatibility yet with glibc.
To bump the in-tree ebuild to use git simply requires adjusting the
patch version variables so that old patches are not applied and changing
the download location to be your favourite git checkout (browse the
tree, each commit has a link that automatically creates a tarball of
that code version)
Do we have an active maintainer for uclibc at present? What can I/we do
to help get uclibc more up to date? Personally I think there is a case
that this is a sufficiently niche library that it's worth pushing for at
least a keyworded ebuild that tracks git, and I think there is even a
case that the unmasked version should generally be the latest release
(I'm sure stuff breaks, but on average each new release breaks less
stuff, not more)?
If we don't have a maintainer then could someone perhaps proxy
maintain? I was previously maintaining a stack of patches on an older
release - so far none for git, but I guess others will also be sitting
on a pile of personal tweaks?
Cheers
Ed W