Bug#1072766: rust-alacritty: FTBFS: unsatisfiable build-dependencies

[James McCoy]

On Fri, Jun 07, 2024 at 05:23:32PM GMT, Santiago Vila wrote:
> 
> [...]
> Install main build dependencies (apt-based resolver)
> 
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: librust-copypasta-0.8+wayland-dev 
> (>= 0.8.1-~~) but it is not installable
>Depends: librust-copypasta-0.8+x11-dev (>= 
> 0.8.1-~~) but it is not installable
>Depends: librust-copypasta-0.8-dev (>= 
> 0.8.1-~~) but it is not installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.
> E: Package installation failed
> Not removing build depends: cloned chroot in use
> 
> 

I missed this relationship when updating copypasta.

Rather than fix this directly in unstable's current alacritty package,
I'm going to finish the work to get the version in experimental uploaded
to unstable.  This will address the issue, since experimental's
alacritty uses copypasta 0.10.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1066261: lintian: FTBFS: hello.c:9:5: error: implicit declaration of function 'strcpy' [-Werror=implicit-function-declaration]

[James McCoy]

Control: tag -1 patch

On Wed, Mar 13, 2024 at 12:42:03PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > cc -o strong \
> > -Wdate-time -D_FORTIFY_SOURCE=2 \
> > -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>/debian/test-out/packages/checks/binaries/hardening/binaries-hardening/binaries-hardening-1.0=.
> >  -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection \
> > -Wl,-z,relro -Wl,-z,now \
> > hello.c
> > hello.c: In function 'report':
> > hello.c:9:5: error: implicit declaration of function 'strcpy' 
> > [-Werror=implicit-function-declaration]
> > 9 | strcpy(buf, string);
> >   | ^~
> > hello.c:2:1: note: include '' or provide a declaration of 'strcpy'
> > 1 | #include 
> >   +++ |+#include 
> > 2 | 
> > hello.c:9:5: warning: incompatible implicit declaration of built-in 
> > function 'strcpy' [-Wbuiltin-declaration-mismatch]
> > 9 | strcpy(buf, string);
> >   | ^~
> > hello.c:9:5: note: include '' or provide a declaration of 'strcpy'
> > cc1: some warnings being treated as errors
> > make[2]: *** [Makefile:11: all] Error 1

Attached patch fixes these issues.  This is also available as MR!496 on
Salsa.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>From 53dc310d4d5af6b0701d55577b30fb9a7e493bd1 Mon Sep 17 00:00:00 2001
From: James McCoy 
Date: Fri, 15 Mar 2024 12:31:42 -0400
Subject: [PATCH] t: Fix compilation failures with dpkg 1.22.6

Dpkg 1.22.6 enables -Werror=implicit-function-declaration by default.
This causes various compilation failures in the tests, mainly due to
missing includes.

The remaining failures are due to newer GCC versions defaulting to the
C11 standard, which doesn't expose the gets() function anymore.  For
these tests, explicitly compile with -std=c99 to re-expose the function.

Closes: #1066261
Signed-off-by: James McCoy 
---
 .../hardening/binaries-hardening/build-spec/orig/hello.c   | 1 +
 .../binaries/static/binaries-golang/build-spec/orig/Makefile   | 2 +-
 .../build-spec/orig/Makefile   | 2 +-
 .../control-file-golang-built-using/build-spec/orig/Makefile   | 2 +-
 .../built-using/binaries-golang/build-spec/orig/Makefile   | 2 +-
 .../import-path/binaries-golang/build-spec/orig/Makefile   | 2 +-
 .../control-file-golang-built-using/build-spec/orig/Makefile   | 2 +-
 .../build-spec/orig/Makefile   | 2 +-
 .../binaries-embedded-libs/build-spec/orig/hardening-trigger.h | 3 +++
 9 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/t/recipes/checks/binaries/hardening/binaries-hardening/build-spec/orig/hello.c b/t/recipes/checks/binaries/hardening/binaries-hardening/build-spec/orig/hello.c
index 7b87bd737..0ee9099e1 100644
--- a/t/recipes/checks/binaries/hardening/binaries-hardening/build-spec/orig/hello.c
+++ b/t/recipes/checks/binaries/hardening/binaries-hardening/build-spec/orig/hello.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 
 void
 report(char *string)
diff --git a/t/recipes/checks/binaries/static/binaries-golang/build-spec/orig/Makefile b/t/recipes/checks/binaries/static/binaries-golang/build-spec/orig/Makefile
index f04b342de..66c9d6f3a 100644
--- a/t/recipes/checks/binaries/static/binaries-golang/build-spec/orig/Makefile
+++ b/t/recipes/checks/binaries/static/binaries-golang/build-spec/orig/Makefile
@@ -4,7 +4,7 @@ COMPILE:= $(CC) $(NOPIE_CFLAGS) $(CPPFLAGS) $(NOPIE_LDFLAGS)
 
 all:
 	# static version
-	$(COMPILE) -static -o basic.static basic.c
+	$(COMPILE) -std=c99 -static -o basic.static basic.c
 
 install:
 	install -d $(DESTDIR)/usr/lib/foo/
diff --git a/t/recipes/checks/debian/control/field/adopted/control-file-golang-xs-go-import-path/build-spec/orig/Makefile b/t/recipes/checks/debian/control/field/adopted/control-file-golang-xs-go-import-path/build-spec/orig/Makefile
index 6047afb59..900ebadbe 100644
--- a/t/recipes/checks/debian/control/field/adopted/control-file-golang-xs-go-import-path/build-spec/orig/Makefile
+++ b/t/recipes/checks/debian/control/field/adopted/control-file-golang-xs-go-import-path/build-spec/orig/Makefile
@@ -4,7 +4,7 @@ COMPILE:= $(CC) $(NOPIE_CFLAGS) $(CPPFLAGS) $(NOPIE_LDFLAGS)
 
 all:
 	# static version
-	$(COMPILE) -static -o static basic.c
+	$(COMPILE) -std=c99 -static -o static basic.c
 
 clean distclean:
 	rm -f basic
diff --git a/t/recipes/checks/debian/control/field/

Bug#1065731: marked as pending in libvterm

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1065731 in libvterm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/libvterm/-/commit/1e77b861739a56510aa1afa6e3ea1b24ab0cbd56


Add Breaks against neovim and emacs-libvterm

Closes: #1065731
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065731

Bug#1065731: libvterm0: Missing Breaks for rdeps that were built against libvterm 0.1

[James McCoy]

Package: libvterm0
Version: 0.3.3-2
Severity: serious
Justification: Policy 8.6.2

The missing Breaks can allow partial upgrades and therefore break
the package, since the ABI changed.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvterm0 depends on:
ii  libc6  2.37-15.1

libvterm0 recommends no packages.

libvterm0 suggests no packages.

-- no debconf information

Bug#1064680: subversion: FTBFS: :86:in `require': /<>/BUILD/subversion/bindings/swig/ruby/libsvn_swig_ruby/.libs/li

[James McCoy]

Control: reassign -1 swig/4.2.0-1
Control: affects -1 src:subversion
Control: forwarded -1 https://github.com/swig/swig/issues/2751
Control: retitle -1 SWIG_snprintf not defined for ruby/tcl bindings

On Sun, Feb 25, 2024 at 08:33:47PM +0100, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>'
> > make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> > rule.
> > if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then for d in 
> > /<>/BUILD/subversion/bindings/swig/ruby/libsvn_swig_ruby 
> > /<>/BUILD/subversion/bindings/swig/ruby/../../../libsvn_*; do 
> > if [ -n "$DYLD_LIBRARY_PATH" ]; then 
> > LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs"; else 
> > LD_LIBRARY_PATH="$d/.libs"; fi; done; export LD_LIBRARY_PATH; fi; \
> > cd /<>/BUILD/subversion/bindings/swig/ruby; \
> >   check_rb() { \
> > /usr/bin/ruby -I 
> > /<>/BUILD/../subversion/bindings/swig/ruby 
> > /<>/BUILD/../subversion/bindings/swig/ruby/test/run-test.rb 
> > "$@"; \
> >   }; \
> >   if check_rb --help 2>&1 | grep -q -- --collector; then \
> > check_rb --collector=dir --verbose=normal; \
> >   elif [ "3" -eq 1 -a "1" -lt 9 ] ; then \
> > check_rb --verbose=normal; \
> >   else \
> > check_rb; \
> >   fi
> > :86:in
> >  `require': 
> > /<>/BUILD/subversion/bindings/swig/ruby/libsvn_swig_ruby/.libs/libsvn_swig_ruby-1.so.1:
> >  undefined symbol: SWIG_snprintf - 
> > /<>/BUILD/subversion/bindings/swig/ruby/.ext/svn/ext/core.so 
> > (LoadError)

This is a bug in the bindings generated by SWIG, which is fixed in 4.2.1
but not yet uploaded.  Reassigning.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1062674: lua-compat53: NMU diff for 64-bit time_t transition

[James McCoy]

On Fri, Feb 02, 2024 at 04:18:01PM +, Graham Inggs wrote:
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

The 53 in lua-compat53 isn't related to the ABI.  This Lua module
provides a Lua 5.3 API surface that can be used in previous Lua
versions.  Lua module packages aren't generally named according to the
SONAME (for reasons I'm not clear on).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1063254: lua-luv: identified for time_t transition but no ABI in shlibs

[James McCoy]

On Mon, Feb 05, 2024 at 01:38:47PM -0800, Steve Langasek wrote:
> However, lua-luv's shlibs file declares a dependency on a library package
> name that contains no ABI information:
> 
> $ cat DEBIAN/shlibs
> liblua5.1-luv 0 lua-luv (>= 1.44.2-0)
> liblua5.2-luv 0 lua-luv (>= 1.44.2-0)
> liblua5.3-luv 0 lua-luv (>= 1.44.2-0)
> liblua5.4-luv 0 lua-luv (>= 1.44.2-0)
> $
> 
> It is therefore not obvious that we should rename the package to
> 'lua-luvt64' as part of this transition.

This is how most, if not all, of the lua modules are packaged.

I see that lua-compat53 was renamed to lua-compat53t64, but the 53 isn't
anything ABI related.  The package is named that because it's providing
a Lua 5.3-compatible API that can be used in Lua versions prior to 5.3.

I'm not sure why Lua modules are packaged this way, but any "obvious"
renamings of lua packages on your list are probably misleading.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1052945: marked as pending in neovim

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1052945 in neovim reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/vim-team/neovim/-/commit/1ef33139d48e4c1d92ae4f686ca4895e137dfe5c


fix(unittests): ignore __s128 and __u128 types in ffi

Linux added these types to their userspace headers in [6.5], which
causes unit tests to fail like

```
 Running tests from test/unit/api/private_helpers_spec.lua
RUN   vim_to_object converts true: 17.00 ms ERR
test/unit/helpers.lua:748: test/unit/helpers.lua:732: (string) '
test/unit/helpers.lua:264: ';' expected near '__s128' at line 194'
exit code: 256

stack traceback:
test/unit/helpers.lua:748: in function 'itp_parent'
test/unit/helpers.lua:784: in function 
```

Since we don't use these types, they can be ignored to avoid LuaJIT's C
parser choking on them.

[6.5]: 
https://github.com/torvalds/linux/commit/224d80c584d3016cb8d83d1c33914fdd3508aa8c

(cherry picked from commit 9afbfb4d646cd240e97dbaae109f12bfc853112c)
Signed-off-by: James McCoy 
Closes: #1052945


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052945

Bug#1052799: closing 1052799

[James McCoy]

close 1052799 1.2.2-1
thanks

rust-xcb (1.2.2-1) unstable; urgency=medium

Bug#1051063: vim-scripts: no license assumption must be non-free

[James McCoy]

On Fri, Sep 01, 2023 at 11:04:44PM +0200, Bastian Germann wrote:
> In vim-script's copyright file, the following assumption is written:
> 
> "Summary of license information of each script is reported below. For scripts
> which license is "no license" it is assumed in good faith that having being
> posted on vim.org their licence is at least as free as the licence of Vim
> itself."
> 
> This assumption is wrong. International copyright agreements unfortunately 
> make
> those files non-DFSG-free.
> 
> Please move them affected files to a new source package with Section: 
> non-free/editors.

Honestly, this package probably should just be removed.  Most of the
scripts aren't maintained upstream anymore and are of questionable
utility.

I had been intending to split the package up anyway, but I'll probably
just package a couple of the more useful/maintained ones and then just
RM vim-scripts.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1050396: RM: pangoterm -- RoQA; low popcon; depends on gtk2

[James McCoy]

Control: forcemerge 967680 -1

On Thu, Aug 24, 2023 at 01:49:47AM +0200, Bastian Germann wrote:
> pangoterm does not seem to be used a lot and is unmaintained upstream.

It's not unmaintained upstream.

> I intend to file a RM bug.
> If you have any reasons to keep it in Debian please voice them here.

If more concrete plans develop to force gtk2 out of the archive, then
this package can be removed along with those.  Until then, leave it be.

> To get people's attention, I am filing as a serious bug and will reassign to
> the FTP team when the package is autoremoved from testing.

There was already a bug noting that this still depends on gtk2.  Merging
with that one and keeping its Severity: normal.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1034875: marked as pending in kitty

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1034875 in kitty reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/kitty/-/commit/b66f1fdd1774d353b9cd10946410b293f2eb0124


Ship kitty-open.desktop as an example

The desktop file registers itself as a handler for application/sh (and
related) mimetypes.  When it has priority in the mime database, this
will *execute* rather than *view* the file.

Even if those mimetypes were removed, there are also text/* mimetypes
that can be executed.

Since this is unexpected, and potentially dangerous (running
shellscripts when they were intended to be viewed), stop installing the
desktop file.

Instead, provide it as an example and describe how to enable, as well as
the caveats, in README.Debian.

Newer kitty versions will support[0] prompting the user before executing
executable files, but that can't be easily backported to the Python
version of the kitten.

[0]: 
https://github.com/kovidgoyal/kitty/commit/537cabca710f64b838d3b8b1dc986db596fb29d4

Closes: #1034875
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1034875

Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[James McCoy]

On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote:
> Executing the script as default open action is IMO a very bad idea
> because what you get by email is largely to not be trusted so I would
> suggest that kitty be modified to not execute scripts in its URL
> launcher mode (or that it gets some interactive confirmation from the
> user before executing it).

Upstream has added support for prompting if a file is executable[0].
However, the current upstream version of kitty has rewritten all of its
kittens in go, so the changes aren't trivially backported.

For bookworm, I'm going to stop installing kitty-open.desktop, by default.
Install, I will ship it under /usr/share/doc/kitty/examples and add a
note to README.Debian about it.

[0]: 
https://github.com/kovidgoyal/kitty/commit/537cabca710f64b838d3b8b1dc986db596fb29d4

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[James McCoy]

On Sat, May 06, 2023 at 04:07:56PM +0200, Gabriel Corona wrote:
> Hi,
> 
> > In the mean time, it's probably a good idea to drop
> > "application/x-sh;application/x-shellscript" from the list of supported
> > mime type to limit the risk. (I assume that even with "text/plain" and a
> > .sh file extension or a shebang, kitty might still decide to execute the
> > script... so the issue is not entirely fixed, but it reduces the number
> > of
> > cases where "kitty +open" is invoked on shell scripts)
> 
> Indeed, you can use a file with MIME type such as text/ascii or
> x-scheme-handler/kitty and a .tool file extension and it will be executed
> through kitty.
> 
> Affected software include: mail clients (mutt, Thunderbird [3,4]), browsers
> (Firefox [1,2]), PDF viewers (Okular [5]).
> 
> [1] https://www.gabriel.urdhr.fr/img/kitty-firefox1.png
> [2] https://www.gabriel.urdhr.fr/img/kitty-firefox2.png
> [3] https://www.gabriel.urdhr.fr/img/kitty-thunderbird1.png
> [4] https://www.gabriel.urdhr.fr/img/kitty-thunderbird2.png

The above examples prompt the user, so they're making an explicit
choice.  That's less of an issue.

> > Or it's the users responsibility to configure their system to
> > view shell files rather than execute them, if they are in the habit of
> > clicking exe's attached to emails or otherwise clicking untrusted shell
> > scripts.
> 
> Or it is our responsibility to ship with a secure by default configuration?

I'm leaning towards shipping kitty-open.desktop under
/usr/share/doc/kitty/examples and adding a note to README.Debian about
how to install it and the implications.  I've not used this particular
functionality of Kitty, so I'm not sure how this will change the usual
user experience.

However, I think this is a safer default and provides more information
to the user.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[James McCoy]

Keeping the full text for Kovid's benefit.

On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote:
> Package: kitty
> Version: 0.26.5-4
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Hello,
> 
> I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de
> in mutt and that mail contains 3 shell scripts as attachments
> (application/x-sh). I wanted to have a look at the scripts and thus I
> "opened" those attachments... that open operation has been handled by
> Kitty due its MimeType declaration in
> /usr/share/applications/kitty-open.desktop [1] and the shell script has
> thus been fed to "kitty +open 

Bug#1028442: vim-ultisnips: autopkgtest fails if Vim has non-contiguous patch ranges applied

[James McCoy]

Source: vim-ultisnips
Version: 3.2-1
Severity: serious
Tags: upstream
Justification: RT

Bookworm's Vim now has a non-contiguous set of patches applied:

% vim --version | grep Included
Included patches: 1-1000, 1087, 1117-1118, 1129

This is causing the "with-vim" autopkgtests to fail to parse the Vim
version.  For example:

==
ERROR: runTest 
(test_Autotrigger.Autotrigger_WillProduceNoExceptionWithVimLowerThan214.runTest)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.8wvyi1gs/downtmp/build.Ujt/src/test/vim_test_case.py", 
line 99, in setUp
reason_for_skipping = self.skip_if()
  ^^
  File 
"/tmp/autopkgtest-lxc.8wvyi1gs/downtmp/build.Ujt/src/test/test_Autotrigger.py", 
line 56, in 
if not check_required_vim_version(self)
   
  File 
"/tmp/autopkgtest-lxc.8wvyi1gs/downtmp/build.Ujt/src/test/test_Autotrigger.py", 
line 8, in check_required_vim_version
if not test.vim.has_version(7, 4, 214):
   ^^^
  File 
"/tmp/autopkgtest-lxc.8wvyi1gs/downtmp/build.Ujt/src/test/vim_interface.py", 
line 102, in has_version
_patch = int(line.split(":")[-1].strip().split("-")[-1])
 ^^^
ValueError: invalid literal for int() with base 10: '1118, 1129'

See the full log for more failures:
https://ci.debian.net/data/autopkgtest/unstable/i386/v/vim-ultisnips/30238961/log.gz

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1027824: FTBFS: hanging testsuite: build killed after time of inactivity on buildds

[James McCoy]

Control: forwarded -1 https://github.com/vim/vim/issues/11782

On Tue, Jan 03, 2023 at 10:39:02PM +0200, Adrian Bunk wrote:
> On Tue, Jan 03, 2023 at 09:15:03PM +0100, Salvatore Bonaccorso wrote:
> > Looking at the older build failures from
> > https://buildd.debian.org/status/logs.php?pkg=vim=amd64 it looks
> > it was always on x86-conova-01 when it failed.
> 
> The test seems to fail on IPV6-only buildds, I suspect something might 
> go wrong with the usage of "localhost" in this test without IPV4?

Thanks for the hints.  That allowed me to debug the issue.  I've
submitted a bug upstream and sent a PR which resolves the issue in my
testing.

https://github.com/vim/vim/pull/11783

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1027793: closed by Debian FTP Masters (reply to James McCoy ) (Bug#1027766: fixed in vim 2:9.0.1000-3)

[James McCoy]

On Tue, Jan 03, 2023 at 09:15:36PM +0100, Alejandro Colomar wrote:
> Hi,
> 
> On 1/3/23 17:09, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the vim-common package:
> > 
> > #1027793: vim: insert mode: Backspace doesn't do anything
> > 
> > It has been closed by Debian FTP Masters  
> > (reply to James McCoy ).
> > 
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP Masters 
> >  (reply to James McCoy 
> > ) by
> > replying to this email.
> > 
> 
> For my own curiosity, would you mind pointing to the specific change that
> fixed this bug?

https://salsa.debian.org/vim-team/vim/-/commit/7bdf6feff01b77304c2d1a8af335bd57689b4c66

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1027766: marked as pending in vim

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1027766 in vim reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/vim-team/vim/-/commit/7bdf6feff01b77304c2d1a8af335bd57689b4c66


Fix substitution of VIMCUR in vim-common.install

Closes: #1027766
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027766

Bug#1027566: marked as pending in neovim

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1027566 in neovim reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/vim-team/neovim/-/commit/dd9165a249022eb7d3c0b88cc040895a11d48ed3


Bump minimum lua-nvim to 0.2.4-1

0.2.4-1 changed how process exit is communicated, so the tests had to be
adapted accordingly.  The upstream fixes are in the previous commit, but
we need to ensure we're using a new enough lua-nvim when running with
these changes.

Closes: #1027566
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027566

Bug#1023529: marked as pending in subversion

[James McCoy]

Control: tag -1 pending

Hello,

Bug #1023529 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/-/commit/16964505e3be18838bb39d2870695da11624c85c


swig-py: Fix conditionals by SWIG version and by Python version for proxy code.

We are using different code for proxy object, by Python version and by SWIG
version.  The distinguish between Python 2 and Python 3 was done by SWIG
macro "SWIGPYTHON_PY3".  However, the macro was dropped since SWIG commit
a343b7e[1], between SWIG 4.0.2 release and upcoming SWIG 4.1.0 release.

As we already dropped support for the combination of SWIG >= 4.0 and Python 2,
we should detect Python 2 only in SWIG < 4.0 case. So we can rely on the macro
only in the case.

* subversion/bindings/swig/include/proxy.swg ():
  Reorder the conditionals distinguish SWIG versions and Python versions,
  as described above.

Found by: Jitka Plesnikova (jplesnik {_AT_} redhat.com)

Suggested by: Julien Schueller (schueller {_AT_} phimeca.com) [2]

[1] https://github.com/swig/swig/commit/a343b7e254567a64761bc1be7dc55b7b7424ec52
[2] https://github.com/swig/swig/issues/2373#issuecomment-1250997124

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1904167 
13f79535-47bb-0310-9956-ffa450edef68
Signed-off-by: James McCoy 
Closes: #1023529


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1023529

Bug#1022711: subversion: "svn --non-interactive status -v svn-md5" started by emacs hangs

[James McCoy]

Control: merge 1016889 1022711
Control: severity 1016889 important

On Mon, Oct 24, 2022 at 02:48:17PM +0200, Vincent Lefevre wrote:
> Control: retitle -1 svn tries to read a directory on a different filesystem 
> and hangs
> Control: severity -1 grave
> Control: tags -1 security
> 
> On 2022-10-24 14:21:53 +0200, Vincent Lefevre wrote:
> > I have a file called "svn-md5". When I want to open this file with
> > emacs (including "emacs -Q"), emacs runs
> > 
> >   svn --non-interactive status -v svn-md5
> > 
> > (I don't know why), but "svn --non-interactive status -v svn-md5"
> > hangs, so that I can't read the file.
> 
> Reproducible with just a "svn info". The reason is that svn tries
> to read "/home/.svn", which belongs to another filesystem and
> possibly to another user.

This looks like the same root case as #1016889.  Svn has to find the
single .svn directory that versions the given directory.  It walks up
the filesystem to do this, just like git, but seems to have looser
checks on which directories may be valid, which leads to issues like you
report and the one in #1016889.

> In addition to the hang, which affects
> other applications like emacs, this is potentially a security issue.
> svn should stop going up in the hierarchy once the mount point (or
> home directory?) has been reached, or at least once the owner of the
> directory changes.

Why?  There's nothing that says a working directory can't have
subdirectories owned by different users.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1022783: closing 1022783

[James McCoy]

close 1022783 0.9.4-2
thanks
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[James McCoy]

Control: severity -1 normal
Control: tag -1 - security

On Mon, Sep 19, 2022 at 02:53:24AM +0200, Vincent Lefevre wrote:
> On 2022-09-18 14:40:36 -0400, James McCoy wrote:
> > You're saying that the change you were preparing was lost, but nothing
> > was actually changed in svn, right?
> 
> Yes. What happens is that svn retrieves the current property value
> from the server, puts it in a file "/tmp/svn-prop.tmp" and runs an
> editor on this file. The user modifies this file and quits the
> editor. Then svn normally updates this property on the server
> (from the modified svn-prop.tmp) and removes this temporary file.
> The issue is that svn removes this file even when the update fails.

Ok.  I don't see this as either "critical" or a security issue.  "Data
loss" implies the actual versioned data is corrupted/lost.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[James McCoy]

On Sun, Sep 18, 2022 at 02:18:22AM +0200, Vincent Lefevre wrote:
> (The "critical" severity is in part because the data loss was
> triggered by a remote attack, though the data loss may occur
> with any kind of network failure.)
> 
> I wanted to edit a log message with
> 
>   svn pe --revprop svn:log -r 151946
> 
> (not just a minor change, I was replacing text by a much longer text),
> but got an immediate error from SSH after quitting the editor:
> 
> kex_exchange_identification: read: Connection reset by peer
> Connection reset by 155.133.131.76 port 22
> svn: E170013: Unable to connect to a repository at URL 'svn+ssh://mysvn'
> svn: E210002: To better debug SSH connection problems, remove the -q option 
> from 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: E210002: Network connection closed unexpectedly
> 
> Subversion apparently does not keep a copy of the text (contrary to
> the case of a commit, which leaves a svn-commit.tmp file), so the
> whole new text was lost!!!

You're saying that the change you were preparing was lost, but nothing
was actually changed in svn, right?

-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1019555: elan: Update dirs dependency

[James McCoy]

Source: elan
Version: 1.4.1-1
Severity: serious
Tags: ftbfs, patch
Justification: fails to build from source (but built successfully in the past)

I've uploaded rust-dirs 4.0.0, which will cause elan to FTBFS.  Attached
is an updated dependencies patch which built successfully locally.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Christopher Hoskin 
Date: Mon, 27 Jun 2022 01:31:31 +0100
Subject: dependencies

Forwarded: not-needed
---
 Cargo.toml| 11 +++
 src/elan-dist/Cargo.toml  |  7 +--
 src/elan-utils/Cargo.toml | 10 +++---
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/Cargo.toml b/Cargo.toml
index 5b85302..122e8a7 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -34,15 +34,15 @@ libc = "0.2.82"
 markdown = "0.3.0"
 rand = "0.8.2"
 regex = "1.4.3"
-remove_dir_all = "0.6.1"
+remove_dir_all = "0.7.0"
 same-file = "1.0.6"
 scopeguard = "1.1.0"
 serde = "1.0.119"
 serde_derive = "1.0.119"
 serde_json = "1.0.61"
-sha2 = "0.9.2"
+sha2 = "0.10.2"
 tempfile = "3.2.0"
-term = "0.7.0"
+term = "0.5.2"
 time = "0.3.4"
 toml = "0.5.8"
 url = "2.2.0"
@@ -52,11 +52,6 @@ tar = ">=0.4.36"
 flate2 = "1.0.14"
 json = "0.12.4"
 
-[target."cfg(windows)".dependencies]
-winapi = { version = "0.3.9", features = ["jobapi", "jobapi2", 
"processthreadsapi", "psapi", "synchapi", "winuser"] }
-winreg = "0.8.0"
-gcc = "0.3.55"
-
 [workspace]
 members = ["src/download", "src/elan-dist", "src/elan-utils"]
 
diff --git a/src/elan-dist/Cargo.toml b/src/elan-dist/Cargo.toml
index fb58e02..727946b 100644
--- a/src/elan-dist/Cargo.toml
+++ b/src/elan-dist/Cargo.toml
@@ -11,13 +11,12 @@ license = "MIT OR Apache-2.0"
 [dependencies]
 regex = "1.4.3"
 itertools = "0.10.0"
-ole32-sys = "0.2.0"
 url = "2.2.1"
 tar = "0.4.33"
 flate2 = "1.0.14"
 walkdir = "2.3.1"
 toml = "0.5.8"
-sha2 = "0.9.3"
+sha2 = "0.10.2"
 remove_dir_all = "0.7.0"
 elan-utils = { path = "../elan-utils" }
 error-chain = "0.12.4"
@@ -25,10 +24,6 @@ json = "0.12.4"
 zip = "0.5.13"
 filetime = "0.2.14"
 
-[target."cfg(windows)".dependencies]
-winapi = { version = "0.3.9", features = ["handleapi", "sysinfoapi", 
"tlhelp32", "winnt"] }
-winreg = "0.8.0"
-
 [target."cfg(not(windows))".dependencies]
 libc = "0.2.88"
 
diff --git a/src/elan-utils/Cargo.toml b/src/elan-utils/Cargo.toml
index 19ed717..790d8f4 100644
--- a/src/elan-utils/Cargo.toml
+++ b/src/elan-utils/Cargo.toml
@@ -14,16 +14,12 @@ libc = "0.2.88"
 rand = "0.8.3"
 remove_dir_all = "0.7.0"
 scopeguard = "1.1.0"
-semver = "0.11.0"
-sha2 = "0.9.3"
+semver = "0.9.0"
+sha2 = "0.10.2"
 toml = "0.5.8"
 url = "2.2.1"
 curl = "0.4.34"
-openssl = { version = "0.10", features = ["vendored"] }
+openssl = { version = "0.10" }
 regex = "1.4.3"
-dirs = "3.0.1"
+dirs = ">= 3.0.1, < 5.0"
 
-[target."cfg(windows)".dependencies]
-winapi = { version = "0.3.9", features = ["combaseapi", "errhandlingapi", 
"fileapi", "handleapi", 
-"ioapiset", "minwindef", "processthreadsapi", "shlobj", "shtypes", 
"userenv", "winbase", "winerror", "winnt", "winioctl"] }
-winreg = "0.8.0"

Bug#1006928: librust-phf-shared+uncased-dev depends on package that is not in Debian.

[James McCoy]

Control: tag -1 pending

On Tue, Mar 08, 2022 at 11:40:21AM +, peter green wrote:
> The most recent upload of rust-phf-shared added a new feature package,
> librust-phf-shared+uncased-dev which depends on librust-uncased-0.9-dev
> 
> rust-uncased is not in Debian and I cannot find any evidence of an attempt
> to package it.

Thanks for the notice.  I've uploaded the uncased crate to NEW.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1002164: rust-alacritty-terminal: FTBFS: build-dependency not installable: librust-signal-hook-registry-1.2+default-dev

[James McCoy]

On Tue, Dec 21, 2021 at 05:09:44PM +0100, Lucas Nussbaum wrote:
> > The following packages have unmet dependencies:
> >  librust-signal-hook-dev : Depends: 
> > librust-signal-hook-registry-1.2+default-dev but it is not installable
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.

This is waiting for signal-hook-mio to get through NEW, so signal-hook
can be updated.  Once that happens, if there hasn't been a new upstream,
release we can cherry-pick
https://github.com/alacritty/alacritty/pull/5609/commits/0189128a330af655a599b6d9dbaac49f7ba18e51
to fix rust-alacritty-terminal.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#981823: librust-alacritty-terminal-dev is not installable

[James McCoy]

On Sat, Aug 28, 2021, 15:39 Steve Langasek 
wrote:

> Note that although rust-alacritty-terminal may no longer need
> rust-terminfo,
> if it still depends on rust-vte, then the package is still not buildable
> because the only version of rust-vte in the archive is 0.3 and
> rust-alacritty-terminal requires 0.8.
>

Yeah, I'm working my way through the dependency stack.  Rust-vte and
rust-alacritty-terminal are going to be updated.

>

Bug#982684: subversion: FTBFS on armhf, mips64el: test failure

[James McCoy]

Control: forwarded -1 
https://mail-archives.apache.org/mod_mbox/subversion-dev/202102.mbox/%3C20210212173613.2qji5xpfmcybulyl%40localhost%3E

On Sat, Feb 13, 2021 at 01:23:05PM +, Ivo De Decker wrote:
> The latest upload of subversion to unstable fails on armhf and mips64el:
> 
> https://buildd.debian.org/status/package.php?p=subversion
> 
> On the first try, it failed on mipsel as well. Maybe the failing test is
> unreliable?

Thanks for the report.  I've already raised the issue upstream.  If I
can't get traction on it soon, I may just disable the test.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Thu, Feb 11, 2021 at 06:21:08AM +0100, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Wed, Feb 10, 2021 at 08:49:39PM -0500, James McCoy wrote:
> > On Wed, Feb 10, 2021 at 09:21:54PM +0100, Salvatore Bonaccorso wrote:
> > > Hi James,
> > > 
> > > On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> > > > On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > > > > The following vulnerability was published for subversion.
> > > > > 
> > > > > CVE-2020-17525[0]:
> > > > > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> > > > 
> > > > I'll have uploads ready for this tonight to both sid and buster.  I'll
> > > > send the debdiff for review before uploading to buster-security.
> > > 
> > > Ack, thank you!
> > 
> > Buster debdiff attached.
> 
> Looks good to me. Did you got an explicit chance to test the issue
> triggering setup?

I was able to verify with a new test upstream provided.  Backporting and
enabling that test in this upload is too disruptive, though.

I'll look into doing that for future sid uploads, as I see that the
current packaging is missing protocol specific runs of the test suite.

> In any case please feel free to upload to
> security-master.

Uploaded.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#981823: librust-alacritty-terminal-dev is not installable

[James McCoy]

On Thu, Feb 04, 2021 at 01:23:33PM +0200, Adrian Bunk wrote:
> The following packages have unmet dependencies:
>  librust-alacritty-terminal-dev : Depends: librust-terminfo-0.7+default-dev 
> (>= 0.7.1-~~) but it is not installable
>   Depends: librust-vte-0.8-dev but it is not 
> installable

The initial upload of rust-terminfo was REJECTed.  I believe the issues
have been addressed, but not uploaded, since then.  However, newer
versions of rust-alacritty-terminal no longer use rust-terminfo.

Since rust-alacritty-terminal is just part of the stack needed to get
alacritty packaged, I'll update it along with the rest of the work once
Bullseye is released.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Wed, Feb 10, 2021 at 09:21:54PM +0100, Salvatore Bonaccorso wrote:
> Hi James,
> 
> On Wed, Feb 10, 2021 at 03:20:22PM -0500, James McCoy wrote:
> > On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> > > The following vulnerability was published for subversion.
> > > 
> > > CVE-2020-17525[0]:
> > > | Remote unauthenticated denial-of-service in Subversion mod_authz_svn
> > 
> > I'll have uploads ready for this tonight to both sid and buster.  I'll
> > send the debdiff for review before uploading to buster-security.
> 
> Ack, thank you!

Buster debdiff attached.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
diffstat for subversion-1.10.4 subversion-1.10.4

 changelog   |8 
+++
 gbp.conf|2 
 patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch |   26 
++
 patches/series  |1 
 4 files changed, 36 insertions(+), 1 deletion(-)

diff -Nru subversion-1.10.4/debian/changelog subversion-1.10.4/debian/changelog
--- subversion-1.10.4/debian/changelog  2019-07-27 22:44:06.0 -0400
+++ subversion-1.10.4/debian/changelog  2021-02-10 15:15:45.0 -0500
@@ -1,3 +1,11 @@
+subversion (1.10.4-1+deb10u2) buster-security; urgency=high
+
+  * Backport security fixes from upstream:
++ CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion
+  mod_authz_svn  (Closes: #982464)
+
+ -- James McCoy   Wed, 10 Feb 2021 15:15:45 -0500
+
 subversion (1.10.4-1+deb10u1) buster-security; urgency=high
 
   * Backport security fixes from upstream:
diff -Nru subversion-1.10.4/debian/gbp.conf subversion-1.10.4/debian/gbp.conf
--- subversion-1.10.4/debian/gbp.conf   2019-07-27 22:44:06.0 -0400
+++ subversion-1.10.4/debian/gbp.conf   2021-02-10 15:15:45.0 -0500
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = upstream/1.10.x
-debian-branch = debian/sid
+debian-branch = debian/buster
 upstream-tag = upstream/%(version)s
 
 sign-tags = True
diff -Nru 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
--- 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
1969-12-31 19:00:00.0 -0500
+++ 
subversion-1.10.4/debian/patches/0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch
2021-02-10 15:15:45.0 -0500
@@ -0,0 +1,26 @@
+From: Stefan Sperling 
+Date: Fri, 29 Jan 2021 13:17:15 +
+Subject: Fix a potential NULL dereference in the config file parser.
+
+* subversion/libsvn_repos/config_file.c
+  (get_repos_config): svn_repos_find_root_path() may return NULL.
+   Check the return value accordingly.
+---
+ subversion/libsvn_repos/config_file.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/subversion/libsvn_repos/config_file.c 
b/subversion/libsvn_repos/config_file.c
+index 9187277..2414db9 100644
+--- a/subversion/libsvn_repos/config_file.c
 b/subversion/libsvn_repos/config_file.c
+@@ -237,6 +237,10 @@ get_repos_config(svn_stream_t **stream,
+ {
+   /* Search for a repository in the full path. */
+   repos_root_dirent = svn_repos_find_root_path(dirent, scratch_pool);
++  if (repos_root_dirent == NULL)
++return svn_error_trace(handle_missing_file(stream, checksum, access,
++   url, must_exist,
++   svn_node_none));
+ 
+   /* Attempt to open a repository at repos_root_dirent. */
+   SVN_ERR(svn_repos_open3(>repos, repos_root_dirent, NULL,
diff -Nru subversion-1.10.4/debian/patches/series 
subversion-1.10.4/debian/patches/series
--- subversion-1.10.4/debian/patches/series 2019-07-27 22:44:06.0 
-0400
+++ subversion-1.10.4/debian/patches/series 2021-02-10 15:15:45.0 
-0500
@@ -14,3 +14,4 @@
 0014-Provide-a-way-for-svnserve-s-get-deleted-rev-API-to-.patch
 0015-Adjust-expectations-of-a-new-test-to-account-for-dif.patch
 0016-In-svnserve-consistently-handle-errors-in-opening-a-.patch
+0017-Fix-a-potential-NULL-dereference-in-the-config-file-.patch

Bug#982464: subversion: CVE-2020-17525: Remote unauthenticated denial-of-service in Subversion mod_authz_svn

[James McCoy]

On Wed, Feb 10, 2021 at 03:36:11PM +0100, Salvatore Bonaccorso wrote:
> The following vulnerability was published for subversion.
> 
> CVE-2020-17525[0]:
> | Remote unauthenticated denial-of-service in Subversion mod_authz_svn

I'll have uploads ready for this tonight to both sid and buster.  I'll
send the debdiff for review before uploading to buster-security.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978353: marked as pending in serf

[James McCoy]

Control: tag -1 pending

Hello,

Bug #978353 in serf reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/serf/-/commit/17baa8f922362010416a91dadbcada79c2c2d447


Include upstream patch to fix OpenSSL 1.1.1i compat

Closes: #978353
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/978353

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[James McCoy]

On Fri, Jan 15, 2021 at 08:36:22AM -0500, Justin Erenkrantz wrote:
> Sadly, my Debian sid box ran into other issues and is currently inaccessible.
> 
> I *think* that this would address the 1.3.x test issues, but 1.3.x doesn't
> build on Mac OS for me for other reasons...so, let me know how it goes?  =)  
> --

Success!

Thanks,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[James McCoy]

Happy New Year!

On Wed, Dec 30, 2020 at 10:39:28PM -0500, James McCoy wrote:
> On Tue, Dec 29, 2020 at 02:35:11PM -0500, Justin Erenkrantz wrote:
> > The OpenSSL devs intended this to be a breaking change - but it's not
> > documented anywhere.  Sigh.
> > 
> > I've got a WIP patch against trunk that causes test_ssl to pass - see 
> > below. 
> > It also seems to work with OpenSSL 1.1.1h as well as OpenSSL 1.1.1i /
> > 1.1.1-stable, AFAICT.
> > 
> > James: can you please give it a try as well?
> 
> Yes, I can confirm this fixes test_ssl_handshake on trunk.  There's
> enough difference between trunk and branches/1.3.x that it doesn't apply
> cleanly there.

Any chance you would be able to make a patch for 1.3.x?  Although a 1.4
release would be nice, it's a bit late in the Debian release cycle to
upload a major new version.

A targeted fix for the test suite would address the immediate issue,
though.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[James McCoy]

On Tue, Dec 29, 2020 at 02:35:11PM -0500, Justin Erenkrantz wrote:
> The OpenSSL devs intended this to be a breaking change - but it's not
> documented anywhere.  Sigh.
> 
> I've got a WIP patch against trunk that causes test_ssl to pass - see below. 
> It also seems to work with OpenSSL 1.1.1h as well as OpenSSL 1.1.1i /
> 1.1.1-stable, AFAICT.
> 
> James: can you please give it a try as well?

Yes, I can confirm this fixes test_ssl_handshake on trunk.  There's
enough difference between trunk and branches/1.3.x that it doesn't apply
cleanly there.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[James McCoy]

On Sun, Dec 27, 2020 at 10:46:24AM -0500, Justin Erenkrantz wrote:
> Thanks.  I expect that this might be due to the last change - erroring out on
> an expired self-signed root cert.  Though I thought we didn’t check in a root
> cert for our test chain...could Debian’s packaging be including a cert for
> testing?

I use create_certs.py from trunk to re-generate the test certificates
every build, otherwise I was running into time bombs with the certs
expiring.  Other than that, I don't do anything different than the
normal test process.

The Debian packaging does have some local patches[0] applied to address
issues that have been fixed upstream but not yet released.

[0]: https://sources.debian.org/patches/serf/1.3.9-8/

> I will try to take a look this week with Debian sid...I assume it has 1.1.1i
> already?  — justin 

Yes, it does.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[James McCoy]

On Sat, Dec 26, 2020 at 11:09:41PM +0100, Lucas Nussbaum wrote:
> Source: serf
> Version: 1.3.9-8
> [...]
> > Trailer-Test: f
> > ...F..
> > 
> > There was 1 failure:
> > 1) test_ssl_handshake: test/test_util.c:456: expected <0> but was <120199>

It looks like the change from libssl1.1 version 1.1.1h to 1.1.1i
regressed this test.

The documented changes between these two releases are:

 Changes between 1.1.1h and 1.1.1i [8 Dec 2020]

  *) Fixed NULL pointer deref in the GENERAL_NAME_cmp function
 This function could crash if both GENERAL_NAMEs contain an EDIPARTYNAME.
 If an attacker can control both items being compared  then this could lead
 to a possible denial of service attack. OpenSSL itself uses the
 GENERAL_NAME_cmp function for two purposes:
 1) Comparing CRL distribution point names between an available CRL and a
CRL distribution point embedded in an X509 certificate
 2) When verifying that a timestamp response token signer matches the
timestamp authority name (exposed via the API functions
TS_RESP_verify_response and TS_RESP_verify_token)
 (CVE-2020-1971)
 [Matt Caswell]

  *) Add support for Apple Silicon M1 Macs with the darwin64-arm64-cc target.
 [Stuart Carnie]

  *) The security callback, which can be customised by application code, 
supports
 the security operation SSL_SECOP_TMP_DH. This is defined to take an 
EVP_PKEY
 in the "other" parameter. In most places this is what is passed. All these
 places occur server side. However there was one client side call of this
 security operation and it passed a DH object instead. This is incorrect
 according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with 
all
 of the other locations. Therefore this client side call has been changed to
 pass an EVP_PKEY instead.
 [Matt Caswell]

  *) In 1.1.1h, an expired trusted (root) certificate was not anymore rejected
 when validating a certificate path. This check is restored in 1.1.1i.
 [David von Oheimb]

The full diff is at 
https://github.com/openssl/openssl/compare/OpenSSL_1_1_1h...OpenSSL_1_1_1i

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#975239: python-pynvim: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[James McCoy]

Control: forcemerge 975237 -1

On Thu, Nov 19, 2020 at 12:56:31PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > collecting ... collected 68 items
> > 
> > test/test_buffer.py::test_repr PASSED[  
> > 1%]
> > test/test_buffer.py::test_get_length PASSED  [  
> > 2%]
> > test/test_buffer.py::test_get_set_del_line PASSED[  
> > 4%]
> > test/test_buffer.py::test_get_set_del_slice PASSED   [  
> > 5%]
> > test/test_buffer.py::test_vars PASSED[  
> > 7%]
> > test/test_buffer.py::test_api PASSED [  
> > 8%]
> > test/test_buffer.py::test_options PASSED [ 
> > 10%]
> > test/test_buffer.py::test_number PASSED  [ 
> > 11%]
> > test/test_buffer.py::test_name PASSED[ 
> > 13%]
> > test/test_buffer.py::test_valid PASSED   [ 
> > 14%]
> > test/test_buffer.py::test_append PASSED  [ 
> > 16%]
> > test/test_buffer.py::test_mark PASSED[ 
> > 17%]
> > test/test_buffer.py::test_invalid_utf8 
> > E: Build killed with signal TERM after 150 minutes of inactivity

Same issue was filed yesterday, against both python-msgpack and
python-pynvim.  I'll merge this one with python-pynvim's bug.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#975087: Not relevant to msgpack itself, therefore

[James McCoy]

Control: reopen -1

On Thu, Nov 19, 2020 at 12:32:53AM +0100, Thomas Goirand wrote:
> Since James McCoy says it's fixed in python-pynvim 0.4.2, I'm closing
> this bug for msgpack.

I was referring to the upstream version, which has not been packaged
yet.  Also, this bug was filed against *both* packages, so it shouldn't
be closed without any resolution.

It seems to me that the bug should be cloned -- one for python-msgpack
to add a Breaks against python-pynvim << 0.4.2~ (to avoid issues with
partial upgrades) and one to fix python-pynvim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#975087: python-msgpack breaks python-pynvim autopkgtest: times out after 2:47 hours

[James McCoy]

On Wed, Nov 18, 2020, 15:21 Paul Gevers  wrote:

> Source: python-msgpack, python-pynvim
> Control: found -1 python-msgpack/1.0.0-4
> Control: found -1 python-pynvim/0.4.1-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update timeout
>
> Dear maintainer(s),
>
> With a recent upload of python-msgpack the autopkgtest of python-pynvim
> fails in testing when that autopkgtest is run with the binary packages
> of python-msgpack from unstable. It passes when run with only packages
> from testing. In tabular form:
>
>passfail
> python-msgpack from testing1.0.0-4
> python-pynvim  from testing0.4.1-2
> all others from testingfrom testing
>

This should be fixed by python-pynvim 0.4.2.

>

Bug#974950: vim-scripts: missing vim-addon-manager registry file

[James McCoy]

On Tue, Nov 17, 2020 at 02:43:55PM -0300, Antonio Terceiro wrote:
> On Mon, Nov 16, 2020 at 07:04:26PM -0500, James McCoy wrote:
> > On Mon, Nov 16, 2020 at 08:41:57PM -0300, Antonio Terceiro wrote:
> > > The new vim-scripts breaks existing usage with vim-addon-manager.
> > > 
> > > It is missing the vim-addon-manager registry file, and moving the files
> > > around breaks existing users.
> > 
> > Please see the NEWS file.  This was changed to not use vim-addon-manager
> > anymore.
> 
> Ah, I missed that. Sorry for the noise. FWIW I would expect such a
> change to also be explicitly mentioned in the changelog.

The general change was, but not the specific details on how to adapt to
the change:

  * Refactor packaging to use dh-vim-addon instead of vim-addon-manager
+ Add Build-Depends on dh-vim-addon
+ Remove vim/vim-addon-manager Recommends.  Replaced by Depends on
  ${vim-addon:Depends}
+ Install each plugin in its own sub-directory of /usr/share/vim-scripts

> Do you think vim-addon-manager should be deprecated and eventually
> removed?

Yes.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#957592: neovim: ftbfs with GCC-10

[James McCoy]

On Fri, Apr 17, 2020 at 11:07:04AM +, Matthias Klose wrote:
> [...]
> /usr/bin/ld: src/nvim/CMakeFiles/nvim.dir/sign.c.o (symbol from plugin): in 
> function `init_signs':
> (.text+0x0): multiple definition of `ListLenSpecials'; 
> src/nvim/CMakeFiles/nvim.dir/auto/msgpack_lua_c_bindings.generated.c.o 
> (symbol from plugin):(.text+0x0): first defined here
> /usr/bin/ld: src/nvim/CMakeFiles/nvim.dir/spell.c.o (symbol from plugin): in 
> function `spelltab':
> (.text+0x0): multiple definition of `RemapValues'; 
> src/nvim/CMakeFiles/nvim.dir/auto/msgpack_lua_c_bindings.generated.c.o 
> (symbol from plugin):(.text+0x0): first defined here
> /usr/bin/ld: src/nvim/CMakeFiles/nvim.dir/spell.c.o (symbol from plugin): in 
> function `spelltab':
> (.text+0x0): multiple definition of `ListLenSpecials'; 
> src/nvim/CMakeFiles/nvim.dir/auto/msgpack_lua_c_bindings.generated.c.o 
> (symbol from plugin):(.text+0x0): first defined here

This is fixed upstream.  I'm trying to finish a new upstream release to
fix this, among other issues.  However, if I can't get to that in the
next couple days, I'll upload an update to Debian with just these fixes
applied.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#965301: opendht FTBFS in unstable.

[James McCoy]

On Sun, Jul 19, 2020 at 03:30:18AM +0100, peter green wrote:
> Secondly on architectures where the build can be attempted it is failing
> with
> 
> > [  3%] Building CXX object CMakeFiles/opendht-static.dir/src/utils.cpp.o
> > /usr/bin/c++  -DASIO_STANDALONE -DOPENDHT_LOG=true -DOPENDHT_PEER_DISCOVERY 
> > -DPACKAGE_VERSION=\"2.1.0\" -I/<>/. -I/<>/include 
> > -I/<>/include/opendht 
> > -I/<>/obj-x86_64-linux-gnu/include  -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-return-type 
> > -Wall -Wextra -Wnon-virtual-dtor -pedantic-errors -fvisibility=hidden 
> > -DMSGPACK_DISABLE_LEGACY_NIL -DMSGPACK_DISABLE_LEGACY_CONVERT -fPIC   
> > -std=gnu++14 -o CMakeFiles/opendht-static.dir/src/utils.cpp.o -c 
> > /<>/src/utils.cpp
> > In file included from /usr/include/msgpack/adaptor/cpp11/chrono.hpp:14,
> >  from /usr/include/msgpack/type.hpp:38,
> >  from /usr/include/msgpack.hpp:22,
> >  from /<>/include/opendht/utils.h:23,
> >  from /<>/src/utils.cpp:23:
> > /usr/include/msgpack/v1/adaptor/cpp11/chrono.hpp:20:10: fatal error: 
> > boost/numeric/conversion/cast.hpp: No such file or directory
> >20 | #include 
> >   |  ^~~
> > compilation terminated.
> 
> I am ccing the msgpack-c maintainers in case this is a problem in that 
> package.

Yes, in this case it is, since that code doesn't require explicit opt-in
to use boost.  I'll update libmsgpack-dev's Depends.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#956007: marked as pending in mercurial

[James McCoy]

On Thu, Jun 25, 2020, 06:54 Julien Cristau  wrote:

>
>
> https://salsa.debian.org/python-team/applications/mercurial/-/commit/306a0553aa60103c40bd0a89de6e2d67f3b851ff
>
> 
> Remove python-subversion from autopkgtest dependencies (closes: #956007)
> 
>

It seems I didn't send the follow-up I intended. The python3-subversion
package is available in Sid, in case that would affect the change.

Cheers,
James

>

Bug#954866: Bug#953881: transition: ruby2.7 only

[James McCoy]

On Thu, Apr 23, 2020 at 02:09:35PM +0200, Paul Gevers wrote:
> I
> suggest you apply the same fix you already did here [2] and stop
> building the python package for now if that works.

Done and uploaded, however that now makes mercurial FTBFS, as I had
notified them earlier this month (#956007).  I've now raised that bug to
serious.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954866: Bug#953881: transition: ruby2.7 only

[James McCoy]

On Thu, Apr 23, 2020 at 10:13:15AM +0200, Paul Gevers wrote:
> It seems the ruby2.5 removal transition [1] is stalled by subversion
> [2]. Can the fix for 954866 please be uploaded to unstable such that
> subversion can migrate and we can finish the removal of ruby2.5 in testing?

I'd rather not upload an RC.  The ETA for the actual release is May
27th.

There don't seem to be any users of ruby-svn in the archive, so maybe
it's best to remove that from testing in the interim?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954866: marked as pending in subversion

[James McCoy]

Control: tag -1 pending

Hello,

Bug #954866 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/-/commit/a6ef88eeceb38b0916abc0bfe2b4c57cc9a0041d


Disable building python-subversion if SWIG 4.0 is installed

The python2 bindings can't be built with SWIG 4.0.  The next upstream
subversion release is going to have support for Python 3, so the
bindings will be re-enabled then.

Closes: #954866
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/954866

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

Control: severity -1 normal

On Sun, Mar 22, 2020 at 02:57:54PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> [...]
> > Trailer-Test: f
> > 140691743627136:error:14095126:SSL routines:ssl3_read_n:unexpected eof 
> > while reading:../ssl/record/rec_layer_s3.c:302:
> > ..F...
> > 
> > There was 1 failure:
> > 1) test_ssltunnel_basic_auth_server_has_keepalive_off: 
> > test/test_context.c:2138: expected <0> but was <120199>
> > 
> > !!!FAILURES!!!
> > Runs: 66 Passes: 65 Fails: 1

This was caused by a change in OpenSSL 1.1.1e, which has been reverted
in 1.1.1f.  As such, I'm lowering the severity to normal but keeping it
open since there is still an intention to reinstate this change in
OpenSSL in the future.

Serf has plans to add handling for this, so I'll close it once I get
their fixed version uploaded.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

On Mon, Mar 30, 2020 at 07:00:46PM -0400, James McCoy wrote:
> On Mon, Mar 30, 2020 at 02:53:40PM -0400, Justin Erenkrantz wrote:
> > Here's a tentative patch that causes the test cases to pass with OpenSSL
> > 1.1.1e+ for me on Debian Sid.
> > 
> > James, can you please give it a go and confirm that it works for you?
> 
> The package does build and pass tests with the patch.  Thanks!
> 
> > Before I commit, we'd also need to gate this based on the new OpenSSL
> > constant.  We could gate based upon the OpenSSL version number, but I think
> > if we can confine to this one area, gating based on ifdef is likely prudent.
> 
> +1

Just as an FYI, the OpenSSL changes have been partially reverted[1]
upstream for the 1.1.1f release.  The change will be re-introduced in
3.0, so using the ifdef, instead of OpenSSL version, was the prudent
choice.

[1]: https://github.com/openssl/openssl/pull/11400

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

On Mon, Mar 30, 2020 at 02:53:40PM -0400, Justin Erenkrantz wrote:
> Here's a tentative patch that causes the test cases to pass with OpenSSL
> 1.1.1e+ for me on Debian Sid.
> 
> James, can you please give it a go and confirm that it works for you?

The package does build and pass tests with the patch.  Thanks!

> Before I commit, we'd also need to gate this based on the new OpenSSL
> constant.  We could gate based upon the OpenSSL version number, but I think
> if we can confine to this one area, gating based on ifdef is likely prudent.

+1

> I'd also like to get the scons patch you sent earlier into a new release.
> I'm hopeful that I can cut a new 1.3 release sometime this week and have
> others vote on it - that should make your downstream efforts a bit easier.

That would be appreciated.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

On Fri, Mar 27, 2020 at 05:15:24PM -0400, Justin Erenkrantz wrote:
> James,
> 
> I finally got a Debian sid environment up.  However, I'm seeing a different
> sets of test failures right now against vanilla serf 1.4.x and trunk (which
> works with the scons/python3 in sid without a patch AFAICT) - this is with
> 1.4.x branch:

I haven't tested what happens with 1.4.x, since there hasn't been a
release yet.

Are the test certs expired?  I automatically run
test/certs/create_certs.py as part of the build process to ensure that
doesn't happen.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

On Wed, Mar 25, 2020 at 08:57:14AM -0400, Justin Erenkrantz wrote:
> James,
> 
> Thanks for the bug report.  For reference, the upstream OpenSSL commit looks 
> to
> be:
> 
> https://github.com/openssl/openssl/commit/
> d924dbf4ae127c68463bcbece04b6e06abc58928
> 
> I strongly suspect that the patch on our side (against 1.3.x) is something 
> akin
> to below.  I'm having trouble getting a test environment up with the latest
> OpenSSL to reproduce, so if anyone can test in the interim, that'd be
> appreciated.

Latest Debian sid has everything ready to test, although you'll need the
patch I'm carrying to build since SCons is using Python 3.  That reminds
me, I was supposed to send that to the list awhile back.

>   If not, I'll try again as time (and kiddo) permit.

Unfortunately, that didn't have any effect.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#951893: marked as pending in subversion

[James McCoy]

Control: tag -1 pending

Hello,

Bug #951893 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/-/commit/03f9b7c539004bf9f616254ff00aeca8df9418d8


Build with swig3.0 to fix FTBFS with swig4.0

The Python2 swig bindings currently build using swig's -classic switch,
which no longer exists in swig4.0.  The changes to support building
without that are coming in the next subversion release, but are too
invasive to backport.

Explicitly build with swig3.0 for now to work around the problem, and
unblock various transitions.

Closes: #951893
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/951893

Bug#951893: subversion FTBFS with swig 4.0.1

[James McCoy]

On Mon, Mar 23, 2020 at 12:50:42PM -0300, Lucas Kanashiro wrote:
> diff -Nru subversion-1.13.0/debian/control 
> subversion-1.13.0.new/debian/control
> --- subversion-1.13.0/debian/control  2020-01-19 10:59:14.0 -0300
> +++ subversion-1.13.0.new/debian/control  2020-03-23 11:39:46.474677200 
> -0300
> @@ -32,7 +32,7 @@
> rename,
> ruby,
> ruby-dev,
> -   swig,
> +   swig3.0,

I had forgotten that multiple versions of swig were still in the
archive.  This will work around the issue until next upstream release
happens.
> zlib1g-dev
>  Build-Conflicts: libsvn-dev (<< 1.13~)
>  Rules-Requires-Root: no
> diff -Nru subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch 
> subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch
> --- subversion-1.13.0/debian/patches/fix-swig-ruby-includes.patch 
> 1969-12-31 21:00:00.0 -0300
> +++ subversion-1.13.0.new/debian/patches/fix-swig-ruby-includes.patch 
> 2020-03-23 11:39:46.450677157 -0300
> @@ -0,0 +1,15 @@
> +Description: Do not include ruby include subdir which has headers that
> + clash with standard ones, such as assert.h.
> +Author: Dimitri John Ledkov 
> +
> +--- a/build/ac-macros/swig.m4
>  b/build/ac-macros/swig.m4
> +@@ -168,7 +168,7 @@
> + AC_CACHE_CHECK([for Ruby include path], [svn_cv_ruby_includes],[
> + if test -d "$rbconfig_rubyhdrdir"; then
> +   dnl Ruby >=1.9
> +-  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
> -I$rbconfig_rubyhdrdir/ruby -I$rbconfig_rubyhdrdir/ruby/backward"
> ++  svn_cv_ruby_includes="-I. -I$rbconfig_rubyhdrdir 
> -I$rbconfig_rubyhdrdir/ruby/backward"

The use of /ruby looks like a very old change, which isn't needed
anymore.  I'll forward this upstream.

Thanks for the info and patches.  I'll get a new upload ready soon.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[James McCoy]

Looping in upstream:

On Sun, Mar 22, 2020 at 02:57:54PM +0100, Lucas Nussbaum wrote:
> Version: 1.3.9-8

This is the same version of the serf package that's been in Debian since
2019/12/31, so something else seems to have changed.

> [...]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > [...]
> > Trailer-Test: f
> > 140691743627136:error:14095126:SSL routines:ssl3_read_n:unexpected eof 
> > while reading:../ssl/record/rec_layer_s3.c:302:
> > ..F...
> > 
> > There was 1 failure:
> > 1) test_ssltunnel_basic_auth_server_has_keepalive_off: 
> > test/test_context.c:2138: expected <0> but was <120199>

Running a bisect against what's changed in the archive, shows that the
test started failing when OpenSSL's version changed from 1.1.1d-2 to
1.1.1e-1.

Looking at OpenSSL's changelog, it seems this was a change on their end
that's affecting serf.

 Changes between 1.1.1d and 1.1.1e [17 Mar 2020]
  *) Properly detect EOF while reading in libssl. Previously if we hit an EOF
 while reading in libssl then we would report an error back to the
 application (SSL_ERROR_SYSCALL) but errno would be 0. We now add
 an error to the stack (which means we instead return SSL_ERROR_SSL) and
 therefore give a hint as to what went wrong.
 [Matt Caswell]

I guess serf needs to adapt to this change in behavior.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#953742: vim: FTBFS on armel, armhf, i386, mips64el, mipsel, s390x

[James McCoy]

On Thu, Mar 12, 2020 at 08:28:19PM +, Ivo De Decker wrote:
> The latest upload of vim to unstable fails on armel, armhf, i386, mips64el, 
> mipsel, s390x:
> 
> https://buildd.debian.org/status/package.php?p=vim

At least the 32-bit arch failures are understood and I've already given
upstream a fix.  Will upload a new version soon with that fix.

The others look like more of Vim's flaky tests, which I don't yet have a
good way to manage.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#951893: subversion FTBFS with swig 4.0.1

[James McCoy]

On Sat, Feb 22, 2020 at 08:19:30PM +0200, Adrian Bunk wrote:
> ...
> /usr/bin/swig -I/build/1st/subversion-1.13.0/BUILD/subversion 
> -I/build/1st/subversion-1.13.0/subversion/include 
> -I/build/1st/subversion-1.13.0/subversion/bindings/swig 
> -I/build/1st/subversion-1.13.0/subversion/bindings/swig/include 
> -I/build/1st/subversion-1.13.0/subversion/bindings/swig/proxy 
> -I/build/1st/subversion-1.13.0/BUILD/subversion/bindings/swig/proxy 
> -I/usr/include/apr-1.0  -I/usr/include/apr-1.0 -I/usr/include  -python  
> -classic -o subversion/bindings/swig/python/core.c 
> /build/1st/subversion-1.13.0/subversion/bindings/swig/core.i
> Deprecated command line option: -classic. This option is no longer supported.
> make[1]: *** [/build/1st/subversion-1.13.0/build-outputs.mk:290: 
> subversion/bindings/swig/python/core.c] Error 1

Unfortunately, just removing -classic has a lot of other implications,
which aren't straight forward to fix.  There _are_ fixes upstream, but
as part of a much larger set of changes to make the swig bindings
compatible with Python3.

I might need to wait for the next upstream release.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#950496: msgpack-c: FTBFS on 32-bit: error: narrowing conversion of ‘4294967295’ from ‘long unsigned int’ to ‘__time_t’ {aka ‘long int’}

[James McCoy]

Control: tag -1 fixed-upstream

On Sun, Feb 02, 2020 at 04:47:26PM +0100, Andreas Beckmann wrote:
> msgpack-c/experimental on all 32-bit architectures:
> https://buildd.debian.org/status/package.php?p=msgpack-c=experimental

Yes, that and #950460 are the main reasons I haven't uploaded this to
unstable yet.

Upstream already has a fix, which I was already working on backporting.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#948770: marked as pending in subversion

[James McCoy]

Control: tag -1 pending

Hello,

Bug #948770 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/commit/6196c3e30966fee3f58663eeeaae6d39d306b5c7


use python2 as the interpreter now for tests, not python

/usr/bin/python is no longer guaranteed to exist, per PEP 394.  Use
python2 instead for compatibility.

Closes: #948770
Signed-off-by: James McCoy 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/948770

Bug#948269: file: misdetection of shared libraries as statically linked - breaks dh_shlibdeps

[James McCoy]

On Mon, Jan 06, 2020 at 12:19:21PM +0100, Christoph Biedl wrote:
> Additionally, I always upload new upstream versions of src:file to
> experimental first to avoid situations like this. If anybody wishes to
> receive a notification to start tests, drop me a line with your e-mail
> address, preferably group/team/package address. That list is public.

Autopkgtests already run against packages in experimental, albeit at a
slower pace than those in unstable.  It seems those did catch the issue
-- https://release.debian.org/britney/pseudo-excuses-experimental.html#file

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#945605: closing 914963, closing 945605

[James McCoy]

# These were fixed with upstream's 0.4.0 release, but I forgot to include the
# Closes entries in the changelog
#
#  * New upstream version 0.4.0
#- Fix FTBFS with neovim >= 0.4 (Closes: #945605)
#- Renamed to python-pynvim (Closes: #914963)
close 914963 python-pynvim/0.4.0-1
close 945605 python-pynvim/0.4.0-1
thanks
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#945605: python-neovim: diff for NMU version 0.3.0-1.1

[James McCoy]

On Mon, Dec 23, 2019 at 12:36:25PM +0200, Adrian Bunk wrote:
> I've prepared an NMU for python-neovim (versioned as 0.3.0-1.1) and 
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.

I've uploaded the new upstream version (0.4.0) which contains these
fixes.  It's going through NEW though, since I also followed upstream's
rename (now src:python-pynvim, python3-pynvim).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#930020: 8.1.* patches

[James McCoy]

On Fri, Jun 14, 2019 at 02:38:57PM +0800, Alastair Irvine wrote:
> On Thu, Jun 06, 2019 at 22:13:22 -0400, James McCoy wrote:
> > Unfortunately, the update isn't going to be as simple for
> > Jessie/Stretch.  The functionality relied upon for check_secure() to
> > work correctly relies on a number of earlier patches in the 8.1 series
> > (as I discovered with neovim).
> > 
> > I think all of these need to be ported for a complete solution:
> > 
> > * 8.1.0177
> > * 8.1.0189
> > * 8.1.0538
> > * 8.1.0544
> > * 8.1.0546
> > * 8.1.0547
> > * 8.1.0613
> > * 8.1.1046
> > * 8.1.1365
> 
> Does anyone need help back-porting the required patches for stretch?

The list ended up being longer than above.  I've nearly finished.
Hoping to get it done this weekend.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#920042: lua-nvim: autopkgtest times out since 2019-01-10

[James McCoy]

On Mon, Jan 21, 2019 at 09:17:00PM +0100, Paul Gevers wrote:
> Since 2019-01-10 the autopkgtest of your package times out (after 2:47h)
> on ci.debian.net. Unfortunately, this most likely isn't caused by any of
> your direct (test) dependencies, otherwise the integration with our
> migration software should have caught it. The timeout also happens in
> testing. If the content of our log is correct, the following files may
> hint at the culprit:
> https://ci.debian.net/data/packages/testing/amd64/l/lua-nvim/1696673.log
> https://ci.debian.net/data/packages/unstable/amd64/l/lua-nvim/1675059.log

It actually was caused by a test dependency (via @builddeps@) -- neovim.
I don't see a migration check that ran lua-nvim's tests as part of
neovim's migration.

I'll be committing the attached patch upstream.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>From 24fe448aa406b0aa2267044a9858e3d2e5963b61 Mon Sep 17 00:00:00 2001
From: James McCoy 
Date: Sun, 3 Mar 2019 11:49:54 -0500
Subject: [PATCH] Use --embed --headless for Socket/TcpStream session tests

After neovim/neovim#9024, "nvim --embed" waits for a UI to attach.
"nvim --embed --headless" is required if there is not going to be a UI.
---
 test/session_spec.lua | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/session_spec.lua b/test/session_spec.lua
index d5d705c..1fc289d 100644
--- a/test/session_spec.lua
+++ b/test/session_spec.lua
@@ -155,7 +155,7 @@ end)
 -- Session using SocketStream
 test_session(string.format("Session using SocketStream [%s]", socket_file), function ()
   child_session = Session.new(ChildProcessStream.spawn({
-nvim_prog, '-u', 'NONE', '--embed',
+nvim_prog, '-u', 'NONE', '--embed', '--headless',
 '--cmd', string.format('call serverstart("%s")', socket_file)
   }))
   child_session:request('vim_eval', '1') -- wait for nvim to start
@@ -193,7 +193,7 @@ end)
 -- Session using TcpStream
 test_session("Session using TcpStream", function ()
   child_session = Session.new(ChildProcessStream.spawn({
-nvim_prog, '-u', 'NONE', '--embed',
+nvim_prog, '-u', 'NONE', '--embed', '--headless',
 '--cmd', 'call serverstart("127.0.0.1:")'
   }))
 
-- 
2.20.1

Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file

[James McCoy]

Package: libtool-bin
Version: 2.4.6-7
Severity: serious
File: /usr/bin/libtool

The amd64 package, the only one not built on a buildd, contains a
zero-byte /usr/bin/libtool.  This makes it completely non-functional.

$ dpkg-deb -c libtool-bin_2.4.6-7_amd64.deb
drwxr-xr-x root/root 0 2019-01-12 09:10 ./
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/
-rwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/libtool
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/doc/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/doc/libtool-bin/
-rw-r--r-- root/root  9329 2019-01-12 09:10 
./usr/share/doc/libtool-bin/changelog.Debian.gz
-rw-r--r-- root/root342562 2015-02-15 12:15 
./usr/share/doc/libtool-bin/changelog.gz
-rw-r--r-- root/root  1976 2019-01-12 09:10 
./usr/share/doc/libtool-bin/copyright
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/man/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/man/man1/
-rw-r--r-- root/root20 2019-01-12 09:10 
./usr/share/man/man1/libtool.1.gz

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtool-bin depends on:
ii  libtool  2.4.6-7

libtool-bin recommends no packages.

libtool-bin suggests no packages.

-- no debconf information

Bug#911944: neovim FTBFS: tests fail

[James McCoy]

Version: 0.3.2-1

On Sat, Nov 10, 2018 at 03:36:08PM -0500, James McCoy wrote:
> On Sat, Nov 10, 2018 at 04:09:55PM +0100, Helmut Grohne wrote:
> > I also tried in pbuilder and there I only got the utf_char2bytes
> > failure, not the ones with check_cores. This hints that something about
> > my build environment is fishy. If I understand correctly, my user's
> > resource limits "leak" through sbuild while they don't pass through
> > pbuilder. Would limiting the number of processes or virtual memory be a
> > plausible explanation for the failures?
> 
> Possibly.  I can more reliably hit the utf_char2bytes failure when I
> have other builds running in parallel.  It seems to correlate with
> resource contention.

The utf_char2bytes test was fixed in 0.3.2, and some of the more
reliably flaky tests are now getting skipped on Debian builds.

I'm going to close this particular report.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

[James McCoy]

On Sun, Dec 30, 2018 at 09:30:34PM -0500, James McCoy wrote:
> Dropping debhelper and related bug, since this is just about libtermkey.
> 
> On Sun, Dec 30, 2018 at 08:22:00PM +, Niels Thykier wrote:
> > Anyhow, on to the details I have found:
> > 
> >  * Only test case 05flags.t fails and only if stdin is a *readable*
> >non-tty (e.g. /dev/null, an empty file or a non-empty file)
> > 
> >  […]
> > 
> >  * If the TERM is set to "dump", the test hangs.
> 
> Both of these issues have come up before in #809162.

Sorry, that should be #809192.

> At the time, I
> sent a patch to libtermkey's upstream to avoid the crash and then forgot
> to follow up on it.
> 
> I've sent a prod and will try to keep on top of it better this time. :)

He's looking into both issues (libtermkey NULL pointer crash and
libterm-termkey-perl's 05flags.t hang) now.  They're primarily test
issues, since it should be expected that normal use of these libraries
would have a valid TERM in the environment.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#917592: libterm-termkey-perl: FTBFS (failing tests)

[James McCoy]

Dropping debhelper and related bug, since this is just about libtermkey.

On Sun, Dec 30, 2018 at 08:22:00PM +, Niels Thykier wrote:
> Anyhow, on to the details I have found:
> 
>  * Only test case 05flags.t fails and only if stdin is a *readable*
>non-tty (e.g. /dev/null, an empty file or a non-empty file)
> 
>  […]
> 
>  * If the TERM is set to "dump", the test hangs.

Both of these issues have come up before in #809162.  At the time, I
sent a patch to libtermkey's upstream to avoid the crash and then forgot
to follow up on it.

I've sent a prod and will try to keep on top of it better this time. :)

> For the record, this bug could be triggered without the debhelper change
> if anyone ever built the package with:
> 
> dpkg-buildpackage -uc -uc  
> (Which apparently no one does - including our buildds, much to my surprise).

My experience is quite the opposite.  I've run into multiple issues in
Vim's tests due to 

Bug#911944: neovim FTBFS: tests fail

[James McCoy]

On Sat, Nov 10, 2018 at 04:09:55PM +0100, Helmut Grohne wrote:
> On Sat, Nov 10, 2018 at 09:29:42AM -0500, James McCoy wrote:
> > On Fri, Oct 26, 2018 at 03:30:54PM +0200, Helmut Grohne wrote:
> > > Looking to reproducible builds, the failure pattern looks quite random:
> > > 
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neovim.html
> 
> > The armhf & ppc64el buildd failures I can't reproduce on the
> > porterboxes, although the latter is likely another flaky test.
> 
> armhf likely needs to be retried as the build timed out.

It should't have timed out, though.  A single test shouldn't take >150
minutes. :) It got stuck, and I would need to investigate that live.

> > > However, in local builds for unstable/amd64 in sbuild, I didn't get a
> > > single successful build.
> > 
> > If it's not any of the mentioned failures, then some more information
> > would be useful, as I have quite the opposite behavior locally.
> 
> What information are you interested in?

First off would be the actual failure, but it seems you were hitting the
one I reported to upstream.

> I also tried in pbuilder and there I only got the utf_char2bytes
> failure, not the ones with check_cores. This hints that something about
> my build environment is fishy. If I understand correctly, my user's
> resource limits "leak" through sbuild while they don't pass through
> pbuilder. Would limiting the number of processes or virtual memory be a
> plausible explanation for the failures?

Possibly.  I can more reliably hit the utf_char2bytes failure when I
have other builds running in parallel.  It seems to correlate with
resource contention.

> So it might be useful to reduce the scope of this bug to the
> utf_char2bytes failure and the armhf/ppc64el buildd failures.

Sounds reasonable.  Any help triaging/narrowing down ways to reproduce
the failures would be helpful.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#911944: neovim FTBFS: tests fail

[James McCoy]

On Fri, Oct 26, 2018 at 03:30:54PM +0200, Helmut Grohne wrote:
> neovim fails to build from source in unstable.
> 
> | [  ERROR   ] 6 errors, listed below:
> | [  ERROR   ] test/functional/helpers.lua @ 743: after_each
> | test/helpers.lua:289: crash detected (see above)
> | 
> | stack traceback:
> | test/helpers.lua:289: in function 'check_cores'
> | test/functional/helpers.lua:748: in function 
> 

I haven't seen these on the buidds or locally.  The only issue I've been
seeing, aside from some flaky tests, I've filed upstream[0]:

[ RUN  ] mbyte utf_char2bytes: FAIL
test/unit/helpers.lua:731: (string) '
not enough memory'

stack traceback:
test/unit/helpers.lua:747: in function 'itp_parent'
test/unit/helpers.lua:774: in function 

[0]: https://github.com/neovim/neovim/issues/9212

> Looking to reproducible builds, the failure pattern looks quite random:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neovim.html

I'm not actually sure what's happening in the most recent builds there.
I don't see any explicit error output, just the testing stopping earlier
than it should.

The armhf & ppc64el buildd failures I can't reproduce on the
porterboxes, although the latter is likely another flaky test.

> However, in local builds for unstable/amd64 in sbuild, I didn't get a
> single successful build.

If it's not any of the mentioned failures, then some more information
would be useful, as I have quite the opposite behavior locally.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#912061: Bug #912061 in msgpack-c marked as pending

[James McCoy]

Control: tag -1 pending

Hello,

Bug #912061 in msgpack-c reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/msgpack-c/commit/aea33069def5664463e8cf197a45feea0271ba5f


rules: Use -DBUILD_GMOCK=OFF to avoid building gmock

googletest/googletest/CMakeLists.txt now depends on values set in
googletest/CMakeLists.txt, so pointing cmake at the sub-directory no
longer works.  Instead, explicitly use the option to avoid building
gmock.

Closes: #912061
Signed-off-by: James McCoy 



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/912061

Bug#911714: Bug #911714 in serf marked as pending

[James McCoy]

Control: tag -1 pending

Hello,

Bug #911714 in serf reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/serf/commit/de771b25106e14d961931cc84a91d533f1b550a0


Backport create_certs.py from upstream to generate certs at test time

The certs used for testing expire 1 year after they're generated, which
causes a timebomb for stable releases.

Closes: #911714
Signed-off-by: James McCoy 



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/911714

Bug#911714: serf FTBFS: ssl tests fail

[James McCoy]

On Tue, Oct 23, 2018 at 10:15:28PM +0200, Helmut Grohne wrote:
> serf fails to build from source in unstable e.g. on i386:
> 
> https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/serf_1.3.9-6.rbuild.log.gz
> 
> | There were 14 failures:
> | 1) test_ssl_trust_rootca: test/test_util.c:456: expected <0> but was 
> <120199>
> | 2) test_ssl_certificate_chain_with_anchor: test/test_util.c:456: expected 
> <0> but was <120199>

Ah, the bad cert timebomb has expired again (see #862027).  I was hoping
a new upstream release would have happened in the interim.

There is hope, as there's a release candidate out for their next
version, which contains a script to generate the bad certs at build
time.

I'll see about backporting the script if the upstream release doesn't
happen Real Soon Now.  I'll probably have to look into it anyway, since
this is going to affect stable builds too.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#910233: Bug #910233 in subversion marked as pending

[James McCoy]

Control: tag -1 pending

Hello,

Bug #910233 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/commit/a0d1bdf1e3f809e9244f74c8146f286f3d7262dd


libsvn-{java,dev}: Use absolute target path for symlink_to_dir calls

Closes: #910233
Signed-off-by: James McCoy 



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/910233

Bug#910233: Bug #910233 in subversion marked as pending

[James McCoy]

Control: tag -1 pending

Hello,

Bug #910233 in subversion reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/jamessan/subversion/commit/5ed1d9dfd96277d55e8e96eec6fe0c74d840254c


libsvn-{java,dev}: Use absolute target path for symlink_to_dir calls

Closes: #910233
Signed-off-by: James McCoy 



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/910233

Bug#910233: libsvn-{dev,java}: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[James McCoy]

On Thu, Oct 04, 2018 at 06:56:45AM +0200, Andreas Beckmann wrote:
> On 2018-10-04 02:53, James McCoy wrote:
> > On Wed, Oct 03, 2018 at 07:49:35PM +0200, Andreas Beckmann wrote:
> >> an upgrade test with piuparts revealed that your package installs files
> >> over existing symlinks and possibly overwrites files owned by other
> 
> > This is exactly what I did:
> > 
> > https://salsa.debian.org/jamessan/subversion/commit/d5e5e1c5c61b072974de5e0803deed669530e48c
> > https://salsa.debian.org/jamessan/subversion/commit/af236dd6de6239dff820d480206b4c92b8287be2
> 
> That looks good, except ...
> 
> The problematic links I observed are not normalized but use an absolute
> target:
> /usr/share/doc/libsvn-java -> /usr/share/doc/libsvn1
> (I didn't check where these originate from.)

Ack, you're right.  Thanks!

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#910233: libsvn-{dev,java}: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[James McCoy]

On Wed, Oct 03, 2018 at 07:49:35PM +0200, Andreas Beckmann wrote:
> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
> 
> Note that dpkg intentionally does not replace directories with symlinks
> and vice versa, you need the maintainer scripts to do this.
> See in particular the end of point 4 in
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade
> 
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.

This is exactly what I did:

https://salsa.debian.org/jamessan/subversion/commit/d5e5e1c5c61b072974de5e0803deed669530e48c
https://salsa.debian.org/jamessan/subversion/commit/af236dd6de6239dff820d480206b4c92b8287be2

Confused,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[James McCoy]

On Thu, Jun 14, 2018 at 08:49:53PM +0300, Niko Tyni wrote:
> On Wed, May 16, 2018 at 08:33:58AM -0400, James McCoy wrote:
> > On Fri, May 11, 2018 at 04:27:39PM +0200, Emmanuel Bourg wrote:
> > > Control: tags -1 + patch
> > > 
> > > Le 06/05/2018 à 02:13, James McCoy a écrit :
> > > 
> > > > It looks like that will do the right thing.  Now I just need to figure
> > > > out the larger issue of adapting upstream's build system.
> > > 
> > > I've managed to patch the EZT Make template to use 'javac -h' instead of
> > > javah. A few classes with no native methods but static fields used in
> > > native code also required the addition of the @Native annotation.
> > 
> > Thanks!  I'll get the annotations upstreamed soon, since those seem like
> > obvious fixes.  I'm pretty close to having a more general fix for the
> > Java templates, but if subversion starts getting in the way of other
> > packages it's good to have your patch to fall back on.
> 
> Hi, any news on this? It's blocking parts of our Perl 5.28 rebuild
> testing, and will obviously block the transition as well when we get
> that far.

I ended up having to throw away what I had been doing and try a
different approach.  That got sidelined by other work, so I'll look into
uploading Emmanuel's temporary fix soon.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[James McCoy]

On Fri, May 11, 2018 at 04:27:39PM +0200, Emmanuel Bourg wrote:
> Control: tags -1 + patch
> 
> Le 06/05/2018 à 02:13, James McCoy a écrit :
> 
> > It looks like that will do the right thing.  Now I just need to figure
> > out the larger issue of adapting upstream's build system.
> 
> I've managed to patch the EZT Make template to use 'javac -h' instead of
> javah. A few classes with no native methods but static fields used in
> native code also required the addition of the @Native annotation.

Thanks!  I'll get the annotations upstreamed soon, since those seem like
obvious fixes.  I'm pretty close to having a more general fix for the
Java templates, but if subversion starts getting in the way of other
packages it's good to have your patch to fall back on.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[James McCoy]

On Thu, May 03, 2018 at 11:25:03PM +0200, Emmanuel Bourg wrote:
> On Wed, 2 May 2018 22:11:49 -0400 James McCoy <james...@debian.org> wrote:
> 
> > Ah, that's because the javah command was removed in Java 10, to be
> > replaced by running "javac -h".
> > 
> > It would have been useful to get a notice about this ahead of time, for
> > those not as involved with Java.  Especially since this has apparently
> > been planned since Java 8.
> 
> Sorry for the lack of communication around the switch, there was a
> deprecation warning about javah during the build since the switch to
> OpenJDK 9 in March, but it might have been difficult to notice for
> Subversion.
> 
> Looking at the build log it seems javah is invoked 5 times and the
> headers are all generated into the subversion/bindings/javahl/include
> directory. Did you try disabling the calls to javah and adding '-h
> subversion/bindings/javahl/include/' to the javac parameters?

Thanks for the tip.  I'm not sure why that didn't register when first
looking at the help.

It looks like that will do the right thing.  Now I just need to figure
out the larger issue of adapting upstream's build system.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#897555: subversion: FTBFS: /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory

[James McCoy]

On Wed, May 02, 2018 at 11:02:02PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > [snip]
> > /usr/lib/jvm/default-java/bin/javah -force -d 
> > subversion/bindings/javahl/include -classpath 
> > subversion/bindings/javahl/classes: 
> > org.apache.subversion.javahl.ClientException 
> > org.apache.subversion.javahl.ClientNotifyInformation 
> > org.apache.subversion.javahl.CommitInfo 
> > org.apache.subversion.javahl.CommitItem 
> > org.apache.subversion.javahl.CommitItemStateFlags 
> > org.apache.subversion.javahl.ConflictDescriptor 
> > org.apache.subversion.javahl.ConflictResult 
> > org.apache.subversion.javahl.DiffSummary 
> > org.apache.subversion.javahl.ISVNClient 
> > org.apache.subversion.javahl.ISVNConfig 
> > org.apache.subversion.javahl.ISVNEditor 
> > org.apache.subversion.javahl.ISVNRemote 
> > org.apache.subversion.javahl.ISVNReporter 
> > org.apache.subversion.javahl.ISVNRepos 
> > org.apache.subversion.javahl.JNIError 
> > org.apache.subversion.javahl.JNIObject 
> > org.apache.subversion.javahl.NativeException 
> > org.apache.subversion.javahl.NativeResources 
> > org.apache.subversion.javahl.OperationContext 
> > org.apache.subversion.javahl.ProgressEvent 
> > org.apache.subversion.javahl.ReposNotifyInformation 
> > org.apache.subversion.javahl.SVNClient 
> > org.apache.subversion.javahl.SVNRepos org.apache.subversion.javahl.SVNUtil 
> > org.apache.subversion.javahl.SubversionException
> > /bin/bash: /usr/lib/jvm/default-java/bin/javah: No such file or directory
> > make[1]: *** [/<>/build-outputs.mk:601: 
> > subversion/bindings/javahl/include/org_apache_subversion_javahl_ClientException.h]
> >  Error 127

Ah, that's because the javah command was removed in Java 10, to be
replaced by running "javac -h".

It would have been useful to get a notice about this ahead of time, for
those not as involved with Java.  Especially since this has apparently
been planned since Java 8.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#894565: vim: FTBFS: Test failures if build user cannot open /dev/stdout

[James McCoy]

On Mon, Apr 02, 2018 at 08:44:17PM -0700, Daniel Schepler wrote:
> On Mon, Apr 2, 2018 at 7:21 PM, James McCoy <james...@debian.org> wrote:
> > Why is /dev/stdout missing?  It's possible one of the attached patches
> > will work around that issue, but I'm more curious why that's happening
> > in the first place.
> 
> /dev/stdout is present in the chroot.  However, in my setup, stdout is
> a pipe to a "tee" process, and the pipe is owned by root so the build
> user can't access it through /dev/stdout.

This seems like an environmental issue to me.  /dev/stdout should be
writable.  Given that, the stdout-writable.diff patch is probably the
right approach to take.  If you're able to confirm that, I'll send the
patch upstream.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#894565: vim: FTBFS: Test failures if build user cannot open /dev/stdout

[James McCoy]

On Sun, Apr 01, 2018 at 07:49:05AM -0700, Daniel Schepler wrote:
> From 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/vim.html
> (and I'm also seeing pretty much the same failure under pbuilder):
> 
> ...
> 
> Executing Test_z()
> Executing Test_z_negative_lnum()
> Executing Test_z_overflow()
> Executed 345 tests
> 
> 
> From test_writefile.vim:
> Found errors in Test_writefile_sync_dev_stdout():
> Caught exception in Test_writefile_sync_dev_stdout(): Vim(call):E482:
> Can't create file /dev/stdout @ function

Why is /dev/stdout missing?  It's possible one of the attached patches
will work around that issue, but I'm more curious why that's happening
in the first place.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
diff --git i/src/testdir/test_writefile.vim w/src/testdir/test_writefile.vim
index b8e0001f7..86f534d1e 100644
--- i/src/testdir/test_writefile.vim
+++ w/src/testdir/test_writefile.vim
@@ -106,5 +106,5 @@ func Test_writefile_sync_dev_stdout()
 return
   endif
   " Just check that this doesn't cause an error.
-  call writefile(['one'], '/dev/stdout')
+  call writefile(['one'], '/dev/stdout', 'a')
 endfunc
diff --git i/src/testdir/test_writefile.vim w/src/testdir/test_writefile.vim
index b8e0001f7..df383625e 100644
--- i/src/testdir/test_writefile.vim
+++ w/src/testdir/test_writefile.vim
@@ -102,7 +102,7 @@ func Test_writefile_sync_arg()
 endfunc
 
 func Test_writefile_sync_dev_stdout()
-  if !has('unix')
+  if !has('unix') || !filewritable('/dev/stdout')
 return
   endif
   " Just check that this doesn't cause an error.

Bug#889873: vagrant: unable to download images (moved from atlas.hashicorp.com to app.vagrantup.com)

[James McCoy]

On Thu, Feb 08, 2018 at 09:02:03AM +0100, Lucas Nussbaum wrote:
> It seems that Hashicorp decided to migrate from e.g.
> https://atlas.hashicorp.com/alpine/alpine64
> to
> https://app.vagrantup.com/alpine/boxes/alpine64
> 
> This breaks images download, making this package essentially
> unfortunately:
> 
> $ vagrant init alpine/alpine64
> A `Vagrantfile` has been placed in this directory. You are now
> ready to `vagrant up` your first virtual environment! Please read
> the comments in the Vagrantfile as well as documentation on
> `vagrantup.com` for more information on using Vagrant.

A workaround is to change the default server URL in the Vagrantfile, as
suggested in the upstream bug report.

https://github.com/hashicorp/vagrant/issues/9442#issuecomment-363080565

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#870367: marked as pending

[James McCoy]

tag 870367 pending
thanks

Hello,

Bug #870367 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

https://anonscm.debian.org/cgit/pkg-vim/neovim.git/commit/?id=e65e6a9

---
commit e65e6a9d6f574e8ec3fb45724aaf38b6a19fe53c
Author: James McCoy <james...@debian.org>
Date:   Tue Aug 1 21:06:51 2017 -0400

Backport big-endian integer options fix

Signed-off-by: James McCoy <james...@debian.org>

diff --git a/debian/changelog b/debian/changelog
index a568ba6..faae08a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+neovim (0.2.0-3) UNRELEASED; urgency=medium
+
+  * Cherry-pick b98ea042 from upstream to fix reading values of integer
+options on big-endian systems.  (Closes: #870367)
+
+ -- James McCoy <james...@debian.org>  Tue, 01 Aug 2017 20:59:28 -0400
+
 neovim (0.2.0-2) unstable; urgency=medium
 
   * Upload to unstable.

Bug#870367: neovim FTBFS on big endian: Test_get_buf_options line 3: Expected 8 but got 0

[James McCoy]

Control: tag -1 fixed-upstream

On Aug 1, 2017 09:09, "Adrian Bunk"  wrote:

...
>From test_bufwintabinfo.vim:
Found errors in Test_get_buf_options():
function RunTheTest[9]..Test_get_buf_options line 3: Expected 8 but got 0


I'll backport the fix from upstream soon.

Cheers,
James

Bug#863992: neovim-qt: FTBFS on mipsel: tst_shell neovim crash

[James McCoy]

Control: severity -1 important

On Fri, Jun 02, 2017 at 05:42:16PM -0400, Aaron M. Ucko wrote:
> The experimental mipsel build of neovim-qt failed, as detailed in 
> https://buildd.debian.org/status/fetch.php?pkg=neovim-qt=mipsel=0.2.7-1=1496289160=0
> In particular, I observe
> 
>   7/12 Test  #7: tst_shell ***Failed   16.27 sec
>   [...]
>   PASS   : NeovimQt::Test::uiStart()
>   QWARN  : NeovimQt::Test::startVarsShellWidget() Neovim fatal error "The 
> Neovim process has crashed"
> 
> Could you please take a look?

I wasn't able to reproduce this manually on the porterbox, nor did the
latest upload to unstable reproduce the problem.  I do notice that the
experimental build which failed was using the aspucd resolver.  That
tends to be overly aggressive on choosing packages from experimental to
install, rather than preferring sid.

For now, I'm going to consider it an artifact of that and lower the bug
to important, but I'll continue to monitor the builds.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install

[James McCoy]

Control: severity -1 normal

On Wed, Mar 29, 2017 at 08:21:23AM -0400, PICCORO McKAY Lenz wrote:
> 2017-03-28 23:04 GMT-04:00 James McCoy <james...@debian.org>:
> 
> This discussion is specifically talking about when a 411 status is
> returned, not a 413.
> 
> the document only cited 411 error as example, could not cover all the cases 
> due
> there are more, if u understand how to work http 1.1 vs other http 1.X and 2

You're right that it documented the known problems.  However, given that
1.8.1 was published almost 4 years ago, I'd expect that common problems
would have come up.

Given that there's an easy workaround (set http-chunked-requests to
off) I'm lowering the severity of the bug.

I agree that the general setup you describe of having a proxy is common,
but I think the particular proxy or proxy configuration you happen to be
interacting with is rather broken.  Making it more robust to standard
HTTP headers is a much better fix than disabling auto-detection of the
correct http-chunked-requests setting for a broader class of users.

> well ist not working, i provide not only one, i provide two urls where u come
> and get to test.. once with svn 1.6.12 and once with svn 1.7.0 rc1 and theres
> no work
>  
> seend to you in private mail:

The IP URL is just plain broken.  All I get is a 500 response, no matter
how I try to run svn.  The name-based URL does respond when
http-chunked-requests is disabled, but breaks when auto-detection is
enabled.  I'll discuss this with upstream to see if there's something
better than can be done here.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install

[James McCoy]

On Tue, Mar 28, 2017 at 10:50:20PM -0400, PICCORO McKAY Lenz wrote:
> I cited why must be set for 1.8 and q.9 until 1.10 released:
> 
> Users who wish to avoid the additional request may set that option to yes or 
> no
>  in order to short-circuit the additional request and avoid making it.

This discussion is specifically talking about when a 411 status is
returned, not a 413.

You talked about building subversion locally fixing the behavior, but
that wouldn't have changed the default value for the
http-chunked-requests configuration.

> later we have:
> 
> The Serf-based HTTP access library would use chunked transfer encoding for 
> most
> requests. When themod_dav_svn Subversion server is fronted by a proxy or
> reverse proxy
> 
> its common that well made configuration are a light webserver for front 
> request
> and specialiced webserver for each specific task, in this case, apache2 for
> subversion..

Yes, and later in that same document we have:

  Subversion 1.8.1 fixes this issue by detecting automatically whether
  chunked requests are supported at the set up of a session. This is
  done by issuing one additional request at the start of the session.

Subversion 1.8.10 is newer than 1.8.1 and therefore has the above
mentioned fix.

> so obviously u dont have how to test, and package dont have any of these
> guaranties.. I NOTE MANY SIMILAR CASES UNRESOLVED in large amount of bugs in
> debian bug list for subversion package.. 
> 
> so then please leave aside the selft defensive excuses and please fix the
> package.. 

I'm not being defensive.  I'm trying to understand the actual problem,
since what you're describing is not related to the release notes you are
quoting.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#858955: subversion: Error unable to retrieve any working copy after upgrade/install

[James McCoy]

On Tue, Mar 28, 2017 at 07:34:46PM -0400, PICCORO McKAY Lenz wrote:
> Package: subversion
> Version: 1.8.10-6+deb8u4
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,the current package in debian are broken
> i upgrade clients to jeesie
> and now could'n chekout working copies from external networks, only
> internal local network
> 
> but when i conpiled my own package, but version 1.8.0 im able to
> chekout from any svn of any version
> 
>* What led up to the situation?
> I used debian wheeze (clients) and squeeze (servers)
> and then upgrade/install jeesie on clients, but servers leave intact
> due great performance
> (note that some tests on wheeze does not report good performance, no
> hardware update will)
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> svn co http:///svn/project1
>* What was the outcome of this action?
> Unable to connect to a repository at URL 'http:///svn/project1'
> Unexpected HTTP status 413 'Request Entity Too Large' on '/svn/project1'

You suggest that setting "http-chunked-requests = no" fixes this, when
the error in the release notes is a 411, not a 413.  Are you sure that
has an impact?  Without a server to test against, I can't investigate
the problem.

As far as changing the config, the default value is to auto-detect
whether chunked requests are supported.  If your specific proxy is
broken, then I would suggest following the directions in the release
notes and setting the config that's needed for you _just_ for that
server.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#855282: debsign: support .buildinfo files

[James McCoy]

On Mon, Mar 06, 2017 at 11:45:20PM -0500, James McCoy wrote:
> On Thu, Feb 16, 2017 at 05:23:00PM +, Ximin Luo wrote:
> > I've done an initial implementation here:
> > 
> > https://anonscm.debian.org/cgit/collab-maint/devscripts.git/log/?h=pu/debsign-buildinfo
> > 
> > Please review!
> 
> This was merged and uploaded in 2.17.2.  However, now I see that
> buildinfo files may be arch-qualified even with a _source.changes (e.g.,
> by using "sbuild -A --source-only-changes").  That's not currently
> handled properly since "debsign foo_ver_source.changes" expects
> "foo_ver_source.buildinfo" to exist.
> 
> Should debsign be deriving the path for the buildinfo from the contents
> of the changes file?

I've changed all of the "child file" handling to use this approach in
4a4238dbf1e789e998cf047ea0f006e982fba56b.  That seems cleaner than
debsign replicating logic to determine the names of related files.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#855282: debsign: support .buildinfo files

[James McCoy]

On Thu, Feb 16, 2017 at 05:23:00PM +, Ximin Luo wrote:
> I've done an initial implementation here:
> 
> https://anonscm.debian.org/cgit/collab-maint/devscripts.git/log/?h=pu/debsign-buildinfo
> 
> Please review!

This was merged and uploaded in 2.17.2.  However, now I see that
buildinfo files may be arch-qualified even with a _source.changes (e.g.,
by using "sbuild -A --source-only-changes").  That's not currently
handled properly since "debsign foo_ver_source.changes" expects
"foo_ver_source.buildinfo" to exist.

Should debsign be deriving the path for the buildinfo from the contents
of the changes file?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#848230: reassign 848230 to python-neovim, closing 848230

[James McCoy]

reassign 848230 python-neovim 0.1.9-1
close 848230 0.1.13-1
thanks

Bug#852918: marked as pending

[James McCoy]

tag 852918 pending
thanks

Hello,

Bug #852918 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=collab-maint/devscripts.git;a=commitdiff;h=00a3307

---
commit 00a3307137b96cc2d8789d70b988ae0a9d34ea04
Author: James McCoy <james...@debian.org>
Date:   Mon Jan 30 23:30:38 2017 -0500

test_package_lifecycle: Ignore debhelper's create-stamp logs

Signed-off-by: James McCoy <james...@debian.org>

diff --git a/debian/changelog b/debian/changelog
index 9cc40cf..0ae0b04 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,11 @@ devscripts (2.17.1) UNRELEASED; urgency=medium
   * debian/tests/control:
 + Depend on build-essential.
 
+  [ James McCoy ]
+  * test_package_lifecycle:
++ Ignore debhelper's new "create-stamp" output to fix the test failure.
+  (Closes: #852918)
+
  -- Mattia Rizzolo <mat...@debian.org>  Fri, 27 Jan 2017 14:56:35 +0100
 
 devscripts (2.17.0) unstable; urgency=medium

Bug#850845: marked as pending

[James McCoy]

tag 850845 pending
thanks

Hello,

Bug #850845 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=collab-maint/devscripts.git;a=commitdiff;h=67a38da

---
commit 67a38dae69c12bf4bfb769dfd0d3970b99f02041
Author: James McCoy <james...@debian.org>
Date:   Tue Jan 10 22:10:17 2017 -0500

dget: Verify/propagate errors when processing a dsc

Check exit status of “dpkg-source -x” fails and use exec to run
dpkg-buildpackage, so we can properly report failures.

Signed-off-by: James McCoy <james...@debian.org>

diff --git a/debian/changelog b/debian/changelog
index 92abad6..6fe077b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -15,6 +15,9 @@ devscripts (2.17.0) UNRELEASED; urgency=medium
 + Support debian/clean files.  (Closes: #850662)
   * Remove bash completion for dcut, since src:dput will be providing it.
 (Closes: #850684)
+  * dget:
++ Verify exit status of “dpkg-source -x” and propagate failure.  (Closes:
+  #850845)
 
  -- Sean Whitton <spwhit...@spwhitton.name>  Mon, 19 Dec 2016 09:51:35 +
 

Bug#846711: marked as pending

[James McCoy]

tag 846711 pending
thanks

Hello,

Bug #846711 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=collab-maint/devscripts.git;a=commitdiff;h=602d25c

---
commit 602d25c02c4bc4ace2bfd646bec1dbb55e07f616
Author: James McCoy <james...@debian.org>
Date:   Thu Dec 8 23:12:04 2016 -0500

debuild: Run lintian (and hook) directly

When the running of lintian was moved to dpkg-buildpackage, that removed
the ability to ignore the return code.  While it's generally better to
avoid lintian having a non-zero return code, this was an unplanned
regression and breaks valid use cases.

Similarly, the check for the existence of lintian was restored, so
debuild doesn't fail if lintian doesn't exist.

Signed-off-by: James McCoy <james...@debian.org>

diff --git a/debian/changelog b/debian/changelog
index f84e221..f2b2cb4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,10 @@ devscripts (2.16.12) UNRELEASED; urgency=medium
   * mergechanges:
 + Add handling for buildinfo files, based on a patch by Simon McVittie.
   (Closes #843470)
+  * debuild:
++ Move invocation of lintian back into debuild.  This restores the
+  behavior of ignoring the return code of lintian (Closes: #847168) and
+  only running lintian when it is present (Closes: 846711).
 
  -- James McCoy <james...@debian.org>  Mon, 05 Dec 2016 22:58:29 -0500
 

Bug#846711: git-build-recipe: FTBFS: Tests failures

[James McCoy]

On Tue, Dec 06, 2016 at 10:39:44AM +, Colin Watson wrote:
> […]
>   subprocess.CalledProcessError: Command '['/usr/bin/debuild', '--tgz-check', 
> '-i', '-I', '-S', '-uc', '-us']' returned non-zero exit status 29
>   }}}
>   
>   stdout: {{{
>   dpkg-buildpackage -rfakeroot -us -uc -i -I -S --check-command=lintian
>   dpkg-buildpackage: error: check-commmand 'lintian' not found
>   }}}
> […]
> 
> git-build-recipe doesn't do anything particular to ask debuild to run
> lintian here, and it doesn't expect or require a lintian check.  It used
> to be that debuild would check whether lintian was in fact installed,
> and not run it if it wasn't; indeed, its documentation still says "then
> runs lintian on the .changes file created (assuming that lintian is
> installed)", thereby claiming that that's still what it does.  But this
> was broken in devscripts 58eb4a4a5e006bf9a2589da0ef2f36aa0d81ed8c when
> changing debuild to use dpkg-buildpackage --check-command.

Indeed.  In order to fix this, I either need to move running lintian
back into debuild or dpkg needs to not error when the check command
isn't present.

A related issue I see is that the semantics of debuild's lintian hook
and dpkg-bp's check hook are different, due to this.  debuild would not
try to run lintian, but would still call the lintian hook. However, the
hook argument would be false to indicate that lintian wasn't actually
going to be run.  In other words,

diff --git i/scripts/dpkg-buildpackage.pl w/scripts/dpkg-buildpackage.pl
index 9ec0d849d..a93edfa79 100755
--- i/scripts/dpkg-buildpackage.pl
+++ w/scripts/dpkg-buildpackage.pl
@@ -366,7 +366,7 @@ if (@rootcommand and not find_command($rootcommand[0])) {
 }
 
 if ($check_command and not find_command($check_command)) {
-error(g_("check-commmand '%s' not found"), $check_command);
+$check_command = undef;
 }
 
 if ($signcommand) {

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB