Re: Update projectM packages
Hi!
> Please read devref:
>
> http://www.debian.org/doc/developers-reference/beyond-pkging.html#mia-qa
>
> libvisual-projectm is orphaned, so you don't need to contact anyone
> for it. Just adding the libvisual-projectm binary package to the
> libprojectm/projectm source package is enough for the ftpmasters to
> autocruft remove the libvisual-projectm source package.
>
> A new upstream release isn't appropriate for an NMU.
Okay.
> Are you sure upstream didn't change the ABI without bumping the
> SONAME? Looking at the symbols, it seems that there are a lot of
> symbol renames, deletions and so on. It looks like they forgot to do a
> SONAME bump. There is a transition freeze coming this month, this
> should probably wait until squeeze is released, or go to experimental.
I already contacted upstream about this, but I'm still waiting for a reply.
> Normally one would rename the libprojectm source package to projectm
> and change its version of the packaging instead of starting from
> scratch.
It would have been a lot more work to change libprojectm. All scripts and
stuff needed to be changed.
> A review of the package itself:
>
> debian/patches/debian-changes-2.0.1-0 needs editing and renaming.
> Please forward the two patches upsream if you haven't already.
Is done.
> No need to distribute src/README since it is about compiling/installing.
I'll remove it from including.
> Er, your source package contains debian/libprojectm.debhelper.log, how
> on earth did you manage that???
Seems to be some cruft I forgot to remove.
> Wow, upstream sure does embed a lot of external libraries, fonts. It
> is not appropriate to do that, please ask them to split them out of
> the main source tarball into a dependencies.tar.gz or similar. While
> upstream still embeds them and to ensure they are not used by Debian,
> it is a good idea to rm -rf the relevant directories before running
> upstream's build system. If any of them are actually used in Debian,
> please notify the Debian security team.
Okay, I'll ask them to do that.
> Please reassign #580559 to src:libprojectm and merge it with #565355.
> It looks like the maintainer is already working on this anyway, see
> #565355 for details. Next time you might want to investigate more
> closely before duplicating work?
Finished. I packaged the projectM packages for myself a half year ago and
found it in my directory a few menths ago. Then I decided to forward it to
the maintainers, but after I did not received a reply, I was thinking about
maintaining it by myself.
But of course I would leave the projectM package to the libprojectm
maintainer if he wants to have it.
> There are many many (mostly minor) lintian complaints (including some
> inappropriately overridden ones):
> [blahblah...]
I sent all this stuff to upstream. It's a little crazy upstream included
some ancient Autotools stuff although the project is using cmake.
> There are also a bunch of GCC and cmake warnings that should be sent
> upstream.
I already started diving into the code, but still have some problems to
understand what's going on in several units. I better send this to upstream
too.
> Please ask upstream to support QuesoGLC in addition to FTGL for font
> rendering. GLC allows font fallbacks so you can render a string that
> has characters from several different fonts. pango might be another
> alternative.
Okay, didn't know about that.
Thanks for your large analysis... Might take some days to fix all named
issues.
Cheers,
Matthias
Reply to: