Bug#994954: virtualenv in buster fails with 404 on https://pypi.org/simple/pkg-resources/

[Anders Kaseorg]

Package: python3-virtualenv
Version: 15.1.0+ds-2
Severity: grave
Justification: renders package unusable

virtualenv in Debian 10 buster recently (today, I think) stopped working for 
both versions of Python. It now fails with “EnvironmentError: 404 Client Error: 
Not Found for url: https://pypi.org/simple/pkg-resources/”. This seems to be 
due to this Debian patch:

https://sources.debian.org/src/python-virtualenv/15.1.0+ds-2/debian/patches/use-wheels.patch/

I’m not sure why it worked before; perhaps there was some server-side 
workaround that was recently removed. One can pass ‘virtualenv --no-download’ 
as a workaround, though this may not be possible if virtualenv is invoked in 
the middle of a script download by some third-party installer.

# virtualenv /tmp/v
Running virtualenv with interpreter /usr/bin/python2
New python executable in /tmp/v/bin/python2
Not overwriting existing python script /tmp/v/bin/python (you must use 
/tmp/v/bin/python2)
Installing setuptools, pkg_resources, pip, wheel...
  Complete output from command /tmp/v/bin/python2 - setuptools pkg_resources 
pip wheel:
  Looking in links: /usr/lib/python3/dist-packages, /usr/share/python-wheels/
Collecting setuptools
  Downloading 
https://files.pythonhosted.org/packages/e1/b7/182161210a13158cd3ccc41ee19aadef54496b74f2817cc147006ec932b4/setuptools-44.1.1-py2.py3-none-any.whl
 (583kB)
Collecting pkg_resources
Could not install packages due to an EnvironmentError: 404 Client Error: Not 
Found for url: https://pypi.org/simple/pkg-resources/


...Installing setuptools, pkg_resources, pip, wheel...done.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 2379, in 
main()
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 724, in main
symlink=options.symlink)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 996, in 
create_environment
download=download,
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 926, in 
install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 817, in 
call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /tmp/v/bin/python2 - setuptools pkg_resources pip wheel failed 
with error code 1

# virtualenv --python=python3 /tmp/v
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/v/bin/python3
Also creating executable in /tmp/v/bin/python
Installing setuptools, pkg_resources, pip, wheel...
  Complete output from command /tmp/v/bin/python3 - setuptools pkg_resources 
pip wheel:
  Looking in links: /usr/lib/python3/dist-packages, /usr/share/python-wheels/
Collecting setuptools
  Downloading 
https://files.pythonhosted.org/packages/4e/2e/f8e006dbaaa46ed1e762c287585b92476deb8d3ccb79b720ed3b86bc6113/setuptools-58.1.0-py3-none-any.whl
 (816kB)
Collecting pkg_resources
Could not install packages due to an EnvironmentError: 404 Client Error: Not 
Found for url: https://pypi.org/simple/pkg-resources/


...Installing setuptools, pkg_resources, pip, wheel...done.
Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 11, in 
load_entry_point('virtualenv==15.1.0', 'console_scripts', 'virtualenv')()
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 724, in main
symlink=options.symlink)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 996, in 
create_environment
download=download,
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 926, in 
install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 817, in 
call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /tmp/v/bin/python3 - setuptools pkg_resources pip wheel failed 
with error code 1

Bug#894667: beep: CVE-2018-0492

[Anders Kaseorg]

On Thu, 5 Apr 2018, Tony Hoyle wrote:
> It's concerning that the holeybeep.ninja site exploited an unrelated 
> fault for 'fun' without apparently telling anyone.

To be fair, they told you exactly what was going to happen: “Apply this 
[patch] as soon as possible using the following command: patch -p1 < 
beep.diff. A short beep should be heard if all hunks are applied 
successfully.”

Anders

Bug#857890: reproducible but weird

[Anders Kaseorg]

On Thu, 16 Mar 2017, Adam Borowski wrote:
> The bug does reproduce for me on _some_ setups, all in regular sbuild:
> 
> successful: amd64
> FTBFS:  armhf
> FTBFS:  armhf qemu-user on amd64
> successful: armhf on arm64
> 
> The timezone is the same, so is schroot/sbuild configuration, all what
> differs are architectures and kernel versions.
> 
> And it's consistent for repeats.

Can you show a failing build log?

Anders

Bug#857890: git: FTBFS: debian/rules:55: recipe for target 'override_dh_auto_test-arch' failed

[Anders Kaseorg]

The actual failures shown in your build log, copied below, are in 
t0006-date.sh.  I can’t reproduce this using the locale and timezone 
settings listed at 
https://tests.reproducible-builds.org/debian/index_variations.html, but 
perhaps you’re trying something new?  Could there be something peculiar 
about your build environment where, for example, TZ=UTC leads programs to 
conclude there’s a 1 hour offset from UTC?

Anders

make[4]: Entering directory '«BUILDDIR»/t'
*** t0006-date.sh ***
Initialized empty Git repository in «BUILDDIR»/t/trash 
directory.t0006-date/.git/
expecting success: 
test-date relative 1251659995 >actual &&
test_i18ncmp expect actual

ok 1 - relative date (5 seconds ago)

expecting success: 
test-date relative 1251659700 >actual &&
test_i18ncmp expect actual

ok 2 - relative date (5 minutes ago)

expecting success: 
test-date relative 1251642000 >actual &&
test_i18ncmp expect actual

ok 3 - relative date (5 hours ago)

expecting success: 
test-date relative 1251228000 >actual &&
test_i18ncmp expect actual

ok 4 - relative date (5 days ago)

expecting success: 
test-date relative 1249932000 >actual &&
test_i18ncmp expect actual

ok 5 - relative date (3 weeks ago)

expecting success: 
test-date relative 123866 >actual &&
test_i18ncmp expect actual

ok 6 - relative date (5 months ago)

expecting success: 
test-date relative 121416 >actual &&
test_i18ncmp expect actual

ok 7 - relative date (1 year, 2 months ago)

expecting success: 
test-date relative 1196472000 >actual &&
test_i18ncmp expect actual

ok 8 - relative date (1 year, 9 months ago)

expecting success: 
test-date relative 62166 >actual &&
test_i18ncmp expect actual

ok 9 - relative date (20 years ago)

expecting success: 
test-date relative 1220210400 >actual &&
test_i18ncmp expect actual

ok 10 - relative date (12 months ago)

expecting success: 
test-date relative 1188674400 >actual &&
test_i18ncmp expect actual

ok 11 - relative date (2 years ago)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 12 - show date (iso8601:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 13 - show date (iso8601-strict:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 14 - show date (rfc2822:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 15 - show date (short:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 16 - show date (default:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 17 - show date (raw:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

ok 18 - show date (unix:146600 +0200)

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

--- expect  2017-03-16 07:03:00.492354839 +0100
+++ actual  2017-03-16 07:03:00.500354847 +0100
@@ -1 +1 @@
-146600 +0200 -> 2016-06-15 14:13:20 +
+146600 +0200 -> 2016-06-15 16:13:20 +0200
not ok 19 - show date (iso-local:146600 +0200)
#   
#   echo "$time -> $expect" >expect &&
#   test-date show:$format "$time" >actual &&
#   test_cmp expect actual
#   

expecting success: 
echo "$time -> $expect" >expect &&
test-date show:$format "$time" >actual &&
test_cmp expect actual

--- expect  2017-03-16 07:03:00.504354852 +0100
+++ actual  2017-03-16 07:03:00.508354856 +0100
@@ -1 +1 @@
-146600 +0200 -> 146600 +
+146600 +0200 -> 146600 +0200
not ok 20 - show date (raw-local:146600 +0200)
#   
#   echo "$time -> $expect" >expect &&
#   test-date show:$format "$time" >actual &&
# 

Bug#847961: gitweb: missing dependency to libcgi-pm-perl

[Anders Kaseorg]

Control: affects -1 1:2.10.2-3

The regression was introduced by Perl, not Git.  CGI.pm used to live in 
Perl core but was dropped in Perl 5.22.  I’ve confirmed that testing is 
also affected (and, based on the Perl changelog, has probably been 
affected all year).

I’ll add the missing dependency to gitweb shortly.

Anders

Bug#842586: git: FTBFS on mips64el (fatal: Out of memory, getdelim failed)

[Anders Kaseorg]

Control: notfound -1 git/1:2.10.2-1
Control: close -1

On Mon, 31 Oct 2016, Sebastiaan Couwenberg wrote:
> I think we can close this issue as notfound in git/1:2.10.2-1, since the
> most reliable mips64el buildd was able to build it successfully.

Thanks, doing so.

Anders

Bug#842586: git: FTBFS on mips64el (fatal: Out of memory, getdelim failed)

[Anders Kaseorg]

On Mon, 31 Oct 2016, Sebastiaan Couwenberg wrote:
> Disabling the tests on mips64el is reasonable.
> 
> You can also do a build on the mips64el porterbox if that succeeds
> without changes you can just upload that.

Alright.  I am still a DM in the process of applying to be a DD, but I’ve 
now requested a DM guest account (https://nm.debian.org/process/114), and 
I’ll see if that is granted quickly.

Anders

Bug#842586: git: FTBFS on mips64el (fatal: Out of memory, getdelim failed)

[Anders Kaseorg]

Control: tags -1 + help

On Sun, 30 Oct 2016, Bas Couwenberg wrote:
> The recent git upload FTBFS on mips64el due to OOM, the missing build on
> mips64el is preventing the qgis rebuild as part of the ongoing gdal
> transition (#842288).
> 
> The build was performed on mipsel-manda-02 which is known to have issues
> like these (although git built successfully on this buildd before).
> Perhaps a rebuild on another buildd will be sufficient.

Eep.

Looking at 
https://buildd.debian.org/status/logs.php?pkg=git&arch=mips64el, the build 
has been attempted three times now, including once on mipsel-aql-02, 
failing all three times with out of memory errors.  None of the failing 
tests (t0023-crlf-am.sh, t0064-sha1-array.sh, t0302-credential-store.sh) 
have changed between 2.10.1 and 2.10.2, and 2.10.1 built with no trouble.  
These tests should be using basically no memory (about 4 MB each).

Maybe another test running in parallel is using memory and causing these 
tests to fail?  Could these build machines be so underpowered that they 
shouldn’t be setting DEB_BUILD_OPTIONS=parallel=4?

Unless someone familiar with the mips64el buildd situation has a better 
plan, I’m unsure how to proceed except by disabling individual failing 
tests, or the entire test suite, for mips64el.

Any ideas?

Anders

Bug#842477: [PATCH] git-sh-setup: Restore sourcability from outside scripts

[Anders Kaseorg]

On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote:
> This did break in v2.10.0, and it's taken a couple of months to notice
> this, so clearly it's not very widely used, which says something about
> the cost-benefit of maintaining this for external users.

For the record, in case this affects the calculation, it was noticed that 
guilt was broken a just couple of days after the first git 2.10.x upload 
to Debian, which was last weekend.

https://bugs.debian.org/842477
http://repo.or.cz/guilt.git/blob/v0.36:/guilt#l28

(I have no further opinion; I trust that Junio has all the information 
needed to decide one way or the other.)

Anders

Bug#842477: [PATCH] git-sh-setup: Restore sourcability from outside scripts

[Anders Kaseorg]

On Sun, 30 Oct 2016, Ævar Arnfjörð Bjarmason wrote:
> This seems like a reasonable fix for this issue. However as far as I
> can tell git-sh-setup was never meant to be used by outside scripts
> that didn't ship as part of git itself.
> 
> If that's the case any change in the API which AFAICT is now
> considered internal might break them, so should some part of that be
> made public & documented as such?

It is documented (Documentation/git-sh-setup.txt), and this is not the 
internal Documentation/technical section of the documentation, so my 
default assumption would be that everything shown there is intended as 
public.  I only bring this up as a question because it was apparently 
allowed to break.  If I’m wrong and it isn’t public, other patches are 
needed (to the documentation and to its users in contrib).

Anders

Bug#842477: [PATCH] git-sh-setup: Restore sourcability from outside scripts

[Anders Kaseorg]

v2.10.0-rc0~45^2~2 “i18n: git-sh-setup.sh: mark strings for
translation” broke outside scripts such as guilt that source
git-sh-setup as described in the documentation:

$ . "$(git --exec-path)/git-sh-setup"
sh: 6: .: git-sh-i18n: not found

This also affects contrib/convert-grafts-to-replace-refs.sh and
contrib/rerere-train.sh in tree.  Fix this by using git --exec-path to
find git-sh-i18n.

While we’re here, move the sourcing of git-sh-i18n below the shell
portability fixes.

Signed-off-by: Anders Kaseorg 
---

Is this a supported use of git-sh-setup?  Although the documentation is
clear that the end user should not invoke it directly, it seems to imply
that scripts may do this, and in practice it has worked until v2.10.0.

 git-sh-setup.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index a8a4576..240c7eb 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -2,9 +2,6 @@
 # to set up some variables pointing at the normal git directories and
 # a few helper shell functions.
 
-# Source git-sh-i18n for gettext support.
-. git-sh-i18n
-
 # Having this variable in your environment would break scripts because
 # you would cause "cd" to be taken to unexpected places.  If you
 # like CDPATH, define it for your interactive shell sessions without
@@ -46,6 +43,9 @@ git_broken_path_fix () {
 
 # @@BROKEN_PATH_FIX@@
 
+# Source git-sh-i18n for gettext support.
+. "$(git --exec-path)/git-sh-i18n"
+
 die () {
die_with_status 1 "$@"
 }
-- 
2.10.1

Bug#840189: dblatex fails in pdflatex: Use of \@xmultirow doesn't match its definition

[Anders Kaseorg]

Control: clone -1 -2
Control: reassign -2 texlive-latex-extra 2016.20161008-1
Control: retitle -2 texlive-latex-extra should Breaks: dblatex (<< 0.3.8-2~)
Control: severity -2 serious

Although it is not texlive-latex-extra’s fault that dblatex fails with the 
new version, I believe it should not enter testing without declaring this 
Breaks.  If you disagree, feel free to downgrade or close this.

Anders

Bug#839481: openafs: FTBFS: Tests failures

[Anders Kaseorg]

Control: forwarded 839481 https://gerrit.openafs.org/12414
Control: tags 839481 + upstream pending

I sent a patch for this failure upstream, but then I ran into the separate 
problem that dblatex no longer works at all in sid as of yesterday, and 
filed https://bugs.debian.org/840189 for that.  I’ll upload my patch once 
dblatex is fixed.

Anders

Bug#840189: dblatex fails in pdflatex: Use of \@xmultirow doesn't match its definition

[Anders Kaseorg]

Package: dblatex
Version: 0.3.8-1
Severity: grave

dblatex in sid fails on every document as follows:

$ echo 'Hello, world!' > 
hello.xml
$ dblatex hello.xml
Build the book set list...
Build the listings...
XSLT stylesheets DocBook - LaTeX 2e (0.3.8-1)
===
Build hello.pdf
pdflatex failed
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: Use of \@xmultirow 
doesn't match its definition.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: Missing 
\begin{document}.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: You can't use `macro 
parameter character #' in horizontal mode.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[#
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: You can't use `macro 
parameter character #' in horizontal mode.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[#2]{#
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: You can't use `macro 
parameter character #' in horizontal mode.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[#2]{#3}[#
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: You can't use `macro 
parameter character #' in horizontal mode.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[#2]{#3}[#4]{#
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: Too many }'s.
/usr/share/texmf/tex/latex/dblatex/style/dbk_table.sty:32: leading text: 
\expandafter{\@xmultirow{#1}[#2]{#3}[#4]{#5}}
Unexpected error occured
Error: pdflatex compilation failed

This causes openafs to FTBFS.

The problem seems to have been triggered by texlive-latex-extra 
2016.20161008-1, whose multirow.sty has a different \@xmultirow macro that 
takes six arguments rather than five.  Downgrading to texlive-latex-extra 
2016.20160819-1 from stretch makes the problem goes away.

Since \@xmultirow is a private internal macro, dblatex should not rely on 
it.

Bug#818787: doxygen: Changes default HAVE_DOT to YES without having graphviz in the Depends line.

[Anders Kaseorg]

Hi, I’m one of the nobodies that looks at my build logs.  I noticed five 
instances of

  sh: 1: dot: not found
  error: Problems running dot: exit code=127, command='dot',
  arguments='"…/graph_legend.dot" -Tpng -o "…/graph_legend.png"'

in the openafs build log, and indeed Doxygen is generating 
graph_legend.html files that link to a missing graph_legend.png.  There 
are no explicit uses of dot.  Doxygen decided to do this itself, by 
default.

You can reproduce this error just by running

  doxygen -g; doxygen

in an empty directory without graphviz installed.  I think it’s hard to 
argue that an empty Doxygen project should be expected to manually declare 
a build dependency on graphviz.

Anders

Bug#834087: Bug#832656: runit: breaks users of runit: ln: failed to create symbolic link '/etc/service/bcron-sched': No such file or directory

[Anders Kaseorg]

Control: tags -1 + moreinfo

On Thu, 28 Jul 2016, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed to install.
> […]
>   ln: failed to create symbolic link '/etc/service/bcron-sched': No such file 
> or directory
> […]
> Similar problems were seen in different *-run packages.

This is marked as affecting git-daemon-run, but I can’t figure out what 
problem is being reported.  ‘apt install git-daemon-run’ succeeds for me 
in a sid chroot.

However, there seems to be a suggestion that fixing the problem, whatever 
it is, requires switching the packaging to Debhelper, which is in progress 
(awaiting sponsorship): https://bugs.debian.org/834886.

Anders

Bug#833930: gitk: display shot, application usability gone

[Anders Kaseorg]

Control: tags -1 + moreinfo
Control: severity -1 normal

I tried to reproduce this by installing a fresh jessie VM in virt-manager 
with debian-live-8.5.0-amd64-xfce-desktop.iso, installing gitk, then 
upgrading the VM to stretch in two parts (apt upgrade; apt full-upgrade), 
then rebooting.  I did not observe a gitk display problem at any point 
during, between, or after these steps.

Do you have a detailed recipe for reliably reproducing this, ideally 
starting from a known state such as a live CD?

Perhaps that is hard, but at least we can distinguish between a user 
configuration issue and a system configuration issue: can you reproduce on 
the same system under a freshly created account?

Anders

Bug#778196: No, not fixed

[Anders Kaseorg]

Control: found 778196 1.6.9-2+deb8u1
Control: reopen

Commit a6013738 (Linux: Move code to reset the root to afs/LINUX) is a 
prerequisite of 860764da (Linux: d_alias becomes d_u.d_alias), but the 
former is missing in 1.6.9-2+deb8u1.

Anders


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737076: libyaml: CVE-2013-6393: heap-based buffer overflow when parsing YAML tags

[Anders Kaseorg]

On Thu, 30 Jan 2014, Salvatore Bonaccorso wrote:
> On Wed, Jan 29, 2014 at 08:52:01PM -0500, Anders Kaseorg wrote:
> > Thanks.  Here’s the new release (currently awaiting upload sponsorship):
> > 
> > http://web.mit.edu/andersk/Public/debian/libyaml_0.1.4-3.dsc
> > http://web.mit.edu/andersk/Public/debian/libyaml_0.1.4-2_3.debdiff
> 
> Have you asked your current sponsor? Otherwise I can upload your
> package.

I haven’t gotten a reply yet.  You can go ahead and upload it.

Thanks,
Anders


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737076: libyaml: CVE-2013-6393: heap-based buffer overflow when parsing YAML tags

[Anders Kaseorg]

Thanks.  Here’s the new release (currently awaiting upload sponsorship):

http://web.mit.edu/andersk/Public/debian/libyaml_0.1.4-3.dsc
http://web.mit.edu/andersk/Public/debian/libyaml_0.1.4-2_3.debdiff

Anders


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728508: [PATCH] Re: Bug#728508: Acknowledgement (Dropped #include results in connect.c:380:9: warning: assignment makes pointer from integer without a cast)

[Anders Kaseorg]

tags 728508 + patch
thanks

--- 
a/debian/diff/0003-transport-expose-git_tcp_connect-and-friends-in-new-t.diff
+++ 
b/debian/diff/0003-transport-expose-git_tcp_connect-and-friends-in-new-t.diff
@@ -13,10 +13,10 @@ library easier to understand before adding to it.
 Signed-off-by: Jonathan Nieder 
 ---
  Makefile  |   2 +
- connect.c | 276 -
+ connect.c | 277 +
  tcp.c | 280 ++
  tcp.h |   8 ++
- 4 files changed, 290 insertions(+), 276 deletions(-)
+ 4 files changed, 291 insertions(+), 276 deletions(-)
  create mode 100644 tcp.c
  create mode 100644 tcp.h
 
@@ -41,10 +41,18 @@ index af847f8..a78f758 100644
  LIB_OBJS += transport.o
  LIB_OBJS += transport-helper.o
 diff --git a/connect.c b/connect.c
-index 06e88b0..aa7b3e6 100644
+index 06e88b0..da37b2c 100644
 --- a/connect.c
 +++ b/connect.c
-@@ -251,282 +251,6 @@ static enum protocol get_protocol(const char *name)
+@@ -6,6 +6,7 @@
+ #include "run-command.h"
+ #include "remote.h"
+ #include "connect.h"
++#include "tcp.h"
+ #include "url.h"
+ #include "string-list.h"
+ 
+@@ -251,282 +252,6 @@ static enum protocol get_protocol(const char *name)
die("I don't handle protocol '%s'", name);
  }
  


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728508: Dropped #include results in connect.c:380:9: warning: assignment makes pointer from integer without a cast

[Anders Kaseorg]

Package: git
Version: 1:1.8.5~rc0-1
Severity: serious

A misresolved merge conflict dropped #include "tcp.h" from connect.c 
between 1.8.4.2-1 and 1.8.5~rc0-1, which results in these build warnings:

CC connect.o
connect.c: In function 'git_connect':
connect.c:379:3: warning: implicit declaration of function 'git_use_proxy' 
[-Wimplicit-function-declaration]
connect.c:380:4: warning: implicit declaration of function 'git_proxy_connect' 
[-Wimplicit-function-declaration]
connect.c:380:9: warning: assignment makes pointer from integer without a cast 
[enabled by default]
connect.c:382:4: warning: implicit declaration of function 'git_tcp_connect' 
[-Wimplicit-function-declaration]

Obviously this was a silly accident, but it will cause runtime crashes on 
some architectures (https://wiki.debian.org/ImplicitPointerConversions), 
as well as rejection on at least the Ubuntu amd64 buildds via a build log 
filter, so it probably merits Severity: serious.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727226: [PATCH] cvsserver: Determinize output to combat Perl 5.18 hash randomization

[Anders Kaseorg]

Perl 5.18 randomizes the seed used by its hash function, so iterating
through hashes results in different orders from run to run:
  http://perldoc.perl.org/perl5180delta.html#Hash-overhaul

This usually broke t9400 (gitcvs.dbname, gitcvs.ext.dbname, when
running cmp on two .sqlite files) and t9402 (check [cvswork3] diff,
when running test_cmp on two diffs).

To fix this, hide the internal order of hashes with sort when sending
output or running database queries.

(An alternative workaround is PERL_HASH_SEED=0, but this seems nicer.)

Signed-off-by: Anders Kaseorg 
---
 git-cvsserver.perl | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 67b1e7b..6177f4a 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -430,10 +430,10 @@ sub req_validrequests
 
 $log->debug("req_validrequests");
 
-$log->debug("SEND : Valid-requests " . join(" ",keys %$methods));
+$log->debug("SEND : Valid-requests " . join(" ",sort keys %$methods));
 $log->debug("SEND : ok");
 
-print "Valid-requests " . join(" ",keys %$methods) . "\n";
+print "Valid-requests " . join(" ",sort keys %$methods) . "\n";
 print "ok\n";
 }
 
@@ -2124,7 +2124,7 @@ sub req_diff
 print "M retrieving revision $meta2->{revision}\n"
 }
 print "M diff ";
-foreach my $opt ( keys %{$state->{opt}} )
+foreach my $opt ( sort keys %{$state->{opt}} )
 {
 if ( ref $state->{opt}{$opt} eq "ARRAY" )
 {
@@ -4050,7 +4050,7 @@ sub update
 close FILELIST;
 
 # Detect deleted files
-foreach my $file ( keys %$head )
+foreach my $file ( sort keys %$head )
 {
 unless ( exists $seen_files->{$file} or 
$head->{$file}{filehash} eq "deleted" )
 {
@@ -4078,7 +4078,7 @@ sub update
 }
 
 $self->delete_head();
-foreach my $file ( keys %$head )
+foreach my $file ( sort keys %$head )
 {
 $self->insert_head(
 $file,
-- 
1.8.4.1


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666813: Apache 2.4 upload date scheduled for May 30

[Anders Kaseorg]

Although this isn’t important, I believe you can also get rid of 
AP2_MAKE_DEFS and override_dh_auto_make; the defaults are fine.

Anders

On Thu, 11 Jul 2013, Colin Watson wrote:
> diff -Nru mod-vhost-ldap-2.0.8/debian/rules mod-vhost-ldap-2.0.8/debian/rules
> --- mod-vhost-ldap-2.0.8/debian/rules 2011-06-21 17:18:19.0 +0100
> +++ mod-vhost-ldap-2.0.8/debian/rules 2013-07-10 23:24:42.0 +0100
> @@ -19,7 +19,7 @@
>  #}}}
>  
>  %:
> - dh --with quilt $@
> + dh $@ --with quilt,apache2
>  
>  AP2_MAKE_DEFS=top_dir=/usr/share/apache2 \
>   APXS=apxs2 APACHECTL=apachectl2 \
> @@ -35,8 +35,4 @@
>   $(MAKE) $(AP2_MAKE_DEFS)
>  
>  override_dh_auto_install:
> - mkdir -p $(DEST)/usr/lib/apache2/modules
> - install -m 644 .libs/mod_vhost_ldap.so $(DEST)/usr/lib/apache2/modules
> - mkdir -p $(DEST)/etc/apache2/mods-available
> - install -m 644 debian/vhost_ldap.load $(DEST)/etc/apache2/mods-available
> - install -m 644 debian/vhost_ldap.conf $(DEST)/etc/apache2/mods-available
> + # handled by dh_apache2


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#683568: git: NO_HARDLINKS broke in 1.7.11 (renamed to NO_INSTALL_HARDLINKS)

[Anders Kaseorg]

Package: git
Version: 1:1.7.11-1~exp0
Severity: serious
Justification: package uninstallable

The btrfs “Too many links” bug (http://bugs.debian.org/642603, 
http://bugs.debian.org/645009, http://bugs.debian.org/654596) has 
reappeared in 1:1.7.11-1~exp0 because, when the no-hardlinks patch was 
merged upstream as v1.7.11-rc0~47^2, NO_HARDLINKS was renamed to 
NO_INSTALL_HARDLINKS.  debian/rules needs to be updated accordingly, and 
the migration code in git.preinst might need to be adjusted.

Anders


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#654596: git: failure to upgrade from squeeze ("mv: git-add.tmp and git-add are the same file")

[Anders Kaseorg]

On Wed, 4 Jan 2012, Jonathan Nieder wrote:
> + # : coreutils mv refuses to
> + # replace a file by a symlink to the same inode.
> + # Fine, let's give /usr/lib/git-core/git its own inode.

Or, inspired by http://debbugs.gnu.org/6960#65 , we could move the symlink 
in from a different directory (as long as it’s on the same filesystem), to 
fool mv into not recognizing the symlink target!

--- a/debian/git.preinst
+++ b/debian/git.preinst
@@ -46,12 +46,13 @@ rm_conffile /etc/emacs/site-start.d/50git-core.el "$1" "$2"
 if test "$1" = upgrade &&
dpkg --compare-versions "$2" lt-nl '1:1.7.7-2'; then
refinode=$(stat -c%i /usr/lib/git-core/git)
+   tmp=$(mktemp -d --tmpdir=/usr/lib/git-core)
for f in /usr/lib/git-core/*; do
test "$f" != /usr/lib/git-core/git || continue
-   rm -f "$f.tmp"
inode=$(stat -c%i "$f")
test "$inode" = "$refinode" || continue
-   ln -s git "$f.tmp"
-   mv -f "$f.tmp" "$f"
+   ln -s git "$tmp/symlink"
+   mv -f "$tmp/symlink" "$f"
done
+   rmdir "$tmp"
 fi

I’ll let you decide which version is less horrible.

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#654596: git: failure to upgrade from squeeze (NOT btrfs; symlink errors)

[Anders Kaseorg]

On Wed, 4 Jan 2012, Jon Dowland wrote:
> >  mv: `/usr/lib/git-core/git-add.tmp' and `/usr/lib/git-core/git-add' are 
> > the same file

This was also reported by a user of the Ubuntu PPA: 
https://bugs.launchpad.net/911906

It seems mv -f refuses to replace a file with a symlink to the same inode 
(WTF?), so this part of the preinst doesn’t work:

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
rm -f "$f.tmp"
inode=$(stat -c%i "$f")
test "$inode" = "$refinode" || continue
ln -s git "$f.tmp"
mv -f "$f.tmp" "$f"
done

This isn’t a limitation of the rename() syscall, so one silly fix that 
preserves atomicity would be to invoke rename() from another language:

-   mv -f "$f.tmp" "$f"
+   perl -e 'rename($ARGV[0], $ARGV[1])' -- "$f.tmp" "$f"

*whine*

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#635102: tcsh: FTBFS: testsuite failures

[Anders Kaseorg]

tags 635102 + patch
thanks

Here’s a debdiff that just removes this failing test in
debian/patches/disable-test-notty.patch, along with the two other tests
that were already removed there for the same reason.

Anders

diff -u tcsh-6.17.06/debian/changelog tcsh-6.17.06/debian/changelog
--- tcsh-6.17.06/debian/changelog
+++ tcsh-6.17.06/debian/changelog
@@ -1,3 +1,10 @@
+tcsh (6.17.06-2) unstable; urgency=low
+
+  * debian/patches/disable-test-notty.patch: Disable an additional test
+that fails when not running with a TTY.  (Closes: #635102)
+
+ -- Anders Kaseorg   Tue, 20 Sep 2011 20:00:11 -0400
+
 tcsh (6.17.06-1) unstable; urgency=low
 
   * new upstream version
diff -u tcsh-6.17.06/debian/patches/disable-test-notty.patch 
tcsh-6.17.06/debian/patches/disable-test-notty.patch
--- tcsh-6.17.06/debian/patches/disable-test-notty.patch
+++ tcsh-6.17.06/debian/patches/disable-test-notty.patch
@@ -30,0 +31,13 @@
+--- a/tests/lexical.at
 b/tests/lexical.at
+@@ -33,10 +33,6 @@ AT_SETUP([Comments])
+ AT_CHECK([echo 'echo OK@%:@comment' | tcsh -f], , [OK
+ ])
+ 
+-AT_CHECK([tcsh -f -c 'echo @%:@no comment'], ,
+-[@%:@no comment
+-])
+-
+ AT_DATA([comment2.csh],
+ [[echo testing...@%:@\
+ OK

Bug#635102: tcsh: FTBFS: testsuite failures

[Anders Kaseorg]

I finally figured out how to reproduce this.  The test suite only fails 
when stdin is redirected from /dev/null, because


$ tcsh -f -c 'echo #no comment'
#no comment
$ tcsh -f -c 'echo #no comment' < /dev/null

$

This looks like a potentially legitimate upstream bug.

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#632573: serf/experimental: FTBFS (kfreebsd): testsuite failures

[Anders Kaseorg]

I sent a patch to the upstream bug that seems to fix the test failures 
for me on Linux, at least (after removing the ip6-localhost kludge). 
Can someone try it on kFreeBSD?


http://code.google.com/p/serf/issues/detail?id=78#c2

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626979: haskell-platform requires older libghc-quickcheck2-dev than exists

[Anders Kaseorg]

Package: haskell-platform
Version: 2011.2.0.1.1
Severity: serious

haskell-platform depends libghc-quickcheck2-dev (>= 2.4.0.1), 
libghc-quickcheck2-dev (< 2.4.0.1+), but this dependency is unsatisfiable 
because Debian only has libghc-quickcheck2-dev 2.4.1.1-1.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626772: cabal-install: unsatisfied versioned build dep on libghc-http-dev

[Anders Kaseorg]

Package: cabal-install
Version: 0.10.2-1
Severity: serious

Since the version number of haskell-http from 40001010-1 to 1:4000.1.1-2 
(http://bugs.debian.org/601698), the versioned build deps for 
haskell-cabal-install on libghc-http-dev (>= 4002), libghc-http-dev 
(<< 4001) are now unsatisfiable.  The upper bound needs to be changed 
to (<< 1:4001) or so.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#618872: Wildcard regression in mod_vhost_ldap 2.0.6

[Anders Kaseorg]

Package: libapache2-mod-vhost-ldap
Version: 2.0.6-1
Tags: patch
Severity: serious

The commit “Fix wildcard search” [1] in mod_vhost_ldap 2.0.6 is incorrect, 
and actually breaks wildcard searches.  The code was correct originally 
[2], and has been in production use on servers at MIT for two years.  But 
now it looks for records that literally have ‘\*’ in the hostname instead 
of ‘*’, and of course it doesn’t find one.

(Are you sure you haven’t been accidentally testing with records that have 
literal backslashes in the hostname, e.g. ‘\*.example.com’?  Or perhaps 
someone was trying out the patch for wildcard hostnames without my prior 
patch that properly escapes LDAP queries [3]?)

I verified the regression from 2.0.5 on a real server, and successfully 
tested the patch below on top of 2.0.6.  The patch is also available in my 
Git repository git://andersk.mit.edu/mod-vhost-ldap.git in the branch 
“wildcard”.  This branch also has a spelling fix for the example 
configuration file.

[1] 
http://git.debian.org/?p=users/ondrej/mod-vhost-ldap.git;a=commitdiff;h=a6842df 
[2] http://bugs.debian.org/470093

http://git.debian.org/?p=users/ondrej/mod-vhost-ldap.git;a=commitdiff;h=a529b3b
[3] http://bugs.debian.org/469930

http://git.debian.org/?p=users/ondrej/mod-vhost-ldap.git;a=commitdiff;h=303e7b4 

-- 8< --
From 188f008c3b074a8352e814024a13b1710427893a Mon Sep 17 00:00:00 2001
From: Anders Kaseorg 
Date: Sat, 19 Mar 2011 03:52:56 -0400
Subject: [PATCH] Revert incorrect “fix” of wildcard search

It is wrong to add extra backslashes before *, because escaping is
already done by ldap_bv2escaped_filter_value.  The extra backslash
made lookups fail.

This partially reverts commit fb5409ad77a245ed0ae746d198b394b580b4de3e.

Signed-off-by: Anders Kaseorg 
---
 mod_vhost_ldap.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/mod_vhost_ldap.c b/mod_vhost_ldap.c
index 24b74b9..b6bee2a 100644
--- a/mod_vhost_ldap.c
+++ b/mod_vhost_ldap.c
@@ -538,11 +538,11 @@ fallback:
 
 if (result == LDAP_NO_SUCH_OBJECT) {
 if (conf->wildcard == MVL_ENABLED) {
-   if (strcmp(hostname, "\\*") != 0) {
-   if (strncmp(hostname, "\\*.", 3) == 0)
-   hostname += 3;
+   if (strcmp(hostname, "*") != 0) {
+   if (strncmp(hostname, "*.", 2) == 0)
+   hostname += 2;
 hostname += strcspn(hostname, ".");
-hostname = apr_pstrcat(r->pool, "\\*", hostname, NULL);
+hostname = apr_pstrcat(r->pool, "*", hostname, NULL);
 ap_log_rerror(APLOG_MARK, APLOG_NOTICE|APLOG_NOERRNO, 0, r,
  "[mod_vhost_ldap.c] translate: "
  "virtual host not found, trying wildcard %s",
-- 
1.7.4.1




--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#590873: openconnect < 2.25 does not verify SSL server certificates

[Anders Kaseorg]

Package: openconnect
Version: 2.22-1.1
Severity: grave
Tags: security fixed-upstream

Versions of OpenConnect before 2.25 do not verify that the server SSL 
certificate matches the server hostname, which enables an attacker to 
perform an MITM attack on the connection.  This can be fixed by upgrading 
to OpenConnect 2.25.

From the upstream changelog:

OpenConnect v2.25 — 2010-05-15
• Always validate server certificate, even when no extra --cafile is 
  provided.
• Add --no-cert-check option to avoid certificate validation.
• Check server hostname against its certificate.
• Provide text-mode function for reviewing and accepting "invalid" 
  certificates.
• Fix libproxy detection on NetBSD.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#576967: cdbs: Splits CC into multiple env-var words

[Anders Kaseorg]

reassign 576967 cdbs
tags 576967 +patch
thanks

How can you suggest that a multiword CC is “abuse” and okay to break, when 
by your own logic (bug 523642), CDBS “has a well defined current behaviour 
that users rely on”?

This change also broke one of my packages that does some cross compiling 
by setting CC = gcc -m32.  This is a perfectly legitimate use of CC; for 
example, the libc6 packaging does this to cross-compile libc6-i386 on 
amd64.

But in fact, the CDBS change that introduced this regression (commit 
ee9bbf5 in version 0.4.77) doesn’t even correctly do what it was 
_intended_ to do.  The $(origin) function is supposed to be called with a 
variable name, not with the contents of a variable. 
http://www.gnu.org/software/make/manual/html_node/Origin-Function.html#Origin-Function

So, can you please apply this patch, which fixes both of these bugs and 
should make everyone happy?

Thanks,
Anders

diff --git a/1/rules/buildvars.mk.in b/1/rules/buildvars.mk.in
index cbca47b..535ca74 100644
--- a/1/rules/buildvars.mk.in
+++ b/1/rules/buildvars.mk.in
@@ -121,10 +121,10 @@ cdbs_expand_branches = $(subst WORDDELIMITER,$3,$(subst 
BRANCHDELIMITER,$4,$(cal
 cdbs_findargs-path-or-name = $(if $(findstring /,$(firstword $(1))),-path 
'./$(patsubst ./%,%,$(firstword $(1)))',-name '$(firstword $(1))') $(foreach 
obj,$(wordlist 2,$(words $(1)),$(1)),-or $(if $(findstring /,$(obj)),-path 
'./$(obj:./%=%)',-name '$(obj)'))
 
 # Resolve VAR only if declared explicitly in makefile or environment
-cdbs_expand_nondefaultvar = $(if $(filter-out $(origin $1),default),$1)
+cdbs_expand_nondefaultvar = $(if $(filter-out $(origin $1),default),$1="$($1)")
 
 # Declare (shell-style) variables to itself if explicitly declared
-cdbs_set_nondefaultvars = $(foreach var,$1,$(patsubst %,$(var)="%",$(call 
cdbs_expand_nondefaultvar,$($(var)
+cdbs_set_nondefaultvars = $(foreach var,$1,$(call 
cdbs_expand_nondefaultvar,$(var)))
 
 # Return non-empty if build system is different from host system
 cdbs_crossbuild = $(if $(call 
cdbs_streq,$(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)),,yes)



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

[Anders Kaseorg]

tags 563882 +patch
thanks

On Sat, 9 Jan 2010, Jonathan Nieder wrote:
> To test this hypothesis, it would be nice to use a copy of git built 
> with DEB_BUILD_OPTIONS=nocheck to compare
> […]

Thanks for looking at this, Jonathan.

Now that Git 1.6.6.1 is out, I propose we build git-core 1.6.6.1-1 with 
the patch I posted above , which lets 
the two tests in question expect to fail on ia64 only.  Then ia64 users 
can have a package to test this with more easily, and non-ia64 users don’t 
have to wait for us to find an ia64 user and convince them to care (which 
we’ve all been unable to do for several weeks).

As far as I can tell, this test failure was triggered by some kind of 
change on the buildd and is not a real regression from the version in 
testing, given that it was observed with an earlier version in Ubuntu.  
So even for ia64 users, if there are any, this should not cause any more 
problems than already exist.

The only other option I see is to disable the ia64 architecture entirely 
for git-core, given that we’re effectively unable to support it.  But I 
think patching the test suite is less unfortunate.

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#561727: git-core: /etc/bash_completion.d/git sometimes freezes

[Anders Kaseorg]

fixed 561727 1:1.6.0-1
thanks

Apparently Git 1.6.0 added a new environment variable 
GIT_CEILING_DIRECTORIES to work around this problem.  From git(1):

   GIT_CEILING_DIRECTORIES
   This should be a colon-separated list of absolute paths. If set, it
   is a list of directories that git should not chdir up into while
   looking for a repository directory. It will not exclude the current
   working directory or a GIT_DIR set on the command line or in the
   environment. (Useful for excluding slow-loading network
   directories.)

Does that solve your problem?  (Git 1.6.5 is in lenny-backports.)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#561727: git-core: /etc/bash_completion.d/git sometimes freezes

[Anders Kaseorg]

Is this worse than any other tab completion DoSes, such as ‘scp 
tarpit-host:’?  If an attacker can write into a parent of your home 
directory, than you have way bigger problems than tab completion.

Does this really merit a release-critical severity?

Anders



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

[Anders Kaseorg]

I tried to set up an emulated ia64 chroot with which to track down the 
problem, but apparently ski doesn’t work .  
:-(

Looking at build logs from various versions, it is always the same two 
tests that fail, and only on ia64.  Most users aren’t on ia64, and it 
seems that Git “mostly works” on ia64 anyway, so it’s important to unblock 
new versions from flowing into testing.  So unless someone with an ia64 
box can find the root problem quickly, I propose temporarily doing this.

diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index c2d408b..70796b7 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -91,9 +91,15 @@ test_expect_success \
  check_cache_at frotz dirty &&
  check_cache_at nitfol dirty'
 
+if [ "$(uname -m)" = ia64 ]; then
+alias test_expect_success_except_ia64=test_expect_failure
+else
+alias test_expect_success_except_ia64=test_expect_success
+fi
+
 echo '+100644 X 0  yomin' >expected
 
-test_expect_success \
+test_expect_success_except_ia64 \
 '4 - carry forward local addition.' \
 'rm -f .git/index &&
  git read-tree $treeH &&
@@ -105,7 +111,7 @@ test_expect_success \
  compare_change 4diff.out expected &&
  check_cache_at yomin clean'
 
-test_expect_success \
+test_expect_success_except_ia64 \
 '5 - carry forward local addition.' \
 'rm -f .git/index &&
  git read-tree $treeH &&



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

[Anders Kaseorg]

Package: git-core
Version: 1:1.6.5.2-1
Severity: serious
Justification: FTBFS

Some time between 1.6.5-1 and 1.6.5.2-1, git-core started failing to build 
on ia64, because the test t1001-read-tree-m-2way.sh is failing.  This has 
continued in every version up through 1.6.6-1.

The same bug was reported with git-core 1.6.3.3-2 on Ubuntu Karmic:
https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/445773

(I don’t personally care about ia64, but unfortunately this FTBFS is 
preventing new versions of Git from migrating to testing and Ubuntu 
Lucid.)

Full build log:
https://buildd.debian.org/build.php?arch=ia64&pkg=git-core&ver=1%3A1.6.5.2-1

*** t1001-read-tree-m-2way.sh ***
*   ok 1: setup
*   ok 2: 1, 2, 3 - no carry forward
* FAIL 3: 4 - carry forward local addition.
rm -f .git/index &&
 git read-tree $treeH &&
 git checkout-index -u -f -q -a &&
 git update-index --add yomin &&
 read_tree_twoway $treeH $treeM &&
 git ls-files --stage >4.out || return 1
 git diff --no-index M.out 4.out >4diff.out
 compare_change 4diff.out expected &&
 check_cache_at yomin clean
* FAIL 4: 5 - carry forward local addition.
rm -f .git/index &&
 git read-tree $treeH &&
 git checkout-index -u -f -q -a &&
 echo yomin >yomin &&
 git update-index --add yomin &&
 echo yomin yomin >yomin &&
 read_tree_twoway $treeH $treeM &&
 git ls-files --stage >5.out || return 1
 git diff --no-index M.out 5.out >5diff.out
 compare_change 5diff.out expected &&
 check_cache_at yomin dirty
*   ok 5: 6 - local addition already has the same.
*   ok 6: 7 - local addition already has the same.
…
* failed 2 among 27 test(s)
make[3]: *** [t1001-read-tree-m-2way.sh] Error 1



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#543015: barnowl: FTBFS: tests failed

[Anders Kaseorg]

The package builds successfully in an Ubuntu PPA, at least, after adding 
Build-Depends: libclass-accessor-perl.

Andersdiff -u barnowl-1.3/debian/changelog barnowl-1.3/debian/changelog
--- barnowl-1.3/debian/changelog
+++ barnowl-1.3/debian/changelog
@@ -1,3 +1,9 @@
+barnowl (1.3-2) unstable; urgency=low
+
+  * Build-depend libclass-accessor-perl.  (Closes: #543015)
+
+ -- Anders Kaseorg   Tue, 22 Sep 2009 17:08:09 -0400
+
 barnowl (1.3-1) unstable; urgency=low
 
   * New upstream version
diff -u barnowl-1.3/debian/control barnowl-1.3/debian/control
--- barnowl-1.3/debian/control
+++ barnowl-1.3/debian/control
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Sam Hartman 
-Build-Depends: debhelper (>= 7), autoconf, libglib2.0-dev, libzephyr-dev (>= 
3.0~beta), libncurses5-dev, libncursesw5-dev, libkrb5-dev, libperl-dev, 
pkg-config, zip, libssl-dev, autotools-dev
+Build-Depends: debhelper (>= 7), autoconf, libglib2.0-dev, libzephyr-dev (>= 
3.0~beta), libncurses5-dev, libncursesw5-dev, libkrb5-dev, libperl-dev, 
pkg-config, zip, libssl-dev, autotools-dev, libclass-accessor-perl
 vcs-git: git://git.debian.org/git/collab-maint/barnowl.git
 vcs-browser: http://git.debian.org/?p=collab-maint/barnowl.git
 Standards-Version: 3.8.2

Bug#510153: tcl8.6_8.6.0~b1-2(hppa/experimental): FTBFS not fixed

[Anders Kaseorg]

tags 510153 +patch
thanks

The issue is that debian/rules calls
$(MAKE) CFLAGS="$(CFLAGS)"
overriding the CFLAGS variable set in pkgs/tdbc1.0b1/Makefile.in, which 
had been set up to include ${SHLIB_CFLAGS} (-fPIC) by 
pkgs/tdbc1.0b1/configure (generated from the TEA_MAKE_LIB macro in 
pkgs/tdbc1.0b1/tclconfig/tcl.m4).

This is arguably an upstream bug, because CFLAGS is supposed to be 
overridable in this way, and should contain only optional optimization 
flags, not essential flags like -fPIC.

However, passing the Debian CFLAGS to configure instead of forcefully 
overriding them in make is cleaner, and allows the package to build:

diff -u tcl8.6-8.6.0~b1/debian/rules tcl8.6-8.6.0~b1/debian/rules
--- tcl8.6-8.6.0~b1/debian/rules
+++ tcl8.6-8.6.0~b1/debian/rules
@@ -43,6 +43,7 @@
cd unix && \
  TCL_LIBRARY="/usr/share/tcltk/tcl$(v)" \
  TCL_PACKAGE_PATH="/usr/local/lib/tcltk /usr/local/share/tcltk 
/usr/lib/tcltk /usr/share/tcltk /usr/lib/tcltk/tcl$(v) /usr/lib" \
+ CFLAGS="$(CFLAGS)" \
  ./configure --host=$(DEB_HOST_GNU_TYPE) \
  --build=$(DEB_BUILD_GNU_TYPE) \
  --prefix=/usr \
@@ -54,7 +55,7 @@
  --mandir=/usr/share/man \
  --enable-man-symlinks && \
  touch ../generic/tclStubInit.c && \
- $(MAKE) CFLAGS="$(CFLAGS)"
+ $(MAKE)
# Build the static library.
cd unix && \
  ar cr libtcl$(v).a *.o && \



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510153: tcl8.6_8.6.0~b1-2(hppa/experimental): FTBFS not fixed

[Anders Kaseorg]

FYI, amd64 has the same build failure (at least on Ubuntu karmic).

x86_64-linux-gnu-gcc -shared -g -O2 -fno-unit-at-a-time 
-Wl,-Bsymbolic-functions -Wl,--export-dynamic  -o libtdbc1.0b1.so tdbc.o 
tdbcStubInit.o tdbcTokenize.o  -L/build/buildd/tcl8.6-8.6.0~b1/unix -ltclstub8.6
/usr/bin/ld: tdbc.o: relocation R_X86_64_32 against `a local symbol' can not be 
used when making a shared object; recompile with -fPIC
tdbc.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libtdbc1.0b1.so] Error 1

Full build log:
http://launchpadlibrarian.net/26840035/buildlog_ubuntu-karmic-amd64.tcl8.6_8.6.0~b1-2~andersk1_FAILEDTOBUILD.txt.gz

Anders



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#508265: Fixed upstream in 1.0.12

[Anders Kaseorg]

tag 508265 + fixed-upstream
thanks

This was fixed in 1.0.12 upstream.  In fact, this is the only source 
change between 1.0.11 and 1.0.12.  The other difference is that the 
configure is compiled with autoconf 2.63 instead of 2.61, and an 
autoconf-generated “compile” script was added.  A diff between the 
upstream versions (excluding ./configure) is attached.


The upstream change is slightly different from Stefan’s patch in that the 
#ifs have been reordered, but is functionally equivalent.  We could add 
the upstream change as a dpatch, or we could upgrade the package to 
1.0.12.  The latter approach seems cleaner.


Assuming we decide to run with 1.0.12, I have attached a debdiff that 
updates the context in one of the dpatches against the regenerated 
./configure in 1.0.12.  I’ve verified that the binary packages build and 
that the kernel module builds and loads on amd64.Only in sysprof-1.0.12: compile
diff -ur --exclude=configure sysprof-1.0.11/configure.ac sysprof-1.0.12/configure.ac
--- sysprof-1.0.11/configure.ac	2008-10-24 19:06:21.0 -0400
+++ sysprof-1.0.12/configure.ac	2008-12-03 20:48:51.0 -0500
@@ -1,6 +1,6 @@
 AC_PREREQ(2.54)
 
-AC_INIT([sysprof], [1.0.11])
+AC_INIT([sysprof], [1.0.12])
 AC_CONFIG_SRCDIR(sysprof.glade)
 
 AM_INIT_AUTOMAKE(no-define)
diff -ur --exclude=configure sysprof-1.0.11/Makefile.in sysprof-1.0.12/Makefile.in
--- sysprof-1.0.11/Makefile.in	2008-10-24 19:06:47.0 -0400
+++ sysprof-1.0.12/Makefile.in	2008-12-03 20:48:54.0 -0500
@@ -194,8 +194,8 @@
 	check-recursive installcheck-recursive
 DIST_COMMON = README $(srcdir)/Makefile.in $(srcdir)/configure AUTHORS \
 	COPYING ChangeLog INSTALL Makefile.am NEWS TODO aclocal.m4 \
-	config.h.in configure configure.ac depcomp install-sh missing \
-	mkinstalldirs
+	compile config.h.in configure configure.ac depcomp install-sh \
+	missing mkinstalldirs
 SOURCES = $(sysprof_SOURCES)
 
 all: config.h
diff -ur --exclude=configure sysprof-1.0.11/module/sysprof-module.c sysprof-1.0.12/module/sysprof-module.c
--- sysprof-1.0.11/module/sysprof-module.c	2008-10-24 19:13:13.0 -0400
+++ sysprof-1.0.12/module/sysprof-module.c	2008-12-03 20:49:53.0 -0500
@@ -67,25 +67,27 @@
 DECLARE_WAIT_QUEUE_HEAD (wait_for_exit);
 
 /* Macro the names of the registers that are used on each architecture */
-#if defined(CONFIG_X86_64)
-#   define REG_FRAME_PTR rbp
-#   define REG_INS_PTR rip
-#   define REG_STACK_PTR rsp
-#   define REG_STACK_PTR0 rsp0
-#elif defined(CONFIG_X86)
-#   if LINUX_VERSION_CODE >= KERNEL_VERSION (2,6,25)
-#   define REG_FRAME_PTR bp
-#   define REG_INS_PTR ip
-#   define REG_STACK_PTR sp
-#   define REG_STACK_PTR0 sp0
+#if !defined(CONFIG_X86_64) && !defined(CONFIG_X86)
+#   error Sysprof only supports the i386 and x86-64 architectures
+#endif
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION (2,6,25)
+#   define REG_FRAME_PTR bp
+#   define REG_INS_PTR ip
+#   define REG_STACK_PTR sp
+#   define REG_STACK_PTR0 sp0
+#else
+#   if defined(CONFIG_X86_64)
+#   define REG_FRAME_PTR rbp
+#   define REG_INS_PTR rip
+#   define REG_STACK_PTR rsp
+#   define REG_STACK_PTR0 rsp0
 #   else
 #   define REG_FRAME_PTR ebp
 #   define REG_INS_PTR eip
 #   define REG_STACK_PTR esp
 #   define REG_STACK_PTR0 esp0
 #   endif
-#else
-#   error Sysprof only supports the i386 and x86-64 architectures
 #endif
 
 typedef struct userspace_reader userspace_reader;
diff -ur sysprof-1.0.11.debian/debian/changelog 
sysprof-1.0.12.debian/debian/changelog
--- sysprof-1.0.11.debian/debian/changelog  2008-12-13 16:31:42.0 
-0500
+++ sysprof-1.0.12.debian/debian/changelog  2008-12-13 16:46:19.0 
-0500
@@ -1,3 +1,10 @@
+sysprof (1.0.12-0.1) unstable; urgency=low
+
+  * New upstream release.
++ Fix compiling on amd64 with kernel >= 2.6.25 (Closes: #508265).
+
+ -- Anders Kaseorg   Sat, 13 Dec 2008 16:44:40 -0500
+
 sysprof (1.0.11-0.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -ur sysprof-1.0.11.debian/debian/patches/static_libbfd.dpatch 
sysprof-1.0.12.debian/debian/patches/static_libbfd.dpatch
--- sysprof-1.0.11.debian/debian/patches/static_libbfd.dpatch   2008-12-13 
16:31:42.0 -0500
+++ sysprof-1.0.12.debian/debian/patches/static_libbfd.dpatch   2008-12-13 
16:53:12.0 -0500
@@ -9,14 +9,14 @@
 --- sysprof-1.0.9~/configure   2007-10-21 23:42:22.0 +0200
 +++ sysprof-1.0.9/configure2008-01-25 19:19:41.0 +0100
 @@ -3759,7 +3759,7 @@
- { echo "$as_me:$LINENO: result: $ac_cv_lib_bfd_bfd_get_error" >&5
- echo "${ECHO_T}$ac_cv_lib_bfd_bfd_get_error" >&6; }
- if test $ac_cv_lib_bfd_bfd_get_error = yes; then
+ { $as_echo "$as_me:$LINENO: result: $ac_cv_lib_bfd_bfd_get_error" >

Bug#494633: openafs modules don’t build with etch kernel 2.6.24-etchnhalf.1-amd64

[Anders Kaseorg]

Package: openafs-modules-source
Version: 1.4.2-6etch1
Severity: grave
Tags: etch

The new release of etch includes a new default kernel
2.6.24-etchnhalf.1-amd64, and the etch openafs-modules-source package
doesn’t build against it:

  CC [M]  
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.24-etchnhalf.1-amd64-MP/afs_atomlist.o
In file included from 
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.24-etchnhalf.1-amd64-MP/afs_atomlist.c:11:
/usr/src/modules/openafs/include/afs/param.h:36:26: error: linux/config.h: No 
such file or directory
make[7]: *** 
[/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.24-etchnhalf.1-amd64-MP/afs_atomlist.o]
 Error 1





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#415398: apt-cacher causes corruption when used with Ubuntu and Debian archives

[Anders Kaseorg]

Package: apt-cacher
Version: 1.5.3
Severity: grave

In many instances, the Debian and Ubuntu archives have different
packages with the same name.  In the apt-cacher cache, these pairs of
packages collide with each other, resulting in corruption of one of
them:

$ wget 
http://archive.ubuntu.com/ubuntu/pool/main/g/gawk/gawk_3.1.5.dfsg-4_i386.deb 
-O- | md5sum -
02537b72e8ef16eee8c643bf9693d5d2  -
$ wget http://ftp.debian.org/debian/pool/main/g/gawk/gawk_3.1.5.dfsg-4_i386.deb 
-O- | md5sum -
ae8f5e5fa4d35fc1dd2f1cd4f2120dd8  -
$ wget 
http://localhost/apt-cacher/archive.ubuntu.com/ubuntu/pool/main/g/gawk/gawk_3.1.5.dfsg-4_i386.deb
 -O- | md5sum -
02537b72e8ef16eee8c643bf9693d5d2  -
$ wget 
http://localhost/apt-cacher/ftp.debian.org/debian/pool/main/g/gawk/gawk_3.1.5.dfsg-4_i386.deb
 -O- | md5sum -
02537b72e8ef16eee8c643bf9693d5d2  -

(Similarly, if I clean the cache and request Debian's version first and
Ubuntu's second, I get Debian's twice.)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]