[Pkg-electronics-devel] Updating Arduino UI and related package dependencies, what blockers do we have?

[Brian Holaday]

Hi Team,

I know that I am not much help here as of yet but have any of you looked at
(https://koji.fedoraproject.org/koji/buildinfo?buildID=1524434) as far as
building. I also don't know if there has been any support in adding (
https://www.microchip.com/mplab/mplab-x-ide) - MPLab X as an option for
installing?

Here is a list (would be ideal) I like to use:
+ KiCad (5.1.8)
+ Arduino (1.8.13)
+ MPLAB X (5.45)
+ (simavr) and (sdcc) - Up to Date

Right now I am actually testing (Ubuntu and Fedora) to see what distro long
term I might stick with. Seems like Fedora is more updated but I have yet
to test any of the electronics packages but I wish more support was driven
in these packages here but I also know it's challenging to find time. A
clear example is I still have some KiCad model work pending in the KiCad
main repo.

I wish you all the best.

On Sat, Dec 12, 2020 at 9:52 AM Carsten Schoenert <c.schoenert at t-online.de>
wrote:

> Hello Rock,
>
> Am 12.12.20 um 12:18 schrieb Rock Storm:
> ...
> > I wouldn't worry too much about getting it into Bullseye.
>
> of course not as there is always the way through backports.
>
> > We should work on it regardless of the release cycle. If we could get
> > Arduino 1.8.13 working in Debian that'd be a huge achievement given
> > where we are now. If we could get it in time for the next release,
> > it'd be amazing, but I'd be very happy with just getting it in at
> > some point.
> Exactly, I'm happy if we can come to some movement into a forward
> direction.
>
> > As for arduino-builder, I gave up last year after getting no support
> > from the Go Packaging Team team to get the new dependencies into the
> > system [1][2]. Hence why arduino-builder has not been updated since
> > then. I'm happy to try again and/or let anyone with more experience/time
> > to spare to take over the package.
> >
> > [1]: https://lists.debian.org/debian-go/2019/07/msg00007.html
> > [2]: https://lists.debian.org/debian-go/2019/07/msg00008.html
>
> Ahh, o.k. I was thinking about such a reason why it was in stuck.
>
> Regarding new B-D I figured out these three packages.
>
> > diff --git a/debian/control b/debian/control
> > index de1ab70..cfa1a47 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -12,7 +12,10 @@ Build-Depends: debhelper-compat (= 12),
> >                 golang-github-arduino-go-timeutils-dev,
> >                 golang-github-fsnotify-fsnotify-dev,
> >                 golang-github-go-errors-errors-dev,
> > +               golang-github-iancoleman-orderedmap-dev,
> > +               golang-github-pkg-errors-dev,
> >                 golang-github-schollz-closestmatch-dev,
> > +               golang-github-sirupsen-logrus-dev,
> >                 golang-github-stretchr-testify-dev,
> >                 golang-google-grpc-dev,
> >                 golang-goprotobuf-dev
>
> But more I wasn't able and willing test because it was becoming to much
> and fragile without asking other involved people.
> I've no idea how often the two (or more) Arduino Go packages needing an
> update, it might doable if we start to take care on these packages on
> our own and ask for help again once we facing new and deeper issues. But
> first we need a plan it all as you've written further down.
>
> >> 2. We need a new package arduino-core-avr to fulfill a new dependency of
> >> split of AVR stuff from arduino-core.
> >
> > As for the AVR stuff, as was suggested by Leonardo, I started looking
> > at how Arduino is packaged in Fedora. Instead of an 'arduino-core-avr'
> > source package, the 'arduino' source package provides the binary
> > 'arduino-devel' package which seems to provide more or less the same
> > content(?). Maybe anticipating future introduction of new cores(?). So
> > basically their 'arduino' source package recklessly aggregates all
> > arduino libraries and cores. I'm not saying this is the right way to do
> > it, and I'm not saying I'm against an 'arduino-core-avr' package, just
> > wanted to point out that a different approach is done there.
>
> Yes, I was also thinking about some new source package structure due the
> new situation right now. But I have no complete overview how the various
> parts are needed to interact. We should start a new wiki page or enhance
> and use the existing one to collect the things, otherwise it will become
> cumbersome quickly to go through an email thread again and again.
>
> > Other concerns I have, please forgive my ignorance here:
> >
> > 3. Arduino seems to ship custom versions of avr-gcc and avrdude. I have
> > not investigated what the differences (if any) are. But this could mean
> > that certain code compiled in Debian produces different results if
> > compiled using the standalone app provided by Arduino. Maybe Matthijs can
> > shed some light here. Cause ideally Arduino should use the system
> > gcc-avr and avrdude packages already present in Debian.
>
> I can fully understand why Arduino is doing this, but as you also
> explain for one reason we don't want this and we don't need to follow
> that way. Of course this could be less painful to do if upstream is
> willing to hear our concerns and is helping sometimes so we as Debian
> can provide packages for users that produce the same outcome in the end.
>
> > 4. I'd say there's a fair risk of this package becoming a sort of a
> > dependency hell given the amount of little dependencies it has. So I'd
> > suggest investing some time in planning the packaging strategy and also
> > getting the commitment from a team to maintain it cause it probably
> > won't be a 5-minute-job.
>
> Fully correct. And that was one of reason why I started this thread
> here. We should revisit everything we have right now and ask our self if
> the structure is till useful and correct. Otherwise it will become
> rapidly tedious to work on needed package migrations.
>
> > 5. And last but not least, I think it is not a problem but users could
> > quite easily install non-FOSS libraries for whatever closed-source
> > components they are using on their projects. I believe as long as we
> > don't ship these libraries the package is fine, but I'm raising the issue
> > just in case anyone has concerns about this.
>
> This point was Matthijs already mentioning within the licensing thread
> on GitHub for ArduinoCore-avr and I agree on this. We should invest our
> time in the parts of software that is clearly free and also nearly easy
> to handle. OTOH we can also provide non-free packages if this is
> sensible and helpful for users.
>
> --
> Regards
> Carsten
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20201214/ea984e45/attachment-0001.html>