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.

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.

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.

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).

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).

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.

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.

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.

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?

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?

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.

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.

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):

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.