Re: RFS: libaosd (updated package)
On Tue, Jul 27, 2010 at 7:36 PM, Eugene Paskevich <eugene@raptor.kiev.ua> wrote:
> As you started reviewing this package does it mean that
> I have found a sponsor and now should note appropriately in m.d.n?
No. Since I'm at DebConf I have some time to review packages, but not
nessecarily enough time for ongoing sponsorship after DebConf.
>> Why did you add the libaosd-text-dev package?
>
> The reason for splitting out libaosd-text-dev from libaosd-dev is mainly
> because libaosd-dev could be used standalone without the -text lib and
> header.
Hmm OK. Personally I don't think that needs to be done.
> In the current state it is possible to have aosd-text.h installed without
> the actual libaosd-text.so library installed, which is definitely wrong.
That is a separate bug that can be fixed by depending on both libraries.
>> Are you aware of the abi-compliance-checker package? It would be great
>> if you could use it upstream to ensure you do not break the ABI. There
>> is also this service based on that tool:
>>
>> http://linuxtesting.org/upstream-tracker/
>
> Now that you told me about it, I am, thank you. :-)
> I have run the check 0.2.5 vs 0.2.6 and
> for both libaosd and libaosd-text the verdict was: Compatible.
Great, please use it before releasing any future versions.
>> As upstream, do you have any comments on #464744?
>
> I was going to comment in that bug directly once the package is uploaded.
Does the new package revert it or something?
>> Why did you drop this line from debian/rules?
>>
>> rm -f config.sub config.guess
>
> I'm not sure why they are there to begin with.
> These files are in orig tarball and are replaced with debian ones.
> Why do they have to be removed on clean?
As was said in another mail, so that the changes between the upstream
and the Debian version do not end up in the diff.gz/debian.tar.gz.
> Thank you, I'll try to contact openSUSE maintainer.
Great.
>> The upstream build system hides the build commands, usually we prefer
>> that they are shown so that looking at the build logs allows people to
>> debug issues more easily.
>
> Fixed with a patch.
Might be a good idea to make upstream more flexible and only hide
stuff if a certain environment variable is set. In any case your patch
makes the system print ugly stuff like this:
ESC[KESC[0;33mGenerating
dependencies...ESC[0m^MESC[KESC[0;32mSuccessfully generated
dependencies.ESC[0m
I wonder if just switching to automake would not be a better solution.
>> I: libaosd2: no-symbols-control-file usr/lib/libaosd.so.2.0.0
>> I: libaosd-text2: no-symbols-control-file usr/lib/libaosd-text.so.2.0.0
>
> Given that this tag is of wishlist severity, I believe that it's not
> strictly
> necessary to resolve. If it is strongly advised to fix this one,
> could you please point me to the guide on how to create these files?
> Is it just dpkg-gensymbols or there is something more to it?
This command should give you enough info:
lintian-info -t no-symbols-control-file
Since there are no other source packages that build-depend on libaosd,
adding a symbols file isn't useful, just ignore it for now. Once some
packages have migrated from libxosd then you might like to add symbols
files.
>> dpkg-shlibdeps: warning: dependency on XXX could be avoided
>> if "YYY" were not uselessly linked against it (they use none of its
>> symbols).
>
> I'm gonna need your help in resolving this one...
> As per Niels Thykier's advice I have added these flags into debian/rules
> LDFLAGS: --as-needed,--no-undefined.
>
> It removed most of the warnings but these two:
>
> dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if
> "debian/aosd-cat/usr/bin/aosd_cat" were not uselessly linked against it
> (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if
> "debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0" were not uselessly
> linked against it (they use none of its symbols).
That is a set of bugs in the stack below pangocairo. Some of the glib
pkgconfig files add pthread to Libs instead of Libs.private and then
this is propagated up by other buggy pkgconfig files that use Requires
instead of Requires.private.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: