Quantcast

1.0.25 is out, now what?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

1.0.25 is out, now what?

Olaf Meeuwissen-4
Hi Devs,

It took two years before 1.0.25 saw the light of day but it has been out
for two weeks now.  Are we going to wait another two years for 1.0.26?
I sincerely hope not.

One of the things that I think contributed to the long period between
releases is the lack of a milestone, plan and/or schedule.  Alioth does
not seem to have any kind of functionality that can help with that so I
have set up a milestone[1] at my sane-backends GitLab clone[2].

 [1] https://gitlab.com/sane-project/backends/milestones/1
 [2] https://gitlab.com/sane-project/backends

And as the current content pretty much sums things up for now, I might
as well just copy-and-paste it:

> This is a very unofficial milestone for the goals for
> sane-backends-1.0.26.  I will update this with feedback from the
> sane-devel mailing list.
>
>  - modernize the autofoo bits
>  - fix all compiler warnings
>  - bump language level to C99
>  - default to libusb-1.0
>
> I would like to get the release into the Ubuntu 16.04 LTS and Fedora
> 24 releases.  That implies that we need to release by early February
> 2016.

Adding support for new devices, improving functionality for devices that
are already supported and fixing bugs will be part of 1.0.26 as well but
I think that that goes without saying.  Said it anyway and maybe that is
just as well.  Better be explicit.

Feedback and suggestions are welcome.

I've already started on the first item in a local topic branch that I
hope to push soonish.

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

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Alessandro Zummo
On Mon, 19 Oct 2015 22:20:25 +0900
Olaf Meeuwissen <[hidden email]> wrote:

> Adding support for new devices, improving functionality for devices that
> are already supported and fixing bugs will be part of 1.0.26 as well but
> I think that that goes without saying.  Said it anyway and maybe that is
> just as well.  Better be explicit.

 Thanks for your hard work. Regarding coolscan3, epson2 and epsonds,
 I have no major additions.

 The first has probably a lot of bugs, but I miss any detailed
 specification from Nikon for most of the scanners.

 epson2 performs quite well, it might have a few bugs too
 but it's surely stable.

 epsonds is a new addition and I was able to test
 it with three quite new scanners. We'll see if there's
 any feedback.

 I welcome C99/C11 and the new libusb.

 There's probably still some bug in the usb code. I have
 intermittent results with some scanners on usb2
 and with others on usb3. switching among the two usb
 standards solves them all.

 Infrared support could be finally enabled as well. my own
 tiffscan frontend already handles it and I had some
 good results using it with coolscan3 and doing
 IR scratch removal with vuescan directly on the produced tiff files.
 
--

 Best regards,

 Alessandro Zummo - CEO,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Johannes Meixner
In reply to this post by Olaf Meeuwissen-4

Hello Olaf,

first and foremost many thanks for all your
"SANE Project Janitor" work.

On Oct 19 22:20 Olaf Meeuwissen wrote (excerpt):
>> ... unofficial ... goals for sane-backends-1.0.26.
>>
>>  - modernize the autofoo bits
>>  - fix all compiler warnings
>>  - bump language level to C99
>>  - default to libusb-1.0
>>
>> ... release by early February 2016.
...
> Feedback and suggestions are welcome.


Suggestion for an additional goal for sane-backends-1.0.26:

- drop support for parallel port scanners

My plan is to do this for sane-backends-1.0.25
for openSUSE Tumbleweed but currently I provide
sane-backends-1.0.25 with parallel port scanner support
because I simply had no time yet to do it.
My current plan how to drop it is to keep the backends
for parallel port scanners but to only remove the
entries for parallel port scanners from the description
files which results that the YaST scanner setup no longer
shows parallel port scanners. This way I could get end-user
feedback if parallel port scanners are still of any interest
and if yes, I could tell the user how to enable the matching
backend manually without the need to install a different
sane-backends package to get a parallel port scanner working.


RFC for an additional goal for sane-backends-1.0.26:

- switch to group "lp" instead of "scanner"

Currently SANE upstream creates udev rules with
MODE="0664", GROUP="scanner".

Hereby I ask for comments whether or not SANE upstream
should switch to group "lp" instead of "scanner".

The reason for using "lp" instead of "scanner" is described
at "USB scanner access permissions via udev" in
https://en.opensuse.org/SDB:Configuring_Scanners
(excerpt):
------------------------------------------------------------------
For USB multifunction devices the multifunction aspect could
make it troublesome in other Linux distributions that may
use the SANE upstream way to set scanner device nodes to
group "scanner" and add the users to that "scanner" group
which conflicts with the CUPS backend that usually needs
"lp" group read/write access to access the printer unit
so that special setup is needed to make printing work.

In openSUSE there is no group "scanner". Only the "lp" group
exists and is used in /etc/udev/rules.d/55-libsane.rules as
MODE="0664", GROUP="lp".

It is sufficiently secure and reasonable easy to use by default
the same group "lp" for printers and scanners because both kind
of devices usually require physical user access (to get the
printed paper or to place a paper on the scanner) so that both
kind of devices should usually require the same kind of security
and for multifunction devices only one group can be set and
then the "lp" group is the more reasonable default setting.
------------------------------------------------------------------

I do not know how read/write access for USB scanners is done
in other Linux distributions. If also other Linux distributions
set normal-user read/write access for the device node by the
udev "uaccess" tool that sets device node user ACLs, then the
"scanner" group should be no longer actually needed because
normal-user read/write access via ACL is independent of the
device node group so that the device node group could be changed
to "lp" without regressions for normal-user read/write access.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Alessandro Zummo

Alessandro Zummo writes:

> On Mon, 19 Oct 2015 22:20:25 +0900
> Olaf Meeuwissen <[hidden email]> wrote:
>
>> Adding support for new devices, improving functionality for devices that
>> are already supported and fixing bugs will be part of 1.0.26 as well but
>> I think that that goes without saying.  Said it anyway and maybe that is
>> just as well.  Better be explicit.
>
>  Thanks for your hard work.

Thanks for the thanks ;-)  It's nice to know at least some people
appreciate what one's doing.

>  Regarding coolscan3, epson2 and epsonds,
>  I have no major additions.
>
>  The first has probably a lot of bugs, but I miss any detailed
>  specification from Nikon for most of the scanners.

No specs is a problem that probably affects most of the backend
developers.  Reverse engineering is no fun and even less so when you
don't have direct access to a device.  Maybe we could think about how to
approach manufacturers to get access to specs and/or devices (and under
what conditions because we still want to be able to release source
code under LGPL-like conditions!) but that is not for 1.0.26.  Perhaps a
discussion about this is better conducted off-list.  Anyway, this is not
something that affects 1.0.26 directly.

> [snip epson2 and epsonds stuff]

>  I welcome C99/C11 and the new libusb.

C11?  Too early, I think.  C99?  So far we have 3 ayes and 0 nays.

>  There's probably still some bug in the usb code. I have
>  intermittent results with some scanners on usb2
>  and with others on usb3. switching among the two usb
>  standards solves them all.

I'm curious about USB related issues that other backends are facing that
might be solved by switching to libusb-1 as the default.  I intend to
keep libusb-0 as a fallback for 1.0.26.

>  Infrared support could be finally enabled as well. my own
>  tiffscan frontend already handles it and I had some
>  good results using it with coolscan3 and doing
>  IR scratch removal with vuescan directly on the produced tiff files.

IR support?  I knew you were gonna bring that up ;-) but that's a SANE
API change.  Given the schedule for 1.0.26, I don't think that is doable
within that time frame.  If we are going to change the API, there are
probably a *lot* of things we should work out before we can commit to
anything.  One of those things would be a clearly documented mechanism
for API changes so that backends *and* frontends can deal with them in a
graceful and sane manner (pun intended) and changes can be made in a
more incremental fashion than library major so-version bumps (if at all
possible).

There's lots more but I'll keep that for later so I can focus on getting
a 1.0.26 out in time for the major Linux distribution's spring releases.
If there are other releases SANE should care about, please say so!

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

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Alessandro Zummo
On Wed, 21 Oct 2015 21:32:37 +0900
Olaf Meeuwissen <[hidden email]> wrote:

> >
> don't have direct access to a device.  Maybe we could think about how to
> approach manufacturers to get access to specs and/or devices (and under
> what conditions because we still want to be able to release source

 Tried many times. Nikon gives out some speca but only
 for a few devices. too less of a market for them.

> >  Infrared support could be finally enabled as well. my own
> >  tiffscan frontend already handles it and I had some
> >  good results using it with coolscan3 and doing
> >  IR scratch removal with vuescan directly on the produced tiff files.
>
> IR support?  I knew you were gonna bring that up ;-) but that's a SANE

 I'm not so much interested anymore, I converted my old
 slides a long time ago and my setup works correctly, but I still
 get requests from time to time.

> API change.  Given the schedule for 1.0.26, I don't think that is doable
> within that time frame.  If we are going to change the API, there are
> probably a *lot* of things we should work out before we can commit to

 luckily we have only a few frontends to check for and most of
 them will correctly bail out when given an unknown frame type.

 given that there are a very few users that would try it I do not
 think we will be receiving a lot of reports of bad frontends.

 once xsane, scanimage, gimp and a few others have been verified
 to work we'd have covered the vast majority

> anything.  One of those things would be a clearly documented mechanism
> for API changes so that backends *and* frontends can deal with them in a
> graceful and sane manner (pun intended) and changes can be made in a

 I haven't checked but I think that it's written somewhere that a frontend
 should correctly behave when given an unknown frame type.

--

 Best regards,

 Alessandro Zummo - CEO,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Johannes Meixner
In reply to this post by Olaf Meeuwissen-4

Hello,

On Oct 21 21:32 Olaf Meeuwissen wrote (excerpt):
> Alessandro Zummo writes:
>>  There's probably still some bug in the usb code. I have
>>  intermittent results with some scanners on usb2
>>  and with others on usb3. switching among the two usb
>>  standards solves them all.
>
> I'm curious about USB related issues that other backends
> are facing that might be solved by switching to libusb-1
> as the default.

At openSUSE we use libusb-1 since openSUSE 12.2
(i.e. we use libusb-1 since about April 2012)
via "configure --enable-libusb_1_0".
I am not aware of issues because of this.


Regarding USB 3, see
https://bugzilla.opensuse.org/show_bug.cgi?id=856794

Summary:
It seems one needs a very current kernel for USB 3.
For me kernel 4.1.6 did not work with sane-backends-1.0.25.
For me kernel-vanilla-4.3.rc5 works where it seems
the xhci USB driver is now at least somewhat fixed.
But I needed additionally the workarounds for
the broken xhci driver in sane-backends-1.0.25
i.e. sane-backends-1.0.24 did not work for me
with kernel-vanilla-4.3.rc5, see
https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c28


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Olaf Meeuwissen-4
Hi Devs,

Olaf Meeuwissen writes:

> [...]
>
> One of the things that I think contributed to the long period between
> releases is the lack of a milestone, plan and/or schedule.  Alioth does
> not seem to have any kind of functionality that can help with that so I
> have set up a milestone[1] at my sane-backends GitLab clone[2].
>
>  [1] https://gitlab.com/sane-project/backends/milestones/1
>  [2] https://gitlab.com/sane-project/backends
>
> And as the current content pretty much sums things up for now, I might
> as well just copy-and-paste it:
>
>> This is a very unofficial milestone for the goals for
>> sane-backends-1.0.26.  I will update this with feedback from the
>> sane-devel mailing list.
>>
>>  - modernize the autofoo bits
> [...]
>
> I've already started on the first item in a local topic branch that I
> hope to push soonish.

OK, so that turned out to happen a bit later than anticipated.  It's
there[3] now though and you are welcome to try it out.

 [3] https://gitlab.com/sane-project/backends/tree/autotool-reform

Simply clone the repository and checkout the autotool-reform branch.  As
I don't think generated files belong in a version control system, you'll
have to run

  autoreconf

after the checkout.  That will make sure your Makefile.in files and the
aclocal.m4 file get updated.  This requires that you have autoconf and
automake installed.  Versions are declared in configure.ac and as of
writing are autoconf-2.69 and automake-1.9.

If you have any trouble with this branch, please create a new ticket[4]
or send mail to the list.  Ditto for other feedback.

 [4] https://gitlab.com/sane-project/backends/issues/new

Next steps on this branch will go through the automake, gettext and
libtool bits, in that order, one at a time.  I expect to end up with
something that requires the versions of these tools in the second half
of 2012.  That should not be too new for development setups, I think.

What I'd like to hear about most, though, is the removal of generated
files from git.  I plan to keep the extra step after checkout limited to
just an

  autoreconf -i

possibly with a -f.  If there are convincing reasons to put generated
files back under git control that can be done before the branch gets
merged.

Please note that generated files are still included in dist tarballs so
that "ordinary" users will not need any of the autotools.

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

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Johannes Meixner
Hi Johannes,

Johannes Meixner writes:

> Hello,
>
> On Oct 21 21:32 Olaf Meeuwissen wrote (excerpt):
>> Alessandro Zummo writes:
>>>  There's probably still some bug in the usb code. I have
>>>  intermittent results with some scanners on usb2
>>>  and with others on usb3. switching among the two usb
>>>  standards solves them all.
>>
>> I'm curious about USB related issues that other backends
>> are facing that might be solved by switching to libusb-1
>> as the default.
>
> At openSUSE we use libusb-1 since openSUSE 12.2
> (i.e. we use libusb-1 since about April 2012)
> via "configure --enable-libusb_1_0".
> I am not aware of issues because of this.

Thanks for the info.  So at least changing to libusb-1 is unlikely to
cause any trouble.

My original question however, was if doing so would fix any outstanding
libusb-0 issues that we may have.  I could go through the open tickets
but if someone knows of any off the top of their head ...

# The Alioth tracker's advanced query functionality still has me
# completely mistified.

> Regarding USB 3, see
> https://bugzilla.opensuse.org/show_bug.cgi?id=856794
>
> Summary:
> It seems one needs a very current kernel for USB 3.
> For me kernel 4.1.6 did not work with sane-backends-1.0.25.
> For me kernel-vanilla-4.3.rc5 works where it seems
> the xhci USB driver is now at least somewhat fixed.
> But I needed additionally the workarounds for
> the broken xhci driver in sane-backends-1.0.25
> i.e. sane-backends-1.0.24 did not work for me
> with kernel-vanilla-4.3.rc5, see
> https://bugzilla.opensuse.org/show_bug.cgi?id=856794#c28

USB 3 is known to be a bit of a "rough ride" and nobody seems to know
what the secret mix is to get things to work.

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

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Alessandro Zummo
Sorry for the late follow-up.

Alessandro Zummo writes:

> On Wed, 21 Oct 2015 21:32:37 +0900
> Olaf Meeuwissen <[hidden email]> wrote:
> [...]
>> API change.  Given the schedule for 1.0.26, I don't think that is doable
>> within that time frame.  If we are going to change the API, there are
>> probably a *lot* of things we should work out before we can commit to
>
>  luckily we have only a few frontends to check for and most of
>  them will correctly bail out when given an unknown frame type.

I'm not thinking about just adding a frame type.  There are a number of
things that can be improved (progress indication, batch scanning among
others).  If we are to make changes, we may as well address those too.
And when we do, there will be soversion bump so there will be nothing
that needs to be checked for current frontends.

>  given that there are a very few users that would try it I do not
>  think we will be receiving a lot of reports of bad frontends.
>
>  once xsane, scanimage, gimp and a few others have been verified
>  to work we'd have covered the vast majority
>
>> anything.  One of those things would be a clearly documented mechanism
>> for API changes so that backends *and* frontends can deal with them in a
>> graceful and sane manner (pun intended) and changes can be made in a

This is meant to allow for more gradual API changes without needing a
soversion bump, in case that was not clear.  Note though that I am not
sure that this is even possible but it is something to think about.

>  I haven't checked but I think that it's written somewhere that a frontend
>  should correctly behave when given an unknown frame type.

I cannot find anything.  I checked the sane_get_parameters() spec and
the Image Data Format sections.

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


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Alessandro Zummo
On Wed, 28 Oct 2015 18:01:25 +0900
Olaf Meeuwissen <[hidden email]> wrote:

> I'm not thinking about just adding a frame type.  There are a number of
> things that can be improved (progress indication, batch scanning among
> others).  If we are to make changes, we may as well address those too.
> And when we do, there will be soversion bump so there will be nothing
> that needs to be checked for current frontends.

 I'd agree on the principle, but doing this way it will
 take more time and we'll end up with two versions of sane
 to handle, since you can't just drop the old one.

--

 Best regards,

 Alessandro Zummo - CEO,
  Tower Technologies - Torino, Italy

  http://www.towertech.it


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Johannes Meixner
Sorry for the belated response.

Johannes Meixner writes:

> Hello Olaf,
>
> first and foremost many thanks for all your
> "SANE Project Janitor" work.
>
> On Oct 19 22:20 Olaf Meeuwissen wrote (excerpt):
>>> ... unofficial ... goals for sane-backends-1.0.26.
>> Feedback and suggestions are welcome.
>
>
> Suggestion for an additional goal for sane-backends-1.0.26:
>
> - drop support for parallel port scanners

Low priority for 1.0.26 at best.  But your suggestion made me think of
something more important:

 - integrate distribution patches

I've updated the milestone[1] to reflect this.

 [1] https://gitlab.com/sane-project/backends/milestones/1

> My plan is to do this for sane-backends-1.0.25 for openSUSE Tumbleweed
> [...]

I'd like to hear about your experiences.

> RFC for an additional goal for sane-backends-1.0.26:
>
> - switch to group "lp" instead of "scanner"
>
> Currently SANE upstream creates udev rules with
> MODE="0664", GROUP="scanner".
>
> Hereby I ask for comments whether or not SANE upstream
> should switch to group "lp" instead of "scanner".

I think it best to leave this to the individual distributions to decide.
What can be done fairly easily, however, is to make it easier for them
to override/customize the DEVMODE, DEVOWNER and DEVGROUP values in
tools/sane-desc.c.

> [...]
> It is sufficiently secure and reasonable easy to use by default
> the same group "lp" for printers and scanners because both kind
> of devices usually require physical user access (to get the
> printed paper or to place a paper on the scanner) so that both
> kind of devices should usually require the same kind of security
> and for multifunction devices only one group can be set and
> then the "lp" group is the more reasonable default setting.

Security is not the only issue at stake here.  Use of consumables
(i.e. paper and ink/toner) is another that may need to be more strictly
controlled for printers than scanners.

> I do not know how read/write access for USB scanners is done
> in other Linux distributions.

FYI, Debian has

  ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

in its udev rules file.

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


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Johannes Meixner

Hello

On Oct 28 20:18 Olaf Meeuwissen wrote (excerpt):
> Johannes Meixner writes:
...
>> Suggestion for an additional goal for sane-backends-1.0.26:
>>
>> - drop support for parallel port scanners
>
> Low priority for 1.0.26 at best.

Also for me this is low priority because I have zero
issue reports regarding parallel port scanners.

I will report my experience when I have droped support
for parallel port scanners in openSUSE Tumbleweed.


> But your suggestion made me think of
> something more important:
>
> - integrate distribution patches

The openSUSE patches are public available via the
openSUSE Build Service (OBS) development project "graphics"
therein the source package "sane-backends" at
https://build.opensuse.org/package/show/graphics/sane-backends

Currently the only patch which is of interest for
SANE upstream is dell1600n_net-fix-strncat.patch
which is already fixed at SANE upstream
https://alioth.debian.org/tracker/index.php?func=detail&aid=315198&group_id=30186&atid=410366

All others are only for SUSE-specific needs.


>> RFC for an additional goal for sane-backends-1.0.26:
>>
>> - switch to group "lp" instead of "scanner"
...
> I think it best to leave this to the individual distributions to decide.

My hope is that the individual distributions might even be able
to agree on a common default so that all Linux users could have
the same default base of operations.

> What can be done fairly easily, however, is to make it easier for them
> to override/customize the DEVMODE, DEVOWNER and DEVGROUP values in
> tools/sane-desc.c.

Perhaps a configure option to specify that would be nice?

> FYI, Debian has
>
>  ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

I like to understand the reson behind why Debian uses
the "scanner" group.

Is it that for Debian use of consumables (paper and ink/toner)
in a printer is more strictly controlled than scanners?

Regardless what the reason is, I also like to understand how
Debian deals with multifunction devices because - as far as
I understand it - there is the conflict that multifunction devices
would have to belong both to the "lp" and the "scanner" group.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

stef-22
In reply to this post by Olaf Meeuwissen-4
On 28/10/2015 12:18, Olaf Meeuwissen wrote:

> Sorry for the belated response.
>
> Johannes Meixner writes:
>
>> Hello Olaf,
>>
>> first and foremost many thanks for all your
>> "SANE Project Janitor" work.
>>
>> On Oct 19 22:20 Olaf Meeuwissen wrote (excerpt):
>>>> ... unofficial ... goals for sane-backends-1.0.26.
>>> Feedback and suggestions are welcome.
>>
>> Suggestion for an additional goal for sane-backends-1.0.26:
>>
>> - drop support for parallel port scanners
     Hello,

     rather than dropping support for working hardware (and which
doesn't require any work), I'd prefer an option to optionally compile
them in (or out). That would give the package builder the final choice
and keep support for them for those who still use them (still got 2 of
them).

Regards,
     Stef


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Johannes Meixner

Hello,

On Oct 29 20:13 Stef wrote (excerpt):
>>> - drop support for parallel port scanners
>
> rather than dropping support for working hardware
> (and which doesn't require any work), I'd prefer
> an option to optionally compile them in (or out).
> That would give the package builder the final choice
> and keep support for them for those who still use
> them (still got 2 of them).

See what I had written here:
--------------------------------------------------------------
Date: Wed, 21 Oct 2015 13:43:17 +0200 (CEST)
...
Subject: Re: [sane-devel] 1.0.25 is out, now what?
.
.
.
My current plan how to drop it is to keep the backends
for parallel port scanners but to only remove the
entries for parallel port scanners from the description
files which results that the YaST scanner setup no longer
shows parallel port scanners. This way I could get end-user
feedback if parallel port scanners are still of any interest
and if yes, I could tell the user how to enable the matching
backend manually without the need to install a different
sane-backends package to get a parallel port scanner working.
--------------------------------------------------------------

I.e. I have no plans to remove the actual backends
(driver libraries) all of a sudden.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Michael Shigorin-2
In reply to this post by Johannes Meixner
On Wed, Oct 28, 2015 at 01:57:12PM +0100, Johannes Meixner wrote:
> I will report my experience when I have droped support
> for parallel port scanners in openSUSE Tumbleweed.

Folks have been boasting old hardware (and _specifically_
scanner) support as a distinct advantage over Windows, FWIW.

I'd estimate a feedback window of a distro release cycle
or even more for this kind of queries...

--
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by Johannes Meixner
Hi Johannes,

Johannes Meixner writes (among other things):

> On Oct 28 20:18 Olaf Meeuwissen wrote (excerpt):
>> Johannes Meixner writes:
> ...
>>> RFC for an additional goal for sane-backends-1.0.26:
>>>
>>> - switch to group "lp" instead of "scanner"
> ...
>> I think it best to leave this to the individual distributions to decide.
>
> My hope is that the individual distributions might even be able
> to agree on a common default so that all Linux users could have
> the same default base of operations.
>
>> What can be done fairly easily, however, is to make it easier for them
>> to override/customize the DEVMODE, DEVOWNER and DEVGROUP values in
>> tools/sane-desc.c.
>
> Perhaps a configure option to specify that would be nice?

And/or command-line options that can be used to specify them (with
build-time defaults provided via configure options).  That way you can
change your mind after configuring without having to reconfigure.  You
simply rerun the tool.

>> FYI, Debian has
>>
>>  ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
>
> I like to understand the reson behind why Debian uses
> the "scanner" group.

No clue.  You'll have to ask the Debian maintainer.

> Is it that for Debian use of consumables (paper and ink/toner)
> in a printer is more strictly controlled than scanners?

I just mentioned that as an example use case that I could think of.  Not
because Debian actually tries to do something like that.  It would local
policy (company/institute, department, etc.) stuff at best.

> Regardless what the reason is, I also like to understand how
> Debian deals with multifunction devices because - as far as
> I understand it - there is the conflict that multifunction devices
> would have to belong both to the "lp" and the "scanner" group.

It's been a while and my memory is not quite up to snuff but from what I
understand the setfacl invocation *adds* a scanner group with read/write
permissions to the device access control list (if there wasn't one).  If
there is one already, only the groups permissions are set.

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


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 1.0.25 is out, now what?

Olaf Meeuwissen-4
In reply to this post by stef-22
Hi Stef,

Stef writes:

> On 28/10/2015 12:18, Olaf Meeuwissen wrote:
>> Sorry for the belated response.
>>
>> Johannes Meixner writes:
>>
>>> Hello Olaf,
>>>
>>> first and foremost many thanks for all your
>>> "SANE Project Janitor" work.
>>>
>>> On Oct 19 22:20 Olaf Meeuwissen wrote (excerpt):
>>>>> ... unofficial ... goals for sane-backends-1.0.26.
>>>> Feedback and suggestions are welcome.
>>>
>>> Suggestion for an additional goal for sane-backends-1.0.26:
>>>
>>> - drop support for parallel port scanners
>      Hello,
>
>      rather than dropping support for working hardware (and which
> doesn't require any work), I'd prefer an option to optionally compile
> them in (or out). That would give the package builder the final choice
> and keep support for them for those who still use them (still got 2 of
> them).

I've updated my milestone[1] to reflect this.

 [1] https://gitlab.com/sane-project/backends/milestones/1

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


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Loading...