On Sun, Jul 1, 2012 at 2:35 AM, Andreas Tille <[email protected]> wrote:
>
> > W: fis-gtm source: newer-standards-version 3.9.3 (current is 3.9.1)
>
> That's because of your squeeze VM. You should probably install lintian
> from unstable using
>
> apt-get -t unstable install lintian
>
> (after having added unstable to your sources.list and not to forget to
> set preferences to make sure stable is prefered over unstable - if I
> remember correctly I posted the according entries to make in /etc/apt in
> the MoM period somewhere - if you can not find it and it is not clear
> what to do just ask again)
>
>
Thanks for pointing that out,
I found the instructions from the MoM emails period,
and managed to update lintian:
>From version : Lintian v2.4.3+squeeze1
To version : Lintian v2.5.10
I had to divert a bit from the January 25th, MoM instructions
in order to address a dependency between lintian and the
package: hardening-includes.
So, I modified the file:
preferences.d/01-linitan.pref
to contain:
Package: lintian
Pin: release a=unstable
Pin-Priority: 605
Package: hardening-includes
Pin: release a=unstable
Pin-Priority: 605
-
I hope is ok to put two related packages
in the same preferences file.
With this the update went smoothly.
> W: fis-gtm-5.5.000: executable-not-elf-or-script
> > ./usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_slist
>
> This should be easy to fix. Either there is a shebang line missing in
> the scripts or the permissions are not correctly set. Most probably
> this also could (should) be changed upstream as well.
>
>
Yeap,
I'll wait for Amul to confirm if we can insert the shebang line
in these scripts. He referred to this in his email.
> > W: fis-gtm-5.5.000: extra-license-file
> > usr/lib/fis-gtm/V5.5-000_x86_64/COPYING
>
> If this file is somewhere used inside the code a lintian override might
> make sense here.
Ok, I'll try to add a lintian override for this file.
I'm reading the instructions from
http://lintian.debian.org/manual/section-2.4.html
in order to do this...
> > W: fis-gtm-5.5.000: shlib-with-executable-stack
> > usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
> > 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
>
> This needs further inspection (I have not seen such warnings before).
>
> > c) What is missing in this case is the setuid for
> >
> > gtmsecshr
>
> Could be set inside debian/rules file.
>
Ok, I'm experimenting with the following now:
Index: rules
===================================================================
--- rules (revision 11509)
+++ rules (working copy)
@@ -39,6 +39,7 @@
--installdir $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)
@echo "I: Fixing up permissions for removed write rights -- we aren't
done yet!"
chmod +w -R $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)
+ chmod u+s $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)/gtmsecshr
> > 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).
>
> This should be expressed in a versioned Build-Depends. While this is
> fullfilled in current testing + unstable it should prevent build failures
> in other systems. (Done in SVN)
>
>
Got that update from your SVN commit. Thanks.
> Also in this case I would rather do something like
>
> apt-get -t unstable install cmake
>
>
good point.
I did so, by adding a file:
/etc/apt/preferences.d/02-cmake.pref
with the following content, that includes cmake
and its dependencies:
Package: cmake
Pin: release a=unstable
Pin-Priority: 605
Package: libarchive12
Pin: release a=unstable
Pin-Priority: 605
Package: libstdc++6
Pin: release a=unstable
Pin-Priority: 605
Package: cmake-data
Pin: release a=unstable
Pin-Priority: 605
Package: libacl1
Pin: release a=unstable
Pin-Priority: 605
Package: libattr1
Pin: release a=unstable
Pin-Priority: 605
Now this machine has:
cmake --version
cmake version 2.8.9-rc1
> 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....
>
> I admit that I never experienced that debuild and cowbuilder showed this
> kind of different behaviour and I do not have a sensible explanation for
> your observation. Further investigation is actually needed.
>
I'll do first another manual build with the changes above,
and then will revisit the cowbuilder environment.
I should be reporting on this soon...
Luis
