Re: [sane-devel] What does basic support mean on the supported devices page for Plustek Opticbook 3600?

2018-04-09 Thread Olaf Meeuwissen
Hi Alex,

Alex ARNAUD writes:

> Hello all,
>
> I'm trying to help a visual-impaired person that wants to switch to
> GNU/Linux.
>
> He has a Plustek Opticbook 3600 and I found on this page:
> https://www.chiark.greenend.org.uk/doc/libsane/supported.html that the
> support of this device is noted as basic but honestly I don't understand
> what this mean.

The meaning of "basic" and other status classifiers are explained in the
Legend at the bottom of the page.  There's a link near the top, BTW.

> What does basic support for such device mean ?

  basic means it works at least in the most important modes but quality
  is not perfect.

> Is the page I've found correct to check if an hardware is compatible
> with Sane?

The page is not wrong but a bit out-of-date.  Have a look at

  https://sane-project.org/sane-backends.html

for the latest information.  FWIW, the support status of the scanner you
mentioned has *not* changed.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] Alioth Tracker Item → GitLab Issue

2018-03-24 Thread Olaf Meeuwissen
Hi all,

A couple of days ago on sane-devel, I wrote:

> Today Alioth Tracker Item #315943 was submitted.  We now have 1583 bugs
> and 53 feature requests registered at Alioth.  About a quarter of the
> bugs and half of the feature requests is still open.  When Alioth gets
> discontinued (sometime May 2018 for all I know) *all* that information
> will become inaccessible.
>
> I have been looking[1] at transferring these Tracker Items to GitLab
> issues but things on the Alioth side do not look easy (see the issue
> for details).  Currently, I am looking at scraping Alioth for all of
> the information on our Tracker Items and use that to create issues on
> GitLab.  I haven't made up my mind yet about whether to use a special
> "tracker-items" project for that or try to create the issues on the
> right project, i.e. one of backends, frontends or website.  Whichever
> way I decide, issues can be moved between projects on GitLab anyway so
> it's not such a big deal.
>
>  [1]: https://gitlab.com/sane-project/ops/issues/10

I've been able to pull all but two of the Tracker Items we have at
Alioth with the code I pushed to

  https://gitlab.com/sane-project/tracker-migration

The two issues that I have not been able to pull (so far) are both on
the Bugs tracker (310605 and 311568).  For some reason the connection
resets.

Anyway, I have HTML pages and attachments for all 1634 other items.
Next on the agenda is figuring out how to get this on GitLab ;-)

Oh, I'll be monitoring the Alioth Trackers for changes every now and
then.  There's no way to make them read-only :-(

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Alioth deprecation

2018-03-23 Thread Olaf Meeuwissen
Hi Laura, list,

Gerhard Jäger writes:

> Dear Laura,
>
> Thank you for the information and thanks to Olaf we're already in the
> process of moving to gitlab: https://gitlab.com/sane-project
>
> Although not all issues we have with the movement are solved, the
> project is on a good way.

And just how good you can see in the burndown chart and issue lists at

  https://gitlab.com/sane-project/ops/milestones/1

The main issue we still have is with issues, pun intended.  Migrating
our Alioth Tracker Items[1] has turned out to be a bit cumbersome but
I'm making good progress with a website scraper to at least fetch all
Tracker Item content before Alioth goes off-line.

 [1]: https://gitlab.com/sane-project/ops/issues/10

Allan has requested our mailing lists to be migrated and I rsync the
project's home directory just in case.

> On 20.03.2018 at 09:38 Laura Arjona Reina wrote:
>> Hello SANE developers
>>
>> (Please CC me, I'm not subscribed).
>>
>> Thanks for working in making scanning easy!
>>
>> Yesterday I happened to be in the need of downloading and compiling
>> sane-backends in a Debian box, and realised that you (upstream
>> project) use Debian's Alioth for the development management (repos,
>> mailing lists, bug tracker, maybe more).

For what it's worth, I did update our website to point to the GitLab
repositories and issues.  If you find anything wrong in that area,
please submit an issue at

  https://gitlab.com/sane-project/website/issues

Anyway, thanks for letting us know!  And hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Alioth Tracker Item → GitLab Issue

2018-03-20 Thread Olaf Meeuwissen
Hi all,

I just pushed updates to the website that point people to submit issues
against our GitLab projects instead of creating Tracker Items on Alioth.

The GitLab issues have been configured with a wealth of labels:

 - backend/* for every SANE Project supported backend
 - frontend/* for every SANE Project "supported" frontend (that's quoted
   because, sadly?, sane-frontends it all but dead) but please note that
   the scanimage and saned frontends are part of sane-backends (huh?!?)
 - connection/* for network, usb, scsi and parallel connections

In addition there are labels for bugs, feature requests, documentation
and translation issues, build issues, security issues (tick the checkbox
to keep these confidential!), sanei, portability and tools issues,
issues that have a patches and issues needing feedback.  These last two
are colour coordinated with the Doing and To Do labels that are used on
the board(s).  Actually, I have tried to colour coordinate most of the
labels that I think are sort of in the same category.  Of course, any
issue can have more than one label.

# I still would like to add descriptions to the current labels but I
# think that can wait for now.  There's more important stuff to take
# care off!  Read on.

Today Alioth Tracker Item #315943 was submitted.  We now have 1583 bugs
and 53 feature requests registered at Alioth.  About a quarter of the
bugs and half of the feature requests is still open.  When Alioth gets
discontinued (sometime May 2018 for all I know) *all* that information
will become inaccessible.

I have been looking[1] at transferring these Tracker Items to GitLab
issues but things on the Alioth side do not look easy (see the issue
for details).  Currently, I am looking at scraping Alioth for all of
the information on our Tracker Items and use that to create issues on
GitLab.  I haven't made up my mind yet about whether to use a special
"tracker-items" project for that or try to create the issues on the
right project, i.e. one of backends, frontends or website.  Whichever
way I decide, issues can be moved between projects on GitLab anyway so
it's not such a big deal.

 [1]: https://gitlab.com/sane-project/ops/issues/10

# Tomorrow I have the day off, Vernal Equinox Day is a national holiday
# in Japan!, so I hope to make some headway in scraping Alioth.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Version bumps

2018-03-16 Thread Olaf Meeuwissen
Hi,

I've pushed a number of commits that mostly just update the versions of
"stuff" the SANE Project depends on.  On the CI front, this:

  - adds a Fedora 27 build
  - drops the Fedora 25 build
  - bumps the Alpine build to 3.7
  - bumps the Debian build to 9.4

In terms of "canonical" build environment, CI now uses Debian 9.

# I thinking about dropping the Debian 8 and Fedora 26 builds, BTW.

As for the SANE backends code, I have bumped the autofoo bits to match
the versions in Debian 9.  Specifically,

  - autoconf is unchanged
  - automake went from 1.11.6 to 1.15
  - libtool from 2.4.2 to 2.4.6
  - gettext from 0.18.1 to 0.19.8

If you experience build problems and think they may be due to the above,
try a `make distclean` and re`./configure`.  That said, I don't expect
there to be any :-)

# Here's assuming maintainer-mode rules don't throw a monkey wrench.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] Alioth → GitLab Migration Update

2018-03-13 Thread Olaf Meeuwissen
Hi all,

A good month ago, Olaf Meeuwissen wrote:

> Hi all,

So I thought I'd give you an update ;-)

> I have started work on some of the issues on the migration milestone I
> created on GitLab[1].  Of course you can follow what's going on on the
> milestone directly (or the board[2]) but I figured I'd post an update.
>
>   [1]: https://gitlab.com/sane-project/ops/milestones/1
>   [2]: 
> https://gitlab.com/sane-project/ops/boards?milestone_title=Alioth%20%E2%86%92%20GitLab%20Migration

# As for the board, I've been trying out the sane-project *group* board
# as opposed to the ops *project* board so you should now look at
#
#  https://gitlab.com/groups/sane-project/-/boards?milestone_title=%23started
#
# to get a picture of the current state.

> For starters, both the sane-backends and sane-frontends repositories
> on Alioth are now *read-only* and will no longer receive any updates.
> The developers should push to the corresponding repositories at
> GitLab.com from now on.
>
> Pushes to the Alioth repositories will now fail with an error message
> telling you how to switch your local checkout.
>
> # The website project will follow once we have a site set up on the
> # GitLab infra-structure.  In the mean time, all these changes have
> # been reflected in the site's pages.

The website project has followed suit and the Alioth repository is now
read-only.  This completes the transfer of *all* of the SANE project's
git repositories from Alioth to GitLab.com.

> All SANE project members on Alioth have received invitations to join the
> project on GitLab.com and a bit shy of half have already accepted.  The
> rest will get another nudge soon.  Please note that only project members
> can push to GitLab.com.

On this front, close to three quarters of the Alioth members have now
joined (or declined to join) the project on GitLab.com.  The remaining
five have received several nudges by now and any outstanding invitations
will be closed after 2018-03-21 00:00 UTC.

# The initial invitation was issued on 2018-02-01, BTW.

> Release artifacts, [...]

Nothing changed in this department.

> In the mean time, I'm also looking at the possibility of migrating the
> Tracker items we have at Alioth[5].  It doesn't look easy, but someone
> at GitLab.com (the Director of Strategic Partnerships) has contacted me
> with an offer to help.  I'm not holding my breath but any help in this
> area is welcome.
>
>   [5]: https://gitlab.com/sane-project/ops/issues/10

I have been poking around in the FusionForge source code that powers
Alioth and found an interesting commit that may make migrating Alioth
issues a breeze.  Well, almost at least.  I'm waiting for the Alioth
maintainers to apply a patch so I can test.  Details are in the issue
linked to above.

> If there is anything you think that's missing from the milestone[1] or
> find fault with any of the attached release artifacts[3][4], feel free
> to submit a new issue[6].  You don't have to be a SANE Project member.
> Simply login to GitLab.com[7] and create a new issue[6].
>
>   [6]: https://gitlab.com/users/sign_in
>   [7]: https://gitlab.com/sane-project/ops/issues/new

This stands without change.

> Next up on my list is the website[8].
>
>   [8]: https://gitlab.com/sane-project/ops/issues/7

This issue has been closed after a good deal of mucking about with the
links in the webpages so they would work on Alioth and GitLab.  While
working on this and testing stuff, I even got myself black-listed and
could not browse the site on Alioth for a while :-/
There is now a static SANE Project website that you can visit on

  https://sane-project.gitlab.io/website/

It should be identical to the one on Alioth.  The Scanner Search
Engine[9] will break as soon as Alioth goes off-line, though.

 [9]: https://sane.alioth.debian.org/cgi-bin/driver.pl

I have asked[10] Allan to make the project's domain (sane-project.org)
point to the GitLab hosted website.

 [10]: https://gitlab.com/sane-project/ops/boards?=

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] daily git snapshots

2018-03-11 Thread Olaf Meeuwissen
Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
> The cron job seems running. I can download the daily git snapshots.
>
> I just pushed some commits to gitlab. But I cannot find the immediately
> builds on the website.

When you say "immediately", exactly how fast do you think they complete
:-P

Here's the time line of events:

 2018-03-11 11:08UTC: you pushed[1]
 2018-03-11 11:20UTC: archive build finished[2]

 [1]: 
https://gitlab.com/sane-project/backends/commit/a5ae2dad1d4202911be927933b8f8d6a8dde6413
 [2]: https://gitlab.com/sane-project/backends/pipelines/18712000/builds

The builds took a total of 11 minutes and 46 seconds (after a 13 second
wait) to complete.  I'd say give GitLab.com about 15-20 minutes for the
build to complete because it tests the build on *several* setups (as is
clear from [2]) and the archive is only updated when all succeed.

That said, I have experienced some delays occasionally when the updated
"new" website was being deployed, i.e. transferred to storage.  Anyway,
the archive appears to be available for download now.

I'm writing this an hour and five minutes after the build completed ;-)
I'd say that beats those daily snapshots hands down.  But that's not
really the point.  The point is that things happen automatically when
they make sense: build on push and update the archive if all parts of
the build completed successfully (for some definition of success).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Epson Perfection V300 and the backend

2018-03-09 Thread Olaf Meeuwissen
Hi Todd,

ToddAndMargo writes:

> On 03/08/2018 03:09 AM, Olaf Meeuwissen wrote:

# Better quoting would be appreciated :-)

> looking at
> krarc:/home/CDs/Linux/Epson/iscan-gt-f720-bundle-1.0.1.x64.rpm/data/iscan-data-1.36.0-1.noarch.rpm/usr/share/iscan-data/device/
>
> I only find an XML for the Perfection V800.

The presence of an XML file for your device is not a hard requirement,
IIRC.  The fact that scanimage lists your V300 would be proof of that.
If you can actually scan with scanimage even more so.  If you can scan
with scanimage then the V300 _is_ supported by the epkowa backend.

If, on the same machine and with the same permissions, saned is not able
to detect the device, then there is something wrong with your saned
configuration iself or with the way saned is started by, I presume,
systemd.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Epson Perfection V300 and the backend

2018-03-08 Thread Olaf Meeuwissen
Hi Todd,

ToddAndMargo writes:

> Hi All,
>
> Fedora 27
> iscan-gt-f720-bundle-1.0.1.x64.rpm
>
> By change is the Epson Perfection V300 included in
> the rpm's front end, but not its back end?

I just remembered I wrote a section about the network configuration for
iscan a decade or so ago.  Have a look at

  http://download.ebz.epson.net/man/linux/iscan_e.html#sec7

and see if some of that helps.

> Scanimage can find it,
>
> $ scanimage -L
> device `epkowa:interpreter:001:008' is a Epson Perfection V300 flatbed
> scanner
>
> but saned cannot.
>
> saned[16940]: [net] sane_init: done
> saned[16940]: [dll] init: backend `net' is version 1.0.27
> saned[16940]: [net] sane_get_devices: local_only = 1
> saned[16940]: [dll] sane_get_devices: found 0 devices
> saned[16940]: saned exiting
>
> If not, how do I get the V300 into the back end?

Does saned's dll load the epkowa backend?  I think you can check by
running it in standalone mode and get the dll backend to output the
debug info with

  sudo SANE_DEBUG_DLL=128 saned -d128

You are of course looking at the saned output from a saned that runs on
the machine to which your V300 is connected, right?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] daily git snapshots

2018-03-06 Thread Olaf Meeuwissen
Hi Rolf,

Rolf Bensch writes:

> Hi Olaf
>
> Am 04.03.2018 um 02:52 schrieb Olaf Meeuwissen:
>> ...
>>
>> Sorry about that.  Should be fixed now.
>
> The last file on the website is from 28-Feb-2018 00:05

Should be fixed now.  Looks like something is wrong with the changes I
made to the script and/or permission issues with me running the script
manually and Allan's cron job running it.  Will have a look.

>> # Not quite sure why that happened but I suspect I made a mistake with
>> # the ln command.  It doesn't seem to be caused by the update-htdocs.sh
>> # script.  IIUC, that script runs daily.
>>
>> Anyway, given the (in)frequency with which our repositories are pushed
>> to I wonder if it makes sense to drop the daily git snapshots in favour
>> of the source tarballs created by our CI setup on every push.
>>
>> # Sometimes weeks go by without a commit ;-)
>>
>> The git snapshots are *not* the same as the source tarballs.  The former
>> are the result of
>>
>>   git archive --format=tar --prefix=sane-backends-$(date +%Y%m%d) master
>>
>> whereas the latter are the result of
>>
>>   make dist
>
> This is exactly what I need.

If that's the case, you may want to take a look at changing the URL you
fetch your source tarballs from.  The details[1] are on GitLab, but you
basically want to grab

 
https://gitlab.com/sane-project/$project/builds/artifacts/master/download?job=archive

and use the sane-$project-*.tar.gz that's in the zip'd archive that that
URL provides.  This works for $project values of backends and frontends.
There may be other files in the zip'd archive but those are intended for
the website so you can safely ignore those.

 [1]: https://docs.gitlab.com/ce/user/project/pipelines/job_artifacts.html

You can also take a peek at

 alioth.debian.org:/home/groups/sane/bin/make-git-snapshots.sh

which does something similar for the Alioth hosted website.

>> So the latter are equivalent to what we eventually release.
>>
>> How easy/hard would it be to change things on your end to use the CI
>> source tarballs?  Should I submit an issue for that on GitLab?
>>
>> ...
>
> On my point of view, daily git snapshots without any changes make no sense.

That's exactly why I asked.  We now have CI builds with every push.
These are guaranteed to have a change.  It doesn't really matter how
often they happen, once a month or every five minutes ;-)
A new source tarball will be created for *every* push unless the build
fails.  Even so, the last successfull source tarball will be available
from the URL above.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] daily git snapshots

2018-03-03 Thread Olaf Meeuwissen
Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
> There are no daily git snapshots available on the wesite anymore. I can
> only find a folder, which goes into itself.

Sorry about that.  Should be fixed now.

# Not quite sure why that happened but I suspect I made a mistake with
# the ln command.  It doesn't seem to be caused by the update-htdocs.sh
# script.  IIUC, that script runs daily.

Anyway, given the (in)frequency with which our repositories are pushed
to I wonder if it makes sense to drop the daily git snapshots in favour
of the source tarballs created by our CI setup on every push.

# Sometimes weeks go by without a commit ;-)

The git snapshots are *not* the same as the source tarballs.  The former
are the result of

  git archive --format=tar --prefix=sane-backends-$(date +%Y%m%d) master

whereas the latter are the result of

  make dist

So the latter are equivalent to what we eventually release.

How easy/hard would it be to change things on your end to use the CI
source tarballs?  Should I submit an issue for that on GitLab?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Mustek scanner problem

2018-02-24 Thread Olaf Meeuwissen
Hi Chris,

Chris Widdows writes:

> Made the changes, but it is not recognised. XSane seems to only pickup
> on my webcam. I ran sane-find-scanner as root and this is what I got:
>
>> sane-find-scanner
>
>  # sane-find-scanner will now attempt to detect your scanner. If the
>  # result is different from what you expected, first make sure your
>  # scanner is powered up and properly connected to your computer.
>
>  # No SCSI scanners found. If you expected something different, make
> sure that
>  # you have loaded a kernel SCSI driver for your SCSI adapter.
>
> found USB scanner (vendor=0x138a, product=0x0011) at libusb:003:005
> found USB scanner (vendor=0x055f, product=0x050c, chip=GL128) at
> libusb:001:003
>  # Your USB scanner was (probably) detected. It may or may not be
> supported by
>  # SANE. Try scanimage -L and read the backend's manpage.
>
>  # Not checking for parallel port scanners.
>
>  # Most Scanners connected to the parallel port or other proprietary ports
>  # can't be detected by this program.
>> scanimage -L
> device `v4l:/dev/video0' is a Noname Integrated Camera virtual device

Was that run as root as well?  What does

 $ sudo SANE_DEBUG_DLL=128 scanimage -L

say?  Does the output look like it loaded that third-party backend
correctly?  It could be that the backend was installed someplace where
the dll backend does not look.  Not all third-party backends have been
fixed up to play nice with multiarch.

Before multiarch, backends were installed in

  /usr/lib/sane  (or /usr/lib64/sane)

After multiarch, they usually live in a place that looks like

  /usr/lib/x86_64-linux-gnu/sane

> And this is LMDE2 distro, 64bits, kernel 4.9 (from the jessie
> backports). Essentially LMDE2 is a pimped Debian Jessie, which is
> oldstable. 16GB Ram, core i7, Disk is a 64GB ssd + 1TB HDD and the HDD
> is configured as a bcache-backend, because there's 192GB left on the
> ssd, which I use as the bcache cache device.
>
> Rgds Chris
>
>
> On 15/02/18 13:56, Olaf Meeuwissen wrote:
>> Hi Chris,
>>
>> Chris writes:
>>
>>> Hi,
>>>
>>> My first post here, and whilst I think I've covered the obvious things,
>>> I could have easily missed something. But I can read, so in case I
>>> missed what to read, kindly tell me
>>>
>>> Having said that, I have got a Mustek A3F1200N scanner. It's an usb
>>> scanner and Mustek offers a xsane backend deb file for this scanner at
>>> ftp://ftp2.mustek.com.tw/pub/new/driver/A3F1200N/Linux/ . I run 64 bit
>>> LMDE2, so I downloaded and installed the .deb file. This added a lot of
>>> files to /etc/sane.d, but xsane does not detect the scanner. So I did an
>>> lsusb and found this: Bus 001 Device 010: ID 055f:050c Mustek Systems, Inc.
>> Third party backend binary packages often don't bother with getting the
>> device access permissions right on *your* particular system.  Taking a
>> quick look at Mustek's binaries, it doesn't seem to even do so much as
>> try.
>>
>> # Apart from that, it seems to warp you back in time to sane-backends
>> # 1.0.23 for all other backends and clobber whatever changes you made
>> # to /etc/sane.d.  At least for the i386 deb.
>>
>> You didn't mention the distribution you use but something like the below
>> ought to work for most.
>>
>>  sudo cp /lib/udev/rules.d/*-libsane.rules /etc/udev/rules.d/
>>
>> and replace the whole of the gargatuan list of entries that look like
>>
>>   ATTRS{idVendor}=="055f", ATTRS{idProduct}=="050c", 
>> ENV{libsane_matched}="yes"
>>
>> with that single line.  Replace the line that starts with
>>
>>   ENV{libsane_matched}=="yes"
>>
>> with
>>
>>   ENV{libsane_matched}=="yes", RUN+="chmod 0666 $env{DEVNAME}"
>>
>> Replug your device and things should work, if my recollection of the way
>> udev works still up to snuff.  It's not the most granular and security
>> conscious way of going about this but is good enough for single user
>> machines and most SOHO use.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] libsane-imagescan.so.1' (No such file or directory)

2018-02-21 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> On 02/18/2018 07:16 PM, ToddAndMargo wrote:
>> On 02/18/2018 12:14 AM, Olaf Meeuwissen wrote:
>>> The SANE_DEBUG_BJNP setting was a dead giveaway
>>
>> Hi Olaf,
>>
>> Do you have a link to a list of these?

No.  This is knowledge I have gathered following the list, being a SANE
project admin tinkering with the code, looking at bug reports and what
not.  Failing that, I just `git grep ...` my local source checkout.

That said, the manual pages for all backends should, and normally do,
list the environment variables they support.  Problem is, there's about
80 or so backends :-/  Disabling the ones you don't need, or rather only
leaving the ones you do need enabled ought to help narrowing things down
a bit.

>> Many thanks,
>> -T
>
> Olaf?

Sorry for not replying "immediately", I do have a Real Life ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] libsane-imagescan.so.1' (No such file or directory)

2018-02-18 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> On 02/17/2018 04:47 AM, Olaf Meeuwissen wrote:
>>>
>>> found 0 devices
>>>
>>> What is this all about?
>>
>> How are we supposed to know?
>
> But, but, but, I thought you knew all and see all!!!
> I should have put the question at the bottom of the post,
> instead of the top.

Indeed!  :-P
# Just like one should put answers after the questions ;-)

> [...snip...]
>>>
>>> In saned@.service, I have debug set to the following:
>>> Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
>>> SANE_DEBUG_BJNP=5
>>> SANE_DEBUG_NET=128
> [...snip...]
>
> Hi Olaf,
>
> Where did you see pixma being call out?  Maybe???

The SANE_DEBUG_BJNP setting was a dead giveaway ;-)

> Here is some more detailed information:
> [...snip...]

I've already replied to that in detail in an earlier mail so I'll skip
repeating myself here.  Hope you don't mind.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] libsane-imagescan.so.1' (No such file or directory)

2018-02-18 Thread Olaf Meeuwissen
Hi Richard,

Richard Ryniker writes:

> libsane-imagescan.so.1 is in the rpm package at:
>
>   
> http://ftp.gwdg.de/pub/opensuse/repositories/home:/zhonghuaren/Fedora_27/x86_64/imagescan-3.32.0-8.1.x86_64.rpm

# Curious, hosting Fedora packages under an opensuse directory ...

> but I have only looked to see this file is there.  I have not tried it.
> Perhaps it will offer you a path forward.  I suspect the package
> referenced above originates from:
>
> https://github.com/utsushi/imagescan

  $ rpm -qiv imagescan-3.32.0-8.1.x86_64.rp | grep URL
  URL : http://utsushi.github.io/imagescan/

So yes, it appears to come from that GitHub repository but please read
the page that the URL points to ;-)  This is the first (re)packaging of
the GitHub code that I am just now aware of!

# BTW, I should update the page's content a bit because the EPSON
# Download Center has improved.

However, if you use the imagescan bundle from said download center,

  $ rpm -qiv imagescan-3.35.0-1epson4fedora27.x86_64.rpm | grep URL
  URL : http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX

which is where I get the sources that I then push to GitHub.

Hope that helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] libsane-imagescan.so.1' (No such file or directory)

2018-02-17 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> On 02/17/2018 06:13 AM, Richard Ryniker wrote:
>> Does Olaf Meeuwissen's post at
>> https://www.mail-archive.com/sane-devel@lists.alioth.debian.org/msg33846.html
>> help?  It describes imagescan as an Epson product.
>
> Hi Richard,
>
> My scanner is an Epson Perfection V300
>
> I installed iscan-gt-f720-bundle-1.0.1.x64.rpm from

That bundle should support your Perfection V300 just fine.

> https://epson.com/Support/Scanners/Perfection-Series/Epson-Perfection-V19-Photo/s/SPT_B11B231201?review-filter=Linux

Eh, that's for the V19.  Oh, I see now, clicking the Linux Drivers for
Epson Products gets you to

  http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX

(with which I'm familiar) where you can search for the V300.

> I am able to scan with both xsane and simple-scan, which
> both use the front end.

Looks like you're slightly confused as to what's a frontend and what's
a backend as far as SANE is concerned.  Both xsane and simple-scan are
SANE frontends.  Both use the SANE epkowa backend that came as part of
your bundle (via the SANE dll backend) to communicate with the scanner
(via a non-free interpreter plugin used by the SANE epkowa backend in
your particular case).

> I am not able to scan from the back end using saned
> with either "xsane net:localhost" of PDF Studio.

Here you are using the xsane SANE frontend in combination with the SANE
net backend to communicate with saned, running on localhost.  That, in
turn should be using the SANE epkowa backend (again via the SANE dll
backend) to communicate with your scanner (again via that non-free
interpreter plugin that the SANE epkowa backend relies upon in your
particular case).

> I am able to manually start saned and scan with
> PDF Studio, which always uses saned.

OK, so your saned configuration is good (apart from the fact that you
have to start it manually but that's another issue).

>  From Olag's post, it seems that he is saying
> that there is a different driver for the front end
> and the back end.  But, if I can manually start saned,
> it would seems that I have both in place.

Sorry if I gave you that impression but that's not what I was trying to
say.  Perhaps that my explanations above clarify a bit better how the
various pieces are connected.  If you can scan from your V300 using PDF
Studio and PDF Studio always uses your saned on localhost, then, yes,
you have all the required pieces in place.

>  From the error log, I do believe I am missing
> libsane-imagescan.so.1

That SANE backend does not support the V300, AFAIK.  The SANE epkowa
backend does, with the help of a non-free interpreter (libesintXX.so
IIRC).  The imagescan backend is part of the imagescan RPM that you
appear to have installed from an imagescan-bundle or at least had
installed at one time.  These are *not* the same as the iscan-bundles!

BTW, the V19 is supported by *both* bundles.

Check if you still have it installed, remove it if you don't need it and
remove any references to it from any files below /etc/sane.d/ insofar
still present.  My guess is that the error message you initially posted
is due to you removing the imagescan RPM and that that didn't clean up
any references in the SANE configuration or, heaven forbid, you just
removed selected files manually yourself.

You can remove any imagescan.conf you find below /etc/sane.d/ and should
remove any imagescan entry in dll.conf you find.  That should make that
dll backend error go away but probably still will not fix your "xsane
net:localhost" issue.

In case you want to keep imagescan installed, check that
/usr/lib64/sane/libsane-imagescan.so.1 is not a broken symlink and
points to /usr/lib64/utsushi/sane/libsame-imagescan.so.1.0.27.  That is,
the output of

  readlink -e /usr/lib64/sane/libsane-imagescan.so.1

should produce /usr/lib64/utsushi/sane/libsame-imagescan.so.1.0.27

> For the full error log, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1546433
>
> Error log: https://bugzilla.redhat.com/attachment.cgi?id=1397367
> configuration: https://bugzilla.redhat.com/attachment.cgi?id=1397368
>
>  From the error log, it looks like saned tried to contact
> the scanners three times and failed because it could not
> find libsane-imagescan.so.1

It does look that way but I think that is mostly due to the log levels
you specified.  Add SANE_DEBUG_EPKOWA=HEX to see what the epkowa backend
has to say when it looks for your V300 (or V19?).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bi

Re: [sane-devel] libsane-imagescan.so.1' (No such file or directory)

2018-02-17 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> Hi All,
>
> found 0 devices
>
> What is this all about?

How are we supposed to know?  What did you do?  What did you expect to
happen?  What happened?

Please provide details.  We weren't shoulder-surfing at your place when
this happened and we have neither extra-sensory perception capabilities
nor crystal balls.

> Fedora 26 x 64
> Xfce 4.12
>
> sane-backends-1.0.27-9.fc27.x86_64
> sane-backends-drivers-scanners-1.0.27-9.fc27.x86_64
> sane-backends-drivers-cameras-1.0.27-9.fc27.i686
> sane-backends-libs-1.0.27-9.fc27.i686
> sane-backends-daemon-1.0.27-9.fc27.x86_64
> sane-backends-drivers-scanners-1.0.27-9.fc27.i686
> sane-backends-libs-1.0.27-9.fc27.x86_64
> sane-backends-drivers-cameras-1.0.27-9.fc27.x86_64
>
> I am trying to get xsane to work with systemd and saned.  When I run
>  $ xsane net:localhost
>
> I get the following error pop up:
> Error: Failed to open device `net:localhost': Error during device I/0
>
> In saned@.service, I have debug set to the following:
> Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
> SANE_DEBUG_BJNP=5
> SANE_DEBUG_NET=128
>
> And this error pops up in my debug log:
> # journalctl -efx -t saned > saned.log.txt
>
> 996: 032]: [dll] load: searching backend `imagescan' in
> `/usr/lib64/sane'
> Feb 17 02:59:12 rn4.rent-a-nerd.local saned[4032]: [dll] load: trying to
> load `/usr/lib64/sane/libsane-imagescan.so.1'
> Feb 17 02:59:12 rn4.rent-a-nerd.local saned[4032]: [dll] load:
> couldn't open `/usr/lib64/sane/libsane-imagescan.so.1' (No such file or
> directory)
> Feb 17 02:59:12 rn4.rent-a-nerd.local saned[4032]: [dll] load:
> couldn't find backend `imagescan' (No such file or directory)
> Feb 17 02:59:12 rn4.rent-a-nerd.local saned[4032]: [dll]
> sane_get_devices: found 0 devices
> Feb 17 02:59:14 rn4.rent-a-nerd.local saned[4032]: saned exiting

The dll backend not being able to load a backend should not prevent
saned from detect locally connected devices at large.  Looks like you
expect to find a device supported by the pixma backend.  If that's the
case, you may safely remove/purge any imagescan package that you seem to
have picked up from who knows where (EPSON's download site, perhaps?).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Mustek scanner problem

2018-02-15 Thread Olaf Meeuwissen
Hi Chris,

Chris writes:

> Hi,
>
> My first post here, and whilst I think I've covered the obvious things,
> I could have easily missed something. But I can read, so in case I
> missed what to read, kindly tell me
>
> Having said that, I have got a Mustek A3F1200N scanner. It's an usb
> scanner and Mustek offers a xsane backend deb file for this scanner at
> ftp://ftp2.mustek.com.tw/pub/new/driver/A3F1200N/Linux/ . I run 64 bit
> LMDE2, so I downloaded and installed the .deb file. This added a lot of
> files to /etc/sane.d, but xsane does not detect the scanner. So I did an
> lsusb and found this: Bus 001 Device 010: ID 055f:050c Mustek Systems, Inc.

Third party backend binary packages often don't bother with getting the
device access permissions right on *your* particular system.  Taking a
quick look at Mustek's binaries, it doesn't seem to even do so much as
try.

# Apart from that, it seems to warp you back in time to sane-backends
# 1.0.23 for all other backends and clobber whatever changes you made
# to /etc/sane.d.  At least for the i386 deb.

You didn't mention the distribution you use but something like the below
ought to work for most.

 sudo cp /lib/udev/rules.d/*-libsane.rules /etc/udev/rules.d/

and replace the whole of the gargatuan list of entries that look like

  ATTRS{idVendor}=="055f", ATTRS{idProduct}=="050c", ENV{libsane_matched}="yes"

with that single line.  Replace the line that starts with

  ENV{libsane_matched}=="yes"

with

  ENV{libsane_matched}=="yes", RUN+="chmod 0666 $env{DEVNAME}"

Replug your device and things should work, if my recollection of the way
udev works still up to snuff.  It's not the most granular and security
conscious way of going about this but is good enough for single user
machines and most SOHO use.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Alioth → GitLab Migration Update

2018-02-09 Thread Olaf Meeuwissen
Hi all,

I have started work on some of the issues on the migration milestone I
created on GitLab[1].  Of course you can follow what's going on on the
milestone directly (or the board[2]) but I figured I'd post an update.

  [1]: https://gitlab.com/sane-project/ops/milestones/1
  [2]: 
https://gitlab.com/sane-project/ops/boards?milestone_title=Alioth%20%E2%86%92%20GitLab%20Migration

For starters, both the sane-backends and sane-frontends repositories on
Alioth are now *read-only* and will no longer receive any updates.  The
developers should push to the corresponding repositories at GitLab.com
from now on.

Pushes to the Alioth repositories will now fail with an error message
telling you how to switch your local checkout.

# The website project will follow once we have a site set up on the
# GitLab infra-structure.  In the mean time, all these changes have
# been reflected in the site's pages.

All SANE project members on Alioth have received invitations to join the
project on GitLab.com and a bit shy of half have already accepted.  The
rest will get another nudge soon.  Please note that only project members
can push to GitLab.com.

Release artifacts, i.e. source tarballs, have been attached to their
corresponding release tags for both backends[3] and frontends[4].
Various checksums have been added as well as some release notes.

  [3]: https://gitlab.com/sane-project/backends/tags?search=RELEASE
  [4]: https://gitlab.com/sane-project/frontends/tags?search=RELEASE

In the mean time, I'm also looking at the possibility of migrating the
Tracker items we have at Alioth[5].  It doesn't look easy, but someone
at GitLab.com (the Director of Strategic Partnerships) has contacted me
with an offer to help.  I'm not holding my breath but any help in this
area is welcome.

  [5]: https://gitlab.com/sane-project/ops/issues/10

If there is anything you think that's missing from the milestone[1] or
find fault with any of the attached release artifacts[3][4], feel free
to submit a new issue[6].  You don't have to be a SANE Project member.
Simply login to GitLab.com[7] and create a new issue[6].

  [6]: https://gitlab.com/users/sign_in
  [7]: https://gitlab.com/sane-project/ops/issues/new

Next up on my list is the website[8].

  [8]: https://gitlab.com/sane-project/ops/issues/7

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Support for Epson WorkForce ES-200 on Linux Mint 18.2

2018-01-27 Thread Olaf Meeuwissen
Hi Alkarim,

Alkarim Kanji writes:

> I could not find the pager section in README.rst file. I searched manually
> and electronically.
>
> My understanding of pager README.rst is "pager" section in the README.rst
> file that is part of the "imagescan-bundle-linuxmint-18-1.3.23.x64.deb
> folder."

Sorry for not being clear.  `pager` is a command that shows you the
content of the README.rst file.  You may be more familiar with `more` or
`less`.  Anyway, just read the README.rst file.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Support for Epson WorkForce ES-200 on Linux Mint 18.2

2018-01-27 Thread Olaf Meeuwissen
Hi,

Cc:ing sane-devel again to keep everyone informed.

Alkarim Kanji writes:

> Thank you for the support, Olaf.
>
> When I first started attempting to download drivers/software, I ran into
> the " http://support.epson.net/linux/en/imagescanv3.php?
> version=1.3.23#linux_mint" file you pointed to in your email.  I even
> extracted it (within the downloads folder), but got error messages when
> attempting to use the commands given in the README.rst file.  I guess where
> I am going wrong is extraction: should I be extracting the zip file to
> another folder (as opposed to download subfolders)?  If yes, which folder
> should I be extracting it to?  I was unable to find an appropriate folder.
>
> I would appreciated a little more detail.  Below I have shared the error
> messages I am getting so you can guide me accordingly.
>
> When I extract the zipped
> "imagescan-bundle-linuxmint-18-1.3.23.x64.deb.tar.gz" folder (which
> downloads when I click the link above), I get a folder called,
> "imagescan-bundle-linuxmint-18-1.3.23.x64.deb"  I then right-clicked the
> "imagescan-bundle-linuxmint-18-1.3.23.x64.deb" folder and selected the
> option to open Terminal.  In Terminal, I gave the command, "tar xaf
> imagescan-bundle-linuxmint-18-1.3.23.x64.deb.tar.gz" (as prescribed in the
> README.rst file), which resulted in the following error message:
>
> imagescan-bundle-linuxmint-18-1.3.23.x64.deb.tar.gz: Cannot open: No such
> file or directory
> tar: Error is not recoverable: exiting now
>
> Where am I going wrong?

OK, I see.  You used some GUI application to extract and navigate to the
folder that that created.  In that case you can continue with

  pager README.rst

and follow the directions in there to get up and running.

Hope that helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] Relocating the SANE Project

2018-01-27 Thread Olaf Meeuwissen
Hi Markus,

Markus Heiser writes:

>> Am 26.01.2018 um 09:59 schrieb Olaf Meeuwissen <paddy-h...@member.fsf.org>:
>>
>> Dear all,
>>
>> TL;DR :: Let's move to GitLab.com!  Mailing list TBD.
>
> [ ... ]
>
>> The idea of putting a repository mirror on GitHub is interesting but I'm
>> not sure how pull requests and issues would work out if things are split
>> over multiple sites.
>
> Its not a show stopper: pull request can be handled by git itself,
> adding the github remote repo and pull the feature branch from there
> into the gitlab origin. Vice versa the github users are be able to
> fork from gitlab origin this way.
>
>  What I mean: there is no need for a github mirror.
>
> Stay with a Single-Point-of-Definition and do not mirror, it will
> only confuse the github users.

Thanks for your comments.  I realize that a github mirror is not
required.  It's just something I hadn't considered.  When I did, I
started to wonder how the web based merge/pull request workflows would
interoperate.  I have the impression that it will be confusing at the
very least, so, yes, let's start with a *single* location for the
project, at least until we're all settled on GitLab.com

Again, thanks for the feedback,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] hosts.resolv ???

2018-01-27 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> Hi All,
>
> Fedora 27
>
> $ rpm -qa sane\*
> sane-backends-1.0.27-9.fc27.x86_64
> sane-backends-drivers-scanners-1.0.27-9.fc27.x86_64
> sane-backends-drivers-cameras-1.0.27-9.fc27.i686
> sane-backends-libs-1.0.27-9.fc27.i686
> sane-backends-daemon-1.0.27-9.fc27.x86_64
> sane-backends-drivers-scanners-1.0.27-9.fc27.i686
> sane-backends-libs-1.0.27-9.fc27.x86_64
> sane-backends-drivers-cameras-1.0.27-9.fc27.x86_64
>
> What I am trying to do is to allow everyone of
> 192.168.255.0/24   and
> 127.0.0.1
>
> to access saned
>
> as such I have /etc/sane.d/saned.conf (comments removed):
>
> 192.168.255.0/24
> 127.0.0.1
>
> Have I done things correct so far?
>
> Confusion:  in the saned man page, it states:
>
>  FILES
> /etc/hosts.equiv
> The  hosts listed in this file are permitted to
> access all local SANE devices.  Caveat: this
> file imposes serious security risks and its
> use is not recommended.
>
> No fooling not recommended!
>
> Why do I need hosts.equiv to allow access to all SANE
> devices?  I though I just did that in saned.conf?

You don't need one.  Just use /etc/sane.d/saned.conf.  The manual page
is just saying saned will use /etc/hosts.equiv if present.  You are
safer of without a hosts.equiv file.  For details see

  http://man7.org/linux/man-pages/man5/hosts.equiv.5.html

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] /etc/sane.d/saned.conf vs /etc/saned.conf?

2018-01-27 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

> Hi All,
>
> When configuring saned, what is the difference between the access
> list in
>
> /etc/sane.d/saned.conf
>
> and
>
> /etc/saned.conf

By default, saned looks for saned.conf in the directory that was
specified at build time.  For most Linux distributions this will be
/etc/sane.d, the result of passing a --configdir=/etc option to the
configure script (which tags the /sane.d part on by itself).

Using the *normal* build and install procedures that are part of
sane-backends, there is *no* way you would get an /etc/saned.conf.
Any chance you put this there yourself?

If you really want to use /etc/saned.conf, you need to use

  SANE_CONFIG_DIR=/etc saned ...

As far as file contents is concerned, both are processed in the same
way.  It only a matter of which one is used and, as said, the default
is to use the first.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] Relocating the SANE Project

2018-01-26 Thread Olaf Meeuwissen
Dear all,

TL;DR :: Let's move to GitLab.com!  Mailing list TBD.

# Apologies for the belated follow-up.  I planned to wait a week or so
# to let the dust settle before following up but then Real Life got in
# the way :-(

Now for the long story,

On 2018-01-08, Olaf Meeuwissen (that's me!) wrote:

> [ ... Alioth will be discontinued sometime in 2018-05 ... so]
> the SANE Project will no longer be able to:
>
>  - communicate via the mailing lists
>  - push commits to its official git repositories
>  - update the bug and feature requests trackers
>  - update its website
>
> So we have to move some place else for our project hosting but where?

I made a couple of suggestions and asked for feedback.  Apart from one
off-list request to join the SANE project on GitLab.com, not one of the
SANE developers has chimed in.  I will take that to mean that everyone
will be fine with whatever gets chosen in the end.  Speak up if that's
not the case!

The non-developers that did follow up mentioned[1] Sourceforge as a
possibility (and questioned[2] whether that was serious), offered help
with moving the mailing list to Debian infra-structure[1] (thanks,
btw!) and a preference for GitHub[3][4].

There was also a fairly detailed account[5] of the pros and cons of
GitLab vs. GitHub as well as an offer to host mailing lists[6].
Finally, there was a hint on how to get release notifications from
GitHub using an RSS feed[7].

There was the notion that GitLab/GitHub issues and merge/pull requests
could meaningfully replace a large part of the mailing lists[3][5], yet
having mailing lists (archives) around would be nice.  Several people
also pointed out that moving[4][5] and/or mirroring[3] git repositories
elsewhere would be easy and that GitHub Pages have their "quirks"[5].
Finally, the fact that GitLab.com supports logging in via GitHub,
Google, Twitter and BitBucket accounts was pointed out as a pro[5].
Neither GitHub nor the Debian GitLab instance provide this (although the
latter could, in theory).

 [1]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035897.html
 [2]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035900.html
 [3]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035911.html
 [4]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035898.html
 [5]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035899.html
 [6]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035921.html
 [7]: 
https://lists.alioth.debian.org/pipermail/sane-devel/2018-January/035912.html

Taking this all in, and putting the mailing lists issue aside for a bit,
I still prefer moving to GitLab.com.  In terms of repository, issues and
merge/pull request support it offers pretty much the same as GitHub, but
on top of that allows you to log in using accounts users may have with
(selected) other services.  This, I think, lowers the barrier to report
issues.  Furthermore, GitLab.com comes with CI out-of-the-box (which is
used already by the current *unofficial* mirror, btw!).

The idea of putting a repository mirror on GitHub is interesting but I'm
not sure how pull requests and issues would work out if things are split
over multiple sites.

Back to mailing lists, I think that for the short term making use of the
Alioth mail continuation project[8] is our best alternative, although I
am not exactly clear on that project's status.  If I understand things
correctly the current list maintainer will be asked to opt in before
Alioth is discontinued.

I have also considered moving to lists.debian.org but in that case we
probably won't be able to make the list subscriber-only or moderate
incoming posts[9][10].

 [8]: https://wiki.debian.org/Alioth/MailingListContinuation
 [9]: https://wiki.debian.org/Alioth#Mailing_lists
 [10]: https://www.debian.org/MailingLists/HOWTO_start_list

In either case, sane-commit is extremely likely to disappear (you can
use the commit notification functionality of GitLab instead).  As for
sane-standard (which has seen less than 100KB gzipped traffic since July
2004!), I think it doesn't serve any purpose.  SANE standard discussions
can be held on sane-devel.  The sane-announce list sees even less
traffic but does serve a well-defined purpose (prevent announcements
from "drowning" in the other traffic) and should be migrated together
with sane-devel.

Anyway, I'll check the status on [8] and look at some other mailing list
hosting solutions but in the mean-time, how does everyone feel about
moving to GitLab.com?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.a

Re: [sane-devel] Support for Epson WorkForce ES-200 on Linux Mint 18.2

2018-01-25 Thread Olaf Meeuwissen
Hi,

Alkarim Kanji writes:

> First, I trust I am subscribed to the correct forum: the forum that offers
> scanner support tied to Linux flavors.  If not, please direct me to the
> appropriated forum.

You're at the right place.

> I have a laptop that runs both Window$ and Linux Mint 18.2, 64 bit.  Mint
> is my primary OS: I use Window$ only when I absolutely have to.  I
> purchased an Epson WorkForce ES-200 duplex color scanner to be used on
> Linux Mint 18.2.  I spent hours downloading/configuring scanner related
> software with poor results: I can scan, but the quality of scans is poor,
> at best.  I use "Image Scan" software; other applications (gscan2pdf, XSane
> Image Scanning Program) do an even worse job - very likely related to
> availability/configuration of appropriate software.  Then I ran into
> something on Epson's site that told me to click on "Image Scan! for Linux"
> to configure the scanner.  When I do that, with the scanner hooked up and
> turned on, I get the following message:
>
> Could not send command to scanner.
> Check the scanner's status.
>
> It appears the software I downloaded from Epson is not configured
> properly.  I have limited knowledge in this area and am unable to write
> code.
>
> I am requesting help to get the right software downloaded and configured so
> I can use my scanner for quality scans without having to resort to Window$
> to get a decent scan (configuring it on Window$ was a breeze and the
> quality of scans is very good).

There are *two* different packages available from EPSON download site:

 - Image Scan! for Linux
 - Image Scan v3

It looks like you have the first but you need the second.  You can get
it from:

  http://support.epson.net/linux/en/imagescanv3.php?version=1.3.23#linux_mint

That downloads a compressed archive file.  You need to extract that in a
terminal and change to the directory that creates.  Further instructions
can be found in the README.rst file.  So, after the download,

  cd ~/Downloads
  tar xaf imagescan-bundle-linuxmint-18-1.3.23.x64.deb.tar.gz
  cd imagescan-bundle-linuxmint-18-1.3.23.x64.deb
  pager README.rst

should get you up and running.

Once you can scan with imagescan (Image Scan v3), you can safely remove
iscan (Image Scan! for Linux) with

  sudo apt-get remove iscan

> Thank you for the support!

You're welcome.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Support for ET-2650

2018-01-16 Thread Olaf Meeuwissen
Hi Ben,

Ben Greear writes:

> Hello,
>
> It seems the ET-2650 is not supported for scanning.  Anything I can
> do to help get this working?

Smells like an EPSON scanner.  Could you provide more device
information?  USB vendor and product IDs will be a decent start.

  lsusb -d 04b8:

should give the desired output (assuming it *is* an EPSON device).

You may have some luck with the (third party) utsushi backend.  There
are prepackaged binaries you can download from

  http://download.ebz.epson.net/dsc/search/01/search/

(search for the ET-2550 which *might* be similar) or build from the
Community Code Base "fork" sources I've put up at

  https://github.com/utsushi/utsushi

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-12 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

> My code is simply calling scanimage the way I posted here already.
> Running the same commands by hand results in the same behaviour. I
> have my code write the command it runs in a file called ran.txt, so I
> can examine it and run it. I'm just using php to open a 3 pipe method
> of running scanimage. it is actually running it under "script" which
> allows scanimage to continually write to stdout/stderr without
> blocking which gets written to a stdout.txt and stderr.txt files. I
> also implemented the ability to send ctrl-c using the 3rd input pipe.
> So if my loop that is reading the pipes sees that a certain file
> exists and is still running it will send a ctrl-c. My frontend starts
> this php script and detaches and then reads it's output files to see
> what is going on it also continually loads the image being created by
> scanimage. I get the latest page number from stdout.txt/stderr.txt and
> the name of the file from my rant.txt looking for '--batch= and the
> matching quote and replace all %d with the last page number and then I
> have my image retrieve send that file. :-)

I see.  So you're just layering on top of scanimage.  I thought you we
using a PHP layer on top of the SANE C API.  Sorry for overthinking
things.  The image acquisition logic in scanimage is correct so the
problem appears to be in the brother backend.

Sorry for the detour,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-12 Thread Olaf Meeuwissen
Hi again,

Jeff Sadowski writes:

> uning sane -l -d128 -e I am able to see the following error.

This

> [saned] do_scan: done, status=End of file reached
> [saned] process_request: waiting for request
> [saned] process_request: bad status 22
> [saned] quit: exiting

is probably due to the error you get on the other end

> scanimage: scanning image of size 1648x2314 pixels at 24 bits/pixel
> scanimage: acquiring RGB frame
> Progress:98.8%
> scanimage: min/max graylevel value = 11/255
> Application transferred too few scanlines

which indicates that the image acquisition loop ended prematurely for
some reason.  While saned will happily continue to serve requests, how
the backend and scanner react to this depends on the scanner's firmware
and the backend's implementation.  It may very well be that the scanner
expects more read requests and refuses to reply to anything else while
the backend won't send any of those but instead tries to start a new
scan in vain.

Based on what you wrote so far, I think this is a bug in the third party
brother backend you seem to be using.  The only people that can help you
with that are the brother backend developers.  There is nothing the SANE
developers can do about it.

That said, are you sure *your* code is doing the right thing?  That is,
does it read data until sane_read() returns SANE_STATUS_EOF?  Or is it
just reading the number of pixels expected based on the results of a
sane_get_parameters() before you call sane_start()?  The latter is the
*wrong* way to read image data.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-12 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

> Progress. I am now able to scan jpeg files :-)

Good!

> it is odd that -V reports as so
>
> root@raspberrypi:~/sane/sane-backends:x86$ scanimage -V
> scanimage (sane-backends) 1.0.27git; backend version 1.0.24
>
> Is this something I should be worried about?
> Where would it be getting 1.0.24

This is not something to be worried about.  All backends have their own
version, independent of the sane-backends version.  The epson2 backend
for example is at 1.0.124!

The scanimage utility gets it version directly from sane-backends, hence
1.0.27git for a development version after 1.0.27.

Some backends, and probably third party ones in particular, use the
version of the sane-backend's release that they were built against.

Hope this clarifies,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-11 Thread Olaf Meeuwissen
Hi,

Jeff Sadowski writes:

> It seems to be wanting .la files when I have .so files so is there a
> flag to support shared object files over .la?

The dynamic loading should look for .la files first and failing to find
those, look for .so files.  You don't need any flag for that (and AFAIK
there isn't one).

> On Wed, Jan 10, 2018 at 1:36 PM, Jeff Sadowski <jeff.sadow...@gmail.com> 
> wrote:
>> I pulled the current git of sane-backend from
>> https://anonscm.debian.org/git/sane/sane-backends.git
>>
>> I did
>> ./configure --prefix=/usr --libdir=/usr/lib/i386-linux-gnu
>> --sysconfdir=/etc --localstatedir=/var  --
>> make
>> make install
>>
>> now when I run "scanimage -L" it can't see my scanner. Is there a flag
>> I need to use other drivers than the ones it compiles as the brother
>> printer driver is a binary package?

The backends you built are installed below /usr/lib/i386-linux-gnu/sane/
as libsane-$backendname.$extension, right?  Where is the backend of that
brother binary package installed?

If it's not in the same directory, you need to tell the loader to look
in the directory where the brother binary package installed its
backend.  Let's say that is /opt/brother/sane, then you'd have to run

  LD_LIBRARY_PATH=/opt/brother/sane scanimage -L

Alternatively, you can make a symbolic link to the brother backend from
/usr/lib/i386-linux-gnu/sane/.  Using the same example location

  cd /usr/lib/i386-linux-gnu/sane
  ln -s /opt/brother/sane/libsane-$backendname.$extension

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Relocating the SANE Project

2018-01-08 Thread Olaf Meeuwissen
Dear all,

# Project members explicitly BCC:d, just in case they don't subscribe.
# Project admins CC:d to make sure they take note ;-)
# Replies to the list, please.

Since 2003-09-06, the SANE Project has been kindly hosted on Debian's
Alioth.  The Debian project has deprecated[1] this service and intends
to discontinue[*] it when Debian Wheezy becomes EOL.  While that seems
to be slated[2] for 2018-05-31, the Alioth wiki page's News[3] section
states 2018-05-01 for Alioth itself and 2018-02-01 for mailing lists.

 [*]: It is not quite clear what that exactly entails but at best the
  service will become read-only.

A Debian-backed GitLab-based replacement has been announced[4] in beta
and it looks like there may be a temporary continuation of the mailing
lists[5] but *nothing* will be migrated automatically.  Everything has
to be done explicitly.

That is, if we don't act, the SANE Project will no longer be able to:

 - communicate via the mailing lists
 - push commits to its official git repositories
 - update the bug and feature requests trackers
 - update its website

So we have to move some place else for our project hosting but where?

The Debian-backed GitLab-based replacement[6] is one option.  Two others
are GitLab.com[7] and GitHub.com[8].  None of these provides support for
mailing lists so we need something else for that.  Migrating to Debian's
temporary continuation is one option.  Any other suggestions?  As for
the website, all three (will) have support for *static* webpages.  The
trackers are covered by the issue systems of all three.

 [1]: https://wiki.debian.org/Alioth#Deprecation_of_Alioth
 [2]: https://wiki.debian.org/LTS
 [3]: https://wiki.debian.org/Alioth#News
 [4]: https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
 [5]: https://wiki.debian.org/Alioth/MailingListContinuation
 [6]: https://salsa.debian.org
 [7]: https://gitlab.com
 [8]: https://github.com

You may remember that I set up an *unofficial* SANE Project group[9] on
GitLab.com to play around with GitLab CI that mirrors the project's git
repositories on Alioth.  We could use that.  I have also created a stub
on GitHub.com[10] and two on Debian's GitLab[11][12] (which enforces a
*-team naming convention for groups :-() to reserve the names.

 [9]: https://gitlab.com/sane-project
 [10]: https://github.com/sane-project
 [11]: https://salsa.debian.org/sane-team
 [12]: https://salsa.debian.org/sane-project-team

I am personally in favour of using something we could in principle run
ourselves.  That would rule out GitHub.com.  Also, it is not clear yet
when website hosting becomes possible or to what extent Debian's GitLab
instance will provide CI runners (needed to publish the website), so
*my* preference is GitLab.com (steering clear of its enterprise-only
functionality).

What are your preferences?  Feel free to mention other options.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-07 Thread Olaf Meeuwissen
Hi Jeff,

Jeff writes:

> On 07/01/18 05:53, Jeff Sadowski wrote:
>> I'm using debian in exagear do they compile scanimage without support
>> for jpeg and png? It is looking like I have to try and put some other
>> virtual os on my raspberry pi 3 system.
>
> Isn't it just easier to use ImageMagick or GraphicsMagick to convert
> from pnm to what you want?

Support for JPEG and PNG output was added to scanimage in 1.0.25.  So if
you have that (and your distribution enabled it), you don't need either
of the *Magick's.  Note that there were some bugfixes to the JPEG and
PNG support in 1.0.27.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-07 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

> I'm using debian in exagear do they compile scanimage without support
> for jpeg and png? It is looking like I have to try and put some other
> virtual os on my raspberry pi 3 system.

That may depend on the Debian version and architecture you're using.
You can check the package dependencies with

  dpkg-query -W -f '${Depends}\n' sane-utils

On my machine (Devuan ASCII, approximately Debian 9), I get

  adduser, lsb-base (>= 3.0-6), update-inetd, debconf (>= 0.5) |
  debconf-2.0, init-system-helpers (>= 1.18~), libavahi-client3 (>=
  0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.15), libieee1284-3,
  libjpeg62-turbo (>= 1.3.1), libpng16-16 (>= 1.6.2-1), libsane (>=
  1.0.24), libsystemd0, libusb-1.0-0 (>= 2:1.0.8)

So, as mentioned already in my previous reply, I can use JPEG and PNG
but not TIFF.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Weird behavior in exagear.

2018-01-07 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

> So, renaming my image from the directly connected method to pmn allows
> me to view it. Now to find out what I need to get a jpeg, tiff, png
> images.

Your scanimage needs to be linked to JPEG, TIFF and PNG libraries.  You
can check with

  ldd $(which scanimage)

On my machine I get

  $ ldd $(which scanimage)
linux-vdso.so.1 (0x7fffa9f9a000)
libsane.so.1 => /usr/lib/x86_64-linux-gnu/libsane.so.1 
(0x7f11434ed000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 
(0x7f11432ba000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7f114304f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1142cb)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1142aac000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1142892000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f114258e000)
/lib64/ld-linux-x86-64.so.2 (0x7f1143902000)

So I can scan directly to JPEG and PNG but not to TIFF.

If you're compiling scanimage yourself from source, you need to have the
development packages installed before you ./configure.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] 39ceeae6 breaks md5 auth

2018-01-04 Thread Olaf Meeuwissen
Hi James,

James Ring writes:

> Hi Olaf,
>
> On Tue, Jan 2, 2018 at 11:15 PM, Olaf Meeuwissen
> <paddy-h...@member.fsf.org> wrote:
>> Hi James,
>>
>> Thanks for the report.
>>
>> James Ring writes:
>>
>>> Confirmed that with the offending patch, md5.c produces incorrect
>>> digests for known input/output pairs. We should roll it back.
>>>
>>> Also I couldn't reproduce (with gcc 7.2.0) the compiler warning that
>>> the original change was supposed to fix.
>>
>> Hmm, neither can I.  In neither the debian-8-mini nor debian-9-mini CI
>> environments.  But you can still see it in the CI logs for the last
>> pipeline that ran before the offending commit.
>>
>>   https://gitlab.com/sane-project/backends/pipelines/4150861
>>
>> Only the fedora-24-clang log doesn't have it.
>
> Unrelated note: if I read those logs correctly, the CI doesn't run
> `make check`, which maybe they should. It would also be nice to have a
> test case that exercises authentication, though I suspect it is an
> infrequently used feature. I tried adding one, but I couldn't figure
> out how to update the makefiles to include my test.

A `make check` requires /dev/usb to be present in the Docker container
used for the builds in order to pass.  While I have no problem doing
that locally, I haven't tried (or don't recall doing so ;-) on the
shared GitLab.com CI runners.  The VMs that these run on may not even
*have* /dev/usb.

A for an auth test case, a patch with the test is welcome.  I can update
the automake files to integrate the test in the `make check` target.

>>> On Tue, Jan 2, 2018 at 9:57 AM, James Ring <s...@jdns.org> wrote:
>>>> [...snip...]
>>>>
>>>> Reverting that commit restores the functionality. I haven't figured
>>>> out what the problem is from a cursory inspection of the code, I'll
>>>> continue staring at it.
>>
>> I was about to revert the commit but looking at it now I'm wondering
>> what I was thinking when I committed that :-(  Changing the pointer
>> type to something of a different size *obviously* screws up the array
>> indexing!
>>
>> I've cooked up a fix for that (based on e895ee55).  Could you give the
>> attached patch a try?
>
> Yes, this works! I can't help wondering if it might be better to
> introduce an external dependency on, e.g. libxcrypt or libssl to
> implement md5? That way the sane project is not maintaining an md5
> fork.

Thanks for the testing.  Patch has been pushed.

As for the alternative libraries, thanks for the suggestion.  I noticed
that there is also libcrypt which comes with glibc.  Not sure if there
is anything similar for musl or any of the other OSs that are nominally
supported by sane-backends.  At present, it is less work to maintain the
included code than switch to some "standard" library.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] 39ceeae6 breaks md5 auth

2018-01-02 Thread Olaf Meeuwissen
Hi James,

Thanks for the report.

James Ring writes:

> Confirmed that with the offending patch, md5.c produces incorrect
> digests for known input/output pairs. We should roll it back.
>
> Also I couldn't reproduce (with gcc 7.2.0) the compiler warning that
> the original change was supposed to fix.

Hmm, neither can I.  In neither the debian-8-mini nor debian-9-mini CI
environments.  But you can still see it in the CI logs for the last
pipeline that ran before the offending commit.

  https://gitlab.com/sane-project/backends/pipelines/4150861

Only the fedora-24-clang log doesn't have it.

> On Tue, Jan 2, 2018 at 9:57 AM, James Ring <s...@jdns.org> wrote:
>> [...snip...]
>>
>> Reverting that commit restores the functionality. I haven't figured
>> out what the problem is from a cursory inspection of the code, I'll
>> continue staring at it.

I was about to revert the commit but looking at it now I'm wondering
what I was thinking when I committed that :-(  Changing the pointer
type to something of a different size *obviously* screws up the array
indexing!

I've cooked up a fix for that (based on e895ee55).  Could you give the
attached patch a try?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
>From 3651d8c6cd943a1d046e2625bb7bf2eca6f91c42 Mon Sep 17 00:00:00 2001
From: Olaf Meeuwissen <paddy-h...@member.fsf.org>
Date: Wed, 3 Jan 2018 16:13:16 +0900
Subject: [PATCH] Fix array indexing.

This fixes a glaring oversight in 39ceeae6.  Thanks to James Ring for
reporting this.
---
 lib/md5.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/md5.c b/lib/md5.c
index 72b36f35..923a17c7 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -123,6 +123,7 @@ md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
   /* Take yet unprocessed bytes into account.  */
   md5_uint32 bytes = ctx->buflen;
   size_t pad;
+  size_t offset;
 
   /* Now count remaining bytes.  */
   ctx->total[0] += bytes;
@@ -133,9 +134,11 @@ md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
   memcpy (>buffer[bytes], fillbuf, pad);
 
   /* Put the 64-bit file length in *bits* at the end of the buffer.  */
-  ((md5_uint32 *) ctx->buffer)[bytes + pad] = SWAP (ctx->total[0] << 3);
-  ((md5_uint32 *) ctx->buffer)[bytes + pad + 4] = SWAP ((ctx->total[1] << 3) |
-			(ctx->total[0] >> 29));
+  offset = (bytes + pad) / sizeof (md5_uint32);
+  ((md5_uint32 *) ctx->buffer)[offset] = SWAP (ctx->total[0] << 3);
+  offset = (bytes + pad + 4) / sizeof (md5_uint32);
+  ((md5_uint32 *) ctx->buffer)[offset] = SWAP ((ctx->total[1] << 3) |
+	   (ctx->total[0] >> 29));
 
   /* Process last bytes.  */
   md5_process_block (ctx->buffer, bytes + pad + 8, ctx);
-- 
2.11.0

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org

Re: [sane-devel] Reflecta DigiDia 5000 not found

2017-12-28 Thread Olaf Meeuwissen
Hi,

Reinhard Kotucha writes:

> [...]
> I could probably improve the results if anybody tells me what these
> values mean and how to apply them:
>
>   FilmMatR1.4234   -0.32300.0061   -29.7088;
>   FilmMatG0.06000.96770.0719   -31.3147;
>   FilmMatB0.1562   -0.51041.4530   -28.9059;

I'm not sure about the rightmost column but this is a color correction
matrix.  You apply it on the incoming (or gamma corrected?) RGB values
via matrix multiplication like so

 R' = 1.4234 * R + -0.3230 * G + 0.0061 * B + -29.7088
 G' = 0.0600 * R +  0.9677 * G + 0.0719 * B + -31.3147
 B' = 0.1562 * R + -0.5104 * G + 1.4530 * B + -28.9059

R, G, B are the values before correction, R', G' and B' the ones after.
You may have to clamp the results into the [0,255] range (assuming 8bit
samples).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] saned@service environment question

2017-12-06 Thread Olaf Meeuwissen
Hi,

Apologies for the belated reply.

ToddAndMargo writes:

> On 11/25/2017 01:09 AM, Olaf Meeuwissen wrote:
>> Hi ToddAndMargo,
>>
>> ToddAndMargo writes:
>>
>>> Dear list,
>>>
>>> In the man page, the script for saned@.service shows:
>>
>> # OK, you are reading the documentation, just rather selectively ;-)
>>
>>> Environment=SANE_CONFIG_DIR=/etc/sane.d
>>> # If you need to debug your configuration uncomment the next line and
>>> # change it as appropriate to set the desired debug options
>>> # Environment=SANE_DEBUG_DLL=255 SANE_DEBUG_BJNP=5
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1091566#c8
>>> also adds:
>>>
>>> #Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128
>>>
>>> Question:
>>> Do you un-comment the all, or only uncomment one of them?
>>
>> You add the SANE_DEBUG_* variables for the backends you want to debug.
>> In your case, you probably want to look at least at SANE_DEBUG_DLL and
>> SANE_DEBUG_NET and the backend that supports your particular scanner.
>>
>>> Question:
>>>
>>> Should it not be?
>>>
>>> Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
>>> SANE_DEBUG_BJNP=5 SANE_DEBUG_NET=128
>>>
>>> all run togther with spaces as the demlimier?
>>
>> Please read the systemd documentation.  I vaguely seem to remember all
>> the Environment "assignments" are run together by systemd, though.
>>
>> # Disclaimer: I no longer use systemd.
>>
>>> Questions:
>>>
>>> What is
>>> SANE_CONFIG_DIR=/etc/sane.d
>>
>> An environment variable that tells the dll (and most other backends)
>> where to look for their configuration.  See sane-dll(5).
>>
>>> SANE_DEBUG_DLL=255
>>> SANE_DEBUG_BJNP=5, and
>>> SANE_DEBUG_NET=128
>>
>> Environment variables that tell each of the backend how much to log.
>> Larger values produce more output.  What and how much exactly differs
>> between backends.
>>
>> Hope this helps,
>
> Not really, but thank you for trying.
>
> What systemd documentation are you speaking of?

The documentation you get from `man systemd` and what it lists in the
SEE ALSO section.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [inactive] options

2017-11-30 Thread Olaf Meeuwissen
Hi,

ylafont writes:

> I am trying to scan legal size pager over the ADF,   when setting the Scan
> area to legal on the command line, they are changed  back to letter size
>
> *scanimage: rounded value of br-x from 215.9 to 215.872
> scanimage: rounded value of br-y from 355.6 to 279.364
> *
>
> There are inactive options listed for the backend,  Is there a method of
> activating them for this purpose?
>
> *All options specific to device `net:localhost:fujitsu:fi-4220C2dj:100742':
> *
>   Geometry:
> -l 0..224.846mm (in steps of 0.0211639) [0]
> Top-left x position of scan area.
> -t 0..296.972mm (in steps of 0.0211639) [0]
> Top-left y position of scan area.
> -x 0..224.846mm (in steps of 0.0211639) [215.872]
> Width of scan-area.
> -y 0..296.972mm (in steps of 0.0211639) [279.364]
> Height of scan-area.
>* --page-width 0..224.846mm (in steps of 0.0211639) [inactive]*
> Specifies the width of the media.  Required for automatic centering
> of
> *sheet-fed scans.
> --page-height 0..863.489mm (in steps of 0.0211639) [inactive]*
> Specifies the height of the media.

Are these *really* *all* the options?  I'd expect some option to select
the APF (assuming this device also does flatbed/glass plate).  If there
is such an option, try fiddling with the ordering.  Specifically, put
the option selecting the ADF first.

> *backend - fujitsu:fi-4220C2dj:*
>
> *scanimage (sane-backends) 1.0.22; backend version 1.0.22*
>
> Any assistance is greatly appreciated.  Thank you in advance.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Kodak (FUNAI) Verite 55W ECO Scanner/Printer

2017-11-29 Thread Olaf Meeuwissen
Hi Ronald,

Ronald Modesitt writes:

> OS: Linux Mint 18.1
> PC: Dell P690, Two dual core Xeon processors, 16 Gb ram
> Scanner: FUNAI Verite 55W ECO (AIO device)
>
> Unable to install the above scanner, printer works.
> Downloaded and installed printer and scanner device drivers.
> Printer device driver works fine and printer utility shows in Mint menu.
> No utility displays for the scanner, but I don't know that it should.
> Scanner is not found by Simple Scan, however sane-find-scanner finds the
> scanner as follows.
>
> found USB scanner (vendor=0x0f1c [FUNAI], product=0x0123 [KODAK VERITE 55W
> ECO]) at libusb:001:002
>
> Actions taken:
> - added 'funai' to dll.conf file
> - created funai.conf file with line
> usb 0x0f1c 0x0123
>
> Any advice would be greatly appreciated.

This vendor and device are completely unknown to SANE :-(

However, a quick search led me to

  http://www.funaihelp.com/kodak/printer/downloads

where they have 32bit and 64bit scanner drivers for Linux.  The "terms
of use" are decidedly non-free but at this point, that driver may be all
that you have to go on. :-(

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Iscan and Ubuntu 17.10/18.04 fixed

2017-11-26 Thread Olaf Meeuwissen
Hi Klaus,

staedtler-przyborski writes:

> Am 19.11.2017 um 09:14 schrieb Olaf Meeuwissen:
>
>> I read through the bug report you mentioned below and think the whole
>> thing sucks.  Ubuntu has made a *huge* judgement error pulling an
>> *experimental* package for their upcoming release just to get a newer
>> version of the SANE backends upstream.  A lot of scanners supported by
>> third party scanner break for no good reason.
> Reverting this decision would definitely be the best solution.
>
> But who knows (I'm not affiliated to ubuntu in any way, I'm only using
> it). In that case it's good to have workarounds to overcome the limitations.

I'm not affiliated with Ubuntu either (but I do have a Launchpad
account) and I no longer use any of the 'buntus.  I don't let those kind
of "details" get in my way when a "dumb decision" wrecks my workflow or
causes me lots of extra work.  If the maintainers of your preferred
distribution(s) break things, it's up to them to fix them (possibly with
the help of knowledgeable users) and not the upstream project.

> Thanks to another user we got now Brother brscan4 based scanners working
> too (by using an unconventional approach) with relevant scanning apps
> (Xsane, scanimage, simple-scan, scantopdf)and as user.

Oh yeah, hwdb files, yet another systemd thingy.  Our sane-desc utility
know how to create these files since the summer of 2013.  I'm not sure
if any distribution uses them but that would probably not have helped
those brscan4 users anyway.

> Summary of all workarounds:
>
> https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1728012/comments/76

Thanks for the feedback,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] need network syntax for saned.conf

2017-11-25 Thread Olaf Meeuwissen
Hi,

ToddAndMargo writes:

>>
>> Le samedi 25 novembre 2017, 01:38:56 ToddAndMargo a écrit :
>>> Hi All,
>>>
>>> In saned.conf,
>>>
>>> what is the proper syntax to allow all IP from a particular network:
>>>
>>> 192.168.100.0/24
>>>
>>> and what is the syntax allow a range of networks:
>>>
>>> 192.168.100.0/24 through 192.168.105.0/24
>>>
>>>
>>> Many thanks,
>>> -T
>>
>
> On 11/25/2017 02:05 AM, e.m...@orange.fr wrote:
>  > Hello Sir,
>  >
>  > I'm not a specialist of sane but my search engine with "man
> saned.conf" gave
>  > me the following page
>  > https://linux.die.net/man/8/saned
>  > where I see an example
>  ># Access list
>  >scan-client.somedomain.firm
>  ># this is a comment
>  >192.168.0.1
>  >192.168.2.12/29
>  >[::1]
>  >[2001:7a8:185e::42:12]/64
>  >
>  > Is it clear enough?
>  >
>  > Have a nice Saturday
>  >
>  > Regards
>
>
> Actually no.
>
> I had found that portion, but got frustrated with them
> calling "hostnames" as "IP addresses".  Not the same
> thing.  Hostname is before the IP address is resolved.

You're right that host names and IP addresses are not the same thing,
but the saned manual page says:

  The access list is a list of host names, IP addresses or IP subnets
  (CIDR notation)

It doesn't say they are the same thing.  It just says that you can use
whatever combination of these three is most convenient for you.

> And "192.168.2.12/29" which only gives you a single IP
> address with its subnet mask.

Using that would allow access from all eight IPv4 addresses that have
the same 29 initial bits as 192.168.2.12.  Please note that the CIDR
notation was introduced exactly to allow addressing on arbitrary bit
boundaries.

See https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

> The above line shows that
> you do not need the subnet mask.  xxx.xxx.xxx.0/24
> tells you  all the IP's from xxx.xxx.xxx.1 to 255
>
> Can I get away with 192.168.222.0/23?  That would
> be 192.168.222 to 223. 1 to 255

Yes.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] saned@service environment question

2017-11-25 Thread Olaf Meeuwissen
Hi ToddAndMargo,

ToddAndMargo writes:

> Dear list,
>
> In the man page, the script for saned@.service shows:

# OK, you are reading the documentation, just rather selectively ;-)

> Environment=SANE_CONFIG_DIR=/etc/sane.d
> # If you need to debug your configuration uncomment the next line and
> # change it as appropriate to set the desired debug options
> # Environment=SANE_DEBUG_DLL=255 SANE_DEBUG_BJNP=5
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1091566#c8
> also adds:
>
> #Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128
>
> Question:
> Do you un-comment the all, or only uncomment one of them?

You add the SANE_DEBUG_* variables for the backends you want to debug.
In your case, you probably want to look at least at SANE_DEBUG_DLL and
SANE_DEBUG_NET and the backend that supports your particular scanner.

> Question:
>
> Should it not be?
>
> Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
> SANE_DEBUG_BJNP=5 SANE_DEBUG_NET=128
>
> all run togther with spaces as the demlimier?

Please read the systemd documentation.  I vaguely seem to remember all
the Environment "assignments" are run together by systemd, though.

# Disclaimer: I no longer use systemd.

> Questions:
>
> What is
>SANE_CONFIG_DIR=/etc/sane.d

An environment variable that tells the dll (and most other backends)
where to look for their configuration.  See sane-dll(5).

>SANE_DEBUG_DLL=255
>SANE_DEBUG_BJNP=5, and
>SANE_DEBUG_NET=128

Environment variables that tell each of the backend how much to log.
Larger values produce more output.  What and how much exactly differs
between backends.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Everyone!

2017-11-25 Thread Olaf Meeuwissen
Hi ToddAndMargo,

ToddAndMargo writes:

>>> Em sex, 24 de nov de 2017 09:47, ToddAndMargo >> > escreveu:
>>>
>>> On 11/24/2017 03:44 AM, ToddAndMargo wrote:
>>>  > Hi All,
>>>  >
>>>  > What to I do to saned.conf to tell it I want EVERYONE to
>>>  > be able to access it?
>>>
>>> Both network users and all users in general
>>>
>
> On 11/24/2017 05:26 PM, Luiz Angelo Daros de Luca wrote:
>> Add a single + in a line.
>
> I do not understand.
>
> I should have said I was speaking of
>  /etc/sane.d/saned.conf

Straight from the saned manual page in the CONFIGURATION section

  CONFIGURATION
 First and foremost: saned is not intended to be exposed to the
 internet or other non-trusted networks. Make sure that access
 is limited by tcpwrappers and/or a fire‐ wall setup. Don't
 depend only on saned's own authentication. Don't run saned as
 root if it's not necessary. And do not install saned as setuid
 root.

 The saned.conf configuration file contains both options for the
 daemon and the access list.

 data_portrange = min_port - max_port
Specify the port range to use for the data
connection. Pick a port range between 1024 and 65535;
don't pick a too large port range, as it may have
performance issues. Use this option if your saned server
is sitting behind a firewall. If that firewall is a
Linux machine, we strongly recommend using the Netfilter
nf_conntrack_sane module instead.

 The access list is a list of host names, IP addresses or IP
 subnets (CIDR notation) that are permitted to use local SANE
 devices. IPv6 addresses must be enclosed in brackets, and
 should always be specified in their compressed
 form. Connections from localhost are always permitted. Empty
 lines and lines starting with a hash mark (#) are ignored.  A
 line containing the single character ``+'' is interpreted to
 match any hostname. This allows any remote machine to use your
 scanner and may present a security risk, so this shouldn't be
 used unless you know what you're doing.

> I am look at how to add all users and all networks.  I want
> everyone to be able to access the scanner.

Reading or searching the documentation might help ;-)

Hope this helps,
--
Sent with my mu4e

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] What compiler switch for systemd support?

2017-11-21 Thread Olaf Meeuwissen
Hi ToddAndMargo,

ToddAndMargo writes:

> Dear List,
>
> Anyone know what the compiler switch is to compile
> in explicit systemd support?

  $ ./configure --help | grep systemd
--with-systemd  enable systemd support [default=yes]

So, --with-systemd would be the configure time option to use.
Of course, you will need the systemd development packages installed
(probably libsystemd-dev or similar).

With the flag, configure will abort with an error if the requirements to
build in systemd support are not satisfied.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Iscan and Ubuntu 17.10/18.04 fixed

2017-11-19 Thread Olaf Meeuwissen
Hi Klaus, Jörg,

staedtler-przyborski writes:

> [... Ubuntu using libsane1-1.0.27-1~experimental* packages breaks just
> about any third party SANE backend package ...]
> In the meanwhile we got the following backends working by doing these steps:
>
> 1. Brother: brscan, brscan2, brscan3
> 2. Epson Iscan
> 3. Xerox Workcentre 3225

I read through the bug report you mentioned below and think the whole
thing sucks.  Ubuntu has made a *huge* judgement error pulling an
*experimental* package for their upcoming release just to get a newer
version of the SANE backends upstream.  A lot of scanners supported by
third party scanner break for no good reason.

I think things can actually be solved quite easily if Jörg can upload a
libsane-1.0.27 package that simply uses the debian/* from 1.0.25 with a
few minor changes:

 - change the configure invocation to account for the changed USB option
   (see note 2 of the NEWS file)
 - drop any patches that we included (mentioned in an earlier head's up)
 - the usual "new version" changes

This can be uploaded to Debian's unstable/sid and Ubuntu can then pull
that for their upcoming release.

> Any help/advice appreciated.

See above.

@Jörg> You can stop reading here and start on that package ;-)

> The owner of the brscan4 Scanner asked Brother. They replied: "read the
> faq, or check over internet if there are solutions from the community".

That's a polite way of saying "We don't support GNU/Linux" :-(

Brother is not alone in this.  Manufacturers may publish a package that
makes the device work with (a subset of?) SANE but that is not the same
as providing support.

> current state can be observed here
> https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1728012

Ugh!

> Some people call using 'MODE="0777" for epson dangerous. The rule was
> installed by the epson-printer-utility. With the rule Iscan works,
> without not.

A mode of 0777 gives anyone on the PC/laptop access to the scanner (MFP
in your case, I believe).  Whether that is "dangerous" depends on who
uses th PC/laptop.  The idea behind 0664, used by many distributions,
and making the device owned by a special purpose group (scanner, lp,
etc.) or adding an ACL for that group is that that allows the machine's
admin to configure some kind of access policy.

I think that 0666 should work but that basically has the same security
implications.  I don't know if the printer utility has any special
requirements that dictate execute permissions and also don't know what
is responsible for the firmware upload.  I do know that the non-free
scanner plugin are (should be) able to upload the firmware themselves.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Iscan and Ubuntu 17.10/18.04 fixed

2017-11-18 Thread Olaf Meeuwissen
Hi,

staedtler-przyborski writes:

> Dear Sane developers,
>
> all Iscan dependend Epson scanners refused to work with Ubuntu 17.10
> (and 18.04)
>
> see https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1707352.

What a mess.  Changing the package name from libsane to libsane1 and
then expecting nothing breaks???  The Provides: libsane is absolutely
required until all depending packages have been updated to require the
new libsane1 package.

The issue with third party package does not end there.  A lot of them
were created before "multi-arch" so they install in /usr/lib/sane or
/usr/lib64/sane, not in some really architecture dependent place such as
/usr/lib/x86_64-linux-gnu/sane.  There is little change that third party
*vendor* packages will be rebuilt to fix this.

As far as iscan and its interpreters are concerned, to the best of my
knowledge they are no longer actively maintained.  Good luck prodding
EPSON in fixing this.

# Full disclosure: I work at a daughter company of EPSON and have been
# taking care of iscan for over a decade (and spent about five years
# working on utsushi, aka imagescan).

> I know it is not your fault. But maybe some users try to find a solution
> on the sane-devel-mailing- list.

Fortunately not.

> I discovered today a simple fix for this bug (after updating libsane to
> :libsane1 1.0.27-
>
> 1~experimental2ubuntu2.1, curently in proposed).
>
> Copy (or move) the files from /usr/lib/sane (libsane-epkowa.la, libsane-
> epkowa.so.1, libsane-epkowa.so.1.0.15 in my case) to
> /usr/lib/x86_64-linux-gnu/sane

Actually, I'd leave them where they are and create symlinks to them from
where they are expected.  After moving them back to /usr/lib/sane

  cd /usr/lib/x86_64-linux-gnu/sane
  ln -s ../../sane/libsane-epkowa.la
  ln -s ../../sane/libsane-epkowa.so.1
  ln -s ../../sane/libsane-epkowa.so.1.0.15

> after a reboot the Iscan dependend scanners (verified with a Epson V300)
> start to work.

You shouldn't have to reboot.  Just restart your application.

> Maybe Epson delivers updated packages some day so the manual correction
> will be unnecessary

Like I said, good luck with that.

Hope this helps
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Can't use scanner on Mac High Sierra (10.13)

2017-11-18 Thread Olaf Meeuwissen
Hi again,

Olaf Meeuwissen writes:

> Hi Tom,
>
> Cc:ing the list for the benefit of everyone.
>
> Tom Myers writes:
>
>> I have faith that we will get the code to work with High Sierra. I
>> have now been able to build the software now and in my “spare” time
>> trying to debug why it isn’t connecting. It works on 10.11, but not
>> 10.12 or 10.13 so I am hopeful either I find the problem or the group
>> finds the issue.  I figured since I have access to the 12000XL and
>> noticed it wasn’t in there I would share it with the group.
>>
>> Thanks for all the work you do.
>>
>>> On Nov 9, 2017, at 7:51 AM, Olaf Meeuwissen <paddy-h...@member.fsf.org> 
>>> wrote:
>>>
>>> Hi Tom,
>>>
>>> Tom Myers writes:
>>>
>>>> I have been able to build the SANE-Backends-1.0.27 But running it
>>>> gives a problem on USB scanners. It works fine with network scanner
>>>>
>>>> ――― Building ---
>>>>
>>>> ./configure BACKENDS="epson2" PRELOADABLE_BACKENDS="epson2" --with-usb
>>>> make
>>>> make install
>>>>
>>>> Note it would be great if the epson2.desc file be updated for the new 
>>>> 12000XL
>>>>
>>>> :model  "Expression 12000XL"
>>>> :interface  "USB"
>>>> :usbid  "0x04b8" "0x015b"
>>>> :status :good
>>>> :comment    "overseas version of the DS-G2"
>>>
>>> I'd gladly do so but ... seeing that you have trouble using it via USB
>>> on your Mac, what makes you confidently say that this should be added to
>>> the epson2.desc file?
>
> So seeing that it works on 10.11 (but not on 10.12 and 10.13, yet?),
> I'll add it to the epson2.desc (and epson2_usb.c) file.

Done.  Changes are in d6a93b83.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Canon MF231

2017-11-17 Thread Olaf Meeuwissen
Hi Orkhan,

Orkhan Guliyev writes:

> Hello.
>
> I install printer driver for this device from Canon official site. All
> is good, and I can print documents. But with scanner situation is bad. I
> see inSANE project page
> <http://www.sane-project.org/sane-mfgs.html#Z-CANON>that Canon MF231 is
> fully supported but system doesn't see any scanner device from USB.

It is fully supported since 2017-04-26.  sane-backends-1.0.27 was
released 2017-05-22, so based on

> [...]
> And finally this is report of `apt list libsane-dev -a`:
>
> libsane-dev/xenial 1.0.27+git20171029-xenial0 amd64 [can be updated: 
> 1.0.25+git20150528-1ubuntu2.16.04.1]
> libsane-dev/xenial-updates,now 1.0.25+git20150528-1ubuntu2.16.04.1 amd64 
> [installed, can be updated: 1.0.27+git20171029-xenial0]
> libsane-dev/xenial 1.0.25+git20150528-1ubuntu2 amd64

I'd say you have to upgrade your libsane package as you appear to have
1.0.25+git20150528-1ubuntu2.16.04.1 installed 'now'.

The output you show is a bit misleading as it shows all the packages
that are *available*, not just the ones that are installed.  Check with

  apt-cache policy libsane

to see what version is installed and upgrade to a 1.0.27 version.

BTW, you don't need libsane-dev, just libsane.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Can't use scanner on Mac High Sierra (10.13)

2017-11-14 Thread Olaf Meeuwissen
Hi Tom,

Cc:ing the list for the benefit of everyone.

Tom Myers writes:

> I have faith that we will get the code to work with High Sierra. I
> have now been able to build the software now and in my “spare” time
> trying to debug why it isn’t connecting. It works on 10.11, but not
> 10.12 or 10.13 so I am hopeful either I find the problem or the group
> finds the issue.  I figured since I have access to the 12000XL and
> noticed it wasn’t in there I would share it with the group.
>
> Thanks for all the work you do.
>
>> On Nov 9, 2017, at 7:51 AM, Olaf Meeuwissen <paddy-h...@member.fsf.org> 
>> wrote:
>>
>> Hi Tom,
>>
>> Tom Myers writes:
>>
>>> I have been able to build the SANE-Backends-1.0.27 But running it
>>> gives a problem on USB scanners. It works fine with network scanner
>>>
>>> ――― Building ---
>>>
>>> ./configure BACKENDS="epson2" PRELOADABLE_BACKENDS="epson2" --with-usb
>>> make
>>> make install
>>>
>>> Note it would be great if the epson2.desc file be updated for the new 
>>> 12000XL
>>>
>>> :model  "Expression 12000XL"
>>> :interface  "USB"
>>> :usbid  "0x04b8" "0x015b"
>>> :status :good
>>> :comment"overseas version of the DS-G2"
>>
>> I'd gladly do so but ... seeing that you have trouble using it via USB
>> on your Mac, what makes you confidently say that this should be added to
>> the epson2.desc file?

So seeing that it works on 10.11 (but not on 10.12 and 10.13, yet?),
I'll add it to the epson2.desc (and epson2_usb.c) file.

BTW, you are adding the USB info to your epson2.conf (or epson2_usb.c),
aren't you?  You probably also need to do something to get read/write
access to the device when the OS first sees it (or try with root
privileges).  Don't know what you did on 10.11 but maybe things have
changed for 10.12 and 10.13 in that area.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Epson WorkForce DS-1630

2017-11-12 Thread Olaf Meeuwissen
Hi Isabelle,

Isabelle Barbe writes:

> Hi Olaf and Ralph !
>
> Thank you very much for your prompt answer.
>
> The last one was the XP-435, supported by their Image Scan V3, too,
> but XP-435 wasn't able to work properly with the SANE :( I had always
> to install the drivers before using it.  It was so upsetting that we
> throught it away and bought a new Printer (Canon IP110) and now we are
> looking for a scanner which works with Linux (Image Scan V3 doesn't
> run properly in Linux and was enable to recognise this d.. scanner
> !!!).

That's

  
https://alioth.debian.org/tracker/index.php?func=detail=315720_id=30186=410366

right?  Sorry that didn't work out for you.

> As far as the WorkForce DS-1630 is concerned I've read that SANE doesn't
> run with USB3 ? and in the french description (easier to read when we
> are Frenches) I read that this one is just working with USB-3...

SANE does work with USB-3 in a large number of cases but sometimes
people run into trouble.  This most often happens with old versions of
libsane and/or older Linux kernel versions.

If the DS-1630 truly only works with USB-3, then you should check the
USB ports on your computer first.  If those aren't USB-3, there is no
point in buying a DS-1630.

That said, USB-3 devices should fall back to using USB-2 (e.g. if the
computer only has USB-2 ports) and still work but with a possible
decrease in data throughput (i.e. your scans will go slower).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Saned Tutorial is not correct -

2017-11-10 Thread Olaf Meeuwissen
Hi Louis,

Louis Lagendijk writes:

> On Thu, 2017-11-09 at 20:53 +0900, Olaf Meeuwissen wrote:
>> Hi Alvaro,
>>
>> Simon Matter writes:
>> (that you wrote)
>> > > The mistake is also in the man pages:
>> > >
>> > > using Ubuntu 16.04:  man saned
>> > >
>> > > excerpt start:
>> > >
>> > > SYSTEMD CONFIGURATION
>> > >for systemd we need to add 2 configuation files in
>> > > /etc/systemd/system.   < This
>> > > should
>> > > be
>> > > /etc/systemd
>> >
>> > I'm not sure but at least on RHEL7 /etc/systemd/system seems
>> > correct. Can
>> > it be that Ubuntu 16.04 uses an older systemd and therefore the
>> > manpage
>> > should be changed? If yes, then this has to be done in the Ubuntu
>> > packages
>> > of SANE.
>>
>> Please take a look at the Directories section of the systemd manual
>> page[1]
>> and the systemd.unit manual page[2] for Ubuntu 16.04LTS.
>>
>>  [1]: http://manpages.ubuntu.com/manpages/xenial/en/man1/systemd.1.ht
>> ml#contenttoc5
>>  [2]: http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.unit
>> .5.html
>>
>> Based on my understanding of the documentation there, I would say
>> that
>> Ubuntu's(?) saned manual page[3] (which is not modified from the one
>> that the SANE project ships in this respect) refers to the correct
>> directory locations.  If that in some way does not work, it's first
>> and
>> foremost an issue with the Ubuntu tutorial[4] and Ubuntu's systemd
>> and/or SANE packages.
>>
>>  [3]: http://manpages.ubuntu.com/manpages/xenial/en/man8/saned.8.html
>>  [4]: https://help.ubuntu.com/community/SaneDaemonTutorial
>>
>> You may also want to take a look of the files provided by Ubuntu's
>> sane-utils package[5] and note that these files should be installed
>> for
>> you by the package, completely obviating the need for you to
>> configure
>> anything.
>>
>>  [5]: https://packages.ubuntu.com/xenial/amd64/sane-utils/filelist
>
> The locations mentioned in the man-page are definitely correct for
> Fedora and RHEL,  the only systems using systemd at the time I wrote
> the systemd parts of the man-page (in 2013). For these distros they are
> still correct.
> Now Ubuntu may have changed some of the paths when it introduced
> systemd. It may also be the case that Ubuntu does use an old version of
> systemd that does not yet support the user specific units (in
> /etc/systemd/user).

Old systemd version is unlikely for Ubuntu 16.04LTS (from 2016).  If
they willy-nilly change paths, the onus is on them to keep the docs in
sync, IMNSHO.

> Can somebody please confirm if other Ubuntu
> versions (probably later versions) do use /etc/systemd/system?

My Devuan Jessie system doesn't *have* systemd(!), but sports an
/etc/systemd/system/ directory.  Ditto for Devuan's next version.

But everyone should look at what's already in /lib/systemd/system/
instead.  The Debian/Devuan packages put the necessary files there
already.  You should not even need to do anything if you installed
the distribution's binary packages.

On Jessie, I get

  $ dpkg -S lib/systemd/system/saned
  sane-utils: /lib/systemd/system/saned.service
  sane-utils: /lib/systemd/system/saned@.service
  sane-utils: /lib/systemd/system/saned.socket

> If I can find some time I may try to clarify the man-page with the
> alternate location if we can get more clarity on this.

If the distribution packages don't do the right thing file a bug report
with the distribution.  If one builds from source, /etc/systemd/system/
is the right place, according to the systemd documentation.

If the systemd documentation is wrong, bug the systemd cabal ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Can't use scanner on Mac High Sierra (10.13)

2017-11-09 Thread Olaf Meeuwissen
Hi Tom,

Tom Myers writes:

> I have been able to build the SANE-Backends-1.0.27 But running it
> gives a problem on USB scanners. It works fine with network scanner
>
> ――― Building ---
>
> ./configure BACKENDS="epson2" PRELOADABLE_BACKENDS="epson2" --with-usb
> make
> make install
>
> Note it would be great if the epson2.desc file be updated for the new 12000XL
>
> :model  "Expression 12000XL"
> :interface  "USB"
> :usbid  "0x04b8" "0x015b"
> :status :good
> :comment"overseas version of the DS-G2"

I'd gladly do so but ... seeing that you have trouble using it via USB
on your Mac, what makes you confidently say that this should be added to
the epson2.desc file?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Epson WorkForce DS-1630

2017-11-09 Thread Olaf Meeuwissen
Hi Isabelle,

Ralph Little writes:

> Hi,Don't know about SANE but the US Epson website mentions that they
> have a Linux scanner driver for it (just in case if you are not aware
> of it).  I don't have any experience with it and they explicitly state
> that they do not provide support for it, which seems like a bit of a
> cop-out.So no guarantees of course. :(
>
> https://epson.com/faq/SPT_B11B206201~faq-205960
>
> ..and search for the model.

Thanks for the follow-up Ralph.

If the EPSON download site says it's supported by their Image Scan V3,
you should be able to use it with any SANE frontend after installing
Image Scan V3.

In addition, there is a *chance* that it works (to some extent) with one
of the epsonds, epson2 and epson backends.

>   From: Isabelle Barbe <ia.ba...@laposte.net>
>  To: sane-devel@lists.alioth.debian.org
>  Sent: Wednesday, November 8, 2017 9:42 AM
>  Subject: [sane-devel] Epson WorkForce DS-1630
>
> Good afternoon !
>
> Before buying this mentionned scanner I need to know if Libsane
> recognise it. I don't see any mention about it at
> http://www.sane-project.org/sane-mfgs.html#Z-EPSON.

That's because, unfortunately, EPSON does not provide information
linking model names to USB product IDs and SANE does not include third
party backend information in that page :-(

If EPSON provided the linking information, I'd be able to create a much
more useful utsushi.desc file.  And if SANE added third party backends
to those pages, you'd actually be able to find it.

# We could do something about the latter though.

You won't find the DS-1630 there (yet?), but, FWIW, the utsushi.desc
info is at

  http://www.sane-project.org/lists/sane-backends-external.html#S-UTSUSHI

If you can tell me the USB product ID for the DS-1630, I'll fix that
right away.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Saned Tutorial is not correct -

2017-11-09 Thread Olaf Meeuwissen
Hi Alvaro,

Simon Matter writes:
(that you wrote)
>> The mistake is also in the man pages:
>>
>> using Ubuntu 16.04:  man saned
>>
>> excerpt start:
>>
>> SYSTEMD CONFIGURATION
>>for systemd we need to add 2 configuation files in
>> /etc/systemd/system.   < This should
>> be
>> /etc/systemd
>
> I'm not sure but at least on RHEL7 /etc/systemd/system seems correct. Can
> it be that Ubuntu 16.04 uses an older systemd and therefore the manpage
> should be changed? If yes, then this has to be done in the Ubuntu packages
> of SANE.

Please take a look at the Directories section of the systemd manual page[1]
and the systemd.unit manual page[2] for Ubuntu 16.04LTS.

 [1]: 
http://manpages.ubuntu.com/manpages/xenial/en/man1/systemd.1.html#contenttoc5
 [2]: http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.unit.5.html

Based on my understanding of the documentation there, I would say that
Ubuntu's(?) saned manual page[3] (which is not modified from the one
that the SANE project ships in this respect) refers to the correct
directory locations.  If that in some way does not work, it's first and
foremost an issue with the Ubuntu tutorial[4] and Ubuntu's systemd
and/or SANE packages.

 [3]: http://manpages.ubuntu.com/manpages/xenial/en/man8/saned.8.html
 [4]: https://help.ubuntu.com/community/SaneDaemonTutorial

You may also want to take a look of the files provided by Ubuntu's
sane-utils package[5] and note that these files should be installed for
you by the package, completely obviating the need for you to configure
anything.

 [5]: https://packages.ubuntu.com/xenial/amd64/sane-utils/filelist

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

2017-11-04 Thread Olaf Meeuwissen
Hi Alex,

Sorry for the belated follow-up.

Alex ARNAUD writes:

> Le 28/09/2017 à 15:45, Olaf Meeuwissen a écrit:
>> Hi Alex,
>>
>> Based on a quick `git grep -i iris` on the sane-backends source code,
>> the only Irisscan device known to be supported is the "Express 2".  If
>> the "executive 4" has a USB port, could you provide the USB product ID?
>>
>> Connect the device, power it up, run `lsusb` and post the output.
>
> Hi Olaf,
>
> This is what I get when I plug the device and look at dmesg:
>
>> 469.816835] usb 1-6.3: new high-speed USB device number 13 using xhci_hcd
>> [  469.921775] usb 1-6.3: New USB device found, idVendor=0a38, idProduct=0162
>> [  469.921779] usb 1-6.3: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [  469.921782] usb 1-6.3: Product: IRIScanExec4
>> [  469.921784] usb 1-6.3: Manufacturer: IRIS
>> [  469.921787] usb 1-6.3: SerialNumber: A08805056B700953
>
> Best regards.

The only entry we have for idVendor=0a38 has idProduct=0301 and it's in
the list of unsupported devices :-(

 http://sane-project.org/cgi-bin/driver.pl?manu===any=0a38=0301

Hope this helps (guess it doesn't),
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Xerox WorkCentre 6515 support

2017-10-09 Thread Olaf Meeuwissen
Hi Michael,

Michael Eager writes:

> I wondered if there was SANE support for the Xerox WC 6515 MFC scanner, or if 
> it could be added.  It
> appears that the Xerox Phaser 6110MFP is supported and my guess is that the 
> two are similar.  (The
> driver DVD with the 6515 also contains support for the 6110.)
>
> The 6515 is connected using USB and lsusb gives the following:
>ID 0924:42e1 Xerox

Didn't find that in the lists of supported scanners in the development
version's code base.  So, you're going out on a limb here ;-)

> I have downloaded the sane-backend SRPM (from Fedora 25), added an entry for 
> the 6515 to
> xerox_mfp.conf.in, and rebuilt the SRPM.  After installing the RPM, when I 
> try to run "scanimage -L"
> the scanner is not recognized.  Running with SANE_DEBUG_DLL=5, the xerox_mfp 
> lib is loaded.  I don't
> see any debug messages from the xerox_mfp or xerox_mpf_usb routines.

SANE_DEBUG_DLL only influences the debugging support for the dll
backend.  For the xerox-mfp backend, use SANE_DEBUG_XEROX_MFP.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Supported languages?

2017-10-01 Thread Olaf Meeuwissen
Hi Yury,

Yury Tarasievich writes:

> Does scanimage actually contain the l10n
> functionality?

Good question!

While the backends have their messages translated to some 20 languages,
it is the SANE frontend's responsibility to activate translation.  I did
a quick check of the scanimage source code and it doesn't seem to do so.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Best way to stop scanimage?

2017-09-29 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

> Thank you Olaf, :-)
>
> I am developing a php interface I'm calling it php saneng I have it on
> bitbucket for now and using proc_open. I will send the signal via
> proc_terminate giving it the second option being the signal I want to use.
> I had a similar project I got working in the past specifically for my
> scanner and I seem to recall I was giving it signal SIGTERM and I think
> that was causing issues where as when I would test from the command line
> and use ctrl+c it would leave the scanner in a usable state. So now that I
> read about what ctrl+c sends (SIGINT) I think it would be better to send
> that. Maybe there is something wrong with brothers backend that it prefers
> a SIGINT over a SIGTERM. I'll experiment and let you know once I get my
> project a little farther along. My similar project I had got working was
> destroyed when an upgrade failed and I forgot to back it up. No biggy I
> should have a better working one in a few weeks.

The sighandler in scanimage simply calls sane_cancel() the first time
around and _exit(0) the second.  The signal would normally be handled
by the scanimage frontend.  Some backends register their own handlers
which may change the picture I painted in my earlier mail.

# Sorry, didn't think things thru.  It's Friday night ...

Since Brother's backend is a non-free black box, you're in the dark as
to what it does and just have to give things a try :-(

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [PATCH v2] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

2017-09-29 Thread Olaf Meeuwissen
Hi Luiz,

Thanks for the patch.  LGTM with the exception of the manual page and a
typo in the -h output.  I've fixed the typo and brushed up the manual
page's OPTIONS section and pushed the lot.

# I've only reviewed your patch and did not actually test anything.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Best way to stop scanimage?

2017-09-29 Thread Olaf Meeuwissen
Hi Jeff,

Jeff Sadowski writes:

>>> On Thu, Sep 28, 2017 at 10:30 AM, Jeff Sadowski <jeff.sadow...@gmail.com>
>>> wrote:
>>> > Is there a good way to stop scanimage?

> Ooooh Ctrl-C sends the INT(-2) signal that is the signal I think I want.

You've already found out how to solve your issue but here are the
details.

Sending a *single* SIGINT or SIGTERM (and if supported by your system at
compile time SIGHUP or SIGPIPE) will cancel the scan in progress.  This
should leave your scanner in a usable state.

Sending one of these signals again will abort the scan in progress (and
may leave your scanner in an unusable state).

You can send signals with the kill command or via the keyboard.  The
latter is somewhat key binding dependent but usually Ctrl-C will do the
Right Thing.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Compatibility of the Irisscan executive 4 scanner

2017-09-28 Thread Olaf Meeuwissen
Hi Alex,

Alex ARNAUD writes:

> Dear all,
>
> I install Debian GNU/Linux on computer for visual-impaired users and
> I've a request about the compatibility of a Irisscan executive 4 scanner.
>
> I've sought on the internet without finding any specific data about this
> model.

Based on a quick `git grep -i iris` on the sane-backends source code,
the only Irisscan device known to be supported is the "Express 2".  If
the "executive 4" has a USB port, could you provide the USB product ID?

Connect the device, power it up, run `lsusb` and post the output.

Maybe that will turn up extra information.  I am sceptical about
that though, but see below.

> Do you know if this model is compatible with Sane and if yes where I
> could find a tutorial to install it?

If you want to use SANE on Debian GNU/Linux, all you really need to do
is install the sane-utils package.  Next make sure that your users are
members of the scanner and you should be able to use the `scanimage`
command-line utility.

# That's assuming your scanner is supported, of course.

If you have sane-utils installed already (quite likely if you installed
a graphical desktop environment), could you also provide the output of
running `sane-find-scanner`?

# Normally I see rather little value in running this command, but seeing
# that the Irisscan Express 2 is Plustek manufactured and supported by
# the gt68xx backend, it might give a clue as to the chipset which might
# be of use determining how easy/difficult adding support would be in
# case someone is interested in doing so.
#
# That's a lot of "if"s, so don't hold your breath waiting for support
# if your scanner is not supported already ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Canon Pixma G2000

2017-09-09 Thread Olaf Meeuwissen
Hi Iam,

Iam Droidzone writes:

> So, with the latest PPA updates, Ubuntu Xenial recognizes my G2000 as a
> scanner. But I'm having the issue where usblp is claiming the device,
> causing this to appear in dmesg, and the scanning jobs just stutter out:
> "usb 1-1.4: usbfs: interface 1 claimed by usblp while 'scangui' sets config
> #1"

This brings back memories.  Mind you, they're not particularly good
ones.

> I tried many workarounds including writing C code to release the device
> from usblp as documented here:
> https://bugzilla.redhat.com/show_bug.cgi?id=723696#c2
>
> But usblp releases it and then claims it.
> scanimage does not work from command line, or via xsane or scangearmp2.

The libusb_reset_device() function[1] basically does a disconnect and
reconnect of the device, so usblp claiming it again is not a surprise.

 [1]: 
http://libusb.sourceforge.net/api-1.0/group__dev.html#ga7321bd8dc28e9a20b411bf18e6d0e9aa

> Is there a known resolution?

Not that I'm aware of, but you might try modifying your C code to use
the OS specific kernel related libusb APIs[2] to check for an active
kernel driver and detach or attach it as needs be.

 [2]: 
http://libusb.sourceforge.net/api-1.0/group__dev.html#gab14d11ed6eac7519bb94795659d2c971

That's basically what I ended up doing in the sanei_usb.c code for the
third party epkowa backend way back when.  You can find its code at

 http://support.epson.net/linux/src/scanner/iscan/iscan_2.30.3-1.tar.gz

in case you're interested.

I notice that there is now also libusb API that lets you automate this.
Cool, might be something for the sane-backends sanei_usb.c code.

Patches welcome ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

2017-09-09 Thread Olaf Meeuwissen
 any explicit
>> mention of when exactly).
>
> I still think that it is not worth it. It's a problem when you does not
> have an option for changing only a specific behavior. However, a "combo
> option" that aggregates a bundle of options normally used together is good
> (just like rsync -a). My suggestion is to just keep it.

Alright.  As a fairly regular user of it, your rsync -a example
convinced me ;-)

>> You mention something about creating a PID file for the -u option.  That
>> made me think a -p option to specify where you want that file might be a
>> nice addition.  The current location, /var/run/saned.pid, is hard-coded.
>> It's not a bad location but one may want to change it.
>
> I'll take a look. Normally PID file location is something for a
> configuration file.
> Sometimes init would like to take care of the PID file life cycle. Besides
> being hard-coded, if a previous PID file exists, saned should do some
> checks, and abort on failure. Today, if someone manage to run two instances
> of a stand-alone saned, the last one would simply overwrite its own PID
> inside the PID file. Also it should replace PID file instead of simply
> rewriting it. At least it would avoid different code paths (and permission
> requirements) whether a file at PID file exists or not.

Looks like any user with write access to the directory holding the PID
file can clobber it because

  pidfile = fopen (SANED_PID_FILE, "w");

doesn't pass O_EXCL to the underlying open().

On my devuan box, /var/run is a symlink to /run which has 755 perms and
is owned by root.  Digging further, /run is actually a mount point for a
tmpfs.  But anyway, not all systems are created equally.

>> Oh, about the code changes, there are a few places in the manual page
>> I'd change to improve the English but I can do that for you.  There is
>> one mistake though, you document a -B option (as if it were -D).
>
> Yeah, english skill aren't really my "expertise". :-) I do know my
> limitations. Feel free to point me or correct them directly.

I'll correct them directly (if there are any ;-).  It's less overhead
for both of us.

>> I'd drop the SANED_EXEC_* defines you add because they're not used and
>> apart from a minor English nitpick in the option descriptions, the
>> saned.c changes look fine.
>
> Sure. I overlooked that. Thanks.

Hope this helps,

PS: I'll be travelling a bit in the next two weeks so will probably be
late again in following up.
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Supported Epson Perfection 1260 produces 2 background stripe colours

2017-09-08 Thread Olaf Meeuwissen
Hi Julian,

Julian H. Stacey writes:

> Hi Olaf & sane-devel@lists.alioth.debian.org,
>> Hi Julian,
>> Julian H. Stacey writes:
>> > Hi sane-devel@lists.alioth.debian.org
>> >
>> > I have a USB scanner Epson Perfection 1260 (not a printer combo)
>> > half working, using FreeBSD current (3 week old src/ & current
>> > ports/packages) fresh installed sane back end, front end & xsane.
>> >
>> > Example scans here from xsane & scanimage & xscanimage:
>> >http://www.berklix.com/~jhs/tmp/epson_perfection_1260/
>> > all with 2 background colours: yellow on left half of page, red on right.
>
> [...]
>
>> Maybe the log file from
>>   SANE_DEBUG_PLUSTEK=127 scanimage [your-options-here] > out.pnm 2> log
>> can shed some light on your problem?  Please use [your-options-here] to
>> set a small scan area so we don't get inundated with a multi-MB log file
>> here on the list ;-)
>> Hope this helps,
>
> Yes, Thanks ! I scanned a half centimetre wide strip which shows the error,
>   SANE_DEBUG_PLUSTEK=127 scanimage -x200 -y 5  > out.pnm 2> log
> out.pnm is 10K, The log is 170K so for any on a slow net I copied it
> & gzip'ed it to 10K, all here
> http://berklix.eu/~jhs/tmp/epson_perfection_1260/scanimage/1-small/files
> [...]
> I hope the log is useful to someone ?
> I'm reading it with eyes of a newbie, but I see lot of
>   [plustek] usbDev_ScanEnd(), start=1, park=0
>   [plustek] We're little-endian!  NatSemi LM983x is big!
>   [plustek] --> Must swap data!
> line 127:
> /usr/ports/graphics/sane-backends/work/sane-backends-1.0.25/backend/
>   plustek-usbhw.c:DBG( _DBG_READ, "--> Must swap data!\n" );
>
> I dont know the code, if one could debug if swapping is happening OK ?

The usb_HostSwap() function that produces those last two debug lines is
simply a query whether swapping is needed.  I'm not familiar with the
backend's code but the bits that use this function seems to be doing the
swapping on a per pixel basis and do so alright on cursory inspection.
At least for plustek-usbcal.c and plustek-usbimg.c.  I'm a lot less sure
about the correctness of swapping in plustek-usbshading.c seeing code
patterns like

  #ifdef SWAP_COARSE /* sometimes SWAP_FINE */
 if (usb_HostSwap())
  #endif
   usb_Swap(buf, length)

which seems fishy at best.

> Is it concidence the white paper shows yellow then red exactly halfway
> across the page.

Probably not but I have no idea why it would.

@Gerhard> Any ideas?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [#315765] lide220: bad motor noise if scanning app crashes

2017-09-07 Thread Olaf Meeuwissen
Hi list, Hi Farid,

@Farid> Sorry for mistyping your name.

Olaf Meeuwissen writes:

> Hi list,
>
> Farim and I have been going back and forth a bit on the above bug report
> and now Farim has come up with a patch that makes the problem go away.
> Upon glancing it over, things look okay but I'd like some other people
> to review the patch before pushing it.
>
> The problem, insofar I understand, it that cancellation is not triggered
> when the data connection disappears during scans through saned.
>
> You can find the bug report[1] on Alioth.
>
>  [1]: 
> https://alioth.debian.org/tracker/?func=detail=410366=315765_id=30186

Seeing that there was neither response on the list nor it the bug
report, I cleaned up Farid's improved patch a bit and pushed it.

The relevant commit is 1f68d8d8.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Supported Epson Perfection 1260 produces 2 background stripe colours

2017-08-30 Thread Olaf Meeuwissen
Hi Julian,

Julian H. Stacey writes:

> Hi sane-devel@lists.alioth.debian.org
>
> I have a USB scanner Epson Perfection 1260 (not a printer combo)
> half working, using FreeBSD current (3 week old src/ & current
> ports/packages) fresh installed sane back end, front end & xsane.
>
> Example scans here from xsane & scanimage & xscanimage:
>   http://www.berklix.com/~jhs/tmp/epson_perfection_1260/
> all with 2 background colours: yellow on left half of page, red on right.

I get a permission denied on the xsane.pnm but the other two PNM files
clearly show your problem.

> http://www.sane-project.org/cgi-bin/driver.pl?manu=Epson=Perfection+1260=usb=04b8=011d
> shows a choice of 2/3 drivers:J epson2 & sane-plustek [& epkowa?]

Using this scanner with the epkowa backends requires a non-free plugin
that may or, more likely, may not work on FreeBSD.  IIRC, the plugin is
built assuming GNU/Linux and links dynamically against glibc libraries.

The epson2 backend lists it as unsupported.

So, that leaves you with the plustek backend as your most likely
supporting backend.

# I've Cc:d it's maintainer just in case.

> I wasn't sure how to specify driver,
> Couldn't select driver from interactive xsane, nor from
> /usr/local/etc/sane.d/saned.conf (net inter host stuff), so I tried:
>
> xscanimage plustek:/dev/ugen1.5 # fails to open
> xscanimage plustek:/dev/usb/1.5.0 # fails to open
> setenv SANE_DEFAULT_DEVICE "plustek:/dev/ugen1.5" ; xsane # striped
> setenv SANE_DEFAULT_DEVICE "epson2:/dev/ugen1.5" ; xsane  # striped
> setenv SANE_DEFAULT_DEVICE "epkowa:/dev/ugen1.5" ; xsane  # striped
>
> I've done mv ~/.[a-zA-Z]* X/ ; cd X
> mv .[xX]* ~/  # for xauth
> # so its nothing in old inherited .sane/ or similar dor file
>
> Have I missed something ? Or is my scanner defective ?
>
> PS various notes from my
> http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/devd/berklix.conf
>   sane-find-scanner -q
> [...]
> found USB scanner (vendor=0x04b8 [EPSON], product=0x011d \
> [EPSON Scanner], chip=LM9832/3) at libusb:001:005
>   scanimage -L
> device `plustek:libusb:001:005' is a Epson Perfection 1260/Photo \
>flatbed scanner
>   I Added to /usr/local/etc/sane.d/plustek.conf:
> usb 0x04b8 0x011d
> device libusb:001:005

IIUC, you should not have to modify the plustek.conf file at all.  Using
something like you do above (note that it should be `[usb]`) will likely
stop working as soon as you re-plug or power-cycle the device.  On Linux
I'm sure it does, don't know for FreeBSD.

Maybe the log file from

  SANE_DEBUG_PLUSTEK=127 scanimage [your-options-here] > out.pnm 2> log

can shed some light on your problem?  Please use [your-options-here] to
set a small scan area so we don't get inundated with a multi-MB log file
here on the list ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Epson XP-342, XP-247 ?

2017-08-30 Thread Olaf Meeuwissen
Hi,

kamp0...@arcor.de writes:

> I miss the list of models / series of printers:
> Epson Expression Home XP-342 and  XP-247.
>
> http://www.sane-project.org/sane-mfgs.html

That only lists the devices supported by the last release.  For the
bleeding edge status see

  http://www.sane-project.org/lists/sane-mfgs-cvs.html

and for devices supported by third party backends see

  http://www.sane-project.org/lists/sane-backends-external.html

> Is there hope for future support for the devices?

The XP-247 was added recently as supported by the epson2 backend.  If
you have a USB product ID for the XP-342, that'd be helpful in divining
whether it is or can be supported by one of the EPSON related backends.
The output of

  lsusb | grep 04b8:

when your all-in-one is connected to a Linux system and powered on would
do just fine.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Alpine compiler warnings, GitLab.com mirror constipation and Whitespace XOR tabs

2017-08-12 Thread Olaf Meeuwissen
Hi all,

Since I will be off-line for a couple of days starting 2017-08-13, I
figured I'd sent a small update.

## Alpine Compiler Warnings

These are now at an all-time low.  The ones that remain I have no intent
of fixing because they our not within the scope of sane-backend to fix.
One series of warnings is due to an inconsistency in the musl library's
ioctl[1] and the other is equally due to that library insisting that the
avahi header files include  rather than [2].

 [1] https://bugs.alpinelinux.org/issues/7580
 [2] https://bugs.alpinelinux.org/issues/7581

I would have included a link to an appropriate build log of our GitLab
CI builds if it weren't for some serious ...

## GitLab.com Mirror Constipation

Since the beginning of July, the sane-project git repository mirrors[3]
I've set have been lagging and since 2017-07-25 have stopped altogether
:-(  That means the repositories there are behind, but more importantly
it also means that new commits no longer trigger CI builds.  Just when I
had set up building of release-style snapshot source tarballs :-((

 [3] https://gitlab.com/sane-project

The GitLab.com folks have been informed[4] and are working on a general
solution[5] (it affects some 24000 mirrored projects!) but in the mean
time we're without CI builds :-(((

 [4] https://gitlab.com/gitlab-com/support-forum/issues/2206
 [5] https://gitlab.com/gitlab-org/gitlab-ee/issues/3021

## Whitespace XOR Tabs

After arguing heatedly(?) in favour of cleaning up, I haven't really
done much in this area yet.  I do plan to though, so it's not off the
plate.  It's just not all that pressing for me right now having found
some other, not directly SANE related, stuff to play with.  Of course,
there are also still a few tracker[6] items and mailing list threads
that keep me (pre-)occupied ;-)

Actually, this stuff that I'm playing with started out of a desire to
*maybe* help the Devuan[7] folks maintaining systemd-free SANE binary
packages.

 [6] https://alioth.debian.org/tracker/?group_id=30186
 [7] https://devuan.org/

For those that don't know what to do with all the bucket loads of free
time of their summer holidays, there is still a pile of error warnings
for the Fedora builds that could use your attention.
Feel free to pick up my slack!

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] sane-backend 1.0.27 USB broken on Mac with Homebrew

2017-08-12 Thread Olaf Meeuwissen
Hi Thomas,

schmo-fu writes:

> Okay, here i go again ...
>
> i can confirm, that it is not a permission problem. It's just that there
> are no files, where they should be.
>
> The scanner is recognized by sane-find-scanner now. But scanimage -L
> doesn't find it, because the sane-backends .conf files are supposed to
> be at:
> /usr/local/Cellar/sane-backends/1.0.27_1/etc/sane.d/
> but there is no etc/ (and there also is no doc/; both are present under
> 1.0.25_1; (»officially« there should also be a tools/, but this isn't
> present neither in 25 nor in 27).
>
> Looking at
> https://gist.github.com/anonymous/5e324f6e1c7c8b9ea4172a72e0352255
> [[see note]]
> the make-log shows, that the backends are all build with
> "-DPATH_SANE_CONFIG_DIR=usr/local/Cellar/sane-backends/1.0.27_2/etc/sane.d"
> which seems alright.
>
> Maybe they get deleted later? I don't know enough about this process, to
> know where to look for answers.

[ ... looking through the log ... ]

They don't get deleted later.  The files to be installed don't get
created to begin with.  This is arguably a bug in the sane-backends
build system but you can easily work around it by running a `make`
before doing a `make install`.

It looks like the homebrew stuff assumes that `make install` will be
smart enough to also trigger builds for everything that needs to be
installed.  A bit overly optimistic, if you ask me ;-)

Below is the Makefile.am snippet that installs the configuration files.
The first line after the @list, checks for a readable configuration but
because all these files are generated they don't exist unless you run a
`make install` first.

  install-becfg:
  @# Libtool has a bug where it will sometimes symlink the last
  @# installed library in $(sanelibdir) to $(sanelibdir)/libsane.*.
  @# Having two libsane's can cause issues so get rid of it.
  -rm -f $(DESTDIR)$(sanelibdir)/libsane.*
  test -z "$(configdir)" || $(MKDIR_P) "$(DESTDIR)$(configdir)"
  test -z "$(configdir)/dll.d" || $(MKDIR_P) 
"$(DESTDIR)$(configdir)/dll.d"
  @list="$(BACKEND_CONFS_ENABLED) saned.conf dll.conf"; for cfg in 
$$list; do \
if test ! -r $${cfg}; then continue; fi; \
if test -f $(DESTDIR)$(configdir)/$${cfg}; then \
echo NOT overwriting $${cfg} in $(configdir)...; \
else \
echo installing $${cfg} in $(configdir)/$${cfg}...; \
$(INSTALL_DATA) $${cfg} $(DESTDIR)$(configdir)/$${cfg} \
    || exit 1; \
fi; \
done

I pushed a fix for this in 519ff57.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [PATCH] canon_dr: Add support for batch count

2017-08-11 Thread Olaf Meeuwissen
Hi Vadim,

Thanks for the patch.

@Allan> Since you're listed as the canon_dr backend's author, can you
take a look at this?

Vadim V. Vlasov writes:

> The patch adds support for batch count by introducing "--batchMode=XX"
> parameter. This works at least with Canon DR-G1100 but may also
> work with other scanners. At least it should not break current
> behaviour (as long as you do not use "--batchMode=XX").
> Note, what you call "SSM2_BUFF_sync" is, probably, page count
> rather than "sync (unbuffered) mode".
>
> diff -rup a/backend/canon_dr.c b/backend/canon_dr.c
> --- a/backend/canon_dr.c2017-08-09 18:50:33.725500231 +0300
> +++ b/backend/canon_dr.c2017-08-09 19:16:42.073500044 +0300
> @@ -830,6 +830,7 @@ attach_one (const char *device_name, int
> s->padded_read = global_padded_read;
> s->extra_status = global_extra_status;
> s->duplex_offset = global_duplex_offset;
> +  s->batchmode = 1;
>
> /* copy the device name */
> strcpy (s->device_name, device_name);
> @@ -2540,6 +2541,18 @@ sane_get_option_descriptor (SANE_Handle
>opt->cap = SANE_CAP_INACTIVE;
> }
>
> +  /*batch count*/
> +  if(option==OPT_BATCHMODE){
> +opt->name = "batchMode";
> +opt->title = "Batch count";
> +opt->desc = "Request scanner to batch-scan N pages";
> +opt->type = SANE_TYPE_INT;
> +if (s->has_buffer)
> + opt->cap = SANE_CAP_SOFT_SELECT | SANE_CAP_SOFT_DETECT |
> SANE_CAP_ADVANCED;
> +else
> + opt->cap = SANE_CAP_INACTIVE;
> +  }
> +
> if(option==OPT_SIDE){
>   opt->name = "side";
>   opt->title = "Duplex side";
> @@ -2914,6 +2927,10 @@ sane_control_option (SANE_Handle handle,
> *val_p = s->buffermode;
> return SANE_STATUS_GOOD;
>
> +case OPT_BATCHMODE:
> +  *val_p = s->batchmode;
> +  return SANE_STATUS_GOOD;
> +
>   case OPT_SIDE:
> *val_p = s->side;
> return SANE_STATUS_GOOD;
> @@ -3235,6 +3252,13 @@ sane_control_option (SANE_Handle handle,
>
>   case OPT_BUFFERMODE:
> s->buffermode = val_c;
> +  s->batchmode = !s->buffermode;
> +  return SANE_STATUS_GOOD;
> +
> +case OPT_BATCHMODE:
> +  s->batchmode = val_c;
> +  if (val_c != 1)
> +s->buffermode = 1;
> return SANE_STATUS_GOOD;
>
> }
> @@ -3313,7 +3337,7 @@ ssm_buffer (struct scanner *s)
>   memset(out,0,outLen);
>   set_SSM2_BUFF_unk(out, !s->buffermode);
>   set_SSM2_BUFF_unk2(out, 0x40);
> -set_SSM2_BUFF_sync(out, !s->buffermode);
> +set_SSM2_BUFF_sync(out, s->batchmode);
>
>   ret = do_cmd (
>   s, 1, 0,
> diff -rup a/backend/canon_dr.h b/backend/canon_dr.h
> --- a/backend/canon_dr.h2017-08-09 18:50:33.725500231 +0300
> +++ b/backend/canon_dr.h2017-08-09 18:51:07.021500227 +0300
> @@ -48,6 +48,7 @@ enum scanner_Option
> OPT_DROPOUT_COLOR_F,
> OPT_DROPOUT_COLOR_B,
> OPT_BUFFERMODE,
> +  OPT_BATCHMODE,
> OPT_SIDE,
>
> /*sensor group*/
> @@ -280,6 +281,7 @@ struct scanner
> int df_thickness;
> int dropout_color[2];
> int buffermode;
> +  int batchmode;
> int rollerdeskew;
> int swdeskew;
> int swdespeck;

--
Sent with my mu4e

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Need Help getting Canon ImageClass MF244dw working

2017-08-11 Thread Olaf Meeuwissen

Dave Platt writes:

>> Dave,
>>
>> Thank you very much, it did work, I used this.
>
> You're quite welcome!
>
>> I did notice that I do not have the same tweaks that Rolf and I had worked
>> on on his ppa. I am guessing that his ppa gets updated more than the
>> regular sane backend.
>
> He may be building from a custom tree, or one which is based on the
> current top-of-branch development code at the SANE repository.

Rolf's PPA builds from the nightly `git archive` tarball but does apply
some Ubuntu inspired patches for better distro integration (as do *any*
of the official packages of any Linux distribution).

> There have been a number of changes committed to the repo since
> 1.0.27 was released, I believe, and you would not have found any of
> those in the 1.0.27 tarball you downloaded.
>
>> One last question. Is the folder that gets extracted for building
>> (sane-backends-1.0.27)
>> tied to anything, or can it be removed?
>
> You should be able to remove it.  Once the files are installed in
> /usr/local/ there won't be any back-links to the source or build
> directories.

If you want to do a `make uninstall` later, when the official packages
have fixed the problem for example, you might want to keep it around
though.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Canon PIXMA MX925 - scan process now broken (does not end)

2017-08-11 Thread Olaf Meeuwissen
Hi Kay,

Kay Drangmeister writes:

> Hi,
>
> I am using the sane libs (Ubuntu 16.04) with a Canon Pixma MX925
> successfully for years now. Since some time (days, maybe weeks), the
> scan process does not terminate well.

There were two recent threads about similar issues that may be of
interest

 https://lists.alioth.debian.org/pipermail/sane-devel/2017-July/035481.html
 https://lists.alioth.debian.org/pipermail/sane-devel/2017-July/035520.html

Note, both threads continue on

 https://lists.alioth.debian.org/pipermail/sane-devel/2017-August/thread.html

You could try reverting to 1.0.25+git20150528

@Rolf> I hope these recent problem don't have anything to do with my
   sanei threading changes.

> [...]

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Restore support WorkCentre 3510 (may be 3520) in sane-backend-1.0.27

2017-08-11 Thread Olaf Meeuwissen
Hi Youry,

Sorry for not following up on your related comment on GitLab.com[1]
earlier.

 [1]: 
https://gitlab.com/sane-project/backends/commit/c9027378a12a6f67b22ee5fe203df1739486e3ad#note_37105915

Youry Metlitsky writes:

> On WorkCentre 3515 dev->compressionTypes is 0x51 and (dev->compressionTypes & 
> (1 << 6)) is true.
> On WorkCentre 3510 dev->compressionTypes is 0x41, but this device don't 
> support jpeg - this is error!

Is the commit you commented on, which only conditionalizes compilation
of the JPEG specific bits in the code, the cause of breakage or is the
problem with the dev->compressionTypes checking?

That is do things work when you build from the commit immediately before
c9027378 or not?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Need Help getting Canon ImageClass MF244dw working

2017-08-08 Thread Olaf Meeuwissen
Hi Curtis,

Curtis Graham writes:

> I still can't seem to get my scanner to work with debian 1.0.25-4.1. I'm
> guessing I need to get up to 1.0.27. My Multi Scanner is a Canon imageclass
> MF244dw. Here is the output:
>
> sudo sane-find-scanner
> [...]
> found USB scanner (vendor=0x04a9 [Language Error], product=0x27d2 [Language 
> Error]) at libusb:007:004

> I think it is
> usb 0x04a9 0x27d2

You think correctly.  This device was added on 2017-04-26, so, yes,
you'll need 1.0.27.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Canon LiDE 210

2017-08-03 Thread Olaf Meeuwissen
Hi Jörg,

Jörg Frings-Fürst writes:

> Hello,
>
> I forward this bug from Debian[1]. Please can someone check the
> included patch?

> diff --git a/backend/genesys.c b/backend/genesys.c
> index 984cead..eb8695a 100644
> --- a/backend/genesys.c
> +++ b/backend/genesys.c
> @@ -210,6 +210,8 @@ sanei_genesys_init_structs (Genesys_Device * dev)
> dev->model->motor_type);
> }
>
> +dev->usb_mode = 0;
> +
> /* set up initial line distance shift */
> dev->ld_shift_r = dev->model->ld_shift_r;
> dev->ld_shift_g = dev->model->ld_shift_g;

Patch looks simple enough, but I think a better place to set the initial
value of usb_mode is where dev is created, in attach() itself.

I'll attach my suggested patch to the Debian bug report[1] and follow up
there.

 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869673

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Issue with libsane 1.0.27+git20170719-xenial0 and Canon PIXMA MX495

2017-08-02 Thread Olaf Meeuwissen
Hi Jean,

Since I got mentioned by name ;-), you may want to look into using git's
bisect subcommand.  If that sounds/looks to complicated, you can do it
by hand as well.  First find the sha1-id for the version that works for
you.  Then using that sha1-id, create a list of the ones you might need
to check with

  git log --oneline ..HEAD -- backend/pixma*

Then check out the sha1-id in the middle, check whether that works.  If
it does, you can drop the bottom half of you list.  If it doesn't, you
can drop the top half.  Repeat this until you find the first sha1-id for
which things no longer work for you after the one for which things still
work.

I just ran the above command for the sha1-id corresponding to our 1.0.25
release and there are only ten changes to the pixma code.  So at worst,
you need to try four times.  It's a bit faster than doing them one at a
time ;-)

# Apologies if you already know what bisecting is.

Rolf Bensch writes:

> Hi Jean,
>
> If you like, you can install SANE from the git repository as described
> in INSTALL.linux (http://sane-project.org/docs.html) to find the problem
> in the source code.
>
> Most interesting are the commits from the master branch containing
> changes for files starting with pixma after 27.05.2017. Usually these
> commits come from Olaf Meeuwissen or from me. Please checkout these
> commits, compile and test them. Easy to use git frontends are git-gui,
> gitk or gitg. But you must checkout a commit with its sha1-id from the
> command line (the 1st 6 to 7 characters of the sha1-id are enough to
> identify the commit), e.g.:
>
> $ git checkout  c2594e
> Note: checking out 'c2594e'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
>   git checkout -b 
>
> HEAD ist jetzt bei c2594e9... Revert "pixma_imageclass.c: MF240 Series
> supports only 300dpi for adf scans"
>
> Please report the branch which 1st produces the problems you've reported
> before.
>
> Otherwise we must wait some weeks finding the problem commit.
>
> Hope this helps.
>
> Cheers,
> Rolf
>
> Am 25.07.2017 um 23:03 schrieb Jean Cérien:
>>
>> Hi Rolf,
>>
>> First, thank you for looking into this.
>> Second, there is no rush, as I have a workaround reverting to 1.0.25,
>>
>> I've tried with sane-release ppa,
>> scanimage (sane-backends) 1.0.27git; backend version 1.0.27
>> and it works fine
>>
>> same with sane-test, which is ok,
>>
>> I've reverted to sane-git, and it fails again.
>>
>> Let me know if you need more info,
>>
>> J.
>>
>> On Tue, Jul 25, 2017 at 3:59 AM, Rolf Bensch <r...@fam-bensch.de
>> <mailto:r...@fam-bensch.de>> wrote:
>>
>> Hi Jean,
>>
>> Please try my other ppa's (SANE Release and SANE Test) with older
>> versions of SANE: https://launchpad.net/~rolfbensch
>> <https://launchpad.net/%7Erolfbensch> and report the
>> results. Then I'll have an idea where to search for the issue you
>> reported.
>>
>> Please be patient. I'm on the move until end of August and I have less
>> time to work on SANE.
>>
>> Hope this helps.
>>
>> Cheers,
>> Rolf
>>
>> Am 19.07.2017 um 23:22 schrieb Jean Cérien:
>> >
>> > Hello
>> > I have a multifunction canon pixma mx 495. Up
>> > to 1.0.25+git20150528-1ubuntu2, I only had one small issue, the ADF
>> > wasnt working, but flatbed was ok.
>> >
>> > Since 1.0.27+git20170719-xenial0, in flatbed mode, I can only scan on
>> > page and then I get an error:
>> > scanimage: sane_read: Error during device I/O
>> >
>> > after scaning one page, trying to scan a second.
>> >
>> > Reverting to 1.0.25 restore the previous way of working and allows me
>> > to scan multiple pages via flatbed.
>> >
>> > scanimage -L gives:
>> > device `pixma:04A91787' is a CANON Canon PIXMA MX490 Series
>> > multi-function peripheral
>> >
>> > I've tried 1.0.27 with  /etc/sane.d/pixma.conf from 1.0.25, but
>> > unfortunately, that does not work.
>> >
>> > As an FYI, the ADF reports 'Operation was cancelled' in 1.0.25 and .27
>> >
>>   

Re: [sane-devel] Running sane din docker

2017-08-01 Thread Olaf Meeuwissen
Hi Jan,

Jan De Luyck writes:

> On Sun, 30 Jul 2017, at 06:31, Olaf Meeuwissen wrote:
>> Hi Jan,
>>
>> Jan De Luyck writes:
>>
>> [...]
>>
>> Can I have a look at your Dockerfile?  What docker command-line
>> invocation (or what docker-compose.yml) do you use?
>
> Sure. I've got everything up on https://github.com/jdeluyck/docker-saned

Thanks.  I had a quick look and didn't notice much out of the ordinary
(although I must admit I've never used runit).  One thing looked a bit
weird though: the need for the device to have group ID 'lp' (7).  IIRC,
on Debian they use a dynamically added saned user/group.  This typically
has an numeric ID >100.

But this user/group stuff shouldn't really matter for as far as I can
see, inside the container everything is run as root anyway (unless in
the very unlikely case that saned is setuid).

Your README.md also mentions you derived your setup from another one,
sesceu/docker-saned.  Have you checked if that works as expected?  I
noticed it passes a few other environment variables to the container.

>> Can you scan via the USB interface from within the container as well as
>> from outside of the container?  If that works, the problem is with the
>> networking part.
>>
>> Can you scan via saned from *within* the container?  Obviously, from
>> outside the container doesn't work otherwise you wouldn't have asked
>> here ;-)
>
> I've tested with scanimage:
>
> # scanimage -T
> scanimage: scanning image of size 638x877 pixels at 24 bits/pixel
> scanimage: acquiring RGB frame, 8 bits/sample
> scanimage: reading one scanline, 1914 bytes...  PASS
> scanimage: reading one byte...  PASS
> scanimage: stepped read, 2 bytes... PASS
> [...]
>
> - which I would say looks good. This is running from inside the
> container.

Looks fine but is this via USB or via saned for localhost?  That is,
what is the default device inside the container?  A simple

  scanimage -L

should tell you that.

>> >> > By sharing the /dev/bus/usb filesystem to the container, and mapping the
>> >> > necessary ports, I've gotten it to run (using runit to keep the services
>> >> > up and running). The scanner is detected, and I can start a remote scan
>> >> > - unfortunately it never completes, it fails shortly in the scan with a
>> >> > SIGPIPE error, and the client app (being scanimage or xsane) bombs out.
>> >> >
>> >> > The docker container is based on Debian Stable, I have dbus running
>> >> > inside it and ahavi is available.
>>
>> IIUC, you shouldn't need either.  Not for a USB scanner exposed via
>> saned.
>
> Oh. OK. That greatly reduces my dependencies.

Yup!  Smaller container, yeah!

>> >> > Running scanimage -T returns:
>> >> > $ scanimage -T
>> >> > scanimage: scanning image of size 638x877 pixels at 24 bits/pixel
>> >> > scanimage: acquiring RGB frame, 8 bits/sample
>> >> > scanimage: reading one scanline, 1914 bytes...  FAIL No data
>>
>> No data?  Right from the start ...
>>
>> >> > [...]
>> >> > scanimage: stepped read, 3 bytes... FAIL No data
>> >> > scanimage: received signal 13
>> >> > scanimage: trying to stop scanner
>> >> > Segmentation fault
>> >> >
>> >> > The last messages I get from saned -d128 are:
>> >> >
>> >> > [saned] do_scan: trying to write 8192 bytes to client
>> >> > [saned] quit: received signal 13
>>
>> Given that you get No data from the start, there may be something more
>> interesting earlier in the log.
>
> This is the full dump:
>
> # saned -d 128
> [saned] main: starting debug mode (level 128)
> [saned] read_config: searching for config file
> [saned] read_config: data port range: 1 - 10001
> [saned] read_config: done reading config
> [saned] saned (AF-indep+IPv6) from sane-backends 1.0.25 starting up
> [saned] do_bindings: trying to get port for service "sane-port" (getaddrinfo)
> [saned] do_bindings: [1] socket () using IPv6
> [saned] do_bindings: [1] setsockopt ()
> [saned] do_bindings: [1] bind () to port 6566
> [saned] do_bindings: [1] listen ()
> [saned] do_bindings: [0] socket () using IPv4
> [saned] do_bindings: [0] setsockopt ()
> [saned] do_bindings: [0] bind () to port 6566
> [saned] do_bindings: [0] bind failed: Address already in use

Hmm, probably not really an issue given log messages further down but
you might want to disable IPv6.

> [saned] run_standalone: spawning Avahi process
> [saned] run_standalone: waiting for control conn

Re: [sane-devel] Running sane din docker

2017-07-29 Thread Olaf Meeuwissen
Hi Jan,

Jan De Luyck writes:

> Ah. I'm running saned in a container, which runs on the host which has
> the usb scanner plugged in. I want to share that scanner over the
> network to other machines.

# For folks more familiar with VMs, it's like making the USB devices
# from the host OS visible to the guest OS and then use saned from the
# guest OS to expose a host OS connected USB scanner.

Can I have a look at your Dockerfile?  What docker command-line
invocation (or what docker-compose.yml) do you use?

Can you scan via the USB interface from within the container as well as
from outside of the container?  If that works, the problem is with the
networking part.

Can you scan via saned from *within* the container?  Obviously, from
outside the container doesn't work otherwise you wouldn't have asked
here ;-)

> The scanner is a HP PSC 1200, supported through hpaio (and works great).
>
> Hpaio backend is version 3.16.11.
> Sane is version 1.0.25
>> >
>> > I'm currently trying to get Sane to run inside a docker container.
>> > Reasons being that I can't modify the OS of the underlying machine, but
>> > I can play with docker containers.
>> >
>> > By sharing the /dev/bus/usb filesystem to the container, and mapping the
>> > necessary ports, I've gotten it to run (using runit to keep the services
>> > up and running). The scanner is detected, and I can start a remote scan
>> > - unfortunately it never completes, it fails shortly in the scan with a
>> > SIGPIPE error, and the client app (being scanimage or xsane) bombs out.
>> >
>> > The docker container is based on Debian Stable, I have dbus running
>> > inside it and ahavi is available.

IIUC, you shouldn't need either.  Not for a USB scanner exposed via
saned.

>> > Running scanimage -T returns:
>> > $ scanimage -T
>> > scanimage: scanning image of size 638x877 pixels at 24 bits/pixel
>> > scanimage: acquiring RGB frame, 8 bits/sample
>> > scanimage: reading one scanline, 1914 bytes...  FAIL No data

No data?  Right from the start ...

>> > [...]
>> > scanimage: stepped read, 3 bytes... FAIL No data
>> > scanimage: received signal 13
>> > scanimage: trying to stop scanner
>> > Segmentation fault
>> >
>> > The last messages I get from saned -d128 are:
>> >
>> > [saned] do_scan: trying to write 8192 bytes to client
>> > [saned] quit: received signal 13

Given that you get No data from the start, there may be something more
interesting earlier in the log.

>> > Stracing saned gave me:
>> > 960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: trying to read 8188 bytes from scanner\n", 48)
>> > = 48
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: read 8188 bytes from scanner\n", 38) = 38
>> > 1960  select(135, [4], [134], NULL, {tv_sec=0, tv_usec=0}) = 1 (out
>> > [134], left {tv_sec=0, tv_usec=0})
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: trying to write 8192 bytes to client\n", 46) =
>> > 46
>> > 1960  write(2, "do_scan: trying to read 8188 bytes from scanner\n", 48)
>> > = 48
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: read 8188 bytes from scanner\n", 38) = 38
>> > 1960  select(135, [4], [134], NULL, {tv_sec=0, tv_usec=0}) = 1 (out
>> > [134], left {tv_sec=0, tv_usec=0})
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: trying to write 8192 bytes to client\n", 46) =
>> > 46
>> > 1960  select(135, [4], [134], NULL, {tv_sec=0, tv_usec=0}) = 1 (out
>> > [134], left {tv_sec=0, tv_usec=0})
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960  write(2, "do_scan: trying to write 8192 bytes to client\n", 46) =
>> > 46
>> > 1960  write(134,
>> > "\0\0\37\374\372\370\373\372\370\374\373\371\374\373\371\374\373\371\374\373\371\374\373\371\371\370\3
>> > 66\372\371\367\372\371\367\373\372\370\373\372\370\372\371\367\372\371\367\371\370\366\372\372\370\372\372\370\372\372\
>> > 370\372\372\370\372\372\370\372\372\370\372\372\370\372\372\370\372\372\370\372\372\370\372\372\370\372\372\370\372\372
>> > "..., 8192) = -1 EPIPE (Broken pipe)
>> > 1960  --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=1960,
>> > si_uid=0} ---
>> > 1960  write(2, "[saned] ", 8)   = 8
>> > 1960 

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

2017-07-29 Thread Olaf Meeuwissen
Hi Luiz,

Thanks for your patches.  I really appreciate that you also keep the
documentation in sync!

Luiz Angelo Daros de Luca writes:

> The two first patches are trivial bugfixes.

Indeed they are and I'll push them shortly.

> However, this one proposes a new organization on saned options, as
> shown at:
>
> https://alioth.debian.org/tracker/index.php?func=detail=315747_id=30186=410366

Doing the saned options the Unix way?  Great, "Do just one thing" but
let's also have a look at the "and do it well" part.  This is not to
imply that your patch is not doing things well, btw, just a little
reminder that that is also part of the Unix way.

> All flags now do one thing and normally have an opposite flag that can
> deactivate it.

I am not sure what you are trying to achieve with the opposite flags.
What use case do you have in mind for them?

I can think of:
 - negating an option set in a configuration file
 - negating an earlier option on the command-line
 - signalling a running saned to toggle its behaviour
but none look overly compelling to me.  I even think that the first and
last ones are not supported by saned anyway.

If there is no clear use case, perhaps saned should not provide them.
In that case, I'd remove:
 - -D and make running in the background the default because saned is
   normally meant to run as a daemon
 - -s and make logging to syslog the default because daemon processes
   shouldn't scribble on anyone's terminal unless asked to
 - -l and make running in stand-alone mode the default because that's
   what daemons ought to do anyway

# Hmm, looks like the manual page needs more changes to update the
# configuration sections for (x)inetd and systemd then.

> The flag -a was kept compatible but, flags -d and -s now have a
> different behavior.  -d only sets the debug level and -s only forces
> syslog. I guess this breakage does little harm as those flags are only
> used for dev (as they quits saned after first client).

I had some doubts about -s being "only used for dev" but upon reading
the manual page and the code, you're right.  The -s option behaves as
the -d option.  Their only difference is in where the output goes.

With that cleared up, I agree it is safe to say that no-one will be
using these options when running their saned service as a background
process.  If running saned on demand, e.g. via (x)inetd, you could use
them but I would frown upon doing so for "production" use.

# BTW, the saned manual page says you cannot give options when running
# from (x)inetd but that is incorrect or at least outdated.

Systemd?  No clue how that works and very little intent to find out.
If anyone in the know wants to chime in re running saned with these
options they're welcome.

# FWIW, I switched to Devuan in December 2016 after using Debian for
# about 19 years to regain init freedom ;-)  Alternative init system
# approaches are welcome!

Procd?  I'd think you know ;-)

> If not, I can introduce new flags for those actions and revert -d/-s
> previous behavior.

I don't think there is any need to keep these options backwardly
compatible but it might be in order for saned to warn people that these
options have changed since 1.0.27, show the new invocation for the old
behaviour and a pointer to the manual page for details on the changed
options.

Something similar could be done for -a, warning users that this option
is deprecated and will be removed in the future (without any explicit
mention of when exactly).

You mention something about creating a PID file for the -u option.  That
made me think a -p option to specify where you want that file might be a
nice addition.  The current location, /var/run/saned.pid, is hard-coded.
It's not a bad location but one may want to change it.

Oh, about the code changes, there are a few places in the manual page
I'd change to improve the English but I can do that for you.  There is
one mistake though, you document a -B option (as if it were -D).

I'd drop the SANED_EXEC_* defines you add because they're not used and
apart from a minor English nitpick in the option descriptions, the
saned.c changes look fine.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] sane-backend 1.0.27 USB broken on Mac with Homebrew

2017-07-27 Thread Olaf Meeuwissen
Hi Thomas,

schmo-fu writes:

> Hi Olaf,
>
> sorry for the long wait, but now i'm back at the machine with the scanner.

No problem.  I've been swamped with Real Work the last three days
anyways ;-)

> Am 24.07.17 um 14:09 schrieb Olaf Meeuwissen:
>>
>> Try --with-usb=yes.  That really *should* bomb.
>>
> I put '--with-usb=yes' into the formula, but that didn't stop the
> compilation. You find the log here:
> https://gist.github.com/anonymous/5ea27bd1a4c1f0baffebffe7aec0caf3

That has:

  checking for USB... no
  checking for USB... no
  checking usb.h usability... yes
  checking usb.h presence... yes
  checking for usb.h... yes
  checking for usb_interrupt_read in -lusb... yes
  checking lusb0_usb.h usability... no
  checking lusb0_usb.h presence... no
  checking for lusb0_usb.h... no

So it *does* find some usable USB support and hence won't bomb.  From
the comment in configure.ac, that first `yes` hints at a 10+ years old
libusb (or Windows version).  I *think* it found something from that
libusb-compat package.

>> From the config.log I see that there's probably a libusb-compat
>> installed somewhere.  I'd suggest to get rid of that (as far as SANE is
>> concerned) because libusb-1.x should be okay.
>>
>> From that same file, I also gather there should be libusb*.pc files (or
>> similar) in
>>
>>   /usr/local/opt/libusb/lib/pkgconfig
>>
>> and
>>
>>   /usr/local/opt/libusb-compat/lib/pkgconfig
>>
>> Curious about what those have to say about libusb because, AFAIU, the
>> configure script should be looking at those before it decides there's
>> no USB support.
>
> i copied the contents of the two pc-files to this pad:
> https://codicill.us/pad/p/gist

I have zero idea about homebrew works but the paths of the *.pc files
themselves and the prefixes they list look highly suspicious.  That is,
the files live below /usr/local/opt/ but their prefix point below
/usr/local/Cellar/.  There may be some symlinks to make this all work,
magically, but to me it looks fishy.

If those *.pc files are found when running ./configure, that excerpt of
the ./configure output quoted above should reduce to just

  checking for USB... yes

and USB should work.  The ./configure script makes sure that pkg-config
(which deals with these *.pc files) is set up correctly for your build
environment before it tries to find the *.pc files.  From the initial
./configure output excerpt it very much looks like they are *not* found
at all.

> Then i force uninstalled libusb-compat.
> That stopped sane-find-scanner from working (See error-message at the
> end of the pad). So this looks more like sane-find-scanner is actually
> build with usb-support?

Yup.  And if I am not mistaken, that came from libusb-compat which you
subsequently nuked.  The error message is interesting though (in light
of those *.pc files you pasted).

  dyld: Library not loaded: /usr/local/opt/libusb-compat/lib/libusb-0.1.4.dylib

The libusb.pc mentions a version of 0.1.5_1 (emulated_by=libusb-1.0 ??)
and libusb-1.0.pc mentions 1.0.21.

Hmm, libusb is 0.1.5?  Seriously?  The latest version is 0.1.12 and that
was released years ago.  How does that jive with a 0.1.4.dylib?

# I'm not expecting you to answer this.  I am just thinking "out loud".

> So i reinstalled (build-from-source) sane-backends (after deactivating
> the dependency for libusb-compat) and it bombed (of course).
> Logs from that: https://gist.github.com/dfbe878620c1ae20f1bcbda44dbe37e3
>
> So i reinstalled libusb-compat and now i'm back to where i started.

Based on the above, I would drop the 10+ year old duct tape that goes by
the name of libusb-compat and look at fixing whatever thwarts pkg-config
finding one of those *.pc files, preferably libusb-1.0.pc.

Hmm, ...

Having another round through the info in the various links you and Yurii
provided I noticed

  checking for pkg-config... no

Is homebrew using pkgconfig instead?  If so, I'd suggest adding
something like

  system "ln", "-s", "pkg-config", "/usr/bin/pkgconfig"

*before* running configure to sane-backends.rb.  Adjust /usr/bin as
necessary.  While at it, also drop the

  depends_on "libusb-compat"

or replace it with something like

  depends_on "libusb-1.0"

at least, do yourself a favour and build against libusb-1.0.

So far for tonight's debugging session ;-)  If you still have trouble,
don't hesitate to "bother" me (and the list ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] sane-backend 1.0.27 USB broken on Mac with Homebrew

2017-07-27 Thread Olaf Meeuwissen
Hi Yurii,

Yurii Kolesnykov writes:

> Hi Thomas, Olaf!
>
>> It'd make more sense if you can tell me where these homebrew-commits can
>> be found.
>> # I've been on GNU+Linux and just about nothing else for two decades ;-)
>>
> Here is the brew formulae file. You can see history of commits.
> https://github.com/Homebrew/homebrew-core/blob/master/Formula/sane-backends.rb

Thanks!  I'll follow up with more info in Thomas' follow up.
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Getting Alpine Linux sane-backends builds compiler warning free

2017-07-27 Thread Olaf Meeuwissen
Hi Valery,

Valery Kartel writes:

> Hi, Olaf
>
> I pushed a PR for libieee1284, so waiting for accept it.
> https://github.com/alpinelinux/aports/pull/1982

I noticed that was accepted.

> And now I playing with sane-backends building with libpng, libieee1284 and
> linux-headers as you mentioned.

As for the CI builds, I think I'll stick to using linux-headers only so
I have a bit more diversity in the way sane-backends gets build.

> There are some new backends enabled now:
> canon_pp
> hpsj5s
> mustek_pp
> v4l
>
>> I also see that you list the license as GPL in the APKBUILD file.
> Yes I set GPL as a license for this package and all its subpackages. But I
> saw its not so simple with some backends licensing.

Indeed.

> Can you provide me some idea or some list how to describe licensing right
> way for not-only-gpl parts?

For starters, I would use the LICENSE file as a guide.

So the frontends are GPL-2.0+ and the API spec is public domain.  As for
the backends, *most* are GPL-2.0+ with exception.  The ones that are not
are, IIRC, GPL-2.0+.  BTW, I'm not sure whether the exception is exactly
the same for all backends.

A long while back I actually analysed the situation (at the office) but
I don't have access to the results anymore (assuming they still exist).
What might be one way of recourse is the debian/copyright file (from the
Debian/Devuan/Ubuntu packages).  These contain a machine processable
"bill of rights" and are normally quite carefully vetted (at least the
first time around).

It's a bit old (1.0.24!), but I've attached the one that came with my
Devuan libsane package for reference.

# Maybe I should insert SPDX[1] compliant license tags in all files and
# add a little script that can extract them ...
#
# [1]: https://spdx.org/

> Thanks for advise

You're welcome.

>> My builds have so far not included the kernel-headers package in the
>> list of packages to be installed but I'm leaning towards adding it.  It
>> would solve a major compiler warning headache for me ;-)
>>
>> If Alpine Linux' default build environment always includes it, I feel
>> more justified to "take the easy way out".

FTR, I did take the easy way out (but may want to look at disabling the
umax_pp backend if it's just going to no-op).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: sane-backends
Upstream-Contact: 
Source: ftp://ftp.sane-project.org/pub/sane/

Files: *
Copyright: 1997-2014 Andreas Beck 
   1997-2014 David Mosberger
License: GPL-2+ with sane exception

Files: debian/*
Copyright: 1997-2002 Kevin Dalley <kev...@rahul.net>
   2002-2011 Julien BLACHE <jbla...@debian.org>
   2002-2006 Aurélien Jarno <aure...@debian.org>
   2013  Mark Buda <her...@acm.org>
   2014-2016 Jörg Frings-Fürst <deb...@jff-webhosting.net>
License: GPL-2+ with sane exception

Files: backend/abaton.*
Copyright: 1998-1998 David Huggins-Daines
License: GPL-2+ with sane exception

Files: backend/agfafocus.*
Copyright: 1997  Ingo Schneider
   1998  Karl Anders Øygard
License: GPL-2+

Files: backend/apple.*
Copyright: 1998  Milon Firikis
License: GPL-2+ with sane exception

Files: backend/artec.*
   backend/qcam.*
   backend/dll.*
   include/sane/sanei_scsi.h
   include/sane/sanei_wire.h
   sanei/sanei_DomainOS.c
   sanei/sanei_codec_ascii.c
   sanei/sanei_codec_bin.c
   sanei/sanei_config2.c
   sanei/sanei_net.c
   sanei/sanei_wire.c
Copyright: 1996-1997 David Mosberger-Tang
License: GPL-2+ with sane exception

Files: backend/artec_eplus48u.*
Copyright: 2002  Michael Herder <craps...@gmx.net>
License: GPL-2+ with sane exception

Files: backend/as6e.*
Copyright: 2000  Eugene S. Weiss
License: GPL-2+ with sane exception

Files: backend/avision.*
Copyright: 1999-2007 Rene Rebe <r...@exactcode.de>
   1999-2001 Meino Christian Cramer <mccra...@s.netic.de>
   2002  Jose Paulo Moitinho de Almeida <moiti...@civil.ist.utl.pt>
   2010-2011 Mike Kelly <m...@piratehaven.org>
License: GPL-2+ with sane exception

Files: backend/bh.*
Copyright: 1999-2000 Tom Martone
License: GPL-2+ with sane exception

Files: backend/canon-scsi.c
  backend/canon.*
Copyright: 1997  BYTEC GmbH Germany
License: GPL-2+ with sane exception

Files: backend/canon630u.c
Copyright: 2002  Nathan Rutman <nat...@gordian.com> 
   2001  Marcio Luis Teixeira
   1996-1997 Andreas Beck
  

[sane-devel] Getting Alpine Linux sane-backends builds compiler warning free

2017-07-22 Thread Olaf Meeuwissen
Hi Valery,

I'm one of the SANE developers and am trying to get rid of all compiler
warnings on a select subset of build environments.  Alpine Linux is one
of them and its parallel port IO support is giving me a bit of trouble.
Hope you can help me out a bit.

I don't see any libieee1284 packages for 3.6.  Is there any activity to
add libieee1284?  It would enable support for a few more backends.

A few backends also provide parallel port IO support if certain Linux
kernel headers are present.  Looking at the `makedepends` list in the
sane package's APKBUILD file, I don't see kernel-headers listed.  Can
I assume that the Alpine package build environment makes sure that is
present?  If not, you may want to add it.  It would make at least the
umax_pp backend do something more useful.  Without that package, it
compiles but essentially just no-ops just about all the I/O after
spitting out a warning, IIUC.

My builds have so far not included the kernel-headers package in the
list of packages to be installed but I'm leaning towards adding it.  It
would solve a major compiler warning headache for me ;-)

If Alpine Linux' default build environment always includes it, I feel
more justified to "take the easy way out".

You can find my build environment setup[1] as well as build logs[2] (the
middle stage, first on the drop-down list) over at GitLab.com.

 [1]: https://gitlab.com/sane-project/ci-envs/blob/master/alpine-3.6-musl.df
 [2]: https://gitlab.com/sane-project/backends/pipelines

Somewhat off-topic, but ...

I also see that you list the license as GPL in the APKBUILD file.  Is
that for that file only or does that apply to the binary packages?
If the latter, it's not correct and really should be fixed.

BTW, love the fact that you provide a package per backend!  Wishing
other distributions would do the same.

Thanks for any feedback in advance,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [#315765] lide220: bad motor noise if scanning app crashes

2017-07-21 Thread Olaf Meeuwissen
Hi list,

Farim and I have been going back and forth a bit on the above bug report
and now Farim has come up with a patch that makes the problem go away.
Upon glancing it over, things look okay but I'd like some other people
to review the patch before pushing it.

The problem, insofar I understand, it that cancellation is not triggered
when the data connection disappears during scans through saned.

You can find the bug report[1] on Alioth.

 [1]: 
https://alioth.debian.org/tracker/?func=detail=410366=315765_id=30186

Thanks in advance,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] leading whitespace: spaces XOR tabs

2017-07-21 Thread Olaf Meeuwissen
Hi,

Gerhard Jäger writes:

> Well - Olaf,
>
> seems nothing can stop you from doin' that ;)

Convincing counter-arguments can but I can be hard to convince ;-)

> I second Allan, so go on. If I ever will apply my changes, I think I can
> live with it.
>
> Cheers,
>   Gerhard
>
> On 20.07.2017 at 15:07 m. allan noah wrote:
>> Olaf, you make a pretty convincing case, especially as regards to your
>> wider than average exposure to the codebase. If you feel strongly
>> about this, and are willing to do the work (which I think will be
>> harder than you expect), then I will remove my objections.

Hard?  No.  A lot of work?  Sure.  More work than I thought it would be?
I've already realized that.  Am I deterred by that?  Not at all.

There were several hundred compiler warnings on Debian GNU/Linux 8.x in
the past.  They're gone now.  The new ones, some 50 or so?, that popped
up in 9.0 are a thing of the past now too.  Warnings on Alpine are down
too and I'm sensing they're being gone is within reach.  Fedora is on
the list next ;-)

Anyways, with all concerns of the two of you out of the way now, I'll
have a good look at it again and clean up things starting with the low
hanging fruit.  I'll also add policy checking at a warning level so we
can all see where we're at in the CI build logs.

As long as there are tools that can check this "boring" stuff for you,
it is relatively easy keep things in order.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] leading whitespace: spaces XOR tabs

2017-07-20 Thread Olaf Meeuwissen
Hi all,

Apologies for replying to my own, original post but I want to reply to
all initial follow-up in a single post.

First off, Gerhard, Allan, Johannes, many thanks for the feedback.

Your summarized comments with my replies first, followed by in-line
comments on my initial post.

 1. The whole code base?  Is that worth it?

In principle, yes, the whole code base unless backend maintainers
balk.  Whether it's worth it, I don't know.  I only know that at
least I will feel better (but that's not all important, of course).
As a self-appointed janitor I get to deal with a larger part of the
code base than the average backend maintainer.  Switching between
space/tab conventions on a per line basis and indenting and coding
styles between blocks (at best!) sometimes feels like a juggling
job.
# And my hand-eye coordination leaves to be desired ;-)

 2. How about unmaintained backends only?

That might be an option but please note that the maintained status
was decided based on "backend contributor mentioned in the AUTHORS
file with commit privileges" without regard for actual status.

@Gerhard> Are you still *maintaining* the plustek and plustek-pp
  backends?  If yes, how about you clean up ;-)?

 3. Wouldn't that break people's patches?

Get them upstreamed.  Seriously, what's keeping everyone's generally
usable private patches from getting included?
In case your patches don't make it in for some reason, have a good
look at the documentation for the --ignore-whitespace options.  Both
git am and git apply as well as the patch program support it.

 4. But that makes git blame harder to use!

git blame is only really useful if your UI let's you quickly jump to
the changeset in question and move to the one before it with ease.
If it doesn't, Johannes' git log --follow -p is magnitudes better.
# BTW, I use both approaches, judiciously.

 5. Whitespace issues haven't really bothered me.

That's you.  They do bother *me*.  That's why I brought this up in
the first place ;-)
Clean, consistently formatted code is a lot easier and inviting to
work with.  A SANE approach to leading whitespace at the file level
is a start.  Pun intended.
As you mentioned, such code may make it easier for folks to pick up
the maintenance of a backend.  If so, we're off for the better.
# As a "janitor", I'm just trying to fix "broken windows" and patch
# up "cracks in the walls" of the sane-backends apartment building.

 6. Spaces-only leads to more intelligible diffs.

ACK.  Less weird indenting when looking at the diff.

 7. Spaces everywhere please, I want to get rich quick ;-)

Let's combine that with a one-space indent style so we can inject a
pyramid scheme and get rich quicker yet :-P

And now for some observations pouring over my inital post and the
current state of white space use.

Olaf Meeuwissen writes:

> [... fixing "hair-raising" -Wmisleading-indentation issues ...]
>
> This whole exercise has made me look at the whole code base in a little
> more detail and, quite frankly, the use of leading whitespace is a total
> and utter mess.  Some places are better of than others but on the whole
> it's pretty pathetic.

OK, so that may have been a bit over the top, but, hey, I want to grab
everyone's attention.

> So here's a few "rules" I'd like to apply in order to address this.
> Each file
>
>  - uses either spaces or tabs for *all* of its leading whitespace
>This is *not* on a per line basis, this applies to the *whole* file.
>  - if using tabs, these tabs may be followed by up to 7 spaces
>This is to accommodate n-space indent policies (where n mod 8 != 0)
>and assumes eight spaces to the tab.
>  - if using tabs, uses eight spaces to the tab
>  - if to be used by `make`, an initial whitespace character shall be
>a tab, independent of whether its on a continuation line or not

Let's add ChangeLogs/ChangeLog-1.0.$n for n < 26 to the files that have
a leading tab.  Most of them are pretty close to that already.

I've written (and attached) a little script that analyses every file you
throw at it following something close to the above.  Please have a look
at the script to get an idea of what is does and what the output is all
about.

Suggested use:

  git ls-files | xargs -n 1 tabs-and-spaces.sh

> The "rules" above are inspired by a combination of consistency, ease of
> checking/fixing and giving developers some leeway in applying their own
> preferences to their code.

It turns out that the checking is the easy part.  The fixing can be a
pain in the behind and may require a fair bit of manual intervention :-(

> Whether to use spaces or tabs for each file will be decided on the basis
> of a count of tabs and spaces (and 

Re: [sane-devel] [janitorial] Error @ git push

2017-07-17 Thread Olaf Meeuwissen
Hi Rolf,

Thanks for reminding everyone of the issue[1], :-).  The short answer is
that there is nothing to worry really about.  Everything should be fine.
For the longer answer, see my comments below.

 [1]
 https://lists.alioth.debian.org/pipermail/sane-devel/2015-December/034213.html

Rolf Bensch writes:

> Hi Olaf,
>
> My last git push produced this output:
>
> Versende nach
> git+ssh://roben-gu...@git.debian.org/git/sane/sane-backends.git
> remote: Sending notification emails to:
> sane-com...@lists.alioth.debian.org
> remote: Aktualisiere d94c29a..3258b70
> remote: Fast-forward
> remote:  backend/hp3500.c| 2 ++
> remote:  backend/plustek-pp_scan.h   | 6 +-
> remote:  configure   | 2 +-
> remote:  configure.ac| 2 +-
> remote:  doc/descriptions/pixma.desc | 4 ++--
> remote:  include/sane/config.h.in| 3 ---

Now that's odd!  You seem to be sending two commits of mine with your
change to pixma.desc as well.

Maybe your local master was behind origin/master when you pushed?

Anyway, your change to pixma.desc triggered a rebuild of the supported
device lists on the website.  Due to my changes to configure{,.ac} that
rebuild decided it needs to reconfigure the checked out source tree (on
Alioth) and do so like

> remote:  6 files changed, 7 insertions(+), 12 deletions(-)
> remote: cd .. && make  am--refresh
> remote: make[1]: Entering directory
> `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git'
> remote: /bin/bash ./config.status --recheck

You can see it runs a ./config.status script (which remembers the
options used when ./configure was run) and tells it to --recheck.

> [...]

Near the very end, the ./config.status script updates itself with any
new findings (so you can do a ./config.status *without* --recheck'ing
real fast) and tries to set execute permissions on the script.  The
latter fails because the script is owned by kitno-guest and the update
is run by roben-guest.

# The code that does this is courtesy of autoconf so it is not trivial
# to fix this in a persistent way :-(

> remote: configure: creating ./config.status
> remote: chmod: changing permissions of `./config.status': Operation not 
> permitted
> remote: configure: error: write failure creating ./config.status

This is not a problem because the script already has the permissions it
is trying to set.

> I've never seen the checking stuff before.

The configure{,.ac} scripts don't change all that frequently ;-)

I see the checking quite a bit when fiddling with autofoo stuff.  As
long as it only complains about not being able to set permissions on
./config.status things should be fine.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] sanei_thread "fixes" and Fedora 26 CI builds

2017-07-15 Thread Olaf Meeuwissen
Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
>
> Am 15.07.2017 um 10:21 schrieb Olaf Meeuwissen:
>> @Rolf> Can you take a look at 73861ea, please?  It affects the pixma
>>backend.  I think it's fine but I'd like an extra pair of eyes
>>on that.
>>
>>
> Everthing looks fine. My scanner is still working. :-)

Thanks for the quick follow-up and good to know that I didn't make you
scanner go bonkers ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] sanei_thread "fixes" and Fedora 26 CI builds

2017-07-15 Thread Olaf Meeuwissen
Hi all,

I've put my leading whitespaces proposal on hold for a few days and
started fixing compiler warnings from the Alpine 3.6 musl builds.

Alpine uses the musl C library and that means stuff is sometimes a bit
different.  Which is a Good Thing!  Its pthread "idiosyncracies" led to
a pile of [-Wint-conversion] warnings that hilighted some preconceived
notions in the sanei_thread.c code and a large number of backends using
that.

The backends have been fixed up now and the sanei_thread.c code patched
up to a point where it should work with all integer type based pthread_t
implementations.  The configure script now checks for this and disables
pthread support if it doesn't find an integer pthread_t.

So for folks using musl, which uses a struct __pthread *, that means
your "multi-threading" support will fall back to multi-processing.
Patches to sanei_thread.c are welcome :-)

@Rolf> Can you take a look at 73861ea, please?  It affects the pixma
   backend.  I think it's fine but I'd like an extra pair of eyes
   on that.

On a different front, Fedora 26 was released[1] on 2017-07-11 so I've
added a CI builder for that as well.  The Fedora 25 build will stay
around for a bit longer yet, but probably not that long.

 [1]: https://fedoramagazine.org/fedora-26-is-here/

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] leading whitespace: spaces XOR tabs

2017-07-12 Thread Olaf Meeuwissen
Hi all,

I just committed the last compiler warning fixes and made the Debian 9
builds "AWARE".  Now any compiler warnings on all 4 Debian builds will
bomb the build in question and hence prevent the creation of a new
snapshot tarball.

I mentioned[1] that the plustek-pp backend's indenting defied me but
after some staring at the code I realized it was using a four spaces to
the tab convention.  Convincing my editor to do the same made it a lot
easier to understand the intended behaviour but fixing the "mess" was
still a very delicate affair.  I had to change the mixed use of spaces
and tabs used to indent to *exactly* match in order to silence compiler
warnings.

 [1] https://lists.alioth.debian.org/pipermail/sane-devel/2017-June/035445.html

This whole exercise has made me look at the whole code base in a little
more detail and, quite frankly, the use of leading whitespace is a total
and utter mess.  Some places are better of than others but on the whole
it's pretty pathetic.

# Just make your editor visually distinguish spaces and tabs and you'll
# see.  I used Emacs' whitespace-mode (in its default configuration) and
# it "lit up the place" in a variety of colours.

So here's a few "rules" I'd like to apply in order to address this.
Each file

 - uses either spaces or tabs for *all* of its leading whitespace
   This is *not* on a per line basis, this applies to the *whole* file.
 - if using tabs, these tabs may be followed by up to 7 spaces
   This is to accommodate n-space indent policies (where n mod 8 != 0)
   and assumes eight spaces to the tab.
 - if using tabs, uses eight spaces to the tab
 - if to be used by `make`, an initial whitespace character shall be
   a tab, independent of whether its on a continuation line or not

Note, this says absolutely nothing about whitespace use after the first
non-whitespace.  That can still be a mess.

The "rules" above are inspired by a combination of consistency, ease of
checking/fixing and giving developers some leeway in applying their own
preferences to their code.

Whether to use spaces or tabs for each file will be decided on the basis
of a count of tabs and spaces (and in case of doubt comparison with any
related files so as to keep some kind of consistency between them).  The
criterion will be a majority of one over the other (taking into account
the number of spaces to a tab).  So, with n spaces to the tab, the
larger value of n*number_of_leading_tabs and number_of_leading_spaces
will decide the leading whitespace policy for a file.

# Personally, I would much prefer to uses spaces everywhere the file
# format permits (with a minor execption for files used by make, see
# above) over the board.
# You may find the following blog post of interest ;-)
#
#  
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

If anyone objects, I'm open to suggestions, including "Why bother? Just
use spaces!" ;-)

If I hear nothing, the tools/style-check.sh script will be modified to
implement these rules and can then be use to check for any "violations"
and (recursively) fix them.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] CI now builds snapshots with "funny" versions

2017-07-06 Thread Olaf Meeuwissen
Hi All,

I found it most unfair that sane-frontends didn't get the same snapshot
tarball treatment as sane-backends does so I set up a simple CI job over
on GitLab.com.  All it does is roll a source tarball.  Nothing more.  It
doesn't even try to compile the sources.  But!  We now have a

  sane-frontends-1.0.14-31-gc1b7785-dirty.tar.gz

on http://sane-project.org/snapshots/

Now I'm wondering if I should drop the daily git archives ...
# ... and update the SANE - Download web page[1].
# [1]: http://sane-project.org/source.html

For those of you running cron jobs against those git archives, perhaps
now is your chance to speak your mind (or change your cron job ;-)

Olaf Meeuwissen writes:

> Hi Allan,
>
> About two weeks ago I wrote on the sane-devel mailing list:
>
>> Dear list,
>>
>> [ ... creating `git describe --dirty` versioned tarballs ...]
>>
>> So then, what does happen on Alioth when the daily snapshots are made?
>> These snapshots are, unsurprisingly, courtesy of a daily cron job.  It
>> runs something close to
>>
>>   git archive --format=tar master | gzip > sane-backends-$DATE.tar.gz
>>
>> I've tried to run `make dist` on Alioth.  No such luck.  [...]
>>
>> The fact you cannot run `make dist` on Alioth is probably why the daily
>> snapshots are just `git archive`s, but those archives are not made the
>> way as our release tarballs.  And that bugs me.  Maybe I should change
>> that cron job to pull the tarballs from GitLab.com ...
>
> Well, I did just that and ran it manually without any hitch.  There is
> now an extra snapshot[1] that is made the same way we roll our release
> tarballs.
>
>  [1] http://sane-project.org/snapshots/
>
> This snapshot corresponds to the most current git checkout that passed
> the CI build at GitLab.com.
>
> The updated make-git-snapshots.sh should (famous last words!) run
> without any trouble and produce no output.  If, however, you start
> receiving mail from your daily sane cronjob, just forward it to me
> and I'll fix it up.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Where is the define of SANE_I18N

2017-07-05 Thread Olaf Meeuwissen
Hi,

dan...@pek.destiny.com.cn writes:

> Hey guys,
>
> I have working on the source code of sane-backends, I found the macro
> SANE_I18N is used to sane’s localization. But I just found the follow
> lines of it’s define
>
> #ifndef SANE_I18N
> #define SANE_I18N(text) text
> #endif
>
> The above lines, dose nothing. So I wonder how SANE_I18N translate
> these backends?

The backends don't translate.  It's the responsibility of the *frontend*
to translate the strings.  The SANE_I18N macro is only the marker we use
to tell xgettext which strings should be translated.  These strings end
up in po/sane-backends.pot.

The reasoning behind making the frontend responsible for translation is
that the backend may be executing remotely (e.g. via saned).  You don't
want to get the translations suitable for a remotely executing process.
This process may execute under a different LANG setting than your local
SANE frontend.

Let's say you run your frontend with LANG=zh_CN and scan via the net
backend on a server that just happens to run saned with LANG=fr_FR.
Would you be happy with French messages?  Probably not ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] CI now builds snapshots with "funny" versions

2017-07-01 Thread Olaf Meeuwissen
Hi Allan,

About two weeks ago I wrote on the sane-devel mailing list:

> Dear list,
>
> [ ... creating `git describe --dirty` versioned tarballs ...]
>
> So then, what does happen on Alioth when the daily snapshots are made?
> These snapshots are, unsurprisingly, courtesy of a daily cron job.  It
> runs something close to
>
>   git archive --format=tar master | gzip > sane-backends-$DATE.tar.gz
>
> I've tried to run `make dist` on Alioth.  No such luck.  [...]
>
> The fact you cannot run `make dist` on Alioth is probably why the daily
> snapshots are just `git archive`s, but those archives are not made the
> way as our release tarballs.  And that bugs me.  Maybe I should change
> that cron job to pull the tarballs from GitLab.com ...

Well, I did just that and ran it manually without any hitch.  There is
now an extra snapshot[1] that is made the same way we roll our release
tarballs.

 [1] http://sane-project.org/snapshots/

This snapshot corresponds to the most current git checkout that passed
the CI build at GitLab.com.

The updated make-git-snapshots.sh should (famous last words!) run
without any trouble and produce no output.  If, however, you start
receiving mail from your daily sane cronjob, just forward it to me
and I'll fix it up.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] Multi-page scans

2017-06-29 Thread Olaf Meeuwissen
Hi,

dm...@yahoo.fr writes:

> I am running Xsane under Ubuntu 64bit and my printer is an Epson
> ET-4550.  I've had trouble getting Xsane to recognise it wirelessly, so
> I am using a USB connection. The machine sits about 4 feet from my
> desktop PC.
>
> The printer has a document feeder, but I am trying to scan non-standard
> sheets, so these need to be placed on the platen.  I am trying to get
> multi-page pdfs, but it's quite hard, as I have to quickly open the lid
> of the scanner and replace the page before it starts scanning the next
> page, and I can only tell when to do this by listening to the tone of
> the motor driving the scanner arm!
>
> Is there a way of setting Xsane to pause between each page of the scan,
> or is there a better way of achieving what I am trying to do?  Thanks.

If you can translate your non-default scan settings to command-line
options, then yes.  You can use

  scanimage --batch-prompt [other-options]

to do what you want.  See the scanimage manual page for details.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] [janitorial] Fixing compiler warnings (was: :Debian 9 CI builds added)

2017-06-26 Thread Olaf Meeuwissen
Hi all,

Olaf Meeuwissen writes:
> At present, the Debian 9 builds only test compilation and flag compiler
> warnings.  They do not fail the build if there are any warnings, unlike
> the builds for Debian 8.
>
> I plan to "stamp out" warnings on *both* Debian versions, in the next
> few weeks/months, but feel free to help out ;-)

An unexpected foot mishap kept me from running on my day off so I went
into "compiler warning fixer bot" mode and fixed most of them.  Build
results should be in soon.

# Eh, they finished while writing this mail ...

There are really only two issues left:

 - use of the deprecated readdir_r in sanei/sanei_scsi.c

 - misleading indentation in the plustek-pp backend

I have fixed a small pile of misleading indentation warnings in other
backends but the mix of indentation "styles" (if you can bring yourself
to call it that) in the plustek-pp source code makes the code just about
impossible to read.  I felt a strong urge to just pull the files through
a code beautifier but managed to resist that for now.

@Gerhard> Seeing that git blames you for most of that code, can you
  please take a look and fix up at least the trouble spots?
  The warnings can be found in the logs of the Debian 9 CI
  build pipelines on gitlab[1].

  [1] https://gitlab.com/sane-project/backends/pipelines/9333781

The readdir_r warning I'll get to sometime soonish, I hope.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Debian 9 CI builds added

2017-06-22 Thread Olaf Meeuwissen
Hi all,

I have been refactoring the way the Docker images for the CI jobs are
built and added support for Debian 9 which was released on 2017-06-17.

At present, the Debian 9 builds only test compilation and flag compiler
warnings.  They do not fail the build if there are any warnings, unlike
the builds for Debian 8.

I plan to "stamp out" warnings on *both* Debian versions, in the next
few weeks/months, but feel free to help out ;-)

# BTW, Fedora 26 is also nearing release, with gcc-7 ... curious what
# that'll bring.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


Re: [sane-devel] need help with hp 2135 all in one scanning...

2017-06-17 Thread Olaf Meeuwissen
Hi Stamatis,

Stamatis Diamantopoulos writes:

> hallo
>
> i have been using the ' *2135 hp all in one*'  scanner for 6 months now for
> printing and scanning. two days ago i got an error message saying
> no devices found
> i can still print and photocopy but no scanning...

What happened between two days ago and the last time you scanned in
terms of your system setup?

> i have uninstalled and reinstalled *xsane* still nothing happened
> my sane version is :

Very unlikely that xsane has anything to do with this.

> *libsane.so.1 -> libsane.so.1.0.27libsane.so.1 -> libsane.so.1.0.27*

Now here's a possible clue.  That version was only released about a
month ago.  Looks like you updated.  Would reverting back to 1.0.25
be an option?

# Depending on your OS, there may be binary packages with a 1.0.26*
# version.  If so, that would be fine too.  BTW, telling us what OS
# and version of it you're using will make helping you easier.

> in the terminal* sudo sane-find-scanner* gave this:
>
> found USB scanner (vendor=0x0bda [Generic], product=0x0129 [USB2.0-CRW]) at 
> libusb:001:006
> found USB scanner (vendor=0x0a5c [Broadcom Corp], product=0x21d7 
> [BCM43142A0]) at libusb:001:005
> found USB scanner (vendor=0x03f0 [HP], product=0xe111 [DeskJet 2130 series]) 
> at libusb:001:007

The SANE project doesn't have any explicit info on that HP scanner.
Could it be that you have been using the external hpaio backend?

> any help welcomed...

Does running

  sudo scanimage --list-devices

show your scanner?  If it does, it's a permission issue.  Something must
have changed the permission settings.  Perhaps your upgrade to 1.0.27?
If so, I'd like to know *how* you upgraded because it could be an issue
with your OS' provided binary package (meaning more people are affected
and that package ought to get fixed).

If the above command does not list your scanner, I can think of two
possibilities, assuming you used the hpaio backend.  Either that backend
is no longer installed or your sane-backends-1.0.27 can no longer find
it for some reason.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


[sane-devel] [janitorial] Git post-receive hook changes (was Re: Pushing autofoo changes to Alioth leaves me "stumped")

2017-06-13 Thread Olaf Meeuwissen
Hi again list,

Following up on my own post cuz I've made a few changes on how things
work on Alioth, triggered by me "being stumped".  I've peeked and poked
in the git hooks and think I now sort of know what has been going on all
this time.  From here on things will be a wee bit different, though.

Olaf Meeuwissen writes:

> Hi list,
>
> I just pushed a commit changing configure.ac and backends/Makefile.am.
> Here's part of what that gave me.
>
>  remote: *** A Makefile was modified; please ./configure && make on Alioth
>  remote: *** Contact sane-devel if you don't know what to do

Rather than telling *you* what to do, the post-receive hook will do it
for you.  Unless I screwed up, of course, and within the limitations
that Alioth imposes (no autoconf, no automake, no ... nothing, really,
as far as autotools and gettext are concerned).

> I'm clueless, hence my mail.

I'm a lot less clueless now but still not omniscient, so if you have
trouble pushing your changes to Alioth, please contact the list.

Gory details follow.

> [...]  Let's try
>
>   ./configure
>
> Barfs towards the end with
>
>   configure: creating ./config.status
>   chmod: changing permissions of `./config.status': Operation not permitted
>   configure: error: write failure creating ./config.status
>
> Tried running make anyway.
>
>   Generating epsonds.conf from epsonds.conf.in
>   /bin/bash: epsonds.conf: Permission denied
>   make[1]: *** [epsonds.conf] Error 1
>   make[1]: Leaving directory 
> `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git/backend'
>   make: *** [all-recursive] Error 1
>
> So apart from the lack of tools to do what *should* be done, there are
> also a bunch of permission issues that make the message when pushing,
> eh, well, rather useless.

I've tried to work around this by liberally sprinkling `sg sane`
statements in the scripts that are invoked from the post-receive hook
*and* a `chmod g+w --recursive` on that checkout on Alioth (lots of
"permission denied" errors there, though).

Hope that helps.

> The message when pushing is courtesy of the git post-receive hook.  If I
> rip that out, what will change for the worse, stop working or just plain
> break?

It'll try to run a `./config.status --recheck` for you now.  Which is
really just a half-assed attempt to do the right thing.  The trigger for
this is a change in any file that matches Makefile.  That matches any of
Makefile, Makefile.in, Makefile.in.in and Makefile.am.

# It even matches doc/plustek/Makefile.kernel2[46]!  No idea what those
# are for, yet.

If a Makefile.am changed, you should run automake (or let `make` do the
right thing when ./configure has been run with --enable-maintainer-mode
(it hasn't) but that would in turn fail because automake is missing and
the `missing` script will tell you so).

If a Makefile.in or Makefile.in.in changed, you *should* run autoconf.
Again, if ./configure had been run with --enable-maintainer-mode it does
that for you (but would fail because autoconf is also `missing`).

> In the mean time, I've just run autoreconf on my debian-8-full Docker
> container[1] and pushed the "fall out".
>
>  [1] https://gitlab.com/sane-project/ci-envs
>
> Hmm, that triggered a pile of such messages and tried to
>
>   remote: cd .. && make  am--refresh
>   remote: make[1]: Entering directory 
> `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git'
>   remote: /bin/bash ./config.status --recheck
>
> failing with the same permission errors as before.  All this is rather
> disappointing to see and I'd like to do something about it.  Clues and
> suggestions very welcome.

Failing any suggestions, I'll see if I can at least sort most of this
*mess* out and have the post-receive hook do what's necessary insofar
possible and give actionable feedback where needed.

# It's not just changes to Makefile.am.  Changes to configure.ac and
# acinclude.m4 as well as a few other files will also require running
# some tools that are *not* available on Alioth.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@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-requ...@lists.alioth.debian.org


  1   2   3   4   5   6   7   8   9   10   >