From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
Dear list,
attached you may find two patches, which I've previously sent to the
list with
git format-patch -s --stdout | sendmail git@vger.kernel.org
Even though my mail server seems to have delivered them correctly:
Jul 13 10:53:32 albatross postfix/smtp[29758]: C404D895D6F:
to=[off-list ref],
relay=vger.kernel.org[209.132.176.167]:25, delay=2.2,
delays=0.08/0.04/0.56/1.6, dsn=2.7.1, status=sent (250 2.7.1 Looks
like Linux source DIFF email.. BF:<H 5.0943e-06>; S932911AbXGMIxb)
they never made it onto the list.
What am I doing wrong?
Should I resubmit the patches or is this enough for now?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
all software projects are done by iterative prototyping.
some companies call their prototypes "releases", that's all.
From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
Hi there,
still not having figured out the problem with the list (and I did
contact postmaster@), I just discovered that in fact the patch only
handles git-svn clone, not git-svn init. Thus, it's best to ignore
it for now. I am sorry for not taking enough care before publishing
it.
The openssl-autodetect patch does work and is ready for inclusion,
if you agree.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"if builders built buildings the way
programmers wrote programs,
then the first woodpecker that came along
would destroy civilization."
-- gerald weinberg
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:21
On 7/13/07, martin f krafft [off-list ref] wrote:
attached you may find two patches, which I've previously sent to the
list with
git format-patch -s --stdout | sendmail git@vger.kernel.org
I suggest you try "git format-patch -s --stdout |less" before sending
format-patch without parameters produces nothing.
Even assuming you run something like "git-format-patch start.."
(note the range specification), its output is NOT what sendmail
can use (unless you have a special sendmail which understands
mboxes).
From: Jeff King <hidden> Date: 2016-06-15 22:43:21
On Fri, Jul 13, 2007 at 11:30:50AM +0200, martin f krafft wrote:
git format-patch -s --stdout | sendmail git@vger.kernel.org
Even though my mail server seems to have delivered them correctly:
[...]
they never made it onto the list.
vger will reject messages without a message-id. git-format-patch by
default does not generate a message-id, so unless sendmail generates one
on the fly, that is your problem.
In general, git-format-patch output is probably not suitable for direct
sending...have you looked at git-send-email?
-Peff
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:21
martin f krafft wrote:
Subject: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
Uses $(CPP) to attempt to preprocess an include <openssl/sha.h> directive. If
that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using
mozilla's SHA implementation.
Shouldn't this be rather in configure.in? Main Makefile has only defaults
for different systems, but does not do tests.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
also sprach Alex Riesen [off-list ref] [2007.07.13.1457 +0200]:
I suggest you try "git format-patch -s --stdout |less" before
sending format-patch without parameters produces nothing.
I did. I simply misquoted in the email. Fact is that sendmail did
send an email, which VGER recognised to be a diff; yet it never
showed up.
I think the missing message ID is likely the problem. I'll look into
it.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
humpty was pushed.
From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
also sprach Jakub Narebski [off-list ref] [2007.07.14.0258 +0200]:
Shouldn't this be rather in configure.in? Main Makefile has only
defaults for different systems, but does not do tests.
You are right, except git HEAD already comes with a Makefile (rather
than a Makefile.in), so I just ran it while testing out patches.
I introduced the test because I thought the computer could find out
about libssl for me, rather than myself having to forget to specify
NO_OPENSSL every time.
I agree that this should be (also) in configure.ac; the question is
more whether we *could* also add it to the Makefile to make
from-source compilations easier.
On the other hand, I wonder: if the mozilla/sha.h implementation is
in the tree anyway, why even bother with libssl? The SHA
implementation is unlikely to be changed anytime soon, so the extra
library dependency seems overkill just for the SHA hash
functionality.
Just my 2¢
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"to get back my youth i would do anything in the world, except take
exercise, get up early, or be respectable."
-- oscar wilde
From: martin f krafft <hidden> Date: 2016-06-15 22:43:21
also sprach Jeff King [off-list ref] [2007.07.13.1755 +0200]:
vger will reject messages without a message-id. git-format-patch by
default does not generate a message-id, so unless sendmail generates one
on the fly, that is your problem.
In general, git-format-patch output is probably not suitable for direct
sending...have you looked at git-send-email?
I just ran a test and found out: sendmail does generate a message ID
on the fly on the client, so this cannot be the problem.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
http://www.transnationalrepublic.org/
From: Eric Wong <hidden> Date: 2016-06-15 22:43:21
martin f krafft [off-list ref] wrote:
Hi there,
still not having figured out the problem with the list (and I did
contact postmaster@), I just discovered that in fact the patch only
handles git-svn clone, not git-svn init. Thus, it's best to ignore
it for now. I am sorry for not taking enough care before publishing
it.
Heh, I haven't used git-svn init in months :)
--
Eric Wong