FS#68062 - [sane] configure options corrections, minor improvements
Attached to Project:
Arch Linux
Opened by Siegfried Metz (NiceGuy) - Wednesday, 30 September 2020, 23:30 GMT
Last edited by David Runge (dvzrv) - Sunday, 21 February 2021, 14:17 GMT
Opened by Siegfried Metz (NiceGuy) - Wednesday, 30 September 2020, 23:30 GMT
Last edited by David Runge (dvzrv) - Sunday, 21 February 2021, 14:17 GMT
|
Details
Description:
sane-1.0.31: configure: WARNING: unrecognized options: --with-docdir, --enable-avahi, --enable-libusb_1_0 *) sane since version 1.0.27 changed configure option for usb support to --with-usb instead of the one we use in our PKGBUILD "--enable-libusb_1_0". I waited to report it because there used to be bugs with the changed configure option --with-usb, which got sorted out a few releases later. Now, for sane-1.0.31 --with-usb is the only configure option to use going forward. Upstream release notes for 1.0.27 regarding changed configure usb option [1]: "Note 2: On all systems, the --enable-libusb* flags are now ignored. Instead, the --with-usb and --without-usb flags now control support. When neither is given, USB support will be enabled if possible and disabled otherwise. If --with-usb is requested but not possible, ./configure will fail. There is no support to prefer libusb-0.1 over libusb-1.0. When libusb-1.0 is not found, libusb-0.1 will be tried." *) Also sane-1.0.31 changed configure option for avahi - instead of --enable-avahi it has changed to --with-avahi [2]: " BUILD: * replaces the --enable-avahi option with an --with-avahi that defaults to enabling if possible. If the option is given and the required support is not available, configure will exit with an error." *) Use --docdir=/usr/share/doc/sane instead of --with-docdir=/usr/share/doc/sane. *) I also noticed that there still is the unnecessary dependency of libusbx, which is deprecated and maybe a contender for a TODO entry to get rid of for the entire Arch repos. So, please change it to just libusb. It's just a minor change, why not change it anyway when you're at it. :) Another improvement: git rid of the xinetd file and functionality. Is there any reason (downstream distributions for instance, which really want and depend on that file and xinetd functionality) in 2020 to still distribute xinetd related files? We're just a few months away from 2021 and should definitely get rid of any xinetd provided files and services, since Arch switched to systemd full time a long time ago. The last 1-2 months there appeared Bug reports about to get rid of xinetd files, directories and functionality in various other packages, so sane is just a continued effort in that regard. Package inetutils comes to my mind. BONUS: I'm a huge fan of explicitly specifying --with-systemd and a hardening "Position independent code" PIC configure option --with-pic, so only PIC objects are used. That would be awesome. :) [1]: https://gitlab.com/sane-project/backends/-/releases/RELEASE_1_0_27 [2]: https://gitlab.com/sane-project/backends/-/releases/1.0.31 Additional info: * >=sane-1.0.31 Steps to reproduce: - Compile sane-1.0.31 and notice the unrecognized configure options --with-docdir, --enable-avahi, --enable-libusb_1_0. - Change configure options to get rid of the unrecognized configure options during compilation in the build() section. - Change dependency libusbx to libusb. - Get rid of the xinetd entry in the backup array and package() install section for the xinetd file in /etc/xinetd/sane. - Bonus: --with-systemd and --with-pic 
PKGBUILD.patch
(3.4 KiB)
|
This task depends upon
Closed by David Runge (dvzrv)
Sunday, 21 February 2021, 14:17 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with sane 1.0.32-3
Sunday, 21 February 2021, 14:17 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with sane 1.0.32-3
With our sane-1.0.31-2 package just the libusbx to libusb change in the depends array has been taken care of, but the configure options have not been changed, nor has the xinetd support removed entirely.
I also added --with-systemd and --with-pic configure options explicitly.
Sorry, I didn't see them before I did my last rebuild (due to libusbx deprecation).
Please give sane 1.0.32-2 in [testing] a spin!
I'm passively following the Arch mailing lists, but not subscribed, and already knew you're pretty busy anyway with a lot of other packages / or on vacation. Fine by me.
Would it been rude if I pinged you by private mail, or is the mailing list the better place? In no way rude or demanding!
I compiled the fresh 1.0.32-2 sane package myself and I noticed a few things:
*) ChangeLogs are included from version 1.0.0 to 1.0.28 in 1 directory under /usr/share/doc/sane/ChangeLogs and we might get rid of them as they are out of date. Upstream expects to use git log mentioned in the file /usr/share/doc/sane/ChangeLog.
What's odd too: outdated *.changes files. Not sure anyone still wants those. To get the latest and last 15 changelogs, Gitlab -> Tags -> Releases.
*) I got 2 warnings by configure:
configure: WARNING: Group uucp does not exist on this system.
configure: WARNING: Locking feature will be disabled.
I don't know about uucp if that's just me and harmless or a bug in general. The second warning, I played around a little and no matter what configure option I use the locking feature is _ALWAYS_ disabled. Does the locking feature actually work? Configure text listed something like: only for a small set of backends, but we enable all of them and maybe that is a bug by sane's configure scripts.
*) Last one: there is a security warning for the configure option --enable-pnm-backend. Do we need this feature, as it claims for testing frontends?
Taken from the configure file:
-----8< snip >8-----
'AS_HELP_STRING([--enable-pnm-backend], [enable the pnm backend for testing frontends (possible security risk, see PROBLEMS file)]),'
-----8< snip >8-----
:--EDITED to explain the pnm configure backend option:--
The funny part is: if we explicitly specify --disable-pnm-backend, one would assume it's disabled accordingly, but then the pnm backend is enabled anyway. So the only way to fully disable the pnm backend is to not list any *-pnm-backend configure option. Drives one nuts to figure this out.
Either is fine!
> Besides a few permission errors and a password prompt whenever I start simple-scan, scanning works.
Hm, that doesn't sound right. Care to elaborate? :)
> ChangeLogs are included from version 1.0.0 to 1.0.28 in 1 directory under /usr/share/doc/sane/ChangeLogs and we might get rid of them as they are out of date.
That can be arranged.
> configure: WARNING: Group uucp does not exist on this system.
Hm, uucp should be created by systemd's `/usr/lib/sysusers.d/basic.conf`. if that indeed does not work, we can also disable the feature again.
> 'AS_HELP_STRING([--enable-pnm-backend], [enable the pnm backend for testing frontends (possible security risk, see PROBLEMS file)]),'
Ouf, good catch! I'll remove it. I tried to follow their gitlab-ci.yml. Seems they also enable a few testing options, that should not be included in a release.
So, basically, scanning works and you did a splendid job implementing it all, David.
*) I use the hpaio backend from the hplip package and the permission errors stemmed from colord-sane just probing for the right active usb port connection. I found it out, by using the 'sane-find-scanner' utility from the sane package itself. Instead of easy human-readable errors, one has to look in different places if it's harmless or not. For completeness:
"colord-sane[5105]: io/hpmud/musb.c 2099: Invalid usb_open: Permission denied" and
sane-find-scanner: "could not open USB device 0x1d6b/0x0002 at 002:001: Access denied (insufficient permissions)"
The 'password prompt', is invoked by simple-scan or similar tools for starting 2 avahi systemd units to find network connected scanners, which I do not make use of and my locally connected All in one scanner works by simply ignoring it. :)
I prefer to keep avahi-daemon.{servicea,socket} services disabled, but it is leading to annoying authentication attempts.
*) I also strongly suggest we keep the configure option --disable-locking, as the only backend that makes use of the feature is Plustek. Not verified or checked if this is the most used or bought one or whatever.
If this accurately still is true as explained in the README file, it also elegantly never touches the uucp group error encountered during configure.
We miss out on simultaneous access, but this should be available to all backends or most of them. As this is how I understand it.
Taken from the README file:
"--enable-locking
Means, that some backends will use a lockfile for allowing multiple
access to one scanner. This is useful, i.e. one frontend is scanning
the button status and another one will scan. The path to the lock
files is defined by --localstatedir at the configure step and is
$localstatedir/lock. The default group is uucp and can be changed
by using --with-group=newgroup. If you do not want any backend to
use a lockfile, simply use --disable-locking.
Note: The Plustek backend is currently the only backend that makes
use of this feature."
*) Question: To be able to scan with a locally connected scanner, is the scanner group still necessary? In the other open sane bug report you explained:
"Note: For the saned@.service now the separate user/group saned is used..."
That's the only thing I haven't checked out yet, remotely trying to access and scan, not connected directly.
> I prefer to keep avahi-daemon.{servicea,socket} services disabled, but it is leading to annoying authentication attempts.
Haha, yeah, seems that is true for many people. As long as it is "fixable" by running the service, all is fine I guess :)
> I also strongly suggest we keep the configure option --disable-locking
I agree!
> To be able to scan with a locally connected scanner, is the scanner group still necessary?
I believe not. At least judging from the udev rules (`rg scanner /usr/lib/udev/rules.d`) or hwdb entries (`rg scanner /usr/lib/udev/hwdb.d`).
The group is introduce by our vendor files for sysusers.d, that come with our filesystem package. I guess that entry will remain.
The saned service exposes a scanner remotely, which means it is a good idea to run it as a separate user/group and give it access to scanners only explicitely. In an upcoming release I will probably harden that service further though (if possible).
Thanks a lot for testing! :)