Dear Hakan, Thank You very much for your quick reply.
Unfortunately I don’t know too much about the development history of this package @Debian and the related decisions. It would be helpful though to have other developers and maintainers to have their say on this to help find a common solution. At first one should find out if support for newer devices would suffer from such an approach. I have not come across that topic yet... Best regards Nightwalker-87 > Am 25.07.2019 um 18:17 schrieb Hakan Ardo <hakan.a...@gmail.com>: > > Hi, > gcc-avr was originally built from the mainline gcc, but was later split out > by to build depend on gcc-source as it was not wanted in the mainstream gcc > package. Has that situation changed? > > It was then decided to base the package on the Atmel distribution instead of > the upstream source as that gave support for newer devices faster. > > Now, as far as I can tell, Atmel have dropped their source distribution and > only provided binaries. So something have to be done indeed. > > Switching back to use upstream source would be one option. But will that mean > we'll have to dropp support for newer devices? > > Den tors 25 juli 2019 17:27nightwalker-87 <nightwalker...@t-online.de > <mailto:nightwalker...@t-online.de>> skrev: > Package: gcc-avr > Version: 1:5.4.0+Atmel3.6.1-2 > Severity: normal > Tags: newcomer > > Dear Maintainer, > > It appears that the gcc-avr toolchain in the debian repository is severely > outdated compared to the current level of version support for the main gcc > toolchain. This leaves avr-developers wishing to use newer C language features > behind and makes it necessary to use external toolchains (source based or pre- > compiled). Pointing to this in the debian-devel IRC-Channel, lead to the > following idea: "if it was in mainline, the gcc-avr package could be dropped > in > favour of a package built from the mainline version of gcc." as well as "an > example of such a source package is gcc-arm-none-eabi, the equivalent for avr > could be added by someone interested, then gcc-avr could be removed." (user: > pabs) From my point of view this could be a promising approach to resume > development on this topic. I would appreciate, if debian developers could take > action on this topic to resolve this long lasting backlog and make > contribution > to make debian even more attractive for development. As it stands the avr-8 > architecture will remain for many years to come in some parts even with new > applications. > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages gcc-avr depends on: > ii binutils-avr 2.26.20160125+Atmel3.6.1-4 > ii libc6 2.28-10 > ii libgcc1 1:8.3.0-7 > ii libgmp10 2:6.1.2+dfsg-4 > ii libmpc3 1.1.0-1 > ii libmpfr6 4.0.2-1 > ii libstdc++6 8.3.0-7 > ii zlib1g 1:1.2.11.dfsg-1 > > gcc-avr recommends no packages. > > Versions of packages gcc-avr suggests: > ii avr-libc 1:2.0.0+Atmel3.6.1-2 > ii gcc 4:8.3.0-1 > pn gcc-doc <none> > > -- no debconf information
