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

Re: RFS: libvigraimpex (updated package)



> > * George Danchev <danchev@spnet.net>, 2009-09-04, 18:06:
> > 
> 
>http://mentors.debian.net/debian/pool/main/l/libvigraimpex/libvigraimpex_1.6.0-2.dsc
> > >>
> > >> I would be glad if someone uploaded this package for me.
> > >
> > >I'm not that optimistic with the C++ code and symbols files.
> > >
> > >First, yours appear to be architecture dependent:
> > >http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libvigraimpex2ldbl
> > 
> > Yes, I'm aware of that:
> > 
> > $ grep arch= debian/libvigraimpex2ldbl.symbols | c++filt
> >    (arch=!alpha !amd64 !ia64 
!s390)vigra::void_vector_base::resize(unsigned 
> int)@Base 1.5.0
> >    (arch=alpha amd64 ia64 s390)vigra::void_vector_base::resize(unsigned 
> long)@Base 1.5.0
> > 
> > >Second, there are problems: see #521569
> > 
> > Yes, using -c 2 or higher is a bit risky. But I don't do such things.
> 
> Yes, that is correct.
> 
> > >and the whole thread at:
> > >http://lists.debian.org/debian-devel/2009/04/msg00297.html
> > 
> > Right, but since #521551 is fixed, providing symbols files for C++ 
> > libraries is not such a big issue anymore. (That reminds me that I am 
> > missing versioned build dependency on dpkg-dev.)
> 
> Very good. You have a point with regard to #521551, so gimmi some time to 
> investigate and line up with it.
> 
> > >Third, as I can see from debian/rules, dh_makeshlibs won't pass any check
> > >option to dpkg-gensymbols and the default -c1 is used which is a request 
> for
> > >FTBFS on certain architectures in that case.
> > >
> > >So, I suggest we remove the symbols part or simply disable it (pass -c0 
to
> > >dpkg-gensymbols, as I did with one of my library packages bobcat) until a
> > >better solution is found or GCC people accept the solution provided at:
> > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
> > 
> > I can pass -c0 to dpkg-gensymbols if you insist, but I don't think this is
> > really necessary.
> 
> Don't bother for the time being.

Unfortunately, I will get a chance to work on that package possibly during the 
next weekend, since I'm currently busy taking care of nasty RC-bugs in some of 
my packages (RC always gets higher priority). Hopefully, another sponsor could 
take care of that before I'm able to, but your valuable work won't be left 
unaddressed. Thanks!


-- 
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


Reply to: