[Savannah-hackers-public] [task #13797] Please add capability for GNUstep to have multiple git repos...

[Gregory John Casamento]

URL:
  

 Summary: Please add capability for GNUstep to have multiple
git repos...
 Project: Savannah Administration
Submitted by: gcasa
Submitted on: Thu 05 Nov 2015 06:46:46 PM EST
 Should Start On: Thu 05 Nov 2015 12:00:00 AM EST
   Should be Finished on: Thu 05 Nov 2015 12:00:00 AM EST
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

We have been operating on GNA, but now want to move back to savannah.  I would
like to organize the project so that we have multiple repos for each different
sub project of GNUstep (gui, base, make, back, gorm, etc...).   It is my
understanding that this is something that has to be requested.  Please advise.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch

[Paul Smith]

On Thu, 2015-11-05 at 22:12 +0200, Eli Zaretskii wrote:
> > Date: Thu, 5 Nov 2015 12:54:30 -0700
> > From: Bob Proulx 
> > Cc: savannah-hackers-public@gnu.org
> > 
> > > > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 1472, 
> > > > in send
> > > > remote: p.terminate()
> > > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1269, in 
> > > > terminate
> > > > remote: self.send_signal(signal.SIGTERM)
> > > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1264, in 
> > > > send_signal
> > > > remote: os.kill(self.pid, sig)
> > > > remote: OSError: [Errno 1] Operation not permitted
> > 
> > "Operation not permitted" seems both clear and confusing at the same
> > time.  I mean, what operation?  And why wasn't it permitted?
> 
> Looks like it tried to kill itself, and got EPERM.  That's what the
> backtrace says: the frame at top of stack is the call to os.kill.  No?

Not itself: the pid related to object "p" at git_multimail.py:1472.

The "self" in Python is like "this" in C++, so self.pid represents the
PID of object "p", which seems to be a subprocess.Popen() object, or
subclass of that, and we're calling its terminate() method:

https://docs.python.org/2/library/subprocess.html#popen-objects


On Thu, 2015-11-05 at 13:14 -0700, Bob Proulx wrote:
>   vcs:/srv/git/emacs.git# ll -L /usr/lib/sendmail 
>   -rwsr-xr-x 1 root root 758788 Jul 13  2014 /usr/lib/sendmail

Yeah, that'll do it!

Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch

[Bob Proulx]

Hi Paul!

Paul Smith wrote:
> > > > remote: self.send_signal(signal.SIGTERM)
>...
> > > > remote: OSError: [Errno 1] Operation not permitted
> 
> It looks like the code is trying to send SIGTERM to this PID (using
> kill(2) underneath I expect), and it's failing with errno 1 "operation
> not permitted".  That's all the error info we get back from the OS, so
> there's no way to know exactly why it wasn't permitted.

If I make an assumption that the system was operating very slowly due
to external disk I/O waits and if I guess that the code is timing out
then it might try to clean up the timeout by sending a SIGTERM.  That
is probably a section of code rarely used and unlikely to be tested.

> That seems odd because the most obvious reason for this is that you're
> not the owner of the PID, but doesn't this code actually start that PID?
> Maybe it's setuid?  Well, you're right that the only way to find out
> more is read the code in git_multimail.py to see exactly what's going
> on.

I assume it is calling /usr/sbin/sendmail.

  vcs:/srv/git/emacs.git# ll /usr/lib/sendmail 
  lrwxrwxrwx 1 root root 13 Aug  3  2014 /usr/lib/sendmail -> ../sbin/exim4
  vcs:/srv/git/emacs.git# ll -L /usr/lib/sendmail 
  -rwsr-xr-x 1 root root 758788 Jul 13  2014 /usr/lib/sendmail

Bob

Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch

[Eli Zaretskii]

> Date: Thu, 5 Nov 2015 12:54:30 -0700
> From: Bob Proulx 
> Cc: savannah-hackers-public@gnu.org
> 
> > > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 1472, in 
> > > send
> > > remote: p.terminate()
> > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
> > > remote: self.send_signal(signal.SIGTERM)
> > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1264, in 
> > > send_signal
> > > remote: os.kill(self.pid, sig)
> > > remote: OSError: [Errno 1] Operation not permitted
> 
> "Operation not permitted" seems both clear and confusing at the same
> time.  I mean, what operation?  And why wasn't it permitted?

Looks like it tried to kill itself, and got EPERM.  That's what the
backtrace says: the frame at top of stack is the call to os.kill.  No?

Now, why would a process get EPERM when it wants to kill itself?

> I hate it when programmers are slack about error handling.

There's no programmer involved here, this is just the Python
equivalent of "Abort; core dumped."

Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch

[Paul Smith]

On Thu, 2015-11-05 at 12:54 -0700, Bob Proulx wrote:
> > > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 1472, in 
> > > send
> > > remote: p.terminate()
> > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
> > > remote: self.send_signal(signal.SIGTERM)
> > > remote:   File "/usr/lib/python2.6/subprocess.py", line 1264, in 
> > > send_signal
> > > remote: os.kill(self.pid, sig)
> > > remote: OSError: [Errno 1] Operation not permitted
> 
> "Operation not permitted" seems both clear and confusing at the same
> time.  I mean, what operation?  And why wasn't it permitted?

It looks like the code is trying to send SIGTERM to this PID (using
kill(2) underneath I expect), and it's failing with errno 1 "operation
not permitted".  That's all the error info we get back from the OS, so
there's no way to know exactly why it wasn't permitted.

That seems odd because the most obvious reason for this is that you're
not the owner of the PID, but doesn't this code actually start that PID?
Maybe it's setuid?  Well, you're right that the only way to find out
more is read the code in git_multimail.py to see exactly what's going
on.

Re: [Savannah-hackers-public] mail-sending error from git server updating emacs "concurrency" branch

[Bob Proulx]

Ken Raeburn wrote:
> I got this error back from the git server while pushing an update to
> the “concurrency” branch of emacs:
>...
> > remote: Sending notification emails to: emacs-di...@gnu.org
> > remote: *** Error while generating commit email
> > remote: ***  - mail sending aborted.
> > remote: Traceback (most recent call last):

Thanks for letting us know about the error.  Although I installed that
hook for the emacs team I am not a Python programmer and the only part
of the backtrace that tells me anything is:

> > remote:   File "hooks/post-receive", line 62, in 
> > remote: git_multimail.main(sys.argv[1:])
> > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 2631, in 
> > main
> > remote: run_as_post_receive_hook(environment, mailer)
> > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 2482, in 
> > run_as_post_receive_hook
> > remote: push.send_emails(mailer, body_filter=environment.filter_body)
> > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 2462, in 
> > send_emails
> > remote: rev.recipients,
> > remote:   File "/srv/git/emacs.git/hooks/git_multimail.py", line 1472, in 
> > send
> > remote: p.terminate()
> > remote:   File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
> > remote: self.send_signal(signal.SIGTERM)
> > remote:   File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal
> > remote: os.kill(self.pid, sig)
> > remote: OSError: [Errno 1] Operation not permitted

"Operation not permitted" seems both clear and confusing at the same
time.  I mean, what operation?  And why wasn't it permitted?  I hate
it when programmers are slack about error handling.  Someone would
need to look at the python source and debug it.  We are using the
Github project pretty much verbatim.

At a guess if it were a very large message it would have exceeded the
Exim configured message size limits.  That might have resulted in an
operation not permitted error in the python, maybe.  But since you
said the mail did go out that doesn't seem right either.

> > To raeb...@git.sv.gnu.org:/srv/git/emacs.git
> >   6a31219..39372e1  tmp -> concurrency
> 
> This was Sunday morning, around 1:42AM EDT (not EST). The email did
> go out, and it was a pretty large message, as this was merging over
> two years’ worth of changes from master to the concurrency branch.
> 
> Around the same time, from a different client machine, “git remote
> update” got a “Connection reset by peer” error. A later attempt
> worked fine.

Thanks for reporting the result.  However I think we can only shrug
and with some regret say that we don't know.  It obviously isn't a
permission error or every commit would be failing.  I can only imagine
something resulted from the large size coupled with other things
happening on the system.

The vcs server VM is hosted on a system with a lot of other VMs and
other I/O disk bandwidth.  Just as a general statement we have always
been seeing a lot of load spikes when the entire FSF environment is
busy.  Pretty much everything uses disk and bottlenecks there.  It is
possible something like that occurred and caused some timeout error
which was misreported as a not-permitted error.

Bob