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

[Rolf Bensch]

Hi,

I see, the other work flows are pretty much easier for sane than git flow.

Am 20.05.2017 um 03:45 schrieb Olaf Meeuwissen:
> Hi,
> 
> Rolf Bensch writes:
> 
>> Hi,
>>
>>
>> Am 19.05.2017 um 15:02 schrieb Olaf Meeuwissen:
>>> Hi All(an),
>>>
>>> m. allan noah writes:
>>>
 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.


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

>>
>> 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.
> 
> 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-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Olaf Meeuwissen]

Hi,

Rolf Bensch writes:

> Hi,
>
>
> Am 19.05.2017 um 15:02 schrieb Olaf Meeuwissen:
>> Hi All(an),
>>
>> m. allan noah writes:
>>
>>> 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.

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/

> Hope this helps.

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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Rolf Bensch]

Hi,


Am 19.05.2017 um 15:02 schrieb Olaf Meeuwissen:
> Hi All(an),
> 
> m. allan noah writes:
> 
>> 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-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Olaf Meeuwissen]

Hi All(an),

m. allan noah writes:

> 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-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[m. allan noah]

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

On Fri, May 19, 2017 at 5:13 AM, Rolf Bensch  wrote:
> Are we already in Code Freeze?
>
> I would like to commit a bug fix this weekend.
>
> Rolf
>
>
> Am 28.04.2017 um 14:04 schrieb 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.
>>
>> 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-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Olaf Meeuwissen]

Hi Rolf,

Rolf Bensch writes:

> Are we already in Code Freeze?

Allan wrote:

>> 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.

> 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).

> Rolf
>
> Am 28.04.2017 um 14:04 schrieb 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.
>>
>> 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

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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Rolf Bensch]

Are we already in Code Freeze?

I would like to commit a bug fix this weekend.

Rolf


Am 28.04.2017 um 14:04 schrieb 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.
>
> 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



-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Louis Lagendijk]

On Sun, 2017-05-07 at 07:34 +0900, Olaf Meeuwissen wrote:
> Hi all,
> 
> Louis Lagendijk writes:
> 
> > On Sat, 2017-05-06 at 15:55 +0200, Wilhelm wrote:
> > > Am 06.05.2017 um 14:27 schrieb m. allan noah:
> > > > On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk  > > > et>
> > > > wrote:
> > > > > 
> > > 
> > > From a scanbd point of view it would be suffcient to have either:
> > > 
> > > 1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and
> > > all
> > > sane-applications use the compile-time setting. scanbd can set
> > > this
> > > to an alternative (e.g. scanbd-dll.conf) file before starting
> > > saned.
> > > 
> > > 2) give saned a -c  option
> > > 
> > > I would prefer 1)
> > 
> > Well 2 is not an option in my opinion as there is no way for saned
> > to
> > pass an argument to the rest of saned. That is why I implemented
> > 1).
> 
> I don't understand why saned would have to pass arguments to the rest
> of
> saned.  Can you explain?

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.


> > 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).

> 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?
> 
>  - 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.

> 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. 

> 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.

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

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

[Olaf Meeuwissen]

Hi all,

Louis Lagendijk writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

Or there is a stale pidfile lingering around.

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

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

[m. allan noah]

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

allan

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

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

[Louis Lagendijk]

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

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

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

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

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

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

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

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


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

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

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

Comments anybody?

BR, Louis

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Wilhelm]

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

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

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

2) give saned a -c  option

I would prefer 1)

Thanks for investigating on this ;.)

--
 Wilhelm


-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[m. allan noah]

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

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

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

allan

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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Louis Lagendijk]

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

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

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

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

cheers, Louis

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Rolf Bensch]

Hi Olaf,

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

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

Hope this helps.

Cheers,
Rolf


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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Olaf Meeuwissen]

Hi again,

Olaf Meeuwissen writes:

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

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

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

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

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

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

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

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

This is still on my list.

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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Olaf Meeuwissen]

Hi Allan,

m. allan noah writes:

> Ok folks, it's time to get another sane-backends release out the door.

I was about to ping you on that ;-)

> 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 ...

> 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.

> 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)

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.

> 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-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[m. allan noah]

You can send translations at any time, up to the day of the release.

allan

On Fri, Apr 28, 2017 at 10:20 AM, Yuri Chornoivan  wrote:
> п'ятниця, 28-кві-2017 08:04:55 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.
>>
>> 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
>
> Hi,
>
> When is it possible/right to send translation updates?
>
> Thanks in advance for your answer.
>
> Best regards,
> Yuri
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-requ...@lists.alioth.debian.org



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

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

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

[Yuri Chornoivan]

п'ятниця, 28-кві-2017 08:04:55 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.
> 
> 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

Hi,

When is it possible/right to send translation updates?

Thanks in advance for your answer.

Best regards,
Yuri

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org