Debian Bug report logs - #642603
git - too many hardlinks in /usr/lib/git-core

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: git - too many hardlinks in /usr/lib/git-core

Date: Sat, 24 Sep 2011 13:57:04 +0200

Package: git
Version: 1:1.7.6.3-1
Severity: important

The git package includes many hardlinks in /usr/lib/git-core. It fails
to upgrade if this directory is located on a btrfs, which have a limit
of links to one inode in one directory.

| dpkg: error processing /var/cache/apt/archives/git_1%3a1.7.6.3-1_amd64.deb (--unpack):
|  unable to make backup link of `./usr/lib/git-core/git-send-pack' before installing new version: Too many links

Bastian

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-rt-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages git depends on:
ii  git-man          1:1.7.6.3-1     
ii  libc6            2.13-21         
ii  libcurl3-gnutls  7.21.7-3        
ii  liberror-perl    0.17-1          
ii  libexpat1        2.0.1-7         
ii  perl-modules     5.12.4-4        
ii  zlib1g           1:1.2.3.4.dfsg-3

Versions of packages git recommends:
ii  less                         444-1    
ii  openssh-client [ssh-client]  1:5.9p1-1
ii  patch                        2.6.1-2  
ii  rsync                        3.0.8-1  

Versions of packages git suggests:
pn  git-arch                              <none>
pn  git-cvs                               <none>
pn  git-daemon-run | git-daemon-sysvinit  <none>
pn  git-doc                               <none>
pn  git-el                                <none>
pn  git-email                             <none>
pn  git-gui                               <none>
pn  git-svn                               <none>
pn  gitk                                  <none>
pn  gitweb                                <none>

-- no debconf information

Message #10 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Bastian Blank <waldi@debian.org>

Cc: 642603@bugs.debian.org

Subject: Re: git - too many hardlinks in /usr/lib/git-core

Date: Sat, 24 Sep 2011 14:13:48 -0500

Hi,

Bastian Blank wrote:

> The git package includes many hardlinks in /usr/lib/git-core. It fails
> to upgrade if this directory is located on a btrfs, which have a limit
> of links to one inode in one directory.
>
> | dpkg: error processing /var/cache/apt/archives/git_1%3a1.7.6.3-1_amd64.deb (--unpack):
> |  unable to make backup link of `./usr/lib/git-core/git-send-pack' before installing new version: Too many links

Yuck.  As a reminder to myself: dpkg upgrades a package in three
stages:

 1. Extract the new version of each file to <foo>.dpkg-new,
    and link the old version to <foo>.dpkg-tmp so the next step can be
    backed out if it is interrupted.
 2. fsync() and rename() the new files into place.
 3. Unlink the backed-up old versions.

This report is about a consequence of step 1 --- it doubles the number
of links to each file.  This makes it easy to run into filesystem
limits.

Unfortunately, it's not clear to me what that limit actually _is_ for
btrfs.  Here's what I know.

 i.   "stat $(git --exec-path)git" informs me it has 106 links at the
       moment (so 212 in the middle of an upgrade).

 i.   _POSIX_LINK_MAX is 8.  If we care about that level of portability
      (and we shouldn't), then Debian packages would have at most
      four links to each file.

 ii.  LINK_MAX in linux/limits.h is 127.  UFS_LINK_MAX and EXT2_LINK_MAX
      are 32000.

 iii. btrfs's limit is on number of links to a file in a single
      directory.  Spreading links over multiple directories avoids it.
      Whatever the actual limit _is_ (I couldn't find clear numbers),
      upstream seems to consider it a problem and would probably be
      open to patches fixing it.

      http://thread.gmane.org/gmane.comp.file-systems.btrfs/6285/focus=6354

 iv.  Git's "make install" punts and falls back to "ln -s" when
      attempts to make a hard link fail.  Maybe the git packaging
      should have been doing the same, by writing the links in
      postinst instead of asking dpkg to take care of it.  This would
      also allow some minor space savings since /usr/bin/git and
      /usr/lib/git-core/git-add could be links to the same inode on
      installations where they happen to be on the same filesystem.

 v.   dpkg could learn to cap the number of links at (<packaged number
      of links> + 1) instead of (<packaged number> * 2) by making only
      one backup link for each old inode, but I doubt that is worth it
      (it would require a new data structure to maintain the inode ->
      paths mapping, to tell which paths are linked).

Corrections?  What do you think?

Thanks,
Jonathan

Message #15 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 642603@bugs.debian.org

Subject: Re: git - too many hardlinks in /usr/lib/git-core

Date: Sun, 25 Sep 2011 13:03:33 +0200

On Sat, Sep 24, 2011 at 02:13:48PM -0500, Jonathan Nieder wrote:
> Unfortunately, it's not clear to me what that limit actually _is_ for
> btrfs.  Here's what I know.
> 
>  iii. btrfs's limit is on number of links to a file in a single
>       directory.  Spreading links over multiple directories avoids it.
>       Whatever the actual limit _is_ (I couldn't find clear numbers),
>       upstream seems to consider it a problem and would probably be
>       open to patches fixing it.

They intend to fix it, but this needs a format bump, something they do
not lightly.

The real limit is something like 4096 / ($len_filename + 8) or so.

> Corrections?  What do you think?

Use symlinks.

Bastian

-- 
Captain's Log, star date 21:34.5...

Message #20 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Antti Kultanen <debbugs@pyksy.fi>

Cc: 642603@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: git: unable to make backup link [...] Too many links

Date: Wed, 12 Oct 2011 04:04:43 -0500

severity 642603 serious
merge 642603 645009
tags 642603 + patch pending
quit

Antti Kultanen wrote:
> On Tue, 11 Oct 2011, Jonathan Nieder wrote:

>> Do you use btrfs?
>
> Yes. Yes I do.
>
> What's going on?

See http://bugs.debian.org/642603 for details.  How about this patch?

-- >8 --
Subject: debian: use symlinks instead of hardlinks for builtin aliases

dpkg upgrades a package in three stages:

 1. Extract the new version of each file to <foo>.dpkg-new,
    and link the old version to <foo>.dpkg-tmp so the next step can be
    backed out if it is interrupted.
 2. fsync() and rename() the new files into place.
 3. Unlink the backed-up old versions.

The git package includes many hardlinks in /usr/lib/git-core. It
fails to upgrade in step 1 if this directory is located on a btrfs,
which have a limit of links to one inode in one directory:

| dpkg: error processing /var/cache/apt/archives/git_1%3a1.7.6.3-1_amd64.deb (--unpack):
|  unable to make backup link of `./usr/lib/git-core/git-send-pack' before installing new version: Too many links

At least within git itself, most uses of builtins use the non-dashed
form ("git <command>"), so effort spent optimizing the dashed forms
(e.g., by using hardlinks instead of symlinks) is mostly a waste.
Let's just use symlinks here.

Requested-by: Bastian Blank <waldi@debian.org>
Fixes: http://bugs.debian.org/642603
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 debian/changelog                                   |    4 +
 ...d-a-knob-to-turn-off-hardlinks-within-same.diff |   84 ++++++++++++++++++++
 debian/rules                                       |    3 +-
 3 files changed, 90 insertions(+), 1 deletions(-)
 create mode 100644 debian/diff/0018-Makefile-add-a-knob-to-turn-off-hardlinks-within-same.diff

diff --git a/debian/changelog b/debian/changelog
index 41c3ad7f..8e677616 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -15,6 +15,10 @@ git (1:1.7.7-1.1) unstable; urgency=low
         GNU/kFreeBSD
       * Makefile: fix permissions of mergetools/ when building from
         source extracted with permissive umask
+    * 0018-Makefile-add-a-knob-to-turn-off-hardlinks-...diff: new;
+      Makefile: add a knob to disable hardlinks within bindir and
+      gitexecdir.
+  * debian/rules: add NO_HARDLINKS=1 to OPTS (closes: #642603).
 
   [ Simon Chopin ]
   * debian/git.postinst: fix fresh install contrib/hooks cleaning
diff --git a/debian/diff/0018-Makefile-add-a-knob-to-turn-off-hardlinks-within-same.diff b/debian/diff/0018-Makefile-add-a-knob-to-turn-off-hardlinks-within-same.diff
new file mode 100644
index 00000000..222dcbf3
--- /dev/null
+++ b/debian/diff/0018-Makefile-add-a-knob-to-turn-off-hardlinks-within-same.diff
@@ -0,0 +1,84 @@
+From b58698d5c82baa52fb9aaba10c06152ad6b836d1 Mon Sep 17 00:00:00 2001
+From: Jonathan Nieder <jrnieder@gmail.com>
+Date: Wed, 12 Oct 2011 03:38:42 -0500
+Subject: Makefile: add a knob to turn off hardlinks within same directory
+
+The git builtins in $(gitexecdir) are implemented as hard links to a
+single git binary by default, so even the overhead of symlink
+resolution is not needed to run them.  However, the trick can be
+harmful, in two cases:
+
+ - on Windows, some tools to estimate directory size hugely
+   overestimate the size of git (each hardlink counts as taking up the
+   same amount of space as git.exe)
+
+ - various filesystems have limits on the number of hardlinks that
+   can be made to a particular file --- Linux's LINK_MAX is 127,
+   _POSIX_LINK_MAX is 8, and btrfs has a limit of 4096 /
+   ($len_filename + 8) or so links to a given inode in a single
+   directory.
+
+Normally that second case is not a problem (when ln fails, "make
+install" falls back to "ln -s"), but if git is tar'ed up on one
+filesystem and then extracted on a more limited one, it can result in
+"Too many links" errors.
+
+Nowadays people are encouraged to (and typically do) run builtins
+using the "git" command name directly rather than those dashed forms
+in scripts, making the use of hardlinks for the dashed forms a
+somewhat pointless optimization.  Introduce a new knob to allow people
+to turn it off with a simple "make install NO_HARDLINKS=YesPlease".
+
+Typically someone using this setting would want to set
+NO_CROSS_DIRECTORY_HARDLINKS, too, but that is not enforced, so you
+can make $(bindir)/git and $(gitexecdir)/git into hardlinks to the
+same inode and still make sure your tarball avoids the btrfs limits if
+you want.
+
+Requested-by: Bastian Blank <waldi@debian.org>
+Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
+---
+ Makefile |    7 +++++++
+ 1 files changed, 7 insertions(+), 0 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 9afdcf2..ab64ff4 100644
+--- a/Makefile
++++ b/Makefile
+@@ -226,6 +226,10 @@ all::
+ # Define NO_CROSS_DIRECTORY_HARDLINKS if you plan to distribute the installed
+ # programs as a tar, where bin/ and libexec/ might be on different file systems.
+ #
++# Define NO_HARDLINKS if you plan to distribute the installed programs as a tar
++# that might be extracted on a filesystem like btrfs that does not cope well
++# with many links to one inode in one directory.
++#
+ # Define USE_NED_ALLOCATOR if you want to replace the platforms default
+ # memory allocators with the nedmalloc allocator written by Niall Douglas.
+ #
+@@ -2326,12 +2330,14 @@ endif
+ 	} && \
+ 	for p in $(filter $(install_bindir_programs),$(BUILT_INS)); do \
+ 		$(RM) "$$bindir/$$p" && \
++		test -z "$(NO_HARDLINKS)" && \
+ 		ln "$$bindir/git$X" "$$bindir/$$p" 2>/dev/null || \
+ 		ln -s "git$X" "$$bindir/$$p" 2>/dev/null || \
+ 		cp "$$bindir/git$X" "$$bindir/$$p" || exit; \
+ 	done && \
+ 	for p in $(BUILT_INS); do \
+ 		$(RM) "$$execdir/$$p" && \
++		test -z "$(NO_HARDLINKS)" && \
+ 		ln "$$execdir/git$X" "$$execdir/$$p" 2>/dev/null || \
+ 		ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
+ 		cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
+@@ -2339,6 +2345,7 @@ endif
+ 	remote_curl_aliases="$(REMOTE_CURL_ALIASES)" && \
+ 	for p in $$remote_curl_aliases; do \
+ 		$(RM) "$$execdir/$$p" && \
++		test -z "$(NO_HARDLINKS)" && \
+ 		ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ 		ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ 		cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
+-- 
+1.7.7
+
diff --git a/debian/rules b/debian/rules
index 243b1335..a18ba26a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,8 @@ OPTS =NO_OPENSSL=1 prefix=/usr gitexecdir=/usr/lib/git-core \
   INSTALLDIRS=vendor \
   NO_PYTHON=1 \
   USE_SRV_RR=1 \
-  THREADED_DELTA_SEARCH=1 NO_CROSS_DIRECTORY_HARDLINKS=1 \
+  THREADED_DELTA_SEARCH=1 \
+  NO_CROSS_DIRECTORY_HARDLINKS=1 NO_HARDLINKS=1 \
   DEFAULT_PAGER=pager DEFAULT_EDITOR=editor
 DOC_OPTS =prefix=/usr htmldir=/usr/share/doc/git/html \
   ASCIIDOC8=1 ASCIIDOC_NO_ROFF=1
-- 
1.7.7

Message #31 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Antti Kultanen <debbugs@pyksy.fi>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 642603@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: git: unable to make backup link [...] Too many links

Date: Wed, 12 Oct 2011 14:53:51 +0300 (EEST)

On Wed, 12 Oct 2011, Jonathan Nieder wrote:
> See http://bugs.debian.org/642603 for details.  How about this patch?

Unfortunately it does not fix the problem. Still failing but with a 
different file.

-8<-
# dpkg -i git_1.7.7-1_amd64.deb
(Reading database ... 433269 files and directories currently installed.)
Preparing to replace git 1:1.7.6.3-1 (using git_1.7.7-1_amd64.deb) ...
Unpacking replacement git ...
dpkg: error processing git_1.7.7-1_amd64.deb (--install):
 unable to make backup link of `./usr/lib/git-core/git-merge-ours' before installing new version: Too many links
Errors were encountered while processing:
 git_1.7.7-1_amd64.deb
zsh: exit 1     dpkg -i git_1.7.7-1_amd64.deb
-8<-

-- 
 // http://www.pyksy.fi/ // pyksy @IrcNet //

Message #36 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Antti Kultanen <debbugs@pyksy.fi>

Cc: 642603@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: git: unable to make backup link [...] Too many links

Date: Wed, 12 Oct 2011 07:43:21 -0500

Antti Kultanen wrote:

> # dpkg -i git_1.7.7-1_amd64.deb
> (Reading database ... 433269 files and directories currently installed.)
> Preparing to replace git 1:1.7.6.3-1 (using git_1.7.7-1_amd64.deb) ...
> Unpacking replacement git ...
> dpkg: error processing git_1.7.7-1_amd64.deb (--install):
>  unable to make backup link of `./usr/lib/git-core/git-merge-ours' before installing new version: Too many links

Ah, thanks.

It should be possible to reproduce the bug in 1.7.6.3-1 that that
patch fixed by simply reinstalling git 1.7.6.3-1 --- it is the version
of git being replaced that is relevant.  The simplest workaround to
recover is to remove git and then install the new version (and then to
confirm the fix by reinstalling it).

To allow people to upgrade from the broken state without removing git
in between, we'll need to remove some of the hard links _before_
upgrading (i.e., in "preinst upgrade").  I don't know how to feel
about that.  A part of me wants to think:

 - the low and idiosyncratic hardlink limit is a btrfs bug.

 - btrfs is effectively experimental still.  Generally speaking, btrfs
   users probably know how to recover from this kind of thing (though
   they may not be happy about having to do it).

Unfortunately, this bug didn't just appear in git recently, though
it's only been reported recently.  It affects upgrades from squeeze.
The triggering change was in dpkg 1.16.1 ("Defer hardlink renames").

So it's probably worth a workaround.  Here's some pseudocode to
explain a possible way to do that.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 debian/changelog   |    6 ++++--
 debian/git.preinst |   30 ++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 080286a3..f69995bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,8 +18,10 @@ git (1:1.7.7-2) unstable; urgency=low
     * 0018-Makefile-add-a-knob-to-turn-off-hardlinks-...diff: new;
       Makefile: add a knob to disable hardlinks within bindir and
       gitexecdir.
-  * debian/rules: add NO_HARDLINKS=1 to OPTS (thx Bastian Blank;
-    closes: #642603).
+  * debian/rules: add NO_HARDLINKS=1 to OPTS (thx Bastian Blank).
+  * debian/git.preinst: if /usr/lib/git-core uses btrfs, convert
+    builtins to symlinks before upgrade from git <= 1:1.7.7-1 (thx
+    Antti Kultanen; closes: #642603).
   * debian/rules: do not rely on umask to set contrib permissions.
   * update debian/copyright.
   * debian/watch, debian/copyright: point to code.google.com for now.
diff --git a/debian/git.preinst b/debian/git.preinst
index f3502d96..8fb7feb6 100644
--- a/debian/git.preinst
+++ b/debian/git.preinst
@@ -24,6 +24,14 @@ rm_conffile () {
 	fi
 }
 
+is_btrfs () {
+	path=$1
+
+	fs=$(stat -f -c%t "$path")
+	# value from linux/magic.h
+	test "$fs" = 9123683e
+}
+
 # Now /etc/emacs/site-start.d/50git-core.el belongs to the
 # git-el package.  If we are upgrading from a pre- 1.7.4.1-2~
 # version then git-el is at most unpacked (so its version
@@ -31,3 +39,25 @@ rm_conffile () {
 # an unchanged 50git-core.el file without danger.
 #
 rm_conffile /etc/emacs/site-start.d/50git-core.el "$1" "$2"
+
+# Git versions before 1.7.7-2 kept about 100 hard links to
+# /usr/lib/git-core/git at /usr/lib/git-core/git-* to support old
+# scripts.  Btrfs doesn't like to have more than 128 or so links
+# to a single inode in a given directory.  dpkg versions since
+# 1.16.1 temporarily double the number of hard links to an inode
+# when upgrading a package.  Boom.
+#
+# Get rid of the hard links before upgrading to avoid trouble.
+if test "$1" = upgrade &&
+   dpkg --compare-versions "$2" lt-nl '1:1.7.7-2' &&
+   is_btrfs /usr/lib/git-core; then
+	refinode=$(stat -c%i /usr/lib/git-core/git)
+	for f in /usr/lib/git-core/*; do
+		test "$f" != /usr/lib/git-core/git || continue
+		inode=$(stat -c%i "$f")
+		test "$inode" = "$refinode" || continue
+		rm -f "$f.dpkg-tmp"
+		ln -s git "$f.dpkg-tmp"
+		mv -f "$f.dpkg-tmp" "$f"
+	done
+fi
-- 
1.7.7

Message #41 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Antti Kultanen <debbugs@pyksy.fi>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 642603@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: git: unable to make backup link [...] Too many links

Date: Wed, 12 Oct 2011 16:17:25 +0300 (EEST)

On Wed, 12 Oct 2011, Jonathan Nieder wrote:

> Antti Kultanen wrote:
>>  unable to make backup link of `./usr/lib/git-core/git-merge-ours' before installing new version: Too many links
> It should be possible to reproduce the bug in 1.7.6.3-1 that that
> patch fixed by simply reinstalling git 1.7.6.3-1 --- it is the version
> of git being replaced that is relevant.

You are correct. Reinstalling 1.7.6.3-1 over 1.7.6.3-1 does reproduce 
the problem.

>  The simplest workaround to
> recover is to remove git and then install the new version (and then to
> confirm the fix by reinstalling it).

Also correct. Removing git git-core git-man 1.7.6.3-1 and then 
installing 1.7.7-1 seems to work fine.


No comment on the btrfs issue :-) but thanks for your help and support.

-- 
 // http://www.pyksy.fi/ // pyksy @IrcNet //

Message #46 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <Martin@lichtvoll.de>

To: Chris Mason <chris.mason@oracle.com>, linux-btrfs@vger.kernel.org, sliedes@cc.hut.fi

Cc: 642603@bugs.debian.org

Subject: Re: Number of hard links limit

Date: Wed, 12 Oct 2011 19:34:06 +0200

Hello,

Am Freitag, 6. August 2010 schrieb Chris Mason:
> On Fri, Aug 06, 2010 at 02:30:39PM +0300, Sami Liedes wrote:
> > On Tue, Aug 03, 2010 at 12:22:14AM +0200, Oystein Viggen wrote:
> > > IIRC, the limit on hard links is per directory.  That is, if you
> > > put each hard link into its own directory, there's basically no
> > > limit to the amount of hard links you can make to one file.
> > 
> > Yes, that's always pointed out in these threads. Still, it seems to
> > be breaking real use cases also beyond backuppc (someone mentioned
> > installing some Gentoo package).
> 
> Right, this will get fixed in a future btrfs update.  We're focusing on
> stability with what we have right now, but I do agree we should have
> done this link back reference design differently.

What is the status of fixing the limits of hardlinks in BTRFS?

It is now easy to hit on Debian systems that have git package installed:

Preparing to replace git 1:1.7.6.3-1 (using .../git_1%3a1.7.7-1_amd64.deb) 
...
Unpacking replacement git ...
dpkg: error processing /var/cache/apt/archives/git_1%3a1.7.7-1_amd64.deb 
(--unpack):
 unable to make backup link of `./usr/lib/git-core/git-send-pack' before 
installing new version: Too many links
configured to not write apport reports
                                      dpkg-deb: error: subprocess paste 
was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/git_1%3a1.7.7-1_amd64.deb


also see:

git - too many hardlinks in /usr/lib/git-core
http://bugs.debian.org/642603


While above bug might be fixed by using symlinks or by some other 
workaround, I think this limit will be hit more likely as BTRFS matures. I 
think it should be fixed, before the experimental flag of BTRFS is removed.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Message #51 received at 642603-close@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: 642603-close@bugs.debian.org

Subject: Bug#642603: fixed in git 1:1.7.7-2

Date: Thu, 13 Oct 2011 09:02:26 +0000

Source: git
Source-Version: 1:1.7.7-2

We believe that the bug you reported is fixed in the latest version of
git, which is due to be installed in the Debian FTP archive:

git-all_1.7.7-2_all.deb
  to main/g/git/git-all_1.7.7-2_all.deb
git-arch_1.7.7-2_all.deb
  to main/g/git/git-arch_1.7.7-2_all.deb
git-core_1.7.7-2_all.deb
  to main/g/git/git-core_1.7.7-2_all.deb
git-cvs_1.7.7-2_all.deb
  to main/g/git/git-cvs_1.7.7-2_all.deb
git-daemon-run_1.7.7-2_all.deb
  to main/g/git/git-daemon-run_1.7.7-2_all.deb
git-daemon-sysvinit_1.7.7-2_all.deb
  to main/g/git/git-daemon-sysvinit_1.7.7-2_all.deb
git-doc_1.7.7-2_all.deb
  to main/g/git/git-doc_1.7.7-2_all.deb
git-el_1.7.7-2_all.deb
  to main/g/git/git-el_1.7.7-2_all.deb
git-email_1.7.7-2_all.deb
  to main/g/git/git-email_1.7.7-2_all.deb
git-gui_1.7.7-2_all.deb
  to main/g/git/git-gui_1.7.7-2_all.deb
git-man_1.7.7-2_all.deb
  to main/g/git/git-man_1.7.7-2_all.deb
git-svn_1.7.7-2_all.deb
  to main/g/git/git-svn_1.7.7-2_all.deb
git_1.7.7-2.diff.gz
  to main/g/git/git_1.7.7-2.diff.gz
git_1.7.7-2.dsc
  to main/g/git/git_1.7.7-2.dsc
gitk_1.7.7-2_all.deb
  to main/g/git/gitk_1.7.7-2_all.deb
gitweb_1.7.7-2_all.deb
  to main/g/git/gitweb_1.7.7-2_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 642603@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gerrit Pape <pape@smarden.org> (supplier of updated git package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 13 Oct 2011 00:04:49 +0000
Source: git
Binary: git git-man git-core git-doc git-arch git-cvs git-svn git-email git-daemon-run git-daemon-sysvinit git-gui gitk git-el gitweb git-all
Architecture: all source
Version: 1:1.7.7-2
Distribution: unstable
Urgency: low
Maintainer: Gerrit Pape <pape@smarden.org>
Changed-By: Gerrit Pape <pape@smarden.org>
Description: 
 git        - fast, scalable, distributed revision control system
 git-all    - fast, scalable, distributed revision control system (all subpacka
 git-arch   - fast, scalable, distributed revision control system (arch interop
 git-core   - fast, scalable, distributed revision control system (obsolete)
 git-cvs    - fast, scalable, distributed revision control system (cvs interope
 git-daemon-run - fast, scalable, distributed revision control system (git-daemon s
 git-daemon-sysvinit - fast, scalable, distributed revision control system (git-daemon s
 git-doc    - fast, scalable, distributed revision control system (documentatio
 git-el     - fast, scalable, distributed revision control system (emacs suppor
 git-email  - fast, scalable, distributed revision control system (email add-on
 git-gui    - fast, scalable, distributed revision control system (GUI)
 git-man    - fast, scalable, distributed revision control system (manual pages
 git-svn    - fast, scalable, distributed revision control system (svn interope
 gitk       - fast, scalable, distributed revision control system (revision tre
 gitweb     - fast, scalable, distributed revision control system (web interfac
Closes: 642603 645005
Changes: 
 git (1:1.7.7-2) unstable; urgency=low
 .
   [ Jonathan Nieder ]
   * debian/git.postinst: check if /usr/share/doc/git/contrib/hooks is a
     symlink before changing it to one (thx Євгеній Мещеряков; closes:
     #645005).
   * debian/diff:
     * 0001-ident-check-etc-mailname-if-author-email-is-unknown.diff,
       0007-Makefile-do-not-use-setgid-bit-on-...diff: remove; obsolete.
     * 0002...0006, 0008...0015: rename to 0005-*, ..., 0017-*.
     * 0001...0004: new from the upstream 'master' branch:
       * ident: check /etc/mailname if email is unknown
       * ident: do not retrieve default ident when unnecessary
       * init --shared: do not set setgid bit on directories on
         GNU/kFreeBSD
       * Makefile: fix permissions of mergetools/ when building from
         source extracted with permissive umask
     * 0018-Makefile-add-a-knob-to-turn-off-hardlinks-...diff: new;
       Makefile: add a knob to disable hardlinks within bindir and
       gitexecdir.
   * debian/rules: add NO_HARDLINKS=1 to OPTS (thx Bastian Blank;
     closes: #642603).
   * debian/rules: do not rely on umask to set contrib permissions.
   * update debian/copyright.
   * debian/watch, debian/copyright: point to code.google.com for now.
     The upstream tarballs haven't been added back to kernel.org yet.
   * debian/changelog.upstream, debian/versions.upstream: include
     v1.7.6.4.
 .
   [ Simon Chopin ]
   * debian/git.postinst: fix fresh install contrib/hooks cleaning
     (#645005).
Checksums-Sha1: 
 cb2a52961ce18598435bdc11dc8b8e3aa67857cb 1874 git_1.7.7-2.dsc
 579329ddf0bc32dabbba6ac23feebfad44204859 469073 git_1.7.7-2.diff.gz
 5c6e84bf2afb3a780e88b9eea45c93eabe99625a 2122310 git-doc_1.7.7-2_all.deb
 7be4a3f99100a898478090bed3b7f9d08f5f90a7 432186 git-arch_1.7.7-2_all.deb
 11008c34ea6273cab3672d2cb8a44b33489b5619 501482 git-cvs_1.7.7-2_all.deb
 7044afb15d1ee59c509bd359e4f2ffba64d42598 487510 git-svn_1.7.7-2_all.deb
 bf44a23bc41c85a3e3fbaa0a27127631873f13fa 419398 git-daemon-run_1.7.7-2_all.deb
 9a2fc74e7961779f1be2803fa558eb55c91f5915 421000 git-daemon-sysvinit_1.7.7-2_all.deb
 47d27da9f5d1caebf0b7002a931430d1fba6e506 437472 git-email_1.7.7-2_all.deb
 462183cb3ed3db2ade3bf24034f92ed972e8bce0 694430 git-gui_1.7.7-2_all.deb
 3bd3c410ef5938121837162aa1dbb2285e3fac2b 543028 gitk_1.7.7-2_all.deb
 3fcd80b70f86b7668ea1e34b58b46571ac84892c 427896 gitweb_1.7.7-2_all.deb
 4563d8fa23d8272a315343b579c4cc9335f4a1b7 417710 git-all_1.7.7-2_all.deb
 3c1514045b1f4f03b25d537136a8630bf119ff5a 1328 git-core_1.7.7-2_all.deb
 ee68b9b01481b6a7152c98e1ae3f2b4b0fd9c2df 441494 git-el_1.7.7-2_all.deb
 f060aed024a6142b0e317fee00275264eed35049 998352 git-man_1.7.7-2_all.deb
Checksums-Sha256: 
 53e41f2bbb4e510125035e61542c0830f3acf979aab79f8091d1a724b714c96f 1874 git_1.7.7-2.dsc
 38da6c3114f01664487ea98895df6bb9e7996436f30886315eedd85822ff97af 469073 git_1.7.7-2.diff.gz
 5df8f5a5505521d68c28f5944c1f8106481d8972c9056db482e2028a691e3bd9 2122310 git-doc_1.7.7-2_all.deb
 3096133e8c2204d9af4eb22eb6172e86362e74c53f6bbc9f162b2c8e5feff44e 432186 git-arch_1.7.7-2_all.deb
 7fffa90837d74121f786f03b08ad17059927657b015c526a1b08b42ecc75b1ef 501482 git-cvs_1.7.7-2_all.deb
 3986ae7c7168b0d2c69847797904e334255e9a3f6849a9944d95f1b2d08e9b47 487510 git-svn_1.7.7-2_all.deb
 ea1ed58ccda374f27bb5b68da744cfb641760a994201135ae37b565ef7565086 419398 git-daemon-run_1.7.7-2_all.deb
 45aba408f8a9f0858b78eea980c3eebd11a18f2450e538cea34b280e6a2dde5c 421000 git-daemon-sysvinit_1.7.7-2_all.deb
 75695a450dfa904ecf291be8b42497688a51a7f186b9702680510dcbf472086b 437472 git-email_1.7.7-2_all.deb
 3b2b7850586d6a071dbd29cc9433f5e16cab55fb5ddf015d39f8a8eef40852cc 694430 git-gui_1.7.7-2_all.deb
 e4474784d350fb40df74b543860a8c86111cfe63206013835a23d0c66107904c 543028 gitk_1.7.7-2_all.deb
 8d2eff811bbb30ad0903a7f4c7d0175ba5c86fe502d92461ea26f344168658d5 427896 gitweb_1.7.7-2_all.deb
 e1cd95e479cbfa3ac56174de86d51dd51ff0f7742998ae42df6da2e1f9c7616a 417710 git-all_1.7.7-2_all.deb
 5fe09452fa395c1ccc63b96436cc709daf3064e2a8aad55cca12441e1240b194 1328 git-core_1.7.7-2_all.deb
 22be54a2929a7d95001f26eb7fdbfec464a4995b926123a32ab9cc3de3eb21bf 441494 git-el_1.7.7-2_all.deb
 db8d70d78891e98c2c5378cfa4c479ebbb64e6947c73a2c7cb7ce6302e8b4066 998352 git-man_1.7.7-2_all.deb
Files: 
 93c0101227b1f339e3b6a66689c33a3e 1874 vcs optional git_1.7.7-2.dsc
 8129352ed8e59da450d4230463e48d4d 469073 vcs optional git_1.7.7-2.diff.gz
 b3f9b90fc1986ee8cbb100187c557453 2122310 doc optional git-doc_1.7.7-2_all.deb
 4141b96b6b74b2698b9d3821bfbfa2f4 432186 vcs optional git-arch_1.7.7-2_all.deb
 23aecd293f6a114bb298d50f0974b001 501482 vcs optional git-cvs_1.7.7-2_all.deb
 21aa7178757fc6f32af61e65b8aca3b6 487510 vcs optional git-svn_1.7.7-2_all.deb
 c38d2c96fdbb7561176c64c58971f6ba 419398 vcs optional git-daemon-run_1.7.7-2_all.deb
 e2ddd26d90fdbf5e4ac893c13d14fea9 421000 vcs optional git-daemon-sysvinit_1.7.7-2_all.deb
 c91059418c33401ef1edbb9be73aebe6 437472 vcs optional git-email_1.7.7-2_all.deb
 446e9a702cfdee7c573c390bb406d508 694430 vcs optional git-gui_1.7.7-2_all.deb
 4e384c7fa8e8a190b5131db6d553a9d8 543028 vcs optional gitk_1.7.7-2_all.deb
 4f2a173e4353400f903d6abc62daf534 427896 vcs optional gitweb_1.7.7-2_all.deb
 ce5386065135d2fe3a1812c470aa11fe 417710 vcs optional git-all_1.7.7-2_all.deb
 79165f6686fbcae927c73dcddd9b3d95 1328 vcs optional git-core_1.7.7-2_all.deb
 c07f7ce24dd88b5b37378c66e0e4131e 441494 vcs optional git-el_1.7.7-2_all.deb
 7e7c6a20cd16ba63981c005a0712404b 998352 doc optional git-man_1.7.7-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6Wg8kACgkQGJoyQbxwpv+5dACff4El0s5SrnkyxxISeUTp58Bi
L3cAnijEX2rzcBgSaMx+aKO5I+z+ABwl
=mn+h
-----END PGP SIGNATURE-----

Message #61 received at 642603@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 642603@bugs.debian.org

Subject: Re: git: unable to make backup link [...] Too many links

Date: Sat, 15 Oct 2011 02:06:16 -0500

clone 642603 -1
retitle -1 [btrfs] git fails to upgrade from squeeze: unable to make backup link: Too many links
found -1 git/1:1.7.7-2
quit

Jonathan Nieder wrote:

> To allow people to upgrade from the broken state without removing git
> in between, we'll need to remove some of the hard links _before_
> upgrading (i.e., in "preinst upgrade").

Therefore cloning the bug.

Send a report that this bug log contains spam.