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