Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

2021-04-18 Thread John Scott
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for Newlib:

 * Package name    : newlib
   Version : 3.3.0-1.1
   Upstream Author : Red Hat and others
 * URL : https://sourceware.org/newlib/
 * License : various
 * Vcs : https://salsa.debian.org/debian/newlib
   Section : devel

It builds those binary packages:

  newlib-source - C library and math library for embedded systems (source)
  libnewlib-arm-none-eabi - C library and math library compiled for bare metal 
using Cortex A/R/M
  libnewlib-doc - C library and math library intended for use on embedded 
systems (doc)
  libnewlib-dev - C library and math library intended for use on embedded 
systems

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/newlib/

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/newlib/newlib_3.3.0-1.1.dsc

Changes since the last upload:

 newlib (3.3.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add newlib-source binary package to aid building for new targets.
 (Closes: #912271)

This change wouldn't normally be appropriate for an NMU, but the
maintainer, Agustin Henze, hasn't been responsive to my attempts for
contact, and is also on the LowThresholdNmu list and keeps the package
in the Debian group on Salsa for collaborative maintenance:
https://wiki.debian.org/LowThresholdNmu

I haven't encountered the maintainer previously, but believe in good
faith that these changes would be welcome and that the LowThresholdNmu
criterion are met by addressing a bug with important severity. My
interest in this bug, to introduce a newlib-source binary package, is
to unblock my progress on gcc-sh-elf, which is otherwise almost ready.

That package will bootstrap a toolchain by building GCC and Newlib
simultaneously in a combined build tree, which in my opinion is best
practice for embedded toolchains going forward.

The changelog is set to unstable in anticipation that I won't manage to
clear NEW before Bullseye is released. If anyone would be so kind to
sponsor me sooner, I could change that to experimental.


signature.asc
Description: This is a digitally signed message part


Bug#985563: RFS: binutils-sh-elf/1 [ITP] -- GNU binary utilities for embedded SuperH devices

2021-04-18 Thread John Scott
On Fri, 19 Mar 2021 19:30:45 -0400 John Scott  wrote:
> The package should be built against experimental.

I've come to realize that on the buildd's, packages from experimental
aren't pulled in unless required to satisfy the build dependencies.
Disregard this; it's not a big deal, except that the autopkgtest does
require GCC 11, but I don't think those are run for experimental
anyway.


signature.asc
Description: This is a digitally signed message part