threads / discuss / 9017

failing to send patches to the list

Subject: failing to send patches to the list

## tl;dr

9 messages between Jul 13, 2007 and Jul 14, 2007.

replies: 8people: 5as markdown or json

martin f krafft· Jul 13, 2007, 09:30 UTC · lore
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=<git@vger.kernel.org>,
  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 7b2bb44f78b8bc691bbc1445c6c333fdc281a788 Mon Sep 17 00:00:00 2001
From: martin f. krafft <madduck@madduck.net>
Date: Fri, 13 Jul 2007 11:09:05 +0200
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.

Signed-off-by: martin f. krafft <madduck@madduck.net>
---
 Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index d7541b4..1676343 100644
--- a/Makefile
+++ b/Makefile
@@ -532,6 +532,12 @@ ifndef NO_CURL
 	endif
 endif
 
+HAS_OPENSSL := $(shell echo "\#include <openssl/sha.h>" \
+			| $(CPP) -o/dev/null - 2>/dev/null || echo no)
+ifeq "$(HAS_OPENSSL)" "no"
+	NO_OPENSSL = "openssl_sha.h_not_found"
+endif
+
 ifndef NO_OPENSSL
 	OPENSSL_LIBSSL = -lssl
 	ifdef OPENSSLDIR
-- 
1.5.3.rc1.7.gcae4



From 5f537c75774c5c0b45b74585ace4178738f251f0 Mon Sep 17 00:00:00 2001
From: martin f. krafft <madduck@madduck.net>
Date: Fri, 13 Jul 2007 11:09:46 +0200
Subject: [PATCH] Provide --stdlayout option for git-svn to set trunk,tags,branches to defaults

The --stdlayout option to git-svn init initialises the default Subversion
values of trunk,tags,branches: -T trunk -b branches -t tags. If any of the
-T/-t/-b options are given in addition, they are given preference.

Signed-off-by: martin f. krafft <madduck@madduck.net>
---
 Documentation/git-svn.txt |    6 +++++-
 git-svn.perl              |    8 +++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 0a210e4..9e74b27 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -44,10 +44,14 @@ COMMANDS
 --tags=<tags_subdir>;;
 -b<branches_subdir>;;
 --branches=<branches_subdir>;;
+--stdlayout;;
 	These are optional command-line options for init.  Each of
 	these flags can point to a relative repository path
 	(--tags=project/tags') or a full url
-	(--tags=https://foo.org/project/tags)
+	(--tags=https://foo.org/project/tags). The option --stdlayout is
+	a shorthand way of setting trunk,tags,branches as the relative paths,
+	which is the Subversion default. If any of the other options are given
+	as well, they take precedence.
 --no-metadata;;
 	Set the 'noMetadata' option in the [svn-remote] config.
 --use-svm-props;;
diff --git a/git-svn.perl b/git-svn.perl
index b3dffcc..5b443ee 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -77,11 +77,12 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
 		   \$Git::SVN::_repack_flags,
 		%remote_opts );
 
-my ($_trunk, $_tags, $_branches);
+my ($_trunk, $_tags, $_branches, $_stdlayout);
 my %icv;
 my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared,
                   'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags,
                   'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix,
+                  'stdlayout' => \$_stdlayout,
                   'minimize-url|m' => \$Git::SVN::_minimize_url,
 		  'no-metadata' => sub { $icv{noMetadata} = 1 },
 		  'use-svm-props' => sub { $icv{useSvmProps} = 1 },
@@ -296,6 +297,11 @@ sub cmd_clone {
 	    $url !~ m#^[a-z\+]+://#) {
 		$path = $url;
 	}
+        if (defined $_stdlayout) {
+          $_trunk = 'trunk' if (!defined $_trunk);
+          $_tags = 'tags' if (!defined $_tags);
+          $_branches = 'branches' if (!defined $_branches);
+        }
 	$path = basename($url) if !defined $path || !length $path;
 	cmd_init($url, $path);
 	Git::SVN::fetch_all($Git::SVN::default_repo_id);
-- 
1.5.3.rc1.7.gcae4
martin f krafft· Jul 13, 2007, 09:56 UTC · re: martin f krafft · lore

git-svn patch faulty (was: failing to send patches to the list)

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
Eric Wong· Jul 14, 2007, 10:54 UTC · re: martin f krafft · lore

Re: git-svn patch faulty (was: failing to send patches to the list)

martin f krafft <madduck@madduck.net> wrote:
Show 7 quoted lines
> 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
Alex Riesen· Jul 13, 2007, 12:57 UTC · re: martin f krafft · lore

Re: failing to send patches to the list

On 7/13/07, martin f krafft <madduck@madduck.net> wrote:
Show 5 quoted lines
> 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).

martin f krafft· Jul 14, 2007, 06:05 UTC · re: Alex Riesen · lore

Re: failing to send patches to the list

also sprach Alex Riesen <raa.lkml@gmail.com> [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.
Jeff King· Jul 13, 2007, 15:55 UTC · re: martin f krafft · lore

Re: failing to send patches to the list

On Fri, Jul 13, 2007 at 11:30:50AM +0200, martin f krafft wrote:
Show 5 quoted lines
>   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
martin f krafft· Jul 14, 2007, 06:52 UTC · re: Jeff King · lore

Re: failing to send patches to the list

also sprach Jeff King <peff@peff.net> [2007.07.13.1755 +0200]:
Show 6 quoted lines
> 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/
Jakub Narebski· Jul 14, 2007, 00:58 UTC · re: martin f krafft · lore

Re: failing to send patches to the list

martin f krafft wrote:
Show 5 quoted lines
> 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
martin f krafft· Jul 14, 2007, 06:59 UTC · re: Jakub Narebski · lore

Re: failing to send patches to the list

also sprach Jakub Narebski <jnareb@gmail.com> [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

← back to recent threads