failing to send patches to the list

failing to send patches to the list

[martin f krafft]

[-- Attachment #1.1: Type: text/plain, Size: 937 bytes --]

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.

[-- Attachment #1.2: 0001-fall-back-to-mozilla-s-sha.h-if-openssl-sha.h-is-not.patch --]
[-- Type: text/x-diff, Size: 1009 bytes --]

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


[-- Attachment #1.3: 0002-Provide-stdlayout-option-for-git-svn-to-set-trunk.patch --]
[-- Type: text/x-diff, Size: 2789 bytes --]

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


[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

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

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: failing to send patches to the list

[Alex Riesen]

On 7/13/07, martin f krafft <madduck@madduck.net> 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).

Re: failing to send patches to the list

[Jeff King]

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

Re: failing to send patches to the list

[Jakub Narebski]

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

Re: failing to send patches to the list

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

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.

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: failing to send patches to the list

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

also sprach Jeff King <peff@peff.net> [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/

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: failing to send patches to the list

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

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

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Eric Wong]

martin f krafft <madduck@madduck.net> 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