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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
