Re: [MoM] Packaging fis-get
On Sun, Feb 12, 2012 at 10:20:44AM -0500, Luis Ibanez wrote:
> Yes, you used the right email address.
:-)
> That reminds me that I have to finish that homework
> with the help of our local GPG Guru.
Either local Guru or global one:
http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/
> This is to a certain level, related to the code generation
> step that fis-gtm does with mumps. The full "pro" directory,
> was generated during that bootstrapping stage. But now that
> we captured some of the generated .h and .c files, we can no
> longer use the default "clean" method of the fis-gtm makefile,
> since it goes and removes the "pro" directory, and some other
> files, that now make part of our pure-C source code base.
I did suspected something like this. I guess this is the reason why you
have overriden dh_clean by doing nothing. But nothing in this case is
only part of the solution because we need to get rid of those *.o files
etc. So you either need to reimplement the clean target or you make a
backup of all those files which should remain. In this special case the
following also comes to mind:
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'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).
> 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).
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.
> > ~/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.
Fine.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: