On 9/27/07, Bernd Zeimetz <[EMAIL PROTECTED]> wrote: > > 4) Give up and stay away from the Debian main repositories, just put > > the package up on a private package repository. > > Please don't choose this way to solve the problem. Lego Mindstorms are > used a lot for education, including universities, as it is just very > easy to build objects with Lego bricks, so you have more time to think > about the code then about how to handle metal or other raw material.
I agree. As I said, I want to do things right if I can. > Unfortunately I still have no clue about cross-compiling, but please let > me know if you need any help with the python parts. Feel free to join > #debian-python on OFTC, all questions regarding python apps/modules are > welcome there Thanks, I'll be there, since I actually do have a few questions on that part as well. > Imho one very fast way to solve the problem would be to package all the > python tools, including fwflash - but without the actual firmware blob. > Instead you ask the people to download the file or let the tool handle > this automatically - at least this would make sure people are able to > use your tools with mindstorms while you have enough time to figure out > how to ship the precompiled firmware in a debian package. For example > you could build the firmware package on arm only and let your tools > download and extract the package. If you look at the previous version of my library, which is in C and builds with SCons ( http://code.google.com/p/libnxt/ ), in C I embedded the binary image directly into the source code before compiling, using a small python script. And that python script does detect the absence of the compiled firmware image, and asks the user whether the binary should be downloaded from code.google.com. The alternative is to abort the build, make the binary image locally, and rerun. While this is a workable solution, I find it annoying because it places part of the burden of packaging on the user, for an implementation detail. I have seen this kind of thing done before, but for licensing reasons (non-free firmware that cannot be bundled in the package), whereas this seems to be a purely technical issue. Could the same kind of thing be done at package creation time, ie. prompt the packager to either build or download a working version of the binary image when the package is built (or just download it automatically if non-interactive is required) ? The end result is the same, except that end users don't have to care any more, which is always nice. If you couldn't tell btw: I think that the first solution I mentionned would work well. The flash driver is tiny, and so trivial that it is highly unlikely that it will change in the future, so I consider bundling it a debian-specific fix to the upstream build system more than anything else (so that the packaging process doesn't need to download something from the web, which is what the python setup.py is likely going to do to get around the cross-compiler issue). - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
