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-gu...@git.debian.org/git/sane/sane-backends.git > remote: Sending notification emails to: > sane-com...@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 -- 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