Apparent "permissions" issue with /dev/cuau0?

This seems a bit weird to me.  I'll explain the context, then the
perceived issue.

I maintain a port (astro/gpsman) which can make use of a serial port to
communicate with a GPS.

The author of the program let me know earlier today that he had made a
tarball of GPSman-6/4 available.  Accordingly, I started updating the
port to use the new version.

While I was doing that, I noticed that there's a stanza in the port's
Makefile:

.if ${OSVERSION} < 600000
GPSMAN_DEFAULT_PORT?=   /dev/cuaa0
.else
GPSMAN_DEFAULT_PORT?=   /dev/cuad0
.endif

and I recalled that the MPSAFE TTY layer was recently committed to HEAD,
and that the serial device names changed accordingly.  Thus, while it
isn't actually essential (as the user can change the device name fairlly
readily), I thought it would be reasonable to adjust that stanza so that
folks installing GPSman on a recent CURRENT system would at least have a
default value that matched something on their system.

Accordingly, I changed my working copy to read:

.if ${OSVERSION} < 600000
GPSMAN_DEFAULT_PORT?=   /dev/cuaa0
.elif ${OSVERSION} < 800045
GPSMAN_DEFAULT_PORT?=   /dev/cuad0
.else
GPSMAN_DEFAULT_PORT?=   /dev/cuau0
.endif

I then rebooted my laptop from the CURRENT slice and tried installing
the (updated) port.

The install was clean (as expected).  I found that I needed to move my
old ~/.gpsman directory aside; on invocation, gpsman offered to create
~/.gpsman-dir (where it stashes various preferences).  I was mildly
pleased to see that the default for the serial port showed up as
/dev/cuau0 (as desired).

I turned on my GPS, plugged it in, tried getting gpsman to talk to it,
and got a complaint: GPSman said that I didn't have permission (I
*think* that was its whine, anyway).  I looked; the device was:

crw-rw----  1 uucp  dialer    0,  51 Oct 28 20:23 /dev/cuau0

and output of id(1) verified that I was in group "dialer" (specifically
so I could do this type of thing), as expected.


I then de-installed gpsman, rebooted the laptop to RELENG_6 (also built
this morning), reinstalled GPSman, tried the "tallk tothe GPS"
experiment again, and it worked just as it always had before -- no
problems (using the "Garmin" protocol, if that matters).

So: the hardware works.  The physical connection should be OK.  It seems
to me that either there's Something Weird going on with access to
things in a file namespace in CURRENT (which isn't all that likely, as
it would probably have an adverrse effect on tracking CURRENT daily --
and others would likely have been ... mentioning ... it) or GPSman is
trying to do something to the serial port in a way that is no longer
supported in CURRENT.

Now, GPSman is a Tcl/Tk application.  And as I'm not really sufficiently
ambitious as to keep a separate set of installed ports ofr each of
RELENG_6, RELENG_7, and HEAD, I set things up so that /usr/local is
mounted from the same place regardless of which slice I boot from.  I
then maintain the ports while running RELENG_6 -- and on the other
slices, I have the misc/compat6x port installed.

While there are a few "gotchas" occasionally (RELENG_6 firefox isn't
happy with CURRENT's threading model, though I could probably address
that via /etc/libmap.conf), the vast mojority of stuff I use Just Works.

FWIW, the version of the misc/compat6x port installed is
compat6x-i386-6.4.604000.200810.

I'm disinclined to believe that this is an issue with the 6.4 release of
GPSman; as ssuch, I expect to send out the PR to update the port
shortly.  But it would be nicer if the software could be used under
FreeBSD CURRENT.  :-}

I suppose I could try using ktrace(1) to get a better idea what's going
on.  Any other (better?) ideas?

Thanks!

Peace,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.