On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote: > > 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. > Probably still a good idea to CC them or file a bug in the BTS to > document your intentions, as adding a binary package is not a usual > change, even if the NMU criterias are fulfilled. Okay, I made some noise on the bug report today and Cc'ed the debian- toolchain mailing list on it. I'm not touching the moreinfo tag yet to give them time to respond. > Alternatively, you should consider ITS'ing the package. > At least from your description it sounds as it would be a valid > candidate, but I didn't check the details. I do believe it would be a valid candidate, but I don't think it would be a good idea to salvage it until I get gcc-sh-elf into the archive. The best way forward for the Newlib package is to only provide a newlib-source package, and make the respective GCC source packages (like gcc-sh-elf and gcc-arm-none-eabi) build their own Newlib ports. For reasons I won't repeat here, this should be best practice, but I am not yet in a position to where I can assume responsibility for the ARM packages that are currently built by the Newlib source package. > please change to experimental. (Its anyway _always_ a good idea to > clear NEW first via experimental…) Done.
Attachment:
signature.asc
Description: This is a digitally signed message part