[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Packaging fis-get



Hi Andreas,


On Sun, Feb 12, 2012 at 10:05 AM, Andreas Tille <andreas@an3as.eu> wrote:
> On Sat, Feb 11, 2012 at 09:04:05PM -0500, Luis Ibanez wrote:
>> Report on MoM and fis-gtm packaging.
>> but...
>> end up manually generated the patch and
>> added it to the debian/patches directory.
>
> I did:
>
>  quilt push
>  quilt refresh
>
> which changes the patch slightly (by stripping of dates) and added some
> basic description to the patch (lintian in nitpicking mode (-I) will ask
> for this and it can not harm.

Great,
I see the changes now.

> Please make sure that I used your correct
> e-mail address you want to use for this purpose.  I also added this one
> to Uploaders.

Yes, you used the right email address.

> It needs to be one ID of your GPG key.  Otherwise dch will
> consider your changes as NMU (Non Maintainer Upload).
>

That reminds me that I have to finish that homework
with the help of our local GPG Guru.


> I also noticed that in my "debuild" attempt some files remained in the
> build tree and thus I removed these via clean target in debian/rules.
>


Yes,
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.


> When working on the clean target I noticed, that the file
>
>   pro/obj/gtm_threadgbl_deftypes.h
>
> vanished from the build directory somehow.

Yes, this is part of the set of files that
we captured in the "extra" set, after being
generated with mumps in the bootstrapping
stage.


> Please watch this issue.  The
> rule is that after
>
>   debuild
>   make -f debian/rules clean
>
> the build directory should look identical to the state before debuild.
> Otherwise you will get "Does not build twice in a row" bugs filed
> against your package.
>

I see.

I'll review this.
Your override of the clean rule may
have already solved this problem,
but I'll double check, just in case.


>> This moves us one step forward on building
>> the package, when calling "debuild".
>>
>> I still have to verify whether the resulting build
>> produces the binaries that are expected...
>
> At my side pdebuild (in a clean chroot) as well as debuild there are no
> good news regarding a successful build:
>

mm...
I haven't use pdebuild before.
(will read about it).


> ...
> Source Directory List: sr_linux sr_x86_64 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix sr_port_cm sr_port
> make[2]: Entering directory `/home/andreas/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B'
> tcsh -f /home/andreas/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix/gen_xfer_desc.csh sr_linux sr_x86_64 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix sr_port_cm sr_port
> ~/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B ~/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/pro/obj
> tcsh -f /home/andreas/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix/gen_gtm_threadgbl_deftypes.csh /home/andreas/debian-maintain/repack/fis-gtm/fis-gtm/fis-gtm-5.4-00
> 2B sr_port pro/obj sr_linux sr_x86_64 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix sr_port_cm sr_port
> Entering gen_gtm_threadgbl_deftypes.csh to build gtm_threadgbl_deftypes.h
> ~/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
>
>
> Hope you can fix this build issue.
>


Ok, I'm not trying to replicate this.
and will be reporting back soon.


    Thanks


         Luis


Reply to: