[sane-devel] git push issues
paddy-hack at member.fsf.org
Mon Dec 21 12:28:36 UTC 2015
m. allan noah writes:
> hmm- perhaps we could set the umask on the make command? I'm not sure
> if that would help, I've not had any caffeine yet this morning :)
Extremely unlikely. Per `man 2 chmod`:
The effective UID of the calling process must match the owner of the
file, or the process must be privileged
(Linux: it must have the CAP_FOWNER capability).
Note, the file in question is updated and already has the permissions
that `chmod +x` wants to add. A later push (the ChangeLog changes in
5136e66) completed without a hitch.
The root of the problem is really that the various git hooks run as the
user that pushes commits. This causes the files in the working copy to
be owned by whomever changed/updated them last.
One way to solve this would be per committer working copies. Another
would be to do a clean checkout per commit. Both are inefficient. The
latter can be time consuming so it may be better to run it in the
background or as a cron job maybe.
Running the hooks as a dedicated user like sane or sane_scm is another
approach but I don't know if that is possible on Alioth. Both groups
exist but there don't seem to be any correspondings users. I didn't
check the GForge LDAP databases, though.
Poking around a bit on Alioth, I get the impression that a cronjob by
one of the project maintainers might be the easiest solution. The git
hooks could, for example, touch a known file that the cronjob can check
in order to decide what needs to be done.
I'm open for ideas and not sure if this is worth all the trouble right
now with my autotools-reform looming on the horizon.
# Say what!?! Neither autoconf nor automake on Alioth? Uh-oh!
> On Sun, Dec 20, 2015 at 6:50 AM, Olaf Meeuwissen
> <paddy-hack at member.fsf.org> wrote:
>> Hi Allan,
>> I just pushed most of the patches that Volker posted to the list and
>> encountered some "trouble".
>> One of the patches triggered a mail to sane-commits that exceeded the
>> 40kb limit. The commit in question has a rather large diff and it looks
>> like the sane-backends repository's post-receive hook includes the whole
>> diff. Wouldn't it be sufficient to just sent the commit message?
>> The second issue I ran into is that one of the patches triggered a
>> make am--refresh
>> in the sane-backends-list-git working copy. Both update-lists.sh and
>> update-search.sh in the post-receive hook may trigger this. This went
>> like so:
>> remote: cd .. && make am--refresh
>> remote: make: Entering directory `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git'
>> remote: /bin/bash ./config.status --recheck
>> remote: configure: creating ./config.status
>> remote: chmod: changing permissions of `./config.status': Operation not permitted
>> remote: configure: error: write failure creating ./config.status
>> remote: make: *** [config.status] Error 1
>> remote: make: Leaving directory `/var/lib/gforge/chroot/home/groups/sane/sane-backends-lists-git'
>> remote: make: *** [../config.status] Error 2
>> The reason this fails is that kitno-guest owns config.status and the
>> make was run by olaf-guest (member of both sane and sane_scm groups).
>> User A cannot modify permissions of a file owner by user B, even if they
>> are both in the group that's assigned to the file.
>> This particular commit has no effect on the HTML pages or the backend
>> descriptions so it didn't break anything this time. However, I think
>> the various scripts should run without ownership issues. What do you
>> I'm not sure about what would be the best way to deal with this and
>> welcome suggestions.
>>  https://lists.alioth.debian.org/pipermail/sane-devel/2015-December/034167.html
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
Support Free Software Support the Free Software Foundation
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
More information about the sane-devel