Re: Packaging a library that requires cross-compiled code
Just a quick summary of the current status of the package, following
these discussions and work on #debian-python.
The package python-pynxt now build-depends on python-pynxt ||
(gcc-4.2-source && binutils-source). If python-pynxt is available, the
flash_driver.bin blob is obtained by copying it out of the installed
python-pynxt package. If it is not available, then a cross-compiling
binutils and gcc (C compiler only) toolchain is built, which in turn
This provides a way to build the entire package, using only
debian-provided packages, with a 'caching' functionality to avoid
having to rebuild a toolchain if a previous version of the package is
One case that I feel is missing from this setup is the trivial "just
use the blob provided by upstream". Given that we now have the entire
machinery to rebuild the blob if someone really really wants to (as an
aside, I'd like to repeat that the only thing I can see anyone doing
with it is either breaking the flashing process, or damaging the brick
by messing with the flash write timing), would it be acceptable to
default to using the upstream blob, unless an explicit force flag is
passed to debian/rules ?
On 9/30/07, Bernd Zeimetz <email@example.com> wrote:
> Holger Levsen wrote:
> > Hi,
> > On Sunday 30 September 2007 00:25, Bernd Zeimetz wrote:
> >> What about the following plan:
> > It's not only pointless, but will also result in FTBFS errors once the old
> > package is not available anymore.
> not if you build-depend on oldpackge | gcc-source and just build the
> firmware again if the old package is not available. Building the
> firmware is pretty easy and takes 5 minutes on my machine.
> But you're right, thre's no need to rebuild Davids provided firmware
> blob, especially since it will not run on a user's computer.
> debian/rules will allow to rebuild it for the paranoids, though.
> Bernd Zeimetz
> <firstname.lastname@example.org> <http://bzed.de/>
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com