lejos packaging for Fedora

This is where you talk about the NXJ software itself, installation issues, and programming talk.

Moderators: 99jonathan, roger, imaqine

Re: lejos packaging for Fedora

Postby gloomyandy » Mon Jul 14, 2014 8:46 pm

I'm not familiar with the details of the Fedora release system so perhaps you can provide some details...
* Is the source used for the fedora release pulled directly from the leJOS CVS repo or is there some sort of manual upload of the source?
* What happens if the leJOS repos are updated? Who/what will update the fedora release and when will this update happen?

As to the toolchain issues, if you are offering to port the source to a new tool chain and support that new port then please talk to us. If anyone else reading this would like to do so then again please say so. The current VM code is old (dating back to the RCX), and I'm sure would benefit from a clean up (I'm well aware of the issues you have noted). But I for one have no real interest in doing this. The NXT is no longer current hardware, my experience of using the newer toolchains has been that the resultant code is larger (which causes problems with the limited space on the NXT) and slower then when using the older ones. I find it hard to get enthusiastic about a bigger/slower VM! In terms of supporting leJOS on the NXT I personally think there are many issues more important then this one that would benefit from additional developer effort, but if this is an area that interests you and you are prepared to provide ongoing effort to support the results, then obviously we would be interested. Note that these are my personal views on the subject, other developers may feel differently.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4004
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: lejos packaging for Fedora

Postby skoehler » Mon Jul 14, 2014 9:00 pm

dwrobel wrote:On the other hand I was able to just compile and boot succesfully the embox project on my NXT. This project uses the arm-none-eabi-gcc toolchain which currently seems to be preffered toolchain from distribution's point of view. In other words having possibility to use this toolchain would significantly help maintaining lejos package. Please consider to support it.

As developers of software for an embedded system, we can make all kinds of choices. For example, we might compile newlib the way we want - not the way the guy who compiled the arm toolchain for Fedora. Especially for embedded systems, the toolchain is as much part of the build as everything else. If you want to use another toolchain, then you're on your own.
Also, Andy has explained to you a lot of times that the toolchain has been carefully chosen to minimize the firmware's size. The binary you build might not even flash, as the tool we use to flash the firmware to the NXT has a limit built in.
skoehler
leJOS Team Member
 
Posts: 1415
Joined: Thu Oct 30, 2008 4:54 pm

Re: lejos packaging for Fedora

Postby skoehler » Mon Jul 14, 2014 9:16 pm

dwrobel wrote:Now the pacakge is almost ready. It allows either to reuse the binary NXT firmware blob without recompilation or recompile it using either the arm-elf-gcc or the arm-none-eabi-gcc toolchain with the information that the build compiled with the arm-none-eabi-gcc toolchain is currently not supported.


Did you talk to Fedora whether recompiling the firmware is even necessary? The link you provided earlier certainly does not support that.
skoehler
leJOS Team Member
 
Posts: 1415
Joined: Thu Oct 30, 2008 4:54 pm

Re: lejos packaging for Fedora

Postby dwrobel » Tue Jul 15, 2014 7:47 pm

gloomyandy wrote:* Is the source used for the fedora release pulled directly from the leJOS CVS repo or is there some sort of manual upload of the source?


The are a few ways to provide source references, it can be tarbal url or a particular source control revision/tag. It's described in a more detailed way here. Then the tarbarl needs to be uploaded to the lookaside cache from where it is downloaded by the builder during the package compilation process.

gloomyandy wrote:* What happens if the leJOS repos are updated? Who/what will update the fedora release and when will this update happen?

There is an upstream monitoring system which monitors it automatically in case a new release is available an automatic bug is created which allows a maintainer to prepare new package version.

gloomyandy wrote:*As to the toolchain issues, if you are offering to port the source to a new tool chain and support that new port then please talk to us.

As stated earlier I'm not an expert in this area. I could try to help to debug some areas in Java/C code once it would at least boot properly (having all the assembler code and linker .lds scripts configured properly).
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby dwrobel » Sat Aug 16, 2014 6:40 pm

The lejos-nxj package for the Fedora 20 (i386, x86_64) with instruction how to install it easily can be found in the following Fedora copr repository: https://copr.fedoraproject.org/coprs/dwrobel/lejos-nxj/

It's not ready for inclusion in the official Fedora repository as it doesn't compile on the rawhide version as aforementioned in the previous post.
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby dwrobel » Mon Aug 18, 2014 3:48 pm

dwrobel wrote:Hi,

I'm planing to preprare an RPM package of NXT software to have fully reproducible and stable build system.

Basically I've managed to compile the latest stable version from the svn tag lejos_nxj_0.9.1-3[1] (as the official sources doesn't contain eclipse plugin sources) and it works quite well (tools, examples, eclipse plugin).


The current status of Fedora packaging is as following:

The lejos-nxj package for the Fedora 20 (i386, x86_64) with instruction how to install it easily can be found in the following Fedora copr repository: https://copr.fedoraproject.org/coprs/dwrobel/lejos-nxj/

The package review is reported as: https://bugzilla.redhat.com/show_bug.cgi?id=1131019

The review WhiteBoard is marked as: NotReady, BuildFails as the package doesn't build in the rawhide. I would greatly appreciate any help in resolving this issue (more information is available here).
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby gloomyandy » Mon Aug 18, 2014 4:50 pm

Hi,
A few comments/thoughts on all of this....

Unless there is someone prepared to test and support a new build of the firmware then I do not think it is a good idea to make anything other than the standard leJOS firmware image available to users. This includes any build from source that results in a binary this is not identical to the standard leJOS image. If any such image is made available then it is essential that it is easily identified as such. Could you explain what your intentions are for the firmware?

I am also not very comfortable with having someone that has not had a long term involvement with leJOS being responsible for creating a new distribution. I'm sorry if this seems rather negative but we have seen similar situations in the past were people have created blogs/downloads based on leJOS and then lost interest leaving users lost and us trying to pick up the pieces. Given the potentially widespread distribution of this version I am particularly concerned. At the moment we know nothing about your leJOS involvement or history (except for posts all within this thread). Perhaps you could reassure us a little, could you explain your interest in Java/leJOS/Robotics/Lego and your motivation for starting this project?

As before this is very much my own opinion, other developers may have a different view.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4004
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: lejos packaging for Fedora

Postby dwrobel » Mon Aug 18, 2014 6:02 pm

gloomyandy wrote:Hi,
A few comments/thoughts on all of this....

Unless there is someone prepared to test and support a new build of the firmware then I do not think it is a good idea to make anything other than the standard leJOS firmware image available to users. This includes any build from source that results in a binary this is not identical to the standard leJOS image.


I would try to shortly describe how the situation looks from the distribution's standpoint. It would be perfect if you just provide source tarball and let distribution to compile the sources and stop worrinying if resulting binaries would be completely different amongst distributions. Please just try to compare the /bin/sh (generated from the same source tarball) between each linux distribution. You will notice that each one might have different size and content - but no one actually worries about it. Not to mention that no one is interested in using binaries provided by upstream, if provided at all.

The same applies to lejos projects. Thus, if you would be keen to just prepare the source tarball which would be easily compilable in every distribution you might take advantages of that by concentrating on the development part of the project and forgot about maintaining and receiving bugs that something doesn't work because you're providing buggy dependencies.

Just for the record the list of lejos dependencies:
BuildRequires: ant
BuildRequires: apache-commons-cli
BuildRequires: bcel
BuildRequires: bluecove
BuildRequires: cpptasks
BuildRequires: jcommon
BuildRequires: jfreechart
BuildRequires: java-devel >= 1:1.7.0
BuildRequires: javapackages-tools
BuildRequires: eclipse-pde
BuildRequires: eclipse-platform
BuildRequires: libusb-devel

In other words do you have time to fully support and maintain all dependencies of lejos? Or you prefer to rely on versions provided by distribution and used by many different projects.

The similar approach is used by github where developers just pushes sources and just provides short information how to compile sources. The rest is done by distributions.

If the idea behind is still unclear or I wasn't able to provide convincing arguments - just let me know I would try to explain it better.
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby gloomyandy » Mon Aug 18, 2014 7:44 pm

Which is all very well but none of that applies to the leJOS firmware (which was the subject of the text you quoted).
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4004
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: lejos packaging for Fedora

Postby dwrobel » Tue Aug 19, 2014 8:15 pm

gloomyandy wrote:Which is all very well but none of that applies to the leJOS firmware (which was the subject of the text you quoted).

Saying that something doesn't apply without any agrument is not an agrument.
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby dwrobel » Tue Aug 19, 2014 8:42 pm

gloomyandy wrote:I am also not very comfortable with having someone that has not had a long term involvement with leJOS being responsible for creating a new distribution.


The person who maintans the software packaging doesn't need to be involved in the development process. It's enough that they knows packaging rules used in a Linux distribution.

My idea is to teach/show my childrens how programming languages can be used to control real appliances. Both of them has laptops with Fedora Linux. They can use/install only open source software, and use them from repositories which can be controlled by "yum" or "apper". From that simple perspective they couldn't use the lejos as there was no automatic way of installing or deinstalling the lejos software - in case something doesn't work or they are no longer interested in using particular software. Not to mention that all the installed software should automatically be updated once we upgrading from one Fedora release to the next one. Now having at least copr repository they could install the lejos and we've managed to create simple java based plotter (very similar to this one) which is able to print HPGL documents exported from Inkspace (if someone is interested we could share sources).

If someone else would like to install the lejos-nxj software it would have ready to use single line/one click solution. I think that having possibility to install the software from repositories on modern linux distributions is a must, if you have different opition/solution, preferrably better, please share your thoughts.
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby gloomyandy » Tue Aug 19, 2014 9:26 pm

I've already made the argument, see the many previous posts, but I'll make it again here just so we are clear....

This is not an argument about supporting code which runs in a standard Linux environment it is about the leJOS firmware which runs in the very limited environment of the NXT, in effect an embedded system. We do not want to have multiple versions of the leJOS firmware out there unless there is someone willing and capable of supporting it. I doubt very much if any distro maintainer is going to have the tools or the interest to debug issues that can show up with the firmware (Both Sven any myself have already indicated how different builds with different versions of gcc and the toolchain can be, some of them do not even fit in the available flash memory). Debugging issues with the firmware is not a trivial problem. As I said (and you quoted) unless the resultant firmware build is identical to that which we build then it is not a good idea to have users install and use it. So we need to do one of the following:
* Ship a binary version of the firmware and have people use that (my understanding is that this may not be acceptable for some distributions)
* Ensure that the binary built from the firmware source is identical (my understanding is that this will not be the case because different versions of the gcc cross compiler will be used with different distros).
* we need someone who will handle any problems that users may experience.
If we do not do this then by creating different builds you will in effect be forcing us to try and support all of these builds (and that is something I am certainly not going to do), or if users hit problems the first thing we will do is tell them to use the standard firmware (in which case what was the point of using the different one?).

So as I said before will the firmware used by these distributions be our standard binary image? if not are you saying you are happy to resolve any issues which turn up with users of a non standard firmware build?
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4004
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: lejos packaging for Fedora

Postby dwrobel » Wed Aug 20, 2014 6:02 pm

gloomyandy wrote:So we need to do one of the following:
* Ship a binary version of the firmware and have people use that (my understanding is that this may not be acceptable for some distributions)
* Ensure that the binary built from the firmware source is identical (my understanding is that this will not be the case because different versions of the gcc cross compiler will be used with different distros).
* we need someone who will handle any problems that users may experience.


Please refer to the very beginning of this post where I described what are the possible options for providing the NXT firmware blob. Then please have a look at defaults used by the .spec file which generates the package. As you can see the default is to use the arm-elf-gcc toolchain. You can verify the location to the sources of the compiler, binutils and newlib which are used to compile the compiler itself then how the NXT firmware is compiled (if it's exactly how you're building it).

Once verified please confirm whether you are able to support such a binary or do you still see some issues?
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

Re: lejos packaging for Fedora

Postby gloomyandy » Wed Aug 20, 2014 9:19 pm

Is using the binary blob the default option? I think it would be best if it was.

I've looked at the spec file, but it is not really possible to verify that this will result in a standard build just from inspection of the file, and I don't have the time to setup a build system to try all of this. So is the resultant binary file identical to the one we currently ship (other than date/time stamps)? If not then ideally you need to understand why not as this may indicate some problem with the build process.

If the resultant binary is identical then we should be able to support it. If the file is not identical then please ensure that it is easy to identify (ideally from the system menu) that this version of the firmware is different from the standard leJOS build. If users can choose to build the firmware using alternate tools, then again please make it easy for us to identify that this was the case. We need to make it possible for us to get users to check what firmware they are using (users are not always aware of the process by which the firmware on the NXT has been created). Probably the simplest way to do this is for your build scripts to adjust the version number. Perhaps changing this to add some offset to the minor version would be best (so for instance rather then build 0.9.1 you would use 0.9.101 or some such scheme). The version number is held as a hex number and is passed into the gcc command line.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4004
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: lejos packaging for Fedora

Postby dwrobel » Thu Aug 21, 2014 7:58 pm

gloomyandy wrote:Is using the binary blob the default option?

As stated before it's default.

gloomyandy wrote:I've looked at the spec file, but it is not really possible to verify that this will result in a standard build just from inspection of the file, and I don't have the time to setup a build system to try all of this.

You can download binaries from the copr builder

gloomyandy wrote:So is the resultant binary file identical to the one we currently ship (other than date/time stamps)? If not then ideally you need to understand why not as this may indicate some problem with the build process.


They are different as I didn't use the original tarball but had to use the following svn checkout to get the sources for eclipse plugin (details are in a spec file):

Code: Select all
$ svn checkout svn://svn.code.sf.net/p/lejos/code/tags/lejos_nxj_0.9.1-3

Code: Select all
$ svn info
Path: .
Working Copy Root Path: /home/dw/projects/lego/nxt/lejos-nxj
URL: svn://svn.code.sf.net/p/lejos/code/tags/lejos_nxj_0.9.1-3
Relative URL: ^/tags/lejos_nxj_0.9.1-3
Repository Root: svn://svn.code.sf.net/p/lejos/code
Repository UUID: 06c8f799-c779-4783-8af7-179afedb67c8
Revision: 7017
Node Kind: directory
Schedule: normal
Last Changed Author: skoehler
Last Changed Rev: 6624
Last Changed Date: 2012-05-29 22:13:18 +0200 (Tue, 29 May 2012)


Code: Select all
$ svn log | head -n 4
------------------------------------------------------------------------
r6624 | skoehler | 2012-05-29 22:13:18 +0200 (Tue, 29 May 2012) | 2 lines

tagged 0.9.1-3


As a result in the menu version they also differs yours has rev.6595, menu rev.6117 whereas my has rev.6624, menu rev.6117. Assuming that I use official tag and didn't make mistake it looks that your release doesn't match the tag?

gloomyandy wrote:Perhaps changing this to add some offset to the minor version would be best (so for instance rather then build 0.9.1 you would use 0.9.101 or some such scheme). The version number is held as a hex number and is passed into the gcc command line.


To have it fully automated let's assume that I could always add a 100 (0x64) to the existing version.
dwrobel
New User
 
Posts: 21
Joined: Mon Jul 07, 2014 8:39 pm

PreviousNext

Return to NXJ Software

Who is online

Users browsing this forum: No registered users and 2 guests

cron
more stuff