Re: [oe] [OpenWrt-Devel] uClibc-ng
Hi Florian, Florian Fainelli wrote, > Hello, > > (adding uclibc and Bernhard) > > 2014-07-20 12:13 GMT-07:00 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. > > 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OpenWrt-Devel] uClibc-ng
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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OpenWrt-Devel] uClibc-ng
On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote: > > > Il 23 luglio 2014 13:42:38 Jody Bruchon 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? -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OpenWrt-Devel] uClibc-ng
On Thu, Jul 24, 2014 at 1:48 PM, Bernhard Reutner-Fischer wrote: > On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote: >> >> >> Il 23 luglio 2014 13:42:38 Jody Bruchon 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 > ucl...@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
