#253 Bundling exception request for icaro
Closed: Fixed None Opened 11 years ago by echevemaster.

== Overview ==

Icaro is a software development project and free hardware for teaching of robotics in primary and secondary schools. It is a way of bringing transparent and simple fundamentals of robotics trying to simplify concepts for complex technical knowledge that teachers need to minimum work in the classroom.

It consists of a number of software packages (specifically three parts) that work with hardware plates of inexpensive and manufacturing, allowing the research and design pedagogical of robots easily, recycling electronic components and using
the characteristics of the various computer labs that can be found in schools. The main idea is to reach software of low requirements that can take advantage of any existing computer in a college or the notebooks of the OLPC project

As we told them, this project consists of three parts:

'''Tortucaro'''

Is a TurtleArt's plugin that implements a set of primitives (basics blocks within LOGO) for generating an abstraction layer to read and send signals to the control plates. Leveraging the TurtleArt's primitives and adding the Tortucaro plugin, you can develop a robot that responds to the the signals serial port (or by a converter serial/usb as integrated ftl232) through an API programmed in python and PySerial.

'''Icaro-Bloques'''

icaro-bloques is based on all the work done by the PINGUINO project, a clone of ARDUINO but done with architecture PIC (18F2550). PINGUINO was written by Jean Mandom with the idea of ​​having a hardware based on PIC with ARDUINO boards support (based on ATMEL) and written entirely in Python. PINGUINO turn is based on the project VASCO-PUF that designed a bootloader and software to load.

'''Apicaro'''

Apicaro is a Python module to communicate to Np05 plate using python-serial. It has classes and functions to implement a transfer protocol using python.

The Icaro Project is developed by Valentin Basel, an active contributor of Fedora

After this lengthy explanation, i present the current problem

First the SRPM

and then the bundled sources

Note:
The reason of decoupling is that the developer attempted a way to deliver the bundled sources to run specifically in the $HOME of the user, but this obviously is not aligned with the guideline

and because I did not agree with the arrangement of headers and c source files within noarch python package (although given the nature of the package, some people have told me that there would be no problem)

If the exception is accepted upstream will move the files to their original locations. (ie within the tarball)

This sources, headers files, c sources files, linkers, libs and usb descriptors belongs specifically to Pinguino and Puf Vasco Project. '''is important to note that these routines are executed in the PIC and not directly on the Fedora user's host'''

Files:
From the Pinguino Project

  • analog.c (analog-digital conversion of the pic)
  • servo.c (servos)
  • arduinodelay.c (that has nothing to do with arduino, only seeks to be compatible, but not for atmel, it's for PIC)
  • digitalw.c (Digital writing Pin pic)
  • _cdc.c (serial communication with CDC)
  • boot_iface.h, common_types.h, define.h, macro.h (They contains address memory bank of PIC)

  • the linkers (lkr) also belong to Pinguino Project

  • and the usb descriptors and the libpuf.lib are from Puf Vasco Project

IMO the latest release of Pinguino Project is far from included in Fedora because it contains precompiled binary of sdcc and the sdcc system-wide is no-compatible with the project. (Icaro does not have this problem and is perfectly compatible with sdcc system-wide), further that the latest releases of Pinguino evolve to a type of 32-bit hardware architecture, that is quite expensive and difficult to obtain, which is against the philosophy of Icaro as an educational project.

And ...

Puf Vasco Project is dead from 6 years ago. (libpuf.lib and usb descriptors)

I also wanted to ask you something although it is a little out of the topic. Tortucaro as well as explain above, is a plugin for TurtleArt activity, however only we have guidelines (AFAIK) for packaging Activities and not for plugins.

This comment comes as the fedora-review tool recognizes this plugin as an activity when it is not.


This was discussed at today's fpc meeting and we think it falls under

"An exception is made for binary firmware, as long as it meets the requirements documented here: Licensing:Main#Binary_Firmware" -- http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions

You are free to bundle te pinguino firmware.

regarding sugar plugins vs activities, that's just because no one's written any guidelines for those. If you'd like to draft some to be added to the page, that would be great.

Login to comment on this ticket.

Metadata