[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

etch: dash 0.5.3-7, git-core 1:1.4.4.4-1



Hi,

please include dash 0.5.3-7 into etch, it's 4 days in sid and only
includes new debconf translations.

Additionally I suggest git-core 1:1.4.4.4-1 for etch.  It's a new
upstream point release, 25 days in sid now, fixing some important bugs,
see attachment.  Upstream handles point releases quite conservative, and
adds no new features, only fixes.  I attach the upstream changes since
1.4.4.3, currently in etch.  The oldest hunk already was included in
1.4.4.3-1 (#388370).

Thanks, Gerrit.
commit 8977c110b5bbd230c28c727ddb85856067d55cfb
Author: Junio C Hamano <junkio@cox.net>
Date:   Wed Jan 3 23:09:08 2007 -0800

    pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
    
    Running the SHA1_Update() on the whole packfile in a single call
    revealed an overflow problem we had in the SHA-1 implementation
    on POWER architecture some time ago, which was fixed with commit
    b47f509b (June 19, 2006).  Other SHA-1 implementations may have
    a similar problem.
    
    The sliding mmap() series already makes chunked calls to
    SHA1_Update(), so this patch itself will become moot when it
    graduates to "master", but in the meantime, run the hash
    function in smaller chunks to prevent possible future problems.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/pack-check.c b/pack-check.c
index c0caaee..8e123b7 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,16 +1,18 @@
 #include "cache.h"
 #include "pack.h"
 
+#define BATCH (1u<<20)
+
 static int verify_packfile(struct packed_git *p)
 {
 	unsigned long index_size = p->index_size;
 	void *index_base = p->index_base;
 	SHA_CTX ctx;
 	unsigned char sha1[20];
-	unsigned long pack_size = p->pack_size;
-	void *pack_base;
 	struct pack_header *hdr;
 	int nr_objects, err, i;
+	unsigned char *packdata;
+	unsigned long datasize;
 
 	/* Header consistency check */
 	hdr = p->pack_base;
@@ -25,11 +27,19 @@ static int verify_packfile(struct packed_git *p)
 			     "while idx size expects %d", nr_objects,
 			     num_packed_objects(p));
 
+	/* Check integrity of pack data with its SHA-1 checksum */
 	SHA1_Init(&ctx);
-	pack_base = p->pack_base;
-	SHA1_Update(&ctx, pack_base, pack_size - 20);
+	packdata = p->pack_base;
+	datasize = p->pack_size - 20;
+	while (datasize) {
+		unsigned long batch = (datasize < BATCH) ? datasize : BATCH;
+		SHA1_Update(&ctx, packdata, batch);
+		datasize -= batch;
+		packdata += batch;
+	}
 	SHA1_Final(sha1, &ctx);
-	if (hashcmp(sha1, (unsigned char *)pack_base + pack_size - 20))
+
+	if (hashcmp(sha1, (unsigned char *)(p->pack_base) + p->pack_size - 20))
 		return error("Packfile %s SHA1 mismatch with itself",
 			     p->pack_name);
 	if (hashcmp(sha1, (unsigned char *)index_base + index_size - 40))

commit 1084b845d9d77bcb2e8255636358dd0dc35360a5
Author: Junio C Hamano <junkio@cox.net>
Date:   Tue Jan 2 11:19:05 2007 -0800

    Fix infinite loop when deleting multiple packed refs.
    
    It was stupid to link the same element twice to lock_file_list
    and end up in a loop, so we certainly need a fix.
    
    But it is not like we are taking a lock on multiple files in
    this case.  It is just that we leave the linked element on the
    list even after commit_lock_file() successfully removes the
    cruft.
    
    We cannot remove the list element in commit_lock_file(); if we
    are interrupted in the middle of list manipulation, the call to
    remove_lock_file_on_signal() will happen with a broken list
    structure pointed by lock_file_list, which would cause the cruft
    to remain, so not removing the list element is the right thing
    to do.  Instead we should be reusing the element already on the
    list.
    
    There is already a code for that in lock_file() function in
    lockfile.c.  The code checks lk->next and the element is linked
    only when it is not already on the list -- which is incorrect
    for the last element on the list (which has NULL in its next
    field), but if you read the check as "is this element already on
    the list?" it actually makes sense.  We do not want to link it
    on the list again, nor we would want to set up signal/atexit
    over and over.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/cache.h b/cache.h
index f2ec5c8..a0e9727 100644
--- a/cache.h
+++ b/cache.h
@@ -174,6 +174,7 @@ extern int refresh_cache(unsigned int flags);
 
 struct lock_file {
 	struct lock_file *next;
+	char on_list;
 	char filename[PATH_MAX];
 };
 extern int hold_lock_file_for_update(struct lock_file *, const char *path, int);
diff --git a/lockfile.c b/lockfile.c
index 2a2fea3..143d7d8 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -28,9 +28,12 @@ static int lock_file(struct lock_file *lk, const char *path)
 	sprintf(lk->filename, "%s.lock", path);
 	fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
 	if (0 <= fd) {
-		if (!lk->next) {
+		if (!lk->on_list) {
 			lk->next = lock_file_list;
 			lock_file_list = lk;
+			lk->on_list = 1;
+		}
+		if (lock_file_list) {
 			signal(SIGINT, remove_lock_file_on_signal);
 			atexit(remove_lock_file);
 		}
@@ -38,6 +41,8 @@ static int lock_file(struct lock_file *lk, const char *path)
 			return error("cannot fix permission bits on %s",
 				     lk->filename);
 	}
+	else
+		lk->filename[0] = 0;
 	return fd;
 }
 
diff --git a/refs.c b/refs.c
index 0e156c5..1549f2a 100644
--- a/refs.c
+++ b/refs.c
@@ -644,7 +644,6 @@ static int repack_without_ref(const char *refname)
 	}
 	if (!found)
 		return 0;
-	memset(&packlock, 0, sizeof(packlock));
 	fd = hold_lock_file_for_update(&packlock, git_path("packed-refs"), 0);
 	if (fd < 0)
 		return error("cannot delete '%s' from packed refs", refname);

commit e6d40d65df07059fc655fabe62fa5b575ead7815
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date:   Fri Dec 22 03:20:11 2006 +0100

    diff --check: fix off by one error
    
    When parsing the diff line starting with '@@', the line number of the
    '+' file is parsed. For the subsequent line parses, the line number
    should therefore be incremented after the parse, not before it.
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/diff.c b/diff.c
index 3315378..b003c00 100644
--- a/diff.c
+++ b/diff.c
@@ -825,8 +825,6 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
 	if (line[0] == '+') {
 		int i, spaces = 0;
 
-		data->lineno++;
-
 		/* check space before tab */
 		for (i = 1; i < len && (line[i] == ' ' || line[i] == '\t'); i++)
 			if (line[i] == ' ')
@@ -841,6 +839,8 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
 		if (isspace(line[len - 1]))
 			printf("%s:%d: white space at end: %.*s\n",
 				data->filename, data->lineno, (int)len, line);
+
+		data->lineno++;
 	} else if (line[0] == ' ')
 		data->lineno++;
 	else if (line[0] == '@') {

commit ec722203ee43beed8e4feac84af4307eb68f1ba3
Author: Junio C Hamano <junkio@cox.net>
Date:   Wed Dec 13 00:58:28 2006 -0800

    spurious .sp in manpages
    
    This cherry-picks 7ef04350 that has been applied to the 'master'
    to fix ".sp" in generated manpages.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
index ad03755..6a361a2 100644
--- a/Documentation/callouts.xsl
+++ b/Documentation/callouts.xsl
@@ -13,4 +13,18 @@
 	<xsl:apply-templates/>
 	<xsl:text>.br&#10;</xsl:text>
 </xsl:template>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+  <xsl:variable name="content">
+    <xsl:apply-templates/>
+  </xsl:variable>
+  <xsl:value-of select="normalize-space($content)"/>
+  <xsl:if test="not(ancestor::authorblurb) and
+                not(ancestor::personblurb)">
+    <xsl:text>&#10;&#10;</xsl:text>
+  </xsl:if>
+</xsl:template>
+
 </xsl:stylesheet>

Reply to: