clone 704441 -1
retitle -1 remote-helpers should be executable and in
/usr/share/git-core/contrib
tags -1 - wontfix
quit
On Mon, Apr 01, 2013 at 12:39:11AM -0700, Jonathan Nieder wrote:
> When there is interest in scripts under /usr/share/doc/git being
> executable, that is a sign that that scrip
On Mon, Apr 01, 2013 at 05:12:29PM -0700, Jonathan Nieder wrote:
> Sure. I meant to link to the bugs for these but forgot to; sorry
> about that.
>
> http://bugs.debian.org/702697 - git-remote-bzr
> http://bugs.debian.org/703864 - git-remote-hg
Aha, perfect.
> Yep, these need to be installed
retitle 687391 git: executables in contrib/ should be executable
quit
I just ran into this same issue with contrib/remote-helpers/git-remote-hg,
where all the same reasoning applies as for the contrib hooks.
There are a lot of files in contrib/. Many of them (about 60) are
marked executable in g
Hi Jonathan,
This bug appears to be fixed as of Git 1.8.1.5, the newest upstream
release. When I repeat your reproduction recipe, the 'clone' succeeds
with no error message, and tagFoo exists in the cloned repo.
-- 8< --
mkdir foo &&
(
cd foo &&
git init &&
echo A >foo.tx
found 671181 1:1.8.1.5-1
Still present in the latest upstream. Sounds like a painful bug when
it bites.
Jonathan, did you spot why Junio's patch you linked to didn't make it
upstream? (Unfortunately follow-up threads are common on the git-list
and I don't know a good way to browse for them, so
On Fri, 10 Jun 2016 15:38:53 +0900 Richard Möhn
wrote:
> This is not a good solution for everyone, but I'm now running Anki
> inside a Debian Jessie Docker container. See here for how to do it:
> http://cloj.de/AnkiDocker/
I much appreciated Richard's recipe. I found Docker rather finicky to work
Now that the author of this software has seen the light and made it
free software, it'd be great to have it in Debian.
Is there a particular obstacle known to be in the way of doing so,
or is just a matter of someone doing the work?
Thanks,
Greg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
Package: openssh-client
Version: 1:4.3p2-9etch3
Severity: normal
Tags: patch
The man page ssh-agent(1) says,
"""Authentication data need not be stored on any other machine, and
authentication passphrases never go over the network. However, the
connection to the agent is forwarded over SSH remot
Package: tightvnc-java
Version: 1.2.7
Severity: normal
The debian/copyright file in the tightvnc-java source package omits
some copyrights, some licenses, and some authors found in the source files.
It also includes an author, two copyrights, and a license that I see
no basis for in the source fi
tag 507959 patch
thanks
Below is a modified debian/copyright file that I believe fixes these
problems.
Thanks,
Greg
- debian/copyright -
This package was debianized by Ola Lundqvist <[EMAIL PROTECTED]> on
Tue, 19 Dec 2000 20:15:28 +0100.
It was downloaded from
http://www.tightv
/init.d/stop-bootlogd-single. It's
possible that some packages still use the old-fashioned practice.
Once this patch or another fix is uploaded, bugs #426465 and #505440
in initramfs-tools can be downgraded.
Greg
#! /bin/sh /usr/share/dpatch/dpatch-run
## 95_clear_environment.dpatch by Greg
[Missed 507...@b.d.o in my first reply, apologies for dupes.]
# reopen 507966 =
# thanks
Forgive me if I'm mistaken, but I believe this reply was intended for
a different bug. Your salutation appears to be for someone not named
previously on bug #507966.
Agreed that it's sometimes worthwhile to
On Sat, Oct 10, 2009 at 10:03:52PM +0200, Marc Dequènes (Duck) wrote:
> I hope current distutils tries to clean things properly when called with
> the 'clean' target, but as many projects embed ancient versions of
> setup.py, i think your patch is useful. It will be included in the next
> upload
Package: schroot
Version: 1.3.2-1
Severity: normal
Hello,
schroot suffers from a race condition where if two schroot sessions
are ended concurrently, one of them may fail to clean up properly. On
some intensely schroot-using build machines, I see this failure
regularly. The symptom looks like t
On Thu, Aug 19, 2010 at 3:21 PM, Roger Leigh wrote:
>> Currently I'm working around the issue with a flock around the body of
>> do_umount_all(). That's easy and is enough to address the problem
>> when no other umounts are happening on the system.
>
> If you would like this fix including, I'll b
Control: fixed -1 1:2.20.1-2+deb10u1
Control: fixed -1 1:2.26.2-1~bpo10+1
I tried reproducing this on the Git 2.20 in buster (with the
reproduction recipe from message #14), and it seems it
has been fixed! Same with the Git 2.26 backported from bullseye.
Instead of a fork bomb, there's an error m
Several reports on the web say that this issue is fixed by installing
Vagrant 2.0.3, from upstream's own .deb package:
https://github.com/dotless-de/vagrant-vbguest/issues/292
https://github.com/devopsgroup-io/vagrant-hostmanager/issues/256
And indeed that worked for me just now on buster, aft
Package: src:python3.8
Severity: wishlist
Hello,
Do you think you might be able to provide a backport of python3.8 in
buster-backports? I'm sure I'm not the only user of buster who would
greatly appreciate having Python 3.8 packaged for it.
Thanks, kind regards,
Greg
Control: affects -1 - src:git
On Fri, 26 Jul 2019 20:07:31 +0200 Paul Gevers wrote:
> With a recent upload of git the autopkgtest of hg-git fails in testing
> when that autopkgtest is run with the binary packages of git from
> unstable. It passes when run with only packages from testing. In tabul
Control: retitle -1 git: test suite fails on hppa, in run_with_limited_stack
Control: found -1 1:2.26.1-1
On Thu, 7 Aug 2014 16:10:20 -0400 John David Anglin
wrote:
> run_with_limited_stack git tag --contains HEAD >actual &&
> [...]
> Killed
> not ok 136 - --contains works in a deep repo
Thanks
Great! WFM on amd64, too.
> *)
> + uname_m=$(uname -m)
> + case $uname_m in
> + parisc*)
> + test_set_prereq HPPA
> + ;;
> + esac
Probably cleanest to put this outside the `case $uname_s`.
Would you mind if I send a version of this patch to the upstream
mailing list? I think that's the
On Wed, May 13, 2020 at 4:53 AM John David Anglin wrote:
> On 2020-05-13 1:44 a.m., Greg Price wrote:
> > Probably cleanest to put this outside the `case $uname_s`.
> I put it where I did because the result of uname -m is somewhat OS dependent.
>
> The config.guess script a
/757402
Based-on-patch-by: John David Anglin
Signed-off-by: Greg Price
---
t/test-lib.sh | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05..c62961a3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1467,6 +1467,14
23 matches
Mail list logo
