[Buildroot] uClibc-ng

[Buildroot] uClibc-ng

[Waldemar Brodkorb]

Hello Embedded Linux Hackers,

it seems there is no plan to release a new uClibc version.
The current maintainer does not response on any public or private mails
about a plan to do a needed release. Therefore most of you carrying a lot
of patches against uClibc 0.9.33.2 to make it work in your project.
A really ugly situation. 

To get out of this situation I started a spin-off called uClibc-ng.
The website for the project is here: http://www.uclibc-ng.org
Beta 3 is tagged and downloadable via 
http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz

If you want a 1.0 in the near future please test and report back any
issues. You can use the bug tracker, the mailing list or dicussion forum
to report back. To prevent spam you need to be subscribed or registered.

I have added most of the patches from your projects on top of uClibc
master.

Thanks
 Waldemar

uClibc-ng

[Waldemar Brodkorb]

Hello Embedded Linux Hackers,

it seems there is no plan to release a new uClibc version.
The current maintainer does not response on any public or private mails
about a plan to do a needed release. Therefore most of you carrying a lot
of patches against uClibc 0.9.33.2 to make it work in your project.
A really ugly situation. 

To get out of this situation I started a spin-off called uClibc-ng.
The website for the project is here: http://www.uclibc-ng.org
Beta 3 is tagged and downloadable via 
http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz

If you want a 1.0 in the near future please test and report back any
issues. You can use the bug tracker, the mailing list or dicussion forum
to report back. To prevent spam you need to be subscribed or registered.

I have added most of the patches from your projects on top of uClibc
master.

Thanks
 Waldemar

[Buildroot] uClibc-ng

[Thomas De Schampheleire]

Hi Waldemar,

Waldemar Brodkorb <wbx@uclibc-ng.org> schreef:
>Hello Embedded Linux Hackers,
>
>it seems there is no plan to release a new uClibc version.
>The current maintainer does not response on any public or private mails
>about a plan to do a needed release. Therefore most of you carrying a lot
>of patches against uClibc 0.9.33.2 to make it work in your project.
>A really ugly situation. 
>
>To get out of this situation I started a spin-off called uClibc-ng.
>The website for the project is here: http://www.uclibc-ng.org
>Beta 3 is tagged and downloadable via 
>http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz
>
>If you want a 1.0 in the near future please test and report back any
>issues. You can use the bug tracker, the mailing list or dicussion forum
>to report back. To prevent spam you need to be subscribed or registered.
>
>I have added most of the patches from your projects on top of uClibc
>master.

Interesting development!
One question: how do you see musl vs uclibc-ng in the future? At this moment uclibc supports more architectures, but this may change. Do you think both should/can coexist? What are the distinctive features of uclibc over musl, according to you?

Thanks,
Thomas

[Buildroot] uClibc-ng

[Waldemar Brodkorb]

Hi Thomas,
Thomas De Schampheleire wrote,

> Hi Waldemar,
> 
> Waldemar Brodkorb <wbx@uclibc-ng.org> schreef:
> >Hello Embedded Linux Hackers,
> >
> Interesting development!  One question: how do you see musl vs
> uclibc-ng in the future? At this moment uclibc supports more
> architectures, but this may change. Do you think both should/can
> coexist? What are the distinctive features of uclibc over musl,
> according to you?

I think both can coexist for a while. uClibc is more compatible to
glibc, so most of the software packages used on embedded systems are
working fine without patching. Musl is relatively new and there are
patches required to make some stuff work. Alpine Linux, Sabotage and
OpenADK have a lot of patches, fixing musl issues.

uClibc has support for non-MMU systems. uClibc can be configured at 
build time and can be made smaller than musl. Musl can be used to
have a complete static linked system, uClibc still requires
libgcc_so.so for some threading functions. uClibc is widely used
in the embedded Linux world, musl is a newcomer.

For musl you need to patch gcc. 4.9.x does not include support for
it.

It is just good to have a choice.
At the time all software packages working fine with musl and support
for it is added to gcc and all architectures and MMU-less systems
are supported, uClibc might be obsolete.

best regards
 Waldemar

Re: [Buildroot] uClibc-ng

[Waldemar Brodkorb]

Hi Thomas,
Thomas De Schampheleire wrote,

> Hi Waldemar,
> 
> Waldemar Brodkorb <wbx@uclibc-ng.org> schreef:
> >Hello Embedded Linux Hackers,
> >
> Interesting development!  One question: how do you see musl vs
> uclibc-ng in the future? At this moment uclibc supports more
> architectures, but this may change. Do you think both should/can
> coexist? What are the distinctive features of uclibc over musl,
> according to you?

I think both can coexist for a while. uClibc is more compatible to
glibc, so most of the software packages used on embedded systems are
working fine without patching. Musl is relatively new and there are
patches required to make some stuff work. Alpine Linux, Sabotage and
OpenADK have a lot of patches, fixing musl issues.

uClibc has support for non-MMU systems. uClibc can be configured at 
build time and can be made smaller than musl. Musl can be used to
have a complete static linked system, uClibc still requires
libgcc_so.so for some threading functions. uClibc is widely used
in the embedded Linux world, musl is a newcomer.

For musl you need to patch gcc. 4.9.x does not include support for
it.

It is just good to have a choice.
At the time all software packages working fine with musl and support
for it is added to gcc and all architectures and MMU-less systems
are supported, uClibc might be obsolete.

best regards
 Waldemar

[Buildroot] uClibc-ng

[Waldemar Brodkorb]

Hi Sedat,
Sedat Dilek wrote,

> On Sun, Jul 20, 2014 at 9:13 PM, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote:
> > Hello Embedded Linux Hackers,
> >
> > it seems there is no plan to release a new uClibc version.
> > The current maintainer does not response on any public or private mails
> > about a plan to do a needed release. Therefore most of you carrying a lot
> > of patches against uClibc 0.9.33.2 to make it work in your project.
> > A really ugly situation.
> >
> 
> I have seen some patches got in uClibc upstream some weeks ago (-> inactivity).

I didn't go so far to say uClibc is dead, it is just totally unclear
when the next release is planned.

> But anyway, a 1st try...
> Look at OpenSSL and LibreSSL... Might be we see some competition or
> rebirth starting here, too?

Dunno, time will show.
 
> My POV (from my experiences) is most embedded projects are not really
> interested in upstream work or keep their own patches (this seems to
> be easier).
> An example:
> Recently, I pointed to [0], but the maintainer of the project did not
> give any feedback to Bernd (requested a simple S-o-b).
> What I want to say it is not only a problem of the uClibc maintainer :-).

I think most embedded projects try to push their local patches to
upstream. At least buildroot does it a lot and I try to do it if
time permits. In your example the uClibc maintainer could also just
add the patch and mention where he has got it from. Or should the
known bug should just be ignored, because of a missing S-o-b?
 
> From my experiences successful projects do regular releases (6 months
> or a year).
> What are your plans?

A good mantra: Release early, release often.
I have no plans doing regular releases every static time period.
Just if it make sense.
 
> > To get out of this situation I started a spin-off called uClibc-ng.
> > The website for the project is here: http://www.uclibc-ng.org
> > Beta 3 is tagged and downloadable via
> > http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz
> >
> 
> Do you plan a browsable Git website, where someone can look at the
> source via webbrowser?

Trac has it included:
http://www.uclibc-ng.org/browser/uClibc-ng
Or:
http://www.openadk.org/cgi-bin/gitweb.cgi?p=uClibc-ng.git;a=summary
 
> OK, you have now an infrastructure...
> Do you have people (developers, users) behind you :-)?

No. Just me. I am using it for my OpenADK project. I published the
stuff so others might benefit from it. Some buildroot and OpenWrt
devs were interested.
 
> > If you want a 1.0 in the near future please test and report back any
> > issues. You can use the bug tracker, the mailing list or dicussion forum
> > to report back. To prevent spam you need to be subscribed or registered.
> >
> > I have added most of the patches from your projects on top of uClibc
> > master.
> >
> 
> Did you look also at the patches [1] from the Freetz project?

Yes. I wanted to inform the freetz project, but I didn't find a
mailinglist or the mail adresses of the main contributors.
Most of the patches are either backports from git master or from
OpenWrt. I hope the rest might get contributed by the freetz people
with some meta-information, what kind of problem is fixed by a
patch.

best regards
 Waldemar
 

Re: uClibc-ng

[Waldemar Brodkorb]

Hi Sedat,
Sedat Dilek wrote,

> On Sun, Jul 20, 2014 at 9:13 PM, Waldemar Brodkorb <wbx@uclibc-ng.org> wrote:
> > Hello Embedded Linux Hackers,
> >
> > it seems there is no plan to release a new uClibc version.
> > The current maintainer does not response on any public or private mails
> > about a plan to do a needed release. Therefore most of you carrying a lot
> > of patches against uClibc 0.9.33.2 to make it work in your project.
> > A really ugly situation.
> >
> 
> I have seen some patches got in uClibc upstream some weeks ago (-> inactivity).

I didn't go so far to say uClibc is dead, it is just totally unclear
when the next release is planned.

> But anyway, a 1st try...
> Look at OpenSSL and LibreSSL... Might be we see some competition or
> rebirth starting here, too?

Dunno, time will show.
 
> My POV (from my experiences) is most embedded projects are not really
> interested in upstream work or keep their own patches (this seems to
> be easier).
> An example:
> Recently, I pointed to [0], but the maintainer of the project did not
> give any feedback to Bernd (requested a simple S-o-b).
> What I want to say it is not only a problem of the uClibc maintainer :-).

I think most embedded projects try to push their local patches to
upstream. At least buildroot does it a lot and I try to do it if
time permits. In your example the uClibc maintainer could also just
add the patch and mention where he has got it from. Or should the
known bug should just be ignored, because of a missing S-o-b?
 
> From my experiences successful projects do regular releases (6 months
> or a year).
> What are your plans?

A good mantra: Release early, release often.
I have no plans doing regular releases every static time period.
Just if it make sense.
 
> > To get out of this situation I started a spin-off called uClibc-ng.
> > The website for the project is here: http://www.uclibc-ng.org
> > Beta 3 is tagged and downloadable via
> > http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz
> >
> 
> Do you plan a browsable Git website, where someone can look at the
> source via webbrowser?

Trac has it included:
http://www.uclibc-ng.org/browser/uClibc-ng
Or:
http://www.openadk.org/cgi-bin/gitweb.cgi?p=uClibc-ng.git;a=summary
 
> OK, you have now an infrastructure...
> Do you have people (developers, users) behind you :-)?

No. Just me. I am using it for my OpenADK project. I published the
stuff so others might benefit from it. Some buildroot and OpenWrt
devs were interested.
 
> > If you want a 1.0 in the near future please test and report back any
> > issues. You can use the bug tracker, the mailing list or dicussion forum
> > to report back. To prevent spam you need to be subscribed or registered.
> >
> > I have added most of the patches from your projects on top of uClibc
> > master.
> >
> 
> Did you look also at the patches [1] from the Freetz project?

Yes. I wanted to inform the freetz project, but I didn't find a
mailinglist or the mail adresses of the main contributors.
Most of the patches are either backports from git master or from
OpenWrt. I hope the rest might get contributed by the freetz people
with some meta-information, what kind of problem is fixed by a
patch.

best regards
 Waldemar
 

[Buildroot] [OpenWrt-Devel] uClibc-ng

[Thomas Petazzoni]

Dear Florian Fainelli,

On Mon, 21 Jul 2014 11:23:46 -0700, Florian Fainelli wrote:

> 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb <wbx@uclibc-ng.org>:
> > Hello Embedded Linux Hackers,
> >
> > it seems there is no plan to release a new uClibc version.
> > The current maintainer does not response on any public or private mails
> > about a plan to do a needed release. Therefore most of you carrying a lot
> > of patches against uClibc 0.9.33.2 to make it work in your project.
> > A really ugly situation.
> 
> Although I do welcome your action, and stepping in to offer a solution
> to this, I feel like forking might have the potential of making this
> situation worse, including, but not limited to:
> 
> - creating confusion between uclibc and uclibc-ng
> - pissing off Bernhard
> - duplicating existing infrastructure instead of gaining access to it
> - what if you end up in the same situation as uClibc, we all have busy lives?
> 
> Thomas and I talked to Khem Raj about this uClibc situation during ELC
> back in June, and Khem offered some help to see if we could:
> 
> - make Bernhard aware of the lack of release situation
> - use his uclibc.org access to facilitate a 0.9.34? release

ELC was end of April, early May, and Khem told me he would act with one
month. I've pinged him several times, and nothing happened. He might
have been too afraid to piss off Bernhard.

On my side, I fully support Waldemar's fork. The last uClibc release is
more than 2 years old, and Bernhard has never been answering to *any*
of the e-mails asking to do a release, sent since September 2013 or so.
At this point, I think there is absolutely no hope to see any action
being done by the existing uClibc community in terms of doing stable
releases, and this case, the lever that open-source licenses provide is
simple: fork. That's what Waldemar has done, and it's good.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [OpenWrt-Devel] uClibc-ng

[Waldemar Brodkorb]

Hi Florian,
Florian Fainelli wrote,

> Hello,
> 
> (adding uclibc and Bernhard)
> 
> 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb <wbx@uclibc-ng.org>:
> > Hello Embedded Linux Hackers,
> >
> > it seems there is no plan to release a new uClibc version.
> > The current maintainer does not response on any public or private mails
> > about a plan to do a needed release. Therefore most of you carrying a lot
> > of patches against uClibc 0.9.33.2 to make it work in your project.
> > A really ugly situation.
> 
> Although I do welcome your action, and stepping in to offer a solution
> to this, I feel like forking might have the potential of making this
> situation worse, including, but not limited to:
> 
> - creating confusion between uclibc and uclibc-ng

What kind of confusion. uClibc-ng frontpage clearly states it is a
spin-off of uClibc.

> - pissing off Bernhard

May be I am already pissed off by him? In the past I send a patch
for mips64 n64 with no answer. After a ping a month later it got
applied. A bug report about broken sparc support never got a
response. Public mails of the buildroot project missing a release
got ignored. A private mail from me to Eric and Bernhard, response
from Eric that he is no longer involved, no answer from Bernhard.
So the selective answers of Bernhard are a problem, at least for me.

> - duplicating existing infrastructure instead of gaining access to it

I asked Bernhard if he wants to give up maintainership.

> - what if you end up in the same situation as uClibc, we all have busy lives?

So what is the situation of uClibc? The problem is lack of
communication. I would be fine if Bernhard would answer any mails
regarding non-technical issues with uClibc. A short mail "I am busy,
no release this year." would be at least a fair statement.
Or "I am very busy, having a new job, can someone make a release?"
 
> Thomas and I talked to Khem Raj about this uClibc situation during ELC
> back in June, and Khem offered some help to see if we could:
> 
> - make Bernhard aware of the lack of release situation
> - use his uclibc.org access to facilitate a 0.9.34? release

Nothing happened. Should I whine another year on the mailinglist
about a new release?
As an old OpenBSD user I am following:
Shutup and hack!
 
best regards
 Waldemar

Re: [OpenWrt-Devel] uClibc-ng

[Waldemar Brodkorb]

Hi Florian,
Florian Fainelli wrote,

> Hello,
> 
> (adding uclibc and Bernhard)
> 
> 2014-07-20 12:13 GMT-07:00 Waldemar Brodkorb <wbx@uclibc-ng.org>:
> > Hello Embedded Linux Hackers,
> >
> > it seems there is no plan to release a new uClibc version.
> > The current maintainer does not response on any public or private mails
> > about a plan to do a needed release. Therefore most of you carrying a lot
> > of patches against uClibc 0.9.33.2 to make it work in your project.
> > A really ugly situation.
> 
> Although I do welcome your action, and stepping in to offer a solution
> to this, I feel like forking might have the potential of making this
> situation worse, including, but not limited to:
> 
> - creating confusion between uclibc and uclibc-ng

What kind of confusion. uClibc-ng frontpage clearly states it is a
spin-off of uClibc.

> - pissing off Bernhard

May be I am already pissed off by him? In the past I send a patch
for mips64 n64 with no answer. After a ping a month later it got
applied. A bug report about broken sparc support never got a
response. Public mails of the buildroot project missing a release
got ignored. A private mail from me to Eric and Bernhard, response
from Eric that he is no longer involved, no answer from Bernhard.
So the selective answers of Bernhard are a problem, at least for me.

> - duplicating existing infrastructure instead of gaining access to it

I asked Bernhard if he wants to give up maintainership.

> - what if you end up in the same situation as uClibc, we all have busy lives?

So what is the situation of uClibc? The problem is lack of
communication. I would be fine if Bernhard would answer any mails
regarding non-technical issues with uClibc. A short mail "I am busy,
no release this year." would be at least a fair statement.
Or "I am very busy, having a new job, can someone make a release?"
 
> Thomas and I talked to Khem Raj about this uClibc situation during ELC
> back in June, and Khem offered some help to see if we could:
> 
> - make Bernhard aware of the lack of release situation
> - use his uclibc.org access to facilitate a 0.9.34? release

Nothing happened. Should I whine another year on the mailinglist
about a new release?
As an old OpenBSD user I am following:
Shutup and hack!
 
best regards
 Waldemar

[Buildroot] [OpenWrt-Devel] uClibc-ng

[Thomas Petazzoni]

Dear Florian Fainelli,

On Mon, 21 Jul 2014 11:55:21 -0700, Florian Fainelli wrote:

> > On my side, I fully support Waldemar's fork. The last uClibc release is
> > more than 2 years old, and Bernhard has never been answering to *any*
> > of the e-mails asking to do a release, sent since September 2013 or so.
> > At this point, I think there is absolutely no hope to see any action
> > being done by the existing uClibc community in terms of doing stable
> > releases, and this case, the lever that open-source licenses provide is
> > simple: fork. That's what Waldemar has done, and it's good.
> 
> To speak my mind, I think uClibc has no future in the next 2 or 3
> years, musl is a much more active project, with multiple embedded
> projects starting to use it, on the other end, (e)glibc has remedied
> its own problems and its useful again.
> 
> No MMU architectures are becoming less and less popular, and the cost
> for larger flash storage mediums keeps decreasing, so all these key
> selling features (noMMU support and reduced memory footprint) that
> uClibc has will soon no longer be any useful to it.

I don't really think noMMU architectures are becoming less and less
popular. There is actually a whole new generation of
Cortex-M3/Cortex-M4 based processors that are capable of running Linux
and that offer really nice power management capabilities.

> Bottom line is, I believe uClibc is a (relatively speaking) dead
> project already, forking it might be useful to keep the existing user
> base alive, but I expect all of them to transition to something active
> and maintained, whether that's glibc or musl.

I also agree that probably not that much is going to appear in uClibc,
especially with the currently slow release cycle. However, a C library
is something that needs to be maintained (as the significant number of
uClibc patches that we all carry around indicates), and therefore
having a central upstream that is alive remains useful.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [OpenWrt-Devel] uClibc-ng

[Waldemar Brodkorb]

Hi Florian,
Florian Fainelli wrote,

> To speak my mind, I think uClibc has no future in the next 2 or 3
> years, musl is a much more active project, with multiple embedded
> projects starting to use it, on the other end, (e)glibc has remedied
> its own problems and its useful again.

I am on your site here. But the 2-3 years must be become such a bad
time for embedded users? 
We already have separate repositories for ARC and NPTL support and for
Xtensa and NPTL. We have different projects all using different
patch sets on top of 0.9.33.x. Buildroot, OpenWrt, OpenEmbedded,
Freetz, Bering-Uclibc, OpenADK, Aboriginal (musl switch is in work).

I do not see such a bad split-off in musl. Why? Because musl have a 
responsive and active maintainer. 
 
> Bottom line is, I believe uClibc is a (relatively speaking) dead
> project already, forking it might be useful to keep the existing user
> base alive, but I expect all of them to transition to something active
> and maintained, whether that's glibc or musl.

Sure, and that is totally okay for me. I just wanna make the
existing userbase happy for the time, they can not switch to musl or
glibc. Why not make the transition smooth?

best regards
 Waldemar

Re: [OpenWrt-Devel] uClibc-ng

[Waldemar Brodkorb]

Hi Florian,
Florian Fainelli wrote,

> To speak my mind, I think uClibc has no future in the next 2 or 3
> years, musl is a much more active project, with multiple embedded
> projects starting to use it, on the other end, (e)glibc has remedied
> its own problems and its useful again.

I am on your site here. But the 2-3 years must be become such a bad
time for embedded users? 
We already have separate repositories for ARC and NPTL support and for
Xtensa and NPTL. We have different projects all using different
patch sets on top of 0.9.33.x. Buildroot, OpenWrt, OpenEmbedded,
Freetz, Bering-Uclibc, OpenADK, Aboriginal (musl switch is in work).

I do not see such a bad split-off in musl. Why? Because musl have a 
responsive and active maintainer. 
 
> Bottom line is, I believe uClibc is a (relatively speaking) dead
> project already, forking it might be useful to keep the existing user
> base alive, but I expect all of them to transition to something active
> and maintained, whether that's glibc or musl.

Sure, and that is totally okay for me. I just wanna make the
existing userbase happy for the time, they can not switch to musl or
glibc. Why not make the transition smooth?

best regards
 Waldemar

[Buildroot] [OpenWrt-Devel] uClibc-ng

[Bernhard Reutner-Fischer]

On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote:
> 
> 
> Il 23 luglio 2014 13:42:38 Jody Bruchon <jody@jodybruchon.com> ha scritto:
> 
> >On 7/22/2014 11:30 PM, Steve Bennett wrote:> I would like to add my
> >support to Thomas' position.
> > > Regardless of what happens with glibc and/or musl, an active community
> > > supporting regular releases of uClibc is a good thing.
> > > Time has spoken that we can't expect this to happen unless something
> >changes.
> >
> >I agree. It is better to have a responsive maintainer releasing periodic
> >"stable" versions than to have what is essentially no maintainer and
> >sustained long-term fragmentation of what "uClibc" really is. If the
> >uClibc maintainer wakes up in the future and begins releasing again, the
> >new project's changes can always be merged back to the parent, as they
> >did with eglibc and glibc. For now we need to focus on making a stable
> >release, something which is grossly overdue and harms all projects
> >currently using uClibc.
> >
> >I also agree that musl is an interesting project with a bright future
> >(and a bright present for that matter), but it does not cover all of
> >what uClibc covers and the number of projects that already require
> >uClibc is too large to simply drop uClibc and move to musl.
> >
> >-Jody Bruchon
> 
> Gents,
> Are we considering anyway that Bernard has recently restarted with patches
> review and commit without no contribution from the other co-maintainers
> (myself the first) ?
> Likely Bernard is already preparing a release !

Yea, but very very slowly, i know.
I just started preparing a meta-changelog for the release notes and
then we'll call it an official tarball.

Lots of changes, about 10% done, approx. 1h left before bedtime.

Any prominent changes we should make absolutely sure to mention?

Re: [OpenWrt-Devel] uClibc-ng

[Bernhard Reutner-Fischer]

On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote:
> 
> 
> Il 23 luglio 2014 13:42:38 Jody Bruchon <jody@jodybruchon.com> ha scritto:
> 
> >On 7/22/2014 11:30 PM, Steve Bennett wrote:> I would like to add my
> >support to Thomas' position.
> > > Regardless of what happens with glibc and/or musl, an active community
> > > supporting regular releases of uClibc is a good thing.
> > > Time has spoken that we can't expect this to happen unless something
> >changes.
> >
> >I agree. It is better to have a responsive maintainer releasing periodic
> >"stable" versions than to have what is essentially no maintainer and
> >sustained long-term fragmentation of what "uClibc" really is. If the
> >uClibc maintainer wakes up in the future and begins releasing again, the
> >new project's changes can always be merged back to the parent, as they
> >did with eglibc and glibc. For now we need to focus on making a stable
> >release, something which is grossly overdue and harms all projects
> >currently using uClibc.
> >
> >I also agree that musl is an interesting project with a bright future
> >(and a bright present for that matter), but it does not cover all of
> >what uClibc covers and the number of projects that already require
> >uClibc is too large to simply drop uClibc and move to musl.
> >
> >-Jody Bruchon
> 
> Gents,
> Are we considering anyway that Bernard has recently restarted with patches
> review and commit without no contribution from the other co-maintainers
> (myself the first) ?
> Likely Bernard is already preparing a release !

Yea, but very very slowly, i know.
I just started preparing a meta-changelog for the release notes and
then we'll call it an official tarball.

Lots of changes, about 10% done, approx. 1h left before bedtime.

Any prominent changes we should make absolutely sure to mention?

Re: [OpenWrt-Devel] uClibc-ng

[Khem Raj]

On Thu, Jul 24, 2014 at 1:48 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote:
>>
>>
>> Il 23 luglio 2014 13:42:38 Jody Bruchon <jody@jodybruchon.com> ha scritto:
>>
>> >On 7/22/2014 11:30 PM, Steve Bennett wrote:> I would like to add my
>> >support to Thomas' position.
>> > > Regardless of what happens with glibc and/or musl, an active community
>> > > supporting regular releases of uClibc is a good thing.
>> > > Time has spoken that we can't expect this to happen unless something
>> >changes.
>> >
>> >I agree. It is better to have a responsive maintainer releasing periodic
>> >"stable" versions than to have what is essentially no maintainer and
>> >sustained long-term fragmentation of what "uClibc" really is. If the
>> >uClibc maintainer wakes up in the future and begins releasing again, the
>> >new project's changes can always be merged back to the parent, as they
>> >did with eglibc and glibc. For now we need to focus on making a stable
>> >release, something which is grossly overdue and harms all projects
>> >currently using uClibc.
>> >
>> >I also agree that musl is an interesting project with a bright future
>> >(and a bright present for that matter), but it does not cover all of
>> >what uClibc covers and the number of projects that already require
>> >uClibc is too large to simply drop uClibc and move to musl.
>> >
>> >-Jody Bruchon
>>
>> Gents,
>> Are we considering anyway that Bernard has recently restarted with patches
>> review and commit without no contribution from the other co-maintainers
>> (myself the first) ?
>> Likely Bernard is already preparing a release !
>
> Yea, but very very slowly, i know.
> I just started preparing a meta-changelog for the release notes and
> then we'll call it an official tarball.
>
> Lots of changes, about 10% done, approx. 1h left before bedtime.
>
> Any prominent changes we should make absolutely sure to mention?

I think

ARC support would be one.
standalone execution on x86_64 now works
math tests are fixed
MIPS64R2 support is added




> _______________________________________________
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc