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...)
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!
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 :).
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.
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.
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!
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!
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! :)
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...
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?
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.
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
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
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: firstname.lastname@example.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!
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?
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.
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.
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
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
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!
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!
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.