Apply formatting changes to the existing ChangeLogs for the 1.0.27 and
1.0.28 releases. (This includes re-ordering some entries so that merge
requests always appear together.) Manual formatting changes to entries
in these ChangeLogs have been preserved.
Add missing ChangeLogs for later releases.
This means that commits from the same merge request will always appear
together in the ChangeLog, instead of appearing shuffled together with
other commits that were authored around the same time.
Use 12-digit short hashes (which appear in merge commits). The number
of digits required to unambiguously identify a commit increases as the
Git repository grows. The ChangeLog for the 1.0.27 release has 7-digit
short hashes, which are no longer meaningful: 9 digits are needed now.
Forcing 12 digits to display here is the solution in the Linux kernel.
Do not "decorate" the log with branch or tag names. It is understood
that each file starts at a specific release tag (e.g. 1.0.27) and ends
at the next tag (1.0.28), or at HEAD for development snapshots. Topic
branch names, or the refs "master" and "HEAD", do not need labeling.
The output of "net-snmp-config --cflags" can contain optimization flags.
These might not be applicable to the current compiler, causing warnings.
Use PKG_CHECK_MODULES to check for Net-SNMP and obtain the compiler and
linker flags instead, in the same way as for libcurl or poppler-glib.
Ensure these files are updated after pixma/pixma.c is changed. Do not
remove them during "make clean" or "make distclean", because they are
part of the source distribution (generated with "make dist"). Display
the relative paths in the build output.
Some of the status code checks also check that the returned data is
of the expected size. However, if they are not, it is possible to
return SANE_STATUS_GOOD in error. We should generate an appropriate
error code other than SANE_STATUS_GOOD for this case.
Building with --enable-silent-rules makes it easier to identify errors
or warnings in the build output. Automake provides macros for custom
rules to use, so that they will print a similar message to rules which
run the compiler or linker:
...
CC libpieusb_la-pieusb.lo
CCLD libpieusb.la
CCLD libsane-pieusb.la
CC libsane_pixma_la-pixma-s.lo
GEN pixma/pixma_sane_options.h
GEN pixma/pixma_sane_options.c
CC pixma/libpixma_la-pixma.lo
...
This does not change the current output if silent rules are disabled.
The current warnings do not explain to the administrator what risks may
actually be involved by exposing saned to the network, so that they can
take the appropriate measures.
Currently the administrator is advised to restrict incoming connections
to saned (using tcpwrappers and/or firewall rules). This might not have
been the typical posture when this was written. More importantly, these
actions are not meant to protect against a loss of confidentiality, and
the administrator should not be led to believe this is the case.
Suggest the use of a secure tunnel between each client and saned, which
can be achieved without modifying the software.
The saned(8) man page should be used to describe the behavior of saned
itself. The information about configuring inetd, xinetd, or systemd to
launch saned - while it is helpful - belongs in a separate location.
Keep in mind that distribution packages usually configure the service
automatically, and they may ship with their own specific instructions.
(For example, update-inetd can be used in Debian and its derivatives.)
This change moves this information from the man page into a new file,
making it more concise as well. Working examples are moved to separate
files that can be copied directly from the source tree to the system.
David Ward