Re: [Savannah-hackers-public] Git email hook?

2022-09-20 Thread Paul Smith
On Tue, 2022-09-20 at 09:35 -0400, Paul Smith wrote:
> Is the hook for sending email on commits to git.sv.gnu.org working?
> 
> I pushed a change this morning and didn't see any email about it.
> 
> Cheers!

Got the email about 4 hours later; apparently there's some lag in the
system (I just got this email, about 4.5 hours later...)



[Savannah-hackers-public] Git email hook?

2022-09-20 Thread Paul Smith
Is the hook for sending email on commits to git.sv.gnu.org working?

I pushed a change this morning and didn't see any email about it.

Cheers!



Re: [Savannah-hackers-public] Anyone have any news on Savannah?

2022-08-15 Thread Paul Smith
On Mon, 2022-08-15 at 13:28 -0600, Bob Proulx wrote:
> Paul Smith wrote:
> > Unfortunately it seems to be down / under attack again this morning
> > :(
> 
> I see that my attempts at mitigation of the current problem are
> failing.  I am looking into things again now.  I'll type this in
> stream of consciousness as I work the problem and then send it.

Thanks the site is currently working for me.  And I was interested to
read the notes on your debug session :).



Re: [Savannah-hackers-public] Anyone have any news on Savannah?

2022-08-15 Thread Paul Smith
On Sun, 2022-08-14 at 22:06 -0600, Bob Proulx wrote:
> Paul Smith wrote:
> > I haven't been able to reach the Savannah website for most of the
> > day.
> > Things like the Git service are available but the website is not.
> 
> Thanks for the report.  It appears that some agent was pounding on
> the web site.  There were max processes of apache2 web server running
> and nothing making progress.  I killed all and restarted the web
> server and things seem to be functional now.
> 
> It looks like the fail2ban dynamic rules were not transferred over to
> the new system.  We have some custom rules there that help block
> abusive agents.  I'll get those set up on the system.

Thanks Bob.

Unfortunately it seems to be down / under attack again this morning :(

Don't people have better things to do with their lives?  Sigh.



[Savannah-hackers-public] Anyone have any news on Savannah?

2022-08-14 Thread Paul Smith
I haven't been able to reach the Savannah website for most of the day.
Things like the Git service are available but the website is not.




Re: [Savannah-hackers-public] git status update

2017-02-07 Thread Paul Smith
On Tue, 2017-02-07 at 14:04 -0700, Bob Proulx wrote:
> I switched git dns over to the new server (again) this morning.
> Trying not to thrash the IP address for git+ssh users too often.
> Everything git core command specific looks okay for my testing.

I was able to use the new server without any issues.  I was also able
to use HTTPS transport to clone anonymously... yay!



Re: [Savannah-hackers-public] Testing new savannah website (2nd test)

2017-02-04 Thread Paul Smith
On Fri, 2017-02-03 at 19:35 -0700, Bob Proulx wrote:
> Note that this isn't a migration problem.  I pulled git back to the
> older server.  So it might be a problem with the older git version on
> the older server.

I don't want to interrupt anyone's good work, but I wonder if there's a
hoped-for timeline for putting Git back on the new server again?

The current one works fine for me except that I really want HTTPS
support, which the current server doesn't provide.

Thanks for everyone's hard work on this... at $(realjob) we're moving
our offices in two months so I know how complex and frustrating it can
be to unearth and move years of accreted tech.

Cheers!



Re: [Savannah-hackers-public] git migration status

2016-12-13 Thread Paul Smith
On Mon, 2016-12-12 at 04:06 -0700, Bob Proulx wrote:
> On the good news side of things is that hopefully most people haven't
> noticed any huge disruption because of this.  As soon as I work
> through the most recent problems then I will say something about https
> being available.

I've seen the emails going around and you've been fast enough at
switching things back that I haven't noticed any impacts at all, so
thanks for your hard work!

It'll be great to have things well-set up (and this time, well-
documented?)... good luck! :)



Re: [Savannah-hackers-public] git migration status

2016-12-10 Thread Paul Smith
Hi all; very excited to see some new infrastructure being deployed for
Savannah!

I was wondering if the changes will allow us to address the current
problem where we don't have MitM-resistant access to SCM repositories
(at least not Git repositories) for non-maintainers; currently the only
protocols available are the "git" protocol and the "http" protocol.

I'd love to see "https" availabile for accessing Git repositories.
See for example: https://savannah.gnu.org/support/?109093

Just curious...



Re: [Savannah-hackers-public] [Repo-criteria-discuss] Savannah and HTTPS

2016-10-10 Thread Paul Smith
On Fri, 2016-10-07 at 22:16 -0400, Mike Gerwitz wrote:
> On Mon, Sep 19, 2016 at 12:30:03 +0200, Hanno Böck wrote:
> > *The code repositories*
> > 
> > Now all of the above can be aleviated a bit if a user carefully uses
> > https all the time manually or uses a plugin like https everywhere. But
> > even more worrying is that there is no way to access the savannah git
> > repositories in a secure way for anonymous users.
> > 
> > If you look at a repository site like this:
> > http://savannah.gnu.org/git/?group=patch
> > 
> > There are two ways to clone the repo: Over the git:// protocol, which
> > is plaintext and insecure, and over ssh, which is only available if you
> > have a savannah account and are a member of that project. Therefore for
> > all people that are not part of a project there is no secure way of
> > getting the git code.

Most replies seem to be concentrating on the Savannah web page, but
personally I think this lack of any ability to retrieve source via a
secure channel, even one wanted to, is a much bigger issue.

Maybe we can concentrate on what it would take to solve this problem
immediately, and leave the less clear-cut issues for later?



Re: [Savannah-hackers-public] Pusing to Git repo declined

2016-05-27 Thread Paul Smith
On Fri, 2016-05-27 at 11:18 +0200, Aljosha Papsch wrote:
> > If the project is serious about enforcing these habits then the right
> > way to do it is by rejecting commits that don't meet the criteria, so
> > that the user can fix them and avoid incorrect commits appearing in the
> > repository in the first place.
> How do you fix the commit locally? Is it alright rewriting history
> that's not been pushed yet?

Yes, it's fine.  I do it probably 15 times a day, to a greater or lesser
extent.

The simplest case of rewriting history is using "git commit --amend" to
change the current HEAD commit for your branch.  More sophisticated
rewriting of history typically involves "git rebase", either interactive
or not.



Re: [Savannah-hackers-public] Pusing to Git repo declined

2016-05-26 Thread Paul Smith
On Thu, 2016-05-26 at 13:41 -0700, Jim Meyering wrote:
> On Tue, May 24, 2016 at 10:30 PM, Aljosha Papsch wrote:
> > Thanks for the clarification. I will fix these files now. While forcing
> > users to push clean files is unexpected for user, I guess it would be great
> > if these messages were warnings and would not result in a fatal error.
> > Users could then decide for themselves whether to clean up files, in the
> > sense "You have been warned". Is that possible?

The problem with this is that it's not possible in Git to "change" a
commit once it's been made, except by "rewriting history", and once a
commit is pushed to a public server it's typically a very bad idea to
rewrite its history.

So, if you simply warn about these problems but let the commit push
succeed, then there is no way for the user to clean up the mess except
by adding a new commit on top which undoes the problems.  It is really
unpleasant, in the project history, to see a constant set of "push a
change, push a cleanup to the change" commits.

If the project is serious about enforcing these habits then the right
way to do it is by rejecting commits that don't meet the criteria, so
that the user can fix them and avoid incorrect commits appearing in the
repository in the first place.



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

2015-11-05 Thread 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

2015-11-05 Thread 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!




[Savannah-hackers-public] Why is cgit showing the wrong stuff?

2015-01-28 Thread Paul Smith
Looking at http://git.savannah.gnu.org/cgit for GNU make (at least)
there's something bizarre about it:

http://git.savannah.gnu.org/cgit/make.git/tree

If I don't specify any tag or SHA in the URL, it always chooses some
strange commit from 2013 as the default; for example:

http://git.savannah.gnu.org/cgit/make.git/commit

and if I choose master specifically, I get the same thing:

http://git.savannah.gnu.org/cgit/make.git/commit/?id=master

But, if I go to the summary:

http://git.savannah.gnu.org/cgit/make.git/

(or look at my local clone) I see that master was just updated earlier
today and if I use that SHA instead I get the right stuff:

http://git.savannah.gnu.org/cgit/make.git/tree/?id=e4ac28e83081fa273b19fa778d46c1e3052cb834


S... why does cgit think my master branch is still stuck back in
2013 and what can I do to fix it?




Re: [Savannah-hackers-public] http not working for savannah.gnu.org ... ?

2014-03-28 Thread Paul Smith
On Fri, 2014-03-28 at 12:18 -0600, Bob Proulx wrote:
 Thank you for reporting this problem.  However this always works fine
 for me.  But I think we have different environments.  Does being
 logged in versus not logged in change this in any way?

 When I am logged in the page always redirects to the https version of
 the page.  When not logged in it simply works with the http version of
 the page.  I just now tested a few combinations and I didn't see
 problems either way.

I was logged in, yes.  I didn't try logging out.

But now it started working for me.  When I just tried it took a while
with Connecting... but finally came back with the page (previously it
would come back with an error page), and now when I do it it works
quickly.

So, either there was something wrong on my end or else someone fixed it!

Thanks Bob.  FWIW, I agree that it would be good to change the email
link address...


PS. I am using Chromium, and the only plugins I have wouldn't impact
this: flashblock and adblock basically.




Re: [Savannah-hackers-public] git accumulations on vcs

2013-03-01 Thread Paul Smith
On Fri, 2013-03-01 at 15:45 +, Karl Berry wrote:
 There are many hundreds of git processes happily chugging away on vcs,
 going back to October.  This can't be right?

Do you know what they're doing?  Presumably they're all waiting on
something since if they were all active the server would be on its
knees.  Can you tell what they're waiting on (does strace -p pid show
anything interesting)?  How they were invoked/command line args, etc.?

We have a Git server here and I never see that kind of thing.  But of
course the usage model is very different.




[Savannah-hackers-public] Migrating items from one tracker to another...?

2011-08-29 Thread Paul Smith
So, I've decided that having separate trackers for bugs, support,
patches, and tasks is annoying and confusing.  I'd like to consolidate
them all and have just one tracker: Bugs.

What I'd really like to do is move the patches and support tracker
contents into the bug tracker (the tasks tracker was empty so I just
turned it off).

I realize this is not quite so simple since the numbering, fields, etc.
are different.  However I'd be happy to have default values filled in
for missing fields etc.

Does anyone have any idea how to do such a thing?  Maybe with some magic
Savannah admin script or something?

Or, is there a way to make trackers read-only to the public, so at least
no NEW items can be added there but people can still see the old items
(until I resolve them somehow)?

-- 
---
 Paul D. Smith psm...@gnu.org  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.net
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist




Re: [Savannah-hackers-public] Anyone have any updates on Savannah?

2010-11-29 Thread Paul Smith
On Mon, 2010-11-29 at 19:34 +0100, Sylvain Beucler wrote:
 What I know is there's been a SQL injection leading to illegitimate
 membership access

Oh blerg.  The prevalence of these types of very simple (to avoid and to
fix) mistakes even on technical sites makes me despair.

OK thanks.


PS. I notice it took mere minutes for spammers to find the new Savannah
page and post some spammy comments :-).

-- 
---
 Paul D. Smith psm...@gnu.org  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.net
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist




[Savannah-hackers-public] Issue with email notification of Savannah bugs

2010-11-10 Thread Paul Smith
There's a problem with the email notification code in Savannah.
Recently a bug was filed (http://savannah.gnu.org/bugs/?31614) in which
the verbatim tag was used to provide some code examples.  In the bug,
the example looks correct:

$ echo 'a\ b:; echo $@' | make -f - a b
echo a b
a b

However, I have configured Savannah to forward bug notifications and in
the email I got the backslash was removed; I've noticed this in other
bugs as well and it's supremely annoying as it changes the entire
meaning of the issue to lose the backslashes; in the email I get:

$ echo 'a b:; echo $@' | make -f - a b
echo a b
a b

Note the missing backslash which completely changes the example.

Is there somewhere to file a bug about this, and/or can it be fixed?

Cheers!




[Savannah-hackers-public] Savannah user posting spam

2010-09-05 Thread Paul Smith
Hi all;

This morning at about 1am EDT this user account:

https://savannah.gnu.org/users/sevanath

posted spam to 21 of the GNU make bug reports.

Please disable this account; thanks!




Re: [Savannah-hackers-public] git features on Savannah

2010-07-28 Thread Paul Smith
On Wed, 2010-07-28 at 21:16 +, Karl Berry wrote:
 And changing this would require very significant discussion and effort
 from the FSF sysadmins, since they are the only ones with the power to
 actually make changes on the www.gnu.org server.  I don't see that
 happening any time in the foreseeable future, so you just have to put up
 with CVS.  Sorry.

OK, not a huge problem.  I'm assuming that this means I should NOT
uncheck the CVS component from my Savannah admin page, even if I enable
a different source control tool?

 time I update the manual so that chapter names change, etc. the
 
 Chapter names, ok, but that wouldn't change html_node files.  It is not
 a good thing to change node names, so consider the CVS pain additional
 reason not to :).

Mm.  Well, some terminology changed in the manual, so the node names
(that used the old terms) needed to change.

Just curious, but why is it bad to change node names?  Is it because
people save bookmarks to them or something?

If I keep this in mind maybe I can pick smarter node names that are
less fragile.

 Also, in CVS I had my CVSROOT/loginfo trigger set up to send email on
 checkin to a mailing list; is this possible with git on Savannah?
 
 I don't know, and I'm not seeing info at
 http://savannah.gnu.org/maintenance/UsingGit.  Sylvain, anyone?

Yeah, I read that :-).

This (email notifications) is something I'd really like to have.