Re: [brlcad-devel] .deb packages (Debian, Ubuntu, ...) for 7.16.10

[Manuel A. F. M. <man...@gm...>]

On Tuesday 31 August 2010 20:00:30 brlcad wrote:
> Yes to all three is probably the most accurate answer.  We made a copy
> for our own use but they're dead projects.  So after finding out from
> upstream that they have no desire or intent to maintain the codes
> further, we took them over as the new upstream.

Fine then :)

> OpenNURBS is a special case.  We do presently have a fork of the code
> with modifications that upstream is 100% uninterested in integrating. 
> The Rhino folks (graciously) provide OpenNURBS as open source but are
> absolutely not interested in enhancements, particularly ones that are
> competitive with their commercial products.

OK, I'll treat you as upstream too, then.

> > That could cause the same security bugs as any other package, really.
> > The thing in this case is that is very unlikely that people accept
> > another package just because your TNT is a bit patched. However, I
> > could take over the maintainance of that package and include those
> > patches myself in the same package (or bug the current maintainer to
> > do it).
> 
> TNT is not a dead code.  Upstream is a one-man show with very little
> interest in expanding the project.  I'd be perfectly happy using a
> system-installed TNT, but again it is just a bunch of headers and our
> patches have been trivial build portability changes (not logic).

This is a diff between versions (brlcad first, upstream beta 3.0.12 second):
http://devel.adenu.ia.uned.es/~mafm/brlcad-tnt.diff

Apart from adding std:: to min(), max() and pow(), there are whitespace 
changes but some other changes seem bugfixes:

-       if ((i0 > 0) && (i1 < n_) || (i0 <= i1))
+       if ((i0 >= 0) && (i1 < n_) || (i0 <= i1))

-            A[i] += B[i];
+            A[i] -= B[i];


Also, you use Jama C++ version, which is also already present in Debian 
repositories.

Will you then accept if I manage to get the current maintainer of those 
packages in Debian to include the std:: stuff, and use then the system's TNT 
and Jama to compile BRL-CAD with?

> > - executable-not-elf-or-script: this often means that the file is
> > executable when there is no need to. In the case of Tcl scripts,
> > probably is missing the header because they are included in other
> > files. But in this case they don't need to be executable at all.
> > Solution: chmod -x them.
> 
> Case-by-case basis.  Most of the scripts in the tclscripts directory
> could have the executable bit removed except for ami.tcl and the
> ampi.tcl scripts.  The "cleanup" is probably to rename them to .sh
> instead  (though that will likely make them turn up under the next
> warning)

I could do that if I knew how to not mess things up.  I don't know much 
about Tcl, and in particular have no idea about why they are hybrids between 
sh and tcl when they only use shell to tell that they are not shell scripts.  
Same with most of the other warnings that I don't comment about.

> > - manpage-has-errors-from-man / manpage-has-bad-whatis-entry: it would
> > be nice to fix them, most of them is probably due to symbols which
> > should ideally be escaped.
> 
> All fixable.

I tried to fix at least some, but I don't have any idea about man pages (and 
much less them being produced from docbook) and I didn't succeed with the 
fixes that I tried to produce.

> > - manpage-section-mismatch / manpage-in-wrong-directory: fix section in
> > the man page itself (curiously enough, bzflag is the only package in
> > the archive which currently has this problem :D ):
> > http://lintian.debian.org/tags/manpage-in-wrong-directory.html
> 
> Where does Tcl install their command API headers on Debian?  They are
> usually also man 'n' pages.  BZFlag's error seems genuine -- a man5
> installed into a man6 directory.  Their warning on our files is that
> they're not in a [1-9] directory, but instead an 'n' page.

Debian follows Filesystem Hierarchy Standards, which only names 1-8 sections 
and nothing at all about n (don't know why):
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES

Gentoo does mention them, I don't know where they they got the info from:
http://www.gentoo.org/doc/en/man-guide.xml
"- mann   This section is mainly used by Tcl/Tk. The n stands for new."

Man page HowTo:
http://www.schweikhardt.net/man_page_howto.html
"- n    (Deprecated) New documentation, that may be moved to a more 
appropriate section.
- o    (Deprecated) Old documentation, that may be kept for a grace period.
- l    (Deprecated) Local documentation referring to this particular system.

Please do not use the n, o and l sections; according to the File System 
Standard these sections are deprecated. Stick to the numeric sections."

So I don't know how important is for you to maintain it in "mann".  If you 
want to maintain it, I can easily move them to man3, for example.


Cheers.
-- 
Manuel A. Fernandez Montecelo <man...@gm...>