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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/edff0ebd9d04108cd1d8483e24e29...@mb8-2.1blu.de