On Sun, Jul 1, 2012 at 2:35 AM, Andreas Tille
<andreas@an3as.eu> 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
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