[Pkg-electronics-devel] Heads up, what's the status an the Arduino package(s) in Debian?

[Carsten Schoenert]

Hi there,

after several hours and days working on updating Arduino I want to give
some feedback and some kind of status on the things I have and I'm
currently working on.
But it's not only me who is doing some work on improving the package
situation of the Arduino IDE. So another part of work is done by Rock Storm.

The situation on the Arduino IDE is a bit fragmented. Means there isn't
only one package that needs an update, there are now more and new
packages needed. In the past Geert Stappers, Ignacio Losiggio and also
Scott Howard did some work on updating the IDE version. I want and need
to thank these peoples, without this previous work we would have to fix
a lot of more things.
Currently Rock and myself seeing the following dependencies we have to take.

1. Arduino IDE [1] (Debian src:arduino)
   This is the main IDE application.

2. Arduino Builder [2] (Debian new src:arduino-builder)
   This part was split of from the IDE and the resulting package is
   "building" the binary files from the sketch files and also take care
   on bringing them onto the target. It's written in Go.
   Building the binary package requires unfortunately packaging other
   new Go build dependencies.
   This will get superseded one day by arduino-cli.

2.1. Arduino CTAGS [3] (Debian new arc:arduino-ctags)
   This, as the name is obviously already saying, is a clone of the
   Exuberant Ctags package and is also a new build dependency for
   Arduino Builder.
   So far I can see this clone was happen as the upstream project for
   Exuberant Ctags is nearly dead since years.

2.x Some more Go packages as build dependency for Arduino Builder.
   Rock can say more on this part.

3. Arduino Core AVR [4] (Debian new src:arduino-core-avr)
   As for the builder part also this specific part was also split of
   from the IDE. It includes core AVR stuff which is always needed to
   work with the IDE like libraries, bootloaders and firmware.

I have worked on 1. and 3., Rock is working on the package that fall into 2.

What is the situation for point 1?
Thanks to a lot of work that was done by Geert, Ignacio and Scott I'm no
in a position where I have successful imported the latest release of the
IDE (1.8.13) with some needed adjustment on filtering of non DFSG stuff.
I was also able to renew the patch queue to get the new source build-able.
Due the split off on old stuff the structure of the existing binary
packages has changed. The package now don't provide any additional
"core" stuff and I've dropped that binary package and migrated all
remaining things back into the arduino package which is now also
arch:any due a required external architecture related library.

The last thing I was working on is the rewrite of debian/copyright. As
always, not the funniest things I'd like to work on. And I found some
inconsistencies between the existing source and the file license.txt in
the top folder and the data within build/linux/dist/appdata.xml. For me
it looks like no one in the upstream project did ever update all these
data in the files. I've contacted Matthijs from Arduino and asked for
some help in clearing the situation.

I use a clone of the git tree from pkg-electronic to prepare and collect
my work within my namespace on Salsa [5].

What is the situation for point 3?
This package is a complete new package, I opened issue #977605 [6] as
ITP about this package.
I have a working package, means it technically packaged. But the devil
is in the details as we are bound to the DFSG if the package needs to go
into main.
All the prebuilded binary staff that is shipped in the upstream release
needs to get filtered out and requires a rebuild while package creation
(btw. that was never done in the old package arduino-core so far I see).
Means we need to
 - rebuild all the bootloader *.hex in the folder bootloaders
 - rebuild all the firmwares *.hex files in the folder firmwares

For a lot of the more simple bootloader files I succeeded. But for all
the files that requiring interaction with the LUFA library [7] I haven't
get it managed yet. And looking at the counts of *.hex files these are a
lot :-(.

The same situation is also unfortunately true for the firmware files in
the firmware/atmegaxxu2/ folder, also here various rebuilds with the
files from the LUFA library are needed. Unfortunately Arduino is not
sharing any information (except the version of LUFA which was used) how
the files are getting build in the past. I had no luck until today to
rebuild even a single file. If someone can share some information how we
can rebuild these files I appreciate any help.

Recapture this, that we are able to build and provide a package
arduino-core-avr so the packaged Arduino IDE can start, we also must
admit that users can't use this package as probably expected due the
current missing *.hex files. I have currently no suggested solution or
workaround for this. Also here, if someone has useful tips I'd like to
hear those.

Rock and myself concluded that beside this circumstance we should go
with this. And we should go in contact with upstream to improve the
situation together.

My current WIP on this package can also found in my namespace on Salsa [8].

Please be aware that I use explicitly the option of doing force pushing
stuff to the two repositories on Salsa within my namespace!

If someone is interested on have look at this all please do, if not than
please have some peaceful x-mas days and enjoy some free days and of
course stay healthy these days!

[1] https://github.com/arduino/arduino
[2] https://github.com/arduino/arduino-builder
[3] https://github.com/arduino/ctags
[4] https://github.com/arduino/ArduinoCore-avr
[5] https://salsa.debian.org/tijuca/arduino
[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977605
[7] http://www.lufa-lib.org/
[8] https://salsa.debian.org/tijuca/arduino-core-avr

-- 
Regards
Carsten