Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 22:34, Christian Seiler wrote:
> On 12/06/2016 11:22 PM, James Cowgill wrote:
>> The version number should be the version number immediately before the
>> one where the dpkg-maintscript stuff is added, not when the symlink was
>> converted to a directory.
>>
>> In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
>> in 1.95-4.8-2).
> 
> I wouldn't use that version if you ever want to backport that specific
> version of the package, it's better to specify the previous Debian
> version directly, in this case 1.95-4.8-1.

There is actually a section in dpkg-maintscript-helper(1) about why this
is a bad idea (it breaks local builds or anyone else who manually
patched your package).

Note that 1.95-4.8-2~ sorts before 1.95-4.8-2~deb8+1 anyway so there is
no issue with backports here.

James



signature.asc
Description: OpenPGP digital signature

Bug#847234: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 21:36, Andreas Tille wrote:
> On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
>> Package: r-cran-rcurl
>> Version: 1.95-4.8-1
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> ...
>> >From the attached log (usually somewhere in the middle...):
>>
>> 2m19.9s INFO: dirname part contains a symlink:
>>   /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>>   /usr/lib/R/site-library/RCurl/examples/CIS/cis.R (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS/cis.R (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>> ...
> 
> I tried to fix this the following way.  In the Jessie package
> r-cran-rcurl_1.95-4.3-1+deb8u1_amd64.deb the examples link is:
> 
> 
> $ readlink /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples
> 
> 
> Since in the package in unstable examples is a directory I tried
> to fix the upgrade path by
> 
> 
> $ cat debian/maintscript
> symlink_to_dir /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples 1.95-4.3-1

The version number should be the version number immediately before the
one where the dpkg-maintscript stuff is added, not when the symlink was
converted to a directory.

In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
in 1.95-4.8-2).

See dpkg-maintscript-helper(1) prior-version section.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#847001: nmu: libjack dependencies using new port_rename APIs

[James Cowgill]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
X-Debbugs-CC: pkg-multimedia-maintain...@lists.alioth.debian.org

Hi,

In #845654 and #845655, the dependencies generated by libjack were
tightened after a new API was added to both jack implementations. The
packages which use the new API need to be binNMUed to get the new
dependency. I checked codesearch for packages using the affected
functions (jack_set_port_rename_callback and jack_port_rename) and
these were the only 3 packages affected. I already knew about hydrogen
and libsoundio though.

ardour and hydrogen need to wait for the new libjack-dev to be
installed, while libsoundio needs to wait for the new
libjack-jackd2-dev.

Does this seem right?

nmu ardour_1:5.4.0~dfsg-2 . ANY . unstable . -m "rebuild for tighter libjack 
dependency"
nmu hydrogen_0.9.7-1 . ANY . unstable . -m "rebuild for tighter libjack 
dependency"
nmu libsoundio_1.0.2-1 . ANY . unstable . -m "rebuild for tighter libjack 
dependency"

dw ardour_1:5.4.0~dfsg-2 . ANY . unstable . -m 'libjack-dev (>= 1:0.125.0-2)'
dw hydrogen_0.9.7-1 . ANY . unstable . -m 'libjack-dev (>= 1:0.125.0-2)'
dw libsoundio_1.0.2-1 . ANY . unstable . -m 'libjack-jackd2-dev (>= 
1.9.10+20150825git1ed50c92~dfsg-4)'

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#846980: python-jack-client: incorrect libjack dependency

[James Cowgill]

Package: python-jack-client
Version: 2.0.3+dfsg1-2
Severity: important

Hi,

python-jack-client and python3-jack-client have a direct dependency on
libjack0. This is incorrect since there are two implementations of
libjack and this dependency will only satisfy one of them.

The current jack dependency is currently:
libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125

James



signature.asc
Description: OpenPGP digital signature

Bug#654537: jack-a-c-k: stub atomicity functions used when machdep ones are available

[James Cowgill]

Version: 1:0.125.0-1

On Wed, 4 Jan 2012 00:39:03 + (UTC) Thorsten Glaser  wrote:
> Source: jack-audio-connection-kit
> Version: 0.121.0+svn4538-3
> Severity: minor
> Tags: upstream
> 
> On m68k, I get these warnings during compilation:
> 
> ../config/cpu/generic/atomicity.h:23:2: warning: #warning "stub atomicity 
> functions are not atomic on this platform" [-Wcpp]
> 
> However, there's a config/cpu/m68k/atomicity.h available,
> the config/sysdeps/atomicity.h just doesn't pick it up.

As of jack 0.125.0, the generic atomic functions are implemented using
GCC intrinsics so there isn't really a bug here anymore.

I have also filed this upstream bug about removing all the unused
platform specific code:
https://github.com/jackaudio/jack1/issues/56

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842702: zabbix: CVE-2016-9140: API JSON-RPC remote code execution

[James Cowgill]

Hi,

On Sun, 13 Nov 2016 21:23:30 +0100 Salvatore Bonaccorso  
wrote:
> On Sun, Nov 13, 2016 at 09:00:58PM +0100, Salvatore Bonaccorso wrote:
> > I'm not sure the subject is correct in stating that versions only
> > below 3.0.3 are affected. Looking from the changes in api_jsonrpc.php
> > it does not look yet fixed. Can you confirm?
> > 
> > Is upstream actually aware of the issue? Is a fix available?
> 
> From a quick test on a unstable vm this seem still the case for the
> current unstable version.

https://support.zabbix.com/browse/ZBX-11483
Quote from richlv (upstream):
> doesn't look like it - the exploit-db example logs in as Admin, then
> does script.update, followed by script.execute - it does not connect to
> the trapper port directly but goes through the frontend.
> 
> that looks like somebody with the superadmin rights using a feature as
> intended... not sure anything can/should be done about it.

Similarly, I'm not convinced there's a bug here at all.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841173: openjdk-9: FTBFS on mips*

[James Cowgill]

Control: forwarded -1 https://bugs.openjdk.java.net/browse/JDK-8170639

On 29/11/16 14:44, Matthias Klose wrote:
> Please can you forward the issue upstream?

So as discussed upstream, this won't make it into OpenJDK 9 so can the
patch be applied directly to Debian instead?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#846266: solid: FTBFS on mipsel and m68k - src/solid/predicate_parser.c: No such file or directory

[James Cowgill]

Source: solid
Version: 5.28.0-1
Severity: serious
Tags: patch

Hi,

So I've had a look at the mips FTBFS, and while I have not been able to
reproduce it there does seem to be a parallel build race going on with
the bison/flex parser generation.

In src/solid/CMakeLists.txt, the parser is generated using bison_target
which uses add_custom_command under the hood. The output file is then
added to the list of sources creating a file-level dependency from the
KF5Solid target to the bison/flex generation command. However, the list
of sources is later used as part of the KF5Solid_static target. Since
file-level dependencies cannot cross between targets, the bison
generation happens twice completely independently as part of the two
targets. If you are very unlucky, the generation in one target can
happen at the same time as the compilation of the parser in the other
target causing a collision.

The attached patch should fix that by putting the generation in a
separate target and manually adding a dependency on it. This forces the
parser to be generated before anything is compiled.

As a side node, there seems to be a bug in CMake 3.7.0 which causes
bison targets to be remade repeatedly, but it looks like it'll be fixed
in 3.7.1.

Thanks,
James
--- a/src/solid/CMakeLists.txt
+++ b/src/solid/CMakeLists.txt
@@ -9,6 +9,7 @@ endif()
 set(solid_LIB_SRCS ${solid_LIB_SRCS} ${solid_QM_LOADER})
 
 add_library(KF5Solid  ${solid_LIB_SRCS})
+add_dependencies(KF5Solid SolidParserTarget)
 target_include_directories(KF5Solid PUBLIC "$")
 generate_export_header(KF5Solid BASE_NAME Solid)
 add_library(KF5::Solid ALIAS KF5Solid)
@@ -87,6 +88,7 @@ install(TARGETS KF5Solid EXPORT KF5SolidTargets ${KF5_INSTALL_TARGETS_DEFAULT_AR
 ### static lib for tests  ###
 
 add_library(KF5Solid_static STATIC ${solid_LIB_SRCS})
+add_dependencies(KF5Solid_static SolidParserTarget)
 set_target_properties(KF5Solid_static PROPERTIES COMPILE_FLAGS -DSOLID_STATIC_DEFINE=1)
 
 target_link_libraries(KF5Solid_static PUBLIC Qt5::Core)
diff --git a/src/solid/devices/CMakeLists.txt b/src/solid/devices/CMakeLists.txt
index b841b54..a020825 100644
--- a/src/solid/devices/CMakeLists.txt
+++ b/src/solid/devices/CMakeLists.txt
@@ -90,6 +90,7 @@ flex_target(SolidLexer
 )
 add_flex_bison_dependency(SolidLexer SolidParser)
 list(APPEND solid_LIB_SRCS ${BISON_SolidParser_OUTPUTS} ${FLEX_SolidLexer_OUTPUTS})
+add_custom_target(SolidParserTarget DEPENDS ${BISON_SolidParser_OUTPUTS} ${FLEX_SolidLexer_OUTPUTS})
 
 include(devices/backends/fakehw/CMakeLists.txt)
 


signature.asc
Description: OpenPGP digital signature

Bug#846084: qemu-user-static: mips bigendian netlink is broken

[James Cowgill]

Package: qemu-user-static
Version: 1:2.7+dfsg-3
Severity: normal
Forwarded: https://bugs.launchpad.net/qemu/+bug/1643619

Hi,

I am filing this because I want a Debian bug number - I have already
forwarded it upstream and done a small amount of investigation into it.

When attempting to qemu debootstrap a mips big-endian chroot,
debootstrap fails to configure systemd. This is because netlink on
qemu-user mips is broken - a request is made to the kernel which never
replies.

I did some investigation and it seems that the netlink requests are all
byteswapped and the kernel ignores them (presumably because they contain
garbage). I suspect this also affects other big-endian architectures but
I have not checked.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#845654: libjack0: generated dependencies not tight enough for jack_port_rename

[James Cowgill]

Package: libjack0
Version: 1:0.125.0-1
Severity: serious
Control: clone -1 -2
Control: reassign -2 libjack-jackd2-0 1.9.10+20150825git1ed50c92~dfsg-1
Control: retitle -2 libjack-jackd2-0: generated dependencies not tight enough 
for jack_port_rename

Hi,

The shlib dependencies generated by libjack0 are not tight enough for
packages which use the jack_port_rename API from jack 0.125.0. I've
just seen this when trying to run the new (not yet in unstable) version
of hydrogen on an older system.

Packages using jack_port_rename still get a dependency like:
libjack-jackd2-0 (>= 1.9.5~dfsg-14) | libjack-0.116

If an old libjack (eg from jessie) is installed, reverse dependencies
fail with:
undefined symbol: jack_port_rename

Bumping the version of libjack-jackd2-0 is easy, but bumping
libjack-0.116 is not because it's a virtual package. I think we could
either used versioned provides or have libjack0 provide an two virtual
packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#834135: mplayer crashes with SIGSEGV when taking a screenshot

[James Cowgill]

Control: tags -1 patch fixed-upstream

On 24/11/16 21:52, Antonio Ospite wrote:
> Package: mplayer
> Version: 2:1.3.0-5
> Followup-For: Bug #834135
> 
> Dear Maintainer,
> 
> the crash when taking screenshots is still there in 2:1.3.0-5.
> 
> The patch in my previous message fixes it, please consider applying it.

For reference, the patch was applied to upstream SVN in revision 37875.

James



signature.asc
Description: OpenPGP digital signature

Bug#845317: #845317 bzflag: please make the build reproducible

[James Cowgill]

On 22/11/16 15:30, Alexandre Detiste wrote:
>  Hi,
> 
> I tought this previous change would had been enough
> to make the build reproducible (2016-03-13).
> 
> These Makefiles seems to be installed anyway.
> 
> https://anonscm.debian.org/cgit/pkg-games/bzflag.git/commit/debian/bzflag-data.install?id=bf256e7b9504df17fc3d47d1d083788ad40c8bfe
> 
> --- a/debian/bzflag-data.install
> +++ b/debian/bzflag-data.install
> @@ -1,3 +1,6 @@
> data/[!CM]* usr/share/games/bzflag/

This line will install the entire l10n and fonts directories including
the makefiles.

James



signature.asc
Description: OpenPGP digital signature

Bug#845271: libdvdread: CHECK_VALUE failed in src/ifo_read.c:1675

[James Cowgill]

Control: reassign libdvdread4 5.0.3-2

Hi,

On 21/11/16 23:10, shirish शिरीष wrote:
> Source: libdvdread
> Severity: normal

[I have assumed you're running testing when fixing up the headers]

> Dear Maintainer,
> I was trying to play a movie. I have filed it under libdvdread as I'm
> unsure whether it's libdvdnav or libdvdread which is at fault.
> 
> The media is in conventional VIDEO_TS directory with the following
> directory structure -
> 
> [$] ls
> 
> VIDEO_TS.BUP  VIDEO_TS.IFO  VIDEO_TS.VOB  VTS_01_0.BUP  VTS_01_0.IFO
> VTS_01_1.VOB  VTS_01_2.VOB  VTS_01_3.VOB
> 
> Whenever I run the above, I get the following statements dumped on the screen 
> -
> 
> AV: 00:02:39 / 01:26:44 (3%) A-V:  0.000
> *** libdvdread: CHECK_VALUE failed in src/nav_read.c:264 ***
> *** for dsi->dsi_gi.zero1 == 0 ***

Usually a CHECK_VALUE failed means the DVD is corrupt or burned
incorrectly. Here 'dsi_gi.zero1' is a reserved field and should always
be 0. If only this DVD gives this error, then it's probably the DVD
that's at fault.

James



signature.asc
Description: OpenPGP digital signature

Bug#828545: simutrans: FTBFS with openssl 1.1.0

[James Cowgill]

On 19/11/16 14:04, Jörg Frings-Fürst wrote:
> severity 828353 important
> unblock 827061 by 828353
> thanks
> 
> we removed all openssl dependnecy so I'm downgrading and unblock this
> bug.

I disagree. The version of simutrans in testing is still RC-buggy so
this bug should still be severity serious.

James



signature.asc
Description: OpenPGP digital signature

Bug#841183: dvbcut: mplayer2 has gone away

[James Cowgill]

On 18/11/16 17:24, Bernhard Übelacker wrote:
> Am 18.11.2016 um 18:08 schrieb James Cowgill:
>> On 18/11/16 14:28, Bernhard Übelacker wrote:
>>> Hello James,
>>> sorry for the late reply.
>>>
>>> I prepared a new version removing mplayer2 and opened a RFS in [1].
>>
>> Why did you remove mpv?
> 
> Hello James,
> because currently dvbcut executes just plain "mplayer".
> And as far as I see mpv does not provide a binary with that name.
> 
> The recommends mpv seems as it was already useless for Jessie (except
> the user manually created a link from mplayer to mpv).

Ok that makes sense.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841183: dvbcut: mplayer2 has gone away

[James Cowgill]

On 18/11/16 14:28, Bernhard Übelacker wrote:
> Hello James,
> sorry for the late reply.
> 
> I prepared a new version removing mplayer2 and opened a RFS in [1].

Why did you remove mpv?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'

[James Cowgill]

Control: reassign -1 binutils 2.25-5
Control: severity -1 important
Control: affects -1 src:fracplanet
Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol 
table

Hi,

On 14/11/16 19:08, Adrian Bunk wrote:
> Package: fracplanet
> Version: 0.4.0-5
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=fracplanet=sid
> 
> g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet 
> obj/common.o obj/control.o obj/control_about.o obj/control_render.o 
> obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o 
> obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o 
> obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o 
> obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o 
> obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o 
> obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o 
> obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o 
> obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o 
> obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o 
> obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o 
> obj/moc_control_terrain.o obj/moc_dialog_documentation.o 
> obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang
>  le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib 
> -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
> /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd'
> 
> 
> Michael Biebl mentioned #844227 on IRC, are these bugs coincidence,
> or is there something that broke/changed in Mesa on mips* recently?

Looking at this a bit closer, it appears to be a longstanding binutils
bug which was recently made worse due to a change in counting local
symbols.

Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the
first (long standing) bug:

$ readelf --syms libGL.so.1 | head -n15
Symbol table '.dynsym' contains 1559 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1: 000163c0 0 SECTION LOCAL  DEFAULT   10
 2: 000902a8 0 SECTION LOCAL  DEFAULT   16
 3: 0007264052 FUNCGLOBAL DEFAULT   11 
glCheckFramebufferStatusE
 4: 0006c47052 FUNCGLOBAL DEFAULT   11 glConvolutionFilter1D
 5: 0007219828 FUNCGLOBAL DEFAULT   11 glVertexAttrib3fvARB
 6: 0006b73052 FUNCGLOBAL DEFAULT   11 glLoadMatrixd
 7: 000943d0 0 NOTYPE  LOCAL  DEFAULT   24 _fbss
 8: 0006c6a052 FUNCGLOBAL DEFAULT   11 
glGetConvolutionParameter
 9: 0006973052 FUNCGLOBAL DEFAULT   11 glVertex4i
10: 0006ebe052 FUNCGLOBAL DEFAULT   11 
glGetBufferPointervARB
11: 0006e3d828 FUNCGLOBAL DEFAULT   11 glWindowPos2f

Here the _fbss symbol is LOCAL which is prohibited by the ELF standard
which requires all LOCAL symbols to precede GLOBAL symbols. This bug is
definitely present in jessie's binutils, because jessie's libGL also
has a symbol table similar to this. Wheezy's mesa doesn't have this bug
but I don't know if binutils definitely doesn't have it in wheezy.

Ordinarily this wasn't much of an issue since glibc and ld would just
skip LOCAL symbols when processing the symbol tables. However somewhere
between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for
calculating the 'st_info' field for the .dynsym section header changed.
Recompiling mesa with both versions of binutils gives identical libGL
binaries except for this difference in the section header:

diffoscope output (- 2.27-9, + 2.27.51.20161108-1):
│ -  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   3  8
│ +  [ 5] .dynsym   DYNSYM  2e40 002e40 009228 18   
A  6   9  8

Here 3 = the index of the first non-global symbol, and 9 = the total
number of local symbols. These values should of course be equal if the
rules about symbol ordering were followed. ld uses the value of the
'st_info' field to skip LOCAL symbols when linking, which explains why
only the 5 symbols from 3-8 in the above symbol table cause link errors.

I'm still investigating, but getting a reduced testcase is quite tricky
and recompiling mesa on mips takes about an hour.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#844464: kodi: FTBFS on mips(el): undefined gl* and egl* symbols

[James Cowgill]

On 16/11/16 03:39, Aaron M. Ucko wrote:
> Source: kodi
> Version: 17.0~beta5+dfsg1-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> The mips and mipsel builds of kodi failed with undefined references to
> gl* and egl* symbols, per the log excerpt below.  Could you please
> take a look?

FYI I am aware of this (with many packages affected) and it looks like
it's probably a toolchain issue but I'll let you know once I've
investigated it.

James



signature.asc
Description: OpenPGP digital signature

Bug#819755: qemu-user-static: "Temporary failure in name resolution" with qemu-{mips, mipsel, s390x}-static

[James Cowgill]

Control: tags -1 patch fixed-upstream

On Fri, 01 Apr 2016 23:28:35 +0200 Luca Falavigna  wrote:
> Package: qemu-user-static
> Version: 1:2.5+dfsg-5
> Severity: important
> 
> Dear Maintainer,
> 
> I just created a fresh mips schroot using qemu-debootstrap to emulate mips
> architecture.
> 
> Unfortunately, I cannot resolve any name because it seems DNS resolution is 
> not
> working anymore. Attached is strace log of a simple ping against 
> ftp.debian.org
> 
> This behaviour happens at least under mips, mipsel and s390x.

For mips, this has been fixed by upstream commit
2e6eeb67429a7e0683d3d1a75ca497dd67c751e4 which I have attached. It's
present in the master branch, but not in any stable branches (note I am
not that familiar with upstream qemu development).

glibc in stretch uses the sendmmsg syscall when doing DNS lookups which
was not wired up correctly in qemu.

Thanks,
James
From 2e6eeb67429a7e0683d3d1a75ca497dd67c751e4 Mon Sep 17 00:00:00 2001
From: Aleksandar Markovic 
Date: Wed, 12 Oct 2016 14:30:22 +0200
Subject: [PATCH] linux-user: Update mips_syscall_args[] array in main.c

Array mips_syscall_args[] determines number of arguments for each
syscall on Mips32. It wasn't updated with newer syscalls. Also,
preadv and pwritev have 5 arguments, not 6.

Signed-off-by: Aleksandar Markovic 
Signed-off-by: Riku Voipio 
---
 linux-user/main.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 0e31dad..18d5a62 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2295,8 +2295,8 @@ static const uint8_t mips_syscall_args[] = {
 MIPS_SYS(sys_dup3, 3)
 MIPS_SYS(sys_pipe2, 2)
 MIPS_SYS(sys_inotify_init1, 1)
-MIPS_SYS(sys_preadv, 6) /* 4330 */
-MIPS_SYS(sys_pwritev, 6)
+MIPS_SYS(sys_preadv, 5) /* 4330 */
+MIPS_SYS(sys_pwritev, 5)
 MIPS_SYS(sys_rt_tgsigqueueinfo, 4)
 MIPS_SYS(sys_perf_event_open, 5)
 MIPS_SYS(sys_accept4, 4)
@@ -2308,6 +2308,26 @@ static const uint8_t mips_syscall_args[] = {
 MIPS_SYS(sys_open_by_handle_at, 3) /* 4340 */
 MIPS_SYS(sys_clock_adjtime, 2)
 MIPS_SYS(sys_syncfs, 1)
+MIPS_SYS(sys_sendmmsg, 4)
+MIPS_SYS(sys_setns, 2)
+MIPS_SYS(sys_process_vm_readv, 6) /* 345 */
+MIPS_SYS(sys_process_vm_writev, 6)
+MIPS_SYS(sys_kcmp, 5)
+MIPS_SYS(sys_finit_module, 3)
+MIPS_SYS(sys_sched_setattr, 2)
+MIPS_SYS(sys_sched_getattr, 3)  /* 350 */
+MIPS_SYS(sys_renameat2, 5)
+MIPS_SYS(sys_seccomp, 3)
+MIPS_SYS(sys_getrandom, 3)
+MIPS_SYS(sys_memfd_create, 2)
+MIPS_SYS(sys_bpf, 3)/* 355 */
+MIPS_SYS(sys_execveat, 5)
+MIPS_SYS(sys_userfaultfd, 1)
+MIPS_SYS(sys_membarrier, 2)
+MIPS_SYS(sys_mlock2, 3)
+MIPS_SYS(sys_copy_file_range, 6) /* 360 */
+MIPS_SYS(sys_preadv2, 6)
+MIPS_SYS(sys_pwritev2, 6)
 };
 #  undef MIPS_SYS
 # endif /* O32 */
-- 
2.10.2



signature.asc
Description: OpenPGP digital signature

Bug#836454: texlive-binaries: xetex produces bad dvi at MIPS

[James Cowgill]

Hi,

On 13/11/16 13:59, Norbert Preining wrote:
>> I can upload a new package that reverts these changes, or prepare a new
>> package and we try to build it on mips/mipsel Debian builder machines.
> 
> Here is a source package and binaries of amd64
> 
> deb http://people.debian.org/~preining/TeX/ bin/
> deb-src http://people.debian.org/~preining/TeX/ bin/
> 
> Version is -8
> 
> If anyone feels advanterous to test this I would be happy.

I've tried building it on mips and mipsel and it builds fine.

> For someone that can also access s390 it would be nice if we
> can remove the case for s390 in the rules file (-O1), too,
> but that needs also testing.

I haven't tried it, but there is a s390x porterbox you could use:
zelenka.debian.org.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#629107: hydrogen: No text in User Manual

[James Cowgill]

Hi,

On 13/11/16 18:29, treb...@tuxfamily.org wrote:
> Le 2016-11-13 11:55, James Cowgill a écrit :
>> On 12/11/16 11:41, Jaromír Mikeš wrote:
>>> I know about this bug and I am not ignoring it.
>>> I already tried fix it in past without success :(
>>> Hopefully some more skilled mate from team will give a hand with it.
>>
>> How about the attached patch?
>>
>> I think the original purpose of that code in debian/rules was to force
>> the manual to always be rebuilt. Unfortunately it moves 'manual.docbook'
>> out of the way (as if it was autogenerated) but it looks like this is
>> the master manual which is directly edited.
>>
>> My alternate implementation simply touches the master manuals which
>> should hopefully force everything to be rebuilt as well.
>>
>> Thanks,
>> James
> 
> Hi James,
> 
> and thanks for this patch which definitely move forward. Thanks ! (If you'd
> know the number of times I prayed for this bug to be fixed)
> 
> I tried a rebuild at home on a Debian Jessie + 0.9.7 version with this
> added.
> And I made one qt4 build and one qt5 build.
> 
> The outcome is that when going to : hydrogen menu -> Info -> User
> manual, I've got
> the user manuel (in English whatever the language I'm using).
> If I then click on "Documentation index" with I expect to show me this :
> https://cloud.githubusercontent.com/assets/8705846/17536586/4797c9fc-5e96-11e6-91fb-ad40223b4fcf.png
> 
> But it doesn't.
> 
> James, Jaromir, others, any idea ?

Where is the source for that documentation index?

If I grep the hydrogen sources, I can't find the strings from that
image. I also tried building upstream git master and the index doesn't
work for me there either.

James



signature.asc
Description: OpenPGP digital signature

Bug#629107: hydrogen: No text in User Manual (Was: hydrogen packaging)

[James Cowgill]

Control: tags -1 patch

Hi,

On 12/11/16 11:41, Jaromír Mikeš wrote:
> 2016-11-12 11:58 GMT+01:00  :
> 
>> while you're working around the Hydrogen packaging, can I humbly
>> ask you to have a look at this bug :
>> https://bugs.debian.org/629107 ?
>>
>> There is willingness upstream (which I'm part of regarding the
>> manual) to update and improve the bundled update manual and not
>> having it displayed/accessible in the GUI is frustrating.
>>
>> As said in bug 629107, I've been looking at it but am not
>> knowledgeable/competent to resolve it. Help here would be
>> appreciated.
> 
> Hi Olivier,
> 
> I know about this bug and I am not ignoring it.
> I already tried fix it in past without success :(
> Hopefully some more skilled mate from team will give a hand with it.

How about the attached patch?

I think the original purpose of that code in debian/rules was to force
the manual to always be rebuilt. Unfortunately it moves 'manual.docbook'
out of the way (as if it was autogenerated) but it looks like this is
the master manual which is directly edited.

My alternate implementation simply touches the master manuals which
should hopefully force everything to be rebuilt as well.

Thanks,
James
--- a/debian/rules
+++ b/debian/rules
@@ -35,23 +35,9 @@ DEB_COPYRIGHT_CHECK_IGNORE_REGEX = ^.*\.(flac|png|qm)|debian/(changelog|copyrigh
 # according to upstream INSTALL.txt this avoids potential clash with Qt3
 export QTDIR=/usr/share/qt4
 
-# Put aside upstream-shipped autogenerated files during build
-upstreamtmpfiles = $(wildcard data/doc/*.html data/doc/*.docbook)
-upstreamtmpfiles_ = $(patsubst %.upstream,%,$(wildcard data/doc/*.html.upstream data/doc/*.docbook.upstream))
-pre-build:: debian/stamp-upstreamtmpstuff
-debian/stamp-upstreamtmpstuff: debian/stamp-copyright-check
-	for file in $(upstreamtmpfiles); do \
-		[ ! -e $$file ] || [ -e $$file.upstream ] || mv $$file $$file.upstream; \
-	done
-	touch $@
-clean::
-	for file in $(upstreamtmpfiles_); do \
-		[ ! -e $$file.upstream ] || mv -f $$file.upstream $$file; \
-	done
-	rm -f debian/stamp-upstreamtmpstuff
-
 common-build-indep:: debian/docs.stamp
 debian/docs.stamp:
+	touch data/doc/manual.docbook data/doc/tutorial.docbook
 	$(MAKE) -C data/doc
 	touch $@
 clean::


signature.asc
Description: OpenPGP digital signature

Bug#836454: texlive-binaries: xetex produces bad dvi at MIPS

[James Cowgill]

Hi,

On 10/11/16 15:22, Norbert Preining wrote:
> Hi James,
> 
>> BROKEN_ICU_ARCHS := mips mipsel sparc64
>>
>> [...]
>> # building on mips/sparc etc is somehow broken, try fix from tlbuild
>> # by setting U_IS_BIG_ENDIAN=0
>> ifneq (,$(findstring $(DEB_HOST_ARCH), $(BROKEN_ICU_ARCHS)))
>>   export CFLAGS += -DU_IS_BIG_ENDIAN=0
>>   export CXXFLAGS += -DU_IS_BIG_ENDIAN=0
>> else
>> endif
>>
>> But mips _is_ big endian so overriding U_IS_BIG_ENDIAN to 0 gives
>> completely wrong results.
> 
> Umpf, ok, seems like an overlap in the problems occurring in ICU
> and mips.
> 
> I would be *very* grateful if you could report about your
> experiences with building with removing mips(el) from the
> BROKEN_ICU_ARCHS and see if it works.

I've managed to build texlive-bin on mips and mipsel after removing them
from BROKEN_ICU_ARCHS. I ran the xetex testcase in this bugreport on
both arches and it seems to work fine.

Why was it originaly added?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#836454: texlive-binaries: xetex produces bad dvi at MIPS

[James Cowgill]

Hi,

I've been spending some time on this bug. I tried upstream xetex and it
worked fine on mips. I then stumbled upon the debian/rules file and the
bug now seems so blindingly obvious:

# architectures where icu related programs (xetex) have problems
# and core dump etc. Possible fix, but sub-optimal because slowing down
# programs
BROKEN_ICU_ARCHS := mips mipsel sparc64

[...]
# building on mips/sparc etc is somehow broken, try fix from tlbuild
# by setting U_IS_BIG_ENDIAN=0
ifneq (,$(findstring $(DEB_HOST_ARCH), $(BROKEN_ICU_ARCHS)))
  export CFLAGS += -DU_IS_BIG_ENDIAN=0
  export CXXFLAGS += -DU_IS_BIG_ENDIAN=0
else
endif

But mips _is_ big endian so overriding U_IS_BIG_ENDIAN to 0 gives
completely wrong results.

I'll do a rebuild later today and let you know how it goes.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#815409: qemu-img create -f qcow2 ... segfaults on mips

[James Cowgill]

Hi,

For the record, this bug is now fixed by linux 4.8[1] in unstable which
now emulates FPU branch delay slots using a per-thread page so the stack
is never executed.

Thanks,
James

[1] commit 432c6bacbd0c (MIPS: Use per-mm page to execute branch delay
slot instructions)



signature.asc
Description: OpenPGP digital signature

Bug#843632: RM: colobot [armhf mips mips64el mipsel] -- ROM; Now-enabled tests FTBFS

[James Cowgill]

Hi,

On 08/11/16 13:18, Didier 'OdyX' Raboud wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> As of 0.1.9-1, I have enabled building and running the unittests for
> colobot. The builds have revealed that the embedded hippomocks library
> doesn't support arm* or mips* (and probably, hasn't ever).

Did you intend to have arm64 removed as well (it's not in the bug title)?

> Please remove colobot from these architectures: armhf, mips, mips64el
> and mipsel from testing, so that colobot 0.1.9 can migrate to testing.
> 
> See the following discussions:
> - https://github.com/dascandy/hippomocks/issues/57 (arm64 support)
> - https://github.com/dascandy/hippomocks/pull/50 (mips support)
> - https://github.com/colobot/colobot/issues/853 (src:colobot FTBFS)

Do you object to disabling the tests on these architectures instead?
Hippomocks is only used if the testsuite is enabled.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843538: freeorion: enable on mips64el

[James Cowgill]

Hi,

On 07/11/16 16:14, Markus Koschany wrote:
> On 07.11.2016 16:17, James Cowgill wrote:
>> Source: freeorion
>> Version: 0.4.6-3
>> Severity: wishlist
>>
>> Hi,
>>
>> Please enable freeorion on mips64el. Unlike mips and mipsel it doesn't
>> suffer from the virtual memory limitations so it should build fine.
>>
>> Unfortunately there isn't a lot which can be done about the 32-bit mips
>> arches short of maybe disabling optimizations or messing about with some
>> gcc options to reduce memory usage (I have tried neither). It's an
>> architectural limitation, not a problem with the buildds.
> 
> Hi James,
> 
> I can enable mips64el when I package the next revision or Git snapshot.

Thanks.

> I have tried to build on mips and mipsel with "MinSizeRel" (-O0)
> optimization but it never really worked. The latest versions of
> FreeOrion require more than 4 GB of RAM and with less the build process
> becomes very slow due to swapping. The issue is somewhere in the
> ConditionParsers but I don't know how it can be optimized.

OK then. It's probably best to just leave mips and mipsel disabled until
someone can find out how to get it working.

James



signature.asc
Description: OpenPGP digital signature

Bug#843538: freeorion: enable on mips64el

[James Cowgill]

Source: freeorion
Version: 0.4.6-3
Severity: wishlist

Hi,

Please enable freeorion on mips64el. Unlike mips and mipsel it doesn't
suffer from the virtual memory limitations so it should build fine.

Unfortunately there isn't a lot which can be done about the 32-bit mips
arches short of maybe disabling optimizations or messing about with some
gcc options to reduce memory usage (I have tried neither). It's an
architectural limitation, not a problem with the buildds.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843032: qemu-user-static: Upgrade fails: unable to close /proc/sys/fs/binfmt_misc/register

[James Cowgill]

On Thu, 3 Nov 2016 13:15:47 +0300 Michael Tokarev  wrote:
> 03.11.2016 12:46, Toby Speight wrote:
> > I was able to work around this issue by hand-editing the postinst it to add
> > '|mips*' to the end of $omit (luckily, I don't need MIPS emulation on my
> > systems).
> > 
> > The one thing that stands out about the MIPS registration is that the magic
> > and mask are much longer than for other systems - is it possible that the
> > kernel can't handle such long patterns?  If so, can this be detected and
> > avoided?
> 
> This change was introduced very recently, see #829243.  But it works fine
> on my system.  I wonder if 3.16 kernel is unable to process that binfmt
> while 4.1+ can handle it...  Oh well.

Looks like this kernel commit added support for longer formats:
bbaecc088245e840e59a5abe23d69cf7748b3c88

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/binfmt_misc.c?id=bbaecc088245e840e59a5abe23d69cf7748b3c88

This is probably what causes this. The above commit exists only in 3.18+

James



signature.asc
Description: OpenPGP digital signature

Bug#843175: iio-sensor-proxy: file in non-standard top level directory: /rules.d

[James Cowgill]

Control: tags -1 - moreinfo

On 04/11/16 16:43, Ritesh Raj Sarraf wrote:
> Control: tag -1 +moreinfo
> 
> On Fri, 2016-11-04 at 15:25 +0000, James Cowgill wrote:
> 
>> iio-sensor-proxy installs the file:
>>  /rules.d/80-iio-sensor-proxy.rules
> 
> 
> You mean in /lib/udev/rules.d/ ? If so, I'm curious how that is a policy
> violation.
> 
> Otherwise, things looks fine to me.

It appears amd64 is fine, but all other arches are not.

https://buildd.debian.org/status/fetch.php?pkg=iio-sensor-proxy=i386=1.3-1=1474117505

> drwxr-xr-x root/root 0 2016-09-17 09:05 ./rules.d/
> -rw-r--r-- root/root   374 2016-09-17 09:05 
> ./rules.d/80-iio-sensor-proxy.rules

Lintian also reports this error:
https://lintian.debian.org/tags/non-standard-toplevel-dir.html

James



signature.asc
Description: OpenPGP digital signature

Bug#818239: ohcount-doc: creates non-FHS /ruby directory

[James Cowgill]

Control: found -1 3.0.0-8.2

Changelog:
>  ohcount (3.0.0-8.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Source-ful, binary-less upload to get rid of /ruby directory.
>  Probably somehow my fault? (Closes: #818239)

Apparently this didn't work.

See the arch:all build log:
https://buildd.debian.org/status/fetch.php?pkg=ohcount=all=3.0.0-8.2=1468796113

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843175: iio-sensor-proxy: file in non-standard top level directory: /rules.d

[James Cowgill]

Package: iio-sensor-proxy
Version: 1.3-1
Severity: serious
Justification: Policy 9.1

Hi,

iio-sensor-proxy installs the file:
 /rules.d/80-iio-sensor-proxy.rules

Since this file is in a non-standard top level directory, it is
prohibited by the FHS.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843169: xbmc-eventclients-j2me: uninstallable in unstable

[James Cowgill]

Package: xbmc-eventclients-j2me
Version: 17.0~beta5+dfsg1-1
Severity: serious
Tags: sid stretch

Hi,

The xbmc-eventclients-j2me cannot be installed in unstable.
The kodi-eventclients-j2me package does not exist.

$ sudo apt-get install -o Debug::pkgProblemResolver=true xbmc-eventclients-j2me
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) xbmc-eventclients-j2me:amd64 < none -> 2:17.0~beta5+dfsg1-1 
@un puN Ib >
Broken xbmc-eventclients-j2me:amd64 Depends on kodi-eventclients-j2me:amd64 < 
none @un H >
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 xbmc-eventclients-j2me : Depends: kodi-eventclients-j2me but it is not 
installable
E: Unable to correct problems, you have held broken packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843136: drumgizmo FTBFS on mips and mipsel: error: undefined reference to `__atomic_load_8'

[James Cowgill]

Hi,

On 04/11/16 08:51, Radovan Birdic wrote:
> Package drumgizmo_0.9.11-1 FTBFS on mips and mipsel with following error:
> 
>> plugingui-plugingui.o: In function `std::atomic::is_lock_free() 
>> const':
>> /usr/include/c++/6/atomic:212: undefined reference to `__atomic_is_lock_free'
[...]
> The problem is in configure.ac file. Code used for checking is libatomic 
> needed to link 
> always returns the same result. For mips and mipsel test passes but the build 
> fails because of missing libatomic.
> I have changed that test to provide linking with libatomic as needed.

The patch:
> --- drumgizmo-0.9.11.orig/configure.ac
> +++ drumgizmo-0.9.11/configure.ac
> @@ -473,11 +473,12 @@ dnl ==
>  AC_MSG_CHECKING([for the need for linkage with libatomic])
>  AC_LANG_PUSH([C++])
>  AC_LINK_IFELSE([AC_LANG_SOURCE[
> +  #include 

Typo? You want 

>#include 
> +  std::atomic x;
> +  std::atomic y;  

I don't think you should rely on these types being in the global namespace.

>int main() {
> -struct Test { int val; };
> -std::atomic s;
> -return s.is_lock_free()?1:0;
> + return x + y;
>}
>  ]],
>  [AC_MSG_RESULT([no])],

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#843149: drumgizmo: compiled with -msse3 on amd64

[James Cowgill]

Package: drumgizmo
Version: 0.9.10-1
Severity: important

Hi,

drumgizmo appears to be compiled with -msse3 on amd64. This is not
allowed as it will SIGILL on amd64 arches without SSE3 support (although
there are few machines this applies to). The baseline SSE support in
amd64 is sse2.

Ordinarily this would be a RC bug, but it appears the SSE code is
currently disabled in drumgizmo so it doesn't matter. I did an objdump
check on the current binaries and they contain no SSE3 instructions.
Having said that, I think you're on thin ice as gcc may insert them at
any time :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842620: mpv: OSD is gone‽

[James Cowgill]

On 01/11/16 22:52, Salvo Tomaselli wrote:
> Well your workaround doesn't really help. I still need to put the
> mouse on the bottom, while before, to see how long was left, i could
> just move the mouse slightly.

This is the OSC 'deadzone' and is also a configurable setting. Try:
 mpv --script-opts=osc-deadzonesize=0

This is the PR which made all these changes:
https://github.com/mpv-player/mpv/pull/3631

James



signature.asc
Description: OpenPGP digital signature

Bug#842810: mpv: Add missing MIME types to desktop file?

[James Cowgill]

Hi,

On 01/11/16 12:47, Petter Reinholdtsen wrote:
> Package: mpv
> Verison: 0.21.0-2
> 
> Hi.
> 
> I noticed mpv do not list the same set of MIME types as vlc in its
> desktop file.  This causes the graphical file manager in the various
> desktops to not suggest mpv to play various audio and video formats when
> the user click on a media file.

Could you ask upstream directly?
https://github.com/mpv-player/mpv/issues/new

Thanks,
James



signature.asc
Description: OpenPGP digital signature

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

[James Cowgill]

Hi,

I've had a bit of a look at this bug. I've now tried to build git on two
different machines running different hardware (octeon and loongson) and
it built fine both times so I'm not too sure what's going on here.

All 3 builds which failed were Loongson machines running 3.16 kernels.
While I know they have FPU problems, I wouldn't have thought that would
give an out of memory error.

It would be good to get the package rebuilt on an Octeon to see if it is
a hardware problem.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842620: mpv: OSD is gone‽

[James Cowgill]

Hi,

On 30/10/16 20:50, Salvo Tomaselli wrote:
> Package: mpv
> Version: 0.21.0-2
> Severity: normal
> 
> Dear Maintainer,
> after upgrade, the osd that appears when moving the mouse seems to be gone.

Try moving your mouse to the bottom of the window.

In mpv 0.21 the default OSD layout was changed from 'box' to
'bottombar'. You can get the old behavior by using:

 mpv --script-opts=osc-layout=box

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842513: vlc: immediate crash on launch on powerpc

[James Cowgill]

Control: tags -1 - help
Control: severity -1 important
Control: retitle -1 vlc: should prevent installation on powerpc G3

Hi,

On 30/10/16 00:16, Robert Ou wrote:
> On Sat, Oct 29, 2016 at 3:43 PM, James Cowgill <jcowg...@debian.org> wrote:
>> Control: tags -1 help
>> Control: severity -1 grave
>>
>> Hi,
>>
>> On 29/10/16 23:00, Robert Ou wrote:
>>> Package: src:vlc
>>> Version: 2.2.4-7
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>> I decided I wanted to test the performance of Debian PowerPC on my
>>> ancient iMac, and I discovered that vlc will immediately crash with an
>>> illegal instruction right after showing the "Privacy and Network Access
>>> Policy" window and before showing the main window. The crashes look like
>>> the following:
>>>
>>> [ 1560.952016] vlc[997]: unhandled signal 4 at 0ea48f58 nip 0ea48f58 lr 
>>> 0ea48f4c code 30001
>>
>> As powerpc is a release architecture, this bug is RC.
>>
>> I tried running vlc on partch. It managed to get further, but then
>> segfaulted inside QT so it's probably a separate issue. I also had to
>> run it in xvfb so it probably gets different results.
>>
>> Specifically what powerpc hardware do you have? Could you run vlc within
>> gdb to determine which instruction it SIGILLs on (try 'layout asm')?
> 
> I was testing on a first-generation iMac with a 333 MHz PowerPC 750
> (G3). Running vlc under gdb shows that the crash occurs in
> libqt4_plugin.so in QRect::adjusted. The crash occurs on a "lvx
> v0,r10,r5" opcode, which is an Altivec opcode. The G3 however does not
> support Altivec. Here is a backtrace and some more debug information:

This explains it. From the PowerPC FAQ:
https://wiki.debian.org/PowerPC/FAQ#VLC_crashes_on_startup._What.27s_up_with_that.3F

"
If VLC immediately crashes, it's probably because you're on a G3 and
VLC was compiled with Altivec instructions. To use VLC on a G3, you
must compile it with the configure option --disable-altivec.
"

Having said that, I think adding something to vlc's preinst to prevent
installation on systems without altivec would be a good idea here.

I'm not sure going through all the trouble of compiling vlc twice so it
works on the G3 is worth it here - especially since powerpc may not be
a release architecture in 24 hours...

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842513: vlc: immediate crash on launch on powerpc

[James Cowgill]

Control: tags -1 help
Control: severity -1 grave

Hi,

On 29/10/16 23:00, Robert Ou wrote:
> Package: src:vlc
> Version: 2.2.4-7
> Severity: normal
> 
> Dear Maintainer,
> 
> I decided I wanted to test the performance of Debian PowerPC on my
> ancient iMac, and I discovered that vlc will immediately crash with an
> illegal instruction right after showing the "Privacy and Network Access
> Policy" window and before showing the main window. The crashes look like
> the following:
> 
> [ 1560.952016] vlc[997]: unhandled signal 4 at 0ea48f58 nip 0ea48f58 lr 
> 0ea48f4c code 30001

As powerpc is a release architecture, this bug is RC.

I tried running vlc on partch. It managed to get further, but then
segfaulted inside QT so it's probably a separate issue. I also had to
run it in xvfb so it probably gets different results.

Specifically what powerpc hardware do you have? Could you run vlc within
gdb to determine which instruction it SIGILLs on (try 'layout asm')?

Can a powerpc porter help here?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#809365: #809365: exifprobe: segfault on some invalid jpegs

[James Cowgill]

Control: forwarded -1 https://github.com/hfiguiere/exifprobe/issues/5
Control: found -1 2.0.1-6

On 29/10/16 09:43, Henri Salo wrote:
> Did you report this issue to the upstream bug tracker? I think that these 
> should
> be forwarded to https://github.com/hfiguiere/exifprobe/issues to get them 
> fixed.
> Please contact me in case you need help with it.

I've forwarded it upstream just now.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#704206: teem: FTBFS[any-i386]: testsuite failures

[James Cowgill]

Control: found -1 1.12.0~20160122-1
Control: found 820503 1.12.0~20160122-1

Hi,

It appears that the most recent upload (1.12.0~20160122-1) reverted the
fixes for these two bugs which were done in Tobias's NMU
(1.11.0~svn6057-1.1). Please reapply the patches from it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842381: orpie: please remove embedded ocamlgsl

[James Cowgill]

Package: orpie
Version: 1.5.2-1
Severity: normal

Hi,

orpie contains an embedded copy of ocamlgsl. Please use the ocamlgsl
Debian package instead.

After doing this, it would be good if the Architecture field was
reverted to "any" so that orpie builds on more architectures.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842379: libb2: FTBFS on non-x86 architectures

[James Cowgill]

Source: libb2
Version: 0.97-2
Severity: important
Tags: sid stretch

Hi,

libb2 FTBFS on non-x86 architectures, because it couldn't detect the
-msse2 compiler option.

However it appears that libb2 does support other architectures by using
its reference C implementation. I think you have to disable the
--enable-fat option on non-x86 arches and prevent -march=native from
being used.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842377: libb2: missing Vcs-Browser field

[James Cowgill]

Source: libb2
Version: 0.97-2
Severity: minor

Hi,

libb2 has a Vcs-Git field, but no Vcs-Browser field. This seems like a
minor oversight to me.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#773205: libatomic-ops-dev: FTBFS on mips64el

[James Cowgill]

Control: found -1 7.4.4-1
Control: severity -1 serious

Hi,

In 7.4.4-1 the patches adding mips64el support were removed from the
package. While they've applied upstream in the 'master' branch not all
of them were applied to the 'release-7_4' branch and libatomic-ops FTBFS
on mips64el again.

These have been applied to 7.4.4-1 (which is good):
 0002-Remove-inclusion-of-acquire_release_volatile.h-on-mi.patch
 0003-Minor-fix-of-code-alignment-in-mips-AO_compare_and_s.patch

Please reapply these patches from 7.4.2-3:
 0001-Use-LLD-and-SCD-instructions-on-mips64.patch
 0004-Support-n32-ABI-for-mips64.patch

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842313: libupnp6: minidlna reports upnp error since upgrade to 1:1.6.19+git20160116-1.1

[James Cowgill]

Control: retitle -1 libupnp6: minidlna reports upnp error since upgrade to 
1:1.6.19+git20160116-1.1

On 28/10/16 09:55, Simon Frei wrote:
> Control: retitle "minidlna reports upnp error since upgrade to
> 1:1.6.19+git20160116-1.1"
> 
> I mistakenly referenced the old package *-1 instead of *-1.1 in the
> title and body of the bugreport - sorry for that.
> The only reason for suspecting libupnp6 to be the reason is that these
> error started appearing right after the upgrade. In this upgrade
> minidlna was not upgraded, but libupnp was.

Are you sure it was libupnp at fault here? I ask because minidlna does
not depend on libupnp and should have nothing to do with it.

Please provide the _exact_ output of '/usr/sbin/minidlnad -dv' and the
steps needed to reproduce this.

James





signature.asc
Description: OpenPGP digital signature

Bug#839104: libsfml-window2.4: unusable applications after XCB conversion (was: extremetuxracer takes the focus but no windows is displayed...)

[James Cowgill]

Control: tags -1 pending

[+CC everyone affected by the bug]

Hi all,

On 27/10/16 11:28, James Cowgill wrote:
> On 27/10/16 05:56, Marko Lindqvist wrote:
>> Even my own build I last used a couple of months ago has broken this
>> way. I suspect it was broken either SFML (etr no longer uses SDL) or
>> gdm updates.
> 
> This reminded me of this bug in SFML which fixes a lot of glitches:
> https://github.com/SFML/SFML/pull/1138
> 
> Sure enough, applying that fixes extremetuxracer. SFML is planning a
> new release very soon (in fact I'm probably responsible for relaying it
> a few days). Hopefully this will be fixed fairly soon.

I have uploaded the 2.4.x git branch from upstream SFML to experimental
which should fix this issue. Can someone test it please? You may have to
wait a few hours from now before it appears on the mirrors.

I'll upload it to unstable when there's an actual release, which
shouldn't be too long now (ha).

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#839498: bup: FTBFS: Tests failures

[James Cowgill]

Control: tags -1 pending

Hi,

I've uploaded the attached NMU to fix this bug.

This will also trigger a rebuild on mipsel which (I hope) will fix the
FTBFS there as well.

Thanks,
James
diff -Nru bup-0.28.1/debian/changelog bup-0.28.1/debian/changelog
--- bup-0.28.1/debian/changelog 2016-10-02 22:22:52.0 +0100
+++ bup-0.28.1/debian/changelog 2016-10-27 15:22:29.0 +0100
@@ -1,3 +1,10 @@
+bup (0.28.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on tzdata to fix FTBFS. (Closes: #839498)
+
+ -- James Cowgill <jcowg...@debian.org>  Thu, 27 Oct 2016 15:22:29 +0100
+
 bup (0.28.1-1) unstable; urgency=medium
 
   * New upstream version 0.28.1
diff -Nru bup-0.28.1/debian/control bup-0.28.1/debian/control
--- bup-0.28.1/debian/control   2016-10-02 22:22:52.0 +0100
+++ bup-0.28.1/debian/control   2016-10-27 15:11:21.0 +0100
@@ -12,6 +12,7 @@
  python-pylibacl,
  python-pyxattr [linux-any],
  rsync,
+ tzdata,
 Build-Depends-Indep: pandoc (>= 1.11.1-4~), pandoc-data (>= 1.11.1-4~)
 Standards-Version: 3.9.6
 Homepage: https://github.com/bup/bup


signature.asc
Description: OpenPGP digital signature

Bug#839104: extremetuxracer takes the focus but no windows is displayed but sound is played => impossible to switch to other applications, impossible to close extremetuxracer

[James Cowgill]

Control: reassign -1 libsfml-window2.4 2.4.0+dfsg-2
Control: affects -1 src:extremetuxracer
Control: retitle -1 libsfml-window2.4: unusable applications after XCB 
conversion
Control: tags -1 fixed-upstream

Hi,

On 27/10/16 05:56, Marko Lindqvist wrote:
> On 19 October 2016 at 22:08, Markus Koschany  wrote:
>> On 19.10.2016 15:43, Isaac To wrote:
>>> On Thu, 29 Sep 2016 14:59:47 +0200 Markus Koschany >> > wrote:
 On 29.09.2016 14:52, gpe wrote:
> I'm using gnome and a NVIDIA vidéo card with NVIDIA drivers.

 I'm also using GNOME but with an ATI video card and free drivers. What
 happens if you use the free nouveau drivers?
>>>
>>> I just want to share that I see exactly the same problem: a window shows
>>> up, immediately get deleted, and this repeats after a very short while.
>>> My lspci shows the following:
>>
>> Hello,
>>
>> thanks for your additional information but unfortunately I don't know
>> how to interpret your strace output. I find it still unlikely that
>> extremetuxracer is the root cause because the game (or the packaging)
>> has not changed in months. It is rather related to your video card
>> driver, the X server, SDL or window manager.
> 
>  Even my own build I last used a couple of months ago has broken this
> way. I suspect it was broken either SFML (etr no longer uses SDL) or
> gdm updates.

This reminded me of this bug in SFML which fixes a lot of glitches:
https://github.com/SFML/SFML/pull/1138

Sure enough, applying that fixes extremetuxracer. SFML is planning a
new release very soon (in fact I'm probably responsible for relaying it
a few days). Hopefully this will be fixed fairly soon.

New 2.4.1 release:
https://github.com/SFML/SFML/pull/1164

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#842145: usrmerge: fails on nfsroot systems

[James Cowgill]

On 26/10/16 14:11, Marco d'Itri wrote:
> On Oct 26, James Cowgill <jcowg...@debian.org> wrote:
>> Can't rename('/sbin/.nfs003efaa00995~~tmp~usrmerge~~', 
>> '/sbin/.nfs003efaa00995'): Device or resource busy at 
>> /usr/lib/convert-usrmerge line 98
> The .nfs* file is case of NFS silly rename, but I am not sure about why 
> it happens here: did you check what 
> /sbin/.nfs003efaa00995~~tmp~usrmerge~~ was?
> Maybe there are possibile workarounds, but right now I do not have an 
> environment to test this. Since convert-usrmerge can be run in a chroot 
> on the NFS server maybe it would be easier to just make it fail if the 
> root is NFS-mounted.

Yes that's is probably the easiest option

>> You can try correcting the errors reported and running again
>> /usr/lib/convert-usrmerge until it will complete without errors.  
> Did you try running /usr/lib/convert-usrmerge again?

I repeated it a few times. I had to restart various services in between
retries (I think I restarted everything by the end). Eventually it
succeeded.

>> I was thinking that it may be possible to fix this if the machine was
>> rebooted halfway though (after all the files have been moved, but all
>> the file symlinks still present), but I don't know if that would work.
> It is expected to.

I'll try that next time if possible.

James



signature.asc
Description: OpenPGP digital signature

Bug#842145: usrmerge: fails on nfsroot systems

[James Cowgill]

Package: usrmerge
Version: 12
Severity: important

Hi,

Today I upgraded one of my mipsel machines to stretch. The machine is
an Ubiquiti ER8 router and because it doesn't have a hard disk
controller, it's booted using nfsroot.

After upgrading, I tried to install usrmerge which gave:

---
Setting up usrmerge (12) ...

FATAL ERROR:

Can't rename('/sbin/.nfs003efaa00995~~tmp~usrmerge~~', 
'/sbin/.nfs003efaa00995'): Device or resource busy at 
/usr/lib/convert-usrmerge line 98
   
You can try correcting the errors reported and running again
 
/usr/lib/convert-usrmerge until it will complete without errors.  
Do not install or update other Debian packages until the program  
has been run successfully. 

 
dpkg: error processing package usrmerge (--configure):
 subprocess installed post-installation script returned error exit status 1 
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:   
 usrmerge   
E: Sub-process /usr/bin/dpkg returned an error code (1)
---

I then had to convert the machine to usrmerge the painful way. A
warning message for anyone using nfsroot would be nice.

I was thinking that it may be possible to fix this if the machine was
rebooted halfway though (after all the files have been moved, but all
the file symlinks still present), but I don't know if that would work.

Thanks,
James

Bug#775722: grub2: fix mips64el build

[James Cowgill]

Control: reopen -1

Hi YunQiang,

On second thoughts, maybe this bug is still relevant?

I've just seen this bug:
#775723 grub2-yeeloong: cannot work with 3A laptop

I wasn't actually aware that there was a 3A Yeeloong, but if that is the
case and it works with grub2 then adding mips64el support and the other
things in your patch would still make sense.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841979: jessie-pu: package minissdpd/1.2.20130907-3

[James Cowgill]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: Thomas Goirand <z...@debian.org>

Hi,

The attached debdiff fixes #816759 (minissdpd: CVE-2016-3178
CVE-2016-3179) for jessie. Both CVEs are taged 'no-DSA' by the security
team.

Thanks,
James

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru minissdpd-1.2.20130907/debian/changelog 
minissdpd-1.2.20130907/debian/changelog
--- minissdpd-1.2.20130907/debian/changelog 2014-07-14 08:02:57.0 
+0100
+++ minissdpd-1.2.20130907/debian/changelog 2016-10-24 22:46:46.0 
+0100
@@ -1,3 +1,15 @@
+minissdpd (1.2.20130907-3+deb8u1) jessie; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2016-3178 and CVE-2016-3179. (Closes: #816759)
+The minissdpd daemon contains a improper validation of array index
+vulnerability (CWE-129) when processing requests sent to the Unix
+socket at /var/run/minissdpd.sock the Unix socket can be accessed
+by an unprivileged user to send invalid request causes an
+out-of-bounds memory access that crashes the minissdpd daemon.
+
+ -- James Cowgill <jcowg...@debian.org>  Mon, 24 Oct 2016 22:46:46 +0100
+
 minissdpd (1.2.20130907-3) unstable; urgency=medium
 
   * Removed $all from init.d script.
diff -Nru minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch 
minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch
--- minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch   1970-01-01 
01:00:00.0 +0100
+++ minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch   2016-10-24 
22:43:23.0 +0100
@@ -0,0 +1,95 @@
+Description: Fix CVE-2016-3178
+ buffer overflow while handling negative length request
+Author: Salva Peiró <speir...@gmail.com>
+Origin: upstream, 
https://github.com/miniupnp/miniupnp/commit/b238cade9a173c6f751a34acf8ccff838a62aa47
+Bug-Debian: https://bugs.debian.org/816759
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/minissdpd.c
 b/minissdpd.c
+@@ -555,7 +555,7 @@ void processRequest(struct reqelem * req
+   type = buf[0];
+   p = buf + 1;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -661,7 +661,7 @@ void processRequest(struct reqelem * req
+   goto error;
+   }
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -679,7 +679,7 @@ void processRequest(struct reqelem * req
+   newserv->usn[l] = '\0';
+   p += l;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -697,7 +697,7 @@ void processRequest(struct reqelem * req
+   newserv->server[l] = '\0';
+   p += l;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+--- a/testminissdpd.c
 b/testminissdpd.c
+@@ -45,6 +45,23 @@ void printresponse(const unsigned char *
+ #define SENDCOMMAND(command, size) write(s, command, size); \
+   printf("Command written type=%u\n", (unsigned)command[0]);
+ 
++int connect_unix_socket(const char * sockpath)
++{
++  int s;
++  struct sockaddr_un addr;
++
++  s = socket(AF_UNIX, SOCK_STREAM, 0);
++  addr.sun_family = AF_UNIX;
++  strncpy(addr.sun_path, sockpath, sizeof(addr.sun_path));
++  if(connect(s, (struct sockaddr *), sizeof(struct sockaddr_un)) < 
0) {
++  fprintf(stderr, "connecting to %s : ", addr.sun_path);
++  perror("connect");
++  exit(1);
++  }
++  printf("Connected to %s\n", addr.sun_path);
++  return s;
++}
++
+ /* test program for minissdpd */
+ int
+ main(int argc, char * * argv)
+@@ -52,6 +69,7 @@ main(int argc, char * * argv)
+   char command1

Bug#816759: minissdpd: CVE-2016-3178 CVE-2016-3179

[James Cowgill]

Control: tags -1 pending

Hi,

I have uploaded the attached NMU to fix this bug. It was mostly based on
the fix already present in wheezy-lts (the CVE patches are identical).
I've done some basic testing of the patches and it fixes the buffer
overflow which can be triggered as described earlier in the bugreport.

I'll see what I can do about fixing this in jessie as well.

Thanks,
James
diff -Nru minissdpd-1.2.20130907/debian/changelog 
minissdpd-1.2.20130907/debian/changelog
--- minissdpd-1.2.20130907/debian/changelog 2016-07-13 19:12:39.0 
+0100
+++ minissdpd-1.2.20130907/debian/changelog 2016-10-24 08:54:59.0 
+0100
@@ -1,3 +1,15 @@
+minissdpd (1.2.20130907-3.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2016-3178 and CVE-2016-3179. (Closes: #816759)
+The minissdpd daemon contains a improper validation of array index
+vulnerability (CWE-129) when processing requests sent to the Unix
+socket at /var/run/minissdpd.sock the Unix socket can be accessed
+by an unprivileged user to send invalid request causes an
+out-of-bounds memory access that crashes the minissdpd daemon.
+
+ -- James Cowgill <jcowg...@debian.org>  Mon, 24 Oct 2016 08:54:59 +0100
+
 minissdpd (1.2.20130907-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch 
minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch
--- minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch   1970-01-01 
01:00:00.0 +0100
+++ minissdpd-1.2.20130907/debian/patches/CVE-2016-3178.patch   2016-10-24 
08:54:59.0 +0100
@@ -0,0 +1,95 @@
+Description: Fix CVE-2016-3178
+ buffer overflow while handling negative length request
+Author: Salva Peiró <speir...@gmail.com>
+Origin: upstream, 
https://github.com/miniupnp/miniupnp/commit/b238cade9a173c6f751a34acf8ccff838a62aa47
+Bug-Debian: https://bugs.debian.org/816759
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/minissdpd.c
 b/minissdpd.c
+@@ -555,7 +555,7 @@ void processRequest(struct reqelem * req
+   type = buf[0];
+   p = buf + 1;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -661,7 +661,7 @@ void processRequest(struct reqelem * req
+   goto error;
+   }
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -679,7 +679,7 @@ void processRequest(struct reqelem * req
+   newserv->usn[l] = '\0';
+   p += l;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+@@ -697,7 +697,7 @@ void processRequest(struct reqelem * req
+   newserv->server[l] = '\0';
+   p += l;
+   DECODELENGTH_CHECKLIMIT(l, p, buf + n);
+-  if(p+l > buf+n) {
++  if(l > (unsigned)(buf+n-p)) {
+   syslog(LOG_WARNING, "bad request (length encoding)");
+   goto error;
+   }
+--- a/testminissdpd.c
 b/testminissdpd.c
+@@ -45,6 +45,23 @@ void printresponse(const unsigned char *
+ #define SENDCOMMAND(command, size) write(s, command, size); \
+   printf("Command written type=%u\n", (unsigned)command[0]);
+ 
++int connect_unix_socket(const char * sockpath)
++{
++  int s;
++  struct sockaddr_un addr;
++
++  s = socket(AF_UNIX, SOCK_STREAM, 0);
++  addr.sun_family = AF_UNIX;
++  strncpy(addr.sun_path, sockpath, sizeof(addr.sun_path));
++  if(connect(s, (struct sockaddr *), sizeof(struct sockaddr_un)) < 
0) {
++  fprintf(stderr, "connecting to %s : ", addr.sun_path);
++  perror("connect");
++  exit(1);
++  }
++  printf("Connected to %s\n", addr.sun_path);
++  return s;
++}
++
+ /* test program for minissdpd */
+ int
+ main(int argc, char * * argv)
+@@ -52,6 +69,7 @@ main(int argc, char * * argv)
+   char command1[] = 
"\x01\x00urn:schemas-upnp-org:device:InternetGatewayDevice";
+   char command2[] = 
"\x02\x00uuid:fc4ec57e-b051-11db-88f8-0060085db3f6::upnp:rootdevice";
+   char command3[] = { 0x03, 0x00 };
++const char bad_command4[] = { 0x04, 0x01, 0x60, 0x8f, 0xff, 0xff, 
0xff, 0x7f};
+   struct sockaddr_un addr;
+   int s;
+   int i

Bug#813411: cython: Wrong definition of st_dev in posix/stat.pxd on mips/mipsel

[James Cowgill]

Control: retitle -1 cython: Wrong definition of st_dev in posix/stat.pxd on 
mips/mipsel

Hi,

On Mon, 01 Feb 2016 09:36:34 -0800 Nikolaus Rath  wrote:
> Package: cython
> Version: 0.23.2+git16-ga8fbae1-1+b1
> Severity: normal
> Tags: patch
> 
> On mips and mipsel, the st_dev and st_rdev members of struct stat do not
> have type dev_t. This breaks POSIX compatibility, but is difficult to fix
> (cf. https://sourceware.org/bugzilla/show_bug.cgi?id=17786).
> 
> When using Cython, this leads to conversation warnings in the generated
> C code.
> 
> A workaround is to change the definition of struct stat that is used by Cython
> when we are compiling under mips. The drawback is that this requires the 
> Cython
> compilation to run under mips, and that the resulting C file will be mips
> specific (without the patch, the generated C file is suitable for any
> architecture). However, I think this may be less of an issue for the Debian
> package, because we are building everything from source on the target
> architecture anyway (including regeneration of the C file from Cython code),
> and it only happens to mips/mipsel users.
> 
> Thoughts on including this patch in the Debian package?
> 
> --- a/Includes/posix/stat.pxd
> +++ b/Includes/posix/stat.pxd
> @@ -16,7 +16,25 @@ cdef extern from "sys/stat.h" nogil:
>  S_IFMT
>  S_IFDIR
>  
> -struct stat:
> +IF UNAME_MACHINE.startswith('mips64'):

This is incorrect. The above dev_t bug you describe only occurs in the
o32 ABI. Your patch would "fix" all mips ABIs including n64 (ie
mips64el). As the ABI is tied to the compiler, the correct way to do
this is either a C preprocessor #if, or invoking the compiler and
asking it what the default ABI is. I don't know how easy it is to do in
cython though.

If it only prints warnings and nothing otherwise breaks, I don't think
this is a big issue though. Maybe the o32 ABI will be fixed one day...

James



signature.asc
Description: OpenPGP digital signature

Bug#778720: bind9: hangs on mips jessie based machine

[James Cowgill]

Control: retitle -1 bind9: hangs on mips jessie based machine

Ping?

This is a Debian specific bug which ha had a patch for over a year now...

James



signature.asc
Description: OpenPGP digital signature

Bug#776275: os-prober: add mips64el support

[James Cowgill]

Control: retitle -1 os-prober: use grub-mount-udeb on all linux/freebsd arches
Control: tags -1 patch

Hi,

On Mon, 26 Jan 2015 13:55:58 +0800 YunQiang Su  wrote:
> Package: os-prober
> Version: 1.65
> 
> diff -Nru os-prober-1.65/debian/control os-prober-1.65+mips/debian/control
> --- os-prober-1.65/debian/control 2014-11-12 23:18:54.0 +0800
> +++ os-prober-1.65+mips/debian/control 2015-01-19 18:46:01.0 +0800
> @@ -11,7 +11,7 @@
>  Package: os-prober-udeb
>  Package-Type: udeb
>  Architecture: any
> -Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna
> (>= 1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc
> mipsel kfreebsd-i386 kfreebsd-amd64]
> +Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna
> (>= 1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc
> mipsel mips64el mipsn32el kfreebsd-i386 kfreebsd-amd64]
>  Provides: os-prober
>  Description: utility to detect other OSes on a set of drives
>   This package is to be used by boot loader installers to detect other OSes

In grub2 2.02~beta2-14, grub-mount-udeb was made available on all
arches (except hurd). Instead of just enabling it on mips64el, I
think it makes more sense to add a dependency on arches except hurd
like the patch below does.

Thanks,
James

diff -ur a/debian/control b/debian/control
--- a/debian/control2016-01-30 06:38:44.0 +
+++ b/debian/control2016-10-24 13:09:44.507692788 +0100
@@ -11,7 +11,7 @@
 Package: os-prober-udeb
 Package-Type: udeb
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna (>= 
1.16), grub-mount-udeb [i386 amd64 powerpc ppc64 ppc64el sparc mipsel 
kfreebsd-i386 kfreebsd-amd64]
+Depends: ${misc:Depends}, ${shlibs:Depends}, di-utils-mapdevfs, anna (>= 
1.16), grub-mount-udeb [linux-any kfreebsd-any]
 Provides: os-prober
 Description: utility to detect other OSes on a set of drives
  This package is to be used by boot loader installers to detect other OSes



signature.asc
Description: OpenPGP digital signature

Bug#841727: mpv: Refuses to start due to missing libGL

[James Cowgill]

Control: tags -1 unreproducible

Hi,

On 22/10/16 20:01, Mario Lang wrote:
> Package: mpv
> Version: 0.21.0-1
> Severity: serious
> 
> fx:~/music% mpv -no-video -ao jack file.mp3
> mpv: error while loading shared libraries: libGL.so.1: cannot open shared 
> object file: No such file or directory
[...]
> Versions of packages mpv depends on:
[..]
> ii  libgl1-mesa-glx [libgl1]12.0.3-1

libGL.so.1 is found in the above package on my system which you
apparently have installed.

$ dpkg -S /usr/lib/x86_64-linux-gnu/libGL.so.1
libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1

Do you have the above file on your system? If not, try reinstalling the
above package.

If that still doesn't work, please provide the outputs of:
 - ldd /usr/bin/mpv
 - /sbin/ldconfig -v 2>/dev/null | grep -v ^$'\t'

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#725417: Thanks a lot

[James Cowgill]

Hi,

On 21/10/16 22:36, Santiago Garcia Mantinan wrote:
> Hi!
> 
> I've been preparing a new version of mbr which will change the format and
> not overwrite the disk-id, but I have not finished yet and I don't have time
> lately, so your upload is very welcome.

Great!

If you want, I could reschedule my NMU to skip the delayed queue and go
straight in (I doubt it would make too much difference though).

James



signature.asc
Description: OpenPGP digital signature

Bug#834856: [Debian-med-packaging] Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[James Cowgill]

On 21/10/16 14:55, YunQiang Su wrote:
> On Fri, Oct 14, 2016 at 3:47 PM, Emilio Pozuelo Monfort
>  wrote:
>> Control: severity -1 serious
>>
>> On Fri, 19 Aug 2016 22:29:48 -0700 Afif Elghraoui  wrote:
>>> Control: severity -1 important
>>> Control: tag -1 + help
>>>
>>> Hello and thank you for the report.
>>>
>>> على الجمعـة 19 آب 2016 ‫14:48، كتب Jonathan Jackson:
 Package: python-pysam
 Version: 0.9.1.4+ds-1
 Severity: grave
 Justification: renders package unusable

>>>
>>> While the package may be unusable on mips64el, it works well for the
>>> vast majority of users as I understand it, so this situation deserves a
>>> severity of 'important' rather than 'grave'.
>>
>> mips64el is a release architecture, thus this bug is serious.
> 
> mips64el seems building successfully now, while mipsel fails.
> I guess it is due to Loongson machine.

If mips64el has built (possibly one of the build machines is 'nicer' to
it), is this bug RC anymore?

> Let me have a give-back on mipsel.

While it could help, the same segfault happens on armel, mipsel and x32
according to the build logs. I don't think it's hardware specific.

https://buildd.debian.org/status/package.php?p=python-pysam

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#725417: mbr: install-mbr wipes the disk-id portion of the MBR, rendering Windows 7 unbootable

[James Cowgill]

isable testsuite on all archs. (Closes: #792126, LP: #445643)
+
+  [ Dejan Latinovic ]
+  * Fix FTBFS on ia64, m68k and mips64el by using xxd instead of ld.
+(Closes: #697332)
+
+  [ Lannart Sorensen ]
+  * Prevent install-mbr from wiping new style MBRs.
+(Closes: #725417, LP: #814956)
+
+  [ Martin Pitt ]
+  * Read UTC setting from /etc/adjtime instead of /etc/default/rcS.
+(Closes: #813671)
+
+ -- James Cowgill <jcowg...@debian.org>  Fri, 21 Oct 2016 10:57:33 +0100
+
 mbr (1.1.11-5) unstable; urgency=low
 
   * Add dh_md5sums to debian/rules, thanks to jmccrohan. Closes: #672321.
diff -u mbr-1.1.11/debian/control mbr-1.1.11/debian/control
--- mbr-1.1.11/debian/control
+++ mbr-1.1.11/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Santiago Garcia Mantinan <ma...@debian.org>
 Standards-Version: 3.9.3
-Build-Depends: debhelper(>= 7), bin86, util-linux (>= 2.13) | linux32
+Build-Depends: debhelper(>= 7), bin86, util-linux (>= 2.13) | linux32, xxd
 
 Package: mbr
 Architecture: any
diff -u mbr-1.1.11/debian/rules mbr-1.1.11/debian/rules
--- mbr-1.1.11/debian/rules
+++ mbr-1.1.11/debian/rules
@@ -1,7 +1,5 @@
 #!/usr/bin/make -f
 
-KERNEL_ARCH := $(shell linux64 uname -m)
-
 CC := gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 
 CFLAGS := -g -Wall -W
@@ -23,13 +21,6 @@
 build-stamp:
./configure --exec-prefix=`pwd`/debian/mbr/ 
--prefix=`pwd`/debian/mbr/usr
$(MAKE) CC="$(CC)" LD="$(LD)" CFLAGS="$(CFLAGS)"
-ifneq (,$(findstring x86_64,$(KERNEL_ARCH)))
-   # Limit the tests on x86_64 kernels
-else ifeq (i386,$(DEB_BUILD_ARCH))
-   $(MAKE) check
-else
-   # Limit the tests on non i386
-endif
touch build
 
 clean:
only in patch2:
unchanged:
--- mbr-1.1.11.orig/mbr.h
+++ mbr-1.1.11/mbr.h
@@ -4,19 +4,20 @@
 /* This file defines the interface to the encapsulated binary file
produced by ld. */
 
-extern u_int8_t _binary_mbr_b_start[];
-extern u_int8_t _binary_mbr_b_end[];
+extern unsigned char mbr_b[];
+extern unsigned int mbr_b_len;
+
+#define MBR_START mbr_b
+#define MBR_END (mbr_b + mbr_b_len)
+#define MBR_SIZE mbr_b_len
+
+extern unsigned char y2k_b[];
+extern unsigned int y2k_b_len;
+
+#define Y2K_START y2k_b
+#define Y2K_END  (y2k_b + y2k_b_len)
+#define Y2K_SIZE y2k_b_len
 
-#define MBR_START _binary_mbr_b_start
-#define MBR_END _binary_mbr_b_end
-#define MBR_SIZE (_binary_mbr_b_end - _binary_mbr_b_start)
-
-extern u_int8_t _binary_y2k_b_start[];
-extern u_int8_t _binary_y2k_b_end[];
-
-#define Y2K_START _binary_y2k_b_start
-#define Y2K_END _binary_y2k_b_end
-#define Y2K_SIZE (_binary_y2k_b_end - _binary_y2k_b_start)
 
 /* This defines the format of the parameters in the MBR for versions 0
and 1.  This structure is now frozen. */


signature.asc
Description: OpenPGP digital signature

Bug#841300: arcboot: remove this package?

[James Cowgill]

On 21/10/16 11:01, Guido Günther wrote:
> Hi,
> On Wed, Oct 19, 2016 at 02:30:18PM +0100, James Cowgill wrote:
>> Source: arcboot
>> Version: 0.3.15
>> Severity: serious
>> Tags: sid stretch
>>
>> Hi,
>>
>> Given that stretch will drop support for pre-mips32r2 processors
>> including the SGI IP22 and IP32, should this package be removed?
> 
> Seems so. Did you (or do you intend) to file the RM?

I have not filed an RM. I'd prefer if you do it since you are the
maintainer.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841434: whohas: cannot fetch ancient Fedora and OpenBSD releases

[James Cowgill]

Package: whohas
Version: 0.29.1-1
Severity: normal

Hi,

$ whohas --strict mpv > /dev/null
Tried fetching "http://ftp.openbsd.org/pub/OpenBSD/5.7/packages/i386/; five 
times. Giving up.
Tried fetching 
"http://dl.fedoraproject.org/pub/fedora/linux/releases/21/Everything/i386/os/Packages/m/;
 five times. Giving up.
Tried fetching 
"http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Everything/i386/os/Packages/m/;
 five times. Giving up.

Fedora 20 and 21 are no longer hosted on dl.fedoraproject.org.
Similarly OpenBSD 5.7 has gone away. Please can you update the versions
in whohas - or even better, let it use whatever the latest version of a
particular distribution is.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#831857: libupnp: CVE-2016-6255: write files via POST

[James Cowgill]

Control: tags -1 patch pending

Hi,

I am about to upload the attached NMU to finally fix this bug. I've also
attached a patch suitable for jessie-security, and a test script I used
to create a libupnp server for testing the fix with.

Thanks,
James
/*
 * Upnp CVE-2016-6255 test program
 *
 * This program runs the webserver from libupnp serving files from the current
 * directory. If libupnp is vulnerable to CVE-2016-6255, it will allow uploading
 * files.
 *
 * Example:
 *
 * $ gcc -I/usr/include/upnp cve-2016-6255-test.c -lupnp -ocve-2016-6255-test
 * $ cat testfile
 * cat: testfile: No such file or directory
 * $ ./cve-2016-6255-test > /dev/null &
 * [2] 32309
 * $ curl -i --data $'FAIL\n' http://localhost:49152/testfile
 * $ cat testfile
 * FAIL
 */

#define _GNU_SOURCE
#include 
#include 
#include 

int main(void)
{
	char* wd = get_current_dir_name();

	// Setup upnp
	printf("Init = %d\n", UpnpInit("127.0.0.1", 0));
	printf("SetRoot = %d\n", UpnpSetWebServerRootDir(wd));
	free(wd);

	// Hang
	for (;;)
		pause();
}
diff -Nru libupnp-1.6.19+git20141001/debian/changelog 
libupnp-1.6.19+git20141001/debian/changelog
--- libupnp-1.6.19+git20141001/debian/changelog 2014-10-23 21:48:01.0 
+0100
+++ libupnp-1.6.19+git20141001/debian/changelog 2016-10-19 21:02:05.0 
+0100
@@ -1,3 +1,12 @@
+libupnp (1:1.6.19+git20141001-1+deb8u1) jessie-security; urgency=high
+
+  * Non-maintainer upload.
+  * Don't allow unhandled POSTs to write to the filesystem by
+default (Closes: #831857) (CVE-2016-6255)
+Thanks to Matthew Garrett for the patch.
+
+ -- James Cowgill <jcowg...@debian.org>  Wed, 19 Oct 2016 21:02:05 +0100
+
 libupnp (1:1.6.19+git20141001-1) unstable; urgency=low
 
   * Ack both NMUs, thankyou for your care of this package.
diff -Nru libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch 
libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch
--- libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch   
1970-01-01 01:00:00.0 +0100
+++ libupnp-1.6.19+git20141001/debian/patches/CVE-2016-6255.patch   
2016-10-19 21:00:38.0 +0100
@@ -0,0 +1,61 @@
+From c91a8a3903367e1163765b73eb4d43be7d7927fa Mon Sep 17 00:00:00 2001
+From: Matthew Garrett <mj...@srcf.ucam.org>
+Date: Tue, 23 Feb 2016 13:53:20 -0800
+Subject: [PATCH] Don't allow unhandled POSTs to write to the filesystem by
+ default
+
+If there's no registered handler for a POST request, the default behaviour
+is to write it to the filesystem. Several million deployed devices appear
+to have this behaviour, making it possible to (at least) store arbitrary
+data on them. Add a configure option that enables this behaviour, and change
+the default to just drop POSTs that aren't directly handled.
+
+Signed-off-by: Marcelo Roberto Jimenez <mrobe...@users.sourceforge.net>
+---
+ configure.ac | 4 
+ upnp/inc/upnpconfig.h.in | 5 +
+ upnp/src/genlib/net/http/webserver.c | 4 
+ 3 files changed, 13 insertions(+)
+
+--- a/configure.ac
 b/configure.ac
+@@ -495,6 +495,10 @@ if test "x$enable_blocking_tcp_connectio
+ AC_DEFINE(UPNP_ENABLE_BLOCKING_TCP_CONNECTIONS, 1, [see upnpconfig.h])
+ fi
+ 
++RT_BOOL_ARG_ENABLE([postwrite], [no], [write to the filesystem on otherwise 
unhandled POST requests])
++if test "x$enable_postwrite" = xyes ; then
++AC_DEFINE(UPNP_ENABLE_POST_WRITE, 1, [see upnpconfig.h])
++fi
+ 
+ RT_BOOL_ARG_ENABLE([samples], [yes], [compilation of upnp/sample/ code])
+ 
+--- a/upnp/inc/upnpconfig.h.in
 b/upnp/inc/upnpconfig.h.in
+@@ -131,5 +131,10 @@
+  * header (i.e. configure --enable-unspecified_server) */
+ #undef UPNP_ENABLE_UNSPECIFIED_SERVER
+ 
++/** Defined to 1 if the library has been compiled to support filesystem 
writes on POST
++ *  (i.e. configure --enable-postwrite) */
++#undef UPNP_ENABLE_POST_WRITE
++
++
+ #endif /* UPNP_CONFIG_H */
+ 
+--- a/upnp/src/genlib/net/http/webserver.c
 b/upnp/src/genlib/net/http/webserver.c
+@@ -1366,9 +1366,13 @@ static int http_RecvPostMessage(
+   if (Fp == NULL)
+   return HTTP_INTERNAL_SERVER_ERROR;
+   } else {
++#ifdef UPNP_ENABLE_POST_WRITE
+   Fp = fopen(filename, "wb");
+   if (Fp == NULL)
+   return HTTP_UNAUTHORIZED;
++#else
++  return HTTP_NOT_FOUND;
++#endif
+   }
+   parser->position = POS_ENTITY;
+   do {
diff -Nru libupnp-1.6.19+git20141001/debian/patches/series 
libupnp-1.6.19+git20141001/debian/patches/series
--- libupnp-1.6.19+git20141001/debian/patches/series2014-10-04 
05:26:29.0 +0100
+++ libupnp-1.6.19+git20141001/debian/patches/series2016-10-19 
21:00:43.0 +0100
@@ -5,3 +5,4 @@
 18-url-upnpstrings.patch
 19_fix_tests.patch
 21_fix-1.6.19+git.patch
+CVE-2016-6255.patch
diff -Nru libupnp-1.6.19+git20160116/debian/changelog 
libupnp-1.6.19+git2016

Bug#841344: moarvm: enable mips* archs

[James Cowgill]

Source: moarvm
Version: 2016.09+dfsg-2
Severity: wishlist

Hi,

I've managed to build both moarvm on the 3 mips archs (mips, mipsel and
mips64el) with no extra changes. Please can you allow this package to
build on mips.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841346: rakudo: enable mips* arches

[James Cowgill]

Source: rakudo
Version: 2016.09-2
Severity: wishlist
Control: block -1 by 841344

Hi,

I've managed to build rakudo on mips64el with no extra changes and it
should work on all 3 mips archs (mips, mipsel and mips64el) as well.
Please can you allow this package to build on mips.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841343: rakudo: FTBFS on arm64, powerpc and ppc64 - testsuite errors

[James Cowgill]

Source: rakudo
Version: 2016.09-2
Severity: serious
Tags: sid stretch

Hi,

rakudo FTBFS on arm64, powerpc and ppc64 with errors in the testsuite.

arm64 times out during the 't/04-nativecall/02-simple-args.t' test.

For powerpc the errors are:
t/04-nativecall/01-argless.t . ok
t/04-nativecall/02-simple-args.t . ok
t/04-nativecall/03-simple-returns.t ..
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/11 subtests
t/04-nativecall/04-pointers.t  ok
t/04-nativecall/05-arrays.t .. ok
t/04-nativecall/06-struct.t .. ok
t/04-nativecall/07-writebarrier.t  ok
t/04-nativecall/08-callbacks.t ... ok
t/04-nativecall/09-nativecast.t .. ok
t/04-nativecall/10-cglobals.t  ok
t/04-nativecall/11-cpp.t . ok
t/04-nativecall/12-sizeof.t .. ok
t/04-nativecall/13-cpp-mangling.t  ok
t/04-nativecall/13-union.t ... ok
t/04-nativecall/14-rw-attrs.t 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/16 subtests
t/04-nativecall/15-rw-args.t .
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/22 subtests
t/04-nativecall/16-rt125408.t  ok
t/04-nativecall/16-rt125729.t  ok
t/04-nativecall/17-libnames.t  ok
t/04-nativecall/18-routine-sig-sanity.t .. ok
t/04-nativecall/19-function-pointers.t ... ok

Test Summary Report
---
t/04-nativecall/03-simple-returns.t(Wstat: 1024 Tests: 11 Failed: 4)
  Failed tests:  2-3, 9-10
  Non-zero exit status: 4
t/04-nativecall/14-rw-attrs.t  (Wstat: 256 Tests: 16 Failed: 1)
  Failed test:  15
  Non-zero exit status: 1
t/04-nativecall/15-rw-args.t   (Wstat: 1024 Tests: 22 Failed: 4)
  Failed tests:  2, 4, 14, 16
  Non-zero exit status: 4
Files=45, Tests=600, 139 wallclock secs ( 0.30 usr  0.06 sys + 136.86
cusr  1.64 csys = 138.86 CPU)
Result: FAIL

The ppc64 errors are all in the nativecall tests as well.

Full build logs:
https://buildd.debian.org/status/package.php?p=rakudo

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841316: gcc: the last 6.2.0-7 broke the virtualbox build

[James Cowgill]

Hi,

On Wed, 19 Oct 2016 14:47:48 + (UTC) Gianfranco Costamagna
 wrote:
> Source: gcc
> Version: 6.2.0-7
> Severity: serious
> 
> As said, I built virtualbox correctly with 6.2.0-6 and then uploaded on 
> unstable.
> The new gcc 6.2.0-7 broke the build with the following error:
[...]
> /usr/include/x86_64-linux-gnu/sys/inotify.h:34:13: error: flexible array 
> member 'inotify_event::name' not at end of 'struct InotifyEventWithName'

Relevant parts:

cdefs.h
---
# define __flexarr  []

inotify.h

/* Structure describing an inotify event.  */
struct inotify_event
{
  int wd;   /* Watch descriptor.  */
  uint32_t mask;/* Watch mask.  */
  uint32_t cookie;  /* Cookie to synchronize two events.  */
  uint32_t len; /* Length (including NULs) of name.  */
  char name __flexarr;  /* Name.  */
};

HostDnsServiceLinux.cpp:

struct InotifyEventWithName
{
struct inotify_event e;
char name[NAME_MAX];
};

While I do not know if this is a GCC bug or not, doing the above is a
bit dodgy (and prohibited by C99). What is the offset of
InotifyEventWithName::name supposed to be (given sizeof(inotify_event)
is undefined)?

This report has some info about GCC 6 changes in this regard:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550

Since it's closed as WONTFIX, I expect this will not be changed in gcc.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841300: arcboot: remove this package?

[James Cowgill]

Source: arcboot
Version: 0.3.15
Severity: serious
Tags: sid stretch

Hi,

Given that stretch will drop support for pre-mips32r2 processors
including the SGI IP22 and IP32, should this package be removed?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#795316: jackd2: Suggestion to fix overly-liberal shlibs for libjacknet

[James Cowgill]

Control: tags -1 - patch

On Wed, 12 Aug 2015 14:38:38 -0700 Steve Langasek
 wrote:
> Package: jackd2
> Version: 1.9.10+20140719git3eb0ae6a~dfsg-3
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu wily ubuntu-patch
> 
> Dear maintainer,
> 
> I know you've only just fixed the shlibs file to correct jackd2's FTBFS
> failure, but I'd like to recommend a change to the shlibs handling.  As part
> of preparing the g++5 ABI transition in Ubuntu, it came to light that:
> 
>  - libjacknet is a private library, and
>  - its ABI is impacted by the g++5 ABI transition
> 
> So while the current shlibs fix the build failure, in the unlikely event
> that something *did* link against libjacknet (unlikely because it's a
> private library with no headers in the -dev package), that package would
> have a wrong dependency, which would be satisfied by other versions of the
> package with known-incompatible ABI.

As far as I can tell (as I don't deal much with jack), libjacknet is not
a private library. It is used to create network slaves which communicate
with a jack server over the network. The header for it is
/usr/include/jack/net.h.

Also, I don't think it is affected by the g++5 ABI transition because
all the C++ symbols are not part of the ABI - the main API is C (the C++
symbols should probably be hidden).

I think the best solution is to move it into a separate package since
the library is not used much (compared to the main jack client library).
Having said that, it's not too important as I don't think there are any
ABI issues here.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841278: strace: new upstream version

[James Cowgill]

Source: strace
Version: 4.13-0.1
Severity: wishlist

Hi Steve,

A new upstream version of strace was recently release (4.14) about two
weeks ago. It contains my mips64el fixes so it would to get it into
stretch so strace can run there.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841173: openjdk-9: FTBFS on mips*

[James Cowgill]

On 18/10/16 10:32, James Cowgill wrote:
> The patch was originally written for 9~b139-1, but I'm running another
> build now for 9~b140-1 and I will let you know how it goes
> (unfortunately it takes ages).

I tested openjdk-9_9~b140-1 with my patch on amd64, mips64el and mipsel
and it built fine on all of them.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841224: MediaTomb Multiple Remote Vulnerabilities

[James Cowgill]

Control: severity -1 grave
Control: tags -1 security
Control: retitle -1 mediatomb: libupnp vulnerabilities CVE-2012-5958, 
CVE-2012-5959, CVE-2012-5960, CVE-2016-6255
Control: found -1 0.12.1-4

On 18/10/16 17:17, Brian Martin wrote:
> Package: mediatomb
> Version: 0.12.1-47

This version does not exist, I have marked it as found in 0.12.1-4
(pre-wheezy) as a conservative guess.

> This was discovered on Ubuntu and reported to them. Ubuntu replied that
> the package is inherited from Debian "which means it isn't supported by
> the Ubuntu Security Team."

The reason it's not supported in Ubuntu is because it's in the
"universe" repository which does not get security support (not that it
comes from Debian).

> While testing a new NASL detection script, we found it was causing a
> crash in MediaTomb. Specifically, there is a NULL pointer dereference at
> in the function check_soap_body() in soap_device.c (line 470). We went
> to see if this had been patched in libupnp and found that it had been
> patched eight years ago
> (https://sourceforge.net/p/pupnp/code/ci/2c094ee8ea01259967f82513296b031f718603fd/).
> 
> 
> Given that MediaTomb is still being distributed by Ubuntu and more than
> 1,000 instances are visible via Shodan
> (https://www.shodan.io/search?query=MediaTomb), we will make a
> best-effort to quickly flag some of the vulnerabilities that we know
> have been fixed in libupnp and still exist in MediaTomb. All of the
> below have been tested on Ubuntu 16.04 x64 Desktop using mediatomb-dbg.
> We believe them to be vulnerable in Debian 8.6 (jesse) as well.
> 
> CVE-2012-5958, CVE-2012-5959, CVE-2012-5960
[...]
> CVE-2016-6255
> 
> This allows a remote unauthenticated attacker create arbitrary files in
> the WebRoot simply by sending an HTTP POST request. Note that Ubuntu's
> mediatomb installation must have write permission to the WebRoot
> directory. This issue has been patched by c91a8a3
> (https://sourceforge.net/p/pupnp/code/ci/c91a8a3903367e1163765b73eb4d43be7d7927fa/)
> and 66e43a2
> (https://sourceforge.net/p/pupnp/code/ci/66e43a28d27fee95d270d2b8106d8a099c14f334/).
> We wrote a PoC cleverly called "cve-2016-6255.py" that when used like so:
> 
> $ ./cve-2016-6255.py http://192.168.1.217:49153/danger_zone

Apparently it is not possible to remove mediatomb's copy of libupnp due
to the number of changes and those changes cannot be upstreamed due to
licensing issues. This means the libupnp fixed will have to be patched
into mediatomb.

Unfortunately upstream has been fairly inactive over the last few years
so any fixes probably won't come from them :( 

Thanks for reporting!
James



signature.asc
Description: OpenPGP digital signature

Bug#766424: jackd2: please enable using OSS on GNU/kFreeBSD

[James Cowgill]

Control: tags -1 - patch

Hi Steven,

On Thu, 23 Oct 2014 00:33:58 +0100 Steven Chamberlain wrote:
> Package: jackd2
> Version: 1.9.10+20140719git3eb0ae6a~dfsg-2
> Severity: important
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
> 
> Hi,
> 
> Please could you accept this patch to use OSS on GNU/kFreeBSD.
> Otherwise jackd2 does not have any useful local audio device backends.
> 
> This has been well-tested on my system.

Unfortunately this patch no longer applies. Is it possible for you to
have another look (and submit it upstream)?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841195: translate-shell: mplayer2 has gone away

[James Cowgill]

Package: translate-shell
Version: 0.9.4-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
suggested packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841192: mozplugger: mplayer2 has gone away

[James Cowgill]

Package: mozplugger
Version: 1.14.5-2
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
suggested packages.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841193: qmmp: mplayer2 has gone away

[James Cowgill]

Package: qmmp
Version: 1.1.4-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
suggested packages.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841190: doublecmd-common: mplayer2 has gone away

[James Cowgill]

Package: doublecmd-common
Version: 0.7.5-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
suggested packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841189: anki: mplayer2 has gone away

[James Cowgill]

On 18/10/16 13:21, James Cowgill wrote:
> Package: anki
> Version: 2.0.32+dfsg-1
> Severity: minor
> 
> Hi,
> 
> mplayer2 no longer exists in stretch, please can you remove it from the
> recommended packages.

Woops, that should be "suggested" and not "recommended".

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841189: anki: mplayer2 has gone away

[James Cowgill]

Package: anki
Version: 2.0.32+dfsg-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841187: youtube-dl: mplayer2 has gone away

[James Cowgill]

Package: youtube-dl
Version: 2016.06.25-2
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841186: simpleburn: mplayer2 has gone away

[James Cowgill]

Package: simpleburn
Version: 1.7.3-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

As a replacement, mpv is probably closer to mplayer2 than mplayer is so
you may want to add that to the list of recommends instead.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841184: debian-edu: mplayer2 has gone away

[James Cowgill]

Source: debian-edu
Version: 1.910
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

Thanks,
James




signature.asc
Description: OpenPGP digital signature

Bug#841182: mps-youtube: mplayer2 has gone away

[James Cowgill]

Package: mps-youtube
Version: 0.2.7.1-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

(on a side node, libav-tools is now a transitional package so you could
remove that too)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841183: dvbcut: mplayer2 has gone away

[James Cowgill]

Package: dvbcut
Version: 0.7.0-1
Severity: minor

Hi,

mplayer2 no longer exists in stretch, please can you remove it from the
recommended packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#841173: openjdk-9: FTBFS on mips*

[James Cowgill]

Source: openjdk-9
Version: 9~b139-1
Severity: important
Tags: patch

Hi,

openjdk-9 FTBFS on mips* with the error:

/«PKGBUILDDIR»/src/hotspot/src/os/linux/vm/jsig.c:47:2: error: #error
"Not all signals can be encoded in jvmsigs. Adapt its type!"
 #error "Not all signals can be encoded in jvmsigs. Adapt its type!"
  ^

This is because MIPS has 128 signals which the code added to OpenJDK 9
does not take into account. The attached patch fixes this by using
sigset_t to store the list of signals used by the JVM.

The patch was originally written for 9~b139-1, but I'm running another
build now for 9~b140-1 and I will let you know how it goes
(unfortunately it takes ages).

Thanks,
James
Description: Use sigset_t to store the signals used by the JVM
 On mips there are 128 signals so uint64_t is not big enough to store all of
 them. Replace the current method of storing the signals with a sigset_t which
 will work on all architectures.
Author: James Cowgill <jcowg...@debian.org>

diff -u b/hotspot/src/os/linux/vm/jsig.c b/hotspot/src/os/linux/vm/jsig.c
--- b/hotspot/src/os/linux/vm/jsig.c
+++ b/hotspot/src/os/linux/vm/jsig.c
@@ -41,13 +41,8 @@
 #define true 1
 #define false 0
 
-#define MASK(sig) ((uint64_t)1 << (sig-1))  // 0 is not a signal.
-// Check whether all signals fit into jvmsigs. -1 as MASK shifts by -1.
-#if (64 < NSIG-1)
-#error "Not all signals can be encoded in jvmsigs. Adapt its type!"
-#endif
 static struct sigaction sact[NSIG]; /* saved signal handlers */
-static uint64_t jvmsigs = 0; /* signals used by jvm */
+static sigset_t jvmsigs; /* signals used by jvm */
 
 /* used to synchronize the installation of signal handlers */
 static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -65,6 +60,11 @@
 static bool jvm_signal_installing = false;
 static bool jvm_signal_installed = false;
 
+static __attribute__((constructor)) void jvmsigs_init(void)
+{
+sigemptyset();
+}
+
 static void signal_lock() {
   pthread_mutex_lock();
   /* When the jvm is installing its set of signal handlers, threads
@@ -110,7 +110,7 @@
 
   signal_lock();
 
-  sigused = (sig < NSIG) && ((MASK(sig) & jvmsigs) != 0);
+  sigused = (sig < NSIG) && sigismember(, sig);
   if (jvm_signal_installed && sigused) {
 /* jvm has installed its signal handler for this signal. */
 /* Save the handler. Don't really install it. */
@@ -127,7 +127,7 @@
 save_signal_handler(sig, oldhandler);
 
 /* Record the signals used by jvm */
-jvmsigs |= MASK(sig);
+sigaddset(, sig);
 
 signal_unlock();
 return oldhandler;
@@ -168,7 +168,7 @@
 
   signal_lock();
 
-  sigused = (sig < NSIG) && ((MASK(sig) & jvmsigs) != 0);
+  sigused = (sig < NSIG) && sigismember(, sig);
   if (jvm_signal_installed && sigused) {
 /* jvm has installed its signal handler for this signal. */
 /* Save the handler. Don't really install it. */
@@ -191,7 +191,7 @@
 }
 
 /* Record the signals used by jvm */
-jvmsigs |= MASK(sig);
+sigaddset(, sig);
 
 signal_unlock();
 return res;
@@ -223,7 +223,7 @@
 
 struct sigaction *JVM_get_signal_action(int sig) {
   /* Does race condition make sense here? */
-  if ((MASK(sig) & jvmsigs) != 0) {
+  if (sigismember(, sig)) {
 return [sig];
   }
   return NULL;
only in patch2:
unchanged:
--- a/hotspot/src/os/linux/vm/os_linux.cpp
+++ b/hotspot/src/os/linux/vm/os_linux.cpp
@@ -4206,14 +4206,16 @@ bool os::Linux::signal_handlers_are_inst
 
 // For signal-chaining
 struct sigaction sigact[NSIG];
-uint64_t sigs = 0;
-#if (64 < NSIG-1)
-#error "Not all signals can be encoded in sigs. Adapt its type!"
-#endif
+sigset_t sigs;
 bool os::Linux::libjsig_is_loaded = false;
 typedef struct sigaction *(*get_signal_t)(int);
 get_signal_t os::Linux::get_signal_action = NULL;
 
+static __attribute__((constructor)) void sigs_init()
+{
+sigemptyset();
+}
+
 struct sigaction* os::Linux::get_chained_signal_action(int sig) {
   struct sigaction *actp = NULL;
 
@@ -4288,7 +4290,7 @@ bool os::Linux::chained_handler(int sig,
 }
 
 struct sigaction* os::Linux::get_preinstalled_handler(int sig) {
-  if uint64_t)1 << (sig-1)) & sigs) != 0) {
+  if (sigismember(, sig)) {
 return [sig];
   }
   return NULL;
@@ -4297,7 +4299,7 @@ struct sigaction* os::Linux::get_preinst
 void os::Linux::save_preinstalled_handler(int sig, struct sigaction& oldAct) {
   assert(sig > 0 && sig < NSIG, "vm signal out of expected range");
   sigact[sig] = oldAct;
-  sigs |= (uint64_t)1 << (sig-1);
+  sigaddset(, sig);
 }
 
 // for diagnostic


signature.asc
Description: OpenPGP digital signature

Bug#840894: llvm-3.8: lli-3.8 man page contains fakeroot error

[James Cowgill]

Package: llvm-3.8
Version: 1:3.8.1-12
Severity: normal

Hi,

The man page for lli-3.8 contains a fakeroot error near the top:

DESCRIPTION

ERROR:  ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.  OVERVIEW: llvm
interpreter & dynamic compiler

It's also very poorly formatted (compared to lli-3.5 at least), but that
may be caused by the above error.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#840825: libtag1-dev: missing header files

[James Cowgill]

Package: libtag1-dev
Version: 1.11+dfsg.1-0.1
Severity: serious
Control: affects -1 kid3
X-Debbugs-CC: m...@lm7.fr

Hi,

taglib 1.11+dfsg.1-0.1 and 1.11+dfsg.1-0.2 are missing various include
files which should be shipped in /usr/include. These are reported by
dh_install:

dh_install --list-missing
dh_install: usr/include/taglib/podcastframe.h exists in debian/tmp but
is not installed to anywhere
dh_install: usr/include/taglib/tableofcontentsframe.h exists in
debian/tmp but is not installed to anywhere
dh_install: usr/include/taglib/eventtimingcodesframe.h exists in
debian/tmp but is not installed to anywhere
dh_install: usr/include/taglib/chapterframe.h exists in debian/tmp but
is not installed to anywhere
dh_install: usr/include/taglib/synchronizedlyricsframe.h exists in
debian/tmp but is not installed to anywhere

This at least breaks kid3 which uses these headers if taglib is new
enough. Can I also suggest enabling "dh_install --fail-missing" so this
doesn't happen again :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#840775: bowtie: enable some more 64-bit arches

[James Cowgill]

Source: bowtie
Version: 1.1.2-5
Severity: wishlist
Tags: patch

Hi,

I've attached a patch adding support for all the other 64-bit arches
which have Debian ports.

Instead of listing them all in the Makefile, I invoked gcc to ask if it
was using 64-bit pointers (using __LP64__). This is important on some
arches (like mips) since the 32-bit mips buildds run 64-bit kernels and
running "uname -m" gives "mips64".

Tested on mips64el.

Thanks,
James
diff -Nru bowtie-1.1.2/debian/control bowtie-1.1.2/debian/control
--- bowtie-1.1.2/debian/control	2016-05-25 23:44:22.0 +0100
+++ bowtie-1.1.2/debian/control	2016-10-14 14:47:00.0 +0100
@@ -15,7 +15,7 @@
 Homepage: http://bowtie-bio.sourceforge.net/
 
 Package: bowtie
-Architecture: amd64 kfreebsd-amd64 arm64 ppc64el
+Architecture: alpha any-amd64 arm64 mips64el ppc64 ppc64el s390x sparc64
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  python
diff -Nru bowtie-1.1.2/debian/patches/gcc-64bit.patch bowtie-1.1.2/debian/patches/gcc-64bit.patch
--- bowtie-1.1.2/debian/patches/gcc-64bit.patch	1970-01-01 01:00:00.0 +0100
+++ bowtie-1.1.2/debian/patches/gcc-64bit.patch	2016-10-14 14:47:00.0 +0100
@@ -0,0 +1,23 @@
+Description: Use gcc to determine if an arch is 64-bit
+ uname -m is misleading when determining if an arch is 64-bit or not
+ - It indicates the _build_ machine's processor which may not be the same as the
+   processor the code is being built for (cross compiling).
+ - It fails if a 32-bit compiler is used on a 64-bit cpu (eg build i386 packages
+   on x86_64). This is common on the mips buildds.
+ Therefore ask GCC if this architecture is 64-bit. Using __LP64__ is the easiest
+ method, but is not portable and probably only works with GCC and Clang
+ unfortunatly.
+Author: James Cowgill <jcowg...@debian.org>
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Makefile
 b/Makefile
+@@ -125,7 +125,7 @@ SEARCH_FRAGMENTS = $(wildcard search_*_p
+ VERSION = $(shell cat VERSION)
+ 
+ BITS=32
+-ifneq (,$(filter $(shell uname -m), aarch64 ppc64le x86_64))
++ifeq (1,$(shell echo __LP64__ | $(CC) -P -E -))
+ 	BITS=64
+ endif
+ # msys will always be 32 bit so look at the cpu arch instead.
diff -Nru bowtie-1.1.2/debian/patches/series bowtie-1.1.2/debian/patches/series
--- bowtie-1.1.2/debian/patches/series	2016-05-25 23:03:35.0 +0100
+++ bowtie-1.1.2/debian/patches/series	2016-10-14 14:47:00.0 +0100
@@ -12,3 +12,4 @@
 enable_arm64.patch
 spelling.patch
 reproducible.patch
+gcc-64bit.patch


signature.asc
Description: OpenPGP digital signature

Bug#840655: O: eldav -- interface to the WebDAV servers for Emacs.

[James Cowgill]

Hi,

On 13/10/16 16:38, Adrian Bunk wrote:
> On Thu, Oct 13, 2016 at 04:25:48PM +0100, James Cowgill wrote:
>> Hi,
> 
> Hi James,
> 
>> On 13/10/16 16:19, TANIGUCHI Takaki wrote:
>>> Package: wnpp
>>> Severity: normal
>>>
>>> * I'm not using this package regularly.
>>> * Dead upstream
>>
>> Why orphan and not remove?
> 
> why remove?

I was only asking...

As the package states, there is already an emcas WebDAV interface. The
purpose of eldav appears to be a smaller WebDAV client (disclaimer: I
have not used either).

There is no upstream and the last upstream release is 13 years old. In
this time no-one appears - from my extremely extensive google search :)
- to have continued development and now the package has no maintainer I
think it's likely that it will just rot.

> eldav seems to be in a better state than some of the stuff that gets 
> ITP'ed into Debian every day.

You're probably right about that.

James



signature.asc
Description: OpenPGP digital signature

Bug#840655: O: eldav -- interface to the WebDAV servers for Emacs.

[James Cowgill]

Hi,

On 13/10/16 16:19, TANIGUCHI Takaki wrote:
> Package: wnpp
> Severity: normal
> 
> * I'm not using this package regularly.
> * Dead upstream

Why orphan and not remove?

James



signature.asc
Description: OpenPGP digital signature

Bug#820334: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers

[James Cowgill]

Control: tags -1 patch fixed-upstream

Hi,

On 06/10/16 09:42, James Cowgill wrote:
> Control: forwarded -1 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/147
> Control: tags -1 sid stretch
> 
> Hi,
> 
> I've submitted the above PR upstream which should fix this issue. The
> patch was a bit bigger than what I would have liked due to the cmELF
> class requiring some changes.

The PR was accepted and I've attached a patch which backports it to 3.6.

Thanks,
James
From c51099bb1018191964e5ee05e17f133233160806 Mon Sep 17 00:00:00 2001
From: James Cowgill <jcowg...@debian.org>
Date: Thu, 13 Oct 2016 11:00:00 +0100
Subject: [PATCH] MIPS: Handle DT_MIPS_RLD_MAP_REL tag when removing RPath from
 ELFs

This is a combination of 5 commits.

elf: remove tag switch from ELF_Dyn ByteSwap function
elf: add DynamicEntryList methods and rpath tag constants
cmSystemTools: rewrite RemoveRPath using DyanmicEntryList methods
cmSystemTools, elf: handle DT_MIPS_RLD_REL_MAP in RemoveRPath
elf: Remove GetDynamicEntryCount and ReadBytes methods

Backported from upstream 3.8.0 commit:
ea563a27a2042cfb3be33d0f74efecc7687b86bb
---
 Source/cmELF.cxx | 225 ---
 Source/cmELF.h   |  24 +++--
 Source/cmSystemTools.cxx |  72 ---
 3 files changed, 135 insertions(+), 186 deletions(-)

diff --git a/Source/cmELF.cxx b/Source/cmELF.cxx
index 26f1a44..9fe8a43 100644
--- a/Source/cmELF.cxx
+++ b/Source/cmELF.cxx
@@ -134,18 +134,13 @@ public:
 
   // Forward to the per-class implementation.
   virtual unsigned int GetNumberOfSections() const = 0;
-  virtual unsigned int GetDynamicEntryCount() = 0;
   virtual unsigned long GetDynamicEntryPosition(int j) = 0;
+  virtual cmELF::DynamicEntryList GetDynamicEntries() = 0;
+  virtual std::vector EncodeDynamicEntries(
+const cmELF::DynamicEntryList&) = 0;
   virtual StringEntry const* GetDynamicSectionString(unsigned int tag) = 0;
   virtual void PrintInfo(std::ostream& os) const = 0;
 
-  bool ReadBytes(unsigned long pos, unsigned long size, char* buf)
-  {
-this->Stream.seekg(pos);
-this->Stream.read(buf, size);
-return this->Stream ? true : false;
-  }
-
   // Lookup the SONAME in the DYNAMIC section.
   StringEntry const* GetSOName()
   {
@@ -246,10 +241,12 @@ public:
 return static_cast(this->ELFHeader.e_shnum);
   }
 
-  // Get the file position and size of a dynamic section entry.
-  virtual unsigned int GetDynamicEntryCount();
+  // Get the file position of a dynamic section entry.
   virtual unsigned long GetDynamicEntryPosition(int j);
 
+  virtual cmELF::DynamicEntryList GetDynamicEntries();
+  virtual std::vector EncodeDynamicEntries(const cmELF::DynamicEntryList&);
+
   // Lookup a string from the dynamic section with the given tag.
   virtual StringEntry const* GetDynamicSectionString(unsigned int tag);
 
@@ -289,6 +286,10 @@ public:
   }
 
 private:
+  // ByteSwap(ELF_Dyn) assumes d_val and d_ptr are the same size
+  typedef char dyn_size_assert
+[sizeof(ELF_Dyn().d_un.d_val) == sizeof(ELF_Dyn().d_un.d_ptr) ? 1 : -1];
+
   void ByteSwap(ELF_Ehdr& elf_header)
   {
 cmELFByteSwap(elf_header.e_type);
@@ -323,121 +324,7 @@ private:
   void ByteSwap(ELF_Dyn& dyn)
   {
 cmELFByteSwap(dyn.d_tag);
-switch (dyn.d_tag) {
-  case DT_NULL: /* dyn.d_un ignored */
-break;
-  case DT_NEEDED:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_PLTRELSZ:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_PLTGOT:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_HASH:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_STRTAB:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_SYMTAB:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_RELA:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_RELASZ:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_RELAENT:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_STRSZ:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_SYMENT:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_INIT:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_FINI:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_SONAME:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_RPATH:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_SYMBOLIC: /* dyn.d_un ignored */
-break;
-  case DT_REL:
-cmELFByteSwap(dyn.d_un.d_ptr);
-break;
-  case DT_RELSZ:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_RELENT:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case DT_PLTREL:
-cmELFByteSwap(dyn.d_un.d_val);
-break;
-  case

Bug#839486: lhasa: FTBFS: Tests failures

[James Cowgill]

Control: tags -1 patch

Hi,

On Sat, 1 Oct 2016 16:16:05 +0200 Lucas Nussbaum  wrote:
> Source: lhasa
> Version: 0.3.1-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161001 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
[...]
> FAIL: test-file-headers
> ===
> 
> --- output/larc333/lz4.lzs-hdr.txt2016-03-30 02:24:28.0 +
> +++ /tmp/lhasa-test.bbrkwr/hdr.txt2016-10-01 11:46:04.06800 +
> @@ -5,5 +5,5 @@
>  header_level: 0
>  os_type: 0
>  crc: b6d5
> -timestamp: 1273184274
> +timestamp: 1273187874
>  --
> Output not as expected for larc333/lz4.lzs
> rmdir: failed to remove '/tmp/lhasa-test.bbrkwr': Directory not empty
> FAIL test-file-headers (exit status: 1)

This appears to be due to timezone differences on the build machine.
test/test_common.sh handles this using:

TZ=Europe/London
export TZ

But this doesn't work if tzdata isn't installed!

Applying the attached patch to add tzdata to the build dependencies
fixes this bug for me.

Thanks,
James
diff -ur a/debian/control b/debian/control
--- a/debian/control	2016-03-31 20:08:13.0 +
+++ b/debian/control	2016-10-11 11:42:20.257704348 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Jonathan Dowland 
 Build-Depends: debhelper (>= 9.20120115), automake (>= 1:1.11.3),
-   autoconf (>= 2.68), libtool (>= 2.4.2)
+   autoconf (>= 2.68), libtool (>= 2.4.2), tzdata
 Standards-Version: 3.9.6
 Homepage: http://fragglet.github.com/lhasa/
 Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/lhasa.git


signature.asc
Description: OpenPGP digital signature

Bug#840271: Removed package(s) from unstable (codelite)

[James Cowgill]

Hi,

On 10/10/16 11:23, Debian FTP Masters wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
> 
>   codelite | 9.2+dfsg-2 | powerpc
> codelite-plugins | 9.2+dfsg-2 | powerpc
> 
> --- Reason ---
> ROM; nodejs no longer built on powerpc
> --

I don't understand. codelite neither Build-Depends nor Depends on nodejs
so this removal seems completely pointless to me. Codelite is just going
to reappear on powerpc when I next upload a new version.

Also, it would be great if you could CC the maintainer before removing
packages.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#798043: lives: creates (and uses) world-writeable directory

[James Cowgill]

Hi,

On 01/10/16 07:23, salsaman wrote:
> James, I was wondering what action should be taken regarding
> directory/subdirectory permissions for existing users. The options I can
> think of (from simplest to most complex): a) do nothing, only new users
> get the benefit. b) add a note in Release Notes informing users how to
> update the directory permissions manually, or c) Show a one time pop-up
> when LiVES is upgraded asking the user if they want the program to
> update permissions for the working directory for them, and if they click
> Yes, do the update for them.
> 
> Which of the options do you recommend ?

Sorry for not replying sooner - I've been quite busy recently!

I think c is the nicest solution for users so if you're prepared to
implement it, that would be the best solution. Adding something to the
release notes and possibly the debian/NEWS file is probably OK if not.

I think we need to tell users somehow, so not option a :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#834147: binutils: breaks mips and mipsel link of blender

[James Cowgill]

Control: tags -1 patch

Hi,

On 29/09/16 16:26, James Cowgill wrote:
> It turns out that the bug probably is in binutils and not gcc after all
> (see the original GCC bug). Updating the new bug forward address
> accordingly.

I've attached the patch posted in the upstream bugreport. Please can it
be applied to the Debian binutils package.

Thanks,
James
Index: binutils/gas/config/tc-mips.c
===
--- binutils.orig/gas/config/tc-mips.c	2016-09-29 05:12:31.0 +0100
+++ binutils/gas/config/tc-mips.c	2016-09-29 20:05:13.257411084 +0100
@@ -1353,7 +1353,7 @@ static void s_mips_stab (int);
 static void s_mips_weakext (int);
 static void s_mips_file (int);
 static void s_mips_loc (int);
-static bfd_boolean pic_need_relax (symbolS *, asection *);
+static bfd_boolean pic_need_relax (symbolS *);
 static int relaxed_branch_length (fragS *, asection *, int);
 static int relaxed_micromips_16bit_branch_length (fragS *, asection *, int);
 static int relaxed_micromips_32bit_branch_length (fragS *, asection *, int);
@@ -4258,6 +4258,8 @@ mips_move_text_labels (void)
   mips_move_labels (seg_info (now_seg)->label_list, TRUE);
 }
 
+/* Duplicate the test for LINK_ONCE sections as in `adjust_reloc_syms'.  */
+
 static bfd_boolean
 s_is_linkonce (symbolS *sym, segT from_seg)
 {
@@ -14823,7 +14825,7 @@ mips_frob_file (void)
 	 constants; we'll report an error for those later.  */
   if (got16_reloc_p (l->fixp->fx_r_type)
 	  && !(l->fixp->fx_addsy
-	   && pic_need_relax (l->fixp->fx_addsy, l->seg)))
+	   && pic_need_relax (l->fixp->fx_addsy)))
 	continue;
 
   /* Check quickly whether the next fixup happens to be a matching %lo.  */
@@ -17043,7 +17045,7 @@ nopic_need_relax (symbolS *sym, int befo
 /* Return true if the given symbol should be considered local for SVR4 PIC.  */
 
 static bfd_boolean
-pic_need_relax (symbolS *sym, asection *segtype)
+pic_need_relax (symbolS *sym)
 {
   asection *symsec;
 
@@ -17068,7 +17070,6 @@ pic_need_relax (symbolS *sym, asection *
   return (!bfd_is_und_section (symsec)
 	  && !bfd_is_abs_section (symsec)
 	  && !bfd_is_com_section (symsec)
-	  && !s_is_linkonce (sym, segtype)
 	  /* A global or weak symbol is treated as external.  */
 	  && (!S_IS_WEAK (sym) && !S_IS_EXTERNAL (sym)));
 }
@@ -17507,7 +17508,7 @@ md_estimate_size_before_relax (fragS *fr
   if (mips_pic == NO_PIC)
 change = nopic_need_relax (fragp->fr_symbol, 0);
   else if (mips_pic == SVR4_PIC)
-change = pic_need_relax (fragp->fr_symbol, segtype);
+change = pic_need_relax (fragp->fr_symbol);
   else if (mips_pic == VXWORKS_PIC)
 /* For vxworks, GOT16 relocations never have a corresponding LO16.  */
 change = 0;


signature.asc
Description: OpenPGP digital signature

Bug#820334: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers

[James Cowgill]

Control: forwarded -1 https://gitlab.kitware.com/cmake/cmake/merge_requests/147
Control: tags -1 sid stretch

Hi,

I've submitted the above PR upstream which should fix this issue. The
patch was a bit bigger than what I would have liked due to the cmELF
class requiring some changes.

Tagging for stretch since jessie contains binutils 2.25 which is
unaffected.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#839731: jessie-pu: package mpg123/1.20.1-2+deb8u1

[James Cowgill]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-multimedia-maintain...@lists.alioth.debian.org

Hi,

A security issue was reported against mpg123 in bug #838960. Since it
was marked no-DSA by the security team, it needs a normal jessie-pu
update to fix it in jessie.

The debdiff is attached. I've tested it on jessie against the testcase
provided in the upstream bug report (https://mpg123.org/bugs/240).

Thanks,
James

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

Kernel: Linux 4.4.0-36-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru mpg123-1.20.1/debian/changelog mpg123-1.20.1/debian/changelog
--- mpg123-1.20.1/debian/changelog  2014-08-31 10:51:53.0 +0100
+++ mpg123-1.20.1/debian/changelog  2016-10-04 11:42:56.0 +0100
@@ -1,3 +1,10 @@
+mpg123 (1.20.1-2+deb8u1) jessie; urgency=high
+
+  * Team upload.
+  * Fix DoS with crafted ID3v2 tags. (Closes: #838960)
+
+ -- James Cowgill <jcowg...@debian.org>  Tue, 04 Oct 2016 11:42:56 +0100
+
 mpg123 (1.20.1-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru mpg123-1.20.1/debian/patches/0002-dos-crafted-id3v2-tags.patch 
mpg123-1.20.1/debian/patches/0002-dos-crafted-id3v2-tags.patch
--- mpg123-1.20.1/debian/patches/0002-dos-crafted-id3v2-tags.patch  
1970-01-01 01:00:00.0 +0100
+++ mpg123-1.20.1/debian/patches/0002-dos-crafted-id3v2-tags.patch  
2016-10-04 11:41:20.0 +0100
@@ -0,0 +1,18 @@
+Description: Fix DoS with crafted ID3v2 tags
+Author: Thomas Orgis <thomas-fo...@orgis.org>
+Bug: https://sourceforge.net/p/mpg123/bugs/240/
+Bug-Debian: https://bugs.debian.org/838960
+Applied-Upstream: 1.23.8
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/libmpg123/id3.c
 b/src/libmpg123/id3.c
+@@ -752,7 +752,7 @@ int parse_new_id3(mpg123_handle *fr, uns
+   unsigned long fflags; /* need 16 bits, 
actually */
+   id[4] = 0;
+   /* pos now advanced after ext head, now 
a frame has to follow */
+-  while(tagpos < length-10) /* I want to 
read at least a full header */
++  while(length >= 10 && tagpos < 
length-10) /* I want to read at least a full header */
+   {
+   int i = 0;
+   unsigned long pos = tagpos;
diff -Nru mpg123-1.20.1/debian/patches/series 
mpg123-1.20.1/debian/patches/series
--- mpg123-1.20.1/debian/patches/series 2014-08-30 20:39:33.0 +0100
+++ mpg123-1.20.1/debian/patches/series 2016-10-04 11:41:20.0 +0100
@@ -1 +1,2 @@
 0001-disable_not_public_funcs.patch
+0002-dos-crafted-id3v2-tags.patch


signature.asc
Description: OpenPGP digital signature