GNU Arm Embedded Toolchain

Could you please deliver the GCC source code in a separated tarball?

Asked by TiN

Hello, I'm the Debian maintainer of the package gcc-arm-none-eabi. I have been maintaining for a while pulling the changes directly from svn, but now that you have releases on regular basis it'd be easier to synchronize the package with the tarball instead. Now, the tarball you release contains the whole toolchain, so I have to mangle the tarball and rebuild it using a custom script. If you provide instead a separated tarball with the GCC code, I can fetch it directly from the web page and package it as is.

Thanks in advance,

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
TiN
Solved:
Last query:
Last reply:
Revision history for this message
Tejas Belagod (belagod-tejas) said : 		#1

Hi,

The sources to GCC are included in the src tarball. Are you saying you'd like a separate tarball just for GCC?

Thanks,
Tejas.

Revision history for this message
TiN (agustinhenze) said : 		#2

Yes, I'd like to have a separate tarball just for GCC. In Debian exists a tool called uscan, it's for tracking upstream and every time that upstream makes a new release you get a notification through this. Right now, I have to execute my custom script[0] to repack the upstream tarball and I miss the good feature of receiving notifications when a new upstream release is done.

[0] https://salsa.debian.org/debian/gcc-arm-none-eabi/blob/master/debian/repack-upstream.py

Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#3

Hi Agustin,

I do not understand why a unified tarball prevents the use of uscan. The 4 elements of a debian/watch line is a script to execute when a new version is detected. People usually call uupdate but you could call you any script instead, for instance your repack script.

By the way, why do you remove directories from GCC's testsuite?

Best regards,

Thomas

Revision history for this message
TiN (agustinhenze) said : 		#4

Yes, you're right. Anyway, I wouldn't like to maintain this piece of software. But, if you say that you are not going to change the layout of the tarball in future releases or letting me know in advance if you change it, could work well.

Actually right now, I can't use uscan because it has a bug[0] and doesn't fetch the href from the GNU ARM embedded page. I suspect that the spaces are confusing to uscan, but I really don't know. If you can modify the href removing the spaces to see if we can sort out the bug, that'd be really good because I don't know if uscan is going to get fixed soon.

I'm removing everything that is not needed, because it's repeated for the GCC compiler distributed by Debian.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904578

Revision history for this message
TiN (agustinhenze) said : 		#5

Well actually I've tried locally and removing `data-eula-href=""` from the href it works

Revision history for this message
Tejas Belagod (belagod-tejas) said : 		#6

> But, if you say that you are not going to change the layout of the tarball in future releases or letting me know in advance if you change it, could work well.

We can definitely keep you informed of our plans if we decide to change the tarball layout. How much of a notice would be reasonable for you to make changes on your end?

Revision history for this message
TiN (agustinhenze) said : 		#7

Great! Just one week in advance would be ok, if you want to send a patch instead would be better :).

Thanks!