[gentoo-dev] News Item for uClibc-ng deprecation

[gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

Hi everyone,

Can I get feedback on the following news item?  (BTW, thanks soap)

Title: uClibc-ng retirement on 2023/01/01
Author: Anthony G. Basile <blueness@gentoo.org>
Posted: 2021-08-15
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/uclibc/*

uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
noone has volunteered to step up maintenance or expressed interest in
the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
profiles, which will be removed on 2023/01/01. For parties interested in
an alternative libc, consider moving to musl, which is supported.

Gentoo continues to wholeheartedly support musl and is focusing its
efforts in that area.

Resources:
- https://wiki.gentoo.org/wiki/Project:Hardened_musl
- https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
- #gentoo-hardened (IRC channel on irc.libera.chat) for support and
discussion


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Alexey Sokolov]

17.08.2021 12:40, Anthony G. Basile пишет:
> Hi everyone,
> 
> Can I get feedback on the following news item?  (BTW, thanks soap)
> 
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile <blueness@gentoo.org>
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
> 
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in

2023-01-01 please.

> an alternative libc, consider moving to musl, which is supported.
> 
> Gentoo continues to wholeheartedly support musl and is focusing its
> efforts in that area.
> 
> Resources:
> - https://wiki.gentoo.org/wiki/Project:Hardened_musl
> - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
> - #gentoo-hardened (IRC channel on irc.libera.chat) for support and
> discussion
> 
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Joshua Kinard]

On 8/17/2021 07:40, Anthony G. Basile wrote:
> Hi everyone,
> 
> Can I get feedback on the following news item?  (BTW, thanks soap)
> 
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile <blueness@gentoo.org>
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
> 
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in
> an alternative libc, consider moving to musl, which is supported.
> 
> Gentoo continues to wholeheartedly support musl and is focusing its
> efforts in that area.
> 
> Resources:
> - https://wiki.gentoo.org/wiki/Project:Hardened_musl
> - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches)
> - #gentoo-hardened (IRC channel on irc.libera.chat) for support and
> discussion

According to the uClibc-ng website, 1.0.38 was released earlier this year
(March 27th).  Was an announcement put out somewhere about the project not
being maintained any further beyond that release, or has it gone quiet after
that?

I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
Python3 in my stage3's mysteriously all started failing for unexplained
reasons.  Thought about trying to bootstrap a new environment from scratch
at some point, but just haven't gotten around to it.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Mike Gilbert]

On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile <blueness@gentoo.org> wrote:
>
> Hi everyone,
>
> Can I get feedback on the following news item?  (BTW, thanks soap)
>
> Title: uClibc-ng retirement on 2023/01/01
> Author: Anthony G. Basile <blueness@gentoo.org>
> Posted: 2021-08-15
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/uclibc/*
>
> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> noone has volunteered to step up maintenance or expressed interest in
> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> profiles, which will be removed on 2023/01/01. For parties interested in
> an alternative libc, consider moving to musl, which is supported.

2023? That seems like a pretty long time to wait to remove something
that isn't very well supported right now.

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]



> On 17 Aug 2021, at 16:19, Joshua Kinard <kumba@gentoo.org> wrote:
> [snip]
> 
> According to the uClibc-ng website, 1.0.38 was released earlier this year
> (March 27th).  Was an announcement put out somewhere about the project not
> being maintained any further beyond that release, or has it gone quiet after
> that?

Upstream supporting something doesn't mean that's the case in Gentoo. The
last "proper" mention of deprecating uclibc in Gentoo was from blueness
in January this year [0].

Funnily enough: while digging for the email, I did notice you replied [1] and couldn't
build ncurses, which is pretty apt for illustrating the problems here. That is, no developers
within Gentoo are supporting uclibc, none of us are really surprised when common/core packages
break, and the tracker [2] at least is rotting (as are other uclibc-related bugs).

The gist is, it's not really supported anymore now. This is just about formally dropping
it. I'd be really surprised if anyone is able to use this day-to-day without a fair amount
of patches.

In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to step in future,
we can look at uclibc-ng again, but I don't think we've got the resources right now.

[0] https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
[1] https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
[2] https://bugs.gentoo.org/570544

> 
> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
> Python3 in my stage3's mysteriously all started failing for unexplained
> reasons.  Thought about trying to bootstrap a new environment from scratch
> at some point, but just haven't gotten around to it.
> 

That sounds like a good reason to dump it too ;)

best,
sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Joshua Kinard]

On 8/17/2021 13:49, Sam James wrote:
> 
> 
>> On 17 Aug 2021, at 16:19, Joshua Kinard <kumba@gentoo.org> wrote:
>> [snip]
>>
>> According to the uClibc-ng website, 1.0.38 was released earlier this year
>> (March 27th).  Was an announcement put out somewhere about the project not
>> being maintained any further beyond that release, or has it gone quiet after
>> that?
> 
> Upstream supporting something doesn't mean that's the case in Gentoo. The
> last "proper" mention of deprecating uclibc in Gentoo was from blueness
> in January this year [0].
> 
> Funnily enough: while digging for the email, I did notice you replied [1] and couldn't
> build ncurses, which is pretty apt for illustrating the problems here. That is, no developers
> within Gentoo are supporting uclibc, none of us are really surprised when common/core packages
> break, and the tracker [2] at least is rotting (as are other uclibc-related bugs).
> 
> The gist is, it's not really supported anymore now. This is just about formally dropping
> it. I'd be really surprised if anyone is able to use this day-to-day without a fair amount
> of patches.
> 
> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to step in future,
> we can look at uclibc-ng again, but I don't think we've got the resources right now.
> 
> [0] https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
> [1] https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
> [2] https://bugs.gentoo.org/570544
> 
>>
>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
>> Python3 in my stage3's mysteriously all started failing for unexplained
>> reasons.  Thought about trying to bootstrap a new environment from scratch
>> at some point, but just haven't gotten around to it.
>>
> 
> That sounds like a good reason to dump it too ;)

The thing is, the breakage I describe is *really* weird.  Unpack my 2019
uclibc-ng stage3 on a MIPS system, chroot in, everything works fine.  But
the instant you recompile ncurses inside of it, using the *same* Portage
snapshot that it was built from, the Python interpreter falls over with a
NULL deref in its curses module.  I've debugged it down to the exact line of
C code in Python, but cannot find an explanation why it fails.

I've had my share of weird crap running these SGI systems, but this one
takes the cake.  That's why I gave up on uclibc-ng for a time until I could
try kickstarting a new build from scratch using OpenADK (which still
supports older pre-mips32/64r* platforms).  No other choice, really, because
once Python goes down, so too does emerge.

Even bugged it on Python's bug tracker, but no surprise it's gone ignored:
https://bugs.python.org/issue39819

In any event, yeah, I don't have a real issue with dropping it.  I've
noticed that some of the more recent commits to it are really just ingesting
chunks of glibc and stripping out some of the macro fluff.  There's actually
a change in upstream glibc I've yet to test on one of my non-coherent cache
platforms that uclibc-ng pulled in that probably breaks them in fun fun ways
(not that that platform ever worked well from the beginning, though...).

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile <blueness@gentoo.org> wrote:
> >
> > Hi everyone,
> >
> > Can I get feedback on the following news item?  (BTW, thanks soap)
> >
> > Title: uClibc-ng retirement on 2023/01/01
> > Author: Anthony G. Basile <blueness@gentoo.org>
> > Posted: 2021-08-15
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Profile: default/linux/uclibc/*
> >
> > uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> > noone has volunteered to step up maintenance or expressed interest in
> > the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> > profiles, which will be removed on 2023/01/01. For parties interested in
> > an alternative libc, consider moving to musl, which is supported.
> 
> 2023? That seems like a pretty long time to wait to remove something
> that isn't very well supported right now.

+1

While I have no involvement with uClibc-ng, it does seem awfully long
before removal.

-Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

On 8/17/21 2:08 PM, Joshua Kinard wrote:
> On 8/17/2021 13:49, Sam James wrote:
>>
>>
>>> On 17 Aug 2021, at 16:19, Joshua Kinard <kumba@gentoo.org> wrote:
>>> [snip]
>>>
>>> According to the uClibc-ng website, 1.0.38 was released earlier this year
>>> (March 27th).  Was an announcement put out somewhere about the project not
>>> being maintained any further beyond that release, or has it gone quiet after
>>> that?
>>
>> Upstream supporting something doesn't mean that's the case in Gentoo. The
>> last "proper" mention of deprecating uclibc in Gentoo was from blueness
>> in January this year [0].
>>
>> Funnily enough: while digging for the email, I did notice you replied [1] and couldn't
>> build ncurses, which is pretty apt for illustrating the problems here. That is, no developers
>> within Gentoo are supporting uclibc, none of us are really surprised when common/core packages
>> break, and the tracker [2] at least is rotting (as are other uclibc-related bugs).
>>
>> The gist is, it's not really supported anymore now. This is just about formally dropping
>> it. I'd be really surprised if anyone is able to use this day-to-day without a fair amount
>> of patches.
>>
>> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to step in future,
>> we can look at uclibc-ng again, but I don't think we've got the resources right now.
>>
>> [0] https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781
>> [1] https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe
>> [2] https://bugs.gentoo.org/570544
>>
>>>
>>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when
>>> Python3 in my stage3's mysteriously all started failing for unexplained
>>> reasons.  Thought about trying to bootstrap a new environment from scratch
>>> at some point, but just haven't gotten around to it.
>>>
>>
>> That sounds like a good reason to dump it too ;)
> 
> The thing is, the breakage I describe is *really* weird.  Unpack my 2019
> uclibc-ng stage3 on a MIPS system, chroot in, everything works fine.  But
> the instant you recompile ncurses inside of it, using the *same* Portage
> snapshot that it was built from, the Python interpreter falls over with a
> NULL deref in its curses module.  I've debugged it down to the exact line of
> C code in Python, but cannot find an explanation why it fails.
> 
> I've had my share of weird crap running these SGI systems, but this one
> takes the cake.  That's why I gave up on uclibc-ng for a time until I could
> try kickstarting a new build from scratch using OpenADK (which still
> supports older pre-mips32/64r* platforms).  No other choice, really, because
> once Python goes down, so too does emerge.
> 
> Even bugged it on Python's bug tracker, but no surprise it's gone ignored:
> https://bugs.python.org/issue39819
> 
> In any event, yeah, I don't have a real issue with dropping it.  I've
> noticed that some of the more recent commits to it are really just ingesting
> chunks of glibc and stripping out some of the macro fluff.  There's actually
> a change in upstream glibc I've yet to test on one of my non-coherent cache
> platforms that uclibc-ng pulled in that probably breaks them in fun fun ways
> (not that that platform ever worked well from the beginning, though...).
> 

Its broken on every arch.  Its time for it to go.  What little time I
have I need to put into musl.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

On 8/17/21 2:24 PM, Aaron Bauman wrote:
> On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
>> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile <blueness@gentoo.org> wrote:
>>>
>>> Hi everyone,
>>>
>>> Can I get feedback on the following news item?  (BTW, thanks soap)
>>>
>>> Title: uClibc-ng retirement on 2023/01/01
>>> Author: Anthony G. Basile <blueness@gentoo.org>
>>> Posted: 2021-08-15
>>> Revision: 1
>>> News-Item-Format: 2.0
>>> Display-If-Profile: default/linux/uclibc/*
>>>
>>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
>>> noone has volunteered to step up maintenance or expressed interest in
>>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
>>> profiles, which will be removed on 2023/01/01. For parties interested in
>>> an alternative libc, consider moving to musl, which is supported.
>>
>> 2023? That seems like a pretty long time to wait to remove something
>> that isn't very well supported right now.
> 
> +1
> 
> While I have no involvement with uClibc-ng, it does seem awfully long
> before removal.
> 
> -Aaron
> 

How does 2022-08-01 sound?  That's about 1 year.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] News Item for uClibc-ng deprecation

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On Tue, Aug 17, 2021 at 02:54:19PM -0400, Anthony G. Basile wrote:
> On 8/17/21 2:24 PM, Aaron Bauman wrote:
> > On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote:
> >> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile <blueness@gentoo.org> wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> Can I get feedback on the following news item?  (BTW, thanks soap)
> >>>
> >>> Title: uClibc-ng retirement on 2023/01/01
> >>> Author: Anthony G. Basile <blueness@gentoo.org>
> >>> Posted: 2021-08-15
> >>> Revision: 1
> >>> News-Item-Format: 2.0
> >>> Display-If-Profile: default/linux/uclibc/*
> >>>
> >>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021,
> >>> noone has volunteered to step up maintenance or expressed interest in
> >>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc"
> >>> profiles, which will be removed on 2023/01/01. For parties interested in
> >>> an alternative libc, consider moving to musl, which is supported.
> >>
> >> 2023? That seems like a pretty long time to wait to remove something
> >> that isn't very well supported right now.
> > 
> > +1
> > 
> > While I have no involvement with uClibc-ng, it does seem awfully long
> > before removal.
> > 
> > -Aaron
> > 
> 
> How does 2022-08-01 sound?  That's about 1 year.

Since we know it is broken, a year even seems long.
Also, We can't get rid of the uclibc-based profiles until uclibc is removed.

Thanks,

William

> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail    : blueness@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]