[sane-devel] [janitorial] Error @ git push

[Olaf Meeuwissen]

Hi Rolf,

Thanks for reminding everyone of the issue[1], :-).  The short answer is
that there is nothing to worry really about.  Everything should be fine.
For the longer answer, see my comments below.

 [1]
 https://lists.alioth.debian.org/pipermail/sane-devel/2015-December/034213.html

Rolf Bensch writes:

> Hi Olaf,
>
> My last git push produced this output:
>
> Versende nach
> git+ssh://roben-guest@git.debian.org/git/sane/sane-backends.git
> remote: Sending notification emails to:
> sane-commit at lists.alioth.debian.org
> remote: Aktualisiere d94c29a..3258b70
> remote: Fast-forward
> remote:  backend/hp3500.c            | 2 ++
> remote:  backend/plustek-pp_scan.h   | 6 +-----
> remote:  configure                   | 2 +-
> remote:  configure.ac                | 2 +-
> remote:  doc/descriptions/pixma.desc | 4 ++--
> remote:  include/sane/config.h.in    | 3 ---

Now that's odd!  You seem to be sending two commits of mine with your
change to pixma.desc as well.

Maybe your local master was behind origin/master when you pushed?

Anyway, your change to pixma.desc triggered a rebuild of the supported
device lists on the website.  Due to my changes to configure{,.ac} that
rebuild decided it needs to reconfigure the checked out source tree (on
Alioth) and do so like

> remote:  6 files changed, 7 insertions(+), 12 deletions(-)
> remote: cd .. && make  am--refresh
> remote: make[1]: Entering directory
> `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git'
> remote: /bin/bash ./config.status --recheck

You can see it runs a ./config.status script (which remembers the
options used when ./configure was run) and tells it to --recheck.

> [...]

Near the very end, the ./config.status script updates itself with any
new findings (so you can do a ./config.status *without* --recheck'ing
real fast) and tries to set execute permissions on the script.  The
latter fails because the script is owned by kitno-guest and the update
is run by roben-guest.

# The code that does this is courtesy of autoconf so it is not trivial
# to fix this in a persistent way :-(

> remote: configure: creating ./config.status
> remote: chmod: changing permissions of `./config.status': Operation not permitted
> remote: configure: error: write failure creating ./config.status

This is not a problem because the script already has the permissions it
is trying to set.

> I've never seen the checking stuff before.

The configure{,.ac} scripts don't change all that frequently ;-)

I see the checking quite a bit when fiddling with autofoo stuff.  As
long as it only complains about not being able to set permissions on
./config.status things should be fine.

Hope this helps,
--
Olaf Meeuwissen, LPIC-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