Re: trying to build the image.deb
[Federico, I added you to CC because you previousely uploaded the imagej
packages. Please read below about a FTBFS issue.]
On Tue, 23 Sep 2008, Paolo Ariano wrote:
i could understand but i don't understand why i had not this problem
until today, imagej is in debian from some months ;) what is changed ?
just to understand
There is a difference between a binary package in the Debian package pool
which can be installed and the packaging stuff we are working on (to be
able to upload the next version). I guessed from your past mails that
you are mixing up this completely different things. Just try
$ apt-cache policy imagej
imagej:
Installed: (none)
Candidate: 1.40a-1
Version table:
1.40a-1 0
501 http://debian.tu-bs.de testing/contrib Packages
50 http://ftp.de.debian.org unstable/contrib Packages
This tells you which package version is actually available in Debian.
This is the old version which was prepared by you previousely and
finally uploaded by Federico Di Gregorio <fog@debian.org>. I have
no idea how Federico builded the package but I definitely did it not
in a pbuilder environment which makes sure that all build dependencies
are fullfilled. (Just try `apt-cache show pbuilder` to learn about
pbuilder.)
The reason why this was no problem until now is, that autobuilders
only work on packages in main Debian not in contrib and non-free.
Because ImageJ is in contrib it was not compiled for any other
architecture and thus the uploaded binary file just went through.
So strictly speaking - we are lucky that imagej is in testing -
it should not be there because the build process does not work
out of a clean Debian build environment (i.e. no Java etc previousely
installed).
We are now working on the next version of ImageJ in CVS and I try to avoid
the issues described above by providing proper build dependencies to enable
building ImageJ on any architecture (including autobuilding on i386). The
preparation for the next upload of ImageJ to the Debian package pool
as an installable package is done in the form of fixing the files in
the debian directory inside the SVN until the package build process
finally works. Does this clarify the difference between an upload
of a binary Debian package to the Debian mirror and working on packaging
stuff in SVN? There is no automatism which propagates the SVN stuff
to the Debian package pool.
yes, i hoped openjava solved the jpeg issue but is not the case at the
open maybe in the future
See my mail to debian-java. I failed to google the ImageJ - JPEG
issue on this list. Perhaps you might also foreward this question
to upstream - they might be interested in building ImageJ with
OpenJDK. I can not really imaginge that JPEG as very propular
image format is not supported in OpenJDK - so there must be some
really simple solution ...
hope to upload (the binary to debian server)
Well, please don't until the issue above is fixed. Perhaps there
is some other way to circumvent the "license has to be read" issue
in sun-java-jdk which I do not know.
as soon as possible as in
the imagej ML linux users said that they have problem with the old
imagej.sh
As I told you there is another image with this script (see bash -n output).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: