from:"Paul Menzel"

[sane-devel] [PATCH] [RFC] add sanei_usb test program

2013-03-18 Thread Paul Menzel

Dear Stef,


sorry that it took me so long to reply.


Am Samstag, den 16.03.2013, 11:11 +0100 schrieb Stef:

[?]

 it is a handy format that ease the review process. I'll consider it 
 for another occasion if there is a consensus on receiving sometimes 
 about 12 mails and on raising the mail size limit (one of the patches is 
 ~40k if inlined).
 For this time I'd appreciate that you comment on the patches with their 
 current form.

I edited the patch right away. You can save this message and apply it
with `git am --scissors patch/to/file`.

Some typos, grammar, return value comments and coding style [1] is
hopefully improved. Here is the diff.

$ git diff stefs-patch stefs-patch-my  /tmp/git-diff-stef-and-my-changes.diff
diff --git a/testsuite/sanei/Makefile.am b/testsuite/sanei/Makefile.am
index a05108e..49c1a97 100644
--- a/testsuite/sanei/Makefile.am
+++ b/testsuite/sanei/Makefile.am
@@ -1,11 +1,11 @@
 ##  Makefile.am -- an automake template for Makefile.in file
 ##  Copyright (C) 2009 Chris Bagwell and Sane Developers.
 ##
-##  This file is part of the Sane build infra-structure.  See
+##  This file is part of the Sane build infrastructure.  See
 ##  included LICENSE file for license information.
 
-MATH_LIB = @MATH_LIB@ 
-USB_LIBS = @USB_LIBS@ 
+MATH_LIB = @MATH_LIB@
+USB_LIBS = @USB_LIBS@
 PTHREAD_LIBS = @PTHREAD_LIBS@
 
 EXTRA_PROGRAMS = sanei_usb_test
@@ -19,7 +19,7 @@ clean-local:
rm -f sanei_usb_test
 
 all:
-   @echo 'run make tests' to run tests
+   @echo run 'make tests' to run tests
 
 tests: $(EXTRA_PROGRAMS)
sanei_usb_test
diff --git a/testsuite/sanei/Makefile.in b/testsuite/sanei/Makefile.in
index ab92780..379ce69 100644
--- a/testsuite/sanei/Makefile.in
+++ b/testsuite/sanei/Makefile.in
@@ -162,7 +162,7 @@ MAINT = @MAINT@
 MAKEINDEX = @MAKEINDEX@
 MAKEINFO = @MAKEINFO@
 MANIFEST_TOOL = @MANIFEST_TOOL@
-MATH_LIB = @MATH_LIB@ 
+MATH_LIB = @MATH_LIB@
 MKDIR_P = @MKDIR_P@
 MSGFMT = @MSGFMT@
 MSGMERGE = @MSGMERGE@
@@ -202,7 +202,7 @@ STRIP = @STRIP@
 SYSLOG_LIBS = @SYSLOG_LIBS@
 SYSTEMD_LIBS = @SYSTEMD_LIBS@
 TIFF_LIBS = @TIFF_LIBS@
-USB_LIBS = @USB_LIBS@ 
+USB_LIBS = @USB_LIBS@
 VERSION = @VERSION@
 V_MAJOR = @V_MAJOR@
 V_MINOR = @V_MINOR@
@@ -300,7 +300,7 @@ $(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ 
$(am__configure_deps)
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
cd $(top_builddir)  $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
-sanei_usb_test$(EXEEXT): $(sanei_usb_test_OBJECTS) 
$(sanei_usb_test_DEPENDENCIES) $(EXTRA_sanei_usb_test_DEPENDENCIES) 
+sanei_usb_test$(EXEEXT): $(sanei_usb_test_OBJECTS) 
$(sanei_usb_test_DEPENDENCIES) $(EXTRA_sanei_usb_test_DEPENDENCIES)
@rm -f sanei_usb_test$(EXEEXT)
$(LINK) $(sanei_usb_test_OBJECTS) $(sanei_usb_test_LDADD) $(LIBS)
 
diff --git a/testsuite/sanei/README b/testsuite/sanei/README
index fba421e..7b8af5b 100644
--- a/testsuite/sanei/README
+++ b/testsuite/sanei/README
@@ -1,8 +1,8 @@
 SANEI test suite
 ===
-St\E9phane Voltz stef.dev at free.fr
+St?phane Voltz stef.dev at free.fr
 
-This directory contains tests programs for sanei functions. They are compiled 
+This directory contains test programs for sanei functions. They are compiled
 and run by 'make tests'.
 
 sanei_usb tested functions, at least one USB scanner needs to be plugged:
diff --git a/testsuite/sanei/sanei_usb_test.c b/testsuite/sanei/sanei_usb_test.c
index 8cd45dd..d7541f7 100644
--- a/testsuite/sanei/sanei_usb_test.c
+++ b/testsuite/sanei/sanei_usb_test.c
@@ -30,7 +30,7 @@
 #include ../../include/_stdint.h
 
 /*
- * In order to avoid modifying sanei_usb.c to allow for unit tests
+ * In order to avoid modifying sanei_usb.c to be suitable for unit tests
  * we include it so we can use its private variables and structures
  * and still test the code.
  */
@@ -40,102 +40,102 @@
 /** test sanei_usb_init()
  * calls sanei_usb_init
  * @param expected expected use count
- * @return 0 on success, else 1
+ * @return 0 on success, else 1 or 2
  */
-static int test_init(int expected)
+static int test_init (int expected)
 {
   /* initialize USB */
-  printf(%s starting ...\n, __FUNCTION__);
+  printf (%s starting ...\n, __FUNCTION__);
   sanei_usb_init ();
-  if (initialized==0)
+  if (initialized == 0)
 {
-  printf(ERROR: sanei_usb not initialized!\n);
+  printf (ERROR: sanei_usb not initialized!\n);
   return 1;
 }
   if (initialized != expected)
 {
-  printf(ERROR: incorrect use count, expected %d, got %d!\n,expected, 
initialized);
+  printf (ERROR: incorrect use count, expected %d, got %d!\n, expected, 
initialized);
   return 2;
 }
-  
-  printf(sanei_usb initialized, use count is %d ...\n, initialized);
-  printf(%s success\n\n, __FUNCTION__);
+
+  printf (sanei_usb initialized, use count is %d ...\n, initialized);
+  printf (%s success\n\n, __FUNCTION__);
   return 0;
 }
 
 /** test sanei_usb_exit()
  * calls sanei_usb_exit
  * @param

[sane-devel] [PATCH] [RFC] add sanei_usb test program

2013-03-14 Thread Paul Menzel

Dear Stef,


Am Freitag, den 08.03.2013, 21:55 +0100 schrieb Stef:

[?]

  I really think this test program should be added, it doesn't add 
 extra dependency and helps testing a lot. For instance while adding a 
 test case for the problem Olaf spotted (not setting usb context to 
 null), it allowed me to find I also forgot to reset device_number to 0 
 in sane_exit().

I agree with your reasoning.

I think I spotted some small things. Could you please resend the patch
inlined, so I can answer inline with my email client? That would be
awesome.

You can do

$ git format-patch -1

as you already did and copy that to the commit message body and make
sure to turn of automatic line wrapping in Thunderbird.


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130314/705487e8/attachment.pgp

[sane-devel] [RFC] move test_wire.c test program away from sanei sudirectory

2013-03-14 Thread Paul Menzel

Dear Stef,


Am Dienstag, den 12.03.2013, 21:56 +0100 schrieb Stef:

  currently there is already a 'test_wire.c' test program in the 
 sanei subdirectory. Since I am planning to add a testsuite/sanei 
 subdirectory. I'm feeling like moving this program there, so we keep 
 test code and 'core' code separated.
  Would this be OK ?

sounds good. Though I am not sure if it makes sense to introduce sub
directories in the `testsuite` folder when there just a few tests. But
your call.


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130314/0ccd7ca1/attachment.pgp

[sane-devel] HP5400 XPA support patch

2013-03-11 Thread Paul Menzel

Dear Tyson,


Am Sonntag, den 10.03.2013, 13:32 -0400 schrieb Tyson Whitehead:
 I cleaned up (switched the coding style to match the existing one used
 in the HP5400 driver) and updated (resolved the various conflicts to get
 it to apply against 1.0.22) Martin's XPA support patch for the HP5400.
 
 http://sourceforge.net/projects/hp5400backend/

Thank you for doing that.

 Please find the updated version attached.

Could you please resend this patch with the diff inlined as it is easier
to reply to it.

$ git format-patch -1

You can add an introductory note in front of it by doing and separate
this by adding the following line.

 8  8 

See `git help am`.

Like this seems to be from 2010? Was this backend always developed
outside of SANE upstream and merged every now and then?

 It works for me.  I don't know why the original never made it out of
 the HP5400 repo.

Do you know if it was ever submitted for review? Does Martin agree with
getting this into SANE upstream repository?


 --- sane-backends-1.0.22/backend/hp5400.h-xpa   2010-12-01 18:49:58.0 
 -0500
 +++ sane-backends-1.0.22/backend/hp5400.h   2012-10-14 23:34:42.043244625 
 -0400
 @@ -70,4 +70,12 @@
  };
  
 +enum ScanSource
 +{
 +  SRC_FLATBED,
 +  SRC_XPA,
 +  SRC_NOLAMP
 +};
 +
 +
  /* In case we ever need to track multiple models */
  typedef struct
 @@ -136,4 +144,10 @@
  * internally. Leave it for the time being as 
 it
  * may be needed later. */
 +  int iLamp;   /* experimental setting, do not use.
 +* Should the lamp be turned off (iLamp=1) 
 +* or not (iLamp=0) */
 +  int iSource; /* scan_source 
 +* Normal or 
 +* Transparenty adapter (=XPA) */
  }
  TScanParams;
 --- sane-backends-1.0.22/backend/hp5400_internal.c-xpa  2010-12-01 
 18:49:58.0 -0500
 +++ sane-backends-1.0.22/backend/hp5400_internal.c  2012-10-16 
 18:56:39.342199492 -0400
 @@ -152,4 +152,9 @@
 return 0;
  }
 +  else
 +{
 +  if (WriteByte (pHWParams-iXferHandle, 0x, 0x00) == 0)
 +   return 0;
 +}
return -1;
  }
 @@ -157,21 +162,44 @@
  HP5400_SANE_STATIC
  int
 -WarmupLamp (int iHandle)
 +WarmupLamp (int iHandle, int iSource)
  {
 -  int i = 30;  /* Max 30 seconds, 15 is typical for cold 
 start? */
 -  int couldRead;
 -  unsigned char dataVerify[0x02];
 -
 -  /* Keep writing 01 to  until no error... */
 -  unsigned char data[] = {
 -0x01
 -  };
 -  unsigned char data0300[3];
 +  int iWait;   /* Max 60 seconds,
 +* 15 is typical for cold start of flatbed,
 +* xpa takes much longer */
 +
 +  {/* Try to set the right lamp to make scan 
 succeed */
 +char flag;
 +if (iSource==SRC_XPA)
 +  {
 +  iWait = 60;
 +  flag=0x02;/*mdvh  turn on  xpa lamp*/

Could you please also revise your patch regarding coding style stuff.
Like a space in front of the comment?

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130311/1a95f674/attachment.pgp

[sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update

2013-03-11 Thread Paul Menzel

Dear Klaus,


Am Freitag, den 08.03.2013, 17:10 +0100 schrieb Klaus Kaempf:

 * Paul Menzel paulepanter at users.sourceforge.net [Mar 04. 2013 10:34]:
  
  In my opinion, before committing this upstream you could squash several
  commits into the original one (as it is not upstream yet). That will
  keep the commit log cleaner.
 
 sure, no problem. What's the usual process for getting code upstream ?

I am also new to SANE. But sending your patches to the list for review
and providing a branch to pull from is good way I think.

 Are there any coding style guidelines for SANE ?

They are not documented I think. At least I have not found them. You can
only look at already existing files.

  If you have even more time and as you found some small errors already
  and fixed them, you could run Cppcheck and splint on your code (and
  mention that in the commit message).
 
 My primary goal, besides getting running code, is to make the code
 clean and maintanable. These tools will certainly help, thanks !

Awesome!


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130311/9e7a1d75/attachment.pgp

[sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update

2013-03-04 Thread Paul Menzel

Dear Klaus,


Am Montag, den 04.03.2013, 10:02 +0100 schrieb Klaus Kaempf:

 after (too) many weeks, I finally found some time to work on the
 'pieusb' backend driver again.

nice. Thank you for taking the time.

 Based on Jan's work, I started a big round of cleanups and coding
 style improvements. The various pieusb_*.c are now separate
 compilation units.
 
 See https://github.com/kkaempf/sane-backends/tree/kkaempf for the
 current state.
 
 The current code compiles but wasn't tested against the actual scanner
 yet.
 Once this test is successful, I'd like to push the code upstream and
 go from there.

In my opinion, before committing this upstream you could squash several
commits into the original one (as it is not upstream yet). That will
keep the commit log cleaner.

If you have even more time and as you found some small errors already
and fixed them, you could run Cppcheck and splint on your code (and
mention that in the commit message).


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130304/36a87fd3/attachment-0001.pgp

[sane-devel] Support for Benq Scanwit 2720S

2013-02-25 Thread Paul Menzel

Dear Andrew, dear Oliver,


why not discuss this publicly on this list too.

1. People having a BenQ ScanWit 2720S might join the discussion and test
the patches too.

2. It is archived too in the case of some hardware failure and missing
backup.


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130225/02e48c6f/attachment.pgp

[sane-devel] [PATCH] Add support to snapscan for Benq Scanwit 2720S film scanner

2013-02-25 Thread Paul Menzel

Dear Andrew,


thank you for working on finishing the support.

Am Montag, den 25.02.2013, 10:00 + schrieb Andrew Goodbody:

[?]

What is the current status?

My comments are inline.

 ---
  backend/snapscan-options.c |  223 +---
  backend/snapscan-scsi.c|  309 
 ++--
  backend/snapscan-sources.c |   31 -
  backend/snapscan.c |  133 ++-
  backend/snapscan.h |   28 +++-
  5 files changed, 597 insertions(+), 127 deletions(-)
 
 diff --git a/backend/snapscan-options.c b/backend/snapscan-options.c
 index a7401bb..674c8d2 100644
 --- a/backend/snapscan-options.c
 +++ b/backend/snapscan-options.c
 @@ -1,9 +1,9 @@
  /* sane - Scanner Access Now Easy.
  
 -   Copyright (C) 1997, 1998, 2001 Franck Schnefra, Michel Roelofs,
 +   Copyright (C) 1997, 1998, 2001, 2013 Franck Schnefra, Michel Roelofs,
 Emmanuel Blot, Mikko Tyolajarvi, David Mosberger-Tang, Wolfgang Goeller,
 Petter Reinholdtsen, Gary Plewa, Sebastien Sable, Mikael Magnusson,
 -   Oliver Schwartz and Kevin Charter
 +   Andrew Goodbody, Oliver Schwartz and Kevin Charter
  
 This file is part of the SANE package.
  
 @@ -67,11 +67,15 @@
  static SANE_Int def_rgb_lpr = 4;
  static SANE_Int def_gs_lpr = 12;
  static SANE_Int def_bpp = 8;
 +static SANE_Int def_frame_no = 1;
  
  
  /* predefined preview mode name */
  static char md_auto[] = Auto;
  
 +/* predefined focus mode name */
 +static char md_manual[] = Manual;
 +
  /* predefined scan mode names */
  static char md_colour[] = SANE_VALUE_SCAN_MODE_COLOR;
  static char md_bilevelcolour[] = SANE_VALUE_SCAN_MODE_HALFTONE;
 @@ -103,6 +107,15 @@ static char lpr_desc[] = SANE_I18N(
  a scan; if it's set too high, X-based frontends may stop responding 
  to X events and your system could bog down.);
  
 +static char frame_desc[] = SANE_I18N(
 +Frame number of media holder that should be scanned.);
 +
 +static char focus_mode_desc[] = SANE_I18N(
 +Use manual or automatice selection of focus point.);

1. automatic

 +
 +static char focus_desc[] = SANE_I18N(
 +Focus point for scanning.);
 +
  /* ranges */
  static const SANE_Range x_range_fb =
  {
 @@ -174,6 +187,16 @@ static const SANE_Range y_range_tpo_2580 =
  SANE_FIX (0.0), SANE_FIX (80.0), 0
  };/* mm */
  
 +/* TPO range for the Scanwit 2720S */

TPO? Turn page over [1] ? Could you enlighten me please? It?s used for
the other devices too and search the Web did not help.

[1] http://en.wikipedia.org/wiki/TPO

Found it in `snapscan.h`.

typedef enum
{
SRC_FLATBED = 0,/* Flatbed (normal) */
SRC_TPO,/* Transparency unit */
SRC_ADF
} SnapScan_Source;

 +static const SANE_Range x_range_tpo_2720s =
 +{
 +SANE_FIX (0.0), SANE_FIX (23.6), 0
 +};/* mm */
 +static const SANE_Range y_range_tpo_2720s =
 +{
 +SANE_FIX (0.0), SANE_FIX (35.7), 0
 +};/* mm */
 +
  /* TPO range for the Epson 3490 */
  static const SANE_Range x_range_tpo_3490 =
  {
 @@ -198,6 +221,14 @@ static const SANE_Range lpr_range =
  {
  1, 50, 1
  };
 +static const SANE_Range frame_range =
 +{
 +1, 6, 1
 +};
 +static const SANE_Range focus_range =
 +{
 +0, 0x300, 6
 +};
  
  static const SANE_Range brightness_range =
  {
 @@ -243,6 +274,8 @@ static void init_options (SnapScan_Scanner * ps)
  {10, 50, 75, 100, 150, 200, 300, 400, 600, 800, 1600};
  static SANE_Word resolutions_2400[] =
  {10, 50, 75, 100, 150, 200, 300, 400, 600, 1200, 2400};
 +static SANE_Word resolutions_2700[] =
 +{4, 337, 675, 1350, 2700};
  static SANE_Word resolutions_3200[] =
  {15, 50, 150, 200, 240, 266, 300, 350, 360, 400, 600, 720, 800, 
 1200, 1600, 3200};
  static SANE_String_Const names_all[] =
 @@ -253,6 +286,8 @@ static void init_options (SnapScan_Scanner * ps)
  {md_auto, md_colour, md_bilevelcolour, md_greyscale, md_lineart, 
 NULL};
  static SANE_String_Const preview_names_basic[] =
  {md_auto, md_colour, md_greyscale, md_lineart, NULL};
 +static SANE_String_Const focus_modes[] =
 +{md_auto, md_manual, NULL};
  static SANE_Int bit_depth_list[4];
  int bit_depths;
  SANE_Option_Descriptor *po = ps-options;
 @@ -287,6 +322,10 @@ static void init_options (SnapScan_Scanner * ps)
 y_range_tpo = y_range_tpo_2480;
  }
  break;
 +case SCANWIT2720S:
 +x_range_tpo = x_range_tpo_2720s;
 +y_range_tpo = y_range_tpo_2720s;
 +break;
  case PERFECTION3490:
  x_range_tpo = x_range_tpo_3490;
  y_range_tpo = y_range_tpo_3490;
 @@ -318,6 +357,7 @@ static void init_options (SnapScan_Scanner * ps)
  po[OPT_MODE_GROUP].cap = 0;
  po[OPT_MODE_GROUP].constraint_type = SANE_CONSTRAINT_NONE;
  
 +ps-res = DEFAULT_RES;

Why move this from below?

  po[OPT_SCANRES].name = SANE_NAME_SCAN_RESOLUTION;

[sane-devel] [RFC] Why I consider downstream bug reports a good thing

2013-02-18 Thread Paul Menzel

Dear SANE folks,

Allan wrote in his reply to my message on the mailing list that he
considers downstream reports ?pointless? [1].

Here are my arguments why I consider downstream reports good in addition
to upstream reports. Comments are welcome.

1. Distributions have different issues to deal with than upstream and
different rules. Basically they often cannot just ship the latest
upstream version.

Often they have several releases and depending on their focus they need
to add support for new hardware to older releases. Sometimes their
development guide lines prohibit to just ship new releases as code
cleanups or other improvements might be not allowed and only bug fixes
and hardware support is.

This is true for example for Debian stable releases, for Ubuntu LTS
(long-term support) releases or for example Red Hat Enterprise products.

As SANE upstream does not provide any LTS releases as for example the
Linux kernel, the distributions need to backport commits and they need
to know what needs to be backported. Package maintainers often do not
have much time for going through upstream log and need to know what
needs backporting. Downstream reports help them.

2. Having downstream reports shows the distribution?s quality assurance
team analyzing their bug tracking system where problems are. For example
if Red Hat, SUSE or Canonical [2] see that SANE issues make up five
percents (just made up) of the reports, they might decide to invest some
resources into upstream SANE. Either by assigning developers to work on
SANE by fixing bugs, improve code and to add support for new devices, by
contacting the device manufacturers and negotiate with them to provide
SANE drivers, or by simply paying developers.

3. Distributions often use their bug trackers ? Debian the Debian BTS
[3] ? to figure out their current state and their bug tracking system is
tightly integrated with their tools. Upstream integration means most of
the time just to document the upstream report and link to it, which is
important as that is how the WWW works.

4. Some distributions do not have a committed maintainer for SANE
packages, so uploads and packaging has to be done by packagers not
really familiar with SANE. Having downstream reports helps them to
improve the packaging.

Distributions with committed package maintainers mostly will not be
burdened by downstream reports, as they provide packages resembling the
upstream state regarding device support, so users will not hit these
issues and therefore will not report them.

5. Noting the URL of the downstream report in the upstream bug tracker ?
Alioth in SANE?s case ? is important to, to notify people, finding the
upstream report first, this bug is already tracked in their
distribution. And as written above, that is how the Web works. Links,
links, links.

Thanks,

Paul

[1]
http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030914.html
[2] https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bugs
[3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sane-backends
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130218/2d9c1ad8/attachment.pgp

[sane-devel] [RFC] Why I consider downstream bug reports a good thing

2013-02-18 Thread Paul Menzel

Dear Stef,

Am Montag, den 18.02.2013, 17:54 +0100 schrieb Stef:
On 18/02/2013 15:09, Paul Menzel wrote:

Allan wrote in his reply to my message on the mailing list that he
considers downstream reports ?pointless? [1].

Here are my arguments why I consider downstream reports good in addition
to upstream reports. Comments are welcome.

1. Distributions have different issues to deal with than upstream and
different rules. Basically they often cannot just ship the latest
upstream version.

This is true for example for Debian stable releases, for Ubuntu LTS
(long-term support) releases or for example Red Hat Enterprise products.

Thanks,

Paul

I suppose it's up to distro to tell if such feature requests help them.
Regarding SANE, Id' rather stick to
http://www3.sane-project.org/contrib.html and keep bug reports for
effective work.

I agree and therefore I wrote

?? why I consider downstream reports good *in addition* to
upstream reports.?

above.

Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130218/fde7d49d/attachment.pgp

[sane-devel] [PATCH] doc/descriptions.txt: Document the `:scsi` keyword

2013-02-15 Thread Paul Menzel

Date: Fri, 15 Feb 2013 12:18:56 +0100

The `:scsi` keyword is introduced in the following commit.

commit acc2b0fccf0c67b5b7851314dce340fdba1cb960
Author: Julien BLACHE jb at jblache.org
Date:   Tue Jan 13 21:17:16 2009 +

Add a new :scsi keyword for SCSI devices, add support for SCSI devices 
in the udev and HAL FDI outputs.
---
Please apply with `git am /path/to/this/mbox`.

 doc/descriptions.txt |   13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/descriptions.txt b/doc/descriptions.txt
index d4cab94..95ed9e1 100644
--- a/doc/descriptions.txt
+++ b/doc/descriptions.txt
@@ -91,6 +91,19 @@ be used if no vendor or product ids are given intentionally, 
e.g. for a group of
 scanners.
 Example: `:usbid 0x1234 0x4321'
 
+`:scsi' defines the SCSI vendor and model name of the device and should be used
+for devices advertising itself as a SCSI processor device, which are not dealt
+with in the wild card rule for SCSI scanner devices advertising themselves
+correctly as a SCSI scanner device.
+(See http://en.wikipedia.org/wiki/SCSI_Peripheral_Device_Type.)
+The keyword has three arguments, which can be retrieved by the `lsscsi' command
+or `udevadm info -a -p /sys/class/scsi_generic/?'. The first one is the vendor 
id,
+the second one theh model name. The third argument has to be `processor'.
+Otherwise `sane-desc` will abort.
+The keyword is optional, and applicable for devices with `:interface SCSI'.
+only, and should be used only once per model.
+Example: `:scsi HP C5110A processor'
+
 The keyword `:status' is an indication of the level of support for the model.
 It's followed by one of the following keyword arguments: `:unsupported',
 `:untested', `:minimal', `:basic', `:good', or `:complete'. The `:status'
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130215/014287f6/attachment.pgp

[sane-devel] [PATCH] backend/hp.c: Remove tautological if condition to remove build warning

2013-02-15 Thread Paul Menzel

Date: Fri, 15 Feb 2013 14:02:42 +0100

Building SANE default configuration with Clang 3.2 the following warning
is generated.

$ clang --version
Debian clang version 3.2-1~exp5 (tags/RELEASE_32/final) (based on LLVM 
3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang ./configure
$ make
[?]
/bin/sh ../libtool --silent  --tag=CC   --mode=compile clang 
-DHAVE_CONFIG_H -I. -I../include/sane -I/usr/local/include -I. -I. -I../include 
-I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=hp 
-DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d   
-DPATH_SANE_DATA_DIR=/usr/local/share   
-DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane   -DV_MAJOR=1 -DV_MINOR=0 
 -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes 
-pedantic -ansi -MT libhp_la-hp.lo -MD -MP -MF .deps/libhp_la-hp.Tpo -c -o 
libhp_la-hp.lo `test -f 'hp.c' || echo './'`hp.c
hp.c:590:7: warning: variable 'new' is used uninitialized whenever 'if' 
condition is false [-Wsometimes-uninitialized]
  if (!ptr)
  ^~~~
hp.c:601:59: note: uninitialized use occurs here
  RETURN_IF_FAIL( hp_device_list_add(global.device_list, new) );
  ^~~
./hp.h:83:25: note: expanded from macro 'RETURN_IF_FAIL'
  SANE_Status status = (try);   
\
^
hp.c:590:3: note: remove the 'if' if its condition is always true
  if (!ptr)
  ^
hp.c:563:15: note: initialize the variable 'new' to silence this warning
  HpDevice  new;
   ^
= NULL
1 warning generated.

And indeed the `if` condition is always true as the `for` loop only
exists if `ptr` is `NULL`.

The proposal to silence the warning by setting `new` to NULL is not used
as then a NULL device would be added to the device list in
`RETURN_IF_FAIL( hp_device_list_add(global.device_list, new) );`.
---
 backend/hp.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/backend/hp.c b/backend/hp.c
index c85e40c..5810254 100644
--- a/backend/hp.c
+++ b/backend/hp.c
@@ -587,13 +587,10 @@ hp_get_dev (const char *devname, HpDevice* devp)
   DBG(3, hp_get_dev: New device %s, connect-%s, scsi-request=%lu\n,
   devname, connect, (unsigned long)info-config.use_scsi_request);
 
-  if (!ptr)
-  {
- status =  sanei_hp_device_new (new, devname);
+  status = sanei_hp_device_new (new, devname);
 
- if ( status != SANE_STATUS_GOOD )
-   return status;
-  }
+  if ( status != SANE_STATUS_GOOD )
+ return status;
 
   if (devp)
   *devp = new;
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130215/c7337985/attachment.pgp

[sane-devel] [PATCH v2] backend/hp.c: Remove tautological if condition to address build warning

2013-02-15 Thread Paul Menzel

Date: Fri, 15 Feb 2013 14:02:42 +0100

Building SANE default configuration with Clang 3.2 the following warning
is generated.

$ clang --version
Debian clang version 3.2-1~exp5 (tags/RELEASE_32/final) (based on LLVM 
3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang ./configure
$ make
[?]
/bin/sh ../libtool --silent  --tag=CC   --mode=compile clang 
-DHAVE_CONFIG_H -I. -I../include/sane -I/usr/local/include -I. -I. -I../include 
-I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=hp 
-DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d   
-DPATH_SANE_DATA_DIR=/usr/local/share   
-DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane   -DV_MAJOR=1 -DV_MINOR=0 
 -g -O2 -W -Wall -Wcast-align -Wcast-qual -Wmissing-declarations 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes 
-pedantic -ansi -MT libhp_la-hp.lo -MD -MP -MF .deps/libhp_la-hp.Tpo -c -o 
libhp_la-hp.lo `test -f 'hp.c' || echo './'`hp.c
hp.c:590:7: warning: variable 'new' is used uninitialized whenever 'if' 
condition is false [-Wsometimes-uninitialized]
  if (!ptr)
  ^~~~
hp.c:601:59: note: uninitialized use occurs here
  RETURN_IF_FAIL( hp_device_list_add(global.device_list, new) );
  ^~~
./hp.h:83:25: note: expanded from macro 'RETURN_IF_FAIL'
  SANE_Status status = (try);   
\
^
hp.c:590:3: note: remove the 'if' if its condition is always true
  if (!ptr)
  ^
hp.c:563:15: note: initialize the variable 'new' to silence this warning
  HpDevice  new;
   ^
= NULL
1 warning generated.

And indeed the `if` condition is always true as the `for` loop only
exists if `ptr` is `NULL`.

The proposal to silence the warning by setting `new` to NULL is not used
as then a NULL device would be added to the device list in
`RETURN_IF_FAIL( hp_device_list_add(global.device_list, new) );`.
---
v2: Improve commit message.

Please apply with `git am /path/to/this/mbox`.
 backend/hp.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/backend/hp.c b/backend/hp.c
index c85e40c..5810254 100644
--- a/backend/hp.c
+++ b/backend/hp.c
@@ -587,13 +587,10 @@ hp_get_dev (const char *devname, HpDevice* devp)
   DBG(3, hp_get_dev: New device %s, connect-%s, scsi-request=%lu\n,
   devname, connect, (unsigned long)info-config.use_scsi_request);
 
-  if (!ptr)
-  {
- status =  sanei_hp_device_new (new, devname);
+  status = sanei_hp_device_new (new, devname);
 
- if ( status != SANE_STATUS_GOOD )
-   return status;
-  }
+  if ( status != SANE_STATUS_GOOD )
+ return status;
 
   if (devp)
   *devp = new;
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130215/32aa08e6/attachment.pgp

[sane-devel] [PATCH] backend/plustek-usbscan.c: Fix typo never in history

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 12:12:08 +0100

The following commit

commit b91010f24028e9d634fc93080d71a6727da01ce8
Author: Gerhard Jaeger gerhard at gjaeger.de
Date:   Wed Feb 13 10:31:22 2013 +0100

Cleanup, fix compilation warning conditions.

introduced that typo, which is now fixed.
---
Please apply this patch by saving this message as a mbox file and then
do

$ git-am path/to/saved/mbox

 backend/plustek-usbscan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/backend/plustek-usbscan.c b/backend/plustek-usbscan.c
index 848968e..c8824fc 100644
--- a/backend/plustek-usbscan.c
+++ b/backend/plustek-usbscan.c
@@ -29,7 +29,7 @@
  *- changed usb_MapDownload prototype
  * - 0.50 - cleanup
  * - 0.51 - added usb_get_res() and usb_GetPhyPixels()
- * - 0.52 - removed stuff, that will most probably nver be used
+ * - 0.52 - removed stuff, that will most probably never be used
  * .
  * hr
  * This file is part of the SANE package.
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/2eb068e4/attachment.pgp

[sane-devel] [PATCH] backend/plustek-usbdevs.c: Remove trailing whitespace

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 12:17:09 +0100

The following commit introduced two trailing whitespace errors.

commit 00167c20c53885c062c0e427b4141d1ac6994144
Author: Gerhard Jaeger gerhard at gjaeger.de
Date:   Wed Feb 13 10:32:28 2013 +0100

Added support for Q-Scan A6 - see bug report #312073
---
1. Please apply this patch again with `git am path/to/mbox/file`.
2. Three remarks, regarding the above commit message.
   a) Normally the imperative should be used instead of past simple. The
Linux kernel is doing that for example. And more logically the automatic
messages by Git command do the same [1].
   b) As Hiroshi seems to have done the major part of the port, it would
have been nice to preserve that metadata.

  git commit --amend --author=Hiroshi Miura miurahr at linux.com 
--date=Mon Nov 9 06:37:52 2009 +0900

   c) Alioth URLs are a pain (at least to me). At least I do not know
how easily finding the report. So adding the URL additionally [2] would
save time.

[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[2] 
http://alioth.debian.org/tracker/index.php?func=detailaid=312073group_id=30186atid=410366
---
 backend/plustek-usbdevs.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/backend/plustek-usbdevs.c b/backend/plustek-usbdevs.c
index 2327b3e..a993e41 100644
--- a/backend/plustek-usbdevs.c
+++ b/backend/plustek-usbdevs.c
@@ -803,11 +803,11 @@ static DCapsDef Cap0x0A53_0x1000 =
  */
 static DCapsDef Cap0x0A53_0x2000 =
 {
-   {{ 0,   0},   0, -1, {1226, 3508}, { 50, 50 }}, 
+   {{ 0,   0},   0, -1, {1226, 3508}, { 50, 50 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
-   {600, 600},  
+   {600, 600},
DEVCAPSFLAG_SheetFed,
SENSORORDER_rgb,
4,
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/a93d5991/attachment.pgp

[sane-devel] [PATCH] backend/plustek-usbhw.c: Replace 20013 by 2013 in copyright notice

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 13:00:31 +0100

The following commit

commit 00167c20c53885c062c0e427b4141d1ac6994144
Author: Gerhard Jaeger gerhard at gjaeger.de
Date:   Wed Feb 13 10:32:28 2013 +0100

Added support for Q-Scan A6 - see bug report #312073

updated the copyright years and introduced a typo. Fix this.
---
Please apply with `git am path/to/mbox/file`.

 backend/plustek-usbhw.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/backend/plustek-usbhw.c b/backend/plustek-usbhw.c
index c0e6090..a1dae68 100644
--- a/backend/plustek-usbhw.c
+++ b/backend/plustek-usbhw.c
@@ -7,7 +7,7 @@
  *  @brief Functions to control the scanner hardware.
  *
  * Based on sources acquired from Plustek Inc.br
- * Copyright (C) 2001-20013 Gerhard Jaeger gerhard at gjaeger.de
+ * Copyright (C) 2001-2013 Gerhard Jaeger gerhard at gjaeger.de
  *
  * History:
  * - 0.40 - starting version of the USB support
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/7de29b17/attachment.pgp

[sane-devel] [PATCH v2] backend/plustek-usbdevs.c: Remove trailing whitespace

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 12:17:09 +0100

The following commit introduced two trailing whitespace errors.

commit 00167c20c53885c062c0e427b4141d1ac6994144
Author: Gerhard Jaeger gerhard at gjaeger.de
Date:   Wed Feb 13 10:32:28 2013 +0100

Added support for Q-Scan A6 - see bug report #312073
---
v2: Remove second signature line ---.

1. Please apply this patch again with `git am path/to/mbox/file`.
2. Three remarks, regarding the above commit message.
   a) Normally the imperative should be used instead of past simple. The
Linux kernel is doing that for example. And more logically the automatic
messages by Git command do the same [1].
   b) As Hiroshi seems to have done the major part of the port, it would
have been nice to preserve that metadata.

  git commit --amend --author=Hiroshi Miura miurahr at linux.com 
--date=Mon Nov 9 06:37:52 2009 +0900

   c) Alioth URLs are a pain (at least to me). At least I do not know
how easily finding the report. So adding the URL additionally [2] would
save time.

[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[2] 
http://alioth.debian.org/tracker/index.php?func=detailaid=312073group_id=30186atid=410366

 backend/plustek-usbdevs.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/backend/plustek-usbdevs.c b/backend/plustek-usbdevs.c
index 2327b3e..a993e41 100644
--- a/backend/plustek-usbdevs.c
+++ b/backend/plustek-usbdevs.c
@@ -803,11 +803,11 @@ static DCapsDef Cap0x0A53_0x1000 =
  */
 static DCapsDef Cap0x0A53_0x2000 =
 {
-   {{ 0,   0},   0, -1, {1226, 3508}, { 50, 50 }}, 
+   {{ 0,   0},   0, -1, {1226, 3508}, { 50, 50 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
{{ 0,   0},   0,  0, {0, 0}, { 0, 0 }},
-   {600, 600},  
+   {600, 600},
DEVCAPSFLAG_SheetFed,
SENSORORDER_rgb,
4,
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/cd081bb0/attachment.pgp

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

2013-02-13 Thread Paul Menzel

Bonjour Gerard,

Am Dienstag, den 12.02.2013, 20:53 +0100 schrieb contact adbdr:
Gutenabend Gerhard und Paul,

a small spelling mistake: it is ?Guten Abend?. ;-)

Some answers after Gerhard Jaeger's mail:
-It never occurs before the third scan, but sometimes only the fourth
scan is bad.
-The resolution does not seem to have any influence.

That is good to know.

And an answer to Paul Menzel
-I have to compress the log because the mail has to remain below 100k,
otherwise it is rejected by the alioth mail handler

That is what I guess. Maybe it could be increased to 1 MB.

Additional information:

Setting in plustek.conf the binary in
option altCalibration 0
to 1
has the result that the problem cannot be reproduced.

Wow. Nice find. Could you please update the bug report in Alioth with
that information?

Scanning with valgrind active, as proposed by Paul Menzel, makes the
process very slow,

That is expected as Valgrind checks all memory accesses.

and also has the result that the problem cannot be reproduced.

Wow. I guess Valgrind somehow is able to fix the wrong accesses.

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck
--leak-check=full --num-callers=50 --track-origins=yes --log-file=`date
+%Y%m%d-%H%M%S`--simple-scan--valgrind.log simple-scan

I selected two logs, the first with 'option altCalibration 1'
the second with 'option altCalibration 0' in which case the problem is
supposed to show up.
But after gzip these are over 80k and the result is that a mail
containing either the one or the other is rejected, so I need
instructions as to how to transmit these.

Solving this issue by attaching the files to the Alioth bug entry
#314019 [1] was a great idea.

As the problem can't be reproduced while valgrind logs, I wonder whether
there is any use in doing the same with an 32 bit OS.

I guess it is not necessary.

Just for the record for list or archive readers, there ware some
follow-ups on the Alioth report #314019 too [1].

Thanks,

Paul

[1]
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314019group_id=30186
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/0418dcd8/attachment.pgp

[sane-devel] [PATCH v2] backend/plustek-usbdevs.c: Remove trailing whitespace

2013-02-13 Thread Paul Menzel

Dear Gerhard,

Am Mittwoch, den 13.02.2013, 13:56 +0100 schrieb Gerhard J?ger:

On Wednesday 13 February 2013 13:25:41 Paul Menzel wrote:
Date: Wed, 13 Feb 2013 12:17:09 +0100

The following commit introduced two trailing whitespace errors.
[...]
1. Please apply this patch again with `git am path/to/mbox/file`.
2. Three remarks, regarding the above commit message.
a) Normally the imperative should be used instead of past simple. The
Linux kernel is doing that for example. And more logically the automatic
messages by Git command do the same [1].
b) As Hiroshi seems to have done the major part of the port, it would
have been nice to preserve that metadata.
[...]

to be honest, I struggled with myself before writing this mail and I
do not want to start any kind of flame war. But I'm not sure if
I now should say thank you for the patches or simply reply with
*PLONK*

the patches clean the code. So why *PLONK*?

I'm not sure how many hours I've spent on that damned code and the
last thing I would like to see is a sh... comment wrt (2) or some
educational corrections to me or anybody else on this list.

Real help is appreciated, patches are welcome, education in any
direction is counteractive.

Come on, you are basically saying that you are not willing to learn and
prefer wasting time by not using the tools correctly (`git show`) and by
even making commits worse and spending time on editing them instead of
doing `git am` three times and `git push`.

I even told you the commands and spend my time fixing errors introduced
with your commits. Believe me that such review and clean up work is not
very entertaining and satisfying either. Taking time to explain stuff to
others too.

Thanks,

[sane-devel] [PATCH] hp.desc: Mark HP ScanJet 6100C as SCSI device type 3

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 17:26:24 +0100

According to the blog post of jhansonxi [1] the HP ScanJet 6100C
advertises itself as a processor device by using the value 3 for the
SCSI Peripheral Device Type [2].

$ more 
/devices/pci:00/:00:1e.0/:01:01.0/host4/target4:0:5/4:0:5:0
KERNELS==4:0:5:0
SUBSYSTEMS==scsi
DRIVERS==
ATTRS{device_blocked}==0
ATTRS{type}==3
ATTRS{scsi_level}==3
ATTRS{vendor}==HP 
ATTRS{model}==C2520A 
[?]

Since it is not using the normal value 6 for scanner device [2], this
has to be documented in the description file in the form

:scsi vendor model processor

so that the program `sane-desc` can create the correct udev rules file.

Please note that this commit is for completeness as with Julian Blache?s
commit [3]

commit 9b229f06b9fdca1098d7fb5181731b030fbdfccc
Author: Julien BLACHE jb at jblache.org
Date:   Sun Oct 31 10:20:53 2010 +0100

Add SCSI IDs for ScanJet 4c

the model attribute C2520A is already present in the generated udev
rules file.

[1] 
http://jhansonxi.blogspot.de/2009/08/writing-udev-rules-to-get-scsi-scanner.html
[2] http://en.wikipedia.org/wiki/SCSI_Peripheral_Device_Type
[3] 
http://anonscm.debian.org/gitweb/?p=sane/sane-backends.git;a=commitdiff;h=9b229f06b9fdca1098d7fb5181731b030fbdfccc
---
Please apply with `git am path/to/saved/mbox`.

 doc/descriptions/hp.desc |1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/descriptions/hp.desc b/doc/descriptions/hp.desc
index 8a662c5..d73d286 100644
--- a/doc/descriptions/hp.desc
+++ b/doc/descriptions/hp.desc
@@ -83,6 +83,7 @@
 :model ScanJet 6100C
 :interface SCSI
 :status :complete
+:scsi HP C2520A processor
 
 :model ScanJet 6200C
 :interface SCSI USB
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/626f4e93/attachment-0001.pgp

[sane-devel] [PATCH v2] hp.desc: Mark HP ScanJet 6100C as SCSI device type 3

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 17:26:24 +0100

According to the blog post of jhansonxi [1] the HP ScanJet 6100C
advertises itself as a processor device by using the value 3 for the
SCSI Peripheral Device Type [2].

$ more 
/devices/pci:00/:00:1e.0/:01:01.0/host4/target4:0:5/4:0:5:0
KERNELS==4:0:5:0
SUBSYSTEMS==scsi
DRIVERS==
ATTRS{device_blocked}==0
ATTRS{type}==3
ATTRS{scsi_level}==3
ATTRS{vendor}==HP 
ATTRS{model}==C2520A 
[?]

Since it is not using the normal value 6 for scanner device [2], this
has to be documented in the description file in the form

:scsi vendor model processor

so that the program `sane-desc` can create the correct udev rules file.

Please note that this commit is for completeness as with Julien Blache?s
commit [3]

commit 9b229f06b9fdca1098d7fb5181731b030fbdfccc
Author: Julien BLACHE jb at jblache.org
Date:   Sun Oct 31 10:20:53 2010 +0100

Add SCSI IDs for ScanJet 4c

the model attribute C2520A is already present in the generated udev
rules file.

[1] 
http://jhansonxi.blogspot.de/2009/08/writing-udev-rules-to-get-scsi-scanner.html
[2] http://en.wikipedia.org/wiki/SCSI_Peripheral_Device_Type
[3] 
http://anonscm.debian.org/gitweb/?p=sane/sane-backends.git;a=commitdiff;h=9b229f06b9fdca1098d7fb5181731b030fbdfccc
---
Please apply with `git am path/to/saved/mbox`.

v2: Spell Juli*e*n correctly.

 doc/descriptions/hp.desc |1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/descriptions/hp.desc b/doc/descriptions/hp.desc
index 8a662c5..d73d286 100644
--- a/doc/descriptions/hp.desc
+++ b/doc/descriptions/hp.desc
@@ -83,6 +83,7 @@
 :model ScanJet 6100C
 :interface SCSI
 :status :complete
+:scsi HP C2520A processor
 
 :model ScanJet 6200C
 :interface SCSI USB
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/3854f2f0/attachment.pgp

[sane-devel] [PATCH] epson{, 2}.desc/epkowa.desc: Mark Epson GT-5500 as SCSI device type 3

2013-02-13 Thread Paul Menzel

Date: Wed, 13 Feb 2013 18:41:54 +0100

In Alioth bug #313734 [1] Yann Cantin reported that the Epson GT-5500
advertises itself as a SCSI processor device [2].

Since it is not using the normal value 6 for scanner device [2], this
has to be documented in the description file in the form

:scsi vendor model processor

so that the program `sane-desc` can create a correct udev rules file.

Please note that this commit is for completeness as with Julien Blache?s
commit [3]

commit ed0d09f8635a3004b267892fc00759d15de03aec
Author: Julien BLACHE jb at jblache.org
Date:   Fri Jun 24 22:08:52 2011 +0200

Add wildcard for some Epson scanners

a wildcard rule is added matching on Epson devices containing the string
?SCANNER? in their model name.

[1] 
https://alioth.debian.org/tracker/index.php?func=detailaid=313734group_id=30186atid=410366
[2] http://en.wikipedia.org/wiki/SCSI_Peripheral_Device_Type
[3] 
http://anonscm.debian.org/gitweb/?p=sane/sane-backends.git;a=commitdiff;h=ed0d09f8635a3004b267892fc00759d15de03aec
---
Please apply with `git am path/to/this/mbox`.

 doc/descriptions-external/epkowa.desc |1 +
 doc/descriptions/epson.desc   |1 +
 doc/descriptions/epson2.desc  |1 +
 3 files changed, 3 insertions(+)

diff --git a/doc/descriptions-external/epkowa.desc 
b/doc/descriptions-external/epkowa.desc
index c31c9d4..2c91d2d 100644
--- a/doc/descriptions-external/epkowa.desc
+++ b/doc/descriptions-external/epkowa.desc
@@ -520,6 +520,7 @@
 
 :model GT-5500
 :interface SCSI
+:scsi  EPSON SCANNER GT-5500 processor
 :status:good
 
 :model GT-6000
diff --git a/doc/descriptions/epson.desc b/doc/descriptions/epson.desc
index a31fc84..7cfb874 100644
--- a/doc/descriptions/epson.desc
+++ b/doc/descriptions/epson.desc
@@ -47,6 +47,7 @@
 
 :model GT-5500
 :interface SCSI
+:scsi EPSON SCANNER GT-5500 processor
 :status :good
 
 :model GT-6500
diff --git a/doc/descriptions/epson2.desc b/doc/descriptions/epson2.desc
index 5f2ddd3..a4d4c38 100644
--- a/doc/descriptions/epson2.desc
+++ b/doc/descriptions/epson2.desc
@@ -337,6 +337,7 @@
 
 :model  GT-5500
 :interface  SCSI
+:scsi   EPSON SCANNER GT-5500 processor
 :status :good
 
 :model  GT-6000
-- 
1.7.10.4
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/e5e7fd66/attachment.pgp

[sane-devel] Git best practices for proper application of patches

2013-02-12 Thread Paul Menzel

Am Montag, den 11.02.2013, 16:31 -0500 schrieb m. allan noah:
Sane is an ancient project by FLOSS standards, and in those many
years, has developed some bad habits. Some of these are by necessity,
as it is difficult or impossible to properly review code for hardware
you don't have. Some of these habits are by choice- most of us would
rather use our limited hours to write code for hardware we do have,
than write docs or sometimes even update tickets. We get enough
'proper' procedure in our day jobs :) We also have a massive number
of developers who have moved on to other interests, yet their backends
are still (marginally) supported by the sane project. This increases
the burden on the remaining devs somewhat.

All-in-all, sane is a bit of a mess. I'll be the first to take the
blame for that, as I have not done a good job recruiting new devs, and
I have not kept up with all the housekeeping duties. Releases are
sporadic, bugs are not assigned, known issues to core infrastructure
are not fixed, and sometimes moderated emails sit for a day or two
before I get a chance to review them. So, I am acutely aware of your
concerns, and agree with some of them.

I am certainly in no position to tell you what to do. You should
consider my messages as a view point from some FLOSS user trying to fix
a thing a bug in SANE and while at it trying to improve the things I
notice.

If you get feedback from non SANE developers often, then fine. But
people will notice them again and again and get a bad first impression.

So to your points above, in my opinion one has to enforce some policy
nevertheless because in the end it will bite everyone later on.

Proper commit messages (summary, empty line, message body with
description) will even save time of writing that ChangeLog file, you can
easily generate from `git log --format=oneline` (plus some arguments) as
other projects are doing.

However, I do NOT like your methods. It appears that you know very
little about sane, its protocol, or it's history.

I am the first to admit that. Why should I need to know about that,
wanting to submit a bug fix?

Yet you find it necessary to ask bug-reporting end users for an
education (when their request is perfectly clear) [1],

As commented, I do not see a problem with asking questions. If you do, I
am sorry for violating some rule I do not know about. The reporter
always has the choice to answer or not to answer.

you give incorrect information in the bug tracker [2][3],

As I already answered to Stef, my statement was not absolute and indeed
is partly true and in [3] I asked a question after searching for that on
the Web.

and you waste the bug reporters time asking them to provide useless
data like a description of the scanner or a pointless downstream bug
report [4].

Are you involved in packaging stuff. I am involved in the Debian project
and having downstream and upstream reports is certainly appreciated
there. (That is another problem: communication between upstream and
packagers.)

So, how about you talk less, and code more.

The same I could say to you, how about you accept criticism and not be
offended by it ? as when people are offended, most of the time they know
the criticism is justified ?, also talk less by writing these answers
and enforce some sane development guidelines for SANE living up to the
current standards in other projects so that people just wanting to
contribute some small fixes feel welcome and can use the methods they
are used to from other projects?

Get the patches you submitted to completion (so otherwise busy folks
like stef don't have to do it for you).

He never needed to complete it for me. He could also have told me, that
it is incomplete and I would have fixed it. It was his choice to do as
he did.

Find some more bugs in the tracker to produce patches for. Be prepared
to spend your own money to buy scanners just so you can verify your
code. Then, consider picking up one of the unmaintained backends. That
is how the rest of us got started. Once you reach that point, you will
have a much better understanding about what the problems are with
SANE, and you will be in a better position to help correct them.

I certainly never had and do not have any intention to become a SANE
developer. (And I guess that is also good for Stef, you and myself. ;-))

Seeing that my intended help causes more harm than good, I am going to
only find the cause of the Simple Scan crash my parents experience with
the HP Photosmart 2610 and will not disturb you any longer.

Good luck to you all and SANE.

Thanks,

Paul

[1]
https://alioth.debian.org/tracker/?func=detailatid=410366aid=313734group_id=30186
[2]
https://alioth.debian.org/tracker/index.php?func=detailaid=314021group_id=30186atid=410366
[3]
https://alioth.debian.org/tracker/index.php?func=detailaid=314019group_id=30186atid=410366
[4]
http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030902.html

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

2013-02-12 Thread Paul Menzel

Dear Gerard,

Am Dienstag, den 12.02.2013, 09:20 +0100 schrieb contact adbdr:

Thank you for the serious folluw-up. Here the answers on three points

thank you for resending it to the list. Did you have to compress the log
file because of size limitations of the list?

In Simple Scan does that happen also when clicking on ?New? after every scan?

yes, and also if I change between texte and photograph

Simple Scan stores a log file under `~/.cache/simple-scan/`. Do you see
any interesting in there?

I enclose the file as there is some opening error

If you mean

GDBus.Error:org.freedesktop.ColorManager.Failed: property match
'Serial'='sane:plustek:libusb:003:004' does not exist

then that is harmless. Colord [8] is a daemon making it possible to
manages colors between input and output devices.

I do not see any interesting either in the Simple Scan log file.

What is the behavior using `scanimage` (`man scanimage`)?

$ scanimage image.pnm # repeat three times

As expected, as after restarting xsane, the pages are clean, and the
process takes time because of the lamp-timer but

scanimage -d plustek:libusb:003:004 --batch-count 4 --batch-prompt -l 0 -t 0
-x 215 -y 297 image.pnm

makes the problem show up, both pages 3 and 4 are bad.

Interesting. Thank you for confirming this.

As to using Valgrind, this will take some more time to obtain a result

You can also use Simple Scan for that if that is easier under Fedora.

Until someone more knowledgeable than me has time to deal with this,
that is my last hope to find some clue where something goes wrong.

It is very strange that the bug shows up after two scans.

Oh, last thing that comes to my mind. Does the problem depend also on
the resolution? If you take a higher resolution, does the problem start
to occur earlier or later?

These are just guesses. So please do not have too high hopes.

[?]

Thanks,

Paul

[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
[2]
https://alioth.debian.org/tracker/index.php?func=detailaid=314019group_id=30186atid=410366
[3] http://live.debian.net/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=909551
[5]
https://alioth.debian.org/tracker/index.php?func=detailaid=304296group_id=30186atid=410366
[6] http://www.sane-project.org/sane-backends.html#S-PLUSTEK
[7] http://www.gjaeger.de/scanner/plustek/
[8] http://www.freedesktop.org/software/colord/intro.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130212/27fd83ad/attachment.pgp

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

2013-02-11 Thread Paul Menzel

Dear G?rard,

thank you for following up on the sane-devel mailing list.

Could you please make sure not to send any HTML message, and just plain
text, as this is what the netiquette suggests [1].

Am Sonntag, den 10.02.2013, 10:55 +0100 schrieb G?rard van der Veen:
I entered a bug in the tracker

please always mention the bugs right away. G?erard means issue #314019
[2] in the Alioth bug tracker.

and got a comment by Paul Menzel
https://alioth.debian.org/users/paulepanter-guest/:
I think the tracker is not used a lot anymore by the current developers.
Please bring your issue up to the sane-devel list

As Allan commented in the tracker issue (Alioth unfortunately does not
offer to reference certain comments.), my statement was incorrect. The
tracker is still used. But as Stef wrote to the sane-devel list,
bringing issues up to the list is fine too.

As the problem is absent in sane 32-bit, and permanent in 64-bit, it
could well be a development issue.
in the tracker it reads:

[#314019] my scanner has a problem in the 64-bit systems but works
fine with the same systems in 32 bit

Scanning several pages with my flatbed scanner works fine for the first
two pages; the subsequent pages will have wide coloured vertical bands
in the background (black for a grayscale scan).

This is true for the 64-bit versions of Fedora 16, 17 and 18; with the
32-bit versions of the mentioned distributions there is no problem.
Scanning using xsane or simple-scan produce both the misbehaviour.

Which versions?

In Simple Scan does that happen also when clicking on ?New? after every
scan?

Simple Scan stores a log file under `~/.cache/simple-scan/`. Do you see
any interesting in there?

After leaving the graphical fronted and it's restart one can again scan
two pages properly.

What is the behavior using `scanimage` (`man scanimage`)?

$ scanimage image.pnm # repeat three times

Version details are (here with Fedora 17):
Linux 3.7.3-101.fc17.x86_64
sane-frontends-1.0.14-14.fc17.src.rpm
sane-backends-1.0.23-4.fc17.src.rpm
idem libs and drivers-scanners

As you only tested Fedora stuff, could you use a 32-bit and 64-bit live
image of a different distribution like Debian [3] and try to reproduce
the issue there? That would be awesome.

scanimage -L
device `plustek:libusb:003:003' is a Epson Perfection 1250/Photo flatbed
scanner

joined the scan of an empty, white but not very clean, A4 sheet, scanned
as n? 3 after startup of xsane.

The workaround is to stay in a 32-bit OS

submitted also at bugzilla.redhat.com for fedora with the id 909551

Please always add URLs too. In this case the URL is [4].

comparing the joined file with the one joined with 304296 (08/04/2007 -
not solved yet)

The URL is [5].

and the problem description there with this one, the similarity is
striking:
1. the coloured bands are similar
2. OK with the 32 bit OS Gentoo, problem with the same OS in 64 bit

Ok, sorry for the suggestion of using a different distribution above. It
looks like it is an upstream problem and no packaging problem.

but the scanners are of different models (but may use the same chip)

Hmm, the SANE Web site should provide that information. Anyway you have
an Epson Perfection 1250/Photo and the reporter using Gentoo uses an
Epson Perfection 1260/Photo, so they probably have the same chip. And
indeed, from the supported scanners page [6] going to the Plustek
backend page [7], the table there shows, that both use the chip LM9832.

the OS's are different distributions

By the way, nice work for digging up that old bug #304296.

G?rard, I am not sure how to proceed. I smells like a Plustek backend
problem.

Besides looking through the code, I have only the following suggestion.

Could you try to run Simple Scan or, if issue is reproducible with
`scanimage`, `scanimage` under Valgrind? You have to install all the
debugging packages for that. I think Fedora has a command for installing
these, but I am not sure as I am not using it.

Please run the following under 32-bit and 64-bit and attach it to your
reply.

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck
--leak-check=full --num-callers=50 --track-origins=yes --log-file=`date
+%Y%m%d-%H%M%S`--simple-scan--valgrind.log simple-scan

Maybe Valgrind can find something or give a hint.

Thanks,

Paul

[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
[2]
https://alioth.debian.org/tracker/index.php?func=detailaid=314019group_id=30186atid=410366
[3] http://live.debian.net/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=909551
[5]
https://alioth.debian.org/tracker/index.php?func=detailaid=304296group_id=30186atid=410366
[6] http://www.sane-project.org/sane-backends.html#S-PLUSTEK
[7] http://www.gjaeger.de/scanner/plustek/
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally

[sane-devel] Git best practices for proper application of patches

2013-02-11 Thread Paul Menzel

Dear SANE developers,


sorry for complaining again, but I am quite upset.

I was happy to see, that two of my bug reports I submitted to the Alioth
bug tracker were marked as ?Fixed?.

1. [sane-Bugs][314012] Cppcheck: [tools/sane-desc.c:619]: (error) Memory leak: 
word [1]
2. [sane-Bugs][314013] tools/sane-desc.c: Trailing whitespace [2]

Running `git remote update` in my sane-backends Git clone, I was became
upset seeing just the following commit.

commit e7804700f64660aedaff2aa5a429c4ed05031d78
Author: St?phane Voltz stef.dev at free.fr
Date:   Mon Feb 11 07:55:43 2013 +0100

minor fixes to sane-desc.c
- memleaks on error paths
- whitspaces at end of line

And I want to explain why, so you can hopefully understand me.

First, I spent several minutes to compose a proper commit messages and
attached them to the reports [1][2]. So afterward this time is now
*wasted*! We all have the same problem, that time is the most precious
thing Free Software developers/activists have as we are mostly involved
in several projects.

Second, commits like that ? and looking through the Git commit history
of SANE unfortunately all commits are similar to that as already stated
in my message ?[sane-devel] Current project status? [3] ? violate basic
software development practices which popular projects like the Linux
kernel follow.

a) One commit for one change.

Why? ?) Because distributions can then backport patches more easily with
`git cherry-pick`.

?) Besides that whitespace changes are always a nuisance, please look at
the commit and find out what the memory leak is! (Right, ignoring
whitespace changes with some git switch would work, but people do not
always have a checkout handy, so please find it in the Gitweb overview
or in the message to the SANE commit list! So people *waste* time to
understand a commit which has to be avoided.

b) Proper commit messages, which means a commit summary and a detailed
and elaborate description/explanation of the commit in the commit
message body. The OpenStack Git commit message page [5] sums the points
up quite nicely in my opinion. See also the pages [6] and [7].

   It is important to know how a bug was found, if it caused any issues
and how it is fixed. Most of the time this is present in the bug report,
so it needs to be referenced in the commit message!

   Referencing the bug report is also crucial as you cannot ? well you
could, but it is bad practice for public branches ? change commit
messages in public branches. So people needing to comment on the change
should easily find the bug report or mailing list thread.

   And no, it is not enough to just reference the bug report by saying:
?It contains all information.?. The developer preparing the commit now
knows what the problem is and what the fix does. Some days later (or a
year later) even the developer will not remember what happened. So
reading the code and the *whole* bug report would be needed to find out
that information. This takes people not involved with that change
longer! Again, please save everyone some time, and write a proper commit
message with all necessary information to understand the commit!

   Lastly, this is necessary for proper review. If I am not mistaken,
currently SANE does not have a proper review process and each backend
maintainer can commit whatever she or he wants. Good commit messages
would help the reviewer to check the correctness of the patch. If the
author writes something in the commit messages she or he thinks what
should have been accomplished, the reviewer can check against that and
find out if the code lives up to that requirement. Otherwise the
reviewer cannot verify that.


Therefore, for one please download attached patches for example created
with `git format-patch -1` and apply them with

git am path/to/downloaded/file

which will keep the author information and set up the committer
information. Then maybe fix up some stuff with `git commit --amend` in
the commit message and then push it.

And *enforce* these rules in the SANE project by rejecting patches not
following these guidelines. SANE is big enough that proper patches are
crucial to not introduce regressions and to make it easy for sporadic
developers to get an overview over latest developments.

I hope I do not step on anyone toes, but in my opinion such things are
*very* important for FLOSS projects or any software project!


Thanks and sorry for another long post,

Paul


[1] 
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314012group_id=30186
[2] 
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314013group_id=30186
[3] 
http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/030888.html
[4]

[sane-devel] Git best practices for proper application of patches

2013-02-11 Thread Paul Menzel

Dear Stef,

sorry for stepping on toes. I do not want to fight and want the SANE
project to prosper!

Am Montag, den 11.02.2013, 20:32 +0100 schrieb stef:
Le 11/02/2013 11:15, Paul Menzel a ?crit :

[?]

if you are upset because attribution for the trailing whitespace
removal, I can consider that.

That was another side effect, which I do not care much about. Though it
is also good development practice to know the author. Git stores the
committer too and you can display it for example using `git log
--format=fuller`.

But #314012, is incomplete, I should have rejected as such (and not
marked it fixed). Since cppcheck seems to bail out on the first
occurence of the same memleak in a function, you have to rerun it after
fixing each error to get sure everything is fine like I did. So it is
clearly my work.

I am sorry that I do not have a crystal bowl handy telling me what you
did. You should have simply told me by replying to the bug report or
mention it in the commit message. There is no problem with patches being
incomplete ? though I admit it would be better that they are not. That
is review good for. So thank you for completing that fix.

Like it was to set up a test script, take reference
data and test, to ensure there is no regression in sane-desc.

So? Please document how you do regression tests and publish that script.

[The following should have been a separate thread. Mixing discussions
wastes time too.]

By
- asking to rename the list because you didn't pay attention to its notice

Would you please read my message again! You clearly did not understand
it!

- thinking I am the project leader while it is Allan (who is doing a
great job BTW)

And what is the problem about that? Where could I have found out besides
that he did the latest release(s)?

Besides such terms being not very clear, looking at the commit log you
clearly are doing a lot of coding too, so you I would consider you part
of the ?core developers?.

- telling bug tracker is not used

Quoting my comment in #314019 [1] (Alioth-URLs are insane):

I think the tracker is not used a lot anymore by the current
developers.

So I stated that I might be wrong. Additionally you told me beforehand
on the list, that you do not use it a lot.

- going ballistic on such mundane thing than a few extra spaces

Sorry, what are you referring to?

- teaching lesson on bug reporting to someone that has already went
through the hassle of registering to the bug tracker and posting to the list
you're neither building cooperation nor helping us.

Sorry, again I do not understand what you are referring you. The reason
might very well be that English is not my native language.

I didn't expect to have burning so much of my free time on such
activities tonight, when I planned to work on a LiDE60 bug. I still
think you are welcome provide you stay constructive.

I very much try to stay constructive. Even though I have the impression
you are getting quite hostile for no reason as your points above are
incorrect in my opinion. And I am very much trying to be polite.

It looks like you have the same view towards myself.

So let?s hope, that most of this is all a misunderstanding.

Did you get notice of yesterday's comments on #314014 and #314015 ?
There is real work to do on these.

Sure. (Though Alioth notification message are not very helpful (muddled,
no threading.)

My parents use GNU/Linux and that HP Photosmart 2610 device. So first I
will respond when I have access again and second there are enough bugs
in all kind of programs needing to be fixed so my parents are not upset.

Thanks,

Paul

[1]
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314011group_id=30186
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130211/32eeb8c7/attachment.pgp

[sane-devel] support for Canoscan LIDE 80 expected?

2013-02-10 Thread Paul Menzel

Dear Lorenz,

welcome to the sane-devel list!

Am Samstag, den 09.02.2013, 20:43 +0100 schrieb Lorenz Wiedemann:

is there any chance of adding Canoscan LIDE 80 to the SANE backends,

There is always a chance! ;-) Please try to save subscribers time and
provide URLs to the scanners description page! In this case it is [1].
And there is even a dedicated Web page for that device. Searching
through the supported scanners list [2], you find that page [3].

so it can be used with Ubuntu ?

Well it depends on the Ubuntu release and if Canonical or the package
maintainers backport support for new devices.

As you use Ubuntu please report a bug to their Launchpad bug tracker [4]
so that they become aware of the missing device support.

Also you should contact Canon and asked them for Linux support.

This isn't a new scanner... but it would be very helpful to use it as
it's giving high quality images (under Win XP).

What about more current Microsoft Windows versions? What driver version
and program do you use under Microsoft Windows XP?

lsusb says it has the ID 04a9:2214, GL842 in it (not 841).

Please compare the information on the SANE Web page for Canon LiDE 80
[3] with the device you have. Just to be sure.

scanimage -L and sane-find-scanner do not recognize it.

As the Web page says, the device is unsupported. I do not know if
somebody is working on the SANE Genesys currently as I just looked into
SANE too.

Besides the actions above, you can read the Contribute Web page [5] for
further information on what to do.

Installing Canon software under Wine / Ubuntu works, but there is no
scanner/device present to be chosen.

You could also try running Microsoft Windows in some virtualization
software like KVM, XEN, ?.

Thanks and sorry for not giving you better news,

Paul

[1]
http://www.canon.de/Support/Consumer_Products/products/scanners/LiDE_series/CanoScan_LiDE_80.aspx
[2] http://www.sane-project.org/sane-backends.html
[3] http://www.sane-project.org/unsupported/canon-lide-80.html
[4] https://launchpad.net/sane-backends
[5] http://www.sane-project.org/contrib.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130210/1d54fe04/attachment.pgp

[sane-devel] Infrastructure: Rename sane-devel to sane-discuss

2013-02-08 Thread Paul Menzel

Dear Stef,

thank you for your answer.

Am Donnerstag, den 07.02.2013, 22:04 +0100 schrieb Stef:
On 07/02/2013 12:52, Paul Menzel wrote:

I just subscribed to the list and I am sorry to start with that topic
which has probably already been discussed.

But I was confused to by the -devel suffix and being subscribed to
several other FOSS project lists after reading the Web page [1] I was
surprised that it is also used for user questions.

So to spare potential subscribers from reading the long description on
[1] and to make it apparent from the list name where to subscribe to, I
suggest to rename the list to sane-discuss and forward messages to
`sane-devel` to it for some time.

If that is not possible at all, it would be great if the Mailing lists
Web page [1] could be restructured to have a short overview at the very
top with the descriptions from the Alioth list overview page [2].

[1] http://www.sane-project.org/mailing-lists.html
[2] https://alioth.debian.org/mail/?group_id=30186

this list is about sane development, hence the name.

the description on [1] contradicts your statement.

sane-devel is the main discussion list for SANE (Scanner Access
Now Easy). Despite its name, it's also intended for users.

Since there is no other mailing list for question not directly related
to development, this list is the only place where it can be posted.

Ok.

Having one mailing list is good enough for me.

Also fine.

No need to change name.

As you wrote above despite the original intention or not this list is
used not only for development. So not to confuse interested subscribers
changing the name would be *useful*.

On Alioth the list is described by 'Discussion about SANE (Scanner
Access Now Easy) for users and developers' . Looks good to me.

It looks like you did not understand my message. (Interleaved quoting
style might help with that. ;-)) Anyway, I wrote that I like the short
overview at Alioth better than the long description used at the SANE Web
page [1].

Thanks,

Paul

PS: From other lists I am used to only receive plain text messages.
Could you configure Thunderbird to just send plain text stuff.
Especially as my mobile connection prices are quite high. ;-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130208/358a25cc/attachment.pgp

[sane-devel] Handling of bug reports and patches

2013-02-08 Thread Paul Menzel

Dear Stef,


Am Donnerstag, den 07.02.2013, 22:42 +0100 schrieb Stef:
 On 07/02/2013 12:59, Paul Menzel wrote:

  yesterday I created several new tickets and attached patches to some of
  them, like [1].
 
   [#314016] Cppcheck: [backend/hp-device.c:351,430]: (error) 
  Possible null pointer dereference
 
  Looking at the Git history it looks like though that for example the
  last commit was submitted and discussed on this mailing list, sane-devel
  [2].
 
   commit 883d19145255ca098b89a9c2a5939c69034c98d8
   Author: Rolf Bensch roben-guest at alioth.debian.org
   Date:   Wed Feb 6 22:16:58 2013 +0100
 
   fixed button support for Canon Pixma MG6200
 
  So to know what to do and what the current process is to get patches in,
  should I bring the issues up to this list or should I just wait and
  leave them in the Alioth tracker?

  [1] 
  https://alioth.debian.org/tracker/index.php?func=detailaid=314016group_id=30186atid=410366
  [2] 
  http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/thread.html

  opening a bug and sending a mail, or sending only a mail are OK for 
 me. Opening a bug, may not be enough, specially if it is not affected to 
 anyone, or if it is too broad. The #313848 is a good example, it spans 
 other several backends, is not affected to anybody and has this 
 unattractive comment 'there may be some false positives'.

  Since I have more things to do than time to do it, I'd rather not 
 dig into a big report to see if I have something to fix. And when I (too 
 rarely) look at the issue tracker, I prefer to look into reports that 
 have clear description.

looking at the Git commit log, it looks like you are the main developer.
Even project leader?

So if you feel like that about the bug tracker, could documentation
please be updated, so people do not spend time by registering at Alioth
and use the cumbersome process to enter a ticket and can just contact
the mailing list?


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130208/b19ced50/attachment.pgp

[sane-devel] My patches and issues in Alioth

2013-02-08 Thread Paul Menzel

Dear SANE folks,


could you please take a look at the following Alioth tickets I attached
patches to.

https://alioth.debian.org/tracker/?func=detailatid=410366aid=314011group_id=30186
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314012group_id=30186
https://alioth.debian.org/tracker/?func=detailatid=410366aid=314013group_id=30186

https://alioth.debian.org/tracker/?func=detailatid=410366aid=314014group_id=30186
(not sure about the correctness of the patch)

https://alioth.debian.org/tracker/?func=detailatid=410366aid=314015group_id=30186
(Input of knowledgeable developers appreciated. I am going to bring
it up to the list otherwise.)

https://alioth.debian.org/tracker/?func=detailatid=410366aid=314016group_id=30186


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130208/7485425d/attachment.pgp

[sane-devel] Infrastructure: Rename sane-devel to sane-discuss

2013-02-07 Thread Paul Menzel

Dear SANE folks,


I just subscribed to the list and I am sorry to start with that topic
which has probably already been discussed.

But I was confused to by the -devel suffix and being subscribed to
several other FOSS project lists after reading the Web page [1] I was
surprised that it is also used for user questions.

So to spare potential subscribers from reading the long description on
[1] and to make it apparent from the list name where to subscribe to, I
suggest to rename the list to sane-discuss and forward messages to
`sane-devel` to it for some time.

If that is not possible at all, it would be great if the Mailing lists
Web page [1] could be restructured to have a short overview at the very
top with the descriptions from the Alioth list overview page [2].


Thanks,

Paul


[1] http://www.sane-project.org/mailing-lists.html
[2] https://alioth.debian.org/mail/?group_id=30186
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130207/d156f479/attachment.pgp

[sane-devel] Handling of bug reports and patches

2013-02-07 Thread Paul Menzel

Dear SANE folks,


yesterday I created several new tickets and attached patches to some of
them, like [1].

[#314016] Cppcheck: [backend/hp-device.c:351,430]: (error) Possible 
null pointer dereference

Looking at the Git history it looks like though that for example the
last commit was submitted and discussed on this mailing list, sane-devel
[2].

commit 883d19145255ca098b89a9c2a5939c69034c98d8
Author: Rolf Bensch roben-guest at alioth.debian.org
Date:   Wed Feb 6 22:16:58 2013 +0100

fixed button support for Canon Pixma MG6200

So to know what to do and what the current process is to get patches in,
should I bring the issues up to this list or should I just wait and
leave them in the Alioth tracker?


Thanks,

Paul


[1] 
https://alioth.debian.org/tracker/index.php?func=detailaid=314016group_id=30186atid=410366
[2] 
http://lists.alioth.debian.org/pipermail/sane-devel/2013-February/thread.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130207/e12f905a/attachment.pgp

[sane-devel] Current project status

2013-02-07 Thread Paul Menzel

Dear SANE folks,

a German saying is ?Aller guten Dinge sind drei.? (All good things com
in threes.) [1], which I use to justify spamming you with messages
today. And I promise that this is the last thread starting message for
this Thursday.

TLDR: Sorry for spamming you when just having subscribed.

Trying to investigate a segmentation fault of Simple Scan [2], I ran it
under Valgrind and to my surprise several memory leaks were reported
also in SANE 1.0.22 (Debian Sid/unstable).

Thinking of SANE as one of the crucial projects for the FOSS desktop and
all users depend on it for scanning and its age, I would have expected
it to nearly being bug free after all the testing it is getting.

Then looking at the bug tracker a lot of bugs are open and then I looked
at bug

[#313848] Cppcheck full report

and the Debian Cppcheck project [4] and a lot of possible errors are
reported by the static code analyzer. Valgrind would probably even find
more.

Not to talk only negatively, for most users SANE seems to do the job.
But it looks like there are still some users with problems and
unfortunately that are the reports which people remember when they say,
Microsoft Windows or Apple stuff works better than GNU/Linux desktops.

I guess the answer to why these issues are not dealt with are easy: lack
of developers/contributors. In the end people have to think about their
real life and do not have time anymore. Especially this is hard when the
team is not big.

Other indicators for me as an outsider are only one release per year for
example. As a Debian user I also noticed that Julien Blache does not
seem to have time anymore to maintain the Debian package.

Also looking at the Git commit messages they are very short which is
especially bad for outsiders trying to investigate bugs. The Linux
kernel, the Git project or for example ? shameless plug ? coreboot [5]
require much more elaborate commit messages and at least Linux has a big
community.

I will stop here and come to the topic.

Seeing SANE as a crucial project, should not Canonical (Ubuntu), Suse or
RedHat pay one or several developers to take care about this and to deal
with the reports and developments.

At least infrastructure for continuous integration (build tests) and
static code checks could be provided by them.

My point in the last years a lot of tools have become available for FOSS
projects (or have been improved) so that quality assurance can be done
by machines, so that developers/contributors can focus their time on
development.

Did somebody offer such a service to the SANE project already?

Or do I talk complete nonsense and everything is fine?

Thanks,

Paul

[1] http://de.wiktionary.org/wiki/Aller_guten_Dinge_sind_drei
[2] https://bugs.launchpad.net/bugs/1053616
[3]
https://alioth.debian.org/tracker/index.php?func=detailaid=313848group_id=30186atid=410366
[4] http://qa.debian.org/daca/cppcheck/sid/sane-backends_1.0.22-2.html
[5] http://www.coreboot.org/
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130207/9820bfc6/attachment.pgp

[sane-devel] [PATCH] [RFC] add sanei_usb test program

[sane-devel] [PATCH] [RFC] add sanei_usb test program

[sane-devel] [RFC] move test_wire.c test program away from sanei sudirectory

[sane-devel] HP5400 XPA support patch

[sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update

[sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update

[sane-devel] Support for Benq Scanwit 2720S

[sane-devel] [PATCH] Add support to snapscan for Benq Scanwit 2720S film scanner

[sane-devel] [RFC] Why I consider downstream bug reports a good thing

[sane-devel] [RFC] Why I consider downstream bug reports a good thing

[sane-devel] [PATCH] doc/descriptions.txt: Document the `:scsi` keyword

[sane-devel] [PATCH] backend/hp.c: Remove tautological if condition to remove build warning

[sane-devel] [PATCH v2] backend/hp.c: Remove tautological if condition to address build warning

[sane-devel] [PATCH] backend/plustek-usbscan.c: Fix typo never in history

[sane-devel] [PATCH] backend/plustek-usbdevs.c: Remove trailing whitespace

[sane-devel] [PATCH] backend/plustek-usbhw.c: Replace 20013 by 2013 in copyright notice

[sane-devel] [PATCH v2] backend/plustek-usbdevs.c: Remove trailing whitespace

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

[sane-devel] [PATCH v2] backend/plustek-usbdevs.c: Remove trailing whitespace

[sane-devel] [PATCH] hp.desc: Mark HP ScanJet 6100C as SCSI device type 3

[sane-devel] [PATCH v2] hp.desc: Mark HP ScanJet 6100C as SCSI device type 3

[sane-devel] [PATCH] epson{, 2}.desc/epkowa.desc: Mark Epson GT-5500 as SCSI device type 3

[sane-devel] Git best practices for proper application of patches

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue

[sane-devel] Git best practices for proper application of patches

[sane-devel] Git best practices for proper application of patches

[sane-devel] support for Canoscan LIDE 80 expected?

[sane-devel] Infrastructure: Rename sane-devel to sane-discuss

[sane-devel] Handling of bug reports and patches

[sane-devel] My patches and issues in Alioth

[sane-devel] Infrastructure: Rename sane-devel to sane-discuss

[sane-devel] Handling of bug reports and patches

[sane-devel] Current project status

34 matches

Site Navigation

Mail list logo

Footer information