Radiance in Debian!

radiance-general
1

Hi list,

I'm happy to announce that Radiance was accepted in Debian's unstable on
Thursday, it'll be shipped with the next release which is called Lenny.

My thanks go to Gregory J. Ward for replying to all my emails and taking
care of all problems I run into.

At the moment Debian's version is '3R8+20070924.dfsg' - which mainly
means it is the CVS HEAD from 2007-09-24. Unfortunately I had to remove
some pdf files which are in the Radiance distribution without sources,
therefore the .dfsg was added to the version - but I'm sure Gregory and
me will find a way around that, too.

The following packages are shipped in Debian:

* radiance - containing the binaries and manpages
* radiance-doc - containing all other documentation and the examples
* radiance-materials - all material files
* radiance-sse3 - SSE3 optimized versions of the renderers, this package
is only available on i386, the amd64 binaries are automatically
optimized for SSE4 (if I remember right, man gcc tells more ;))

The overview in the package tracing system can be found at [1].

/usr/share/radiace/doc/README.Debian provides additional details, it can
also be read online at [2]

If the pacakges are not available on your favourite platform yet,
they're probably just not built yet - some buildds seem to lag a bit
behind - [3]. Please try again later :slight_smile:

I'd be happy about any kind of feedback, especially before Lenny will be
released - which will take some more months for sure, but as soon as it
is released, there's no way to fix minor bugs anymore.

Also - if there's any interest - I'll make sure there will be backports
for Etch available as soon as the package migrates from unstable to testing.

If there's any interest I can also build and provide a Debian live cd
with radiance pre-installed.

For developers are probably the build logs interesting - they're
provided at [4]. Patches I've added to build under Debian are listed at
[5]. Mainly they remove the shipped libtiff in favor for Debian's
libtiff and fix several implicit declarations, which are known to result
in problems on several of Debian's architectures.

Feel free to ask if you have any questions regarding the packages or Debian.

Best regards,

Bernd Zeimetz

[1]:
http://packages.debian.org/search?keywords=radiance&searchon=names&suite=unstable&section=all
[2]:
http://svn.recluse.de/filedetails.php?repname=debian&path=%2Ftrunk%2Fpackages%2Fradiance%2Fdebian%2FREADME.Debian&rev=0&sc=0
[3]:
http://people.debian.org/~igloo/status.php?packages=radiance
[4]: http://buildd.debian.org/build.php?pkg=radiance
[5]:
http://svn.recluse.de/listing.php?repname=debian&path=%2Ftrunk%2Fpackages%2Fradiance%2Fdebian%2Fpatches%2F&rev=0&sc=0

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

2

Hi Bernd,

That's fantastic news!
Thanks for all your efforts, installation of Radiance on GNU/Linux
now is as easy as it can be :slight_smile:

Ciao,

Francesco

3

Hi Bernd,

I've read your post to radiance-general, and am just installing a
Debian-unstable in Qemu to give you some more feedback. This has been
taking forever--my box isn't particularly fast, and is in dire need of
some upgrading. Will get back to you...

I have a few thoughts that I'd like to share with you, irrespective of
the actual install. Please don't take them as rants, and feel free to
completely ignore them if you feel they're out of place. I seem to
have a talent of always striking the wrong string with people...

Before I go on, let me mention that I have not actually packaged debs
myself, but I did roll some Radiance RPMs many years ago, and know how
you must have been suffering from the non-standard build/install of
Radiance. I could never release my RPMs, since this was years before
Radiance went OS, and my explicit request with LBL got turned down.

a) I've been browsing the Debian pages for the best part of an hour
now, but just can't find the relevant page. I might be completely
wrong (this could well have come from the Fedora packaging
guidelines), but something tells me that auxiliary data (such as the
*-materials.deb) should actually go into *-data.deb. This is more
general, e.g. some of the .cal files that you have in there could be
for, let's say some fancy rtrace projection, rather than a parametric
material definition. I believe the general idea behind the *-data is
that it is not required to run the software--many games have extra
characters/cars/worlds in *-data.

b) Have you checked with debian-legal yet whether the Radiance license
is ok for inclusion of the package in Debian proper, rather than
non-free? I've been studying the DFSG and Software License FAQ
(http://people.debian.org/~bap/dfsg-faq.html), and ended up having
lots of scribble (=doubts) on my print-out.

The Radiance license is not OSI approved, this is what the FAQ has
this to say about self-made licenses:

"But it is our strong and heartfelt advice that using a tried-and-true
license is best for almost all purposes. Even large corporations with
dozens of lawyers on staff itching to write their own license have
found this out the hard way, as in the Mozilla license saga, or the
Djvu license story, or the trouble Trolltech had with the Qt license."

The point most relevant (and potentially hindering) seems to be this one:

"# Q: Are clickwrap licenses okay? (Meaning licenses require anyone
receiving the software to click on an I AGREE button indicating ascent
to the terms.)

"A: No, not unless the clickwrap stuff can be removed. Even aside from
freeness, as a practical matter such a clickwrap requirement would be
an unreasonable burden upon our users.

"To be technical, in principle one could put the GPL in a clickwrap
and the license would be perfectly fine. But once you add a
requirement that the software must be distributed via the clickwrap,
or that clickwrap code cannot be removed from the software, your
license becomes non-free. Since clickwraps without such a requirement
are a bit pointless, clickwrap licenses are almost always non-free."

I understand that technically there would be no problem with throwing
up an 'agree/decline' window upon install, but I think this would be
not be solving the problem.

What I do not know is whether this click-wrap is merely an artifact
from the days when Radiance was non-free (in which case we might be
able to lobby LBL as the copyright holder to get it removed), or if it
has been left in there for a purpose.

If you haven't done any legal checkup yet, I'd be more than happy to
offer my help.

c) This, again, is too long ago to remember: There used to be a
Radiance RPM in Turbolinux, and I'm fairly convinced that a Debian
package also existed. One of them actually packaged it into
radiance-nox11 and radiance-x11. The idea was that to use Radiance in
render farm, all the extra X11 requirements would not have to be
installed. I'm not suggesting that you follow this approach, but do
give it a thought.

d) Your communication with Greg happened off-list. I feel that many
Radiance developers (and users, too) would be very interested in
reading though the thread. BTW, this is also the reason why I'm
posting this to radiance-devel, rather than just to you personally. I
strongly believe that the Radiance development process should be as
transparent as possible. Anyhow -- is there any chance of you making
this conversation available to the rest of us (with Greg's permission,
of course)? I am particularly interested in what Greg has to say about
libtiff. It seems you linked to the system one, not the one which
comes with Radiance. Does that mean that the official one can be
trusted now?

e) There's more in the pipeline, but let me get my hands dirty first.

So much for now

Take care

Axel

4

Hi Axel,

I have a few thoughts that I'd like to share with you, irrespective of
the actual install. Please don't take them as rants, and feel free to
completely ignore them if you feel they're out of place. I seem to
have a talent of always striking the wrong string with people...

any comments are welcome!

a) I've been browsing the Debian pages for the best part of an hour
now, but just can't find the relevant page. I might be completely
wrong (this could well have come from the Fedora packaging
guidelines), but something tells me that auxiliary data (such as the
*-materials.deb) should actually go into *-data.deb. This is more

I've called it -materials now, I doubt that makes a big difference. I
don't know any policy about packages having to use -data. I think most
of the stuff are material definitions in the package, so I think it's fine.
I don't want to split them again, Debian's ftp masters like to start to
grumble if a package builds too many small packages.

If you're facing such questions - the Debian policy is what you want to
read: http://www.debian.org/doc/debian-policy/ch-binary.html#s3.1

b) Have you checked with debian-legal yet whether the Radiance license
is ok for inclusion of the package in Debian proper, rather than

radiance is NOT in non-free. It is in Debian/main.
Actually the license is a bit weird, it's similar to the php license
with some name changes, but it's fine for main.
You're probably thinking abut the .dfsg. in the version number - it just
means I had to remove two pdf files which are shipped without source.
Seems the source of one of them is lost, and Greg will ship the other
files's source with 3R9, or they're removed both by him. THen the .dfsg.
is gone, too. Nothing that stops a package from going into main, though.

c) This, again, is too long ago to remember: There used to be a
Radiance RPM in Turbolinux, and I'm fairly convinced that a Debian
package also existed.

If I remember right Lars build those packages. I know they exist, but
usually it is faster for me to repackage things from ground of then
trying to understand what other people did and doing things based on that.

One of them actually packaged it into
radiance-nox11 and radiance-x11. The idea was that to use Radiance in
render farm, all the extra X11 requirements would not have to be
installed. I'm not suggesting that you follow this approach, but do
give it a thought.

I gave it a thought, too, but discarded that for now as the dependency
to x11 only brings a few hundred k of extra libraries. I doubt that's
worth the work. You don;t need to install X completely on Debian...

d) Your communication with Greg happened off-list. I feel that many
Radiance developers (and users, too) would be very interested in
reading though the thread. BTW, this is also the reason why I'm
posting this to radiance-devel, rather than just to you personally. I
strongly believe that the Radiance development process should be as
transparent as possible. Anyhow -- is there any chance of you making
this conversation available to the rest of us (with Greg's permission,
of course)? I am particularly interested in what Greg has to say about
libtiff. It seems you linked to the system one, not the one which
comes with Radiance. Does that mean that the official one can be
trusted now?

I doubt it is worth to read trough the whole thread. But if it's ok for
Greg I'll create a summary of the interesting parts of it.

About libtiff: if I remember it right (without reading trough the 30
mails again), the reason why there's one shipped in radiance is that the
libtiff in BSD was broken, or so. Anyway I have no other chance then
using Debian's libtiff, I'd get slapped by the ftp masters if I'd try to
add the source of an old version of libtiff to Debian - it's a waste of
space and another thing you need to patch if there's a security hole in
libtiff.

Cheers,

Bernd

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

5

any comments are welcome!

--^ is there a difference between all and any here? This confuses me too
often.
Every comment is welcome of course.

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

6

f) If you compile with SPECIAL="ogl", you'll get OpenGL drivers for
the holodeck stuff. This makes it much faster and nicer. There will be
additional device files. Here are mine:

glx1.hdi ogl.hdi oglo.hdi ogls.hdi oglso.hdi x11.hdi
glx1h.hdi oglh.hdi ogloh.hdi oglsh.hdi oglsoh.hdi x11h.hdi

Downside would be the additional dependency on the Mesa libs.

b) (again). I did not mean to suggest that Radiance is not Free. What
I simply do not know is whether it's Free Enough to be included in
Debian proper. It certainly is free enough for me.

I already pointed out the potential click-wrap problem, which you
simply patched away.

If the click-wrap is there for no reason at all, then a better
solution would be to get it removed up-stream. Since I don't know what
Greg has to say about this, I shall make no further assumptions.
Generally speaking, however, you only need to agree if somebody takes
something away from you (e.g. your right to distribute the software,
like it was in those old days), not if somebody gives you something
for absolutely and unconditionally free.

Another interesting phrase is para 5 of the Radiance Software License:

"5. Products derived from this software may not be called "Radiance",
nor may "Radiance" appear in their name, without prior written
permission of Lawrence Berkeley National Laboratory."

No problem with me. However, what it would stop me from doing is to
create something like radiance-ng (as in next-generation), or
radiance-nt (as in new technology) or nu-radiance (as in new).

You will be aware that there is syslog and syslog-ng, both GPLd, I
believe, so this kind of naming is not unheard of.

The question is whether this teeny weeny restriction of my freedom to
name a derived package anything-radiance or radiance-anything is
enough for the very strict rules of the DSC to render it non-free.
Probably not, but I thought I'd throw in my 2 Escudos, anyhow.

I trust that you as a seasoned Debian developer with >30 packages
under your belt know all the ins and outs of all sorts licenses and
Social Contracts, so having your assurance that Radiance is
Free-as-in-Debian will make me sleep comfortably at night.

Thanks for your time

Axel

7

Axel Jacobs wrote:

f) If you compile with SPECIAL="ogl", you'll get OpenGL drivers for
the holodeck stuff. This makes it much faster and nicer. There will be
additional device files. Here are mine:

broken on linux, at least with the current xorg. It builds, but the
output is distorted. Probably this depends on the graphic hardware,
though. Something to look a bit deeper into.

b) (again). I did not mean to suggest that Radiance is not Free. What
I simply do not know is whether it's Free Enough to be included in
Debian proper. It certainly is free enough for me.

You can be sure the license is free enough to be included in Debian,
otherwise
- it would have been rejected by the ftp masters. They take such things
_serious_.
- there wouldn't be php in Debian.

I already pointed out the potential click-wrap problem, which you
simply patched away.

The license does not require any kinds of click-wrap, it is the build
system which asks me to accept the license. As the build system is
shipped under that license I'm free to change it (I'm not using it at
all btw, much more easy to do build without the build-system).

If the click-wrap is there for no reason at all, then a better
solution would be to get it removed up-stream. Since I don't know what
Greg has to say about this, I shall make no further assumptions.

Still don;t see the problem here, as the click-wrap is not in the
license but in the build system - but it would probably make people's
life more easy if they wouldn't have to accept the license while using
that build system.

Another interesting phrase is para 5 of the Radiance Software License:

"5. Products derived from this software may not be called "Radiance",
nor may "Radiance" appear in their name, without prior written
permission of Lawrence Berkeley National Laboratory."

ugly, but ok.
http://www.debian.org/social_contract#guidelines (4)

I trust that you as a seasoned Debian developer with >30 packages

... still working on becoming an official Developer :slight_smile:

under your belt know all the ins and outs of all sorts licenses and
Social Contracts, so having your assurance that Radiance is
Free-as-in-Debian will make me sleep comfortably at night.

even if you couldn't trust me, you can trust the ftp master who checks
the packages. He reads _every_ file and would simply reject a package if
- debian/copyright (== /usr/share/doc/radiance/copyright) is not
complete or if there're any problems with a license of a single file. Or
because there're two pdfs without source included, which happened to me
- I just missed to look for their source.

Cheers,

Bernd

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

8

Hi Bernd,

You are welcome to share whatever portion you like from our e-mail exchange.

Thanks again for all your efforts!
-Greg

9

Hi,

You are welcome to share whatever portion you like from our e-mail
exchange.

ok, I think I'll compile a FAQ-like document, that's probably the best
thing to do.

Thanks again for all your efforts!

you're welcome!

Bernd

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

10

Hi,

here come the interesting parts of the mails between Greg and me (my stuff
quoted, a few additional links added):

···

------------------------------------------------------------------------------

The source distribution contains an older version of libtiff, was this
version modified to suit the needs of radiance, or is it replaceable by the
libtiff which is shipped by Debian?

It probably works with the new version. My problem was getting the newer
version to compile on Macs and FreeBSD was proving problematic, and I didn't
need any of its features so I was lazy and just fell back to one that worked.

------------------------------------------------------------------------------

Where's the difference in the build process between using 'makeall' and the
SConstruct file with scons? Except that building fails when it is done by
scons:
gcc -o bin/rhpict src/hd/rhpict.o src/hd/rhpict2.o src/rt/Version.o
src/hd/holofile.o src/hd/holo.o src/hd/viewbeams.o -Lsrc/lib -lrtpic
-lrtio -lrtproc -lrtargs -lrtmath -lrtmem -lrterror -lm
src/lib/librtargs.a(badarg.o): In function `badarg':
badarg.c:(.text+0x63): undefined reference to `isfltd'
badarg.c:(.text+0x98): undefined reference to `isintd'
collect2: ld returned 1 exit status
scons: *** [bin/rhpict] Error 1
scons: building terminated because of errors. </code>

Georg Mischler <schorsch@schorsch.com> is responsible for the SCONS build
system, which is there to make compiling under Windows less painful. I don't
know what its status is, and Schorsch has been pretty difficult to raise these
days.

------------------------------------------------------------------------------

If I'd provide a package with optimized binaries for i386/sse3, which programs
would you recommend to build in an optimized version?

Definitely the renderers, "rpict," "rtrace," and "rvu" built in src/rt. After
that, maybe some of the libraries in src/common, especially the cal*.c routines.
I'd have to think about it after that....

------------------------------------------------------------------------------

- There're some manpages missing:

W: radiance: binary-without-manpage usr/bin/debugcal
W: radiance: binary-without-manpage usr/bin/genambpos
W: radiance: binary-without-manpage usr/bin/genrhgrid
W: radiance: binary-without-manpage usr/bin/glaze
W: radiance: binary-without-manpage usr/bin/mgf2inv
W: radiance: binary-without-manpage usr/bin/mgfilt
W: radiance: binary-without-manpage usr/bin/nff2rad
W: radiance: binary-without-manpage usr/bin/objpict
W: radiance: binary-without-manpage usr/bin/optics2rad
W: radiance: binary-without-manpage usr/bin/pcwarp
W: radiance: binary-without-manpage usr/bin/pdelta
W: radiance: binary-without-manpage usr/bin/pgblur
W: radiance: binary-without-manpage usr/bin/plot4
W: radiance: binary-without-manpage usr/bin/ra_hexbit
W: radiance: binary-without-manpage usr/bin/ra_pfm
W: radiance: binary-without-manpage usr/bin/rlux
W: radiance: binary-without-manpage usr/bin/rview
W: radiance: binary-without-manpage usr/bin/vinfo
W: radiance: binary-without-manpage usr/bin/xyzimage

do you know if there're any manpages for those tools hidden somewhere, or if
somebody else is working on them? If not I'll go and write minimal manpages
for them.

I never wrote man pages for these, as they are specialty programs used by
experts, for the most part. Some aren't used at all, and probably shouldn't be
compiled (like pcwarp and plot4). No one else has written man pages for
anything, as far as I know. You are welcome to give it a go if you have time,
but I don't even have time at the moment to go through them, really.

https://ssl.recluse.de/svn/debian/trunk/packages/radiance/debian/radiance-experttools.sgml

------------------------------------------------------------------------------

there're some wish scripts in src/utils which were written for wish3.6, but
8.4 or so is the actual version - are there any issues I could run into while
shipping them?

I don't think the trad code works anymore, and I haven't had time to update it.
I imagine it would take some effort -- a day or two or three.

(trad is not included in Debian therefore)

------------------------------------------------------------------------------

Could you provide me with a list of tools which shouldn't be
compiled/distributed at all? For all others I'll write minimal manpages
as long as they have some useful output with --help, for all others I'll
write some default manpage.

Actually, we did a build clean-up a while ago and pulled out all the completely
useless programs. The plot4 program actually serves a purpose, which I only
remembered after I sent the e-mail. The pcwarp program is more experimental,
and should probably be pulled.

------------------------------------------------------------------------------

Do you have any font converters,
or was the conversion of helvetica and verdana done manually?

As I recall, Paul Haeberli had a really simple polygonal font format, similar to
my own, and it was a snap to convert. If you have something that already parses
the foreign format, and it's not difficult to add a new output format, the one I
use is quite simple. It's described in:
http://radsite.lbl.gov/radiance/refer/filefmts.pdf

------------------------------------------------------------------------------

in my opinion you want to add

https://ssl.recluse.de/svn/debian/trunk/packages/radiance/debian/patches/rholo-missing-devpath-fix.dpatch

to the next version of radiance to make sure rholo finds its dev files even
when they're not living in a default directory. I'm not 100% sure what happens
if DEVDIR is not set, though, but I guess it will just take the default.

If the DEVDIR is not set, and it usually isn't, rholo searches for its device
drivers in subdirectories named dev/ in each of the executable PATH locations.
In other words, installing the drivers in dev/ under the Radiance executable
directory should always work. I put DEVDIR in there as a precaution for strange
systems that might cause a collision. It's never happened.

according to the FHS such files have to go to /usr/lib, therefore I have to
change those paths. Btw, would it make sense to include rholo in the package
with the sse3 optimized binaries? It seems to be kinda cpu intensive, if I
understand the manpage right. Do you probably have some small example I could
use to test rholo? Unfortunately nobody here ever used it.

The files you're putting in /usr/lib are executables if that makes any
difference -- did you mean /usr/local/lib? It seems odd to install things in
the main system directory. I wouldn't want them there if I were a user
installing a third-party package.

Rholo calls rtrace to do most of the CPU-intensive work, but you can compile it
however you think best.

To test, go to the ray/obj/cabin directory and trun "make nholo." You might
also alter the nholo target to set -n 2 to make sure multi-processing is working
right, and "-o x11" rather than "-o ogl" to try out the quadtree driver.

The ogl driver just produces random weird pixels in linux - but x11 works
fine.
I have another question for you:
Does it make a difference if I build radiance with -ffast-math?
According to the gcc manpage this makes only a difference for programs
which depend on an exact implementation of IEEE or ISO
rules/specifications for math functions. Is this the case for radiance?

I'm sorry but not surprised to hear the OGL driver doesn't work under Linux.
They seem to have a pretty loose idea of this standard. It works under Mac OS
X, but then, that's where I'm able to test and debug it.

As for -ffast-math, there shouldn't be a problem for Radiance. It doesn't rely
on exact trig calculations or the like.

------------------------------------------------------------------------------

The only problem I run into now is that rview is a link to vim these
days, and something I can't overwrite or reuse. Is it a problem if I
remove the rview link, or do I have to patch anything?

The rview program was renamed to rvu just to avoid the conflict with vim. I put
a soft link in for backwards-compatibility, but you can safely remove it if it
causes problems.
https://ssl.recluse.de/svn/debian/trunk/packages/radiance/debian/patches/no-rview-please.dpatch

------------------------------------------------------------------------------

And last but not least:

bzed@hal:~$ wget -q -O - http://www.radiance-online.org/main.html |
grep hemp
<a href="hemp://radsite.lbl.gov" target="_top">LBNL</a>, <a
href="hemp://www.epfl.ch" target="_top">EPFL</a>, then

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>

11

there're some wish scripts in src/utils which were written for wish3.6, but
8.4 or so is the actual version - are there any issues I could run into while
shipping them?

I don't think the trad code works anymore, and I haven't had time to update it.
I imagine it would take some effort -- a day or two or three.

(trad is not included in Debian therefore)

I use trad all the time. Still works flawlessly without hacking in:
- F7
- the latest LEARNIX, which is based on KNOPPIX 5.0.1, which is based
on Debian unstable from about one year ago.

Would be a shame not to include it. Why don't you just give it a try...

Axel

12

Would be a shame not to include it. Why don't you just give it a try...

I gave it a try and it failed. Gave it another try today and it worked. Probably
it was just too late in the night when I tried it the last time.... Will be
included in the next revision/version of the package. Thanks for the hint.

···

--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>