On Thu, 14 Oct 2021 00:46:43 +0000 John Scott <jsc...@posteo.net> wrote:
> Source: newlib
> Version: 3.3.0-1.1
> Severity: important
> X-Debbugs-Cc: debian-toolch...@lists.debian.org,
pkg-electronics-de...@alioth-lists.debian.net, m...@qa.debian.org
>
> The Newlib package is, in my opinion, currently in a poor state of
> affairs.
> * The upstream release 4.1.0 has yet to be packaged.
> * It currently uses an obsolete Debhelper compatibility level, which
> puts it at risk of being removed in the Bookworm release cycle
> (#965746).
> * Ports to new systems, such as riscv64-unknown-elf, are wanted
> (#980918).
> * There is at least one credible security issue which hasn't been
> addressed (#984446).
>
> I believe this package is eligible for salvaging based on these facts:
> * My previous NMU of Newlib went unacknowledged.
> * The maintainers have been unresponsive to my attempts at contact.
> * There has been no visible work on the package for 18 months.
>
> Here is my game plan for Newlib, which I have alluded to on the pkg-
> electronics-devel list and not gotten any pushback on:
> * It provides multiple benefits, including avoiding the bootstrap
> problem and enabling running of the GCC test suite, for the GCC
> packages for various ports to also be responsible for building Newlib.
> This can be done using a combined tree; an initial upload of gcc-sh-elf
> is imminent which will demonstrate this technique.
>
> * I will accordingly make gcc-arm-none-eabi responsible for building
> its own Newlib port by preparing a merge request soon.
>
> * libnewlib-dev is a misnomer; this package should really be called
> libnewlib-arm-none-eabi-dev. I will turn libnewlib-dev into a
> transitional package.
>
> * Only after the dust has settled will I upload Newlib 4.1.0. The
> "downstream consumers" (gcc-sh-elf, gcc-arm-none-eabi, gcc-riscv64-
> none-elf) will be able to migrate to this version at their own pace
> whenever they get rebuilt.
>
> * In the end, I plan for the Newlib source package to provide only two
> binaries: newlib-source, and libnewlib-doc.
>
> I expect that my work will be most welcome within the Electronics Team,
> but if they'd prefer, I could also maintain this under my own
> namespace. In any case, I'm not a project member and will require
> sponsorship, so I will not be able to upload this package on my own.
Sounds good to me! I just read what you wrote here, sorry for the delay.
Feel free to move forward with this plan.
--
TiN
