Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> Still working hard on the sleep and id update. Most stuff work now but
> it's still very unstable due mainly to the new RF firmware.
> I'd like to publish a preview of the firmwares on tomorrow so you can
> give  it a shot if you want.

I'm willing to test it \o.

> OTH I'm thinking about this major firmware update for lambda users.
> When  they just bought their tux, it seems they're quickly discouraged
> by the  firmware update procedure and some get into much troubles
> compiling and  installing dfu-programmer. tuxup already facilitates
> the use of  dfu-programmer but including a binary of dfu-programmer
> would remove that  burden.
>
> A few questions:
>
> - Is it a good idea?

The binary would have to work on all distributions and platforms. I
myself don't like binaries too much (but then, I've been a Gentoo user
for quite some time now, which might explain...)

> - I guess we can freely redistribute dfu-programmer in a binary only
> format, but I may be wrong. dfu-programmer is under GPL. Do I have to
> attach a license file with the binary or display the license
> somewhere?

You have to make the sources available, but not necessarily bundled
with the binary. A readme with an URL to download the sources from
should suffice.

> - If I compile it on my linux box, what is it supposed to run on? As
> long  as you have the dependencies, should it work on any computer or
> are there  other stuff to take into account? I'm thinking about BSD,
> OSX, ...

Library versions, as you point out below, may break your application.

> ldd /usr/local/bin/dfu-programmer
>         linux-gate.so.1 =>  (0xffffe000)
>         libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb7f21000)
>         libc.so.6 => /lib/libc.so.6 (0xb7df9000)
>         /lib/ld-linux.so.2 (0xb7f43000)

What makes it hard for joe user to compile ? Couldn't it be seamlessly
integrated in the "tuxup procedure" (neved used it) ?

	Damien