Re: Any progress with FIS GT.M?
On Sun, Jul 01, 2012 at 11:34:10AM -0400, Luis Ibanez wrote:
>
> 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.
You can add as many as you want - just a question of your taste.
> > > 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...
Alternatively you find a lot of examples by simply doing
find packages/ -name "*lintian-overrides" | grep trunk
where you can very simply get the idea.
>
> > > 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
BTW, pbuilder / cowbuilder do handle some so called hooks where you can
open a shell to inspect the current build tree. This might help a bit to
track down the differences between debuild and pdebuild.
> 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
Fine.
> > 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...
Thanks for your work on this
Andreas.
--
http://fam-tille.de
Reply to: