gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] [PATCH] Rename readme.txt for consistency to README.PACKAGERS


From: Sanjeev Gupta
Subject: [gpsd-dev] [PATCH] Rename readme.txt for consistency to README.PACKAGERS
Date: Thu, 19 Mar 2015 13:27:15 +0800

---
 packaging/README.PACKAGERS | 34 ++++++++++++++++++++++++++++++++++
 packaging/readme.txt       | 34 ----------------------------------
 2 files changed, 34 insertions(+), 34 deletions(-)
 create mode 100644 packaging/README.PACKAGERS
 delete mode 100644 packaging/readme.txt

diff --git a/packaging/README.PACKAGERS b/packaging/README.PACKAGERS
new file mode 100644
index 0000000..1fa13e2
--- /dev/null
+++ b/packaging/README.PACKAGERS
@@ -0,0 +1,34 @@
+= Recommendations for distribution integrators =
+
+The X11 subdirectory contains icons and a project logo for use
+in desktop packaging.
+
+Usable deb and RPM specifications have their own subdirectories here.
+Our package files want to set up a hotplug script to notify gpsd
+when a potential GPS device goes active and should be polled.  The
+goal is zero configuration; users should *never* have to tell gpsd how
+to set itself up.
+
+Bluetooth has a requirement to be able to write to the gpsd control
+socket from a userland device manager.  Accordingly, you probably 
+want to set up a gpsd privilege group and make sure the Bluetooth
+device manager is in it.
+
+To avoid problems with gpsd not starting up properly when devices are
+hotplugged, make sure the installed gpsd will have read and write
+permissions on all serial devices that a GPS might be connected to (on
+Linux, this means at least /dev/ttyS*, /dev/ttyUSB*, and
+/dev/ttyACM*).
+
+The gpsd daemon needs to be started as root for best performance (it
+wants to nice itself, and needs root access to kernel PPS devices).
+But very soon after startup it drops privileges.  gpsd normally
+figures out which group it should move to by looking at the ownership
+of a prototypical tty (look in gpsd.c for this code) but the owning
+user and group can be compiled in with build-system options.
+
+Make *sure* whatever group gpsd lands in after privilege-dropping has
+dialout access - otherwise your users will see mysterious failures
+which they will wrongly attribute to GPSD itself.
+
+// end
diff --git a/packaging/readme.txt b/packaging/readme.txt
deleted file mode 100644
index 1fa13e2..0000000
--- a/packaging/readme.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-= Recommendations for distribution integrators =
-
-The X11 subdirectory contains icons and a project logo for use
-in desktop packaging.
-
-Usable deb and RPM specifications have their own subdirectories here.
-Our package files want to set up a hotplug script to notify gpsd
-when a potential GPS device goes active and should be polled.  The
-goal is zero configuration; users should *never* have to tell gpsd how
-to set itself up.
-
-Bluetooth has a requirement to be able to write to the gpsd control
-socket from a userland device manager.  Accordingly, you probably 
-want to set up a gpsd privilege group and make sure the Bluetooth
-device manager is in it.
-
-To avoid problems with gpsd not starting up properly when devices are
-hotplugged, make sure the installed gpsd will have read and write
-permissions on all serial devices that a GPS might be connected to (on
-Linux, this means at least /dev/ttyS*, /dev/ttyUSB*, and
-/dev/ttyACM*).
-
-The gpsd daemon needs to be started as root for best performance (it
-wants to nice itself, and needs root access to kernel PPS devices).
-But very soon after startup it drops privileges.  gpsd normally
-figures out which group it should move to by looking at the ownership
-of a prototypical tty (look in gpsd.c for this code) but the owning
-user and group can be compiled in with build-system options.
-
-Make *sure* whatever group gpsd lands in after privilege-dropping has
-dialout access - otherwise your users will see mysterious failures
-which they will wrongly attribute to GPSD itself.
-
-// end
-- 
2.1.4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]