[sr #109942] restore automake-commit mail?

2020-01-06 Thread Bob Proulx
Follow-up Comment #16, sr #109942 (project administration):

Among other things the post-receive hook file was not executable.  Therefore
it was not being invoked.  I chmod a+x post-receive the file so that it would
be executable.

I simulated the most recent commit.  The mail log says it has sent email out
to automake-commit.  So perhaps it is working now.

The previous commit (HEAD^) was cf27a3dfc64b877524bea0505fe2820d6bfe6251 and
the current commit (HEAD) is b87f297426c2d79494b707d0fecddaff2b6eaefd
therefore to push out that set of commits (there was only one in that set) one
must be in the git directory, pipe the commit hash values into the hook script
as stdin, and run the hook as the user that did the commit.

root@vcs0:/net/vcs/git/automake.git# echo
cf27a3dfc64b877524bea0505fe2820d6bfe6251
b87f297426c2d79494b707d0fecddaff2b6eaefd refs/heads/master | sudo -u karl
./hooks/post-receive
Sending notification emails to: automake-com...@gnu.org

Which seems like it should have worked perfectly.  But in this case the actual
email has a From: address of root when it should not have. Hmm...  Oh well.  I
think in a real commit case that it will have the correct address though.  I
checked and the mail was sent to the mailing list and appears in the raw
mailbox archives.  I did not wait for the */30 cronjob to thread the message. 
I'll check that tomorrow.

I also noticed a bug that has been in the git-multimail.py program for a
while.  The revision header message complains that "reply_to" is not set (it
is for the refchange message though) and does not include the Mail-Followup-To
header on that message.  It is included in the individual refchange messages. 
The python code was too inscrutable for me to discern the problem though.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[sr #109942] restore automake-commit mail?

2020-01-06 Thread Bob Proulx
Follow-up Comment #17, sr #109942 (project administration):

New question/problem: Given the state of sites with strict DMARC policies,
should we set the From: address to the mailing list?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




Re: Cannot Login

2020-01-06 Thread Stephen Dawson
Thanks, Bob.

It works now using same login credentials. Odd, but at least it works.

-- 
Stephen H. Dawson, DSL
Executive Strategy Consultant
+1 (865) 804-3454
http://www.shdawson.com

> On January 6, 2020 at 12:56 AM Bob Proulx  wrote:
> 
> 
> Hello Stephen,
> 
> Stephen H. Dawson, DSL wrote:
> >My Savannah user ID is shdawson.
> >I am unable to log into Savannah. It seems like my user and password
> >combination are accepted, but I am still not getting past the login
> >process.
> 
> The address on file is the same as the one you have used here.
> Perhaps you don't have the password correct?  Perhaps if you used the
> password recovery process, it will send an email to your address, then
> you would be able to log into the system using the credentials it
> sends?  Then you could refresh your password by setting it to
> something new.
> 
> >Is Savannah experiencing performance issues? If not, should I submit a
> >support request for review of this condition?
> 
> Savannah's web interface is working normally.  As far as I can tell.
> At least I am not seeing any obvious problems.  And I am able to log
> into the web site okay.
> 
> Bob



[sr #110171] Remove project EasyWay

2020-01-06 Thread Giovanni Giorgi
URL:
  

 Summary: Remove project EasyWay
 Project: Savannah Administration
Submitted by: gg
Submitted on: Mon 06 Jan 2020 05:52:40 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi, Can you remove my old (2001) and not active project, named Easy Way?


The project URL is
https://savannah.nongnu.org/projects/easyway/





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




Re: Cannot Login

2020-01-06 Thread Bob Proulx
Stephen Dawson wrote:
> Thanks, Bob.
> 
> It works now using same login credentials. Odd, but at least it works.

Odd that it works with no change.  But glad to hear that it is working
for you again.

Bob



[sr #109942] restore automake-commit mail?

2020-01-06 Thread Karl Berry
Follow-up Comment #18, sr #109942 (project administration):

1) the mail came through, yay!! thank you so much. sorry i left it up to you
guys.

2) as you noted, it came From: r...@freefriends.org. Ok, we'll find out about
the From: address next time we commit something. 

3) I strongly think it should be the real committer address, not the list. The
solution to DMARC, imho, is dmarc_moderation_action=munge from, which is
already set for automake-commit. (and i believe pretty much all lists have
either had that set or the headers/footers removed, etc., per Ian.)

4) are you sure emacs-commit was intended to be "replaced"? it feels
unexpected to me. in the non-git world, emacs-commit was the full commits and
emacs-diffs was the diffs. there was the savannah web ui for project admins to
set them independently.

barring evidence to the contrary, i suspect the full commit email simply
stopped working when they switched to git and nobody noticed/reported.

4) maybe check that that all post-receive files are x?

thanks again!!


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/




[sr #109942] restore automake-commit mail?

2020-01-06 Thread Bob Proulx
Follow-up Comment #19, sr #109942 (project administration):

I am pretty sure that the mail being from root even though I ran it with sudo
to be "karl" was because it probably pulled root from USER or one of the other
variables. I did not expect that and after it happened I didn't want to run it
twice. Seems like it probably should work when done for real. Since then it is
a login as the actual user.

I am okay with leaving the from address from the committer. I had forgotten
that passing through the mailing lists causes the fixup as it goes through the
Exim config. So it will be just like all of the mailing lists. That's good to
be all the same.

I looked at the emacs config and the file has not changed since 2014.

[multimailhook]
mailinglist = emacs-di...@gnu.org
emailPrefix = ""

-rw-rw-r-- 1 root emacs 229 Nov 18  2014 config

That seems pretty simple and explicit.  But I don't know.  I can't remember
what I had for breakfast yesterday since I have slept since then.

What is the difference between "commits" and "diffs"?  That distinction has no
meaning to me.  Aren't they both the same?  Not understanding that is
hampering my understanding of the problem.

We could ask Glenn Morris about the thinking at the time as I am pretty sure
he was involved in it.  (But I have little memory of the emacs transition. It
is even possible that I was involved and have no memory of it.)

There are 265 post-receive scripts in place that are not executable. But that
is because at least the ones I spot checked are all empty comments-only
templates. So not sure I would want to simply enable all of them.

When I grep to list non-executable post-receive hooks that are using
git-multimail I find only the single test-project which I used for testing but
then disabled afterward. All of the others using git-multimail are
executable.

I did not look at all of the other non-git-multimail hooks. I don't know how
many of those there are. But there are at least a few that do things
different. Those are all uniquely different.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/