Re: RFS: libaosd (updated package)
On Wed, 28 Jul 2010 17:36:46 +0300, Paul Wise <pabs@debian.org> wrote:
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.
Ok, thank you for your time.
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.
That way seems more logical to me as libaosd-text mostly consists of
convenient pango wrappers and a sample textual renderer for aosd.
Moreover, it gives the user more control of what is actually installed.
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.
I have reviewed the contents and dependencies of the 0.2.5 binary packages
and see that there is no bug actually. So I was too quick for blaming.
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:
Great, please use it before releasing any future versions.
Yes, that is handy indeed, thank you for pointing that out for me.
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?
No, no changes in that field. And I don't plan to change anything back.
0.2.4 had a complete rewrite of aosd_cat and unfortunately an outdated
man page in the debian package.
Since then I adopted the man page upstream and will keep it up-to-date.
So I'm actually not sure what is the best way to deal with this bug.
Guess it should be "won't fix".
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.
I'm about to upload the new package where I have converted to dh >= 7.0.50~
with override_ targets in debian/rules and I also removed the substitution
of those files with debian's ones, resulting in almost pristine rules.
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'm actually leaning towards removing that patch.
Any warnings/errors are shown anyway. And it's me, the maintainer,
who will deal with the building bug reports.
On the other hand, I'm reluctant to make big changes in the de facto
standard
build system used in most of the atheme projects.
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.
Ok, I'll ignore it for now.
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.
Ok, that means that I have nothing to fix in libaosd package itself,
thank you.
--
Eugene Paskevich | *==)----------- | Plug me into
eugene@raptor.kiev.ua | -----------(==* | The Matrix
Reply to: