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

Re: [MoM] Packaging fis-get



On Wed, Feb 8, 2012 at 5:04 AM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi Luis,
>
>
> I took the freedom to change debian/get-orig-source heavily.  The
> rationale was to demonstrate how I would solve the following problems:
>
>  - Find the real version number which is actually 5.4-002B and not
>    54002B.
>  - Create a "non-dirty" tarball
>  - Merge the files prepared by you in
>

Excellent,
I have now updated from your changes.
Great material for me to study.


> This script in theory would work for later versions as well - in
> practice we hopefully do not need the src_extra not for new versions but
> I left this as a demonstration.
>

Yes, good point.

It is great to see the debian/watch role
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch
(another thing that I needed to learn).


> I'd suggest to base our future work on what you get when executing
>
>   make -f debian/rules get-orig-source
>
> in current SVN.
>

Yes, got it.
I just tried your process and got the three tar.gz
files in the "tarballs" directory that you configured.


> Based on this I tried to build the package using your packaging stuff.
> At first I noticed that tcsh was missing in my build chroot.  When
> inspecting debian/control I realised that you moved the packages
> discussed in the previous mails under Depends.  However, these are
> required to build the package and thus I moved the files to
> Build-Depends to enable properly building the package.


Yes, my bad.

Now that you pointed out, I see the difference
use between Build-Depends and Depends.


>
> Usually the building tools are realising themselves via dh_shlibdeps.
> (see manpage).  There is no point in calling this explicitely when using
> dh, everything works automagically - provided you are using
> ${shlibs:Depends} in Depends (and so I did).
>

Thanks for pointing me to the man page.
It was very instructive to read the page.

It is probably a good standard item to include in the MoM
training check-list. It certainly clarifies the content of the control file.

> So far for pushing you foreward by adding usual packaging knowledge
> straight into the code.
>

Thanks for illustrating/implementing this.

> Now I come to the problem I'd like to hand over to you:
>
>   ...
>   debian/rules override_dh_auto_build
> make[1]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B'
> tcsh ./setupenv.sh
> ----- Start the build -----
> Linux Host 64
> Linux Host linux x86_64 x86_regs
> 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 `/tmp/buildd/fis-gtm-5.4-002B'
> make[2]: *** No rule to make target `gtmshr_symbols.export', needed by `../libgtmshr.so'.  Stop.
> make[2]: Leaving directory `/tmp/buildd/fis-gtm-5.4-002B'
> ------ End of build -------
> make[1]: Leaving directory `/tmp/buildd/fis-gtm-5.4-002B'
>   dh_auto_test
>   ...

Yes,
I can replicate this problem here, when I do "debuild".

However, when I call directly:      tcsh  setupenv.sh

the build proceeds as expected,
and finishes successfully.

So, I need to study "debuild" more, to understand what
is different by the time "tcsh setupenv.sh" is called.

I'm now reading:
http://www.debian.org/doc/manuals/maint-guide/build.en.html

>
> Could you please check why setupenv.sh does not work and also why it
> does not return an error code because the package build process keeps on
> instead of stopping because of the error.
>


Yes, I'll dive into this.


>> Next steps:
>>
>> 1) I'm getting some warnings from changelog
>>     when doing "debuild".  I probably have some
>>     lines formatted incorrectly.
>
> I did not noticed this on my side.
>

Sorry, I should have reported the fix for this.
It turned out to be the formatting of the date field.
A fix was committed for it by the time you looked at it.


>> 2) Need to learn how to trigger a build from "debuild".
>>     My current attempt was to use:
>>
>>                      override_dh_auto_build
>>
>>     but that doesn't seem to do what I was expecting.
>
> The build is actually triggered but is broken - at least this is
> the situation from my perspective.
>


Yes, I replicated this here.

I'm guessing that the environment is different when
things are called through "debuild", with respect to
when the command "tcsh setupenv.sh" is called
directly.

I'm tracking this now...


    Luis


Reply to: