[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#819394: RFS: stormlib/9.20-1 [ITP]



On Monday 18 April 2016 18:31:42 Gianfranco Costamagna wrote:
> Hi Pali,
> 
> >Ehm... repacking is ugly!
> 
> I agree here
> 
> >Ok, I can ask, but I doubt that upstream will do that. This is
> >windows project and in windows world is PGP not supported by Visual
> >Studio/MS. (We can be happy that library working fine under linux
> >with gcc :-))
> 
> asking is free :)
> 
> > >hardening-no-bindnow usr/lib/libstorm.so.9.0.0
> > >==> How to do that for current debian/rules which uses cmake?
> > 
> > https://wiki.debian.org/HardeningWalkthrough
> >
> >As a workaround appending CPPFLAGS to CFLAGS and CXXFLAGS should
> >work in most cases. Debhelper (since 0.9.20120417, only with
> >compat=9 and dh_auto* commands!) and cdbs (since 0.4.110) handle
> >this automatically so the workaround is no longer necessary if they
> >are used.
> >
> >As you can see debhelper 9.2015 is in Debian and stormlib has
> >compat=9. So what to do?
> 
> well, there is an implicit declaration in that wiki:
> the upstream makefile should not override Debian flags :)
> 
> 
> in Makefile.linux
> DFLAGS = -D__SYS_ZLIB
> OFLAGS =
> LFLAGS = -lbz2 -lz
> CFLAGS = -fPIC -D_7ZIP_ST
> CFLAGS += $(OFLAGS) $(DFLAGS)
> 
> 
> I guess a += instead of = will fix the issue.

You are looking at wrong file! We do not use Makefile.linux, but 
CMakeLists.txt. And then cmake in /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu 
directory generate own Makefile, nothing from Makefile.linux.

> >And this did not helped me too! I read debian lintian description
> >for symbols-file-contains-current-version-with-debian-revision
> >before.
> >
> >File debian/libstorm9.symbols already contains *all* public
> >functions which can be used by other libraries. And all those
> >functions do not have any debian suffix.
> >
> >So I do not understand why it show error message and even how to fix
> >it.
> 
> I did a build, opened the deb file/control/shlibs (or whatever is
> called) indeed, *your* exported symbols are fine, but many public
> symbols are missing (note: this is a build failures on
> debian-buildds)
> 
> look e.g.
> http://debomatic-amd64.debian.net/distribution#unstable/stormlib/9.20
> -1/buildlog
> 
> you need to list all of them, or make them private

Now I see couple of symbols, but those are not public. They are private 
and probably without stable ABI. For sure they should not be listed or 
used in Debian.

Will making them as "private" helps? And how to do that? Or better, how 
to ignore all symbols expect those which are whitelisted specified in 
debian/libstorm9.symbols file?

> dh_makeshlibs
> dpkg-gensymbols: warning: some new symbols appeared in the symbols
> file: see diff output below dpkg-gensymbols: warning:
> debian/libstorm9/DEBIAN/symbols doesn't match completely
> debian/libstorm9.symbols
> 
> making makeshlibs sad is a build failure here!
> 
> HTH,
> 
> Gianfranco

-- 
Pali Rohár
pali.rohar@gmail.com

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: