Bug#1069693: ppp >=2.5.0 breaks network-manager-fortisslvpn

[James Cowgill]

Control: tags -1 patch upstream

Hi,

On Sat, 11 May 2024 00:58:03 +0200 Maurizio Avogadro 
wrote:
> Some more info gathered this afternoon.
> 
> It seems that network-manager-fortisslvpn also makes a mess with the routing 
> table after the connection has been established.
> 
> I could easily get a working VPN by adding
> 
> ipcp-accept-remote
> 
> to /etc/ppp/options and manually launching openfortivpn; such setting also 
> allowed NetworkManager to accept the IP address supplied by the counterpart 
> (it 
> was the default until ppp v2.4.9), but in this case the connection didn't 
> work 
> until I deleted a rule in the routing table which routed the IP address of 
> the 
> remote gateway through the ppp0 interface (!).
> 
> A duplicate default route through the main physical network interface was 
> created too and the spawned pppd process didn't exit after the connection has 
> been terminated and had to be killed manually: none of these issues happened 
> when openfortivpn was launched manually.

I also did a little investigation yesterday on this as well as #1070343.
There are many upstream issues in both the openfortivpn GitHub and
network-manager Gitlab instances related to this.

To sum up what I think is happening (gathered from various issues):
* During PPP IPCP negotiation the Fortinet server requests it's link IP
address to be the same as it's public IP address. This doesn't make any
sense to me - the link address inside the PPP session should be a
private 10.x address. Maybe there's some reason it does this that I
don't understand...
* pppd configures this address on the ppp device using the
SIOCSIFDSTADDR ioctl. The kernel internally adds a route to the routing
table because it knows it can use this link to get to that IP (lol).
* Pre ppp-2.4 this didn't matter because pppd forcefully used the
address supplied on the command line which is a 169.x address. In this
case the kernel adds a route to a dummy IP which didn't affect anything.
* ppp-2.5 started enforcing the remote IP on the command line matched
the IP sent over IPCP. This initially broke negotiation until
"ipcp-accept-remote" was added, but this option breaks things in another
way by allowing pppd to configure the server supplied IP as the peer
address in the kernel and create a bad route.
* openfortivpn has a hack to workaround this - after pppd is up it
manually removes the route from the routing table. The network-manager
plugin doesn't do this.

I ended up writing a patch which does something similar in the
network-manager plugin - it manually invokes the SIOCSIFDSTADDR ioctl on
the ppp device to switch the peer address to a new fake address. This
seems to work to remove the bad route. Doing this feels really hacky
though and I'm kind of hesitant to upload it unless approved by upstream!

Note if you're testing this patch, you also need the fix for #1070343 in
openfortivpn as well to make it work (or manually set ipcp-accept-remote).

Having done this I'm very tempted to just switch to OpenConnect which
seems to work ok. It has its own ppp implementation which doesn't seem
to set the peer address in the kernel at all (and may just ignore the
server's IPCP requests - I have not checked) and so avoids these issues.

JamesFrom 416b65c3f23d795707ed122f06c54eebd515bc3b Mon Sep 17 00:00:00 2001
From: James Cowgill 
Date: Sat, 11 May 2024 13:59:17 +0100
Subject: [PATCH] Modify PPP peer address to avoid wrong route

---
 src/nm-fortisslvpn-service.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/src/nm-fortisslvpn-service.c b/src/nm-fortisslvpn-service.c
index e4433d5..cdfada4 100644
--- a/src/nm-fortisslvpn-service.c
+++ b/src/nm-fortisslvpn-service.c
@@ -37,6 +37,11 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include 
 
 #include "nm-fortissl-properties.h"
@@ -313,14 +318,39 @@ handle_set_state (NMDBusFortisslvpnPpp *object,
 	return TRUE;
 }
 
+static void
+hack_ppp_peer(const char *tundev)
+{
+	struct ifreq req;
+	int fd, ret;
+
+	_LOGI ("FORTISSLVPN Modifying PPP peer address to avoid incorrect host route");
+
+	memset(, 0, sizeof(req));
+	strlcpy(req.ifr_name, tundev, sizeof(req.ifr_name));
+	req.ifr_dstaddr.sa_family = AF_INET;
+	inet_aton("169.254.0.1", &((struct sockaddr_in*)(_dstaddr))->sin_addr);
+
+	fd = socket(AF_INET, SOCK_STREAM, 0);
+	ret = ioctl(fd, SIOCSIFDSTADDR, );
+	if (ret)
+		_LOGW ("FORTISSLVPN Failed to set PPP peer address, errno = %d", errno);
+	close(fd);
+}
+
 static gboolean
 handle_set_ip4_config (NMDBusFortisslvpnPpp *object,
GDBusMethodInvocation *invocation,
GVariant *arg_config,
gpointer user_data)
 {
+	const char *tundev;
+
 	_LOGI ("FORTISSLVPN service (IP Config Get) reply received.");
 
+	if (g_variant_lookup(arg_config, NM_

Bug#1070343: openfortivpn: Should not be built with --enable-legacy-pppd with ppp 2.5

[James Cowgill]

Control: retitle -1 openfortivpn: Should not be built with --enable-legacy-pppd 
with ppp 2.5

Hi,

I also encountered this bug as relating to pppd-accept-remote. It
happens because the Debian package is built with --enable-legacy-pppd
which was needed with ppp 2.4 but now needs removing since ppp has been
updated to 2.5 in Debian.

Also adding Depends: ppp (>= 2.5) for good measure seems like a good
idea after.

After doing both of those and rebuilding openfortivpn my existing
config works again.

James

Bug#1067512: libglfw3-wayland is practically not installable

[James Cowgill]

Control: severity -1 wishlist

Hi Michel,

On 22/03/2024 19:34, Michel Le Bihan wrote:
> Package: libglfw3-wayland
> Version: 3.3.10-1
> 
> Hello,
> 
> I noticed that libglfw3-wayland conflicts with libglfw3. That makes perfect 
> sense since both packages provide the same .so files. However, most packages 
> in Debian depend only on libglfw3. Take pink-pony as an example. It's not 
> possible to have both pink-pony and libglfw3-wayland installed on the same 
> system.

Yes this is the way the packaging is designed and it's intentional. You
can read the reasons I gave many moons ago here:
https://bugs.debian.org/827125

But it boils down to the fact that glfw exports some X11 symbols and if
your application uses some of these functions then it would crash if you
switched to the wayland library. At the time I didn't try working out
another solution and just made both packages conflict with each other.

> I think that either libglfw3 should be a virtual package that depends on 
> libglfw3-wayland or libglfw3-x11 or that libglfw3
> should have both backends enabled.

Now that glfw 3.4 has runtime backend selection, yes we should be able
to fix this fairly easily by turning both backends on at the same time
when we update to 3.4. This isn't an option in 3.3 though.

James

Bug#1065610: libguestfs0t64: All appliance dependencies lost during time_t transition

[James Cowgill]

Package: libguestfs0t64
Version: 1.52.0-2.1
Severity: serious

Hi,

During the time_t transition all the appliance dependencies of
libguestfs0 were lost:

$ debdiff libguestfs0_1%3a1.52.0-2+b1_amd64.deb 
libguestfs0t64_1%3a1.52.0-2.1_amd64.deb
...
Control files: lines which differ (wdiff format)

{+Breaks: libguestfs0 (<< 1:1.52.0-2.1)+}
Depends: libacl1 (>= 2.2.23), libaugeas0 (>= 1.8.0), libc6 (>= 2.35), libcap2 
(>= 1:2.10), libfuse2 (>= 2.8), libhivex0 (>= 1.3.14), libjansson4 (>= 2.14), 
libpcre2-8-0 (>= 10.22), librpm9 (>= 4.14.0+dfsg1), libselinux1 (>= 3.1~), 
libsystemd0, libtirpc3 (>= 1.0.2), libtsk19 (>= 4.12.1+dfsg), libvirt0 (>= 
1.2.7~rc2), libxml2 (>= 2.8.0), libyara10 (>= 4.0.0~), supermin (>= 5), 
qemu-system-x86, qemu-utils, db-util, icoutils, netpbm,
[-osinfo-db, acl, attr, binutils, bsdextrautils, btrfs-progs, bzip2, cpio, 
cryptsetup-bin, dash, diffutils, dosfstools, e2fsprogs, exfatprogs, extlinux, 
f2fs-tools, fdisk | util-linux (<< 2.29.2), file, gawk, gdisk, grub2-common, 
iproute2 | iproute, dhcpcd-base | isc-dhcp-client, kmod | module-init-tools, 
ldmtool, less, lsscsi, lvm2, lzop, mdadm, mount, mtools, ntfs-3g, 
openssh-client, parted, pciutils, procps, psmisc, scrub, sleuthkit, 
squashfs-tools, syslinux, systemd-sysv | sysvinit-core, udev, uuid-runtime, 
xz-utils, zerofree, zstd-]
{+osinfo-db+}
Installed-Size: [-5038-] {+5039+}
Package: [-libguestfs0-] {+libguestfs0t64+}

The build log contains this:

debian/gen-appliance-depends.sh
...
cat: 'debian/libguestfs0/usr/lib/*-*/guestfs/supermin.d/packages': No such file 
or directory

So I think updating debian/gen-appliance-depends.sh with the new library
name should fix this.



I did try this change but it the package test doesn't pass right now. I
think that supermin fails to understand virtual dependencies when
resolving packages and so fails to install various things. Maybe
once the time_t transition has completed and the affected packages are
binNMUed this should resolve itself?

James

Bug#1057175: transition: libsfml

[James Cowgill]

Package: release.debian.org
Control: affects -1 + src:libsfml
X-Debbugs-Cc: libs...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hi,

libsfml needs a transition due to an ABI bump from 2.5 to 2.6. It's
currently in experimental and built everywhere except mips64el where
it's waiting to be built.

The rdeps are:

casparcg-server (in contrib)
dolphin-emu
extremetuxracer
libcsfml
marsshooter
python-sfml
seriousproton

I did a test rebuild against 2.6 and everything builds on amd64 except
for seriousproton which already FTBFS for other reasons and is not in
testing.

The auto-libsfml tracker looks correct to me.

Thanks,
James

Ben file:

title = "libsfml";
is_affected = .depends ~ "libsfml-audio2.5" | .depends ~ "libsfml-graphics2.5" 
| .depends ~ "libsfml-network2.5" | .depends ~ "libsfml-system2.5" | .depends ~ 
"libsfml-window2.5" | .depends ~ "libsfml-audio2.6" | .depends ~ 
"libsfml-graphics2.6" | .depends ~ "libsfml-network2.6" | .depends ~ 
"libsfml-system2.6" | .depends ~ "libsfml-window2.6";
is_good = .depends ~ "libsfml-audio2.6" | .depends ~ "libsfml-graphics2.6" | 
.depends ~ "libsfml-network2.6" | .depends ~ "libsfml-system2.6" | .depends ~ 
"libsfml-window2.6";
is_bad = .depends ~ "libsfml-audio2.5" | .depends ~ "libsfml-graphics2.5" | 
.depends ~ "libsfml-network2.5" | .depends ~ "libsfml-system2.5" | .depends ~ 
"libsfml-window2.5";

Bug#1057114: seriousproton: Does not link against or depend on all needed libraries

[James Cowgill]

Package: libseriousproton0
Version: 2020.01.15+dfsg-1
Severity: serious
Justification: Policy 3.5

Hi,

The build log for seriousproton contains this near the end:

>dh_shlibdeps
> dpkg-shlibdeps: warning: symbol lua_rawget used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol luaL_checkinteger used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol lua_pushlightuserdata used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol luaopen_math used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol lua_settable used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol luaL_newstate used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol lua_sethook used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol _ZTV14b2PolygonShape used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol lua_getfield used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: symbol 
> _ZN12b2ChainShape11CreateChainEPK6b2Vec2iRS1_S3_ used by 
> debian/libseriousproton0/usr/lib/libseriousproton.so.0 found in none of the 
> libraries
> dpkg-shlibdeps: warning: 61 other similar warnings have been skipped (use -v 
> to see them all)

Which made me suspicious that it didn't link against all needed
libraries. Sure enough - just trying to load it fails:

> $ LD_PRELOAD=/usr/lib/libseriousproton.so.0 ls
> ls: symbol lookup error: /usr/lib/libseriousproton.so.0: undefined symbol: 
> luaopen_base

So it needs lua to run and probably libbox2d based on the build log.

Additionally the package doesn't depend on any of these libraries at
all. The Depends line only contains these packages (this is after
rebuilding with the patch in #997264):

libc6 (>= 2.14)
libgcc-s1 (>= 3.0)
libsfml-audio2.5
libsfml-graphics2.5
libsfml-network2.5
libsfml-system2.5
libsfml-window2.5
libstdc++6 (>= 13.1)

Fixing the CMakeLists.txt file should be enough to fix this because
dpkg-shlibdeps should be able to work it out from there.

James

Bug#1009249: groff: preconv misdetects UTF-8 text

[James Cowgill]

Control: retitle -1 uchardet: misdetects UTF-8 text with a few multi-byte chars
Control: tags -1 fixed-upstream

Hi,

I can confirm this bug still exists in 0.0.8 and running
"uchardet < broken" also gives the wrong encoding.

I think upstream has fixed it in this commit:
https://gitlab.freedesktop.org/uchardet/uchardet/-/commit/bed459c6e75e8a5be59ccd9bc80ac76c0bb8dbeb

I'm a little hesitant to just apply it though because there's been a lot
of change upstream related to UTF-8 detection and it might not interact
well without the other commits.

James

Bug#1055440: libsfml-dev: Requesting libsfml-dev be upgraded to the latest release v2.6.1

[James Cowgill]

Control: tags -1 pending

Hi Chris,

On 06/11/2023 06:36, Chris Thrasher wrote:
> My name is Chris Thrasher and I help maintain SFML. I'm requesting
> libsfml-dev be upgraded to the latest release of SFML, version 2.6.1.
> It was just released a few days ago and includes 5+ years worth of
> improvements to SFML since 2.5.1 was released in 2018.
I've uploaded 2.6.1 to experimental and should appear once it's approved
by the ftp-masters.

As the libraries were renamed, there needs to be a "library transition"
before it can enter unstable and the main release. How long that takes
depends on whether the other packages in Debian that depend on SFML need
changing or not. The is the current list. I haven't tried them with
2.6.1 yet.

dolphin-emu
extremetuxracer
libcsfml
marsshooter
python-sfml
seriousproton

Thanks,
James

Bug#1004647: O: mbedtls -- lightweight crypto and SSL/TLS library - crypto library

[James Cowgill]

Package: wnpp
Severity: normal
X-Debbugs-Cc: and...@pappacoda.it
Control: affects -1 src:mbedtls

I intend to orphan the mbedtls package.

The package description is:
 mbed TLS (formerly known as PolarSSL) is a lean open source crypto 
library for
 providing SSL and TLS support in your programs. It offers an intuitive 
API and
 documented header files, so you can actually understand what the code 
does.

 It features:
  - Symmetric algorithms, like AES, Blowfish, Triple-DES, DES, ARC4, 
Camellia

and XTEA
  - Hash algorithms, like SHA-1, SHA-2, RIPEMD-160 and MD5
  - Entropy pool and random generators, like CTR-DRBG and HMAC-DRBG
  - Public key algorithms, like RSA, Elliptic Curves, Diffie-Hellman, ECDSA
and ECDH
  - TLS 1.0, 1.1 and 1.2
  - Abstraction layers for ciphers, hashes, public key operations, platform
abstraction and threading
 .
 This package contains the shared library handling cryptography.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995005: xsimd: Built with -march=native

[James Cowgill]

Source: xsimd
Version: 7.5.0-1
Severity: serious

Hi,

>From the i386 build log:

...
[  3%] Building CXX object test/CMakeFiles/test_xsimd.dir/main.cpp.o
cd /<>/obj-i686-linux-gnu/test && /usr/bin/c++
-I/<>/include -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -march=native -g -fPIC -Wunused-parameter -Wextra
-Wreorder -std=c++11 -o CMakeFiles/test_xsimd.dir/main.cpp.o -c
/<>/test/main.cpp
...

You must not build Debian packages with the -march=native build flag
because then the package will only work on the same CPU architecture as
the build machine.

I would guess that amd64 is also affected (although there is no build
log so I can't check).

Thanks,
James

Bug#949140: ffmpeg: FTBFS: ERROR: tesseract not found using pkg-config

[James Cowgill]

Control: reassign -1 libtesseract-dev 4.1.1-1
Control: retitle -1 libtesseract-dev: missing dependency on libarchive-dev
Control: affects -1 src:ffmpeg

Hi,

On 17/01/2020 11:51, Mattia Rizzolo wrote:
> Source: ffmpeg
> Version: 4.2.1-2
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer,
> 
> your package failed to rebuild in a standard sid/amd64 chroot.
> Attached is the full build log, hopefully relevant excerpt follows:
> 
> ERROR: tesseract not found using pkg-config
> make[1]: *** [debian/rules:225: override_dh_auto_configure] Error 1
> make[1]: Leaving directory '/build/ffmpeg-4.2.1'
> make: *** [debian/rules:220: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2

And the few lines before that error are:
> gcc [omitted] -ltesseract -larchive
> /usr/bin/ld: cannot find -larchive
> collect2: error: ld returned 1 exit status
> ERROR: tesseract not found using pkg-config
> make[1]: *** [debian/rules:225: override_dh_auto_configure] Error 1

If I install libtesseract-dev and nothing else, building something
against the libraries in the pkg-config file give the same error:
> $ echo 'int main(void) {}' | gcc -x c - $(pkg-config --cflags --libs 
> tesseract) 
> /usr/bin/ld: cannot find -larchive
> collect2: error: ld returned 1 exit status

So I think this is a bug in tesseract.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#946241: ffmpeg: please make autopkgtests cross-test-friendly

[James Cowgill]

Hi,

On 06/12/2019 03:33, Steve Langasek wrote:
> Package: ffmpeg
> Version: 7:4.2.1-2
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
> 
> Dear maintainers,
> 
> In Ubuntu, we are in the process of moving the i386 architecture to a
> compatibility-only layer on amd64, and therefore we are also moving our
> autopkgtest infrastructure to test i386 binaries in a cross-environment.
> 
> This requires changes to some tests so that they are cross-aware and can do
> the right thing.

[...]
> 
> --- ffmpeg-4.2.1/debian/tests/control 2019-11-01 18:17:31.0 -0700
> +++ ffmpeg-4.2.1/debian/tests/control 2019-12-05 17:17:44.0 -0800
> @@ -5,4 +5,4 @@
>  Depends: ffmpeg
>  
>  Tests: encdec-extra
> -Depends: ffmpeg, libavcodec-extra
> +Depends: ffmpeg, libavcodec-extra58

Am I right in thinking this is necessary because libavcodec-extra is an
"arch all multi-arch foreign" package?

I'm wondering if marking libavcodec-extra (and libavfilter-extra) like
that is wrong because the behavior of these packages depends on what the
native architecture is, but I'm not sure. It currently installs the
native arch's libavcodec-extra library which doesn't seem right for a
multi-arch foreign package. I don't know if anyone from the multimedia
team knows why it's done this way (maybe just historical)?

Making the package "arch any multi-arch same" seems sensible to me, or
just removing the packages altogether (we already have a Provides:
libavcodec-extra on the real library packages so the existing
dependencies should work still).

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#916333: dav1d_0.5.2-1_amd64.changes REJECTED

[James Cowgill]

Hi,

On 27/12/2019 08:29, Dylan Aïssi wrote:
> Hi Thorsten,
> 
> Thanks for your work as ftpmaster!
> 
> Le ven. 27 déc. 2019 à 00:00, Thorsten Alteholz
>  a écrit :
>>
>> the list of grants does not contain the right to modify and distribute the
>> modifications of files under the Alliance-for-Open-Media-Patent-License-1.0.
>> I am afraid that this is not compatible woth the DFSG.
> 
> I have re-read the license and did not find the relevant part, could
> you tag the problematic part of the
> Alliance-for-Open-Media-Patent-License-1.0 ?
> 
> In case of the Alliance-for-Open-Media-Patent-License-1.0 is not
> compatible with the DFSG, what should we do for packages in the Debian
> archive with the same license (aom) ? Similar question for packages
> with embedded dav1d (firefox) ?

The AOM patent license is not a copyright license but rather an
"optional extra" which grants users patent rights under some extra
conditions. You would usually use it along with an additional license to
cover all the copyright related parts which the DFSG is more concerned
about.

In aom, I put the patent license in a "Comment" section at the top and
don't mention it in any "License" clauses which I think makes this
distinction between copyright and patent issues a bit clearer.

James



signature.asc
Description: OpenPGP digital signature

Bug#943900: twolame breaks ffmpeg autopkgtest: twolame_init_params(): 384kbps is an invalid bitrate for mono encoding.

[James Cowgill]

Control: reassign -1 src:ffmpeg 7:4.1.4-1
Control: tags -1 upstream
Control: forwarded -1 
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252392.html

Hi,

On 31/10/2019 21:18, Sebastian Ramacher wrote:
> On 2019-10-31 16:37:11, Paul Gevers wrote:
>> Source: twolame, ffmpeg
>> Control: found -1 twolame/0.4.0-2
>> Control: found -1 ffmpeg/7:4.2.1-1
>> Severity: serious
>> Tags: sid bullseye
>> X-Debbugs-CC: debian...@lists.debian.org
>> User: debian...@lists.debian.org
>> Usertags: breaks needs-update
>>
>> Dear maintainers,
>>
>> With a recent upload of twolame the autopkgtest of ffmpeg fails in
>> testing when that autopkgtest is run with the binary packages of twolame
>> from unstable. It passes when run with only packages from testing. In
>> tabular form:
>>passfail
>> twolamefrom testing0.4.0-2
>> ffmpeg from testing7:4.2.1-1
>> all others from testingfrom testing
>>
>> I copied some of the output at the bottom of this report.
>>
>> Currently this regression is blocking the migration of twolame to
>> testing [1]. Due to the nature of this issue, I filed this bug report
>> against both packages. Can you please investigate the situation and
>> reassign the bug to the right package?
> 
> This is an issue in ffmpeg. The change in twolame is deliberate:
> https://github.com/njh/twolame/pull/32. The defaults in ffmpeg produce
> invalid files.

I submitted the above patch. I'll give it a few days to see what
upstream says about it before I upload it.

James



signature.asc
Description: OpenPGP digital signature

Bug#933964: milkytracker: CVE-2019-14464 CVE-2019-14496 CVE-2019-14497

[James Cowgill]

Hi,

On 28/10/2019 12:29, Utkarsh Gupta wrote:
> Hi James,
> 
> On Tue, Oct 22, 2019 at 10:36 PM James Cowgill  <mailto:jcowg...@debian.org>> wrote:
> 
> Hi!
> 
> On 22/10/2019 15:03, Utkarsh Gupta wrote:
> > Hey,
> >
> > I have prepared an NMU for Sid.
> > I'd be happy to upload if you are busy to do so.
> > Given that it is fixed for oldoldstable already, I plan on
> uploading it
> > in a couple of days :)
> >
> > Please let me know if I shouldn't or something.
> 
> Do you have a patch for this NMU (or even better - a git branch against
> the repo in Salsa)?
> 
> 
> Here's the link to the Salsa repo:
> https://salsa.debian.org/utkarsh2102-guest/milkytracker
> Let me know if there's anything else you want me to do?
> 
> I could perhaps upload and create a MR for the same as well :)

Thanks. I've uploaded it (with some minor metadata changes and some more
changelog entries for all the other stuff in git pending upload).

James



signature.asc
Description: OpenPGP digital signature

Bug#933964: milkytracker: CVE-2019-14464 CVE-2019-14496 CVE-2019-14497

[James Cowgill]

Hi!

On 22/10/2019 15:03, Utkarsh Gupta wrote:

Hey,

I have prepared an NMU for Sid.
I'd be happy to upload if you are busy to do so.
Given that it is fixed for oldoldstable already, I plan on uploading it 
in a couple of days :)


Please let me know if I shouldn't or something.


Do you have a patch for this NMU (or even better - a git branch against 
the repo in Salsa)?


James

Bug#941559: libxvidcore4: immediately crashes on amd64 since binNMU

[James Cowgill]

Hi,

On 02/10/2019 11:47, Fabian Greffrath wrote:
> Hi James,
> 
> Am 02.10.2019 01:45, schrieb James Cowgill:
>> Indeed readelf contains some non-executable program headers in
>> 2:1.3.5-1+b1 which do not appear in 2:1.3.5-1 in buster. The
>> ".rotext" section sounds suspicious.
> 
> indeed, the check_cpu_feature() function is defined in
> src/utils/x86_asm/cpuid.asm [1] which includes src/nasm.inc, which in
> turn declares a .rotext section [2] for any other output format than
> macho32 and macho64.
> 
> It would probably be the best patch this to simply declare a .text
> section for all output formats. The question remains, however, why this
> is an issue now but not when xvidcore_2:1.3.5-1 was uploaded?

I had a play around and I think this is caused by the "-z separate-code"
option being enabled by default in binutils >= 2.31. With that option
binutils will put "text" and "rodata" into different segments.
Previously it bundled both of those (along with any other read only
data) into a single executable segment.

Second bullet point in the announcement:
https://sourceware.org/ml/binutils/2018-07/msg00213.html

In theory that also means the bug affects buster if the package is ever
rebuilt / updated there.

James



signature.asc
Description: OpenPGP digital signature

Bug#941559: libxvidcore4: immediately crashes on amd64 since binNMU

[James Cowgill]

Package: libxvidcore4
Version: 2:1.3.5-1
Severity: grave
Tags: sid bullseye

Hi,

Just over a month ago xvidcore was binNMUed and this seems to have
triggered a bug somewhere and now any application which tries to
initialize libxvidcore will segfault.

Test app:
#include 
#include 

int main(void)
{
xvid_gbl_init_t init = {
.version = XVID_VERSION,
.cpu_flags = 0,
.debug = 0,
};
xvid_global(NULL, XVID_GBL_INIT, , NULL);
return 0;
}

$ gcc -o xvid-test xvid-test.c -lxvidcore
$ ./xvid-test 
Segmentation fault (core dumped)

The crash happens here:
Program received signal SIGSEGV, Segmentation fault.
0x77f22940 in check_cpu_features () from 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4
(gdb) bt
#0  0x77f22940 in check_cpu_features () from 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4
#1  0x77e9c15b in detect_cpu_flags () at ../../src/xvid.c:156
#2  0x77e9d265 in xvid_gbl_init (init=0x7fffdee4, 
init=0x7fffdee4) at ../../src/xvid.c:793
#3  xvid_global (handle=, opt=, 
param1=0x7fffdee4, param2=) at ../../src/xvid.c:816
#4  0x516d in main ()

Which in turn seems to happen because the check_cpu_features function is
in a non-executable read only memory region.

$ /proc/4658/maps
[...]
77e87000-77e8b000 rw-p  00:00 0 
77e8b000-77e8d000 r--p  fd:00 954232 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4.3
77e8d000-77ef5000 r-xp 2000 fd:00 954232 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4.3
[vvv]
77ef5000-77f2b000 r--p 0006a000 fd:00 954232 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4.3
[^^^]
77f2b000-77f2c000 r--p 0009f000 fd:00 954232 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4.3
77f2c000-77f36000 rw-p 000a fd:00 954232 
/usr/lib/x86_64-linux-gnu/libxvidcore.so.4.3
77f36000-77fa1000 rw-p  00:00 0 
[...]

Indeed readelf contains some non-executable program headers in
2:1.3.5-1+b1 which do not appear in 2:1.3.5-1 in buster. The
".rotext" section sounds suspicious.

2:1.3.5-1+b1:
$ readelf -l /usr/lib/x86_64-linux-gnu/libxvidcore.so.4
[...]
Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  LOAD   0x 0x 0x
 0x18a8 0x18a8  R  0x1000
  LOAD   0x2000 0x2000 0x2000
 0x000673c9 0x000673c9  R E0x1000
  LOAD   0x0006a000 0x0006a000 0x0006a000
 0x00035088 0x00035088  R  0x1000
  LOAD   0x0009fb90 0x000a0b90 0x000a0b90
 0x98d0 0x00073138  RW 0x1000
[...]
   00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version 
.gnu.version_r .rela.dyn .rela.plt 
   01 .init .plt .plt.got .text .fini 
   02 .rodata .rotext .eh_frame_hdr .eh_frame 
   03 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 

2:1.3.5-1:
$ readelf -l /usr/lib/x86_64-linux-gnu/libxvidcore.so.4
[...]
Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  LOAD   0x 0x 0x
 0x0009da50 0x0009da50  R E0x20
  LOAD   0x0009db90 0x0029db90 0x0029db90
 0x98d0 0x00073138  RW 0x20
[...]
   00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version 
.gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata 
.rotext .eh_frame_hdr .eh_frame 
   01 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 

James



signature.asc
Description: OpenPGP digital signature

Bug#941377: libpocketsphinx-dev: missing dependency on libsphinxbase-dev for pkgconfig file

[James Cowgill]

Package: libpocketsphinx-dev
Version: 0.8+5prealpha+1-6
Severity: important

Hi,

The pkgconfig file in libpocketsphinx-dev is broken because the package
is missing a dependency on libsphinxbase-dev:

$ pkg-config --libs pocketsphinx
Package sphinxbase was not found in the pkg-config search path.
Perhaps you should add the directory containing `sphinxbase.pc'
to the PKG_CONFIG_PATH environment variable
Package 'sphinxbase', required by 'pocketsphinx', not found

James



signature.asc
Description: OpenPGP digital signature

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[James Cowgill]

Hi,

On 27/07/2019 15:52, Jonas Smedegaard wrote:
> Quoting James Cowgill (2019-07-27 11:12:00)
>> Hi,
>>
>>> ffmpeg currently links with libcrystalhd3.
>>>
>>> It seems, however, that libcrystalhd3 is only really useful together 
>>> with firmware-crystalhd, which was never really usable in Debian, 
>>> leading to that package being dropped: 
>>> https://bugs.debian.org/865978
>>>
>>> If someone wants to revive CrystalHD in Debian, it seems a good 
>>> place to start is 
>>> https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
>>>
>>> I suggest to simply stop link with libcrystalhd3 until 
>>> firmware-crystalhd reappear in Debian.
>>
>> I've disables crystalhd.
>>
>> Should we completely from libcrystalhd3 as well in that case?
> 
> Sorry, I fail to parse your last sentence above...

No idea what happened there. What I meant to say:

Should we completely remove libcrystalhd3 from the archive as well in
that case (given what you wrote above)?

James



signature.asc
Description: OpenPGP digital signature

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[James Cowgill]

Hi,

> ffmpeg currently links with libcrystalhd3.
> 
> It seems, however, that libcrystalhd3 is only really useful together
> with firmware-crystalhd, which was never really usable in Debian,
> leading to that package being dropped: https://bugs.debian.org/865978
> 
> If someone wants to revive CrystalHD in Debian, it seems a good place to
> start is https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
> 
> I suggest to simply stop link with libcrystalhd3 until firmware-crystalhd
> reappear in Debian.

I've disables crystalhd.

Should we completely from libcrystalhd3 as well in that case?

James



signature.asc
Description: OpenPGP digital signature

Bug#933180: srt: consider adding non-openssl build

[James Cowgill]

Source: srt
Version: 1.3.2-1
Severity: wishlist

Hi,

While looking over the various as of yet unused build options in FFmpeg,
I noticed that srt has been packaged and could now be enabled!

Unfortunately, since libsrt is linked against OpenSSL, I can't enable it
in FFmpeg because it would make FFmpeg incompatible with the GPL-2.
Please consider adding a version of srt linked to another tls library
which doesn't have these licensing problems.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#933178: libsrt-dev: missing dependency on libssl-dev

[James Cowgill]

Package: libsrt-dev
Version: 1.3.2-1
Severity: important

Hi,

The libsrt-dev package has a missing dependency on libssl-dev. It's not
possible to use the pkg-config file without installing this package as well:

$ pkg-config --cflags srt
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'srt', not found
Package 'libcrypto', required by 'srt', not found

James



signature.asc
Description: OpenPGP digital signature

Bug#925941: nvenc not in ffmpeg

[James Cowgill]

On 23/07/2019 00:59, James Cowgill wrote:
> On that basis, it's unfortunate that nvenc was allowed to be enabled in 
> buster in the first place.

Sorry, I meant to say "stretch" here not "buster".

James



signature.asc
Description: OpenPGP digital signature

Bug#925941: nvenc not in ffmpeg

[James Cowgill]

Hi,

On 19/05/2019 16:30, Sebastian Ramacher wrote:
> On 2019-05-09 23:32:04, Chris wrote:
>> On Thu, 28 Mar 2019 16:16:32 -0600 miltonshane...@gmail.com wrote:
>>> Package: FFMPEG
>>> Version: 4.1.1-1 and others
>>>
>>> When running command ffmpeg -codecs nvenc is not showing in h264  or
>>> nvenc_hevc.  This is supported in Debian 9 but not Buster/Testing.
>>>
>>> I suggest enabling this duing build as it is a widly used feature
>>> along with vaapi
>>>
>>> I am using Debian Linux Buster/Testing with nvidia driver stack in
>>> Testing.
>>
>> This is also the case in Sid. Would be extremely helpful to have this
>> built with nvenc support.
>> The version in Sid seems to have VAAPI support, though.
>>
> 
> Someone needs to package https://github.com/FFmpeg/nv-codec-headers.

I've been having a little look at this. Unfortunately, the more I look,
the more I've come to the conclusion that the way FFmpeg dynamically
loads nvenc violates the LGPL - but I'm not 100% settled, so feel free
to persuade me otherwise :) On that basis, it's unfortunate that nvenc
was allowed to be enabled in buster in the first place.

This is the patch which marked nvenc as "free" upstream:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193467.html

Upstream appears to be relying on the GPL's "system library" exception
to make it possible to dynamically load nvenc without the GPL requiring
the source of nvenc to be provided. I don't think Debian can rely on
this though because nvenc is not normally distributed by Debian (and you
have to enable non-free to get it).

James



signature.asc
Description: OpenPGP digital signature

Bug#923494: Please Recommend and dlopen libsdl2 rather than depending on it

[James Cowgill]

Hi,

On 12/03/2019 12:44, Reinhard Tartler wrote:
> On Tue, Mar 12, 2019 at 8:36 AM Carl Eugen Hoyos  > wrote:
> 
> Please show the dependencies of (at least) libavutil and libavcodec
> with your approach and maybe compare them to what sdl needs: While the
> list may become smaller I wonder if it this would really solve the
> described issue.
> 
> Sure thing, please find the full build log attached to this email.
> It details the full metadata at the end of the log.

I've been on a rather long haitus from Debian stuff for a while, t I now
have some time to do more so I'm going to get FFmpeg 4.1.4 uploaded next
(and by the looks of things 4.2 is just around the corner...)

I see a "fix" for this in the git history, but I think it's broken:

* There is an obvious typo in the d/rules file which prevents the option
to disable the SDL output device from taking effect. You can see from
the build log attached to this bug report that we still have an SDL
dependency.

* Even after fixing that, the dependency remains. I think the "opengl"
device backend has a dependency on SDL as well. Disabling that is
probably a greater loss?

* With the above two changes (disabling both sdl and opengl), I ran the
final packages through dose and compared the dependencies. This is the
list of transitive dependencies that no longer need installing after
this change:

 libsdl2-2.0-0
 libwayland-client0
 libwayland-cursor0
 libwayland-egl1
 libxcursor1
 libxinerama1
 libxkbcommon0
 libxrandr2
 libxss1
 xkb-data

Notice that all of OpenGL, all xcb and core x11 libraries are still
required.

The total uncompressed size of these packages is around 8M, with
libsdl2-2.0-0 and xkb-data being the only significant packages (the rest
are < 100k). Note that xkb-data is installed by default so that saving
is probably only relevant for stripped down containers. For comparison,
if I install ffmpeg in a build chroot, apt says it will use 418M of
extra space.

In conclusion, I don't think the savings this change gives us are worth
it, and I don't like disabling features in FFmpeg :)

I think what you really want is an "ffmpeg-nox" package containing a
build of the frontend ffmpeg tool with libavdevice completely disabled.
I haven't run this in dose, but by dropping this dependency I would
expect all the GL / X11 / etc dependencies to also go which would give
much better space savings. Probably needs a little more thinking about
the way this would be implemented though (and it's relationship with the
normal ffmpeg package).

James



signature.asc
Description: OpenPGP digital signature

Bug#932240: debhelper: no longer detects setgid binaries in dh_shlibdeps

[James Cowgill]

Package: debhelper
Version: 12.2
Severity: important
Control: affects -1 src:nethack

Hi,

I noticed when upgrading nethack, dh_shlibdeps no longer finds the main
nethack ELF binaries. debhelper 12.1.1 works correctly.

With 12.1.1:
$ dh_shlibdeps -v
dh_shlibdeps -v
dpkg-shlibdeps -Tdebian/nethack-common.substvars
debian/nethack-common/usr/lib/games/nethack/dlb
debian/nethack-common/usr/lib/games/nethack/lev_comp
debian/nethack-common/usr/lib/games/nethack/dgn_comp
debian/nethack-common/usr/lib/games/nethack/recover
dpkg-shlibdeps -Tdebian/nethack-console.substvars
debian/nethack-console/usr/lib/games/nethack/nethack-console
dpkg-shlibdeps -Tdebian/nethack-lisp.substvars
debian/nethack-lisp/usr/lib/games/nethack/nethack-lisp
dpkg-shlibdeps -Tdebian/nethack-x11.substvars
debian/nethack-x11/usr/lib/games/nethack/nethack-x11

With 12.2:
$ dh_shlibdeps -v
dpkg-shlibdeps -Tdebian/nethack-common.substvars
debian/nethack-common/usr/lib/games/nethack/dlb
debian/nethack-common/usr/lib/games/nethack/lev_comp
debian/nethack-common/usr/lib/games/nethack/dgn_comp
debian/nethack-common/usr/lib/games/nethack/recover


I think this is caused by the fix for #931996. Nethack installs these
files with the setgid bit by default, which changes the output of file
in a way that's no longer detected properly:

$ file --brief debian/nethack-x11/usr/lib/games/nethack/nethack-x11
setgid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=1485534d83c00eb43ac9e8ddf15cab6c5b062ad7, for GNU/Linux
3.2.0, stripped

It's pretty easy to fix this in nethack if I need to, but I don't think
something like this should break in debhelper without a compat bump.

James



signature.asc
Description: OpenPGP digital signature

Bug#900015: missing pkg-config support is blocking switch to mbedTLS in libgit2

[James Cowgill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 30/04/2019 21:22, Christoph Berg wrote:
> Re: James Cowgill 2018-05-24
> 
>> I've downgraded this bug because it is a feature request. It's
>> not as if mbedtls is the only library which doesn't support
>> pkg-config :)
>> 
>> As you have seen there has been an open upstream issue about this
>> for almost 3 years. I will see what I can do about it, but I
>> would not expect it to be fixed soon.
> 
> fldigi 4.1.02's configure check probes for mbedtls >= 2.16 using 
> pkg-config (and builds the embedded copy otherwise), so it seems
> this has been implemented upstream in mbedtls by now. Can we have
> it in Debian, please?

I cannot find any trace of pkg-config in upstream mbedtls git. The
issue and (newer) merge request are still open:

https://github.com/ARMmbed/mbedtls/issues/228
https://github.com/ARMmbed/mbedtls/pull/1753

James
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+Ixt5DaZ6POztUwQx/FnbeotAe8FAlzItGkACgkQx/Fnbeot
Ae+bJg//aLDExeX71V5VK9Nim8zLdFHQFx+1ILyEjULTGxChMZad/Bu6UiAS6FnX
76UHidW94WG03lnS26dst1KSHh5lzOlfELuGg5BKGOBstjNmFamWjUL9F6+WdgIz
fsUpf9gnZ6Yvik84BNggit9SeofJ3cyLI3BHN6ioBsTcLhzT20zYR+GffCrKnWcm
HoDp+Gv5OkXKRsa8ipAL4+Cu2nfEjKwv0/aYSLCM2cqG0DFyS4JjjnfhFdF8dXtA
zaFGda7Dffgir/heME/7mh6gZxp6cbLXgGQ3Op5ThrzrIR4R0DZl3zC5hdi8mxnk
0fR+Gwlms4TLGTqd1QQzTXBlXj+Q+j0YkDlAH4eY+QEvf73mBHh6HVYa4TljP99L
tHdosUD84vekrS9ESUjhqOpwU7PAFapLGSnj+HuWThGgWHHOyxWubCSh2mmFT7DS
DgKe7mVc6OGGA3ZgESlrFiMz+QDVPyYiHd7UKgSrJ9OAKAxs2RtaksEmbifv2qY0
+OvBha1tBnCydPCsJnqJ3wkHf2SZAkdQ+QW7PQqBpdkVQXhBscOx/enYSPpUl04p
k7dGAxJdepRPRm7/o1D8zJKZ57pcYyh2/DjUZzk/RWaG6hpKfFyUxXsThXgVFPRh
iTn0K7j7EtfQrQTQ7yF2JEPFWirIK9SVYaxm8EBWaW8C2E9yZAU=
=HbtU
-END PGP SIGNATURE-

Bug#921528: python3-gitlab: missing dependency on yaml

[James Cowgill]

Package: python3-gitlab
Version: 1:1.6.0-3
Severity: important

Hi,

If you request yaml output from the python-gitlab command, it will crash
with:

$ python-gitlab -o yaml project list
Traceback (most recent call last):
  File "/usr/bin/python-gitlab", line 11, in 
load_entry_point('python-gitlab==1.6.0', 'console_scripts', 'gitlab')()
  File "/usr/lib/python3/dist-packages/gitlab/cli.py", line 188, in main
cli_module.run(gl, what, action, args, verbose, output, fields)
  File "/usr/lib/python3/dist-packages/gitlab/v4/cli.py", line 386, in run
printer.display_list(data, fields, verbose=verbose)
  File "/usr/lib/python3/dist-packages/gitlab/v4/cli.py", line 309, in 
display_list
import yaml  # noqa
ModuleNotFoundError: No module named 'yaml'

Installing python3-yaml allows it to work.

James



signature.asc
Description: OpenPGP digital signature

Bug#917604: libavcodec57 v. 7:3.4.3-1 has depended from libx264-152

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 29/12/2018 04:47, Сергей Фёдоров wrote:
> Package: libavcodec57
> Version: 7:3.4.3-1
> Severity: important
> Tags: a11y
> 
> Dear Maintainer,
> 
> When it is installed a packet libavcodec57 v. 7:3.4.3-1
> (FFmpeg library with de/encoders for audio/video codecs - runtime files)
> it is issued a message «It has depended from libx264-152  but it is not
>  installable», but  there is «libx264-148» or «libx264-155» only.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')

libavcodec57 has been removed from unstable and should not be used
anymore. Please upgrade to libavcodec58 (currently version 7:4.1-1) and
remove the libavcodec57 package.

James

Bug#914200: tortoisehg: uninstallable with mercurial 4.8

[James Cowgill]

Control: tags -1 pending
Control: tags 915858 pending
Control: tags 909583 pending

Hi,

On 20/11/2018 15:01, Julien Cristau wrote:
> Package: tortoisehg
> Version: 4.7-0.1
> Severity: serious
> 
> Hi,
> 
> I just uploaded mercurial 4.8 to sid, tortoisehg will be uninstallable.

I have just uploaded the attached NMU to DELAYED/2 which upgrades
tortoisehg to 4.8.1 which will fix this (and the other two bugs above).
Please tell me if you want me to cancel it.

I've pushed my changes to salsa (and dgit repos), and I attach the full
debdiff and a shorter version containing just the changes to the debian/
directory.

Thanks,
James
diff -Nru tortoisehg-4.7/PKG-INFO tortoisehg-4.8.1/PKG-INFO
--- tortoisehg-4.7/PKG-INFO 2018-08-20 04:03:06.0 +0100
+++ tortoisehg-4.8.1/PKG-INFO   2018-12-10 15:10:00.0 +
@@ -1,6 +1,6 @@
 Metadata-Version: 1.0
 Name: tortoisehg
-Version: 4.7
+Version: 4.8.1
 Summary: TortoiseHg dialogs for Mercurial VCS
 Home-page: https://tortoisehg.bitbucket.io
 Author: Steve Borho
diff -Nru tortoisehg-4.7/debian/changelog tortoisehg-4.8.1/debian/changelog
--- tortoisehg-4.7/debian/changelog 2018-09-01 16:37:37.0 +0100
+++ tortoisehg-4.8.1/debian/changelog   2018-12-22 11:21:56.0 +
@@ -1,3 +1,21 @@
+tortoisehg (4.8.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ James Cowgill ]
+  * New upstream version. (Closes: #909583)
+  * d/control:
+- Update mercurial dependency to allow 4.7 and 4.8. (Closes: #914200)
+
+  [ Ondřej Nový ]
+  * d/control: Remove ancient X-Python-Version field.
+  * d/copyright: Use https protocol in Format field.
+
+  [ Stéphane Blondon ]
+  * d/thg.1.xml: Uudate link to upstream BTS in the manpage. (Closes: #915858)
+
+ -- James Cowgill   Sat, 22 Dec 2018 11:21:56 +
+
 tortoisehg (4.7-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tortoisehg-4.7/debian/control tortoisehg-4.8.1/debian/control
--- tortoisehg-4.7/debian/control   2018-09-01 16:36:09.0 +0100
+++ tortoisehg-4.8.1/debian/control 2018-12-22 11:21:56.0 +
@@ -14,11 +14,10 @@
 Homepage: https://tortoisehg.bitbucket.io
 Vcs-Git: https://salsa.debian.org/debian/tortoisehg.git
 Vcs-Browser: https://salsa.debian.org/debian/tortoisehg
-X-Python-Version: >= 2.4
 
 Package: tortoisehg
 Architecture: all
-Depends: mercurial (>= 4.7~), mercurial (<< 4.8~), python-pyqt5,
+Depends: mercurial (>= 4.7~), mercurial (<< 4.9~), python-pyqt5,
  python-pyqt5.qsci, ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
 Recommends: libjs-jquery, libjs-underscore, python-iniparse, python-pygments
 Suggests: tortoisehg-nautilus
diff -Nru tortoisehg-4.7/debian/copyright tortoisehg-4.8.1/debian/copyright
--- tortoisehg-4.7/debian/copyright 2018-08-30 09:14:34.0 +0100
+++ tortoisehg-4.8.1/debian/copyright   2018-12-22 11:21:56.0 +
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: TortoiseHg
 Upstream-Contact: Maintainer: Steve Borho , TK Soh 

 Source: https://tortoisehg.bitbucket.io/download/source.html
diff -Nru tortoisehg-4.7/debian/thg.1.xml tortoisehg-4.8.1/debian/thg.1.xml
--- tortoisehg-4.7/debian/thg.1.xml 2018-08-30 09:14:34.0 +0100
+++ tortoisehg-4.8.1/debian/thg.1.xml   2018-12-22 11:21:56.0 +
@@ -453,7 +453,7 @@
 
 BUGS
 The upstreams BTS can be found
-  at http://bitbucket.org/tortoisehg/stable/issues/"/>.
+  at https://bitbucket.org/tortoisehg/thg/issues"/>.
   
   
 SEE ALSO
diff -Nru tortoisehg-4.7/doc/source/conf.py tortoisehg-4.8.1/doc/source/conf.py
--- tortoisehg-4.7/doc/source/conf.py   2018-02-02 17:35:52.0 +
+++ tortoisehg-4.8.1/doc/source/conf.py 2018-12-10 15:09:54.0 +
@@ -49,9 +49,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = '3.8'
+version = '4.7'
 # The full version, including alpha/beta/rc tags.
-release = '3.8.0'
+release = '4.7.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff -Nru tortoisehg-4.7/doc/source/preface.txt 
tortoisehg-4.8.1/doc/source/preface.txt
--- tortoisehg-4.7/doc/source/preface.txt   2017-03-29 01:25:22.0 
+0100
+++ tortoisehg-4.8.1/doc/source/preface.txt 2018-12-10 15:09:54.0 
+
@@ -52,11 +52,9 @@
 Community
 =
 
-Mailing Lists:
+Mailing List::
 
-* `Users <https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss>`_ - 
Announcements, user Q, and feature discussions.
-* `Developers `_ - Patches, bug reports, development 
discussions.
-* `Issues <https://lists.sourceforge.net/lists/listinfo/tortoisehg-issues>`_ - 
Notifications from the issue tracker.
+   `Developers `_ - Patches, bug reports, 
development discussions.
 
 And our `wiki &

Bug#916545: git-buildpackage: gbp pq import fails to import patches with no headers

[James Cowgill]

Package: git-buildpackage
Version: 0.9.11
Severity: normal

Hi,

As a result of the fix applied to gbp to fix #912426, gbp pq import can
no longer import patches containing no headers. This in turn causes dgit
to fail to clone at least glibc (where I originally saw this bug).

For example, running gbp pq import on glibc 2.28-2 gives:
> gbp:info: Trying to apply patches at 
> '56686caf41f17b97b32401a4b12ce45a22d80f37'
> gbp:warning: Patch 'git-updates.diff' has no authorship information, using 
> 'GNU Libc Maintainers '
> gbp:warning: Patch 'check-unknown-symbols.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:warning: Patch 'locale-print-LANGUAGE.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:warning: Patch 'LC_IDENTIFICATION-optional-fields.diff' has no authorship 
> information, using 'GNU Libc Maintainers '
> gbp:error: Failed to apply 
> '/home/jcowgill/me-workspace/glibc/glibc/debian/patches/localedata/local-all-no-archive.diff':
>  Failed to read patch header of 
> '/home/jcowgill/me-workspace/glibc/glibc/debian/patches/localedata/local-all-no-archive.diff':
>  b"error: empty patch: '/dev/null'\n"
> gbp:error: Couldn't apply patches

The first line of "local-all-no-archive.diff" is simply "---" to mark
that the patch contains no header. Since the above fix ignores anything
after encountering a "---", an empty file gets passed to git mailinfo
which barfs.

Reverting the fix from #912426 seems to fix this.

James



signature.asc
Description: OpenPGP digital signature

Bug#852312: O: codelite -- Powerful and lightweight IDE

[James Cowgill]

Control: retitle -1 O: codelite -- Powerful and lightweight IDE

Hi,

On Mon, 23 Jan 2017 13:30:33 + James Cowgill 
wrote:
> Package: wnpp
> Severity: normal
> 
> Hi,
> 
> I'd like to give codelite up for adoption if anyone is interested. I
> don't really use it much anymore and it could do with a maintainer who
> does use it. It's a fairly large package and usually requires quite a
> bit of time to update so only adopt this if you're willing to put the
> effort into it. I'd prefer not to sponsor this package for anyone as I
> expect the review would take just as much time as updating the package
> in the first place! There is a git packaging repository on collab-maint.
> 
> I'll continue maintaining it until someone appears.

It has become apparent that I don't have the time to keep up maintaining
this, therefore I'm orphaning it now.

The git repository is here, and it's also pushed to dgit.
 https://salsa.debian.org/debian/codelite

James



signature.asc
Description: OpenPGP digital signature

Bug#915544: ffmpeg FTBFS against opencv 3.4.4

[James Cowgill]

Hi,

On 04/12/2018 15:24, Mo Zhou wrote:
> Source: ffmpeg
> Version: 7:4.0.3-1
> Severity: important
> 
> builddlog attached.

Relevant extract:
> check_func_headers opencv2/core/core_c.h cvCreateImageHeader -lopencv_core 
> -lopencv_imgproc
> test_ld cc -lopencv_core -lopencv_imgproc
> test_cc
> BEGIN /tmp/ffconf.jas2uoC0/test.c
> 1 #include 
> 2 #include 
> 3 long check_cvCreateImageHeader(void) { return (long) 
> cvCreateImageHeader; }
> 4 int main(void) { int ret = 0;
> 5  ret |= ((intptr_t)check_cvCreateImageHeader) & 0x;
> 6 return ret; }
> END /tmp/ffconf.jas2uoC0/test.c
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
> -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
> -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -fno-strict-overflow -fstack-protector-all -fPIE 
> -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 
> -I/usr/include/lilv-0 -I/usr/include/sratom-0 -I/usr/include/sord-0 
> -I/usr/include/serd-0 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid 
> -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/libxml2 -I/usr/include/uuid -I/usr/include/freetype2 
> -I/usr/include/libpng16 -I/usr/include/bs2b -I/usr/include/libdrm 
> -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi -c -o 
> /tmp/ffconf.jas2uoC0/test.o /tmp/ffconf.jas2uoC0/test.c
> In file included from /usr/include/opencv2/core/core_c.h:48,
>  from /tmp/ffconf.jas2uoC0/test.c:1:
> /usr/include/opencv2/core/types_c.h: In function 'cvIplImage':
> /usr/include/opencv2/core/types_c.h:370:12: error: incompatible types when 
> returning type 'int' but 'IplImage' {aka 'struct _IplImage'} was expected
>  return _IplImage();
> ^~~
> ERROR: libopencv not found
> make[1]: *** [debian/rules:214: override_dh_auto_configure] Error 1

Simply trying to compile the above header with a C compiler fails:

> $ gcc -include /usr/include/opencv2/core/core_c.h -x c - < /dev/null
> In file included from /usr/include/opencv2/core/core_c.h:48,
>  from :32:
> /usr/include/opencv2/core/types_c.h: In function ‘cvIplImage’:
> /usr/include/opencv2/core/types_c.h:370:12: error: incompatible types when 
> returning type ‘int’ but ‘IplImage’ {aka ‘struct _IplImage’} was expected
>  return _IplImage();
> ^~~

So it looks like the entire C API is bust in 3.4.4.

I seem some bugs and upstream ffmpeg discussion related to this:
https://github.com/opencv/opencv/issues/10963
https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226872.html

It seems the conclusion is that the OpenCV C API is dead and FFmpeg
should drop all support for it. That seems the likely course of action
for the Debian package unless someone can think of anything better.

James



signature.asc
Description: OpenPGP digital signature

Bug#914085: soundscaperenderer: failed to cofigure cleanly

[James Cowgill]

Control: severity -1 grave

Hi,

On 19/11/2018 08:03, Jean-Luc Coulon (f5ibh) wrote:
> Package: soundscaperenderer
> Version: 0.5.0~dfsg-1
> Severity: important
> 
> Hi,
> 
> While upgrading from 0.4.2~dfsg-7 to 0.5.0~dfsg-1, I get the following error:
> 
> 
> Setting up soundscaperenderer (0.5.0~dfsg-1) ...
> update-alternatives: error: alternative path /usr/bin/ssr-nfc-hoa.qt doesn't 
> exist
> dpkg: error processing package soundscaperenderer (--configure):
>  installed soundscaperenderer package post-installation script subprocess 
> returned error exit status 2
> Errors were encountered while processing:
>  soundscaperenderer

Thanks for this bug.

This is also reported by piuparts:
https://piuparts.debian.org/sid/fail/soundscaperenderer_0.5.0~dfsg-1.log

James



signature.asc
Description: OpenPGP digital signature

Bug#913541: pupnp-1.8: autopkgtests fail on some arches: libupnp uses large file support

[James Cowgill]

Control: tags -1 patch

Hi,

On 12/11/2018 20:04, Steve Langasek wrote:
> Package: pupnp-1.8
> Version: 1:1.8.4-2
> Followup-For: Bug #913541
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu disco ubuntu-patch
> 
> Attached is a patch which fixes the autopkgtest failure on 32-bit arches.
> In the process it also makes the pkg-config .pc file more useful; since
> software won't build correctly against pupnp without LFS_CFLAGS, we make
> these part of the pkg-config environment automatically.

Thanks for the patch.

My only concern is that setting _FILE_OFFSET_BITS in the pkg-config file
might surprise rdeps by having LFS silently turned on when they weren't
expecting it (especially if they don't work with LFS for some reason).
I'll probably ask upstream about what they think about this first.

James



signature.asc
Description: OpenPGP digital signature

Bug#913698: /usr/bin/ffprobe: Do not display version / build headers to stderr for ffprobe and others

[James Cowgill]

Control: tags -1 upstream wontfix
Control: forwarded -1 https://trac.ffmpeg.org/ticket/7211

Hi,

On 14/11/2018 03:31, Witold Baryluk wrote:
> Package: ffmpeg
> Version: 7:4.0.3-1
> Severity: wishlist
> File: /usr/bin/ffprobe
> 
> Hi.
> 
> 
> user@debian:~$ ffprobe output_x264_medium_crf22.mp4 >stdout.txt 2>stderr.txt
> user@debian:~$ cat stdout.txt
> user@debian:~$ cat stderr.txt
> ffprobe version 4.0.3-1 Copyright (c) 2007-2018 the FFmpeg developers
>   built with gcc 8 (Debian 8.2.0-9)
>   configuration: --prefix=/usr --extra-version=1 --toolchain=hardened
>   --libdir=/usr/lib/x86_64-linux-gnu
[...]
> I find it very distracting to have half of the screen consumed by version
> of ffmpeg, build options and libraries options.
> 
> There is no need for any (ANY, not even the first line) of these by default, 
> because there are:
> 
> ffprobe -version
> 
> that shows the same information  (on stdout).
> 
> And more comprehensive / machine parsable commands:
> 
> ffprobe -show_program_version
> ffprobe -show_library_versions
> ffprobe -show_versions  (both two above combined)
> 
> 
> Having option that restores some build info to be printed and continues
> execution could be useful for some tho. But it should not be enabled by
> default, and should output all these build info details to stdout.

This issue has been reported to upstream before (see the above link) and
they've declined to fix it - mainly citing support issues. Given that
upstream ffmpeg (for better or worse) are going to be receiving support
requests from people who have the Debian package installed, I'd rather
not deviate from upstream on this.

James



signature.asc
Description: OpenPGP digital signature

Bug#885025: gerbera: FTBFS against upnp 1.8.3

[James Cowgill]

Hi,

On 12/11/2018 20:51, Uwe Kleine-König wrote:
> Control: unblock 884635 with -1
> 
> Hello James,
> 
> On Fri, Dec 22, 2017 at 11:50:00PM +, James Cowgill wrote:
>> Source: gerbera
>> Version: 1.1.0+dfsg-2
>> Severity: important
>> Tags: sid buster fixed-upstream
>> Forwarded: https://github.com/gerbera/gerbera/issues/192
>> Control: block 884635 by -1
>>
>> Gerbera FTBFS with pupnp 1.8.3 in experimental as described in the
>> upstream bug report.
>>
>> Fixed in this commit (unfortunately quite large):
>> https://github.com/gerbera/gerbera/commit/55396b59027f12a8da09e81a83c7565051466159
>>
>> In addition, when the libupnp 1.8 transition begins, gerbera should
>> switch back to build-depending on libupnp-dev (instead of
>> libupnp1.8-dev).
> 
> Can you please upload gerbera with Build-Depending on libupnp-dev again.
> This is blocking the auto-pupnp-1.8 transition[1] (I think).

As the title of this bug suggests, gerbera won't build with pupnp 1.8.3
(or 1.8.4) so on its own this won't help. I was going to try and package
gerbera 1.2.0 which does fix this issue, but it's taking longer than
expected (mostly javascript library issues). I'll have a look at
patching it in the meantime.

James



signature.asc
Description: OpenPGP digital signature

Bug#913209: [mpv] Segfault when setting png as screenshot format

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 08/11/2018 04:51, Synthea wrote:
> Package: mpv
> Version: 0.23.0-2+deb9u2
> Severity: normal
> 
> When using --screenshot-format=png or inserting a line screenshot-
> format=png in the config files mpv segfaults
> Here's the debug
[...]
> Screenshot: '/home/dday/Screenshot-0001.png'
> 
> Thread 1 "mpv" received signal SIGSEGV, Segmentation fault.
> 0x765030e0 in avcodec_find_best_pix_fmt_of_list () from
> /usr/lib/x86_64-linux-gnu/libavcodec.so.57

What version of ffmpeg do you have? You can run this to find out:
 dpkg -l libavcodec57

This sounds like #904123 which was fixed in ffmpeg 7:3.2.12-1~deb9u1.

James



signature.asc
Description: OpenPGP digital signature

Bug#884635: transition: libupnp

[James Cowgill]

Hi,

On 05/11/2018 17:28, Uwe Kleine-König wrote:
> Hello Emilio,
> 
> [adding jcowgill to recipients]
> 
> On 11/05/2018 04:37 PM, Emilio Pozuelo Monfort wrote:
>> Please get this started, and bump the bug severities to serious.
> 
> I never did a transition before, so I'm not entirely clear what should
> happen now.
> 
> The following steps should be done:
> 
> a) upload pupnp-1.8 providing libupnp-dev to unstable
> b) rebuild reverse dependencies of libupnp-dev
> c) remove src:libupnp from unstable
> d) remove src:libupnp from testing
> e) remove the binary packages of src:libupnp from unstable
> f) remove the binary packages of src:libupnp from testing
> g) for b in 884243 884996 912066 885025; do bts severity $b serious;done
> h) remove djmount and linux-igd from unstable and testing
> i) apply patch from 884996 to amule and upload to unstable

Yeah we can start this transition now that 1.8.4 was released (which
resolved the ABI related issues). I'll upload it soon.

The order is this:

a) I upload pupnp-1.8 (which "hijacks" libupnp-dev from src:libupnp)
g) Update bug severities
b) binNMU all rdeps of libupnp-dev
[time passes]
i) NMU amule / any other package if not fixed soon
[time passes - eventually all broken rdeps are autoremoved from testing]
d and f) Happen automatically at this point
[transition complete (with respect to testing)]
h) File requests to remove remaining packages
c and e) File request to remove src:libupnp

James



signature.asc
Description: OpenPGP digital signature

Bug#912827: mpv 0.29.1 cannot display video on Weston 5.0.0

[James Cowgill]

Control: reassign -1 weston
Control: severity -1 normal
Control: retitle -1 weston: add support for stable xdg-shell
Control: affects -1 mpv
Control: tags -1 upstream

Hi,

On 04/11/2018 07:04, Kelly Clowers wrote:
> Package: mpv
> Version: 0.28.2-3
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> Updated MPV to 0.29.1 from 0.28.2
> 
> * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Tried to play a video file I have played many times before
> 
> * What was the outcome of this action?
> 
> MPV failed to play the file with the following error message:
> 
> krc@ken:~/NFS/public/video/documentaries/David_Attenborough$ mpv
> 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv
> Playing: 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv
> Unable to revert mtime: /usr/local/share/fonts
>  (+) Video --vid=1 (*) (h264 1920x1080 25.000fps)
>  (+) Audio --aid=1 --alang=eng (*) (dts 6ch 48000Hz)
>  Subs  --sid=1 --slang=eng (*) (hdmv_pgs_subtitle)
> [vo/gpu/wayland] Compositor doesn't support the required xdg_wm_base protocol!
> [vo/gpu] Failed initializing any suitable GPU context!
> Error opening/initializing the selected video_out (--vo) device.
> Video: no video

As of this commit (first in 0.29.0), mpv dropped support for xdg-shell
v6 and now only supports the stable version of xdg-shell:
https://github.com/mpv-player/mpv/commit/76211609e3c589dafe3ef9a36cacc06e8f56de09

Unfortunately Weston doesn't support stable xdg-shell yet. I have a
feeling that currently mutter is the only compositor which does
(although I may be wrong).

There is an upstream mpv bug about this which hasn't seen any activity.
I'll poke it and see what upstream has to say, but I doubt they're going
to reintroduce xdg-shell v6 support.
https://github.com/mpv-player/mpv/issues/6110

James



signature.asc
Description: OpenPGP digital signature

Bug#912423: codelite: fails to start: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported

[James Cowgill]

Control: reassign -1 libwxsqlite3-3.0-0 3.4.1~dfsg-2
Control: tags -1 - confirmed
Control: retitle -1 libwxsqlite3-3.0-0: switch to gtk3 breaks the ABI
Control: affects -1 src:codelite src:maitreya

Hi,

On 31/10/2018 13:15, James Cowgill wrote:
> Control: severity -1 grave
> Control: tags -1 confirmed
> Control: retitle -1 codelite: fails to start: GTK+ 2.x symbols detected. 
> Using GTK+ 2.x and GTK+ 3 in the same process is not supported
> 
> Hi,
> 
> On 31/10/2018 11:50, Larus wrote:
>> Package: codelite
>> Version: 10.0+dfsg-3
>> Severity: important
>>
>> Dear Maintainer,
>> when starting codelite the process shuts down directly when starting.
>> Reason:
>> (codelite:1081): Gtk-ERROR **: 12:48:04.992: GTK+ 2.x symbols detected. 
>> Using GTK+ 2.x and GTK+ 3 in the same process is not supported
>> Sadly I haven't been able to resolve this.
> 
> Indeed I cannot start codelite in unstable either. As well as the above,
> I also get a lot of other errors when trying to run it (below).

This was caused by wxsqlite3 switching to GTK+3. This comes into
conflict with codelite which is built against GTK+2. As the error above
states, you cannot load the GTK+2 and GTK+3 libraries into the same process.

This change is pretty much guaranteed to break all reverse dependencies
of wxsqlite3 (because any existing rdep must have been compiled against
GTK+2 to function). I think it makes most sense to handle this like a
normal package transition and either rename the package, or add extra
packages (like wxwidgets3.0 did). If you don't do that, you'll need to
add a Breaks for all your rdeps (but this won't help if any user
programs outside Debian link against wxsqlite).

In theory, codelite does support building against GTK+3, but I haven't
tried it. The other rdep is maitreya which doesn't link against any GTK+
version directly, so in theory changing the build dependencies to the
GTK+3 versions should "Just Work" :)  This means you can probably get
away with a rename instead of adding extra packages.

It's unfortunate this took a month to discover. I guess there's not many
people using these packages :/

James



signature.asc
Description: OpenPGP digital signature

Bug#912423: codelite: fails to start: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported

[James Cowgill]

Control: severity -1 grave
Control: tags -1 confirmed
Control: retitle -1 codelite: fails to start: GTK+ 2.x symbols detected. Using 
GTK+ 2.x and GTK+ 3 in the same process is not supported

Hi,

On 31/10/2018 11:50, Larus wrote:
> Package: codelite
> Version: 10.0+dfsg-3
> Severity: important
> 
> Dear Maintainer,
> when starting codelite the process shuts down directly when starting.
> Reason:
> (codelite:1081): Gtk-ERROR **: 12:48:04.992: GTK+ 2.x symbols detected. Using 
> GTK+ 2.x and GTK+ 3 in the same process is not supported
> Sadly I haven't been able to resolve this.

Indeed I cannot start codelite in unstable either. As well as the above,
I also get a lot of other errors when trying to run it (below).

Unfortunately I don't have a lot of time to maintain codelite anymore
(see the open RFA bug), so any help from anyone in debugging this would
be appreciated. From the log, it's going to be something related to
wxWidgets. Maybe trying some older wxWidgets versions might help??

Thanks for reporting!
James

Log:
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxCommandEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxNotifyEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxScrollEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxScrollWinEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxMouseEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxKeyEvent" already in RTTI table - have you used 
IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxSizeEvent" already in RTTI table - have you used 
IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxPaintEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxNcPaintEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxEraseEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxMoveEvent" already in RTTI table - have you used 
IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxFocusEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxChildFocusEvent" already in RTTI table - have 
you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file 
twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxCloseEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxShowEvent" already in RTTI table - have you used 
IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxMaximizeEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxIconizeEvent" already in RTTI table - have you 
used 

Bug#912066: linux-igd: FTBFS with upnp 1.8.4

[James Cowgill]

Source: linux-igd
Version: 1.0+cvs20070630-6
Severity: important
Tags: sid buster
User: jcowg...@debian.org
Usertags: upnp-1.8-transition
Control: block 884635 by -1

Hi,

linux-idg FTBFS with upnp 1.8.4 (in experimental) with this error:
> gatedevice.c:10:10: fatal error: TimerThread.h: No such file or directory
>  #include 
>   ^~~
> compilation terminated.

The threadutil library is no longer shipped with upnp 1.8 since it's an
implementation detail which has nothing to do with upnp itself.

Unfortunately it looks like a lot of code needs rewriting to use
pthreads directly or another threading library (which can cope with some
of the extra features of threadutil like thread pooling).

James



signature.asc
Description: OpenPGP digital signature

Bug#911584: libopenmpt: out of bounds memory read in MED files

[James Cowgill]

Source: libopenmpt
Version: 0.2.7025~beta20.1-1
Severity: important
Tags: security upstream fixed-upstream

Hi,

Upstream 0.3.13 released a fix for an out of bound read in malformed MED
files. It affects stretch.

Announcement:
https://lib.openmpt.org/libopenmpt/2018/10/21/security-updates-0.3.13-0.2.10933-beta36-0.2.7561-beta20.5-p11-0.2.7386-beta20.3-p14/

Upstream commit which fixes this:
https://source.openmpt.org/browse/openmpt/trunk/?op=revision=10903

James



signature.asc
Description: OpenPGP digital signature

Bug#910708: mpv: please compile with v4l support

[James Cowgill]

Control: tags -1 wontfix
Control: close -1

Hi,

On 10/10/2018 02:04, sergio wrote:
> Package: mpv
> Version: 0.29.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> please add v4l support.
> 
> % mpv --tv=driver=help
> Error parsing option tv (option not found)

This is intentional. The tv support in mpv has been unmaintained for
some time now and upstream recommends you use the v4l support from
libavdevice instead.

Eg:
 mpv av://v4l2:/dev/video0

James



signature.asc
Description: OpenPGP digital signature

Bug#910271: transition: mbedtls

[James Cowgill]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

mbedTLS needs a transition because upstream bumped the SONAME of
libmbedtls in 2.13 due to some symbol changes. I have also changed the
SONAME of libmbedcrypto to realign it with upstream. Previously upstream
had bumped the SONAME for no reason, so I reverted that change. Since we
now need a transition anyway, it seems sensible to me to use upstream's
SONAME again.

The auto-mbedtls transition tracker looks correct. These packages need
binNMUing:
 bctoolbox
 bibledit
 charybdis
 dislocker
 dolphin-emu
 gatling
 julia
 libgit2
 lief
 mongrel2
 ncbi-blast+
 ncbi-vdb
 neko
 shadowsocks-libev
 sra-sdk

All the packages build fine in a test rebuild except for dolphin-emu
which FTBFS for unrelated reasons which I will fix soon (#910268).

sra-sdk is waiting on this ftpmaster removal bug before it can migrate
to testing: #907266

Thanks,
James

Ben file:

title = "mbedtls";
is_affected = .depends ~ "libmbedcrypto1" | .depends ~ "libmbedtls10" |
.depends ~ "libmbedcrypto3" | .depends ~ "libmbedtls12";
is_good = .depends ~ "libmbedcrypto3" | .depends ~ "libmbedtls12";
is_bad = .depends ~ "libmbedcrypto1" | .depends ~ "libmbedtls10";


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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



signature.asc
Description: OpenPGP digital signature

Bug#910268: dolphin-emu: FTBFS with googletest 1.8.1

[James Cowgill]

Source: dolphin-emu
Version: 5.0+dfsg-3
Severity: serious
Tags: sid buster ftbfs fixed-upstream

dolphin-emu FTBFS with googletest 1.8.1:
> In file included from 
> /usr/src/gtest/include/gtest/internal/gtest-internal.h:40,
>  from /usr/src/gtest/include/gtest/gtest.h:59,
>  from 
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:11:
> /usr/src/gtest/include/gtest/internal/gtest-port.h:891:57: error: 
> 'gtest_AllCombinationsVertexLoaderParamTest_dummy_' was declared 'extern' and 
> later 'static' [-fpermissive]
>  # define GTEST_ATTRIBUTE_UNUSED_ __attribute__ ((unused))
>  ^
> /usr/src/gtest/include/gtest/gtest-param-test.h:1421:54: note: in expansion 
> of macro 'GTEST_ATTRIBUTE_UNUSED_'
>static int gtest_##prefix##test_case_name##_dummy_ GTEST_ATTRIBUTE_UNUSED_ 
> = \
>   ^~~
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:111:1: 
> note: in expansion of macro 'INSTANTIATE_TEST_CASE_P'
>  INSTANTIATE_TEST_CASE_P(
>  ^~~
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:110:12: 
> note: previous declaration of 
> 'gtest_AllCombinationsVertexLoaderParamTest_dummy_'
>  extern int gtest_AllCombinationsVertexLoaderParamTest_dummy_;
> ^
> In file included from 
> /usr/src/gtest/include/gtest/internal/gtest-internal.h:40,
>  from /usr/src/gtest/include/gtest/gtest.h:59,
>  from 
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:11:
> /usr/src/gtest/include/gtest/internal/gtest-port.h:891:57: error: 
> 'gtest_FormatsAndElementsVertexLoaderSpeedTest_dummy_' was declared 'extern' 
> and later 'static' [-fpermissive]
>  # define GTEST_ATTRIBUTE_UNUSED_ __attribute__ ((unused))
>  ^
> /usr/src/gtest/include/gtest/gtest-param-test.h:1421:54: note: in expansion 
> of macro 'GTEST_ATTRIBUTE_UNUSED_'
>static int gtest_##prefix##test_case_name##_dummy_ GTEST_ATTRIBUTE_UNUSED_ 
> = \
>   ^~~
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:206:1: 
> note: in expansion of macro 'INSTANTIATE_TEST_CASE_P'
>  INSTANTIATE_TEST_CASE_P(
>  ^~~
> /<>/Source/UnitTests/VideoCommon/VertexLoaderTest.cpp:205:12: 
> note: previous declaration of 
> 'gtest_FormatsAndElementsVertexLoaderSpeedTest_dummy_'
>  extern int gtest_FormatsAndElementsVertexLoaderSpeedTest_dummy_;
> ^~~~
> make[5]: *** 
> [Source/UnitTests/VideoCommon/CMakeFiles/Test_VertexLoaderTest.dir/build.make:66:
>  
> Source/UnitTests/VideoCommon/CMakeFiles/Test_VertexLoaderTest.dir/VertexLoaderTest.cpp.o]
>  Error 1

Should be fixed by this upstream commit which I'll upload at some point:

https://github.com/dolphin-emu/dolphin/commit/ccf9ecbb03edbdd728738499dc5fae4d0631882a

James



signature.asc
Description: OpenPGP digital signature

Bug#909380: libvidstab: enable Multi-Arch: same

[James Cowgill]

Hi,

On 01/10/2018 11:55, Keng-Yu Lin wrote:
> Hi James:
>   While I worked on the package, salsa was kind of messy for non-DD
> contributors. I just checked, it looks much better now. I think I will
> use salsa as the vcs repository.
> 
>   Can you help grant me the DM permission so that I am able to upload?
> 
>   `dcut dm` as described in https://wiki.debian.org/DebianMaintainer

I don't give DM permissions to people I haven't worked with before.
However, I will happily sponsor the upload for you if you give me a git
repository or a dsc.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#909193: mpv shows artifacts when playing IPTV rtp:// streams

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 19/09/2018 15:01, Pavel Kreuzt wrote:
> Package: mpv
> Version: 0.29.0-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> the artifacts are mostly located on the lower side of the window. Streams 
> play correctly with ffplay without extra options, so it's not a decoder 
> problem.

Can you provide an example stream which exibits this behavior? I tested
a few rtp streams and they seem to work fine.

Also, please run mpv with the "-v" option on one of the broken streams,
and attach the output to this bug report.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#909590: gerbera: Gerbera fails on start and every 5 sec

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 25/09/2018 19:14, Jean-Louis wrote:
> Package: gerbera
> Version: 1.1.0+dfsg-2+b2
> Severity: important
> 
> Dear Maintainer,
> 
> Hello, I use gerbera for a long time and recently, the server failed and 
> fails  to restart every 5 seconds. 
> No valuable information in log file. The package is fully unusable.
> 
> Same problem after purge and reinstall. I guess the best information is the 
> following line that apperas once in the log file at machine startup :
> 
> Sep 25 19:21:51 mercury gerbera[1178]: /usr/bin/gerbera: 
> /lib/arm-linux-gnueabihf/libc.so.6: version `' not found (required by 
> /lib/arm-linux-gnueabihf/libmagic.so.1)

That is a very strange error indicating that ld.so failed to load
gerbera before any code was executed.

Does running "gerbera --version" outside systemd work?
Does running "file" on something work?

Are you running a system with usrmerge enabled (ie is /lib a symlink to
/usr/lib)?

James



signature.asc
Description: OpenPGP digital signature

Bug#909583: tortoisehg: update to 4.7.1

[James Cowgill]

Source: tortoisehg
Version: 4.7-0.1
Severity: wishlist

Hi,

I know it's only been about a week since the release, but it would be
great if tortoisehg could be updated to 4.7.1 in Debian. It fixes a lot
of crashes which I seem to be hitting a lot.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#893749: stretch-pu: package easytag/2.4.3-1+deb9u1

[James Cowgill]

Control: tags -1 - moreinfo

Hi,

Sorry for the delay. I completely forgot about this bug!

I've attached v2 of the patch to fix #855251. After submitting the
original stretch-pu bug, I discovered (after someone mentioned this on
the upstream bug report) the root cause and reverted the relevant
upstream commit. This fix has been in unstable since 2.4.3-4 (about 7
months) without any issues. I've done some brief testing of in a stretch
build and it seems to work fine there as well.

Thanks,
James
diff -Nru easytag-2.4.3/debian/changelog easytag-2.4.3/debian/changelog
--- easytag-2.4.3/debian/changelog  2016-12-05 23:46:24.0 +
+++ easytag-2.4.3/debian/changelog  2018-09-24 18:31:35.0 +0100
@@ -1,3 +1,11 @@
+easytag (2.4.3-1+deb9u1) stretch; urgency=medium
+
+  * debian/patches:
+- Add patch to revert upstream commit which causes OGG corruption.
+  (Closes: #855251)
+
+ -- James Cowgill   Mon, 24 Sep 2018 18:31:35 +0100
+
 easytag (2.4.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru easytag-2.4.3/debian/gbp.conf easytag-2.4.3/debian/gbp.conf
--- easytag-2.4.3/debian/gbp.conf   2016-12-05 20:47:35.0 +
+++ easytag-2.4.3/debian/gbp.conf   2018-09-24 18:31:35.0 +0100
@@ -1,3 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 compression = xz
+debian-branch = debian/stretch
diff -Nru easytag-2.4.3/debian/patches/02_fix-ogg-corruption.patch 
easytag-2.4.3/debian/patches/02_fix-ogg-corruption.patch
--- easytag-2.4.3/debian/patches/02_fix-ogg-corruption.patch1970-01-01 
01:00:00.0 +0100
+++ easytag-2.4.3/debian/patches/02_fix-ogg-corruption.patch2018-09-24 
18:31:35.0 +0100
@@ -0,0 +1,241 @@
+Description: Revert upstream commit which causes OGG file corruption
+ Revert "Do not maintain an open handle on Ogg files"
+ This reverts commit e5c640ca3f259f1b74e716723345521987a7bd68.
+Author: James Cowgill 
+Author: David King 
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=776110
+Bug-Debian: https://bugs.debian.org/855251
+Bug-Debian: https://bugs.debian.org/886272
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/tags/vcedit.c
 b/src/tags/vcedit.c
+@@ -35,6 +35,7 @@
+ struct _EtOggState
+ {
+ /*< private >*/
++GFileInputStream *in;
+ #ifdef ENABLE_SPEEX
+ SpeexHeader *si;
+ #endif
+@@ -125,6 +126,11 @@ vcedit_clear_internals (EtOggState *stat
+ }
+ #endif /* ENABLE_OPUS */
+ 
++if (state->in)
++{
++g_object_unref (state->in);
++}
++
+ memset (state, 0, sizeof (*state));
+ }
+ 
+@@ -239,7 +245,6 @@ _blocksize (EtOggState *s,
+ 
+ static gboolean
+ _fetch_next_packet (EtOggState *s,
+-GInputStream *istream,
+ ogg_packet *p,
+ ogg_page *page,
+ GError **error)
+@@ -269,8 +274,8 @@ _fetch_next_packet (EtOggState *s,
+ while (ogg_sync_pageout (s->oy, page) <= 0)
+ {
+ buffer = ogg_sync_buffer (s->oy, CHUNKSIZE);
+-bytes = g_input_stream_read (istream, buffer, CHUNKSIZE, NULL,
+- error);
++bytes = g_input_stream_read (G_INPUT_STREAM (s->in), buffer,
++ CHUNKSIZE, NULL, error);
+ ogg_sync_wrote (s->oy, bytes);
+ 
+ if(bytes == 0)
+@@ -303,7 +308,7 @@ _fetch_next_packet (EtOggState *s,
+ 
+ g_assert (error == NULL || *error == NULL);
+ ogg_stream_pagein (s->os, page);
+-return _fetch_next_packet (s, istream, p, page, error);
++return _fetch_next_packet (s, p, page, error);
+ }
+ }
+ 
+@@ -402,13 +407,14 @@ vcedit_open (EtOggState *state,
+ return FALSE;
+ }
+ 
++state->in = istream;
+ state->oy = g_slice_new (ogg_sync_state);
+ ogg_sync_init (state->oy);
+ 
+ while(1)
+ {
+ buffer = ogg_sync_buffer (state->oy, CHUNKSIZE);
+-bytes = g_input_stream_read (G_INPUT_STREAM (istream), buffer,
++bytes = g_input_stream_read (G_INPUT_STREAM (state->in), buffer,
+  CHUNKSIZE, NULL, error);
+ if (bytes == -1)
+ {
+@@ -648,7 +654,7 @@ vcedit_open (EtOggState *state,
+ }
+ 
+ buffer = ogg_sync_buffer (state->oy, CHUNKSIZE);
+-bytes = g_input_stream_read (G_INPUT_STREAM (istream), buffer,
++bytes = g_input_stream_read (G_INPUT_STREAM (state->in), buffer,
+  CHUNKSIZE, NULL, error);
+ 
+ if (bytes == -1)
+@@ -670,14 +676,11 @@ vcedit_open (EtOggState *state,
+ 
+ /* Headers are done! */
+ g_assert (error == NULL || *error == NULL);
+-/* TODO: Handle error during stream close. */
+-g_object_unref (istream);
+ 
+ return TRUE;
+ 
+ err:
+ g_assert (error == NULL || *error != NULL);
+-g_object_unref (istream);
+ vcedit_clear

Bug#909380: libvidstab: enable Multi-Arch: same

[James Cowgill]

Source: libvidstab
Version: 1.1.0-1
Severity: normal
Control: block 781938 by -1

Hi,

I just noticed libvidstab was uploaded. Thanks!

Please add some "Multi-Arch: same" fields on libvidstab-dev and
libvidstab1.1 so that the package is multi-arch compatible. I can't
enable the library in ffmpeg until this is done.

An unrelated question: do you have a vcs repository with the packaging
in somewhere?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#909339: git-deborig: should ensure .git/info exists before writing attributes

[James Cowgill]

Package: devscripts
Version: 2.18.4
Severity: normal

Hi,

If git-deborig is run in a repository without a .git/info directory, it
fails with:
> could not open .git/info/attributes for writing at /usr/bin/git-deborig line 
> 230.

git-deborig should probably create this directory before hand.

Thanks,
James

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=AEED6158020EAFFF
DEBSIGN_PROGRAM=gpg

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0~rc2
pn  at  
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.07.24
ii  dput-ng [dput]  1.21
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
ii  licensecheck3.0.31-2
ii  lintian 2.5.104
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.7.0~rc1
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-2
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  5.5
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
ii  diffoscope   101
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-2
pn  gnuplot  
ii  gpgv 2.2.10-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.8p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-2
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#909026: nethack-el: fails to run with nethack 3.6.1

[James Cowgill]

Package: nethack-el
Version: 1:0.9.5-3
Severity: grave
Tags: sid buster
X-Debbugs-CC: neth...@packages.debian.org

Hi,

nethack-el fails to start when using nethack-lisp 3.6.1. There's a
strong chance this is caused by nethack itself, but I haven't
investigated it much.

I'm filing this bug now because I have been thinking about removing the
lisp port anyway and this is the only package which uses it. As far as I
can see, the port has been dead for almost 12 years upstream, hasn't
really been tested with nethack 3.6, and makes up a large bulk of the
Debian patch set which takes ages to rebase on every upstream update. If
someone wants to help keep it going then patches are welcome, but I'm
not particularly interested in keeping it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#908849: gerbera: No linefeed before CONNECTION header

[James Cowgill]

Control: tags -1 confirmed fixed-upstream
Control: forwarded -1 https://github.com/gerbera/gerbera/pull/316

Hi,

On 15/09/2018 01:17, Pelzi wrote:
> Package: gerbera
> Version: 1.1.0+dfsg-2+b2
> Severity: normal
> 
> Dear Maintainer,
> 
> Try to play an audio track served by gerbera using the uPnP protocol. This 
> leads to an ordinary http get from client (here VLC running on Mac OS).
> 
> As a result, Gerbera will send back an http answer, consisting of an HTTP 
> header and content (which is intended to be streamed by the client). Gerbera 
> adds "CONNECTION: close" to the last line of the header, whichever that is, 
> e.g.: Accept-Ranges: bytesCONNECTION: close
> (In certain situations the last header line might happen to be the 
> Content-Disposition heder and in that case, VLC turns out to be
> uncapable of parsing the header at all and will refuse to play the respective 
> track.)
> 
> Instead, Gerbera should add another line to the header, i.e.
> Accept-Ranges: bytes
> CONNECTION: close
> These lines must be separated by CR LF, as always in HTTP.

Thanks for the bug report. I can confirm this bug.

I think it's fixed by the above upstream PR (not in any released
version). I'll see if I can cherry-pick it at the next upload of gerbera.

James



signature.asc
Description: OpenPGP digital signature

Bug#908784: nethack: license incompatibility results in non-distributable binaries

[James Cowgill]

On 14/09/2018 17:50, Vincent Cheng wrote:
> On Thu, Sep 13, 2018 at 2:51 PM James Cowgill  wrote:
>> Vincent, can all your changes to the nethack package be licensed under
>> the NGPL instead of the GPL-2.0?
> 
> Yes, I'm fine with licensing my changes to nethack under the NGPL as well.

Thanks!
James




signature.asc
Description: OpenPGP digital signature

Bug#908784: nethack: license incompatibility results in non-distributable binaries

[James Cowgill]

Source: nethack
Version: 3.4.3-14
Severity: serious
X-Debbugs-CC: vch...@debian.org

Hi,

While reviewing the copyright file for the NetHack 3.6.1 upload, I
noticed that the debian directory (and its patches) are marked as under
the GPL-2.0. Unfortunately NetHack's special NGPL license is not
compatible with the GPL (both are copyleft with some conflicting terms),
so I have come to the conclusion that Debian's version of NetHack is not
distributable in binary form at all.

Thankfully I think this can be resolved fairly smoothly. If I look at
the package history, I see that before 3.4.3-14 everything was licensed
under the NGPL (except for the lisp patches). In this version, the
copyright file was changed to relicense(?!) the debian/ directory under
the GPL. Vincent and I are the only people who have claimed copyright
since that point, and I am fine with licensing my stuff under the NGPL,
so Vincent is the only person who needs asking.

Vincent, can all your changes to the nethack package be licensed under
the NGPL instead of the GPL-2.0?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#908161: Please enable building a riscv64 kernel image

[James Cowgill]

Hi!

On 06/09/2018 21:06, Karsten Merker wrote:
> Unfortunately, with the patch applied the kernel itself builds
> successfully, but the package build process then fails with
> 
> -8<--8<--8<--8<--8<-
> 
> make[3]: Leaving directory 
> '<>/linux-4.19~rc2/debian/build/build_riscv64_none_riscv64'
> debian/bin/buildcheck.py debian/build/build_riscv64_none_riscv64 riscv64 none 
> riscv64
> ABI is not completely versioned!  Refusing to continue.
> 
> Unversioned symbols:
> _mcount  module: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> return_to_handlermodule: vmlinux, version: 
> 0x, export: EXPORT_SYMBOL
> Can't read ABI reference.  ABI not checked!
> make[2]: *** [debian/rules.real:217: 
> debian/stamps/build_riscv64_none_riscv64] Fehler 1
> 
> -8<--8<--8<--8<--8<-
> 
> I'm somewhat stuck here - is this an upstream issue or
> have I overlooked something on the packaging side? Pointers
> welcome :).

I sent this upstream patch for this:
http://lists.infradead.org/pipermail/linux-riscv/2018-September/001372.html

James



signature.asc
Description: OpenPGP digital signature

Bug#908020: fonts-cantarell: psautohint invocation silently fails

[James Cowgill]

Source: fonts-cantarell
Version: 0.110-1
Severity: important
Tags: sid buster

Hi,

Building fonts-cantarell in unstable results in this "failure" in the
build log which doesn't cause the build to fail:

> [2/2] /usr/bin/python3 /tmp/fonts-cantarell-0.110/scripts/fm.py 
> /usr/bin/fontmake /usr/bin/psautohint ../src/Cantarell.glyphs src
> WARNING:ufo2ft.outlineCompiler:The copyright was normalized for storage in 
> the CFF table and consequently some characters were dropped: 'Copyright c 
> 2009--2017 The Cantarell Authors'
> WARNING:ufo2ft.outlineCompiler:The copyright was normalized for storage in 
> the CFF table and consequently some characters were dropped: 'Copyright c 
> 2009--2017 The Cantarell Authors'
> WARNING:ufo2ft.outlineCompiler:The copyright was normalized for storage in 
> the CFF table and consequently some characters were dropped: 'Copyright c 
> 2009--2017 The Cantarell Authors'
> WARNING:ufo2ft.outlineCompiler:The copyright was normalized for storage in 
> the CFF table and consequently some characters were dropped: 'Copyright c 
> 2009--2017 The Cantarell Authors'
> WARNING:ufo2ft.outlineCompiler:The copyright was normalized for storage in 
> the CFF table and consequently some characters were dropped: 'Copyright c 
> 2009--2017 The Cantarell Authors'
> usage: psautohint [-h] [-v] [-o PATH [PATH ...]] [-r PATH] [-a] [-w]
>   [-g GLYPH_LIST | --glyphs-file PATH | -x GLYPH_LIST | 
> --exclude-glyphs-file PATH]
>   [-c | --report-only] [--log PATH] [-d] [--no-flex]
>   [--no-hint-sub] [--no-zones-stems] [--fontinfo-file PATH]
>   [--print-dflt-fddict] [--print-list-fddict] [--doc-fddict]
>   [--info] [--version]
>   FONT [FONT ...]
> psautohint: error: unrecognized arguments: -qq
> usage: psautohint [-h] [-v] [-o PATH [PATH ...]] [-r PATH] [-a] [-w]
>   [-g GLYPH_LIST | --glyphs-file PATH | -x GLYPH_LIST | 
> --exclude-glyphs-file PATH]
>   [-c | --report-only] [--log PATH] [-d] [--no-flex]
>   [--no-hint-sub] [--no-zones-stems] [--fontinfo-file PATH]
>   [--print-dflt-fddict] [--print-list-fddict] [--doc-fddict]
>   [--info] [--version]
>   FONT [FONT ...]
> psautohint: error: unrecognized arguments: -qq
> usage: psautohint [-h] [-v] [-o PATH [PATH ...]] [-r PATH] [-a] [-w]
>   [-g GLYPH_LIST | --glyphs-file PATH | -x GLYPH_LIST | 
> --exclude-glyphs-file PATH]
>   [-c | --report-only] [--log PATH] [-d] [--no-flex]
>   [--no-hint-sub] [--no-zones-stems] [--fontinfo-file PATH]
>   [--print-dflt-fddict] [--print-list-fddict] [--doc-fddict]
>   [--info] [--version]
>   FONT [FONT ...]
> psautohint: error: unrecognized arguments: -qq
> usage: psautohint [-h] [-v] [-o PATH [PATH ...]] [-r PATH] [-a] [-w]
>   [-g GLYPH_LIST | --glyphs-file PATH | -x GLYPH_LIST | 
> --exclude-glyphs-file PATH]
>   [-c | --report-only] [--log PATH] [-d] [--no-flex]
>   [--no-hint-sub] [--no-zones-stems] [--fontinfo-file PATH]
>   [--print-dflt-fddict] [--print-list-fddict] [--doc-fddict]
>   [--info] [--version]
>   FONT [FONT ...]
> psautohint: error: unrecognized arguments: -qq
> usage: psautohint [-h] [-v] [-o PATH [PATH ...]] [-r PATH] [-a] [-w]
>   [-g GLYPH_LIST | --glyphs-file PATH | -x GLYPH_LIST | 
> --exclude-glyphs-file PATH]
>   [-c | --report-only] [--log PATH] [-d] [--no-flex]
>   [--no-hint-sub] [--no-zones-stems] [--fontinfo-file PATH]
>   [--print-dflt-fddict] [--print-list-fddict] [--doc-fddict]
>   [--info] [--version]
>   FONT [FONT ...]
> psautohint: error: unrecognized arguments: -qq
>dh_auto_test
>   cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 ninja test
> [0/1] Running all tests.
> No tests defined.
>create-stamp debian/debhelper-build-stamp
>  fakeroot debian/rules binary

The build then continues as normal.

Probably the invocation should be fixed and then the build should be
made to fail if psautohint fails.

James



signature.asc
Description: OpenPGP digital signature

Bug#907032: has there been any thought of also having the rav1e encoder as well ?

[James Cowgill]

Hi,

On 03/09/2018 09:26, shirish शिरीष wrote:
> Hi all,
> 
> Have people looked at https://github.com/xiph/rav1e . One of the
> blockages though seems to be https://github.com/mbebenita/rustfmt
> which doesn't seem to be packaged in Debian at least in first glance.
> As shared this one is supposed to be a bit faster than the reference
> implementation for encoding though.

I had a brief look during Debconf at rav1e. At the time lots of
dependencies weren't packaged. I know things are improving quickly with
Rust in Debian so this may have changed. AFAIK upstream hasn't sorted
the public API out yet or even made a release which I think are both
requirements for packaging this in Debian.

James



signature.asc
Description: OpenPGP digital signature

Bug#907667: lintian: should html escape output if --color=html is used

[James Cowgill]

Package: lintian
Version: 2.5.99
Severity: important
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
X-Debbugs-CC: debian-ad...@lists.debian.org

Hi,

Lintian does not html escape tag information when --color=html is used.
I noticed this after browsing a few packages in the NEW queue which have
broken stylesheets. Current examples:
https://ftp-master.debian.org/new/displaycal_3.6.1.0-1.html
https://ftp-master.debian.org/new/json-editor.js_0.7.28+ds-1.html

When generating those pages, dak passes --color=html to lintian and does
not escape the output (because that would escape the span tags). In this
case some privacy-breach-generic tags contained  $ lintian --color=html libjs-json-editor_0.7.28+ds-1_all.deb
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html [ href="//cdn.jsdelivr.net/sceditor/1.4.3/jquery.sceditor.default.min.css">] 
> (//cdn.jsdelivr.net/sceditor/1.4.3/jquery.sceditor.default.min.css)
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html [ href="//cdn.jsdelivr.net/sceditor/1.4.3/themes/default.min.css">] 
> (//cdn.jsdelivr.net/sceditor/1.4.3/themes/default.min.css)
> W: libjs-json-editor: privacy-breach-generic 
> usr/share/doc/libjs-json-editor/examples/wysiwyg.html 

Bug#907248: libopenmpi3, libpmix2: both ship libpmix.so.2 without suitable conflicts / replaces

[James Cowgill]

Package: libopenmpi3,libpmix2
Severity: grave
Control: found -1 libopenmpi3/3.1.1.real-7
Control: found -1 libpmix2/3.0.1-1

Hi,

Attempting to upgrade libopenmpi3 to 3.1.1.real-7 after libpmix2 has
already been upgraded to 3.0.1-1 results in this error:

> Preparing to unpack .../libopenmpi3_3.1.1.real-7_amd64.deb ...
> Unpacking libopenmpi3:amd64 (3.1.1.real-7) over (3.1.1.real-4+b1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libopenmpi3_3.1.1.real-7_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libpmix.so.2', which is also 
> in package libpmix2:amd64 3.0.1-1
> Errors were encountered while processing:
>  /var/cache/apt/archives/libopenmpi3_3.1.1.real-7_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Both libopenmpi3 and libpmix2 ship libpmix.so.2, but the replaces
relation in libopenmpi3 only applies to libpmix2 (<< 3.0.0-2).
Presumably the same error would occur if libpmix2 is upgraded after
libopenmpi3.

I've filed the bug against both packages, but please reassign it to the
one that needs fixing.

James



signature.asc
Description: OpenPGP digital signature

Bug#907032: Please compile against libaom

[James Cowgill]

Hi,

On 23/08/18 11:54, Wouter Verhelst wrote:
> On Thu, Aug 23, 2018 at 11:36:20AM +0200, Sebastian Ramacher wrote:
>> Control: block -1 by 905096
>>
>> On 2018-08-23 11:29:40, Wouter Verhelst wrote:
>>> libaom has not been packaged yet, however. Should an RFP be filed?
>>
>> That's #905096.
> 
> whoops; missed that, sorry -- probably because I was looking for
> "libaom" rather than "aom".
> 
> Ah well, glad it's being worked on then.

It's in NEW at the moment.

The packaging is on salsa if you want to try it out:
https://salsa.debian.org/multimedia-team/aom

James



signature.asc
Description: OpenPGP digital signature

Bug#906897: libavcodec58: does not support streaming videos

[James Cowgill]

Hi,

On 22/08/18 22:35, Vincent Lefevre wrote:
> On 2018-08-22 22:31:29 +0100, James Cowgill wrote:
>> Firefox 52 does not work with FFmpeg 4.0. You must upgrade either to
>> Firefox 61 or 60.1 ESR.
> 
> Something I cannot do because it no longer support session management
> extensions. :(

Yeah it's unfortunate those extensions don't work anymore.

This is the upstream commit if you want to try backporting it yourself,
however doing that will create a lot of work for you during updates etc.
https://hg.mozilla.org/mozilla-central/rev/573a198b7fdf

It seems unlikely to be backported in Debian because stretch doesn't
have FFmpeg 4.0 so firefox doesn't need to support it there.

James



signature.asc
Description: OpenPGP digital signature

Bug#906897: libavcodec58: does not support streaming videos

[James Cowgill]

Control: retitle -1 firefox-esr: does not work with ffmpeg 4.0
Control: reassign -1 firefox-esr 52.9.0esr-1
Control: close -1 60.1.0esr-1

On 22/08/18 01:16, Vincent Lefevre wrote:
> Package: libavcodec58
> Version: 7:4.0.2-1+b1
> Severity: important
> 
> Contrary to libavcodec57, libavcodec58 does not support streaming
> videos, such as: https://www.youtube.com/watch?v=7DtRPJ2crTA
> 
> Tested in Firefox 52.9.0.

Firefox 52 does not work with FFmpeg 4.0. You must upgrade either to
Firefox 61 or 60.1 ESR.

I've reassigned the bug to firefox-esr and closed it because it should
already be fixed in unstable. Hopefully firefox-esr 60.1 will migrate to
testing soon so it'll be fixed there as well.

James



signature.asc
Description: OpenPGP digital signature

Bug#872692: hgview fails to run

[James Cowgill]

Control: tags -1 sid buster fixed-upstream

Hi,

This is fixed upstream in 1.10.2 (or possibly earlier). It would be good
to get that version uploaded in Debian.

Also tagging "sid buster" because my understanding from the upstream fix
is that this is only broken with mercurial >= 4.3 (and stretch has 4.0).

James



signature.asc
Description: OpenPGP digital signature

Bug#905868: ffmpeg fails autopkgtest on ppc64el

[James Cowgill]

Control: reassign -1 gcc-8 8.2.0-3
Control: severity -1 normal
Control: retitle -1 gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el
Control: affects -1 src:ffmpeg
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731
Control: tags -1 upstream

Hi,

On 10/08/18 23:54, Simon Quigley wrote:
> Package: ffmpeg
> Severity: important
> 
> Attached is the most recent autopkgtest failure log against the new
> ffmpeg release in Ubuntu.

I managed to debug this issue during DebConf and I think it is a gcc-8
regression. I filed this upstream bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731

> I don't believe this is an Ubuntu-only issue.

The bug only happens when -O3 is passed and this only happens on Ubuntu
so this bug is Ubuntu specific. I suggest Ubuntu temporarily patches
ffmpeg to strip the -O3 option and pass -O2 instead. Alternatively you
could try rewriting the broken code (in libavcodec/ppc/fdctdsp.c) to
avoid the miscompilation.

James



signature.asc
Description: OpenPGP digital signature

Bug#882062: [debian-mysql] Bug#882062: Processed: mariadb-10.1: fix-FTBFS-on-GNU-Hurd.patch introduces buffer overflow in mariabackup

[James Cowgill]

Hi,

On 04/08/18 17:32, Otto Kekäläinen wrote:
> Control: tags -1 +moreinfo
> 
> James, can you please check if upstream applied the patch correctly
> and this issue can be closed, or if you think something additional
> still needs to be patched downstream here in Debian?

As far as I can tell, the fix is applied correctly to the 10.1, 10.2 and
10.3 upstream branches but is not yet part of any release.

In Debian, 10.1 is still affected, so I guess you can close this bug
with the next upstream version of 10.1.

The buggy patch was never applied to 10.3 in Debian.

James



signature.asc
Description: OpenPGP digital signature

Bug#905050: mpv: why does mpv tell it's built on unknown

[James Cowgill]

Hi,

On 01/08/18 03:16, shirish शिरीष wrote:
> On 31/07/2018, James Cowgill  wrote:
>> On 31/07/18 07:07, shirish शिरीष wrote:
>>> At times when I'm running a video, I get this ffmpeg warning -
>>>
>>> [ffmpeg] NULL: Failed to parse extradata
>>>
>>> and have no idea why that error triggrs.
>>
>> Probably a broken input file. Does this only happen for some files?
> 
> With quite a few more media files than I care to admit. It could be
> something that a newer encoder could fix when encoding a media file,
> dunno what. I'll try to see if somebody knows  a better de-bugging way
> so I know what's missing or broken and try to see if there is
> something that needs fixing.

Can you try playing the file with ffplay? If you get the same warning
then at least it's nothing to do with mpv.

=

Incidentally I notice this upstream PR which would remove the "built on
UNKNOWN" line and therefore fix the first part of the bug report:
https://github.com/mpv-player/mpv/pull/6046

Maybe they saw this bug :P

James



signature.asc
Description: OpenPGP digital signature

Bug#905096: ITP: aom -- AV1 Video Codec Library

[James Cowgill]

Package: wnpp
Severity: wishlist
Owner: James Cowgill 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: aom
  Version : 1.0.0
  Upstream Author : Alliance for Open Media
* URL : https://aomedia.org/
* License : BSD-2-Clause
  Programming Lang: C
  Description : AV1 Video Codec Library

AOMedia Video 1 (AV1) is an open and royalty free video encoding format
optimized for the Internet and the successor of VP9. aom is the
reference encoder and decoder implementation published by the Alliance
for Open Media.

I intend to maintain this package as part of the Debian Multimedia Team.

James



signature.asc
Description: OpenPGP digital signature

Bug#904163: ffmpeg: investigate the use of versioned provides in place of the alternative dependencies in shlibdeps

[James Cowgill]

Hi,

On 23/07/18 20:05, Reinhard Tartler wrote:
> ​Thanks for looking into this.
> 
> If the infrastructure is in place for this now, and there are upsides
> with this approach then I agree that this should be evaluated, and the
> results documented in this ticket. The thing is, I'm not sure I
> understand the upsides.

I've created this MR which implements this. Feel free to test it :)
https://salsa.debian.org/multimedia-team/ffmpeg/merge_requests/2

> Discoverability is indeed a concern. How are users supposed to know what
> to install in order to get the extra functionality? Will meta-packages
> (think libavcodec-extra) help with picking up the right package? Does
> this also work for package upgrades, or are there situations where APT
> might prefer to remove the -extra variants in favor for base variant?

I think the discoverability issue Mattia mentioned is not applicable
here because we're providing another concrete package? The meta-packages
have not changed, so installing the -extra variants works the same way
as it currently does. I've done some basic testing of upgrades and APT
seems to do the right thing. I haven't tested any complex situations though.

> My main concern with this proposal is the motivation behind it: To
> support 3rd party packages that have been compiled against a version of
> ffmpeg that is NOT found in Debian. I don't think this is something we
> should encourage. In the past, people have asked for help with the
> ffmpeg package and our reply is typically to replace 3rd party packages
> with the version found in Debian, which is frustrating, time-consuming
> and not in anyone's interest.

I have in fact been thinking about using versioned provides for some
time here because it seemed like the "correct" way to do it. The
advantages are mostly limited to simpler dependencies in rdeps. It also
has the small advantage of not requiring a package transition if an
-extra variant is added (although there are no plans for that).

I agree we should not encourage compiling debs against ffmpeg without
using the correct tools / packages. I don't think the fact that
implementing this would "help" people break the rules should count as a
negative point though.

> ​Dirk, I think the right course of action to get your jitsi backport
> working is to contact the supplier of the jitsi package, and ask them to
> recompile the package without the use of 3rd party package
> archives. Feel free to point them to this email.

For this specific situation this is the best thing to do. Also note that
when this bug is fixed, your issue won't be resolved because the package
would need recompiling for FFmpeg 4.0 anyway.

James



signature.asc
Description: OpenPGP digital signature

Bug#905050: mpv: why does mpv tell it's built on unknown

[James Cowgill]

Hi,

On 31/07/18 07:07, shirish शिरीष wrote:
> Package: mpv
> Version: 0.29.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I was running -
[...]
> 
> what kinda stuck me mpv saying -
> 
> [cplayer]  built on UNKNOWN and that info. seems to indicate something
> is wrong.

This is because we build mpv with --disable-build-date for reproducible
builds so the build date is "UNKNOWN". Probably it would be nicer if
that line was completely omitted.

> At times when I'm running a video, I get this ffmpeg warning -
> 
> [ffmpeg] NULL: Failed to parse extradata
> 
> and have no idea why that error triggrs.

Probably a broken input file. Does this only happen for some files?

James



signature.asc
Description: OpenPGP digital signature

Bug#898575: In-memory cache grows almost without bound

[James Cowgill]

Hi,

On 30/07/18 19:11, Juliusz Chroboczek wrote:
>> I think I agree that the manpage needs some clarification to note that
>> the --cache option only affects the stream cache.
> 
>> In the meantime I uploaded mpv 0.29 which has adjusted the cache sizes a
>> bit (although the behavior of --cache has not changed). Can you see if
>> it has improved the situation?
> 
> My situation is somewhat unusal -- I'm streaming from a local server that
> acts as a proxy, so I want to minimise prefetching (to avoid using up
> server resources).  I doubt that the default configuration will suit me,
> but that's okay.
> 
> What's not okay is that with older versions, I could simply tell my users
> to run mpv with "--cache no".  With the new version, I'm going to have to
> ship a script.

I think (through some experimentation) that "--cache=no --cache-secs=10"
will work on 0.29 and 0.27 giving the same behavior as "--cache=no" did
on 0.27.

James



signature.asc
Description: OpenPGP digital signature

Bug#898575: In-memory cache grows almost without bound

[James Cowgill]

Hi,

On 27/07/18 00:57, Juliusz Chroboczek wrote:
>> That's correct. The --cache option only affects the stream cache (which
>> is correctly disabled by that option). The issue here was the size of
>> the demuxer cache (which caches already demuxed packets).
> 
> This is completely unintuitive, and undocumented.  From the manual page:
> 
>--cache=
>   Set the size of the cache in kilobytes, disable it with  no,  or
>   automatically  enable  it  if  needed with auto (default: auto).
> 
> The manual page needs fixing, at the very least.

I think I agree that the manpage needs some clarification to note that
the --cache option only affects the stream cache.

In the meantime I uploaded mpv 0.29 which has adjusted the cache sizes a
bit (although the behavior of --cache has not changed). Can you see if
it has improved the situation?

James



signature.asc
Description: OpenPGP digital signature

Bug#904874: libopenmpt: Crash with some malformed custom tunings in MPTM files

[James Cowgill]

Source: libopenmpt
Version: 0.2.7025~beta20.1-1
Severity: important
Tags: upstream

A new version of libopempt 0.3.11 was released with a security fix:
https://lib.openmpt.org/libopenmpt/2018/07/28/security-updates-0.3.11-0.2.10635-beta34-0.2.7561-beta20.5-p10-0.2.7386-beta20.3-p13/

From SVN log:
[Fix] Tuning: Fix integer overflow and division by zero in
GetRatio()/GetRatioFine() with out-of-range m_FineStepCount caused by
malformed files (caught with afl-fuzz).

AFAIKT this is denial of service only, so keeping the severity at important.

James



signature.asc
Description: OpenPGP digital signature

Bug#904821: mbedtls: CVE-2018-0497, CVE-2018-0498: Remote plaintext recovery on use of CBC based ciphersuites through a timing side-channel

[James Cowgill]

Source: mbedtls
Version: 2.1.2-1
Severity: grave
Tags: security upstream

This security advisory was published for mbedTLS. All versions since 1.2
are affected.

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-02

CVE-2018-0497:
Remote plaintext recovery on use of CBC based ciphersuites through a
timing side-channel

CVE-2018-0498:
Plaintext recovery on use of CBC based ciphersuites through a cache
based side-channel

James



signature.asc
Description: OpenPGP digital signature

Bug#904620: mpv: opening movie from sftp:// in nautilus does not work

[James Cowgill]

Control: forwarded -1 https://github.com/mpv-player/mpv/issues/6024

Hi,

On 26/07/18 04:25, Jan Gerber wrote:
> Package: mpv
> Version: 0.28.2-3
> Severity: normal
> 
> Dear Maintainer,
> 
> opening a video on an sftp:// share in nautilus does not work.
> double clicking on .mp4 file with mpv as default handler fails.
> 
> (the path contains spaces, escaped as %20 by nautilus in sftp urls)
> 
> mpv should use the gvfs path (/run/user/.../gvfs/sftp:...) or support 
> %20/quoted paths in sftp urls.

I've forwarded this upstream here which you can monitor if you want:
https://github.com/mpv-player/mpv/issues/6024

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#898575: In-memory cache grows almost without bound

[James Cowgill]

Hi,

On 26/07/18 08:12, Juliusz Chroboczek wrote:
>> My understanding is that this was an intentional change.
> 
> Please read the bug report again.  Using --cache=no does *not* limit the
> cache.

That's correct. The --cache option only affects the stream cache (which
is correctly disabled by that option). The issue here was the size of
the demuxer cache (which caches already demuxed packets). This cache is
not affected by the --cache option. Upstream enabled this cache and set
it to a very large size. This was reduced in 0.29 thus mitigating the issue.

James



signature.asc
Description: OpenPGP digital signature

Bug#904282: llvm-defaults: add liblldb-dev package

[James Cowgill]

Source: llvm-defaults
Version: 0.41
Severity: wishlist

Hi,

Please add a liblldb-dev package which depends on liblldb-X.X-dev. This
would allow codelite to depend only on the unversioned packages from
llvm-defaults and relieve the need for a source upload every time the
default LLVM version changes.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#904267: zoneminder: FTBFS with FFmpeg 4.0

[James Cowgill]

Source: zoneminder
Version: 1.30.4+dfsg1-4
Severity: serious
Tags: sid buster ftbfs
User: debian-multime...@lists.debian.org
Usertags: ffmpeg-4.0-transition
Control: block 896893 by -1

Hi,

zoneminder FTBFS with FFmpeg 4.0 which was recently uploaded to
unstable. Unfortunately the last rebuild I did was before #887968 was
fixed so I never caught this package before the transition started.

Build log:
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:243:19: error: 
> 'CODEC_FLAG_QSCALE' was not declared in this scope
>c->flags |= CODEC_FLAG_QSCALE;
>^
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:243:19: note: suggested 
> alternative: 'AV_CODEC_FLAG_QSCALE'
>c->flags |= CODEC_FLAG_QSCALE;
>^
>AV_CODEC_FLAG_QSCALE
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:268:19: error: 
> 'CODEC_FLAG_GLOBAL_HEADER' was not declared in this scope
>c->flags |= CODEC_FLAG_GLOBAL_HEADER;
>^~~~
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:268:19: note: suggested 
> alternative: 'AV_CODEC_FLAG_GLOBAL_HEADER'
>c->flags |= CODEC_FLAG_GLOBAL_HEADER;
>^~~~
>AV_CODEC_FLAG_GLOBAL_HEADER
[...]
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:428:22: error: 
> 'AVFMT_RAWPICTURE' was not declared in this scope
>if ( !(of->flags & AVFMT_RAWPICTURE) )
>   ^~~~
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:428:22: note: suggested 
> alternative: 'AVFMT_NOFILE'
>if ( !(of->flags & AVFMT_RAWPICTURE) )
>   ^~~~
>   AVFMT_NOFILE
[...]
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:675:20: error: 
> 'AVFMT_RAWPICTURE' was not declared in this scope
>if ( of->flags & AVFMT_RAWPICTURE )
> ^~~~
> Manifying 21 pod documents
> /<>/zoneminder-1.30.4+dfsg1/src/zm_mpeg.cpp:675:20: note: suggested 
> alternative: 'AVFMT_NOFILE'
>if ( of->flags & AVFMT_RAWPICTURE )
> ^~~~
> AVFMT_NOFILE

UNTESTED patch I found on FreeBSD ports attached. From here:
https://svnweb.freebsd.org/ports/head/multimedia/zoneminder/files/patch-ffmpeg4?view=markup

James
Partially based on https://github.com/ZoneMinder/zoneminder/commit/e17bcb9178d0

--- src/zm_mpeg.cpp.orig	2017-05-09 14:54:48 UTC
+++ src/zm_mpeg.cpp
@@ -240,7 +240,11 @@ void VideoStream::SetupCodec( int colours, int subpixe
 {
   // Quality based bitrate control (VBR). Scale is 1..31 where 1 is best.
   // This gets rid of artifacts in the beginning of the movie; and well, even quality.
+#if LIBAVCODEC_VERSION_CHECK(56, 35, 0, 64, 0)
+  c->flags |= AV_CODEC_FLAG_QSCALE;
+#else
   c->flags |= CODEC_FLAG_QSCALE;
+#endif
   c->global_quality = FF_QP2LAMBDA * (31 - (31 * (bitrate / 100.0)));
 }
 else
@@ -265,7 +269,11 @@ void VideoStream::SetupCodec( int colours, int subpixe
 
 // some formats want stream headers to be separate
 if ( of->flags & AVFMT_GLOBALHEADER )
+#if LIBAVCODEC_VERSION_CHECK(56, 35, 0, 64, 0)
+  c->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
+#else
   c->flags |= CODEC_FLAG_GLOBAL_HEADER;
+#endif
   }
   else
   {
@@ -425,7 +433,9 @@ void VideoStream::OpenStream( )
   }
 
   video_outbuf = NULL;
+#if !LIBAVFORMAT_VERSION_CHECK(57, 0, 0, 0, 0)
   if ( !(of->flags & AVFMT_RAWPICTURE) )
+#endif
   {
 /* allocate output buffer */
 /* XXX: API change will be done */
@@ -672,6 +682,7 @@ double VideoStream::ActuallyEncodeFrame( const uint8_t
   AVPacket *pkt = packet_buffers[packet_index];
   av_init_packet( pkt );
   int got_packet = 0;
+#if !LIBAVFORMAT_VERSION_CHECK(57, 0, 0, 0, 0)
   if ( of->flags & AVFMT_RAWPICTURE )
   {
 #if LIBAVCODEC_VERSION_CHECK(52, 30, 2, 30, 2)
@@ -685,6 +696,7 @@ double VideoStream::ActuallyEncodeFrame( const uint8_t
 got_packet = 1;
   }
   else
+#endif
   {
 opicture_ptr->pts = c->frame_number;
 opicture_ptr->quality = c->global_quality;
--- src/zm_sdp.cpp.orig	2017-05-09 14:54:48 UTC
+++ src/zm_sdp.cpp
@@ -483,7 +483,11 @@ AVFormatContext *SessionDescriptor::generateFormatCont
   uint8_t *dest = 
   (uint8_t *)av_malloc(packet_size + sizeof(start_sequence) +
stream->codec->extradata_size +
+#if LIBAVCODEC_VERSION_CHECK(57, 0, 0, 0, 0)
+   AV_INPUT_BUFFER_PADDING_SIZE);
+#else
FF_INPUT_BUFFER_PADDING_SIZE);
+#endif
   if(dest) {
   if(stream->codec->extradata_size) {
 // av_realloc?
@@ -494,7 +498,11 @@ AVFormatContext *SessionDescriptor::generateFormatCont
   memcpy(dest+stream->codec->extradata_size, start_sequence, sizeof(start_sequence));
   memcpy(dest+stream->codec->extradata_size+sizeof(start_sequence), decoded_packet, packet_size);
   

Bug#848165: freeciv-client-qt: crash at exit ...leavegame->quit

[James Cowgill]

Hi,

On 22/07/18 11:51, Jacob Nevins wrote:
> Marko Lindqvist wrote (Dec 2016):
>>  As the crash is in atexit handlers when the program is closed, this
>> seems like upstream bug #25364: http://gna.org/bugs/?25364
> 
> gna.org has gone away, but the Internet Archive captured the final state
> of this ticket, which is that nothing has been done upstream to address
> this. We have no ticket for it in our current tracker.
> 
> 
> The conversation in Gna indicated that this was some interaction with
> distro defaults, rather than a simple upstream bug:
> 
> mir3x:
> | I prepared 3 patchs, try if any of them works.
> | It just crashes at destructor of static QString, no idea why, but I saw
> | similar reports when qt was built for wrong arch.
> 
> mir3x:
> | ML can u check with gcc -v if your gcc has --enable-__cxa_atexit ?
> | If no then it must be that issue.
> 
> Marko: [gcc -v output, presumably from Debian testing, not including
> --enable-__cxa_atexit]
> 
> mir3x:
> | "--enable-__cxa_atexit" is required for the G++ compiler to produce
> | static destructors that fully comply with the C++ specification.
> | So p1.patch might work.
> | But its probably some debian bug, all static c++ classes will segfault.
> 
> I've attached the 'p1.patch' referred to, rescued from gna.org. I don't
> have any record that anyone tried it.

Not sure about the cause of this bug, but --enable-__cxa_atexit has been
enabled by default in gcc for over 10 years now (see gcc/config.gcc in
the gcc source). I doubt the bug is related to that.

A total guess, but most of the "crash at exit" bugs I've seen were
caused by some memory corruption during program execution which is only
highlighted when the destructors are run.

James



signature.asc
Description: OpenPGP digital signature

Bug#904052: ffmpeg: FTBFS on hurd-i386: wrong value for --target-os at configure

[James Cowgill]

Hi,

On 18/07/18 22:18, Pino Toscano wrote:
> Source: ffmpeg
> Version: 7:4.0-3
> Severity: important
> Tags: patch
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> Hi,
> 
> ffmpeg fails to build on hurd-i386 [1].
> 
> Since version 7:4.0-3 (commit d3d378eb963734f2d330754300a63eb440f2d676
> in the packaging Git) --target-os is passed in all the cases to
> configure, using $DEB_HOST_ARCH_OS as value.  The problem is that
> configure expects for --target-os a (lowercase) value among the
> possible ones returned by `uname -s`, which is "GNU" for Hurd.  OTOH,
> $DEB_HOST_ARCH for hurd-* archs is "hurd", and thus configure fails
> with "Unknown OS".
> 
> Attached there is a patch to use a custom variable for --target-os,
> using the mapping needed (so far for hurd-* only).

I think I'll just move the --target-os option back into the cross
compilation block which will at least fix the native build. In the above
commit it was only the --arch option which was important to always specify.

Maybe upstream FFmpeg could be taught to accept "hurd" as an alternate
name for "gnu" in --target-os?

Jame



signature.asc
Description: OpenPGP digital signature

Bug#904052: ffmpeg: FTBFS on hurd-i386: wrong value for --target-os at configure

[James Cowgill]

Hi,

On 21/07/18 17:26, Pino Toscano wrote:
> In data sabato 21 luglio 2018 17:59:13 CEST, James Cowgill ha scritto:
>> Maybe upstream FFmpeg could be taught to accept "hurd" as an alternate
>> name for "gnu" in --target-os?
> 
> I'm not sure about this: since the default value is taken from the
> output of $(uname -s), that returns "GNU" and not "hurd". I'd be like
> adding eg "gnulinux" as alternate name for "linux", which IMHO does not
> make sense.

I'm asking on the basis that upstream FFmpeg already accepts Debian's
architecture names in the --arch option (even though they're different
to the output of uname -m). It would be nice if it also accept Debian's
architecture names for --target-os as well.

James



signature.asc
Description: OpenPGP digital signature

Bug#904178: ffmpeg: fix mips r6 build

[James Cowgill]

Control: notfound -1 4.0.1-2
Control: found -1 7:4.0.1-2

Hi Yunqiang,

On 21/07/18 05:46, YunQiang Su wrote:
> Package: src:ffmpeg
> Version: 4.0.1-2
> 
> We are working on MIPS r6 ports.
> 
> Please change the lines about mips options in debian/rules to the below.
> # Disable some optimizations on mips*, because they are not always
> available on these architectures
> ifneq (,$(filter mips%r6 mips%r6el, $(DEB_HOST_ARCH)))
> MIPS_NO_R6_OPTION = --disable-mips32r2 \
> --disable-mips64r2 \
> --disable-mips32r5

Is this line intentional (given that --disable-mips32r5 is used below as
well)?

I don't think the name of that variable explains itself very well,
especially since one of the options enables R6. Maybe MIPS_R2_R6_CONFIG
is better?

James



signature.asc
Description: OpenPGP digital signature

Bug#904163: libavcodec-extra57 should PROVIDE package libavcodec57

[James Cowgill]

Control: tags -1 - moreinfo

Hi,

On 21/07/18 16:23, Mattia Rizzolo wrote:
> On Sat, Jul 21, 2018 at 02:41:32PM +0100, James Cowgill wrote:
>> If versioned provides was working properly everywhere then
>> possibly it could be used, but I don't think it does yet (although I'm
>> happy to be corrected!).
> 
> They do.  In the past 2 years many bugs around the infrastructure were
> fixed and versioned provides can now be fully used (in particular, there
> were some last pieces regarding wanna-build and britney, that have been
> fixed ~1 year ago IIRC).
> 
> The only thing is that they may be confusing to some, as it's not so
> straightforward to find a virtual package compared to a plain `apt show`
> :>

OK thanks. I'll see what I can do about this after the ffmpeg 4.0
transition has completed.

James



signature.asc
Description: OpenPGP digital signature

Bug#904178: ffmpeg: fix mips r6 build

[James Cowgill]

Hi,

On 21/07/18 16:38, YunQiang Su wrote:
> James Cowgill  于2018年7月21日周六 下午11:16写道：
>> On 21/07/18 05:46, YunQiang Su wrote:
>>> Please change the lines about mips options in debian/rules to the below.
>>> # Disable some optimizations on mips*, because they are not always
>>> available on these architectures
>>> ifneq (,$(filter mips%r6 mips%r6el, $(DEB_HOST_ARCH)))
>>> MIPS_NO_R6_OPTION = --disable-mips32r2 \
>>> --disable-mips64r2 \
>>> --disable-mips32r5
>>
>> Is this line intentional (given that --disable-mips32r5 is used below as
>> well)?
>>
> 
> yes. when the first try, I don't add --disable-mips32r5, then it
> failed to build,
> when link r2/r6 objects.

I still don't understand. In your new code, the --disable-mips32r5
option is passed unconditionally in the main config block so this extra
option in the r6 block should have no effect.

>> I don't think the name of that variable explains itself very well,
>> especially since one of the options enables R6. Maybe MIPS_R2_R6_CONFIG
>> is better?

James



signature.asc
Description: OpenPGP digital signature

Bug#904163: libavcodec-extra57 should PROVIDE package libavcodec57

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 20/07/18 23:14, Dirk Lehmann wrote:
> Package: libavcodec-extra57
> Version: 7:3.4.3-1
> Severity: normal
> Tags: d-i
> 
> Dear Maintainer,
> 
> I try to install a backport package which is depending on package
> 'libavcodec57'.  But I have installed the package libavcodec-extra57
> on my machine.  If I try to install it, I get the following error:
> 
> --
> root$> apt-get install jitsi
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 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:
>  jitsi : Depends: libavcodec57 but it is not going to be installed or
>   libavcodec-ffmpeg56 but it is not installable
> E: Unable to correct problems, you have held broken packages.
> --

Where is this package from? There is no "jitsi" in Debian (anymore) so
it must be unofficial. When packages are built against ffmpeg they
should get a dependency like this which should work with libavcodec-extra:
 libavcodec57 (>= 7:3.4.3) | libavcodec-extra57 (>= 7:3.4.3)

Probably the jitsi packages itself is at fault, or something else is
preventing the installation.

> I'm not really familiar with DPKG, but I think it could be solved if
> the manifest of dpkg-archive from 'libavcodec-extra57' includes a
> 
> --
> [...]
> Provides: libavcodec57
> [...]
> --

Unfortunately this won't work because it won't satisfy versioned
dependencies. If versioned provides was working properly everywhere then
possibly it could be used, but I don't think it does yet (although I'm
happy to be corrected!).

James



signature.asc
Description: OpenPGP digital signature

Bug#904123: mpv: Screenshot always crashes with Segmentation fault

[James Cowgill]

Control: reassign -1 src:ffmpeg 7:3.4.3-1
Control: found -1 7:3.2.11-1~deb9u1
Control: fixed -1 7:4.0-1
Control: tags -1 fixed-upstream

Hi,

On 21/07/18 14:54, S Andreason wrote:
> James Cowgill wrote:
>> Can you confirm that it's this bug you're seeing?
>> https://github.com/mpv-player/mpv/issues/5989
>>
>> The segfault should only happen for PNG screenshots and not JPEG
>> screenshots.
>>
>> If so then yes it's an FFmpeg bug. It should be fixed when 3.2.12 is
>> uploaded. AFAIKT, 3.4.3 in testing is also affected, but the 4.0 branch
>> (including 4.0.1 in unstable) is not.
>>
>>
> 
> Hi James,
> Yes my backtrace looks like the same bug.
> 
> Thread 1 "mpv" received signal SIGSEGV, Segmentation fault.
> 0xb6ea4240 in avcodec_find_best_pix_fmt_of_list ()
>    from /usr/lib/i386-linux-gnu/libavcodec.so.57
> (gdb) bt
> #0  0xb6ea4240 in avcodec_find_best_pix_fmt_of_list ()
>    from /usr/lib/i386-linux-gnu/libavcodec.so.57
> #1  0x004c3bbd in ?? ()
> 
> No debug symbols installed to see anything further.
> Thank you for the info. Is there anyplace I can visit to see current
> status, or expected time for updates?

Thanks.

This page has most of the public information about ffmpeg (although it's
geared up for developers):
https://tracker.debian.org/pkg/ffmpeg

There isn't really an expected time for the update. It will get updated
when I get around to preparing the update and the security team
processes it.

James



signature.asc
Description: OpenPGP digital signature

Bug#904123: mpv: Screenshot always crashes with Segmentation fault

[James Cowgill]

Hi,

On 20/07/18 06:06, Stewart Andreason wrote:
> Package: mpv
> Version: 0.23.0-2+deb9u2
> Severity: important
> 
> Dear Maintainer,
> 
> Pressing [s] to take a screenshot always crashes with Segmentation fault.
> I see this bug is reported for 0.27.2 over on github.
> There is supposed to be a fix backported to ffmpeg-3.2
> How long until debian-stable gets it?

Can you confirm that it's this bug you're seeing?
https://github.com/mpv-player/mpv/issues/5989

The segfault should only happen for PNG screenshots and not JPEG
screenshots.

If so then yes it's an FFmpeg bug. It should be fixed when 3.2.12 is
uploaded. AFAIKT, 3.4.3 in testing is also affected, but the 4.0 branch
(including 4.0.1 in unstable) is not.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888353: moc: FTBFS with FFmpeg 4.0

[James Cowgill]

Hi,

On 19/07/18 18:05, Elimar Riesebieter wrote:
> * James Cowgill  [2018-07-17 11:36 +0100]:
>> On Mon, 28 May 2018 20:24:23 +0100 James Cowgill 
>> wrote:
>>> On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
>>>> Your package FTBFS with the upcoming version 3.5 of FFmpeg.
>>>
>>> The attached patch fixes this.
>>
>> I've uploaded the attached NMU (based on my previously posted patch) to
>> DELAYED/5. Please tell me if I should cancel it.
> 
> It seems that your patch doesn't build. Check the logs at [0].
> 
> [0] https://buildd.debian.org/status/package.php?p=moc=unstable

My patch hasn't been uploaded to unstable yet, so you can ignore those
logs. It's still in deferred [1,2].

[1] https://ftp-master.debian.org/deferred.html
[2] https://ftp-master.debian.org/deferred/

> I can prepare a tuned patch with upstream over the weekend and upload
> next week via mentors.debian.net.

Do you want me to cancel my NMU? Can I just upload it now?

James



signature.asc
Description: OpenPGP digital signature

Bug#888353: moc: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 pending

Hi,

On Mon, 28 May 2018 20:24:23 +0100 James Cowgill 
wrote:
> Control: tags -1 patch
> 
> Hi,
> 
> On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> > Source: moc
> > Version: 1:2.6.0~svn-r2949-2
> > Severity: important
> > User: debian-multime...@lists.debian.org
> > Usertags: ffmpeg-3.5-transition
> > 
> > Hi,
> > 
> > Your package FTBFS with the upcoming version 3.5 of FFmpeg.
> 
> The attached patch fixes this.

I've uploaded the attached NMU (based on my previously posted patch) to
DELAYED/5. Please tell me if I should cancel it.

James
diff -Nru moc-2.6.0~svn-r2949/debian/changelog 
moc-2.6.0~svn-r2949/debian/changelog
--- moc-2.6.0~svn-r2949/debian/changelog2017-06-19 20:45:41.0 
+0100
+++ moc-2.6.0~svn-r2949/debian/changelog2018-07-17 11:20:03.0 
+0100
@@ -1,3 +1,10 @@
+moc (1:2.6.0~svn-r2949-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Fix FTBFS with FFmpeg 4.0. (Closes: #888353)
+
+ -- James Cowgill   Tue, 17 Jul 2018 11:20:03 +0100
+
 moc (1:2.6.0~svn-r2949-2) unstable; urgency=medium
 
   * Set LC_MESSAGES=en_DK.utf8 to generate upstreams changelog via svn log.
diff -Nru moc-2.6.0~svn-r2949/debian/patches/05_ffmpeg4.patch 
moc-2.6.0~svn-r2949/debian/patches/05_ffmpeg4.patch
--- moc-2.6.0~svn-r2949/debian/patches/05_ffmpeg4.patch 1970-01-01 
01:00:00.0 +0100
+++ moc-2.6.0~svn-r2949/debian/patches/05_ffmpeg4.patch 2018-07-17 
11:19:42.00000 +0100
@@ -0,0 +1,36 @@
+Description: Fix FTBFS with FFmpeg 4.0
+Author: James Cowgill 
+Bug-Debian: https://bugs.debian.org/888353
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/decoder_plugins/ffmpeg/ffmpeg.c
 b/decoder_plugins/ffmpeg/ffmpeg.c
+@@ -697,7 +697,7 @@ static void *ffmpeg_open_internal (struc
+* FFmpeg/LibAV in use.  For some versions this will be caught in
+* *_find_stream_info() above and misreported as an unfound codec
+* parameters error. */
+-  if (data->codec->capabilities & CODEC_CAP_EXPERIMENTAL) {
++  if (data->codec->capabilities & AV_CODEC_CAP_EXPERIMENTAL) {
+   decoder_error (>error, ERROR_FATAL, 0,
+   "The codec is experimental and may damage MOC: 
%s",
+   data->codec->name);
+@@ -705,8 +705,8 @@ static void *ffmpeg_open_internal (struc
+   }
+ 
+   set_downmixing (data);
+-  if (data->codec->capabilities & CODEC_CAP_TRUNCATED)
+-  data->enc->flags |= CODEC_FLAG_TRUNCATED;
++  if (data->codec->capabilities & AV_CODEC_CAP_TRUNCATED)
++  data->enc->flags |= AV_CODEC_FLAG_TRUNCATED;
+ 
+   if (avcodec_open2 (data->enc, data->codec, NULL) < 0)
+   {
+@@ -725,7 +725,7 @@ static void *ffmpeg_open_internal (struc
+ 
+   data->sample_width = sfmt_Bps (data->fmt);
+ 
+-  if (data->codec->capabilities & CODEC_CAP_DELAY)
++  if (data->codec->capabilities & AV_CODEC_CAP_DELAY)
+   data->delay = true;
+   data->seek_broken = is_seek_broken (data);
+   data->timing_broken = is_timing_broken (data->ic);
diff -Nru moc-2.6.0~svn-r2949/debian/patches/series 
moc-2.6.0~svn-r2949/debian/patches/series
--- moc-2.6.0~svn-r2949/debian/patches/series   2017-06-19 20:45:41.0 
+0100
+++ moc-2.6.0~svn-r2949/debian/patches/series   2018-07-17 11:20:03.0 
+0100
@@ -1,3 +1,4 @@
 0001-Refreshed-opus-patch-from-Tomasz-Golinski-tomaszg-al.patch
 0002-Adapted-the-opus-patch-to-config.example.in.patch
 04_playtime_perc.patch
+05_ffmpeg4.patch


signature.asc
Description: OpenPGP digital signature

Bug#890205: closed by James Cowgill (Re: Bug#890205: [mpv] relocation error)

[James Cowgill]

Hi,

On 16/07/18 20:40, Paolo Redaelli wrote:
> I beg your pardon, I missed your reply! :(
> I just updated it
> 
> There they are, after an "apt update;apt install mpv"
> 
> dpkg -l libavfilter6 libavutil55
> 
> ii  libavfilter6:amd64   7:3.4.2-2+b1    amd64   FFmpeg library
> containing media filters - runt
> ii  libavutil55:amd64    10:3.2.2-dmo3   amd64   FFmpeg avutil
> library - runtime files

You have a non-Debian version of libavutil55 installed from
deb-multimedia.org. Please reinstall Debian's version and try again.

> ffmpeg works correctly
> 
> paolo@rigel:~$ ffmpeg -version
> ffmpeg version 2.8.1 Copyright (c) 2000-2015 the FFmpeg developers
> built with gcc 5.2.1 (Debian 5.2.1-22) 20151010

It also looks like you have a custom (and very old) version of ffmpeg
installed, but I think this is unrelated to the issue with mpv.

James



signature.asc
Description: OpenPGP digital signature

Bug#895463: keyutils FTBFS: Can't Determine Endianness

[James Cowgill]

Control: tags -1 pending

Hi,

I've uploaded the attached debdiff which fixes this bug. While I was
preparing the upload, I also migrated the git repository from alioth to
salsa.

James
diff -Nru keyutils-1.5.9/debian/changelog keyutils-1.5.9/debian/changelog
--- keyutils-1.5.9/debian/changelog 2017-11-16 12:19:11.0 +
+++ keyutils-1.5.9/debian/changelog 2018-07-16 09:53:06.0 +0100
@@ -1,3 +1,12 @@
+keyutils (1.5.9-9.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control: Migrate Vcs repository to salsa.d.o.
+  * d/patches: Add endianness-and-PIE.patch to fix FTBFS.
+Thanks to Steve Langasek and Adam Conrad (Closes: #895463)
+
+ -- James Cowgill   Mon, 16 Jul 2018 09:53:06 +0100
+
 keyutils (1.5.9-9.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru keyutils-1.5.9/debian/control keyutils-1.5.9/debian/control
--- keyutils-1.5.9/debian/control   2017-09-28 13:12:55.0 +0100
+++ keyutils-1.5.9/debian/control   2018-07-16 09:52:48.0 +0100
@@ -7,8 +7,8 @@
 lsb-release,
 Standards-Version: 3.9.8
 Homepage: http://people.redhat.com/~dhowells/keyutils/
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/keyutils.git
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/keyutils.git
+Vcs-Git: https://salsa.debian.org/debian/keyutils.git
+Vcs-Browser: https://salsa.debian.org/debian/keyutils
 
 Package: keyutils
 Architecture: linux-any
diff -Nru keyutils-1.5.9/debian/patches/endianness-and-PIE.patch 
keyutils-1.5.9/debian/patches/endianness-and-PIE.patch
--- keyutils-1.5.9/debian/patches/endianness-and-PIE.patch  1970-01-01 
01:00:00.0 +0100
+++ keyutils-1.5.9/debian/patches/endianness-and-PIE.patch  2018-07-16 
09:51:51.0 +0100
@@ -0,0 +1,23 @@
+Description: fix regexp match against `file /proc/$$/exe` for -fPIE bash
+ Now that bash is built with PIE enabled, keyutils' check for endianness
+ fails because file no longer returns "executable", but instead returns
+ "shared object" for file << 5.33 and "pie executable" for file >= 5.33.
+Author: Steve Langasek 
+Author: Adam Conrad 
+Last-Modified: 2018-05-07
+
+--- a/tests/toolbox.inc.sh
 b/tests/toolbox.inc.sh
+@@ -19,10 +19,10 @@ includes=${includes%/*}/
+ echo === $OUTPUTFILE ===
+ 
+ endian=`file -L /proc/$$/exe`
+-if expr "$endian" : '.* MSB executable.*' >&/dev/null
++if expr "$endian" : '.* MSB \(executable\|shared object\|pie executable\).*' 
>&/dev/null
+ then
+ endian=BE
+-elif expr "$endian" : '.* LSB executable.*' >&/dev/null
++elif expr "$endian" : '.* LSB \(executable\|shared object\|pie 
executable\).*' >&/dev/null
+ then
+ endian=LE
+ else
diff -Nru keyutils-1.5.9/debian/patches/series 
keyutils-1.5.9/debian/patches/series
--- keyutils-1.5.9/debian/patches/series2017-09-28 13:12:55.0 
+0100
+++ keyutils-1.5.9/debian/patches/series2018-07-16 09:51:51.0 
+0100
@@ -16,3 +16,4 @@
 Make-build-reproducible.patch
 Drop-tests-requiring-CONFIG_BIG_KEYS.patch
 Adjust-tests-for-3.18-kernel-change.patch
+endianness-and-PIE.patch


signature.asc
Description: OpenPGP digital signature

Bug#903610: mpv: FTBFS with python 3.7 as the default python3

[James Cowgill]

Source: mpv
Version: 0.27.2-1
Severity: important
Forwarded: https://github.com/mpv-player/mpv/issues/5958
Control: found -1 0.28.2-1

As reported upstream in the above bug, mpv will FTBFS when python 3.7 is
made the default version of python.

MPV fix attempt (upgrading waf):
https://github.com/mpv-player/mpv/pull/5975

Waf commit which fixes this:
https://gitlab.com/ita1024/waf/commit/facdc0b173d933073832c768ec1917c553cb369c

Reverting the build system to python2 should also fix this.

James



signature.asc
Description: OpenPGP digital signature

Bug#901784: libmypaint-1.3-0: Can't install libmypaint-1.3-0

[James Cowgill]

Hi,

Sorry I accidentally sent the last email by mistake before it was finished.

On 18/06/18 14:35, José Couto wrote:
> Sorry, I forgot to cc bugs.debian.org .
> 
> Hi, James. Thank you for your help.
[...]
> I can't install libmypaint-common by hand either:
> 
> ###
> # apt-get -o Debug::pkgProblemResolver=yes install libmypaint-commo
> n  
> 
> Reading package lists... Done 
> Building dependency tree        
> Reading state information... Done 
> Package libmypaint-common is not available, but is referred to by
> another packag
> e. 
> This may mean that the package is missing, has been obsoleted, or 
> is only available from another source 
> 
> E: Package 'libmypaint-common' has no installation candidate
> ###

As I said I don't know what's wrong here. That package should exist and
does exist in the main package lists and on my machine.

Maybe try running "apt update" again?
What's in your /etc/apt/sources.list?

James



signature.asc
Description: OpenPGP digital signature

Bug#901784: libmypaint-1.3-0: Can't install libmypaint-1.3-0

[James Cowgill]

Hi,

On 18/06/18 14:35, José Couto wrote:
> Sorry, I forgot to cc bugs.debian.org <http://bugs.debian.org>.
> 
> Hi, James. Thank you for your help.
[...]
> I can't install libmypaint-common by hand either:
> 
> ###
> # apt-get -o Debug::pkgProblemResolver=yes install libmypaint-commo
> n  
> 
> Reading package lists... Done 
> Building dependency tree        
> Reading state information... Done 
> Package libmypaint-common is not available, but is referred to by
> another packag
> e. 
> This may mean that the package is missing, has been obsoleted, or 
> is only available from another source 
> 
> E: Package 'libmypaint-common' has no installation candidate
> ###

I'm not sure what's going on here. Maybe your APT cache is corrupt somehow?

> 
> mypaint-data is not installed in my computer:
> 
> ###
> # dpkg -l mypaint-data 
> dpkg-query: no packages found matching mypaint-data
> ###
> 
> Regards.
> 
> 
> On Mon, Jun 18, 2018 at 2:02 PM James Cowgill  <mailto:jcowg...@debian.org>> wrote:
> 
> Hi,
> 
> On 18/06/18 12:19, Coque Couto wrote:
> > Package: libmypaint-1.3-0
> > Severity: grave
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> > libmypaint-1.3-0 package seems to be broken. Trying to install gimp
> > reports the following error:
> [...]
> > It seems that libmypaint-common is not installable:
> >
> > ###
> > # apt install libmypaint-1.3-0
> > Reading package lists... Done
> > Building dependency tree       
> > Reading state information... Done
> > 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:
> >  libmypaint-1.3-0 : Depends: libmypaint-common (>= 1.3.0-2) but it
> is not installable
> > E: Unable to correct problems, you have held broken packages.
> > ###
> 
> I can't reproduce this. Can you run apt with the problem solver enabled
> and paste the log?
> 
> # apt-get -o Debug::pkgProblemResolver=yes install libmypaint-1.3-0
> 
> Do you have mypaint-data installed? If so, this is probably a duplicate
> of #894757.
> 
> James
> 

Bug#896824: ignition-common: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 patch fixed-upstream

Hi,

On Tue, 24 Apr 2018 16:26:55 +0100 James Cowgill 
wrote:
> Source: ignition-common
> Version: 1.0.1-1
> Severity: important
> User: debian-multime...@lists.debian.org
> Usertags: ffmpeg-4.0-transition
> 
> Hi,
> 
> Your package FTBFS with version 4.0 of FFmpeg.

This is fixed in 1.1.1. I have also attached a patch containing the fix
which applies to 1.0.1.

James
Description: Fix FTBFS with FFmpeg 4.0
Origin: upstream, https://bitbucket.org/ignitionrobotics/ign-common/commits/89d45a69d76e
Bug: https://bitbucket.org/ignitionrobotics/ign-common/pull-requests/120
Bug-Debian: https://bugs.debian.org/896824
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/AudioDecoder.cc
+++ b/src/AudioDecoder.cc
@@ -257,8 +257,13 @@ bool AudioDecoder::SetFile(const std::st
 return false;
   }
 
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(56, 60, 100)
+  if (this->data->codec->capabilities & AV_CODEC_CAP_TRUNCATED)
+this->data->codecCtx->flags |= AV_CODEC_FLAG_TRUNCATED;
+#else
   if (this->data->codec->capabilities & CODEC_CAP_TRUNCATED)
 this->data->codecCtx->flags |= CODEC_FLAG_TRUNCATED;
+#endif
 
   // Open codec
   if (avcodec_open2(this->data->codecCtx, this->data->codec, nullptr) < 0)
--- a/src/Util.cc
+++ b/src/Util.cc
@@ -291,8 +291,10 @@ void ignition::common::load()
   if (first)
   {
 first = false;
+#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
 avcodec_register_all();
 av_register_all();
+#endif
 
 #if defined(__linux__) && defined(HAVE_AVDEVICE)
 avdevice_register_all();
--- a/src/Video.cc
+++ b/src/Video.cc
@@ -164,8 +164,13 @@ bool Video::Load(const std::string &_fil
 
   // Inform the codec that we can handle truncated bitstreams -- i.e.,
   // bitstreams where frame boundaries can fall in the middle of packets
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(56, 60, 100)
+  if (codec->capabilities & AV_CODEC_CAP_TRUNCATED)
+this->dataPtr->codecCtx->flags |= AV_CODEC_FLAG_TRUNCATED;
+#else
   if (codec->capabilities & CODEC_CAP_TRUNCATED)
 this->dataPtr->codecCtx->flags |= CODEC_FLAG_TRUNCATED;
+#endif
 
   // Open codec
   if (avcodec_open2(this->dataPtr->codecCtx, codec, nullptr) < 0)


signature.asc
Description: OpenPGP digital signature

Bug#901784: libmypaint-1.3-0: Can't install libmypaint-1.3-0

[James Cowgill]

Hi,

On 18/06/18 12:19, Coque Couto wrote:
> Package: libmypaint-1.3-0
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> libmypaint-1.3-0 package seems to be broken. Trying to install gimp
> reports the following error:
[...]
> It seems that libmypaint-common is not installable:
> 
> ###
> # apt install libmypaint-1.3-0
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> 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:
>  libmypaint-1.3-0 : Depends: libmypaint-common (>= 1.3.0-2) but it is not 
> installable
> E: Unable to correct problems, you have held broken packages.
> ###

I can't reproduce this. Can you run apt with the problem solver enabled
and paste the log?

# apt-get -o Debug::pkgProblemResolver=yes install libmypaint-1.3-0

Do you have mypaint-data installed? If so, this is probably a duplicate
of #894757.

James



signature.asc
Description: OpenPGP digital signature