Request for update: SANE 1.0.29

Bug #1862926 reported by Till Kamppeter on 2020-02-12
This bug affects 5 people
Affects Status Importance Assigned to Milestone
sane-backends (Debian)
Fix Released
sane-backends (Ubuntu)

Bug Description

In Focal we are still a bit old-fashioned regarding scanning. We are still at the ancient SANE 1.0.27! That is really INSANE.

Current version is 1.0.29 and it contains a very important new feature which will make hundreds (thousands?) of new scanners work with Ubuntu. This new feature is Apple AirScan support as a client. I have introduced a lot of nice printing stuff to support AirPrint, making lots of printers (practically all modern network printers) working, and all the multi-function devices under these (printer and scanner in one) do AirScan, so all these scanner will work with SANE 1.0.29 (if yours does not, it is a bug in SANE, please report).

The AirScan support is provided by the new "escl" backend. supporting the eSCL protocol AirPrint is based on. The protocol uses HTTP and XML, so this works out-of-the-box if your printer is connected to the network, if it is connected via USB it work via IPP-over-USB using the ippusbxd package.

Changes list from upstream:

- Backends
   + adds an escl backend (theoretically supporting all AirPrint devices with a scan unit
   + adds support for 23 new scanner models via existing backends
   + significantly changes genesys and pixma backends
   + fixes bugs in canon_dr, fujitsu, hp3900, mustek_usb2, plustek and xerox_mfp backends
   + fixes all compiler warnings on Debian 10 (#120)
   + fixes portability issues for uClibc-ng and MacOS builds
   + adds support to record and replay USB I/O traffic
   + adds timestamps to debug logs

debdiff attached.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sane-backends (Ubuntu):
status: New → Confirmed
nmaxx (nmaxx) wrote :

I agreee, this absolutely belongs in 20.04, and a SRU for 18.04 would probably be warranted as well, assuming this is possible (not sure about compatibility with clients built against 1.0.27).

Mathew Hodson (mhodson) on 2020-02-16
tags: added: upgrade-software-version
Robert Ancell (robert-ancell) wrote :

The changes to the symbol files had changed the package name from 'libsane' to 'libsane1', so I reverted that and uploaded the rest, thanks Till!

Robert Ancell (robert-ancell) wrote :

There wasn't a bug link in the changelog, so this bug wont be automatically closed.

Till Kamppeter (till-kamppeter) wrote :

1.0.29-0ubuntu1 does FTBFS, -0ubuntu2 with added Build-Depends: on the way.

Till Kamppeter (till-kamppeter) wrote :

The attached debdiff adds the missing Build-Depends for fixing the FTBFS and getting all backends built.

Robert Ancell (robert-ancell) wrote :

I uploaded 1.0.29-0ubuntu2 to focal

Thank you for the second upload, it fixed the general FTBFS but some architectures still show problems:

i386 (the only remaining 32-bit architecture?):

The genesys backend fails the unit tests due to a problem with floating point arithmetics on 32/64-bit. There are bug reports upstream, but all unsolved:


Fails on symbol table generation:

dh_makeshlibs -- -v1.0.29 -Pdebian/libsane -plibsane
dpkg-gensymbols: warning: new libraries appeared in the symbols file:
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libsane/DEBIAN/symbols doesn't match completely debian/libsane.symbols.ppc64el

Do we really need to generate symbol tables for each scanner driver? No one develops against the drivers, only against the main library.

To fix, one simply needs to copy the patch from the buildlog and apply it.

And why do we need these scanner drivers on server-only architectures?


Bog known and fixed upstream:

So the biggest problem is the i386, as upstream has no solution for that, perhaps skip this one test (genesys backend) i386-only.

Already when I started updating SANE to 1.0.29 I had a look into Rolf Bensch's PPA

and overtaken some of his work, especially I copied the symbols files. But his package is not built for ppc64el and s390x (probably because no one needs scanner drivers on these server-only architectures?). Probably therefore ppc64el fails with the symbol table.

The s390x problem Rolf also did not hit due to his selection of architectures.

The i386 problem is known to Rolf and this has made him skipping the unit tests altogether:

Sebastien Bacher (seb128) wrote :

The build got fixed now
the remaining blocked is an arm64 autopkgtest issue which isn't new to this update

Seb, thanks for the info about the package being fixed.
locutusofborg, thanks for fixing and uploading.

Changed in sane-backends (Ubuntu):
status: Confirmed → Fix Released
Rolf Bensch (rolfbensch) wrote :

Till, in my ppa the symbol files are not up to date. I just removed outdated entries, but not added new ones.

However, libpng-dev is included to the build by other dependecies. I see that adding this package to control file makes this dependency more transparent and I'll add it into my ppa.

nmaxx (nmaxx) wrote :

That you so much for updating SANE to 1.0.29 - I think scanning in Ubuntu is in a *much* better place now, including futureproofing via the AirPrint device support. :)

Can't wait for the 20.04 release...

Changed in sane-backends (Debian):
status: Unknown → Fix Released

For what its' worth, the sane escl is buggy even in 1.0.29, installing 1.0.31 improves matters !.
Example bug/failure is here, but NOTE is not actually limited to the titled printer:-

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.