Re: [sane-devel] scanbd integration (was Re: sane-backends release 1.0.26 schedule)

[Olaf Meeuwissen]

Hi Louis,

I already commented rather elaborately on your reply to Allan's follow
up.  Here I just pick up on the things specific to this reply of yours.

Louis Lagendijk writes:

> On Sat, 2017-05-06 at 21:20 +0900, Olaf Meeuwissen wrote:
>> Hi Louis,
>>
>> Louis Lagendijk writes:
>>
>> [snip]
>>
>> > I made a patch to dll.c where
>> > - It used the dll.conf with the name pointed out by env. var
>> > SANE_CONFIG_FILE if defined, if not
>> > - it tries to load a dll2.conf if it exists. This is meant to be a
>> > file
>> > dropped in thre sane config dir by scanbd. If that does not exist
>> > - it follows the existing code path.
>>
>> So, if I understand correctly, your patched dll backend tries
>>
>>  $SANE_CONFIG_FILE (if defined)
>>  $SANE_CONFIG_DIR/dll2.conf (if SANE_CONFIG_DIR is defined)
>>  $sysconfdir/dll2.conf
>>  $SANE_CONFIG_DIR/dll.conf (if SANE_CONFIG_DIR is defined)
>>  $sysconfdir/dll.conf
>>
>> where $sysconfdir is set at ./configure time.Is that right?
>>
> Yes, I am indeed using the $sysconfdir (or SANE_CONFIG_DIR) as search
> path for all config files.
>
> I am using the sanei functions for loading the config, so the logic is
> the same as for loading other config files.

As long as you're using sanei_config_open() to get the file you should
be fine.

>> > I added a #include statement in the config file so dll2.conf can
>> > include dll.conf if so required.
>>
>> How does that work when SANE_CONFIG_DIR is defined?
>
> I need to check this, but I am using sanei_config so it SHOULD (famous
> last words) work. do it would follow the normal search path
> (SANE_CONFIG_DIR if set, otherwise $sysconfdir). I actually implemented
> this by a call to read_conf with the new name from within read_config.
> This would allow even allow an include from an include.

What about the possibility of infinite loops in this case?  An a.conf
including b.conf which includes a.conf.  The various directories that
may be visited in order to locate a file makes this even more difficult
to track/detect.

> I however just realized that if a user gets the override dll.conf,
> scanbd could use dll.conf explicitely. This removes the need for the
> #include, so i will remove it.

That would eliminate a few questions ;-)

> alan mailed me about one issue: if there is a dll2.conf but scanbd is
> not started, sane would not find any scanners. I don't know what to do
> about that case. Well start scanbd init scripts or the systemd units
> could place/remove the dll2.conf, but that is to much of an hack.

The init system should not be doing this kind of stuff.  The package's
post-installation and pre-removal scripts could do this instead.

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-backends release 1.0.26 schedule

[Olaf Meeuwissen]

Hi all,

Louis Lagendijk writes:

> On Sat, 2017-05-06 at 15:55 +0200, Wilhelm wrote:
>> Am 06.05.2017 um 14:27 schrieb m. allan noah:
>> > On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk 
>> > wrote:
>> > >
>> > > Hi,
>> > > Yesterday when I had a look at our bug tracker for any issues in
>> > > my code I found
>> > > https://alioth.debian.org/tracker/?func=detail_id=30186=315004=410366
>> > > This is an issue for scanbd integration that requires more
>> > > flexibility for configuration of dll-loading: when scanbd is used
>> > > users need to use the net backend only, but scanbd/saned need to
>> > > be fed with the "normal" list of backends.
>> > > I made a patch to dll.c where
>> > > - It used the dll.conf with the name pointed out by env. var
>> > >   SANE_CONFIG_FILE if defined, if not
>> > > - it tries to load a dll2.conf if it exists. This is meant to be
>> > >   a file dropped in thre sane config dir by scanbd.  If that does
>> > >   not exist
>> > > - it follows the existing code path.
>> > >
>> > > I added a #include statement in the config file so dll2.conf can
>> > > include dll.conf if so required.
>> > >
>> > > I am in the process of testing and cleaningup. but my question
>> > > is:
>> > > should I commit this change so close to the freeze date?
>> > > Documentation is still to be done, but I would still have 2 weeks
>> > > for that.  Alan, what do you think?
>> >
>> > I don't now recall the entire discussion around the guts of
>> > scanbd's implementation, but you description sounds a little odd to
>> > me.
>> >
>> > 1. If dll2.conf is created by scanbd, and scanbd is not running,
>> > and the user uses scanimage or another frontend, he will
>> > unknowingly load dll2.conf first. Even if dll2.conf #includes
>> > dll.conf, it is still a behavior change.
>> > 2. Do you not also need changes to saned to make this work? That
>> > seemed to be the case in the earlier discussion.
>> > 3. I think I would prefer a more clear name than dll2.conf, but I
>> > cannot think of one :)
>>
>> From a scanbd point of view it would be suffcient to have either:
>>
>> 1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and all
>> sane-applications use the compile-time setting. scanbd can set this
>> to an alternative (e.g. scanbd-dll.conf) file before starting saned.
>>
>> 2) give saned a -c  option
>>
>> I would prefer 1)
>
> Well 2 is not an option in my opinion as there is no way for saned to
> pass an argument to the rest of saned. That is why I implemented 1).

I don't understand why saned would have to pass arguments to the rest of
saned.  Can you explain?

> The change to an alternative dll.file was driven by the fact that when
> packaging scanbd you want to minimize the amount of configuration to be
> done by the user.

There's post-installation scripts that can take care of most of that and
pre-removal scripts can restore things back to how they were.  As far as
I understand, the only thing the user needs to configure are the desired
actions when a button gets pushed.

 - in /etc/scanbd/sane.d/
   - add symlinks to all files (and directories) in /etc/sane.d
   - replace the /etc/scanbd/sane.d/dll.conf link with a copy
   - disable the net backend in /etc/scanbd/sane.d/dll.conf
 - in /etc/sane.d/dll.conf disable all backends
   You could prefix all lines with '#scanbd ' for example.
 - in /etc/sane.d/dll.conf enable the net backend
   I would also add a note that admins should make changes in
   /etc/scanbd/sane.d/dll.conf instead.
 - in /etc/sane.d/net.conf make sure localhost is enabled

After that scanbd can just set SANE_CONFIG_DIR=/etc/scandb/sane.d and do
its thing.

On the off chance that sane-backends package upgrades add/remove conf
files, you should probably also add a trigger to update the symlinks.

Did I miss something?  If not, why would we need to complicate the dll
backend's configuration file handling if this can be handled fairly
easily by package post-installation and pre-removal scripts?

The only "wart" in the above is the pile of symlinks.

But please read on as I am open to modifying the dll backend's conffile
handling.  Just not in the upcoming 1.0.26.  I think it's all too last
minute and could use some more thought and discussion.

> If the scanbd package drops a dll2.conf file in
> SANE_CONFIG_DIR there is no need for manual configuration.
>
> I am now implenmenting a #pidfile directive for in dll2.conf that will
> check for the pidfile and fail processing of dll2.conf and fallback to
> dll.conf.

Hmm, #pidfile looks like a comment to me (and the few backends whose
code I looked at).  You probably should use something without a #.

> The way I envisage this working is:
> The package drops a dll2.conf file containing:
>
> #pidfile=/var/run/scanbd.pid
> net
>
> so sane users see only the net backend if scanbd is active.

Or there is a stale pidfile lingering around.

I doubt that there is much you could do about that.  It would be up to
systemd 

Re: [sane-devel] sane-backends release 1.0.26 schedule

[m. allan noah]

Hmm, I think we should not rush this change. We can do another sane
release once we have something we all agree on, and have spent more
time testing.

allan

On Sat, May 6, 2017 at 2:13 PM, Louis Lagendijk  wrote:
> On Sat, 2017-05-06 at 15:55 +0200, Wilhelm wrote:
>> Am 06.05.2017 um 14:27 schrieb m. allan noah:
>> > On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk 
>> > wrote:
>> > > On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
>> > > > Ok folks, it's time to get another sane-backends release out
>> > > > the
>> > > > door.
>> > > >
>> > > > Olaf has done a good job of cleaning up our contributors list
>> > > > and
>> > > > curating the bug tracker. However, there are a handful of
>> > > > patches in
>> > > > the bug tracker that could still be applied, once they are
>> > > > reviewed.
>> > > > Also, quite a number of backends that are now unmaintained. So,
>> > > > this
>> > > > is a good time to get involved with sane. If you benefit from
>> > > > this
>> > > > project, and have some programming experience, we could use the
>> > > > help.
>> > > >
>> > > > Schedule:
>> > > >
>> > > > May 7: Feature freeze (only fix bugs and update docs after this
>> > > > date)
>> > > > May 14: Code freeze (only update docs after this date)
>> > > > May 21: Release
>> > > >
>> > >
>> > > Hi,
>> > > Yesterday when I had a look at our bug tracker for any issues in
>> > > my
>> > > code I found https://alioth.debian.org/tracker/?func=detail
>> > > _id=30
>> > > 186=315004=410366
>> > > This is an issue for scanbd integration that requires more
>> > > flexibility
>> > > for configuration of dll-loading: when scanbd is used users need
>> > > to use
>> > >  the net backend only, but scanbd/saned need to be fed with the
>> > > "normal" list of backends.
>> > > I made a patch to dll.c where
>> > > - It used the dll.conf with the name pointed out by env. var
>> > > SANE_CONFIG_FILE if defined, if not
>> > > - it tries to load a dll2.conf if it exists. This is meant to be
>> > > a file
>> > > dropped in thre sane config dir by scanbd. If that does not exist
>> > > - it follows the existing code path.
>> > >
>> > > I added a #include statement in the config file so dll2.conf can
>> > > include dll.conf if so required.
>> > >
>> > > I am in the process of testing and cleaningup. but my question
>> > > is:
>> > > should I commit this change so close to the freeze date?
>> > > Documentation
>> > > is still to be done, but I would still have 2 weeks for that.
>> > > Alan, what do you think?
>> > >
>> >
>> > I don't now recall the entire discussion around the guts of
>> > scanbd's
>> > implementation, but you description sounds a little odd to me.
>> >
>> > 1. If dll2.conf is created by scanbd, and scanbd is not running,
>> > and
>> > the user uses scanimage or another frontend, he will unknowingly
>> > load
>> > dll2.conf first. Even if dll2.conf #includes dll.conf, it is still
>> > a
>> > behavior change.
>> > 2. Do you not also need changes to saned to make this work? That
>> > seemed to be the case in the earlier discussion.
>> > 3. I think I would prefer a more clear name than dll2.conf, but I
>> > cannot think of one :)
>>
>> From a scanbd point of view it would be suffcient to have either:
>>
>> 1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and all
>> sane-applications use the compile-time setting. scanbd can set this
>> to
>> an alternative (e.g. scanbd-dll.conf) file before starting saned.
>>
>> 2) give saned a -c  option
>>
>> I would prefer 1)
>>
> Well 2 is not an option in my opinion as there is no way for saned to
> pass an argument to the rest of saned. That is why I implemented 1).
>
> The change to an alternative dll.file was driven by the fact that when
> packaging scanbd you want to minimize the amount of configuration to be
> done by the user. If the scanbd package drops a dll2.conf file in
> SANE_CONFIG_DIR there is no need for manual configuration.
>
> I am now implenmenting a #pidfile directive for in dll2.conf that will
> check for the pidfile and fail processing of dll2.conf and fallback to
> dll.conf.
>
> The way I envisage this working is:
> The package drops a dll2.conf file containing:
>
> #pidfile=/var/run/scanbd.pid
> net
>
> so sane users see only the net backend if scanbd is active.
>
> The default dll.conf remains unchanged, but net should be commented out
>
> Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf)
>
>
> The only configuration required from the user is:
> - comment net from dll.conf if not already done
> - populate net.conf with localhost
>
> I changed the name of the alternative config file to dll-override.conf
> (but remain open for better alternatives).
>
> I hope that these changes (dll-override.conf as name + check for
> pidfile) address concerns people may have so I can commit the changes
> today and be in time for 1.0.26.
>
> Comments anybody?
>
> BR, Louis
>
> --
> sane-devel mailing list: 

Re: [sane-devel] sane-backends release 1.0.26 schedule

[Louis Lagendijk]

On Sat, 2017-05-06 at 15:55 +0200, Wilhelm wrote:
> Am 06.05.2017 um 14:27 schrieb m. allan noah:
> > On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk 
> > wrote:
> > > On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
> > > > Ok folks, it's time to get another sane-backends release out
> > > > the
> > > > door.
> > > > 
> > > > Olaf has done a good job of cleaning up our contributors list
> > > > and
> > > > curating the bug tracker. However, there are a handful of
> > > > patches in
> > > > the bug tracker that could still be applied, once they are
> > > > reviewed.
> > > > Also, quite a number of backends that are now unmaintained. So,
> > > > this
> > > > is a good time to get involved with sane. If you benefit from
> > > > this
> > > > project, and have some programming experience, we could use the
> > > > help.
> > > > 
> > > > Schedule:
> > > > 
> > > > May 7: Feature freeze (only fix bugs and update docs after this
> > > > date)
> > > > May 14: Code freeze (only update docs after this date)
> > > > May 21: Release
> > > > 
> > > 
> > > Hi,
> > > Yesterday when I had a look at our bug tracker for any issues in
> > > my
> > > code I found https://alioth.debian.org/tracker/?func=detail
> > > _id=30
> > > 186=315004=410366
> > > This is an issue for scanbd integration that requires more
> > > flexibility
> > > for configuration of dll-loading: when scanbd is used users need
> > > to use
> > >  the net backend only, but scanbd/saned need to be fed with the
> > > "normal" list of backends.
> > > I made a patch to dll.c where
> > > - It used the dll.conf with the name pointed out by env. var
> > > SANE_CONFIG_FILE if defined, if not
> > > - it tries to load a dll2.conf if it exists. This is meant to be
> > > a file
> > > dropped in thre sane config dir by scanbd. If that does not exist
> > > - it follows the existing code path.
> > > 
> > > I added a #include statement in the config file so dll2.conf can
> > > include dll.conf if so required.
> > > 
> > > I am in the process of testing and cleaningup. but my question
> > > is:
> > > should I commit this change so close to the freeze date?
> > > Documentation
> > > is still to be done, but I would still have 2 weeks for that.
> > > Alan, what do you think?
> > > 
> > 
> > I don't now recall the entire discussion around the guts of
> > scanbd's
> > implementation, but you description sounds a little odd to me.
> > 
> > 1. If dll2.conf is created by scanbd, and scanbd is not running,
> > and
> > the user uses scanimage or another frontend, he will unknowingly
> > load
> > dll2.conf first. Even if dll2.conf #includes dll.conf, it is still
> > a
> > behavior change.
> > 2. Do you not also need changes to saned to make this work? That
> > seemed to be the case in the earlier discussion.
> > 3. I think I would prefer a more clear name than dll2.conf, but I
> > cannot think of one :)
> 
> From a scanbd point of view it would be suffcient to have either:
> 
> 1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and all
> sane-applications use the compile-time setting. scanbd can set this
> to
> an alternative (e.g. scanbd-dll.conf) file before starting saned.
> 
> 2) give saned a -c  option
> 
> I would prefer 1)
> 
Well 2 is not an option in my opinion as there is no way for saned to
pass an argument to the rest of saned. That is why I implemented 1).

The change to an alternative dll.file was driven by the fact that when
packaging scanbd you want to minimize the amount of configuration to be
done by the user. If the scanbd package drops a dll2.conf file in
SANE_CONFIG_DIR there is no need for manual configuration.

I am now implenmenting a #pidfile directive for in dll2.conf that will
check for the pidfile and fail processing of dll2.conf and fallback to
dll.conf. 

The way I envisage this working is:
The package drops a dll2.conf file containing:

#pidfile=/var/run/scanbd.pid
net

so sane users see only the net backend if scanbd is active.

The default dll.conf remains unchanged, but net should be commented out

Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf)


The only configuration required from the user is:
- comment net from dll.conf if not already done
- populate net.conf with localhost

I changed the name of the alternative config file to dll-override.conf
(but remain open for better alternatives).

I hope that these changes (dll-override.conf as name + check for
pidfile) address concerns people may have so I can commit the changes
today and be in time for 1.0.26.

Comments anybody?

BR, Louis

-- 
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] scanbd integration (was Re: sane-backends release 1.0.26 schedule)

[Louis Lagendijk]

On Sat, 2017-05-06 at 21:20 +0900, Olaf Meeuwissen wrote:
> Hi Louis,
> 
> Louis Lagendijk writes:
> 
> > On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
> > > Ok folks, it's time to get another sane-backends release out the
> > > door.
> > 
> > [snip]
> > 
> > Hi,
> > Yesterday when I had a look at our bug tracker for any issues in my
> > code I found https://alioth.debian.org/tracker/?func=detail_i
> > d=30186=315004=410366
> > This is an issue for scanbd integration that requires more
> > flexibility
> > for configuration of dll-loading: when scanbd is used users need to
> > use
> > the net backend only, but scanbd/saned need to be fed with the
> > "normal" list of backends.
> 
> Thanks for trying to improve scanbd integration.
> 
> > I made a patch to dll.c where
> > - It used the dll.conf with the name pointed out by env. var
> > SANE_CONFIG_FILE if defined, if not
> > - it tries to load a dll2.conf if it exists. This is meant to be a
> > file
> > dropped in thre sane config dir by scanbd. If that does not exist
> > - it follows the existing code path.
> 
> So, if I understand correctly, your patched dll backend tries
> 
>   $SANE_CONFIG_FILE (if defined)
>   $SANE_CONFIG_DIR/dll2.conf (if SANE_CONFIG_DIR is defined)
>   $sysconfdir/dll2.conf
>   $SANE_CONFIG_DIR/dll.conf (if SANE_CONFIG_DIR is defined)
>   $sysconfdir/dll.conf
> 
> where $sysconfdir is set at ./configure time.  Is that right?
> 
Yes, I am indeed using the $sysconfdir (or SANE_CONFIG_DIR) as search
path for all config files. 

I am using the sanei functions for loading the config, so the logic is
the same as for loading other config files.


> If so, I guess that could be okay but I don't like the dll2.conf name
> very much.  It seems to imply there's a dll2 backend.  There isn't
> one,
> not now at least.
Neither do I. I am still looking for something better, right now I am
trying to get a working solution. How about dll-override.conf?

> > I added a #include statement in the config file so dll2.conf can
> > include dll.conf if so required.
> 
> How does that work when SANE_CONFIG_DIR is defined?

I need to check this, but I am using sanei_config so it SHOULD (famous
last words) work. do it would follow the normal search path
(SANE_CONFIG_DIR if set, otherwise $sysconfdir). I actually implemented
this by a call to read_conf with the new name from within read_config.
This would allow even allow an include from an include.

I however just realized that if a user gets the override dll.conf,
scanbd could use dll.conf explicitely. This removes the need for the
#include, so i will remove it.

alan mailed me about one issue: if there is a dll2.conf but scanbd is
not started, sane would not find any scanners. I don't know what to do
about that case. Well start scanbd init scripts or the systemd units
could place/remove the dll2.conf, but that is to much of an hack. Maybe
 add a pidfile parameter on the first line in dll2.conf that if not
present makes sane fallback to dll.conf?

Thanks for the feedback
Louis

-- 
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 for Panasonic

[Jeff Breidenbach]

See also

https://code.google.com/archive/p/kvss905c/downloads
-- 
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-backends release 1.0.26 schedule

[Wilhelm]

Am 06.05.2017 um 14:27 schrieb m. allan noah:
> On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk  wrote:
>> On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
>>> Ok folks, it's time to get another sane-backends release out the
>>> door.
>>>
>>> Olaf has done a good job of cleaning up our contributors list and
>>> curating the bug tracker. However, there are a handful of patches in
>>> the bug tracker that could still be applied, once they are reviewed.
>>> Also, quite a number of backends that are now unmaintained. So, this
>>> is a good time to get involved with sane. If you benefit from this
>>> project, and have some programming experience, we could use the help.
>>>
>>> Schedule:
>>>
>>> May 7: Feature freeze (only fix bugs and update docs after this date)
>>> May 14: Code freeze (only update docs after this date)
>>> May 21: Release
>>>
>>
>> Hi,
>> Yesterday when I had a look at our bug tracker for any issues in my
>> code I found https://alioth.debian.org/tracker/?func=detail_id=30
>> 186=315004=410366
>> This is an issue for scanbd integration that requires more flexibility
>> for configuration of dll-loading: when scanbd is used users need to use
>>  the net backend only, but scanbd/saned need to be fed with the
>> "normal" list of backends.
>> I made a patch to dll.c where
>> - It used the dll.conf with the name pointed out by env. var
>> SANE_CONFIG_FILE if defined, if not
>> - it tries to load a dll2.conf if it exists. This is meant to be a file
>> dropped in thre sane config dir by scanbd. If that does not exist
>> - it follows the existing code path.
>>
>> I added a #include statement in the config file so dll2.conf can
>> include dll.conf if so required.
>>
>> I am in the process of testing and cleaningup. but my question is:
>> should I commit this change so close to the freeze date? Documentation
>> is still to be done, but I would still have 2 weeks for that.
>> Alan, what do you think?
>>
> 
> I don't now recall the entire discussion around the guts of scanbd's
> implementation, but you description sounds a little odd to me.
> 
> 1. If dll2.conf is created by scanbd, and scanbd is not running, and
> the user uses scanimage or another frontend, he will unknowingly load
> dll2.conf first. Even if dll2.conf #includes dll.conf, it is still a
> behavior change.
> 2. Do you not also need changes to saned to make this work? That
> seemed to be the case in the earlier discussion.
> 3. I think I would prefer a more clear name than dll2.conf, but I
> cannot think of one :)

>From a scanbd point of view it would be suffcient to have either:

1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and all
sane-applications use the compile-time setting. scanbd can set this to
an alternative (e.g. scanbd-dll.conf) file before starting saned.

2) give saned a -c  option

I would prefer 1)

Thanks for investigating on this ;.)

--
 Wilhelm


-- 
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] scanbd integration (was Re: sane-backends release 1.0.26 schedule)

[Olaf Meeuwissen]

Hi Louis,

Louis Lagendijk writes:

> On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
>> Ok folks, it's time to get another sane-backends release out the
>> door.
> [snip]
>
> Hi,
> Yesterday when I had a look at our bug tracker for any issues in my
> code I found 
> https://alioth.debian.org/tracker/?func=detail_id=30186=315004=410366
> This is an issue for scanbd integration that requires more flexibility
> for configuration of dll-loading: when scanbd is used users need to use
> the net backend only, but scanbd/saned need to be fed with the
> "normal" list of backends.

Thanks for trying to improve scanbd integration.

> I made a patch to dll.c where
> - It used the dll.conf with the name pointed out by env. var
> SANE_CONFIG_FILE if defined, if not
> - it tries to load a dll2.conf if it exists. This is meant to be a file
> dropped in thre sane config dir by scanbd. If that does not exist
> - it follows the existing code path.

So, if I understand correctly, your patched dll backend tries

  $SANE_CONFIG_FILE (if defined)
  $SANE_CONFIG_DIR/dll2.conf (if SANE_CONFIG_DIR is defined)
  $sysconfdir/dll2.conf
  $SANE_CONFIG_DIR/dll.conf (if SANE_CONFIG_DIR is defined)
  $sysconfdir/dll.conf

where $sysconfdir is set at ./configure time.  Is that right?

If so, I guess that could be okay but I don't like the dll2.conf name
very much.  It seems to imply there's a dll2 backend.  There isn't one,
not now at least.

> I added a #include statement in the config file so dll2.conf can
> include dll.conf if so required.

How does that work when SANE_CONFIG_DIR is defined?

> I am in the process of testing and cleaningup. but my question is:
> should I commit this change so close to the freeze date?

I prefer you don't.  There still seem to be a few things that need
sorting out and code freeze is tomorrow ;-)  Too risky if you ask me.

> Documentation is still to be done, but I would still have 2 weeks for
> that.  Alan, what do you think?

Allan, can we make improving scanbd integration a priority for the
release after 1.0.26 and schedule that soonish, like say in three months
or so?  Preferably in time for inclusion in the Autumn releases of the
major Linux distributions.

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-backends release 1.0.26 schedule

[m. allan noah]

On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk  wrote:
> On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
>> Ok folks, it's time to get another sane-backends release out the
>> door.
>>
>> Olaf has done a good job of cleaning up our contributors list and
>> curating the bug tracker. However, there are a handful of patches in
>> the bug tracker that could still be applied, once they are reviewed.
>> Also, quite a number of backends that are now unmaintained. So, this
>> is a good time to get involved with sane. If you benefit from this
>> project, and have some programming experience, we could use the help.
>>
>> Schedule:
>>
>> May 7: Feature freeze (only fix bugs and update docs after this date)
>> May 14: Code freeze (only update docs after this date)
>> May 21: Release
>>
>
> Hi,
> Yesterday when I had a look at our bug tracker for any issues in my
> code I found https://alioth.debian.org/tracker/?func=detail_id=30
> 186=315004=410366
> This is an issue for scanbd integration that requires more flexibility
> for configuration of dll-loading: when scanbd is used users need to use
>  the net backend only, but scanbd/saned need to be fed with the
> "normal" list of backends.
> I made a patch to dll.c where
> - It used the dll.conf with the name pointed out by env. var
> SANE_CONFIG_FILE if defined, if not
> - it tries to load a dll2.conf if it exists. This is meant to be a file
> dropped in thre sane config dir by scanbd. If that does not exist
> - it follows the existing code path.
>
> I added a #include statement in the config file so dll2.conf can
> include dll.conf if so required.
>
> I am in the process of testing and cleaningup. but my question is:
> should I commit this change so close to the freeze date? Documentation
> is still to be done, but I would still have 2 weeks for that.
> Alan, what do you think?
>

I don't now recall the entire discussion around the guts of scanbd's
implementation, but you description sounds a little odd to me.

1. If dll2.conf is created by scanbd, and scanbd is not running, and
the user uses scanimage or another frontend, he will unknowingly load
dll2.conf first. Even if dll2.conf #includes dll.conf, it is still a
behavior change.
2. Do you not also need changes to saned to make this work? That
seemed to be the case in the earlier discussion.
3. I think I would prefer a more clear name than dll2.conf, but I
cannot think of one :)

allan

-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"

-- 
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] Fix PPA build (was Re: sane-backends release 1.0.26 schedule)

[Olaf Meeuwissen]

Hi Rolf,

Rolf Bensch writes:

> Hi Olaf,
>
> I tried to build a recent version for zesty some weeks ago with my test
> ppa: https://launchpad.net/~rolfbensch/+archive/ubuntu/sane-test/+packages .

Thanks for the link!  Now I can see the build failures.
BTW, it looks like the build does not apply the debian/patches/.  Don't
know if that's intentional or not.

> I'll try to investigate this issue next week. If you can provide a patch
> before, I can merge it into the build system very quickly.

See the attached.
 - debian/rules: modified a few configure flags and added one for the
   API spec (BTW, 6ffeb909 fixed a brain fart for that option)
 - debian/control: add transfig as a build dependency for the spec (BTW,
   we do PDF now too but that requires pdflatex and gs as well)
 - debian/patches/multiarch_dll_searc_path.patch: adjust to upstream
   changes

Note that this only aims to fix the xenial build but the other builds
should be mostly identical if not exactly.

I've checked

  debian/rules binary
  dpkg-buildpackage -b

and both complete without a hitch, on xenial (in a Docker container).

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
diff -ru sane-backends-git20160712/debian/control sane-backends-g6ffeb90/debian/control
--- sane-backends-git20160712/debian/control	2016-04-22 02:58:47.0 +0900
+++ sane-backends-g6ffeb90/debian/control	2017-05-06 20:25:38.417580064 +0900
@@ -22,6 +22,7 @@
  po-debconf,
  texlive,
  texlive-latex-extra,
+ transfig,
  xutils-dev
 Homepage: http://www.sane-project.org
 
diff -ru sane-backends-git20160712/debian/patches/multiarch_dll_search_path.patch sane-backends-g6ffeb90/debian/patches/multiarch_dll_search_path.patch
--- sane-backends-git20160712/debian/patches/multiarch_dll_search_path.patch	2016-07-03 04:42:43.0 +0900
+++ sane-backends-g6ffeb90/debian/patches/multiarch_dll_search_path.patch	2017-05-06 20:57:03.126925833 +0900
@@ -7,21 +7,21 @@
 ===
 --- sane-backends-1.0.23.orig/backend/dll.c	2012-08-10 12:33:29.0 +1200
 +++ sane-backends-1.0.23/backend/dll.c	2012-09-20 11:35:03.742380791 +1200
-@@ -430,7 +430,7 @@
+@@ -450,7 +450,7 @@
  
if (path)
  {
--  src_len = strlen (path) + strlen (LIBDIR) + 1 + 1;
-+  src_len = strlen (path) + strlen (DEB_DLL_LIBDIR) + 1 + 1;
+-  src_len = strlen (path) + strlen (DIR_SEP) + strlen (LIBDIR) + 1;
++  src_len = strlen (path) + strlen (DIR_SEP) + strlen (DEB_DLL_LIBDIR) + 1;
src = malloc (src_len);
if (!src)
  	{
-@@ -438,11 +438,11 @@
+@@ -458,11 +458,11 @@
  	  return SANE_STATUS_NO_MEM;
  	}
orig_src = src;
--  snprintf (src, src_len, "%s:%s", path, LIBDIR);
-+  snprintf (src, src_len, "%s:%s", path, DEB_DLL_LIBDIR);
+-  snprintf (src, src_len, "%s%s%s", path, DIR_SEP, LIBDIR);
++  snprintf (src, src_len, "%s%s%s", path, DIR_SEP, DEB_DLL_LIBDIR);
  }
else
  {
diff -ru sane-backends-git20160712/debian/rules sane-backends-g6ffeb90/debian/rules
--- sane-backends-git20160712/debian/rules	2013-03-13 00:37:25.0 +0900
+++ sane-backends-g6ffeb90/debian/rules	2017-05-06 20:20:12.367963271 +0900
@@ -48,15 +48,16 @@
 		--localstatedir=/var \
 		--datadir=\$${prefix}/share \
 		--mandir=\$${prefix}/share/man \
-		--with-docdir=\$${prefix}/share/doc/libsane \
+		--docdir=\$${prefix}/share/doc/libsane \
 		--with-snmp=no \
 		--disable-locking \
 		--enable-static \
 		--enable-pthread \
 		--with-gphoto2 \
-		--enable-translations \
+		--enable-nls \
 		--enable-avahi \
-		--enable-libusb_1_0
+		--with-usb \
+		--with-api-spec
 
 	# generate POT file for translators
 	(cd po && make sane-backends.pot)
-- 
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-backends release 1.0.26 schedule

[Louis Lagendijk]

On Fri, 2017-04-28 at 08:04 -0400, m. allan noah wrote:
> Ok folks, it's time to get another sane-backends release out the
> door.
> 
> Olaf has done a good job of cleaning up our contributors list and
> curating the bug tracker. However, there are a handful of patches in
> the bug tracker that could still be applied, once they are reviewed.
> Also, quite a number of backends that are now unmaintained. So, this
> is a good time to get involved with sane. If you benefit from this
> project, and have some programming experience, we could use the help.
> 
> Schedule:
> 
> May 7: Feature freeze (only fix bugs and update docs after this date)
> May 14: Code freeze (only update docs after this date)
> May 21: Release
> 

Hi,
Yesterday when I had a look at our bug tracker for any issues in my
code I found https://alioth.debian.org/tracker/?func=detail_id=30
186=315004=410366
This is an issue for scanbd integration that requires more flexibility
for configuration of dll-loading: when scanbd is used users need to use
 the net backend only, but scanbd/saned need to be fed with the
"normal" list of backends.
I made a patch to dll.c where
- It used the dll.conf with the name pointed out by env. var
SANE_CONFIG_FILE if defined, if not
- it tries to load a dll2.conf if it exists. This is meant to be a file
dropped in thre sane config dir by scanbd. If that does not exist
- it follows the existing code path.

I added a #include statement in the config file so dll2.conf can
include dll.conf if so required.

I am in the process of testing and cleaningup. but my question is:
should I commit this change so close to the freeze date? Documentation
is still to be done, but I would still have 2 weeks for that.
Alan, what do you think?

cheers, Louis

-- 
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-backends release 1.0.26 schedule

[Rolf Bensch]

Hi Olaf,

I tried to build a recent version for zesty some weeks ago with my test
ppa: https://launchpad.net/~rolfbensch/+archive/ubuntu/sane-test/+packages .

I'll try to investigate this issue next week. If you can provide a patch
before, I can merge it into the build system very quickly.

Hope this helps.

Cheers,
Rolf


Am 06.05.2017 um 08:32 schrieb Olaf Meeuwissen:
> Hi again,
> 
> Olaf Meeuwissen writes:
> 
>> Hi Allan,
>>
>> m. allan noah writes:
>>
>>> Ok folks, it's time to get another sane-backends release out the door.
>>
>> [snip]
>>> However, there are a handful of patches in
>>> the bug tracker that could still be applied, once they are reviewed.
>>
>> I'm working through the recent patches to the mailing list.
> 
> I'm done with the patches to the mailing list as well as any in the bug
> tracker.  I've gone back all the way to September 2015.  There are still
> a few patches in the bug tracker for issues that have been assigned and
> seen follow-up from assignees.  Those I haven't touched.  I'll leave
> these to the respective assignees.
> 
> # Going through all open bugs looking for patches is *no* fun.  I had to
> # open every single bug report :-(  Is there no way to flag bug reports
> # with a patch so I can query on that?
> 
>> I also have some concerns about Wilhelm's report (from 2017-04-05)
>> that looping over
>>
>>   sane_init()
>>   sane_get_devices()
>>   sane_exit()
>>
>> crashes on Debian (not on Arch Linux or Gentoo).  It appears to be an
>> issue with threading.  I know the sanei_thread API has issues but
>> haven't gotten around to testing this.  I hope to take a look before
>> the release.
> 
> This seems to have been fixed in git.  See the mailing list for details.
> 
>> [snip]
>> Do you need a hand writing or an eye reviewing the release notes?  If
>> yes, just say so.
>>
>> Please mention that the USB support's configure option has changed, that
>> libusb-0.1 is deprecated and that libusb-1.0 is the default now (if both
>> are available).  This may hit unsuspecting binary package maintainers.
>>
>> @Rolf> Could the changed configure option be why your PPAs no longer
>>build?  See a9c81394 for details.  You want --with-usb (or just
>>default if a libusb*-dev package is in the Build-Depends).  If
>>it's something else, let us know what's preventing your builds
>>from succeeding.
> 
> I've started looking at Rolf's PPA build issue.  It doesn't seem to be
> the --with-usb flag that's causing the trouble.  There's a couple of
> things that need fixing but I'll have a look at that later today or
> tomorrow.
> 
>> As there have been some changes in configure.ac and friends, I'll check
>> if the doc/backend-writing.txt file needs updating.
> 
> This is still on my 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] Xsane does not work any more with Lide 200 and Lide220 at Ubuntu16.04LTS

[csola48]

  
  
2017-05-06 02:34 keltezéssel, Aaron
  Muir Hamilton írta:


  I don't think there is a fix for this in sane-backends. I don't think
the problem is in sane-backends. I think it's a problem with XSane (and
a couple of other frontends).



 

  Yeah!
But then we the solution?! Command line?
It Xsane is not developed? 

csola48


  

  


-- 
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_init()/sane_exit() crashes on debian systems / not on e.g. arch linux

[Wilhelm Meier]

Hi Olaf,

Am 06.05.2017 um 07:58 schrieb Olaf Meeuwissen:
> Hi again,
> 
> Olaf Meeuwissen writes:
> 
>> Hi Wilhelm,
>>
>> Wilhelm writes:
>>
>>> Hi all,
>>>
>>> the following small program regularly crashes on debian based system
>>> when inserting / removing a device. This does not happen on e.g. arch
>>> linux or gentoo systems.
>>
>> A bit late perhaps, but I've been trying to reproduce this without any
>> success.
> 
> I seem to be having more luck now.
> 
>> I'm using Debian stretch (9.0 to be), last updated 2017-05-01 with a
>> default SANE configuration.  I don't have scanbd installed and don't
>> have saned set up.  I have an EPSON PM-A750 attached which is supported
>> by the epson2 backend.
>>
>> I saved your program to debian-crash.c and compiled with:
>>
>>   gcc -lsane -o debian-crash debian-crash.c
>>
>> Running ./debian-crash (I'm a member of the scanner group so no sudo is
>> required) did not produce the problem you describe.  At least not in the
>> 5 or 6 cycles I let it run for before killing it with Ctrl-C.
> 
> After 10 cycles the pixma backend started printing warnings but no
> crash.  I had to enable localhost in the net backend to get things
> to crash.  That also happened at the 10th cycle (on my system).
> 
>   sane version 1.0
>   [bjnp] create_broadcast_socket: ERROR - can not open socket - Too many open 
> files[bjnp] create_broadcast_socket: ERROR - can not open socket - Too many 
> open files[bjnp] create_broadcast_socket: ERROR - can not open socket - Too 
> many open filesdebian-crash: thread-watch.c:171: avahi_threaded_poll_lock: 
> Assertion `p' failed.
>   Aborted
> 
> I used f3f8afb0 with the debian/rules for 1.0.25-4 to configure and
> build libraries.  Running the same test with the libsane.so that
> produces no longer triggered the above.
> I let it run for 100 cycles but that did not trigger any crash.
> 
>> [snip]
>>> Any reasons or plans to fix that?
> 
> Looks like it has been fixed in the latest code in git (although I don't
> know what commit(s) were responsible for that).  

thank you for dealing with this issue.

This seems very reasonable to me since ArchLinux the package uses the
most recent sources whereas debian / ubuntu is a bit behind.

Well, I had to put a workaround into scanbd ...

Thanks again!

> If you still see this
> problem on your end with the latest version in git, please let us know
> what is needed to reproduce and include more details on the symptoms you
> see.
> 
> 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-backends release 1.0.26 schedule

[Olaf Meeuwissen]

Hi again,

Olaf Meeuwissen writes:

> Hi Allan,
>
> m. allan noah writes:
>
>> Ok folks, it's time to get another sane-backends release out the door.
>
> [snip]
>> However, there are a handful of patches in
>> the bug tracker that could still be applied, once they are reviewed.
>
> I'm working through the recent patches to the mailing list.

I'm done with the patches to the mailing list as well as any in the bug
tracker.  I've gone back all the way to September 2015.  There are still
a few patches in the bug tracker for issues that have been assigned and
seen follow-up from assignees.  Those I haven't touched.  I'll leave
these to the respective assignees.

# Going through all open bugs looking for patches is *no* fun.  I had to
# open every single bug report :-(  Is there no way to flag bug reports
# with a patch so I can query on that?

> I also have some concerns about Wilhelm's report (from 2017-04-05)
> that looping over
>
>   sane_init()
>   sane_get_devices()
>   sane_exit()
>
> crashes on Debian (not on Arch Linux or Gentoo).  It appears to be an
> issue with threading.  I know the sanei_thread API has issues but
> haven't gotten around to testing this.  I hope to take a look before
> the release.

This seems to have been fixed in git.  See the mailing list for details.

> [snip]
> Do you need a hand writing or an eye reviewing the release notes?  If
> yes, just say so.
>
> Please mention that the USB support's configure option has changed, that
> libusb-0.1 is deprecated and that libusb-1.0 is the default now (if both
> are available).  This may hit unsuspecting binary package maintainers.
>
> @Rolf> Could the changed configure option be why your PPAs no longer
>build?  See a9c81394 for details.  You want --with-usb (or just
>default if a libusb*-dev package is in the Build-Depends).  If
>it's something else, let us know what's preventing your builds
>from succeeding.

I've started looking at Rolf's PPA build issue.  It doesn't seem to be
the --with-usb flag that's causing the trouble.  There's a couple of
things that need fixing but I'll have a look at that later today or
tomorrow.

> As there have been some changes in configure.ac and friends, I'll check
> if the doc/backend-writing.txt file needs updating.

This is still on my 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_init()/sane_exit() crashes on debian systems / not on e.g. arch linux

[Olaf Meeuwissen]

Hi again,

Olaf Meeuwissen writes:

> Hi Wilhelm,
>
> Wilhelm writes:
>
>> Hi all,
>>
>> the following small program regularly crashes on debian based system
>> when inserting / removing a device. This does not happen on e.g. arch
>> linux or gentoo systems.
>
> A bit late perhaps, but I've been trying to reproduce this without any
> success.

I seem to be having more luck now.

> I'm using Debian stretch (9.0 to be), last updated 2017-05-01 with a
> default SANE configuration.  I don't have scanbd installed and don't
> have saned set up.  I have an EPSON PM-A750 attached which is supported
> by the epson2 backend.
>
> I saved your program to debian-crash.c and compiled with:
>
>   gcc -lsane -o debian-crash debian-crash.c
>
> Running ./debian-crash (I'm a member of the scanner group so no sudo is
> required) did not produce the problem you describe.  At least not in the
> 5 or 6 cycles I let it run for before killing it with Ctrl-C.

After 10 cycles the pixma backend started printing warnings but no
crash.  I had to enable localhost in the net backend to get things
to crash.  That also happened at the 10th cycle (on my system).

  sane version 1.0
  [bjnp] create_broadcast_socket: ERROR - can not open socket - Too many open 
files[bjnp] create_broadcast_socket: ERROR - can not open socket - Too many 
open files[bjnp] create_broadcast_socket: ERROR - can not open socket - Too 
many open filesdebian-crash: thread-watch.c:171: avahi_threaded_poll_lock: 
Assertion `p' failed.
  Aborted

I used f3f8afb0 with the debian/rules for 1.0.25-4 to configure and
build libraries.  Running the same test with the libsane.so that
produces no longer triggered the above.
I let it run for 100 cycles but that did not trigger any crash.

> [snip]
>> Any reasons or plans to fix that?

Looks like it has been fixed in the latest code in git (although I don't
know what commit(s) were responsible for that).  If you still see this
problem on your end with the latest version in git, please let us know
what is needed to reproduce and include more details on the symptoms you
see.

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