On Mon, Jul 2, 2012 at 11:00 AM, Yaroslav Halchenko
<debian@onerussian.com> wrote:
Luis, I have inlined my answers ... I do not have a "working" checkout
of fis-gtm since there was some restructuring you guys were talking
about -- please commit them.
mm, It should be building with what is currently in
github (fis-gtm source) and in the debian-med SVN.
On Mon, 02 Jul 2012, Shah, Amul wrote:
> I did not see this email in the debian-med mailing list archive, so I'm re-sending.
> my comments marked as [amul:1].
> >W: fis-gtm source: newer-standards-version 3.9.3 (current is 3.9.1)
use the freshiest lintian ;-) better use Debian sid (unstable)
altogether (e.g. in VM) for the working environment to test it
appropriately
This has been taken care of now.
I updated lintian from unstable,
but I agree that if I setup the VM again,
I would simply update the entire system to unstable,
and in that way have a similar environment to what
we get with cowbuilder.
> >W: fis-gtm-5.5.000: executable-not-elf-or-script ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmcshrc
> >W: fis-gtm-5.5.000: executable-not-elf-or-script ./usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_slist
> [amul:1] I'm going to hazard a guess that that lintian expects file extensions
> or shebang on the first line to identify what the file is doing.
> ...
> The others are bourne shell scripts that lack the shebang. I'm going
> to look into their usage and see if we can add that into them.
yeap -- all executables scripts must have shebang to guarantee proper
environment to be chosen.
I'm now inserting the shebang line in the "rules" file, by calling sed.
It is not pretty, but it does the trick.
Note that, after the change, one of the scripts get a format warning
from lintian. (must still track that one: +1 in my TODO list).
> Of the scripts
> above, gtmprofile* and gtmcshrc are bourne shell and C-shell scripts for users
> to source.
if they are to be sourced they should not be executable... we might
altogether place them under /etc/fis-gtm/5.5.000/ since they sound like
environment configuration files. Are they supposed to be sourced by any
fis-gtm's script? then we might like to symlink them back under
/usr/lib/fis-gtm/V5.5-000_x86_64/
This is a question for Bhaskar.
The implications escape me... :-)
> >W: fis-gtm-5.5.000: extra-license-file usr/lib/fis-gtm/V5.5-000_x86_64/COPYING
> [amul:1] Is this because it is also in ./usr/share/doc/fis-gtm-5.5.000/copyright?
most probably. if no internal scripts/binaries rely on it to be there:
rm after installation (in debian/rules). If they are needed -- lintian
override is needed with a description for that
I used the dictatorial method of deleting the COPYING file
with an entry in the rules file. Another non-pretty solution,
but yet one that does the trick...
> >W: fis-gtm-5.5.000: shlib-with-executable-stack usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
> [amul:1] This is expected. Ignore it
weird -- that should have been ignored since I added creation of an
override in debian/rules... may be that old lintian did not understand
the '*' in the file pattern... test with a fresh one
I'll post the outputs of a fresh build.
> >W: fis-gtm-5.5.000: shared-lib-without-dependency-information ./usr/lib/fis-gtm/V5.5-000_x86_64/libgtmutil.so
> >W: fis-gtm-5.5.000: shared-lib-without-dependency-information ./usr/lib/fis-gtm/V5.5-000_x86_64/utf8/libgtmutil.so
> [amul:1] This is expected. The installation builds there shared libraries from
> compiled M code. Ignore it
we better then have an override (adjust debian/rules which generates it
) with such a comment
Now that I see how you inserted the lintian exception,
I can copy it for this file. (+1 to my TODO list...)
> > gtmsecshr
> [amul:1] Not knowing anything about debuild or cowbuilder, I assume that you
> run the commands as a normal user. I would no expect gtmsecshr to have setuid
> permissions. Nor would I expect gtmsecshr to have setuid root permissions until
> the file is installed.
kinda resolved in my other comment -- need override_dh_fixperms.
This is a great finding.
Let me repeat it just to see if I understood correctly.
One of the standard steps of packaging is:
dh_fixperms
This step resets permissions to safe defaults.
In our case, we have to override the default behavior
of this stage, in order to prevent it from changing the
permissions that we have set correctly in the intermediate
installation.
Is that right ?
I'll experiment with the overriding it...
(will report on this tomorrow)
> [amul:1] This is the only thing that I could find that resembles a post install script.
> ls -l ../build/luisibanez-fis-gtm-4077ab8/debian/fis-gtm-5.5.000/usr/share/lintian/overrides/fis-gtm-5.5.000
> -rw-r--r-- 1 ibanez ibanez 83 Jun 30 17:34 ../build/luisibanez-fis-gtm-4077ab8/debian/fis-gtm-5.5.000/usr/share/lintian/overrides/fis-gtm-5.5.000
that is those lintian overrides which get installed
> >So.. something is unfolding differently in the cowbuilder environment.
> >One thing that comes to mind is that in the CMakeList.txt file we
> >are expecting to find CMake 2.8.5 (or higher).
that is ok -- we have 2.8.8 in sid
Yeap. It works great in cowbuilder,
and in the rackspace server, I did the same trick that Andreas
suggested to update cmake from unstable.
So, this is no longer an issue.
> >(with debuild ) I have been building a local cmake (from the source
> >in the Git repository of CMake) and then running "debuild -d" so
> >it ignores the fact that the cmake dependency is not preset (as an
> >installed debian package).
evil you! ;) (see my comment about sid a as working environment)
Hey !, It was a gesture that proves
our determination to get this done :-)
a bit pedestrian, I must admit...
(fixed now in a decent manner, by updating cmake from unstable).
> >It would look like something in the cowbuilder environment is preventing
> >the installation scripts from setting the right permissions, or maybe
> >from knowing that it has to modify the permissions....
those non-executable permissions are a bit weird to me to say the
truth -- may be another gift from dh_fixperms?... and I am lost
already either it was resolved or not ;)
I haven't solved it yet,
but your finding of dh_fixperms seems to point in the right direction.
I'll give it a shot at this tomorrow, and will report back.
Hope this helps
It certainly does
Thanks
Luis