git push issues

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

git push issues

Olaf Meeuwissen-4
Hi Allan,

I just pushed most of the patches that Volker posted to the list[1] 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[1]: 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[1]: *** [config.status] Error 1
  remote: make[1]: 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
think?

I'm not sure about what would be the best way to deal with this and
welcome suggestions.

 [1] 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
https://my.fsf.org/donate                        https://my.fsf.org/join
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9


--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git push issues

m. allan noah-3
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 :)

allan

On Sun, Dec 20, 2015 at 6:50 AM, Olaf Meeuwissen
<[hidden email]> wrote:

> Hi Allan,
>
> I just pushed most of the patches that Volker posted to the list[1] 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[1]: 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[1]: *** [config.status] Error 1
>   remote: make[1]: 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
> think?
>
> I'm not sure about what would be the best way to deal with this and
> welcome suggestions.
>
>  [1] 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
> https://my.fsf.org/donate                        https://my.fsf.org/join
>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>



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

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: git push issues

Olaf Meeuwissen-4
Hi Allan,

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
> <[hidden email]> wrote:
>> Hi Allan,
>>
>> I just pushed most of the patches that Volker posted to the list[1] 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[1]: 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[1]: *** [config.status] Error 1
>>   remote: make[1]: 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
>> think?
>>
>> I'm not sure about what would be the best way to deal with this and
>> welcome suggestions.
>>
>>  [1] 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
https://my.fsf.org/donate                        https://my.fsf.org/join
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9

--
sane-devel mailing list: [hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to [hidden email]
Loading...