Discussion:
sane-backends release 1.0.26 schedule
(too old to reply)
m. allan noah
2017-04-28 12:04:55 UTC
Permalink
Raw Message
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

Any questions or concerns, let me know.

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-***@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-***@lists.alioth.debian.org
Yuri Chornoivan
2017-04-28 14:20:37 UTC
Permalink
Raw Message
Post by m. allan noah
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.
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
Any questions or concerns, let me know.
allan
Hi,

When is it possible/right to send translation updates?

Thanks in advance for your answer.

Best regards,
Yuri
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-request@
m. allan noah
2017-04-28 15:10:55 UTC
Permalink
Raw Message
You can send translations at any time, up to the day of the release.

allan
Post by Yuri Chornoivan
Post by m. allan noah
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.
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
Any questions or concerns, let me know.
allan
Hi,
When is it possible/right to send translation updates?
Thanks in advance for your answer.
Best regards,
Yuri
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
Olaf Meeuwissen
2017-04-30 11:35:04 UTC
Permalink
Raw Message
Hi Allan,
Post by m. allan noah
Ok folks, it's time to get another sane-backends release out the door.
I was about to ping you on that ;-)
Post by m. allan noah
Olaf has done a good job of cleaning up our contributors list and
curating the bug tracker.
I don't think I did a good job (yet?) with the bug tracker but, hey, if
you think I did, I'll take the kudos ;-)

# Me no like the Alioth bug tracker ... at all. It feels so antiquated
# now I've been using GitLab and GitHub for a year or two ...
Post by m. allan noah
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 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.
Post by m. allan noah
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.
May 7: Feature freeze (only fix bugs and update docs after this date)
I have the whole week off until May 7 (Golden Week here in Japan). I
was thinking of doing some other hacking but I'll go over the mailing
list for unapplied but appliable patches as well as patches in the bug
tracker. I won't be doing anything May 2/3, though.
Post by m. allan noah
May 14: Code freeze (only update docs after this date)
May 21: Release
Any questions or concerns, let me know.
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.

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

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-06 06:32:47 UTC
Permalink
Raw Message
Hi again,
Post by Olaf Meeuwissen
Hi Allan,
Post by m. allan noah
Ok folks, it's time to get another sane-backends release out the door.
[snip]
Post by m. allan noah
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?
Post by Olaf Meeuwissen
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.
Post by Olaf Meeuwissen
[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.
Post by Olaf Meeuwissen
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Rolf Bensch
2017-05-06 08:55:27 UTC
Permalink
Raw Message
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
Post by Olaf Meeuwissen
Hi again,
Post by Olaf Meeuwissen
Hi Allan,
Post by m. allan noah
Ok folks, it's time to get another sane-backends release out the door.
[snip]
Post by m. allan noah
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?
Post by Olaf Meeuwissen
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.
Post by Olaf Meeuwissen
[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.
Post by Olaf Meeuwissen
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-06 12:00:55 UTC
Permalink
Raw Message
Hi Rolf,
Post by 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 .
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.
Post by Rolf Bensch
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
Rolf Bensch
2017-05-07 11:15:39 UTC
Permalink
Raw Message
Hi,

@Olaf: Thanks for your patch. It's working with the ppa.

Please have a look at the attached patches. Maybe there are additional
fixes for SANE (fix_avahi_error_paths.patch) or there are needful
additional options for configure possible or just keep them inside the ppa?

Many thanks for your help.

Cheers,
Rolf
Post by Olaf Meeuwissen
Hi Rolf,
Post by 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 .
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.
Post by Rolf Bensch
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
Rolf Bensch
2017-05-08 10:05:16 UTC
Permalink
Raw Message
Hello All,

My Ubuntu ppa (ppa:rolfbensch/sane-git
<https://launchpad.net/%7Erolfbensch/+archive/ubuntu/sane-git>) is
working again. It distributes pre-built packages for all supported
Ubuntu distributions (amd64, i386 and armhf architectures).

I changed the package names to fit the packages version convention a
little bit more. I hope that this helps to change the package names
provided from Ubuntu.

If you are already using my ppa, you must use the "Force Version"
function of your package manager once to get the updates.

Please report if you may have any problems.

Hope this helps.

Cheers,
Rolf
Post by Rolf Bensch
Hi,
@Olaf: Thanks for your patch. It's working with the ppa.
Please have a look at the attached patches. Maybe there are additional
fixes for SANE (fix_avahi_error_paths.patch) or there are needful
additional options for configure possible or just keep them inside the ppa?
Many thanks for your help.
Cheers,
Rolf
Post by Olaf Meeuwissen
Hi Rolf,
Post by 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 .
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.
Post by Rolf Bensch
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
Olaf Meeuwissen
2017-05-10 11:54:42 UTC
Permalink
Raw Message
Hi Rolf,
Post by Rolf Bensch
@Olaf: Thanks for your patch. It's working with the ppa.
Good!
Post by Rolf Bensch
Please have a look at the attached patches. Maybe there are additional
fixes for SANE (fix_avahi_error_paths.patch) or there are needful
additional options for configure possible or just keep them inside the ppa?
I will take a look at the patches, maybe this weekend, but unless they
fix bugs on the sane-backends side, they'll have to wait until after the
release.

If other binary package maintainers are listening, I welcome patches in
the Alioth bug tracker (even though I rather dislike that bug tracker
itself ;-). Feel free to add any that haven't been submitted yet,
assign them to me and, please!, prefix a [PATCH] to the summary line so
I can quickly find them.
Post by Rolf Bensch
Many thanks for your help.
You're welcome.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-13 03:57:51 UTC
Permalink
Raw Message
Hi again,
Post by Olaf Meeuwissen
Hi Rolf,
Post by Rolf Bensch
Please have a look at the attached patches. Maybe there are additional
fixes for SANE (fix_avahi_error_paths.patch) or there are needful
additional options for configure possible or just keep them inside the ppa?
I will take a look at the patches, maybe this weekend, but unless they
fix bugs on the sane-backends side, they'll have to wait until after the
release.
- disable_rpath.patch -> no longer needed

The SANE_LINKER_RPATH macro was unsued and removed in f80cf1db,
derived files were synced in d853463e.

- fix_avahi_error_paths.patch -> applied

- dll_backend_conf.patch -> applied w/ modifications

The pint backend remains enabled.

- frontend_libs.patch -> applied change to Makefile.am

The Makefile.in file will be updated later. The LIBS variable
should be empty at build time, i.e. in the Makefile.

- libsane_deps.patch -> investigate post-release

I don't have the time right now to check the details of the impact
of this for the various build scenarios we support.

- multiarch_manpages_libdir.patch -> won't apply

This doesn't take --libdir/--prefix configure time options into
account.

- sane-config_and_pkg-config_fixes.patch -> investigate post-release

See my comment for libsane_deps.patch.

And here's a little reminder for those who missed the first post
Post by Olaf Meeuwissen
If other binary package maintainers are listening, I welcome patches in
the Alioth bug tracker (even though I rather dislike that bug tracker
itself ;-). Feel free to add any that haven't been submitted yet,
assign them to me and, please!, prefix a [PATCH] to the summary line so
I can quickly find them.
If you submit patches, please submit *one* patch per bug tracker item.
I know that's a pain but it will make dealing with them easier to track.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-13 09:15:09 UTC
Permalink
Raw Message
Hi Jörg,
Post by Olaf Meeuwissen
Hi again,
Post by Olaf Meeuwissen
Hi Rolf,
Post by Rolf Bensch
Please have a look at the attached patches. Maybe there are additional
fixes for SANE (fix_avahi_error_paths.patch) or there are needful
additional options for configure possible or just keep them inside the ppa?
Inspired by this nudge from Rolf Bensch to have a look at the same for
his PPA, I went through the Debian debian/patches for sane-backends.

These have been applied upstream:

0015-frontend_libs.patch
0100-source_spelling.patch
0105-hp3900.patch
0110-dll_backend_conf.patch
0120-typo.patch
0605-man_typo.patch
0500-CVE-2017-6318.patch (was cherry-picked from upstream)

Maybe not exactly but at least in spirit.

This will be taken care of by the next autotools sync:

0030-ppc64el.patch

These are candidates for after the upcoming sane-backends release:

0005-libsane_deps.patch
0035-trim-libraries-in-sane-backends.pc.in.patch
0700-mk_reproducible_results.patch
0705-kfreebsd.patch
0135-saned-remotescanners.patch

These will not be upstreamed:

0010-unneeded_doc.patch
0020-nousbtest.patch
0025-multiarch_manpages_libdir.patch
0115-license_typo.patch
0600-scanimage_manpage.patch
0710-sane-desc.c_debian_mods.patch
0125-multiarch_dll_search_path.patch

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Louis Lagendijk
2017-05-06 09:52:24 UTC
Permalink
Raw Message
Post by m. allan noah
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.
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&group_id=30
186&aid=315004&atid=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-***@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-***@lists.alioth.debian.org
m. allan noah
2017-05-06 12:27:25 UTC
Permalink
Raw Message
Post by Louis Lagendijk
Post by m. allan noah
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.
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&group_id=30
186&aid=315004&atid=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.
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-***@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-***@lists.alioth.debian.org
Wilhelm
2017-05-06 13:55:50 UTC
Permalink
Raw Message
Post by m. allan noah
Post by Louis Lagendijk
Post by m. allan noah
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.
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&group_id=30
186&aid=315004&atid=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.
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 <file> option

I would prefer 1)

Thanks for investigating on this ;.)

--
Wilhelm
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Louis Lagendijk
2017-05-06 18:13:22 UTC
Permalink
Raw Message
Post by Wilhelm
Post by m. allan noah
Post by Louis Lagendijk
Post by m. allan noah
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.
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&group
_id=30
186&aid=315004&atid=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.
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 :)
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 <file> 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-***@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-***@lists.alioth.debian.org
m. allan noah
2017-05-06 23:43:46 UTC
Permalink
Raw Message
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
Post by Louis Lagendijk
Post by Wilhelm
Post by m. allan noah
Post by Louis Lagendijk
Post by m. allan noah
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.
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&group
_id=30
186&aid=315004&atid=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.
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 :)
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 <file> 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.
#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)
- 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
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-06 22:34:26 UTC
Permalink
Raw Message
Hi all,
Post by Louis Lagendijk
Post by Wilhelm
Post by m. allan noah
Post by Louis Lagendijk
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&group_id=30186&aid=315004&atid=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.
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 :)
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 <file> 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?
Post by Louis Lagendijk
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.
Post by Louis Lagendijk
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 #.
Post by Louis Lagendijk
#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 (cough), the init script or scanbd to make sure the pidfile is
removed, even in the case scanbd crashes.

BTW, this could be simplified if scanbd creates that dll2.conf file as
/var/run/sane/scanbd.conf at startup (and removes it on exit) and the
dll backend modified to prefer that file unless explicitly told to
ignore it (by scanbd via an environment variable). When ignoring, the
regular conffile handling kicks in and dll.conf is searched for in all
the directories given in SANE_CONFIG_DIR if defined. If SANE_CONFIG_DIR
ends with a path separator, : on Unix, $PWD and $sysconfdir are searched
as well. If SANE_CONFIG_DIR is not defined, the search looks in $PWD
first and $sysconfdir next.

# BTW, I just noticed that the use of $PWD is open to abuse by frontends
# that call chdir() before sane_init() and backends that chdir() before
# searching for their conffile.
Post by Louis Lagendijk
The default dll.conf remains unchanged, but net should be commented out
Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf)
In my /var/run/sane/scanbd.conf scenario, this is where scanbd needs to
signal the dll backend to ignore that file.
Post by Louis Lagendijk
- comment net from dll.conf if not already done
- populate net.conf with localhost
That's still food for post-installation and pre-removal scripts. The
idea being that you want to use scanbd if you install it.

BTW, you want to add localhost to net.conf. There may be other hosts
configured already.
Post by Louis Lagendijk
I changed the name of the alternative config file to dll-override.conf
(but remain open for better alternatives).
I think that /var/run/sane/scanbd.conf is pretty self-explanatory. You
could also go for /etc/sane.d/scanbd.conf but that might be just a tad
confusing as there is a /etc/scanbd/scanbd.conf as well.
Post by Louis Lagendijk
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?
See above ;-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Louis Lagendijk
2017-05-08 21:33:41 UTC
Permalink
Raw Message
Post by Olaf Meeuwissen
Hi all,
Post by Louis Lagendijk
Post by Wilhelm
et>
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 <file> 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?
A terribly confusing typo: I meant sane (or libsane that by default
runs dll.c. Libsane does not have the possibility to pass any arguments
to it. So saned could not pass the argment to libsane (or dll.c for
that matter). Or it would have to use a environment variable anyway.
that is what I tried to convey.
Post by Olaf Meeuwissen
Post by Louis Lagendijk
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.
That would not solve the dll.d issue though, sigh (see below for more
details).
Post by Olaf Meeuwissen
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.
This would not work for dll.c updates on rpm based systems at least:
new versions of config files will be stored as dll.conf.rpmnew. So at
least on rpm based systems not touching dll.conf is desirable. A
restore of the dll.conf from a scanbd removal can not restore the
dll.conf to the latest dll.conf.

Hence my preference to make an dll-override (see below for an
alternative solution) and leave dll.conf alone (and only load the
backends mentioned in that alternative dll.conf file and ignore dll.d
if an override is specified. I am still unhappy about the inconsistent
behaviour in that case though).
I only wish that dll.d was only loaded from a directive in dll.conf. 
Dll.d is a nasty problem. Any better suggestions for that?
Post by Olaf Meeuwissen
 - 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
Copying dll.conf + symlinking the rest should be ok. I am happy with
this part of the solution.

Modifying sane config files I am not sure about. I seem to recall that
modifying other packages config files is not allowed or at least
frowned upon for fedora. So this would still be a manual action for the
user.

Postinstall for scanbd could do the copying/linking as you propose.
This solves the scanbd side of things. The problem is on the sane
(default) side as we have dll.d to deal with.
Post by Olaf Meeuwissen
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.
Again, I need to check the rules.
Post by Olaf Meeuwissen
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.
I am not too worried about that part.
Post by Olaf Meeuwissen
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.
I fully agree on not including this now. I started my initial mail
stating that I realized that I was very late taking this on. I said in
the report on Alioth that it could take a long time and most likely
would miss 1.0.26.

If the scanbd package drops a dll2.conf file in
Post by Olaf Meeuwissen
Post by Louis Lagendijk
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 #.
pidfile does not work anyhow, when scanbd is started from systemd it
will not have a pid-file. I should have known as I wrote the systemd
units for scanbd. I need to find a better start for directives, but I
selected # as it is now that start of a comment and could not interfere
with any backend names (although the all start with [a-z] for now.
Using # as start for any directive made sure that I would not create
new problems. But I am open for any suggestion. I consider what I have
now more as a proof of concept, so we can change whatever we need.
Post by Olaf Meeuwissen
Post by Louis Lagendijk
#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 (cough), the init script or scanbd to make sure the pidfile is
removed, even in the case scanbd crashes.
Yeah systemd or an init script could create another file and remove it.
But that still leaves the possibility that scanbd would crash or hang
without the init system knowing about it.
Post by Olaf Meeuwissen
BTW, this could be simplified if scanbd creates that dll2.conf file as
/var/run/sane/scanbd.conf at startup (and removes it on exit) and the
dll backend modified to prefer that file unless explicitly told to
ignore it (by scanbd via an environment variable).  When ignoring,
the
Why not create a /var/lib/sane.d where scanbd or any other program can
place a dll.conf at start and remobve it at exit?
Post by Olaf Meeuwissen
regular conffile handling kicks in and dll.conf is searched for in all
the directories given in SANE_CONFIG_DIR if defined.  If
SANE_CONFIG_DIR
ends with a path separator, : on Unix, $PWD and $sysconfdir are searched
as well.  If SANE_CONFIG_DIR is not defined, the search looks in $PWD
first and $sysconfdir next.
Let's just add /var/lib/sane.d in the search path?
Post by Olaf Meeuwissen
# BTW, I just noticed that the use of $PWD is open to abuse by
frontends
# that call chdir() before sane_init() and backends that chdir() before
# searching for their conffile.
Should we not completely remove $PWD on Unix then? It seems to be a
security liability anyhow (just imagine what happens if something just
places a config file in the directory where the user running a program?
Adding ~/.config/sane.d to the search path might be a better solution
for the user that wants an own configuration.
Post by Olaf Meeuwissen
Post by Louis Lagendijk
The default dll.conf remains unchanged, but net should be commented out
But we then should ignore dll.d
Post by Olaf Meeuwissen
Post by Louis Lagendijk
Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf)
In my /var/run/sane/scanbd.conf scenario, this is where scanbd needs to
signal the dll backend to ignore that file.
Post by Louis Lagendijk
- comment net from dll.conf if not already done
- populate net.conf with localhost
That's still food for post-installation and pre-removal scripts.  The
idea being that you want to use scanbd if you install it.
BTW, you want to add localhost to net.conf.  There may be other hosts
configured already.
Post by Louis Lagendijk
I changed the name of the alternative config file to dll-
override.conf
(but remain open for better alternatives).
I think that /var/run/sane/scanbd.conf is pretty self-
explanatory.  You
could also go for /etc/sane.d/scanbd.conf but that might be just a tad
confusing as there is a /etc/scanbd/scanbd.conf as well.
See above: /var/lib/sane.d /dll.conf for overrides may be a small
burden for scanbd and is open for other users. And it removes a lot of
the burden for sane. when scanbd starts it just creates that dll.conf
file and we are done.

Thanks for the fruitdull discussion guys!
Cheers, Louis
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-17 11:19:27 UTC
Permalink
Raw Message
Hi Louis,

Sorry for the delay in replying.
I managed to fat-finger your mail into the trash :-(
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Hi all,
Post by Louis Lagendijk
Post by Wilhelm
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 <file> 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?
A terribly confusing typo: I meant sane (or libsane that by default
runs dll.c. Libsane does not have the possibility to pass any arguments
to it. So saned could not pass the argment to libsane (or dll.c for
that matter).Or it would have to use a environment variable anyway.
that is what I tried to convey.
Okay, now I understand. You're right, frontends have no way to pass any
arguments to the *backend* other than via environment variables. I have
run into this myself (at the office) when writing the (third-party, C++)
utsushi backend. While you can configure a SANE_Handle anyway you like,
using sane_control_option(), there is no SANE API to dynamically
configure a SANE *backend*.

# Hmm, maybe something for a next version of the SANE API? Talking
# about which, scan button support should be included too!
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Post by Louis Lagendijk
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.
That would not solve the dll.d issue though, sigh (see below for more
details).
Post by Olaf Meeuwissen
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.
new versions of config files will be stored as dll.conf.rpmnew. So at
least on rpm based systems not touching dll.conf is desirable. A
restore of the dll.conf from a scanbd removal can not restore the
dll.conf to the latest dll.conf.
Hmm, that sounds more like a problem with rpm to me. Everything under
/etc is sysadmin territory. If a sysadmin makes changes, these should
not be clobbered. Putting the new file in *.rpmnew takes care of that
all right but is there no way to notify the person doing the upgrade?

Debian based systems ask what you want to do when it detects a changed
conffile. Of course, this kind of interaction may not be desirable when
things have to be done non-interactively but I believe that's supported
too (by doing things the RPM way).

# It's not supported yet(?), but it'd be great if this supported merging
# of changes by the chunk!
Post by Louis Lagendijk
Hence my preference to make an dll-override (see below for an
alternative solution) and leave dll.conf alone (and only load the
backends mentioned in that alternative dll.conf file and ignore dll.d
if an override is specified. I am still unhappy about the inconsistent
behaviour in that case though).
I don't really understand why you need to ignore dll.d when using this
alternative dll.conf. What's wrong with enabling third party backends?
Post by Louis Lagendijk
I only wish that dll.d was only loaded from a directive in dll.conf.
Dll.d is a nasty problem. Any better suggestions for that?
The dll.d support is a very convenient mechanism for third-party SANE
backends. Think about how you'd handle the dll.conf editing for those.
Imagine if every single backend in sane-backends came in it own binary
package, as if it were third-party. How would you manage dll.conf?

If a sysadmin installs a backend, I'd assume the purpose is that it'd
get used by SANE frontends. Dropping a one-liner file in dll.d is all
that is needed to activate the backend.

So even if you have scanbd installed, you'd want to be able to use any
third-party backends, no?
Post by Louis Lagendijk
Post by Olaf Meeuwissen
- 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
Copying dll.conf + symlinking the rest should be ok. I am happy with
this part of the solution.
Good.
Post by Louis Lagendijk
Modifying sane config files I am not sure about. I seem to recall that
modifying other packages config files is not allowed or at least
frowned upon for fedora. So this would still be a manual action for
the user.
While I agree that modifying conffiles automatically is to be frowned
upon in the general case, the modifying that I suggested has no effect
on the *observable* behaviour of SANE frontends (as long as scanbd does
not crash and burn).
Post by Louis Lagendijk
Postinstall for scanbd could do the copying/linking as you propose.
This solves the scanbd side of things. The problem is on the sane
(default) side as we have dll.d to deal with.
Post by Olaf Meeuwissen
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.
Again, I need to check the rules.
Post by Olaf Meeuwissen
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.
I am not too worried about that part.
Me neither (just have a look at /etc/rc?.d ;-) but I thought I'd point
it out for the aesthetically inclined among us.
Post by Louis Lagendijk
Post by Olaf Meeuwissen
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.
I fully agree on not including this now. I started my initial mail
stating that I realized that I was very late taking this on. I said in
the report on Alioth that it could take a long time and most likely
would miss 1.0.26.
If the scanbd package drops a dll2.conf file in
Post by Olaf Meeuwissen
Post by Louis Lagendijk
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 #.
pidfile does not work anyhow, when scanbd is started from systemd it
will not have a pid-file. I should have known as I wrote the systemd
units for scanbd.
# Glad I'm on Devuan these days, where this is not an issue (together
# with another pile of, eh, "pötterware" issues).
Post by Louis Lagendijk
I need to find a better start for directives, but I
selected # as it is now that start of a comment and could not interfere
with any backend names (although the all start with [a-z] for now.
Using # as start for any directive made sure that I would not create
new problems. But I am open for any suggestion. I consider what I have
now more as a proof of concept, so we can change whatever we need.
Quite a few, if not all, SANE backends treat # in their config as a
comment. Our .desc files treat ; as a comment too (as does Lisp). So
those are out and we want something that's not valid in a C identifier.
At the same time we want to convey that the presence of said PID file
indicates that the dll-override.conf file takes effect. It also has to
be simple to implement, right? Also assuming that *only* scanbd needs
special casing for now, something like

%if pidfile=/var/run/scanbd.pid
net
%else
# the regular dll.conf content
%endif

where the conditional would be equivalent to

sh test -e /var/run/scanbd.pid

could be included in sane-backends (with suitable changes to dll.c *and*
scanbd signalling when to skip this test, of course).

# The % is a LaTeX comment, btw. Feel free to use something else.
# LaTeX uses \ to start commands but seeing that's an escape in C and
# most other places ... maybe not a good idea.
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Post by Louis Lagendijk
#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 (cough), the init script or scanbd to make sure the pidfile is
removed, even in the case scanbd crashes.
Yeah systemd or an init script could create another file and remove it.
But that still leaves the possibility that scanbd would crash or hang
without the init system knowing about it.
Post by Olaf Meeuwissen
BTW, this could be simplified if scanbd creates that dll2.conf file as
/var/run/sane/scanbd.conf at startup (and removes it on exit) and the
dll backend modified to prefer that file unless explicitly told to
ignore it (by scanbd via an environment variable). When ignoring, the
Why not create a /var/lib/sane.d where scanbd or any other program can
place a dll.conf at start and remove it at exit?
What if two (or more such) programs need files with different content?
You don't want all of them to create their own dll.conf and clobber
what's there already, right? Or remove the file created by a process
that started *after* the process that's exiting now.

# Are there any other programs right now that need this? If not,
# dll.conf or any other name is fine, for now.

BTW, /var/run/ is a better location if those files are only supposed to
be around when a program is running. It's for stuff that isn't supposed
or expected to survive a reboot. Things in /var/lib/ are supposed and
expected survive a reboot.

Actually, this /var/whatever/ approach only works for programs of which
there will only be a single instance (think daemons) at any time. If
there is a remote possibility of running the same program twice or more
at the same time, you need a different solution. If these programs can
use the same file, maybe a static config file in /etc/$program/ would be
more appropriate.
Post by Louis Lagendijk
Post by Olaf Meeuwissen
regular conffile handling kicks in and dll.conf is searched for in all
the directories given in SANE_CONFIG_DIR if defined. If SANE_CONFIG_DIR
ends with a path separator, : on Unix, $PWD and $sysconfdir are searched
as well.If SANE_CONFIG_DIR is not defined, the search looks in $PWD
first and $sysconfdir next.
Let's just add /var/lib/sane.d in the search path?
Eh, /var/run/sane.d please.

# Coming back to other programs also using this, how would the dll
# backend know which of the files in this directory to prefer?
Post by Louis Lagendijk
Post by Olaf Meeuwissen
# BTW, I just noticed that the use of $PWD is open to abuse by frontends
# that call chdir() before sane_init() and backends that chdir() before
# searching for their conffile.
Should we not completely remove $PWD on Unix then?
+1

Fortunately this is *not* in the SANE API spec (so could be changed
rather easily) but it will be *breaking* behaviour that people may have
been relying on for just a bit short of about two decades :-(
Post by Louis Lagendijk
It seems to be a security liability anyhow (just imagine what happens
if something just places a config file in the directory where the user
running a program?
Calling chdir() to a location with a known "bad" file is easier ;-)
Post by Louis Lagendijk
Adding ~/.config/sane.d to the search path might be a better solution
for the user that wants an own configuration.
Something below $HOME would seem right. IIRC, XSane puts stuff under
~/.sane. The XDG guidelines[1] (hmm, more pötter stuff) would rather
have this some place under $XDG_CONFIG_HOME, with a default of
$HOME/.config/. I'd vote for $HOME/.sane/ because of XSane precedent,
but we'd have to work out some naming conventions to accommodate the
needs of both frontends and backends (irrespective of the directory
location).

[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Post by Louis Lagendijk
The default dll.conf remains unchanged, but net should be commented out
But we then should ignore dll.d
Why do you want to ignore third-party backends when using scanbd?
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Post by Louis Lagendijk
Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf)
In my /var/run/sane/scanbd.conf scenario, this is where scanbd needs to
signal the dll backend to ignore that file.
Post by Louis Lagendijk
- comment net from dll.conf if not already done
- populate net.conf with localhost
That's still food for post-installation and pre-removal scripts.The
idea being that you want to use scanbd if you install it.
BTW, you want to add localhost to net.conf. There may be other hosts
configured already.
Post by Louis Lagendijk
I changed the name of the alternative config file to dll-override.conf
(but remain open for better alternatives).
I think that /var/run/sane/scanbd.conf is pretty self-explanatory. You
could also go for /etc/sane.d/scanbd.conf but that might be just a tad
confusing as there is a /etc/scanbd/scanbd.conf as well.
See above: /var/lib/sane.d /dll.conf for overrides may be a small
burden for scanbd and is open for other users. And it removes a lot of
the burden for sane. when scanbd starts it just creates that dll.conf
file and we are done.
Thanks for the fruitdull discussion guys!
I'd like to return the thanks. Not because I don't want them but
because you deserve some too! ;-)

The discussion has become a bit fragmented and hard to follow perhaps
but overall I feel there is something "deep" that is not addressed by
the SANE API standard's backend mechanism. Maybe we've come to a point
where we need to review whether the SANE API standard still covers the
needs of today's scanners and our user's use cases in a suitable way.
After all, your cell/smart phone of today has many times more computing
resources than a high-end desktop at the time the SANE API standard was
formulated.

# Heck, today's fridge beats a 20-year old desktop hands down now! And
# it *scans* its contents to let you know you're out of milk (or beer!)
# to boot! Here's wondering if it's using SANE under the covers ... ;-)

On the other hand, I do realise that many of you (and me) also want a
solution (or kludge) now rather than sometime in the future. Let's take
a step back and focus on something that works with the inventive kludge
that scanbd provides in the face of the shortcomings of the SANE API
standard.

Perhaps Wilhelm's SANE_CONFIG_FILE approach is the simplest solution for
the time being after all and perhaps we should simply leave the more
"elegant" solution(s) for an updated SANE API standard.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-06 12:20:25 UTC
Permalink
Raw Message
Hi Louis,
Post by Olaf Meeuwissen
Post by m. allan noah
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&group_id=30186&aid=315004&atid=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.
Post by Olaf Meeuwissen
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.
Post by Olaf Meeuwissen
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?
Post by Olaf Meeuwissen
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.
Post by Olaf Meeuwissen
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Louis Lagendijk
2017-05-06 15:43:10 UTC
Permalink
Raw Message
Post by Olaf Meeuwissen
Hi Louis,
Post by Olaf Meeuwissen
Post by m. allan noah
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&group_i
d=30186&aid=315004&atid=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.
Post by Olaf Meeuwissen
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.
Post by Olaf Meeuwissen
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?
Post by Olaf Meeuwissen
Post by Olaf Meeuwissen
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-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-07 00:50:06 UTC
Permalink
Raw Message
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.
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Hi Louis,
[snip]
Post by Louis Lagendijk
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.
Post by Louis Lagendijk
Post by Olaf Meeuwissen
Post by Louis Lagendijk
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.
Post by Louis Lagendijk
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 ;-)
Post by Louis Lagendijk
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-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Rolf Bensch
2017-05-19 09:13:24 UTC
Permalink
Raw Message
Are we already in Code Freeze?

I would like to commit a bug fix this weekend.

Rolf
Post by m. allan noah
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.
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
Any questions or concerns, let me know.
allan
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-19 10:51:48 UTC
Permalink
Raw Message
Hi Rolf,
Post by Rolf Bensch
Are we already in Code Freeze?
Post by m. allan noah
May 14: Code freeze (only update docs after this date)
and since there has been nothing on the mailing list to the contrary,
I'd say, yes, we are in Code Freeze. For a good five days already.
Post by Rolf Bensch
I would like to commit a bug fix this weekend.
So please wait until after the release (or create a branch if you really
cannot wait and push that).
Post by Rolf Bensch
Rolf
Post by m. allan noah
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.
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
Any questions or concerns, let me know.
allan
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
m. allan noah
2017-05-19 11:07:45 UTC
Permalink
Raw Message
What is the nature of the bug fix? Is it going to cause scanners that
worked with the prior release to be broken with this one? How big is
the fix? How likely to cause regressions?

allan
Post by Rolf Bensch
Are we already in Code Freeze?
I would like to commit a bug fix this weekend.
Rolf
Post by m. allan noah
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.
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
Any questions or concerns, let me know.
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-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-19 13:02:37 UTC
Permalink
Raw Message
Hi All(an),
Post by m. allan noah
What is the nature of the bug fix? Is it going to cause scanners that
worked with the prior release to be broken with this one? How big is
the fix? How likely to cause regressions?
Here's where git branches come in nice. Rolf creates a branch, commits
his bug fix and pushes the branch. Next, he informs the project admins
of the bug fix branch and that he would like to see it included in the
upcoming releases. The project admins have a look at the code changes
and can decide for themselves and/or ask for more information as needs
be.

Right now, everything goes straight to master and I am not sure that is
the best way to proceed when using git (Subversion and CVS are different
beasts). I also realize that forcing everything through some sort of
review process is unrealistic for sane-backends where most developers
are rather focussed on their own backend(s) only. Maybe we should try
to write up some kind of policy for pushing to master.

Something like

- pushing changes to master for a backend you maintain is okay (unless
in code freeze)
- pushing changes for code that affects multiple backends, something in
sanei/ for example or the build system, should go to a branch and get
reviewed before merging to master
- anything you like to have an extra pair of eyes on goes to a branch
and you ask/assign someone for review (uh-oh, Alioth doesn't support
merge requests ... :-(, mail and/or mailing list for now?)
- ... and some more for non-SANE developers that I'll skip for now

Anyway, let's focus on the release first.

I'll be around, intermittently, for most of the weekend (JST, UTC+0900)
if anything needs reviewing or if you have questions about any autotools
stuff. If you need a Debian GNU/Linux 8.8 setup for sane-backends

docker pull registry.gitlab.com/sane-projects/ci-envs:debian-8-full

is your friend. It'll only take a minute or so to download.
# But it won't do the SANE API documentation and manual pages yet :-(

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Rolf Bensch
2017-05-19 15:50:36 UTC
Permalink
Raw Message
Hi,
Post by Olaf Meeuwissen
Hi All(an),
Post by m. allan noah
What is the nature of the bug fix? Is it going to cause scanners that
worked with the prior release to be broken with this one? How big is
the fix? How likely to cause regressions?
Here's where git branches come in nice. Rolf creates a branch, commits
his bug fix and pushes the branch. Next, he informs the project admins
of the bug fix branch and that he would like to see it included in the
upcoming releases. The project admins have a look at the code changes
and can decide for themselves and/or ask for more information as needs
be.
Right now, everything goes straight to master and I am not sure that is
the best way to proceed when using git (Subversion and CVS are different
beasts). I also realize that forcing everything through some sort of
review process is unrealistic for sane-backends where most developers
are rather focussed on their own backend(s) only. Maybe we should try
to write up some kind of policy for pushing to master.
Something like
- pushing changes to master for a backend you maintain is okay (unless
in code freeze)
- pushing changes for code that affects multiple backends, something in
sanei/ for example or the build system, should go to a branch and get
reviewed before merging to master
- anything you like to have an extra pair of eyes on goes to a branch
and you ask/assign someone for review (uh-oh, Alioth doesn't support
merge requests ... :-(, mail and/or mailing list for now?)
- ... and some more for non-SANE developers that I'll skip for now
In real life my company is using the gitflow structure to organize the
projects in git:
https://datasift.github.io/gitflow/IntroducingGitFlow.html . The
developer is free installing gitflow or not, but he|she must always
stick to the gitflow structure on the gitlab server.

Hope this helps.

Cheers,
Rolf
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-05-20 01:45:13 UTC
Permalink
Raw Message
Hi,
Post by Rolf Bensch
Hi,
Post by Olaf Meeuwissen
Hi All(an),
Post by m. allan noah
What is the nature of the bug fix? Is it going to cause scanners that
worked with the prior release to be broken with this one? How big is
the fix? How likely to cause regressions?
Here's where git branches come in nice. Rolf creates a branch, commits
his bug fix and pushes the branch. Next, he informs the project admins
of the bug fix branch and that he would like to see it included in the
upcoming releases. The project admins have a look at the code changes
and can decide for themselves and/or ask for more information as needs
be.
Right now, everything goes straight to master and I am not sure that is
the best way to proceed when using git (Subversion and CVS are different
beasts). I also realize that forcing everything through some sort of
review process is unrealistic for sane-backends where most developers
are rather focussed on their own backend(s) only. Maybe we should try
to write up some kind of policy for pushing to master.
Something like
- pushing changes to master for a backend you maintain is okay (unless
in code freeze)
- pushing changes for code that affects multiple backends, something in
sanei/ for example or the build system, should go to a branch and get
reviewed before merging to master
- anything you like to have an extra pair of eyes on goes to a branch
and you ask/assign someone for review (uh-oh, Alioth doesn't support
merge requests ... :-(, mail and/or mailing list for now?)
- ... and some more for non-SANE developers that I'll skip for now
In real life my company is using the gitflow structure to organize the
https://datasift.github.io/gitflow/IntroducingGitFlow.html . The
developer is free installing gitflow or not, but he|she must always
stick to the gitflow structure on the gitlab server.
I'm aware of Git Flow. It has its good points but I tend to find it a
bit over-engineered. Maybe for a big corporate project, yes, but for
something like sane-backends I think it too complex. Something like
GitLab Flow[1,2] (or GitHub Flow[3]) would be more suitable, IMHO, but
with a few reasonably well-defined exceptions for the "no direct commits
to master" rule (as I mentioned above).

[1] https://docs.gitlab.com/ce/workflow/gitlab_flow.html
[2] https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/
[3] https://guides.github.com/introduction/flow/
Post by Rolf Bensch
Hope this helps.
Me too,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Rolf Bensch
2017-05-20 13:04:25 UTC
Permalink
Raw Message
Hi,

I see, the other work flows are pretty much easier for sane than git flow.
Post by Olaf Meeuwissen
Hi,
Post by Rolf Bensch
Hi,
Post by Olaf Meeuwissen
Hi All(an),
Post by m. allan noah
What is the nature of the bug fix? Is it going to cause scanners that
worked with the prior release to be broken with this one? How big is
the fix? How likely to cause regressions?
Here's where git branches come in nice. Rolf creates a branch, commits
his bug fix and pushes the branch. Next, he informs the project admins
of the bug fix branch and that he would like to see it included in the
upcoming releases. The project admins have a look at the code changes
and can decide for themselves and/or ask for more information as needs
be.
Right now, everything goes straight to master and I am not sure that is
the best way to proceed when using git (Subversion and CVS are different
beasts). I also realize that forcing everything through some sort of
review process is unrealistic for sane-backends where most developers
are rather focussed on their own backend(s) only. Maybe we should try
to write up some kind of policy for pushing to master.
Something like
- pushing changes to master for a backend you maintain is okay (unless
in code freeze)
- pushing changes for code that affects multiple backends, something in
sanei/ for example or the build system, should go to a branch and get
reviewed before merging to master
I just pushed an doc update to master and created and pushed the branch
'pixma/mf240_adf_only_300dpi' with the corresponding bug fix. Outside
code freeze I'd have pushed the fix directly into master.

@Allan: You can decide if the branch can be merged into master before or
after the next release. If you won't merge it, I'll do it by myself
after the next release.
Background for this patch: The MF240 scanner supports only 300dpi for
adf scans. For this scanner I set the max. allowed value for adf scans
to 300dpi and activated and set the counterpart variable to 300dpi (min.
allowed value for adf scans). The activated variable is already in use
within other pixma sub-backends. This fix only affects the MF240 scanner.
Post by Olaf Meeuwissen
Post by Rolf Bensch
Post by Olaf Meeuwissen
- anything you like to have an extra pair of eyes on goes to a branch
and you ask/assign someone for review (uh-oh, Alioth doesn't support
merge requests ... :-(, mail and/or mailing list for now?)
- ... and some more for non-SANE developers that I'll skip for now
If I wanted to ask someone to review the new branch, I'd named it as
'pixma/review/mf240_adf_only_300dpi'.

According to gitlab flow and github flow I would add these items:

- master is always 'stable'
then the 'daily git snapshots' on the website can be renamed from
'Unstable (Development) Source' to something like 'Stable Post Release
source', I suppose that sane won't provide unstable sources in
tarballs anymore
- releases, feature freeze and code freeze are tagged on master, e.g.
RELEASE_1_0_27, FEATURE_FREEZE_PRE_1_0_27, CODE_FREEZE_PRE_1_0_27
the restrictions for the freeze tags should be written into the tag
message
Post by Olaf Meeuwissen
Post by Rolf Bensch
In real life my company is using the gitflow structure to organize the
https://datasift.github.io/gitflow/IntroducingGitFlow.html . The
developer is free installing gitflow or not, but he|she must always
stick to the gitflow structure on the gitlab server.
I'm aware of Git Flow. It has its good points but I tend to find it a
bit over-engineered. Maybe for a big corporate project, yes, but for
something like sane-backends I think it too complex. Something like
GitLab Flow[1,2] (or GitHub Flow[3]) would be more suitable, IMHO, but
with a few reasonably well-defined exceptions for the "no direct commits
to master" rule (as I mentioned above).
[1] https://docs.gitlab.com/ce/workflow/gitlab_flow.html
[2] https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/
[3] https://guides.github.com/introduction/flow/
From my point of view, the new branch is a trial balloon for working
with and|or reviewing branches. Please feel free to define any naming
standard as you like.

Cheers,
Rolf
--
sane-devel mailing list: sane-***@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-***@lists.alioth.debian.org
Loading...