xsane rabbit hole

Links: scanimage man page :: clear overview of network and usb scanners, groups

I recently connected a mothballed Epson that scans on every system, but found that it didn't work in Fedora. The sane-find-scanner utility detected the scanner, but scanimage -L did not (as root or user). This is apparently a common problem, sometimes associated with permissions, sometimes random bugs.

I did get it to scan by manually entering the USB address detected by sane-find-scanner, and add the library suffix for Epsons* from /usr/lib/sane/. This looks like, eg...

$ scanimage -d epson2:libusb:001:005 --resolution 75 --mode Gray > star.jpeg
$ convert star.jpeg -normalize out.jpg

Conversion (ImageMagick) is required because the output image caused errors "not jpeg starts 0x50 0x34". The Start of File (SOF) was not the correct header for a JPEG. This is because it's really a PGM file. Anyway, scanning in this way would be prohibitively time intensive.

*attempted both /usr/lib/sane/libsane-epson and /usr/lib/sane/libsane-epson2

$ scanimage --help --device-name epson:libusb:001:005

Options specific to device `epson:libusb:001:005':
Scan Mode:
--mode Lineart|Gray|Color [Lineart]
Selects the scan mode (e.g., lineart, monochrome, or color).
--dropout None|Red|Green|Blue [None]
Selects the dropout.

--gamma-correction User defined (Gamma=1.0)|User defined (Gamma=1.8) [User defined (Gamma=1.8)]
Selects the gamma correction value from a list of pre-defined devices
or the user defined table, which can be downloaded to the scanner
--resolution 75|150|300|600dpi [75]
Sets the resolution of the scanned image.
--speed[=(yes|no)] [no]
Determines the speed at which the scan proceeds.

--short-resolution[=(yes|no)] [no]
Display short resolution list
--red-gamma-table 0..255,...
Gamma-correction table for the red band.
--green-gamma-table 0..255,...
Gamma-correction table for the green band.
--blue-gamma-table 0..255,...
Gamma-correction table for the blue band.

--wait-for-button[=(yes|no)] [no]
After sending the scan command, wait until the button on the scanner
is pressed to actually start the scan process.
Preview:
--preview[=(yes|no)] [no]
Request a preview-quality scan.
--preview-speed[=(yes|no)] [no]

Geometry:
-l 0..215.9mm [0]
Top-left x position of scan area.
-t 0..297.857mm [0]
Top-left y position of scan area.
-x 0..215.9mm [215.9]
Width of scan-area.
-y 0..297.857mm [297.857]
Height of scan-area.
--quick-format CD|A5 portrait|A5 landscape|Letter|A4|Max [Max]

strace

Stracing scanimage revealed that the appropriate lsusb.so was consulted, but nothing was returned. I also moved all .conf files in /etc/sane.d/ except the epsons, in case the client was could not locate the appropriate .conf file from the 30 or so in that folder. No luck.

saned

One article (link is also at top of page), seemed to imply that saned was necessary to run the scanner. I considered saned (configured via /etc/sane.d/saned.conf) only necessary for network access to scanners, and so looked more closely.

Saned and CUPS appear similar, at least in concept. Since I could find no clear guideline for the syntax for adding USB printers into saned, it's possible they are added to /etc/sane.d/saned.conf in a similar USB URL format as in CUPS, eg usb:/dev/usb/lp0. But it appears we may have to more specific about which USB and so include each:

groups

The Fedora installation had no group for scanning. It might be necessary to add a "scanner" group and create user access. If there is an underlying permissions issue, this might resolve it.

fuduntu - yum/rpm stuff

links: yum setup :: yum command examples

---

why yum/rpm?

In the previous post, I noted an install of Fuduntu, a recently orphaned distro. The idea was to establish a simple system which might retain its stability against the tide of media player updates. An expected side benefit was the opportunity to learn yum. Specifically, it's necessary to modify Fuduntu's default yum files because Fuduntu's yum URL's are now invalid. Note: the final Fuduntu release appears to be based on Fedora 17 (or roughly Enterprise Linux 6), plus some Ubuntu features.

/etc/yum.conf

No notable differences between Fedora and Fuduntu in the global /etc/yum.conf file. Standard.

repos to remove - /etc/yum.repos.d/

The helpful System > Administration > Software Sources window:

We can see the Fuduntu repository entries are there, though they no longer point anywhere. To follow good housekeeping, toggle enable to "enable=0" inside each undesired repo entry in /etc/yum.repos.d/. To be more thorough, we could delete unwanted repo files(in /etc/yum.repos.d/) and gpg keys (in /etc/pki/gpg-keys/). In my simple world, I renamed all the repos with a .bak extension and kept them -- I might want to look inside one later. This also allows me to change the extension back to ".repo" if I wanted to reactivate one for some reason.

# cd /etc/yum.repos.d/
# rename .repo .bak *.repo

repos to add

As noted at the top, I assumed Fuduntu's nearest releases were F17 and EL6.
(1) REPOFORGE (formerly RPM Forge)

# rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm

However, rpm for some reason could not resolve the host and was providing the following error

Retrieving http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm
curl: (6) Could not resolve host: pkgs.repoforge.org; Cannot allocate memory
error: skipping http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm - transfer failed

This is not a small problem, and requires a separate post on IPv4 and IPv6 addressing, which will be my next post. Essentially, curl does the DNS and downloading for rpm/yum actions. Users can specify "--ipv4" in direct CLI curl requests, but there are no such switches when rpm calls curl as a subroutine, out of sight of the user. If it doesn't receive IPv6 information, curl fails, causing rpm to fail.

So, for now, downloaded the rpm repo file directly via my browser, and then...

# yum --nogpgcheck localinstall rpmforge-release-0.5.3-1.el6.rf.i686.rpm

...and finally

# yum install --enablerepo=rpmforge-extras

Looking at its file, it performs a gpg check on the downloaded packages. There are many settings available, a simple example is the one above -- to toggle a repo in a file on or off, change the state in the "enabled" line.

(2) ATRPMS Below is the repair for curl IPv6 finickiness. Then one can directly download and install the file using rpm.

[verify]
# nano /etc/host.conf
order hosts,bind

[enter]
# nano /etc/hosts
::ffff:a02d:fe1a packages.atrpms.net
160.45.254.26 packages.atrpms.net
::ffff:a02d:fe16 dl.atrpms.net
160.45.254.22 dl.atrpms.net

[test]
# curl --ipv6 packages.atrpms.net

[install key]
# rpm --import http://packages.atrpms.net/RPM-GPG-KEY.atrpms

[install]
# rpm -ivh http://dl.atrpms.net/all/atrpms-repo-17-6.fc17.i686.rpm
Retrieving http://dl.atrpms.net/all/atrpms-repo-17-6.fc17.i686.rpm
Preparing... ########################################### [100%]
1:atrpms-repo ########################################### [100%]

# ldconfig

# yum clean all

(3) RPMFUSION

[verify]
# nano /etc/host.conf
order hosts,bind

[enter]
# nano /etc/hosts
::ffff:c11c:eb3c download1.rpmfusion.org
193.28.235.60 download1.rpmfusion.org

[test]
# curl --ipv6 download1.rpmfusion.org

[install]
# rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-17.noarch.rpm
Retrieving http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-17.noarch.rpm
warning: /var/tmp/rpm-tmp.QSSeST: Header V3 RSA/SHA256 Signature, key ID 8296fa0f: NOKEY
Preparing... ########################################### [100%]
1:rpmfusion-free-release ########################################### [100%]

# ldconfig

# yum clean all

manual repo pointing

Let's create a new repo file, fedora1.repo. Permissions of the file should be 644...

# chown 644 /etc/yum.repos.d/fedora1.repo

...it should appear in System > Administration > Software Sources:

quick test - yum repolist

Fast way to check if everything is operating correctly

---

NOTES: gpg keys

On first cut, the new repository did not work. Note that in the above repo listing, we requested a gpg check and provided the folder to find it...

gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

... but then of course we only had Fuduntu keys in that folder, no Fedora keys. Further, the Fedora project has moved on, it's no longer operating repos for Fedora 17. So we could use rpm to import the keys and automatically create softlinks... /etc/pki/rpm-gpg/...

# rpm --import RPM-GPG-KEY-fedora-17-primary
# rpm --import RPM-GPG-KEY-fedora-17-secondary

...but Fedora does not maintain older packages, so we'd have the keys to nothing. We could even add the old F17 keys manually...

# gedit /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-primary

...post the key block from the link into that file, then made a softlink for housekeeping...

# ln -s /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-primary /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

...but again this would be pointless since no F17 software is available at Fedora.

There are also these sorts of possible yum problems.