Create a Linux source release.

[GoogleCodeExporter]

What change would like to see?

An archive of the Arduino source code for Linux.

Why?

To simplify Linux packaging, apparently.

Original issue reported on code.google.com by dmel...@gmail.com on 28 Jan 2010 at 2:21

Attachments:

• linux-source-archive.patch

[GoogleCodeExporter]

Here's a simple patch to make a source distribution tar.gz for linux using ant.

Run using "ant source-dist" from build/

it will build "arduino_$VERSION.tar.gz" in build/

Usually source tarballs only include source code. The ant target in this patch 
will also include some compiled jars that are already compiled on github:

arduino/core/preproc/preproc.jar
arduino/core/methods/methods.jar
arduino/app/src/processing/app/tools/format/tool/jalopy.jar
arduino/app/src/processing/app/tools/format/tool/log4j.jar

Debian right not deletes all those jars and rebuilds them during their build. 
They will all rebuild when you run "ant build" except for methods.jar, which 
has to be manually poked. Perhaps we should write in a dependency on the ant 
target that builds methods.jar.

The source-dist target in this patch includes the javadocs which are already on 
github.

Also, this patch will include pre-compiled libraries and third party .jars:
arduino/app/lib/apple.jar
arduino/app/lib/RXTXcomm.jar
arduino/app/lib/jna.jar
arduino/app/lib/antlr.jar
arduino/app/lib/ecj.jar
arduino/app/lib/oro.jar
arduino/build/linux/dist/lib/librxtxSerial.so

I think it is ok to include these since they are there for the convenience of 
the user. Debian removes these files and replaces them with the debian packaged 
versions.

Finally, this patch will also include a patched avrdude:
arduino/build/linux/dist/tools/avrdude.conf
arduino/build/linux/dist/tools/avrdude

For now this is important to keep since David has patched them and the new 
version of avrdude including this patch has not be released yet. Debian's build 
removes these and replaces them with the Debian's avrdude, which also has 
David's patch.

The question now is: should we keep the precompiled jars (e.g. methods.jar, 
preproc.jar) or should we amend build.xml to build them when arduino is built?

Original comment by showard...@gmail.com on 29 Sep 2010 at 7:58

Attachments:

• arduino_source-dist.patch

[GoogleCodeExporter]

typo:
Debian right *now* deletes all those jars

Original comment by showard...@gmail.com on 29 Sep 2010 at 8:00

[GoogleCodeExporter]

showard314 thanks for the patch, but I think you need to exclude some more 
things: the .git directory, the linux/work directory, the binary .class files, 
etc.  I agree that it's okay to include the compiled .jars for convenience.  
Can you revise this?

Original comment by dmel...@gmail.com on 2 Oct 2010 at 8:31

[GoogleCodeExporter]

Here's the patch that excludes all work directories and .class files (my 
original patch was in a clean non-git source tree - this patch is more robust 
as it works in a git tree and with pre-compiled code).

David, on a side note - I saw that you are distributing a patched rxtx. I want 
to confirm what you did in your patch (I maintain debian's rxtx and will patch 
it to match your changes):

            if(osName.equals("Linux"))
            {
                String[] Temp = {
                "ttyS", // linux Serial Ports
                "ttySA", // for the IPAQs
                "ttyUSB", // for USB frobs
                "rfcomm",       // bluetooth serial device
                "ttyircomm", // linux IrCommdevices (IrDA serial emu)
                };
                CandidatePortPrefixes=Temp;
            }

did you add:
"ttyACM",// linux CDC ACM devices

Are there any other patches?

Were there any other changes?

Original comment by showard...@gmail.com on 3 Oct 2010 at 4:55

Attachments:

• arduino-source-dist.patch

[GoogleCodeExporter]

Thanks for the updated patch (and apologies for not figuring out that I should 
have just done a fresh export before running the previous one).

Yep, that was the only change I made to the RXTX: adding ttyACM to the list of 
Linux serial prefixes to scan in the RXTXCommDriver.java file.

I also see that you've been trying to do something about this: 
<https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/325506>.  Thanks for 
that, too.  I'd rather rely on the distribution RXTX, but don't want to force 
people to go through an extra step to configure it.

Original comment by dmel...@gmail.com on 3 Oct 2010 at 12:06

[GoogleCodeExporter]

Thanks for the reply!

Regarding the sun java bug - it appears that Debian has no interest in trying 
to get the sun java bug working. Arduino does work well with OpenJDK [1], which 
has no problem finding rxtx. OpenJDK is the default for Fedora, Debian, Ubuntu, 
and many other distros. Would it be possible to rely on both the distribution 
rxtx and the distribution java? You won't have to redistribute sun java, just 
ask users to install "$ apt-get install default-jdk" in Debian/Ubuntu or "$ su 
-c "yum install java-1.6.0-openjdk-devel"" in Fedora. You also will only need 
64 bit avrdude in order to have a 64 bit release (you won't need to worry about 
64 bit RXTX if the distro has it). Once avrdude 5.11 is released (or distros 
patch their avrdude with your patch like Debian did) you actually could just 
rely on distro's avrdude, rxtx, and openjdk - you won't need to worry about 64 
bit versions of anything. In fact, Ubuntu and Debian actually distribute 
arduino that was compiled and runs on OpenJDK.

The arduino-0018 64 bit .jars downloaded from arduino.cc works with openjdk 
without needing any changes.

Also, Ubuntu is already spinning release CDs - so their archive is very frozen 
for version 10.10. Ubuntu 10.10 will be released with arduino 0019, but I will 
get 0021 into the archive as soon as it opens again and request that it and the 
patched rxtx be backported to 10.10. That means that there will be a delay of 
about a month before 10.10 will have 0021.

If you need any help getting avrdude, gcc-avr, rxtx, arduino, or any other 
packages fixed in Debian/Ubuntu just let me know.

[1] http://openjdk.java.net/

Original comment by showard...@gmail.com on 3 Oct 2010 at 2:34

[GoogleCodeExporter]

Is there any benefit to keeping those pre-compiled jars in the source package 
if they can be simply rebuilt?

Has anyone been in touch with upstream RXTX?  Will they include ttyACM in their 
list, or are we going to have to patch it downstream indefinitely?

Is it really needed to patch RXTX?  I notice that 
http://rxtx.qbang.org/wiki/index.php/FAQ#RXTX_does_not_find_my_device.2C_what.27
s_wrong.3F seems to suggest that you can specify the port used at runtime.

Original comment by p.d.oli...@gmail.com on 3 Oct 2010 at 4:27

[GoogleCodeExporter]

p. d. oliver has some good questions, I know a little bit about the RXTX part 
at least:

>Is there any benefit to keeping those pre-compiled jars in the source package 
if they can be simply rebuilt?

There are two types of pre-compiled jars in the source package: 3rd party 
"convenience" jars and some that are built from processing. Arduino doesn't 
redistribute the source code for the 3rd party jars in the source distribution, 
so they can't be rebuilt. The source code of the 3rd party jars can be found at 
their own project sites. The processing jars, however, can be rebuilt. I'm 
"downstream" of Arduino, and I personally remove ALL precompiled jars like 
p.d.oliver suggests. We grab the source code for the 3rd party jars and rebuild 
the processing jars. I feel I may be in the minority for wanting all jars 
removed, but that's what the majority of the big linux distros require you to 
do.

>Has anyone been in touch with upstream RXTX?  Will they include ttyACM in 
their list, or are we going to have to patch it downstream indefinitely?

RXTX used to include ttyACM in their default list, but their default list ended 
up enumerating ~5000 devices. On a big box that's not so bad, but on embedded 
systems that is killer. They ended up releasing their code with a minimal list, 
but included every other possible port in a commented out section of code with 
commented instructions telling downstream to edit the code to include any port 
they need. If we are going to patch, we are probably going to have to do it 
indefinitely since it seems that is what RXTX upstream wants us to do.

>Is it really needed to patch RXTX?  I notice that 
http://rxtx.qbang.org/wiki/index.php/FAQ#RXTX_does_not_find_my_device.2C_what.27
s_wrong.3F seems to suggest that you can specify the port used at runtime.

Great comment - here's what the INSTALL file of RXTX says about that:

 613 If you wish, you can set the system properties gnu.io.rxtx.SerialPorts
 614 and gnu.io.rxtx.ParallelPorts.  If either of these is set, then no
 615 scanning will be carried out and only the specified ports will be
 616 available.  You can use this to make one platform look like another,
 617 to restrict Java access to ports, or possibly for other reasons.  For
 618 example
 619 
 620         java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp
 621 
 622 will look kind of like Solaris, if you have created the appropriate
 623 device nodes.

The downside is that it removes some of the platform independence away from 
arduino unless we carefully select all possible ports. It's also possible that 
some users would have an interesting configuration that we will miss and leave 
their port off the list on accident. It might be worth trying and seeing if you 
can get it to work.

Original comment by showard...@gmail.com on 4 Oct 2010 at 12:27

[GoogleCodeExporter]

On a related note: David, could we have a section of the site (or in the git 
repository) that holds all the patches you have done to release arduino on 
avrdude, rxtx, etc.? This way people rebuilding those binaries can avoid bugs 
that you have already figured out and fixed.

Original comment by showard...@gmail.com on 4 Oct 2010 at 12:29

[GoogleCodeExporter]

http://github.com/arduino/Arduino/commit/224a7bf768bfba423fb685f979c69e5ffe609f4
4

I'll upload the 0021 source release when I get a chance.  

Is OpenJDK relatively robust and dependable now?  I had the impression that the 
Sun JDK was the recommended version, but that may be obsolete (or just wrong).  
But if OpenJDK works, and finds the RXTX package by default, we can just use 
that and stop shipping RXTX ourselves.

The problem with specifying the ports to RXTX is that, as I understand it, you 
have to specify the exact port names, not the prefixes to be scanned (e.g. 
/dev/ttyUSB0 as opposed to /dev/ttyUSB).

The avrdude source we use is in the Git archive.  RXTX could be too, but so far 
I've just changed the one line.

Original comment by dmel...@gmail.com on 4 Oct 2010 at 1:27

• Changed state: Fixed
• Added labels: Milestone-0022

[GoogleCodeExporter]

OpenJDK has become the default over the past year. A little over a year ago sun 
java was still the default, but it has switched recently.

Running Java under Ubuntu- https://help.ubuntu.com/community/Java
"The default flavor of JRE installed is defined by the package default-jre. 
Currently, it is openjdk-6-jre, which is mostly derived from the Sun JRE."

Debian Java FAQ.
Chapter 3 - Status of Java in Debian Squeeze - 
http://www.debian.org/doc/manuals/debian-java-faq/ch-debian-java-squeeze.html#s3
.1
"Java-common has switched to OpenJDK as the default-jdk on most architectures."

What is the Java environment in Fedora? - http://fedoraproject.org/wiki/JavaFAQ
"OpenJDK 6 is the default Java environment since Fedora 9. It is 
Oracle(formerly Sun) Java under a free and open source license, and there are 
runtime and development packages."

Original comment by showard...@gmail.com on 4 Oct 2010 at 2:48

[GoogleCodeExporter]

Cool, I hadn't realized that.

Can you bring this up on the Arduino developers mailing list 
<http://mail.arduino.cc/mailman/listinfo/developers_arduino.cc>?  That is, 
suggest switching to OpenJDK and the distribution's version of RXTX and 
avrdude?  That's probably the best place to understand what's needed to make 
that happen.

Original comment by dmel...@gmail.com on 4 Oct 2010 at 3:21