[nas] Re: Silly versioning conflicts

[Steve McIntyre]

On Sun, Dec 10, 2000 at 02:53:55PM -0700, Jon Trulson wrote:
>On Sun, 10 Dec 2000, Steve McIntyre wrote:
>> 
>> It's a good question. Is the API of the library likely to change in
>> any major fashion without the protocol changing? I'd guess it might,
>> so the two should probably be separated. My main concern is that the
>> major version of the library just went _backwards_, even though (I
>> hope) the new library should be binary-compatible with the old.
>> 
>
>	The library API is extremely unlikely to change in an
>incompatible way.  All of the changes I've incorporated or provided for
>libaudio have always been fixes to the build or to correct bugs.  The
>current 1.4 library, API-wise, is completely binary compatible to anything
>written for 1.2*.

OK, that's what I'd expect.

>	The protocol version (2.2) itself has never been changed to my
>knowlege since the 1.2 release.

Ditto.

>> What might be nice is a new release number - jump from 1.4.1 to
>> 2.0. Then we can unify the library version number with the NAS version
>> again...
>
>	;-) Yeah, but then all those nice packages built with 1.x shared
>objects over the last year or so will break hehe.

True. It's exactly that reason why I want to change to 2.x now - to
stop the Debian packaged stuff breaking.

>	Perhaps it is time to sync the release version and libaudio to
>2.0, with the understanding that the libaudio and server protocol
>revisions are likely to diverge after that...
>
>	Thoughts anyone?

Works for me...

>> I've got Erik Inge Bolso's patch for 2 channels (not 3!) applied, and
>	
>	I've got that too, and some additional OS support.
>
>> I'm basically happy now to make a package and release it. I've had to
>> put a couple of minor things back in from the previous package, but
>> nothing major. It's all stuff that should apply cleanly on top of any
>> other changes you have...

The two things I put back for my build are both things that were
highlighted to me through reported Debian bugs:

1. The nas sockets dirrectory should be made sticky to prevent
   possible security problems.

--- nas-1.2p5.orig/server/os/connection.c
+++ nas-1.2p5/server/os/connection.c
@@ -506,8 +506,11 @@
     unsock.sun_family = AF_UNIX;
     oldUmask = umask (0);
 #ifdef X_UNIX_DIR
+#ifndef S_ISVTX
+#define S_ISVTX   01000
+#endif
     if (!mkdir (X_UNIX_DIR, 0777))
-       chmod (X_UNIX_DIR, 0777);
+       chmod (X_UNIX_DIR, 0777|S_ISVTX);
 #endif
     strcpy (unsock.sun_path, X_UNIX_PATH);
     strcat (unsock.sun_path, display);

2. The Debian nas package starts auvoxware automatically at boot,
   essentially as a daemon. It can also be restarted later using
   /etc/init.d/nas. In this second case I had a bug reported where
   this then kept the controlling terminal open. I therefore need to
   close all the std{in,out,err} file descriptors to avoid this.

--- nas-1.2p5.orig/server/dia/main.c
+++ nas-1.2p5/server/dia/main.c
@@ -94,6 +94,17 @@
     display = "0";
     ProcessCommandLine(argc, argv);
 
+    /* We're running as a daemon, so close stdin, stdout and stderr
+       before we start the main loop */
+    close(0);
+    close(1);
+    close(2);


>	The main 'serious' fix I have is in audio/soundlib.c - it corrects
>a problem whereby clients would hang if the element Import size matched
>the internally computed buffer size of a flow.  If you've ever had certain
>sized audio files hang auplay, then you might want this.

That sounds likely, yes. :-)

>	I will put together a development release (1.4.1a) that contains
>these and other fixes.  I'll wait on the versioning issue until we know
>what we should do. ;-)

Cheers.
-- 
Steve McIntyre, Cambridge, UK.                   stevem at chiark.greenend.org.uk
Use Debian GNU/Linux - upgrade your Windoze box today!  http://www.debian.org/
"Can't keep my eyes from the circling sky,                 +------------------
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  |Finger for PGP key