Hello Andreas, On 11/22/12 15:15, Andreas Tille wrote:
Sounds good. I just added gert-guest to the Debian Med project to enable commit permissions. Note: I also found
Good.
Indeed, I didn't remeber that one. First I'll try to recover the password. The problem is, I don't know which email address I was using. I doesn't seem to be my current work address.gerddie-guest Gert Wollny on Alioth - perhaps an old yccount you might have forgot.
There is a 1:1 relation between ITP and package. The reason is simple: If you upload the package the bug is closed - so with the first upload there would be no remaining bug to close for the other packages.
Okay.
You're probably right, the dev package will stay monolithic, but the libraries (and programs) could be logically divided. I'll thing about how to do this.- lintian: My libmia package contains more than one shared library, so I guess I should override the "package-name-doesnt-match-sonames", right?It depends. Alternatively you might consider creating more than one binary package. It helps to decide if you answer the question whether it might make any sense to install a single library without all the others - in this case I'd vote for single binaries. Otherwise a lintian override might make sense.
There's another thing I overlooked - MIA uses plug-ins similar to ocatave using modules *.oct, I decided that it might be better to name the modules *.mia to avoid that every platform has its own code path for searching these libs. The problem is, dh_strip doesn't recognice these files and leaves them unstripped. I've seen this issue discussed with regard to octave and a bug report regarding Go modules, all unresolved and quite old. Hence, my solution is to patch the dh_strip script to consider the *.mia files and include this patched version in the debian build script, but since my knowledge of perl is close to zero, this is really a one-time hack. You know of a better solution?
The libmia-doc created by Doxygen contains a "jquery.js" (embedded-javascript-library). I read that one should add the according package as dependency and remove the javascript, tried it, but is seems that the system provided jquery.js is different, i.e. the documentation web page didn't work properly. So I'd override this as well.
I recently learned that this could be a dangerous decision. If the source code contains some compressed JavaScript people do consider this as "binary without source" which in turn deserves a RC bug (or ftpmaster will reject the initial upload). Are you really sure that doxygen created jquery functions are not properly rendered with Debian's packages jquery?I just confirmed that it doesn't - the debian package provided version of jquery is v1.7.1, but the doxygen generated script claims to be v1.3.2. In addition, I've scanned the doxygen source code, and it creates different scripts depending on the Doxygen htmlgen options (doxygen/src/htmlgen.cpp) which leaves the question which of the two possible versions is provided by debian. Apart from that the Doxygen tarball distributes the same compressed javascript code (upstream and in at least in Ubuntu 12.04) as of version 1.8.1.2. I just checked, it seems that doxygen 1.8.2 (which is in experimental) uses the 1.7.1 jquery. So in light of being able to backport the package, it would be better to keep the script, considering the RC bug thingy, I would consider to add the uncompressed version of the script (if it is still available) to the source tarball in a contrib directory if doxygen is < 1.8.2, and otherwise use the package version. Then again there is the danger that doxygen will not sync to ne new jquery release at the same time debian provides a new package.
best, Gert