Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[James Cowgill]

Source: ffmpeg
Version: 7:3.3.3-3
Severity: important
Control: found -1 7:3.2.4-1
Control: affects -1 src:winff

Hi,

Just noticed that winff's autopkgtests fail on armhf because ffmpeg
receives a SIGBUS.

The failing command is:

> /usr/bin/ffmpeg -i test.avi -vcodec flv -f flv -r 29.97 -vf scale=w=320:h=240 
> -aspect 4:3 -b:v 300k -g 160 -cmp dct -subcmp dct -mbd 2 -flags +aic+mv0+mv4 
> -trellis 1 -ac 1 -ar 22050 -b:a 56k -y -t 1 test.flv

Where test.avi can be obtained from the winff source package:
https://sources.debian.net/src/winff/1.5.5-1/debian/tests/test.avi/

Backtrace:
> (gdb) bt
> #0  ff_diff_pixels_armv6 () at src/libavcodec/arm/pixblockdsp_armv6.S:46
> #1  0xf6540fe8 in dct_sad8x8_c (h=8, stride=352,
> src2=0xaacf377f 
> "ddefhiiihmmmnnnoopqqruuuvvvwwyyz{{|}}\200\200\201\201\202\203\203\203\202\202\202\203\203\203\204\204\206\205\205\204\204\203\203\203\200\201\201\201\201\202\202\202\206\206\206\206\206\206\206\206\210\212\215\220\222\222\221\220\220\220\220\221\221\222\222\222\223\223\224\225\225\226\226\227\235\235\236\236\236",
>  '\237' , 
> "\240\240\241\241\242\242\243\243\243\244\245\245\246\246\247\250\250\251\251\252\252\253\251\251\252\252\252\253\253\253\255\255\255\255\255\255\255\255\256\256\257\257\257\260\260\260\261\261\261\261\261\261\261\261\263\263\263\264\264\264\265\265\264\264\264\264\264\264\264"...,
> src1=0xaadf6990 
> "bcegijjkkklononnnmnnnoppqqqrvvuuuvwxy{|~~\177\200\201\201\202\203\202\202\203\204\204\204\204\205\205\206\206\206\206\205\205\205\204\203\203\203\202\202\202\202\202\203\204\204\205\205\207\211\210\211\213\215\220\222\222\221\221\221\221\220\220\220\220\221\223\223\224\225\226\225\225\225\227\232\233\234\235\235\234\234\235\235\235\236\237\236\237\240\237\236\236\237\237\237\240\241\241\241\241\242\243\243\243\244\245\244\245\246\246\246\247\247\250\251\252\253\253\253\253\252\252\254\254\254\254\254\255\255\256\257\257\257\257\257\257\257\257\260\260\261\262\262\261\260\261\261\262\262\262\263\264\264\264\264\264\264\264\264\264\264\263"...,
>  s=0xaac58b10) at src/libavcodec/me_cmp.c:631
> #2  dct_sad16_c (s=0xaac58b10,
> dst=0xaadf6990 
> "bcegijjkkklononnnmnnnoppqqqrvvuuuvwxy{|~~\177\200\201\201\202\203\202\202\203\204\204\204\204\205\205\206\206\206\206\205\205\205\204\203\203\203\202\202\202\202\202\203\204\204\205\205\207\211\210\211\213\215\220\222\222\221\221\221\221\220\220\220\220\221\223\223\224\225\226\225\225\225\227\232\233\234\235\235\234\234\235\235\235\236\237\236\237\240\237\236\236\237\237\237\240\241\241\241\241\242\243\243\243\244\245\244\245\246\246\246\247\247\250\251\252\253\253\253\253\252\252\254\254\254\254\254\255\255\256\257\257\257\257\257\257\257\257\260\260\261\262\262\261\260\261\261\262\262\262\263\264\264\264\264\264\264\264\264\264\264\263"...,
> src=0xaacf377f 
> "ddefhiiihmmmnnnoopqqruuuvvvwwyyz{{|}}\200\200\201\201\202\203\203\203\202\202\202\203\203\203\204\204\206\205\205\204\204\203\203\203\200\201\201\201\201\202\202\202\206\206\206\206\206\206\206\206\210\212\215\220\222\222\221\220\220\220\220\221\221\222\222\222\223\223\224\225\225\226\226\227\235\235\236\236\236",
>  '\237' , 
> "\240\240\241\241\242\242\243\243\243\244\245\245\246\246\247\250\250\251\251\252\252\253\251\251\252\252\252\253\253\253\255\255\255\255\255\255\255\255\256\256\257\257\257\260\260\260\261\261\261\261\261\261\261\261\263\263\263\264\264\264\265\265\264\264\264\264\264\264\264"...,
>  stride=352, h=16) at src/libavcodec/me_cmp.c:971
> #3  0xf6570cec in cmp_inline (chroma=0, qpel=0, chroma_cmp_func= out>, cmp_func=0x0, src_index=, ref_index=,
> h=16, size=0, suby=0, subx=0, y=, x=-1, s=0x0) at 
> src/libavcodec/motion_est.c:217
> #4  cmp_simple (chroma_cmp_func=, cmp_func=0x0, 
> src_index=, ref_index=, y=, 
> x=-1, s=0x0)
> at src/libavcodec/motion_est.c:234
> #5  cmp (flags=0, chroma_cmp_func=, cmp_func=0x0, 
> src_index=, ref_index=, h=16, size=0, suby=0, 
> subx=0,
> y=, x=-1, s=0x0) at src/libavcodec/motion_est.c:266
> #6  small_diamond_search (flags=0, h=16, size=0, penalty_factor=-16, 
> ref_index=240, src_index=2, dmin=, best=0xfffee064, s=0x0)
> at src/libavcodec/motion_est_template.c:445
> #7  diamond_search (flags=0, h=16, size=0, penalty_factor=-16, ref_index=240, 
> src_index=2, dmin=, best=0xfffee064, s=0x0)
> at src/libavcodec/motion_est_template.c:840
> #8  epzs_motion_search_internal (h=16, size=0, flags=0, ref_mv_scale=0, 
> last_mv=0x0, ref_index=-162058212, src_index=0, P=0xfffee01c,
> my_ptr=0xf77efce8 <__stack_chk_guard>, mx_ptr=0x15, s=0x1196a700) at 
> src/libavcodec/motion_est_template.c:966
> #9  ff_epzs_motion_search (s=0x1196a700, s@entry=0xaac58b10, mx_ptr=0x15, 
> mx_ptr@entry=0xfffee0e4, my_ptr=0xf77efce8 <__stack_chk_guard>,
> my_ptr@entry=0xfffee0e8, P=P@entry=0xfffee0ec, 
> src_index=src_index@entry=0, ref_index=ref_index@entry=0, last_mv=0xaaccf9b8, 
> ref_mv_scale=32768,
> ref_mv_scale@entry=65536, 

Bug#871270: encfs: installs private library in public directory

[James Cowgill]

Control: user debian-...@lists.debian.org
Control: usertag -1 - gcc-7-op-mangling
Control: retitle -1 encfs: installs private library in public directory

Hi,

On 15/08/17 22:28, Eduard Bloch wrote:
> Hallo,
> * jcowg...@debian.org [Mon, Aug 07 2017, 03:20:41PM]:
>> Package: encfs
>> Version: 1.9.2-1
>> Severity: serious
>> Tags: sid buster
>> User: debian-...@lists.debian.org
>> Usertags: gcc-7-op-mangling
>>
>> Hi,
>>
>> It appears that your package provides an external symbol that is
>> affected by the recent name mangling changes in GCC 7. See:
>> https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling
> 
> It might be the case, however, the library inside is for internal use
> only. So I think the report and advise are not appropriate here. If you
> agree, please close the bug report and maybe also adjust the scan script
> to consider the hints from lintian overrides, like those:
> 
> $ cat /usr/share/lintian/overrides/encfs
> encfs: non-dev-pkg-with-shlib-symlink usr/lib/libencfs.so.6.0.1 
> usr/lib/libencfs.so
> encfs: no-shlibs-control-file usr/lib/libencfs.so.6.0.1
> encfs: postinst-must-call-ldconfig usr/lib/libencfs.so.6.0.1
> encfs: package-name-doesnt-match-sonames libencfs6

If the library is private, then indeed you do not need to rebuild it
with GCC 7 (since there will be no external rdeps).

However, you are aware that installing a private library in a public
directory is a policy violation (various bits in section 8)? Lintian
overrides doesn't make any difference to ld.so when determining if a
library is public. You should instead be installing it in a private
directory (such as /usr/lib/encfs) and using RUNPATH or RPATH.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#872245: netdata: remove myself from the Uploaders

[James Cowgill]

Source: netdata
Version: 1.6.0+dfsg-3
Severity: minor

Hi,

While I know I have expressed an interest in netdata in the past, I
don't think I will have any time to work on it soon and as far as I can
remember I have never actually done any work on it. On that basis, I
think it would be best if you remove me from the list of uploaders so it
accurately reflects the people working on it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871565: gcc-7: ppc64el: miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

[James Cowgill]

Control: reassign -1 gcc-7 7.1.0-13
Control: severity -1 important
Control: retitle -1 gcc-7: ppc64el: miscompiles ffmpeg's 
scalarproduct_int16_vsx at -O1
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81833
Control: affects -1 src:ffmpeg

Hi,

On 09/08/17 06:47, Adrian Bunk wrote:
> Source: ffmpeg
> Version: 7:3.3.3-2
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=ppc64el=7%3A3.3.3-2=1502249633=0
[...]
> TESTcheckasm-audiodsp
> /<>/tests/fate-run.sh fate-checkasm-audiodsp "" "" 
> "/<>/debian/standard" 'run tests/checkasm/checkasm 
> --test=audiodsp' '' '/dev/null' '' '1' '' '' '' '' '' '' '' ''
>  /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all 
> -threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact 
> -fflags +bitexact -f image2 -vcodec pgmyuv -hwaccel none -threads 1 
> -thread_type frame+slice -i 
> /<>/debian/standard/tests/vsynth1/%02d.pgm -flags +bitexact 
> -sws_flags +accurate_rnd+bitexact -fflags +bitexact -threads 1 -idct simple 
> -dct fastint -vf format=gbrp14be,vflip= -vcodec rawvideo -frames:v 5 -pix_fmt 
> gbrp14be -frames:v 1 -f nut md5:
>  /<>/debian/standard/tests/checkasm/checkasm --test=audiodsp
> Test checkasm-audiodsp failed. Look at tests/data/fate/checkasm-audiodsp.err 
> for details.
> checkasm: using random seed 3484844225
> ALTIVEC:
>audiodsp.scalarproduct_int16_altivec (audiodsp.c:81)
>  - audiodsp.audiodsp [FAILED]
> VSX:
>audiodsp.scalarproduct_int16_vsx (audiodsp.c:81)
>  - audiodsp.audiodsp [FAILED]
> checkasm: 2 of 2 tests have failed
> /<>/tests/Makefile:219: recipe for target 
> 'fate-checkasm-audiodsp' failed
> make[2]: *** [fate-checkasm-audiodsp] Error 1

I've debugged this a bit and it definitely looks like GCC 7 has
miscompiled some of the VSX routines in FFmpeg. I've filed an upstream
bug againt GCC, but I'll probably just disable these optimizations on
ppc64el until it's fixed.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871300: [Pkg-gmagick-im-team] Bug#871300: libmagick++-6.q16-7: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

Hi,

On 08/08/17 06:38, Bastien Roucaries wrote:
> Le 7 août 2017 22:59:06 GMT+02:00, James Cowgill <jcowg...@debian.org> a 
> écrit :
>> On 07/08/17 16:55, roucaries bastien wrote:
>>> On Mon, Aug 7, 2017 at 4:47 PM,  <jcowg...@debian.org> wrote:
>>>> Package: libmagick++-6.q16-7
>>>> Version: 8:6.9.7.4+dfsg-16
>>>> Severity: serious
>>>> Tags: sid buster
>>>> User: debian-...@lists.debian.org
>>>> Usertags: gcc-7-op-mangling
>>>>
>>>
>>> I need a change that break ABI, I will release a new version. Does it
>>> exist in this case a short cut
>>
>> If you are going to rename the Debian package and trigger a package
>> transition, you do not need to add any of the extra symbols/shlibs
>> stuff. You should still build-depend on gcc (>= 4:7) however - I'm not
>> sure if all the buildds use GCC 7 by default yet.
> 
>  Should i depends on g++7 for libmagick++-dev ?

I don't think you need to do that. Consumers of your library don't need
to be running gcc-7 (it should work with gcc-6 and gcc-7). Your library
does need to be built using gcc-7 so that it is compatible with both
compilers.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[James Cowgill]

Hi,

On 10/08/17 08:31, Joël Krähemann wrote:
> Package: lv2-dev
> Version: 1.14.0~dfsg1-1
> Severity: important
> 
> Dear Maintainer,
> 
> The following header makes use of smallest possible pointer in 
> LV2_Event_Buffer struct's data field.
> 
> lv2/lv2plug.in/ns/ext/event/event.h
> 
> Please change it to biggest possible pointer. It should be definitely void* 
> type because the memory
> pointed by data shall contain another struct LV2_Event.
> 
> This describes an integer overflow. There shouldn't be any overflow.

I'm afraid I don't see what the problem is here, or where the integer
overflow is. The data field is casted to an appropriate pointer type
whenever it is used and doing that is portable if you're careful.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[James Cowgill]

Hi,

On 09/08/17 04:59, Edmund Grimley Evans wrote:
> James:
>> I think the runtime is working, but this is the testcase from the SIGBUS
>> bug which you can use:
>>
>> ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi 
>> libx264rgb.avi -y -hide_banner -nostdin
>> ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32le -f nut 
>> /dev/null -y -hide_banner -nostdin
>>
>> Since the SIGBUS bug occurs in NEON code, if the runtime detection is
>> working, this will _only_ fail on machines with NEON and work on
>> non-NEON machines.
> 
> This bug was closed while I was sleeping, but I will mention anyway
> that with 7:3.3.3-1 those commands give a SIGBUS, as expected, but
> only if /proc is mounted.
> 
> Presumably with the fixed version, 7:3.3.3-2, performance will be
> measurably worse on a system with NEON when /proc is not mounted.
> 
> Upstream should probably switch to using getauxval(). Do you want to
> suggest it to them?

I've filed it upstream here:
https://trac.ffmpeg.org/ticket/6578

James



signature.asc
Description: OpenPGP digital signature

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

Hi,

On 09/08/17 10:07, Jose Gutierrez de la Concha wrote:
> On Tue, Aug 8, 2017 at 6:07 PM, James Cowgill <jcowg...@debian.org
> <mailto:jcowg...@debian.org>> wrote:
> 
>On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
>> On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill <jcowg...@debian.org 
>> <mailto:jcowg...@debian.org>
>> <mailto:jcowg...@debian.org <mailto:jcowg...@debian.org>>> wrote:
>>[...]
>>>- If your package does not provide a symbols file, add a dh_makeshlibs
>>>  override so that tight enough dependencies are generated.
>>>
>>>  Using libebml as an example (debian/rules):
>>>  + override_dh_makeshlibs:
>>>  + # For new symbols when compiled with GCC 7
>>>  + dh_makeshlibs -V'libebml4v5 (>= 1.3.4-2~)'
>>> 
> 
> Any ideas how should I handle multiple packages in override_dh_makeshlibs
> zeroc-ice has several packages that include libzeroc-ice3.6,
> libzeroc-freeze3.6
> so I cannot really pass a single package name in -V 

Here's an example. SFML has 5 libraries and 2 of them have specific
dh_makeshlibs calls.

https://sources.debian.net/src/libsfml/2.4.2%2Bdfsg-4/debian/rules/#L18

In short, you use the -p option to apply a -V to a specific package and
then use --remaining-packages if there are any left.

I think that only the libzeroc-ice3.6 package is affected by this
(although you may want to double check) so you may only need to set the
dependencies for that package.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[James Cowgill]

Hi,

On 06/08/17 04:01, Edmund Grimley Evans wrote:
> As far as I know, the best way to implement run-time detection of
> hardware capabilities is with getauxval(AT_HWCAP) and
> getauxval(AT_HWCAP2).
> 
> There is some kind of NEON detection in ffmeg. See, for example:
> 
> https://sources.debian.net/src/ffmpeg/7:3.3.3-1/libavutil/arm/cpu.c/
> 
> That code appears to use /proc rather than getauxval. Is there a good
> reason for that?

I guess you would have to ask upstream to get an answer to this
question.

> In case someone reading this has access to hardware (or a simulator)
> without NEON but is not familiar with ffmpeg, what is a quick and easy
> way of checking whether ffmpeg is working?

I think the runtime is working, but this is the testcase from the SIGBUS
bug which you can use:

ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi 
libx264rgb.avi -y -hide_banner -nostdin
ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32le -f nut 
/dev/null -y -hide_banner -nostdin

Since the SIGBUS bug occurs in NEON code, if the runtime detection is
working, this will _only_ fail on machines with NEON and work on
non-NEON machines.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871544: jenkins.debian.org: jtx1b runs armhf builds with wrong personality

[James Cowgill]

Package: jenkins.debian.org
Severity: normal

Hi,

I noticed this build of ffmpeg in buster failed on armhf, while the same
version does build in the unstable version:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/ffmpeg.html
https://tests.reproducible-builds.org/debian/rbuild/buster/armhf/ffmpeg_3.3.3-1.rbuild.log

The configure log contains
> Mon Aug  7 07:36:24 UTC 2017  I: Starting 1st build on remote node 
> jtx1b-armhf-rb.debian.net.
[...]
>  *** standard ***
> install prefix/usr
> source path   /build/ffmpeg-3.3.3
> C compilergcc
> C library glibc
> ARCH  aarch64 (generic)

While I don't know for certain, my guess is that this is an aarch64
machine doing armhf builds, and the personality in the chroot has not
been set correctly for armhf. I don't know if pbuilder has this ability
(I know schroot does), but if not then you could use "setarch linux32"
instead.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871275: libapt-pkg5.0: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

Hi,

On 08/08/17 15:44, David Kalnischkies wrote:
> On Mon, Aug 07, 2017 at 03:47:15PM +0100, jcowg...@debian.org wrote:
>> In GCC 7, the name mangling for C++ conversion operators which return a
>> type using the abi_tag attribute (most commonly std::string) has
>> changed. When your library is compiled with GCC 7, it will now emit two
>> symbols for the conversion operator using the new and old naming.
>> Executables compiled with GCC 7 will always use the new symbol, while
>> old executables compiled using <= GCC 6 will use the old symbol. For new
>> executables to build without undefined references, your library will
>> need rebuilding with GCC 7.
> 
> On the upside, going through the list of severity pushes [0] I can spot
> only aptitude from our reverse build-dependencies – and while it is
> indeed using that API, it will stop doing so in the next upload
> (#853316) so the practical effect is rather low (assuming we can
> convince mafm to upload before we do I guess).
> 
> On a more theoretical note isn't there some way to emit a function with
> the old mangle calling the new mangle (or duplicating it)?
> I can't really believe that all of libstdc++6 doesn't contain a single
> abitagged conversion operator, so I would presume they managed to pull
> it of somehow (or we would be looking at v7 everywhere now).

Maybe I misunderstood your question, but if you compile a library
exporting an affected conversion operator using GCC 7, GCC will emit an
alias to ensure that the old and new symbols both work. This is why
there is no ABI break here - we just need to ensure these libraries are
rebuilt.

libstdc++6 doesn't need a workaround here. It doesn't need to
build-depend on gcc-7 because it's built from the same source. Beyond
that it added the new symbols to the symbols files like any other package.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#871288: libzeroc-ice3.6: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

On 08/08/17 11:29, Jose Gutierrez de la Concha wrote:
> On Tue, Aug 8, 2017 at 5:01 PM, James Cowgill <jcowg...@debian.org
> <mailto:jcowg...@debian.org>> wrote:
> [...]
> > - If your package does not provide a symbols file, add a 
> dh_makeshlibs
> >   override so that tight enough dependencies are generated.
> >
> >   Using libebml as an example (debian/rules):
> >   + override_dh_makeshlibs:
> >   + # For new symbols when compiled with GCC 7
> >   + dh_makeshlibs -V'libebml4v5 (>= 1.3.4-2~)'
> >
> > Does this work with dbgsym generated packages?
> 
> dh_makeshlibs has nothing to do with dbgsym packages. I'm not sure I
> quite understand your question.
> 
> As far as I can tell libzeroc-ice3.6 currently does not provide a shlibs
> or symbols
> file, so I guess we can skip this for now? 

It provides an shlibs file:
$ dpkg-deb -I libzeroc-ice3.6_3.6.3-5_amd64.deb
 new debian package, version 2.0.
 size 1905864 bytes: control archive=1639 bytes.
 728 bytes,18 lines  control
1293 bytes,16 lines  md5sums
 471 bytes,18 lines   *  postinst #!/bin/sh
 273 bytes,16 lines   *  postrm   #!/bin/sh
 398 bytes,12 lines  shlibs
  60 bytes, 2 lines  triggers

James



signature.asc
Description: OpenPGP digital signature

Bug#871300: [Pkg-gmagick-im-team] Bug#871300: libmagick++-6.q16-7: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

Hi,

On 07/08/17 16:55, roucaries bastien wrote:
> On Mon, Aug 7, 2017 at 4:47 PM,   wrote:
>> Package: libmagick++-6.q16-7
>> Version: 8:6.9.7.4+dfsg-16
>> Severity: serious
>> Tags: sid buster
>> User: debian-...@lists.debian.org
>> Usertags: gcc-7-op-mangling
>>
> 
> I need a change that break ABI, I will release a new version. Does it
> exist in this case a short cut

If you are going to rename the Debian package and trigger a package
transition, you do not need to add any of the extra symbols/shlibs
stuff. You should still build-depend on gcc (>= 4:7) however - I'm not
sure if all the buildds use GCC 7 by default yet.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#870936: mediatomb: should mediatomb be removed from unstable?

[James Cowgill]

Hi,

On 06/08/17 09:50, Lucas Nussbaum wrote:
> Source: mediatomb
> User: debian...@lists.debian.org
> Usertags: qa-removals-post-stretch
> 
> Hi,
> 
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package 
> from
> unstable, because:
> 
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.

The answer is: yes it definitely should be removed.

However, there is a replacement fork called gerbera (which I haven't
finished packaging yet) and I don't want to lose all the open bugs
against mediatomb which may also apply to gerbera. I'm going to try and
finish it some time during DebConf so hopefully this won't be an issue...

Thanks,
James



> 
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
> 
> If this bug is still open one month from now (on 2017-09-06), it will be 
> turned
> into a removal request, using:
> 
>   reassign -1 ftp.debian.org
>   retitle -1 RM: mediatomb -- RoQA; missed both jessie and stretch
>   thanks
> 
> - Lucas, for the QA team.
> 
> 
> [1] https://lists.debian.org/debian-qa/2017/07/msg00021.html
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
> 




signature.asc
Description: OpenPGP digital signature

Bug#870896: libmatroska6v5: Please rebuild against GCC 7 to fix bug 853553

[James Cowgill]

Control: tags -1 moreinfo

Hi Christian,

On 06/08/17 02:29, Christian Marillat wrote:
> Package: libmatroska6v5
> Version: 1.4.7-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Now we have libebml in ustable the same (Rebuild against GCC 7) is
> needed for libmatroska

Why do you think libmatroska needs rebuilding against GCC 7 ? I don't
think it contains any symbols which would be affected by a GCC 7 rebuild.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

[James Cowgill]

Hi Steve,

On 03/08/17 21:03, Steve Langasek wrote:
> Package: ffmpeg
> Version: 7:3.3.3-1
> Severity: important
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu artful ubuntu-patch autopkgtest
> 
> Dear maintainers,
> 
> The latest release of ffmpeg enables NEON support by default when building
> on armhf; however, NEON support is not a standard part of the ARMv7 ABI, and
> Debian supports running armhf on chips that do not implement NEON.
> 
> Using NEON based on runtime detection of support for it is fine, but the
> existing ffmpeg implementation doesn't appear to do this, instead using NEON
> based on build-time configuration with no fallback.

Are you sure this is true? I tried running the failing test on abel.d.o
(which AFAIK does not have NEON) and harris (which does). The test only
caused ffmpeg to crash on harris, which seems to suggest that the
runtime NEON detection is working properly.

These are the commands to reproduce the autopkgtest fail if you want to
try it:

ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi 
libx264rgb.avi -y -hide_banner -nostdin
ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32le -f nut 
/dev/null -y -hide_banner -nostdin

> This issue was noticed in Ubuntu only because the autopkgtests for ffmpeg
> and x264 triggered an unaligned access in the NEON code, which is *also* not
> a portable assumption on armhf; however, if the NEON code had not had any
> unaligned access, the fact that NEON was used would have gone unnoticed on
> Ubuntu infrastructure.
> 
>   http://autopkgtest.ubuntu.com/packages/f/ffmpeg/artful/armhf
>   http://autopkgtest.ubuntu.com/packages/x/x264/artful/armhf
> 
> (And if upstream does fix their code to support runtime detection of NEON
> support, then there will be a different bug for us to worry about fixing!)

This is #870622 BTW. If possible, I would much rather fix these bugs
without having to disable all the NEON optimizations.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

[James Cowgill]

Hi,

On 04/08/17 09:58, Jiong Wang wrote:
> Change
> 
>   "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB"
> 
> Into:
> 
> .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon)
> adreq lr,  ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB
> 
> might be a solution.  The idea is we use .eqv to remove the function
> attribute, so the assembler won't set LSB in any case.

This was the commit which introduced the +CONFIG_THUMB stuff:
https://github.com/FFmpeg/FFmpeg/commit/8986fddc2bab92bd7d77a123ac70c4fb70c96c7c

On the technical side, does having the LSB clear when executing a blx
instruction cause a mode change out of Thumb, or does it retain the
mode? I think all the code in that file is compiled in the same mode, so
if the mode is retained then simply dropping +CONFIG_THUMB might work.

Would it be possible for you or someone with better ARM assembly
experience to submit the fixes upstream? It would help greatly.

On Debian, there is #870676 open about NEON code on ARM. We could "fix"
this bug and that one by disabling NEON but it would be nice if we
didn't have to do that.

Thanks,
James

> On 04/08/17 12:39, Jiong Wang wrote:
>> Hi,
>>
>>   This issue is caused by a recent change in ARM assembler included
>> since Binutils 2.29.
>>
>>   The details of that change can be found at
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
>>
>>   The semantics of ADR has changed.  In general, the address generated
>> by ADR will guarantee the LSB be set if it's a thumb function address.
>>
>>I noticed h264idct_neon.S is using something like:
>>
>>  adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB
>>
>>As ADR now will set the LSB automatically, you don't need
>> CONFIG_THUMB any more.
>>
>>I think h264idct_neon.S needs to be updated, and the modification
>> should make sure it works with both old Binutils and the new one.
>>
>> Regards,
>> Jiong



signature.asc
Description: OpenPGP digital signature

Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

[James Cowgill]

Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org

Hi,

I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz

It fails with SIGBUS when running the h264 tests.

> (gdb) bt 
> #0  0xf6456e12 in ff_h264_idct_add_neon () at 
> src/libavcodec/arm/h264idct_neon.S:24
> #1  0xf6456f3c in ff_h264_idct_add16_neon () at 
> src/libavcodec/arm/h264idct_neon.S:118
> #2  0xf659c88c in hl_decode_mb_idct_luma (p=, 
> dest_y=, linesize=, block_offset= out>, pixel_shift=0, transform_bypass=0, simple=1,
> mb_type=, sl=, h=) at 
> src/libavcodec/h264_mb.c:778
> #3  hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=) at 
> src/libavcodec/h264_mb_template.c:349
> #4  0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00, 
> sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
> #5  0xf65b3670 in decode_slice (avctx=, 
> arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
> #6  0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at 
> src/libavcodec/h264_slice.c:2728
> #7  0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "", 
> h=0xaab6ea00) at src/libavcodec/h264dec.c:715
> #8  h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70, 
> got_frame=0xaab38a2c, avpkt=) at src/libavcodec/h264dec.c:1016
> #9  0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at 
> src/libavcodec/pthread_frame.c:199
> #10 0xf61895e8 in start_thread () from 
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6

> (gdb) print $pc
> $1 = (void (*)()) 0xf6456e12 

> (gdb) disassemble
> Dump of assembler code for function ff_h264_idct_add_neon:
>0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
>0xf6456e14 <+4>: vmov.i16q15, #0 ; 0x
>0xf6456e18 <+8>: vswpd1, d2
>0xf6456e1c <+12>:vst1.16 {d30-d31}, [r1 :128]!

Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.

Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:

> --- h264idct_neon-binutils-2.28-5   2017-08-03 12:48:07.560036237 +
> +++ h264idct_neon-binutils-2.29-3   2017-08-03 12:47:43.666083113 +
> @@ -89,8 +89,8 @@
>   118:  f04f 0e00   movne.w lr, #0
>   11c:  f1be 0f00   cmp.w   lr, #0
>   120:  bf14ite ne
> - 122:  f2af 0e7f   subwne  lr, pc, #127; 0x7f
> - 126:  f2af 1e27   subweq  lr, pc, #295; 0x127
> + 122:  f2af 0e7e   subwne  lr, pc, #126; 0x7e
> + 126:  f2af 1e26   subweq  lr, pc, #294; 0x126
>   12a:  47f0blx lr
>   12c:  f1bc 0c01   subs.w  ip, ip, #1
>   130:  f101 0120   add.w   r1, r1, #32
[...]

Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869241: python-libnacl FTBFS: Illegal instruction

[James Cowgill]

Hi,

On 01/08/17 10:59, Colin Watson wrote:
> On Fri, Jul 21, 2017 at 11:55:28PM +0300, Adrian Bunk wrote:
>> Source: python-libnacl
>> Version: 1.5.2-1
>> Severity: serious
>>
>> https://buildd.debian.org/status/fetch.php?pkg=python-libnacl=all=1.5.2-1=1500664052=0
>>
>> ...
>>dh_auto_test -i -O--buildsystem=pybuild
>> I: pybuild base:184: cd /<>/.pybuild/pythonX.Y_2.7/build; 
>> python2.7 -m nose tests
>> Illegal instruction
>> E: pybuild pybuild:283: test: plugin distutils failed with: exit code=132: 
>> cd /<>/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose tests
>> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
>> debian/rules:7: recipe for target 'build-indep' failed
>> make: *** [build-indep] Error 25
> 
> I think this can only be a bug in libsodium rather than in
> python-libnacl as such; presumably somewhere in crypto_aead_aes256gcm_*
> or crypto_aead_chacha20poly1305_ietf_* which are newly used in
> python-libnacl 1.5.2.  But I can't reproduce it locally, and the Ubuntu
> builders seemed happy with it too, so perhaps it has something to do
> with the CPU or the kernel version, or perhaps it was fixed in libsodium
> 1.0.13 (the failure was with 1.0.12).
> 
> Before embarking on any more time-consuming investigation, could the
> build be given back to see if libsodium 1.0.13 helps?

It fails on barriere.debian.org with libsodium 1.0.13. Looking at
/proc/cpuinfo, barriere does not have the x86 AES instructions.

> (gdb) bt
> #0  0x74a46c3f in crypto_aead_aes256gcm_beforenm () from 
> /usr/lib/x86_64-linux-gnu/libsodium.so
> #1  0x74a49cd1 in crypto_aead_aes256gcm_encrypt () from 
> /usr/lib/x86_64-linux-gnu/libsodium.so
> #2  0x74c72038 in ffi_call_unix64 () from 
> /usr/lib/x86_64-linux-gnu/libffi.so.6
> #3  0x74c71a9a in ffi_call () from 
> /usr/lib/x86_64-linux-gnu/libffi.so.6
> #4  0x74e85e84 in _ctypes_callproc () from 
> /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
> #5  0x74e85845 in ?? () from 
> /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
> #6  0x55640163 in PyObject_Call ()
> #7  0x55659622 in PyEval_EvalFrameEx ()
[...]

> (gdb) disassemble
> Dump of assembler code for function crypto_aead_aes256gcm_beforenm:
>0x74a46c20 <+0>: movdqu (%rsi),%xmm1
>0x74a46c24 <+4>: xor%eax,%eax
>0x74a46c26 <+6>: pxor   %xmm0,%xmm0
>0x74a46c2a <+10>:movaps %xmm1,0x10(%rdi)
>0x74a46c2e <+14>:movdqa %xmm1,%xmm3
>0x74a46c32 <+18>:shufps $0x10,%xmm1,%xmm0
>0x74a46c36 <+22>:movdqu 0x10(%rsi),%xmm2
>0x74a46c3b <+27>:pxor   %xmm0,%xmm3
> => 0x74a46c3f <+31>:aeskeygenassist $0x1,%xmm2,%xmm12
>0x74a46c46 <+38>:movdqa %xmm2,%xmm14
>0x74a46c4b <+43>:movaps %xmm2,0x20(%rdi)
>0x74a46c4f <+47>:shufps $0x8c,%xmm3,%xmm0
>0x74a46c53 <+51>:pshufd $0xff,%xmm12,%xmm12
>0x74a46c59 <+57>:pxor   %xmm0,%xmm12
>0x74a46c5e <+62>:shufps $0x10,%xmm2,%xmm0

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#868936: vlc: port to libupnp-1.8

[James Cowgill]

Hi,

On 31/07/17 14:50, Marcelo Roberto Jimenez wrote:
> I personally don't like that change of names. I agree that it is not the
> proper way to do it. It was done as a temporary hack to allow both libs
> to be installed. Since libupnp 1.8 is finally advancing, this should no
> longer be the case.
> 
> So, I think libupnp should come back to the proper naming scheeme, but
> IIRC, some Debian apps will be affected, since installing both libs has
> been a Debian request.

This appears to where it was decided?  I'm not sure I can remember
asking you to change the package names.
https://github.com/mrjimenez/pupnp/issues/15

The argument in that thread is about co-installing libraries. This isn't
a problem for Debian (at runtime at least) because the libraries and
headers are in separate packages. It may be an issue for other
distributions though.

There is currently nothing in Debian depending on libupnp 1.8 so large
changes such as this are not a problem at the moment.

Thanks,
James
> On Fri, Jul 28, 2017 at 12:05 PM, Jean-Baptiste Kempf  > wrote:
> 
> Hello Sebastian, Bugreporters,
> 
> On Fri, 21 Jul 2017, at 14:58, Sebastian Ramacher wrote:
> > > On Thu, Jul 20, 2017 at 02:34:42PM +0200, Sebastian Ramacher wrote:
> > > > > currently there are two versions of libupnp in the archive 
> (libupnp6 and
> > > > > libupnp-1.8-10). To be able to remove libupnp6 (i.e. the older of 
> the
> > > > > two) it is necessary to port vlc (and all other rdepends) to
> > > > > libupnp-1.8.
> > > > >
> > > > > The patch below implements this for vlc. With this applied I can 
> still
> > > > > playback videos with vlc.
> > > >
> > > > As long as the adoption to upnp 1.8 requires to add -1.8 everywhere 
> (are we
> > > > supposed to change it to -1.9 next month with the next upstream 
> release?), this
> > > > was explicitly NAKed upstream.
> > >
> > > Which upstream? vlc I suppose? Do you have a link to the discussion
> > > handy?
> >
> > Yes, vlc upstream. This was over IRC and I don't have logs. But I'm sure
> > J-B
> > will repeat it if necessary (CCed)
> 
> Sure.
> 
> Since when releasing a new version of a library requires changing all
> the includes and all the pkg-config detection?
> 
> SO names are done to notate API/ABI changes within a library and
> PKG-CONFIG files are done to show where to find the includes folder and
> how to link.
> 
> If you do a moderate breaking change, you change the API, the ABI, and
> bump the library version name majorly. And people linking against you
> will need to adapt, when they bump the requirements. This was done for
> almost every minor C/C++ library, since forever.
> 
> So, sorry, but this way of renaming the headers folder name and changing
> the .pc files is completely backward; and sorry, totally not justified,
> because it's justified for complete rewrites, not for a moderate change.
> 
> If you want to do that anyway, at least provide the same .pc file name
> which gives the new includes.
> 
> Best,
> 
> 
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#870233: smplayer: executes javascript code downloaded from insecure URL

[James Cowgill]

Control: found -1 14.9.0~ds0-1
Control: fixed -1 17.7.0~ds0-1

Hi,

On 31/07/17 06:45, Jonas Smedegaard wrote:
> Source: smplayer
> Version: 17.7.0~ds0-1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> smplayer includes code in src/basegui.cpp to download and (I guess)
> execute javascript code for parsing youtube paths.  The download URL is
> http://updates.smplayer.info/yt.js which is insecure and therefore I
> suspect easy to replace with evil code.

If I am reading the code correctly, it looks like the javascript
download code is gated on the YT_USE_YTSIG define which is disabled in
the version in buster/sid:

https://sources.debian.net/src/smplayer/17.7.0~ds0-1/src/smplayer.pro/#L439

However, it is enabled in stretch and jessie (with a slightly different
define in jessie):

https://sources.debian.net/src/smplayer/16.11.0~ds0-1/src/smplayer.pro/#L442
https://sources.debian.net/src/smplayer/14.9.0~ds0-1/src/smplayer.pro/#L339

So I think this bug only affects those versions.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865516: ffmpeg: please compile with --enable-libzmq

[James Cowgill]

Hi,

On 22/06/17 10:39, Jonas Smedegaard wrote:
> Package: ffmpeg
> Version: 7:3.2.6-1
> Severity: wishlist
> 
> FFMpeg supports altering states during runtime via ZeroMQ.
> 
> Please enable that feature, by build-depending on libzeromq-dev and
> configure with --enable-libzmq option.

It looks to me like this has already been enabled? It's even enabled in
stretch.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869778: Re: Bug#869778: libgsl2: soname change breaks dependencies

[James Cowgill]

Hi,

On 26/07/17 16:18, Dirk Eddelbuettel wrote:
> On 26 July 2017 at 15:36, James Cowgill wrote:
> | On 26/07/17 15:10, Dirk Eddelbuettel wrote:
> | > On 26 July 2017 at 14:48, James Cowgill wrote:
> | > | On 26/07/17 14:39, Dirk Eddelbuettel wrote:
> | > | > On 26 July 2017 at 15:18, Julien Cristau wrote:
> | > | > | Control: reopen -1
> | > | > | 
> | > | > | On Wed, Jul 26, 2017 at 12:57:55 +0100, James Cowgill wrote:
> | > | > | 
> | > | > | > Hi,
> | > | > | > 
> | > | > | > On 26/07/17 12:32, Dirk Eddelbuettel wrote:
> | > | > | > > On 26 July 2017 at 13:14, Michal Politowski wrote:
> | > | > | > > | Package: libgsl2
> | > | > | > > | Version: 2.4+dfsg-1
> | > | > | > > | Severity: important
> | > | > | > > | 
> | > | > | > > | libgsl2 2.3+dfsg-1 contains 
> /usr/lib/i386-linux-gnu/libgsl.so.19 (on i386)
> | > | > | > > | libgsl2 2.4+dfsg-1 contains 
> /usr/lib/i386-linux-gnu/libgsl.so.23
> | > | > | > > | this breaks packages depending on libgsl2.
> | > | > | > > | 
> | > | > | > > | If the soname changed, package name must change too.
> | > | > | > > 
> | > | > | > > Right.  I'll change the soname.
> | > | > | > 
> | > | > | > From NEWS:
> | > | > | > > ** removed routines which were deprecated in v2.1:
> | > | > | > >  gsl_bspline_deriv_alloc
> | > | > | > >  gsl_bspline_deriv_free
> | > | > | > 
> | > | > | > Isn't this an ABI break? If so, upstream changing the SONAME was 
> correct
> | > | > | > and the package should be renamed (instead of reusing the old
> | > | > | > incompatible SONAME).
> | > | > | > 
> | > | > | Yes.  You need to either bump SONAME *and* change package name, or 
> keep
> | > | > | the package name and SONAME but revert the ABI breakage.  There's no
> | > | > | option where you get to break ABI but keep the SONAME and/or package
> | > | > | name.
> | > | > 
> | > | > Allow me to quote myself from a reply I just sent a minute ago:
> | > | > 
> | > | >We have this discussion on every release.  Look what is in 
> (upstream's)
> | > | >configure.ac:
> | > | >
> | > | >dnl Library versioning (C:R:A == current:revision:age)
> | > | >dnl See the libtool manual for an explanation of the numbers
> | > | >dnl
> | > | >dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
> | > | >dnl gsl-1.1libgsl 1:0:1  libgslcblas 0:0:0
> | > | >dnl gsl-1.1.1  libgsl 2:0:2  libgslcblas 0:0:0
> | > | >dnl gsl-1.2libgsl 3:0:3  libgslcblas 0:0:0
> | > | >dnl gsl-1.3libgsl 4:0:4  libgslcblas 0:0:0
> | > | >dnl gsl-1.4libgsl 5:0:5  libgslcblas 0:0:0
> | > | >dnl gsl-1.5libgsl 6:0:6  libgslcblas 0:0:0
> | > | >dnl gsl-1.6libgsl 7:0:7  libgslcblas 0:0:0
> | > | >dnl gsl-1.7libgsl 8:0:8  libgslcblas 0:0:0
> | > | >dnl gsl-1.8libgsl 9:0:9  libgslcblas 0:0:0
> | > | >dnl gsl-1.9libgsl 10:0:10 libgslcblas 0:0:0 
> | > | >dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0 
> | > | >dnl gsl-1.11   libgsl 12:0:12  libgslcblas 0:0:0 
> | > | >dnl gsl-1.12   libgsl 13:0:13  libgslcblas 0:0:0 
> | > | >dnl gsl-1.13   libgsl 14:0:14  libgslcblas 0:0:0 
> | > | >dnl gsl-1.14   libgsl 15:0:15  libgslcblas 0:0:0 
> | > | >dnl gsl-1.15   libgsl 16:0:16  libgslcblas 0:0:0 
> | > | >dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0 
> | > | >dnl gsl-2.0libgsl 18:0:18  (**) libgslcblas 0:0:0 
> | > | >dnl gsl-2.1libgsl 19:0:0   libgslcblas 0:0:0 
> | > | >dnl gsl-2.2libgsl 20:0:1   libgslcblas 0:0:0 
> | > | >dnl gsl-2.2.1  libgsl 21:0:2   libgslcblas 0:0:0 
> | > | >dnl gsl-2.3libgsl 22:0:3   libgslcblas 0:0:0 
> | > | >dnl gsl-2.4libgsl 23:0:0   libgslcblas 0:0:0 
> | > | >dnl 
> | > | >dnl (*) There was an error on this release.  Firstly, the 
> versioning
> | > | >dnl numbers were not updated.  Secondly, 2 functions were removed, 
> but
> | > | >dnl the age not reset--this should have been 11:0:0.  However these
> | > | >dnl functions were not documented and are regarded as internal, so 
> we
> | > | >dnl will assume 11:0:11.
> | > | >dnl
> | > | >dnl (**) There was an error on this releas

Bug#866532: inkscape: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory

[James Cowgill]

Hi,

On 26/07/17 15:51, José Luis García Pallero wrote:
> Using Debian Sid I've installed from the official repositories the
> packages inkscape 0.92.1-2 and libgsl2 2.4+dfsg-1, but I obtain the
> error:
> 
> inkscape: error while loading shared libraries: libgsl.so.19: cannot
> open shared object file: No such file or directory
> 
> I can't understand why inkscape is asking for libgsl.so.19

This is a different bug caused by libgsl2 2.4+dfsg-1 (#869778). If you
downgrade back to 2.3+dfsg-1 it should work again.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869778: Re: Bug#869778: libgsl2: soname change breaks dependencies

[James Cowgill]

Hi,

On 26/07/17 15:10, Dirk Eddelbuettel wrote:
> On 26 July 2017 at 14:48, James Cowgill wrote:
> | On 26/07/17 14:39, Dirk Eddelbuettel wrote:
> | > On 26 July 2017 at 15:18, Julien Cristau wrote:
> | > | Control: reopen -1
> | > | 
> | > | On Wed, Jul 26, 2017 at 12:57:55 +0100, James Cowgill wrote:
> | > | 
> | > | > Hi,
> | > | > 
> | > | > On 26/07/17 12:32, Dirk Eddelbuettel wrote:
> | > | > > On 26 July 2017 at 13:14, Michal Politowski wrote:
> | > | > > | Package: libgsl2
> | > | > > | Version: 2.4+dfsg-1
> | > | > > | Severity: important
> | > | > > | 
> | > | > > | libgsl2 2.3+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.19 
> (on i386)
> | > | > > | libgsl2 2.4+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.23
> | > | > > | this breaks packages depending on libgsl2.
> | > | > > | 
> | > | > > | If the soname changed, package name must change too.
> | > | > > 
> | > | > > Right.  I'll change the soname.
> | > | > 
> | > | > From NEWS:
> | > | > > ** removed routines which were deprecated in v2.1:
> | > | > >  gsl_bspline_deriv_alloc
> | > | > >  gsl_bspline_deriv_free
> | > | > 
> | > | > Isn't this an ABI break? If so, upstream changing the SONAME was 
> correct
> | > | > and the package should be renamed (instead of reusing the old
> | > | > incompatible SONAME).
> | > | > 
> | > | Yes.  You need to either bump SONAME *and* change package name, or keep
> | > | the package name and SONAME but revert the ABI breakage.  There's no
> | > | option where you get to break ABI but keep the SONAME and/or package
> | > | name.
> | > 
> | > Allow me to quote myself from a reply I just sent a minute ago:
> | > 
> | >We have this discussion on every release.  Look what is in (upstream's)
> | >configure.ac:
> | >
> | >dnl Library versioning (C:R:A == current:revision:age)
> | >dnl See the libtool manual for an explanation of the numbers
> | >dnl
> | >dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
> | >dnl gsl-1.1libgsl 1:0:1  libgslcblas 0:0:0
> | >dnl gsl-1.1.1  libgsl 2:0:2  libgslcblas 0:0:0
> | >dnl gsl-1.2libgsl 3:0:3  libgslcblas 0:0:0
> | >dnl gsl-1.3libgsl 4:0:4  libgslcblas 0:0:0
> | >dnl gsl-1.4libgsl 5:0:5  libgslcblas 0:0:0
> | >dnl gsl-1.5libgsl 6:0:6  libgslcblas 0:0:0
> | >dnl gsl-1.6libgsl 7:0:7  libgslcblas 0:0:0
> | >dnl gsl-1.7libgsl 8:0:8  libgslcblas 0:0:0
> | >dnl gsl-1.8libgsl 9:0:9  libgslcblas 0:0:0
> | >dnl gsl-1.9libgsl 10:0:10 libgslcblas 0:0:0 
> | >dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0 
> | >dnl gsl-1.11   libgsl 12:0:12  libgslcblas 0:0:0 
> | >dnl gsl-1.12   libgsl 13:0:13  libgslcblas 0:0:0 
> | >dnl gsl-1.13   libgsl 14:0:14  libgslcblas 0:0:0 
> | >dnl gsl-1.14   libgsl 15:0:15  libgslcblas 0:0:0 
> | >dnl gsl-1.15   libgsl 16:0:16  libgslcblas 0:0:0 
> | >dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0 
> | >dnl gsl-2.0libgsl 18:0:18  (**) libgslcblas 0:0:0 
> | >dnl gsl-2.1libgsl 19:0:0   libgslcblas 0:0:0 
> | >dnl gsl-2.2libgsl 20:0:1   libgslcblas 0:0:0 
> | >dnl gsl-2.2.1  libgsl 21:0:2   libgslcblas 0:0:0 
> | >dnl gsl-2.3libgsl 22:0:3   libgslcblas 0:0:0 
> | >dnl gsl-2.4libgsl 23:0:0   libgslcblas 0:0:0 
> | >dnl 
> | >dnl (*) There was an error on this release.  Firstly, the versioning
> | >dnl numbers were not updated.  Secondly, 2 functions were removed, but
> | >dnl the age not reset--this should have been 11:0:0.  However these
> | >dnl functions were not documented and are regarded as internal, so we
> | >dnl will assume 11:0:11.
> | >dnl
> | >dnl (**) There was an error on this release. Age should have been
> | >dnl reset to 18:0:0
> | >
> | >I maitained this for close to 20 years, and we done (IIRC) ONE soname 
> change.
> | 
> | The list above only contains 3 ABI changes, of which one was "ignored"
> | by upstream.
> | 
> | The first one (ignored as detailed above):
> | > dnl gsl-1.9libgsl 10:0:10 libgslcblas 0:0:0
> | > dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0
> | 
> | One here:
> | > dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0
> | > dnl gsl-2.0libgsl 18:0:18  (**) libgslcblas 0:0:0
> | > dnl gsl-2.1libgsl 19:0:0   libgslc

Bug#869778: Re: Bug#869778: libgsl2: soname change breaks dependencies

[James Cowgill]

Hi,

On 26/07/17 14:39, Dirk Eddelbuettel wrote:
> On 26 July 2017 at 15:18, Julien Cristau wrote:
> | Control: reopen -1
> | 
> | On Wed, Jul 26, 2017 at 12:57:55 +0100, James Cowgill wrote:
> | 
> | > Hi,
> | > 
> | > On 26/07/17 12:32, Dirk Eddelbuettel wrote:
> | > > On 26 July 2017 at 13:14, Michal Politowski wrote:
> | > > | Package: libgsl2
> | > > | Version: 2.4+dfsg-1
> | > > | Severity: important
> | > > | 
> | > > | libgsl2 2.3+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.19 (on 
> i386)
> | > > | libgsl2 2.4+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.23
> | > > | this breaks packages depending on libgsl2.
> | > > | 
> | > > | If the soname changed, package name must change too.
> | > > 
> | > > Right.  I'll change the soname.
> | > 
> | > From NEWS:
> | > > ** removed routines which were deprecated in v2.1:
> | > >  gsl_bspline_deriv_alloc
> | > >  gsl_bspline_deriv_free
> | > 
> | > Isn't this an ABI break? If so, upstream changing the SONAME was correct
> | > and the package should be renamed (instead of reusing the old
> | > incompatible SONAME).
> | > 
> | Yes.  You need to either bump SONAME *and* change package name, or keep
> | the package name and SONAME but revert the ABI breakage.  There's no
> | option where you get to break ABI but keep the SONAME and/or package
> | name.
> 
> Allow me to quote myself from a reply I just sent a minute ago:
> 
>We have this discussion on every release.  Look what is in (upstream's)
>configure.ac:
>
>dnl Library versioning (C:R:A == current:revision:age)
>dnl See the libtool manual for an explanation of the numbers
>dnl
>dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
>dnl gsl-1.1libgsl 1:0:1  libgslcblas 0:0:0
>dnl gsl-1.1.1  libgsl 2:0:2  libgslcblas 0:0:0
>dnl gsl-1.2libgsl 3:0:3  libgslcblas 0:0:0
>dnl gsl-1.3libgsl 4:0:4  libgslcblas 0:0:0
>dnl gsl-1.4libgsl 5:0:5  libgslcblas 0:0:0
>dnl gsl-1.5libgsl 6:0:6  libgslcblas 0:0:0
>dnl gsl-1.6libgsl 7:0:7  libgslcblas 0:0:0
>dnl gsl-1.7libgsl 8:0:8  libgslcblas 0:0:0
>dnl gsl-1.8libgsl 9:0:9  libgslcblas 0:0:0
>dnl gsl-1.9libgsl 10:0:10 libgslcblas 0:0:0 
>dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0 
>dnl gsl-1.11   libgsl 12:0:12  libgslcblas 0:0:0 
>dnl gsl-1.12   libgsl 13:0:13  libgslcblas 0:0:0 
>dnl gsl-1.13   libgsl 14:0:14  libgslcblas 0:0:0 
>dnl gsl-1.14   libgsl 15:0:15  libgslcblas 0:0:0 
>dnl gsl-1.15   libgsl 16:0:16  libgslcblas 0:0:0 
>dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0 
>dnl gsl-2.0libgsl 18:0:18  (**) libgslcblas 0:0:0 
>dnl gsl-2.1libgsl 19:0:0   libgslcblas 0:0:0 
>dnl gsl-2.2libgsl 20:0:1   libgslcblas 0:0:0 
>dnl gsl-2.2.1  libgsl 21:0:2   libgslcblas 0:0:0 
>dnl gsl-2.3libgsl 22:0:3   libgslcblas 0:0:0 
>dnl gsl-2.4libgsl 23:0:0   libgslcblas 0:0:0 
>dnl 
>dnl (*) There was an error on this release.  Firstly, the versioning
>dnl numbers were not updated.  Secondly, 2 functions were removed, but
>dnl the age not reset--this should have been 11:0:0.  However these
>dnl functions were not documented and are regarded as internal, so we
>dnl will assume 11:0:11.
>dnl
>dnl (**) There was an error on this release. Age should have been
>dnl reset to 18:0:0
>
>I maitained this for close to 20 years, and we done (IIRC) ONE soname 
> change.

The list above only contains 3 ABI changes, of which one was "ignored"
by upstream.

The first one (ignored as detailed above):
> dnl gsl-1.9libgsl 10:0:10 libgslcblas 0:0:0
> dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0

One here:
> dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0
> dnl gsl-2.0libgsl 18:0:18  (**) libgslcblas 0:0:0
> dnl gsl-2.1libgsl 19:0:0   libgslcblas 0:0:0

And the current one we're talking about here:
> dnl gsl-2.3libgsl 22:0:3   libgslcblas 0:0:0
> dnl gsl-2.4libgsl 23:0:0   libgslcblas 0:0:0

James



signature.asc
Description: OpenPGP digital signature

Bug#869794: linbox: testsuite fails if ASan is enabled

[James Cowgill]

Source: linbox
Version: 1.4.2-4
Severity: normal

Hi,

Building the package with address sanitizer enabled triggers a buffer
overflow in the test-rank-md testcase and memory leaks in the
test-regression test case.

This can be reproduced by using DEB_BUILD_OPTIONS="sanitize=+address"

Log:

> PASS: test-commentator
> PASS: test-det
> PASS: test-frobenius
> PASS: test-rational-solver
> PASS: test-rational-solver-adaptive
> PASS: test-rank-u32
> PASS: test-rank-Int
> /bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. -fsanitize=address 
> -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security ../linbox/liblinbox.la -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp -o test-rank-md test-rank-md.o -lntl -lmpfr  
> -liml   -fopenmp -lblas -llapack -lgivaro -lgmpxx -lgmp  -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp 
> libtool: link: g++ -g -O2 -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. 
> -fsanitize=address -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -fopenmp -o .libs/test-rank-md test-rank-md.o -fopenmp -fsanitize=address 
> -Wl,-z -Wl,relro -Wl,-z -Wl,now -fopenmp  ../linbox/.libs/liblinbox.so -lntl 
> -lmpfr -liml -lblas -llapack -lgivaro -lgmpxx -lgmp -fopenmp
> PASS: test-cra
> FAIL: test-rank-md
> /bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. -fsanitize=address 
> -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security ../linbox/liblinbox.la -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp -o test-ntl-lzz_pex test-ntl-lzz_pex.o -lntl 
> -lmpfr  -liml   -fopenmp -lblas -llapack -lgivaro -lgmpxx -lgmp  
> -fsanitize=address -Wl,-z,relro -Wl,-z,now -fopenmp 
> libtool: link: g++ -g -O2 -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. 
> -fsanitize=address -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -fopenmp -o .libs/test-ntl-lzz_pex test-ntl-lzz_pex.o -fopenmp 
> -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now -fopenmp  
> ../linbox/.libs/liblinbox.so -lntl -lmpfr -liml -lblas -llapack -lgivaro 
> -lgmpxx -lgmp -fopenmp
> /bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. -fsanitize=address 
> -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security ../linbox/liblinbox.la -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp -o test-charpoly test-charpoly.o -lntl 
> -lmpfr  -liml   -fopenmp -lblas -llapack -lgivaro -lgmpxx -lgmp  
> -fsanitize=address -Wl,-z,relro -Wl,-z,now -fopenmp 
> PASS: test-ntl-lzz_pex
> libtool: link: g++ -g -O2 -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. 
> -fsanitize=address -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -fopenmp -o .libs/test-charpoly test-charpoly.o -fopenmp -fsanitize=address 
> -Wl,-z -Wl,relro -Wl,-z -Wl,now -fopenmp  ../linbox/.libs/liblinbox.so -lntl 
> -lmpfr -liml -lblas -llapack -lgivaro -lgmpxx -lgmp -fopenmp
> PASS: test-charpoly
> /bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. -fsanitize=address 
> -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security ../linbox/liblinbox.la -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp -o test-toeplitz-det test-toeplitz-det.o 
> -lntl -lmpfr  -liml   -fopenmp -lblas -llapack -lgivaro -lgmpxx -lgmp  
> -fsanitize=address -Wl,-z,relro -Wl,-z,now -fopenmp 
> libtool: link: g++ -g -O2 -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. 
> -fsanitize=address -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -fopenmp -o .libs/test-toeplitz-det test-toeplitz-det.o -fopenmp 
> -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now -fopenmp  
> ../linbox/.libs/liblinbox.so -lntl -lmpfr -liml -lblas -llapack -lgivaro 
> -lgmpxx -lgmp -fopenmp
> PASS: test-toeplitz-det
> /bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. -fsanitize=address 
> -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security ../linbox/liblinbox.la -fsanitize=address 
> -Wl,-z,relro -Wl,-z,now -fopenmp -o test-blas-matrix test-blas-matrix.o -lntl 
> -lmpfr  -liml   -fopenmp -lblas -llapack -lgivaro -lgmpxx -lgmp  
> -fsanitize=address -Wl,-z,relro -Wl,-z,now -fopenmp 
> libtool: link: g++ -g -O2 -fdebug-prefix-map=/tmp/linbox/linbox-1.4.2=. 
> -fsanitize=address -fno-omit-frame-pointer -fstack-protector-strong -Wformat 
> -Werror=format-security -fsanitize=address -Wl,-z -Wl,relro -Wl,-z -Wl,now 
> -fopenmp -o .libs/test-blas-matrix 

Bug#869781: libgsl2: bumped library version without soname change, breaking reverse dependencies

[James Cowgill]

Control: forcemerge 869778 -1

Hi,

On 26/07/17 12:31, Antonio Ospite wrote:
> Package: libgsl2
> Version: 2.4+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
> since libgsl2=2.4+dfsg-1 reverse dependencies are broken, I experienced
> the problem with bogofilter (which depends on bogofilter-bdb which
> depends on libgsl2):
> 
>   bogofilter: error while loading shared libraries: libgsl.so.19: cannot open 
> shared object file: No such file or directory
> 
> This seems to happens because 2.4+dfsg-1 bumped the library version but
> the package name is always the same and does not reflect the SONAME
> change.

This is a duplicate of #869778

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869778: Re: Bug#869778: libgsl2: soname change breaks dependencies

[James Cowgill]

Hi,

On 26/07/17 12:32, Dirk Eddelbuettel wrote:
> On 26 July 2017 at 13:14, Michal Politowski wrote:
> | Package: libgsl2
> | Version: 2.4+dfsg-1
> | Severity: important
> | 
> | libgsl2 2.3+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.19 (on i386)
> | libgsl2 2.4+dfsg-1 contains /usr/lib/i386-linux-gnu/libgsl.so.23
> | this breaks packages depending on libgsl2.
> | 
> | If the soname changed, package name must change too.
> 
> Right.  I'll change the soname.

From NEWS:
> ** removed routines which were deprecated in v2.1:
>  gsl_bspline_deriv_alloc
>  gsl_bspline_deriv_free

Isn't this an ABI break? If so, upstream changing the SONAME was correct
and the package should be renamed (instead of reusing the old
incompatible SONAME).

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869660: ffmpeg: choppy video playback in Kdenlive & VLC in sid

[James Cowgill]

Control: found -1 7:3.2.6-1
Control: notfound -1 7:3.2.5-1
Control: tags -1 moreinfo

Hi,

On 25/07/17 13:19, Vincent Pinon wrote:
> Package: ffmpeg
> Version: 7:3.2.5-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>Upgrading sid around mid july (after few weeks forgetting about it)
>suddenly made video programs very uncomfortable to use: noticed in
>Kdenlive, but VLC too.
>Problem also reported by other user on Kdenlive forum:
>https://forum.kde.org/viewtopic.php?f=265=140299
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>I forced downgrade back to stretch. Kdenlive & MLT versions remained
>the same, but libavcodec & co changed between 3.2.6 & 3.2.5
> 
>* What was the outcome of this action?
>Kdenlive is smooth to use in stretch, but only 1 or 2 fps & choppy
>audio in sid.
> 
>* What outcome did you expect instead?
>I expect video programs to work in sid.

Debian's VLC doesn't use the packaged version of FFmpeg so if you see
the issues in VLC, FFmpeg probably isn't to blame.

Stretch has FFmpeg 3.2.5 and sid has 3.2.6, however at the time your
linked thread started, FFmpeg 3.2.6 didn't exist. This means it's likely
they could reproduce it with an old FFmpeg.

Is it possible for you to try different versions of VLC and FFmpeg on
your system to see if they are the problem (eg: just upgrade ffmpeg to
sid)? Could you try other players as well like ffplay or mpv?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869411: Connections to youtube return 403

[James Cowgill]

On 23/07/17 10:58, Mateusz Łukasik wrote:
> Package: smplayer
> Version: 16.11.0~ds0-1
> Severity: grave
> 
> Hi,
> 
> Google change youtube api and all connections to youtube return error 403.
> 
> This bug has been already upstream fix.

Why do you consider this release-critical? To me, it seems important at
best.

James



signature.asc
Description: OpenPGP digital signature

Bug#869385: higan: FTBFS on arm64, mips* - error: unknown type name 'thread_local'

[James Cowgill]

Source: higan
Version: 103-1
Severity: serious
Tags: sid buster

Hi,

higan FTBFS on arm64, mips* and some ports architectures with the error:
> In file included from ../libco/libco.c:22:0:
> ../libco/sjlj.c:30:8: error: unknown type name 'thread_local'
>  static thread_local cothread_struct co_primary;
> ^~~~

This appears to be because the code uses C11's "thread_local" storage
type without including "threads.h" where it's declared.

Note I haven't done a test rebuild yet - I'm just guessing that this is
the cause.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#869180: src:hydrogen-drumkits: source contains unlicensed material (bogusly treated as GPL-2)

[James Cowgill]

Hi,

On 21/07/17 10:49, Jonas Smedegaard wrote:
> Package: src:hydrogen-drumkits
> Version: 2015.09.28-1
> Severity: serious
> Justification: Policy 2.2.1
> 
> These drumkits are in upstream metadata listed _without_ license:
> 
> ColomboAcousticDrumkit (sf)
> EasternHop (sf)
> Electric Empire (sf)
> HardElectro (sf)
> HipHop-1 (sf)
> HipHop-2 (sf)
> Millo's MultiLayered 2 (sf)
> Synthie-1 (sf)
> VariBreaks (sf)
> 
> In Debian copyright file those are listed as licensed GPL-2.

The fact that the metadata doesn't contain a license, does not imply
that these files are not GPL-2. Have you actually checked the license of
any of these?

For instance, a brief google search seems to indicate that the first one
on your list (ColomboAcousticDrumkit) is GPL-2 licensed:
http://freepats.zenvoid.org/Percussion/acoustic-drum-kit.html

James



signature.asc
Description: OpenPGP digital signature

Bug#869093: mpv: hwdec=vdpau now not supported?

[James Cowgill]

Control: clone -1 -2
Control: reassign -2 src:ffmpeg 7:3.2.6-1
Control: retitle -2 ffmpeg: please update to 3.3
Control: severity -2 wishlist
Control: block -1 by -2

Hi,

On 20/07/17 14:50, Arthur Marsh wrote:
> Package: mpv
> Version: 0.26.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Replaying a video that on the previous version of mpv used minimal cpu:
> 
> $ mpv --vo=vdpau --hwdec=vdpau *mp4
> Playing: blah.mp4
>  (+) Video --vid=1 (*) (h264 1920x1080 29.970fps)
>  (+) Audio --aid=1 --alang=jpn (*) (aac 2ch 48000Hz)
>  Audio --aid=2 --alang=jpn (*) (aac 6ch 48000Hz)
>  Audio --aid=3 --alang=jpn (*) (aac 2ch 48000Hz)
> Requested hardware decoder not compiled.
> AO: [pulse] 48000Hz stereo 2ch float
> VO: [vdpau] 1920x1080 yuv420p
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I checked the release notes, which stated:
> 
> VA-API/VDPAU hardware decoding now requires FFmpeg > 3.2.
> 
> and checked the installed ffmpeg:
> 
> ffmpeg 7:3.2.6-1+b3

Sorry, I didn't check VDPAU before uploading 0.26.0.

It appears there was a typo in the release notes - it should say that
ffmpeg 3.3 is required for VDPAU. This is the relevant upstream commit:

video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2:
https://github.com/mpv-player/mpv/commit/f59371de2170141fc28540d03c4e7ecc62844ebf

Unfortunately Debian doesn't yet have FFmpeg 3.3 so that feature was not
compiled into mpv at build time. Now that upstream has dropped the old
version, there is no alternative to fallback on.

I might be able to revert the upstream commit temporarily.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#868904: gwc: FTBFS: meschach/matrix.h:37:21: fatal error: machine.h: No such file or directory

[James Cowgill]

Control: forcemerge 868858 -1

On 19/07/17 16:46, Lucas Nussbaum wrote:
> Source: gwc
> Version: 0.22-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170719 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> gcc -DDATADIR=\"/usr/share\" -DHELPDIR=\"/usr/share/doc\" 
>> -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DAPPNAME=\"gtk-wave-cleaner\"  
>> -DHAVE_ALSA  -DHAVE_FFTW3 -DFFTWPREC=2 -DHAVE_OGG -DHAVE_MP3  -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -Wall -g -O2 
>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -pthread -I/usr/include/gtk-2.0 
>> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
>> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
>> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 
>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
>> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
>> -I/usr/include/freetype2   -c i0.c
>> fmacheps.c:37:1: warning: return type defaults to 'int' [-Wimplicit-int]
>>  main()
>>  ^~~~
>> In file included from stat.h:1:0,
>>  from stat.c:11:
>> meschach/matrix.h:37:21: fatal error: machine.h: No such file or directory
>>  #include "machine.h"
>>  ^
>> compilation terminated.

Duplicate of #868858

James



signature.asc
Description: OpenPGP digital signature

Bug#868915: gpac: FTBFS: faad_dec.c:408:35: error: expected '; ' before 'PACKAGE_VERSION'

[James Cowgill]

Control: reassign -1 libfaad-dev
Control: forcemerge 868854 -1

Hi,

On 19/07/17 16:42, Lucas Nussbaum wrote:
> Source: gpac
> Version: 0.5.2-426-gc5ad4e4+dfsg5-3
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170719 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> gcc -O2  -Wall -fPIC -DPIC -I/usr/include/mozjs -DXP_UNIX -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -g -O2 
>> -fdebug-prefix-map=/<>/gpac-0.5.2-426-gc5ad4e4+dfsg5=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
>> -fno-strict-aliasing -Wno-pointer-sign -fPIC -DPIC -msse2 
>> -DGPAC_HAVE_CONFIG_H -I"/<>/gpac-0.5.2-426-gc5ad4e4+dfsg5" 
>> -fvisibility="hidden" 
>> -I"/<>/gpac-0.5.2-426-gc5ad4e4+dfsg5/include" -g -DGPAC_HAS_FAAD 
>> -c -o faad_dec.o faad_dec.c
>> In file included from faad_dec.c:40:0:
>> /usr/include/faad.h:32:9: note: #pragma message: please update faad2 include 
>> filename and function names!
>>  #pragma message("please update faad2 include filename and function names!")
>>  ^~~
>> In file included from /usr/include/faad.h:35:0,
>>  from faad_dec.c:40:
>> faad_dec.c: In function 'FAAD_GetCodecName':
>> faad_dec.c:408:35: error: expected ';' before 'PACKAGE_VERSION'
>>   if (ctx->is_sbr) return "FAAD2 " FAAD2_VERSION " SBR mode";
>>^
>> faad_dec.c:409:18: error: expected ';' before 'PACKAGE_VERSION'
>>   return "FAAD2 " FAAD2_VERSION;
>>   ^

This is #868854 in ffad2.

James



signature.asc
Description: OpenPGP digital signature

Bug#868787: erlang-p1-cache-tab: FTBFS on mips, mipsel and powerpc: undefined symbol: __sync_add_and_fetch_8'

[James Cowgill]

Source: erlang-p1-cache-tab
Version: 1.0.9-1
Severity: serious
Tags: sid buster patch

Hi,

erlang-p1-cache-tab FTBFS on mips, mipsel and powerpc with this error
while running the testsuite:
> Failed to load NIF /<>/priv/lib/ets_cache: Failed to load NIF 
> library: '/<>/priv/lib/ets_cache.so: undefined symbol: 
> __sync_add_and_fetch_8' (load_failed)

This happens because these architectures do not implement 64-bit atomics
natively. The fix is to use libatomic (part of GCC) which provides
helper routines for these missing atomics, implemented using locks.

The attached patch does this by:
- Linking against libatomic
- Switching from __sync_add_and_fetch to __atomic_add_fetch

One side effect of this is that libatomic is pulled in on every
architecture. If you don't like this, you can use -Wl,--as-needed.

Thanks,
James
--- a/c_src/ets_cache.c
+++ b/c_src/ets_cache.c
@@ -100,7 +100,7 @@ static ERL_NIF_TERM incr_counter(ErlNifE
   if (enif_get_uint(env, argv[0], ))
 if (counter < max_counters) {
   if (counters[counter] != MAX_UINT64)
-	return enif_make_uint64(env, __sync_add_and_fetch(counters + counter, 1));
+	return enif_make_uint64(env, __atomic_add_fetch(counters + counter, 1, __ATOMIC_SEQ_CST));
 }
 
   return enif_make_badarg(env);
--- a/rebar.config
+++ b/rebar.config
@@ -24,7 +24,7 @@
 
 
 {port_specs, [{"priv/lib/ets_cache.so", ["c_src/ets_cache.c"]}]}.
-{port_env, [{"CFLAGS", "$CFLAGS -g -O2 -Wall"}]}.
+{port_env, [{"CFLAGS", "$CFLAGS -g -O2 -Wall"}, {"LDFLAGS", "$LDFLAGS -latomic"}]}.
 
 {cover_enabled, true}.
 {cover_export_enabled, true}.


signature.asc
Description: OpenPGP digital signature

Bug#867358: mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address

[James Cowgill]

Hi,

On 16/07/17 23:31, Ben Hutchings wrote:
> Control: tag -1 upstream patch
> 
> On Sun, 2017-07-16 at 23:21 +0100, Ben Hutchings wrote:
>> On Thu, 2017-07-06 at 13:10 +0300, Adrian Bunk wrote:
>>> Control: reassign -1 src:linux 4.9.30-2
>>> Control: retitle -1 mips/mipsel: mips-linux-gnu-gccgo-7: waitid: bad address
>>> Control: affects -1 src:golang-github-pelletier-go-toml 
>>> src:golang-github-nicksnyder-go-i18n gccgo-7
>>>
>>> On Thu, Jul 06, 2017 at 02:11:00AM +0300, Adrian Bunk wrote:
>>>> Source: golang-github-pelletier-go-toml
>>>> Version: 1.0.0-1
>>>> Severity: serious
>>>>
>>>> https://buildd.debian.org/status/package.php?p=golang-github-pelletier-go-toml=sid
>>>>
>>>> ...
>>>>dh_auto_test -a -O--buildsystem=golang
>>>>go test -v -p 4 github.com/pelletier/go-toml 
>>>> github.com/pelletier/go-toml/cmd github.com/pelletier/go-toml/cmd/tomljson 
>>>> github.com/pelletier/go-toml/cmd/tomll github.com/pelletier/go-toml/query
>>>> go build github.com/davecgh/go-spew/spew: /usr/bin/mips-linux-gnu-gccgo-7: 
>>>> waitid: bad address
>>>> FAIL   github.com/pelletier/go-toml [build failed]
>>>> ?  github.com/pelletier/go-toml/cmd[no test files]
>>>> ...
>>>
>>> James Cowgill told me that this is actually a kernel bug:
>>>   https://www.linux-mips.org/archives/linux-mips/2017-03/msg00580.html
>>
>> That's now a 404, strangely.  Did you mean "[PATCH 0/2] Fix indirect
>> syscall handler for syscalls with > 4 args"?

Hmm, I may have made a typo with that link. Here's the real one:
https://www.linux-mips.org/archives/linux-mips/2017-03/msg00575.html

> James - assuming I guessed correctly above, why is it that the second
> patch "MIPS: Remove pt_regs adjustments in indirect syscall handler"
> hasn't been applied?  Was this fixed some other way upstream?

I've just tried with v4.13-rc1 and the bug is still not fixed there. My
guess is that the first patch is more obviously correct than the second
one so was applied first. I have never received any feedback on these
patches so I don't actually know why only one of them was applied.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#868612: mixxx FTBFS with libsqlite3-dev 3.19.3-3

[James Cowgill]

Control: tags -1 patch upstream

Hi,

On 17/07/17 00:55, Adrian Bunk wrote:
> Source: mixxx
> Version: 2.0.0~dfsg-7
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mixxx.html
> 
> ...
> In file included from src/library/trackcollection.cpp:7:0:
> /usr/include/sqlite3.h:3712:16: error: using typedef-name 'sqlite3_value' 
> after 'struct'
>  typedef struct sqlite3_value sqlite3_value;
> ^
> In file included from src/library/trackcollection.cpp:4:0:
> src/library/trackcollection.h:38:20: note: 'sqlite3_value' has a previous 
> declaration here
>  typedef struct Mem sqlite3_value;
> ^
> In file included from src/library/trackcollection.cpp:7:0:
> /usr/include/sqlite3.h:3712:30: error: conflicting declaration 'typedef int 
> sqlite3_value'
>  typedef struct sqlite3_value sqlite3_value;
>   ^
> In file included from src/library/trackcollection.cpp:4:0:
> src/library/trackcollection.h:38:20: note: previous declaration as 'typedef 
> struct Mem sqlite3_value'
>  typedef struct Mem sqlite3_value;
> ^
> scons: *** [lin64_build/library/trackcollection.o] Error 1

The attached patch should fix this.

Upstream appears to have completely rewritten the sqlite3 code so this
patch can't really be applied upstream.

James
--- a/src/library/trackcollection.h
+++ b/src/library/trackcollection.h
@@ -34,8 +34,7 @@
 #include "library/dao/libraryhashdao.h"
 
 #ifdef __SQLITE3__
-typedef struct sqlite3_context sqlite3_context;
-typedef struct Mem sqlite3_value;
+#include 
 #endif
 
 class TrackInfoObject;


signature.asc
Description: OpenPGP digital signature

Bug#868499: osmose-emulator: No sound

[James Cowgill]

Control: tags -1 patch upstream

Hi,

On 16/07/17 07:14, Diogo Martins Silva wrote:
> Package: osmose-emulator
> Version: 1.0-4
> Severity: important
> 
> Dear Maintainer,
> 
> Emulator correctly plays games, except with no sound.
> 
> Relevant Log entry:
> 
> cannot open audio device : plughw:0,0No such file or
> directory
> 
> I don't use plugged in sound card, just a regular laptop hardware sound card.

The attached patch might work by switching the ALSA device to "default".
Could you rebuild osmose-emulator and test it?

In this context "plughw:0,0" refers to passing the sound to the first
soundcard on the first device, after doing any necessary rate
conversion. This is bad because:
- It hardcodes the device (which as you found, may not even exist)
- It is incompatible with PulseAudio

Thanks,
James
diff -ur a/osmose/OsmoseCore.cpp b/osmose/OsmoseCore.cpp
--- a/osmose/OsmoseCore.cpp	2016-08-12 05:56:04.0 +0100
+++ b/osmose/OsmoseCore.cpp	2017-07-16 12:54:16.178464325 +0100
@@ -111,7 +111,7 @@
 {
 		try
 		{
-			sndThread = new SoundThread("plughw:0,0", p->getFIFOSoundBuffer());
+			sndThread = new SoundThread("default", p->getFIFOSoundBuffer());
 			sndThread->start(); 	// Start thread, not playing !		
 			string msg = "Creating SoundThread";
 			QLogWindow::getInstance()->appendLog(msg);


signature.asc
Description: OpenPGP digital signature

Bug#868514: usbguard: unused dependency on nlohmann-json-dev

[James Cowgill]

Source: usbguard
Version: 0.6.2+ds1-2
Severity: minor

Hi,

usbguard seems to have an unused dependency on nlohmann-json-dev.
Removing it still allows the build to pass without losing any features.

James



signature.asc
Description: OpenPGP digital signature

Bug#868468: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u2

[James Cowgill]

On 15/07/17 20:50, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2017-07-15 at 20:37 +0100, James Cowgill wrote:
>> Some more security issues were discovered in libopenmpt so it will need
>> another stretch update. One of the issues looked potentially serious so
>> I had CVE-2017-11311 allocated for it. That CVE has been marked as
>> no-dsa by the security team.
>>
>> Also, sorry this is pretty late for 9.1.
> 
> It is, but if it's uploaded in time then it still might make it.

Thankyou! Uploaded.

James



signature.asc
Description: OpenPGP digital signature

Bug#868468: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u2

[James Cowgill]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

Some more security issues were discovered in libopenmpt so it will need
another stretch update. One of the issues looked potentially serious so
I had CVE-2017-11311 allocated for it. That CVE has been marked as
no-dsa by the security team.

Also, sorry this is pretty late for 9.1.

Debdiff against 0.2.7386~beta20.3-3+deb9u1 (which is already in
stretch-pu) attached.

Thanks,
James

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

Kernel: Linux 4.11.0-1-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 /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libopenmpt-0.2.7386~beta20.3/debian/changelog 
libopenmpt-0.2.7386~beta20.3/debian/changelog
--- libopenmpt-0.2.7386~beta20.3/debian/changelog   2017-06-20 
08:58:50.0 +0100
+++ libopenmpt-0.2.7386~beta20.3/debian/changelog   2017-07-15 
18:33:57.0 +0100
@@ -1,3 +1,11 @@
+libopenmpt (0.2.7386~beta20.3-3+deb9u2) stretch; urgency=medium
+
+  * Add security patches (Closes: #867579).
+- up8: Out-of-bounds read while loading a malfomed PLM file.
+- up10: CVE-2017-11311: Arbitrary code execution by a crafted PSM file.
+
+ -- James Cowgill <jcowg...@debian.org>  Sat, 15 Jul 2017 18:33:57 +0100
+
 libopenmpt (0.2.7386~beta20.3-3+deb9u1) stretch; urgency=medium
 
   * Add various security patches (Closes: #864195).
diff -Nru libopenmpt-0.2.7386~beta20.3/debian/patches/series 
libopenmpt-0.2.7386~beta20.3/debian/patches/series
--- libopenmpt-0.2.7386~beta20.3/debian/patches/series  2017-06-20 
08:58:50.0 +0100
+++ libopenmpt-0.2.7386~beta20.3/debian/patches/series  2017-07-15 
16:49:37.0 +0100
@@ -4,3 +4,5 @@
 up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
 up5-excessive-cpu-consumption-on-malformed-files-ams.patch
 up6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch
+up8-out-of-bounds-read-plm.patch
+up10-heap-buffer-overflow-in-sample-loading-from-malformed-files-psm.patch
diff -Nru 
libopenmpt-0.2.7386~beta20.3/debian/patches/up10-heap-buffer-overflow-in-sample-loading-from-malformed-files-psm.patch
 
libopenmpt-0.2.7386~beta20.3/debian/patches/up10-heap-buffer-overflow-in-sample-loading-from-malformed-files-psm.patch
--- 
libopenmpt-0.2.7386~beta20.3/debian/patches/up10-heap-buffer-overflow-in-sample-loading-from-malformed-files-psm.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libopenmpt-0.2.7386~beta20.3/debian/patches/up10-heap-buffer-overflow-in-sample-loading-from-malformed-files-psm.patch
  2017-07-15 17:59:44.0 +0100
@@ -0,0 +1,30 @@
+Description: Fix CVE-2017-11311
+ See https://lib.openmpt.org/libopenmpt/md_announce-2017-07-07.html
+ Fix heap buffer overflow which may allow arbitrary code execution via a
+ crafted PSM File.
+Origin: upstream, 
https://source.openmpt.org/browse/openmpt?op=revision=8460
+Bug-Debian: https://bugs.debian.org/867579
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/soundlib/Load_psm.cpp
 b/soundlib/Load_psm.cpp
+@@ -1187,15 +1187,16 @@ bool CSoundFile::ReadPSM16(FileReader 
+   }
+ 
+   SAMPLEINDEX smp = sampleHeader.sampleNumber;
+-  if(smp < MAX_SAMPLES)
++  if(smp > 0 && smp < MAX_SAMPLES)
+   {
+   m_nSamples = std::max(m_nSamples, smp);
+ 
+-  
mpt::String::Read(m_szNames[smp], 
sampleHeader.name);
+   sampleHeader.ConvertToMPT(Samples[smp]);
++  
mpt::String::Read(m_szNames[smp], 
sampleHeader.name);
+ 
+-  if((loadFlags & loadSampleData) && 
file.Seek(sampleHeader.offset))
++  if(loadFlags & loadSampleData)
+   {
++  file.Seek(sampleHeader.offset);
+   
sampleHeader.GetSampleFormat().ReadSample(Samples[smp], file);
+   }
+   }
diff -Nru 
libopenmpt-0.2.7386~beta20.3/debian/patches/up8-out-of-bounds-read-plm.patch 
libopenmpt-0.2.7386~beta20.3/debian/patches/up8-out-of-bounds-read-plm.patch
--- 
libopenmpt-0.2.7386~beta20.3/debian/patches/up8-out-of-bounds-read-plm.patch
1970-01-01 01:00:00.0 +0100
+++ 
libopenmpt-0.2.7386~beta20.3/debian/patches/up8-out-of-bounds-read-plm.patch
2017-07-15 18:04:11.0 +0100
@@ -0,0 +1,25 @@
+Descriptio

Bug#868448: gearhead: needs updating for fpc 3.0.2

[James Cowgill]

Source: gearhead
Version: 1.302-3
Severity: serious
Tags: sid buster patch

Hi,

gearhead needs updating for fpc 3.0.2 which was recently uploaded to
unstable. Specifically the build-dependency on fpc-source-3.0.0 is going
to disappear soon.

I've attached the patch Graham Inggs uploaded to Ubuntu to fix this. You
may be able to base you changes on that.

Thanks,
James

diff -Nru gearhead-1.302/debian/changelog gearhead-1.302/debian/changelog
--- gearhead-1.302/debian/changelog	2016-11-21 16:50:02.0 +
+++ gearhead-1.302/debian/changelog	2017-04-10 10:17:42.0 +
@@ -1,3 +1,9 @@
+gearhead (1.302-3ubuntu1) zesty; urgency=medium
+
+  * Update for fpc 3.0.2
+
+ -- Graham Inggs   Mon, 10 Apr 2017 12:17:42 +0200
+
 gearhead (1.302-3) unstable; urgency=medium
 
   * Apply xterm-boxdrawing patch for better graphics and cursor behavior
diff -Nru gearhead-1.302/debian/control gearhead-1.302/debian/control
--- gearhead-1.302/debian/control	2016-11-21 16:26:05.0 +
+++ gearhead-1.302/debian/control	2017-04-10 10:17:42.0 +
@@ -1,8 +1,9 @@
 Source: gearhead
 Section: games
 Priority: optional
-Maintainer: Kari Pahula 
-Build-Depends: debhelper (>= 9), fp-compiler, fp-units-multimedia, fp-units-misc, fp-units-base, libsdl-ttf2.0-dev, libsdl-image1.2-dev, fpc-source-3.0.0
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Kari Pahula 
+Build-Depends: debhelper (>= 9), fp-compiler, fp-units-multimedia, fp-units-misc, fp-units-base, libsdl-ttf2.0-dev, libsdl-image1.2-dev, fpc-source-3.0.2
 Standards-Version: 3.9.8
 Homepage: http://www.gearheadrpg.com/
 
diff -Nru gearhead-1.302/debian/rules gearhead-1.302/debian/rules
--- gearhead-1.302/debian/rules	2016-11-21 16:38:53.0 +
+++ gearhead-1.302/debian/rules	2017-04-10 10:17:42.0 +
@@ -32,7 +32,7 @@
 export FPCFLAGS
 
 # TODO: find this dynamically
-FPCSRCVERSION=3.0.0
+FPCSRCVERSION=3.0.2
 
 #Architecture 
 build: build-arch build-indep


signature.asc
Description: OpenPGP digital signature

Bug#868376: attal: homepage no longer exists

[James Cowgill]

Source: attal
Version: 1.0~rc2-2
Severity: normal

Hi,

The Homepage for attal no longer exists. It now points to a domain
parking page:
http://www.attal-thegame.org/

The sourceforge project page does still exist:
https://sourceforge.net/projects/attal/

However, it's pretty clear that this game has been abandoned upstream.

James



signature.asc
Description: OpenPGP digital signature

Bug#867579: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p10 available

[James Cowgill]

Control: severity -1 grave
Control: tags -1 fixed-upstream

Hi,

On 07/07/17 15:41, Jörn Heusipp wrote:
> Source: libopenmpt
> Version: 0.2.7386~beta20.3-3
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> A couple of security-related fixes have been released upstream as
> version 0.2.7386-beta20.3-p10. See
> https://lib.openmpt.org/libopenmpt/md_announce-2017-07-07.html .
> 
> p10 fixes a heap buffer overflow which allows an attacker to write
> arbitrary data to an arbitrarily choosen offset. It can be triggered
> with a maliciously modified PSM file. This needs to be fixed ASAP via
> a security update in Stretch. The bug happens due to 2 samples in a
> PSM file using the same sample slot in libopenmpt, whereby the second
> sample uses an invalid offset inside the file. That way, the second
> sample did not re-allocate (via
> sampleHeader.GetSampleFormat().ReadSample(Samples[smp], file); deeper
> down the call chain in SampleIO.cpp:73) the sample buffer itself but
> only set the sample size metadata
> (sampleHeader.ConvertToMPT(Samples[smp]);, ultimately at
> Load_psm.cpp:1054). Later, as a loading post-processing step,
> Sndfile.cpp:411 calls PrecomputeLoops() which writes a couple of
> samples before and after the actual sample data (the amount is
> statically known (InterpolationMaxLookahead) and accounted for when
> allocating the sample buffer). However, due to the sample buffer and
> sample length mismatch caused by the bug, this can write extrapolated
> sample data to an arbitary location offset from the first sample's
> buffer (PrecomputeLoopsImpl() in modsmp_ctrl.cpp:263).

Firstly, sorry it's taken some time for me to get around to this. Since
this bug had the potential for remote code execution and looked pretty
serious, I requested a CVE number for it and it has been assigned
CVE-2017-11311.

> p8 is an out-of-bounds read directly after a heap-allocated allocated
> buffer. It is difficult to trigger in practice because std::vector
> does grow its buffer exponentially.

OK this should be fixed as well.

> p9 fixes another potential race condition due to the use of non
> thread-safe  functions. As discussed previously in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864195#67 , this
> again can at worst cause wrong data to be returned for date metadata
> in libopenmpt. However, please note that the same, now rewritten code
> path, could also trigger an assertion failure in glibc under memory
> pressure (which probably is a glibc bug, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283 ), thereby
> causing the application to crash.

Again, I'm not sure if it is worth fixing this in stretch - it modifies
quite a bit of code. The glibc bug is important, but I'm not sure it
should be worked around in libopenmpt. It's also mitigated by the fact
that on Linux, if you're suffering from memory pressure, something is
probably about to be killed by the OOM killer anyway.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#868168: python2.7: importing test.test_support - ImportError: No module named support

[James Cowgill]

Package: libpython2.7-stdlib
Version: 2.7.13-3
Severity: important
Control: affects -1 src:gnucash
X-Debbugs-CC: gnuc...@packages.debian.org

Hi,

Attempting to import "test_support" from the "test" module is broken in
2.7.13-3. It worked correctly in 2.7.13-2. This bug causes gnucash to
FTBFS on mips (where the newer version of python2.7 successfully built).

> $ python2
> Python 2.7.13+ (default, Jun  8 2017, 16:45:33)
> [GCC 6.3.0 20170516] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 from test import test_support
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/test/test_support.py", line 2, in 
> import test.support
> ImportError: No module named support

Looking at the upstream patches applied in 2.7.13-3, there should be a
new support subdirectory in /usr/lib/python2.7/test/, but it appears to
be missing from the Debian package.

> $ ls -al /usr/lib/python2.7/test/
> total 224
> drwxr-xr-x 2 root root   200 Jul 12 16:31 .
> drwxr-xr-x 1 root root  8880 Jul 12 16:31 ..
> -rw-r--r-- 1 root root47 Jun  8 16:45 __init__.py
> -rw-r--r-- 1 root root   122 Jul 12 16:31 __init__.pyc
> -rwxr-xr-x 1 root root  7366 Jun  8 16:45 pystone.py
> -rw-r--r-- 1 root root  7989 Jul 12 16:31 pystone.pyc
> -rwxr-xr-x 1 root root 62310 Jun  8 16:45 regrtest.py
> -rw-r--r-- 1 root root 51804 Jul 12 16:31 regrtest.pyc
> -rw-r--r-- 1 root root79 Jun  8 16:45 test_support.py
> -rw-r--r-- 1 root root   255 Jul 12 16:31 test_support.pyc

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#868053: sunpy: FTBFS with python-astropy >= 2

[James Cowgill]

Source: sunpy
Version: 0.7.8-1
Severity: serious
Tags: sid buster

sunpy FTBFS with testsuite when built using python-astropy from unstable:

> python -m pytest sunpy -k "not figure and not online"
> = test session starts 
> ==
> platform linux2 -- Python 2.7.13, pytest-3.0.6, py-1.4.34, pluggy-0.4.0
> rootdir: /<>, inifile: setup.cfg
> collected 618 items / 36 errors
> 
>  ERRORS 
> 
> ___ ERROR collecting sunpy/coordinates/tests/test_frameattributes.py 
> ___
> ImportError while importing test module 
> '/<>/sunpy/coordinates/tests/test_frameattributes.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> sunpy/coordinates/__init__.py:3: in 
> from .frames import *
> sunpy/coordinates/frames.py:17: in 
> from astropy.coordinates import FrameAttribute
> E   ImportError: cannot import name FrameAttribute

James



signature.asc
Description: OpenPGP digital signature

Bug#867058: golang-1.8: Please enable mips64el in debian/ directory

[James Cowgill]

Hi Adrian,

On 03/07/17 19:46, John Paul Adrian Glaubitz wrote:
> Source: golang-1.8
> Version: 1.8.3-1
> Severity: normal
> Tags: patch
> User: debian-m...@lists.debian.org
> Usertags: mips64el
> 
> Hi!
> 
> I just bootstrapped golang-1.8 on mips64el.  In order to be able to build the
> package successfully on mips64el, the architecture needs to be added to the
> Architecture field in debian/control.in, then debian/control needs to be
> regenerated using "debian/rules gencontrol". For some reason, the architecture
> mapping for mips64el->mips64le is already present in debian/helpers/goenv.sh
> and doesn't need to be added.

I was under the impression that the golang maintainers want all
architectures bootstrapped from gccgo? This was the reason
mips64el support was not in stretch despite upstream support for it.
If a normal bootstrap would have been acceptable, I would have done it
ages ago.

Again I have to point out that you are *not* allowed to upload binary
debs to the archive before the corresponding source is uploaded. You
need to re-read this:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#porter-guidelines

Please can you actually discuss this with the package maintainers and
mips porters _before_ you do anything like this again. You should also
read the mips related go bugs filed against various golang packages.

Thankfully you didn't upload golang-defaults so a mass-build of go
packages wasn't triggered...

[On a related note, the gccgo patches for mips64el have now been merged
into GCC master]

James



signature.asc
Description: OpenPGP digital signature

Bug#866357: reconserver FTBFs on several architectures: error: 'installSignalHandler' was not declared in this scope

[James Cowgill]

Hi,

On 29/06/17 07:21, Adrian Bunk wrote:
> Source: reconserver
> Version: 0.15.2-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=reconserver=sid
> 
> ...
> reConServer.cxx: In member function 'virtual int 
> reconserver::ReConServerProcess::main(int, char**)':
> reConServer.cxx:763:25: error: 'installSignalHandler' was not declared in 
> this scope
> installSignalHandler();
>  ^

The common factor here seems to be the version of librecon-1.11-dev in
use. The successful builds all have 1:1.11.0~beta4-1, but the failing
builds have 1:1.11.0~beta1-3.

It looks like you forgot the epoch in the build-dependency:
librecon-1.11-dev (>> 1.11.0~beta4) | librecon-dev

Also, the use of "| librecon-dev" is wrong here because it allows
ignoring the dependency in non-buildd builds.

James



signature.asc
Description: OpenPGP digital signature

Bug#866378: 3dchess: 100 % CPU consumption

[James Cowgill]

Hi,

On 29/06/17 11:49, Markus Koschany wrote:
> Package: 3dchess
> Version: 0.8.1-19
> Severity: serious
> 
> While I was working on an update for 3dchess, I discovered that the
> game is very wasteful with CPU resources and consumes 100 % of a
> single CPU core. I haven't noticed this behavior before but it also
> appears that it was not caused by the recent hardening change which
> added the pie flag by default.

I can reproduce this bug with 0.8.1-17 from wheezy.

Looking at the code here:
https://sources.debian.net/src/3dchess/0.8.1-19/src/main.c/#L127

It looks to me like the game loop has no sleeps or other waiting in it.
It has probably always consumed 100% CPU.

> I think this bug makes the game unsuitable for another release.

Note that you filed the bug against a version in stretch. If you want it
to only apply to the next release you have to tag it "sid buster".

Having said that, I don't see how this bug is RC. The game is still
playable, even if the 100% CPU usage is annoying.

Jame



signature.asc
Description: OpenPGP digital signature

Bug#866107: jack-capture: FTBFS on mips, mipsel: undefined reference to `__atomic_load_8'

[James Cowgill]

Source: jack-capture
Version: 0.9.73-1
Severity: serious
Tags: sid buster

Hi,

jack-capture FTBFS on mips, mipsel and various ports architectures with
the error:
> /tmp/ccZYp8m1.o: In function `print_console':
> ./jack_capture.c:721: undefined reference to `__atomic_load_8'
> ./jack_capture.c:721: undefined reference to `__atomic_load_8'
> /tmp/ccZYp8m1.o: In function `process':
> ./jack_capture.c:1723: undefined reference to `__atomic_load_8'
> ./jack_capture.c:1728: undefined reference to `__atomic_fetch_add_8'
> ./jack_capture.c:1730: undefined reference to `__atomic_load_8'
> ./jack_capture.c:1742: undefined reference to `__atomic_fetch_add_8'
> ./jack_capture.c:1723: undefined reference to `__atomic_load_8'
> ./jack_capture.c:1723: undefined reference to `__atomic_load_8'
> ./jack_capture.c:1728: undefined reference to `__atomic_fetch_add_8'
> ./jack_capture.c:1730: undefined reference to `__atomic_load_8'
> ./jack_capture.c:1742: undefined reference to `__atomic_fetch_add_8'
> ./jack_capture.c:1723: undefined reference to `__atomic_load_8'
> collect2: error: ld returned 1 exit status

This is because jack-capture uses 64-bit atomics which requires the use
of the libatomic helper library on some architectures.

The simple fix is to add "-latomic" to DEB_LDFLAGS_MAINT_APPEND like this:
> export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -latomic

Alternatively you could add the library to the LINKFLAGS variable in the
upstream Makefile.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865355: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u1

[James Cowgill]

Hi again,

On 25/06/17 23:11, James Cowgill wrote:
> On 25/06/17 22:46, Cyril Brulebois wrote:
>> James Cowgill <jcowg...@debian.org> (2017-06-20):
>>> This update contains a number of security fixes to libopenmpt which
>>> upstream has specifically asked me to get into stretch. Upstream asked
>>> me to fix these earlier this month and since none of them looked
>>> "critical" I decided to wait and file a stretch-pu bug (although maybe
>>> I was a little lazy...) The worst bugs fixed here are NULL pointer
>>> dereferences - I don't think there is any remote code execution here.
>>
>> I suspect it would be best to check with the security team anyway?
> 
> OK I've asked them in the original bug report.

Salvatore Bonaccorso replied and said this was OK to do in a point release.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864195#72

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865355: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u1

[James Cowgill]

Hi,

On 25/06/17 22:46, Cyril Brulebois wrote:
> James Cowgill <jcowg...@debian.org> (2017-06-20):
>> This update contains a number of security fixes to libopenmpt which
>> upstream has specifically asked me to get into stretch. Upstream asked
>> me to fix these earlier this month and since none of them looked
>> "critical" I decided to wait and file a stretch-pu bug (although maybe
>> I was a little lazy...) The worst bugs fixed here are NULL pointer
>> dereferences - I don't think there is any remote code execution here.
> 
> I suspect it would be best to check with the security team anyway?

OK I've asked them in the original bug report.

>> Upstream kindly backported all the fixes to the version Debian has in
>> stretch and they were taken from this announcement:
>> https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
>>
>> I omitted 2 patches which seem to be impossible to exploit or which
>> only have minor cosmetic effects.
>>
>> Debdiff attached.
>>
> 
> Patch: 
> debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
>> --- 
>> libopenmpt-0.2.7386~beta20.3/debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
>>1970-01-01 01:00:00.0 +0100
>> +++ 
>> libopenmpt-0.2.7386~beta20.3/debian/patches/up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
>>2017-06-20 08:58:50.0 +0100
>> @@ -0,0 +1,351 @@
>> +Description: Fix excessive CPU consumption on malformed DMF and MDL files
>> + See https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
>> + This patch prevents loading of DMF and MDL modules taking multiple minutes 
>> if
>> + the module contains truncated compressed samples.
>> +Origin: upstream, 
>> https://source.openmpt.org/browse/openmpt?op=revision=8237
>> +Bug-Debian: https://bugs.debian.org/864195
>> +---
>> +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
>> +--- a/soundlib/Load_dmf.cpp
>>  b/soundlib/Load_dmf.cpp
>> +@@ -16,6 +16,7 @@
>> + #include "stdafx.h"
>> + #include "Loaders.h"
>> + #include "ChunkReader.h"
>> ++#include 
>> + 
>> + OPENMPT_NAMESPACE_BEGIN
>> + 
>> +@@ -1087,68 +1088,66 @@ struct DMFHTree
>> +int bitnum;
>> +int lastnode, nodecount;
>> +DMFHNode nodes[256];
>> +-};
>> +-
> 
> ^^^ This update seems to be putting DMFReadBits() and DMFNewNode()
> functions “inside” the DMFHTree struct? I'm not a C overlord, but that's
> a construction I haven't seen yet. :)

It's perfectly legal in C++ though :)

> Anyway all I could spot was this structure update, and a function
> signature update, both of which not being exported as far as I can tell.
> 
> So that looks good to me, except for the security team question in my
> first paragraph.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[James Cowgill]

Hi security team,

On 07/06/17 10:45, James Cowgill wrote:
> On 05/06/17 07:03, Jörn Heusipp wrote:
>> Source: libopenmpt Version: 0.2.7386~beta20.3-3 Severity: 
>> important Tags: upstream
>> 
>> Dear Maintainer,
>> 
>> A couple of security-related fixes have been released upstream
>> as version 0.2.7386-beta20.3-p7. See 
>> https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
>> 
>> These most importantly fix a couple of possible crashes which
>> can be triggered by maliciously modified or malformed or
>> truncated module files as well as denial-of-service through hangs
>> or excessive CPU consumption which can also be triggered
>> maliciously modfied or malformed or truncated module files.
> 
> I've had a look at the patches now and this is what I think:
> 
> p1-division-by-zero-in-tempo-calculation.patch 
> p2-infinite-loop-in-plugin-routing.patch 
> p6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch
> 
> These three are clearly denial-of-service by malicious module file 
> and should be fixed in stretch. However, I don't think the first 
> two are "serious" because they're just denial-of-service bugs in a 
> library almost exclusively used on end user machines (as opposed
> to eg remote code execution). I don't understand patch p6 well
> enough to say how serious it is (depends on where the invalid
> pointer being dereferenced comes from).
> 
> p3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch 
> p5-excessive-cpu-consumption-on-malformed-files-ams.patch
> 
> Are these actually security bugs? As long as the code finishes in a
> reasonable amount of time and produces the right results, then 
> there's not much harm in leaving the code as it is.
> 
> p4-theoretical-null-pointer-dereference-during-out-of-memory-while-error-handling.patch
>
>
> 
I don't think this is a security bug. It requires malloc to fail,
> and the chances of that happening on Linux are very small. If that 
> does occur, you're likely to be killed by the OOM killer anyway.
> 
> I also note that the C++ standard _requires_ std::exception::what 
> to return a non-null value so a very intelligent compiler could 
> legitimately remove the null check (I doubt GCC does this though).
> 
> p7-race-condition-in-multi-threaded-use-it.patch
> 
> I also don't think this is a security bug (at least on Linux). 
> Looking at the glibc sources, the internal tzdata state is 
> protected by a mutex so the only risk here is that localtime will 
> return some garbage time values. Since the string generated by
> this function is only going to be shown to the user, nothing that
> bad will happen in this case. Finally, it relies on a
> multithreaded client application loading 2 modules at the same time
> which seems unlikely to me.

I decided later in this thread that all the patches except p4 and p7
should be fixed in stretch. I opened a stretch-pu bug here: #865355. I
it OK for these to be fixed as a stretch update or should they be
handled by you?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864195: closed by James Cowgill <jcowg...@debian.org> (Bug#864195: fixed in libopenmpt 0.2.8190~beta24-1)

[James Cowgill]

Hi,

On 25/06/17 06:29, Jörn Heusipp wrote:
> On 06/19/2017 08:45 PM, Debian Bug Tracking System wrote:
>> #864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7
>> available
>> It has been closed by James Cowgill <jcowg...@debian.org>.
> 
> As far as I can see, there is still no updated libopenmpt package in
> Stretch for any of the issues.

It's closed because the relevant security fixes have been fixed in
unstable. This bug is tracking the stretch-pu request specifically: #865355.

James



signature.asc
Description: OpenPGP digital signature

Bug#807648: zyne: Requested version of wxPython not found

[James Cowgill]

Control: severity -1 grave

On 24/06/17 13:35, B.Schweinitz wrote:
> Package: zyne
> Version: 0.1.2-2
> Followup-For: Bug #807648
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I tried to start zyne after installing it with apt-get install
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>  File "/usr/bin/zyne", line 4, in 
> wxversion.select("2.8")
>   File "/usr/lib/python2.7/dist-packages/wxversion.py", line 152, in select
> raise VersionError("Requested version of wxPython not found")
> wxversion.VersionError: Requested version of wxPython not found

I can confirm this in both stretch and unstable, so bug should clearly
by RC.

James



signature.asc
Description: OpenPGP digital signature

Bug#841645: golang-go: There is no mips64el support

[James Cowgill]

Hi,

On 13/06/17 18:39, Tianon Gravi wrote:
> On 7 June 2017 at 02:23, Mathieu Malaterre  wrote:
>> Are you saying that the patch is more complex than just
>> s/mipsn64/mips64el/ ? Or are you saying you do not want to maintain
>> such patch until upstream add an alias for mips64el ?
> 
> Yes, the patch is more complex than simply adjusting the GOARCH values
> from what I've seen -- the crux of the issue is that we need Go
> available in order to build Go, and gccgo has been our simplest source
> for doing so (especially since it makes backports easy to bootstrap
> too), but this discrepancy between GOARCH in gccgo vs cgo causes build
> issues when doing so.
> 
> In theory we should be able to do a cross-compiling bootstrap of
> mips64el, but that increases the complexity level significantly as
> well (if not in the packaging source, then in the upload procedure to
> get all the right bits in place in the archive).

FYI my patches to fix all this in gccgo were merged today (with the
exception of one minor issue in the testsuite I need to fixup). They'll
need backporting to gcc-7 to be usable for Debian though (or wait ages
for gcc-8).

While I've had success building golang with these patches on mips64el,
there does seem to be a few things to iron out with mips and mipsel at
the moment. Those arches run out of memory frequently while building
golang. I am also aware of a kernel bug which causes the build to
spuriously fail on 32-bits.

James



signature.asc
Description: OpenPGP digital signature

Bug#865317: miller FTBFS on mips: FAIL run (exit status: 1)

[James Cowgill]

Hi,

On 20/06/17 14:29, Adrian Bunk wrote:
> Source: miller
> Version: 5.2.0-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=miller=sid
> 
> ...
> Tests completed: 2713
> FAIL run (exit status: 1)
[...]
> The same build failure on powerpc is an indication that it
> could be a 32bit big endian problem.

This error comes from the substr test in miller's testsuite:
> announce DSL SUBSTR
> 
> run_mlr put -q '
>   int n = strlen($x);
>   print "input= <<".$x.">>";
>   for (i = -n-2; i <= n+2; i += 1) {
> for (j = -n-2; j <= n+2; j += 1) {
>   print "i: ".fmtnum(i,"%3d")
> ."   j:".fmtnum(j,"%3d")
> ."   substr(".$x.",".fmtnum(i,"%3d").",".fmtnum(j,"%3d")."): <<"
> .substr($x, i, j) .">>";
> }
> print;
> }
> ' << EOF
> x=
> x=o
> x=o1
> x=o123456789
> EOF

When "fmtnum(i, "%3d")" is called, control eventually gets to this
function in c/lib/mlrutil.c:
> char* mlr_alloc_string_from_ll_and_format(long long value, char* fmt) {
>   int n = snprintf(NULL, 0, fmt, value);
>   char* string = mlr_malloc_or_die(n+1);
>   sprintf(string, fmt, value);
>   return string;
> }

The arguments are:
value = integer in i
fmt = "%3d"

The function will call snprintf "%3d" on a long long value which invokes
undefined behavior (from size integer for given format). The incorrect
result is then returned.

Only mips and powerpc are affected because: their ABI distinguishes
between passing "int" and "long long" (because they are 32-bit), and
they are big endian so the "wrong" part of the integer gets read by
sprintf. The result is always "-1" or "0" because it will read the
sign-extended part.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865423: gst-rtsp-server1.0: testsuite emits large amounts of multicast traffic

[James Cowgill]

Hi,

On 21/06/17 12:03, Sebastian Dröge wrote:
> On Wed, 2017-06-21 at 11:47 +0100, James Cowgill wrote:
>>
>> Hi,
>>
>> While running the testsuite, the "gst/rtspserver" test emits about 200k
>> UDP packets into the local network. They are all sent to a multicast
>> address which will be forwarded to the router for the current subnet and
>> then probably dropped (since no-one else should be in the chosen
>> multicast group). This violates Policy 4.9 which states "For packages in
>> the main archive, no required targets may attempt network access."
>>
>> On a related note, this does seem to be the cause of losing all the mips
>> buildds at AQL recently. The multicast traffic seems to trip the
>> protection mechanisms at AQL and so the router disables the Debian rack
>> to "protect" the rest of the network. There was a firewall rule to
>> prevent this, but there was a typo in it so it didn't work this time.
>>
>> It is likely this package will be blacklisted on mips* until this bug is
>> fixed.
> 
> Can you think of any alternative other than disabling the testsuite?
> I'm ok with disabling it if there's nothing else we can do, and feel
> free to also just upload a NMU for that :)

I think there are some smaller modifications which only disable the
multicast bits. You could disable just rtspserver test or apply the
attached patch to disable the multicast bits. With this patch wireshark
show no stray packets at all, but obviously it isn't going to test any
of the multicast related code.

On a related note, I tried running the testsuite inside an empty network
namespace and about half the tests failed. I guess no-one tests that
case because you wouldn't ever run an RTSP server without any network.

Also, I see the testsuite results are ignored. Is that intentional (and
just to get the test logs from the buildds)?

James
diff -ur a/tests/check/gst/rtspserver.c b/tests/check/gst/rtspserver.c
--- a/tests/check/gst/rtspserver.c	2017-05-15 16:46:41.0 +0100
+++ b/tests/check/gst/rtspserver.c	2017-06-21 13:46:56.947393396 +0100
@@ -167,8 +167,6 @@
 
   /* use an address pool for multicast */
   pool = gst_rtsp_address_pool_new ();
-  gst_rtsp_address_pool_add_range (pool,
-  "224.3.0.0", "224.3.0.10", 5500, 5510, 16);
   gst_rtsp_address_pool_add_range (pool, GST_RTSP_ADDRESS_POOL_ANY_IPV4,
   GST_RTSP_ADDRESS_POOL_ANY_IPV4, 6000, 6010, 0);
   gst_rtsp_media_factory_set_address_pool (factory, pool);
@@ -816,7 +814,6 @@
 
 GST_START_TEST (test_setup_udp_mcast)
 {
-  do_test_setup (GST_RTSP_LOWER_TRANS_UDP_MCAST);
 }
 
 GST_END_TEST;


signature.asc
Description: OpenPGP digital signature

Bug#865423: gst-rtsp-server1.0: testsuite emits large amounts of multicast traffic

[James Cowgill]

Source: gst-rtsp-server1.0
Version: 1.12.1-1
Severity: serious
Justification: Policy 4.9
Control: found -1 1.10.4-1

[I know this particular bit of policy is bit contentious. You can
downgrade this bug if you want]

Hi,

While running the testsuite, the "gst/rtspserver" test emits about 200k
UDP packets into the local network. They are all sent to a multicast
address which will be forwarded to the router for the current subnet and
then probably dropped (since no-one else should be in the chosen
multicast group). This violates Policy 4.9 which states "For packages in
the main archive, no required targets may attempt network access."

On a related note, this does seem to be the cause of losing all the mips
buildds at AQL recently. The multicast traffic seems to trip the
protection mechanisms at AQL and so the router disables the Debian rack
to "protect" the rest of the network. There was a firewall rule to
prevent this, but there was a typo in it so it didn't work this time.

It is likely this package will be blacklisted on mips* until this bug is
fixed.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865355: stretch-pu: package libopenmpt/0.2.7386~beta20.3-3+deb9u1

[James Cowgill]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

This update contains a number of security fixes to libopenmpt which
upstream has specifically asked me to get into stretch. Upstream asked
me to fix these earlier this month and since none of them looked
"critical" I decided to wait and file a stretch-pu bug (although maybe I
was a little lazy...) The worst bugs fixed here are NULL pointer
dereferences - I don't think there is any remote code execution here.

Upstream kindly backported all the fixes to the version Debian has in
stretch and they were taken from this announcement:
https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html

I omitted 2 patches which seem to be impossible to exploit or which only
have minor cosmetic effects.

Debdiff attached.

Thanks,
James

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libopenmpt-0.2.7386~beta20.3/debian/changelog 
libopenmpt-0.2.7386~beta20.3/debian/changelog
--- libopenmpt-0.2.7386~beta20.3/debian/changelog   2017-01-12 
17:17:13.0 +
+++ libopenmpt-0.2.7386~beta20.3/debian/changelog   2017-06-20 
08:58:50.0 +0100
@@ -1,3 +1,14 @@
+libopenmpt (0.2.7386~beta20.3-3+deb9u1) stretch; urgency=medium
+
+  * Add various security patches (Closes: #864195).
+- up1: Division by zero in temp calculation.
+- up2: Infinite loop with cyclic plugin routing.
+- up3: Excessive CPU consumption on malformed DMF and MDL files.
+- up5: Excessive CPU consumption on malformed AMS files.
+- up6: Invalid memory read when applying NNAs to effect plugins.
+
+ -- James Cowgill <jcowg...@debian.org>  Tue, 20 Jun 2017 08:58:50 +0100
+
 libopenmpt (0.2.7386~beta20.3-3) unstable; urgency=medium
 
   * debian/tests:
diff -Nru libopenmpt-0.2.7386~beta20.3/debian/patches/series 
libopenmpt-0.2.7386~beta20.3/debian/patches/series
--- libopenmpt-0.2.7386~beta20.3/debian/patches/series  2017-01-12 
17:09:08.0 +
+++ libopenmpt-0.2.7386~beta20.3/debian/patches/series  2017-06-20 
08:58:50.0 +0100
@@ -1 +1,6 @@
 01_libmodplug_symver.patch
+up1-division-by-zero-in-tempo-calculation.patch
+up2-infinite-loop-in-plugin-routing.patch
+up3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
+up5-excessive-cpu-consumption-on-malformed-files-ams.patch
+up6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch
diff -Nru 
libopenmpt-0.2.7386~beta20.3/debian/patches/up1-division-by-zero-in-tempo-calculation.patch
 
libopenmpt-0.2.7386~beta20.3/debian/patches/up1-division-by-zero-in-tempo-calculation.patch
--- 
libopenmpt-0.2.7386~beta20.3/debian/patches/up1-division-by-zero-in-tempo-calculation.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libopenmpt-0.2.7386~beta20.3/debian/patches/up1-division-by-zero-in-tempo-calculation.patch
 2017-06-20 08:58:50.0 +0100
@@ -0,0 +1,51 @@
+Description: Guard against division by zero in tempo calculation
+ See https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
+Origin: upstream, 
https://source.openmpt.org/browse/openmpt?op=revision=8235
+Bug-Debian: https://bugs.debian.org/864195
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/soundlib/Sndfile.cpp
 b/soundlib/Sndfile.cpp
+@@ -1542,15 +1542,15 @@ void CSoundFile::RecalculateSamplesPerTi
+   {
+   case tempoModeClassic:
+   default:
+-  m_PlayState.m_nSamplesPerTick = 
Util::muldiv(m_MixerSettings.gdwMixingFreq, 5 * TEMPO::fractFact, 
m_PlayState.m_nMusicTempo.GetRaw() << 1);
++  m_PlayState.m_nSamplesPerTick = 
Util::muldiv(m_MixerSettings.gdwMixingFreq, 5 * TEMPO::fractFact, 
std::max(TEMPO::store_t(1), m_PlayState.m_nMusicTempo.GetRaw() << 1));
+   break;
+ 
+   case tempoModeModern:
+-  m_PlayState.m_nSamplesPerTick = 
static_cast((Util::mul32to64_unsigned(m_MixerSettings.gdwMixingFreq, 60 
* TEMPO::fractFact) * Util::mul32to64_unsigned(m_PlayState.m_nMusicSpeed, 
m_PlayState.m_nCurrentRowsPerBeat)) / m_PlayState.m_nMusicTempo.GetRaw());
++  m_PlayState.m_nSamplesPerTick = 
static_cast((Util::mul32to64_unsigned(m_MixerSettings.gdwMixingFreq, 60 
* TEMPO::fractFact) / std::max(uint64(1),  
Util::mul32to64_unsigned(m_PlayState.m_nMusicSpeed, 
m_PlayState.m_nCurrentRowsPerBeat) * m_PlayState.m_nMusicTempo.GetRaw(;
+   break;
+ 
+   case tempoModeAlternative:
+-  m_PlayState.m_nSamplesPerTick = 
Util::muldiv(m_MixerSettings.gdwMixingFreq, TEMPO::fractFact, 
m_Pl

Bug#865314: Re: Bug#865314: debian-installer-9-netboot-mips: 32bit MIPS (big-endian) Malta netboot installer doesn't boot

[James Cowgill]

Hi,

On 20/06/17 15:40, Bruno Bierbaumer wrote:
> It's maybe related that the mips64el kernel doesn't  boot at all.

This is unrelated. On mips64el, QEMU defaults to the 20Kc CPU which
Debian does not support. If you pass "-cpu MIPS64R2-generic" to QEMU
then it should work.

James

> On Tue, 20 Jun 2017 15:11:27 +0100 Steve McIntyre  wrote:
>> On Tue, Jun 20, 2017 at 04:01:26PM +0200, Bruno Bierbaumer wrote:
>>> Yes, it works perfectly well for Debian Jessie.
>>
>> Ok, thanks for confirming.
>>
>> mips folks - any clues please? AFAICS we've had ~zero input about mips
>> in d-i and image work, and no visible testing. Some help would be
>> appreciated...
>>
>>> On Tue, 20 Jun 2017 14:47:52 +0100 Steve McIntyre  wrote:
 On Tue, Jun 20, 2017 at 03:43:36PM +0200, Bruno Bierbaumer wrote:
> It also seems to be broken on MIPSEL
>
> wget
> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-mipsel/current/images/malta/netboot/initrd.gz
> wget
> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-mipsel/current/images/malta/netboot/vmlinux-4.9.0-3-4kc-malta
> qemu-system-mipsel -M malta -m 256 -kernel vmlinux-4.9.0-3-4kc-malta
> -initrd initrd.gz -nographic

 Hi Bruno,

 Did the same setup work with jessie images? I've got ~no background
 with mips stuff here...

 -- 
 Steve McIntyre, Cambridge, UK.
 st...@einval.com
 "We're the technical experts.  We were hired so that management could
  ignore our recommendations and tell us how to do our jobs."  -- Mike 
 Andrews



>>>
>>>
>> -- 
>> Steve McIntyre, Cambridge, UK.
>> st...@einval.com
>> Google-bait:   http://www.debian.org/CD/free-linux-cd
>>   Debian does NOT ship free CDs. Please do NOT contact the mailing
>>   lists asking us to send them to you.



signature.asc
Description: OpenPGP digital signature

Bug#865314: debian-installer-9-netboot-mips: 32bit MIPS (big-endian) Malta netboot installer doesn't boot

[James Cowgill]

Hi,

On 20/06/17 15:11, Steve McIntyre wrote:
> On Tue, Jun 20, 2017 at 04:01:26PM +0200, Bruno Bierbaumer wrote:
>> Yes, it works perfectly well for Debian Jessie.
> 
> Ok, thanks for confirming.
> 
> mips folks - any clues please? AFAICS we've had ~zero input about mips
> in d-i and image work, and no visible testing. Some help would be
> appreciated...
> 
>> On Tue, 20 Jun 2017 14:47:52 +0100 Steve McIntyre  wrote:
>>> On Tue, Jun 20, 2017 at 03:43:36PM +0200, Bruno Bierbaumer wrote:
 It also seems to be broken on MIPSEL

 wget
 http://ftp.nl.debian.org/debian/dists/stretch/main/installer-mipsel/current/images/malta/netboot/initrd.gz
 wget
 http://ftp.nl.debian.org/debian/dists/stretch/main/installer-mipsel/current/images/malta/netboot/vmlinux-4.9.0-3-4kc-malta
 qemu-system-mipsel -M malta -m 256 -kernel vmlinux-4.9.0-3-4kc-malta
 -initrd initrd.gz -nographic
>>>
>>> Hi Bruno,
>>>
>>> Did the same setup work with jessie images? I've got ~no background
>>> with mips stuff here...

I think I know which error you mean (and I confess I have seen it
before). The issue is that QEMU loads the initrd into the memory
immediately after the kernel, but that bit of memory might get
overwritten by KASLR when the kernel starts and relocates itself.

You can workaround it by passing "-append nokaslr" to QEMU, but I guess
that QEMU should be fixed to place the initrd in a higher bit of memory.

James



signature.asc
Description: OpenPGP digital signature

Bug#865125: libomp5: symbols file contains syntax errors

[James Cowgill]

Package: libomp5
Version: 4.0-1
Severity: serious

Hi,

The build log reports that libomp5.symbols contains syntax errors. This
caused dpkg-gensymbols to ignore everything after the syntax errors and
now libomp5 contains a number of incorrect symbol versions containing
the Debian revision number.

Build log:
>dh_makeshlibs -a
> Use of uninitialized value $rest in pattern match (m//) at 
> /usr/share/perl5/Dpkg/Shlibs/Symbol.pm line 125, <$filehandle> line 272.
> dpkg-gensymbols: warning: failed to parse line in debian/libomp5.symbols:  
> (optional=templinst|arch=!mips !mipsel !ppc64 !ppc64el !mips64 !mips64el) 
> __kmpc_atomic_fixed1_add@VERSION 0.20130412
> Use of uninitialized value $rest in pattern match (m//) at 
> /usr/share/perl5/Dpkg/Shlibs/Symbol.pm line 125, <$filehandle> line 272.
> dpkg-gensymbols: warning: failed to parse line in debian/libomp5.symbols:  
> (optional=templinst|arch=!mips !mipsel !ppc64 !ppc64el !mips64 !mips64el) 
> __kmpc_atomic_fixed1_add@VERSION 0.20130412
> dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
> (optional=templinst|arch=!mips
> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
> diff output below
> dpkg-gensymbols: warning: debian/libomp5/DEBIAN/symbols doesn't match 
> completely debian/libomp5.symbols

Excerpt from libomp5 DEBIAN/symbols near the first syntax error:
>  __kmpc_atomic_fixed1u_div_cpt_rev_fp@VERSION 4.0
>  __kmpc_atomic_fixed1u_div_fp@VERSION 0.20130412
>  __kmpc_atomic_fixed1u_div_rev@VERSION 0.20130412
>  __kmpc_atomic_fixed1u_div_rev_fp@VERSION 4.0
>  __kmpc_atomic_fixed1u_mul_cpt_fp@VERSION 4.0-1
>  __kmpc_atomic_fixed1u_mul_fp@VERSION 4.0-1
>  __kmpc_atomic_fixed1u_shr@VERSION 4.0-1
>  __kmpc_atomic_fixed1u_shr_cpt@VERSION 4.0-1

All the remaining symbols have version "4.0-1"

Also, some of these symbols look very suspicious. For instance, the
above symbol "__kmpc_atomic_fixed1_add" is marked as
"optional=templinst" but it is clearly not a C++ template instantiation.
Do you know the reason why these symbols need to be optional?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#865111: openmprtl FTBFS on mips64el: #error Unknown or unsupported architecture

[James Cowgill]

Control: tags -1 patch

Hi,

On 19/06/17 13:20, Adrian Bunk wrote:
> Source: openmprtl
> Version: 4.0-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=openmprtl=mips64el=4.0-1=1497874221=0
> 
> ...
> cd /«PKGBUILDDIR»/obj-mips64el-linux-gnuabi64/runtime/src && /usr/bin/c++   
> -Domp_EXPORTS -I/«PKGBUILDDIR»/obj-mips64el-linux-gnuabi64/runtime/src 
> -I/«PKGBUILDDIR»/runtime/src -I/«PKGBUILDDIR»/runtime/src/i18n 
> -I/«PKGBUILDDIR»/runtime/src/include/45 
> -I/«PKGBUILDDIR»/runtime/src/thirdparty/ittnotify  -g -O2 
> -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   -D 
> _GNU_SOURCE -D _REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 
> -fno-exceptions -fno-rtti -Wno-sign-compare -Wno-unused-function 
> -Wno-unused-value -Wno-unused-variable -Wno-switch -Wno-unknown-pragmas 
> -Wno-missing-field-initializers -Wno-missing-braces -Wno-comment -o 
> CMakeFiles/omp.dir/kmp_global.cpp.o -c 
> /«PKGBUILDDIR»/runtime/src/kmp_global.cpp
> In file included from /«PKGBUILDDIR»/runtime/src/kmp_global.cpp:17:0:
> /«PKGBUILDDIR»/runtime/src/kmp_affinity.h:229:4: error: #error Unknown or 
> unsupported architecture
>  #  error Unknown or unsupported architecture
> ^
> runtime/src/CMakeFiles/omp.dir/build.make:257: recipe for target 
> 'runtime/src/CMakeFiles/omp.dir/kmp_global.cpp.o' failed

It looks to me like the upstream patch was misapplied in kmp_affinity.h.
The attached patch should fix this by re-inserting the #else at the end
of the #if chain. I also fix the indentation of the mips defines which
was off by 1 character.

Thanks,
James
--- a/runtime/src/kmp_affinity.h
+++ b/runtime/src/kmp_affinity.h
@@ -204,28 +204,29 @@ public:
 #  elif __NR_sched_getaffinity != 223
 #   error Wrong code for getaffinity system call.
 #  endif /* __NR_sched_getaffinity */
-#  elif KMP_ARCH_MIPS
-#   ifndef __NR_sched_setaffinity
-#define __NR_sched_setaffinity  4239
-#   elif __NR_sched_setaffinity != 4239
-#error Wrong code for setaffinity system call.
-#   endif /* __NR_sched_setaffinity */
-#   ifndef __NR_sched_getaffinity
-#define __NR_sched_getaffinity  4240
-#   elif __NR_sched_getaffinity != 4240
-#error Wrong code for getaffinity system call.
-#   endif /* __NR_sched_getaffinity */
-#  elif KMP_ARCH_MIPS64
-#   ifndef __NR_sched_setaffinity
-#define __NR_sched_setaffinity  5195
-#   elif __NR_sched_setaffinity != 5195
-#error Wrong code for setaffinity system call.
-#   endif /* __NR_sched_setaffinity */
-#   ifndef __NR_sched_getaffinity
-#define __NR_sched_getaffinity  5196
-#   elif __NR_sched_getaffinity != 5196
-#error Wrong code for getaffinity system call.
-#   endif /* __NR_sched_getaffinity */
+# elif KMP_ARCH_MIPS
+#  ifndef __NR_sched_setaffinity
+#   define __NR_sched_setaffinity  4239
+#  elif __NR_sched_setaffinity != 4239
+#   error Wrong code for setaffinity system call.
+#  endif /* __NR_sched_setaffinity */
+#  ifndef __NR_sched_getaffinity
+#   define __NR_sched_getaffinity  4240
+#  elif __NR_sched_getaffinity != 4240
+#   error Wrong code for getaffinity system call.
+#  endif /* __NR_sched_getaffinity */
+# elif KMP_ARCH_MIPS64
+#  ifndef __NR_sched_setaffinity
+#   define __NR_sched_setaffinity  5195
+#  elif __NR_sched_setaffinity != 5195
+#   error Wrong code for setaffinity system call.
+#  endif /* __NR_sched_setaffinity */
+#  ifndef __NR_sched_getaffinity
+#   define __NR_sched_getaffinity  5196
+#  elif __NR_sched_getaffinity != 5196
+#   error Wrong code for getaffinity system call.
+#  endif /* __NR_sched_getaffinity */
+# else
 #  error Unknown or unsupported architecture
 # endif /* KMP_ARCH_* */
 class KMPNativeAffinity : public KMPAffinity {


signature.asc
Description: OpenPGP digital signature

Bug#865091: libbsd FTBFS on mips64el/ppc64el: FAIL: nlist

[James Cowgill]

Control: tags -1 patch

Hi,

On 19/06/17 09:24, Adrian Bunk wrote:
> FAIL: nlist
> ===
> 
> nlist: nlist.c:70: main: Assertion `rc == 0' failed.
> FAIL nlist (exit status: 134)

I've attached some patches which should fix this for mips64el and
ppc64el (and probably ppc64). As far as I can tell, nlist has never
worked on these architectures.

The ppc64el patch fixes 2 errors in local-elf.h:
* ppc64el defines both __powerpc__ and __powerpc64__ but since the
__powerpc64__ #elif is below the __powerpc__ one, it will never be hit.
* Both assumed that powerpc* was big-endian.

The mips64el patch adds a check for _MIPS_SIM inside the __mips__ #elif
to detect mips64el and use ELFCLASS64 in that case. Note that we can't
use defined(__mips64) here because that is also defined when the n32 ABI
is in use, which uses ELFCLASS32.

Thanks,
James
--- a/src/local-elf.h
+++ b/src/local-elf.h
@@ -140,17 +140,29 @@
 #define ELF_TARG_CLASS	ELFCLASS32
 #define ELF_TARG_DATA	ELFDATA2LSB
 
-#elif defined(__powerpc__)
-
-#define ELF_TARG_MACH	EM_PPC
-#define ELF_TARG_CLASS	ELFCLASS32
-#define ELF_TARG_DATA	ELFDATA2MSB
-
 #elif defined(__powerpc64__)
 
 #define ELF_TARG_MACH	EM_PPC64
 #define ELF_TARG_CLASS	ELFCLASS64
-#define ELF_TARG_DATA	ELFDATA2MSB
+#if defined(__LITTLE_ENDIAN__)
+#define ELF_TARG_DATA	ELFDATA2LSB
+#elif defined(__BIG_ENDIAN__)
+#define ELF_TARG_DATA	ELFDATA2MSB
+#else
+#error Unknown PowerPC64 endianness
+#endif
+
+#elif defined(__powerpc__)
+
+#define ELF_TARG_MACH	EM_PPC
+#define ELF_TARG_CLASS	ELFCLASS32
+#if defined(__LITTLE_ENDIAN__)
+#define ELF_TARG_DATA	ELFDATA2LSB
+#elif defined(__BIG_ENDIAN__)
+#define ELF_TARG_DATA	ELFDATA2MSB
+#else
+#error Unknown PowerPC endianness
+#endif
 
 #elif defined(__riscv)
 
--- a/src/local-elf.h
+++ b/src/local-elf.h
@@ -127,7 +127,11 @@
 #elif defined(__mips__)
 
 #define ELF_TARG_MACH	EM_MIPS
+#if defined(_ABI64) && _MIPS_SIM == _ABI64
+#define ELF_TARG_CLASS	ELFCLASS64
+#else
 #define ELF_TARG_CLASS	ELFCLASS32
+#endif
 #if defined(__MIPSEB__)
 #define ELF_TARG_DATA	ELFDATA2MSB
 #else


signature.asc
Description: OpenPGP digital signature

Bug#865105: gitlab: leaves stale systemd service symlinks after purge

[James Cowgill]

Package: gitlab
Version: 8.13.11+dfsg1-8
Severity: normal

Hi,

Purging gitlab seems to leave some stale files in /etc/systemd/system.
These are usually removed automatically when dh_systemd is in use by a
small snippet inserted into the postrm file. It looks like this is not
being executed.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864928: goaccess: Built-Using refers to non-existing source package libjs-bootstrap

[James Cowgill]

Source: goaccess
Version: 1:1.2-1
Severity: serious

Hi,

All the binary uploads of goaccess 1:1.2-1 in experimental were rejected
by dak with the error:

> $ cat goaccess_1.2-1_amd64.changes.reason 
> goaccess-dbgsym_1.2-1_amd64.deb: Built-Using refers to non-existing source 
> package libjs-bootstrap (= 3.3.7+dfsg-2)

Built-Using must contain _source_ packages, not binary packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864906: apt-cudf: gives invalid solutions involving mixed versioned/unversioned provides

[James Cowgill]

Package: apt-cudf
Version: 5.0.1-8
Severity: normal

Hi,

This bug has arisen after I started looking at why pdl 1:2.018-1~exp1
has been failing to install its dependencies in experimental.

https://buildd.debian.org/status/package.php?p=pdl=experimental

The failures only happen when the aspcud solver is used. When the normal
APT solver is used, everything works fine.

The error in pdl seems to revolve around the versioned provides of
perl-base which currently confuse apt-cudf because perl-base in sid does
NOT use versioned provides, but perl-base in experimental does.

I've attached a simplified test case which illustrates this. When
running apt-cudf on it I get this invalid solution:

$ apt-cudf --solver=aspcud test.edsp
Install: 101
Package: banana
Version: 1
Architecture: amd64

This is wrong because the cantelope dependency has not been satisfied.
Either cantelope needs to be installed, or eggplant needs to be upgraded.

==

The problem seems to be that banana has a generated CUDF dependency on
cantelope like this:

> package: banana%3aamd64
> version: 2
> depends: cantelope%3aamd64 >= 3 | --virtual-cantelope%3aamd64 = 2147483647 | 
> --virtual-cantelope%3aamd64 >= 3

But this gets satisfied by the OLD (already installed) eggplant which
has an unversioned provides:

> package: eggplant%3aamd64
> version: 2
> conflicts: eggplant%3aamd64 , eggplant
> provides: eggplant , --virtual-cantelope%3aamd64 = 2147483646

Thanks,
James
Request: EDSP 0.5
Architecture: amd64
Architectures: amd64
Install: banana:amd64
Strict-Pinning: no

Package: banana
Architecture: amd64
Version: 1
Depends: cantelope (>= 2)
APT-ID: 101
APT-Pin: 500

Package: cantelope
Architecture: amd64
Version: 2
APT-ID: 102
APT-Pin: 500

Package: eggplant
Architecture: amd64
Version: 1
Provides: cantelope
Installed: yes
APT-ID: 103
APT-Pin: 500

Package: eggplant
Architecture: amd64
Version: 2
Provides: cantelope (= 2)
APT-ID: 104
APT-Pin: 500


signature.asc
Description: OpenPGP digital signature

Bug#864886: iotop: add ioprio_* syscall numbers for mips

[James Cowgill]

Source: iotop
Version: 0.6-2
Severity: wishlist
Tags: patch

Hi,

Please consider applying the attached patch which adds the syscall
numbers for the ioprio_get and ioprio_set syscalls for MIPS. The patch
should work on all 3 mips variants supported by Debian. Like x86_64,
MIPS needs to consider the word size to handle running a 32-bit
userspace with a 64-bit kernel.

Thanks,
James

From ba5d1cfe7950f2590daf07766633f47c767cb5e9 Mon Sep 17 00:00:00 2001
From: James Cowgill <jcowg...@debian.org>
Date: Fri, 16 Jun 2017 14:53:18 +0100
Subject: [PATCH] Add ioprio_* syscall numbers for mips

---
 iotop/ioprio.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/iotop/ioprio.py b/iotop/ioprio.py
index 25fa972..cc139c2 100644
--- a/iotop/ioprio.py
+++ b/iotop/ioprio.py
@@ -31,6 +31,8 @@ IOPRIO_GET_ARCH_SYSCALL = [
 ('arm*','*',  315),
 ('i*86','*',  290),
 ('ia64*',   '*', 1275),
+('mips*',   '32bit', 4315),
+('mips*',   '64bit', 5274),
 ('parisc*', '*',  268),
 ('powerpc*','*',  274),
 ('s390*',   '*',  283),
@@ -45,6 +47,8 @@ IOPRIO_SET_ARCH_SYSCALL = [
 ('arm*','*',  314),
 ('i*86','*',  289),
 ('ia64*',   '*', 1274),
+('mips*',   '32bit', 4314),
+('mips*',   '64bit', 5273),
 ('parisc*', '*',  267),
 ('powerpc*','*',  273),
 ('s390*',   '*',  282),
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#864774: mariadb-10.1: make_atomic_add_body from c11_atomics.patch has incorrect behavior

[James Cowgill]

Source: mariadb-10.1
Version: 10.1.23-8
Severity: important
Tags: patch

Hi,

While doing some testing for upstream, I had to apply a slightly
modified version of c11_atomics.patch to get 10.2 to build on MIPS.
However although MariaDB builds after that, it immediately aborts near
some atomics related code.

I discovered that the implementation of make_atomic_add_body in
incorrect in c11_atomics.patch. At the moment we have this:

+#define make_atomic_add_body(S) \
+  __atomic_add_fetch(a, v, __ATOMIC_SEQ_CST)

From the documentation of make_atomic_add, it looks like v should be set
to the previous value of *a which is not done here. The correct
implementation is:

+#define make_atomic_add_body(S) \
+  v= __atomic_fetch_add(a, v, __ATOMIC_SEQ_CST)

This is very similar to the operation used for the native GCC atomics above.

While this bug causes 10.2 to completely break on MIPS, I haven't seen
10.1 break. It may be that this code isn't used anywhere important in
10.1, but I still think it would be good to fix this before finding out
some obscure place it does break.

Thanks,
James
diff -Nru mariadb-10.1-10.1.24/debian/patches/c11_atomics.patch 
mariadb-10.1-10.1.24/debian/patches/c11_atomics.patch
--- mariadb-10.1-10.1.24/debian/patches/c11_atomics.patch   2017-06-07 
01:23:44.0 +0100
+++ mariadb-10.1-10.1.24/debian/patches/c11_atomics.patch   2017-06-14 
14:03:27.0 +0100
@@ -59,7 +59,7 @@
 +#elif defined(HAVE_GCC_C11_ATOMICS)
 +
 +#define make_atomic_add_body(S) \
-+  __atomic_add_fetch(a, v, __ATOMIC_SEQ_CST)
++  v= __atomic_fetch_add(a, v, __ATOMIC_SEQ_CST)
 +#define make_atomic_fas_body(S) \
 +  v= __atomic_exchange_n(a, v, __ATOMIC_SEQ_CST)
 +#define make_atomic_cas_body(S) \


signature.asc
Description: OpenPGP digital signature

Bug#864717: libffado: FTCBFS assumes host = machine architecture

[James Cowgill]

Control: retitle -1 libffado: FTCBFS assumes host = machine architecture

Hi,

On 13/06/17 13:33, treb...@tuxfamily.org wrote:
> Package: libffado
> Version: 2.3.0-2
> 
> Dear debian maintainers,
> 
> trying to rebuild a 32 bits package for FFADO with pbuilder on 64 bits
> machine gives me a :
> ...
> zip
> ...
> scons: done reading SConscript files.
> scons: Building targets ...
> building 'config_debug.h' from 'config_debug.h.in'
> building 'config.h' from 'config.h.in'
> g++ -o src/DeviceStringParser.os -c -std=gnu++11 -mx32 -fPIC -fPIC

I've adjusted the title to something a bit better.

The issue is that the libffado scripts assume that they can determine
the host architecture by probing the machine architecture through some
black magic (calling objdump on /bin/mount !). The x32.patch follows
this by reading "uname -m" to determine if it's running on x32 or i386.

The correct solution is to remove all of this code and just invoke $(CC)
which in Debian package builds should be set to a suitable compiler for
the right architecture. Conveniently, there appears to an option to do
this "DETECT_USERSPACE_ENV=False", so we don't need to patch the source
and we can probably remove x32.patch after this as well (untested though!).

As a workaround you can use "linux32 pbuilder..." when building the
package to override "uname -m". I know that sbuild already does this for
you which is probably why none of the buildds suffer from this bug.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[James Cowgill]

On 08/06/17 23:10, Johannes Schultz wrote:
> Hi,
> 
>>> I guess it depends on what you define as "reasonable". Depending on the
>>> malformed file and setup, they may take minutes to load (given that
>>> enough (virtual) memory is available to load all the truncated samples).
>>> The test cases that were generated by American Fuzzy Lop were about 5KB
>>> in size and took about 10 seconds to load on my machine, which I would
>>> say is quite excessive for such a tiny file, but those examples can be
>>> modified (by adding more malformed sample slots) to extend the loading
>>> time from seconds to minutes while still being about 5KB.
>>>
>>> To give some perspective, I don't just use libopenmpt on Desktop systems
>>> but also to scan module data in a server application where users can
>>> upload their own modules, and if a user could keep a server request busy
>>> for a minute (while also wasting tons of memory and CPU time), that
>>> server could be DOSed very easily. Thus I'd strongly suggest to include
>>> those two patches.
>>
>> I see, that is quite a long time to wait! Do you have these testcases so
>> I can try them? My only concern is that p3 is pretty big so it has the
>> potential of causing a regression. p5 looks fine.
> 
> I have attached some manually-crafted worst-case files to demonstrate
> the issue. For maximum effect, a 64-bit build has to be used, because
> otherwise memory allocation will fail fairly quickly and the malformed
> sample data won't even be attempted to be decoded.
> 
> p3 is smaller than it looks since some of it is just moving around
> things and as a consequence re-indenting them. The actual decoding logic
> is not modified. A diff without whitespaces should show this.

Thanks.

Do any of these issues have CVE numbers?

James



signature.asc
Description: OpenPGP digital signature

Bug#853394: extremetuxracer: ftbfs with GCC-7

[James Cowgill]

Control: block -1 by 853729

Hi,

On 11/06/17 00:18, Marko Lindqvist wrote:
> On 31 January 2017 at 11:31, Matthias Klose  wrote:
>> event.o: In function `CEvent::Enter()':
>> ./src/event.cpp:160: undefined reference to `sf::String::operator 
>> std::__cxx11::basic_string> std::allocator >() const'
>> ./src/event.cpp:166: undefined reference to `sf::String::operator 
>> std::__cxx11::basic_string> std::allocator >() const'
>> ./src/event.cpp:170: undefined reference to `sf::String::operator 
>> std::__cxx11::basic_string> std::allocator >() const'
>> game_over.o: In function `GameOverMessage(CControl const*)':
>> ./src/game_over.cpp:91: undefined reference to `sf::String::operator 
>> std::__cxx11::basic_string> std::allocator >() const'
>> ./src/game_over.cpp:97: undefined reference to `sf::String::operator 
>> std::__cxx11::basic_string> std::allocator >() const'
>> game_over.o:./src/game_over.cpp:107: more undefined references to 
>> `sf::String::operator std::__cxx11::basic_string> std::char_traits, std::allocator >() const' follow
>> collect2: error: ld returned 1 exit status
>> Makefile:474: recipe for target 'etr' failed
>> make[3]: *** [etr] Error 1
> 
>  I see that error with g++7 on both etr-0.7 branch (where release used
> by Debian is from) and development version. We saw similar problem on
> etr development version with earlier version of clang++, but with
> current Debian Testing (Stretch) etr development version compiles fine
> with clang++. etr-0.7 branch does not compile with clang++ for
> unrelated reasons.
>  This seems like a sort of incompatibility problem between c++11
> std::string and SFML string class. I don't know if we can do anything
> to it in etr upstream. Could Debian accept a version that specifically
> requires clang++ to be used, and cannot be compiled with g++7? There
> is no such release at the moment, but etr-0.8 could be like that.
> Another option is to just wait if g++8 will fix the problem, like
> clang++ upgrade apparently did.

This bug is caused by a slight ABI adjustment to "operator
std::string()" functions in GCC 7 (see the GCC 7 porting guide [1]).
This is not an ABI break, but it does require libsfml to be rebuilt
against GCC 7 first before reverse dependencies can be.

Once GCC 7 becomes the default compiler, I'll upload a new version of
libsfml with some shlibs bumps which should resolve this without any
changes to extremetuxracer.

[1] https://gcc.gnu.org/gcc-7/porting_to.html

James



signature.asc
Description: OpenPGP digital signature

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[James Cowgill]

Hi,

On 08/06/17 13:23, Johannes Schultz wrote:
>>> I don't understand patch p6 well enough to say how
>>> serious it is (depends on where the invalid pointer being dereferenced
>>> comes from).
>>
>> As far as I know, it is just a NULL pointer. Johannes did the analysis
>> and might be able to elaborate (CCed).
> 
> Correct. I am not sure if it is possible at all to trigger that field to
> be NULL in libopenmpt but it is possible in OpenMPT in some live editing
> situations. I cannot be 100% sure if libopenmpt would ever be able to
> trigger this crash but it should be obvious that adding a null-pointer
> check should do no harm to the library.

OK. In that case all these fixes will almost certainly be deferred until
the first point release of stretch. The release team only wants
emergency fixes in the last week up to the release.

>>> p3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
>>> p5-excessive-cpu-consumption-on-malformed-files-ams.patch
>>>
>>> Are these actually security bugs? As long as the code finishes in a
>>> reasonable amount of time and produces the right results, then there's
>>> not much harm in leaving the code as it is.
>>
>> Again, Johannes knows more about these.
> 
> I guess it depends on what you define as "reasonable". Depending on the
> malformed file and setup, they may take minutes to load (given that
> enough (virtual) memory is available to load all the truncated samples).
> The test cases that were generated by American Fuzzy Lop were about 5KB
> in size and took about 10 seconds to load on my machine, which I would
> say is quite excessive for such a tiny file, but those examples can be
> modified (by adding more malformed sample slots) to extend the loading
> time from seconds to minutes while still being about 5KB.
> 
> To give some perspective, I don't just use libopenmpt on Desktop systems
> but also to scan module data in a server application where users can
> upload their own modules, and if a user could keep a server request busy
> for a minute (while also wasting tons of memory and CPU time), that
> server could be DOSed very easily. Thus I'd strongly suggest to include
> those two patches.

I see, that is quite a long time to wait! Do you have these testcases so
I can try them? My only concern is that p3 is pretty big so it has the
potential of causing a regression. p5 looks fine.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864439: bowtie: FTBFS on mips64el - /usr/bin/ld: .gnu.hash is incompatible with the MIPS ABI

[James Cowgill]

Source: bowtie
Version: 1.2.0+dfsg-1
Severity: serious

Hi,

bowtie FTBFS on mips64el with this error:
> g++ -w -O3 -DCOMPILER_OPTIONS="\"-O3  -Wl,--hash-style=both -DWITH_TBB 
> -DNO_SPINLOCK -DWITH_QUEUELOCK=1 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat 
> -Werror=format-security  -g -O2 -fdebug-prefix-map=.=. 
> -fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
> -Wl,-z,now\""  -Wl,--hash-style=both -DWITH_TBB -DNO_SPINLOCK 
> -DWITH_QUEUELOCK=1 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/«BUILDDIR»/bowtie-1.2.0+dfsg=. -fstack-protector-strong 
> -Wformat -Werror=format-security  -g -O2 
> -fdebug-prefix-map=/«BUILDDIR»/bowtie-1.2.0+dfsg=. -fstack-protector-strong 
> -Wformat -Werror=format-security  -Wl,-z,relro -Wl,-z,now  \
>   -fno-strict-aliasing -DBOWTIE_VERSION="\"`cat VERSION`\"" 
> -DBUILD_HOST="\"Debian-reproducible\"" -DBUILD_TIME="\"`dpkg-parsechangelog 
> --show-field Date`\"" -DCOMPILER_VERSION="\"`g++ -w -v 2>&1 | tail -1 | sed 
> 's/ *(.*//'`\"" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE  
> -DPREFETCH_LOCALITY=2 -DBOWTIE_MM -DBOWTIE_SHARED_MEM -DNDEBUG -Wall \
>   -I /usr/include/seqan \
>   -o bowtie-build-s ebwt_build.cpp \
>   ccnt_lut.cpp ref_read.cpp alphabet.cpp shmem.cpp edit.cpp ebwt.cpp  
> bowtie_build_main.cpp \
>   -lpthread -ltbb -ltbbmalloc_proxy 
> /usr/bin/ld: .gnu.hash is incompatible with the MIPS ABI
> collect2: error: ld returned 1 exit status
> Makefile:258: recipe for target 'bowtie-build-s' failed
> make[2]: *** [bowtie-build-s] Error 1
> make[2]: Leaving directory '/«BUILDDIR»/bowtie-1.2.0+dfsg'
> debian/rules:17: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory '/«BUILDDIR»/bowtie-1.2.0+dfsg'
> debian/rules:14: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

This is because mips* does not currently support -Wl,--hash-style=both.
Unfortunately the MIPS linker (ab)uses the dynamic symbol table making
it much harded to add support for this to BFD so it has not been done yet.

I think the gnu hash style is just an optimization, so it should be OK
to remove this option completely. --hash-style=gnu is already the
default on all all other architectures and has been for a few years now
so removing it on Debian should not affect other architectures.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864429: dms: maintainer email address bounces

[James Cowgill]

Source: dms
Version: 1.0.8-1
Severity: serious
Tags: sid buster
Justification: Policy 3.3

Hi,

The maintainer address for dms bounces with the following message:
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected.  If you think that your messages are
> being rejected in error, contact the mailing list owner at
> dms-maintainers-ow...@lists.alioth.debian.org.

That was after I sent a test message to
dms-maintain...@lists.alioth.debian.org

Per policy 3.3:
> The maintainer must be specified in the Maintainer control field with 
> their correct name and a working email address. The email address given 
> in the Maintainer control field must accept mail from those role 
> accounts in Debian used to send automated mails regarding the package. 
> This includes non-spam mail from the bug-tracking system, all mail from 
> the Debian archive maintenance software, and other role accounts or 
> automated processes that are commonly agreed on by the project.

This also affects jessie, but since the maintainer address matters less
for stable releases, I've tagged this bug sid buster.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864426: dms: FTBFS: dh_sphinxdoc: Sphinx documentation not found

[James Cowgill]

Source: dms
Version: 1.0.8-1
Severity: serious
Tags: sid buster

Hi,

dms FTBFS in unstable (all architectures) with the following error:
>dh_installdocs -a
>debian/rules override_dh_sphinxdoc
> make[1]: Entering directory '/<>'
> dh_sphinxdoc -X searchtools.js -X translations.js
> dh_sphinxdoc: Sphinx documentation not found
> dh_sphinxdoc /usr/share/doc/dms-doc/html/
> dh_sphinxdoc: Path /usr/share/doc/dms-doc/html/ not found in any built package
> (searched in: dms-core dms-wsgi dms-dr dms)
> debian/rules:52: recipe for target 'override_dh_sphinxdoc' failed
> make[1]: *** [override_dh_sphinxdoc] Error 2
> make[1]: Leaving directory '/<>'
> debian/rules:56: recipe for target 'binary-arch' failed
> make: *** [binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
> status 2

I also notice that your debian/rules has a duplicate "dh $@" rule which
looks like a mistake.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864340: mariadb-10.1 FTBFS on mips64el on Loongson: Installing system database killed with signal TERM after 150 minutes of inactivity

[James Cowgill]

Control: tags -1 patch

Hi,

On 07/06/17 12:14, James Cowgill wrote:
> Control: block -1 by 843926
> 
> On 07/06/17 09:29, Adrian Bunk wrote:
>> Source: mariadb-10.1
>> Version: 10.1.22-3
>> Severity: serious
>>
>> https://buildd.debian.org/status/logs.php?pkg=mariadb-10.1=mips64el
>>
>> ...
>> # Run testsuite
>> cd builddir/mysql-test && ./mtr --force --testcase-timeout=30 
>> --suite-timeout=540 --retry=3 --parallel=4 --skip-test-list=unstable-tests  
>> || exit 1 ;
>> Logging: /«PKGBUILDDIR»/mysql-test/mysql-test-run.pl  --force 
>> --testcase-timeout=30 --suite-timeout=540 --retry=3 --parallel=4 
>> --skip-test-list=unstable-tests
>> vardir: /«PKGBUILDDIR»/builddir/mysql-test/var
>> Removing old var directory...
>> Creating var directory '/«PKGBUILDDIR»/builddir/mysql-test/var'...
>> Checking supported features...
>> MariaDB Version 10.1.24-MariaDB-3
>>  - SSL connections supported
>> Sphinx 'indexer' binary not found, sphinx suite will be skipped
>> Using suites: 
>> main-,archive-,binlog-,binlog_encryption-,csv-,encryption-,federated-,funcs_1-,funcs_2-,handler-,heap-,innodb-,innodb_fts-,innodb_zip-,maria-,mariabackup-,multi_source-,optimizer_unfixed_bugs-,parts-,percona-,perfschema-,plugins-,roles-,rpl-,sys_vars-,unit-,vcol-,wsrep-,connect,mroonga/wrapper,mroonga/storage,oqgraph,sequence,spider,spider/bg,sql_discovery,metadata_lock_info,query_response_time
>> Collecting tests...
>> Installing system database...
>> debian/rules:92: recipe for target 'override_dh_auto_test' failed
>> make[1]: *** [override_dh_auto_test] Terminated
>> E: Caught signal ‘Terminated’: terminating immediately
>> make: *** wait: No child processes.  Stop.
>> make: *** Waiting for unfinished jobs
>> make: *** wait: No child processes.  Stop.
>> Build killed with signal TERM after 150 minutes of inactivity
>>
>>
>> It seems to always fail on Loongson buildds but never on others.
>>
>> Based on how it fails, I suspect mariadb-10.1 on mips64el is
>> completely broken on Loongson.
> 
> It looks like this is #843926 ("jemalloc uses a hard coded page size
> detected during build"). I can reproduce this bug on an Broadcom XLP
> machine so it isn't Loongson specific. Both the Loongson buildds and the
> XLP use 16K pages whereas the Octeon buildds use 4K pages. Also the
> reproducer in message #61 in the above bug report also segfaults on the
> Loongsons.

The attached patch disables jemalloc on mips. This seems to be the best
solution at the moment until jemalloc gets fixed - there is an upstream
patch but it's quite large.

Thanks,
James
diff -Nru mariadb-10.1-10.1.24/debian/changelog 
mariadb-10.1-10.1.24/debian/changelog
--- mariadb-10.1-10.1.24/debian/changelog   2017-06-07 01:23:44.0 
+0100
+++ mariadb-10.1-10.1.24/debian/changelog   2017-06-07 13:58:31.0 
+0100
@@ -1,3 +1,10 @@
+mariadb-10.1 (10.1.24-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable jemalloc on mips*. (Closes: #864340)
+
+ -- James Cowgill <jcowg...@debian.org>  Wed, 07 Jun 2017 13:58:31 +0100
+
 mariadb-10.1 (10.1.24-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru mariadb-10.1-10.1.24/debian/control 
mariadb-10.1-10.1.24/debian/control
--- mariadb-10.1-10.1.24/debian/control 2017-06-07 01:23:44.0 +0100
+++ mariadb-10.1-10.1.24/debian/control 2017-06-07 13:58:31.0 +0100
@@ -18,7 +18,7 @@
libarchive-dev,
libboost-dev,
libcrack2-dev (>= 2.9.0),
-   libjemalloc-dev [linux-any],
+   libjemalloc-dev [!kfreebsd-any !hurd-any !mips !mipsel !mips64 
!mips64el],
libjudy-dev,
libkrb5-dev,
libncurses5-dev (>= 5.0-6~),
diff -Nru mariadb-10.1-10.1.24/debian/rules mariadb-10.1-10.1.24/debian/rules
--- mariadb-10.1-10.1.24/debian/rules   2017-06-07 01:23:44.0 +0100
+++ mariadb-10.1-10.1.24/debian/rules   2017-06-07 13:58:31.0 +0100
@@ -40,6 +40,11 @@
 CMAKEFLAGS += -DWITHOUT_TOKUDB=true
 endif
 
+# Disable jemalloc on mips* due to #843926
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel mips64 mips64el))
+CMAKEFLAGS += -DWITH_JEMALLOC=no
+endif
+
 # Add support for verbose builds
 MAKEFLAGS += VERBOSE=1
 


signature.asc
Description: OpenPGP digital signature

Bug#832931: Bug#843926: jemalloc hard codes page size during build

[James Cowgill]

tags 843926 fixed-upstream
forwarded 843926 https://github.com/jemalloc/jemalloc/issues/467
tags 832931 - fixed-upstream
forwarded 832931 https://jira.mariadb.org/browse/MDEV-11877
thanks

Sorry, sent to the wrong bug number.

On 07/06/17 15:15, James Cowgill wrote:
> Control: forwarded -1 https://github.com/jemalloc/jemalloc/issues/467
> Control: tags -1 fixed-upstream
> 
> On 10/11/16 18:37, Thadeu Lima de Souza Cascardo wrote:
>> clone -1 -2
>> reassign -2 libjemalloc1
>> retitle -2 jemalloc uses a hard coded page size detected during build
>> bye
>>
>>
>> So, I traced this to jemalloc using the incorrect page size during
>> runtime. In fact, it detects the page size during build and set it up.
>> This has a large potential for a mess. And what a mess!
>>
>> So, jemalloc in jessie has been built on a 4KiB-page system, and, this,
>> has a hard-coded page size of 4KiB. While jemalloc in sid has a
>> 64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page
>> size system, everything goes well. When we build it on partch, with a
>> 64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc.
>>
>> Later upstream versions seem to support multiple page sizes during
>> build.
> 
> It looks like jemalloc 5.0.0 will support multiple page sizes
> automatically as long as you pass the biggest possible page size when
> you configure it:
> https://github.com/jemalloc/jemalloc/pull/769
> 
> That patch is pretty big though, so it won't help with stretch.
> 
>> For MariaDB specifically, one option would be to build it without
>> jemalloc. Other users would still be likely affected, however.
> 
> Limiting it to specific architectures is probably ok though.
> 
> Thanks,
> James




signature.asc
Description: OpenPGP digital signature

Bug#832931: Bug#843926: jemalloc hard codes page size during build

[James Cowgill]

Control: forwarded -1 https://github.com/jemalloc/jemalloc/issues/467
Control: tags -1 fixed-upstream

On 10/11/16 18:37, Thadeu Lima de Souza Cascardo wrote:
> clone -1 -2
> reassign -2 libjemalloc1
> retitle -2 jemalloc uses a hard coded page size detected during build
> bye
> 
> 
> So, I traced this to jemalloc using the incorrect page size during
> runtime. In fact, it detects the page size during build and set it up.
> This has a large potential for a mess. And what a mess!
> 
> So, jemalloc in jessie has been built on a 4KiB-page system, and, this,
> has a hard-coded page size of 4KiB. While jemalloc in sid has a
> 64KiB-page size. When we try to build mariadb on jessie on a 4KiB-page
> size system, everything goes well. When we build it on partch, with a
> 64-bit 64KiB-page size kernel, things break, if it's a jessie jemalloc.
> 
> Later upstream versions seem to support multiple page sizes during
> build.

It looks like jemalloc 5.0.0 will support multiple page sizes
automatically as long as you pass the biggest possible page size when
you configure it:
https://github.com/jemalloc/jemalloc/pull/769

That patch is pretty big though, so it won't help with stretch.

> For MariaDB specifically, one option would be to build it without
> jemalloc. Other users would still be likely affected, however.

Limiting it to specific architectures is probably ok though.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864340: mariadb-10.1 FTBFS on mips64el on Loongson: Installing system database killed with signal TERM after 150 minutes of inactivity

[James Cowgill]

Control: block -1 by 843926

On 07/06/17 09:29, Adrian Bunk wrote:
> Source: mariadb-10.1
> Version: 10.1.22-3
> Severity: serious
> 
> https://buildd.debian.org/status/logs.php?pkg=mariadb-10.1=mips64el
> 
> ...
> # Run testsuite
> cd builddir/mysql-test && ./mtr --force --testcase-timeout=30 
> --suite-timeout=540 --retry=3 --parallel=4 --skip-test-list=unstable-tests  
> || exit 1 ;
> Logging: /«PKGBUILDDIR»/mysql-test/mysql-test-run.pl  --force 
> --testcase-timeout=30 --suite-timeout=540 --retry=3 --parallel=4 
> --skip-test-list=unstable-tests
> vardir: /«PKGBUILDDIR»/builddir/mysql-test/var
> Removing old var directory...
> Creating var directory '/«PKGBUILDDIR»/builddir/mysql-test/var'...
> Checking supported features...
> MariaDB Version 10.1.24-MariaDB-3
>  - SSL connections supported
> Sphinx 'indexer' binary not found, sphinx suite will be skipped
> Using suites: 
> main-,archive-,binlog-,binlog_encryption-,csv-,encryption-,federated-,funcs_1-,funcs_2-,handler-,heap-,innodb-,innodb_fts-,innodb_zip-,maria-,mariabackup-,multi_source-,optimizer_unfixed_bugs-,parts-,percona-,perfschema-,plugins-,roles-,rpl-,sys_vars-,unit-,vcol-,wsrep-,connect,mroonga/wrapper,mroonga/storage,oqgraph,sequence,spider,spider/bg,sql_discovery,metadata_lock_info,query_response_time
> Collecting tests...
> Installing system database...
> debian/rules:92: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Terminated
> E: Caught signal ‘Terminated’: terminating immediately
> make: *** wait: No child processes.  Stop.
> make: *** Waiting for unfinished jobs
> make: *** wait: No child processes.  Stop.
> Build killed with signal TERM after 150 minutes of inactivity
> 
> 
> It seems to always fail on Loongson buildds but never on others.
> 
> Based on how it fails, I suspect mariadb-10.1 on mips64el is
> completely broken on Loongson.

It looks like this is #843926 ("jemalloc uses a hard coded page size
detected during build"). I can reproduce this bug on an Broadcom XLP
machine so it isn't Loongson specific. Both the Loongson buildds and the
XLP use 16K pages whereas the Octeon buildds use 4K pages. Also the
reproducer in message #61 in the above bug report also segfaults on the
Loongsons.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[James Cowgill]

Control: tags -1 security

Hi,

On 05/06/17 07:03, Jörn Heusipp wrote:
> Source: libopenmpt
> Version: 0.2.7386~beta20.3-3
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> A couple of security-related fixes have been released upstream as 
> version 0.2.7386-beta20.3-p7. See 
> https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
>
> These most importantly fix a couple of possible crashes which can be 
> triggered by maliciously modified or malformed or truncated module 
> files as well as denial-of-service through hangs or excessive CPU 
> consumption which can also be triggered maliciously modfied or 
> malformed or truncated module files.

I've had a look at the patches now and this is what I think:

p1-division-by-zero-in-tempo-calculation.patch
p2-infinite-loop-in-plugin-routing.patch
p6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch

These three are clearly denial-of-service by malicious module file and
should be fixed in stretch. However, I don't think the first two are
"serious" because they're just denial-of-service bugs in a library
almost exclusively used on end user machines (as opposed to eg remote
code execution). I don't understand patch p6 well enough to say how
serious it is (depends on where the invalid pointer being dereferenced
comes from).

p3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
p5-excessive-cpu-consumption-on-malformed-files-ams.patch

Are these actually security bugs? As long as the code finishes in a
reasonable amount of time and produces the right results, then there's
not much harm in leaving the code as it is.

p4-theoretical-null-pointer-dereference-during-out-of-memory-while-error-handling.patch

I don't think this is a security bug. It requires malloc to fail, and
the chances of that happening on Linux are very small. If that does
occur, you're likely to be killed by the OOM killer anyway.

I also note that the C++ standard _requires_ std::exception::what to
return a non-null value so a very intelligent compiler could
legitimately remove the null check (I doubt GCC does this though).

p7-race-condition-in-multi-threaded-use-it.patch

I also don't think this is a security bug (at least on Linux). Looking
at the glibc sources, the internal tzdata state is protected by a mutex
so the only risk here is that localtime will return some garbage time
values. Since the string generated by this function is only going to be
shown to the user, nothing that bad will happen in this case. Finally,
it relies on a multithreaded client application loading 2 modules at the
same time which seems unlikely to me.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#864298: mariadb-10.1: FTBFS on mips*: error: 'ib_mutex_t' does not name a type

[James Cowgill]

Control: tags -1 upstream patch
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-13009

On 06/06/17 16:42, Andreas Beckmann wrote:
> Package: mariadb-10.1
> Version: 10.1.24-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> https://buildd.debian.org/status/package.php?p=mariadb-10.1=unstable
> 
> mips and mipsel failed, mips64el is still building
> 
> In file included from /«PKGBUILDDIR»/storage/innobase/lock/lock0wait.cc:29:0:
> /«PKGBUILDDIR»/storage/innobase/include/srv0mon.h:649:8: error: 'ib_mutex_t' 
> does not name a type
>  extern ib_mutex_t monitor_mutex;
> ^~

The attached patch fixes this for me. The bug affects architectures
without lock-free 64-bit atomics. I think these are: mips, mipsel,
powerpc and m68k (mips64el is not affected).

Thanks,
James
--- a/storage/innobase/include/os0sync.h
+++ b/storage/innobase/include/os0sync.h
@@ -37,6 +37,7 @@ Created 9/6/1995 Heikki Tuuri
 
 #include "univ.i"
 #include "ut0lst.h"
+#include "sync0types.h"
 
 /** CPU cache line size */
 #ifdef __powerpc__


signature.asc
Description: OpenPGP digital signature

Bug#855921: Processed: New version 0.11.2 (not detected by package tracker).

[James Cowgill]

Control: retitle -1 New version 0.11.1 (not detected by package tracker).
Control: severity -1 wishlist
Control: notfound -1 0.11.1-1
Control: close -1 0.11.1-1

Hi,

On 06/06/17 16:42, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
>> found 855921 0.11.1-1
> Bug #855921 {Done: Fabian Greffrath } [freedoom] freedoom: 
> New version 0.11.1 (not detected by package tracker).
> Marked as found in versions freedoom/0.11.1-1; no longer marked as fixed in 
> versions freedoom/0.11.1-1 and reopened.
>> retitle 855921 New version 0.11.2 (not detected by package tracker).
> Bug #855921 [freedoom] freedoom: New version 0.11.1 (not detected by package 
> tracker).
> Changed Bug title to 'New version 0.11.2 (not detected by package tracker).' 
> from 'freedoom: New version 0.11.1 (not detected by package tracker).'.
>> thanks

You should file new bugs for new issues. The old bug was that "0.11.1
was not packaged" and since this is still fixed, this bug should not be
reopened.

On the tracker issue - for some reason UDD (which the tracker uses)
thinks freedoom in sid does not have a watch file, but it does find the
watch file in experimental. I'm not sure why this happened, but
hopefully uploading something to unstable will fix it.

James



signature.asc
Description: OpenPGP digital signature

Bug#864012: lepton: Upstream requires sse4.1 in Intel platform which is not available in all build machines

[James Cowgill]

Control: severity -1 serious

Hi,

On Sat, 3 Jun 2017 14:40:57 +0800 ChangZhuo Chen  wrote:
> Package: lepton
> Version: 1.2.1+20170405-3
> Severity: normal
> 
> lepton requires sse4.1 to build with vectorization. However, not all
> build machines (ex: binet) support sse4.1. If lepton is built in these
> build machines, test cases will fail due to "Illegal instruction" [0].
> 
> [0] 
> https://buildd.debian.org/status/fetch.php?pkg=lepton=amd64=1.2.1%2B20170405-3=1496420251=0

If the package cannot reliably build on all the x86 build machines due
to a fault in the package, the package is RC-buggy.

Note that shipping a binary which requires SSE 4.1 is also prohibited
because it will SIGILL on old (but still supported) machines.

James



signature.asc
Description: OpenPGP digital signature

Bug#852962: ycmd FTBFS on mipsel: test failures

[James Cowgill]

Hi,

On Thu, 1 Jun 2017 00:15:28 +0200 Christoph Biedl
 wrote:
> Julien Cristau wrote...
> 
> > On Wed, Feb  1, 2017 at 10:49:34 +0100, Emilio Pozuelo Monfort wrote:
> >
> > > Somehow this has built now:
> > >
> > > https://buildd.debian.org/status/logs.php?pkg=ycmd=0%2B20161219%2Bgit486b809-1=mipsel
> > >
> > > Let's downgrade for now.
> > >
> > Next upload failed again, somebody needs to look at this.
> 
> Did so, but failed to reproduce the issue on the mipsel porter box.
> However, the bug seems to manifest when building in a qemu-static
> chroot. In that scenario however, diagnostic tools like strace
> fail.
> 
> Updates will follow as I get them.

I've tried this on various mips hardware and I can only seems to fail on
Loongsons (where is reliably fails 100% of the time). Blacklisting it on
those machines could be an option given how close to the release we are.

Interestingly I cannot reproduce this bug with qemu-user so I'm not sure
what's going on there.

James



signature.asc
Description: OpenPGP digital signature

Bug#864144: e2fsprogs strangeness about mips* multilibs

[James Cowgill]

Hi,

On 04/06/17 20:51, Helmut Grohne wrote:
> Hi Ted,
> 
> On Sun, Jun 04, 2017 at 02:46:08PM -0400, Theodore Ts'o wrote:
>> I'm going to confess complete ignorance to what's going on with mips.
>> In the past my modus operandi is that I would make changes in response
>> to requests to the MIPS porters, in some cases with incomplete
>> understand why they were needed in the first place.
>>
>> My bias would be to remove *all* of the mips specific exceptions in
>> the debian directory, and then see if things still build on mips, and
>> if there are any known problems caused by the mips installer or mips
>> bootpath.  And if we do need to add back any exceptions for the MIPS
>> architecture, let's make sure it's very clearly documented why they
>> are there.  Because at the moment, I'm a bit embarassed at my
>> inability to answer your perfectly reasonable questions.  :-)
> 
> I think the approach is reasonable. I did put
> debian-m...@lists.debian.org into X-Debbugs-Cc for this reason and am
> full quoting your reply to that list now to have them object.

From what I can tell, the only purpose of the extra mips libraries is to
support some old bootloaders/firmware - arcboot being the only package I
know which used this. No "normal" packages in the archive would have
been able to use them unless they were statically linked. Since arcboot
was removed, I think it should be safe to remove these special libraries
from e2fsprogs.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#863937: faustworks: FTBFS: RCC: Error in 'Resources/i18n.qrc': Cannot find file 'translations/i18n_ru.qm'

[James Cowgill]

Control: tags -1 pending

On 02/06/17 03:05, Lucas Nussbaum wrote:
> Source: faustworks
> Version: 0.5~repack0-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170601 qa-ftbfs
> Justification: FTBFS in stretch on amd64
> 
> Hi,
> 
> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on amd64.
> 
> Relevant part (hopefully):
[...]
>> /usr/lib/x86_64-linux-gnu/qt4/bin/rcc -name i18n Resources/i18n.qrc -o 
>> qrc_i18n.cpp
>> RCC: Error in 'Resources/i18n.qrc': Cannot find file 
>> 'translations/i18n_ru.qm'
>> Makefile:331: recipe for target 'qrc_i18n.cpp' failed
>> make[1]: *** [qrc_i18n.cpp] Error 1

This appears to be an build script ordering issue when building with
lots of processors. I don't know qmake very well so for the moment I've
just added --no-parallel when building this package.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#863785: mediatomb: Please drop dependency against mozjs 1.8.5

[James Cowgill]

Hi,

On 31/05/17 08:24, bi...@debian.org wrote:
> Source: mediatomb
> Version: 0.12.1-47-g7ab7616-1
> Severity: normal
> Tags: sid buster
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs mozjs185
> 
> Dear maintainer,
> 
> Your package is depending against mozjs 1.8.5. This package is old
> and currently orphaned.
> 
> Could you please remove this dependency or switch to a more recent
> version of mozjs?
> 
> We should remove this version of mozjs from buster, I'm planning to
> make this bug RC when the new development cycle is open.

FYI mediatomb is pretty much dead and I'm working to replace it with the
new fork "gerbera", which has already switched to using duktape as its
javascript engine. I expect this package to be removed before this bug
gets fixed. Mediatomb is not in testing so at least it should not block
removing mozjs there.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#863746: fpc: Please adjust fp-units-gfx.install.in for linux-mips

[James Cowgill]

Hi Adrian,

On 30/05/17 22:46, John Paul Adrian Glaubitz wrote:
> Source: fpc
> Version: 3.0.0+dfsg-11
> Severity: normal
> Tags: patch
> User: debian-m...@lists.debian.org
> Usertags: mips
> 
> Hello!
> 
> I just bootstrapped fpc for mips. In order for the build to work the next
> time the buildds are building it, the debian/fp-units-gfx.install.in
> needs to be adjusted so that usr/lib/fpc/*/*/*/graph* and
> usr/lib/fpc/*/*/*/opencl* aren't missing during dh_install.
> 
> Thus:
> 
> diff -Nru old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in 
> new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in
> --- old/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-04-09 
> 11:44:58.0 +0200
> +++ new/fpc-3.0.2+dfsg/debian/fp-units-gfx.install.in   2017-05-30 
> 23:44:24.519488161 +0200
> @@ -1,11 +1,11 @@
>  #! /usr/bin/dh-exec
>  usr/lib/fpc/*/*/*/ggi*
> -usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
> !linux-ppc64]
> +usr/lib/fpc/*/*/*/graph*[!linux-arm64 !linux-armel !linux-armhf 
> !linux-mips !linux-ppc64]

While we're here, could we add mipsel to the list as well? For most
purposes it can be treated identically to mips.

And thanks for working on fpc for mips!

James



signature.asc
Description: OpenPGP digital signature

Bug#863719: ITP: gerbera -- UPnP Media Server

[James Cowgill]

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

* Package name: gerbera
  Version : 1.0.0
  Upstream Author : Ian Whyman <thev00...@gentoo.org>
* URL : https://gerbera.io/
* License : GPL-2
  Programming Lang: C++
  Description : UPnP Media Server

Gerbera is a UPnP media server, originally based on MediaTomb, which
allows you to stream your digital media through your home network and
consume it on a variety of UPnP compatible devices.

This package is intended to replace MediaTomb which has been abandoned
upstream. I intend to package this as part of the Debian Multimedia  Team.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#863653: easytag: I cannot batch remove images from id3tag

[James Cowgill]

Hi,

On 29/05/17 20:20, max wrote:
> Package: easytag
> Version: 2.4.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I try to batch remove all images from id3tag selecting all files
> list then remove Images. Unfortunately only the first file
> selected results without images.

On the toolbar at the bottom of the images tag there are 5 buttons. The
button on the far right is "Tag selected files with these images". Did
you press that button before saving all the files?

James



signature.asc
Description: OpenPGP digital signature

Bug#863483: kodi: Provide polkit file for shutdown actions for kodi-standalone

[James Cowgill]

Hi,

On 27/05/17 16:45, Sebastian Bachmann wrote:
> Source: kodi
> Version: 2:17.1+dfsg1-3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> to use kodi-standalone to a full extend, one need to add a polkit file to 
> allow
> the kodi user to shutdown the machine.
> As the systemd service is also provided by the package, I think it would be 
> good
> to provide this file as well or note it in the README (I was not able to find
> it).
> 
> The content of the file /etc/polkit-1/localauthority/50-local.d/kodi.pkla
> should look like this:
> 
> [kodi user]
> Identity=unix-user:kodi
> Action=org.freedesktop.login1.*
> ResultAny=yes
> ResultInactive=no
> ResultActive=yes

Allowing the 'org.freedesktop.login1.*' action is probably too much,
since that also allows the kodi user to do some things which only root
should be able to do (like killing other sessions/users).

James



signature.asc
Description: OpenPGP digital signature

Bug#863420: timemachine: segfaults on startup

[James Cowgill]

Hi Chris,

On 27/05/17 10:02, Chris Lamb wrote:
> tags 863420 + pending patch
> thanks
> 
> I've uploaded timemachine 0.3.3-2.1 to DELAYED/5:
>   
>   timemachine (0.3.3-2.1) unstable; urgency=medium
>   
> * Non-maintainer upload.
> * Fix segmentation fault caused by passing a truncated pointer instead of 
> a
>   GtkType. (Closes: #863420)
> 
> The full debdiff is attached.

I tested your fixes, unfortunately timemachine still segfaults on
startup. This time it occurs in gtk_meterscale_new and it looks like the
same pointer truncation problem there. I notice this code is in jackeq
as well, but maybe jackeq doesn't use it on startup?

James

Bug#863416: jackeq: segmentation fault

[James Cowgill]

Control: clone -1 -2
Control: reassign -2 timemachine 0.3.3-2
Control: retitle -2 timemachine: segfaults on startup
Control: clone -1 -3
Control: reassign -3 kluppe 0.6.20-1
Control: retitle -3 kluppe: segfaults when pressing 'new looper'

Hi again,

On 26/05/17 16:42, James Cowgill wrote:
> On 26/05/17 16:30, James Cowgill wrote:
>> On 26/05/17 16:01, Alex Wilk wrote:
>>> Package: jackeq
>>> Version: 0.5.9-2+b2
>>> Severity: normal
>>>
>>> Dear Maintainer!
>>>
>>> ,
>>> | $ jackeq 
>>> | jackEQ 0.5.9
>>> | (c) 2003 - 2009 P. Shirkey
>>> | Featuring the DJEQ ladspa plugin by S. Harris
>>> | With assistance from J. O'Quin on the awesome Jack i/o dropdown menu
>>> | This is free software, and you are welcome to redistribute it
>>> | under certain conditions; see the file COPYING for details.
>>> | Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve 
>>> property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
>>> value "((GString*) 0x55e8dc961840)" of type `gboolean'
>>> | zsh: segmentation fault  jackeq
>>> `
>>
>> Unfortunately I cannot get jackeq to start at all so I'm raising the
>> severity.
>>
>> From a brief look in gdb, it seems that jackeq passes gtk a truncated
>> pointer. I expect this was triggered by the recent PIE rebuild exposing
>> the fact that jackeq is not 64-bit clean.
> 
> So the bug is in src/gtkmeter.c, where gtk_meter_get_type returns an
> unsigned int instead of a pointer. This code looked _very_ familiar
> because the exact same code has already been fixed in jamin! See #848672
> 
> Compare jamin from jessie with jackeq from stretch:
> https://sources.debian.net/src/jamin/0.97.14~cvs~81203-4/src/gtkmeter.c/
> https://sources.debian.net/src/jackeq/0.5.9-2/src/gtkmeter.c/
> 
> Code search:
> https://codesearch.debian.net/search?q=gtk_meter_get_type
> 
> So probably kluppe and timemachine are affected as well.

I've tested both kluppe and timemachine and they both segfault in
exactly the same place.

Kluppe segfaults when pressing "new looper" in the interface. Since this
seems to be a pretty critical feature of kluppe, I've kept the bug at
grave severity.

Timemachine just segfaults on startup like jackeq does.

Note you need a jack server running to reproduce both of these bugs.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#863416: jackeq: segmentation fault

[James Cowgill]

On 26/05/17 16:30, James Cowgill wrote:
> Control: severity -1 grave
> 
> Hi
> 
> On 26/05/17 16:01, Alex Wilk wrote:
>> Package: jackeq
>> Version: 0.5.9-2+b2
>> Severity: normal
>>
>> Dear Maintainer!
>>
>> ,
>> | $ jackeq 
>> | jackEQ 0.5.9
>> | (c) 2003 - 2009 P. Shirkey
>> | Featuring the DJEQ ladspa plugin by S. Harris
>> | With assistance from J. O'Quin on the awesome Jack i/o dropdown menu
>> | This is free software, and you are welcome to redistribute it
>> | under certain conditions; see the file COPYING for details.
>> | Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve 
>> property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
>> value "((GString*) 0x55e8dc961840)" of type `gboolean'
>> | zsh: segmentation fault  jackeq
>> `
> 
> Unfortunately I cannot get jackeq to start at all so I'm raising the
> severity.
> 
> From a brief look in gdb, it seems that jackeq passes gtk a truncated
> pointer. I expect this was triggered by the recent PIE rebuild exposing
> the fact that jackeq is not 64-bit clean.

So the bug is in src/gtkmeter.c, where gtk_meter_get_type returns an
unsigned int instead of a pointer. This code looked _very_ familiar
because the exact same code has already been fixed in jamin! See #848672

Compare jamin from jessie with jackeq from stretch:
https://sources.debian.net/src/jamin/0.97.14~cvs~81203-4/src/gtkmeter.c/
https://sources.debian.net/src/jackeq/0.5.9-2/src/gtkmeter.c/

Code search:
https://codesearch.debian.net/search?q=gtk_meter_get_type

So probably kluppe and timemachine are affected as well.

*sighs at code duplication*

James



signature.asc
Description: OpenPGP digital signature

Bug#863416: jackeq: segmentation fault

[James Cowgill]

Control: severity -1 grave

Hi

On 26/05/17 16:01, Alex Wilk wrote:
> Package: jackeq
> Version: 0.5.9-2+b2
> Severity: normal
> 
> Dear Maintainer!
> 
> ,
> | $ jackeq 
> | jackEQ 0.5.9
> | (c) 2003 - 2009 P. Shirkey
> | Featuring the DJEQ ladspa plugin by S. Harris
> | With assistance from J. O'Quin on the awesome Jack i/o dropdown menu
> | This is free software, and you are welcome to redistribute it
> | under certain conditions; see the file COPYING for details.
> | Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve 
> property `gtk-primary-button-warps-slider' of type `gboolean' from rc file 
> value "((GString*) 0x55e8dc961840)" of type `gboolean'
> | zsh: segmentation fault  jackeq
> `

Unfortunately I cannot get jackeq to start at all so I'm raising the
severity.

From a brief look in gdb, it seems that jackeq passes gtk a truncated
pointer. I expect this was triggered by the recent PIE rebuild exposing
the fact that jackeq is not 64-bit clean.

Thanks for the report!
James



signature.asc
Description: OpenPGP digital signature

Bug#863055: opendkim: forcefully removes conffile on upgrade

[James Cowgill]

Package: opendkim
Version: 2.11.0~alpha-9
Severity: serious
Justification: Policy 10.7.3

Hi,

opendkim.postinst contains this:
> # Upgrade /etc/default to systemd override files
> if [ -d /run/systemd/system ] && [ -f /etc/default/opendkim ]; then
> if /lib/opendkim/opendkim.service.generate; then
> rm -f /etc/default/opendkim
> fi

This will forcefully remove /etc/default/opendkim on upgrade and erase
any changes the user made without saving them anywhere, therefore
violating policy 10.7.3. Instead of removing the file, it should be
moved and then cleaned up on purge.

--

On a related note: I suspect the above code will break if the user ever
decides to switch to a different init system while opendkim is installed.

> if [ -f /etc/tmpfiles.d/opendkim.conf ]; then
> systemd-tmpfiles --create 
> /etc/tmpfiles.d/opendkim.conf
> fi

I haven't tested anything, but I am wondering if this is subtly broken
in the case where the generated $RUNDIR == /var/run/opendkim but $USER
is different. dh_installinit inserts a call to systemd-tmpfiles for the
file in /usr/lib/... which will override whatever is done here in that case.

Thanks,
James



signature.asc
Description: OpenPGP digital signature