[sane-devel] Schedule for release of sane-backends 1.0.24

[m. allan noah]

That is one option. The other is to do own own upcasing, as per this patch:

diff --git a/sanei/sanei_init_debug.c b/sanei/sanei_init_debug.c
index 6b50f03..c9571e9 100644
--- a/sanei/sanei_init_debug.c
+++ b/sanei/sanei_init_debug.c
@@ -67,6 +67,19 @@
 #define BACKEND_NAME sanei_debug
 #include "../include/sane/sanei_debug.h"

+/* If a frontend enables translations, the system toupper()
+ * call will use the LANG env var. We need to use ascii
+ * instead, so the debugging env var name matches the docs.
+ * This is a particular problem in Turkish, where 'i' does
+ * not capitalize to 'I' */
+char
+toupper_ascii (int c)
+{
+  if(c > 0x60 && c < 0x7b)
+return c - 0x20;
+  return c;
+}
+
 void
 sanei_init_debug (const char * backend, int * var)
 {
@@ -80,7 +93,7 @@ sanei_init_debug (const char * backend, int * var)
 {
   if (i >= sizeof (buf) - 1)
 break;
-  buf[i] = toupper(ch);
+  buf[i] = toupper_ascii(ch);
 }
   buf[i] = '\0';


On Sun, Aug 25, 2013 at 9:15 PM, Olaf Meeuwissen
 wrote:
>
> m. allan noah writes:
>
>> No, this is a good issue to discuss. I wonder, can the Turkish
>> keyboard make the capitol 'I'? If not, then what is the correct fix?
>
> A lot of string functions do take the current locale into account when
> doing their thing, so the correct fix is to use the right locale before
> calling toupper().
>
> IIRC, backend names are expected to be valid C identifiers which means
> they are ASCII.  Setting the LC_CTYPE to "C" before use of toupper() and
> reverting when done should fix this issue.  Patch attached.
>
>>> [...]
>>> This is due to  limitation of toupper() function w.r.t.  character 'i' when
>>> locale is set to turkish.
>>> As  toupper('i') is 'i' (i.e. still the small i) ,the SANE_DEBUG_RICOH  etc
>>> would not work correctly.
>>>
>>> Root cause:
>>> Env variable set by user as mentioned in the man page is as below
>>> export SANE_DEBUG_RICOH=4
>>>
>>> Sane's search logic's final string generated  for ricoh backend would be
>>> SANE_DEBUG_RiCOH--->note mismatch for i
>>> [...]
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- AVASYS CORPORATION
> FSF Associate Member #1962   Help support software freedom
>  http://www.fsf.org/jf?referrer=1962



-- 
"The truth is an offense, but not a sin"

[sane-devel] A3 flatbed scanners

[m. allan noah]

You did not say how much you are willing to spend, but cheap A3
machines with real SANE support (not some binary garbage) are not very
common. I would be inclined to look for used Fujitsu. Mike Wirth was
offering an fi-4750 just a couple weeks ago.  Even better, there are a
number of used fi-5750C units on ebay.

allan

On Sun, Aug 25, 2013 at 5:07 PM, Dale Amon  wrote:
> I have been perusing the various offerings in the A3 flatbed scanner niche as
> a replacement for my painfully slow Mustek A3 1200Pro, which does not even
> scan the entire 12x17 area, making it actually pretty useless for some
> things.
>
> I can hardly imagine a more experience crew than here on the topic of what
> A3 flatbeds are fast, reliable, give nice sharp images and most importantly
> are well supported. I have looked at entries in the db but before I plop
> down hard cash I'd like advice from people who have already used them.
>
> I am doing archive scanning for the National Space Society and have lots of
> odd sized and sometimes non-bendable things, so I have to use a flatbed for
> those items... I am using the marvelous Fujitsu ScanSnap for pretty much
> anything bendably letter sized.
>
> I was a bit interested in the Plustek OpticPro A320, but it does not seem to
> be supported yet. I'm a bit fed up with Mustek's recent offerings and the
> fact they do not support their older ones on 64b linux... I have to run my
> Mustek off a 32b virtual machine with an ancient copy of sane because they
> do not give you the ability to recompile the driver to run on anything new.
> A few years ago I spent a good bit of money on an HP model whose page feeder
> never worked right... every time you told it to scan it went through several
> pages from the feeder. It became an expensive door stop.
>
>
>
> --
> View this message in context: 
> http://sane.10972.n7.nabble.com/A3-flatbed-scanners-tp17929.html
> Sent from the SANE - Dev mailing list archive at Nabble.com.
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-request at lists.alioth.debian.org



-- 
"The truth is an offense, but not a sin"

[sane-devel] A3 flatbed scanners

[Dale Amon]

On Sun, Aug 25, 2013 at 08:41:58PM -0400, m. allan noah wrote:
> You did not say how much you are willing to spend, but cheap A3
> machines with real SANE support (not some binary garbage) are not very
> common. I would be inclined to look for used Fujitsu. Mike Wirth was
> offering an fi-4750 just a couple weeks ago.  Even better, there are a
> number of used fi-5750C units on ebay.

The answer is 'under $600', and the further the better.

The eBay items you mention seem to fall inside that range and the
scanner does look nice. Only down side is that I was hoping for 12x17
to cover the size of some common (for me) items.

[sane-devel] A3 flatbed scanners

[Dale Amon]

I have been perusing the various offerings in the A3 flatbed scanner niche as
a replacement for my painfully slow Mustek A3 1200Pro, which does not even
scan the entire 12x17 area, making it actually pretty useless for some
things.

I can hardly imagine a more experience crew than here on the topic of what
A3 flatbeds are fast, reliable, give nice sharp images and most importantly
are well supported. I have looked at entries in the db but before I plop
down hard cash I'd like advice from people who have already used them.

I am doing archive scanning for the National Space Society and have lots of
odd sized and sometimes non-bendable things, so I have to use a flatbed for
those items... I am using the marvelous Fujitsu ScanSnap for pretty much
anything bendably letter sized.

I was a bit interested in the Plustek OpticPro A320, but it does not seem to
be supported yet. I'm a bit fed up with Mustek's recent offerings and the
fact they do not support their older ones on 64b linux... I have to run my
Mustek off a 32b virtual machine with an ancient copy of sane because they
do not give you the ability to recompile the driver to run on anything new.
A few years ago I spent a good bit of money on an HP model whose page feeder
never worked right... every time you told it to scan it went through several
pages from the feeder. It became an expensive door stop.



--
View this message in context: 
http://sane.10972.n7.nabble.com/A3-flatbed-scanners-tp17929.html
Sent from the SANE - Dev mailing list archive at Nabble.com.

[sane-devel] sanei_usb_open() and permission denied

[m. allan noah]

Your suggested changes sound fine to me.

allan

On Sun, Aug 25, 2013 at 1:09 PM, Chris Bagwell  wrote:
> Hi all,
>
> This is probably directly more towards St?phane based on recent USB work but
> of interest to all.
>
> The sanie_usb_test.c test is failing on one of my Linux boxes in the
> test_open_all() test... I'd like to get some input on best way to fix this
> failure or if we should fix it at all.
>
> The reason it is failing for me is because this box has a USB wifi module
> that has a report with Vendor Specific Class/Subclass/Protocol and so sane
> adds it to the list as possible scanner.  The open itself fails when ran by
> normal user because its accessable only by root (EACCES).  The open fails
> when ran as root because its already opened by networking stuff (EBUSY).
>
> Because these two cases are kinda soft failures, I was thinking about
> changing the test to simply skip over these opens instead of failing the
> whole test case.  What do you think about this change?
>
> If you agree with that change, the second issue I'll have is that
> sanei_usb_open() seems to treat EPERM as permission denied
> (SANE_STATUS_ACCESS_DENIED) but not EACCES.  Do you see any issues with me
> changing it so both EPERM and EACCES map to SANE_STATUS_ACCESS_DENIED?
>
> If I don't make that change then the EACCES error code is mapped to generic
> SANE_STATUS_INVAL and I can't tell difference between real failures and
> permission failures.
>
> Chris
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-request at lists.alioth.debian.org



-- 
"The truth is an offense, but not a sin"

[sane-devel] sanei_usb_open() and permission denied

[Chris Bagwell]

Hi all,

This is probably directly more towards St?phane based on recent USB work
but of interest to all.

The sanie_usb_test.c test is failing on one of my Linux boxes in the
test_open_all() test... I'd like to get some input on best way to fix this
failure or if we should fix it at all.

The reason it is failing for me is because this box has a USB wifi module
that has a report with Vendor Specific Class/Subclass/Protocol and so sane
adds it to the list as possible scanner.  The open itself fails when ran by
normal user because its accessable only by root (EACCES).  The open fails
when ran as root because its already opened by networking stuff (EBUSY).

Because these two cases are kinda soft failures, I was thinking about
changing the test to simply skip over these opens instead of failing the
whole test case.  What do you think about this change?

If you agree with that change, the second issue I'll have is that
sanei_usb_open() seems to treat EPERM as permission denied
(SANE_STATUS_ACCESS_DENIED) but not EACCES.  Do you see any issues with me
changing it so both EPERM and EACCES map to SANE_STATUS_ACCESS_DENIED?

If I don't make that change then the EACCES error code is mapped to generic
SANE_STATUS_INVAL and I can't tell difference between real failures and
permission failures.

Chris
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130825/0d958d4d/attachment.html>

[sane-devel] scanbd with old udev version

[Sander Devrieze]

2013/8/25 Wilhelm 

> Am 24.08.2013 15:55, schrieb Sander Devrieze:
>
>> 2013/8/22 Sander Devrieze > 
>> Ok, I got everything working as it should. It came out the permissions
>> in /usr/local/etc/scanbd/saned.**conf had to be fixed.
>>
>
> Can you describe what the problem was? Which permission do you mean? Or do
> you mean the access-list?
>

Yes, the access list contained no entries.

>
>  Maybe some note can
>> be added to the documentation?
>>
>
> do you feel the paragraph for saned isn't sufficient?
>

Indeed, the documentation is very good, but it is written for people who
have (much) experience with configuring sane. It will be better if you
write the documentation with people in mind who do not know anything about
sane.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130825/22d0cf76/attachment-0001.html>

[sane-devel] scanbd with old udev version

[Wilhelm]

Am 25.08.2013 11:41, schrieb Wilhelm:
> Am 24.08.2013 15:55, schrieb Sander Devrieze:
>> 2013/8/22 Sander Devrieze > >
>>
>> 
>> I got a bit further this evening:
>>
>> 1) saned not running + /usr/local/sbin/scanbm & sleep 1 &&
>> SANE_CONFIG_DIR=/usr/local/etc/scanbd/ scanimage -L --> found
>> 2) saned not running +/usr/local/sbin/scanbm & sleep 1 && scanimage
>> -L --> not found
>> 3) saned running + scanimage -L --> not found
>> 4) saned running + SANE_CONFIG_DIR=/usr/local/etc/scanbd/ scanimage
>> -L --> found
>>
>> What to try next?
>>
>> Please note I also still getting this error as in the beginning:
>>
>> libudev: udev_monitor_enable_receiving: bind failed: Operation not
>> permitted
>> /usr/local/sbin/scanbd: Can't enable udev receiving
>> /usr/local/sbin/scanbd: Can't init udev
>>
>>
>> Ok, I got everything working as it should. It came out the permissions
>> in /usr/local/etc/scanbd/saned.conf had to be fixed.
>
> Can you describe what the problem was? Which permission do you mean? Or
> do you mean the access-list?
>
>> Maybe some note can
>> be added to the documentation?
>
> do you feel the paragraph for saned isn't sufficient?

ohm just found a typo in the documentation ... it must read saned.conf 
instead of net.conf !

>
>>
>> In attachment you can find my action script which is based on some GPL
>> script I found. Same license applies. For sending the emails, I suggest
>> installing ssmtp if you do not want to setup your own mailserver.
>
> Thank you. Will put this into the contrib dir.
>


-- 
Wilhelm
w.meier at unix.net

[sane-devel] scanbd with old udev version

[Wilhelm]

Am 24.08.2013 15:55, schrieb Sander Devrieze:
> 2013/8/22 Sander Devrieze  >
>
> 
> I got a bit further this evening:
>
> 1) saned not running + /usr/local/sbin/scanbm & sleep 1 &&
> SANE_CONFIG_DIR=/usr/local/etc/scanbd/ scanimage -L --> found
> 2) saned not running +/usr/local/sbin/scanbm & sleep 1 && scanimage
> -L --> not found
> 3) saned running + scanimage -L --> not found
> 4) saned running + SANE_CONFIG_DIR=/usr/local/etc/scanbd/ scanimage
> -L --> found
>
> What to try next?
>
> Please note I also still getting this error as in the beginning:
>
> libudev: udev_monitor_enable_receiving: bind failed: Operation not
> permitted
> /usr/local/sbin/scanbd: Can't enable udev receiving
> /usr/local/sbin/scanbd: Can't init udev
>
>
> Ok, I got everything working as it should. It came out the permissions
> in /usr/local/etc/scanbd/saned.conf had to be fixed.

Can you describe what the problem was? Which permission do you mean? Or 
do you mean the access-list?

> Maybe some note can
> be added to the documentation?

do you feel the paragraph for saned isn't sufficient?

>
> In attachment you can find my action script which is based on some GPL
> script I found. Same license applies. For sending the emails, I suggest
> installing ssmtp if you do not want to setup your own mailserver.

Thank you. Will put this into the contrib dir.

-- 
Wilhelm
w.meier at unix.net

[sane-devel] epson2 backend URL fixes (was: Re: Epson GT-7300U)

[Chris Bagwell]

Applied this patch and your other model patch to git.

Someone else will have to do the HTML part.

Chris


On Sun, Aug 18, 2013 at 10:41 PM, Olaf Meeuwissen  wrote:

> Just pinging the list about the status of the patch I sent mid June.
> Anyone willing to commit?
>
> Olaf Meeuwissen writes:
>
> > Julian H. Stacey writes:
> >
> >> To whoever maintains page:
> >>  http://www.sane-project.org/sane-backends.html
> >> At line found by
> >>  GT-7300U
> >> The URL behind is
> >>  http://avasys.jp/product/linux_driver/index.php
> >> which needs changing as
> >>  - Its Japanese (with an English button) to http://avasys.jp/eng/
> >> & the their:
> >>  2013/01/21Notice of termination of the Linux Driver Download
> Service
> >> So now please point to
> >>  http://download.ebz.epson.net/dsc/search/01/search/searchModule
> >
> > Looks like Julian is talking about the information from the epson2
> > backend.  Please find a patch attached that fixes all the URLs.  If
> > someone with commit privileges could push this (and update the HTML
> > pages) I'd appreciate it.
> >
> > The patch can be applied with `git am`.
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- AVASYS CORPORATION
> FSF Associate Member #1962   Help support software freedom
>  http://www.fsf.org/jf?referrer=1962
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-request at lists.alioth.debian.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130825/a7067494/attachment.html>

[sane-devel] Schedule for release of sane-backends 1.0.24

[viresh]

On Saturday 24 August 2013 10:46 PM, m. allan noah wrote:
> It has been 1 year since our last release, so here we go again:
>
> Timetable:
> Sept 15, 2013: Feature freeze (only bugs, translation and doc updates)
> Sept 22, 2013: Code freeze (only horrible bugs, translation and doc updates)
> Sept 29, 2013: Release
>
> Note, it is highly likely that there are patches from end users which
> we failed to apply. If you know of such a case, please speak up, so we
> can start a dialog about including them in the release.
>
> During the period leading up to the release, it would be helpful if we
> could get some builds on various platforms, and tests done with
> various scanners. The sooner we discover problems, the better.
>
> allan
Hi Allan,

I was wondering if you have any ideas about how we can overcome the 
limitation of toupper() function in libc w.r.t. Turkish language.
This is not a very important item according to my knowledge,but if we 
have any ideas that can be used ,it would be very helpful.
The issue details are as below,
(note that this is related to 
http://lists.alioth.debian.org/pipermail/sane-devel/2013-August/031544.html)
In case of Pardus linux ,Turkish version with XSane frontend, the 
backend does not output debug logs for some backends.
This is due to  limitation of toupper() function w.r.t.  character 'i' 
when locale is set to turkish.
As  toupper('i') is 'i' (i.e. still the small i) ,the SANE_DEBUG_RICOH  
etc would not work correctly.

Root cause:
Env variable set by user as mentioned in the man page is as below
 export SANE_DEBUG_RICOH=4

Sane's search logic's final string generated  for ricoh backend would 
be  SANE_DEBUG_RiCOH--->note mismatch for i

As the code searches for incorrect env. variable, the debug level 
requested by user is ignored.


Transient conclusions:
Current known side effect of the issue is "debug logs will not be 
available for Turkish OS ,with XSane frontend ,for all the backends 
which have character i in their name"

1>Though I have grepped for getenv ,toupper calls in the backend code, I 
believe only the debug related env. variable is affected by language 
localization.
 However I could see SANE_CONFiG_DiR too somewhere in the log but 
could not confirm the side effects due to lack of knowledge of the 
entire code.
 If it's only related to debug logging and nothing else serious we 
can ignore this issue at the moment.
2>As I am not sure about the other similar scenarios, if necessary I can 
send a patch specific to turkish language.
 As I am not an expert on the language I guess the changes would be 
somewhat hardcoded for character i and local TR.If there is any turkish 
member in the group,it would be very much helpful.

Sorry for bugging you with such items when there are many imp patches to 
be covered but just..

--
Viresh