Bug#893485: gjs: FTBFS on mips* - error: braces around scalar initializer for type 'int'

[James Cowgill]

Source: gjs
Version: 1.52.0-1
Severity: serious
Tags: sid buster patch

Hi,

gjs FTBFS on mips* with this error:
> gjs/profiler.cpp: In function 'void gjs_profiler_start(GjsProfiler*)':
> gjs/profiler.cpp:380:33: error: braces around scalar initializer for type 
> 'int'
>  struct sigaction sa = {{ 0 }};
>  ^
> make[2]: *** [Makefile:2422: gjs/libgjs_la-profiler.lo] Error 1

This happens because sigaction has an unusual layout on mips where the
first field is sa_flags instead of the usual sa_handler/sa_sigaction union.

I've attached a patch to fix this.

Thanks,
James
Description: Fix FTBFS on mips*
 Do not assume the first field of sigaction is a struct or union.
Author: James Cowgill <jcowg...@debian.org>
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/gjs/profiler.cpp
+++ b/gjs/profiler.cpp
@@ -377,9 +377,9 @@ gjs_profiler_start(GjsProfiler *self)
 
 g_return_if_fail(!self->capture);
 
-struct sigaction sa = {{ 0 }};
-struct sigevent sev = {{ 0 }};
-struct itimerspec its = {{ 0 }};
+struct sigaction sa = { 0 };
+struct sigevent sev = { 0 };
+struct itimerspec its = { 0 };
 struct itimerspec old_its;
 
 GjsAutoChar path = g_strdup(self->filename);
@@ -491,7 +491,7 @@ gjs_profiler_stop(GjsProfiler *self)
 
 #ifdef ENABLE_PROFILER
 
-struct itimerspec its = {{ 0 }};
+struct itimerspec its = { 0 };
 timer_settime(self->timer, 0, , nullptr);
 timer_delete(self->timer);
 


signature.asc
Description: OpenPGP digital signature

Bug#811766: scim-unikey: FTBFS with GCC 6: narrowing conversion

[James Cowgill]

Control: tags -1 pending

Hi,

On Tue, 19 Jan 2016 17:55:39 -0800 Martin Michlmayr <t...@hpe.com> wrote:
> Package: scim-unikey
> Version: 0.3.1+debian-3.1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-narrowing
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.

I've uploaded the attached NMU to DELAYED/2 which fixes this bug by
applying the upstream patch already mentioned in this bug report. I have
also taken the opportunity to add the mandatory build-{arch,indep}
targets to debian/rules. Please tell me if I should cancel it / delay it
longer.

Thanks,
James
diff -Nru scim-unikey-0.3.1+debian/debian/changelog 
scim-unikey-0.3.1+debian/debian/changelog
--- scim-unikey-0.3.1+debian/debian/changelog   2012-07-12 16:51:22.0 
+0100
+++ scim-unikey-0.3.1+debian/debian/changelog   2018-03-16 17:26:15.0 
+
@@ -1,3 +1,13 @@
+scim-unikey (0.3.1+debian-3.2) unstable; urgency=medium
+
+  * debian/patches:
+- Add upstream patch to fix FTBFS with GCC 6 due to narrowing conversions.
+  (Closes: #811766)
+  * debian/rules:
+- Add mandatory build-{arch,indep} targets.
+
+ -- James Cowgill <jcowg...@debian.org>  Fri, 16 Mar 2018 17:26:15 +
+
 scim-unikey (0.3.1+debian-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru scim-unikey-0.3.1+debian/debian/patches/gcc6.patch 
scim-unikey-0.3.1+debian/debian/patches/gcc6.patch
--- scim-unikey-0.3.1+debian/debian/patches/gcc6.patch  1970-01-01 
01:00:00.0 +0100
+++ scim-unikey-0.3.1+debian/debian/patches/gcc6.patch  2018-03-16 
17:02:48.0 +
@@ -0,0 +1,269 @@
+Description: Fix FTBFS with GCC 6 caused by narrowing conversions
+Author: marguerite <i...@marguerite.su>
+Origin: upstream, 
https://github.com/scim-im/scim-unikey/commit/dcc2ef6057a72d5babc49c51c1a5f998c9a31131
+Bug-Debian: https://bugs.debian.org/811766
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- a/ukengine/data.cpp
 b/ukengine/data.cpp
+@@ -96,145 +96,145 @@ See TCVN3 & VPS below for examples
+ unsigned char SingleByteTables[][TOTAL_VNCHARS] = 
+ 
+ // TCVN3
+-{{'A','a','¸','¸','µ','µ','¶','¶','·','·','¹','¹',  // 0: a
+-  '¢','©','Ê','Ê','Ç','Ç','È','È','É','É','Ë','Ë',// 1: a^
+-  '¡','¨','¾','¾','»','»','¼','¼','½','½','Æ','Æ',// 2: a(
+-  'B','b','C','c','D','d',
+-  '§','®',
+-  'E','e','Ð','Ð','Ì','Ì','Î','Î','Ï','Ï','Ñ','Ñ',// 3: e
+-  '£','ª','Õ','Õ','Ò','Ò','Ó','Ó','Ô','Ô','Ö','Ö',  // 4: e^
+-  'F','f','G','g','H','h',
+-  'I','i','Ý','Ý','×','×','Ø','Ø','Ü','Ü','Þ','Þ',// 5: i
+-  'J','j','K','k','L','l','M','m','N','n',
+-  'O','o','ã','ã','ß','ß','á','á','â','â','ä','ä',// 6: o
+-  '¤','«','è','è','å','å','æ','æ','ç','ç','é','é',// 7: o^
+-  '¥','¬','í','í','ê','ê','ë','ë','ì','ì','î','î',// 8: o+
+-  'P','p','Q','q','R','r','S','s','T','t',
+-  'U','u','ó','ó','ï','ï','ñ','ñ','ò','ò','ô','ô',// 9: u
+-  '¦','­','ø','ø','õ','õ','ö','ö','÷','÷','ù','ù',//10: u+ 
+-  'V','v','W','w','X','x',
+-  'Y','y','ý','ý','ú','ú','û','û','ü','ü','þ','þ',//11: y
+-  'Z','z',
++{{static_cast('A'),static_cast('a'),static_cast('¸'),static_cast('¸'),static_cast('µ'),static_cast('µ'),static_cast('¶'),static_cast('¶'),static_cast('·'),static_cast('·'),static_cast('¹'),static_cast('¹'), 
 // 0: a
++  static_cast('¢'),static_cast('©'),static_cast('Ê'),static_cast('Ê'),static_cast('Ç'),static_cast('Ç'),static_cast('È'),static_cast('È'),static_cast('É'),static_cast('É'),static_cast('Ë'),static_cast('Ë'), 
   // 1: a^
++  static_cast('¡'),static_cast('¨'),static_cast('¾'),static_cast('¾'),static_cast('»'),static_cast('»'),static_cast('¼'),static_cast('¼'),static_cast('½'),static_cast('½'),static_cast('Æ'),static_cast('Æ'), 
   // 2: a(
++  static_cast('B'),static_cast('b'),static_cast('C'),static_cast('c'),static_cast('D'),static_cast('d'),
++  static_cast('§'),static_cast('®'),
++  static_cast('E'),static_cast('e'),static_cast('Ð'),static_cast('Ð'),static_cast('Ì'),static_cast('Ì'),static_cast('Î'),static_cast('Î'),static_cast('Ï'),static_cast('Ï'),static_cast('Ñ'),static_cast('Ñ'), 
   // 3: e
++  static_cast('£'),static_cast('ª'),static_cast('Õ'),static_cast('Õ'),static_cast('Ò'),static_cast('Ò'),static_cast('Ó'),static_cast('Ó'),static_cast('Ô'),static_cast('Ô'),static_cast('Ö'),static_cast('Ö'), 
 // 4: e^
++  static_cast('F'),static_cast('f'),static_cast('G'),static_cast('g'),static_cast('H'),static_cast('h'),
++  static_cast('I'),static_cast('i'),static_cast('Ý'),static_cast('Ý'),static_cast('×'),static_cast('×'),static_cast('Ø'),static_cast('Ø'),static_cast('Ü'),static_cast('Ü'),static_cast('Þ'),static_cast('Þ'), 
   // 5: i
++  static_cast('J')

Bug#893119: tktreectl: FTBFS - ./configure not found

[James Cowgill]

Source: tktreectrl
Version: 2.2.8-2
Severity: serious
Tags: sid buster

Hi,

tktreectl FTBFS everywhere with:
>  debian/rules build-arch
> dh_testdir
> cp -f /usr/share/misc/config.sub config.sub
> cp -f /usr/share/misc/config.guess config.guess
> ./configure --build aarch64-linux-gnu \
> --prefix=/usr \
> --mandir=\${prefix}/share/man \
> --infodir=\${prefix}/share/info \
> --with-tcl=/usr/lib \
> --with-tk=/usr/lib \
> --with-tclinclude=/usr/include/tcl \
> --with-tkinclude=/usr/include/tcl \
> CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security" \
> LDFLAGS="-lm -Wl,-z,defs -Wl,--no-undefined -Wl,--as-needed"
> /bin/sh: 1: ./configure: not found
> debian/rules:20: recipe for target 'config-stamp' failed
> make: *** [config-stamp] Error 127
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This was caused by this change:
> @@ -16,8 +18,6 @@
>  config: config-stamp
>  config-stamp: 
> dh_testdir
> -   $(MAKE) -f /usr/share/quilt/quilt.make patch
> -   autoreconf --force
>  ifneq "$(wildcard /usr/share/misc/config.sub)" ""
> cp -f /usr/share/misc/config.sub config.sub
>  endif

You need to keep the call to autoreconf.

Please consider converting the package to use dh or at least use
dh_autoreconf instead.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#893114: dablin: FTBFS on armel, mips, mipsel, m68k, powerpc, powerpcspe, sh4 - undefined reference to `__atomic_load_8'

[James Cowgill]

Source: dablin
Version: 1.8.0-1
Severity: serious
Tags: sid buster

Hi

dablin FTBFS on the above architectures with these errors:
> [ 96%] Linking CXX executable dablin
> cd /<>/obj-mips-linux-gnu/src && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/dablin.dir/link.txt --verbose=1
> /usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -Wl,-z,relro -Wl,-z,now -rdynamic 
> CMakeFiles/dablin.dir/sdl_output.cpp.o 
> CMakeFiles/dablin.dir/dabplus_decoder.cpp.o 
> CMakeFiles/dablin.dir/eti_source.cpp.o CMakeFiles/dablin.dir/eti_player.cpp.o 
> CMakeFiles/dablin.dir/dab_decoder.cpp.o 
> CMakeFiles/dablin.dir/fic_decoder.cpp.o 
> CMakeFiles/dablin.dir/pcm_output.cpp.o CMakeFiles/dablin.dir/tools.cpp.o 
> CMakeFiles/dablin.dir/version.cpp.o CMakeFiles/dablin.dir/dablin.cpp.o  -o 
> dablin ../fec/libfec.a -lpthread -lmpg123 -lSDL2 -lfaad -lc -lm 
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:239: 
> undefined reference to `__atomic_store_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:239: 
> undefined reference to `__atomic_store_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o: In function 
> `SDLOutput::GetAudio(unsigned char*, unsigned int)':
> ./obj-mips-linux-gnu/src/./src/sdl_output.cpp:167: undefined reference to 
> `__atomic_load_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:250: 
> undefined reference to `__atomic_load_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:250: 
> undefined reference to `__atomic_load_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:250: 
> undefined reference to `__atomic_load_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:250: 
> undefined reference to `__atomic_load_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:250: more 
> undefined references to `__atomic_load_8' follow
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:239: 
> undefined reference to `__atomic_store_8'
> CMakeFiles/dablin.dir/sdl_output.cpp.o:/usr/include/c++/7/atomic:239: 
> undefined reference to `__atomic_store_8'
> collect2: error: ld returned 1 exit status
> make[3]: *** [src/CMakeFiles/dablin.dir/build.make:336: src/dablin] Error 1
> make[3]: Leaving directory '/<>/obj-mips-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:311: src/CMakeFiles/dablin.dir/all] Error 2
> make[2]: *** Waiting for unfinished jobs
> make[3]: Entering directory '/<>/obj-mips-linux-gnu'
> [ 71%] Building CXX object src/CMakeFiles/dablin_gtk.dir/dablin_gtk.cpp.o
> cd /<>/obj-mips-linux-gnu/src && /usr/bin/c++  
> -DDABLIN_AAC_FAAD2 -I/usr/include/SDL2 -I/usr/include/gtkmm-3.0 
> -I/usr/lib/mips-linux-gnu/gtkmm-3.0/include -I/usr/include/atkmm-1.6 
> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 
> -I/usr/lib/mips-linux-gnu/gdkmm-3.0/include -I/usr/include/giomm-2.4 
> -I/usr/lib/mips-linux-gnu/giomm-2.4/include -I/usr/include/pangomm-1.4 
> -I/usr/lib/mips-linux-gnu/pangomm-1.4/include -I/usr/include/glibmm-2.4 
> -I/usr/lib/mips-linux-gnu/glibmm-2.4/include -I/usr/include/gtk-3.0 
> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
> -I/usr/include/dbus-1.0 -I/usr/lib/mips-linux-gnu/dbus-1.0/include 
> -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
> -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairomm-1.0 
> -I/usr/lib/mips-linux-gnu/cairomm-1.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/sigc++-2.0 
> -I/usr/lib/mips-linux-gnu/sigc++-2.0/include -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/glib-2.0 -I/usr/lib/mips-linux-gnu/glib-2.0/include 
> -I/<>/src/../fec  -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2   -std=c++0x -Wall -Wextra -o 
> CMakeFiles/dablin_gtk.dir/dablin_gtk.cpp.o -c 
> /<>/src/dablin_gtk.cpp
> make[3]: Leaving directory '/<>/obj-mips-linux-gnu'
> make[3]: Entering directory '/<>/obj-mips-linux-gnu'
> [100%] Linking CXX executable dablin_gtk
> cd /<>/obj-mips-linux-gnu/src && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/dablin_gtk.dir/link.txt --verbose=1
> /usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -Wl,-z,relro -Wl,-z,now -rdynamic 
> CMakeFiles/dablin_gtk.dir/sdl_output.cpp.o 
> CMakeFiles/dablin_gtk.dir/dabplus_decoder.cpp.o 
> CMakeFiles/dablin_gtk.dir/eti_source.cpp.o 
> CMakeFiles/dablin_gtk.dir/eti_player.cpp.o 
> CMakeFiles/dablin_gtk.dir/dab_decoder.cpp.o 
> CMakeFiles/dablin_gtk.dir/fic_decoder.cpp.o 
> CMakeFiles/dablin_gtk.dir/pcm_output.cpp.o 
> CMakeFiles/dablin_gtk.dir/tools.cpp.o CMakeFiles/dablin_gtk.dir/version.cpp.o 
> CMakeFiles/dablin_gtk.dir/mot_manager.cpp.o 
> CMakeFiles/dablin_gtk.dir/pad_decoder.cpp.o 
> 

Bug#893110: gupnp-igd: FTBFS (randomly?) testsuite failures - gupnp-simple-igd SIGTRAP

[James Cowgill]

Source: gupnp-igd
Version: 0.2.5-1
Severity: serious
Tags: sid buster

Hi,

gupnp-igd FTBFS on some of the buildds with this error:
> make[6]: Entering directory '/<>/tests/gtest'
> ../../test-driver: line 107: 11204 Trace/breakpoint trap   "$@" > $log_file 
> 2>&1
> FAIL: gupnp-simple-igd
> make[6]: Leaving directory '/<>/tests/gtest'
> make[6]: Entering directory '/<>/tests/gtest'
> =
>gupnp-igd 0.2.5: tests/gtest/test-suite.log
> =
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: gupnp-simple-igd
> ==
> 
> /simpleigd/new: 
> (/<>/tests/gtest/.libs/gupnp-simple-igd:11204): 
> GUPnP-ContextManager-Linux-WARNING **: Got new address for device 1 but 
> device is not active
> FAIL gupnp-simple-igd (exit status: 133)
> 
> 
> Testsuite summary for gupnp-igd 0.2.5
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See tests/gtest/test-suite.log
> Please report to http://www.gupnp.org/
> 

While it built on amd64 on the buildds, the package fails with the same
error when I locally rebuild it. I notice it build fine on all the
Ubuntu builders. I'm afraid I have no idea what is going on here.

James



signature.asc
Description: OpenPGP digital signature

Bug#893097: lynkeos.app: FTBFS on many architectures - PAGE_SIZE undeclared

[James Cowgill]

Source: lynkeos.app
Version: 2.10+dfsg1-1
Severity: serious
Tags: sid buster

Hi,

lynkeos.app FTBFS on many architectures (all except for x86, s390x and
alpha) with the error:
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyCachePrefs.m: In 
> function '-[MyCachePrefs(Private) initPrefs]':
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyCachePrefs.m:60:33: 
> error: 'PAGE_SIZE' undeclared (first use in this function); did you mean 
> '_GSC_SIZE'?
> memSize = get_phys_pages() * PAGE_SIZE;
>  ^
>  _GSC_SIZE
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyCachePrefs.m:60:33: 
> note: each undeclared identifier is reported only once for each function it 
> appears in
> make[5]: *** [/usr/share/GNUstep/Makefiles/rules.make:479: 
> obj/Lynkeos.obj/MyCachePrefs.m.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> gcc 
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/LynkeosStandardImageBuffer.m
>  -c \
>   -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -I. -I.. 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep.. 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../ThreadConnectionSources 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../ThirdPartySources/SMDoubleSlider
>  -DNO_FRAMEWORK_CHECK=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 
> -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 
> -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
> -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fgnu-runtime 
> -Wno-unknown-pragmas -Wno-cpp -fconstant-string-class=NSConstantString -I. 
> -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>-o obj/Lynkeos.obj/LynkeosStandardImageBuffer.m.o
> make[4]: *** [/usr/share/GNUstep/Makefiles/Instance/application.make:147: 
> internal-app-run-compile-submake] Error 2
> make[3]: *** [/usr/share/GNUstep/Makefiles/Master/rules.make:297: 
> Lynkeos.all.app.variables] Error 2
> make[2]: *** [/usr/share/GNUstep/Makefiles/Master/application.make:38: 
> internal-all] Error 2
> dh_auto_build: cd GNUstep && make -j2 -O "INSTALL=install 
> --strip-program=true" messages=yes "CFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security" 
> "CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2" "CXXFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security" "FCFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong" "FFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong" "GCJFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong" "LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--no-undefined 
> -Wl,--as-needed" "OBJCFLAGS=-g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security" "OBJCXXFLAGS=-g 
> -O2 -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security" returned exit code 
> 2
> make[1]: *** [debian/rules:15: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/<>/lynkeos.app-2.10+dfsg1'
> make: *** [debian/rules:12: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

There are two problems here:

PAGE_SIZE is not necessarily a constant. For example, MIPS kernels can
be compiled with different flags to change the page size. If you need to
use the page size, you should use sysconf(_SC_PAGESIZE) instead which
will calculate it at runtime.

In this case, the PAGE_SIZE constant is provided by . The
entire contents of this header is highly architecture specific and
portable applications should not include it at all.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#893089: openjdk-11: FTBFS on mips* - uses -m32 / -m64

[James Cowgill]

Source: openjdk-11
Version: 11~4-2
Severity: important
Tags: patch

Hi,

openjdk-11 FTBFS on mips* (and I expect others which have not built yet)
with this error:
> configure: Using default toolchain gcc (GNU Compiler Collection)
> configure: Will use user supplied compiler CC=mips-linux-gnu-gcc-7
> checking for mips-linux-gnu-gcc-7... /usr/bin/mips-linux-gnu-gcc-7
> checking resolved symbolic links for CC... no symlink
> configure: Using gcc C compiler version 7.3.0 [mips-linux-gnu-gcc-7 (Debian 
> 7.3.0-11) 7.3.0]
> checking for mips-linux-gnu-/usr/bin/mips-linux-gnu-gcc-7... 
> /usr/bin/mips-linux-gnu-gcc-7
> checking whether the C compiler works... no
> configure: error: in `/<>/build':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> configure exiting with result code 77
> make: *** [debian/rules:817: stamps/configure] Error 77
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This happens because the build system inserts a -m32 or -m64 option on
all architectures except arm*.

For Debian this can probably be removed completely, or at least changed
to whitelist the architectures this is supported on (these are the x86,
powerpc, s390 and sparc families I think). I've attached a patch which
does the latter.

Thanks,
James
--- a/make/autoconf/flags.m4
+++ b/make/autoconf/flags.m4
@@ -236,10 +236,11 @@ AC_DEFUN_ONCE([FLAGS_PRE_TOOLCHAIN],
   if test "x$TOOLCHAIN_TYPE" = xxlc; then
 MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}"
   elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
-if test "x$OPENJDK_TARGET_CPU" != xaarch64 &&
-test "x$OPENJDK_TARGET_CPU" != xarm; then
-  MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
-fi
+case "$OPENJDK_TARGET_CPU" in
+  x86*|ppc*|s390*|sparc*)
+MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
+;;
+esac
   fi
 
   # FIXME: global flags are not used yet...


signature.asc
Description: OpenPGP digital signature

Bug#822019: python-osd: Build arch:all+arch:any but is missing build-{arch,indep} targets

[James Cowgill]

Control: tags -1 pending

Hi,

On Wed, 20 Apr 2016 23:05:56 +0200 ni...@thykier.net wrote:
> Package: python-osd
> Severity: normal
> Usertags: arch-all-and-any-missing-targets
> 
> Hi,
> 
> The package python-osd builds an architecture independent *and* an
> architecture dependent package, but does not have the (now mandatory)
> "build-arch" and "build-indep" targets in debian/rules.

I've uploaded the attached NMU which fixes this. It simply applies the
patch which was already in this bug report since a year and a half ago.

Thanks,
James
diff -u python-osd-0.2.14/debian/changelog python-osd-0.2.14/debian/changelog
--- python-osd-0.2.14/debian/changelog
+++ python-osd-0.2.14/debian/changelog
@@ -1,3 +1,12 @@
+python-osd (0.2.14-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Santiago Vila ]
+  * Add build-{arch,indep} targets. (Closes: #822019)
+
+ -- James Cowgill <jcowg...@debian.org>  Thu, 15 Mar 2018 17:08:13 +
+
 python-osd (0.2.14-6) unstable; urgency=medium
 
   [ Jakub Wilk ]
diff -u python-osd-0.2.14/debian/rules python-osd-0.2.14/debian/rules
--- python-osd-0.2.14/debian/rules
+++ python-osd-0.2.14/debian/rules
@@ -4,6 +4,8 @@
 
 #-l$(CURDIR)/$p/usr/lib/
 
+build-arch: build
+build-indep: build
 build: build-stamp
 build-stamp:
dh_testdir
@@ -56 +58 @@
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary 
install


signature.asc
Description: OpenPGP digital signature

Bug#727343: reuse this issue for the more general solution to use dh-autoreconf

[James Cowgill]

Hi,

On Tue, 21 Jan 2014 11:41:53 + Matthias Klose  wrote:
> Control: retitle -1 chise-base: run dh-autoreconf to update 
> config.{sub,guess} and {libtool,aclocal}.m4
> 
> Reusing this report for the more general solution to also update
> the libtool.m4 and/or aclocal.m4 files, needed for the port mentioned
> in bug #726404.
> 
> See https://wiki.debian.org/qa.debian.org/FTBFS for a guide how to
> address these.
> 
> Please ignore this email if the libtool.m4/aclocal.m4 update is not
> needed, and updating the config.{guess,sub} files is sufficient.

While doing the NMU for #821970 I had a look at adding dh-autoreconf
support. It's made a bit more complex by configure.ac not being at the
root of the source package. Unfortunately the nice way of adding this
requires debhelper compat 10 and I didn't want to make a major change
like that in an NMU without asking first.

So I am asking if it's OK for me to update the packaging a bit to use
debhelper compat 10 and dh which should make it easy to fix this bug.

James



signature.asc
Description: OpenPGP digital signature

Bug#821970: chise-base: Build arch:all+arch:any but is missing build-{arch,indep} targets

[James Cowgill]

Control: tags -1 pending

Hi,

On Wed, 20 Apr 2016 22:48:40 +0200 ni...@thykier.net wrote:
> Package: chise-base
> Severity: normal
> Usertags: arch-all-and-any-missing-targets
> 
> Hi,
> 
> The package chise-base builds an architecture independent *and* an
> architecture dependent package, but does not have the (now mandatory)
> "build-arch" and "build-indep" targets in debian/rules.

I've uploaded the attached NMU to fix this. It simply applies the patch
which was added to this bug a year and a half ago.

James
diff -u chise-base-0.3.0/debian/rules chise-base-0.3.0/debian/rules
--- chise-base-0.3.0/debian/rules
+++ chise-base-0.3.0/debian/rules
@@ -38,6 +38,8 @@
cd libchise && CFLAGS="$(CFLAGS)" ./configure 
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
 
 
+build-arch: build
+build-indep: build
 build: build-stamp
 build-stamp: libchise/config.status
dh_testdir
@@ -117 +119 @@
-.PHONY: build clean binary-indep binary-arch binary install 
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary 
install
diff -u chise-base-0.3.0/debian/changelog chise-base-0.3.0/debian/changelog
--- chise-base-0.3.0/debian/changelog
+++ chise-base-0.3.0/debian/changelog
@@ -1,3 +1,12 @@
+chise-base (0.3.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Santiago Vila ]
+  * Add build-{arch,indep} targets. (Closes: #821970)
+
+ -- James Cowgill <jcowg...@debian.org>  Thu, 15 Mar 2018 14:57:51 +
+
 chise-base (0.3.0-2) unstable; urgency=low
 
   * libchise/Makefile.in (CFLAGS): Added -DHAVE_CONFIG_H


signature.asc
Description: OpenPGP digital signature

Bug#857401: chise-db: broken symlink: /usr/share/chise/0.3/db/db -> ../../../lib/xemacs-21.4.15/etc/chise-db

[James Cowgill]

Control: tags -1 patch

Hi,

On Fri, 10 Mar 2017 20:53:44 +0100 Andreas Beckmann <a...@debian.org> wrote:
> Package: chise-db
> Version: 0.3.0-2
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m29.8s ERROR: FAIL: Broken symlinks:
>   /usr/share/chise/0.3/db/db -> ../../../lib/xemacs-21.4.15/etc/chise-db
> 
> This evaluates to /usr/share/lib/xemacs-21.4.15/etc/chise-db
> Looks like you are missing one level of '../', since
> /usr/lib/xemacs-21.4.15/etc/chise-db exists ...

I think this is simply a packaging mistake where the symlink was
installed into the wrong directory. There should be no directory called
"db" AFAIKT.

James
From 134a64303027dc8a6445a2714c343cc6387569c9 Mon Sep 17 00:00:00 2001
From: James Cowgill <jcowg...@debian.org>
Date: Thu, 15 Mar 2018 14:55:36 +
Subject: [PATCH] Install db symlink into correct directory

Closes: #857401
---
 debian/chise-db.install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/chise-db.install b/debian/chise-db.install
index 55ad050..6b50135 100644
--- a/debian/chise-db.install
+++ b/debian/chise-db.install
@@ -1,4 +1,4 @@
 debian/tmp/usr/lib/xemacs-21.4.15/etc/chise-db/character/by_feature/* /usr/lib/xemacs-21.4.15/etc/chise-db/by_feature
 debian/tmp/usr/lib/xemacs-21.4.15/etc/chise-db/character/feature/* /usr/lib/xemacs-21.4.15/etc/chise-db/feature
 debian/tmp/usr/lib/xemacs-21.4.15/etc/chise-db/feature/property/* /usr/lib/xemacs-21.4.15/etc/chise-db/feature/property
-debian/tmp/usr/share/chise/0.3/db /usr/share/chise/0.3/db
+debian/tmp/usr/share/chise/0.3/db /usr/share/chise/0.3
-- 
2.16.2



signature.asc
Description: OpenPGP digital signature

Bug#892703: nmu: lots of libraries on mips + mipsel for fpxx

[James Cowgill]

Hi,

On 15/03/18 10:27, Emilio Pozuelo Monfort wrote:
> All the rest scheduled now, with slightly decreased build priority so it 
> doesn't
> stall the rest of the packages for a couple of days. The build queue is
> practically empty anyway so these should build rather quickly.

Thanks!

> BTW you guys requested this during the stretch cycle in #825342, but in the 
> end
> closed it as not needed.

On Tue, 26 Jul 2016 12:39:11 +0800 YunQiang Su  wrote:
> Yes. It is a problem. It is due to my script detect some wrong files.
>
> While it seems that FPXX doesn't really stop our process to MIPS32r2,
> as we have some more Octeon machines.
>
> So this is out release goal, while not need binNMU now.

*sigh* It should not have been closed then. I guess I wasn't aware of
the bug or must have missed it. One of the advantages in FPXX was to
help workaround some Loongson quirks and these were needed much less
after we increased the number of Octeon buildds. However the original
reason FPXX was created in the first place was for MSA where we still
needed the binNMUs.

James



signature.asc
Description: OpenPGP digital signature

Bug#892970: synopsis: README.source incorrectly says to use dpatch

[James Cowgill]

Source: synopsis
Version: 0.12-9
Severity: minor

Hi,

I notice README.source still contains instructions for using dpatch with
this package even though use of dpatch was removed in 0.12-9.

James



signature.asc
Description: OpenPGP digital signature

Bug#892891: 65.0.3325.146-3 never uploaded

[James Cowgill]

Control: severity -1 serious
Control: retitle -1 FTBFS: error: invalid application of 'sizeof' to incomplete 
type 'policy::ConfigurationPolicyProvider'

On Wed, 14 Mar 2018 15:02:52 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson 
 wrote:
> Package: chromium
> Version: 65.0.3325.146-3
> 
> 65.0.3325.146-3 was never uploaded.

Yes it was - but it FTBFS.

> [14867/32372] CXX obj/chrome/browser/browser/chrome_browser_main.o
> FAILED: obj/chrome/browser/browser/chrome_browser_main.o 
> g++ -MMD -MF obj/chrome/browser/browser/chrome_browser_main.o.d 
> -DUSE_LIBSECRET -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 
> -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DFULL_SAFE_BROWSING 
> -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD 
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG 
> -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DUSE_CUPS 
> -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_GLEXT_PROTOTYPES -DUSE_GLX 
> -DUSE_EGL -DTOOLKIT_VIEWS=1 -DEXPAT_RELATIVE_PATH -DUSING_SYSTEM_ICU=1 
> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=uint16_t 
> -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER 
> -DHAVE_PTHREAD -DV8_USE_EXTERNAL_STARTUP_DATA -DLEVELDB_PLATFORM_CHROMIUM=1 
> -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY 
> -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 
> -DI18N_ADDRESS_VALIDATION_DATA_URL=\"https://chromium-i18n.appspot.com/ssl-aggregate-address/\;
>  -DUSE_SYSTEM_ZLIB=1 -DHUNSPELL_STATIC -DHUNSPELL_CHROME_CLIENT 
> -DUSE_HUNSPELL -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 
> -DFEATURE_ENABLE_VOICEMAIL -DGTEST_RELATIVE_PATH -DWEBRTC_CHROMIUM_BUILD 
> -DWEBRTC_POSIX -DWEBRTC_LINUX -I../.. -Igen -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Igen/shim_headers/libevent_shim 
> -Igen/shim_headers/icui18n_shim -Igen/shim_headers/icuuc_shim 
> -Igen/shim_headers/zlib_shim -Igen/shim_headers/re2_shim 
> -Igen/shim_headers/snappy_shim -Igen/shim_headers/libpng_shim 
> -Igen/shim_headers/libjpeg_shim -Igen/shim_headers/libdrm_shim 
> -I../../third_party/khronos -I../../gpu -I../../third_party/libyuv/include 
> -Igen/shim_headers/ffmpeg_shim -Igen/shim_headers/libvpx_shim 
> -Igen/shim_headers/opus_shim -Igen/shim_headers/minizip_shim 
> -Igen/shim_headers/flac_shim -I../../third_party/ced/src 
> -I../../third_party/protobuf/src -I../../third_party/protobuf/src 
> -Igen/protoc_out -I../../third_party/boringssl/src/include -I/usr/include/nss 
> -I/usr/include/nspr -I../../third_party/leveldatabase 
> -I../../third_party/leveldatabase/src 
> -I../../third_party/leveldatabase/src/include -I../../skia/config 
> -I../../skia/ext -I../../third_party/skia/include/c 
> -I../../third_party/skia/include/config -I../../third_party/skia/include/core 
> -I../../third_party/skia/include/effects 
> -I../../third_party/skia/include/encode -I../../third_party/skia/include/gpu 
> -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy 
> -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf 
> -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports 
> -I../../third_party/skia/include/utils -I../../third_party/vulkan/include 
> -I../../third_party/skia/src/gpu -I../../third_party/skia/src/sksl 
> -I../../third_party/libwebm/source -Igen -I../../third_party/WebKit 
> -Igen/third_party/WebKit -I../../v8/include -Igen/v8/include 
> -Igen/third_party/metrics_proto -I../../third_party/mesa/src/include -Igen 
> -Igen -I../../third_party/libaddressinput/src/cpp/include 
> -I../../third_party/cacheinvalidation/overrides 
> -I../../third_party/cacheinvalidation/src -I/usr/include/libxml2 
> -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
> -I../../third_party/libsecret -I../../third_party/breakpad/breakpad/src -Igen 
> -I../../third_party/webrtc_overrides -I../../third_party/webrtc 
> -I../../third_party/webrtc_overrides -I../../testing/gtest/include 
> -I../../third_party/webrtc -fno-strict-aliasing --param=ssp-buffer-size=4 
> -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= 
> -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -m64 -march=x86-64 
> -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> -Wno-deprecated-declarations -fno-delete-null-pointer-checks 
> -Wno-missing-field-initializers -Wno-unused-parameter -Os -fno-ident 
> -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 
> -fvisibility=hidden -std=gnu++14 -Wno-narrowing -fno-exceptions -fno-rtti 
> -fvisibility-inlines-hidden -Wno-deprecated-declarations -Wno-dangling-else 
> -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -c 
> ../../chrome/browser/chrome_browser_main.cc -o 
> obj/chrome/browser/browser/chrome_browser_main.o
> In file included 

Bug#892917: love: use BD on lua OR luajit

[James Cowgill]

Hi,

On 14/03/18 13:37, Frédéric Bonnard wrote:
> Package: src:love
> Version: 0.9.1-4
> 
> --
> 
> Dear maintainer,
> 
> at the moment both liblua5.1-0-dev and libluajit-5.1-dev are required to
> build. I think one or the other exclusively should be enough, and your
> d/rules specifies one or the other already.
> The best being to require first libluajit-5.1-dev if available and
> fallback on liblua5.1-0-dev.
> This way, love will benefit from luajit's speed if possible but will
> build on more architectures as well thanks to lua's portability (that
> should fix the BD-Uninstallable status on some architectures)
> Here is a patch for this.
> Also, ppc64el's support in luajit is unsure in the long term, so with
> the patch, we ensure to be able to still have love on this architecture
> even if luajit drops ppc64el support (and thus fix the current FTBFS :
> https://buildd.debian.org/status/fetch.php?pkg=love=ppc64el=0.9.1-4=1503721727=0

Bear in mind the buildds ignore alternatives in build-dependencies, so
from their perspective, your patch is equivalent to dropping the non-jit
dependency and won't fix any of the BD-Uninstallable architectures.

I think keeping the current build-dependency on liblua5.1-0-dev but
restricting it to the architectures where luajit is not used should do
what you want.

James



signature.asc
Description: OpenPGP digital signature

Bug#892703: nmu: lots of libraries on mips + mipsel for fpxx

[James Cowgill]

Hi,

On 12/03/18 11:50, James Cowgill wrote:
> Control: retitle -1 nmu: lots of libraries on mips + mipsel for fpxx
> 
> [+ CC debian-mips]
> 
> Hi,
> 
> On Mon, 12 Mar 2018 12:15:38 +0800 YunQiang Su <wzss...@gmail.com> wrote:
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>> Severity: normal
>>
>> For mips and mipsel, we are working on FPXX migration, and this package
>> seems quite old,
>> So the rebuilding is needed to use the current default gcc options.
> 
> Background: FPXX was enabled in Debian in gcc-5 in the middle of 2015.
> FPXX needs to be enabled in all libraries loaded into the same address
> space to be able to use the alternative FR1 mode on 32-bit MIPS which is
> required to use MSA. Now some people have complained that MSA does not
> work in some complex packages because they depend on libraries without
> FPXX enabled.
> 
> I scanned the archive for libraries built without FPXX and were last
> built over 2 years ago. I generated the following list of 201 packages
> which would be useful to binNMU on mips and mipsel. Does this seem
> reasonable?

I have binNMUed these 4 packages which I have seen complaints about. The
rest of the packages should still be done but are not as important.

ALREADY DONE
==
nmu uriparser_0.8.4-1 . mips mipsel . -m 'Rebuild with FPXX ABI'
nmu libglu_9.0.0-2.1 . mips mipsel . -m 'Rebuild with FPXX ABI'
nmu libxt_1:1.1.5-1 . mips mipsel . -m 'Rebuild with FPXX ABI'
nmu libxmu_2:1.1.2-2 . mips mipsel . -m 'Rebuild with FPXX ABI'
==

Thanks.
James



signature.asc
Description: OpenPGP digital signature

Bug#892091: [Pkg-ayatana-devel] Bug#892091: ayatana-indicator-power: FTBFS randomly - gschemas.compiled generated twice

[James Cowgill]

Hi,

On 12/03/18 13:47, Mike Gabriel wrote:
> On  Mo 12 Mär 2018 14:29:18 CET, James Cowgill wrote:
>> On 11/03/18 15:40, Mike Gabriel wrote:
>>> On  Mo 05 Mär 2018 12:31:34 CET, James Cowgill wrote:
>>>> From cmake-commands(7) - add_custom_command:
>>>> "Do not list the output in more than one independent target that may
>>>> build in parallel or the two instances of the rule may conflict
>>>> (instead
>>>> use the add_custom_target() command to drive the command and make the
>>>> other targets depend on that one)."
>>>>
>>>> There are three independent targets here which use gschemas.compiled
>>>> (the three tests).
>>>>
>>>> I found this blog which tries to explain it (number 4):
>>>> https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>>>>
>>>>
>>>>
>>>> James
>>>
>>> Thanks for your research on this.
>>>
>>> Would this feel like a valid fix?
>>>
>>> ```
>>> diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
>>> index 2c45057..714fa6c 100644
>>> --- a/tests/CMakeLists.txt
>>> +++ b/tests/CMakeLists.txt
>>> @@ -32,6 +32,14 @@ add_custom_command (OUTPUT gschemas.compiled
>>>  COMMAND cp -f ${CMAKE_BINARY_DIR}/data/*gschema.xml
>>> ${SCHEMA_DIR}
>>>  COMMAND ${COMPILE_SCHEMA_EXECUTABLE} ${SCHEMA_DIR})
>>>
>>> +add_custom_target(
>>> +    test-notify-gschemas ALL DEPENDS gschemas.compiled
>>> +)
>>> +
>>> +add_custom_target(
>>> +    test-device-gschemas ALL DEPENDS gschemas.compiled
>>> +)
>>
>> I don't think this will work because these two targets might be built in
>> parallel and we end up with the same problem as before. I think you want
>> a single custom target which all the tests depend on.
>>
>> James
> 
> Hmm, but what you say above would contradict the howto provided under
> (4.) at this URL [1] (the one you quoted earlier).
> 
> I think, I exactly immitated what Sam Thursfield wrote on his blog.
> Don't you think?

I think the code directly under the section 4 heading is a failing test
case and an example of what you should _not_ do.

James



signature.asc
Description: OpenPGP digital signature

Bug#889016: lintian: Please update dh_commands for scour 0.36-2

[James Cowgill]

Hi,

On 12/03/18 00:42, Chris Lamb wrote:
> tags 889016 + pending
> thanks
> 
> Hi James,
> 
> Thanks for the reopening this. I've updated all the debhelper data. Can
> you check the scour changes over for sanity? We seem to have changed
> them a number of times in the past 6 months!
> 
> You can see the diff here:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=115ce429ef09111ba8d04ebe23bbacb3a1de26c7

Thanks. I think the scour changes look correct now.

James



signature.asc
Description: OpenPGP digital signature

Bug#892091: [Pkg-ayatana-devel] Bug#892091: ayatana-indicator-power: FTBFS randomly - gschemas.compiled generated twice

[James Cowgill]

Hi,

On 11/03/18 15:40, Mike Gabriel wrote:
> On  Mo 05 Mär 2018 12:31:34 CET, James Cowgill wrote:
>> From cmake-commands(7) - add_custom_command:
>> "Do not list the output in more than one independent target that may
>> build in parallel or the two instances of the rule may conflict (instead
>> use the add_custom_target() command to drive the command and make the
>> other targets depend on that one)."
>>
>> There are three independent targets here which use gschemas.compiled
>> (the three tests).
>>
>> I found this blog which tries to explain it (number 4):
>> https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>>
>>
>> James
> 
> Thanks for your research on this.
> 
> Would this feel like a valid fix?
> 
> ```
> diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
> index 2c45057..714fa6c 100644
> --- a/tests/CMakeLists.txt
> +++ b/tests/CMakeLists.txt
> @@ -32,6 +32,14 @@ add_custom_command (OUTPUT gschemas.compiled
>  COMMAND cp -f ${CMAKE_BINARY_DIR}/data/*gschema.xml
> ${SCHEMA_DIR}
>  COMMAND ${COMPILE_SCHEMA_EXECUTABLE} ${SCHEMA_DIR})
> 
> +add_custom_target(
> +    test-notify-gschemas ALL DEPENDS gschemas.compiled
> +)
> +
> +add_custom_target(
> +    test-device-gschemas ALL DEPENDS gschemas.compiled
> +)

I don't think this will work because these two targets might be built in
parallel and we end up with the same problem as before. I think you want
a single custom target which all the tests depend on.

James



signature.asc
Description: OpenPGP digital signature

Bug#892741: llvmlite: FTBFS on mips64el - testsuite segfaults

[James Cowgill]

Source: llvmlite
Version: 0.22.0-1
Severity: serious
Tags: sid buster

Hi,

llvmlite FTBFS on mips64el with this segmentation fault:
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="{interpreter} -m unittest discover 
> -v" dh_auto_test
> I: pybuild base:184: python2.7 -m unittest discover -v
> test_function_cfg_on_llvm_value (llvmlite.tests.test_binding.TestAnalysis) 
> ... ok
> test_get_function_cfg_on_ir (llvmlite.tests.test_binding.TestAnalysis) ... ok
> test_linux (llvmlite.tests.test_binding.TestDependencies) ... skipped 
> 'Distribution-specific test'
> test_bad_library (llvmlite.tests.test_binding.TestDylib) ... ok
> test_libm (llvmlite.tests.test_binding.TestDylib) ... ok
> test_close (llvmlite.tests.test_binding.TestFunctionPassManager) ... ok
> test_initfini (llvmlite.tests.test_binding.TestFunctionPassManager) ... ok
> test_run (llvmlite.tests.test_binding.TestFunctionPassManager) ... ok
> test_add_module (llvmlite.tests.test_binding.TestGlobalConstructors) ... ok
> test_add_module_lifetime (llvmlite.tests.test_binding.TestGlobalConstructors) 
> ... ok
> test_add_module_lifetime2 
> (llvmlite.tests.test_binding.TestGlobalConstructors) ... ok
> test_close (llvmlite.tests.test_binding.TestGlobalConstructors) ... ok
> test_emit_assembly (llvmlite.tests.test_binding.TestGlobalConstructors)
> Test TargetMachineRef.emit_assembly() ... ok
> test_emit_object (llvmlite.tests.test_binding.TestGlobalConstructors)
> Test TargetMachineRef.emit_object() ... ok
> test_global_ctors_dtors (llvmlite.tests.test_binding.TestGlobalConstructors) 
> ... Segmentation fault
> E: pybuild pybuild:283: test: plugin custom failed with: exit code=139: 
> python2.7 -m unittest discover -v
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> make[1]: *** [debian/rules:11: override_dh_auto_test] Error 25

I did a bit of investigation and I'm fairly certain this is an LLVM bug
which was fixed in LLVM 6 (although I'm not sure what commit fixes it).
Since LLVM 6 has now been released, I suspect you will be upgrading soon
so I have not tried to backport anything to LLVM 5 at this time.

James



signature.asc
Description: OpenPGP digital signature

Bug#892703: nmu: lots of libraries on mips + mipsel for fpxx

[James Cowgill]

Control: retitle -1 nmu: lots of libraries on mips + mipsel for fpxx

[+ CC debian-mips]

Hi,

On Mon, 12 Mar 2018 12:15:38 +0800 YunQiang Su  wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: binnmu
> Severity: normal
> 
> For mips and mipsel, we are working on FPXX migration, and this package
> seems quite old,
> So the rebuilding is needed to use the current default gcc options.

Background: FPXX was enabled in Debian in gcc-5 in the middle of 2015.
FPXX needs to be enabled in all libraries loaded into the same address
space to be able to use the alternative FR1 mode on 32-bit MIPS which is
required to use MSA. Now some people have complained that MSA does not
work in some complex packages because they depend on libraries without
FPXX enabled.

I scanned the archive for libraries built without FPXX and were last
built over 2 years ago. I generated the following list of 201 packages
which would be useful to binNMU on mips and mipsel. Does this seem
reasonable?

Thanks,
James



actor-framework
apache-mod-auth-ntlm-winbind
apache-upload-progress-module
apache2-mod-xforward
attica
avw.lv2
bambamc
biblesync
blepvco
bochs
buddy
chise-base
cl-uffi
clalsadrv
coinor-flopc++
coolkey
cowbell
cunit
cxxtools
dleyna-connector-dbus
dnscrypt-proxy
egenix-mx-base
evince-hwp
fdsend
flatzebra
flowcanvas
flxmlrpc
gadfly
gdome2
giggle
gkrellm2-cpufreq
gkrelltop
gnome-keyring-sharp
gnome-sharp2
goocanvas
gst-fluendo-mp3
gtk-nodoka-engine
gtkgl2
guifications
gumbo-parser
hyperic-sigar
ido
inotifyx
juman
kaa-base
kaa-imlib2
kaa-metadata
keybinder
kytea
lam
libapache-mod-auth-radius
libapache-mod-evasive
libapache2-mod-authnz-external
libapache2-mod-fcgid
libapache2-mod-ldap-userdir
libasr
libbase58
libcdaudio
libcddb
libchardet
libcli
libcommoncpp2
libcoverart
libdispatch
libdjconsole
libdockapp
libg15render
libglademm2.4
libglu
libgnomecanvasmm2.6
libgooglepinyin
libgrss
libhbaapi
libhbalinux
libidl
libinklevel
libkaz
liblastfm
liblbfgs
liblip
libmimic
libnetfilter-queue
libnss-pgsql
libnzb
libpcre++
libpqtypes
libpthread-workqueue
libpulse-java
librcc
libserial
libsignon-glib
libsnl
libtpl
libtrace3
libunibreak
libusb-java
libusbtc08
libverto
libview
libvistaio
libxdg-basedir
libxkbfile
libxmu
libxsettings
libxt
libydpdict
lua-wsapi
memchan
mlpy
mmpong
moblin-gtk-engine
mod-authz-securepass
mod-mime-xattr
mod-mono
mod-proxy-msrpc
mod-vhost-ldap
mono-fuse
moonshot-trust-router
muparser
notify-python
npapi-vlc
ntrack
ois
olsrd
openvpn-auth-radius
pam-dbus
pam-pgsql
pcapy
pidgin-latex
plasma-widget-yawp
proxychains
pyalsaaudio
pyao
pybluez
pychm
pyfribidi
pygpiv
pygts
pylibssh2
pymc
pymca
pymilter
pymtbl
pynifti
pyogg
pythia8
python-adns
python-biggles
python-cjson
python-clamav
python-geohash
python-lzma
python-omniorb
python-osd
python-pysqlite1.1
python-pysqlite2
python-pytc
python-sqlite
pyvorbis
pyxmpp
quixote
quixote1
rabbyt
rainbow
readline5
rfoo
rlog
roboptim-core
safe-iop
scgi
scim-m17n
scim-pinyin
scim-skk
scim-unikey
sciscipy
sfarklib
shhopt
sigx
smart
snack
sonata
spice-xpi
synopsis
tclex
thunar-media-tags-plugin
thunar-vcs-plugin
ucimf-sunpinyin
uriparser
usbtc08-python
wnn6-sdk
xbae
xfce4-cpugraph-plugin
xfce4-power-manager
xfce4-quicklauncher-plugin
xfce4-sensors-plugin
xfce4-systemload-plugin
xmpi
xpyb
yaml-cpp0.3
yorick-curses
yum-metadata-parser


actor-framework
apache-mod-auth-ntlm-winbind
apache-upload-progress-module
apache2-mod-xforward
attica
avw.lv2
bambamc
biblesync
blepvco
bochs
buddy
chise-base
cl-uffi
clalsadrv
coinor-flopc++
coolkey
cowbell
cunit
cxxtools
dleyna-connector-dbus
dnscrypt-proxy
egenix-mx-base
evince-hwp
fdsend
flatzebra
flowcanvas
flxmlrpc
gadfly
gdome2
giggle
gkrellm2-cpufreq
gkrelltop
gnome-keyring-sharp
gnome-sharp2
goocanvas
gst-fluendo-mp3
gtk-nodoka-engine
gtkgl2
guifications
gumbo-parser
hyperic-sigar
ido
inotifyx
juman
kaa-base
kaa-imlib2
kaa-metadata
keybinder
kytea
lam
libapache-mod-auth-radius
libapache-mod-evasive
libapache2-mod-authnz-external
libapache2-mod-fcgid
libapache2-mod-ldap-userdir
libasr
libbase58
libcdaudio
libcddb
libchardet
libcli
libcommoncpp2
libcoverart
libdispatch
libdjconsole
libdockapp
libg15render
libglademm2.4
libglu
libgnomecanvasmm2.6
libgooglepinyin
libgrss
libhbaapi
libhbalinux
libidl
libinklevel
libkaz
liblastfm
liblbfgs
liblip
libmimic
libnetfilter-queue
libnss-pgsql
libnzb
libpcre++
libpqtypes
libpthread-workqueue
libpulse-java
librcc
libserial
libsignon-glib
libsnl
libtpl
libtrace3
libunibreak
libusb-java
libusbtc08
libverto
libview
libvistaio
libxdg-basedir
libxkbfile
libxmu
libxsettings
libxt
libydpdict
lua-wsapi
memchan
mlpy
mmpong
moblin-gtk-engine
mod-authz-securepass
mod-mime-xattr
mod-mono
mod-proxy-msrpc
mod-vhost-ldap
mono-fuse
moonshot-trust-router
muparser
notify-python
npapi-vlc
ntrack
ois
olsrd
openvpn-auth-radius
pam-dbus
pam-pgsql
pcapy
pidgin-latex
plasma-widget-yawp
proxychains
pyalsaaudio
pyao
pybluez
pychm
pyfribidi
pygpiv
pygts

Bug#892582: mixxx: Build-Depend on scour

[James Cowgill]

Hi,

On 11/03/18 10:31, Matteo F. Vescovi wrote:
> On 2018-03-10 at 18:49 (-0500), Jeremy Bicha wrote:
>> Source: mixxx
>> Version: 2.0.0~dfsg-8
>>
>> Please Build-Depend on scour instead of python-scour and python3-scour.
> 
> Lintian complains on the source package with:
> 
> E: mixxx source: missing-build-dependency-for-dh-addon scour => python3-scour
> N: 
> N:The source package appears to be using a dh addon but doesn't build
> N:depend on the package that actually provides it. If it uses it, it must
> N:build depend on it.
> 
> So?

I think it's a lintian bug. I've reopened #889016 for it.

James



signature.asc
Description: OpenPGP digital signature

Bug#889016: lintian: Please update dh_commands for scour 0.36-2

[James Cowgill]

Control: reopen -1

Hi,

This bug was not correctly fixed in lintian 2.5.73. For example, mixxx
currently build depends on python3-scour (instead of scour), but lintian
produces no error for it:
https://lintian.debian.org/maintainer/pkg-multimedia-maintain...@lists.alioth.debian.org.html#mixxx

I think this is because dh_addons was not regenerated and still contains
the old python3-scour entry.

https://sources.debian.org/src/lintian/2.5.79/data/common/dh_addons/

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892488: pcre2: FTBFS on mips* - test failures

[James Cowgill]

Source: pcre2
Version: 10.31-1
Severity: serious
Tags: sid buster
Forwarded: https://bugs.exim.org/show_bug.cgi?id=2254

Hi,

pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
like the JIT is bust.

I forwarded the log upstream to the above address. I'll try to take a
look at what's causing this.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

[James Cowgill]

Control: fixed -1 0.3.1-1

Hi,

On 08/03/18 00:11, Серж ИвановЪ wrote:
> The issue can be fixed using 2 upstream patches:
> 
> https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch
> 
> https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch
> 
> applied to sources in this order, after recompile no segmentation faults
> were encountered.
> 
> those patches can be squashed for convenience to single patch.

Thanks for this (and to Michael for the way to reproduce this). While I
agree that these patches are an improvement, I'm not convinced that they
need to be applied to stable. It seems to me there is also a bug in
freeswitch here which reduced the stack size and proceeds to dlopen some
libraries without understanding the full implications of this.

James



signature.asc
Description: OpenPGP digital signature

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

[James Cowgill]

On 07/03/18 15:58, Серж ИвановЪ wrote:
> Unfortunately freeswitch (the actual application) is not available in
> deb archive.
> 
> How can I provide addition info on this issue?

It would be useful to know what in libopenmpt was causing this.

Can you add this to your APT sources.list:
deb http://deb.debian.org/debian-debug/ stretch-debug main

Then run "apt update; apt install libopenmpt0-dbgsym"

If you generate your backtrace with gdb now, it should tell you what in
libopenmpt triggered the bug.

Running freeswitch inside valgrind might show some issues.

Do other programs which use libopenmpt work - like ffmpeg and openmpt123?

James



signature.asc
Description: OpenPGP digital signature

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

[James Cowgill]

Hi,

On 07/03/18 15:13, Серж ИвановЪ wrote:
> Attached additional info, core dump and gdb backtrace log

Thanks, although I can't read the core dump without the binaries it runs
from. Can you reproduce the bug using binaries only found in the Debian
archive?

James



signature.asc
Description: OpenPGP digital signature

Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

[James Cowgill]

Hi,

On 07/03/18 14:32, s3rj1k wrote:
> Package: libopenmpt0
> Version: 0.2.7386~beta20.3-3+deb9u2
> Severity: important
> 
> Dear Maintainer,
> 
>  Using this shared library with external application creates segfault
>  with memcopy related functions.

I'm not sure I understand what you mean.

Do you have any logs? A stack backtrace? Specifically what commands do
you run to get the segfault?

>  This can be avoided if one would recompile with -O3 optimization as actually
>  does upstream in their makefile (not autotool sources)
> 
>  Adding this to rules effectively fixes issue:
> 
>  export DEB_CXXFLAGS_MAINT_APPEND = -O3

If this flag genuinely does fix the segfault, then there's likely some
undefined behavior in libopenmpt which the compiler is exploiting and
your suggested fix would just hide the real bug.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892267: 3dldf: FTBFS on mips64el, hurd-i386, ia64, powerpc, x32 - "src/3dldf tngnts_1.ldf" segfaults

[James Cowgill]

Source: 3dldf
Version: 2.0.3+dfsg-7
Severity: serious
Tags: sid buster

Hi,

3dldf FTBFS on the above architectures with the error:
> ../src/3dldf tngnts_1.ldf
> GNU 3DLDF Version 2.0.3
> Copyright (C) 2013 The Free Software Foundation
> Author:  Laurence D. Finston
> 
> GNU 3DLDF comes with ABSOLUTELY NO WARRANTY;
> for details see the file COPYING,
> which you should have received in the distribution of GNU 3DLDF 2.0.3
> This is Free Software, and you are welcome to redistribute it under certain 
> conditions;
> for details, again, see the file COPYING.
> 
> Please send bug reports to laurence.fins...@gmx.de
> Web site:  http://www.gnu.org/software/3dldf/LDF.html
> 
> make[4]: *** [Makefile_sub:21: tngnts_1.mp] Segmentation fault

While it didn't fail on amd64, running 3dldf in valgrind (on amd64)
immediately crashes so this is probably not an architecture specific error:
> $ valgrind ../src/3dldf tngnts_1.ldf 
> ==29155== Memcheck, a memory error detector
> ==29155== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==29155== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==29155== Command: ../src/3dldf tngnts_1.ldf
> ==29155== 
> GNU 3DLDF Version 2.0.3
> Copyright (C) 2013 The Free Software Foundation
> Author:  Laurence D. Finston
> 
> GNU 3DLDF comes with ABSOLUTELY NO WARRANTY;
> for details see the file COPYING,
> which you should have received in the distribution of GNU 3DLDF 2.0.3
> This is Free Software, and you are welcome to redistribute it under certain 
> conditions;
> for details, again, see the file COPYING.
> 
> Please send bug reports to laurence.fins...@gmx.de
> Web site:  http://www.gnu.org/software/3dldf/LDF.html
> 
> ==29155== Conditional jump or move depends on uninitialised value(s)
> ==29155==at 0x2A61E9: Id_Map_Entry_Type::operator*=(Transform const&) 
> (imetfncs.web:3854)
> ==29155==by 0x13E602: yyparse(void*) (parser.y++:29090)
> ==29155==by 0x134F5C: main (main.web:1478)
> ==29155== 
> ==29155== Invalid read of size 1
> ==29155==at 0x2A6398: Id_Map_Entry_Type::operator*=(Transform const&) 
> (imetfncs.web:3864)
> ==29155==by 0x13E602: yyparse(void*) (parser.y++:29090)
> ==29155==by 0x134F5C: main (main.web:1478)
> ==29155==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==29155== 
> ==29155== 
> ==29155== Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
> ==29155==  Access not within mapped region at address 0x0
> ==29155==at 0x2A6398: Id_Map_Entry_Type::operator*=(Transform const&) 
> (imetfncs.web:3864)
> ==29155==by 0x13E602: yyparse(void*) (parser.y++:29090)
> ==29155==by 0x134F5C: main (main.web:1478)
> ==29155==  If you believe this happened as a result of a stack
> ==29155==  overflow in your program's main thread (unlikely but
> ==29155==  possible), you can try to increase the size of the
> ==29155==  main thread stack using the --main-stacksize= flag.
> ==29155==  The main thread stack size used in this run was 8388608.
> ==29155== 
> ==29155== HEAP SUMMARY:
> ==29155== in use at exit: 1,207,653 bytes in 21,398 blocks
> ==29155==   total heap usage: 82,187 allocs, 60,789 frees, 2,678,604 bytes 
> allocated
> ==29155== 
> ==29155== LEAK SUMMARY:
> ==29155==definitely lost: 56,200 bytes in 150 blocks
> ==29155==indirectly lost: 309,868 bytes in 7,324 blocks
> ==29155==  possibly lost: 0 bytes in 0 blocks
> ==29155==still reachable: 841,585 bytes in 13,924 blocks
> ==29155== suppressed: 0 bytes in 0 blocks
> ==29155== Rerun with --leak-check=full to see details of leaked memory
> ==29155== 
> ==29155== For counts of detected and suppressed errors, rerun with: -v
> ==29155== Use --track-origins=yes to see where uninitialised values come from
> ==29155== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> Segmentation fault

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892175: pycryptodome FTBFS on 32bit big endian: src/montgomery.c:245: mont_mult: Assertion `t[2*abn_words] <= 1' failed

[James Cowgill]

On Tue, 06 Mar 2018 14:26:31 +0200 Adrian Bunk  wrote:
> Source: pycryptodome
> Version: 3.4.11-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=pycryptodome=sid
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> PYBUILD_SYSTEM=custom \
> PYBUILD_TEST_ARGS="python{version} -m Cryptodome.SelfTest 
> {build_dir}/" dh_auto_test
> I: pybuild base:184: python2.7 -m Cryptodome.SelfTest 
> /<>/.pybuild/pythonX.Y_2.7/build/
> Skipping AESNI tests
> python2.7: src/montgomery.c:245: mont_mult: Assertion `t[2*abn_words] <= 1' 
> failed.
> Aborted

I've only had a brief look, but there are some (uint64_t*) to
(uint32_t*) casts in src/multiply_32.c addmul128 which look like
undefined behavior to me (strict aliasing rule).

I notice BEBIT which looks like an attempt at big-endian support which
clearly hasn't worked.

A recent commit I noticed:
https://github.com/Legrandin/pycryptodome/commit/aa5fac10a1c3a5f2b98c35954ae74207d545ec13

James



signature.asc
Description: OpenPGP digital signature

Bug#892184: nvidia-settings: FTBFS on mips64el, ia64, m68k - /usr/bin/ld: failed to merge target specific data

[James Cowgill]

Source: nvidia-settings
Version: 387.34-1
Severity: serious
Tags: sid buster

Hi,

nvidia-settings FTBFS on the above architectures with this error (taken
from mips64el here):
> /usr/bin/ld: _out/debian/antialias.png.o: warning: linking abicalls files 
> with non-abicalls files
> /usr/bin/ld: _out/debian/antialias.png.o: linking 32-bit code with 64-bit code
> /usr/bin/ld: failed to merge target specific data of file 
> _out/debian/antialias.png.o
> /usr/bin/ld: _out/debian/background.png.o: warning: linking abicalls files 
> with non-abicalls files
> /usr/bin/ld: _out/debian/background.png.o: linking 32-bit code with 64-bit 
> code
> /usr/bin/ld: failed to merge target specific data of file 
> _out/debian/background.png.o
[...]
> collect2: error: ld returned 1 exit status

This is caused by trying to generate objects using "ld --format=binary"
which is not portable. In the case of mips64el, that command generates
objects without certain flags set which causes the link errors. These
flags are usually set by gcc.

If you want to do this portably, you have to go through the C compiler.
Using xxd -i is a common method.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892088: [pkg-golang-devel] Bug#892088: golang-1.10: FTBFS on mips when built on Octeon III buildds

[James Cowgill]

Hi,

On 06/03/18 01:02, Michael Hudson-Doyle wrote:
> Congrats on figuring this out and commiserations on having to do it, I
> guess! Do you think this is worth an upload now or will it be OK to wait
> until upstream releases 1.10.1 (assuming it gets into that)?

I haven't seen any major breakages caused by this bug. The main thing it
blocks is golang-1.10 testing migration in Debian due to some test
failures, so I think it's OK to wait if you prefer. I don't know what
the policy is for go stable updates to say if the fix will be in 1.10.1
or not.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#892091: ayatana-indicator-power: FTBFS randomly - gschemas.compiled generated twice

[James Cowgill]

Source: ayatana-indicator-power
Version: 2.0.92-1
Severity: serious
Tags: sid buster

Hi,

On the buildds, ayatana-indicator-power FTBFS on armhf, mips, ia64, m68k
and sh4 with an error similar to this:
> [ 84%] Generating gschemas.compiled
> cd /<>/obj-mips-linux-gnu/tests && cp -f 
> /<>/obj-mips-linux-gnu/data/*gschema.xml 
> /<>/obj-mips-linux-gnu/tests
> cp: cannot create regular file 
> '/<>/obj-mips-linux-gnu/tests/org.ayatana.indicator.power.gschema.xml':
>  File exists
> make[3]: *** [tests/CMakeFiles/test-device.dir/build.make:65: 
> tests/gschemas.compiled] Error 1
> make[3]: Leaving directory '/<>/obj-mips-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:464: tests/CMakeFiles/test-device.dir/all] 
> Error 2
> make[2]: *** Waiting for unfinished jobs
> make[3]: Entering directory '/<>/obj-mips-linux-gnu'
> [ 84%] Generating gschemas.compiled
> cd /<>/obj-mips-linux-gnu/tests && cp -f 
> /<>/obj-mips-linux-gnu/data/*gschema.xml 
> /<>/obj-mips-linux-gnu/tests
> cd /<>/obj-mips-linux-gnu/tests && 
> /usr/lib/mips-linux-gnu/glib-2.0/glib-compile-schemas 
> /<>/obj-mips-linux-gnu/tests
> make[3]: Leaving directory '/<>/obj-mips-linux-gnu'

This looks like a random error induced by parallel builds. Here you can
see that CMake is attempting to generate "gschemas.compiled" twice when
it should only generate it once.

tests/CMakeLists.txt contains:
> set (SCHEMA_DIR ${CMAKE_CURRENT_BINARY_DIR})
> add_definitions(-DSCHEMA_DIR="${SCHEMA_DIR}")
> execute_process (COMMAND ${PKG_CONFIG_EXECUTABLE} gio-2.0 --variable 
> glib_compile_schemas
>  OUTPUT_VARIABLE COMPILE_SCHEMA_EXECUTABLE
>  OUTPUT_STRIP_TRAILING_WHITESPACE)
> add_custom_command (OUTPUT gschemas.compiled
> DEPENDS 
> ${CMAKE_BINARY_DIR}/data/org.ayatana.indicator.power.gschema.xml
> COMMAND cp -f ${CMAKE_BINARY_DIR}/data/*gschema.xml 
> ${SCHEMA_DIR}
> COMMAND ${COMPILE_SCHEMA_EXECUTABLE} ${SCHEMA_DIR})
[...]
> function(add_test_by_name name)
>   set (TEST_NAME ${name})
>   add_executable (${TEST_NAME} ${TEST_NAME}.cc gschemas.compiled)
>   add_test (${TEST_NAME} ${TEST_NAME})
>   add_dependencies (${TEST_NAME} ayatanaindicatorpowerservice)
>   target_link_libraries (${TEST_NAME} ayatanaindicatorpowerservice gtest 
> ${DBUSTEST_LIBRARIES} ${SERVICE_DEPS_LIBRARIES} ${GTEST_LIBS})
> endfunction()
> add_test_by_name(test-notify)
> add_test(NAME dear-reader-the-next-test-takes-80-seconds COMMAND true)
> add_test_by_name(test-device)

From cmake-commands(7) - add_custom_command:
"Do not list the output in more than one independent target that may
build in parallel or the two instances of the rule may conflict (instead
use the add_custom_target() command to drive the command and make the
other targets depend on that one)."

There are three independent targets here which use gschemas.compiled
(the three tests).

I found this blog which tries to explain it (number 4):
https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

James



signature.asc
Description: OpenPGP digital signature

Bug#892088: golang-1.10: FTBFS on mips when built on Octeon III buildds

[James Cowgill]

Source: golang-1.10
Version: 1.10-1
Severity: serious
Tags: upstream patch
Forwarded: https://go-review.googlesource.com/c/go/+/97735
X-Debbugs-CC: debian-m...@lists.debian.org

[CC the list for the HW issue]

Hi,

golang-1.10 (and 1.9) FTBFS on mips big-endian with various floating
point test errors, but only when built on the Octeon III buildds.

After tearing my head out investigating this, I have concluded that
there is a hardware bug in the Octeon IIIs. The bug occurs when:
- You run a big floating point double operation (like div.d).
- Wait a few instructions (a store here seems to be important).
- Read the *odd* register which the above float operation stored into.
This ends up reading the value from before the double operation instead
of the result of the operation. I've attached a small C program which
reproduces this. It should happen 99% of the time (it will only fail if
you are unlucky and get an interrupt at the wrong time).

I think this does not affect the wider Debian archive because:
- MFHC1 (move from high float) seems to be unaffected (probably...)
- If mips32r2 and fpxx are enabled, GCC only reads the high part of a
float register using MFHC1 (in the few cases it needs to do this - like
integer <-> float conversion).

However, golang is affected because it uses FP32 and on big endian, all
double loads are split into word loads with the odd register loaded
first. I have attached a patch which fixes this which I have also
submitted upstream.

Thanks,
James
#include 
#include 

static void div_octeon_bug(double a, double b, uint32_t* buf)
{
	asm(
		"mtc1 %[fake_clobber], $f5\n"
		"div.d $f4, %[a], %[b]\n"
		"nop\n"
		"nop\n"
		"nop\n"
		"nop\n"
		"swc1 $f0, 0(%[buf])\n"
		"swc1 $f0, 0(%[buf])\n"
		"swc1 $f5, 0(%[buf])\n"
		"swc1 $f4, 4(%[buf])\n"
		"swc1 $f5, 8(%[buf])\n"
		"swc1 $f4, 12(%[buf])\n"
		:
		: [buf]"r"(buf), [fake_clobber]"r"(0xdeadbeef), [a]"f"(a), [b]"f"(b)
		: "memory", "f4", "$f5");
}

int main(void)
{
	uint32_t buf[4];
	div_octeon_bug(1.0, 21.63538985889851, buf);
	printf("%08x %08x\n", buf[0], buf[1]);
	printf("%08x %08x\n", buf[2], buf[3]);
	return 0;
}
From 5ab26b4e5996a3557a1d6f1af7f1e54104448a79 Mon Sep 17 00:00:00 2001
From: James Cowgill <james.cowg...@mips.com>
Date: Wed, 28 Feb 2018 16:10:14 +
Subject: [PATCH] cmd/internal/obj/mips: load/store even float registers first

There is a bug in Octeon III processors where storing an odd floating
point register after it has recently been written to by a double
floating point operation will store the old value from before the double
operation (there are some extra details - the operation and store
must be a certain number of cycles apart). However, this bug does not
occur if the even register is stored first. Currently the bug only
happens on big endian because go always loads the even register first on
little endian.

Workaround the bug by always loading / storing the even floating point
register first. Since this is just an instruction reordering, it should
have no performance penalty. This follows other compilers like GCC which
will always store the even register first (although you do have to set
the ISA level to MIPS I to prevent it from using SDC1).

Change-Id: I5e73daa4d724ca1df7bf5228aab19f53f26a4976
---
 src/cmd/internal/obj/mips/obj0.go | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/cmd/internal/obj/mips/obj0.go b/src/cmd/internal/obj/mips/obj0.go
index 2b9f18c942..c3bab5c48e 100644
--- a/src/cmd/internal/obj/mips/obj0.go
+++ b/src/cmd/internal/obj/mips/obj0.go
@@ -558,20 +558,22 @@ func preprocess(ctxt *obj.Link, cursym *obj.LSym, newprog obj.ProgAlloc) {
 			p.Link = q
 			p1 = q.Link
 
-			var regOff int16
+			var addrOff int64
 			if c.ctxt.Arch.ByteOrder == binary.BigEndian {
-regOff = 1 // load odd register first
+addrOff = 4 // swap load/save order
 			}
 			if p.From.Type == obj.TYPE_MEM {
 reg := REG_F0 + (p.To.Reg-REG_F0)&^1
-p.To.Reg = reg + regOff
-q.To.Reg = reg + 1 - regOff
-q.From.Offset += 4
+p.To.Reg = reg
+q.To.Reg = reg + 1
+p.From.Offset += addrOff
+q.From.Offset += 4 - addrOff
 			} else if p.To.Type == obj.TYPE_MEM {
 reg := REG_F0 + (p.From.Reg-REG_F0)&^1
-p.From.Reg = reg + regOff
-q.From.Reg = reg + 1 - regOff
-q.To.Offset += 4
+p.From.Reg = reg
+q.From.Reg = reg + 1
+p.To.Offset += addrOff
+q.To.Offset += 4 - addrOff
 			}
 		}
 	}
-- 
2.16.2



signature.asc
Description: OpenPGP digital signature

Bug#881449: fail2ban: postfix-sasl jail crashes on trying to ban ip address

[James Cowgill]

Control: forcemerge 867374 -1

Hi,

On Sun, 12 Nov 2017 09:18:09 +1100 Tomasz Ciolek  wrote:
> Package: fail2ban
> Version: 0.9.6-2
> Severity: important
> 
> Fail2ban postfix-sasl jail crashes when trying to ban an IP address: 
> 
> Failed to execute ban jail 'postfix-sasl' action 'iptables-multiport' info 
> 'CallingMap({'time': 1510389716.3446894, 'ip failures':  Actions.__checkBan.. at 0x7fb8d058a950>, 'ipjailmatches': 
> . at 0x7fb8d058a488>, 
> 'ipjailfailures': . at 
> 0x7fb8d058a510>, 'matches': 'Nov 11 19:41:40 celaeno postfix/smtpd[12912]: 
> warning: unknown[85.183.39.75]: SASL LOGIN authentication failed: 
> authentication failure\nNov 11 19:41:48 celaeno postfix/smtpd[12912]: 
> warning: unknown[85.183.39.75]: SASL LOGIN authentication failed: 
> authentication failure\nNov 11 19:41:55 celaeno postfix/smtpd[12912]: 
> warning: unknown[85.183.39.75]: SASL LOGIN authentication failed: 
> authentication failure', 'ipmatches':  Actions.__checkBan.. at 0x7fb8d0592378>, 'failures': 3, 'ip': 
> '85.183.39.75'})': Error starting action
> 
> As a aresult postfix-sasl jail is not fucntiong correctly
[...]
> -- /etc/fail2ban/jail.local file: 
> 
> [postfix-sasl]
> enabled  = true
> port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s

This is probably a duplicate of #867374 relating to the use of imap3, so
I am marking it as such. Try removing imap3 from this port list.

James



signature.asc
Description: OpenPGP digital signature

Bug#891924: klibc: crashes on mips64el if any syscall fails

[James Cowgill]

Package: libklibc
Version: 2.0.4-11
Severity: important
Tags: patch upstream

[Possibly this should be RC, but most things do indeed work - I'll leave
that up to you]

Hi,

I recently noticed that a mips64el initramfs built in unstable was
giving an unusual error (the boot continues as if no error had happened):
> Begin: Running /scripts/init-bottom ... Bus error
> done.

I traced this bug to the "nuke" command which ends up (intentionally)
calling unlink on a directory. A Bus Error then happened in the klibc
syscall handler when writing the new errno.

This happens because klibc is compiled with PIC enabled on mips64el and
the assembler expects the PIC $gp register to be set up correctly for
the store to work. Since it contained a bogus value, the program failed.
I think that when PIE was not enabled in 2.0.4-9, applications wouldn't
mess with the $gp register and by chance it happened to be the correct
value when entering the syscall handler.

I have fixed the bug in the attached patch which disables PIC code
(using the -mno-abicalls option) and adjusted the link flags so the
build still works.

I also submitted this patch and a few others upstream. The other patches
are mostly cleanups and are not that important. They will probably
appear here when the archives refresh themselves:
http://www.zytor.com/pipermail/klibc/2018-March/thread.html

Thanks,
James
From 65bf5068d8f65cb26b1550b1c0f3c4f7db5d6e12 Mon Sep 17 00:00:00 2001
From: James Cowgill <james.cowg...@mips.com>
Date: Fri, 2 Mar 2018 14:48:21 +
Subject: [PATCH 1/5] mips64: compile with -mno-abicalls

By default, the MIPS toolchain compiles all code as PIC. Since klibc
links everything at static addresses, we don't need PIC code so use
-mno-abicalls to disable it. To fix subsequent link errors, use
-Ttext-segment to adjust the base address of klibc to a more sensible
location.

This fixes a bug in the shared library form of klibc where programs
would segfault in the syscall handler because we tried to store into the
"errno" variable without setting up the gp register. This is only required
under the PIC ABI.

Signed-off-by: James Cowgill <james.cowg...@mips.com>
---
 usr/klibc/arch/mips64/MCONFIG | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/usr/klibc/arch/mips64/MCONFIG b/usr/klibc/arch/mips64/MCONFIG
index b37cc6a7..6a4b41b2 100644
--- a/usr/klibc/arch/mips64/MCONFIG
+++ b/usr/klibc/arch/mips64/MCONFIG
@@ -7,7 +7,17 @@
 # accordingly.
 #
 
+KLIBCARCHREQFLAGS = -fno-pic -mno-abicalls -G 0
 KLIBCOPTFLAGS += -Os
 KLIBCBITSIZE  = 64
 
-KLIBCSHAREDFLAGS  = -T $(src)/arch/mips/klibc.ld
+# Extra linkflags when building the shared version of the library
+# This address needs to be reachable using normal inter-module
+# calls, and work on the memory models for this architecture
+# 4862 MB - normal binaries start at 4608 MB. Non-PIC jumps usually
+# use the JAL instruction which requires a destination within the same
+# 256M aligned region. Since we can't put ourselves below the normal
+# load address, use the very top of the 256M region (minus 2MB)
+#
+# Use -Ttext-segment so that the special .MIPS* sections are moved as well.
+KLIBCSHAREDFLAGS = -Ttext-segment 0x12FE0
-- 
2.16.2



signature.asc
Description: OpenPGP digital signature

Bug#886222: ld.gold: internal error in get_got_page_offset, at ../../gold/mips.cc:6271

[James Cowgill]

Control: tags -1 patch

Hi,

On 01/03/18 11:26, Emilio Pozuelo Monfort wrote:
> Hi James,
> 
> On Thu, 1 Feb 2018 10:21:44 +0000 James Cowgill <jcowg...@debian.org> wrote:
>> I have a slightly reduced testcase, but it still requires about 50M of
>> objects so I'm working on reducing it even more.
> 
> Any progress on that? If you have sent this upstream already, can you share 
> the
> bug# ?

There is already an upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=22770

I have attached the v3 of my patch. I submitted v1 upstream but
apparently MIPS _still_ hasn't sorted out the FSF copyright assignment
from when we split off from imgtec so I cannot submit anything else
upstream at the moment.

James
From 48390a9e113ca10fe1094f914127920c4722bdb6 Mon Sep 17 00:00:00 2001
From: James Cowgill <james.cowg...@mips.com>
Date: Thu, 1 Mar 2018 11:55:18 +
Subject: [PATCHv3] [gold] PR22770: MIPS: Fix GOT page counter in multi-got links

The record_got_page_entry function records and updates the maximum
number of GOT page entries which may be required by an object. In the
case where an existing GOT page entry was expanded, only the entry
belonging to the master GOT would have its page count updated. This leaves
the entry belonging to the object GOT with the num_pages count of 1 it
was originally initialized with. Later on when GOTs are being merged in a
multi-got link, this causes the value of entry->num_pages in
add_got_page_entries to always be 1 and underestimates the number of pages
required for the new entry. This in turn leads to an assertion failure in
get_got_page_offset where we run out of pages.

Fix by not inserting Got_page_entrys into the object's GOT at all and
later on adding the total number of page entries recorded for the
object's GOT into the new merged GOT. This is safe because
got_page_entries_ is used for no other purpose in the object's GOT, and
page_gotno_ for the object's GOT should already be incremented by the correct
amount in record_got_page_entry. Remove Got_page_entry::num_pages which
is now unused.

gold/
2018-03-01  James Cowgill  <james.cowg...@mips.com>

	PR gold/22770
	* mips.cc (Mips_got_info::record_got_page_entry): Don't insert
	Got_page_entry for object's GOT.
	(Mips_got_info::add_got_page_entries): Add all pages from from's GOT.
	Rename to add_got_page_count.
	(Got_page_entry): Remove num_pages.
---
 gold/mips.cc | 42 --
 1 file changed, 8 insertions(+), 34 deletions(-)

diff --git a/gold/mips.cc b/gold/mips.cc
index 543a23462f..b4de79b946 100644
--- a/gold/mips.cc
+++ b/gold/mips.cc
@@ -631,11 +631,11 @@ struct Got_page_range
 struct Got_page_entry
 {
   Got_page_entry()
-: object(NULL), symndx(-1U), ranges(NULL), num_pages(0)
+: object(NULL), symndx(-1U), ranges(NULL)
   { }
 
   Got_page_entry(Object* object_, unsigned int symndx_)
-: object(object_), symndx(symndx_), ranges(NULL), num_pages(0)
+: object(object_), symndx(symndx_), ranges(NULL)
   { }
 
   // The input object that needs the GOT page entry.
@@ -644,8 +644,6 @@ struct Got_page_entry
   unsigned int symndx;
   // The ranges for this page entry.
   Got_page_range* ranges;
-  // The maximum number of page entries needed for RANGES.
-  unsigned int num_pages;
 };
 
 // Hash for Got_page_entry.
@@ -775,7 +773,7 @@ class Mips_got_info
 
   // Add FROM's GOT page entries.
   void
-  add_got_page_entries(Mips_got_info<size, big_endian>* from);
+  add_got_page_count(Mips_got_info<size, big_endian>* from);
 
   // Return GOT size.
   unsigned int
@@ -928,7 +926,7 @@ class Mips_got_info
   Global_got_entry_set global_got_symbols_;
   // A hash table holding GOT entries.
   Got_entry_set got_entries_;
-  // A hash table of GOT page entries.
+  // A hash table of GOT page entries (only used in master GOT).
   Got_page_entry_set got_page_entries_;
   // The offset of first GOT page entry for this GOT.
   unsigned int got_page_offset_start_;
@@ -5794,14 +5792,8 @@ Mips_got_info<size, big_endian>::record_got_page_entry(
   else
 this->got_page_entries_.insert(entry);
 
-  // Add the same entry to the OBJECT's GOT.
-  Got_page_entry* entry2 = NULL;
+  // Get the object's GOT, but we don't need to insert an entry here.
   Mips_got_info<size, big_endian>* g2 = object->get_or_create_got_info();
-  if (g2->got_page_entries_.find(entry) == g2->got_page_entries_.end())
-{
-  entry2 = new Got_page_entry(*entry);
-  g2->got_page_entries_.insert(entry2);
-}
 
   // Skip over ranges whose maximum extent cannot share a page entry
   // with ADDEND.
@@ -5821,9 +5813,6 @@ Mips_got_info<size, big_endian>::record_got_page_entry(
   range->max_addend = addend;
 
   *range_ptr = range;
-  ++entry->num_pages;
-  if (entry2 != NULL)
-++entry2->num_pages;
   ++this->page_gotno_;
   ++g2->page_gotno_;
   return;

Bug#870701: python-pip-whl: Incompatible versions of requests and urllib3 cause TypeError when index is unavailable

[James Cowgill]

Hi,

On Fri, 04 Aug 2017 10:41:28 + Stefano Mazzucco  wrote:
> Package: python-pip-whl
> Version: 9.0.1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> when trying to install a package with pip and the PyPI index server is 
> unavailable,
> urllib3 raises an error.
> 
> I ran into this issue when using an extra-index-url option pointing to a 
> server
> that was down.
> 
> For example:
> 
> $ pip install pyyml
> Collecting pyyml
> Exception:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in 
> main
> status = self.run(options, args)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 342, 
> in run
> requirement_set.prepare_files(finder)
>   File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
> prepare_files
> ignore_dependencies=self.ignore_dependencies))
>   File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 554, in 
> _prepare_file
> require_hashes
>   File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 278, 
> in populate_link
> self.link = finder.find_requirement(self, upgrade)
>   File "/usr/lib/python2.7/dist-packages/pip/index.py", line 465, in 
> find_requirement
> all_candidates = self.find_all_candidates(req.name)
>   File "/usr/lib/python2.7/dist-packages/pip/index.py", line 423, in 
> find_all_candidates
> for page in self._get_pages(url_locations, project_name):
>   File "/usr/lib/python2.7/dist-packages/pip/index.py", line 568, in 
> _get_pages
> page = self._get_page(location)
>   File "/usr/lib/python2.7/dist-packages/pip/index.py", line 683, in _get_page
> return HTMLPage.get_page(link, session=self.session)
>   File "/usr/lib/python2.7/dist-packages/pip/index.py", line 792, in get_page
> "Cache-Control": "max-age=600",
>   File 
> "/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
>  line 501, in get
> return self.request('GET', url, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/pip/download.py", line 386, in 
> request
> return super(PipSession, self).request(method, url, *args, **kwargs)
>   File 
> "/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
>  line 488, in request
> resp = self.send(prep, **send_kwargs)
>   File 
> "/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/sessions.py",
>  line 609, in send
> r = adapter.send(request, **kwargs)
>   File 
> "/usr/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/adapters.py",
>  line 423, in send
> timeout=timeout
>   File 
> "/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/connectionpool.py",
>  line 643, in urlopen
> _stacktrace=sys.exc_info()[2])
>   File 
> "/usr/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
>  line 315, in increment
> total -= 1
> TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'

I have just encounted this error and was fairly puzzled until I
investigated further. A simple google search for the error message shows
quite a lot of people having the same issue and a few upstream bug
reports which simply get closed as "Debian's problem". If I understand
the packaging correctly, simply rebuilding this package should update
the various wheels automatically and fix this? Please can this happen.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#891556: faketime: FTBFS with GCC 8 - error: 'strncpy' specified bound 128 equals destination size

[James Cowgill]

Source: ifhp
Version: 3.5.20-15
Severity: important
User: debian-...@lists.debian.org
Usertag: ftbfs-gcc-8

Hi,

I recently performed an (unofficial) archive rebuild with GCC 8 on
mips64el. The main purpose of the rebuild was to discover mips toolchain
regressions, however I noticed this error in the logs which might be
interesting to you:

> ifhp.c: In function 'Find_sub_value':
> ifhp.c:2803:3: error: 'strncpy' specified bound 128 equals destination size 
> [-Werror=stringop-truncation]
>strncpy(copy,id+1,sizeof(copy));
>^~~
> cc1: all warnings being treated as errors
> : recipe for target 'ifhp.o' failed
> make[2]: *** [ifhp.o] Error 1
> make[2]: Leaving directory '/<>/src'
> Makefile:51: recipe for target 'src' failed
> make[1]: *** [src] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:32: recipe for target 'build-stamp' failed
> make: *** [build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

As you probably know, you need to be careful using strncpy.

Instead of:
 char out[SIZE];
 strncpy(out, in, SIZE);

You need to do:
 char out[SIZE]
 strncpy(out, in, SIZE - 1);
 out[SIZE - 1] = '\0';

See strcpy(3)

James





signature.asc
Description: OpenPGP digital signature

Bug#891551: faketime: FTBFS with GCC 8 - error: 'strncpy' specified bound 256 equals destination size

[James Cowgill]

Source: faketime
Version: 0.9.7-1
Severity: important
User: debian-...@lists.debian.org
Usertag: ftbfs-gcc-8

Hi,

I recently performed an (unofficial) archive rebuild with GCC 8 on
mips64el. The main purpose of the rebuild was to discover mips toolchain
regressions, however I noticed this error in the logs which might be
interesting to you:

> faketime.c: In function 'main':
> faketime.c:289:45: error: '%s' directive output may be truncated writing up 
> to 4095 bytes into a region of size between 0 and 4095 
> [-Werror=format-truncation=]
>  snprintf(shared_objs, PATH_BUFSIZE, "%s %s", sem_name, shm_name);
>  ^~ 
> faketime.c:289:5: note: 'snprintf' output between 2 and 8192 bytes into a 
> destination of size 4096
>  snprintf(shared_objs, PATH_BUFSIZE, "%s %s", sem_name, shm_name);
>  ^~~~
> In file included from libfaketime.c:49:
> libfaketime.c: In function 'fake_clock_gettime':
> libfaketime.c:1986:24: error: cast between incompatible function types from 
> 'int (*)(pthread_mutex_t *)' {aka 'int (*)(union  *)'} to 'void 
> (*)(void *)' [-Werror=cast-function-type]
>pthread_cleanup_push((void (*)(void *))pthread_mutex_unlock, (void 
> *)_mutex);
> ^
> cc1: all warnings being treated as errors
> Makefile:98: recipe for target 'faketime' failed
> make[2]: *** [faketime] Error 1
> make[2]: *** Waiting for unfinished jobs
> libfaketime.c: In function 'fake_clock_gettime.part.4':
> libfaketime.c:2081:7: error: 'strncpy' specified bound 256 equals destination 
> size [-Werror=stringop-truncation]
>strncpy(user_faked_time, tmp_env, BUFFERLEN);
>^~~~
> libfaketime.c:2081:7: error: 'strncpy' specified bound 256 equals destination 
> size [-Werror=stringop-truncation]
>strncpy(user_faked_time, tmp_env, BUFFERLEN);
>^~~~
> libfaketime.c: In function 'ftpl_init':
> libfaketime.c:1831:12: error: 'strncpy' specified bound 1024 equals 
> destination size [-Werror=stringop-truncation]
>  (void) strncpy(ft_spawn_target, getenv("FAKETIME_SPAWN_TARGET"), 1024);
> ^~~
> libfaketime.c:1892:5: error: 'strncpy' specified bound 8192 equals 
> destination size [-Werror=stringop-truncation]
>  strncpy(user_faked_time_fmt, tmp_env, BUFSIZ);
>  ^
> libfaketime.c: In function 'ftpl_init':
> libfaketime.c:1831:12: error: 'strncpy' specified bound 1024 equals 
> destination size [-Werror=stringop-truncation]
>  (void) strncpy(ft_spawn_target, getenv("FAKETIME_SPAWN_TARGET"), 1024);
> ^~~
> libfaketime.c:1892:5: error: 'strncpy' specified bound 8192 equals 
> destination size [-Werror=stringop-truncation]
>  strncpy(user_faked_time_fmt, tmp_env, BUFSIZ);
>  ^
> cc1: all warnings being treated as errors
> Makefile:92: recipe for target 'libfaketime.o' failed
> make[2]: *** [libfaketime.o] Error 1
> cc1: all warnings being treated as errors
> Makefile:92: recipe for target 'libfaketimeMT.o' failed
> make[2]: *** [libfaketimeMT.o] Error 1
> make[2]: Leaving directory '/<>/src'
> Makefile:7: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/<>'
> dh_auto_build: make -j3 "INSTALL=install --strip-program=true" returned exit 
> code 2
> debian/rules:22: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

As you probably know, you need to be careful using strncpy.

Instead of:
 char out[SIZE];
 strncpy(out, in, SIZE);

You need to do:
 char out[SIZE]
 strncpy(out, in, SIZE - 1);
 out[SIZE - 1] = '\0';

See strcpy(3)

James



signature.asc
Description: OpenPGP digital signature

Bug#891544: chiark-tcl: FTBFS with GCC 8 - error: division 'sizeof (const int *) / sizeof (int)' does not compute the number of array elements

[James Cowgill]

Source: chiark-tcl
Version: 1.2.1
Severity: important
User: debian-...@lists.debian.org
Usertag: ftbfs-gcc-8

Hi,

I recently performed an (unofficial) archive rebuild with GCC 8 on
mips64el. The main purpose of the rebuild was to discover mips toolchain
regressions, however I noticed this error in the logs which might be
interesting to you:

> mips64el-linux-gnuabi64-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes 
> -Werror -O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC  
> -I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o adns.o -c adns.c
> adns.c: In function 'query_submit':
> adns.c:497:40: error: division 'sizeof (const int *) / sizeof (int)' does not 
> compute the number of array elements [-Werror=sizeof-pointer-div]
>  for (af=aftry; af < af + sizeof(af)/sizeof(*af); af++) {
> ^
> adns.c:496:16: note: first 'sizeof' operand was declared here
>  const int *af;
> ^~
> cc1: all warnings being treated as errors
> ../base/final.make:23: recipe for target 'adns.o' failed
> make[2]: *** [adns.o] Error 1
> make[2]: Leaving directory '/<>/adns'
> Makefile:15: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:47: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

Probably the for loop condition should be:
 af < aftry + sizeof(aftry)/sizeof(*aftry)

James



signature.asc
Description: OpenPGP digital signature

Bug#891520: linux-libc-dev: headers from 4.15 cause "redefinition of 'struct in6_addr'" in libreswan

[James Cowgill]

Package: linux-libc-dev
Version: 4.15.4-1
Severity: important
Tags: fixed-upstream
Control: affects -1 src:libreswan
X-Debbugs-CC: libres...@packages.debian.org

Hi,

I noticed libreswan FTBFS in unstable with this error:
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:33:8: error: redefinition of 'struct in6_addr'
>  struct in6_addr {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:211:8: note: originally defined here
>  struct in6_addr
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:50:8: error: redefinition of 'struct sockaddr_in6'
>  struct sockaddr_in6 {
> ^~~~
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:252:8: note: originally defined here
>  struct sockaddr_in6
> ^~~~
> In file included from 
> /<>/programs/pluto/linux-copy/linux/xfrm.h:4:0,
>  from /<>/programs/pluto/kernel_netlink.c:55:
> /usr/include/linux/in6.h:60:8: error: redefinition of 'struct ipv6_mreq'
>  struct ipv6_mreq {
> ^
> In file included from /<>/linux/include/libreswan.h:76:0,
>  from /<>/programs/pluto/kernel_netlink.c:54:
> /usr/include/netinet/in.h:288:8: note: originally defined here
>  struct ipv6_mreq
> ^
> make[5]: *** [../../mk/depend.mk:34: kernel_netlink.o] Error 1
> make[4]: *** [../../mk/targets.mk:90: all] Error 2
> make[4]: Leaving directory '/<>/programs/pluto'
> make[3]: *** [../mk/targets.mk:90: recursive-all] Error 2
> make[3]: Leaving directory '/<>/programs'
> make[2]: *** [mk/targets.mk:90: recursive-all] Error 2
> make[2]: Leaving directory '/<>'
> make[1]: *** [debian/rules:23: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2

See also this reproducible builds log:
> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libreswan_3.23-4.rbuild.log

This only happens when using linux headers from 4.15.

I think the cause of this was a change in 4.15 in the if_ether.h header.
It should be fixed by this upstream patch (applied in linus's tree but
not yet in stable):
https://www.spinics.net/lists/stable/msg215023.html

da360299b6734135a5f66d7db458dcc7801c826a
"uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define"

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888344: baresip: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 fixed-upstream
Control: forwarded -1 https://github.com/alfredh/baresip/issues/351

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: baresip
> Version: 0.5.7-1
> 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.

This is fixed in 0.5.8. See the above github issue.

James



signature.asc
Description: OpenPGP digital signature

Bug#888335: squeezelite: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 patch

On Wed, 24 Jan 2018 22:26:51 + jcowg...@debian.org wrote:
> Source: squeezelite
> Version: 1.8-4
> 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.

Thanks,
James
Description: Fix FTBFS with FFmpeg 4.0
Author: James Cowgill <jcowg...@debian.org>
Bug-Debian: https://bugs.debian.org/888335
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -264,7 +264,7 @@ static decode_state ff_decode(void) {
 		ff->mmsh_bytes_left = ff->mmsh_bytes_pad = ff->mmsh_packet_len = 0;
 
 		if (!ff->readbuf) {
-			ff->readbuf = AV(ff, malloc, READ_SIZE +  FF_INPUT_BUFFER_PADDING_SIZE);
+			ff->readbuf = AV(ff, malloc, READ_SIZE +  AV_INPUT_BUFFER_PADDING_SIZE);
 		}
 
 		avio = AVIO(ff, alloc_context, ff->readbuf, READ_SIZE, 0, NULL, _read_data, NULL, NULL);


signature.asc
Description: OpenPGP digital signature

Bug#888333: xpra: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 fixed-upstream patch

On Wed, 24 Jan 2018 22:26:51 + jcowg...@debian.org wrote:
> Source: xpra
> Version: 0.17.6+dfsg-1
> 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.

This has been fixed upstream in 2.2.4.

I have also attached the relevant patch which applies on top of
0.17.6+dfsg-1 if you don't have time to get 2.2.4 into unstable (I
notice 2.x is only in experimental).

James
Description: Fix FTBFS with FFmpeg 4.0
Origin: upstream, commit:r18086
Bug-Debian: https://bugs.debian.org/888333
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/xpra/codecs/dec_avcodec2/decoder.pyx
+++ b/xpra/codecs/dec_avcodec2/decoder.pyx
@@ -65,7 +65,7 @@ cdef extern from "libavutil/pixfmt.h":
 AVPixelFormat AV_PIX_FMT_GBRP
 
 cdef extern from "libavcodec/avcodec.h":
-int CODEC_FLAG2_FAST
+int AV_CODEC_FLAG2_FAST
 
 ctypedef struct AVFrame:
 uint8_t **data
@@ -361,7 +361,7 @@ cdef class Decoder:
 self.codec_ctx.thread_safe_callbacks = 1
 self.codec_ctx.thread_type = 2  #FF_THREAD_SLICE: allow more than one thread per frame
 self.codec_ctx.thread_count = 0 #auto
-self.codec_ctx.flags2 |= CODEC_FLAG2_FAST   #may cause "no deblock across slices" - which should be fine
+self.codec_ctx.flags2 |= AV_CODEC_FLAG2_FAST   #may cause "no deblock across slices" - which should be fine
 r = avcodec_open2(self.codec_ctx, self.codec, NULL)
 if r<0:
 log.error("could not open codec: %s", self.av_error_str(r))


signature.asc
Description: OpenPGP digital signature

Bug#888332: audacity: FTBFS with FFmpeg 3.5

[James Cowgill]

Control: tags -1 fixed-upstream
Control: forwarded -1 https://github.com/audacity/audacity/pull/249

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: audacity
> Version: 2.2.1-1
> 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.

This is fixed upstream in audacity 2.2.2.

James



signature.asc
Description: OpenPGP digital signature

Bug#888353: moc: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 24/02/18 20:54, Elimar Riesebieter wrote:
> Hi James,
> 
> * jcowg...@debian.org  [2018-01-24 22:26 +]:
> 
>> 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.
> 
> Is there a ffmpeg version available to test our package build with?
> I can't see version 4 flowing around at least at rmadison...

You can use "3.5" from experimental for the time being. When I uploaded
it I thought they would call it 3.5, but instead they are going to call
it 4.0. It's still the same thing though.

James



signature.asc
Description: OpenPGP digital signature

Bug#888329: guvcview: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 patch

Hi,

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: guvcview
> Version: 2.0.5+debian-1
> 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 should work.

The #ifdefs are not strictly required to build with 3.4 in unstable or
with 4.0, but might be useful if the patch is submitted upstream.

Setting the motion estimation method (me_method) is now done using a
private encoder specific option (av_opt_set*), however I think the
me_methods which were previously set were all either ignored or were the
default settings so I think removing them is OK (unless I've missed
something).

James
Description: Fix FTBFS with FFmpeg 4.0
Author: James Cowgill <jcowg...@debian.org>
Bug-Debian: https://bugs.debian.org/888329
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/gview_v4l2core/uvc_h264.c
+++ b/gview_v4l2core/uvc_h264.c
@@ -61,6 +61,9 @@
 #if !LIBAVCODEC_VER_AT_LEAST(54,25)
 	#define AV_CODEC_ID_H264 CODEC_ID_H264
 #endif
+#ifndef AV_CODEC_FLAG2_FAST
+#define AV_CODEC_FLAG2_FAST CODEC_FLAG2_FAST
+#endif
 
 #include "uvc_h264.h"
 #include "v4l2_formats.h"
@@ -1039,7 +1042,7 @@ int h264_init_decoder(int width, int hei
 		exit(-1);
 	}
 	
-	h264_ctx->context->flags2 |= CODEC_FLAG2_FAST;
+	h264_ctx->context->flags2 |= AV_CODEC_FLAG2_FAST;
 	h264_ctx->context->pix_fmt = AV_PIX_FMT_YUV420P;
 	h264_ctx->context->width = width;
 	h264_ctx->context->height = height;
--- a/gview_encoder/video_codecs.c
+++ b/gview_encoder/video_codecs.c
@@ -42,6 +42,10 @@ extern int verbosity;
 #define CODEC_FLAG2_INTRA_REFRESH 0
 #endif
 
+#ifndef AV_CODEC_FLAG_4MV
+#define AV_CODEC_FLAG_4MV CODEC_FLAG_4MV
+#endif
+
 
 static bmp_info_header_t mkv_codecPriv =
 {
@@ -97,7 +101,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "none",
 		.mb_decision  = 0,
 		.trellis  = 0,
-		.me_method= 0,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 0,
@@ -133,7 +136,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "mjpeg",
 		.mb_decision  = 0,
 		.trellis  = 0,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 0,
@@ -169,7 +171,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "mpeg1video",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 1,
@@ -205,11 +206,10 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "flv",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 1,
-		.flags= CODEC_FLAG_4MV
+		.flags= AV_CODEC_FLAG_4MV
 	},
 	{
 		.valid= 1,
@@ -241,7 +241,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "wmv1",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 1,
@@ -277,7 +276,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "mpeg2video",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 1,
@@ -313,7 +311,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "msmpeg4v3",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 0,
 		.max_b_frames = 0,
 		.num_threads  = 1,
@@ -349,7 +346,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "mpeg4",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 1,
-		.me_method= ME_EPZS,
 		.mpeg_quant   = 1,
 		.max_b_frames = 0,
 		.num_threads  = 1,
@@ -385,7 +381,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "libx264",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 0,
-		.me_method= X264_ME_HEX,
 		.mpeg_quant   = 1,
 		.max_b_frames = 16,
 		.num_threads  = 4,
@@ -426,7 +421,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "libx265",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 0,
-		.me_method= ME_HEX,
 		.mpeg_quant   = 1,
 		.max_b_frames = 16,
 		.num_threads  = 4,
@@ -463,7 +457,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "libvpx_vp8",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 0,
-		.me_method= ME_HEX,
 		.mpeg_quant   = 1,
 		.max_b_frames = 0,
 		.num_threads  = 4,
@@ -500,7 +493,6 @@ static video_codec_t listSupCodecs[] =
 		.codec_name   = "libvpx_vp9",
 		.mb_decision  = FF_MB_DECISION_RD,
 		.trellis  = 0,
-		.me_method= ME_HEX,
 		.

Bug#888328: motion: FTBFS with FFmpeg 3.4

[James Cowgill]

Control: tags -1 patch
Control: forwarded -1 https://github.com/Motion-Project/motion/pull/657

On Wed, 24 Jan 2018 22:26:50 + jcowg...@debian.org wrote:
> Source: motion
> Version: 4.0-1
> 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.

I submitted an upstream PR to fix this. Patch attached.

James
From ff99988d57f4bcb0a7b381374f8106896bda2b15 Mon Sep 17 00:00:00 2001
From: James Cowgill <jcowg...@jcowgill.uk>
Date: Fri, 23 Feb 2018 23:04:33 +
Subject: [PATCH] Fix build errors with FFmpeg 4.0

---
 ffmpeg.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 1e6cdf6..4299ba3 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -67,6 +67,19 @@
 
 #endif
 
+/*/
+#if (LIBAVCODEC_VERSION_MAJOR >= 57)
+
+#define MY_CODEC_FLAG_GLOBAL_HEADER AV_CODEC_FLAG_GLOBAL_HEADER
+#define MY_CODEC_FLAG_QSCALEAV_CODEC_FLAG_QSCALE
+
+#else
+
+#define MY_CODEC_FLAG_GLOBAL_HEADER CODEC_FLAG_GLOBAL_HEADER
+#define MY_CODEC_FLAG_QSCALECODEC_FLAG_QSCALE
+
+#endif
+
 /*/
 AVFrame *my_frame_alloc(void){
 AVFrame *pic;
@@ -548,7 +561,7 @@ static int ffmpeg_set_quality(struct ffmpeg *ffmpeg){
 /* The selection of 8000 is a subjective number based upon viewing output files */
 if (ffmpeg->vbr > 0){
 ffmpeg->vbr =(int)(((100-ffmpeg->vbr)*(100-ffmpeg->vbr)*(100-ffmpeg->vbr) * 8000) / 100) + 1;
-ffmpeg->ctx_codec->flags |= CODEC_FLAG_QSCALE;
+ffmpeg->ctx_codec->flags |= MY_CODEC_FLAG_QSCALE;
 ffmpeg->ctx_codec->global_quality=ffmpeg->vbr;
 }
 }
@@ -673,7 +686,7 @@ static int ffmpeg_set_codec(struct ffmpeg *ffmpeg){
   ffmpeg->ctx_codec->strict_std_compliance = -2;
   ffmpeg->ctx_codec->level = 3;
 }
-ffmpeg->ctx_codec->flags |= CODEC_FLAG_GLOBAL_HEADER;
+ffmpeg->ctx_codec->flags |= MY_CODEC_FLAG_GLOBAL_HEADER;
 
 retcd = ffmpeg_set_quality(ffmpeg);
 if (retcd < 0){
@@ -1085,7 +1098,7 @@ static int ffmpeg_passthru_codec(struct ffmpeg *ffmpeg){
 pthread_mutex_unlock(>rtsp_data->mutex_transfer);
 return -1;
 }
-ffmpeg->video_st->codec->flags |= CODEC_FLAG_GLOBAL_HEADER;
+ffmpeg->video_st->codec->flags |= MY_CODEC_FLAG_GLOBAL_HEADER;
 ffmpeg->video_st->codec->codec_tag  = 0;
 #else
 /* This is disabled in the util_check_passthrough but we need it here for compiling */
-- 
2.16.1



signature.asc
Description: OpenPGP digital signature

Bug#888327: xine-lib-1.2: FTBFS with FFmpeg 3.5

[James Cowgill]

Control: tags -1 fixed-upstream patch

On Wed, 24 Jan 2018 22:26:51 + jcowg...@debian.org wrote:
> Source: xine-lib-1.2
> Version: 1.2.8-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.

Fixed upstream by this commit:
https://sourceforge.net/p/xine/xine-lib-1.2/ci/abd6e04c7a53f10d1a2975159f65ba7e33bee61c/

Patch attached.

James
Description: Fix FTBFS with FFmpeg 4.0
Origin: upstream, https://sourceforge.net/p/xine/xine-lib-1.2/ci/abd6e04c7a53f10d1a2975159f65ba7e33bee61c/
Bug-Debian: https://bugs.debian.org/888327
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/combined/ffmpeg/ff_audio_decoder.c
+++ b/src/combined/ffmpeg/ff_audio_decoder.c
@@ -221,7 +221,7 @@ static void ff_audio_ensure_buffer_size(
 xprintf(this->stream->xine, XINE_VERBOSITY_LOG,
 _("ffmpeg_audio_dec: increasing buffer to %d to avoid overflow.\n"),
 this->bufsize);
-this->buf = xine_realloc_aligned (this->buf, this->bufsize + FF_INPUT_BUFFER_PADDING_SIZE);
+this->buf = xine_realloc_aligned (this->buf, this->bufsize + AV_INPUT_BUFFER_PADDING_SIZE);
   }
 }
 
@@ -232,9 +232,9 @@ static void ff_audio_handle_special_buff
 
 free (this->context->extradata);
 this->context->extradata_size = buf->decoder_info[2];
-this->context->extradata = malloc (buf->decoder_info[2] + FF_INPUT_BUFFER_PADDING_SIZE);
+this->context->extradata = malloc (buf->decoder_info[2] + AV_INPUT_BUFFER_PADDING_SIZE);
 memcpy (this->context->extradata, buf->decoder_info_ptr[2], buf->decoder_info[2]);
-memset (this->context->extradata + buf->decoder_info[2], 0, FF_INPUT_BUFFER_PADDING_SIZE);
+memset (this->context->extradata + buf->decoder_info[2], 0, AV_INPUT_BUFFER_PADDING_SIZE);
 
 ff_aac_mode_set (this, 0);
   }
@@ -451,10 +451,10 @@ static void ff_handle_header_buffer(ff_a
 this->ff_channels, this->ff_bits, this->ff_sample_rate,
 this->context->block_align);
   if (!data_len) break;
-  e = malloc (data_len + FF_INPUT_BUFFER_PADDING_SIZE);
+  e = malloc (data_len + AV_INPUT_BUFFER_PADDING_SIZE);
   if (!e) break;
   xine_fast_memcpy (e, p, data_len);
-  memset (e + data_len, 0, FF_INPUT_BUFFER_PADDING_SIZE);
+  memset (e + data_len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
   this->context->extradata = e;
   this->context->extradata_size = data_len;
   break;
@@ -1008,7 +1008,7 @@ static void ff_audio_decode_data (audio_
   offset = 0;
 
   /* pad input data */
-  memset(>buf[this->size], 0, FF_INPUT_BUFFER_PADDING_SIZE);
+  memset(>buf[this->size], 0, AV_INPUT_BUFFER_PADDING_SIZE);
 
   while (this->size>=0) {
 
--- a/src/combined/ffmpeg/ff_mpeg_parser.c
+++ b/src/combined/ffmpeg/ff_mpeg_parser.c
@@ -26,6 +26,7 @@
 #define LOG
 */
 #include "ff_mpeg_parser.h"
+#include "ffmpeg_compat.h"
 
 /* mpeg frame rate table from lavc */
 static const int frame_rate_tab[][2] = {
@@ -50,7 +51,7 @@ static const int frame_rate_tab[][2] = {
 
 void mpeg_parser_init (mpeg_parser_t *parser)
 {
-  parser->chunk_buffer = malloc(BUFFER_SIZE + FF_INPUT_BUFFER_PADDING_SIZE);
+  parser->chunk_buffer = malloc(BUFFER_SIZE + AV_INPUT_BUFFER_PADDING_SIZE);
   mpeg_parser_reset(parser);
 }
 
--- a/src/combined/ffmpeg/ff_video_decoder.c
+++ b/src/combined/ffmpeg/ff_video_decoder.c
@@ -869,16 +869,18 @@ static void init_video_codec (ff_video_d
   this->stream->video_out->open (this->stream->video_out, this->stream);
 
   this->edge = 0;
-  if(this->codec->capabilities & CODEC_CAP_DR1 && this->class->enable_dri) {
+  if(this->codec->capabilities & AV_CODEC_CAP_DR1 && this->class->enable_dri) {
 if (this->stream->video_out->get_capabilities (this->stream->video_out) & VO_CAP_CROP) {
   /* We can crop. Fine. Lets allow decoders to paint over the frame edges.
  This will be slightly faster. And it is also a workaround for buggy
  v54 who likes to ignore EMU_EDGE for wmv2 and xvid. */
   this->edge = XFF_EDGE_WIDTH ();
+#ifdef CODEC_FLAG_EMU_EDGE
 } else {
   /* Some codecs (eg rv10) copy flags in init so it's necessary to set
* this flag here in case we are going to use direct rendering */
   this->context->flags |= CODEC_FLAG_EMU_EDGE;
+#endif
 }
   }
 
@@ -887,7 +889,7 @@ static void init_video_codec (ff_video_d
   this->context->codec_type = this->codec->type;
 
   if (this->class->choose_speed_over_accuracy)
-this->context->flags2 |= CODEC_FLAG2_FAST;
+this->context->flags2 |= AV_CODEC_FLAG2_FAST;
 
   this->context->skip_loop_filter = skip_loop_filter_enum_values[this->class->skip_loop_filter_enum];
 
@@ -912,7 +914,7 @@ static void init_video_codec (ff_video_d
   /* enable direct rendering by default */
   this->output_format = XINE_IMGFMT_YV12;
 #ifdef ENABLE_DIRECT_RENDERING
-  if( 

Bug#888325: mgba: FTBFS with FFmpeg 4.0

[James Cowgill]

Control: tags -1 fixed-upstream patch
Control: forwarded -1 https://github.com/mgba-emu/mgba/issues/966

On 24/01/18 22:26, jcowg...@debian.org wrote:
> Source: mgba
> Version: 0.5.2+dfsg1-3
> 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.

Fixed with the attached patch. An equivalent has been applied upstream
(see above link).

Thanks,
James
--- a/src/feature/ffmpeg/ffmpeg-encoder.c
+++ b/src/feature/ffmpeg/ffmpeg-encoder.c
@@ -229,7 +229,7 @@ bool FFmpegEncoderOpen(struct FFmpegEnco
 		AVDictionary* opts = 0;
 		av_dict_set(, "strict", "-2", 0);
 		if (encoder->context->oformat->flags & AVFMT_GLOBALHEADER) {
-			encoder->audio->flags |= CODEC_FLAG_GLOBAL_HEADER;
+			encoder->audio->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
 		}
 		avcodec_open2(encoder->audio, acodec, );
 		av_dict_free();
@@ -291,7 +291,7 @@ bool FFmpegEncoderOpen(struct FFmpegEnco
 	encoder->video->gop_size = 60;
 	encoder->video->max_b_frames = 3;
 	if (encoder->context->oformat->flags & AVFMT_GLOBALHEADER) {
-		encoder->video->flags |= CODEC_FLAG_GLOBAL_HEADER;
+		encoder->video->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
 	}
 	if (strcmp(vcodec->name, "libx264") == 0) {
 		// Try to adaptively figure out when you can use a slower encoder


signature.asc
Description: OpenPGP digital signature

Bug#891091: git-buildpackage: pristine-tar uses unreachable tree for main tarball when components exist

[James Cowgill]

Package: git-buildpackage
Version: 0.9.7
Severity: normal

Hi,

I am attempting to use git-buildpackage and pristine-tar with a package
which uses multiple components. Unfortunately if I clone the repository,
pristine-tar fails to generate the main tarball:

> $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> pristine-tar: successfully generated ffdiaporama_2.1+dfsg.orig-rsc.tar.gz
> $ pristine-tar checkout ffdiaporama_2.1+dfsg.orig.tar.gz
> fatal: ambiguous argument '81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53^{tree}': 
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
> fatal: Not a valid object name
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> pristine-tar: command failed: git archive --format=tar 
> 81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53\^\{tree\} | (cd 
> '/tmp/pristine-tar.KmsGn7eSaa' && tar x)

The mentioned tree (81c0361de57e9e6c6dc8bf6cd6e9ba6697fb6e53) does not
exist in the cloned repository but does in the original repository.

I found this which looks to me exactly the same situation I am in, but I
could not find a Debian bug so I am filing one now:

https://lists.sigxcpu.org/pipermail/git-buildpackage/2017-June/000223.html

The gist is that pristine-tar is given a tree object for the main
tarball without the extra component tarballs, but this tree object is
never present in the upstream branch and is unreachable from any tags. I
guess the easiest solution is to pass the final upstream tree (with all
the components) to pristine-tar when generating the main tarball. This
might give bigger deltas, but when I tested it with ffdiaporama the
delta was only a few hundred bytes larger so maybe it's not a big
problem.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#891047: uscan: version mode "same" does not work with --download-current-version

[James Cowgill]

Package: devscripts
Version: 2.17.12
Severity: normal

Hi,

The following watch file which uses the "same" version mode does not
work when --download-current-version is specified. It does work on a
normal uscan invocation however (eg with --force-download).

(at the time the version in debian/changelog was "2.1-1")

> $ cat debian/watch 
> version=4
> opts="dversionmangle=s/\+dfsg\d*$//,uversionmangle=s/\.2014\.0209//,oversionmangle=s/$/+dfsg/"
>  \
>  
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_@ANY_VERSION@@ARCHIVE_EXT@
> opts="dversionmangle=s/\+dfsg\d*$//,uversionmangle=s/\.2014\.0209//,oversionmangle=s/$/+dfsg/,component=rsc"
>  \
>  
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_rsc_@ANY_VERSION@@ARCHIVE_EXT@
>  same
> $ uscan --verbose --download-current-version
> uscan info: uscan (version 2.17.12) See uscan(1) for help
> uscan info: Scan watch files in .
> uscan info: Check debian/watch and debian/changelog in .
> uscan info: package="ffdiaporama" version="2.1-1" (as seen in 
> debian/changelog)
> uscan info: package="ffdiaporama" version="2.1" (no epoch/revision)
> uscan info: ./debian/changelog sets package="ffdiaporama" version="2.1"
> uscan info: Process ./debian/watch (package=ffdiaporama version=2.1)
> uscan info: opts: 
> dversionmangle=s/\+dfsg\d*$//,uversionmangle=s/\.2014\.0209//,oversionmangle=s/$/+dfsg/
> uscan info: line: 
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
> uscan info: Parsing dversionmangle=s/\+dfsg\d*$//
> uscan info: Parsing uversionmangle=s/\.2014\.0209//
> uscan info: Parsing oversionmangle=s/$/+dfsg/
> uscan info: line: 
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
> uscan info: Last orig.tar.* tarball version (from debian/changelog): 2.1
> uscan info: Download the --download-current-version specified version: 2.1
> uscan info: Requesting URL:
>https://download.tuxfamily.org/ffdiaporama/Packages/Stable/
> uscan info: Matching pattern:
>
> (?:(?:https://download.tuxfamily.org)?\/ffdiaporama\/Packages\/Stable\/)?ffdiaporama_bin_[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
> uscan info: Found the following matching hrefs on the web page (newest first):
>ffdiaporama_bin_2.1.2014.0209.tar.gz (2.1) index=2.1-1 matched with the 
> download version
> uscan info: Matching target for downloadurlmangle: 
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: Upstream URL (downloadurlmangled):
>
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: Newest upstream tarball version selected for download 
> (uversionmangled): 2.1
> uscan info: Download filename (filenamemangled): 
> ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan: Newest version of ffdiaporama on remote site is 2.1, specified 
> download version is 2.1
> uscan info: Downloading upstream package: ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: Requesting URL:
>
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: Successfully downloaded package: 
> ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: Start checking for common possible upstream OpenPGP signature 
> files
> uscan info: End checking for common possible upstream OpenPGP signature files
> uscan info: Missing OpenPGP signature.
> uscan info: New orig.tar.* tarball version (oversionmangled): 2.1+dfsg
> uscan info: Executing internal command:
>mk-origtargz --package ffdiaporama --version 2.1+dfsg --compression gzip 
> --directory .. --copyright-file debian/copyright 
> ../ffdiaporama_bin_2.1.2014.0209.tar.gz
> uscan info: New orig.tar.* tarball version (after mk-origtargz): 2.1+dfsg
> uscan info: Successfully symlinked ../ffdiaporama_bin_2.1.2014.0209.tar.gz to 
> ../ffdiaporama_2.1+dfsg.orig.tar.gz.
> uscan info: opts: 
> dversionmangle=s/\+dfsg\d*$//,uversionmangle=s/\.2014\.0209//,oversionmangle=s/$/+dfsg/,component=rsc
> uscan info: line: 
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_rsc_[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
>  same
> uscan info: Parsing dversionmangle=s/\+dfsg\d*$//
> uscan info: Parsing uversionmangle=s/\.2014\.0209//
> uscan info: Parsing oversionmangle=s/$/+dfsg/
> uscan info: Parsing component=rsc
> uscan info: line: 
> https://download.tuxfamily.org/ffdiaporama/Packages/Stable/ffdiaporama_rsc_[-_]?(\d[\-+\.:\~\da-zA-Z]*)(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
>  same
> uscan info: Last orig.tar.* tarball version (from debian/changelog): 
> uscan info: Download the --download-current-version specified version: 
> uscan info: Requesting URL:
>https://download.tuxfamily.org/ffdiaporama/Packages/Stable/
> 

Bug#890918: mpv produces the image with numerous complaints.

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On 20/02/18 16:30, pe...@easthope.ca wrote:
> Package: mpv
> Version: 0.23.0-2+deb9u2
> Severity: normal
> Tags: upstream

You tagged the bug "upstream". This tag usually means that the bug is
known to be in upstream mpv. How do you know this?

> Dear Maintainer,
> 
>* What led up to the situation?
>  Display of output from a Logitech camera
>  M/N: V-U0006
>  P/N: 860-000177
>  PID: LZ944BN
>* What exactly did you do (or not do) that was effective (or ineffective)?
>   Connected USB and executed "mpv tv:// --tv-device=/dev/video0"
>   on two similar systems, imager and dalton.  Transcripts appended.

Does ffmpeg's v4l2 support work better?
 mpv -v av://v4l2:/dev/video0

I should point out that all the code for tv:// has been removed in
upstream mpv, so if this is a bug in mpv, it is unlikely to be fixed
(upstream now tells you to use the av:// form above).

I don't know what "imager" and "dalton" mean. Do they have identical
versions of mpv and identical kernels (probably the 2 most important
bits here)?

Please recreate the transcripts with the -v option to get more verbosity.

Testing with newer kernels and mpv versions would be helpful, but this
might be a bit harder.

>   Note the differences from the same procedure on two almost idential 
>   systems.  Eg. 
>   [tv]  Current format: YUYV
>   versus
>   [tv]  Current format: MJPEG
>* What was the outcome of this action?
>The images appeared with numerous complaints. Eg. 
>[tv] ioctl enum norm failed: Inappropriate ioctl for device
>[tv] Error: Cannot set norm!
>* What outcome did you expect instead?
>A concise and tidy report to the terminal with no complaints, errors 
> or warnings.
>In the present state, the software is not good release quality.

Does your webcam actually play in mpv? Is it just the log messages that
bother you?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890832: gdbm-l10n: should not be priority important

[James Cowgill]

Package: gdbm-l10n
Version: 1.14.1-3
Severity: important
X-Debbugs-CC: locutusofb...@debian.org

Hi,

I noticed that debootstrap started installing the "gdbm-l10n" package
into all new Debian installations. This doesn't look right to me, so I
think the package priority should be changed to optional.

Since policy 4.0.1, library packages should all be priority optional, so
you might take this chance to downgrade libgdbm5.

Remember to file an override bug against ftp.debian.org after changing
package priorities in the uploaded debs.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890411: Bug890411: flex: backported commit causes FTBFS (and potentially miscompilation) of generated files

[James Cowgill]

Control: reopen -1

Hi,

The fix for this bug in 2.6.4-4 isn't good enough to fix the build of
charybdis. charybdis uses some extra types (like u_int) which are not
defined by glibc if strict POSIX compliance is enabled (which is what
_POSIX_C_SOURCE does).

I think defining _DEFAULT_SOURCE should fix this. In glibc, defining
_DEFAULT_SOURCE will also enable POSIX 2008 functions (but will not
disable anything) so you may be able to drop the other defines. However,
this is not a general upstreamable solution because this macro is not
available in other C libraries (or is called something else).

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890703: flex: all amd64 binaries since 2.6.4-1 built with stale skel.c file

[James Cowgill]

Package: flex
Version: 2.6.4-1
Severity: important

Hi,

I spent some time today looking at why charybdis still fails with newer
flex (since it is blocking my mbedtls transition)[1]. I also had a look
at why it inexplicably builds with amd64 and fails on all other
architectures. I have come to the conclusion that the only way this can
happen is if the amd64 binary was not built in a clean environment and
probably contains a stale "src/skel.c" file.

Running "flex ircd_lexer.l" (from charybdis) using the flex 2.6.4-4
binaries on amd64 and i386 respectively gives this diff which is the
cause if the current failures[2]:

> --- charybdis-cy4e9N/charybdis-3.5.5/src/lex.yy.c   2018-02-17 
> 19:07:14.334607450 +
> +++ charybdis-gRy7cn/charybdis-3.5.5/src/lex.yy.c   2018-02-17 
> 18:38:46.253775565 +
> @@ -16,6 +16,12 @@
>  /* First, we deal with  platform-specific or compiler-specific issues. */
>  
>  /* begin standard C headers. */
> +#ifndef _POSIX_C_SOURCE
> +#define _POSIX_C_SOURCE 200809 /* for fileno() */
> +#ifndef _POSIX_SOURCE
> +#define _POSIX_SOURCE 1
> +#endif
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -556,8 +562,8 @@

Simply rebuilding flex on amd64 and rerunning the above test makes the
diff go away.

This code is embedded into the flex binary, so you can tell if a binary
is bad by running:
 strings /usr/bin/flex | grep POSIX_C_SOURCE

The good binary gives:
> #define _POSIX_C_SOURCE 200809 /* for fileno() */
> [[#ifndef _POSIX_C_SOURCE

Bad binaries print nothing.

Given that this bug is present in 4 debs so far (I cannot check the
binary currently in NEW), binNMUing the package won't fix it for good
(since the next upload will probably be bad). Possible improvements:
forcing skel.c to always be rebuilt, or using source only uploads.

Thanks,
James

[1] https://buildd.debian.org/status/package.php?p=charybdis
[2] charybdis uses certain old BSD defines which are only available
if _POSIX_SOURCE is not defined.



signature.asc
Description: OpenPGP digital signature

Bug#890569: aseba: FTBFS on mips(64)el: Valgrind: Loongson-baseline unsupported

[James Cowgill]

Hi,

On 16/02/18 02:23, Aaron M. Ucko wrote:
> Source: aseba
> Version: 1.6.0-2
> Severity: important
> Tags: upstream
> Justification: fails to build from source
> User: debian-m...@lists.debian.org
> Usertags: mips64el mipsel
> 
> Builds of aseba on mips(64)el against non-broken versions of
> libdashel-dev [1][2] failed with errors running aseba-test-invalid-utf8
> under Valgrind:
> 
> 1/172 Test   #1: aseba-test-invalid-utf8 
> ***Failed0.31 sec
>   ==535== Memcheck, a memory error detector
>   [...]
>   VEX: Unsupported baseline
>Found: Loongson-baseline
> 
> I see an upstream Valgrind bug report [3] that may be relevant here;
> until such time as that fix reaches Debian, please consider doing
> without Valgrind on these architectures.
[...]
> [3] https://bugs.kde.org/show_bug.cgi?id=387410

I don't think that bug has anything to do with this.

I think Loongson support is missing in Valgrind because it has lots of
extra instructions and a few quirks which would need emulating. No one
has implemented these yet.

James



signature.asc
Description: OpenPGP digital signature

Bug#881342: rtkit: should depend on dbus and polkit

[James Cowgill]

Control: severity -1 serious
Control: retitle -1 rtkit: should depend on dbus and polkit

Hi,

On 05/02/18 15:18, Алексей Шилин wrote:
> reassign 881342 rtkit 0.11-4
> thanks
> 
> After a bit of investigation, I've found that the source of the issue is 
> actually
> the rtkit package.
> 
> rtkit postinst script contains the following lines added by debhelper:
> 
> # Automatically added by dh_systemd_start
> if [ -d /run/systemd/system ]; then
> systemctl --system daemon-reload >/dev/null || true
> deb-systemd-invoke start rtkit-daemon.service >/dev/null || true
> fi
> # End automatically added section
> 
> Here rtkit-daemon service, which is of Type=dbus, is being started at package
> configuration phase.
> 
> systemd.service(5) says [1]:
> 
> The following dependencies are implicitly added:
> 
> * Services with Type=dbus set automatically acquire dependencies of 
> type 
>   Requires= and After= on dbus.socket.
> 
> So starting rtkit-daemon.service activates dbus.socket which in turn leads to
> dbus.service activation when the rtkit daemon tries to connect to the bus.
> The issue here is that rtkit currently only recommends dbus, which doesn't
> guarantee proper ordering i.e. rtkit may be scheduled to be configured 
> *before*
> dbus and thus start the latter before its configuration (which includes the 
> system
> user creation) is complete, leading to the reported issue.

As I said on IRC, I can't think of any scenario where rtkit is useful
without dbus and polkit. Without dbus, rtkit won't start at all.
Withouut polkit, rtkit will start but will refuse to make any processes
realtime and is therefore a bit useless.

In my opinion, this bug is RC because rtkit needs to depend on these
packages to function. If someone can think of a way to use rtkit without
these packages then I may change my mind :)

> This issue should affect only stretch because according to its changelog 
> rtkit is
> no longer started by default since 0.11-5. Whether the version in stable 
> should
> be fixed is up to its maintainer. I've attached a patch which moves dbus from
> Recommends to Depends, fixing the issue.

While the installation issue only affects stretch, starting rtkit
manually without dbus installed is still broken in unstable so it should
also be fixed there.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890586: rtkit: Homepage URL is dead

[James Cowgill]

Source: rtkit
Version: 0.11-5
Severity: minor

Hi,

The homepage URL listed in the rtkit package is dead:
> $ wget http://0pointer.de/public/
> --2018-02-16 10:32:12--  http://0pointer.de/public/
> Resolving 0pointer.de (0pointer.de)... 85.214.157.71, 
> 2a01:238:43ed:c300:10c3:bcf3:3266:da74
> Connecting to 0pointer.de (0pointer.de)|85.214.157.71|:80... connected.
> HTTP request sent, awaiting response... 403 Forbidden
> 2018-02-16 10:32:12 ERROR 403: Forbidden.

It might be better to set it to the upstream git repo:
http://git.0pointer.net/rtkit.git/

James



signature.asc
Description: OpenPGP digital signature

Bug#890448: transition: mbedtls

[James Cowgill]

On 15/02/18 17:47, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 14/02/18 22:01, James Cowgill wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi,
>>
>> mbedtls bumped the SONAME of one of its libraries (libmbedcrypto) so it
>> needs a transition. The new version is currently in experimental.
>>
>> These reverse dependencies built successfully first time:
>> charybdis
>> dislocker
>> dolphin-emu
>> gatling
>> ncbi-vdb
>> neko
>> shadowsocks-libev
>>
>> bctoolbox was fixed about an hour ago (#890417).
>>
>> mongrel2 still fails, but this is caused by an mbedtls bug which I have
>> queued up ready to upload (the fix is obvious):
>> https://salsa.debian.org/debian/mbedtls/commit/f2769d8c7cb1edb2a8e6fb3e6d8527638550927d
> 
> Go ahead.

Thanks. I've uploaded it.

James



signature.asc
Description: OpenPGP digital signature

Bug#890448: transition: mbedtls

[James Cowgill]

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

Hi,

mbedtls bumped the SONAME of one of its libraries (libmbedcrypto) so it
needs a transition. The new version is currently in experimental.

These reverse dependencies built successfully first time:
charybdis
dislocker
dolphin-emu
gatling
ncbi-vdb
neko
shadowsocks-libev

bctoolbox was fixed about an hour ago (#890417).

mongrel2 still fails, but this is caused by an mbedtls bug which I have
queued up ready to upload (the fix is obvious):
https://salsa.debian.org/debian/mbedtls/commit/f2769d8c7cb1edb2a8e6fb3e6d8527638550927d

Thanks,
James

Ben file:

title = "mbedtls";
is_affected = .depends ~ "libmbedcrypto0" | .depends ~ "libmbedcrypto1";
is_good = .depends ~ "libmbedcrypto1";
is_bad = .depends ~ "libmbedcrypto0";


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



signature.asc
Description: OpenPGP digital signature

Bug#890417: bctoolbox: FTBFS with mbedtls 2.7.0

[James Cowgill]

Source: bctoolbox
Version: 0.6.0-1
Severity: important
Tags: sid buster

Hi,

mongrel2 FTBFS when compiled against mbed TLS 2.7. This version fixes
some security issues, so I would like to upload it reasonably quickly.
This is the only package which FTBFS with the new version.

Build log extract (full log attached):
> /<>/src/crypto/mbedtls.c:421:4: error: 'mbedtls_sha1' is 
> deprecated [-Werror=deprecated-declarations]
> mbedtls_sha1(crt->raw.p, crt->raw.len, buffer);
> ^~~~
> In file included from /<>/src/crypto/mbedtls.c:38:0:
> /usr/include/mbedtls/sha1.h:320:39: note: declared here
>  MBEDTLS_DEPRECATED static inline void mbedtls_sha1( const unsigned char 
> *input,
>^~~~
> /<>/src/crypto/mbedtls.c:427:4: error: 'mbedtls_sha256' is 
> deprecated [-Werror=deprecated-declarations]
> mbedtls_sha256(crt->raw.p, crt->raw.len, buffer, 1); /* last argument is 
> a boolean, indicate to output sha-224 and not sha-256 */
> ^~
> In file included from /<>/src/crypto/mbedtls.c:39:0:
> /usr/include/mbedtls/sha256.h:279:39: note: declared here
>  MBEDTLS_DEPRECATED static inline void mbedtls_sha256(
>^~

I am guessing that disabling -Werror will fix this.

Thanks,
James
dpkg-buildpackage: info: source package bctoolbox
dpkg-buildpackage: info: source version 0.6.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Bernhard Schmidt 
 dpkg-source --before-build bctoolbox-0.6.0
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --buildsystem=cmake
   dh_auto_clean -O--buildsystem=cmake
   dh_clean -O--buildsystem=cmake
 debian/rules build-arch
dh build-arch --buildsystem=cmake
   dh_update_autotools_config -a -O--buildsystem=cmake
   dh_autoreconf -a -O--buildsystem=cmake
aclocal: warning: couldn't open directory 'm4': No such file or directory
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:25: installing './compile'
configure.ac:23: installing './config.guess'
configure.ac:23: installing './config.sub'
configure.ac:30: installing './install-sh'
configure.ac:30: installing './missing'
src/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DCMAKE_SKIP_RPATH=ON -DENABLE_TESTS_COMPONENT=OFF
cd obj-x86_64-linux-gnu && cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_SKIP_RPATH=ON 
-DENABLE_TESTS_COMPONENT=OFF
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE) (Required is at least version 
"1.7.10")
-- Setting install rpath to /usr/lib/x86_64-linux-gnu
-- Looking for mbedtls_ssl_init
-- Looking for mbedtls_ssl_init - found
-- Looking for mbedtls_ssl_get_dtls_srtp_protection_profile
-- Looking for mbedtls_ssl_get_dtls_srtp_protection_profile - not found
-- Found MbedTLS: /usr/include  
-- Using mbedTLS
-- DTLS SRTP not available
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for dladdr in dl
-- Looking for dladdr in dl - found
-- Looking for execinfo.h
-- Looking for execinfo.h - found
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   dh_auto_build -a 

Bug#890410: mpv: fix for CVE-2018-6360 overlooks subtitles

[James Cowgill]

Package: mpv
Version: 0.23.0-1
Severity: grave
Tags: security upstream

Yet another bug relating to the fix for CVE-2018-6360...

This time the bug is not a regression, but a mistake upstream made when
writing the original patch. Upstream overlooked the handling of subtitle
URLs which were not protected.

Upstream has released 0.27.2 and 0.28.2 to fix these. I think the bug
affects 0.23 as well (but I have not yet checked).

Possibly this warrants a new CVE number.

Upstream commit:
https://github.com/mpv-player/mpv/commit/3e71eb8676de53a05f51b987d294e7d2fa0a5bc1

James



signature.asc
Description: OpenPGP digital signature

Bug#890407: milkytracker: various buffer overflows possibly leading to remote code execution

[James Cowgill]

Package: milkytracker
Severity: grave
Tags: security upstream

Forwarding this bug sent to me by Johannes Schultz. It sounds bad. I
have not investigated it (and I don't know if it affects the pre-1.0
version in stable or not)

 Forwarded Message 
Subject: MilkyTracker - critical patches
Date: Wed, 14 Feb 2018 13:39:45 +0100
From: Johannes Schultz 
To: jcowg...@debian.org

Hi James,
I have recently fixed a bunch of very obvious and at the same time very
dangerous bugs in various module loaders in MilkyTracker, most of them
leading to out-of-bond writes both on the heap and stack. I think most
of them would be suitable for remote code execution.
You can find them here:
https://github.com/milkytracker/MilkyTracker/commit/6f7922616f31e5ceddd6f346cfc7f5d61a2f7683
You will also see the individual commits in the commit timeline around
October 2017.
I don't know if there is any immediate release planned by Deltafire, so
I recommend you to update the Debian packages based on those patches ASAP.
The individual diffs can also be found here:
https://sagagames.de/stuff/mt-patches.zip
They should apply to all MilkyTracker versions supported by the various
Debian releases, not just 1.01.00.

Best regards,
Johannes / OpenMPT Dev (and occasionall MilkyTracker bugfixer ;)



signature.asc
Description: OpenPGP digital signature

Bug#890318: util-linux: FTBFS on big endian - sha1/sha1 test fails

[James Cowgill]

Source: util-linux
Version: 2.31.1-0.1
Severity: serious
Tags: sid buster fixed-upstream

Hi,

util-linux FTBFS on all big endian architectures with this testsuite failure:>  
script: /«PKGBUILDDIR»/tests/ts/sha1/sha1
> sub dir: /«PKGBUILDDIR»/tests/ts/sha1
> top dir: /«PKGBUILDDIR»/tests
>self: /«PKGBUILDDIR»/tests/ts/sha1
>   test name: sha1
>   test desc: sha1
>   component: sha1
>   namespace: sha1/sha1
> verbose: yes
>  output: /«PKGBUILDDIR»/tests/output/sha1/sha1
>valgrind: /«PKGBUILDDIR»/tests/output/sha1/sha1.vgdump
>expected: /«PKGBUILDDIR»/tests/expected/sha1/sha1
>  mountpoint: /«PKGBUILDDIR»/tests/output/sha1/sha1-mnt
> 
>  sha1: sha1   ... FAILED (sha1/sha1)
> = script: /«PKGBUILDDIR»/tests/ts/sha1/sha1 =
> = OUTPUT =
>  19844f81e1408f6ecb932137d33bed7cfdcf518a3
>  214c20690f653fb16396e4f804c9dafb46e513d4f
>  3b39356f080492701e97317f88ca581acffae89cf
>  45e7c72295e61b1f0d733e6485bac4237b17d293a
>  597faba6b0f94c599ad7dd08a8801b7e7f4994b15
>  608b5f5340abf513bc11f824daea8828bb00c4541
>  76d49c77f9f4fbb8ef5fd4db0bd3cad4111dcf1c3
> = EXPECTED ===
>  1da39a3ee5e6b4b0d3255bfef95601890afd80709
>  2a9993e364706816aba3e25717850c26c9cd0d89d
>  3da3175a32e6c1aacfd3d3f35770188ae0ab6d078
>  47496226c17d4d0a770cea72eebb659c16753b956
>  5db50ea8b1b20567cd4d8a7fa14de8d37ce9b722c
>  690e072e1df8de879ca307610d5ced675af55a4ac
>  72eda696c8df17722d80518bebb33742e311a4ac1
> = O/E diff ===
> --- /«PKGBUILDDIR»/tests/output/sha1/sha1 2018-02-09 19:15:42.389991140 
> +
> +++ /«PKGBUILDDIR»/tests/expected/sha1/sha1   2017-12-21 14:44:24.0 
> +
> @@ -1,7 +1,7 @@
> -9844f81e1408f6ecb932137d33bed7cfdcf518a3
> -14c20690f653fb16396e4f804c9dafb46e513d4f
> -b39356f080492701e97317f88ca581acffae89cf
> -5e7c72295e61b1f0d733e6485bac4237b17d293a
> -97faba6b0f94c599ad7dd08a8801b7e7f4994b15
> -08b5f5340abf513bc11f824daea8828bb00c4541
> -6d49c77f9f4fbb8ef5fd4db0bd3cad4111dcf1c3
> +da39a3ee5e6b4b0d3255bfef95601890afd80709
> +a9993e364706816aba3e25717850c26c9cd0d89d
> +da3175a32e6c1aacfd3d3f35770188ae0ab6d078
> +7496226c17d4d0a770cea72eebb659c16753b956
> +db50ea8b1b20567cd4d8a7fa14de8d37ce9b722c
> +90e072e1df8de879ca307610d5ced675af55a4ac
> +2eda696c8df17722d80518bebb33742e311a4ac1
> ==

I think this if fixed by this upstream commit:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=4ff4b1106e8c6a71cce59ca40a2019342a92d47d

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890288: mbedtls: CVE-2018-0487 - Risk of remote code execution when verifying RSASSA-PSS signatures

[James Cowgill]

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

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

Vulnerability
When RSASSA-PSS signature verification is enabled, sending a maliciously
constructed certificate chain can be used to cause a buffer overflow on
the peer's stack, potentially leading to crash or remote code execution.
This can be triggered remotely from either side in both TLS and DTLS.

RSASSA-PSS is the part of PKCS #1 v2.1 standard and can be enabled by
the compile time option MBEDTLS_PKCS1_V21 in config.h. If
MBEDTLS_PKCS1_V21 is disabled when compiling the library, then the
vulnerability is not present. RSASSA-PSS signatures are enabled in the
default configuration.

Impact
Depending on the platform, an attack exploiting this vulnerability could
lead to an application crash or remote code execution.

Resolution
Affected users should upgrade to Mbed TLS 1.3.22, Mbed TLS 2.1.10 or
Mbed TLS 2.7.0.

Workaround
Users should wherever possible upgrade to the newer version of Mbed TLS.
Where this is not practical, users should consider if disabling the
option MBEDTLS_PKCS1_V21 in the Mbed TLS configuration is practical for
their application. Disabling RSASSA-PSS signatures in the verification
profile at runtime is not a sufficient countermeasure.



signature.asc
Description: OpenPGP digital signature

Bug#890289: bibledit: embeds mbedtls - vulnerable to CVE-2017-2784, CVE-2017-14032, CVE-2018-0487, CVE-2018-0488

[James Cowgill]

Source: bibledit
Version: 5.0.331-1
Severity: grave
Tags: security

Hi,

I notice bibledit embeds mbed TLS 2.2.1. The embedded version is
vulnerable to at least these CVEs (based on the version number and
assuming they have not been manually patched):
 CVE-2017-2784
 CVE-2017-14032
 CVE-2018-0487
 CVE-2018-0488

[disclaimer: the mbedtls package is still vulnerable to the last two,
but I am working on fixing those]

I see you have overridden lintian which warns you about this:
> # For just now the mbed TLS library is included.
> # When using the system-provided libmbedtls, there currently is a 
> segmentation fault.
> # Pending investigation of this fault, temporarily include mbed TLS.
> # Here is the link to the issue: 
> https://github.com/bibledit/bibledit/issues/499
> # By the way, isn't it called "mbed" TLS, obviously intended to be "embedded"?
> # So Bibledit is doing that right now, it "embeds" mbed TLS.
> bibledit: embedded-library usr/bin/bibledit: mbedtls

"mbed" is the brand name ARM uses for its IOT operating system (of which
mbedtls is a component) and therefore is derived from "embedded systems".

IMO embedding a security library is unacceptable and the package should
not be in a stable release in its current state.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890287: mbedtls: CVE-2018-0488 - Risk of remote code execution when truncated HMAC is enabled

[James Cowgill]

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

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

Vulnerability
When the truncated HMAC extension is enabled and CBC is used, sending a
malicious application packet can be used to selectively corrupt 6 bytes
on the peer's heap, potentially leading to a crash or remote code
execution. This can be triggered remotely from either side in both TLS
and DTLS.

If the truncated HMAC extension, which can be set by the compile time
option MBEDTLS_SSL_TRUNCATED_HMAC in config.h, is disabled when
compiling the library, then the vulnerability is not present. The
truncated HMAC extension is enabled in the default configuration.

The vulnerability is only present if
* The compile-time option MBEDTLS_SSL_TRUNCATED_HMAC is set in config.h.
  (It is set by default) AND
* The truncated HMAC extension is explicitly offered by calling
  mbedtls_ssl_conf_truncated_hmac(). (It is not offered by default)

Impact
Depending on the platform, an attack exploiting this vulnerability could
lead to an application crash or allow remote code execution.

Resolution
Affected users should upgrade to Mbed TLS 1.3.22, Mbed TLS 2.1.10 or
Mbed TLS 2.7.0.

Workaround
Users should wherever possible upgrade to the newer version of Mbed TLS.
Where this is not practical, users should consider disabling the
truncated HMAC extension by removing any call to
mbedtls_ssl_conf_truncated_hmac() in their application, and the option
MBEDTLS_SSL_TRUNCATED_HMAC in the Mbed TLS configuration is practical
for their application.



signature.asc
Description: OpenPGP digital signature

Bug#888348: lives: FTBFS with FFmpeg 3.5

[James Cowgill]

Control: tags -1 fixed-upstream

Hi,

On 12/02/18 00:51, salsaman wrote:
> Sorry,  my bad: I forgot to update the constants in the .h files. I was
> looking in the .c files by mistake.
> 
> Also, I think it should be AV_CODEC_ID_* in the headers (although
> AV_CODEC_* seemed to work too).

Thanks. All the errors are fixed now.

James



signature.asc
Description: OpenPGP digital signature

Bug#890250: abcmidi: valgrind errors running conversions autopkgtest

[James Cowgill]

On 12/02/18 13:31, James Cowgill wrote:
> While looking at #890023, I ran the commands from the "conversions" test
> in valgrind and saw these errors (besides the one relating to #890023).
> I have not investigated them, but they probably indicate some bug.

For reference, these were run on i386.

James



signature.asc
Description: OpenPGP digital signature

Bug#890250: abcmidi: valgrind errors running conversions autopkgtest

[James Cowgill]

Package: abcmidi
Version: 20180125-1
Severity: important

Hi,

While looking at #890023, I ran the commands from the "conversions" test
in valgrind and saw these errors (besides the one relating to #890023).
I have not investigated them, but they probably indicate some bug.

abc2midi araber.abc:
> ==30555== Conditional jump or move depends on uninitialised value(s)
> ==30555==at 0x1191E5: tiefix (store.c:4839)
> ==30555==by 0x1191E5: finishfile (store.c:5856)
> ==30555==by 0x11AEEA: event_blankline (store.c:5920)
> ==30555==by 0x10DE5C: parseline (parseabc.c:2768)
> ==30555==by 0x10E243: parsefile (parseabc.c:2947)
> ==30555==by 0x109153: main (store.c:6021)

yaps araber.abc:
> ==30607== Conditional jump or move depends on uninitialised value(s)
> ==30607==at 0x1195E0: beamline (drawtune.c:2422)
> ==30607==by 0x1195E0: finalsizeline (drawtune.c:3313)
> ==30607==by 0x1195E0: finalsizetune (drawtune.c:3345)
> ==30607==by 0x1195E0: printtune (drawtune.c:3484)
> ==30607==by 0x10FDDE: event_blankline (yapstree.c:1290)
> ==30607==by 0x10D95C: parseline (parseabc.c:2768)
> ==30607==by 0x10DD43: parsefile (parseabc.c:2947)
> ==30607==by 0x108C6A: main (yapstree.c:3001)

James



signature.asc
Description: OpenPGP digital signature

Bug#890023: abcmidi fails autopkg tests on 32bit architectures

[James Cowgill]

Control: tags -1 patch

Hi,

On 10/02/18 08:52, Matthias Klose wrote:
> Package: src:abcmidi
> Version: 20180125-1
> Severity: serious
> Tags: sid buster
> 
> abcmidi fails autopkg tests on 32bit architectures, midi2abc crashing.  Is 
> there
> a reason why the tests are not run at build time?
> 
> 
> MIDI to ABC conversion test
> 
> Convert the araber47.mid file back to abc
> Aborted (core dumped)
> autopkgtest [14:08:29]: test conversions: ---]
> autopkgtest [14:08:33]: test conversions:  - - - - - - - - - - results - - - 
> - -
> - - - - -
> conversions  FAIL non-zero exit status 134
> autopkgtest [14:08:33]: test conversions:  - - - - - - - - - - stderr - - - - 
> -
> - - - - -
> *** Error in `midi2abc': free(): invalid pointer: 0x00c43f28 ***
> Aborted (core dumped)

Caused by a buffer overflow in midi2abc.c:329
> char* addstring(s)
> /* create space for string and store it in memory */
> char* s;
> {
>   char* p;
> 
>   p = (char*) checkmalloc(strlen(s)+1);
>   strncpy(p, s,strlen(s)+2); /* [SS] 2017-08-30 */
>   return(p);
> }

strncpy writes to exactly n bytes to the output buffer, so the call will
always overflow the buffer allocated one line above by 1 byte.

Attached patch fixes this. I think using strcpy is safe here because the
size of the buffer allocated is always greater than the string length.

I think the comment on that line refers to this (from doc/CHANGES):
> August 30 2017
> 
> Midi2abc - The metatext string is not terminated with a 0 and
> as a result can contain random junk, in particular on the Windows
> operating system. Fix in midifile.c, the Msgbuff is initialized to
> 0 when it is allocated.

Some old code I found shows the code originally used strcpy. I'm not I
understand how using strncpy was supposed to fix this. I've copied
upstream who might be able to shed some light on this.

Thanks,
James
--- a/midi2abc.c
+++ b/midi2abc.c
@@ -333,7 +333,7 @@ char* s;
   char* p;
 
   p = (char*) checkmalloc(strlen(s)+1);
-  strncpy(p, s,strlen(s)+2); /* [SS] 2017-08-30 */
+  strcpy(p, s);
   return(p);
 }
 


signature.asc
Description: OpenPGP digital signature

Bug#888348: lives: FTBFS with FFmpeg 3.5

[James Cowgill]

On 11/02/18 23:49, salsaman wrote:
> Please check that you are compiling with the current versions of those
> files. There are no instances of CODEC_* any more in those files.
> 

I see them here, am I looking at the wrong place?
https://sourceforge.net/p/lives/code/HEAD/tree/trunk/lives-plugins/plugins/decoders/mkv_decoder.h#l883

James



signature.asc
Description: OpenPGP digital signature

Bug#888348: lives: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 04/02/18 18:10, salsaman wrote:
> I believe all the issues noted should be fixed now. You will need to
> replace the follwoing files:
> configure.ac
> libweed/weed-compat.h
> libweed/weed-compat.pc
> plugins/decoders/*
> 
> (the weed-compat changes are unrelated, but you will need to update them to
> compile the current decoder plugins).

Sorry for the delay in replying. I tried compiling trunk again but there
are still some errors. Thankfully these are just the CODEC_ to AV_CODEC_
constant renames. Running the following fixes these for me:

sed -i 's/CODEC_/AV_CODEC_/g' lives-plugins/plugins/decoders/mkv_decoder.h
sed -i 's/CODEC_/AV_CODEC_/g' lives-plugins/plugins/decoders/mpegts_decoder.h

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890205: [mpv] relocation error

[James Cowgill]

Hi,

On 11/02/18 21:19, Paolo Redaelli wrote:
> Package: mpv
> Version: 0.27.0-4
> Severity: important
> 
> --- Please enter the report below this line. ---
> 
> It doesn't even start:
> 
> mpv: relocation error: /usr/lib/x86_64-linux-gnu/libavfilter.so.6:
> symbol av_hwframe_map, version LIBAVUTIL_55 not defined in file
> libavutil.so.55 with link time reference

Does ffmpeg (the command tool) work (try "ffmpeg -version")?

Please give the output of:
  ldd /usr/bin/mpv
  dpkg -l libavfilter6 libavutil55

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889987: steam: depends on non-existent libtxc-dxtn0

[James Cowgill]

Control: retitle -1 steam: depends on non-existent libtxc-dxtn0

Hi,

On 09/02/18 19:44, Stephen Kitt wrote:
> Hi Jörg,
> 
> On Fri, 09 Feb 2018 19:39:39 +0100, Jörg Frings-Fürst 
> wrote:
>> on a fresh buster, sid install I get on
>>
>> $ sudo apt-get install steam
> [...]
>> Die folgenden Pakete haben unerfüllte Abhängigkeiten:
>>  steam:i386 : Hängt ab von: libc6:i386 (>= 2.15) soll aber nicht installiert
>> werden
>>   Hängt ab von: libstdc++6:i386 (>= 4.3) soll aber nicht
>> installiert werden
>>   Hängt ab von: libx11-6:i386 soll aber nicht installiert werden
>>   Hängt ab von: libudev1:i386 soll aber nicht installiert werden
>>   Hängt ab von: libxinerama1:i386 soll aber nicht installiert
>> werden
>>   Hängt ab von: libtxc-dxtn0:i386

The only package which provided this library was removed at the end of
January:
https://tracker.debian.org/pkg/s2tc
https://tracker.debian.org/news/928386

I guess only main was checked so noone realized steam (in non-free)
still depended on it :/

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889915: libfaad2 in Wheezy contains patches for some security bugs. They were not backported to Jessie.

[James Cowgill]

On 09/02/18 09:31, Fabian Greffrath wrote:
> Hi Salvatore,
> 
> Salvatore Bonaccorso wrote:
>> The current issues which were fixed in DLA-1077-1 are all no-dsa, so
>> thei did not warrant a DSA via security.d.o. Can you fix those issues
>> via upcoming point releases?
> 
> yes, probably. But I guess that's not Mikulas' point:
> 
> Both wheezy and jessie had package version 2.7-8. While wheezy got a fixed
> package with 2.7-8+deb7u1, jessie didn't. The fix should be as straight as
> uploading the same (source) package to jessie that got uploaded to wheezy.

... with changelog and version number adjustments (it can never be
exactly the same).

Also, the security tracker claims this affects stretch as well which
would need a separate update.

James



signature.asc
Description: OpenPGP digital signature

Bug#889892: mpv: fix for CVE-2018-6360 breaks youtube playlists

[James Cowgill]

Hi,

Make sure you CC the bug number when you reply, so that other people can
see your comments.

On 08/02/18 14:26, Marc Becker wrote:
> Hello James,
> 
> newer upstream LUA code supports direct urls for playlists, v0.23 code does 
> not.
> To my knowledge our (base) code forces calls 'youtube-dl' again for each 
> playlist
> entry by adding a 'ytdl://'-prefix.
> So FOR THIS VERSION it should not be necessary to check a url when CREATING a
> playlist entry. It is certain to get to filter entries (again) due to their 
> prefix.
> 
> So in short, keep the original:
>> playlist = playlist .. "ytdl://" .. site .. "\n"
> and only filter urls that are returned directly (line 270 ff.) or added to 
> EDL playlists.
> 
> While I am aware this is against "fail early" practices it is closest
> in control flow logic to the original code and there might be cases/sites
> where the 'ytdl://' prefix is needed due to the older LUA logic.

[replied to lower down]

> Additionally:
> If somebody manages to slip in a multiline value for 'site' it's over anyway…
> Up-to-date upstream code does not really handle this either.
> Let's hope the downloader validates its input.

That probably warrants some investigation...

> Glad if I could help and please scream at me if I'm on the wrong track here.

You have been helpful - noone realized there was a regression until you
reported it :)

> Hi James,
> 
> needed too long to compose last message, and missed your
> mail(s), sorry 
> 
> The only problem would arise if there is some internal logic
> that decides to return links to some other protocol type but
> must, for some strange reason, again be handled by 'youtube-dl'.

My fix has already been uploaded now do it would be a bit of a pain to
change it :/  However, I think it is still correct. It effectively
incorporates this upstream commit, so if what I have done is wrong,
upstream has also made a mistake:
https://github.com/mpv-player/mpv/commit/1623430b200c7bf67ec19bcab13ccbe9a494d2c7

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889892: mpv: fix for CVE-2018-6360 breaks youtube playlists

[James Cowgill]

Hi,

On 08/02/18 11:36, James Cowgill wrote:
> On 07/02/18 23:16, James Cowgill wrote:
>> Hi,
>>
>> On 07/02/18 21:39, Marc Becker wrote:
>>> Package: mpv
>>> Version: 0.23.0-2+deb9u1
>>> Followup-For: Bug #888654
>>>
>>> Patch to line 264 via 08_ytdl-hook-whitelist-protocols.patch is incorrect,
>>> check is applied to raw Youtube ID instead of valid url and always fails as
>>> a result.
>>>
>>> Suggestions: no checking of raw IDs (skipped in upstream fix as well)
>>
>> Yes I think you're right. It's also broken in sid too (but not in
>> experimental). I think I got thrown off by newer mpv distinguishing
>> between youtube ids and non youtube ids.
> 
> Cloning a new bug to track the regression.

I think the attached patch will fix this (which I have also just
uploaded to unstable).

Also available here:
https://salsa.debian.org/multimedia-team/mpv/compare/debian%2F0.23.0-2+deb9u1...debian%2Fstretch

This incorporates this upstream commit which fixes a different issue,
but by doing so allows me to copy upstream's fix:
https://github.com/mpv-player/mpv/commit/1623430b200c7bf67ec19bcab13ccbe9a494d2c7

Sorry for missing this in my first patch!

James
diff --git a/debian/changelog b/debian/changelog
index 346e88c..b68ace0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+mpv (0.23.0-2+deb9u2) stretch-security; urgency=high
+
+  * debian/patches/08_ytdl-hook-whitelist-protocols.patch:
+- Fix regression in CVE-2018-6360 patch which broke youtube playlists.
+  (Closes: #889892)
+
+ -- James Cowgill <jcowg...@debian.org>  Thu, 08 Feb 2018 12:27:06 +
+
 mpv (0.23.0-2+deb9u1) stretch-security; urgency=high
 
   * debian/patches/08_ytdl-hook-whitelist-protocols.patch:
diff --git a/debian/patches/08_ytdl-hook-whitelist-protocols.patch b/debian/patches/08_ytdl-hook-whitelist-protocols.patch
index 0212bdb..7487f82 100644
--- a/debian/patches/08_ytdl-hook-whitelist-protocols.patch
+++ b/debian/patches/08_ytdl-hook-whitelist-protocols.patch
@@ -10,6 +10,7 @@ Description: ytdl_hook: whitelist protocols from urls retrieved from youtube-dl
 Author: Ricardo Constantino <wiia...@gmail.com>
 Bug: https://github.com/mpv-player/mpv/issues/5456
 Bug-Debian: https://bugs.debian.org/888654
+Bug-Debian: https://bugs.debian.org/889892
 Applied-Upstream: v0.29
 ---
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
@@ -61,18 +62,20 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
  playlist = playlist .. edl_escape(entry.url)
  if not (entry.duration == nil) then
  playlist = playlist..",start=0,length="..entry.duration
-@@ -261,7 +285,9 @@ mp.add_hook("on_load", 10, function ()
+@@ -261,7 +285,11 @@ mp.add_hook("on_load", 10, function ()
  site = entry["webpage_url"]
  end
  
 -playlist = playlist .. "ytdl://" .. site .. "\n"
-+if url_is_safe(site) then
++if not site:find("://") then
 +playlist = playlist .. "ytdl://" .. site .. "\n"
++elseif url_is_safe(site) then
++playlist = playlist .. site .. "\n"
 +end
  end
  
  mp.set_property("stream-open-filename", "memory://" .. playlist)
-@@ -279,14 +305,24 @@ mp.add_hook("on_load", 10, function ()
+@@ -279,14 +307,24 @@ mp.add_hook("on_load", 10, function ()
  
  -- video url
  streamurl = json["requested_formats"][1].url


signature.asc
Description: OpenPGP digital signature

Bug#888654: mpv: fix breaks Youtube playlist sites

[James Cowgill]

Control: clone -1 -2
Control: notfound -1 0.23.0-2+deb9u1
Control: retitle -2 mpv: fix for CVE-2018-6360 breaks youtube playlists
Control: tags -2 - upstream
Control: reopen -2
Control: notfound -2 0.23.0-1
Control: found -2 0.27.0-3
Control: fixed -2 0.28.0-1

On 07/02/18 23:16, James Cowgill wrote:
> Hi,
> 
> On 07/02/18 21:39, Marc Becker wrote:
>> Package: mpv
>> Version: 0.23.0-2+deb9u1
>> Followup-For: Bug #888654
>>
>> Patch to line 264 via 08_ytdl-hook-whitelist-protocols.patch is incorrect,
>> check is applied to raw Youtube ID instead of valid url and always fails as
>> a result.
>>
>> Suggestions: no checking of raw IDs (skipped in upstream fix as well)
> 
> Yes I think you're right. It's also broken in sid too (but not in
> experimental). I think I got thrown off by newer mpv distinguishing
> between youtube ids and non youtube ids.

Cloning a new bug to track the regression.

James



signature.asc
Description: OpenPGP digital signature

Bug#888654: mpv: fix breaks Youtube playlist sites

[James Cowgill]

Hi,

On 07/02/18 21:39, Marc Becker wrote:
> Package: mpv
> Version: 0.23.0-2+deb9u1
> Followup-For: Bug #888654
> 
> Patch to line 264 via 08_ytdl-hook-whitelist-protocols.patch is incorrect,
> check is applied to raw Youtube ID instead of valid url and always fails as
> a result.
> 
> Suggestions: no checking of raw IDs (skipped in upstream fix as well)

Yes I think you're right. It's also broken in sid too (but not in
experimental). I think I got thrown off by newer mpv distinguishing
between youtube ids and non youtube ids.

The original fix for 0.29 adds:
if not site:find("://") then
table.insert(playlist, "ytdl://" .. site)
elseif url_is_safe(site) then
table.insert(playlist, site)
end

So maybe this will work (replacing the existing playlist= assignment):
if not site:find("://") then
playlist = playlist .. "ytdl://" .. site .. "\n"
elseif url_is_safe(site) then
playlist = playlist .. site .. "\n"
end

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889818: prometheus-mongodb-exporter: FTBFS on 32-bit architectures - constant 9007199254740992 overflows int

[James Cowgill]

Control: unarchive 886432
Control: reassign -1 src:golang-gopkg-mgo.v2
Control: forcemerge 886432 -1
Control: found 886432 2016.08.01-3

Hi,

On 07/02/18 11:54, James Cowgill wrote:
> Source: prometheus-mongodb-exporter
> Version: 1.0.0-1
> Severity: serious
> Tags: sid buster
> 
> Hi,
> 
> prometheus-mongodb-exporter FTBFS on mips in a recent rebuild, but since
> I can reproduce this failure on i386 as well, presumably it fails on all
> 32-bit architectures.
> 
> The error is:
>> github.com/golang/glog
>> gopkg.in/mgo.v2/internal/json
>> gopkg.in/mgo.v2/bson
>> # gopkg.in/mgo.v2/bson
>> src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows 
>> int

This is a recurrence of #886432

It looks to me like the patch to fix this was not added to git so the
next upload removed the patch.

Also the Vcs-* URLs are currently dead. I had to go on a hunt for where
the packaging repo was stored for this package.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889818: prometheus-mongodb-exporter: FTBFS on 32-bit architectures - constant 9007199254740992 overflows int

[James Cowgill]

Source: prometheus-mongodb-exporter
Version: 1.0.0-1
Severity: serious
Tags: sid buster

Hi,

prometheus-mongodb-exporter FTBFS on mips in a recent rebuild, but since
I can reproduce this failure on i386 as well, presumably it fails on all
32-bit architectures.

The error is:
> github.com/golang/glog
> gopkg.in/mgo.v2/internal/json
> gopkg.in/mgo.v2/bson
> # gopkg.in/mgo.v2/bson
> src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows 
> int
> gopkg.in/mgo.v2/internal/scram
> github.com/beorn7/perks/quantile
> github.com/golang/protobuf/proto
> github.com/prometheus/client_model/go
> github.com/matttproud/golang_protobuf_extensions/pbutil
> github.com/prometheus/common/internal/bitbucket.org/ww/goautoneg
> github.com/prometheus/common/model
> github.com/prometheus/common/expfmt
> github.com/prometheus/procfs/xfs
> github.com/prometheus/procfs
> github.com/prometheus/client_golang/prometheus
> dh_auto_build: cd build && go install 
> -gcflags=\"-trimpath=/<>/build/src\" 
> -asmflags=\"-trimpath=/<>/build/src\" -v -p 1 
> github.com/dcu/mongodb_exporter github.com/dcu/mongodb_exporter/collector 
> github.com/dcu/mongodb_exporter/shared returned exit code 2

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888654: mpv: CVE-2018-6360

[James Cowgill]

Hi,

On 06/02/18 18:08, Luciano Bello wrote:
> On 2018-02-03 09:13, James Cowgill wrote:
>> Unlike the backport for 0.27 which was fairly straightforward, the
>> backport for 0.23 required significant changes and I ended up rewriting
>> half of it. This means I am less confident about catching all the cases
>> to fix this bug. It would be good if anyone could check it over.
> 
> I tested the PoC (probably as you) and seems fixed. I tried to cover
> under branches and they also look sanitized. I feel as confident as
> somebody can be that the patch is complete. It seems functionally safe.
> 
> Thanks for your work, please upload.

Thanks for testing! I've uploaded it.

James



signature.asc
Description: OpenPGP digital signature

Bug#889528: mpv: Reading bluray using mpv fails

[James Cowgill]

Control: tags -1 - confirmed
Control: reassign -1 libbluray-dev 1:1.0.2-1
Control: retitle -1 libbluray-dev: missing dependencies on libxml, freetype, 
and fontconfig
Control: severity -1 serious
Control: affects -1 src:mpv

Hi,

On 04/02/18 20:29, James Cowgill wrote:
> On 04/02/18 19:32, mahashakti89 wrote:
>> On Sun, Feb 04, 2018 at 04:53:24PM +0100, James Cowgill wrote:
>>> On 04/02/18 16:46, James Cowgill wrote:
>>>> Hi,
>>>>
>>>> On 04/02/18 09:38, mahashakti89 wrote:
>>>>> Package: mpv
>>>>> Version: 0.27.0-3
>>>>> Severity: important
>>>>>
>>>>> Dear Maintainer,
>>>>>
>>>>> I am using smplayer to read blurays - choosen multimedia engine is
>>>>> mpv - but it
>>>>> fails with following message :
>>>>>
>>>>> Playing: br:media/toto/cdrom0
>>>>> No protocol handler found to open URL br:media/toto/cdrom0
>>>>> The protocol is either unsupported, or was disabled at compile-time.
>>>>
>>>> mpv uses a slightly different "bd" protocol instead of "br". Try this:
>>>>  mpv br:// --bluray-device=/media/toto/cdrom0
>>>
>>> Err this of course should be:
>>> mpv bd:// --bluray-device=/media/toto/cdrom0
>>
>> Hi,
>> mpv bd:// --bluray-device=/media/cdrom0
>> Error parsing option bluray-device (option not found)
>> Setting commandline option --bluray-device=/media/cdrom0 failedi.
>>
>> Extract of the mount command
>>
>> gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
>> (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
>> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
>> /dev/sdg1 on /media/toto/PATRIOT2 type fuseblk
>> (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
>>
>> /dev/sr0 on /media/cdrom0 type udf
>> (ro,nosuid,nodev,noexec,relatime,utf8,user)
>>
>> Till then mpv worked fairly well with playing blurays.
> 
> After looking a bit more closely, mpv isn't pulling in libbluray at all.
> The build log contains:> Checking for Bluray support
>   : no ('libbluray >= 0.3.0' not found)
> 
> I'll try and see why it's not detecting the library.

This is due to pkg-config failing to run on libbluray:
> $ pkg-config --cflags libbluray
> Package libxml-2.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libxml-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libxml-2.0', required by 'libbluray', not found

Probably libbluray-dev needs to build-depend on libfreetype6-dev,
libfontconfig-dev and libxml2-dev to fix this.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889528: mpv: Reading bluray using mpv fails

[James Cowgill]

Control: tags -1 confirmed

Hi,

On 04/02/18 19:32, mahashakti89 wrote:
> On Sun, Feb 04, 2018 at 04:53:24PM +0100, James Cowgill wrote:
>> On 04/02/18 16:46, James Cowgill wrote:
>>> Hi,
>>>
>>> On 04/02/18 09:38, mahashakti89 wrote:
>>>> Package: mpv
>>>> Version: 0.27.0-3
>>>> Severity: important
>>>>
>>>> Dear Maintainer,
>>>>
>>>> I am using smplayer to read blurays - choosen multimedia engine is
>>>> mpv - but it
>>>> fails with following message :
>>>>
>>>> Playing: br:media/toto/cdrom0
>>>> No protocol handler found to open URL br:media/toto/cdrom0
>>>> The protocol is either unsupported, or was disabled at compile-time.
>>>
>>> mpv uses a slightly different "bd" protocol instead of "br". Try this:
>>>  mpv br:// --bluray-device=/media/toto/cdrom0
>>
>> Err this of course should be:
>> mpv bd:// --bluray-device=/media/toto/cdrom0
> 
> Hi,
> mpv bd:// --bluray-device=/media/cdrom0
> Error parsing option bluray-device (option not found)
> Setting commandline option --bluray-device=/media/cdrom0 failedi.
> 
> Extract of the mount command
> 
> gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
> (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
> /dev/sdg1 on /media/toto/PATRIOT2 type fuseblk
> (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
> 
> /dev/sr0 on /media/cdrom0 type udf
> (ro,nosuid,nodev,noexec,relatime,utf8,user)
> 
> Till then mpv worked fairly well with playing blurays.

After looking a bit more closely, mpv isn't pulling in libbluray at all.
The build log contains:> Checking for Bluray support
  : no ('libbluray >= 0.3.0' not found)

I'll try and see why it's not detecting the library.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889528: mpv: Reading bluray using mpv fails

[James Cowgill]

On 04/02/18 16:46, James Cowgill wrote:
> Hi,
> 
> On 04/02/18 09:38, mahashakti89 wrote:
>> Package: mpv
>> Version: 0.27.0-3
>> Severity: important
>>
>> Dear Maintainer,
>>
>> I am using smplayer to read blurays - choosen multimedia engine is mpv - but 
>> it
>> fails with following message :
>>
>> Playing: br:media/toto/cdrom0
>> No protocol handler found to open URL br:media/toto/cdrom0
>> The protocol is either unsupported, or was disabled at compile-time.
> 
> mpv uses a slightly different "bd" protocol instead of "br". Try this:
>  mpv br:// --bluray-device=/media/toto/cdrom0

Err this of course should be:
 mpv bd:// --bluray-device=/media/toto/cdrom0

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#889528: mpv: Reading bluray using mpv fails

[James Cowgill]

Hi,

On 04/02/18 09:38, mahashakti89 wrote:
> Package: mpv
> Version: 0.27.0-3
> Severity: important
> 
> Dear Maintainer,
> 
> I am using smplayer to read blurays - choosen multimedia engine is mpv - but 
> it
> fails with following message :
> 
> Playing: br:media/toto/cdrom0
> No protocol handler found to open URL br:media/toto/cdrom0
> The protocol is either unsupported, or was disabled at compile-time.

mpv uses a slightly different "bd" protocol instead of "br". Try this:
 mpv br:// --bluray-device=/media/toto/cdrom0

See the mpv manual page.

Unfortunately I do not have a bluray reader do I can't test this.

James



signature.asc
Description: OpenPGP digital signature

Bug#889545: libopenmpt0: possible out-of-bounds memory read with malformed STP files

[James Cowgill]

Control: retitle -1 libopenmpt0: CVE-2018-6611

On 04/02/18 12:26, James Cowgill wrote:
> Package: libopenmpt0
> Version: 0.3.1-1
> Severity: grave
> Tags: security
> 
> This security update was published for libopenmpt:
> https://lib.openmpt.org/libopenmpt/2018/02/03/security-update-0.3.6/
> 
>> The OpenMPT/libopenmpt project released the latest stable libopenmpt version:
>>
>> libopenmpt 0.3.6 (2018-02-03)
>> [Sec] Possible out-of-bounds memory read with malformed STP files. (r9576)
> 
> The bug only affects 0.3.x so it will not require any updates to stable.
> 
> I have requested a CVE for this bug.

... and it was allocated CVE-2018-6611.

James



signature.asc
Description: OpenPGP digital signature

Bug#889545: libopenmpt0: possible out-of-bounds memory read with malformed STP files

[James Cowgill]

Package: libopenmpt0
Version: 0.3.1-1
Severity: grave
Tags: security

This security update was published for libopenmpt:
https://lib.openmpt.org/libopenmpt/2018/02/03/security-update-0.3.6/

> The OpenMPT/libopenmpt project released the latest stable libopenmpt version:
> 
> libopenmpt 0.3.6 (2018-02-03)
> [Sec] Possible out-of-bounds memory read with malformed STP files. (r9576)

The bug only affects 0.3.x so it will not require any updates to stable.

I have requested a CVE for this bug.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888654: mpv: CVE-2018-6360

[James Cowgill]

Hi,

On 28/01/18 14:17, Salvatore Bonaccorso wrote:
> Source: mpv
> Version: 0.23.0-1
> Severity: grave
> Tags: security upstream
> Forwarded: https://github.com/mpv-player/mpv/issues/5456
> 
> Hi,
> 
> the following vulnerability was published for mpv.
> 
> CVE-2018-6360[0]:
> | mpv through 0.28.0 allows remote attackers to execute arbitrary code
> | via a crafted web site, because it reads HTML documents containing
> | VIDEO elements, and accepts arbitrary URLs in a src attribute without a
> | protocol whitelist in player/lua/ytdl_hook.lua. For example, an
> | av://lavfi:ladspa=file= URL signifies that the product should call
> | dlopen on a shared object file located at an arbitrary local pathname.
> | The issue exists because the product does not consider that youtube-dl
> | can provide a potentially unsafe URL.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I have attempted to backport the upstream patch to fix this and
committed it to the mpv repository on salsa. The diff is here:

https://salsa.debian.org/multimedia-team/mpv/compare/debian%2F0.23.0-2...debian%2Fstretch

Unlike the backport for 0.27 which was fairly straightforward, the
backport for 0.23 required significant changes and I ended up rewriting
half of it. This means I am less confident about catching all the cases
to fix this bug. It would be good if anyone could check it over.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888366: qtwebengine-opensource-src: FTBFS with FFmpeg 3.5

[James Cowgill]

Hi,

On 02/02/18 13:50, Lisandro Damián Nicanor Pérez Meyer wrote:
> El miércoles, 24 de enero de 2018 19:26:50 -03 jcowg...@debian.org escribió:
>> Source: qtwebengine-opensource-src
>> Version: 5.9.2+dfsg-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. In FFmpeg 3.5,
>> there are a number of API changes which will cause many packages to FTBFS.
>> For this reason I have uploaded an early development snapshot to
>> experimental before the 3.5 release in an attempt to fix some of these a
>> bit quicker. While 3.5 has not been finalized and the ABI is not stable
>> yet, there should not be any significant API breakages before the release.
>>
>> Incomplete list of changes (based on looking at common build failures):
>> - Some fields in AVCodecContext have been removed and replaced with private
>>   options which can be set using the av_opt_set* APIs
>> - Most CODEC_* constants have been renamed to AV_CODEC_*
>> - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE
>>   have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and
>>   AV_INPUT_BUFFER_MIN_SIZE.
>> - The old resampling API provided by libavcodec has been removed. Use
>>   libswresample instead.
>> - The libavfilter/avfiltergraph.h header has been removed, include
>>   libavfilter/avfilter.h instead.
>> - The AVFrac structure (representing mixed rational numbers) has been
>>   removed.
> 
> Hi James! Qt upstreams will certainly not start developing against a new 
> FFmpeg version until it gets released.

Having FFmpeg 3.5 released is not a prerequisite to fix this. All the
old APIs in FFmpeg 3.5 have been deprecated for 2 years (or much longer
in some cases). The new APIs are already in old FFmpeg versions.

> That means *at very least* 6 months of 
> delay from the day FFmpeg 3.5 gets released.
> 
> As this bug is filed against qtwebengine *it might happen* that the web 
> engine 
> itself needs an update, in that case the engine must be updated first and 
> then 
> Qt will follow.

I have not specifically looked at qtwebengine, but the build log
indicates that the bugs are in the chromium code. Eg:

> ../../3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:56:35: error: 
> 'CODEC_CAP_DR1' was not declared in this scope

> So I'm afraid it's either waiting or having more than one FFmpeg version in 
> the archive.

I assure you there there will not be more than one FFmpeg version in the
archive at once :)

I already expect I will have to help patch a lot of these bugs (given
the amount of work which past FFmpeg transitions have taken). I will try
to look at this and the build failure in chromium once we get closer to
when I would like to start the transition.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#886222: ld.gold: internal error in get_got_page_offset, at ../../gold/mips.cc:6271

[James Cowgill]

On 02/02/18 10:35, Emilio Pozuelo Monfort wrote:
> On Thu, 1 Feb 2018 10:21:44 +0000 James Cowgill <jcowg...@debian.org> wrote:
>> On 27/01/18 19:13, Gianfranco Costamagna wrote:
>>> On Fri, 5 Jan 2018 16:12:14 +0100 Gianfranco Costamagna 
>>> <locutusofb...@debian.org> wrote:
>>>> On Thu, 4 Jan 2018 14:30:08 + James Cowgill <jcowg...@debian.org> 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On 04/01/18 14:26, Gianfranco Costamagna wrote:
>>>>>> Hello,
>>>>>>
>>>>>>> Is there a way for me to run your testcase without ghc-stage1 (which
>>>>>>> would require building ghc)?
>>>>>>
>>>>>> I don't know, however I attached ghc-stage1 binaries to the report
>>>>>
>>>>> The "ghc-stage1" you attached is a shell script which execs some other
>>>>> binary which you didn't attach.
>>>>>
>>>>
>>>> this is true, I hope you can get from my home in eller.debian.org :)
>>>>
>>>
>>> hello, ping?
>>> (this is the last blocker for ghc 8.2 in unstable, unfortunately somebody 
>>> would like to remove from mips instead of delaying the transition any 
>>> longer)
>>
>> Sorry I got a bit sidetracked working on other things.
>>
>> I have a slightly reduced testcase, but it still requires about 50M of
>> objects so I'm working on reducing it even more.
> 
> Cool, thanks.
> 
>> I did a test compile of ghc using the bfd linker and it does build (pass
>> --disable-ld-override to ghc configure). This might be usable as a
>> workaround if you don't want to delay the transition. I expect this will
>> make ghc / haskell build times increase a lot on mips* though.
> 
> Did you try that on mips64el? Gianfranco tried on mips or mipsel IIRC and it 
> was
> running out of memory. Perhaps reducing the optimization levels or the 
> debugging
> symbols could help...

Yes I only tried it on mips64el.

James



signature.asc
Description: OpenPGP digital signature

Bug#886222: ld.gold: internal error in get_got_page_offset, at ../../gold/mips.cc:6271

[James Cowgill]

Hi,

On 27/01/18 19:13, Gianfranco Costamagna wrote:
> On Fri, 5 Jan 2018 16:12:14 +0100 Gianfranco Costamagna 
> <locutusofb...@debian.org> wrote:
>> On Thu, 4 Jan 2018 14:30:08 + James Cowgill <jcowg...@debian.org> wrote:
>>> Hi,
>>>
>>> On 04/01/18 14:26, Gianfranco Costamagna wrote:
>>>> Hello,
>>>>
>>>>> Is there a way for me to run your testcase without ghc-stage1 (which
>>>>> would require building ghc)?
>>>>
>>>> I don't know, however I attached ghc-stage1 binaries to the report
>>>
>>> The "ghc-stage1" you attached is a shell script which execs some other
>>> binary which you didn't attach.
>>>
>>
>> this is true, I hope you can get from my home in eller.debian.org :)
>>
> 
> hello, ping?
> (this is the last blocker for ghc 8.2 in unstable, unfortunately somebody 
> would like to remove from mips instead of delaying the transition any longer)

Sorry I got a bit sidetracked working on other things.

I have a slightly reduced testcase, but it still requires about 50M of
objects so I'm working on reducing it even more.

I did a test compile of ghc using the bfd linker and it does build (pass
--disable-ld-override to ghc configure). This might be usable as a
workaround if you don't want to delay the transition. I expect this will
make ghc / haskell build times increase a lot on mips* though.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888769: gegl: FTBFS on machines with lots of cores

[James Cowgill]

Source: gegl
Version: 0.3.28-1
Severity: normal

Hi,

I started having a look at the mips build failure. To do this I tried to
run gegl on a mips machine with 64 cores. Unfortunately the testsuite
started randomly failing without out of memory errors.

Example:
> (gegl:8396): GLib-ERROR **: ../../../../glib/gmem.c:100: failed to allocate 
> 262176 bytes
> FAIL clones.xml

Running gegl in gdb, I see that it runs out of memory trying to allocate
stack space for over 250 threads. Given the default stack size of 8MB,
256 threads would require 2GB of space and exceed the amount of virtual
memory available. 250 threads is close enough to cause problems.

I have not debugged this completely, but I do notice that there are a
number of calls to g_thread_pool_new in gegl/operation/*, but no calls
to g_thread_pool_free. Possibly these thread pools (and their threads)
are being leaked?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#888657: ladish: should this package be removed?

[James Cowgill]

Hi,

On 28/01/18 14:16, treb...@tuxfamily.org wrote:
> Le 2018-01-28 14:38, Simon McVittie a écrit :
>> Source: flowcanvas
>> Severity: important
>> User: debian...@lists.debian.org
>> Usertags: proposed-removal
>> Control: clone -1 -2
>> Control: reassign -2 ladish
>> Control: retitle -2 ladish: should this package be removed?
>>
>> flowcanvas depends on numerous obsolete GNOME 2-era libraries
>> (e.g. #885095) and hasn't had a maintainer upload since 2009. Its
>> upstream
>> website says:
>>
>>     **Note**: FlowCanvas is dead, long live Ganv!
>>
>> ganv is also in Debian as src:ganv; it's orphaned in Debian, but appears
>> to have commit activity upstream.
>>
>> flowcanvas has one reverse-dependency in Debian, gladish (src:ladish),
>> whose most recent maintainer upload was in 2014. web.archive.org says
>> the ladish.org website has been down since mid 2014.
> 
> ladish looks to be maintained by alessio (last commit 20 Apr 2017) here :
> https://github.com/alessio/ladish/
> (the same goes laditools as well)

You failed to mention that there has only been one non-merge commit to
that repository since 2014.

The truth is unless someone is willing to do the porting work, these
packages are not going to survive whether they are "maintained" or not.

James



signature.asc
Description: OpenPGP digital signature

Bug#888664: collada2gltf: missing Vcs-* fields

[James Cowgill]

Hi,

On 28/01/18 14:45, Rene Engelhard wrote:
> Hi,
> 
> On Sun, Jan 28, 2018 at 02:34:33PM +0000, James Cowgill wrote:
>> In my analysis of the multimedia team repositories on alioth I noticed
>> that this repository does not have any Vcs-* fields, but does have a
>> repository on both alioth and salsa.
> 
> I consider that a bug when that one was migrated to salsa. The alioth
> one should have been gone.

The alioth repositories are not being removed (at least I am not
planning on doing that). Before moving everything to salsa, I am
trimming down the list of repositories to migrate. The ones left will be
made readonly and presumably archived when alioth is turned off.

James



signature.asc
Description: OpenPGP digital signature

Bug#888669: stops: missing Vcs-* fields

[James Cowgill]

Source: stops
Version: 0.3.0-1
Severity: minor

Hi,

In my analysis of the multimedia team repositories on alioth I noticed
that this repository does not have any Vcs-* fields, but does have a
repository on alioth.

Probably these fields should be added.

Thanks,
James







signature.asc
Description: OpenPGP digital signature

Bug#888668: pd-purepd: missing Vcs-* fields

[James Cowgill]

Source: pd-purepd
Version: 0.1.1-1
Severity: minor

Hi,

In my analysis of the multimedia team repositories on alioth I noticed
that this repository does not have any Vcs-* fields, but does have a
repository on alioth.

Probably these fields should be added.

Thanks,
James







signature.asc
Description: OpenPGP digital signature