[sane-devel] Preparing for a sane-backends release

Tue Aug 11 10:42:54 UTC 2015

Hi Allan,

I compared scanimage and xsane logs, and I found a difference after
"Reader task terminated".

It seems that scanimage has a problem closing the scanner.

I removed scanned data in the log files for better reading.

Hope this helps.

Cheers,
Rolf

Am 08.08.2015 um 00:29 schrieb m. allan noah:
> After a bit of searching, this looks like a bug in libusb-compat:
> http://sourceforge.net/p/libusbx/mailman/libusbx-devel/thread/522AF646.7060108@redhat.com/
> 
> allan
> 
> On Fri, Aug 7, 2015 at 6:21 PM, m. allan noah <kitno455 at gmail.com> wrote:
>> Rolf- can you get a log of the scanimage and xsane shutdown sequences,
>> and see if they call something in a different order? I had one report
>> of this same error with the Fujitsu iX500, but I never reproduced.
>>
>> allan
>>
>> On Fri, Aug 7, 2015 at 5:40 PM, Rolf Bensch <rolf at bensch-online.de> wrote:
>>> Hello,
>>>
>>> I just fixed an usb communication problem with OpenSuse and the Pixma
>>> backend.
>>>
>>> Scanning with xsane is working with my CS9000F scanner. But if I'm
>>> scanning with scanimage, I always get this message at the end of each scan:
>>> "libusb: warning [libusb_close] internal signalling read failed, closing
>>> anyway"
>>>
>>> Then I need to terminate scanimage with 2x CTRL C. And sometimes the USB
>>> bus is blocked for my scanner until I reboot the machine. The scanned
>>> image is OK.
>>>
>>> I'm testing OpenSuse 13.2 in VirtualBox 5.0 on Ubuntu 14.04.1, both x86_64.
>>>
>>> Maybe you can give me a hint where to look to fix this issue or Allan
>>> can fix this for me. I'm not very familiar with the usb library.
>>>
>>> Many thanks for your help.
>>>
>>> Cheers,
>>> Rolf
>>>
>>> Am 04.08.2015 um 13:11 schrieb Johannes Meixner:
>>>>
>>>> Hello,
>>>>
>>>> On Aug 3 14:08 m. allan noah wrote (excerpt):
>>>>> ... I know that Gentoo has some systemd compilation fixes.
>>>>
>>>> Everey Linux distribution should submit their patches to SANE
>>>> upstream (provided their changes make sense for upstream).
>>>>
>>>> Here our (i.e. openSUSE) patches that we still have:
>>>>
>>>>
>>>> 1)
>>>> Right now I filed
>>>> https://alioth.debian.org/tracker/index.php?group_id=30186&atid=410366
>>>> with my fix-buffer-overflow.patch attached
>>>> that fixes a too small array in backend/niash.c
>>>>
>>>>
>>>> 2)
>>>> My re-add-SANE_CAP_ALWAYS_SETTABLE.patch re-adds SANE_CAP_ALWAYS_SETTABLE
>>>> to sane.h which was erroneously removed in sane-backends-1.0.20 so that
>>>> sane-frontends and xsane can no longer build, see
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527675
>>>>
>>>> re-add-SANE_CAP_ALWAYS_SETTABLE.patch
>>>> -----------------------------------------------------------------------------
>>>>
>>>> --- include/sane/sane.h.orig    2009-06-12 10:19:19.000000000 +0200
>>>> +++ include/sane/sane.h 2009-06-12 10:20:12.000000000 +0200
>>>> @@ -115,6 +115,7 @@ SANE_Device;
>>>>  #define SANE_CAP_AUTOMATIC             (1 << 4)
>>>>  #define SANE_CAP_INACTIVE              (1 << 5)
>>>>  #define SANE_CAP_ADVANCED              (1 << 6)
>>>> +#define SANE_CAP_ALWAYS_SETTABLE       (1 << 7)
>>>>
>>>>  #define SANE_OPTION_IS_ACTIVE(cap)     (((cap) & SANE_CAP_INACTIVE)
>>>> == 0)
>>>>  #define SANE_OPTION_IS_SETTABLE(cap)   (((cap) &
>>>> SANE_CAP_SOFT_SELECT) != 0)
>>>> -----------------------------------------------------------------------------
>>>>
>>>>
>>>> The re-add-SANE_CAP_ALWAYS_SETTABLE.patch still applies for
>>>> current sane-backends-git20150804.tar.gz so that I assume
>>>> SANE_CAP_ALWAYS_SETTABLE is still missing in sane-backends.
>>>>
>>>> I did not verify whether or not meanwhile all SANE frontends
>>>> also no longer use SANE_CAP_ALWAYS_SETTABLE so that it could
>>>> meanwhile be really removed in sane-backends.
>>>>
>>>>
>>>> 3)
>>>> My fix-mustek_pp_ccd300.c.patch fixes undefined 'foo = ++foo modulo bar'
>>>> operations in mustek_pp_ccd300.c see
>>>> https://bugzilla.opensuse.org/show_bug.cgi?id=498435
>>>> and
>>>> https://alioth.debian.org/tracker/index.php?func=detail&aid=311857&group_id=30186&atid=410366
>>>> where the upstream maintainer did not understand what is wrong and
>>>> closed it  as "Wont Fix" so that we must keep this patch forever
>>>> to make at least the code somehow valid for the compiler.
>>>> fix-mustek_pp_ccd300.c.patch is attached to the above
>>>> alioth.debian.org bug tracker issue.
>>>> Of course because the result of 'foo = ++foo' is undefined
>>>> I cannot know if my patch implements what is actually intended.
>>>> My patch implements an arbitrary result that only makes the
>>>> compiler happy.
>>>>
>>>>
>>>> 4)
>>>> My install-umax_pp-tool.patch installs tools/umax_pp as /usr/bin/umax_pp
>>>> which is built but not installed but it is needed to recover from
>>>> a failed scan with scanners which use the umax_pp backend, see
>>>> http://bugs.debian.org/496833
>>>>
>>>> install-umax_pp-tool.patch
>>>> --------------------------------------------------------------------
>>>> --- tools/Makefile.am.orig      2009-02-20 17:51:09.000000000 +0100
>>>> +++ tools/Makefile.am   2009-06-05 15:08:45.000000000 +0200
>>>> @@ -7,8 +7,8 @@
>>>>  AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_builddir)/include \
>>>>   -I$(top_srcdir)/include
>>>>
>>>> -bin_PROGRAMS = sane-find-scanner gamma4scanimage
>>>> -noinst_PROGRAMS = sane-desc umax_pp
>>>> +bin_PROGRAMS = sane-find-scanner gamma4scanimage umax_pp
>>>> +noinst_PROGRAMS = sane-desc
>>>>
>>>>  if CROSS_COMPILING
>>>>  HOTPLUG =
>>>> --------------------------------------------------------------------
>>>>
>>>> The install-umax_pp-tool.patch still applies for current
>>>> sane-backends-git20150804.tar.gz so that I assume
>>>> tools/umax_pp is still not installed by default.
>>>>
>>>>
>>>>
>>>> In general regarding parallel port scanner drivers:
>>>>
>>>> The above issues 3) and 4) are about parallel port scanner drivers.
>>>>
>>>> I wonder if support for parallel port scanners is still needed?
>>>>
>>>> I assume that basically nobody tests parallel port scanners.
>>>> Probably also basically nobody usues parallel port scanners.
>>>>
>>>> In this case parallel port scanner drivers should be dropped
>>>> because in practice they are no longer maintained.
>>>>
>>>> As a first step parallel port scanner drivers could be
>>>> no longer built by default e.g. via something like
>>>>   configure --without-parport
>>>> by default.
>>>>
>>>>
>>>> Kind Regards
>>>> Johannes Meixner
>>>
>>>
>>
>>
>>
>> --
>> "well, I stand up next to a mountain- and I chop it down with the edge
>> of my hand"
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tar.gz
Type: application/gzip
Size: 2483 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20150811/352860fe/attachment.bin>