[Tinyos-2.0wg] Re: tinyos-2-0-0-beta2-candidate

[David Gay]

On 7/4/06, Vlado Handziski <vlado.handziski at gmail.com> wrote:
> On 7/3/06, Philip Levis <pal at cs.stanford.edu> wrote:
> > On Jun 30, 2006, at 3:42 PM, David Gay wrote:
> >
> > >
> > > - At some point (not for the beta2) we should make a new tinyos-tools
> > > rpm (there's at least one semi-important fix to ncc, related to
> > > sensorboards and include directory searching)
> >
> >
> > I think that we need a new tools RPM; there are changes in ncc for
> > TOSSIM since 1.2.3.
> >
> > Phil
> >
>
> What about a new tinyos RPM with the remaining testing apps? I have finished
> the testing of the current RPM on eyesIFX and everything seems OK, apart
> from the Sense applications output (showing MSB vs. LSB bits). I have only
> tested on Linux, I don't have the msp430 tools for cygwin.
>
>
> Here are some general issues with the current RPMs. Some of the notes are
> for post-beta consideration. Testing has been done on a clean Fedora Core 5
> installation running in VMware.
>
>  [tester at localhost download]$ sudo rpm -ivh nesc-1.2.7-1.i386.rpm
>  error: Failed dependencies:
>         /usr/bin/guile is needed by nesc-1.2.7-1.i386
>  [tester at localhost download]$

It shouldn't be required (there's some unsupported binary diff stuff
written in Scheme in there). It should either be made optional, or the
binary diff should be removed from the distribution.

> TinyOS RPM:
>
> [tester at localhost download]$ sudo rpm -ivh tinyos-2.0.0beta2-1.noarch.rpm
>  error: Failed dependencies:
>         perl(GraphViz) is needed by tinyos-2.0.0beta2-1.noarch
>
> This has been reported before. There is no "official" RPM package on FC5
> satisfying this dependency.

I'm unclear what's causing it, too (graphviz is invoked as a command only).

> MSP430:
>
> Are we going to provide our own msp430 toolchain RPMs ?

We have been since beta1 at least. No plans to change them.

> General:
>
> While I understand the benefits of having common .spec files for cygwin and
> linux, I think that we are ending up with packages that do not provide
> "turn-key" solution on linux and can confuse a lot of early users. The main
> problems that I see are:
>
> - the packages are not fully relocatable with  --prefix. I think that by
> default we should install all binaries in /opt and use /etc/profile.d/xxx.sh
> /etc/profile.d/xxx.tcsh to amend the paths.

The problem is not the path, it's paths hardwired into scripts/etc.
Now if you want to be the one who spends the effort to make this
happen... AFAIK, most rpms don't properly support --prefix.

> - the packages are not properly setting the permissions to the serial
> devices and the ownership of the /opt/tinyos- 2.x files is left to be
> root.root

How is an RPM supposed to know who the package is being installed for
(FWIW, I don't think an RPM is a great way to distribute source code,
it's just more convenient than a tarball)?

Fixing the Linux serial port problem is tricky:
- which serial ports should be changed?
- USB serial ports are created on insertion. Fixing their permissions
requires hacking the USB installation scripts. And every time I do it
on my machine, I find it stops working 1 year later when I upgrade.
Not to mention that the hack to do this is somewhat dependent on your
USB-serial port device.

In other words, I suspect we're better off covering the serial stuff
through a good web page+wiki.

>
> We have solved all of the issues above in our eyesIFX installer kit:
>
> https://wg.tkn.tu-berlin.de/twiki/bin/view/WSN/EyesIFXDevelopmentKitSoftwarePackageInstallation

Just glancing at the nesC spec (e.g.), I see it's not going to work
quite right for nesC 1.2... (there's more paths now).

_______________________________
> App makefiles:
>
> By creating the java and python message files by default we are introducing
> a large dependency for the users that don't wand any PC support. They should
> be created on demand or we should add "detection logic" and build only the
> message stubs for the language that the user has installed or has selected
> as option during the installation of the RPMs.

Yes, I agree. There was a reason the RPM contains tinyos.jar, and we
forgot that somewhere along the way (I'm guilty of that too in the
Oscilloscope app - it doesn't come prebuilt in the RPM). All generated
files should be:
- pregenerated in the RPM
- NOT checked in to CVS

> Also, please consider using a variable for the java compiler in the
> Makefiles. In many cases we need to change JAVAC=gcj -C to get gcc-java
> support. The only thing currently not working with gcj is the Oscilloscope
> application because of missing widgets.

Do you know if there's a predefined value for JAVAC?

David