Re: [MoM] Packaging fis-get
Andreas,
On Sun, Feb 12, 2012 at 10:38 AM, Andreas Tille <andreas@an3as.eu> wrote:
>
> In the debian/get-orig-script we are unpacking the extra files into the
> build tree. An alternative way could be, to simply add the extra files
> either in a different directory or just keep the extra tarball as is
> inside our orig.tar.gz tarball. Than we could do
>
> override_dh_auto_configure:
> <something to move extra files into place>
> dh_auto_configure
>
> When doing so a clean afterwards can not harm our extra files because
> only copies will be cleaned up.
>
I have now implemented this.
Put the extra files in a helper directory, that gets included in the
orig.tar.gz file.
It is certainly a nice way to take advantage of the fact that we
have the extra file in a separate tar file.
At configuration time, the extra files are copied from the helper
directory into the main directory. This also helps to restore the
files after "clean" is invoked.
>> I'll review this.
>> Your override of the clean rule may
>> have already solved this problem,
>> but I'll double check, just in case.
>
> Well, my intervention into the clean process just removed files - it can
> not restore a needed file out of thin air - so it is actually not fully
> solved. Please consider my idea above. There is probably no single
> solution for this problem and there are always more than one working
> solution. Please ask me to be more verbose if my advise above was not
> clear enough or just find another way to make sure that a clean restores
> what we are originally storing in orig.tar.gz (in whatever way we design
> the layout of the orig.tar.gz).
>
Your details were clear enough.
This is now solved by the approach of including the extra
files in a helper directory included inside the orig.tar.gz file.
The extra files are restored after a "clean" by copying them
back from the helper directory during the configuration stage.
>> mm...
>> I haven't use pdebuild before.
>> (will read about it).
>
> You definitely need to learn about methods to build inside a fresh
> unstable chroot. For the beginning I kept it more simple but you need
> to learn about this anyway. As far as I can see pbuilder (this is the
> package carrying pdebuild) is the most easy for the beginner. If it
> comes to a point where you consider pbuilder as "to slow" because you
> are using it very frequently, you will want to use cowbuilder and an
> alternative way is sbuilder (I recently installed this one which was a
> bit nifty when sitting behind a proxy).
>
I have now read about pbuilder from:
http://pbuilder.alioth.debian.org/pbuilder-doc.pdf
created a pbuild environment with:
sudo pbuilder create --distribution sid --debootstrapopts --arch
--debootstrapopts i386 --basetgz /var/cache/pbuilder/base-i386.tgz
--mirror http://ftp.jp.debian.org/debian linux32
(Did this to ensure that the environment is a 32 bits one...)
> All these tools start from a freshly created basic chroot from Debian
> unstable and build the package inside this. This is an unavoidable way
> to make sure that you really got all Build-Depends correctly.
>
Very nifty indeed.
>> > ~/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj ~/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B
>> > gen_gtm_threadgbl_deftypes.csh-E-: pro build link of /home/andreas/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj/gtm_threadgbl_deftypes failed, see /home/andreas/debi
>> > an-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj/gtm_threadgbl_deftypes_linkmap.txt
>> > ~/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B
>> > make[2]: *** [gtm_threadgbl_deftypes] Fehler 1
>> >
>> Ok, I'm not trying to replicate this.
>> and will be reporting back soon.
>
>
I have don't see this specific error.
Hopefully that means that the use of the helper
directory to restore the extra files is doing the trick.
However, now I'm running on a new error at the
time of building the .c files.
The message is:
/usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error:
posix_types_32.h: No such file or directory
apt-file find tells me that posix_types_32.h is available
in the packages:
* linux-libc-dev
* gcc-multilib
So I added both to the Build-Depends: field
in the control file, but to not effect...
The field (in my local copy) now is:
Build-Depends: debhelper (>= 8), adduser, ucf, po-debconf, libicu-dev,
tcsh, gnupg, zlib1g-dev, libncurses-dev, libgcrypt11-dev,
libgpgme11-dev, linux-libc-dev, gcc-multilib
I'm running out of ideas on how to address this...
It seems to be related to a 32 bits, 64 bits mismatch somewhere..
Any suggestions ?
Thanks
Luis
Reply to: