Summary: | dev-embedded/arduino-1.0.1 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Rüger (RETIRED) <mrueg> |
Component: | New packages | Assignee: | Angelo Arrifano (RETIRED) <miknix> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | dev-embedded+disabled, genbug, nixphoeni |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://arduino.cc/en/Main/ReleaseNotes | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Source ebuild for arduino-1.0.1
build.xml patch to use system libraries and avoid library mismatch error dev-embedded/arduino-1.0.1.ebuild dev-embedded/arduino-1.0.1.ebuild arduino-1.0.1.ebuild arduino-1.0.1.ebuild |
Description
Manuel Rüger (RETIRED)
![]() Sorry for the delay, I'll do it this weekend. Created attachment 316319 [details]
Source ebuild for arduino-1.0.1
Source ebuild
Created attachment 316321 [details, diff]
build.xml patch to use system libraries and avoid library mismatch error
It is working here, but please advise if you can see any improvements to my ebuild writing skills! Oops - I have a problem with this ebuild - I am sure it worked yesterday!! Anyway, I am currently working on it! You should not call ant directly, use eant instead. more info: http://www.gentoo.org/proj/en/java/java-devel.xml maybe you also want to ask in #gentoo-java @ freenode Created attachment 316367 [details]
dev-embedded/arduino-1.0.1.ebuild
The reworked arduino-1.0.1 ebuild. Thanks Manuel for pointing the java devel url and thanks Paul for your initial ebuild.
A few notes though:
1) The code
# IDE tries to compile these libs at first start up
fperms -R g+w "/usr/share/${P}/libraries"
Is this a fatal error? It really seems a bad idea to me to do this.
2) The built arduino fails with an exception error:
Error parsing gtk-icon-sizes string: ''
Exception in thread "main" java.lang.NoClassDefFoundError: gnu/io/CommPortIdentifier
at processing.app.Editor.populateSerialMenu(Editor.java:962)
at processing.app.Editor.buildToolsMenu(Editor.java:691)
at processing.app.Editor.buildMenuBar(Editor.java:476)
at processing.app.Editor.<init>(Editor.java:205)
at processing.app.Base.handleOpen(Base.java:704)
at processing.app.Base.handleOpen(Base.java:669)
at processing.app.Base.handleNew(Base.java:565)
at processing.app.Base.<init>(Base.java:305)
at processing.app.Base.main(Base.java:194)
Caused by: java.lang.ClassNotFoundException: gnu.io.CommPortIdentifier
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 9 more
Paul, did you reproduce this?
It is getting late here, I'll give another look at this tomorrow.
Thanks,
Angelo
Just wondering if these paths are correct: rm -rf build/linux/tools/avrdude* should be maybe build/linux/dist/tools/avrdude* ? and these: if ! use java; then rm -rf lib rm -f arduino i can't find them anymore in the tarball. (In reply to comment #8) > Just wondering if these paths are correct: > > rm -rf build/linux/tools/avrdude* > > should be maybe build/linux/dist/tools/avrdude* ? > > and these: > if ! use java; then > rm -rf lib > rm -f arduino > > > i can't find them anymore in the tarball. @Manuel Yes you are correct. I managed to run the arduino built with the ebuild provided previously: LD_LIBRARY_PATH="/usr/lib/rxtx-2/:$LD_LIBRARY_PATH" CLASSPATH="/usr/share/rxtx-2/lib/RXTXcomm.jar:$CLASSPATH" build/linux/work/arduino symlinking the rxtx jar and dll into the arduino directory really seems like a bad approach to me. Furthermore, those environment variables are available here: /usr/share/rxtx-2/package.env Unless there is a better way to do it, I'm just going to parse that file and export the variables into the environment, in the arduino wrapper. Created attachment 316657 [details]
dev-embedded/arduino-1.0.1.ebuild
Patch arduino script to include the class/ld path of rxtx. The arduino-1.0.1-script.patch is just a copy of arduino-1.0-script.patch which is available on CVS (but will be removed along arduino-1.0 ebuild, soon as this ebuild enters the tree).
@Paul: I don't an arduino at the momment, can you please test the ebuild and see if it compiles/runs/flashes? Thanks!
Can't we use EANT_GENTOO_CLASSPATH and JAVA_ANT_REWRITE_CLASSPATH to set classpath? dropping ".." from the first line silences a QA. java_prepare should be used instead of src_prepare for java ebuilds (In reply to comment #11) > dropping ".." from the first line silences a QA. from Paul's build.xml.patch In build/shared/reference.zip is a documentation which we should install, too. (In reply to comment #11) > Can't we use EANT_GENTOO_CLASSPATH and JAVA_ANT_REWRITE_CLASSPATH to set > classpath? Since the launcher script is provided by upstream and the patch is already in place, I don't think it is worth it. (In reply to comment #12) > In build/shared/reference.zip is a documentation which we should install, > too. I'll have a look. The source code for the arduino libs is pretty important. Arduino provides a lot of high level 'helper' functions like analogWrite() that provide a quick means to blink or fade LEDs etc. The source code for what they all do is quite important if you need to go beyond idiot level button pushing VB style development on Arduino platform. (eg you actually want to chose the frequency of PWM , or just know what it is). This is not just relevant for building on Gentoo , it is an important resource when using Arduino IDE Some provision should be made for installing it , at least on an option. I would suggest thay anyone using Gentoo is above the mickey-mouse level and this should be installed by default is there is a choice. w.r.t the provided toolchain now provided, maybe this should be a build option. Anyone needing to file a bug report at Arduino will probably need to verify the problem using the provided chain , not report on the basis of a Gentoo built toolchain with all the variability that could imply. PS this last comment would affect deps on avr-gcc and should probably block it. *** Bug 428392 has been marked as a duplicate of this bug. *** (In reply to comment #15) > w.r.t the provided toolchain now provided, maybe this should be a build > option. > > Anyone needing to file a bug report at Arduino will probably need to verify > the problem using the provided chain , not report on the basis of a Gentoo > built toolchain with all the variability that could imply. Regarding comment #14 , the ebuild provided above already installs the source code. Also, the ebuild above pulls in crossdev for installation into your system. This will not install any toolchain, just the script used to create them which is really small in size so there is not reason why a user wouldn't want this. Then the ebuild just checks if avr-g++ is in /usr/bin. I agree that not everybody might want the toolchain binaries located there, so I'm going to change the ebuild to locate a avr-g++ in PATH instead. By the way, which provided toolchain are you talking about? The arduino source package does not include any toolchain binaries at all. Guys, what's preventing me from pushing this into the portage tree is that the above ebuild is missing something at build stage. When you launch arduino, at the title bar the ${version} string is left unreplaced. If you go Help->"About arduino" the version string is also unreplaced. Does someone knows what I am missing? Thanks "from Arduino IDE 1.0.1 a full working avr-gcc package is included" http://www.arduino.cc/playground/Learning/Linux I think we need to add "run" as a second build target. http://code.google.com/p/arduino/wiki/BuildingArduino if you do a manual install, you run "ant" and "ant run" (first ant = ant build because build is the default target) Thanks Manuel, I should have made it clear is was a new addition. Nevermind that "run" target, it has nothing to do with it. What I see is, that this target is called during build: <target name="assemble"> <fail unless="target.path" message="Do not call assemble from the command line." /> [...] <!-- Unzip documentation --> <unzip dest="${target.path}" src="shared/reference.zip" overwrite="false"/> <!-- Write the revision file! --> <echo file="${target.path}/lib/version.txt" message="${version}" /> </target> I have added the following line in src_prepare() sed -e "s/\${version}/${PV}/" -i build/build.xml || die Not very nice, but it works. I tested the ebuild with an arduino uno and compiling/uploading worked. :) Created attachment 319634 [details]
arduino-1.0.1.ebuild
Reworked, but needs some further polishing.
Created attachment 319636 [details]
arduino-1.0.1.ebuild
I think this looks good to go. Please test.
Tried mrueg's ebuild - works fine with dev-java/rxtx-2.1.7.2-r3 , but not with rxtx-2.2_pre2. It builds and starts, but doesn't show the ttyACM* ports in the tools menu. (In reply to comment #26) > Tried mrueg's ebuild - works fine with dev-java/rxtx-2.1.7.2-r3 , but not > with rxtx-2.2_pre2. It builds and starts, but doesn't show the ttyACM* ports > in the tools menu. Those are the ports I see in the tools menu: 4019 0 crw-rw---- 1 root uucp 166, 0 4. Aug 2012 /dev/ttyACM0 238 0 crw-rw---- 1 root uucp 4, 64 4. Aug 2012 /dev/ttyS0 Could you try this as root to check if it's a problem with permissions? Sorry, propably it was not clear: With dev-java/rxtx-2.1.7.2-r3 installed it's fine. Then I do get the ttyACMx. Only with rxtx-2.2_pre2 I don't see them. I had the 2.2_pre installed, because with the older arduino-0021 it was just the other way around. (In reply to comment #28) > Sorry, propably it was not clear: > > With dev-java/rxtx-2.1.7.2-r3 installed it's fine. Then I do get the ttyACMx. > > Only with rxtx-2.2_pre2 I don't see them. > > I had the 2.2_pre installed, because with the older arduino-0021 it was just > the other way around. Can you please run it as root, to check it is not a permission problem? Can you try with in-tree arduino-1.0? It works for me with an Arduino Uno wired via USB. Just thought everyone ought to know about this since the official Arduino toolchain now gets installed: http://code.google.com/p/arduino/issues/detail?id=468 Basically Arduino sucks big time. They have a huge bug in something as basic as heap management, they have known about it for over two years and have had a thorough fix for it for over too years. They have done nothing and are now punting out the fatally flawed toolchain with their (non-so-) IDE. Despite that bug claiming to taken bits of the proposed fix for v1.0 memory is still leaking and everything using Strings (like 98% of everything anyone does) will crash inexplicably after some indeterminate time. There's an alternative fix here: http://arduino.cc/forum/index.php/topic,95914.30.html This looks like clean fix though it is a work around. Maybe the ebuild should include this and rebuild whatever needs rebuilding as a result of the change. At the very least the ebuild should warn about this mess if it installs the buggy avr toolchain. An there was thinking Arduino was all about being easy to use ! This ebuild does not install the arduino toolchain. You are on your own to install and use crossdev. The ebuild is also available in my overlay (as long as it hasn't made its way into the tree): layman -a mrueg Thanks. Actually I'm on my own to sort out the mess Arduino have provided. Since Gentoo did not (does not) have a 1.0.1 ebuild, I installed from Arduino directly. Naively thinking what they provided would be a stable, well-tested toolchain (if not the most recent). You know, Debian kinda thinking. What I actually ended up with was a crock of shit that I now need to fix and test myself. I just thought it needed flagging since it is now part of the package and I assumed it was getting installed. If the 1.0.1 ebuild does not install this toolchain that is probalby the best solution. @Manuel: The ebuild looks good to me, I'll push it to the tree this weekend. I just pushed Manuel's ebuild into the tree. Thanks all for your collaboration. |